Cómo agregar un nuevo desarrollador al equipo

Dirijo una pequeña empresa compuesta por solo 2 desarrolladores. Estamos creando una aplicación muy grande para uno de nuestros clientes. El desarrollo de este proyecto ha continuado durante 1,5 años.

Ahora este cliente ha conseguido un patrocinio importante y está organizando eventos relacionados con este proyecto. Así que ahora tenemos una fecha límite en 2 meses y no podemos perderla.

Estamos pensando en agregar un nuevo desarrollador al equipo, y me pregunto qué podemos hacer para ayudar a su integración.

Esta es la situación:

• Nos estamos acercando al umbral de la ley de Brooks : el punto en el que agregar nuevos desarrolladores será contraproducente.
• La aplicación está relativamente bien diseñada, pero la implementación es caótica en algunos puntos (especialmente el código más antiguo).
• Hay pruebas unitarias solo para el código más reciente. Cuando comenzó este proyecto, no realizamos pruebas regularmente.
• La documentación y los comentarios están incompletos.
• La aplicación es grande y compleja.
• El cliente ha escrito casi todos los detalles sobre su proyecto, de una manera muy clara y "amigable para el programador".

¿Es una buena idea agregar una persona ahora? Si es así, ¿qué podemos hacer para ayudar al nuevo desarrollador a integrarse en el equipo?

EDITAR:

El patrocinador está organizando un evento deportivo en Internet para la próxima primavera. Debe comenzar en un día específico del año. No podemos cambiarlo.

Lo que los desarrolladores (yo soy uno de los dos) debemos hacer es:

• Completar la aplicación existente (aproximadamente el 25% del trabajo por hacer).

• Creación de un nuevo módulo, esencial para la organización de este evento (aproximadamente el 75% del trabajo a realizar). Este nuevo módulo no se puede desarrollar sin comprender la API del programa principal.

No puedo hacer una estimación exacta del tiempo, pero estamos en una situación de riesgo.

Lo mejor que puede hacer es no arrojar al nuevo desarrollador al fuego, sino crear algunas funcionalidades y / o correcciones de errores que el desarrollador no debería tener problemas para saltar. Encuentre un área que necesite trabajo que no requiera que una persona conozca toda la arquitectura, los requisitos y la base de código de una sola vez. Quizás haga que él o ella trabaje en documentación para aprender el sistema más rápido.

En lugar de agregar un nuevo desarrollador al equipo, considere agregar un consultor experimentado durante el período de dos a tres meses para manejar el aumento temporal en la carga de trabajo de su empresa. La idea es conseguir a alguien que pueda manejar el tiempo de inicio casi cero, pero al mismo tiempo puede no ser necesariamente la mejor adición a su equipo.

Incluso si cree que el aumento en la carga de trabajo no es temporal, ahora probablemente no sea el mejor momento para hacer crecer su equipo de manera orgánica: agregar un tercer desarrollador es algo estresante para un equipo, incluso sin una presión de la fecha límite del proyecto; La fecha límite ajustada solo empeora la transición.

La compensación es que a cambio de una ayuda temporal, recibirá un código escrito por un extraño. Para mitigar este riesgo, asegúrese de que ambos hagan todas las revisiones de código con él. Asegúrese de revisar y comprender todas sus pruebas unitarias también.

¿Es una buena idea agregar una persona ahora?

No. Si es posible, intente que el cliente acuerde reducir el alcance.

Agregar a una persona tan tarde agregará un riesgo significativo, y la fecha límite no puede ser presionada (por lo que he entendido).

No lo hagas

Todavía.

Vista tradicional

En su pregunta, se refiere a la ley de Brooks de Mythical Man-Month .

Agregar mano de obra a un proyecto de software tardío lo hace más tarde.

Ignorar la ley de Brook tiene un precio. No hagas multitareas. Concéntrese en la entrega de su producto mínimo viable (MVP). Luego, concentre su energía en reclutar, dotar de recursos, capacitar y administrar a un nuevo miembro del equipo.

Dos meses es muy corto. Planifique el reclutamiento con una lista de quemados y verá lo lento que puede ser.

