Cómo agregar un nuevo desarrollador al equipo

24

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.

lortabac
fuente
11
no estás en el umbral de la ley de los arroyos, que se aprobó hace más de un año.
Ryathal
3
No escribiste una palabra sobre el objetivo que tienes para ese plazo. ¿Agregar algunas características específicas para ese patrocinador? ¿Hacer una presentación del producto para los eventos? ¿Crear un paquete de instalación? ¿Solucionar algunos de los problemas más importantes? ¿Qué problemas tienes que no puedes resolver con tu equipo actual?
Doc Brown
¿Cuánto tiempo creen los 2 desarrolladores que necesitarán solos? 3 meses (el cálculo es de 2 desarrolladores * 3 meses es igual a 3 desarrolladores * 2 meses)
scarfridge
@DocBrown Agregué más detalles a la pregunta. Espero que sea más claro ahora.
lortabac
"La documentación y los comentarios están incompletos" ... "El cliente ha escrito casi todos los detalles sobre su proyecto, de una manera muy clara y" amigable para el programador ". Haga que el chico nuevo traduzca los escritos del cliente en la documentación de diseño, luego "Hay pruebas unitarias solo para el código más reciente. Cuando comenzó este proyecto, no realizamos pruebas regularmente", haga que escriba y ejecute pruebas. No se interpondrá en su camino y contribuirá al proyecto
Mawg

Respuestas:

24

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.

Nik
fuente
Agregar pruebas de unidad para el código anterior y corregir errores son algunas ideas de lo que el nuevo desarrollador podría hacer, por supuesto, con soporte y revisiones de código por parte de los demás. ¿Quizás haya necesidad de una prueba de IU automatizada? Eso también es algo que el nuevo desarrollador podría hacer y aprender mucho sobre la aplicación.
Hans-Peter Störr
18

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.

dasblinkenlight
fuente
55
Depende de qué tan atrás estén. El consultor costará más y se llevará el conocimiento con él cuando se vaya. Encontrar a cualquiera que requiera un tiempo de arranque cercano a cero es probablemente una ilusión.
Nik
1
@Nik Estoy de acuerdo, un mayor costo es definitivamente una compensación; también lo es el conocimiento que se drena del proyecto. Conseguir una persona con una puesta en marcha cercana a cero es difícil, especialmente a corto plazo, pero lo he visto en varios proyectos críticos. Sin embargo, los costos de contratarlos fueron bastante altos.
dasblinkenlight
Investigaré un poco, pero un consultor experimentado puede ser difícil de encontrar en mi área. ¿Crees que sería posible trabajar con alguien de otra ciudad? ¿O la distancia retrasaría aún más el proceso?
lortabac
3
Supongo que la ley de Brook también se aplica a un consultor experimentado, por lo que no creo que sea una solución real para el problema.
Doc Brown,
@lortabac Agregar a alguien para que trabaje con usted de manera remota probablemente retrasará las cosas. ¿Qué tan flexibles son los patrocinadores para recortar los requisitos del módulo adicional? Es posible que desee pedirles que ordenen las nuevas funciones en el orden de importancia y decidan cuál es el mínimo absoluto de los requisitos que deben implementar para que el evento tenga sentido. Si no puede encontrar un "bombero" localmente, reducir el alcance puede ser un buen plan de contingencia para usted.
dasblinkenlight
14

¿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).

Buhb
fuente
44
+1. A pesar de todas las otras sugerencias bien intencionadas y con mayor voto, creo que esto es probablemente lo único que realmente funcionará en tal situación.
Doc Brown
De acuerdo de todo corazón. Si le quedan dos meses y simplemente está pensando en contratar a alguien ahora, no obtendrá mucho de un nuevo empleado. A menos que tenga una suerte fantástica o tenga a alguien competente ya en mente, perderá dos meses buscando (y restando valor a su propia productividad) o contratando a alguien que empeorará las cosas. No apresure su contratación.
jmk
10

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).

DesarrolladorDon
fuente
Ese libro es un poco caro, pero lo voy a ver.
Verde
Es posible que pueda encontrar extractos de los libros que mencioné en línea, tal vez a través de los libros de Google. Pedí prestados los libros de Brooks y Coplien a través de la biblioteca de mi universidad local.
DesarrolladorDon
6

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.
Verde
fuente
tal vez determine las áreas que necesitan trabajo y haga que la nueva persona comience escribiendo pruebas para el código existente, para ayudarlo a comprender el sistema antes de sumergirse en cambiarlo o agregarlo.
StevenV
@StevenV que es una excelente, excelente idea. Escribir pruebas para componentes que no conoces te familiarizará con ellos muy, muy rápido. Y el sistema es más comprobable cuando haya terminado. :)
Verde
5

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.

Ralff
fuente
3

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.

HLGEM
fuente
3

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;)

Marc Paradise
fuente
Pocos días después de publicar esta pregunta, dejé la empresa. Como algunos comentarios sobre Ars Technica señalaron correctamente, hubo problemas más profundos que no he mencionado en la pregunta. Solo quería obtener una opinión sobre este tema específico.
lortabac
2

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.

JB King
fuente
2

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.

David Barton
fuente