Las Bases de la Gestión de Proyectos Software y los Mítos del "Hombre-Mes"
Publicado por Javier Garzás el miercoles 23 de agosto de 2006 a las 21:15
Ultima modificación el el miercoles 23 de agosto de 2006
Añadir programadores a un proyecto con retraso provocará un retraso mayor. En un proyecto la figura del arquitecto software es esencial. Medir el progreso de un proyecto en función del tiempo que lleva desarrollandose es un error. Los grandes retrasos se producen por retrasos en el día a día. Estas afirmaciones, tan importantes como frecuentemente olvidadas en la gestión de proyectos actual, fueron desarrolladas por Brooks en un de los libros más importantes en para la gestión de proyectos software: el mítico hombre mes. Donde, sin lugar a dudas, lo más curioso de la historia es como hoy 30 años después (¡!) casi nadie las conoce y casi todos las incumplen. Y es que, como bien diría el propio Brooks: "They call this book the Bible of Software Engineering... and that's because everybody reads it but nobody does anything about it!"
Con la idea de apoyar la recuperación de "la memoría histórica", ahí va un breve resumen de las pricipales ideas que Brooks plantea en su libro.
Brooks compara el desarrollo de sistemas de software con las arenas movedizas que durante la prehistoria engullían animales gigantes que cuanto más luchaban más rápido se hundían. Independientemente de sus capacidades ningún animal conseguía escapar a su inexorable destino. En las arenas movedizas uno puede lograr sacar a flote una mano o una pierna, pero sacar todo el cuerpo se vuelve más difícil. Brooks traza una analogía entre esta situación y el desarrollo. Puede ser fácil desarrollar un programa o componente, pero desarrollar un sistema es mucho más complejo que desarrollar separadamente los elementos que lo componen.
La única salida de este pozo de arenas movedizas es aplicar un proceso de ingeniería consciente y métodos probados en la gestión de proyectos.
La principal causa de los problemas en el desarrollo software está en la planificación y distribución de recursos.
La idea de que horas y recursos humanos son intercambiables conlleva la asunción de que si un proyecto está retrasado basta con agregar más mano de obra (mano de obra = horas, días o meses de trabajo).
El factor humano y las horas no se pueden conmutar como en una multiplicación: el tiempo extra que se agrega por persona va a parar a reuniones, planes, e-mails, negociaciones, discusiones, revisiones, coordinación de reuniones, actas, explicaciones, formación, alguien que tendrá que actuar como supervisor, este supervisor que tendrá que reportar al jefe del proyecto, etc. Por otro lado existen tareas que simplemente no se pueden dividir y deben ser realizadas por la misma persona.
La manera de terminar antes (o no demasiado tarde cuando el proyecto se retrasa por diferentes motivos) no es agregar programadores, sino descartar funcionalidades aún no implementadas. De donde Brooks introduce su famosa ley:
“Adding manpower to a late software project makes it later”
(NOTA: Curiosamente si la Ley de Brooks fuese de aplicación general desarrollos como Linux serían imposibles. En este sentido unos años después Gerald Weinberg en The Psychology of Computer Programming planteará una corrección la ley de Brooks. En su discusión sobre la "programación sin ego", Weinberg señala que en los lugares donde los desarrolladores no tienen propiedad sobre su código, y estimulan a otras personas a buscar errores y posibles mejoras, el avance es mucho más rápido.)
La estimación de un proyecto es algo muy complicado en el que se tiende a equiparar el consumo de las horas estimadas al progreso del proyecto.
Para Brooks la medida utilizada para medir la duración de los proyectos (meses, días u horas de trabajo) es intrínsecamente errónea. Esta medida es falsa: si bien el coste de un proyecto es proporcional a la cantidad de meses de mano de obra, el progreso del mismo no lo es.
Brooks sostiene que la coherencia del modelo mental de la aplicación y el modelo de construcción subyacente, que denomina integridad conceptual, es determinante.
Una aplicación grande es desarrollada por un equipo de varias personas que deben producir un único modelo mental de la aplicación.
¿Cómo organizar el diseño para lograr esta integridad conceptual? Centralizandola la en la figura del arquitecto del sistema, quien diseña el sistema en su totalidad y es responsable final del mismo.
De esto se deriva:
1. El rol de arquitecto es de tal envergadura que, salvo en proyectos pequeños, no puede compatibilizarse con el rol de jefe de proyecto. Si lo comparamos con el cine, el arquitecto es el director y el jefe de proyecto es el productor ejecutivo de la película.
2. Para hacer posible la tarea del arquitecto es indispensable separar la arquitectura de la implementación. De ahí que el arquitecto sea el responsable de lo que afecta al usuario directamente y no de su implementación, y por ello es responsable de todas las especificaciones de interfaz (relativas al usuario).
3. En sistemas de gran tamaño puede ser necesario que crear la figura del arquitecto jefe, quien subdivide el sistema en subsistemas y delega en otros arquitectos. El arquitecto jefe es el responsable de la integración de estos subsistemas y de su coherencia interna.
La integridad conceptual se logra cuando el control del desarrollo software se mantiene intelectualmente en las manos de un reducido grupo de buenos diseñadores (mejor uno que dos, mejor dos que tres, etc.) y consiste en definir una unidad arquitectónica que armonice el conjunto de ideas y la elección de técnicas a lo largo de la construcción del sistema.
© Copyright Javier Garzás, all rights reserved. All material on this site is copyrighted. For articles attributed to named authors, they are the copyright of the corresponding authors. Any unattributed articles are copyright Javier Garzás. Please link freely to this site, but if you want to copy any of the materials you should contact the authors first.