Larry Page y Sergei Brin pasaron dos años eligiendo el equipo inicial para Google. Su elección para el empleado número tres también debe ser cuidadosa.

Vista ágil del nuevo milenio

La competencia impulsa la creación de equipos dinámicos más ahora que en la época en que se escribió Mythical Man-Month (mediados de la década de 1960). Largas carreras en una empresa se han ido. Ahora migramos frecuentemente entre proyectos y empresas. La rápida creación de equipos crea éxito. La aceleración lenta es un factor limitante severo. Grandes ejemplos provienen de proyectos de código abierto, nuevas empresas y el mayor uso de proyectos de equipo en cursos de informática.

Potencialmente, los equipos ágiles tienen en cuenta las restricciones en sus horarios. No llegan tarde porque están optimizados para los recursos disponibles. La integración del nuevo personal es una limitación más, y se considera una compensación entre los objetivos a corto y largo plazo. El equipo ágil integra continuamente el código, entonces, ¿por qué no las personas también?

La integración técnica y social del equipo ágil para el nuevo personal puede usar:

• scrums diarios
• programación en pareja
• refactorización
• Agregar pruebas unitarias faltantes
• engorde de documentación magra
• revisiones de código

El cordero sacrificado

En " Patrones de organización del desarrollo de software ágil", James Coplien analiza la dinámica de grupo y los costos de agregar nuevos miembros al equipo. Su patrón "Sacrificial Lamb" asigna toda la tutoría y capacitación a una persona, protegiendo al resto del equipo de la interrupción.

Es una estrategia que puede considerar implementar.

Otra estrategia es asignar nuevos mentores de contratación que cubran las preguntas de los nuevos empleados durante horas particulares cada día. Si puede prescindir de un solo tipo, tal vez trabaje sin interrupción por las mañanas o por la tarde y responda preguntas por las tardes o las mañanas, respectivamente. El grupo en el que estoy tenía diez pasantes el verano pasado, por lo que muchas personas fueron interrumpidas mucho.

En la actualidad, una persona realiza la tutoría, principalmente durante e inmediatamente después de nuestro scrum matutino (de 8:30 a.m. a alrededor de las 9:15 a.m., combinadas), y en la tarde entre las 12 y las 3:30 (trabaja de 7 a.m. a 3:30 a.m. pm).

Me alegra que hayas mencionado la Ley de Brook. Bien hecho. El problema principal con la adición de otro desarrollador es la sobrecarga en ponerlos al día y la sobrecarga del estado de sincronización con ellos acerca de dónde se encuentra en el proyecto. Por lo tanto, si decides obtener un tercer desarrollador, intentaré esto:

• Dele al nuevo chico un área donde los costos de alta velocidad sean bajos y pueda ponerse en marcha lo más rápido posible. Esto dependerá mucho de a quién contrates y qué habilidades tengan.
• Asegúrese de que esta área esté unida libremente con otras áreas de la aplicación para que la sobrecarga de sincronización sea menor. Enviarlo para hacer un intenso trabajo de DB y reorganizar las tablas puede ser demasiado.
• Haz lo que puedas para mantener la moral alta. Como otros han señalado, agregar un nuevo miembro del equipo puede ser estresante, por lo que tal vez una inversión en bebidas gaseosas podría ayudar.

Si sigue estrictamente la Ley de Brook, probablemente nunca hará crecer su equipo.

El truco es atraer a la nueva persona sin ser golpeado con demasiada desaceleración en su equipo actual. Eventualmente, la nueva persona estará al día, y usted puede superar la joroba.

¿En tu caso? Recomendaría que la nueva persona escriba todas esas pruebas unitarias faltantes.

1. Esos son muy necesarios como protección contra los errores de regresión, lo que lo quemará más rápido que cualquier desaceleración de Brooks.
2. La nueva persona aprenderá las entrañas de su sistema. Es una especie de prueba de fuego, pero su salida no va al código de producción, por lo que hay poco riesgo allí.
3. Establezca un límite estricto sobre cuánto tiempo de los otros miembros del equipo pueden tomar. Por ejemplo, pídales que hagan preguntas y solo espere 30 minutos al día para interactuar con otros miembros del equipo hasta que se cumpla el plazo.

