A raíz varias conversaciones interesantes de esta semana, en las que comentábamos el por qué de los retrasos en los proyectos software, lo increíble de algunas decisiones en la gestión de proyectos, etc., añado este “post” (reescrito de mi anterior página) sobre las principales ideas de Brooks, uno de los autores más relevantes en gestión de proyectos software.
Brooks (1931) fue director del desarrollo del famoso OS/360 de IBM, y a raíz de sus experiencias, éxitos y fracasos escribió “The Mythical Man-Month: Essays in Software Engineering” (aqui la reedición 20 aniversaro de 1995), libro al que deben su mayor fama, aunque no suficiente, frases como:
- “Añadir recursos humanos 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 desarrollándose es un error”
- “¿Cómo puede un proyecto acumular un retraso de un año?… acumulando retrasos día a día”.
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 lleva a que si un proyecto está retrasado la solución sea agregar más mano de obra. Pero el factor humano y las horas no se pueden conmutar como en una multiplicación: el tiempo extra que se añade por cada persona va a parar a reuniones, planes, e-mails, negociaciones, discusiones, revisiones, coordinación de reuniones, actas, explicaciones, formación, etc. Y por otro lado existen tareas que simplemente no se pueden dividir y deben ser realizadas por la misma persona.
Brooks compara el desarrollo software con las arenas movedizas que durante la prehistoria engullían animales gigantes que cuanto más luchaban por escapar más rápido se hundían. 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 libro de Brooks es de 1975, y lo más curioso es como más de 30 años después afirmaciones como las anteriores son muy poco conocidas así como frecuentemente incumplidas. Ya lo dijo 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!»
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
A las frases famosas de este libro yo añadiría:
Un componente (o módulo) no lo considero finalizado hasta que no lo entregan con pruebas (unitarias).
Wow! Hace 30 años ya manejaba ese concepto! Y yo, en pleno siglo XXI, he visto muchas empresas de software que ni siquiera saben que es una prueba unitaria 🙁
Plenamente es una frase que se pasa Absolutamente de largo. Concuerdo plenamente contigo David, empresas en donde el unit test es como los unicornios.
Y cuando les dices que usemos TDD te miran con cara de ya ya dejen que hable no más
Pingback: Las leyes de la evolución del software | Javier Garzás
Pingback: Algunos retos de los profesionales del software. La memoria histórica (2/4) | Javier Garzás
Pingback: La metodología ágil FDD. Además de Scrum hay otras metodologías ágiles (2/2) - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Lo que le contaría a Dijkstra: Hay emprendedores perdiendo su proyecto por usar malas prácticas software - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: 5 graves e históricos errores software… derivados de creer que gestionar software es lo mismo que construir cosas físicas - Javier Garzás | Javier Garzás
Pingback: » Leyes de gestión de proyectos que quizás no sabias
Hola Javier, me encantó este artículo y amo la forma como referencias conceptos y explicaciones adicionales para entender en profundidad cada artículo. GRACIAS!
Hola Javier, me encantó este artículo y amo la forma como referencias conceptos y explicaciones adicionales para entender en profundidad cada artículo. GRACIAS! fd
😉