“Agregar desarrolladores a un proyecto atrasado solo lo atrasará más” (ley de Brooks levemente alterada).
The mythical man month mítico es uno de los ensayos clásicos sobre la gestión de proyectos de software. Y aún sigue que siendo relevante. Sin embargo, los tiempos cambian y, si bien la ley de Brooks es relevante, es necesario analizar algunos conceptos para su aplicación en proyectos ágiles.
Puntos clave de la ley de Brooks
Me gusta que la declaración aparentemente simple de la ley de Brooks resalta la dinámica compleja que existe en el desarrollo de software.
Por ejemplo:
- Tiempo de preparación: los nuevos miembros del equipo necesitan tiempo para poder ser productivos. Necesitan comprender la arquitectura, el código base y las herramientas del proyecto. Este proceso de incorporación requiere que los miembros existentes del equipo desvíen su atención de sus tareas, lo que disminuye temporalmente su capacidad de producción de software..
- Gastos generales de comunicación: a medida que aumenta el tamaño del equipo, también aumenta la cantidad de canales de comunicación entre los miembros del equipo. El número de canales de comunicación aumenta rápidamente con el número de personas, creando una explosión combinatoria. Esto puede provocar problemas de comunicación y requiere más reuniones, lo que reduce la eficiencia general.
- Divisibilidad limitada de tareas: no todas las tareas de desarrollo de software se pueden dividir fácilmente entre muchos desarrolladores. Algunas tareas requieren un esfuerzo concentrado por parte de un grupo pequeño o de un solo desarrollador. Es posible que agregar más desarrolladores a dichas tareas no acelere las cosas e incluso cause retrasos.
Effectos sistémicos de la Ley de Brooks
Desde una perspectiva de sistemas, la Ley de Brooks demuestra cómo una entrada aparentemente simple (agregar más desarrolladores) puede tener resultados complejos e inesperados. Agregar nuevos miembros interrumpe el flujo de trabajo establecido del equipo. No se trata simplemente de un caso de rendimientos decrecientes, sino de interacciones complejas entre diferentes partes del sistema, que conducen a una desaceleración general.
Existen varias simulaciones de la ley de Brooks. Hace unos años esto fue parte de un curso que dicté en la Universidad ORT Uruguay. Les dejo un modelo de simulación sistémica muy simple para la ley de Brooks creado por esos alumnos que participaron del curso (¡en 2017!): https://insightmaker.com/insight/1brB66hP1dBAj2V8egCTNM/Clone-of-Brooks-law
Si miramos el modelo podemos preguntarnos las siguientes preguntas respecto a los impactos de la Ley de Brooks:
- ¿Cuánto tiempo les toma a los nuevos empleados trabajar productivamente en el equipo?
- ¿Qué esfuerzo deben invertir los miembros actuales del equipo en la capacitación de los nuevos empleados?
- ¿Hemos considerado el aumento del costo de la comunicación?
Reinterpretación de la ley de Brooks en Agile: el impacto en la velocidad
Brook estableció la ley en un momento en que los proyectos de alcance fijo eran la norma. Los proyectos ágiles suelen tener un costo fijo. Entonces, la afirmación “un proyecto está retrasado” tiene un significado diferente (si es que tiene algun significado).
En proyectos ágiles, el impacto de la ley de Brooks se siente en la disrupción del funcionamiento del equipo, su impacto en la Velocidad, y – como resultado – en la capacidad del equipo para entregar consistentemente incrementos de software.
Cuando se agregan nuevos desarrolladores a un equipo ágil (algunos modelos de formación de equipos sugerirían que el primer impacto es que estás creando un nuevo equipo), puedo pensar en los siguientes efectos de primer orden a considerar:
- Interrupción del Sprint: El ritmo del equipo existente y el trabajo pendiente del sprint se ven interrumpidos, lo que requiere una reevaluación de las tareas y una posible reconfiguración del trabajo pendiente.
- Incorporación dentro de Sprints: los miembros existentes del equipo deben equilibrar sus tareas de sprint con la incorporación de nuevos colegas, lo que podría llevar a tareas incompletas al final del sprint. Esto afecta la capacidad general.
- Ceremonias de sprint extendidas: los equipos deben volver a aprender cómo mantener las ceremonias dentro del marco de tiempo con el aumento de miembros y canales de comunicación. Nuevamente el efecto visible es la reducción de la capacidad general.
- Velocidad impredecible: las fluctuaciones en la capacidad se harán visibles en la velocidad del equipo, lo que fluctuará y disminuirá la previsibilidad del equipo.
Recomendaciones para navegar los desafíos resultantes de la ley de Brooks
La ley de Brooks es una advertencia de que agregar desarrolladores no es una solución rápida. Si va a agregar desarrolladores, debe tener una visión a más largo plazo del proyecto (y del posible retorno de la inversión). Con el tiempo, los nuevos desarrolladores serán asimilados al equipo y el equipo se adaptará a alguna otra capacidad productiva. Entonces, antes de agregar nuevos miembros al equipo, sugiero pensar en los siguientes efectos de primer orden:
- Sincronización: ¿Sientes la necesidad de aumentar la velocidad? El efecto inmediato probablemente será una reducción. Piense en el futuro de su plan de lanzamiento cuando necesite alcanzar el próximo pico en el rendimiento del equipo.
- Invierta en capacitación: no espere que los nuevos miembros de su equipo comiencen a trabajar, identifiquen las necesidades de capacitación específicas del proyecto y desarrollen un plan de capacitación para facilitar la incorporación.
- Segmentación de tareas: ¿Qué tan buenas son tus historias de usuario? Las tareas más pequeñas ayudan a distribuir mejor el trabajo entre un equipo más grande.
Conclusiones
Las lecciones de la Ley de Brooks no se refieren a agregar más personas para lograr resultados más rápidos. Se trata de comprender las interacciones complejas dentro de un equipo de desarrollo y tomar decisiones informadas. En entornos ágiles, en lugar de centrarse en los retrasos, el impacto real de esta ley se puede ver en la fluctuación de la velocidad del equipo.
¿La mejora del rendimiento de su equipo se ha topado con un cuello de botella? Haga clic en este enlace para comunicarsey demos juntos el primer paso para romper esas barreras.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.