Desarrollo iterativo e incremental

Tiempo aproximado: 9 min.

Preparando el artículo que he prometido sobre cómo escalar Agile sin frameworks, me he dado cuenta de que nunca he descrito qué entiendo por desarrollo iterativo e incremental de producto. Es curioso, porque es un concepto que usamos muchísimo y sobre el que hay muy poco escrito en español.

Un poco de historia

Empecemos por ver de dónde surge este concepto, porque no aparece (explícitamente) en el Agile Manifesto. La mejor reseña histórica que he podido encontrar es la que hacen Craig Larman y Victor Basili en su artículo «Iterative and Incremental Development: A Brief History» publicado en la revista Computer en Junio de 2003.

Según este artículo, una de las primeras referencias al desarrollo incremental aparece en la documentación de un proyecto de investigación y desarrollo de la NASA para el avión supersónico X-15, donde dice: «Una importante contribución al éxito del X-15 en el largo plazo fue su énfasis en el desarrollo incremental y su uso en la investigación científica y técnica altamente especializadas». Si bien no se trataba de desarrollar software, los aprendizajes se llevaron al desarrollo del software del programa espacial, en particular al proyecto Mercury (a finales de los 50). Debo reconocer que me sorprendió (agradablemente) comprobar que hacían iteraciones de medio día. Sí, de medio día. Incluso hacían TDD. Bueno, test-first, que no es lo mismo. Seguramente te sonará el nombre de Jerry Weinberg (si no, ya estás tardando en leer todo lo que puedas de él). Pues Jerry estuvo allí y escribía:

Todos nosotros, en lo que yo puedo recordar, pensábamos que desarrollar en cascada un proyecto grande era bastante estúpido, o al menos ignorante de las realidades… Yo creo que la descripción de «waterfall» nos hizo darnos cuenta de que estábamos haciendo otra cosa, algo que no tenía nombre excepto por lo de «desarrollo de software».

Gerald M. Weinberg

Uno de los primeros grandes proyectos que se desarrollaron con una planificación iterativa e incremental fue el sistema de mando y control de un submarino, allá por los 70. Con una fecha de entrega marcada y una penalización muy elevada por no entregar a tiempo, planificaron 4 iteraciones de 6 meses cada una y fueron incorporando el aprendizaje obtenido en una iteración a la planificación de la siguiente. Otros grandes proyectos similares comenzaron a desarrollarse de esta manera. En la primera iteración construían algo que funcionaba y permitía mejorar las siguientes versiones, hasta entregar en la fecha acordada la mejor versión del producto. Y claro, le cogieron el gusto y comenzaron a planificar con iteraciones cada vez más cortas. Así, el primero que está documentado que usó iteraciones de un mes fue el proyecto LAMPS (para un helicóptero del ejército). Personajes como Barry Boehm (sí, el del famoso «modelo en espiral») estuvieron involucrados en algunos de estos proyectos. Otra figura de la época, Harlan Mills, afirmó que «todas y cada una de las entregas se hicieron cumpliendo fechas y presupuesto».

Creo que la mejor definición que podemos encontrar es ésta (escrita por uno de los autores del artículo en 1975):

La idea fundamental detrás de la mejora iterativa es desarrollar un sistema de software incrementalmente, permitiendo al desarrollador aprovechar lo que se va aprendiendo durante el desarrollo de las versiones tempranas, incrementales y entregables del sistema. El aprendizaje viene tanto del desarrollo como del uso del sistema, donde sea posible. Los pasos clave en el proceso consisten en empezar con una implementación sencilla de un subconjunto de los requisitos del software y mejorar iterativamente la evolución secuencial de versiones hasta que el sistema está implementado. En cada iteración, se hacen modificaciones en el diseño a la misma vez que añadimos nuevas funcionalidades.

Victor Basili & Joe Turner

(Perdón si alguna traducción no es del todo acertada. He tenido que hacer algún giro que seguramente no es muy ortodoxo o incluso correcto. En el artículo arriba mencionado está el texto original).

El anteriormente citado Harlan Mills escribió:

El desarrollo de software se debería hacer incrementalmente, en etapas con la participación del usuario y replanificación continuas, y con una programación ajustada al coste dentro de cada etapa.

