¿Por qué iterativo e incremental en productos digitales?

En un entorno tan cambiante como el actual, las organizaciones necesitan disponer de una visión más amplia de lo que sucede a su alrededor. Los cambios en tecnología evolucionan rápidamente y ello afecta directamente en el ecosistema de los mercados y su exposición en el medio.

Se requiere, por tanto, que la estrategia de negocio pueda adaptarse rápidamente sobre el entorno volátil en el que vivimos. Es volátil, hay incertidumbre y no es predictivo. Nos obliga a disponer de la máxima información más rápidamente, para anticiparnos y poder formular estrategias acordes al ritmo cardíaco del mercado. Un pronóstico constante bajo un proceso empírico.

Ello implica que, si queremos lanzar un producto al mercado en 12 meses, no parece tener mucho sentido irnos a un SDLC Waterfall, ya que el tiempo que transcurre desde la necesidad planteada hasta la entrega puede generar varios problemas:

• Alguno o parte de los requisitos no son correctos y desafortunadamente no te das cuenta hasta la fecha de la entrega, pasados los 12 meses.
• Puede que el negocio ya no esté interesado en los “features” implementados y tengamos los ya conocidos “Change Requests”, lo cual incrementa la duración del proyecto y los costes totales; ya que, después de 12 meses, puede ocurrir que hay que tirar a la basura parte del desarrollo ya finalizado.
• ¿Y si los usuarios no tienen claro el objetivo final? Siendo un SDLC orientado a documentación, quizás no sea la mejor opción para arrancar.

Una alternativa para mitigar los riesgos detectados es iterar por entregas, por ejemplo, 4 iteraciones de 3 meses. Es decir, trabajar en versiones completas en cada ciclo en lugar de trabajar las partes en su máximo detalle. Ello nos acerca al punto de obtener información sobre el trabajo realizado en menos tiempo y evaluar posibles cambios para la siguiente iteración. El objetivo es aquel definido a nivel global y nos permite evaluar el avance con respecto a la totalidad del proyecto.

Pero... dijimos entorno cambiante, ¿no? No parece que 3 meses pueda ser lo suficientemente adaptativo para nosotros. Vamos a revisarlo.

Para ello, vamos a aumentar la frecuencia de las iteraciones y, además, vamos a ajustar la visión global del proyecto a objetivos más cortos, de tal forma, que iremos realizando entregas acordes a esos objetivos y que se irán moldeando a lo largo del tiempo. En otras palabras, iteramos e incrementamos con una periodicidad mucho más corta y elegimos en qué partes aportamos qué nivel de detalle.

Para adaptarse rápidamente al mercado, la colaboración entre las personas es esencial para identificar aquellas funcionalidades que permitan potenciar el posible valor añadido y, en consecuencia, la capacidad para monetizar una característica del producto. Es decir, iteramos e incrementamos con valor. Pero, ¿esto qué significa?

• Iteramos para buscar una mejor solución a través del feedback de los usuarios, no solo para buscar un cambio o modular la frecuencia con la que sucede. Con un desarrollo iterativo, construimos añadiendo nueva funcionalidad incrementalmente e iteramos para mejorar, cambiar o suprimir funcionalidad existente.
• Añadimos software incrementalmente para gradualmente construir funcionalidad. No obtenemos ROI hasta que el usuario empieza a consumir lo que hemos construido. Por tanto, el valor de negocio hasta ese momento es una estimación, al igual que lo es el desarrollo del software.

Una mirada hacia el pasado

Resulta espeluznante observar cómo hemos heredado formas de trabajo ineficientes y que aún perduran en la actualidad. Lo sorprendente de todo es que un ciclo iterativo e incremental no es nada nuevo y lleva alrededor de 50 años dando vueltas. ¿Te lo podías imaginar? Vamos a compartir algunos fragmentos interesantes sobre ello.

En el año 1940, Edward Deming fomentó la presentación del método PDCA (comúnmente conocido como ciclo Deming), para la mejora en los ciclos de calidad y la mejora continua en las empresas.

En el 1950, el Desarrollo Iterativo e Incremental (IID) se aplicó en la fabricación del cohete X15 y su éxito se consideró una de las mejores contribuciones a pesar de no tratarse de un proyecto de software. Tanto fue así, que algunos miembros de la NASA aplicaron IID para el proyecto Mercury en el 1960.

Las iteraciones en el proyecto Mercury eran demasiado cortas, de medio día. El equipo de desarrollo realizaba la revisión técnica de los cambios y aplicaba técnicas de Extreme Programming para la definición de los tests antes de cada micro-incremento.

El proyecto Mercury se convierte en la semilla para la división de IBM que trabajaba directamente con el Gobierno federal de los Estados Unidos, principalmente en proyectos para el Departamento de Defensa y la Agencia de Seguridad Nacional.

En el año 1970, Winston Royce sugirió que un proyecto de 30 meses de duración, debería tener un piloto listo a los 10 meses, ya que existen elementos y factores desconocidos como para que sean asumidos al final. Obviamente y no considerándolo plenamente un proceso IID, vemos alguna pista de retroalimentación y adaptación en el proceso.

Sin embargo, el mismo año, IBM FSD (Federal Security División) arranca el proyecto IID denominado LAMPS y se definen 45 iteraciones durante 4 años. Es el ejemplo más cercano que tenemos con un rango iterativo comprendido entre 1 y 6 semanas. El proyecto fue todo un éxito, tanto en entregas como en presupuesto.

Entre 1975-1980, FSD incorpora el concepto de “ingeniería de integración”, el cual hace mención a la integración de todos los componentes de software al final de cada iteración. A partir de este momento, el modelo IID suscita un gran interés en las divisiones comerciales de IBM, clientes y competidores.

A finales de los 80, el departamento de defensa experimenta significantes fallos en la adquisición de software basado en un estricto método, basado en documentación y un único ciclo como es el modelo en cascada, llegando a las siguientes conclusiones: "de un total de $37 billones, el 75% de los proyectos fueron fallidos o nunca usados. Solo el 2% fue usado sin cambios o modificaciones posteriores."

En 2001, 17 expertos en la materia se reúnen para debatir en profundidad los principios del ciclo IID y dando lugar al Agile Manifesto que conocemos actualmente.

Conclusiones

Las compañias están actualmente orientadas a un enfoque exclusivamente incremental y, en muchos casos, en lugar de continuar con su trayectoria clásica y permanecer transparentes a ello, el efecto llamada de marketing en el prisma Agile, ha producido que muchas empresas quieran estar a la moda e invertir mucho dinero en su transformación interna o como dicen en los medios y redes sociales: transformación digital.

La realidad es que, probablemente, la inversión económica realizada les posicione en un stack tecnológico aceptable; sin embargo, la cultura digital aún requiere de tiempo “extra” para entender el desarrollo de software iterativo e incremental.

Se trata de una conceptualización y un paradigma del producto totalmente diferente, donde se colabora constantemente con el cliente proporcionando ideas y puntos de vista divergentes, y se experimenta dando lugar a prototipos convergentes. Medimos, evaluamos y nos adaptamos a los usuarios y al mercado.

Ser iterativo e incremental implica aceptar que no existe una única solución, que los errores están permitidos y el proceso empírico nos obliga a medir y definir nuevamente soluciones. Ser iterativo e incremental nos obliga a entender qué parte puede aportar mayor o menor valor y adaptarse mucho mejor a las necesidades reales del usuario.

Brindémosle paciencia al entorno, ya que es cuestión de tiempo que las empresas de tecnología se vayan acercando poco a poco al modelo experimental.