La página de Wikipedia sobre la Ley de Brook incluye la siguiente oración:
El plan de las Bermudas, donde la mayoría de los desarrolladores de un proyecto son eliminados ("enviados a las Bermudas") y los restantes quedan para completar el software, se ha sugerido como una forma de eludir la ley de Brooks.
(La ley en sí, declaró brevemente: "agregar personas a un proyecto de software tardío lo hace más tarde").
La oración va seguida de una cita que consiste en un enlace a la edición de InfoWorld del 7 de mayo de 1984, lo que deja en claro que la sugerencia se presenta de manera irónica.
Sin embargo, tengo curiosidad por saber si alguien alguna vez lo intentó de todos modos, y si es así, cuáles fueron los resultados. Sé que a menudo es difícil obtener buenos números en la gestión de proyectos, pero si existen ejemplos en los que se tomó una medición cuantificable antes y después, serían preferibles.
No espero que ninguna organización haya enviado literalmente programadores a las Bermudas. Espero que un escenario más probable sería que algunos programadores fueran trasladados a un proyecto diferente (o tal vez se produjeran despidos, tal vez incluso aquellos provocados por eventos recientes), dejando un número menor de programadores en un proyecto.
Entonces, ¿alguien sabe algo sobre una o más ocasiones en las que un equipo de software se hizo más pequeño por cualquier motivo, y podemos comparar razonablemente la calidad y/o el volumen de producción antes y después?
Las tres razones principales por las que un proyecto tardío termina más tarde si se le agregan más personas son, como se señala en la página de Wikipedia :
Las nuevas personas necesitan aprender, por lo que les quitan tiempo a las personas existentes en el equipo para obtener ayuda. Por lo tanto, menos recursos para hacer el trabajo mientras las nuevas personas se vuelven productivas y realmente comienzan a contribuir con algo.
La comunicación aumenta. Una vez más, menos recursos para hacer el trabajo mientras que las personas pasan más tiempo tratando de averiguar qué están haciendo los demás.
Algunos trabajos no se pueden dividir bien en piezas individuales que se pueden hacer en paralelo. Una persona puede ser más eficiente en hacer una tarea que dedicar tiempo a dividir la tarea, luego todos construyen una pieza y luego pasan tiempo volviendo a armar todo. Si ha realizado programación de subprocesos múltiples, sabe que algunos trabajos a veces son más rápidos cuando se ejecutan dentro de un solo subproceso que en varios subprocesos en paralelo.
Entonces, veamos dónde el plan Bermuda podría ser una posible solución:
ayuda con 3 si tiene el tipo de tareas que no se pueden dividir bien, o si tiene un gerente que trata de mantener a las personas 100% ocupadas (y qué mejor manera de hacerlo que arrojar a cada uno una parte de algún tarea más grande si no hay otro trabajo disponible para ellos).
ayuda con 2 porque la comunicación disminuye y se destinan más recursos a hacer el trabajo. Como ya se señaló en otra respuesta, sabemos por Agile que los equipos más pequeños suelen ser más efectivos que los más grandes.
el punto 1 desaparece porque no necesitas entrenar a nadie. El resto del equipo se centra únicamente en hacer el trabajo.
Entonces, ¿estos puntos garantizan algo? No. En los tres casos, el plan Bermuda solo disminuye la cantidad de recursos mientras que la cantidad de trabajo permanece igual. Sabemos que 9 mujeres no pueden tener un bebé en un mes, pero la mitad de una mujer tampoco puede tener un bebé en el calendario original de 9 meses .
Obtiene beneficios al eliminar personas solo si los gastos generales de comunicación y la división de tareas son realmente el problema. O, obviamente, si el principal problema de la demora fue con las personas que fueron eliminadas del equipo.
Así que depende mucho del contexto . Si el problema y el enfoque para solucionarlo coinciden, entonces el plan Bermuda puede ser una posible solución. Sin coincidencia, sin solución.
Tal vez sea necesario actualizar la Ley de Brooks. En las condiciones modernas, el tamaño del equipo es probablemente más importante que el tamaño total de un proyecto o flujo de trabajo. Muchas organizaciones organizan su desarrollo de software en equipos pequeños y multifuncionales y descubren que varios equipos pequeños (a menudo de menos de 10 personas) pueden ser más productivos que un equipo grande. Eso se ha intentado muchas veces porque hacer que los equipos sean más pequeños es un tema común de los programas de transformación ágil.
No importa la creencia de uno en uno u otro método de desarrollo, o la creencia en esta "ley", lo que es cierto con cada actividad es que hay un número desconocido de impulsores tanto aleatorios como epistémicos que influyen en los resultados del cronograma. Y las tareas tienen diversos grados de elasticidad de recursos y una sola tarea puede tener diversos grados de elasticidad según el entorno en el que se realiza la tarea. Tratar de atribuir la bondad de una intervención, ya sea que aumente el tamaño del equipo, lo disminuya o cambie una bombilla (Hawthorne), no es una tarea fácil y uno podría meterse fácilmente en el negocio de confirmar lo que él cree que es cierto que lo que es realmente cierto. Ni siquiera puedo imaginar el meta estudio longitudinal que tendría que ocurrir, y repetirse, en un conjunto de proyectos considerable, con un conjunto de control, con un "tamaño de personal reducido" documentado.
Lo que sin duda obtendrá son anécdotas y un caso severo de sesgo de confirmación, especialmente de aquellos que son seguidores estrictos de un método u otro.
Lo que creo que es cierto es que tenemos mucho menos control sobre los resultados de costos y cronogramas de lo que queremos creer.
Tiago Cardoso