Harlan Mills

Cada vez se parece esto más a lo que leemos en el Agile Manifesto, ¿verdad?

Pero es más, Mills añadía:

El peligro en la secuencia [de fases en un enfoque en cascada] es que el proyecto pase de ser grande a grandioso, y que exceda nuestra capacidad intelectual humana para gestionar y controlar.

y se preguntaba:

… por qué las empresas toleran las frustraciones y dificultades de este tipo de desarrollo [en cascada]?

Ojo, que esto fue escrito a finales de los 70. ¡¡Hace 50 años!!

Otros autores fundamentales para la divulgación del desarrollo iterativo e incremental fueron , que comenzó a mencionar el desarrollo «evolutivo», o el ya mencionado Jerry Weinberg, que escribió sobre la «programación adaptativa». Pero no es hasta febrero de 1988 que el Departamento de Defensa de los EEUU no reconoce que el estándar al que obligaba a todos sus contratos era la causa de su altísima tasa de fracasos y publica la revisión DoD-Std-2167A en la que abre el camino para el desarrollo de proyectos de software con una planificación iterativa e incremental. Ojo, que sólo lo abre, porque no es hasta diciembre de 1994 que se publica el Mil-Std-498 en el que se retira el sesgo hacia el modelo en cascada:

If a system is developed in multiple builds, its requirements may not be fully defined until the final build…

If a system is designed in multiple builds, its design may not be fully defined until the final build.

Más claro, el agua.

De ahí a que comiencen a proliferar los métodos ligeros de desarrollo de software como XP, Scrum, Crystal Clear, etc. De ahí al Agile Manifesto hay sólo un paso.

Pero estamos en 2019 y todavía hay mucha gente que planifica los proyectos pensando que lo más eficaz es emplear un parte significativa del tiempo a decidir qué hay que hacer, luego encargar a otros que lo hagan, esperar a que pase el tiempo acordado y comprobar que se ha hecho lo que se dijo que había que hacer, y finalmente ponerlo a disposición de los usuarios.

Así que voy a tratar de explicar muy brevemente qué es esto del desarrollo iterativo e incremental, para que se lo puedas dar a cualquiera (sea desarrollador de software o no) y que lo entienda. Es posible que de esta manera podamos reducir esas frustraciones y dificultades a las que se refería Mills hace ya tanto tiempo.

Desarrollo incremental

explica muy bien en su artículo «Don’t know what I want, but I know how to get it» (No sé lo que quiero, pero sé cómo obtenerlo) cuál es la diferencia entre desarrollo iterativo y desarrollo incremental. Y para ello se apoya en estas imágenes de la Mona Lisa.

Incremental development» by Jeff Patton (oil and bits)

Un desarrollo incremental es aquel en el que, con cada entrega, tenemos acabada una pieza más del sistema, pero éste no lo podemos considerar acabado hasta la entrega de la última pieza.

Por ejemplo, podríamos planificar algo así como: primero la base de datos, luego la lógica de negocio y finalmente «las pantallas». Esto tiene el problema de que no hemos pensado en el usuario a la hora de planificar nuestras entregas. Con cada incremento, el usuario no puede hacer nada nuevo. No hay nuevas funcionalidades que utilizar por lo que, desde su punto de vista, no habría mucha diferencia entre un desarrollo incremental y un «waterfall» (con una única entrega al final del proyecto).

Pero también podríamos planificar primero la gestión de almacén, luego la gestión de la tienda y finalmente la gestión de facturas. Es a este enfoque al que se refiere Patton en su dibujo y es al que se refieren también todos los autores al hablar de desarrollo incremental. El usuario, cuando tiene el módulo de gestión de almacén ya puede empezar a gestionar el almacén. Si quiere gestionar la tienda tendrá que esperar, pero al menos ya puede ir gestionando el almacén.

«Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente». ¿Te acuerdas, verdad?

En ambos casos, el feedback temprano sólo lo podemos obtener de un sistema incompleto, por lo que no nos ayudará demasiado a entender cuáles son las verdaderas necesidades de los usuarios, y lo que es más grave, si el feedback se corresponde con una pieza ya entregada, modificarla nos haría incurrir en un sobrecoste en la planificación. Por eso hablamos de historias de usuario, es decir, pequeños incrementos de funcionalidad que permiten al usuario contarle a alguien que ahora puede hacer algo nuevo con nuestro sistema.

