Desarrollo Iterativo versus Incremental ... o ¿cuál es la mejor estrategia para pintar la Mona Lisa?

Este post viene motivado por el debate iniciado por Agustín Villena en chileagil@googlegroups.com a fines de mayo de 2013. El debate se titula "Incremental versus Iterativo" y pone como referencia los siguientes posts: Don’t know what I want, but I know how to get it, por Jeff Patton (2008), y Revisiting the Iterative Incremental Mona Lisa, por Steven Thomas (2012). En estos posts, como metáfora del desarrollo de un producto software se utiliza la elaboración del cuadro de la Mona Lisa. Suele ser un tanto engañoso usar metáforas para explicar conceptos de ingeniería de software, pues normalmente encierran siempre algún truco o interpretación forzosa :-). Sin embargo, como la exposición en dichos posts ya estaba dada en términos de dicha metáfora, continuaré con su utilización. A continuación se muestran las ilustraciones de los posts indicados antes. En cada caso la pintura se realiza en varios pasos numerados. Además, en cada ilustración se destaca el nivel de visualización previa del pintor respecto del cuadro que va a pintar.

Figura 1. Proceso Incremental según Jeff Patton 

Figura 2. Proceso Iterativo según Jeff Patton

Figura 3. Proceso Iterativo e Incremental  según Steven Thomas

En enero de 2010 Jeff Sutherland escribió un post replicando el post de Jeff Patton, titulado Iterative versus Incremental Development. En dicho post Jeff Sutherland descalifica la clasificación de Jeff Patton, diciendo que la Figura 1 (Proceso Incremental) simplemente muestra un enfoque "out of step" (alejado de la realidad), sin embargo, no juzga si es o no un proceso incremental :-). En el caso de la Figura 2, dice que NO es un proceso iterativo sino incremental. Jeff Sutherland interpreta que en la Figura 2 hay una intención de conseguir una versión potencialmente entregable del producto en cada paso. Como veremos a continuación esta consideración hace que un proceso se clasifique como incremental, es decir, un proceso puede ser iterativo (organizar el trabajo en iteraciones, llámense éstos sprints o pasos) pero, para que además sea incremental, debe existir la intención de producir una versión potencialmente entregable. En el caso de la Figura 3 de Steven Thomas, si bien presenta una mezcla de las estrategias de la Figura 1 y Figura 2, también es una cuestión de interpretación si en cada paso existe o no la intención de que el resultado que se obtenga en cada iteración sea un incremento potencialmente entregable.

Consecuentemente con lo anterior, en Scrum se establece que el resultado de un sprint (una iteración) es un incremento potencialmente entregable del producto ("potentially releasable product increment"), es decir, una versión que potencialmente podría pasarse a producción. El incremento es la suma de todos los ítems del Backlog completados durante un sprint y todos los sprints anteriores.

Por otra parte, Alistair Cockburn en el apartado de su web titulado Incremental versus Iterative Development proporciona otra perspectiva en cuanto a la definición de Iterativo y de Incremental. Incremental lo plantea como la estrategia que permite mejorar el proceso (desarrollar partes y luego integrarlas) e Iterativo lo plantea como el re-trabajo para mejorar el producto.

Según todo lo anterior, en mi opinión, queda claro que un Proceso Iterativo, apelando a lo básico, es un proceso donde se trabaja con ventanas temporales (llamadas usualmente iteraciones o sprints) en las cuales se lleva a cabo cierto trabajo sobre el producto. Un Proceso Incremental e Iterativo es un proceso en el cual el resultado de cada iteración es un incremento potencialmente entregable del producto. Pero quedaría por responder la pregunta del millón :-) ¿puede un proceso ser Incremental SIN ser Iterativo?. Mi respuesta es afirmativa, y mi argumento sería el siguiente (en la línea de Alistar Cockburn): si el producto se desarrolla en partes que se van integrando en cierto momento con la intención de hacer una entrega, pero sin utilizar iteraciones (o sprints), estaríamos en el caso de un proceso NO iterativo pero SÍ Incremental. Pondría como ejemplo la estrategia del método Kanban, el cual promueve la generación de un buen flujo de trabajo terminado, con entregas continuas pero sin trabajar con sprints (sin estimar ni planificar, y en su lugar centrarse en la priorización continua del trabajo pendiente). A propósito de este ejemplo, aprovecho para destacar que la decisión de un equipo respecto de usar o no sprints suele tomarse a través de una cuestión mal planteada, puesta en términos de la elección entre usar de forma excluyente Scrum o Kanban (lectura recomendada. ¿Kanban o Scrum? ... that is not the question).

Finalmente, en la metáfora de la Mona Lisa se diferencia entre pintarla teniendo una concepción previa del todo (Figura 1), o comenzar con una idea vaga, e ir definiéndola y ajustándola en cada paso (Figuras 2 y 3). En mi opinión este aspecto (el tener o no una idea preconcebida y detallada del resultado) no es extrapolable tan directamente a desarrollo de software. Es ampliamente reconocido que los requisitos suelen cambiar durante el desarrollo, tanto en términos de añadir o quitar requisitos, como en cuanto a modificar los requisitos originales. Con lo cual aunque se haga un esfuerzo importante por definir anticipadamente todos los requisitos, de todas formas se esperan cambios en ellos. Es por esto que, siguiendo la recomendación de uno de los 7 Mudas de Lean Development en cuanto a "no producir con demasiada antelación", los ítems en el Backlog no deberían ser definidos en mayor detalle hasta que no se acerque su implementación. Es decir, en el Backlog, podemos tener ítems con escasa definición o muy grandes (Épicas) que sabemos que necesitarán un trabajo previo antes de su implementación, pero, como asumimos que habrá cambios, no conviene anticipar su preparación hasta cuando sea inminente que se van a implementar. Una excepción a esto se daría cuando el contexto nos obliga a planificar con mayor antelación (por ejemplo, compromisos contractuales poco flexibles), y esto consecuentemente ejerce presión para anticipar una preparación y estimación más detallada.


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com