Entrega Ágil Disciplinada

Un número creciente de organizaciones están adoptando métodos ágiles y para ello una estrategia común es comenzar con métodos sencillos como Scrum en unos cuantos proyectos. Conforme van teniendo éxito en dichos proyectos, se interesan en llevar Ágil al siguiente nivel. Este artículo describe cómo se ve ese siguiente nivel.

Disciplined Agile Delivery (Entrega Disciplinada de Agilidad), o DAD, es un framework de procesos que brinda una estrategia completa y coherente de cómo funciona en la práctica la entrega ágil de soluciones. DAD es un framework híbrido, centrado en las personas y orientado al aprendizaje. Utiliza una estrategia dirigida por metas y un ciclo de vida dirigido por riesgo y valor. Es escalable y está diseñado para satisfacer contextos empresariales complejos.

Características de DAD

Revisemos qué significa cada una de estas características que he mencionado:

Centrado en las personas (people first). En DAD se fomentan los equipos multidisciplinarios conformados por personas con habilidades distintas y cruzadas. Los miembros de los equipos deben tener múltiples habilidades y realizar actividades en distintas disciplinas fuera de su especialidad.

Orientado al aprendizaje. Existen tres aspectos clave que deben ser atendidos por un ambiente de aprendizaje. El primero es el aprendizaje del dominio: ¿cómo exploras e identificas las necesidades del cliente?, ¿cómo fomentas que el equipo obtenga este aprendizaje? El segundo aspecto se enfoca en el aprendizaje para mejorar el proceso a todos los niveles: individual, de equipo y de organización. El tercer aspecto es el aprendizaje técnico que se enfoca en entender como trabajar de forma efectiva con las herramientas y tecnologías utilizadas para crear la solución.

Agilidad. El framework DAD se adhiere y amplifica los valores y principios del Manifiesto Ágil.

Híbrido. DAD es un framework híbrido porque adopta y personaliza técnicas de métodos ágiles existentes tales como Scrum, Extreme Programming (XP), Agile Data (AD), Agile Modeling (AM), Unified Process (UP) y Kanban, por nombrar algunos. DAD es un framework ágil de segunda generación, que aprende y aprovecha los frameworks ágiles anteriores.

Enfocado en soluciones. DAD mueve el enfoque de tan solo producir software, a proveer soluciones que aportan verdadero valor de negocio, considerando las restricciones económicas, culturales y técnicas. Sí, por supuesto que el software es importante, pero el despliegue exitoso de soluciones de TI típicamente involucra no solo software, sino también adquirir hardware, ajustar procesos de negocio y operativos, e incluso puede impactar la estructura organizacional de los involucrados.

Enfocado en la entrega. El ciclo de vida básico de DAD, mostrado en la figura 1, considera desde el inicio del proyecto, pasando por la construcción del producto y la liberación de la solución en producción (incluso muestra algunas actividades de gestión de portafolio de proyectos previas a la iniciación del proyecto, así como algunas actividades posteriores a la liberación en producción). Esto difiere de los métodos ágiles de primera generación que típicamente se enfocan en las actividades de construcción del software, ignorando el resto del ciclo de vida necesario para desarrollar e implantar exitosamente una solución, especialmente en un contexto corporativo.

Dirigido por metas. Uno de los retos de describir un marco de procesos es que necesitas proveer suficiente información que sirva como guía para ayudar a las personas a entender el marco, pero si se provee demasiada información entonces puede ser tomado como una “receta” y sabemos que eso no es bueno. Para resolver este reto, el framework DAD está dirigido por metas, que se resumen en la figura 2. En mi experiencia, la estrategia dirigida por metas provee la cantidad adecuada de orientación para que el equipo comprenda el proceso, al mismo tiempo que es suficiéntemente flexible para que puedan personalizarlo al contexto correspondiente.

Compatible con el contexto empresarial. Los equipos ágiles no trabajan en un vacío. Normalmente hay sistemas existentes en producción, que no deberían ser impactados, e idealmente deberían ser aprovechados. También hay otros equipos y proyectos desarrollando soluciones en paralelo, y es deseable que dichos equipos puedan aprovechar lo que está haciendo cada uno. Asimismo, puede haber una visión conjunta de la organización, una visión a la que cada equipo contribuye por medio de las soluciones que desarrolla. Y también debe haber una estrategia de gobernanza (governance), aunque posiblemente no sea obvia para todos los miembros de la organización.

Dirigido por riesgo y valor. El framework DAD adopta lo que se conoce como un ciclo de vida dirigido por riesgo y valor (risk/value lifecycle), que viene a ser una versión ligera de la estrategia propuesta por el Proceso Unificado. Los equipos DAD se enfocan en resolver los principales riesgos del proyecto, tales como: lograr consenso de la visión de la solución a desarrollar y probar su arquitectura en etapas tempranas del ciclo de vida. DAD también incorpora revisiones explícitas de la viabilidad del proyecto, si la funcionalidad provista es suficiente, y si la solución está lista para producción. El que también esté dirigido por valor provoca que en DAD los equipos buscan generar soluciones utilizables periódicamente.

Escalable. DAD provee una base escalable para TIs ágiles y es una parte importante de la estrategia de IBM de “agilidad a escala”. Dicha estrategia enfatiza que escalar un proceso tiene que ver con muchos aspectos más allá del tamaño del equipo. Existen muchos otros factores que deben ser considerados al escalar procesos ágiles a nivel organizacional. Entre estos factores están la distribución geográfica del equipo, complejidad (técnica y del dominio), regulaciones que deben ser satisfechas (compliance), estructura organizacional, complejidad organizacional, y disciplina de la empresa. Cada equipo se encontrará en una situación única y debe personalizar su estrategia al contexto en que se encuentra. Por ejemplo, un equipo de siete personas colocalizadas en un ambiente de alta regulación trabajaran de forma distinta a un equipo de cuarenta personas distribuidas geográficamente en un ambiente sin regulación.

