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 cómo agregar mano de obra a un proyecto de software que está retrasado lo retrasa aún más. Esta idea se conoce como ley de Brooks y se presenta junto con el efecto de 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 agregado más programadores a un proyecto que se estaba retrasando, una decisión que más tarde concluiría que, de manera contraria a la intuición, había retrasado aún más el proyecto. También cometió el error de afirmar que un proyecto (que implicaba escribir un compilador ALGOL ) requeriría seis meses, independientemente del número de trabajadores involucrados (requería más). 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 otras pocas lo siguen". [1]
El trabajo se publicó por primera vez en 1975 ( ISBN 0-201-00650-2 ), [2] reimpreso con correcciones en 1982 y republicado en una edición de aniversario con cuatro capítulos adicionales en 1995 ( ISBN 0-201-83595-9 ). incluyendo una reimpresión del ensayo " No Silver Bullet " con comentario del autor.
Brooks analiza varias causas de fallas en la programación. La más duradera es su discusión sobre la ley de Brooks : Agregar mano de obra a un proyecto de software tardío lo hace más tardío . Hombre-mes 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 tanto, es la pieza 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 está retrasando hará que llegue aún más tarde. Esto se debe a que el tiempo necesario para que los nuevos programadores aprendan sobre el proyecto y la mayor sobrecarga de comunicación consumirán una cantidad cada vez mayor del tiempo calendario disponible. 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 agregada.
Brooks agregó el capítulo "No Silver Bullet: Esencia y accidentes en la ingeniería de software" y reflexiones adicionales al respecto 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 ni siquiera un orden de magnitud [diez veces] de mejora en una década en productividad, confiabilidad y simplicidad".
El argumento se basa en la distinción entre complejidad accidental y complejidad esencial, 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, es el sistema más peligroso que jamás diseñará, porque tenderá a incorporar todas las adiciones que originalmente no agregaron al primer sistema debido al tiempo inherente. restricciones. Por lo tanto, al embarcarse en un segundo sistema, un ingeniero debe tener en cuenta que es susceptible de realizar una ingeniería excesiva.
El autor hace la observación de que en un sistema adecuadamente complejo existe un cierto número irreducible de errores. Cualquier intento de corregir los errores observados tiende a dar lugar a la introducción de otros errores.
Brooks escribió: "Pregunta: ¿Cómo es posible que un gran proyecto de software llegue a tener un año de retraso? Respuesta: ¡Un día a la vez!". Los desvíos incrementales en muchos frentes eventualmente se acumulan para producir un gran retraso general. Se requiere atención continua para cumplir pequeños hitos individuales en cada nivel de gestión.
Para crear un sistema fácil de usar, el sistema debe tener integridad conceptual, lo que sólo puede lograrse separando la arquitectura de la implementación. Un único arquitecto jefe (o un pequeño número de arquitectos), actuando en nombre del usuario, decide qué entra en el sistema y qué queda fuera. El arquitecto o equipo de arquitectos debe desarrollar una idea de lo que debe 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 encaja perfectamente con el 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. La cuestión es que si un sistema es demasiado complicado de utilizar, muchas funciones no se utilizarán porque nadie tiene tiempo para 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 lleguen 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 desechable (tanto si lo desea como si 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 de la empresa.
Cada director de proyecto debe crear un pequeño conjunto básico de documentos formales que definan los objetivos del proyecto, cómo se alcanzarán, quién los logrará, cuándo se lograrán y cuánto costarán. Estos documentos también pueden revelar inconsistencias que de otro modo serían difíciles de ver.
Al estimar los tiempos del proyecto, se debe recordar que los productos de programación (que pueden venderse a clientes que pagan) y los sistemas de programación son tres veces más difíciles de escribir que los simples programas internos independientes. [3] Debe tenerse en cuenta qué parte de la semana laboral se dedicará realmente a cuestiones técnicas, en contraposición a tareas administrativas u otras tareas no técnicas, como reuniones y, especialmente, "stand-up" o "all-hands". "reuniones.
Para evitar un desastre, todos los equipos que trabajan en un proyecto deben permanecer en contacto entre sí de tantas formas como sea posible (correo electrónico, teléfono, reuniones, memorandos, etc.). En lugar de asumir algo, los implementadores deberían pedirle a los arquitectos que aclaren su intención sobre una característica que están implementando, antes de proceder con una suposición que bien podría ser completamente incorrecta. Los arquitectos son responsables de formular una imagen grupal del proyecto y comunicarla a los demás.
Así como un equipo quirúrgico durante la cirugía está dirigido por un cirujano que realiza el trabajo más crítico, mientras dirige al equipo para ayudar con las partes menos críticas, parece razonable tener un "buen" programador que desarrolle los componentes críticos del sistema mientras el resto del equipo proporciona lo que se necesita en el momento adecuado. Además, Brooks reflexiona que los "buenos" programadores son generalmente de cinco a diez veces más productivos que los mediocres.
El software es invisible. Por lo tanto, muchas cosas sólo se vuelven evidentes una vez que se ha realizado una cierta cantidad de trabajo en un nuevo sistema, lo que permite al usuario experimentarlo. 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 debería modificarse para cumplir con los requisitos modificados del usuario. Esto sólo puede ocurrir hasta cierto punto; de lo contrario, es posible que el sistema nunca se complete. En una fecha determinada, no se deberían permitir más cambios en el sistema y el código debería congelarse. Todas las solicitudes de cambios deben retrasarse hasta la próxima versión del sistema.
En lugar de que cada programador tenga su propio conjunto especial de herramientas, cada equipo debe 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 crea código basado en una especificación). . Además, las herramientas para todo el sistema deben ser creadas por un equipo de herramientas comunes, supervisado por el director del proyecto.
Hay dos técnicas para reducir los costos de desarrollo de software sobre las que Brooks escribe:
