Los Fundamentos de Agile Scrum. Frank Turley
■ METODOLOGÍA DE ENTREGA DE PROYECTO Y CICLO DE VIDA
Cuando se desarrolla software, de una manera u otra, se realizan los siguientes pasos, bien para funcionalidades individuales o para la solución completa:
■ Analizar
■ Diseñar
■ Desarrollar
■ Integrar
■ Prueba (Test)
Por supuesto, se puede usar otra terminología para esos pasos, o agruparlos en menos pasos, o dividirlos en más; está bien. Estos pasos los podemos llamar procesos de entrega.
Ahora, la pregunta es, ¿Cómo vamos a gestionar y realizar estos procesos? Piense en algunas opciones antes de leer el resto de este capítulo.
¿En cuántas opciones ha pensado?
Puede que tenga muchas opciones en mente, pero todas deben pertenecer a una de las dos formas genéricas que hay. A propósito, estas opciones las podemos llamar el ciclo de vida del desarrollo.
Un ciclo de vida genérico es algo así:
En este ciclo de vida, cada proceso se debe completar antes de proceder al siguiente; es decir, analizamos por completo el requisito y decidimos qué queremos que contenga la solución. Entonces, diseñamos la arquitectura de la solución y averiguamos la mejor manera de dar forma a las características. Entonces, los programadores empiezan a trabajar en las distintas unidades y después las unidades se integran en una solución. Y esa solución se prueba.
Es obvio que los pasos se pueden solapar; por ejemplo, no es necesario esperar a que todas las unidades estén completas antes de integrarlas y probarlas. Su ciclo de vida puede tener el siguiente aspecto:
En esencia, no es distinto del ciclo de vida anterior; seguimos teniendo una secuencia de procesos de desarrollo como motor principal del ciclo de vida.
Como podrá observar, este tipo de ciclo de vida se basa en un esfuerzo inicial por entender qué es lo que vamos a producir. Tenemos una especificación por adelantado, un diseño por adelantado y, por consiguiente, un plan por adelantado. Por eso, a veces se le llama un desarrollo dirigido por el plan. También intentamos predecir qué es lo que queremos y cómo se puede producir, y por eso también se le suele llamar predictivo.
Un Ciclo de vida Predictivo es la manera habitual y apropiada de desarrollar muchos proyectos, como por ejemplo un proyecto de construcción. En primer lugar, se planifica y diseña, y luego se sigue ese plan y diseño. Sin embargo, esto no es cómodo para algunos tipos de proyectos.
Piense en el típico proyecto de desarrollo de TI. Puede dedicarle mucho tiempo a la especificación y análisis de los requisitos, y basarlo todo en eso. ¿Qué ocurre después? ¡Que el cliente no estará contento cuando vea el resultado! Pedirá cambios, y los cambios son caros en este ciclo de vida porque es posible que haya que revisar todo el trabajo anterior.
Como se suele decir en este sector, el cliente no sabe lo que quiere hasta que ve el producto. ¿Cuándo ven el producto? Hacia el final del proyecto. En ese punto, el coste de cambiar es máximo.
Para superar este problema, podemos renunciar a la comodidad y a la estructura de un ciclo de vida predictivo y usar uno que cree el producto de forma incremental, es decir en múltiples versiones, cada vez con más características. Este es un lujo que tenemos en los proyectos de desarrollo de TI que no puede tener todo el mundo: múltiples versiones de software funcional, cada vez con más características. Piense en un proyecto de construcción, no hay incrementos significativos y el producto no se puede utilizar hasta el final.
Para ser justos, esta desventaja de un proyecto de construcción se compensa con el hecho de que si se tiene que empezar un proyecto para construir un hospital, el resultado final será un hospital, con independencia de la cantidad de cambios que haga, y no, por ejemplo, ¡un parque de atracciones! Sin embargo, en desarrollo de TI, se puede empezar un proyecto para crear algo parecido a un hospital y acabar con algo parecido a un parque de atracciones.
Por lo tanto, en los proyectos de desarrollo de TI, podemos tener entregas incrementales: aprovechemos esta oportunidad mediante un ciclo de vida como el siguiente:
No hay una predicción real en este ciclo de vida. En vez de predecir el producto y depender de esa predicción, tenemos pequeños periodos de tiempo durante los cuales creamos incrementos del producto. Mostraremos ese incremento (la última versión del producto) al cliente y a los usuarios finales, recibiremos su feedback (sus comentarios al respecto), y decidiremos qué hacer en el siguiente periodo de tiempo. Así que, en vez de basarnos en la predicción, seguimos con el proyecto y nos adaptamos al feedback. ¿Cómo queréis llamar a este ciclo de vida? “Adaptativo” es un buen nombre: ciclo de vida adaptativo.
Para crear cada incremento, necesitamos ejecutar todos los procesos de desarrollo durante ese periodo de tiempo. En el siguiente periodo, repetiremos los procesos: iteramos. Por eso, este método de desarrollo se llama a veces desarrollo iterativo. Los periodos de tiempo durante los cuales iteramos, se pueden llamar iteraciones. No es el único nombre que se utiliza para ello. Puede que ya conozca por lo menos un nombre más para las iteraciones. Volveremos pronto a este tema.
■ CICLOS DE VIDA PREDICTIVOS VS ADAPTATIVOS
Tanto el ciclo de vida adaptativo como el predictivo, tienen ventajas y desventajas. Que la selección del ciclo sea la correcta depende de muchos factores, pero el más importante es el tipo de producto.
Se pueden hacer dos preguntas esenciales antes de decidir el tipo de ciclo de vida que necesita para su proyecto:
1. ¿Necesito poder adaptarme? Porque si no, un ciclo de vida predictivo es…. ¡Pues más predecible! Es más fácil y está más estructurado. Se necesita un sistema adaptativo cuando existe el riesgo de empezar con la idea de crear un hospital y acabar con un parque de atracciones.
2. ¿Puedo adaptarme? Esta pregunta es todavía más importante. Para ser adaptativo, se debe tener la posibilidad de desarrollar de formar iterativa y de entregar de forma incremental. Pensemos de nuevo en un proyecto de construcción: ¿puede construir el edificio de forma iterativa? ¿Puede diseñar la base sin diseñar el resto del edificio que determinará la carga que debe soportar la base? ¡La respuesta es sencillamente NO! No es posible usar el desarrollo iterativo en un proyecto de construcción. Y la entrega de forma incremental tampoco es posible, como ya hemos visto. Así que no podemos usar un ciclo de vida adaptativo para construir un edificio (no nos confundamos con el diseño interior y la decoración, o incluso unas reformas, para las cuales sí es posible que podamos usar un sistema adaptativo).
Lo que quiero transmitir es que Predictivo vs Adaptativo no es una cuestión que una cosa es buena y la otra mala.
Como pequeño ejercicio, piense en un proyecto de TI para actualizar los sistemas operativos de 300 ordenadores de una organización o en un proyecto de TI para crear una infraestructura de red para una organización enorme con seis oficinas. En su opinión, ¿qué ciclo de vida de desarrollo es mejor para estos dos proyectos?
■ AGILE VS MÉTODO EN CASCADA (WATERFALL)
“Agile” es el nombre más común para los sistemas que utilizan los ciclos de vida Adaptativos. Así es como se puede definir de verdad “Agile”, en vez de decir “¡Agile es una mentalidad!”
Los “fans” de Agile utilizan el término