|
 “Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha analizado y especificado pobremente, decepcionará al usuario y desprestigiará al que lo ha desarrollado”.
Roger S. Pressman. Ingeniería del Software. Mc Graw Hill 1995. Parece lógico suponer que antes de empezar a construir algo, lo mejor es conocer con detalle qué es lo que vamos a hacer.
Una constructora, por ejemplo, podría levantar el edificio que espera su cliente, de forma evolutiva e incremental, a través de ciclos sucesivos de: “construcción – validación con el cliente – demolición de lo erróneo”. Pero contar con un proyecto detallado antes de empezar la construcción es un modelo de desarrollo mucho más adecuado.
En el desarrollo de software, el razonamiento que implica esta comparación es un punto de discordia importante entre defensores de modelos procesos, y de modelos ágiles.
Para los modelos de procesos (CMMI, ISO15504...) y para el marco de gestión de proyectos predictivo (PMI, IPMA...) es obvio y axiomático que:
- Para saber el tiempo y el precio que costará el proyecto, hay que tener una planificación detallada.
- Para elaborar un plan detallado hay que saber con precisión, qué es lo que se va a construir.
- La gestión de proyectos es la profesión que comprende las áreas de conocimiento necesarias para planificar, gestionar la ejecución del trabajo planificado, detectar y corregir las desviaciones.
Sin embargo para la gestión de proyectos adaptable o ágil, las fases no son fases, sino actividades que se desarrollan durante todo el ciclo de vida, a demanda según las circunstancias. El diseño, por ejemplo no es la fase que se realiza después de los requisitos. El diseño, como el descubrimiento de los requisitos, o la codificación y pruebas son actividades que se ejecutan según se van necesitando, a lo largo de iteraciones cortas.
Los requisitos no se conocen de forma detallada al comenzar. La comunicación con el cliente, el análisis y la interacción con los resultados de cada iteración los irán descubriendo.
Las fechas no son resultado de una planificación, sino restricciones de negocio. La garantía del resultado no se confía a los procesos sino a la excelencia técnica y a la responsabilidad del equipo.
La existencia de estos dos enfoques para la gestión de proyectos ocasiona:
- Discusiones de caracter fundamentalista entre defensores de ambos "bandos".
- Despistes y desaguisados al aplicarlos en las organizaciones y en los proyectos que por simpatías, corazonadas o asesoramientos poco objetivos adoptan tal cual modelos poco apropiados.
Algunas cuestiones que ayudan a dar una perspectiva objetiva sobre la utilidad, y ámbito de cada marco:
El software no resulta comparable a la materia prima de otras ingenierías.
El software no es físico, y los sistemas de soft, a diferencia de los artefactos físicos son muy maleables. Por eso es tendencioso presuponer una "talla única" de gestión válida para cualquier sistema y establecer un paralelismo transitivo de métodos que por ser apropiados para la construcción de edificios o aviones, también lo son para desarrollar software.
A nadie se le ocurre comenzar la construcción de un edificio sin saber cuál será exactamente el nº de plantas, o la superficie de éstas; o desarrollar una embarcación básica, e ir ampliando y modificando sus características, a medida que por el uso las van descubriendo los usuarios.
Sin embargo con el software esto es posible.
La capacidad de fertilización que sobre el concepto inicial del producto da el ver, tocar y jugar con un prototipo, con un fragmento de la obra, descubre posibilidades valiosas para el producto, que de otra forma difícilmente podrían haber sido incluidas en una descripción inicial.
La cuestión es: ¿cómo de caro resulta construir poco a poco, realizando "prototipos" que retro-enriquecen la visión del producto?.
Si puedo:
- Poner en contacto directo a desarrolladores y usuarios.
- Conseguir que formen un equipo excelente y motivado.
- Conseguir que toquen, interactúen y vean partes operativas del producto en fases tempranas, y enriquezcan el concepto y valor del producto.
Entonces puedo lograr productos con mayor innovación y con un valor superior al que el que habría conseguido a través de una obtención detallada de requisitos inicial y cerrada.
"Preferimos el software que funciona a la documentación exhaustiva" (agilemanifesto.org)
- La cuestión no es decidir cuál es el mejor modelo para los sistemas de software, sino para "este" sistema de software, con sus características determinadas:
- Grado de incertidumbre del escenario tecnológico sobre el que se desarrolla.
- Grado de inestabilidad del entorno de mercado del cliente.
- Nitidez de la visión del producto.
- Nivel de valor que por innovación necesita el cliente.
- Estructura y factores sociales de las organizaciones adquirientes y suministradora.
- etc.
Si de lo que se trata es del programa para la gestión de un producto bancario, archiconocido, del que se pueden saber extraer y analizar todos sus requisitos al comenzar el proyecto, y para el que el cliente no espera un valor de innovación, sino eficiencia y predecibilidad de desarrollo; por muy software que sea, lo más acertado será conducir el proyecto con un modelo de gestión clásico predictivo.
 |
RSS de los comentarios
creo que la frase de Pressman que comentas no es excluyente con la visión ágil; comprender perfectamente los requisitos determinará el éxito del proyecto ya sea que los entiendas al principio como que los entiendas gradualmente.
Los modelos para mejora de procesos como CMMI no impiden trabajar en forma ágil. CMMI da lineamientos, no especifica procesos, por lo que puedo implementar un framework de procesos ágil cumpliendo los lineamientos de CMMI.
Por la parte de gestión de proyecto, el PMI a través de su PMBoK (al menos en su última edición) insiste en la naturaleza progresiva e iterativa de los proyectos y la necesidad de ejecutar procesos y revisitarlos a medida que avanzamos. Es más, da como ejemplo en proyectos de software el caso de ejecución paralela de actividades de diferentes "fases" para reforzar su postura... Tampoco es excluyente con la visión ágil.
No pretendo contradecir tus comentarios, solo escribo estas lineas para darte mi opinión sobre estos temas puntuales. Creo que la agilidad o no agilidad de los proyectos de desarrollo tienen más que ver con en enfoque de quien implementa los procesos, más que con los estándares de proceso que estos últimos han ido evolucionando y se presentan bastante poco rígidos... (excepto por SOX, pero de esto mejor ni hablar)