Pasar de un proyecto de una persona a un proyecto de equipo en el futuro. ¿Qué debería estar haciendo ahora en preparación y qué puedo esperar?

13

Para elaborar, estoy interesado en saber qué piensa la gente que debe implementar cuando todavía es un proyecto de un solo hombre (control de fuente del equipo, documentación, compilaciones, etc.) y qué cosas no deben hacerse hasta ese momento cuando La segunda persona entra en el proyecto.

Cualquier persona que tenga experiencia en moverse a través de este escenario, apreciará sus conocimientos.

    
pregunta Dan MacBean 15.09.2011 - 16:51

8 respuestas

12

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 de código fuente. Use algo a lo que todos tengan acceso y comience ahora mismo . Sin excepciones. No hay retrasos. No hay excusas.

  2. Cree un área de control de calidad / prueba que sea totalmente independiente de su entorno personal de "trabajo" o "desarrollo". Al menos una identificación de usuario separada. Idealmente en una máquina virtual separada.
    Completamente separado. No es posible superponerse con su entorno de trabajo actual.

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

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

  4. Planea anotar todo. Use 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 debe escribir son las siguientes.

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

    • Cómo ejecutar el conjunto de pruebas de la unidad. Otra vez. Asegúrese de que las instrucciones funcionen y no requiera pensar. "Escribe esto:" "Confirma eso:" 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 escribas todo.

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

    No pierdas mucho tiempo describiendo la arquitectura o los principios de diseño. Necesitas poner a alguien en marcha primero. Puedes explicar las cosas más tarde.

  6. Las siguientes cosas para documentar son las historias de usuario. Y los casos de prueba que apoyan esas historias. Y los datos necesarios para los casos de prueba que apoyan esas historias de usuario.

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

  7. Eventualmente, puedes documentar las otras 4 vistas.

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

    • La vista de proceso suele ser útil. Depende de la aplicación general, lo importante que es esto.

    • Vista de desarrollo (módulos, bibliotecas, marcos, etc.) a menudo se describe de manera informal. Una imagen puede ayudar, pero es notoriamente difícil hacer que esto sea lo suficientemente completo como para que alguien pueda recoger un documento y poner cara a cara. Incluso los proyectos públicos de larga data tienen documentación de la biblioteca que simplemente se ignora. (Esto 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 la base de datos. Todas esas cosas deben ser escritas. Eventualmente.

respondido por el S.Lott 15.09.2011 - 18:00
8

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, guiones de compilación, ...) y entornos (dev, puesta en escena , producción), y nombrarlos de manera consistente tiene un impacto 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 todavía no lo haya hecho). 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 obligatorios en los proyectos grandes, al menos para los proyectos más complejos.
  • Use entorno (s) de almacenamiento donde su proyecto esté listo para ser utilizado. Además, cree y mantenga datos de muestra para una configuración de almacenamiento automatizada.
  • Use un sistema de seguimiento de errores que puede ayudar a priorizar y planificar el desarrollo, y también sirve como memoria para errores anteriores y cómo se resolvieron.
  • Documento cada parte de su proyecto, algunas más que otras. Personalmente, me gusta: Descripción general - Arquitectura - Dependencias - Configuración - Problemas comunes (de aquí ). A veces, menos es más: para evitar que su documentación se quede desactualizada, es mejor ser conciso y dejar que la documentación forme 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 genere 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 , define las tareas con precisión , y revisa y discute los resultados. Poco a poco, comienza cada vez menos la micro-gestión. La idea es crear confianza y aumentar la responsabilidad.
  • Planifique su proyecto , establezca objetivos para su proyecto y para su equipo para el próximo año. Escríbalo y verifíquelo más tarde, esto le dará perspectiva . Esos objetivos pueden o no ser comunicados a otros (siempre que sean objetivos que usted necesite lograr, no 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. Lo encuentro muy motivador cuando trabajo con personas bien preparadas. Nadie debe tener la impresión de que su tiempo se pierde.
  • Deja ir . Es tu bebé, debería convertirse en el de alguien más, también. Permita que el otro se convierta en un experto mejor que usted, al menos en algunas partes del proyecto. Esto significa que en realidad lo lograste.
  • Escucha : si la contrataste, ella tiene algo que decir. Prepárate para aprender.
  • Prepárese para compartir su conocimiento y experiencia (y, por lo tanto, tiempo, sea paciente).
  • Se harán errores , es cómo se manejan y lo que todos están aprendiendo acerca de ellos es lo que cuenta.
  • Permita tiempo para aprender y experimentar

Referencias de libros

Enumeraré algunos de los libros comúnmente mencionados que he leído en realidad y creo que vale la pena leerlos, para una descripción más detallada o para más libros, puede consultar algunos de las preguntas sobre SO que se preguntan exactamente por eso, como this o esta pregunta.

Esos libros realmente valen la pena leerlos con respecto a equipos, organizaciones y proyectos de programación:

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

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

    
respondido por el marapet 14.01.2011 - 00:33
4

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 fuera como lo haría. Dar un amortiguador para que un colega cometa errores, para aprender. Crea una habitación 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 puedan sentir que logran 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 amortización aquí. No trates de hacer microgestión, y si quieres criticar, decir "estás equivocado", asegúrate de tener un mérito, puedes probarlo, no es una pelea "religiosa".

Otro tema clave es encontrar a la persona adecuada para ti. Idealmente, es mejor encontrar a alguien más inteligente que tú. Es subjetivo y relativo, pero si sientes que una persona tiene algún conocimiento y habilidades que no tienes, es lo mejor. Será una colaboración mutuamente gratificante.

Puede ir de dos maneras: el colega será un obstáculo y usted terminará rehaciendo lo que hizo, o las habilidades de dos de ustedes se multiplicarán, no solo se sumarán, y apreciarán mucho trabajando juntos.

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

    
respondido por el Alex Pakka 12.01.2011 - 17:07
2

Mi opinión: comience por documentar la arquitectura interna de su proyecto para alguien ... que no esté al tanto de ello. Trate de explicar qué suposiciones existen y cuándo y 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 más será (por lo tanto, más rápido / más rápido será el despliegue de prueba).

Otra idea (me ayudó mucho una vez): pídale al nuevo desarrollador que realice 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, pida que esas dos líneas se vuelvan a escribir en java para que el desarrollador # 3 Necesitará saber menos para poder trabajar.

    
respondido por el Dimitrios Mistriotis 15.09.2011 - 17:00
1

Me centraré en automatizar todo lo que requiera trabajo manual, por lo que una persona inexperta lo puede arruinar . El cual, basado en su breve comentario anterior, incluye lo siguiente:

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

Si no haces esto, o te encadenarán para hacer estas tareas para siempre, o (algunos de) los nuevos individuos inevitablemente arruinarán algo tarde o temprano.

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

    
respondido por el Péter Török 15.09.2011 - 18:01
0

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

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

  • Al principio, concéntrese en el código de API / nivel central, mientras le da al nuevo empleado un trabajo de "capa de aplicación" o una corrección de errores para familiarizarlos con el código. En general, comienza con más fácil , pero significativo y por lo tanto recompensando tareas .

  • Comunicación es importante. Responda a las preguntas, comentarios e ideas del nuevo empleado. Explique por qué cree que una idea no es buena si lo hace. Un par de ojos nuevos puede detectar espacio para mejorar sorprendentemente bien. Si su nuevo empleado es decente, puede revisar su código y, finalmente, participar en las decisiones de arquitectura. Discute, comparte ideas. Ese es uno de los mayores beneficios de tener un compañero de trabajo en tu proyecto.

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

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

En cuanto a la entrevista, no soy un gran fanático de las pruebas de codificación artificial o de las preguntas con trampa, a menos que desee probar la capacidad de resistencia al estrés del candidato. Incluso los solucionadores de problemas más inteligentes pueden encerrarse en una situación así. Las cualidades que buscará, entre otras, son: honestidad , capacidad profesional , conocimiento / conocimiento tecnológico , 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!

    
respondido por el mizo 13.01.2011 - 15:57
0

Tecnología

Si traes a alguien más como desarrollador, hay tres cosas clave que recomiendo tener en funcionamiento antes de que comiencen.

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

Si estas tres cosas están funcionando correctamente, eliminarás aproximadamente el 75% del problema común que se produce cuando traes a un nuevo miembro del equipo. El objetivo de estas piezas de tecnología es tomar gran parte de lo que está sucediendo solo en tu cabeza y sacarla donde el miembro de tu equipo pueda interactuar con ella.

El control de fuente se asegura de que ambos estén trabajando en la misma cosa. El seguimiento de problemas le ayuda a ambos a hacer un seguimiento de lo que debe hacerse y le facilitará saber en qué están trabajando y qué están logrando. La integración y las pruebas continuas te ayudarán a asegurarte de que tienes un proceso de compilación repetible y que las nuevas mejoras no están rompiendo otras partes del código.

El 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 el control de versión que desea usar:

enlace enlace enlace

Personal

Muchas veces, las dificultades que enfrentará son menores 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 aspectos del proyecto, especialmente si está acostumbrado a hacerlo usted mismo y a tomar todas las decisiones. Se ahorrará algo de pena 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 más importante que probablemente estará aprendiendo es cómo confiar en que la otra persona haga un buen trabajo, incluso si todas sus decisiones individuales no son lo mismo que usted habría tomado.

Desea darle a su nuevo empleado la libertad de resolver los problemas de la forma en que funciona para ellos y al mismo tiempo mantener las salvaguardas en su lugar para que pueda detectar los problemas desde el principio.

    
respondido por el Mark 17.01.2011 - 04:26
0

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

  1. Lea partes cruciales de su código y asegúrese de que sean fáciles de entender. Utilice 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. Como alternativa, colaborar estrechamente en la configuración de este entorno.
  4. Déle al desarrollador nuevas tareas claramente definidas cuando trabaje en este nuevo proyecto. En mi opinión, estas tareas deben incluir una funcionalidad nueva pero simple. Las tareas de limpieza no tienen mucho sentido en mi opinión, ya que el nuevo desarrollador primero debe 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 las 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 lo que compila.) Pero no sea demasiado estricto, esto puede ser frustrante al principio.
  6. Tenga listo un documento con las convenciones de codificación. Puede ser realmente frustrante adivinar cuáles son las demás 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 utilizando diagramas de flujo o algo similar. No desea que el nuevo desarrollador pierda demasiado tiempo en la ingeniería inversa de su proyecto.
  8. Si se supone que el nuevo desarrollador debe realizar implementaciones por sí mismo, tenga preparada una lista de comprobación ordenada que explique todos los pasos necesarios para la implementación.

Y por último, pero no menos importante: obtenga un sistema de control de versiones. La subversión está bien. Pero asegúrese de no agregar esos archivos de 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.

    
respondido por el Philip 15.09.2011 - 22:25