Figura 1. El ciclo de vida básico de DAD

Figura 2. Metas a lo largo de un proyecto DAD

Dirigido por metas

La característica de DAD que los agilistas posiblemente encuentren más intrigante es que es dirigido por metas. La estrategia básica consiste en identificar las metas fundamentas que son aplicables en un punto específico del proyecto, y entonces configurar la estrategia de proceso para cumplir dichas metas de forma que reflejen la situación real del proyecto. Para lograr esto de manera efectiva necesitas entender los asuntos relevantes a cada meta, así como las consecuencias de las decisiones que estás tomando.

Aquí es donde DAD provee orientación. Tomemos como ejemplo la meta de identificar los requerimientos iniciales de un sistema, existen distintos asuntos a considerar al configurar tu proceso para cumplir esa meta: ¿qué nivel de detalle buscas capturar (lista de metas, especificación ligera, especificación detallada)?, ¿qué tipos de modelado realizarás (modelo de dominio, modelo de procesos, modelo de uso, modelo de interfaces de usuario)?, ¿qué mecanismos utilizarás para obtener los requerimientos (entrevistas, brain storming, observación de usuarios)?, ¿cómo gestionaras los cambios de requerimientos?, ¿cómo capturarás los requerimientos no funcionales? Aunque identificar los requerimientos iniciales es una tarea clara y concisa, llevarla a cabo de manera adecuada típicamente requiere algo más que tan solo crear unas tarjetas con historias.

Mejora de proceso explícita

A pesar de todo lo que se habla sobre el empirismo -la importancia del aprendizaje- y la necesidad de mejorar y ajustar tú proceso de software, me llama la atención que Scrum ha cambiado muy poco en los últimos quince años. El framework DAD no asume que tu proceso se quedará estancado, de hecho asume lo contrario. Conforme he trabajado con clientes en todo el mundo, los he visto comenzar con un ciclo de vida similar al de Scrum como el que se muestra en la figura 1 pero conforme pasa el tiempo maduran hacia una estrategia más esbelta, tipo Kanban como la que se muestra en la figura 3.

Figura 3. El ciclo de vida avanzado de DAD

La figura 3 muestra un ejemplo de ciclo de vida hacia el que tienden a migrar los equipos experimentados. Conforme pasa el tiempo se dan cuenta que las distintas prácticas ágiles no necesitan la misma cadencia. Con la estrategia basada en iteraciones de la figura 1, las prácticas ágiles tales como planeación just-in-time, modelado just-in-time, demos y retrospectivas se ejecutan juntas al final/inicio de cada iteración. En lugar de planear al principio de cada iteración, ¿por qué no planeamos cuando necesitamos?, ¿por qué no hacemos demos cuando las necesitamos?, ¿por qué no generamos builds continuamente y los liberamos conforme se necesite? Cuando empiezas a darte cuenta de este tipo de cosas y actuar sobre ellas, comienzas a migrar de una estrategia basada en iteraciones a una basada en un flujo continuo de desarrollo. Este flujo continuo típicamente requiere mayor habilidad y disciplina que al basarse en iteraciones o sprints.

Otra diferencia significativa entre ambos ciclos de vida se da en la forma en la que se da prioridad a los elementos de trabajo. En la figura 1, los elementos de trabajo, incluyendo los requerimientos, son tratados como una lista (stack) con prioridades, similar a como se hace en Scrum (aunque DAD describe varias estrategias posibles para priorizar el trabajo). En cambio, en la figura 3 los elementos de trabajo son tratados como un grupo (pool) de opciones que son categorizadas de acuerdo a distintos esquemas de prioridad, y los elementos de trabajo se jalan del grupo cada que se dispone de capacidad para hacerlo. Dicha estrategia brinda mayor flexibilidad pero requiere mayor disciplina también.

¿Por qué DAD?

DAD es una estrategia de punto medio. Mientras que RUP era demasiado y Scrum era muy poco, creo que DAD es justo la medida adecuada. El reto con RUP es que la mayoría de los equipos no cuenta con el conocimiento de procesos necesario para configurarlo apropiadamente, lo cual típicamente resulta en un proceso muy pesado y con tareas de más. Por otro lado, los equipos de Scrum tienden a tener el problema de no contar con suficiente conocimiento de procesos para completarlo, y la consecuencia de esto es que se invierte un esfuerzo significativo en reinventar o reaprender técnicas para poder atender la gran cantidad de aspectos que Scrum no cubre. En ambos casos, se podría evitar desperdicio de esfuerzos si existiera una opción de punto medio, DAD es esa opción.

El framework DAD también provee la base para escalar métodos ágiles, llevandolo a proyectos complejos e incluso a nivel de un portafolio de proyectos. DAD muestra como se puede entregar exitosamente una solución de TI desde el inicio del proyecto a través de la construcción y hasta la liberación a producción. Una vez que comprendes como hacer esto en proyectos individuales puedes evolucionar tu estrategia para enfrentar la complejidad que se da al llevar Agile a mayor escala. En pocas palabras, aprende a caminar antes de aprender a correr.

Este artículo provee un resumen del nuevo libro “Disciplined Agile Delivery: A Practitioners Guide to Agile Software Delivery in the Enterprise (IBM Press, June 2012)” escrito por Scott W. Ambler y Mark Lines. Para conocer más sobre DAD, visita http://disciplinedagiledelivery.com o asiste a la conferencia que Scott dará sobre este tema en SG Conferencia y Expo (http://sg.com.mx/sgce/2012).