¿Cuál es la diferencia entre el desarrollo iterativo e incremental?
En mis clases de formación, a menudo noto que los estudiantes confunden el desarrollo iterativo con el incremental (IID). El objetivo de este artículo es proporcionar una comprensión sobre la relación entre el desarrollo incremental e iterativo.
Comenzaré con una comparación entre el enfoque en cascada y el enfoque ágil, utilizando como ejemplo la entrega de una aplicación de pagos. También se incluye un mini seminario web correspondiente sobre estos enfoques. En la segunda parte de este artículo, posicionaré el enfoque en cascada y el ágil en una matriz que muestra la intersección del desarrollo incremental e iterativo, explicando los cuatro cuadrantes de la matriz.
Ágil vs Cascada: El Desarrollo De Una Aplicación De Pagos
El Enfoque En Cascada
Si esta aplicación de ejemplo se desarrolla de acuerdo con el modelo tradicional en cascada, se pueden observar los siguientes pasos en la figura 1.
Desbloquea Gratis
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de líderes visionarios que están desbloqueando herramientas, manuales y conocimientos para prosperar en la era de la IA.
Have an account? Log In
Figura 1: Este diagrama muestra un ciclo de vida típico en cascada, usando como ejemplo la entrega de una aplicación.
Inicio del Proyecto
Todo comienza con un patrocinador del proyecto procedente del departamento de marketing, quien logró liberar los fondos necesarios para esta aplicación. Él suponía que la app mejoraría la retención de clientes y la captación de nuevos clientes. Visualizó tres grupos funcionales principales.
Una vez aprobado el proyecto, se asigna un gestor de proyecto y se conforma un equipo. Tras muchas discusiones y talleres de recopilación de requisitos, se acuerda entregar una app de pagos con 250 funcionalidades. Todas estas funciones se registran en un documento de requisitos de software extenso y detallado, firmado por el patrocinador y el representante del cliente (así como por otros interesados clave).
Fase de Diseño del Proyecto
En el siguiente paso, el equipo de proyecto traduce los requisitos en un diseño para la app. El arquitecto revisa el diseño según los principios de diseño. También comprueba si todos los atributos de datos requeridos están disponibles en el sistema backend.
Ahora han pasado dos meses y el cliente no ha visto nada funcionando aún, solo algunos informes de progreso. Y probablemente estos informes de progreso incluyan algún tipo de informe ‘sandía’, dejando al cliente sin idea de si el proyecto está bien encaminado o no.
Fase de Desarrollo del Proyecto
Desarrollar la app lleva seis meses y, cuando está terminada, se le pide al representante del cliente que envíe personas para la prueba de aceptación del usuario. Durante la prueba, se hace evidente que varias funciones no están operativas.
El equipo de proyecto no entiende por qué. Es exactamente lo que estaba descrito en el documento de requisitos. Esto conduce a muchas discusiones, reprocesos y retrasos, y los clientes no están satisfechos con los resultados. Además, si observamos el resultado final, podríamos notar que muchos de los requisitos desarrollados no son utilizados por el cliente, o los usan muy rara vez.
Pudo haber sido aún peor. Supón que el desarrollo de la app tomó 1,5 años y otro banco lanza una aplicación de pagos cuando vas a mitad de camino. ¿Qué harías en ese momento? ¿Seguirías teniendo un caso de negocio viable para continuar y terminar tu propia app?
Mirando la figura 1, queda claro que con un enfoque en cascada, el alcance y los criterios de calidad subyacentes quedan fijados con una única entrega. Todos los pasos se realizan una vez para el proyecto completo y la gestión se centra en el coste y el tiempo. La entrega de valor al cliente se produce solo después del despliegue completo de la app.
El Enfoque Ágil
Si desarrollamos la app utilizando un enfoque de gestión de proyectos ágil, vemos el siguiente patrón:
- El equipo de desarrollo afirma que puede entregar las dos primeras funciones priorizadas por el product owner en la primera iteración.
- El equipo entrega cada tres semanas (sprint, iteración o timebox) un incremento del producto.
- Tras las primeras entregas o incrementos, el cliente confía en que el proyecto dará frutos. Ya tiene una app funcional y comprende que aún no están todas las funciones, pero las que hay funcionan correctamente.
Al revisar la versión más reciente y las funciones entregadas, mencionan una función completamente nueva. Una que nadie había considerado al inicio del proyecto, pero que podría facilitar mucho la vida del cliente.
Después de cada incremento, los comentarios del cliente generan nuevas capacidades funcionales (que no estaban en la lista original) o ajustes en posibles funciones. El producto se hace cada vez más maduro. Con cada incremento, el cliente recibe una nueva versión y está más satisfecho.
Figura 2: El diagrama muestra el ciclo de desarrollo ágil, usando el mismo ejemplo de la entrega de una aplicación.
Si observamos la figura 2, vemos un flujo constante de entregas dentro de una duración fija y utilizando equipos ágiles permanentes (estos son costes fijos). El alcance y los criterios de calidad subyacentes son flexibles (dinámicos) con entregas pequeñas y frecuentes (estos son los incrementos).
Todos los pasos destinados a entregar una funcionalidad o historia de usuario se realizan repetidamente (lo que lo vuelve iterativo) hasta alcanzar la calidad requerida. El control de la gestión se centra en la entrega de valor al cliente. La entrega de valor al cliente se produce después de cada despliegue de un incremento.
Cascada vs Ágil: Resultados de Entrega
Si analizamos más de cerca los dos productos tanto del enfoque en cascada como del enfoque ágil de desarrollo de software, vemos un producto con 250 funcionalidades y un cliente no tan satisfecho, y un producto con solo 150 funcionalidades y un cliente muy satisfecho (ver figura 3).
Figura 3: Este diagrama compara las diferencias en tiempo, número de funcionalidades y satisfacción del cliente para los enfoques en cascada y ágil.
Y si nos fijamos todavía más en detalle en el producto entregado por el enfoque ágil, solo vemos un subconjunto de 100 funcionalidades de la lista original y 50 funcionalidades que son nuevas o ajustadas. Esto está en línea con algunos principios importantes del Manifiesto Ágil, incluyendo:
- Simplicidad, que es el arte de maximizar la cantidad de trabajo no realizado: sólo 150 funcionalidades en lugar de 250 funcionalidades
- Dar la bienvenida a los requisitos cambiantes, incluso en etapas tardías del desarrollo: adaptarse a los comentarios del cliente después de cada iteración e incremento
Los procesos de desarrollo ágil aprovechan el cambio como una ventaja competitiva para el cliente (se entregaron 50 funcionalidades nuevas o ajustadas). Y como resultado, el cliente está muy satisfecho. La máxima prioridad del equipo es satisfacer al cliente a través de la entrega temprana y continua de sistemas de software valiosos.
Mini Webinar: Cascada vs Entrega Ágil
Aquí tienes un breve seminario web con más información sobre las diferencias entre la entrega en cascada y la entrega ágil.
Diferencias entre desarrollo iterativo e incremental
Ahora que he cubierto las diferencias entre un enfoque en cascada y uno ágil usando el ejemplo de crear una aplicación de pagos, voy a situar cascada y ágil en una matriz comparando el desarrollo iterativo e incremental.
Como último paso, profundizaré en el producto mínimo viable (MVP) y el producto mínimo comercializable (MMP), y mostraré dónde encajan en los diferentes enfoques y un mapa de historias. También he incluido un mini seminario web correspondiente.
Matriz de desarrollo iterativo e incremental
Como mencioné, he notado que los estudiantes suelen confundir iterativo e incremental. En la figura 4, puedes encontrar cuatro cuadrantes como resultado de una línea horizontal que representa si hay incremental o no y una línea vertical cruzada que representa si es iterativo o no. Mira este video de YouTube para una versión muy simple de esta figura.
Figura 4: Esta matriz muestra diferentes enfoques de desarrollo y si los miembros del equipo que siguen estos enfoques necesitan iterar y/o trabajar en incrementos.
Cuadrante inferior izquierdo
En la esquina inferior izquierda, vemos el enfoque en el que no hay iteraciones ni incrementos. Este es el enfoque en cascada. Todas las actividades (diseño, análisis, construcción, prueba y despliegue) se realizan una vez para todo el proyecto.
En este caso, observamos una única entrega del producto final basada en un alcance fijo. El valor para el cliente solo se logra después de la entrega del producto final. Uno de los objetivos clave en este enfoque es gestionar el coste.
Cuadrante inferior derecho
En el cuadrante inferior derecho, vemos un enfoque incremental sin iteraciones. Se trata de una entrega escalonada o incremental de partes más pequeñas del producto. Todas las actividades de una etapa determinada (diseño, análisis, construcción, prueba y despliegue) se realizan una sola vez.
Dentro de una etapa determinada, el alcance es fijo, pero el producto total se basa en un alcance más dinámico o flexible. Se puede lograr valor para el cliente después de cada entrega del producto. Uno de los objetivos clave en este enfoque es la velocidad de entrega.
Cuadrante Superior Izquierdo
En el cuadrante superior izquierdo, vemos un enfoque en espiral o iterativo sin incrementos. Se trata de una única entrega donde el producto final se crea a través de varias iteraciones. Un buen ejemplo de este enfoque es el design thinking. En el gráfico se observa una secuencia de actividades como enmarcar, analizar, generar ideas, realizar y reflexionar.
Esta secuencia se repetirá o iterará varias veces, y con cada iteración uno se acerca más al producto final, correcto o requerido. En muchos casos, este producto final es un prototipo o modelo. En este enfoque en espiral tenemos un alcance dinámico o flexible. El valor para el cliente solo se puede conseguir tras la entrega del producto final. Uno de los objetivos clave en este enfoque es la corrección de la solución.
Cuadrante Superior Derecho
En el cuadrante superior derecho, vemos el enfoque ágil que utiliza incrementos y un método iterativo. Scrum es un buen ejemplo de este enfoque.
Al final de cada incremento, a menudo llamado sprint o timebox, se entrega una parte del producto. Este incremento es el resultado de muchas iteraciones para desarrollar piezas pequeñas pero correctas, frecuentemente llamadas historias de usuario o elementos del backlog, del producto. El proyecto iterativo final se entregará pieza por pieza.
En este enfoque ágil tenemos un alcance dinámico o flexible. El valor para el cliente se puede conseguir después de cada entrega. Uno de los objetivos clave de este enfoque es el valor al cliente mediante entregas frecuentes y retroalimentación del usuario.
¿MVP o MMP?
En la figura 4, también puedes encontrar los acrónimos MVP y MMP. MVP significa producto mínimo viable y es una versión de un nuevo producto o servicio que permite al equipo recopilar la mayor cantidad de aprendizaje posible sobre los clientes y obtener validación con el menor esfuerzo. El MVP del servicio Dropbox fue una película sencilla. Esto significa que la P en MVP podría ser un producto completamente distinto al que termina siendo el producto final.
Un ejemplo que ilustra MVP y MMP
Suele utilizar el siguiente ejemplo sobre un nuevo producto financiero. Un gerente de ventas entusiasta tiene una gran idea sobre un producto financiero nuevo. Piensa que pueden vender al menos 100,000 de estos productos.
Junto con algunos expertos financieros, diseñan el producto en un par de meses. Se asigna un equipo de desarrollo, y les toma 4 meses desarrollar el producto. Paralelamente, se desarrollan los folletos comerciales y el producto se lanza en un gran evento.
Desafortunadamente, solo unas pocas personas compran el producto. Si seguimos el enfoque MVP, podríamos partir de la hipótesis de que el 10% de sus usuarios web están interesados en este producto. Entonces desarrollaríamos un MVP para comprobar esta hipótesis.
En este caso, el MVP podría ser un botón simple en la página de inicio. Si se hace clic, se muestra una pantalla con un mensaje sobre el nuevo producto y la opción de agregar tu dirección de correo electrónico si estás interesado. Supón que menos del 1% de los visitantes presionó el botón: el producto no se desarrollaría y la empresa ahorraría muchos recursos valiosos.
Si miramos más de cerca la figura 4, vemos el uso potencial de los MVP en todos los cuadrantes. Cuando se utiliza el enfoque en cascada, se podría crear un MVP en la primera fase de diseño de software para comprobar si el proyecto tiene justificación comercial.
Lo mismo se puede hacer en la primera fase del primer incremento al seguir una entrega escalonada. En algunos casos, el resultado de tu enfoque de design thinking podría ser un MVP. El MVP también podría ser útil al principio de un enfoque ágil.
Mucha gente ve el primer producto entregado al final de una entrega escalonada como el MVP. Esto podría darse, pero la mayoría de las veces, no es un MVP sino un MMP. MMP o producto mínimo comercializable es el producto más pequeño que puede generar valor a tu cliente.
¿Cómo se ve una entrega ágil?
Ahora que está claro que los modelos incrementales y los modelos iterativos no son lo mismo y entendemos el uso del MVP y el MMP, podemos profundizar en cómo se ven las entregas incrementales e iterativas.
Probablemente hayas visto el famoso ejemplo de Jeff Patton sobre la Mona Lisa, donde el cuadro se crea pieza por pieza (entrega escalonada). Otra forma de hacerlo es empezar con el primer incremento, en el que solo se crea un boceto, y con cada nueva iteración se añaden más detalles, hasta que finalmente se obtiene la pintura final (entrega incremental e iterativa o ágil).
En la primera situación ya debes tener una idea detallada del producto final y, en la segunda, solo necesitas un esquema a alto nivel, ya que los cambios son mucho más fáciles de realizar. Si observamos la figura 5, vemos un mapa de historias para un nuevo producto llamado ABC.
Figura 5: Un ejemplo de mapa de historias para un producto específico.
El propietario del producto ideó siete funcionalidades para este producto. Las primeras cuatro funcionalidades son imprescindibles. La funcionalidad 5 y la 6 son recomendables y la última es opcional. Muchos llamarían a esto priorización MoSCoW (imprescindibles, recomendables, opcionales y no se tendrán).
Cada funcionalidad en sí puede dividirse en partes más pequeñas. En la figura se observan funcionalidades o historias de usuario con niveles de imprescindible, recomendable u opcional. Una funcionalidad puede ser imprescindible, pero eso no significa que todas las historias de usuario subyacentes también lo sean. O una funcionalidad puede ser recomendable, pero si implementas esa funcionalidad, algunas historias de usuario son imprescindibles y otras son recomendables u opcionales.
Para implementar este producto ABC, se observan cinco incrementos o entregas. El primero es el producto comercializable mínimo. Este MMP consta de las dos primeras historias de usuario imprescindibles de la funcionalidad 1, y la primera historia de usuario imprescindible de la funcionalidad 2 y 3.
La entrega 2 contiene las siguientes dos historias de usuario imprescindibles de las funcionalidades 1, 2 y 3 (desarrollo iterativo). El desarrollo del producto continúa implementando las siguientes entregas. Con cada entrega el valor para el cliente aumenta.
Después de la entrega 5, el propietario del producto deja de implementar historias de usuario. La retroalimentación del cliente le mostró que el producto ABC es ‘adecuado para su propósito’ y sigue el principio de simplicidad del manifiesto Ágil, por lo que detiene el desarrollo adicional.
Miniwebinar: Desarrollo Iterativo e Incremental
Aquí tienes un seminario web en profundidad sobre el desarrollo de software iterativo e incremental.
Reflexiones finales
¿Tiene tu equipo de desarrollo de software claridad sobre el desarrollo iterativo e incremental? ¿Cómo lo estás aplicando en tus metodologías ágiles o en cascada?
¡Cuéntanos en los comentarios, o únete a nuestro programa de membresía DPM y debate con otros miembros en nuestro foro exclusivo!
