No andaré con rodeos, este artículo no es para decirte que agile es mejor que cascada el 100% de las veces. No existe un solo ciclo de vida que sea efectivo para todos los productos y todos los desarrollos de software; si algo te quedarás al leer este artículo, que sea eso.

El ciclo de vida que se usará para hacer y mantener un producto de software es una decisión importante que hace el equipo. El ciclo elegido les facilitará o complicará lograr objetivos, así que hay que elegirlo con cuidado y evaluar continuamente los resultados que obtenemos.

¿Qué hay que tomar en cuenta para tomar esta decisión? Primero, diagnosticar si en nuestra forma de pensar están los errores comunes en el entendimiento del ciclo de vida; después, evaluar las características del trabajo. De ambas cosas te hablo a continuación.

Errores comunes en el entendimiento del ciclo de vida

Estos son algunos aspectos y conceptos que tienen equipo y organizaciones de software, debidos a una difusión de mitos o una carencia de base teórica.

Error 1: existen dos clases de ciclos de vida, “el viejo” y “el nuevo”

Esta es una distinción que suelen mencionarme en varios lugares, más o menos con estas palabras: “nosotros no seguimos el método tradicional, sino que usamos formas modernas”.

Algunas personas piensan que el ciclo de vida “evolucionó” de un método inicial y fue “mejorándose” con el tiempo. Es decir, que existe un método “viejo” (que ya no hay que usar, porque está viejo) y la versión mejorada, que es la actual. Fuera de toda realidad.

Los ciclos de vida son diferentes entre sí. Cada uno es un modelo diferente, con actividades y objetivos diferentes. Algunos compartirán características, pero no son una “evolución” entre ellos. Por lo tanto, cada método puede ser usado sin importar cuándo se definió, pero hay que tener en cuenta si nos brinda los objetivos que buscamos.

Error 2: Siempre usar el mismo ciclo de vida

Algunos equipos tienen una forma de trabajo rígida. Tomó mucho tiempo definirla, así que la cuidan con recelo y no permiten desviaciones o modificaciones. Ocurre frecuentemente en empresas con procesos certificados. Su forma de abordar cada proyecto y desarrollo es la misma.

Esto no sería problema si se dedicaran a hacer el mismo producto. Sin embargo, suelen aceptar proyectos de características muy diferentes entre sí y los desarrollan siempre bajo la misma forma de trabajo y ciclo de vida.

Ya está definido así y no se puede cambiar, es lo que dicen.

Error 3: Empeñarse en usar un ciclo de vida que no está dando buenos resultados

Los motivos que hacen a los equipos tomar esta decisión, son similares a los de usar siempre el mismo ciclo: hacer cambios en la forma de trabajo es difícil.

En el momento que aparecen los indicadores de que los resultados no son los esperados es que se debe revisar la forma de trabajo y el ciclo de vida elegido. Estos indicadores son: retrasos, problemas de calidad, insatisfacción del usuario y tiempos largos de entrega.

Muchos equipos tienen estos resultados rápido en su ciclo de vida, pero deciden darle otra oportunidad a la forma de trabajo. Sin embargo, esta decisión los mantiene en la senda de los malos resultados, pero el equipo se empeña en seguir usando el mismo ciclo de vida. A veces es porque alguien lo impide y otras veces, muchas, es por falta de conocimiento.

¿Cómo elegir el ciclo de vida para tu desarrollo?

Hablamos ya de algunos malos entendidos que existen respecto a los ciclos de vida. Ahora que los conoces y evaluaste si en tu equipo se cometen uno o varios, te comparto mis recomendaciones al momento de elegir un ciclo de vida para tu desarrollo.

Grado de incertidumbre en la visión y los requerimientos

¿Cuánto sabes de la necesidad y el problema que hay que resolver? No estoy hablando de requerimientos funcionales, sino la claridad de los objetivos de los stakeholders y el problema que quieren resolver. Algunos llaman a esto “estabilidad de los requerimientos”.

En proyectos con poca incertidumbre y requerimientos estables, los ciclos de vida predictivos funcionan muy bien y garantizan una solución adecuada. Software para hardware específico o plataformas claras (como los videojuegos) son ejemplos de esto.

Cuando la incertidumbre es alta (no sabemos qué se quiere resolver) y los cambios son frecuentes, es mejor adoptar un ciclo de vida adaptativo, que permita explorar ampliamente al comienzo y cambiar a entregas más cortas con el tiempo.

Riesgo técnico

¿Es técnicamente factible construir la solución? ¿Sabemos cómo hacerlo? ¿Sabemos si hay algo en la infraestructura que puede fallar? ¿Sabemos cómo funciona el hardware/software que ya existe?

En ocasiones, existe mucho riesgo e incertidumbre técnica. Para estos casos, es mejor utilizar ciclos de vida adaptativos, que permitan la exploración de varias alternativas de arquitectura mediante prototipos o pruebas rápidas y cerrar los huecos de entendimiento técnico. Después de resolverlos, moverse a otro tipo de ciclo.

Madurez del equipo

La disciplina individual de todos los miembros del equipo contribuye o dificulta la elección de un ciclo de vida. En ocasiones, queremos adoptar un ciclo de vida como Lean o CI/CD, cuando el equipo no tiene la disciplina y capacidades para hacerlo.

Es importante evaluar la madurez del equipo en conocimientos y disciplina de prácticas para elegir el ciclo de vida. Lo adecuado es iniciar con uno acorde a la madurez del equipo, hacer un plan para desarrollar nuevas habilidades y cambiarlo cuando la disciplina ya es parte de ellos.

Es posible usar diferentes ciclos durante la vida del software

Mencioné en el error 2 que no se debe mantener el mismo ciclo de vida cuando ya no da resultados. Las circunstancias de los desarrollos de software cambian con el tiempo, por lo tanto, un ciclo de vida que inició dando buenos resultados ya no será adecuado cuando ese cambio ocurre.

No es lo mismo un producto en etapas iniciales de desarrollo, que uno que ya se encuentra operando y en mantenimiento adaptativo. La forma en que aparecen y se gestionan los requerimientos en uno y en otro es diferente, por lo tanto, la forma de abordarlos también lo debe ser.

Por ejemplo, tu producto pudo iniciar el desarrollo con el ciclo de vida ágil hasta obtener el MVP. Este software en producción, que ya está en uso, puede ser suficiente para alcanzar los objetivos y requerir funciones y mejoras incrementales o en cualquier momento. En estos casos, la forma de trabajo cambia a algo como Lean o CI/CD, pues el trabajo se ha reducido a paquetes muy pequeños que no requieren tanta gestión, planificación y overhead de despliegue.

Es posible combinar prácticas de diferentes modelos

Los modelos de ciclo de vida son eso: modelos. Una guía de cómo hacer algo si existen ciertas circunstancias, en las que el modelo funciona bien. Sin embargo, son pocos los desarrollos donde las circunstancias son idénticas a las del modelo.

En estos casos, lo mejor es descomponer el modelo en sus prácticas y entender las circunstancias en las que funciona bien. Lo que tienes es una caja de herramientas con prácticas y su clasificación. Así, evalúas tu desarrollo, entiendes sus circunstancias y construyes el ciclo de vida adecuado combinando prácticas de tu caja de herramientas.

Estas son algunos aspectos importantes en la elección de un ciclo de vida para desarrollar software. Evalúa en tus equipos la forma de pensar que se tiene al respecto y cómo aprender a elegirlo en tus desarrollos actuales.

¿Quieres que hablemos sobre tus proyectos actuales y encontremos la mejor forma de abordarlos? ¡Contáctame y agenda una sesión conmigo!