En primer lugar una breve explicación de lo que es el desarrollo iterativo: construir un software dividiendo el trabajo en fases o iteraciones, realizando en cada una de ellas lo que sería el ciclo completo del desarrollo software, esto es analizar, diseñar, implementar, probar y entregar, todo ello con su correspondiente planificación.
Cada iteración o vuelta de tuerca puede tener una duración diferente a las demás, en base al objetivo que se perfile y el alcance de los trabajos a desarrollar, pero (salvo la primera) siempre parten de la anterior y finalizan con un tangible que se puede validar.
Las ventajas principales del modelo iterativo es poder practicar un divide y vencerás pues se descomponen actividades en ciclos de iteración, haciendo más sencilla su ejecución, al tiempo que se maximizan las validaciones internas (testing) y las externas (las entregas parciales al cliente). Este método evolucionó hacia lo que hoy son metodologías de desarrollo ágil como Scrum.
Analizar, diseñar, implementar, probar y entregar
Pese a que Scrum tiene muchas cosas buenas, el dejar a la fortuna (o al hacer del equipo) el que los sprints sean autocontenidos, con resultado tangible, es un grave problema que en la mayoría de los proyectos aflora en la forma de incapacidad de cerrar funciones o estabilizar sistemas. Por decirlo de alguna forma, el objetivo del
desarrollo iterativo es que cada iteración o ciclo de desarrollo (de la duración que sea) finalice y pueda ser un producto, intermedio si lo queremos ver así, pero un producto: cada iteración es como un episodio de Black Mirror. Sin embargo, cuando trabajamos en Scrum sin el objetivo y la obligación de tangibilizar un producto final en cada sprint, lo que tenemos son episodios de The Walking Dead, en los que hay que esperar al siguiente capítulo para ver qué pasa.
Por supuesto, se puede implementar un desarrollo iterativo en Scrum, no se trata de cosas opuestas ni excluyentes: la diferencia está en cómo se construyen las funcionalidades, no en cómo se controlan las tareas y asignaciones derivadas de esa construcción. Lo ideal desde mi punto de vista es encajar iteraciones dentro de
los sprints.
Aunque parezca un contrasentido, estamos volviendo a las formas de trabajo (que no metodologías de organización) más antiguas. Se tiende a seguir un modelo en cascada, tan defenestrado en la década del 2000 por la demostrada ineficacia para incorporar ágilmente cambios y ajustes: tendemos ahora a organizar el trabajo entre diferentes perfiles (Front / Back) para lo cual es necesario hacer los trabajos en secuencia, analizando y diseñando todo para poder repartir las tareas, generar JIRAs y asignarlos en el tablero esperando que al final del túnel nos encontremos. Y esto es complicado. La ausencia de una estrategia de construcción del software puede llevarnos a lo que se denomina un Wagile, Waterscrum o Scrummerfall.
Por el contrario, el modelo de construcción iterativo, que insisto puede asentarse perfectamente en Scrum, permite empezar a trabajar en pequeñas piezas, simplificando la necesidad de analizar o diseñar en detalle todo un desarrollo, sea un módulo funcional o simplemente una pantalla. El ejemplo que siempre pongo es una pantalla de listado con sus filtros, ordenaciones, estilos de fila, paginación y la típica exportación a Excel: podemos empezar a analizar las tareas necesarias para construir todo, separar las mismas para que dos personas lo implementen (Front & Back) y esperar a que terminen de implementarlo rezando para no haber olvidado nada y que se entiendan entre ellos. Luego, quizá tras dos semanas, al finalizar el sprint, esté todo hecho y funcionando. Más aún, que esa página la pudiésemos enseñar al cliente en una demo, y diera el OK a la misma. Pero esto nunca pasa, es como capturar un unicornio.
Iterar sobre el objeto hasta convertirlo en el objetivo
Si aplicamos algunas pautas de descomposición de esa tarea que nos llevaría dos semanas y la dividimos en tres iteraciones, aún con una sobrecarga de tiempos que nos lleve a tres semanas de trabajo, quizá podamos asegurar un mejor resultado:
- Iteración 1. Hagamos solo el listado, algo fácil: sin estilos, sin filtros, sin ordenaciones ni nada. Una página y un mapper sencillo. Riesgos minimizados, resultado asegurado en la primera iteración que, por sencilla
puede estar muy rápido. Es funcional, se puede probar y compartir con el departamento de QA y el cliente. - Iteración 2. Con un OK puesto a nuestra primera iteración, vamos a por la segunda: acometemos los filtros y las búsqueda, y quizá la paginación. Se trata de modificar lo que ya tenemos funcionando y hemos enseñado. De nuevo, al terminar la iteración, se puede probar parcialmente y enseñar al cliente: aquí seguro
que pide uno o dos filtros más o algún ajuste, pero ya lo tenemos. - Iteración 3. Incorporamos los ajustes del cliente y los bugs encontrados y tratamos de cerrar la funcionalidad, incluyendo la exportación a Excel. Contamos con el OK del cliente a las columnas, los formatos y los filtros, por lo que exportar a Excel algo que ya tenemos construido y validado es sencillo. Maximizamos el éxito y la productividad de nuestro trabajo al basarnos en trabajos previamente verificados.
Iterar es arte, en el sentido de que reproduce el proceso natural creativo de cualquier disciplina plástica, por ejemplo pintura o escultura. Lo natural para desvelar y validar los trabajos que hacemos, muchas veces más cercanos a un cuadro del museo del Prado que a un plano de construcción, es iterar sobre el objeto hasta convertirlo en el objetivo. Sin embargo, lo que hacemos cuando simplemente trabajamos en modo incremental
(que sería dividir tareas en Scrum e ir implementando una a una) tiene el inconveniente de no poder ver la obra hasta que está totalmente terminada.
Insisto en que Scrum es una muy buena forma de organizar el trabajo y las tareas, pero es muy importante poder definir la forma en la que construimos de manera incremental, dotando de esa iteración que nos ayudará mucho a tener control y dominio de los proyectos.
