He terminado la traducción del Capítulo 2 del libro The Mythical Man-Month: Essays on Software Engineering.
En este capítulo entrega ciertas fórmulas muy valiosas que todo líder de proyecto o JP debería tener. También se nota que el libro al ser de 1995, explica en base a metodologías de la época como RUP, por lo que los amantes de las nuevas metodologías ágiles deberán asociarla.
Vamos directo al hueso:
The Mythical Man-Month : Essays on Software Engineering.
Capítulo 2 : The Mythical Man-Month
Traducción terminada el 09 de Abril del 2013, por Ing. Hernaldo González Candia (hernaldog@gmail.com)
Todos los créditos son para el autor del libro Frederick Phillips Brooks.
La buena cocina toma su tiempo. Si se demora es para darle un mejor servicio y complacerlo mejor.MENU DEL RESTAURANT ANTOINE EN NEW ORLEANS
Más proyectos de software han fracasado por falta de tiempo que por cualquier otra causa combinada. ¿Por qué es tan común esta causa?
En primer lugar, nuestras técnicas de estimación están poco desarrolladas. Ya que reflejan una suposición sin voz, totalmente falsa, asumiendo que todo va a salir bien.
En segundo lugar, nuestras técnicas de estimación confunden esfuerzo con progreso, ocultando el supuesto de que los hombres y los meses son intercambiables.
En tercer lugar, porque no estamos seguros de nuestras propias estimaciones, esto sumado a que los líderes del proyecto en general no son "cortésmente tercos" como lo es el chef Antoine.
En cuarto lugar, no se controla bien el progreso de lo planificado. Hay técnicas probadas en otras disciplinas de ingeniería que serían grandes innovaciones en la Ingeniería de Software.
En quinto lugar, cuando se reconoce el atraso, la natural (y tradicional) respuesta es agregar más mano de obra. Esto es lo mismo sofocar un incendio con gasolina, las cosas empeorarán más y quedarán peores. Más fuego requiere más gasolina y así comienza un ciclo que siempre termina en un desastre.
El monitoreo del plan es un tema que da para un ensayo aparte.
Vamos a considerar otros aspectos del problema con más detalle.
Optimismo
Todos los programadores son optimistas. Tal vez este tipo de brujería moderna atrae especialmente a los que creen en los finales felices y las madrinas de las hadas. Tal vez esas cientos de frustraciones desaparecen de la mente de aquellos que sólo se centran en el objetivo final. Tal vez sea simplemente que los computadores son cada vez más nuevos y rápidos, los programadores son cada vez más jóvenes y los jóvenes son siempre optimistas. Pero sin embargo, el proceso siempre funciona igual y el resultado es el mismo: "esta vez es seguro que correr", o "acabo de encontrar el último bug".
Así que la primera suposición falsa que subyace a toda programación o planificación de sistemas que todo va a ir bien, es decir, que cada tarea sólo va a demorar lo que "debería" demorar y no más.
La omnipresencia del optimismo entre los programadores merece más que un análisis a la rápida. Dorothy Sayers, en su excelente libro Mind of the Maker (La Mente del Creador), divide la actividad creativa en tres etapas: la idea, la implementación y la interacción. Un libro, un computador, o un programa llega a existir por primera vez como un ideal a construir, y se construye fuera del tiempo y del espacio, pero está completa en la mente del autor. Luego se realiza dentro del tiempo y el espacio, ya sea por una pluma, tinta y papel, con un hilo, silicio o hierro. La creación sólo se completa cuando alguien lee el libro, utiliza el computador o corre el programa, así interactúan con la mente del creador.
Esta descripción, que la señorita Sayers utiliza en su libro para iluminar no sólo la actividad creativa humana, sino también aspectos cristianos, nos ayudará en nuestra presente tarea. Para los creadores humanos de las cosas, la no completud e inconsistencia de nuestras ideas se ponen en manifiesto sólo durante la implementación. Por esto es que la escritura, la experimentación, la "elaboración" son disciplinas esenciales para aquel que es teórico.
En muchas actividades creativas el medio de ejecución es intratable. Cortar madera, pintar un frontis o terminar un circuito eléctrico. Estas limitaciones físicas del medio pueden restringir las ideas en que estas pueden ser expresadas y que crean dificultades inesperadas en la implementación.
La implementación entonces, toma tiempo y sudor, tanto por los medios físicos como por las insuficiencias de las ideas subyacentes. Tenemos la tendencia a culpar a los medios físicos por la mayor parte de nuestras dificultades de implementación; porque los medios no son "nuestros" en el forma en que lo son las ideas y los colores del orgullo de nuestro juicio.
La programación, sin embargo, se crea con un medio sumamente tratable. El programador construye a partir de puro pensamiento: conceptos y representaciones muy flexibles de los mismos. Debido a que el medio es tratable, se esperan pocas dificultades en la implementación, de ahí nuestro optimismo generalizado. Debido a que nuestras ideas son defectuosas, tenemos errores, por lo que el optimismo está injustificado.
En una simple tarea, la suposición de que todo va a ir bien tiene un efecto probabilístico en la planificación del proyecto. De hecho, podría avanzarse como se está planeado ya que siempre hay atrasos considerados en el plan y que están repartidos o distribuidos dada cierta probabilidad. No es así con los "no atrasos" que tienen una probabilidad finita. Una gran tarea de programación, sin embargo, consiste en muchas sub-tareas algunas asociadas de punta a punta, y en donde la probabilidad de que cada una vaya a ir bien es extremadamente pequeña.
El segundo modo de pensamiento falso se expresa en una unidad de esfuerzo empleado bastante en la estimación y programación del plan: el hombre-mes. En efecto, el costo varía según el número de hombres y el número de meses que se tengan. El progreso en cambio, no siempre variará. Por lo tanto el hombre-mes, como unidad para medir el tamaño de un trabajo, es un mito peligroso y engañoso. Esto implica que los hombres y los meses sólo se pueden intercambiar sólo bajo ciertas condiciones.
Los hombres y los meses son productos intercambiables sólo cuando una tarea se puede dividir entre muchos trabajadores sin comunicación entre ellos (Fig. 2.1). Este es el caso, por ejemplo, de cosechar trigo o recoger algodón, pero nunca en la programación de sistemas.
Cuando una tarea no puede ser dividida debido a las limitaciones secuenciales, si se aplica un mayor esfuerzo, no tendrá ningún efecto sobre la programación (Fig. 2.2). El crecimiento de un niño tarda nueve meses, no importa cuántas matronas le asistan. Muchas de las tareas de software tienen esta característica debido a que hay etapas del desarrollo que son secuenciales.
El Hombre-Mes
El segundo modo de pensamiento falso se expresa en una unidad de esfuerzo empleado bastante en la estimación y programación del plan: el hombre-mes. En efecto, el costo varía según el número de hombres y el número de meses que se tengan. El progreso en cambio, no siempre variará. Por lo tanto el hombre-mes, como unidad para medir el tamaño de un trabajo, es un mito peligroso y engañoso. Esto implica que los hombres y los meses sólo se pueden intercambiar sólo bajo ciertas condiciones.
Fig. 2.1 Tiempo versus el número de trabajadores, esto en una tarea perfectamente particionable.
Los hombres y los meses son productos intercambiables sólo cuando una tarea se puede dividir entre muchos trabajadores sin comunicación entre ellos (Fig. 2.1). Este es el caso, por ejemplo, de cosechar trigo o recoger algodón, pero nunca en la programación de sistemas.
Cuando una tarea no puede ser dividida debido a las limitaciones secuenciales, si se aplica un mayor esfuerzo, no tendrá ningún efecto sobre la programación (Fig. 2.2). El crecimiento de un niño tarda nueve meses, no importa cuántas matronas le asistan. Muchas de las tareas de software tienen esta característica debido a que hay etapas del desarrollo que son secuenciales.
Fig. 2.2 Tiempo versus número de trabajadores, esto en una tarea que no es particionable.
Fig. 2.3 Tiempo versus número de trabajadores, esto en una tarea particionable pero que requiere comunicación.
Adicionalmente, la comunicación se compone de dos partes, la capacitación (training) y la intercomunicación. Cada trabajador debe recibir capacitación en la tecnología, las metas, la estrategia global y el plan de trabajo. Esta formación no puede ser dividida, por lo que esta parte del esfuerzo que se añadió varía linealmente en relación al número de trabajadores.
La intercomunicación es peor. Si cada parte de la tarea debe ser separadamente coordinada con cada una de las otras partes, el esfuerzo aumenta en la medida de:
N * (N -1) / 2
Tres trabajadores requieren tres veces más intercomunicación que dos, cuatro requieren seis veces más que dos.Si por otra parte, es necesario que existan reuniones entre tres, cuatro o más trabajadores para resolver algún problema en conjunto, las cosas empeoran más aún. El esfuerzo agregado de comunicarse plenamente puede contrarrestar la división de la tarea original y nos lleve a la situación de la Figura 2.4.
Fig. 2.4 Tiempo versus número de trabajadores, esto en una tarea que requiere complejas interrelaciones.
Ya que la construcción de software es básicamente un sistema de esfuerzo - lo que incluye un ejercicio de complejas interrelaciones - y que conlleva un gran esfuerzo de comunicación que rápidamente lleva a que se disminuya el tiempo de trabajo individual provocada por la partición de las tareas. Entonces la adición de más hombres hace que se alargue la programación del plan estimado y no se acorte.
Sistemas de Test
No hay partes en el plan programado que se vea tan fuertemente afectado por las restricciones secuenciales como son las faces de depuración y prueba. Además, el tiempo requerido depende del número y la sutileza de los errores encontrados. Teóricamente, este número debería ser cero. A causa del optimismo, por lo general esperan que el número de errores sea menor del que en verdad resulta ser. Por lo tanto, la etapa de testing es la más reprogramada o replanificada de todo el plan.
Desde hace algunos años he estado utilizando con buena tasa de éxito la siguiente regla de oro para la estimación de una tarea de software:
- 1 / 3 planificación
- 1 / 6 codificación
- 1 / 4 testeo o depuración de las componentes y una prueba básica del sistema
- 1 / 4 prueba del sistema y de todos los componentes involucrados
Esto difiere de una estimación convencional en varios aspectos importantes:
- La fracción dedicada a la planificación es más grande de lo normal. Aun así, es apenas suficiente para producir una especificación detallada y sólida, y no lo suficiente para incluir la investigación o la exploración de nuevas técnicas.
- Casi la mitad de la estimación está dedicada a la depuración de código lo que es mucho más grande que lo tradicional.
- La parte fácil de estimar es la codificación, que es la sexta parte de la estimación.
En general no se deja tiempo suficiente para los test de sistemas, y en particular en software esto causa un gran desastre. Dado que el retraso se produce al final de la programación, no se es consciente de los problemas de fechas o estimaciones hasta cuando se acerca la fecha de entrega. Dar esas malas noticias, tarde y sin advertencias previas, es inquietante tanto para los clientes como para los gerentes a cargo.
Por otra parte, un retraso en esta fase tiene inusuales repercusiones financieras y psicológicas. El proyecto está con su capacidad completa de personal y el costo del día a día es alto. Si estamos ante algo más serio, como la construcción de algún software que da soporte a otro negocio (transporte de equipos, habilitación de nuevos módulos, etc.) hace que los costos secundarios producto del atraso sean muy altos. Esto se da casi siempre en software asociado al transporte o envío de productos. De hecho, estos costos secundarios pueden ser muy superiores a todos los demás. Por eso es muy importante que en el plan de estimación original se estime considerando un tiempo suficiente para las pruebas del sistema.
Estimación cobarde
Obsérvese que tanto para el programador como para el jefe de proyecto o líder a cargo, el uso de un patrón pueden determinar una fecha estimada de finalización en el plan, pero no la fecha real de entrega. Una tortilla puede prometerse servirse en dos minutos cuando se sabe que en ese tiempo hay una baja probabilidad de que no esté lista. Ahora, cuando no está lista en esos dos minutos, el cliente tiene dos opciones: esperar o comérsela cruda. Los clientes de Software tienen las mismas opciones.
El cocinero en cambio tiene otra opción, subir la temperatura. El resultado suele ser una tortilla que está quemada por una parte y cruda en otra.
No creo que los jefes de proyecto o líderes tengan menos coraje y firmeza que los cocineros, ni que otros administradores de otras área de la ingeniería. Pero desarrollar falsamente para que el término de la programación coincida con la fecha deseada es mucho más común en nuestra disciplina que en otras áreas de la ingeniería. Es muy difícil hacer una defensa vigorosa, plausible o involucrando todos los riesgos que se visualizan, de una estimación que se obtuvo bajo un método no cuantitativo, con pocos datos de apoyo y aprobada principalmente por los presentimientos de los gerentes.
Es evidente que se necesitan soluciones. Tenemos que desarrollar y dar a conocer las cifras de productividad, las cifras de incidencias que se dan, las reglas de estimación, etc. El conjunto sólo se puede beneficiar si se comparten esos datos.
Hasta que la estimación no se vea sólida, los jefes o líderes tendrán que endurecer su columna vertebral y defender sus estimaciones con la seguridad de que sus "corazonadas" determinen una buena estimación.
El desastre de una planificación regenerativa
¿Qué hace uno cuando se ve que un proyecto de software se va a atrasar? Añadir mano de obra naturalmente. Como sugieren las Fig. 2.1 a la 2.4, esto puede o no puede ayudar.
Consideremos un ejemplo. Supongamos que una tarea se estima en 12 meses-hombre y asignados a tres hombres para cuatro meses. Les pondremos a cada bloque, que representa cada uno, un mes, los códigos A, B, C, D y obtenemos una medición (Fig. 2.5). Supongamos ahora que el primer bloque no se logra hasta transcurrido dos meses (Fig. 2.6). ¿Cuáles son las alternativas que se enfrentaría quien está encargado del plan?
Figura 2.5
Figura 2.6
Figura 2.7
1. Asumir que la tarea debe hacerse a tiempo. Supongamos que sólo ese primer bloque fue estimado con optimimismo, tal como se ve en Fig. 2.6. Entonces quedan 9 meses-hombre de esfuerzo restantes, y como hay un bloque de atraso que son 3 meses, será necesario 4 hombres para cubrir ese bloque. Agregamos 2 hombres a los 3 asignados para 2 bloques.
2. Asumir que la tarea debe hacerse a tiempo. Supongamos que la estimación total fue uniformemente baja, tal como muestra la Figura 2.7. El esfuerzo gastado son 3 meses, quedan 9, pero como se asume que es una estimación uniformemente optimista, este sube a 18 meses-hombre, es decir, cada bloque restante de 6 y no 3 meses. Esto hace que se requieran 9 hombres en total, 6 hombres en vez de 3 asignados.
3. Reprogramar. Quiero tomar el consejo dado por P. Fagg, un ingeniero de hardware con experiencia, "no tomar los pedazos". Es decir, que en la nueva estimación haya tiempo suficiente para que el trabajo puede ser realizado cuidadosamente y completamente con tal que de no volver hacer una reprogramación.
4. Acortar la tarea. Esto tiende a suceder de todos modos en la práctica una vez que el equipo observa que los tiempos se están agotando. Cuando los costos secundarios del atraso son muy altos, esta es la única acción factible. La única alternativa del Jefe de Proyecto o Gerente es acortar la tarea formalmente y con cuidado, para volver a estimar dicha parte ya que sino, verá como la tarea se acorta en silencio por el equipo debido a un diseño incompleto y a las pruebas inconclusas.
En los dos primeros casos, insistiendo en que la tarea no debe ser alterada en cuatro meses, es desastroso. Considere los efectos regenerativos, por ejemplo, para la primera variante (Fig. 2.8). Los dos nuevos hombres, aunque sean competentes y se hayan reclutado rápidamente, requerirán entrenamiento en la tarea por alguno de los hombres experimentados. Si esto toma un mes, los tres hombres-meses ya no podrán trabajar sobre la estimación original. Además, la tarea, originalmente particionada en tres bloques, debe ser reparticionada ahora en cinco partes, así que el poco trabajo que se avanzó se perderá y las pruebas del sistema deberán extenderse.
Figura 2.8
Así, al final del tercer mes, faltan más de 7 hombre-mes, y se tiene 5 personas capacitadas y sólo un mes disponible. Como la Fig. 2,8 indica, el producto está tan atrasado como si no se hubiese añadido nada (Fig. 2.6).
Para poder realizarla en cuatro meses, teniendo en cuenta sólo el tiempo de entrenamiento pero dejando afuera tiempos de reparticionamiento y las pruebas del sistema, sería necesario agregar 4 hombres y no 2, al final del segundo mes. Para cubrir efectos del reparticionamiento y las pruebas del sistema habría que agregar aún más hombres. Ahora, sin embargo, se tiene un equipo de 7 hombres y no de 3, por lo que aspectos como la organización del equipo y la división de tareas ahora son de un grado y tipo diferente.
Hay que tener en cuenta que para el final del tercer mes las cosas se ven muy negras. El hito del 1ro. de Marzo no se ha alcanzado a pesar de todo el esfuerzo en gestión. Es muy fuerte la tentación de repetir el ciclo, agregando aún mas mano de obra, lo que sería una locura.
Lo anterior supone que sólo el primer hito fue desestimado. Si el 1 de Marzo se hace una reestimación de que toda la planificación bajo un punto de vista que toda la planificación anterior fue optimista, como muestra la Figura. 2.7, se requiere añadir sólo 6 hombres más a la tarea original. Los cálculos acerca del tiempo de entrenamiento, reparticionamiento y pruebas del sistema, se dejan como ejercicio al lector. Sin lugar a dudas, el desastre regenerativo da por resultado un producto más pobre, atrasado y reprogramado con respecto al plan original de tres hombres.
Si lo simplificamos de forma escandalosa, planteamos la Ley de Brooks:
Agregar más mano de obra a un proyecto de software que está atrasado, lo atrasa más.
Esta es entonces la desmitificación del hombre-mes. El número de meses de un proyecto depende de sus limitaciones secuenciales. El máximo número de hombres que se pueden agregar al proyecto depende del número de sub-tareas independientes. A partir de estas dos factores se puede derivar una planificación utilizando menos hombres y más meses. (El único riesgo sería la obsolescencia del producto.) No se puede, sin embargo, hacer un plan con más hombres y menos meses. Hay que recordar que más proyectos de software han fracasado por quedar cortos de tiempo que por cualquier otra causa combinada.
