Pasar de un proyecto de un hombre a un proyecto de equipo en el futuro. ¿Qué debo hacer ahora en preparación y qué puedo esperar?

Para dar más detalles, estoy interesado en saber qué piensa la gente que necesita implementar mientras aún es un proyecto de un solo hombre (control de la fuente del equipo, documentación, compilaciones, etc.) y qué cosas no es necesario hacer hasta ese punto cuando llegue la segunda persona en el proyecto.

Cualquier persona con experiencia en moverse a través de este escenario, apreciará sus ideas.

Lo que he aprendido (Intenté un orden diferente. Me equivoqué. Este es el orden en que las cosas se vuelven relevantes).

1. Ponga todo en el control del código fuente. Use algo a lo que todos tengan acceso y comience ahora mismo . Sin excepciones. Sin demoras No hay excusas.

2. Cree un área de control de calidad / prueba que esté totalmente separada de su entorno personal de "trabajo" o "desarrollo". Al menos una identificación de usuario separada. Idealmente en una VM separada.
   Completamente separado No hay superposición posible con su entorno de trabajo actual.

3. Deje de probar más allá de la prueba unitaria en su propio entorno de trabajo. Prueba de código y unidad que haces "como a ti mismo". Todas las demás pruebas (integración, rendimiento, lo que sea) que realice en la VM separada. Nunca pruebes como tú mismo. Siempre pruebe como un usuario de control de calidad separado. Idealmente en una VM separada.

   "Es bueno para mí", es algo malo tener que decirle a los miembros de su equipo. Muy mal. Debes descubrir qué están haciendo mal. Varias veces al día.

4. Planea escribir todo. Utilice una herramienta de marcado de texto sin formato (RST o Markdown o algo así) para que toda la documentación sea de texto sin formato en el repositorio de control de versiones. Una herramienta puede crear páginas HTML (es decir, Docutils para RST) o PDF o lo que parezca mejor. No utilice formatos de documentos propietarios (es decir, MS-Word). Es posible que no jueguen bien con algunos sistemas de control de código fuente.

5. Las primeras cosas que necesita escribir son las siguientes.

   • Cómo crear un entorno de desarrollo laboral. En caso de duda, cree una máquina virtual y realice toda la operación en esa máquina virtual. Asegúrese de que los pasos realmente funcionen y que la documentación sea clara . Líneas reales escritas en la línea de comando real tipo de claridad.

   • Cómo ejecutar el conjunto de pruebas unitarias. De nuevo. Asegúrese de que las instrucciones funcionen y no requieran pensar. "Escriba esto:" "Confirme que:" tipo de cosas. No es que los miembros de tu equipo sean estúpidos. Es que no recuerdas lo que estás asumiendo a menos que lo anotes todo.

   • Cómo ejecutar el conjunto de pruebas de integración.

   No pierda mucho tiempo describiendo la arquitectura o los principios de diseño. Primero debes poner a alguien en funcionamiento. Puedes explicar cosas más tarde.

6. Las siguientes cosas para documentar son las historias de los usuarios. Y los casos de prueba que respaldan esas historias. Y los accesorios de datos necesarios para los casos de prueba que admiten esas historias de usuarios.

   Estarás compartiendo esto. Va bajo control del código fuente.

7. Eventualmente, puede documentar las otras 4 vistas.

   • La vista lógica es algo útil para documentar. Las imágenes son aceptables aquí. Esto tiende a evolucionar rápidamente, así que no pierdas tiempo capturando la información heredada. Encuentre una forma de cooperar con los miembros de su equipo.

   • La vista del proceso a menudo es útil. Depende de la aplicación general qué tan importante es esto.

   • La vista de desarrollo (módulos, bibliotecas, marcos, etc.) a menudo se describe de manera informal. Una imagen puede ayudar, pero es notoriamente difícil hacerla lo suficientemente completa como para que alguien pueda levantar un documento y hacer cara o cruz. Incluso los proyectos públicos de larga data tienen documentación de biblioteca que simplemente se ignora. (Lo que lleva a muchas preguntas de desbordamiento de pila).

     Además de ser aceptable para ser informal, esto tiende a cambiar rápidamente.

   • Información de implementación. Servidores Direcciones IP. Credenciales de base de datos. Todas esas cosas deben ser escritas. Finalmente.

Herramientas y metodología.

¿Qué se necesita para colaborar con éxito y ser productivo?