Además, seamos sinceros: tendrá que administrar el alcance y las expectativas del cliente, independientemente de si trae o no una nueva persona. La recompensa viene el próximo ciclo.

Ed Yourdon hizo un gran comentario sobre la Ley de Brook. Él dijo: por supuesto, agregar personas lo hará ir más lento, pero cuando un proyecto está en riesgo es el único momento en que la administración atraerá a nuevas personas. Por lo tanto: tómalos, minimiza el impacto en la versión actual y deshazte de los malos resultados tan pronto como puedas. De esta manera, con el tiempo, puedes construir un equipo fuerte.

Si tiene trabajo en otros proyectos que puede darle, eso liberará tiempo para que los 2 desarrolladores actuales se concentren en los grandes plazos que podrían ayudar.

Dices que necesitas completar el 25% del trabajo original, más el nuevo trabajo. Y necesita hacer esto en dos meses, cuando le tomó 18 meses hacer el 75% del trabajo. Para ser muy directo, esto me indica que sus habilidades de estimación son aproximadamente promedio para un programador centrado en el código, es decir, cree que las cosas le llevarán aproximadamente la mitad a un tercio siempre que realmente lo hagan.

Heroics puede permitirle entregar el producto que ha contratado, pero no le hará ningún favor a usted ni a su cliente. Será de mala calidad y lleno de errores en estas condiciones, y correrás con humos.

Tenga en cuenta que el tiempo que pasa contratando también tendrá un gran impacto en su disponibilidad: esto no es algo que puede hacer en un fin de semana, lleva tiempo encontrar empleados talentosos que se adapten bien. Espere pasar al menos un par de semanas buscando, entrevistando, etc. Espere que usted y su empleado actual pierdan aproximadamente 10 horas a la semana de tiempo productivo mientras realiza la búsqueda.

Mi recomendación:

Siéntese con su cliente, explíquele que está por encima de su cabeza y trabaje con él para reducir el alcance al mínimo.

Editar Acabo de ver la fecha aquí. Entonces, ¿cómo terminó? (Gracias Ars Technica por publicar una pregunta de tres meses;)

Hay un par de formas diferentes que consideraría investigar:

1. Espere a contratar al nuevo desarrollador hasta que pase la fecha límite para que sea más fácil concentrarse en transmitir el conocimiento del dominio al nuevo tipo. Esta sería mi preferencia, ya que podría ser un poco desafiante en algunos aspectos.

2. Traiga al nuevo desarrollador para que trabaje en la documentación, las pruebas unitarias y otras cosas que no cambien ninguno de los códigos existentes. Esto sería lo que sugeriría si traes al chico nuevo para tratar de minimizar el impacto en la carga de trabajo actual.

La fecha ya pasó, pero para cualquiera que lea esto más tarde.

La clave a tener en cuenta es que el cliente en esta situación tiene mucho más que perder que usted. Ya han gastado mucho dinero, y tienen un evento clave por venir que podría hacer o deshacer su negocio. Ya tiene su dinero, y perder un solo cliente no debería arruinar su negocio. Si lo hace, entonces tiene otros problemas comerciales serios más allá de la terrible gestión de proyectos.

Su mejor opción es negociar un subconjunto esencial de funcionalidad y luego trabajar horas extras para lograrlo. Si no puede hacer que suceda un subconjunto más pequeño o no está dispuesto a trabajar horas extras en esa situación, probablemente no debería estar en el negocio. Esto puede significar poner a otros clientes en espera, sin embargo, supongo que sus otros clientes no han pagado por 3 años de tiempo, por lo que coloque sus recursos donde está el dinero.

Si no están dispuestos a negociar el alcance hacia abajo, entonces estás listo para fallar.

No hay posibilidad de entregar este proyecto por completo en el plazo. Si cree que le queda un 25% en un proyecto que ha tardado 18 meses en ejecutarse hasta el momento, le quedan al menos 6 meses (de ~ 2 desarrolladores). Agregar otra persona no cambiará esto significativamente.

Como se ha señalado, el reclutamiento lleva tiempo. Mi experiencia es que lleva un mes como mínimo. Luego agregue entrenamiento y su tiempo se ha agotado.

Espero que esto te haya funcionado.