El Mítico Hombre-Mes

El Mítico Hombre-Mes: Ensayos de ingeniería de Software (en inglés The Mythical Man-Month : Essays on Software Engineering) es un libro de administración de proyectos de Software de Fred Brooks, cuyo tema central está en que "agregando fuerza de hombre a un proyecto retrasado lo hace demorar aún más". Esta idea es conocida como la "ley Brooks".

El trabajo fue publicado en 1975, y republicado como una versión aniversario en 1995 (ISBN 0-201-83595-9) junto al ensayo "Sin balas de plata" y comentarios por el autor. Puedes encontrar una traducción en este enlace de Sin balas de plata.

Las observaciones de Brooks están basadas en sus experiencias en IBM mientras administraba el desarrollo de OS/360. Para acelerar el desarrollo, se trató infructuosamente de agregar más trabajadores al proyecto que ya estaba retrasado. También apostó que escribir un compilador en ALGOL requería "6 meses de mano de obra" adicional. La tendencia de quienes administran de repetir estos errores llevaron a Brook a la conclusión de "la biblia de la ingeniería de software" porque "todos la leen pero nadie la practica".

El Mítico Hombre-Mes

Asignar más programadores a un proyecto atrasado sólo lo atrasará más, debido al tiempo requerido por los nuevos programadores para aprender acerca del proyecto, como al aumento en la sobrecarga de comunicaciones. Cuando N personas tienen que comunicarse entre ellos (sin jerarquías), al aumentar N, la cantidad de comunicación M disminuye y puede incluso resultar negativa, p.ej., el trabajo total pendiente al final del día es mayor que el trabajo total que había pendiente al principio del día, como cuando se crean muchos nuevos errores.

• Fórmula de la intercomunicación grupal: n(n − 1) / 2
• Ejemplo: 50 programadores generan 50 · (50 – 1) / 2 = 1225 canales de comunicación.

El efecto Segundo-Sistema

El segundo sistema que un arquitecto diseña, es el más peligroso de todos los que nunca hará, dado que tenderá a incorporar todos los agregados que él mismo generó pero no pudo agregar (debido a inherentes restricciones de tiempo) a su primer sistema. Por tanto, cuando se embarca en un segundo sistema, un ingeniero debería tener presente su natural tendencia a sobrecargarlo.

Seguimiento de progresos

Pregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero? Respuesta: ¡De a un día a la vez! Pequeñas demoras incrementales en variados frentes eventualmente se acumulan para producir un enorme retraso. Permanente atención al alcance de pequeñas metas individuales se requiere en todos los niveles del proyecto.

Integridad Conceptual

Para hacer que un sistema sea utilizable (amigable), debe tener integridad conceptual, lo que solo es posible separando la arquitectura de la implementación. Un único arquitecto jefe (o un pequeño número de arquitectos), actuando en representación del usuario, decide qué debe ir en el sistema y qué debe permanecer fuera. Una "super" idea de alguien no debe ser incluída si no calza armoniosamente con el diseño general del sistema. De hecho, para asegurarse un sistema amigable, se debe brindar deliberadamente menos características de las que es capaz de tener. El punto es que si un sistema es demasido complejo de usar, entonces muchas de sus características no se utilizarán solo porque nadie tendrá el tiempo de aprender a usarlas.

El Manual

Lo que el diseñador en jefe produce son especificaciones escritas para el sistema en forma de manual. Debería describir las especificaciones externas del sistema en detalle, p.ej., todo lo que el usuario ve. El manual debería ser alterado a medida que se recibe retroalimentación de los usuarios y del equipo de desarrollo.

El Piloto

Al diseñar un nuevo tipo de sistema, un equipo hará un sistema descartable (aunque esa no sea su intención). Este sistema actúa como una "planta piloto" que revela técnicas que subsecuentemente causarán un completo rediseño del sistema. Este segundo sistema, más inteligente es el que se entregará el cliente, dado que la entrega del sistema piloto solo provocará enojo y decepción en el cliente, y posiblemente la ruina de la reputación del sistema y hasta la de la empresa.

Documentos Formales

Cada gerente de proyecto debe crear un pequeño conjunto de documentos centrales que definan los objetivos del proyecto, como se deben alcanzar, quiénes deben alcanzarlos, cuando deberán alcanzarse, y cuánto van a costar. Estos documentos pueden revelar inconsistencias que de otro modo son difíciles de distinguir.

Enlaces externos

• Las bases de la gestión de proyectos software y los mitos del "hombre-mes"