Consejos / trucos para administrar un nuevo equipo con un nuevo código [cerrado]

¿Cómo te manejas en un nuevo equipo en el que eres el mayor desarrollador y la mayoría de los demás en el equipo son menores para ti por varios años? La tarea por delante del equipo es algo que nadie más, incluido usted, ha logrado en su carrera antes.

La gerencia insiste en una mayor productividad de todo el equipo y, como desarrollador senior, usted es responsable.

¿Algún consejo para salir triunfante en una situación como esta? Claramente, todo el equipo necesita tiempo para aprender y no olvidemos lo nuevo del equipo. Sin embargo, los plazos también están por venir ...

No permita que una fecha límite ajustada o la novedad del proyecto interfieran con las buenas prácticas de ingeniería. Configure un repositorio de software, acepte un estilo de codificación, cree un conjunto de pruebas, etc. La novedad de la tarea no debería ser tan importante, siempre y cuando tenga personas de calidad que estén dispuestas a trabajar duro y aprender la tarea por delante de ellos.

O para decirlo de otra manera: te pusieron a cargo porque la gerencia cree que tu experiencia y antecedentes te han dado las herramientas necesarias para crear software de calidad. No olvides de repente tus habilidades solo porque esta tarea parece desalentadora ahora.

Lo primero es lo primero, comience a usar un sistema de control de código fuente desde la primera línea de código. Acostúmbrese a revisar el código temprano y con frecuencia.

En segundo lugar, decida sobre una estrategia de prueba . Por supuesto, eso debería significar pruebas unitarias, pero también debe considerar cómo automatizar las pruebas de aceptación.

En tercer lugar, establezca un servidor de integración continua para que su código se cree y pruebe regularmente.

Una vez que tenga eso, como equipo establezca algunos estándares de codificación simples . Desea que su código sea fácil de leer para todos. Realmente no importa cuáles son los estándares. Sangría con tabulaciones, sangría con espacios, llaves en la misma línea, lo que sea. No importa lo que sean, solo que todos los apliquen constantemente.

Dado que el equipo es principalmente desarrolladores junior, planifique revisar el código a menudo para asegurarse de que no agreguen demasiadas deudas técnicas a su sistema.

Finalmente, considere usar SCRUM . Si lo hace, contrate a un entrenador o vaya a un entrenamiento. Como todos están haciendo algo que nunca antes han hecho, establecer plazos realistas es simplemente imposible. Con SCRUM, su administración tendrá visibilidad de lo que hace a diario para que puedan ver qué progreso se está haciendo (o no). Y, dado que sus fechas límite aparentemente se le dieron, SCRUM al menos garantiza que si no puede cumplir con la fecha límite, al menos está entregando historias completas de forma incremental, lo que posiblemente sea mejor que llegar al final con un gigante sistema que no funciona en absoluto.

Además de la respuesta de @chrisaycock ... No subestimes el tiempo que necesitarás para la tutoría / capacitación, etc. Como líder, deberás aprender a dejar ir los detalles y confiar en tu equipo. Su trabajo es convertirse en habilitador, eliminador de obstáculos y ejecutar interferencias cuando la gerencia interviene. En un equipo "normal", alrededor de las 7 u 8, el líder ya no se programa. En su situación, esto se reduce a 3 o 4 (Quizás incluso menos), no eres un recurso de programación para el proyecto.

Centrarse en la comunicación en dos áreas.

No es fácil hacer esto, y esa es una razón por la que este trabajo es difícil. Si cumplir con la fecha límite significa características de corte, entonces repásalo. Lo único que intenta evitar en todo esto es un código rápido para establecer una fecha límite. Ese es el comienzo del fin de una base de código que no durará bien y el comienzo de una deuda técnica que se ahoga.

2) Comunicación entre equipos. Establezca prácticas formales como las que Bryan y otros recomiendan. Asegúrese de reunirse regularmente como equipo, por ejemplo, una vez a la semana además de los scrums diarios. Gane respeto y confianza escuchando , su herramienta más importante. Asegúrate de concentrarte en ayudar. Evite las críticas negativas a toda costa. Cuando sea necesario, utilice críticas positivas y aliento, por ejemplo, "eso es genial, una vez que lo que quiera considerar es X" terminado ", eso no es lo que necesitamos, debe hacer X en su lugar"

Lo que he hecho es identificar a los capaces y dividir y conquistar. Tomo los primeros 2 o 3 y los hago capitanes. Los otros se dividen en equipos de manera uniforme siguiendo a los capitanes a sus propios pequeños equipos.

Doy a los capitanes fragmentos o módulos para hacer de un programa.

Los capitanes les dan a los novatos tareas más pequeñas de programación o investigación, mientras se explican a sí mismos lo que están haciendo, por lo que la tutoría ocurre mientras lo hacen.

Intento organizar la sala para que todos estén en el mismo espacio abierto, pero cada equipo tiene su propio círculo de computadoras. Me gusta estar gritando a todos para que las cosas se muevan rápidamente.

Esto funciona bien para unos 10-20 programadores hasta ahora. Los grupos más pequeños son mejores estar en un grupo y aún no he trabajado con nada más grande.