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 intenta mostrar que «añadir recursos humanos a un proyecto retrasado lo hace demorarse aún más». Esta idea es conocida como la «Ley de Brooks».
La obra data de 1975. En 1995, con motivo del 20 aniversario de su publicación, se lanzó una nueva reedición (ISBN 0-201-83595-9) junto al ensayo «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 los administradores de proyecto de repetir estos errores llevaron a Brooks a la conclusión de que a su libro se le llamaba "La biblia de la ingeniería de software" porque "todos la citan, algunas personas la leen, pero casi nadie la practica".
El Mito del Hombre-Mes
editarAsignar 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
editarEl 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
editarPregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero? Respuesta: ¡Día a día! Pequeñas demoras incrementales en variados frentes finalmente 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
editarPara hacer que un sistema sea amigable con el usuario, debe tener integridad conceptual, lo que sólo 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 súper idea de alguien no debe ser incluida 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 demasiado 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
editarLo 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
editarAl 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
editarCada gerente de proyecto debe crear un pequeño conjunto de documentos centrales que definan los objetivos del proyecto, cómo se deben alcanzar, quiénes deben alcanzarlos, cuándo deberán alcanzarse y cuánto van a costar. Estos documentos pueden revelar inconsistencias que de otro modo serían difíciles de distinguir.
Actividades que no pueden ser repartidas o aceleradas
editarEl embarazo de un niño toma nueve meses, no importa el número de mujeres que se asignen a esa tarea. Muchas tareas tienen esta característica debido a los diferentes ciclos de prueba envueltos.
Enlaces externos
editar
Datos: Q1192316
