The Mythical Man-Month: Essays on Software Engineering es un libro sobre ingeniería de software y gestión de proyectos de Fred Brooks publicado por primera vez en 1975, con ediciones posteriores en 1982 y 1995. Su tema central es que agregar mano de obra a un proyecto de software que está retrasado lo retrasa aún más. Esta idea se conoce como la ley de Brooks y se presenta junto con el efecto del segundo sistema y la defensa de la creación de prototipos .
Las observaciones de Brooks se basan en sus experiencias en IBM mientras gestionaba el desarrollo de OS/360 . Había añadido más programadores a un proyecto que se estaba retrasando, una decisión que más tarde concluiría que había retrasado aún más el proyecto, contrariamente a lo que se creía. También cometió el error de afirmar que un proyecto (el de escribir un compilador ALGOL ) requeriría seis meses, independientemente del número de trabajadores involucrados (requería más tiempo). La tendencia de los gerentes a repetir tales errores en el desarrollo de proyectos llevó a Brooks a bromear diciendo que su libro se llama "La Biblia de la Ingeniería de Software", porque "todo el mundo lo cita, algunas personas lo leen y algunas personas lo siguen". [1]
La obra se publicó por primera vez en 1975 ( ISBN 0-201-00650-2 ), [2] se reimprimió con correcciones en 1982 y se volvió a publicar en una edición de aniversario con cuatro capítulos adicionales en 1995 ( ISBN 0-201-83595-9 ), incluida una reimpresión del ensayo " No Silver Bullet " con comentarios del autor.
Brooks analiza varias causas de los fallos de programación. La más duradera es su discusión de la ley de Brooks : añadir mano de obra a un proyecto de software retrasado lo retrasa . El mes-hombre es una unidad hipotética de trabajo que representa el trabajo realizado por una persona en un mes; la ley de Brooks dice que la posibilidad de medir el trabajo útil en meses-hombre es un mito y, por lo tanto, es el tema central del libro.
Los proyectos de programación complejos no se pueden dividir perfectamente en tareas discretas en las que se pueda trabajar sin comunicación entre los trabajadores y sin establecer un conjunto de interrelaciones complejas entre las tareas y los trabajadores que las realizan.
Por lo tanto, asignar más programadores a un proyecto que se retrasa aún más hará que el proyecto se retrase aún más. Esto se debe a que el tiempo que necesitan los nuevos programadores para conocer el proyecto y el aumento de la carga de comunicación consumirán una cantidad cada vez mayor del tiempo disponible en el calendario. Cuando n personas tienen que comunicarse entre sí, a medida que n aumenta, su producción disminuye y, cuando se vuelve negativa, el proyecto se retrasa aún más con cada persona que se suma.
Brooks agregó el capítulo "No Silver Bullet—Essence and Accidents in Software Engineering" y otras reflexiones sobre él en el capítulo "'No Silver Bullet' Refired" a la edición de aniversario de The Mythical Man-Month .
Brooks insiste en que no existe una solución milagrosa : "no existe un único avance, ni en tecnología ni en técnicas de gestión, que por sí solo prometa siquiera una mejora de un orden de magnitud [diez veces] en una década en productividad, fiabilidad y simplicidad".
El argumento se basa en la distinción entre complejidad accidental y complejidad esencial, de forma similar a la forma en que la ley de Amdahl se basa en la distinción entre "paralelizable" y "estrictamente serial".
El efecto del segundo sistema propone que, cuando un arquitecto diseña un segundo sistema, éste es el sistema más peligroso que jamás diseñará, porque tenderá a incorporar todos los añadidos que no hizo originalmente al primer sistema debido a las limitaciones de tiempo inherentes. Por lo tanto, al embarcarse en un segundo sistema, un ingeniero debe tener en cuenta que es susceptible de sobrediseñarlo.
El autor observa que en un sistema suficientemente complejo existe un cierto número irreducible de errores. Cualquier intento de corregir los errores observados tiende a dar como resultado la introducción de otros errores.
Brooks escribió: "Pregunta: ¿Cómo es posible que un gran proyecto de software tenga un año de retraso? Respuesta: ¡Un día a la vez!" Los retrasos incrementales en muchos frentes se van acumulando hasta producir un gran retraso general. Es necesario prestar atención constante al cumplimiento de pequeños hitos individuales en cada nivel de gestión.
Para que un sistema sea fácil de usar, el sistema debe tener integridad conceptual, lo que sólo se puede lograr separando la arquitectura de la implementación. Un único arquitecto jefe (o un pequeño número de arquitectos), que actúa en nombre del usuario, decide qué se incluye en el sistema y qué se deja fuera. El arquitecto o el equipo de arquitectos deben desarrollar una idea de lo que debería hacer el sistema y asegurarse de que el resto del equipo comprenda esta visión. Es posible que no se incluya una idea novedosa de alguien si no se adapta perfectamente al diseño general del sistema. De hecho, para garantizar un sistema fácil de usar, un sistema puede proporcionar deliberadamente menos funciones de las que es capaz de ofrecer. El punto es que, si un sistema es demasiado complicado de usar, muchas funciones no se utilizarán porque nadie tiene tiempo de aprenderlas.
El arquitecto jefe elabora un manual de especificaciones del sistema. Debe describir en detalle las especificaciones externas del sistema, es decir, todo lo que ve el usuario. El manual debe modificarse a medida que se reciban comentarios de los equipos de implementación y de los usuarios.
Al diseñar un nuevo tipo de sistema, un equipo diseñará un sistema descartable (ya sea intencionalmente o no). Este sistema actúa como un "plan piloto" que revela técnicas que posteriormente provocarán un rediseño completo del sistema. Este segundo sistema, más inteligente , debería ser el que se entregue al cliente, ya que la entrega del sistema piloto no causaría más que agonía al cliente y posiblemente arruinaría la reputación del sistema y tal vez incluso la de la empresa.
Todo director de proyecto debe crear un pequeño conjunto de documentos formales que definan los objetivos del proyecto, cómo se van a lograr, quién los va a lograr, cuándo se van a lograr y cuánto van a costar. Estos documentos también pueden revelar inconsistencias que de otra manera serían difíciles de detectar.
Al estimar los tiempos del proyecto, se debe recordar que los productos de programación (que se pueden vender a clientes que pagan) y los sistemas de programación son tres veces más difíciles de escribir que los programas internos simples e independientes. [3] Se debe tener en cuenta qué parte de la semana laboral se dedicará realmente a cuestiones técnicas, en comparación con tareas administrativas u otras tareas no técnicas, como reuniones y, especialmente, reuniones "de pie" o "de todo el personal".
Para evitar desastres, todos los equipos que trabajan en un proyecto deben mantenerse en contacto entre sí de todas las maneras posibles (correo electrónico, teléfono, reuniones, memorandos, etc.). En lugar de dar por sentado algo, los implementadores deben pedirle al arquitecto o arquitectos que aclaren sus intenciones sobre una característica que están implementando, antes de proceder con una suposición que podría ser completamente incorrecta. El arquitecto o arquitectos son responsables de formular una imagen grupal del proyecto y comunicarla a los demás.
De la misma manera que durante una intervención quirúrgica un equipo quirúrgico está dirigido por un cirujano que realiza el trabajo más crítico y al mismo tiempo dirige al equipo para que ayude con las partes menos críticas, parece razonable que un "buen" programador desarrolle componentes críticos del sistema mientras el resto del equipo proporciona lo que se necesita en el momento adecuado. Además, Brooks reflexiona sobre el hecho de que los "buenos" programadores suelen ser entre cinco y diez veces más productivos que los mediocres.
El software es invisible. Por lo tanto, muchas cosas solo se hacen evidentes una vez que se ha realizado una cierta cantidad de trabajo en un nuevo sistema, lo que permite que un usuario lo experimente. Esta experiencia generará conocimientos que cambiarán las necesidades del usuario o la percepción de las necesidades del usuario. Por lo tanto, el sistema debe modificarse para satisfacer los requisitos modificados del usuario. Esto solo puede ocurrir hasta cierto punto, de lo contrario, el sistema nunca podría completarse. En una fecha determinada, no se deben permitir más cambios en el sistema y el código debe congelarse. Todas las solicitudes de cambios deben posponerse hasta la próxima versión del sistema.
En lugar de que cada programador tenga su propio conjunto de herramientas, cada equipo debería tener un creador de herramientas designado que pueda crear herramientas altamente personalizadas para el trabajo que realiza el equipo (por ejemplo, una herramienta generadora de código que cree código en función de una especificación). Además, las herramientas para todo el sistema deberían ser creadas por un equipo de herramientas común, supervisado por el gerente de proyecto.
Hay dos técnicas para reducir los costos de desarrollo de software sobre las que escribe Brooks:
