notasbrooks
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.
El desarrollo de software muchas veces es como un pozo de arenas movedizas
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.
El mito del "mes-hombre"
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 y el seguimiento
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.
La integridad conceptual y el papel del arquitecto software
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.
Síntesis de los principios de Brooks
- El mítico hombre-mes. Añadir más progamadores a un proyecto retrasado lo retarsará aún más.
- El efecto de segundo sistema. El segundo sistema que un ingeniero diseña es el diseño más peligroso... ya que será desastrosamente sobre-diseñado.
- El seguimiento del proyecto. “¿Cómo se puede retrasar un proyecto un año? … retrasándose un poco cada día". Para una buena gestión es recomendable fijar hitos pequeños e individuales.
- Integridad Conceptual. La arquitectura debe separarse de la implementación, debe existir una conceptualidad global y un arquitecto responsable de la misma.
- El sistema piloto. Cuando se diseñoa un nuevo sistema, primero se debe diseñar un prototipo desechable. Este actuará como piloto, para mostrar las guías necesarias a la hora de diseñar el sistema final.
- Documentos formales. Todo jefe de proyecto debe crear un pequeño conjunto de documentación formal, que actúe como guia, que marque los objetivos, la manera de lograrlos, etc.
- Comunicación. Todos los miembros del proyecto deberían tener a su disposición el mayor número de medios de comunicación posibles (e-mail, teléfono, etc.). En caso de duda el programador debe consultar al arquitecto, evitando asunciones erroneas.
- El "surgical team". Los buenos programadores son de 5 a 10 veces más productivos que los mediocres. Es preferible un equipo menor pero de mayor calidad.
- Congelar el código y el versionado. Cuando el usuario vea el software irá tomando experiencia en él, y esta experiencia provocará nuevas necesidades. En algún momento es necesario congelar el código y dejar el resto de necesidades para próximas versiones.
- Herramientas. Todos los miembros del equipo deben usar las mismas herramientas.
© 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.