Desarrollo iterativo

«Iterative development» by Jeff Patton (oil and bits)

Un desarrollo iterativo es aquel en el que, con cada entrega, esperamos el feedback del usuario para decidir los siguientes pasos a seguir.

Por ejemplo, podríamos entregar un prototipo en papel para validar las primeras hipótesis sobre cómo quiere el usuario que le mostremos la información, luego, a partir del feedback recibido, podemos desarrollar un prototipo con el que empezar a validar hipótesis técnicas (integración con fuentes de datos, etc) y así hasta tener la aplicación completada.

Claro, al pedir feedback, bien pudiera ser que tuviéramos que deshacer parte del trabajo hecho. Por eso tratamos de emplear técnicas que nos permitan eliminar incertidumbre al menor coste posible (como los prototipos) y hablamos de conceptos como el MVP o el test A/B mediante los cuales podemos incorporar el feedback lo más rápida y flexible posible.

Desarrollo iterativo e incremental

En su artículo «Revisiting the Iterative Incremental Mona Lisa», Steven Thomas comparte una excelente explicación gráfica de qué entendemos por iterativo e incremental, basándose en las imágenes anteriores de Jeff Patton.

«Iterative Incremental Development» by Steven Thomas (oil and bits)

Un desarrollo iterativo e incremental es aquel en el que, con cada entrega, añadimos funcionalidades completamente nuevas (incremental) pero cada incremento también incluye mejoras sobre funcionalidades que ya existían (iterativo).

Ya hemos visto las ventajas:

  • Podemos adaptar nuestros planes según lo que vayamos aprendiendo, evitando así hacer cosas que no habría que hacer.
  • Podemos entregar valor al usuario antes de acabar todo el desarrollo.

Pero también tenemos inconvenientes:

  • Pudiera ser que, en función del feedback recibido, tuviéramos que deshacer algo ya construido, con el consiguiente sobrecoste.
  • Además, es crucial automatizar las pruebas, o de lo contrario corremos el riesgo de estar estropeando, sin darnos cuenta, funcionalidades ya entregadas.
  • Y como queremos entregar incrementos de software frecuentemente, o automatizamos también nuestro proceso para poner el software funcionando a disposición de los usuarios, o vamos a incurrir en otro importante sobrecoste (no sólo en tiempo, sino también en errores provocados por las personas, que no somos tan buenos como las máquinas para hacer tareas repetitivas).

Un desarrollo Ágil de producto implica hacer a la vez el desarrollo iterativo e incremental.

Otra metáfora gráfica

Henrik Kniberg describe también muy bien el desarrollo iterativo e incremental con esta otra metáfora gráfica. Como es muy conocida, creo que merece la pena mencionarla.

«Iterative & incremental development, horizontal vs vertical» by Henrik Kniberg

Creo que es autoexplicativa, así que no abundaré en ella.

User Story Mapping

Sé que a veces quedarse en la explicación hasta aquí resulta un poco difícil porque no sabemos bien cómo hacer este tipo de planificaciones. Yo te recomiendo la técnica del User Story Mapping. Te puede resultar muy útil a la hora de planificar un desarrollo iterativo e incremental porque sirve para tomar decisiones y provocar muchas conversaciones que posteriormente serán útiles durante la construcción. Además, a lo largo del resto del proyecto también es muy útil para no perder el horizonte sobre lo que se pretende construir.

Si no lo has usado nunca, te animo a probarlo, por ejemplo para finalizar una Agile Inception, porque ayuda a salir con la sensación de que tenemos un plan, que siempre tranquiliza a mucha gente, aunque éste se vaya a modificar en el futuro con el feedback recogido tras cada entrega.


Espero que te resulte útil este artículo. Compártelo todo lo que quieras y, si en algún momento lo usas y quieres compartir tu experiencia, recuerda que tienes un espacio para los comentarios ahí abajo. 🙂

LA FOTO: Imagen de Pexels en Pixabay