El Hombre-Mes Mítico

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 administraba 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, contrariamente a la intuición, había retrasado aún más el proyecto. También cometió el error de afirmar que un proyecto, relacionado con la escritura de un compilador ALGOL, requeriría seis meses, independientemente de la cantidad de trabajadores involucrados (requirió 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 'todos lo citan, algunas personas lo leen y unos pocos la gente pasa por ella".

Ediciones

La obra se publicó por primera vez en 1975 (ISBN 0-201-00650-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 comentario del autor.

Ideas presentadas

El mítico hombre-mes

Brooks analiza varias causas de fallas en la programación. El más perdurable es su discusión sobre la ley de Brooks: Agregar mano de obra a un proyecto de software tardío lo retrasa. 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 lo 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 se retrase aún más. Esto se debe a que el tiempo necesario para que los nuevos programadores aprendan sobre el proyecto y el aumento de los gastos generales 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 aumenta n, su producción disminuye y cuando se vuelve negativa, el proyecto se retrasa aún más con cada persona agregada.

• Fórmula de intercomunicación del grupo: n()n −1)/2.
• Ejemplo: 50 desarrolladores dan 50 × (50 – 1)/2 = 1.225 canales de comunicación.

Ninguna bala de plata

Brooks agregó el capítulo "Ninguna bala mágica: esencia y accidentes en la ingeniería de software" y más reflexiones 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 bala de plata: "no existe un único desarrollo, ya sea en tecnología o técnica de gestión, que por sí solo prometa incluso una mejora de un orden de magnitud [diez veces] dentro de una década en productividad, en confiabilidad, en simplicidad."

El argumento se basa en la distinción entre complejidad accidental y complejidad esencial, de forma similar a como la ley de Amdahl se basa en la distinción entre "paralelizable" y "estrictamente serial".

El efecto del segundo sistema

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 agregó 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.

La tendencia hacia un número irreducible de errores

El autor hace la observación de que en un sistema adecuadamente complejo hay 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.

Seguimiento del progreso

Brooks escribió "Pregunta: ¿Cómo llega un año de retraso a un gran proyecto de software? Respuesta: ¡Un día a la vez!" Deslizamientos incrementales en muchos frentes eventualmente se acumulan para producir un gran retraso general. Se requiere una atención continua para cumplir con pequeños hitos individuales en cada nivel de gestión.

Integridad conceptual

Para crear un sistema fácil de usar, el sistema debe tener integridad conceptual, lo que solo se puede lograr separando la arquitectura de la implementación. Un solo 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 el equipo de arquitectos debe desarrollar una idea de lo que debe hacer el sistema y asegurarse de que el resto del equipo entienda esta visión. Es posible que no se incluya una idea novedosa de alguien si no encaja a la perfección 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. El punto es que, si un sistema es demasiado complicado de usar, muchas características no se utilizarán porque nadie tiene tiempo para aprenderlas.

El manual

El arquitecto jefe produce un manual de especificaciones del sistema. Debe describir detalladamente las especificaciones externas del sistema, es decir todo lo que ve el usuario. El manual debe modificarse a medida que llegan los comentarios de los equipos de implementación y los usuarios.

El sistema piloto

Al diseñar un nuevo tipo de sistema, un equipo diseñará un sistema desechable (ya sea que lo intente 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 debe 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 empresa.

Documentos formales

Todo gerente de proyecto debe crear un pequeño conjunto central de documentos formales que definan los objetivos del proyecto, cómo se logrará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.

Estimación de proyectos

Al estimar los tiempos de los proyectos, debe recordarse 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. 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 "todas las manos" reuniones

Comunicación

Para evitar desastres, 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 deben pedirle a los arquitectos que aclaren su intención sobre una función que están implementando, antes de proceder con una suposición que muy bien podría ser completamente incorrecta. Los arquitectos son responsables de formular una imagen de grupo del proyecto y comunicarla a los demás.

El equipo quirúrgico

Al igual que 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 "bueno" El programador desarrolla componentes críticos del sistema mientras que el resto del equipo proporciona lo que se necesita en el momento adecuado. Además, Brooks reflexiona que "bien" los programadores son generalmente de cinco a diez veces más productivos que los mediocres.

Congelación de código y control de versiones del sistema

El software es invisible. Por lo tanto, muchas cosas solo se vuelven evidentes una vez que se ha realizado una cierta cantidad de trabajo en un nuevo sistema, lo que permite que el usuario lo experimente. Esta experiencia generará información, que cambiará las necesidades de un usuario o la percepción de las necesidades del usuario. Por lo tanto, el sistema debe cambiarse para cumplir con los requisitos modificados del usuario. Esto solo puede ocurrir hasta cierto punto, de lo contrario, es posible que el sistema nunca se complete. 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 retrasarse hasta la próxima versión del sistema.

Herramientas especializadas

En lugar de que cada programador tenga su propio conjunto especial de herramientas, cada equipo debe tener un fabricante de herramientas designado que pueda crear herramientas altamente personalizadas para el trabajo que está realizando 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.

Reducir los costes de desarrollo de software

Hay dos técnicas para reducir los costos de desarrollo de software sobre las que escribe Brooks:

• Los ejecutores pueden ser contratados sólo después de que se haya completado la arquitectura del sistema (un paso que puede tardar varios meses, durante el cual los implementadores contratados prematuramente pueden no tener nada que hacer).
• Otra técnica Brooks menciona no es desarrollar el software en absoluto, sino simplemente comprarlo "del estante" cuando sea posible.