• Identifique partes / componentes de su proyecto: Distinga claramente entre diferentes partes (base de datos, capa de acceso a datos, sitio web, servicio, API, proyectos de prueba, scripts de compilación, ...) y entornos (desarrollo, puesta en escena, producción) y nómbrelos tiene un impacto constante en su comunicación oral y escrita (documentación, nombres de proyectos, ...)
• Utilice un sistema de gestión de código fuente (en caso de que aún no lo haga). Piense en cómo usar la ramificación con su proyecto y configuración.
• Automatice sus compilaciones : haga que sea lo más fácil posible configurar un entorno desde su repositorio de origen.
• Los proyectos de prueba son imprescindibles en proyectos grandes, al menos para los proyectos más complejos.
• Use entornos de preparación donde su proyecto esté listo para ser utilizado. Además, cree y mantenga datos de muestra para una configuración de preparación automática.
• Utilice un sistema de seguimiento de errores que pueda ayudar a priorizar y planificar el desarrollo, y también sirva como memoria para errores pasados ​​y cómo se resolvieron.
• Documente cada parte de su proyecto, algunas más que otras. Personalmente me gusta: Descripción general - Arquitectura - Dependencias - Configuración - Problemas comunes (desde aquí ). A veces, menos es más: para no dejar que su documentación quede desactualizada, es mejor ser conciso y dejar que la documentación se convierta en parte de su actividad diaria.

Gestión / trabajo en equipo

... o cualquier otra cosa en el nivel interpersonal

• Defina sus expectativas del otro desarrollador. Sea razonable, es probable que nadie traiga la misma participación y pasión que usted, al menos no desde el principio. Comunique lo que espera y lo que no, defina sus responsabilidades y las de los demás. No todos son ingenieros, arquitectos, desarrolladores, dba y administradores de sistemas, pero si eso es lo que estás buscando, elige a la persona adecuada o te decepcionará.
• Al principio , defina las tareas con precisión , y revise y discuta los resultados. Gradualmente, comience cada vez menos microgestión. La idea es generar confianza y aumentar la responsabilidad.
• Planifique su proyecto , establezca metas para su proyecto y para su equipo para el próximo año. Anótelo y verifíquelo más tarde, esto le dará perspectiva . Esos objetivos pueden o no comunicarse a otros (siempre que sean objetivos que debe alcanzar, no a otros), simplemente puede ser su propia lista de verificación.
• Tómese un día para preparar y planificar el primer mes (o dos / tres meses) de su nuevo desarrollador. Me resulta extremadamente motivador trabajar con personas bien preparadas. Nadie debería tener la impresión de que pierde su tiempo.
• Dejar ir . Es tu bebé, también debería convertirse en el de otra persona. Permita que el otro se convierta en un experto mejor que usted, al menos en algunas partes del proyecto. Esto significa que en realidad tuviste éxito.
• Escucha , si la contrataste, ella tiene algo que decir. Prepárate para aprender.
• Esté preparado para compartir su conocimiento y experiencia (y, por lo tanto, tiempo, sea paciente).
• Se cometerán errores , lo que cuenta es cómo se manejan y lo que todos están aprendiendo sobre ellos.
• Permitir tiempo para aprender y experimentar.

Referencias de libros

Voy a enumerar algunos de los libros comúnmente mencionados que he hecho leído y creo que vale la pena leer, para una descripción más detallada o más libros es posible que desee echa un vistazo a algunas de las preguntas acerca de cómo solicitar tan exactamente para que, al igual esta o esta pregunta

Vale la pena leer esos libros con respecto a los equipos, organizaciones y proyectos de programación:

• Peopleware
• Mes del hombre mítico
• Estimación de software, desmitificando el arte negro

Ninguna de esas son guías prácticas de cómo implementar la metodología X (excepto la estimación de software, este libro le ayuda a elegir un proceso de estimación apropiado). Por supuesto, los libros más centrados en la programación misma como Code Complete también son muy enriquecedores.

Hablaré de la experiencia, pero tenga en cuenta que cada persona es diferente. Estas cosas no son universales.

Una cosa es dejarlo ir personalmente. Este proyecto es algo con lo que vivió y vivió durante 18 meses; naturalmente, desearía que cada cambio sea como lo haría. Dele un amortiguador para que un colega cometa errores, aprenda. Crea un espacio para que sean útiles. Y tenga en cuenta que podría no suceder de inmediato. También sería genial si hay algo, una parte del código que pueden sentir que tienen éxito en mejorar o crear, que se siente como un éxito en un corto período de tiempo. La paciencia y la tolerancia tienen una buena tasa de pago aquí. No intentes microgestión, y si quieres criticar, decir "estás equivocado", asegúrate de tener un mérito, puedes probarlo, no es una pelea "religiosa".

Otra cuestión clave es encontrar a la persona adecuada para usted. Idealmente, es mejor encontrar a alguien más inteligente que usted. Es subjetivo y relativo, pero si siente que una persona tiene algunos conocimientos y habilidades que no tiene, es lo mejor. Será una colaboración mutuamente gratificante.

Hay dos formas de hacerlo: el colega será un lastre, y terminarás rehaciendo lo que él o ella hizo, o las habilidades de dos de ustedes se multiplicarán, no solo sumarán, y realmente apreciarán trabajar juntos.

Sobre un tema de "código limpio, rápido y reutilizable": sugiero en una entrevista que pida escribir un pequeño micro-kernel / service manager y / o ejecutor de trabajo. Vea cómo se especifican y configuran los componentes conectables. No tiene que estar terminado, es un pensamiento que cuenta. Y también aprenderá rápidamente que las personas que saben cómo hacerlo querrán dinero decente ;-) ¡Buena suerte!

Mi opinión: Comience con documentar la arquitectura de su proyecto interno para alguien ... que no lo sepa. Intente explicar qué suposiciones existen y cuándo / dónde se desvió de las prácticas comunes y por qué.

Automatización de compilación: gran idea, puedo agregar automatización de configuración para una máquina de desarrollo. Lo más fácil es construir cuanto más será (por lo tanto, una implementación de prueba más / más rápida).

Otra idea (me ayudó mucho una vez): pedirle al nuevo desarrollador que haga algunas tareas de limpieza a pequeña escala en diferentes áreas de su base de código, para que se acostumbre a las herramientas de diseño, etc. Una buena idea es eliminar áreas oscuras que podrían agregar confusión más adelante (ejemplo: si usó emmm python para dos líneas de un script de shell en algún lugar y su proyecto se basa en Java, solicite que esas dos líneas se reescriban en Java para que el desarrollador # 3 necesite saber menos para trabajar)

Me enfocaría en automatizar todo lo que requiera trabajo manual, por lo que puede ser arruinado por una persona sin experiencia . Que, según su breve comentario anterior, incluye lo siguiente:

• instale el control de versiones y reemplace las copias de seguridad manuales por las automatizadas,
• configure la implementación automática tanto como sea posible (como mínimo, escriba un script para implementar a través de FTP en lugar de hacerlo a mano.

Si no haces esto, o estarás encadenado para hacer estas tareas para siempre, o (algunos) los nuevos tipos inevitablemente arruinarán algo tarde o temprano.

La otra tarea importante es, como señaló @dimitris, la documentación. @S. Lott agregó muchos más detalles sobre esto, así que solo +1 a él en lugar de repetir :-)

Aquí hay algunos pensamientos, en parte basados ​​en la experiencia personal:

• Documenta tu proyecto. Las especificaciones de diseño, diagramas, manuales y comentarios ayudarán al nuevo empleado a ponerse al día. Explicar un sistema complejo solo verbalmente puede resultar lento y frustrante. La documentación es frecuentemente descuidada en proyectos individuales Asegúrate de que el tuyo sea una excepción.

• Al principio, concéntrese en el código API / core-level usted mismo, mientras le da al nuevo empleado algún trabajo de "capa de aplicación" o corrección de errores para familiarizarlos gradualmente con el código. En general, empezar con más fácil , sin embargo, significativos y así premiar tareas .

• La comunicación es importante Responda a las preguntas, comentarios e ideas del nuevo empleado. Explica por qué piensas que una idea no es buena si lo haces. Un par de ojos nuevos pueden detectar un margen de mejora sorprendentemente bien. Si su nuevo empleado es decente, puede revisar por pares su código y eventualmente participar en decisiones arquitectónicas. Discuta, intercambie ideas entre sí. Ese es uno de los mayores beneficios de tener un compañero de trabajo en su proyecto.

• Defina responsabilidades claramente , una vez que sepa qué tipo de tareas está haciendo su nuevo miembro del equipo. Establezca prácticas de documentación y convenciones de codificación para mantener las cosas fluidas.

• Use un sistema de control de revisión . Mantener un diseño de archivo fuente lógico y disciplina de construcción .

En cuanto a la entrevista, no soy un gran admirador de las pruebas de codificación artificial ni de las preguntas capciosas, a menos que desee probar la capacidad duradera del candidato. Incluso los solucionadores de problemas más inteligentes pueden encerrarse en tal situación. Las cualidades que buscará, entre otras, son: honestidad , capacidad profesional , conocimiento / visión tecnológica , entusiasmo y compatibilidad mutua . El ambiente de trabajo puede significar mucho; No es aconsejable elegir un compañero de equipo que no le guste. Haga sus preguntas correctamente y haga una discusión informal para obtener una buena imagen de su candidato. ¡Buena suerte!

Tecnología

Si está trayendo a alguien más como desarrollador, hay tres cosas clave que recomendaría tener en funcionamiento antes de que comiencen.

1. Fuente de control
2. Seguimiento de problemas
3. Integración continua

Si estas tres cosas están funcionando correctamente, eliminará aproximadamente el 75% del problema común que ocurre cuando contrata a un nuevo miembro del equipo. El objetivo de estas piezas de tecnología es tomar mucho de lo que está sucediendo solo en su cabeza y sacarlo donde el miembro de su equipo pueda interactuar con él.

El control de origen asegura que ambos estén trabajando en lo mismo. El seguimiento de problemas le ayuda a realizar un seguimiento de lo que debe hacerse y le facilitará saber en qué están trabajando y logrando. La integración y las pruebas continuas ayudarán a garantizar que tenga un proceso de compilación repetible y que las nuevas mejoras no rompan otras partes del código.

Programador pragmático tiene algunos libros bastante buenos sobre esto. Aquí hay algunos que recomendaría. Tienen otros títulos similares basados ​​en el lenguaje de programación que está utilizando o qué control de versión desea utilizar:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / títulos / auto / pragmatic-project-automation

Personal

Muchas veces las dificultades que enfrentará son menos en el aspecto técnico de las cosas y más en el aprendizaje para dejar de lado. Puede ser difícil otorgarle a otra persona el control sobre los aspectos del proyecto, especialmente si está acostumbrado a hacerlo todo usted mismo y a tomar cada decisión. Se ahorrará algo de dolor si puede encontrar un área donde pueda hacer que la nueva persona trabaje con una cantidad razonable de libertad al principio para que pueda desarrollar una base de confianza. Si contrata a una buena persona, lo principal que probablemente aprenderá es cómo confiar en la otra persona para que haga un buen trabajo, incluso si todas sus decisiones individuales no son las mismas que usted hubiera tomado.

Desea darle a su nuevo empleado la libertad de resolver problemas de la manera que funcione para ellos mientras mantiene las salvaguardas en su lugar para que pueda detectar los problemas desde el principio.

Estos puntos son los más importantes en mi opinión:

1. Lea las partes cruciales de su código y asegúrese de que sean fáciles de entender. Use comentarios o funciones intuitivas y nombres de variables.
2. Facilite que la nueva persona envíe el código.
3. Si no es trivial, cree un archivo README que explique todos los pasos necesarios para el nuevo desarrollador sobre cómo configurar el entorno de desarrollo. Alternativamente, ayude de cerca a configurar este entorno.
4. Dele al nuevo desarrollador tareas muy claramente definidas cuando trabaje en este nuevo proyecto. En mi opinión, estas tareas deberían implicar una funcionalidad nueva pero simple. Las tareas de limpieza no tienen mucho sentido en mi opinión, ya que el nuevo desarrollador primero tiene que acostumbrarse a su estilo de codificación y a sus hábitos, incluso si son malos. La limpieza o incluso la refactorización son trabajos que deben realizar personas que conocen el código.
5. Deje en claro cuál es el proceso para enviar el código. (Por ejemplo, envíe solo cosas que compilen). Pero no sea demasiado estricto, esto puede ser frustrante al principio.
6. Tenga listo un documento con convenciones de codificación. Puede ser realmente frustrante adivinar cuáles son las otras convenciones de codificación.
7. Si la aplicación es compleja, tenga lista la documentación que explica la arquitectura. O explique la arquitectura a la nueva persona usando diagramas de flujo o algo similar. No desea que el nuevo desarrollador pierda demasiado tiempo en ingeniería inversa de su proyecto.
8. Si se supone que el nuevo desarrollador debe realizar las implementaciones él mismo, tenga una lista de verificación ordenada lista que explique todos los pasos necesarios necesarios para la implementación.

Y por último, pero no menos importante: obtenga un sistema de control de versiones. Subversion está bien. Pero asegúrese de no agregar esos archivos Eclipse (o lo que sea) que sean específicos del usuario y, por lo tanto, cambien constantemente. Te hacen perder horas. No dude en preguntar en Stackoverflow si tiene problemas con él.