En esta serie de artículos voy a intentar describir algunos conceptos de entrega ágil (agile delivery) que pueden ser útiles para equipos y organizaciones que llevan adelante productos o proyectos ágiles, lo cual no siempre es sencillo. Los mismos están basados en los aprendizaje que obtuve y sigo obteniendo al acompañar a clientes en el camino de tener una organización más ágil / adaptativa.
¿Qué es un release?
Un release es un entregable que engloba la/s funcionalidad/es realizadas a lo largo de varios sprints. Si bien hay equipos que lograr tener un “producto viable” en cada iteración, por lo general muchas organizaciones prefieren “acumular” funcionalidad terminada hasta llegar a un producto que contenga un mínimo de funcionalidad valiosa para desplegar. Ese “valor” tiene dos caras: para el negocio, implica ser capaz de completar de forma integral algún proceso, funcionalidad o módulo que beneficien a usuarios y clientes. Desde el punto de vista técnico, es valioso minimizar el costo de la burocracia / administración ligada a la liberación del producto, o sincronización con otros con otros sistemas / servicios co-dependientes.
Varios sprints acumulados conformando un releasePlanificar el release es especialmente útil para organizaciones que todavía tengan alguna etapa de su proceso de validación y liberación de producto en etapas o ”cascada”. Si bien no es lo ideal, es una situación aún frecuente en muchas organizaciones.
¿Por qué trabajar con releases?
Organizar las entregas por releases es algo que suele dar valor tanto a los equipos como a las áreas de negocio. Un release es una forma de “aterrizar” un conjunto de funcionalidades en un entregable concreto.
Cuando pienso en un release, tiendo a pensar en un intervalo de tiempo acotado que puede abarcar unos dos meses.
El planificar en releases ofrece la ventaja de darle al negocio una idea de la funcionalidad que va a tener en un horizonte de tiempo, sin la necesidad de bajar a un nivel de detalle tan grande que nos haga perder flexibilidad.
Funcionalidades “acumuladas” o contenidas en cada releaseAl negocio, tener esta visibilidad le permite organizar mejor elementos como estrategia de lanzamiento, capacitación, campañas de marketing, etc.
Al equipo le permite tener más autonomía sobre como organizarse dentro de cada iteración, y una meta clara u objetivo de “mediano plazo” (entendiendo que el entregable del sprint es un objetivo del corto). Así el equipo establece una expectativa de mediano plazo, para ganar independencia en el corto: en lugar de ser “medidos” respecto a lo construido o no dentro de un sprint específico, indicamos el 70 u 80% de la funcionalidad que creemos estará construida en el horizonte de los próximos 2 meses.
Para la mayoría de las organizaciones, contar con un plan de releases les da es suficiente detalle y simplifica el proceso de dar seguimiento a la construcción. Es bastante similar al concepto de planificación por hitos en los abordajes tradicionales / en cascada.
Por supuesto, es posible planificar varios releases por adelantado, pero no tiene mucho sentido que haya granularidad o detalle en algo que vendrá muy en el futuro, porque la probabilidad de que cambie la prioridad o la necesidad es muy alta.
¿Como se organiza un release?
Últimamente, cuando trabajo con una organización, me gusta usar como metáfora del release al desarrollo de una ciudad.
Imaginemos el mapa de una ciudad en el año 1800. Probablemente haya una plaza central, y dispuesto a su alrededor una iglesia, una gobernación, una plaza de armas y un mercado. Si a esto le sumas las viviendas, los terrenos de cultivo, tenemos los elementos necesarios para la subsistencia de la ciudad.
Para alguien que vive en la actualidad, esa ciudad le parecerá “simple” o “reducida en alcance”: no hay cines, no hay acceso a internet… pero el propósito de la ciudad se cumple: sus ciudadanos tienen los elementos necesarios para vivir, y llevar adelante sus actividades cotidiantes.
Si ahora nos desplazamos en el tiempo hasta el año 1900, veremos que la ciudad está cambiada. Hay más “funcionalidades”: departamento de bomberos, cárceles, diversidad de comercios, etc. Otras funcionalidades que ya existían, están ampliadas: la gobernación se agrandó, la plaza de armas está fortificada, etc. Si bien avanzó, para los ojos del hombre de la actualidad, aún es “primitiva” en ciertos aspectos, pero es posible hacer muchas más cosas que antes. Hay más “procesos de negocio” también, y se satisfacen las necesidades de un número más grande y diverso de ciudadanos.
Finalmente, la ciudad en el año 20xx, tendrá casi todo lo que un ciudadano en la actualidad espera. Y, seguramente, tendrá funcionalidades a seguir cambiando, evolucionando y construyendo, para satisfacer a los ciudadanos que vendrán en el futuro. Al igual que sucede con los productos, una ciudad NUNCA queda terminada.
Cada una de estos mapas de la ciudad a lo largo del tiempo refleja el alcance de un release. Cada ciudad es, en su tiempo, capaz de reflejar soluciones concretas para un conjunto de clientes / usuarios.
No sería prudente “liberar” la ciudad para su uso si no tuviera los elementos mínimos y esenciales para que sus ciudadanos desarrollaran sus actividades en ella (completitud). Aquello que los habitantes pretenden llevar adelante en ella (propósito) tiene que estar disponible. Y, además, para ser reconocida por todos como una ciudad, debe ser identificable y coordinada en su conjunto (integridad) y no ser un simple montón de elementos sueltos sin una clara relación.
Espero que esta metáfora y los conceptos aquí explicados te sean de utilidad. Me gustaría escuchar tus comentarios!!!
Saludos,
Ezequiel