LECCIÓN 1: Introducción a la gestión ágil de proyectos software
Construir software
no es igual que construir productos físicos,
como construir un edificio o un coche
Aunque muchas veces se compara a la ingeniería del software con la arquitectura o la
fabricación de productos físicos, como las cadenas de montaje, construir software no es igual que construir productos físicos. Pero son muchas las ocasiones en las que escuchamos que el desarrollo software debiera trabajar igual que este tipo de procesos de construcción de productos físicos. El desarrollo “debería trabajar como las cadenas de montaje, deberíamos enviar una especificación de requisitos a la empresa o equipo de desarrollo y esperar un producto que cumpla plenamente con la misma”.
Pero difícilmente el cómo se desarrolla software será igual que fabricar un coche o construir un edificio. El producto final,
el software, tiene diferencias muy sustanciales con estos productos físicos. Y obviar estas diferencias puede implicar importantes problemas a la hora de desarrollar, planificar, gestionar, etc., el proyecto software.
Uno de los pilares de las metodologías ágiles es reconocer y dejar clara esta diferencia
(fabricar software no es lo mismo que fabricar un producto físico). ¿Por qué? Porque aunque hay muchas diferencias, a la hora de desarrollar software las fases de
diseño y construcción no se comportan de manera similar y los costes del proyecto se comportan de manera diferente. Veámoslo a continuación.
Separación diseño y construcción
En la ingeniería software, a diferencia de la arquitectura u otras ingenierías tradicionales
, no se puede separar tan claramente la fase de diseño de la fase de construcción.
Desde sus orígenes,
la ingeniería del software intentó perseverantemente emular a las ingenierías clásicas o a la arquitectura. El objetivo era tener una fase de diseño muy separada de la fase de codificación. La codificación no debía comenzar hasta que no terminase el diseño. El diseño concluiría con unos “planos” (p.e. un UML) precisos que guiarían totalmente la construcción. Idealmente, una vez hecho el diseño, éste no se modificaría durante el resto del desarrollo (como ocurre a la hora de construir un edificio, que los planos son previos a la obra, y no se modifican una vez empezada la construcción). De hecho, notaciones para “planos” como UML y ciclos de vida como el cascada (donde cada fase se hace una sola vez y no se pasa a la siguiente fase hasta que se termina la previa) nacieron con este objetivo. De ahí que a
las metodologías más tradicionales se las denominaran también "dirigidas por el plan".
Está demostrado que
es muy difícil especificar en una única y primera fase de diseño todas las cuestiones a tratar en la programación. Por la complejidad de las reglas de negocio que automatizamos cuando construimos software es muy difícil saber qué software se quiere hasta que ya se trabaja en su implementación. De ahí que, en el software, el diseño y la construcción se solapen y que, por ello, muchas veces se recomiende construir por iteraciones (mediante el uso de prototipos incrementales). El diseño muchas veces se construye casi en paralelo a la codificación.
A la mayoría de los diseños de las ingenierías clásicas, arquitecturas, etc., no les sucede esto porque se basan en las matemáticas o la física. En software no es así. Y aunque se pretenda emular ese modo de fabricación en software no funciona bien. Debemos tener muy claro que
es casi imposible cerrar un diseño a la primera para pasarlo a codificación sin tener que modificarlo.
La diferente distribución de los costes del proyecto
Por lo general, realizar un cambio en el producto final de una ingeniería clásica o en un edificio es muy costoso. Cambiar un pilar en un edificio ya construido es altamente costoso. Cambiar una pieza en un coche ya construido implica altos costes. Pero en cambio
el software, por su naturaleza (y si se construye bien),
es fácil de modificar y versionar. Cambiar líneas de código tiene menos coste que cambiar los pilares de un edificio ya construido. De ahí que existan numerosas propuestas que recomiendan construir rápido una versión software y modificarla evolutivamente (p.e.
la técnica de refactorización). Y por ello,
las metodologías ágiles aceptan el cambio del software, y están pensadas para convivir con esta constante evolución y cambio del producto software.
Cambiar el software no es un problema… es una ventaja.
Conclusión
Intentar construir software de la misma manera a como se hace un edificio puede implicar importantes problemas a la hora de desarrollar, de planificar el proyecto, gestionarlo o incluso a la hora de poner solución a una posible desviación sobre el plan.
Los intentos por comparar e intentar emular la construcción de productos físicos han llevado a grandes errores en gestión de proyectos software. Como intentar añadir más programadores a un proyecto retrasado con el objetivo de acelerarlo, creando el efecto contrario (te recomiendo aquí la lectura de
este post). O intentar calcular el avance de proyecto contando líneas de código. Ambos errores vienen de pensar que construir software es como construir un edificio (si la obra va retrasada añado más albañiles o cuento el avance según los “ladrillos” o los metros de altura del edificio).
Las características de los proyectos de desarrollo software hacen necesario seguir prácticas específicas para optimizar los resultados del desarrollo. Es por ello que surgen diferentes metodologías para dirigir y gestionar proyectos software, entre ellas
las metodologías ágiles. Éstas están especialmente indicadas para proyectos con requisitos cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.
La semana que viene veremos el ciclo de vida iterativo e incremental, base de las metodologías ágiles y que refleja un método de gestión diferente a aquel dirigido por el plan.
¡No olvides las lecturas recomendadas!
Siguiente semana: LECCIÓN 2
El ciclo de vida
iterativo e incremental
