Introducción a Disciplina Ágil

de Desarrollo
(Introduction to Disciplined Agile Delivery)

El breve viaje de un equipo ágil, desde

Scrum al Despliegue Continuo
Por Mark Lines y Scott W. Ambler
Copyright © 2016 Disciplined Agile Consortium
Todos los derechos reservados.
ISBN: 1523399309
ISBN-13: 978-1523399307

Dedicatorias
Para Louise, Brian y Katherine
- Mark
Para Beverley y Olivia
- Scott
Jerga legal indescifrable: Los autores y el editor han realizado un trabajo
cuidadoso durante la publicación del presente libro, pero no pueden ofrecer
garantía alguna de ningún tipo, tanto explícita como implícita. Por tanto, no
pueden asumir responsabilidades debidas a errores u omisiones, así como a
eventuales perjuicios relacionados o derivados del uso de la información
contenida en este libro.
 CONTENIDOS
CONTENIDOS

1 INTRODUCCIÓN

2 REALIDAD SOBRE RETÓRICA

3 UN RESUMEN DE DISCIPLINA ÁGIL DE DESARROLLO

4 INTRODUCCIÓN AL CASO DE ESTUDIO

5 INICIO

6 CONSTRUCCIÓN: ITERACION C1

7 CONSTRUCCIÓN: ITERACIÓN C2

8 CONSTRUCCIÓN: ITERACIÓN C3

9 CONSTRUCCIÓN: ITERACIÓN C7

10 CONSTRUCCIÓN: ITERACIÓN C10

11 TRANSICIÓN

12 SIGUIENTES VERSIONES

13 REFLEXIONES FINALES

APÉNDICE: EL DEPARTAMENTO IT CON DISCIPLINA ÁGIL

ÍNDICE

SOBRE LOS AUTORES

 Agradecimientos
Nos gustaría agradecer a Beverley Ambler, Rod Bray, David Dame, Louise
Lines, Glen Little, Valentin-Tudor Mocanu, Kristen Morton, David Shapiro,
Paul Sims, y a Michael Vizdos sus comentarios y aportaciones durante el
desarrollo de este libro. No podríamos haberlo completado sin su ayuda.
Ilustraciones y diseño de la portada por Nicole Wolf
Cry Wolf Illustration (crywolfillustration@gmail.com)
 1 INTRODUCCIÓN
Muchas organizaciones tienen dificultades para utilizar con éxito los métodos
ágiles más comunes como Scrum. A veces abandonan y prueban nuevas
modas como Lean o Scaled Agile Framework (SAFe). La realidad es que el
origen del fracaso en estas adopciones problemáticas se debe frecuentemente
a la aplicación incorrecta de los principios ágiles fundamentales, a enfoques
naïve en el escalado de la agilidad y a la necesidad de afrontar con realismo
las complejidades de las empresas.
Un añadido a esta confusión son las constantes disputas de la comunidad
ágil respecto a cuál es el mejor método, entre Scrum, XP, Kanban, SAFe y
otros. La realidad es que la mayoría de las organizaciones pueden
beneficiarse de muchas de estas estrategias, aunque manteniendo la
consistencia que puede proporcionar un marco de trabajo común. Aquí es
donde entra en escena la Disciplina Ágil de Desarrollo (DAD).
DAD es un híbrido de métodos existentes que proporciona la flexibilidad
de usar varios enfoques además de cubrir aspectos sobre los que no hablan
los métodos ágiles comunes. Como resumen, DAD es “agilidad pragmática”.
Describe estrategias validadas para adaptar y escalar sus iniciativas ágiles de
manera que se adapten a la realidad única de su empresa sin tener que
resolverlo todo por usted mismo.
El libro “Disciplined Agile Delivery: A Practitioner’s Guide to Software
Development in the Enterprise” es la guía definitiva sobre DAD. Sin
embargo, DAD continúa su evolución y su material más reciente puede
encontrarse en el blog de DAD, disponible en DisciplinedAgileDelivery.com.
Aunque este libro sobre DAD es exhaustivo describiendo el marco de
trabajo, tiene 500 páginas. Por ello pensamos que podría ser útil resumir
DAD en una lectura rápida para mostrar cómo podría aplicarse en una
situación típica. Hemos visto que las organizaciones que dedican un poco de
tiempo a entender que es DAD, así como lo que no es, aprecian rápidamente
los beneficios obvios que este marco de trabajo les puede ofrecer.
Escribimos este libro breve con la esperanza que, después de haber
invertido una o dos horas en entender que es DAD realmente, el lector esté
convencido que vale la pena investigar más profundamente la posible
aplicación de DAD a su organización.
Algunos hechos básicos sobre el marco de trabajo DAD:
DAD está resonando dentro de organizaciones de todo el mundo.
Las organizaciones que han adoptado, o están en el proceso de
adoptar el marco de trabajo DAD, incluyen grandes instituciones
financieras, compañías de software, compañías de comercio
electrónico, cadenas de restaurantes, agencias gubernamentales y
muchas otras. Entendemos por adopción tanto la planificación como
la implementación de DAD en la organización entera, no solo en
uno o dos equipos.
Aunque DAD se desarrolló originalmente dentro de IBM, ahora es
propiedad del Disciplined Agile Consortium, y está disponible para
su uso de manera gratuita.
El programa de certificación de DAD está descrito en el
sitio DisciplinedAgileConsortium.org.
DAD no reemplaza los métodos ágiles y lean existentes. Los
complementa y en muchos casos los extiende para que estén
preparados para ser usados en las empresas.
 2 REALIDAD SOBRE RETÓRICA
Uno de los motivos por los que la popularidad de DAD está creciendo
rápidamente es que tiene en cuenta como están haciendo las cosas realmente
las organizaciones que consiguen escalar la agilidad de manera efectiva.
Pensamos que es importante despejar algunos de los mitos derivados de las
exageraciones del purismo ágil, respecto a lo que hemos constatado que
realmente está pasando a partir de nuestra experiencia directa en muchos
clientes alrededor del mundo y de nuestra investigación exhaustiva de la
industria[1].
Mito Realidad
Los equipos ágiles no El equipo ágil medio dedica sobre un mes a
definen requisitos o realizar alguna planificación inicial y a
planifican. modelar requisitos. Aunque DAD busca
minimizar este trabajo, tenemos en cuenta esta
realidad y sugerimos que los equipos nuevos
en la agilidad dediquen unas pocas semanas a
una fase de Inicio que les permita completar
este trabajo de una manera mínima pero
suficiente.
DAD es una forma de Aunque DAD reconoce que, para asegurar la
“WaterScrumFall” financiación del proyecto se necesita un
comienza con mucha trabajo previo al desarrollo de planificación y
planificación y requisitos de otras actividades, DAD hace énfasis en la
(Water), acaba con minimización del trabajo de la fase de Inicio.
pruebas y despliegue Similarmente, DAD reconoce que un patrón
(Fall) y tiene Scrum en el común en las empresas es desplegar las
medio. soluciones de una manera estructurada, como
se describe en la fase de Transición, la
disciplina de prácticas de testeo de la fase de
Construcción –como la Integración Continua–
deberían minimizar el esfuerzo de la
transición y de las pruebas finales. En las
implementaciones más avanzadas de DAD,
los equipos pueden no requerir las fases de
 Inicio y Transición, tal como se describe en el
ciclo de vida de Despliegue Continuo de
DAD.
“Gobierno” es una El gobierno es realmente positivo cuando se
palabra sucia en realiza de una manera ágil/lean. Los
agilidad. El concepto de patrocinadores y el resto de la empresa
auto-organización ágil merecen saber que su inversión se realiza
significa que las adecuadamente y que el riesgo el desarrollo
empresas no deberían del proyecto se monitoriza y se controla,
interferir en como los aunque sea de una manera ligera y ágil. DAD
equipos realizan su proporciona una guía específica para cumplir
software. esta responsabilidad de una manera
relativamente indolora.
DAD es complicado y DAD es bastante sencillo de adoptar,
adoptarlo sería especialmente si su organización está
disruptivo. familiarizada con las prácticas ágiles
comunes. La buena noticia es que DAD
proporciona la guía que aborda porqué
algunas implementaciones de agilidad resultan
problemáticas y pueden ayudar a encarrilarlas
de nuevo.
SAFe es LA solución Para grandes organizaciones que tienen
para escalar la agilidad equipos de proyectos mayores de 100
miembros, SAFe puede efectivamente
funcionar bien en algunos proyectos. A pesar
de eso, la mayoría de organizaciones tiene una
mezcla de equipos de tamaño pequeño y
medio que proporcionan soluciones a
múltiples líneas de negocio. En esas
situaciones SAFe puede no ser adecuado.
Mientras que SAFe es adecuado solo para
ciertos contextos, DAD es mucho más flexible
y adaptable a un rango más amplio de
situaciones en las empresas.
 3 UN RESUMEN DE DISCIPLINA ÁGIL DE
DESARROLLO

Puntos clave
DAD es un marco de trabajo para procesos, no simplemente otra
metodología
Si está usando Scrum, XP, Kanban, o SAFe, ya está usando
variaciones y un subconjunto del marco de trabajo DAD
DAD proporciona cuatro ciclos de vida entre los que escoger, no
prescribe una única manera de trabajar – la variedad es buena
DAD pone el énfasis en alcanzar metas comunes de una manera ágil,
no en la realización de productos de trabajo específicos o en seguir
una estrategia ágil prescriptiva
DAD se ocupa de aspectos clave en la empresa que no abordan
métodos comunes como Scrum
DAD es complementario a SAFe aunque menos prescriptivo y más
práctico para la mayoría de empresas
DAD muestra cómo funciona la agilidad de principio a fin
DAD proporciona una base flexible para poder escalar los métodos
ágiles más extendidos
Aunque la filosofía de DAD es consistente con la del Manifiesto
Ágil, incluye una guía adicional para ser efectivo en los contextos
más complejos propios de las grandes empresas[2]
No es difícil comenzar con DAD
¿Qué es DAD?
Muchas organizaciones comienzan su viaje hacia la agilidad adoptando
Scrum porque describe una buena estrategia para liderar equipos ágiles de
software. Sin embargo, Scrum es solo una pequeña parte de lo que se requiere
para proporcionar soluciones sofisticadas a sus clientes. Invariablemente, los
equipos necesitan buscar en otros métodos para completar los procesos que
Scrum ignora de manera deliberada. Cuando se combinan varios métodos,
existe un solapamiento considerable y conflictos de terminología que pueden
confundir a los miembros del equipo y a otros actores interesados. Peor aún,
la gente no sabe siempre donde buscar una guía o incluso qué carencias
deben resolver.
Para afrontar estos desafíos, el marco de trabajo para procesos Disciplina
Ágil de Desarrollo (DAD) proporciona un enfoque más cohesivo al
desarrollo ágil de soluciones. Para ser más exacto, aquí hay una definición:
“Disciplina Ágil de Desarrollo (DAD) es un marco de trabajo para procesos
centrado en las personas, orientado al aprendizaje y con un enfoque de
agilidad híbrida para el desarrollo de soluciones TI. Tiene un ciclo de vida
basado en el riesgo-valor, está orientado a metas, adopta una perspectiva
organizativa y es escalable”.
Existen aspectos claramente interesantes del marco de trabajo DAD. Este
es un enfoque híbrido que extiende Scrum con estrategias validadas del Agile
Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban,
Lean Software Development, Outside In Development (OID) y otras
metodologías. DAD es un marco de trabajo no propietario y disponible
libremente. DAD extiende a Scrum, que tiene un ciclo de vida centrado en la
construcción, para incluir el ciclo de vida completo del desarrollo de
soluciones, desde el inicio del proyecto hasta la entrega de la solución a sus
usuarios finales. También incluye versiones con el ciclo de vida lean y de
despliegue continuo: contrariamente a otros métodos ágiles, DAD no
prescribe un único ciclo de vida porque reconoce que este no encajaría en
proyectos con un tamaño y contexto muy diferentes. DAD incluye guía
respecto a prácticas técnicas como las incluidas en Extreme Programming
(XP) y otras estrategias de modelado, documentación y gobierno que no
quedan cubiertas ni en Scrum ni en XP. En vez del enfoque prescriptivo de
otros métodos, incluyendo Scrum, el marco de trabajo DAD tiene un enfoque
orientado a metas. De esta manera, DAD proporciona una guía
contextualizada con las alternativas posibles y los aspectos a evaluar en la
toma de decisiones, permitiendo adaptar de manera efectiva DAD a las
circunstancias de cada empresa y proyecto. Al describir lo que funciona, lo
que no funciona, y aún más importante, el porqué, DAD le ayuda a
incrementar la probabilidad de adaptar con éxito las estrategias que funcionen
en su contexto específico.
 Primero las personas: roles en Disciplina Ágil de Desarrollo

El marco de trabajo DAD sugiere un conjunto robusto de roles para el

desarrollo ágil de soluciones. Una pregunta común que recibimos es sobre la
diferencia existente entre los roles principales y los secundarios. Los roles
principales existen en todos los proyectos DAD independientemente de su
tamaño. Los roles secundarios, sin embargo, aparecen típicamente en los
proyectos mayores y a veces solo durante un periodo de tiempo. Otra
pregunta frecuente se refiere a que DAD define diez roles mientras que
Scrum solo necesita tres –Scrum Master, Propietario del producto (Product
Owner) y Equipo de desarrollo (Development Team)–. La primera razón es el
alcance de ambos. Scrum se enfoca principalmente en los aspectos del
liderazgo y de la gestión del cambio durante la fase de Construcción, y por lo
tanto sus roles reflejan esto. DAD, por otro lado, se enfoca explícitamente en
el ciclo de vida completo del desarrollo de soluciones y en todos sus
aspectos, incluyendo las prácticas técnicas que Scrum deja fuera. Así pues,
un alcance mayor requiere más roles. Por ejemplo, dado que DAD incluye
aspectos de arquitectura ágil, incluye un rol de Propietario de la Arquitectura.
Scrum no se ocupa de la arquitectura así que no incluye este rol.

Un marco de trabajo híbrido

Disciplina Ágil de Desarrollo (DAD) es un marco de trabajo híbrido que se
construye sobre la base sólida de otros métodos y marcos de trabajo para el
proceso del software. El marco de trabajo DAD adopta prácticas y estrategias
de fuentes existentes y proporciona una guía para decidir cuándo y cómo
aplicarlas juntas. Se puede ver a los métodos como Scrum, Extreme
Programming (XP), Kanban, y Agile Modeling (AM) como los bloques, y a
DAD como el cemento que los hace encajar de manera efectiva.

Una de las grandes ventajas de la agilidad y del desarrollo de software

lean es la riqueza de prácticas, técnicas y estrategias disponibles. Esto
también es uno de sus desafíos principales porque sin algo como el marco de
trabajo DAD, es difícil conocer que piezas escoger y como encajarlas juntas.
Peor aún, muchos equipos nuevos en la agilidad usarán métodos como Scrum
o SAFe como si fueran una receta que debe seguirse fielmente, ignorando las
guías existentes en otras fuentes y, de ese modo, encontrando problemas.
Un ciclo de vida de desarrollo completo
El énfasis de DAD está en la construcción, aunque también afronta otras
fases del ciclo de vida del sistema que afectan al desarrollo. Un ciclo de vida
completo para el sistema/producto va desde el concepto inicial del producto,
pasando por el desarrollo, la operación y el soporte, y frecuentemente incluye
muchas iteraciones del ciclo de vida de desarrollo. El siguiente diagrama es
una visión de alto nivel del ciclo de vida de DAD. Las tres fases internas –
Inicio, Construcción y Transición– forman la parte del desarrollo del ciclo de
vida. Durante esta parte se construye incrementalmente una solución usable a
lo largo del tiempo.

Obviamente existe más en DAD de lo que muestra este diagrama de alto

nivel. DAD, dado que no es prescriptivo y aspira a reflejar la realidad lo
mejor posible, da soporte a varios tipos de ciclo de vida para el desarrollo.
Las cuatro versiones que incluye son: una versión Ágil/Básica que extiende el
ciclo de vida de construcción de Scrum con ideas validadas de RUP, un ciclo
de vida Avanzado/Lean, un ciclo de vida de Despliegue Continuo y un ciclo
de vida exploratorio basado en un enfoque Lean Startup. Los equipos de
DAD escogerán el ciclo de vida más apropiado para su situación y entonces
lo adaptarán a sus necesidades. Dentro de este resumen inicial de DAD, no
explicaremos estos ciclos de vida[3].
 En general, proponemos los siguientes criterios para escoger cuando estos
ciclos de vida encajan en un contexto:
Ciclo de vida Ágil/Básico de DAD . Este ciclo de vida se basa
fundamentalmente en Scrum y XP con un conjunto de iteraciones de tiempo
limitado (sprints) que forman el núcleo de la fase de Construcción. Es el ciclo
de vida usado más frecuentemente en estos tipos de situaciones:

El trabajo consiste principalmente en mejoras o nuevas

funcionalidades
El trabajo puede identificarse, priorizarse y estimarse al
principio del proyecto
Es una buena elección para equipos nuevos en la agilidad
El equipo ya conoce Scrum y XP

Ciclo de vida Avanzado/Lean de DAD . Este ciclo de vida promueve

principios lean como minimizar el trabajo en curso, maximizar “la fluidez”,
mantener un flujo continuo de trabajo (en lugar de iteraciones fijas), y reducir
los cuellos de botella. El equipo “toma” nuevo trabajo de la pila de elementos
pendientes cuando dispone de capacidad. Mientras que Scrum prescribe el
uso de un conjunto de “ceremonias” en la iteración (Sprint), como la reunión
de coordinación diaria, la sesión de planificación de la iteración o la
retrospectiva, Lean no prescribe esta dedicación obligatoria y en su lugar
sugiere que esto se haga donde y cuando sea necesario. Esto requiere un
grado de disciplina y de autoconocimiento del que habitualmente no disponen
los equipos nuevos a la agilidad, y por tanto este ciclo de vida se considera
avanzado. Aunque los conceptos de Lean y el sistema Kanban pueden ser
sencillos de aprender, puede ser difícil dominar los principios lean de
mantener el flujo y maximizar el rendimiento del sistema. Este ciclo de vida
puede ser la respuesta en estas situaciones:

El trabajo puede descomponerse en elementos muy

pequeños de un tamaño aproximadamente igual
 El trabajo es difícil de anticipar. Los proyectos orientados a
solucionar defectos o gestionar peticiones de soporte son
buenos candidatos para este ciclo de vida.
El equipo está a favor del enfoque ágil de minimizar tanto el
tamaño de los bloques de trabajo (permitiendo reducir el
trabajo en curso) como la planificación previa a la
realización del trabajo.

Ciclo de vida de Despliegue Continuo de DAD . Este ciclo de vida es

una evolución natural del ciclo de vida Avanzado/Lean. Permite desplegar
incrementos de la solución de manera más frecuente que el resto de ciclos.
Para ser efectivo requiere que se realicen de manera madura un conjunto de
prácticas como la integración y el despliegue continuos, además de disponer
de una infraestructura y de prácticas avanzadas de DevOps. Este ciclo de vida
se adapta mejor a estas situaciones:

Proyectos/soluciones que pueden desplegarse a los clientes

de una manera frecuente e incremental
Organizaciones con prácticas y procedimientos de
despliegue integrados y optimizados
Proyectos donde es crítico proporcionar valor a los clientes
de manera acelerada, sin esperar a completar la solución
requerida
Equipos con prácticas maduras y asentadas de DevOps
como son la integración continua, el despliegue continuo y
las pruebas automatizadas de regresión

Ciclo de vida exploratorio. Este ciclo de vida está basado en los

principios Lean Start-up que defiende Eric Ries en El Método Lean Startup,
su libro éxito de ventas. Su filosofía consiste en minimizar las inversiones
iniciales y convertirlas en pequeños experimentos que se validen en el
mercado, que sean medidos frecuentemente y desde el principio del proyecto.
Mientras se desarrolla la solución, el equipo de desarrollo tiene la
oportunidad de producir aquello que se necesita realmente a partir del
feedback del uso real que hacen los clientes. Es un ciclo de vida útil en estos
tipos de situaciones:

La solución se enfoca a un mercado nuevo y desconocido

 Los actores involucrados y el equipo de desarrollo son muy
flexibles para adaptar la solución durante el proceso de
desarrollo
Se dispone de una hipótesis/estrategia que validar con un
criterio claro, para continuar o no, cuando se concluye el
experimento

Los equipos de Disciplina Ágil están orientados a metas

El enfoque orientado a metas y no prescriptivo de DAD permite que los
equipos DAD sean más flexibles y que el escalado sea más sencillo que con
otros métodos ágiles. Por ejemplo, allí donde Scrum prescribe un enfoque
orientado al valor de negocio para gestionar los requisitos mediante el
Backlog del producto, en cambio DAD indica que durante la construcción el
equipo tiene la meta de afrontar los cambios en las necesidades de los actores
interesados. DAD indica que existen diferentes aspectos alrededor de esta
meta que se deben considerar, y que existen diferentes técnicas/prácticas que
se pueden adoptar para alcanzarla. Además DAD describe las ventajas e
inconvenientes de cada técnica y explica en que situaciones es más apropiada.
Así pues, aunque el Backlog de Scrum es una manera efectiva de afrontar las
necesidades cambiantes de los actores interesados del proyecto, no es la única
opción ni la que mejor se adapta a muchas situaciones.
En el primer libro de DAD[4], describimos las metas de una manera no
visual, usando tablas, que exploraban las ventajas e inconvenientes de las
técnicas asociadas los aspectos de la meta. En la segunda mitad de 2012
transformamos este enfoque y desarrollamos una manera de representar las
metas de manera visual mediante lo que llamamos un diagrama de meta del
proceso[5].
Vamos a explicar esto mediante un ejemplo. La siguiente figura muestra
el diagrama de meta para Explorar el alcance inicial, una meta que se debería
afrontar al principio del proyecto, durante la fase de Inicio (recuerde que
DAD presenta un ciclo de vida para el desarrollo completo, no solo para la
fase de construcción). Mientras que algunos métodos ágiles recomiendan
rellenar el Backlog de producto con algunas historias de usuario iniciales,
este diagrama de meta deja claro que puede ser apropiado adoptar un enfoque
algo más sofisticado. ¿Qué nivel de detalle se debería reflejar? La opción de
especificación ligera de escribir tarjetas y diagramas en una pizarra es solo
una de las posibilidades. ¿Qué tipos de vistas se deberían utilizar? Las
historias de usuario son un enfoque para modelar el uso, pero ¿no se deberían
utilizar otras vistas de modelado para explorar los datos o la interfaz de
usuario?
Se muestran en negrita las técnicas más habituales o los puntos de partida
sugeridos. Se puede observar como hay diferentes opciones para los aspectos
a tener en cuenta durante la realizaciónde esta meta.

También debería considerarse la manera de gestionar el trabajo del

proyecto. En DAD se deja claro que los equipos ágiles hacen más que
implementar nuevos requisitos, de ahí nuestra recomendación de usar por
defecto una Lista de ítems de trabajo en vez de la estrategia simplista del
Backlog de Requisitos de Scrum. Los ítems pueden incluir nuevos requisitos
para ser implementados, defectos para ser reparados, talleres de formación,
revisiones del trabajo de otros equipos, y otros tipos de trabajo. Todo esto son
cosas que se deberían estimar, priorizar y planificar. Finalmente, el diagrama
de meta deja claro que cuando se está explorando el alcance inicial del
proyecto se deberían capturar de alguna manera los requisitos no funcionales,
como son –entre otros– la robustez, disponibilidad o la seguridad.
Existen otras ventajas fundamentales de optar por un enfoque orientado a
metas en el desarrollo de soluciones. Primero, facilita la adaptación de los
procesos haciendo explícitas las decisiones a tomar. Segundo, ofrece una
orientación para adaptar la estrategia de escalado a la realidad específica de
cada organización. Tercero, establece unas opciones muy claras en los
procesos y de este modo hace más sencillo aplicar la estrategia apropiada
para cada proyecto. Cuarto, permite ahorrarse las suposiciones de cómo
extender los métodos ágiles y de ese modo permite enfocarse en el trabajo
real del equipo, que es proporcionar valor a los actores interesados del
proyecto. Quinto, muestra claramente los riesgos que se están tomando y por
tanto se incrementa la probabilidad de éxito del proyecto. Sexto, y esto puede
no ser un beneficio, muestra un modelo de madurez para la agilidad.

El mapa conceptual en la siguiente página resume las metas para un

proyecto DAD agrupadas según las tres fases de Inicio, Construcción y
Transición, así como la metas que deben perseguirse durante todo el
proyecto.
 Los equipos de disciplina ágil tienen la perspectiva organizativa
La perspectiva organizativa es uno de los aspectos clave del marco de trabajo
Disciplina Ágil de Desarrollo (DAD). La clave es que los equipos DAD
trabajan dentro del ecosistema de la organización, como el resto de equipos.
Normalmente las soluciones en desarrollo están relacionadas con sistemas en
producción y el impacto del desarrollo en éstos debería ser mínimo. O incluso
mejor, la nueva solución debería incluso enriquecer las funcionalidades y los
datos de dichos sistemas. Habitualmente otros equipos trabajan en paralelo y
cada uno deberían beneficiarse del trabajo de los demás. La organización
puede tener estrategias de negocio o técnicas a la que los equipos deben
contribuir. E idealmente debería existir una estrategia de gobierno que integre
los resultados del trabajo de los equipos.
La perspectiva organizativa es un aspecto importante de la autodisciplina
porque, como profesional, se debería aspirar a hacer lo que sea mejor para la
organización y no solamente lo que resulte más interesante para uno mismo.
Los equipos, trabajando de manera aislada podrían, por ejemplo, escoger
desarrollar algo desde cero, usar herramientas de desarrollo o crear accesos
propios a los datos, cuando todas estas cosas podrían existir previamente en
la organización, y que hubieran sido perfectamente instaladas, probadas,
configuradas y optimizadas. Los profesionales con disciplina ágil:

Trabajan cooperativamente con otros actores interesados de

la empresa, como arquitectos o gestores de portfolio
Adoptan y siguen los estándares y políticas de la empresa
Reaprovechan los recursos existentes de la empresa,
incluyendo sistemas y fuentes de datos existentes
Mejoran el ecosistema organizativo a través de la
refactorización de los activos de la empresa
Adoptan una cultura de DevOps
Comparten el aprendizaje y los conocimientos con otros
equipos
Adoptan estrategias de gobierno adecuadas, incluyendo una
monitorización abierta y honesta

La perspectiva organizativa es importante por diferentes razones. Primero,

puede reducir el tiempo global de desarrollo mediante la reutilización de
recursos existentes. En otras palabras, los equipos DAD invierten menos
tiempo reinventando la rueda y más tiempo produciendo valor real para sus
clientes. Segundo, al trabajar de manera cooperativa con los actores
interesados de la empresa, los equipos DAD pueden tomar la dirección
correcta con facilidad. Tercero, se incrementa la oportunidad que el equipo de
desarrollo ayude a optimizar el conjunto de la organización, y no únicamente
“la solución” a la que ha sido asignado. Como está mostrando el movimiento
de software lean, esto aumenta la efectividad del equipo reduciendo el tiempo
de entrega.

DAD proporciona la base para escalar la agilidad

Cuando estaba en IBM Rational, Scott lideró el desarrollo de la estrategia
básica representada en el siguiente diagrama. La observación fundamental fue
que muchas organizaciones tenían dificultades en escalar los métodos ágiles,
particularmente Scrum. Sentíamos que el primer paso era identificar cómo
desarrollar con éxito una solución de principio a fin. Aunque los principales
métodos ágiles proporcionaban claramente muchas y buenas estrategias, no
existía un “pegamento” real entre estas más allá del consultantware (p.e.
“contrátame y te enseñaré cómo hacerlo”). Es aquí donde el marco de trabajo
DAD entra en escena, aunque solo sea un primer paso, ya que es necesario
igualmente adaptar el proceso ágil al contexto específico de cada empresa.

El marco de trabajo DAD proporciona una base mejor para escalar la

agilidad de diversas maneras. Primero, promueve un ciclo de vida de riesgo-
valor, atacando el trabajo con mayor riego al principio del proyecto para
ayudar a eliminar parte o todo el riesgo, y de ese modo aumentar la
probabilidad de éxito del proyecto. Algunos se refieren a este enfoque como
“fallar rápido y barato” aunque nosotros preferimos ponerlo en términos de
asegurar el éxito desde el principio. Segundo, DAD promueve la auto-
organización mejorada mediante una gobierno efectivo basado en la idea de
que los equipos y los proyectos ágiles se encuentran dentro del ámbito y de
las limitaciones del ecosistema mayor que forma la empresa.
Consecuentemente, DAD recomienda que se adopte una estrategia efectiva de
gobierno que proporcione una guía y que facilite el éxito a los equipos ágiles.
Tercero, DAD promueve el desarrollo de soluciones usables, más allá de la
construcción del software. Además de producir software, los equipos DAD
también crean la documentación de soporte, actualizan y/o despliegan el
hardware en el que corre el software, potencialmente cambian los procesos
relacionados con el uso del sistema e incluso pueden motivar cambios en la
estructura organizativa de las personas que usan el software. Cuarto, tal y
como se describió anteriormente, DAD promueve la perspectiva organizativa
sobre perspectiva de equipo. Quinto, DAD es sensible al contexto y orientado
a metas, no prescriptivo. Un proceso concreto no se ajusta a todas las
situaciones, y los equipos efectivos adaptan su estrategia para reflejar la
situación en la que se encuentran.
Ahora vamos a examinar que significa escalar la agilidad. Cuando muchas
persones escuchan “escalar” piensan frecuentemente en grandes equipos que
están distribuidos geográficamente de alguna manera. Esto ya está pasando, y
algunas organizaciones están teniendo bastante éxito en la aplicación de la
agilidad a este tipo de situaciones, pero frecuentemente escalar la agilidad
implica además otros aspectos. Uno de ellos es la aplicación de la agilidad en
entornos regulados, tanto por requisitos legales como opcionales (como
CMMI o ISO). Otros aspectos son la complejidad de la solución desarrollada,
o integración de diferentes organizaciones en los proyectos (como es el caso
del outsourcing). La siguiente figura resume los potenciales factores de
escalabilidad que se deberían considerar cuando se define una estrategia ágil
personalizada.
 Resumen
El marco de trabajo para procesos Disciplina Ágil de Desarrollo (DAD)
proporciona un enfoque pragmático desde el cual escalar estrategias ágiles
para afrontar las situaciones únicas en las que se encuentran los equipos.
DAD trata de manera explícita las complejidades que afrontan los equipos
ágiles en las grandes empresas, aspectos que muchas metodologías ágiles
prefieren pasar por alto. Estos incluyen como poner en marcha equipos ágiles
de manera práctica, como afrontar la arquitectura dentro del ciclo de vida,
como tratar la documentación de manera efectiva, como afrontar los aspectos
de calidad en un entorno empresarial, como aplicar las técnicas de análisis
ágil para afrontar la miríada de preocupaciones de los actores involucrados, y
muchos otros aspectos.
 4 INTRODUCCIÓN AL CASO DE ESTUDIO
A continuación vamos a describir lo que se podría esperar encontrar en un
proyecto DAD típico usando un caso de estudio ficticio basado en un banco
minorista llamado “BigBank”. La compañía quiere comenzar un proyecto
para permitir a los posibles nuevos clientes la solicitud online de una
hipoteca. La solución debería ser sencilla de usar tanto en un navegador de
ordenador como en los dispositivos móviles.
Después de intentar Scrum con diferentes equipos de proyecto, BigBank
se había dado cuenta que necesitaban adoptar un método ágil que diera
respuesta a los retos específicos a los que se enfrentaba la empresa. En
palabras de uno de sus desarrolladores sénior “Scrum nos deja muchos temas
abiertos, y mi equipo no tiene el tiempo para pensar todas las cosas que
Scrum no indica cómo hacer”. Después de investigar un poco decidieron
adoptar el marco de trabajo DAD porque les ofrecía la flexibilidad que ellos
requerían. A BigBank le gustaba la idea que DAD incluya un ciclo de vida
que extiende y mejora el ciclo de vida de Scrum, permitiéndoles aprovechar
la inversión que habían hecho en Scrum. Como DAD no es prescriptivo y
pone el énfasis en el pragmatismo, BigBank reconoció que DAD podría
escalar para dar respuesta a sus necesidades.
Como se ha descrito previamente, DAD es un marco de trabajo para
procesos que proporciona una guía para los cientos de decisiones que se
toman en un proyecto típico. Para el propósito de este caso de estudio, vamos
a comentar solo un pequeño número de estas decisiones, con el objetivo de
ilustrar como DAD puede dar consejos útiles para el ciclo de vida completo
del proyecto. Ciertamente, a favor de la brevedad del caso, se presenta una
versión muy simplificada de lo que representa un proyecto real.
 El equipo
Vamos a presentar al equipo.

Pepa la Propietaria del Producto (PO): Pepa trabaja para Néstor , el

patrocinador principal del proyecto y representante del negocio. Ella no tiene
un perfil técnico pero se le ha pedido que sea la propietaria del producto en
este proyecto. Se siente presionada por tener que trabajar a tiempo completo
en el mismo espacio de trabajo que el resto del equipo de desarrollo.

Ana la Analista de Negocio: Ana es una consultora con muchos años

de experiencia tanto en el modelado y la documentación de requisitos, como
en el diseño de procesos de negocio. Pepa es su jefa.

Leo el Líder del Equipo: Leo era anteriormente un Scrum Master

Certificado pero recientemente asistió a un taller de DAD que le abrió los
ojos respecto a que sus responsabilidades en el contexto corporativo van más
allá de las que típicas del Scrum Master. Consecuentemente, se ha hecho
cargo de liderar al resto del equipo DAD durante este proyecto piloto.

Carlos el Coach: Carlos es un coach certificado Cinturón Verde de

DAD y le saca partido a su experiencia de años identificando patrones que se
repiten, tanto de éxito como de fracaso, en los proyectos ágiles. Actualmente
está haciendo coaching tanto a éste como otros equipos DAD.

Pavel el Propietario de la Arquitectura: Aunque Pavel es claramente

un desarrollador sénior se da cuenta que ser el propietario de la arquitectura
conlleva responsabilidades más allá de ser el desarrollador con más
experiencia del equipo.

Danny el Desarrollador: Danny es un desarrollador junior que ha estado

trabajando dos años en BigBank. Danny está entusiasmado de estar en un
equipo ágil.
 Debbie la Desarrolladora: Debbie es una desarrolladora de nivel
medio que ha trabajado en sistemas web durante toda su carrera. No tiene
muy claro que este nuevo enfoque ágil vaya a funcionar, pero está dispuesta
a intentarlo.

Tara la Tester: Este es el primer proyecto ágil de Tara. Ella había

aplicado prácticas de testeo (pruebas) tradicionales en sus proyectos
anteriores.

Adam el Administrador de Bases de Datos (ABD): Adam siempre ha

trabajado en proyectos en los que la definición requisitos y el diseño se
hacían íntegramente al principio. Espera que su grupo pueda participar en el
diseño y hacer una revisión de los modelos lógico y físico de la base de datos
antes de que comience el desarrollo. Leo le ha explicado que habrán de seguir
un enfoque evolutivo propio de un proyecto ágil, cosa que no le hace muy
feliz. Aunque Adam solo estará disponible para el equipo el 25% del tiempo
para este proyecto, lo tiene como su máxima prioridad.
Ahora vamos a presentar a los actores interesados:

Victoria la Vicepresidenta de IT: Victoria pidió que este proyecto se

usara como piloto del enfoque DAD y le interesa saber cómo este marco de
trabajo puede ayudar a alcanzar los beneficios de la agilidad que no vio
cuando adoptaron Scrum.

Néstor el Representante del Negocio y Patrocinador del Proyecto:

Aunque Néstor patrocina este proyecto, tiene otras muchas
responsabilidades.

Samuel el Scrum Master Certificado: Samuel no es parte del equipo

pero es un observador al que le interesa el desarrollo del piloto. Cree que se
debe aplicar Scrum “a rajatabla” y no tiene muy claro que aporta DAD sobre
Scrum.
 Alexis el Arquitecto Empresarial: Alexis es el responsable de
asegurar que todas las soluciones IT están bien diseñadas y cumplen los
requisitos técnicos como la seguridad, escalabilidad y la tolerancia a fallos.
Le preocupa que los equipos ágiles puedan ignorar los estándares o no
reutilizar recursos técnicos existentes, ya validados para el uso.

Robert el Responsable de operaciones: Robert y su equipo tendrán

que desplegar y dar soporte a esta aplicación cuando entre en producción.

Samira la Supervisora de soporte: Samira gestiona el grupo de soporte

y le preocupa cómo resolverá las incidencias su equipo cuando el sistema esté
desplegado en producción.

Mindy la Vicepresidenta de Marketing: El equipo de Mindy es

responsable de toda la comunicación pública de BigBank. Su equipo tendrá
que desarrollar toda la campaña de marketing para ofrecer este nuevo servicio
a los clientes.

Padma la Líder de la PMO: Padma es responsable de informar del

estado de los proyectos y realizar un análisis de riesgos de la cartera de
proyectos.

El enfoque
Una de las primeras decisiones que debe tomar un equipo que adopte DAD es
cuál de sus cuatro ciclos de vida se debe usar en el proyecto. Siguiendo la
sugerencia de Leo, el Líder del equipo, el equipo escogió usar el ciclo de vida
Ágil/Básico de DAD por las siguientes razones:

El equipo es nuevo en el agilismo, y este ciclo de vida básico

proporciona una estructura suficiente para equipos noveles
El trabajo puede ser identificado, priorizado y estimado (a alto
nivel) al principio del proyecto, aunque se entiende que los
requisitos puedan evolucionar durante el tiempo
Comenzamos el seguimiento de este caso de estudio al principio de la fase de
Inicio.
 5 INICIO
En DAD, la fase de Inicio hace explícitas las actividades necesarias para la
formación del equipo y el lanzamiento del proyecto. Debería ser tan sencilla
y corta como sea posible. Se pretende formar el equipo y realizar el suficiente
modelado y planificación para que el proyecto comience en la dirección
correcta. Estas actividades se realizan a alto nivel para evaluar los principales
aspectos del proyecto a tener en cuenta, confiando que el equipo pueda ir
definiendo y gestionando los detalles a medida que el proyecto vaya
evolucionando.

Reunión de lanzamiento del proyecto: Leo agenda

concierta una reunión con el equipo para realizar el lanzamiento del proyecto.
Se reúnen el lunes por la mañana. Leo le pide a Néstor, el patrocinador, que
comience la reunión explicando la necesidad de un nuevo Portal de
Peticiones de Hipoteca (PPH) y su importancia como iniciativa crítica del
negocio para atraer nuevos clientes a la entidad. Después de que Néstor haya
respondido a varias preguntas del equipo, Leo describe la estrategia para
desarrollar la solución PPH usando el marco de trabajo DAD. Él explica al
equipo que ha limitado a tres semanas la duración de esta fase de Inicio.
Aunque espera que las siguientes versiones de la solución necesiten fases de
Inicio más cortas, le parece prudente comenzar con mayor dedicación esta
vez, ya que es el primer proyecto con DAD del equipo y parte de la fase se
dedicará a la formación. El objetivo/hito de esta fase es conseguir una visión
consensuada del proyecto por parte de todos los actores interesados. Leo
explica que esto implica que tendrán que hacer el “esfuerzo justo” para
definir los elementos que se encuentran habitualmente en la definición de un
proyecto, aunque en un formato ágil. Usando un proyector, Leo revisa las
nueve metas que DAD propone para su fase de Inicio.
Leo: Parece que estamos en buen camino para cumplir estas metas. Ya
hemos formado el equipo inicial. Y para desarrollar una visión común,
trabajaremos en paralelo en el resto de metas. Vamos a discutir la estrategia
que seguiremos en las siguientes tres semanas y la información que debemos
recopilar para cumplir las siguientes metas:

Alinearse con los estándares corporativos: Leo le pide a

Pavel que convoque una reunión con Alexis para obtener
información de cualquier recurso de arquitectura, procesos,
estándares o guías de las cuales deba estar enterado el equipo, y
sugiere que le pida a Alexis que comparta información sobre la
visión para la arquitectura corporativa para que la nueva
solución esté correctamente alineada.
Explorar el alcance inicial: Pepa planifica agendar reuniones
con representantes de negocio (Néstor y varios otros) para
construir una lista priorizada de requisitos ágiles (historias).
Ana, la analista de negocio, ayudará a Pepa en la facilitación de
estas reuniones.
Identificar la estrategia tecnológica inicial: Pavel invertirá
algún tiempo con Leo y el resto de los desarrolladores para
consensuar una estrategia inicial de arquitectura usando técnicas
de modelado ligero.
Desarrollar un plan inicial de versiones: Una vez que se ha
determinado el alcance inicial, Leo le pedirá a Pepa que agende
una reunión para realizar una estimación conjunta con el equipo
y poder definir un plan de entregas.
Asegurar la financiación: Néstor ha decidido presupuestar las
tres semanas de la fase de Inicio y ha dejado reservado un
presupuesto para los siguientes cuatro meses de las fases de
construcción y transición. Asume que el presupuesto podrá ser
negociado según los resultados de la fase de Inicio.
Crear el entorno de trabajo: Actualmente el equipo está
desperdigado en tres plantas diferentes del edificio y Leo quiere
unificar su espacio de trabajo en una zona común. Para ello
trabajará con los responsables del edificio.
Identificar riesgos: Leo le pide a Pavel que elaboren juntos una
lista de riesgos con sus respectivas estrategias para mitigarlos.
Esperan que la mayoría de dichos riesgos sean de tipo técnico, y
que deriven de la estrategia técnica y de los requisitos no
 funcionales identificados durante el inicio del proyecto.

Semana uno del Inicio

Para asegurar que todo el mundo tiene una base metodológica común y que
está familiarizado con los fundamentos de la agilidad y del marco de trabajo
DAD, el equipo asiste al taller de 3 días Disciplined Agile Delivery
Experience [6]. El jueves comienzan una serie de talleres para obtener un
consenso de los diferentes actores interesados en la visión de la solución,
meta correspondiente a la fase de Inicio de DAD. En la mayoría de estas
reuniones, participarán el equipo principal y los actores concretos que estén
interesados en cada reunión. Carlos asistirá a todas las reuniones para ayudar
en su facilitación. Después de realizar un taller, orientar al equipo es mucho
más sencillo y le ayuda a asentar los conceptos aprendidos de manera
efectiva.
Pepa trabaja en la identificación del alcance inicial. Pepa se reúne con
los actores interesados de negocio para comenzar a trabajar en la
identificación del alcance inicial. Tomando como referencia el diagrama de
meta Explorar el Alcance Inicial, el equipo decide realizar algo de modelado
de uso para identificar los requisitos de alto nivel. El diagrama sugiere que
este tipo de modelado es una buena estrategia para usar en los primeros
proyectos con DAD. Ellos escogen usar el Mapa de Historias[7] para
organizar los flujos del sistema en épicas de alto nivel y en historias, cada una
de las cuales escrita en una tarjeta diferente. Las épicas se escriben en tarjetas
naranjas y las historias en tarjetas amarillas. En la parte posterior de las
tarjetas encontramos el conjunto de criterios de aceptación de alto nivel que
describen las condiciones que deben cumplirse para que la historia de la
tarjeta sea considerada completa por Pepa (la propietaria del producto).
Muchas de las historias serán demasiado grandes para ser implementadas en
una única iteración y por tanto deberán ser descompuestas en historias más
pequeñas, pero de momento son suficientes para comunicar el alcance de alto
nivel.
 Pavel lidera al equipo en la identificación de la estrategia técnica
inicial. Leo y los desarrolladores se reúnen para evaluar las estrategias
técnicas potenciales que podrían usarse en esta solución. Examinan la hoja de
ruta tecnológica de BigBank, los estándares corporativos y la documentación
de la arquitectura de referencia para ver si existen recursos que puedan reusar
como plantillas, servicios/APIs o fuentes de datos. Como DAD sugiere en la
meta Identificar la estrategia técnica inicial, ellos escogen describir la
estrategia técnica a alto nivel, reunir sus ideas en reuniones informales de
modelado y concentrarse en una única arquitectura candidata. El taller de
visión de la arquitectura ocupa un día completo. El equipo puede encontrar
una sala de reuniones amplia para realizar esta reunión con una mesa grande
y mucho espacio en las paredes.
Por desgracia solo había una pequeña pizarra blanca en la pared. Leo
encargó varios rollos de “papel para pizarras blancas” que se engancha a la
pared por la fuerza electroestática. Después de retirar varias cuadros
motivacionales, usaron dicho papel para convertir las paredes en pizarras de
trabajo.
Leo comunica al equipo que Alexis mencionó que el grupo de
Arquitectura Empresarial (EA) quería alejarse de la arquitectura monolítica
actual e ir a medio plazo hacia un modelo basado en micro-servicios. Ellos
también querrían usa la técnica de las “funcionalidades activables” para ser
capaces de compartir todo el código en la rama principal en vez de trabajar en
varias ramas dedicadas a nuevas funcionalidades, y controlar lo que recibe
realmente el usuario mediante configuración. Dicha técnica proporcionará
también aislamiento de las funcionalidades desplegadas, para que ningún
punto único de fallo pueda tirar todo el sistema abajo.
Esta estrategia, que reducirá el riesgo de los despliegues en el futuro al
hacerlos más pequeños y frecuentes, está incluida en la hoja de ruta
tecnológica de BigBank, creada por el equipo de arquitectura empresarial. La
aplicación PPH se construirá pues sobre esta estrategia de micro-servicios y
de funcionalidades activables. El código y los datos existentes se irán
actualizando a lo largo del tiempo según sea necesario[8].

Durante el taller de visión de la arquitectura

Adam destaca la necesidad de crear un modelo de datos exhaustivo antes de
comenzar la fase de Construcción. Carlos responde que con el enfoque ágil el
diseño detallado irá emergiendo durante el curso del desarrollo. En este
momento del tiempo el equipo solo necesita invertir lo justo en modelado
para ir en la buena dirección. El equipo ha realizado suficiente toma de
requisitos y modelado de la arquitectura para sustentar la planificación que se
hará la siguiente semana. Adam no está nada cómodo con esta estrategia,
pero acepta esperar y ver cómo funciona en la práctica.
Una de las cosas que debe poder hacer el Portal de Peticiones de
Hipotecas (PPH) es determinar si alguien es actualmente cliente de BigBank.
Pavel indica que la hoja de ruta tecnológica de BigBank se basa en una
colección de servicios web reutilizables que harán esta y otras cosas. Esos
servicios web se están desarrollando actualmente y concretamente el servicio
de acceso a esa información básica del cliente estará disponible en dos meses.
El equipo que desarrolla estos servicios se llama “Equipo
Rayos-X” y sigue un enfoque de proyecto tradicional, con un ciclo de vida de
cascada. Adam dice que sería más sencillo escribir sentencias simples de
SQL en su código para acceder a los datos existentes. Pavel está de acuerdo
en que sería un enfoque más sencillo, pero que sería una solución de corto
plazo que incrementaría la deuda técnica global en BigBank, debido a que
otra aplicación estaría acoplada directamente con las fuentes de datos
existentes. Carlos sugiere que el equipo debería trabajar de una manera más
tradicional y con la perspectiva organizativa para reflejar la estrategia global
de BigBank. Un poco de trabajo adicional de coordinación resultará en una
solución más robusta, aunque incrementa el riesgo que afronta el equipo
porque ahora dependerán de que el Equipo Rayos-X proporcionen el servicio
web que se requiere.
Al finalizar la jornada el equipo tiene un conjunto de diagramas sobre la
arquitectura tecnológica y la interfaz de usuario que resumen una estrategia
que creen que funcionará para el proyecto. Toman fotos de estos dibujos con
su teléfono móvil y las cuelgan en la wiki del proyecto, dentro de la sección
del manual de arquitectura.

Semana dos del Inicio

Pepa se reúne con los actores interesados de negocio para priorizar el
trabajo. Pepa revisa el mapa de historias con los demás actores interesados
de negocio. Ellos han decidido usar la estrategia de lista de ítems de trabajo,
descrita en DAD, que incluirá el trabajo pendiente en forma de las historias
de usuario, relacionadas a la funcionalidad, y otros tipos de trabajo necesario
para completar la solución. Ellos priorizan estas tarjetas para representar la
importancia de las historias de usuario dentro de la lista de ítems de trabajo
del proyecto. Pepa explica al equipo que estas prioridades pueden cambiar
según el consejo de Pavel, el Propietario de la Arquitectura.
Leo, Pepa y Pavel se reúnen para identificar la lista inicial de
riesgos. Leo y Pavel le preguntan a Pepa sobre los requisitos no
funcionales de la solución. ¿Cuántos usuarios se esperan? ¿Durante qué horas
se darán los picos de uso y cómo serán éstos? ¿Cuántas transacciones por
hora espera? Ellos continúan preguntando sobre otros muchos aspectos
relacionados con la robustez, seguridad, rendimiento y escalabilidad. Esos
requisitos no funcionales se capturan en una pizarra, como paso intermedio
para transcribirse después en una página de la wiki, que estará a disposición
de todo el equipo como referencia y para ser actualizada cuando sea
necesario.
A partir de estos requisitos técnicos recién identificados, el equipo
evoluciona su visión de la arquitectura y discute cuales de sus aspectos
podrían ser más complicados de implementar. Ellos identifican los riesgos
clave del proyecto y discuten de que maneras podrían mitigarlos. Idealmente,
sería preferible mitigar cada riesgo mediante la implementación con éxito de
una funcionalidad relacionada con este, pero a veces también podría usarse
una prueba de concepto técnica, llamada “spike”.
Pavel y Pepa se reúnen para revisar la lista de ítems de trabajo
priorizada. Pavel repasa la lista de riesgos para evaluar las prioridades de
trabajo. Él identifica algunas partes de la solución que deberían abordarse con
mayor prioridad para mitigar algunos riesgos técnicos clave. La estrategia es
construir un esqueleto técnico completo de la solución que implemente lo
antes posible aquellos requisitos con riesgo técnico e importantes, y así
validar la arquitectura con código real. Esto ayudará a eliminar muchos de
estos riesgos al principio de la fase de Construcción, incrementando de ese
modo la probabilidad de éxito del equipo. Sorprendentemente, este enfoque
de mitigación inicial del riesgo no forma parte de Scrum y esto causa
frecuentes sorpresas desagradables en la parte final de los proyectos.
Pepa y el equipo de desarrollo realizan una estimación de la lista de
ítems de trabajo. Tras revisar las estrategias del diagrama de meta
Desarrollar el plan inicial de entregas el equipo escoge la técnica del
Planning Poker para realizar la estimación. Como no disponen de juegos de
cartas de Planning Poker deciden utilizar para esto una aplicación de móvil.
El equipo aprendió esta técnica en el taller DAD que hicieron la semana
anterior. Ellos recorren metódicamente las historias y, para cada una de ellas,
el propietario del producto describe la historia y su criterio de aceptación, y
acto seguido el equipo realiza su estimación. Debido a que es la primera vez
que usan esta técnica con requisitos reales, les cuesta bastante más tiempo del
previsto.
Después de tres horas han completado un 20% de la estimación de las
historias. Aunque han ido acelerando su ritmo, ven claro que completar el
Planning Poker les costará unos dos días al ritmo actual. Carlos sugiere usar
una técnica llamada estimación de tamaño relativo. Debido a que el equipo
ha alcanzado un punto en que tienen un entendimiento compartido de cómo
estimar las cosas, esta estrategia es ahora una opción viable. Ellos liberan la
mesa de la sala y, usando una cinta adhesiva de color, dividen la superficie de
la mesa en seis “secciones de tamaño”, en este caso 1, 2, 3, 5, 8 y ?. El
interrogante es para historias de serán más grandes de ocho (y que serán
estimadas posteriormente vía Planning Poker), algo que el equipo debe
discutir con más detalle, o algo que debe reorganizarse en historias más
pequeñas. Cada persona toma un subconjunto de las tarjetas con historias y
las va situando en la sección del tamaño que cree que les corresponde.
Mientras hacen esto, observan como los demás sitúan las cartas. Cuando ven
algo con lo que no están de acuerdo, por ejemplo alguien que ha indicado que
una historia debería tener tamaño tres pero ellos piensan que es cinco, dicen
algo como “¿quién piensa que es tres?” y lo comentan. Las historias se
estiman en paralelo por los miembros del equipo, cosa que acelera el proceso.
El equipo invierte una hora y cuarto estimando el resto de las historias,
dejando aparte cinco que creen que deben explorarse con mayor detalle. Pepa
acepta hablar con los actores interesados para desarrollar mejor estas historias
durante los siguientes días.
El equipo crea un plan de entregas. El equipo decide que realizarán
iteraciones de dos semanas durante la fase de Construcción. El total de puntos
relativos para el trabajo que han estimado es 160. El equipo no tiene claro
cuantas iteraciones deberían planificar para asegurar que pueden completar el
trabajo. Carlos les tranquiliza explicado que este enfoque ha funcionado en
otros proyectos. Saben que en un proyecto ágil no se requiere invertir
semanas en realizar estimaciones detalladas del trabajo, pero sin una idea de
lo que se puede completar en una iteración es difícil de planificar. Así pues
sugiere al equipo emplear medio día en planificar el trabajo para la primera
iteración de Construcción. Después de descomponer el conjunto de
elementos/historias que se han asignado a la primera iteración en tareas
detalladas y estimarlas, comprueban cuando del trabajo analizado se puede
completar con las horas disponibles en una iteración de dos semanas. Esta
cantidad de trabajo les permite calibrar cuantos puntos puede entregar en una
iteración. Carlos advierte a Pepa que es únicamente una estimación intuitiva
porque es difícil estimar sin ninguna experiencia real basada en la
composición del equipo, la tecnología usada y otros factores dependientes del
contexto. El equipo decide dedicar la siguiente mañana a estimar el proyecto.
Estimando el número de iteraciones requeridas. Basándose en la sesión
de planificación detallada, el equipo determina la mañana siguiente que
pueden completar los cinco elementos de mayor prioridad a partir de la lista
de ítems de trabajo. Estos elementos suman un total de veinte puntos
relativos. Basado en el total de 160 puntos para toda la lista de historias, con
una “velocidad” esperada del equipo de veinte puntos, parece que se tardaría
ocho iteraciones en completar la aplicación. Carlos sugiere que, considerando
el grado de incertidumbre del proyecto que se deriva de que el equipo, la
tecnología y el proceso sean nuevos, de debería añadir una contingencia al
plan de entregas. Sugiere que se añadan dos iteraciones más al calendario y
de esta manera se planifica un total de diez iteraciones. Esto prepara el
proyecto para “sorpresas” no esperadas, incluyendo posibles aumentos al
alcance, de manera que no se ponga en peligro la fecha de entrega. Así pues
acuerdan que la fase de Construcción la formarán diez iteraciones de dos
semanas. Esto les proporciona una fecha a los actores interesados de negocio
de la que pueden depender. La mayor frustración que tienen Néstor y de otros
actores interesados de negocio con el grupo de IT es su falta de capacidad de
entregar los proyectos a tiempo. Una de las razones que se haya adoptado el
enfoque ágil disciplinado es afrontar este problema.
Como se puede ver en el diagrama de la meta Desarrollar el Plan de
Entregas Inicial, un enfoque alternativo de planificación habría sido
establecer la expectativa que el sistema se desplegaría cuando fuera posible
entregar la funcionalidad. A esto se le llama una planificación centrada en
alcance, alternativa a la planificación centrada en la fecha que seleccionó el
equipo.

Carlos sugiere que el equipo consensue el tiempo que cree que necesitará
para realizar la transición a los actores interesados. DAD reconoce que los
actores interesados deben incluir otros colectivos aparte de los usuarios
finales de la aplicación, como son los de Soporte y Operaciones, que serán
responsables del soporte y del mantenimiento necesarios para la solución una
vez que esté en producción. Carlos recomienda que la fase de Transición se
extienda más allá de la fecha de la entrada en funcionamiento de la aplicación
y facilitar así el disponer de tiempo suficiente para la transferencia a los
grupos que harán el soporte. Ellos consensuan que una duración de tres
semanas sería suficiente para la Transición. El plan de entrega también
muestra otras tres semanas de tiempo para el uso de la aplicación, periodo
que BigBank llama habitualmente “garantía” y que si se supera con éxito
supone el cierre formal del proyecto. DAD tiene un hito llamado Actores
satisfechos para significar que se ha completado la entrega o el proyecto.
Leo crea un diagrama de Gantt de alto nivel para mostrar el calendario de
entregas y los hitos asociados. Esta programación se irá actualizando
periódicamente durante la fase de Construcción según sean los resultados
obtenidos.

Semana tres del Inicio

Leo trabaja con los responsables del edificio para montar

un área de trabajo común para el equipo. Durante las dos últimas semanas
Leo y Carlos han recorrido el edificio buscando una buena área de trabajo en
la que colocar el equipo. Han seleccionado un espacio de 8 x 8 metros a la
que han llamado la “Zona Ágil”. Durante esta semana colaboran con Pepa y
el equipo de desarrollo para organizar el espacio de manera que favorezca la
colaboración del equipo. Carlos sugiere varias disposiciones de mesas a partir
de experiencias positivas en otras organizaciones. Este plano muestra el
aspecto de la nueva área de trabajo. Las paredes externas son paneles
separadores altos, de casi dos metros, excepto los paneles laterales que son de
un metro de altura. En la esquina superior-derecha del espacio hay dos
pizarras grandes y también queda espacio para un panel de tareas ágil, donde
pegarán tarjetas de colores para mostrar el avance de las tareas asociadas a
cada elemento de trabajo. Esta es la zona donde el equipo realizará las
reuniones diarias para coordinarse. También hay una pizarra junto al panel de
tareas para realizar modelado ad-hoc. Los dos pequeños rectángulos
inclinados representan pizarras con ruedas. En la parte superior-izquierda el
equipo dispone de una mesa para actividades colaborativas como las
reuniones de planificación, revisión y retrospectiva de las iteraciones.
También se ha colgado un monitor de la pared de manera que se puedan
realizar en cualquier momento demostraciones ad-hoc a actores interesados.
También es útil en otras reuniones como la revisión de la lista de trabajo y de
las estimaciones. El equipo piensa que en algún momento les gustaría migrar
su panel de tareas físico a uno virtual que se mostraría en este monitor. Un
punto clave de la filosofía del diseño del espacio de trabajo es que el equipo
no necesite trabajar fuera del espacio más allá de situaciones excepcionales
como reuniones generales de la empresa. Esto fomenta la colaboración del
equipo y muestra donde deben estar éstos para poder ayudarse entre sí en
cualquier momento.
Pavel trabaja con los desarrolladores para montar las herramientas
de desarrollo. Al final de la primera semana, el equipo de desarrollo
comienza a montar el entorno de desarrollo y sus herramientas de soporte. En
este proyecto se usará un conjunto de tecnologías basadas en Java. Siguiendo
el espíritu de permitir al equipo auto-organizarse Leo permite que cada
desarrollador use el IDE de su elección. Ellos instalan GIT como su
repositorio de código fuente y como grupo consensuan una estrategia para la
gestión del código fuente y la creación de ramas. Posteriormente instalan un
servidor de integración para compilar el código y lanzar las pruebas de
regresión del desarrollo (tests unitarios) cada vez que un desarrollador integre
código en el repositorio. Aunque les gustaría poder crear scripts para permitir
a los testers desplegar autónomamente las versiones a un entorno de pruebas
separado, deciden dejarlo para la fase de Construcción por falta de tiempo.
Para ello convencen a Pepa de añadir un elemento de trabajo de alta prioridad
destinado a crear este scripting de despliegue.
Leo lidera el equipo durante la actualización de la lista de riesgos. El
equipo dedica unos treinta minutos a pensar conjuntamente riesgos
potenciales que pueden encontrarse. Ellos documentan estos riesgos en una
pizarra inicialmente, estimando la probabilidad de que se materialicen (en
porcentaje) y el impacto si ocurrieran (en una escala de uno a diez). Una
multiplicación sencilla de ambos factores nos da la severidad del riesgo que
se usa para priorizar la lista de riesgos. Después de la reunión Leo traslada
esta tabla a una hoja de cálculo que imprime y cuelga junto al panel de tareas.
La lista de riesgos resultante tiene este aspecto:
Riesgo y estrategia de Prob. Impacto Severidad
mitigación
La entrega del Servicio 60% 8 4.8
Web de clientes se retrasa

Pavel seguirá de
cerca el avance del
Equipo Rayos-X

Los actores interesados no 30% 8 2.4

están disponibles

Pepa trabajará con

ellos para asegurar
su disponibilidad
Néstor dará soporte
a Pepa

La estrategia de 10% 10 1
arquitectura no funciona

Se validará en la
Iteración C1 con
código real

Se publicarán nuevas 100% 1 1

versiones de los
navegadores soportados

Debbie monitorizará
los anuncios de
lanzamiento
El equipo
desarrollará pruebas
automatizadas
 Resumiendo el trabajo de Inicio en una visión. Pepa, Pavel, y Leo
trabajan conjuntamente para consolidar su trabajo de las tres últimas semanas
en una visión de resumen que puedan comentar con los actores interesados.
Ellos escogen presentar este trabajo en forma de una presentación
PowerPoint. Carlos proporciona una plantilla usada con equipos similares de
otras organizaciones. Dedican una o dos transparencias a cada uno de los
siguientes temas:

Objetivos de negocio de la iniciativa

Criterio de éxito
Roles y actores interesados clave
Visión
Alcance inicial del proyecto
Estrategia técnica inicial
Plan de entregas inicial
Detalles el entorno de trabajo
Riesgos iniciales del proyecto

La revisión del hito de Visión de los actores interesados. Al final de la

fase de Inicio, como parte del hito de Visión de los actores interesados, se
realiza una revisión este documento con los actores clave. La reunión se
programa con una hora de duración y asiste el equipo de desarrollo completo,
además de actores interesados de negocio, operaciones y soporte.
Adicionalmente, asisten otros actores interesados de los grupos de
arquitectura empresarial, documentación técnica, formación, auditoría interna
y de la oficina de gestión de proyectos (PMO). Aunque es probable que parte
de este grupo tan grande no asista al resto de reuniones del proyecto, es
importante que acudan a esta reunión para revisar la Visión y evitar sorpresas
desagradables al final del proyecto.
Pepa, Leo y Pavel presentan las conclusiones de la fase de Inicio. Se
reservan unos veinte minutos para resolver preguntas de los actores
interesados.
Leo y Pepa finalizan la reunión pidiendo un “acuerdo general”, suficiente
para dar por conseguida la meta de Visión de los actores interesados y poder
comenzar así la fase de construcción el lunes siguiente.
Néstor el patrocinador de negocio y Victoria, la Vicepresidenta de IT
felicitan al equipo por su excelente trabajo en esta fase de Inicio y están de
acuerdo en que el proyecto es razonable tal y como está enfocado. Carlos
recuerda a todo el mundo que, aunque la Visión crea una base compartida
entre los actores interesados y el equipo, y que ayuda a que todos trabajen en
la dirección adecuada, dicha Visión será revisitada al final de cada iteración
para asegurarse que el proyecto se desarrolla como se ha descrito en esta
reunión. Finalmente se levanta la sesión. El equipo está emocionado de
comenzar la Construcción el lunes. Están de acuerdo en que ha valido la pena
invertir tres semanas a hacer la planificación y modelado de alto nivel.
El equipo dedica el resto del día a trasladarse desde sus mesas actuales a
la Zona Ágil.
 6 CONSTRUCCIÓN: ITERACION C1
Después de una fase de Inicio breve y ligera, en la cual el equipo invirtió el
tiempo necesario para construir un consenso sobre el enfoque que iban a
tomar, están listos para comenzar la construcción. Debe tenerse en cuenta que
es imposible dedicar el espacio necesario en este libro a explicar de manera
exhaustiva lo que sucedió con el equipo. Así pues se describen los eventos y
asuntos clave que el equipo encontró y las estrategias que se tomaron para
afrontarlos. La transparencia propia de un proceso ágil combinada con la
autoevaluación constante que hace el equipo facilitan la identificación pronta
de los problemas, que así suelen solucionarse de manera rápida y abierta. Se
ha de tener en cuenta también que este proyecto siguió el ciclo de vida
Ágil/Básico de DAD (basado en Scrum). Para otros ciclos de vida, las
experiencias serían bastante diferentes.
Día 1. Normalmente el equipo invierte la mitad del primer día de la
iteración realizando la sesión de planificación de la iteración. En este caso, el
equipo invirtió algún tiempo durante el Inicio para planificar la primera
iteración y mejorar así la calidad de las estimaciones y del Plan de entregas,
por ello casi toda la planificación de la primera iteración ya está hecha.

Hay seis historias, que suman veinte puntos en

total. Tres de estas historias contienen funcionalidades con importancia
técnica que validarán, al implementarse, si la estrategia de arquitectura que
escogió el equipo durante la fase de Inicio funcionará en la realidad. Podría
ser que el equipo descubra que la estrategia no funcione y, en tal caso,
tendrán que evolucionar el enfoque técnico según su aprendizaje. Este es un
aspecto de la estrategia de ciclo de vida de DAD, basada en el valor/riesgo,
donde el riesgo técnico se considera a la hora de priorizar el trabajo,
facilitando que se consiga el hito de Arquitectura validada pronto durante la
construcción.
El equipo tiene pendiente crear el panel de tareas. En la pizarra que hay en
la esquina de la Zona Ágil crean columnas para los estados Pendiente, En
ejecución, Necesita validación y Completo. Carlos indica que, según su
experiencia, los equipos adaptan estos nombres a los que les parecen más
efectivos, pero opina que estas columnas son una buena configuración del
tablero para comenzar. El equipo de trabajo crea las tarjetas para todos los
elemento de trabajo/historias de la iteración y las sitúan en la columna
izquierda, ordenándolas de arriba a abajo según su prioridad.

A continuación comienzan la reunión de coordinación para planificar el

trabajo del día. Cada miembro toma una o dos tarjetas para las tareas en las
que piensan trabajar durante el día y las mueven a la columna “En ejecución”.
Además escriben sus iniciales en las tarjetas para facilitar que todos sepan
quien está trabajando en cada tarea. La suma de las horas de todas las tarjetas
son 240 horas de trabajo, que deben completarse en la iteración de diez días.
El equipo asume que durante la iteración aparecerá probablemente trabajo no
esperado y por se asegura que estas 240 horas son menos del 80% de la
capacidad de la iteración, como medida de contingencia.
Leo facilita esta reunión, pidiendo a cada miembro del equipo que
describa que ha planificado realizar durante el día, si algo le está retrasando o
impidiéndole avanzar, y si necesitan ayuda de alguien para completar su
trabajo.
Después de la reunión de coordinación, Leo crea una tabla de burndown
en una hoja DIN A0 (de papelógrafo) y la sitúa junto al tablero de tareas para
ayudar al equipo a controlar el ritmo de avance del trabajo planificado para la
iteración actual. La tabla de burndown muestra las 240 horas de trabajo
pendiente inicial y será actualizada diariamente para mostrar las horas
reducidas por el trabajo completado durante el día.
Leo agenda durante el día una reunión de Revisión de la iteración con los
participantes que tendrá lugar al mediodía del último día de la iteración.
También reserva otra reunión con el equipo que se realizará posteriormente a
la de Revisión, llamada comúnmente Retrospectiva, para discutir el resultado
de la iteración y pensar como el equipo puede mejorar.
Día 2. El equipo se reúne a las 9 horas, con puntualidad, delante del panel
de tareas para su reunión de coordinación diaria. Leo recuerda al equipo que
aunque la reunión del primer día les ocupó media hora, la meta es conseguir
que estas reuniones queden por debajo de los quince minutos. Leo también
muestra una nueva página que ha colgado junto al panel de tareas, que
contiene su propuesta para la Definición de Hecho (DoD en inglés). Él
explica que para cada una de las tareas del panel es importante que todo el
equipo conozca que significa “hecho ” con precisión. La hoja tiene el
siguiente aspecto:
Definición de Hecho (DoD)

Todo el código probado e integrado en el repositorio

Todas las pruebas unitarias dan resultado positivo
Todos las pruebas de aceptación están escritas y dan
resultado positivo
Se cumplen los estándares de usabilidad
Se realizan las revisiones entre pares
Se actualiza el libro de arquitectura si es necesario

Esta hoja servirá como recordatorio que, antes de considerar un elemento

como “hecho”, se deben realizar más cosas que simplemente programar el
código y realizar unas pruebas básicas. El equipo discute la DoD propuesta y
sus implicaciones en las tareas de desarrollo. Durante la discusión Danny
destaca que piensa que Leo ha olvidado incluir en la DoD la necesidad de
actualizar las pantallas de ayuda para reflejar las nuevas funcionalidades. El
equipo actualiza la DoD para incluir este recordatorio y esperan ir
actualizando de nuevo esta lista cuando vayan descubriendo más necesidades
de los actores interesados.
Mientras los miembros del equipo van informando a los demás respecto a
lo que pudieron completar ayer, lo que tienen previsto hacer hoy y si tienen
algún bloqueo en su trabajo, Leo registra cuantas horas de trabajo pendiente
se han reducido en el panel de tareas. Una vez que Pavel, Debbie y Danny
han informado al resto, Leo hace lo propio. Las horas que los cuatro
miembros del equipo han completado suman quince. Sin embargo, la tabla de
burndown indica que para completar las 240 horas de trabajo en la fecha de
fin de la iteración se necesitan completar veinticuatro horas de trabajo cada
día. Leo destaca esta diferencia al equipo y comenta “no completamos tanto
trabajo ayer como esperábamos, pero tengo en cuenta que somos nuevos con
este proceso y que hemos dedicado tiempo a actividades que no aparecen en
este panel de tareas, tales como ajustar nuestros scripts de compilación y
otras tareas de montaje de nuestros entornos de desarrollo. Así que, como
muestra el plan de iteración, nos hemos retrasado. Como equipo deberíamos
pensar cómo ponernos al día”.
Día 3. Durante la reunión diaria de coordinación aparecen algunos
problemas. Danny dice que está teniendo problemas con la tarea que tiene en
marcha y que estimó en tres horas. No sabe cómo va a resolver esta dificultad
técnica y piensa también que su estimación era muy optimista, suponiendo
que esta tarea consumirá al menos unas nueve horas. Leo explica que esto no
es extraño y que por suerte el equipo tiene una contingencia en el plan de
iteración para absorber trabajo inesperado. Leo pregunta si alguien puede
ofrecerse voluntario para trabajar en pareja con Danny y superar este
obstáculo técnico. Desgraciadamente nadie se ofrece voluntario porque todos
están más preocupados en no retrasarse con su propio trabajo.

Carlos el Coach interviene y recuerda a todos los miembros del equipo que
deben sentirse responsables de completar todas las tareas de la iteración, con
independencia de quien las acepta inicialmente, si quieren
cumplir el compromiso con el propietario del producto. Debbie se decide y se
ofrece como voluntaria para ayudar a Danny. Como resultado de incrementar
la estimación para la tarea de Danny y de no cerrar ninguna de las demás, el
equipo solo completó diez horas en vez de las veinticuatro esperadas. La
tabla de burndown muestra que el equipo se está retrasando más de lo
recuperable.
Aunque esto es claramente un problema, la parte positive es que usando
una tabla así se identifican inmediatamente los retrasos y el avance real de la
iteración es transparente a todo el equipo. Danny se ofrece a quedarse
trabajando hasta tarde y tratar de recuperar el ritmo. El resto del equipo
decide seguirle y ayudar. Pavel no puede quedarse porque necesita recoger a
su hijo de la guardería pero promete conectarse por VPN desde casa y
trabajar en sus tareas.
Días 4 a 7. El equipo continua trabajando y recuperan la mayoría del
retraso acumulado. A pesar de eso, parece que no podrán completar las seis
historias estimadas para la iteración.
Día 8. Durante la reunión de coordinación diaria del octavo día el equipo
discute que hacer sobre el hecho que no entregarán todo el trabajo
comprometido para la iteración. Carlos aconseja que es mejor entregar el
máximo de tareas “hechas” según la definición que se consensuó, que
intentar entregarlas todas pero solo completadas al 80%. El equipo decide
dejar de trabajar en la funcionalidad Aprobación de petición básica, que
Danny había comenzado el día anterior, y concentrarse en otras cinco
elementos. Ellos le notifican esta decisión inmediatamente a Pepa, la
propietaria del producto, de manera que ella pueda informar a los actores
interesados de negocio y se mantenga la transparencia sobre el trabajo del
equipo.
Adam, el ABD, es escéptico sobre trabajar de una manera ágil incluso
después de haber ido al curso con el resto del equipo. Durante el sprint
trabajó en pareja con los miembros del equipo cuando se necesitaba algún
desarrollo en la base de datos, tal como crear tablas o añadir columnas a
tablas existentes, pero cada vez que lo hizo se quejó porque prefería hacer el
diseño completo de la base de datos desde el principio. Durante la reunión de
coordinación identifica esto como un problema, y Carlos se ofrece a comentar
con él estrategias ágiles para el desarrollo de bases de datos al acabar la
reunión. Esta conversación no acaba bien, aunque Carlos comenta ejemplos
de proyectos similares donde el desarrollo incremental tuvo éxito. Adam
decide que él sabe realmente lo que hay que hacer y decide trabajar de
manera secreta en el modelo lógico y físico detallado de datos con la
intención de “salvar al equipo” cuando este descubra finalmente que él tenía
la razón.
Día 9. Pavel y Debbie trabajan juntos para implementar la historia
Guardar borrador de solicitud, una de las tres historias clave que deberían
probar que la estrategia de arquitectura que ha escogido el equipo es válida.
Dos días antes Pavel había completado el trabajo de la historia Solicitar
evaluación online de crédito, que era otra de las historias críticas
técnicamente. Así pues, el equipo no podrá probar complemente que la
arquitectura funciona hasta el final de la iteración C2. Leo trabaja con Pepa
para cancelar la reunión de revisión de hito que se había programado para
mañana y agendarla al final de la iteración C2. Ellos también envían un
correo para explicar por qué se necesita retrasar esta reunión.
Día 10. El equipo dedica la mañana a estabilizar las historias que han
completado, haciendo pruebas exploratorias y solucionando defectos que han
aparecido a última hora.
La revisión de iteración. A primera hora de la tarde se realiza la revisión
de la iteración con los actores interesados. El marco de trabajo DAD sugiere
que esta revisión sea más que simplemente una demostración. También tiene
sentido revisar el estado del proyecto respecto a la visión que se acordó
durante la fase de Inicio. De manera parecida a como se presentó dicha
visión, Leo ha preparado una presentación simple que incluye los siguientes
puntos:

Situar el contexto: ¿Dónde estamos en relación al plan de

entregas?
Resultado de la iteración: ¿Pudo entregar el equipo todos los
elementos a los que se comprometió?
Rendimiento del equipo: ¿Cuál fue la productividad del equipo
(velocidad)? ¿Se ha obtenido una buena calidad?
Demostración de la solución
Actualización de la visión

¿Seguimos el ritmo esperado? Según la tendencia de la

velocidad del equipo: ¿podremos cumplir la fecha de entrega
del plan de entregas definido durante el Inicio?
¿Cuál es el estado de los riesgos más destacados?
¿Cuándo se podrá considerar la arquitectura valida?
¿Existen problemas que deban tratarse?

Preguntas y respuestas

El equipo no confía totalmente en que la nueva funcionalidad se pueda

demostrar sin problemas porque la aplicación ha estado fallando
periódicamente durante las pruebas. Así que Pavel insiste en hacer la demo
para que Pepa no provoque errores. Carlos permite al equipo realizar la demo
esta manera pero les dice que deberían discutir este enfoque durante la
reunión de retrospectiva que tendrán después. Tal y como temían, la demo
falla durante la ejecución de la última funcionalidad. Los actores interesados
sonríen al ver el fallo y el equipo se siente un poco avergonzado. A pesar de
eso, los actores interesados se sienten impresionados de ver software
funcionando tras solo dos semanas de proyecto. Comentan que se sienten un
poco desilusionados porque el equipo no pudo entregar toda la funcionalidad
que había prometido. Carlos menciona que es habitual que los equipos
tiendan a ser demasiado optimistas en las estimaciones cuando son nuevos en
la agilidad. La agilidad es una novedad para el equipo y les costará algunas
iteraciones aprender a trabajar juntos con efectividad y a tener certeza que
pueden cumplir lo que prometen.
La retrospectiva. Al acabar la reunión con los actores, el equipo
permanece en la sala para realizar su reunión de retrospectiva. Carlos facilita
la reunión, pidiendo que cada miembro diga lo que cree que fue bien, lo que
no funcionó y algunas ideas de cómo cree que podría mejorar el rendimiento
del equipo. Los comentarios que aparecen durante la reunión son:

Leo piensa que el equipo hizo un gran trabajo teniendo en

cuenta que estaban haciendo su primera iteración ágil y Carlos
se muestra de acuerdo.
Tara está preocupada porque el peso de las pruebas descansan
en sus hombros y la mayoría de las historias no estaban
realmente listas para ser probadas hasta el séptimo día de la
iteración. Esto le impidió realizar todos los casos de prueba que
esperaba poder hacer. El equipo está de acuerdo en ayudar más
con las pruebas y realizar pruebas del trabajo de los demás, no
solo de las tareas propias. También deciden que programaran las
historias según su prioridad y se las pondrán a disposición de
Tara y Pepa tan pronto como puedan.
Danny admite que debería haber pedido ayuda con sus
problemas técnicos antes. El equipo acuerda hacer más trabajo
en pareja cuando se enfrenten a partes complicadas de la
solución.
El equipo reconoce que todavía son novatos con la integración
 continua (CI) y que necesitan mejorar la manera en que la están
haciendo.
El equipo solo puedo entregar dieciséis de los veinte puntos de
trabajo que pretendían realizar. Deciden comprometerse a estos
dieciséis puntos para la siguiente iteración y a tomar trabajo
adicional si les sobra tiempo de la iteración. Como han
reservado dos iteraciones de contingencia, el equipo prevé que
continuará siendo capaz de entregar toda la funcionalidad en las
fecha planificada en el Plan de entregas.
El equipo reconoce que deberían haber definido mejor los
elementos de más prioridad de la lista de ítems de trabajo antes
de la sesión de planificación para que esta fuera más eficiente.
Piensan que la segunda sesión les pasará lo mismo. Pepa se
compromete a hacer algo de análisis y modelado previo a partir
de ahora, y Pavel se compromete también a anticipar el
modelado y diseño técnicos con el equipo. Carlos dice que esta
actividad se conoce como refinamiento del Backlog en Scrum,
aunque DAD prefiere usar el nombre de modelado previo.

Como resultado de la retrospectiva el equipo reúne una lista de mejoras en

la pizarra blanca. Como prevén que no podrán implementar todas las mejoras
a corto plazo, deciden priorizarlas y afrontarlas en paquetes como parte de
cada iteración. Mostrar públicamente la lista de mejoras como un radiador de
información ayuda a que el plan de mejora se mantenga presente para todos.
 7 CONSTRUCCIÓN: ITERACIÓN C2
Sesión de planificación de la iteración. El equipo vuelve el lunes por la
mañana descansado y listo para comenzar una nueva iteración. Pepa hace un
recorrido de los elementos de mayor prioridad que suman 16 puntos. Para
cada historia, ella explica la funcionalidad y el criterio de aceptación. Ha
preparado también algunas maquetas de las pantallas y se las muestra al
equipo. Las pantallas son un buen punto de inicio, pero como vieron en la
primera iteración, no son suficientes. Para dos de las historias se dan cuenta
que necesitan dibujar el flujo de negocio para ayudar a entender la historia.
Ella también dedica unos minutos a describir la terminología de negocio,
como respuesta a las preguntas frecuentes que le hace Adam, a quien le gusta
entender estos detalles. Al resto del equipo también le parece que está
conversación les ayuda a aclarar varios conceptos sobre los que no se sentían
seguros.
Para cada historia, Pavel lidera el equipo en la discusión sobre la
estrategia técnica que utilizarán para implementarla. Utilizando este diseño
“justo a tiempo” (Just In Time), el equipo identifica las tareas de desarrollo y
de validación de manera similar a la iteración anterior. En varios momentos
Danny y Pavel examinan una idea en la pizarra mientras los demás dan su
punto de vista. Aunque este modelado demuestra ser muy útil, el equipo se da
cuenta que alarga las sesiones de planificación.
Ahora que el equipo está más familiarizado con el proceso, la sesión de
planificación va más fluida que en la primera iteración. A pesar de esto, se
prolonga más de lo esperado debido a la necesidad de trabajar en la lógica de
negocio y en los detalles de implementación. Esto refuerza su decisión de
hacer el modelado previo en todas las iteraciones, una de las lecciones
aprendidas en la retrospectiva de la iteración anterior. Leo se ofrece
voluntario a despejar el panel de tareas de la iteración anterior y añadir las
nuevas historias y tareas. Después de la comida, el equipo está preparado
para comenzar a trabajar en estos elementos.
Días 1 a 5. El equipo comienza a realizar el trabajo de implementación de
las historias, incluyendo la historia que no completaron en la iteración C1 y
que han vuelto a añadir a esta segunda iteración de dos semanas. Aunque
todos se sientan juntos en la Zona Ágil, en la práctica trabajan la mayoría del
tiempo de manera individual. Cuando alguien tiene una dificultad, como la de
escribir un trozo de código complejo, le piden ayuda a un compañero. Danny,
Debbie y Leo le suelen pedir ayuda a Pavel, debido a su larga experiencia en
el desarrollo de producto. De vez en cuando algún miembro del equipo le
pide a Pepa o a Ana hacer un poco de modelado “justo a tiempo” (JIT) para
aclarar detalles de la lógica de negocio o como debería comportarse una
funcionalidad de la interfaz de usuario.
Adam continua trabajando en pareja con otros miembros del equipo
cuando se necesita. También continúa trabajando en “su” modelo de datos
detallado y espera acabarlo esta semana.
Tara y Carlos trabajan en la puesta en marcha de la infraestructura de
integración continua (CI). Carlos ya ha hecho algo parecido antes y Tara está
impaciente por aprender cómo se implementan con CI las pruebas de
regresión automatizadas. Además Tara tiene pocas pruebas pendientes esta
semana mientras espera a que el resto de miembros completen
suficientemente las funcionalidades. Aunque los demás están haciendo lo
mejor que pueden para crear pruebas unitarias, está claro que no es su punto
fuerte. Tara piensa que no es así como se deberían hacer las pruebas a nivel
de equipo, así que le comenta esta preocupación a Carlos. Carlos está de
acuerdo y le dice que es un tema que quería comentar con el equipo una vez
que la infraestructura de CI comenzara a funcionar. También le sugiere que
sea ella quien haga esta petición de mejora, y que dedique un poco de tiempo
a detallar la propuesta.
Las reuniones diarias de coordinación que se hacen por la mañana
comienzan a funcionar mejor, aunque acaban extendiéndose entre veinte y
veinticinco minutos en lugar de los diez o quince deseados. Algunas
personas, Danny en particular, acostumbran a llegar tarde a estas reuniones,
obligando a los demás a esperarle. Tanto Pavel como Debbie, y algunas veces
también Leo, van demasiado al detalle y frecuentemente intentan solucionar
los problemas identificados en la sesión, en vez de esperar a hacerlo después.
Danny padece el problema opuesto, ya que sus comentarios son
habitualmente muy cortos y los demás miembros del equipo se pierden
detalles importantes que deberían saber. Carlos intenta reconducir estas
desviaciones con tacto durante las reuniones diarias.
En el quinto día Carlos habla con Danny en una zona separada y le
pregunta porque llega tarde habitualmente. Danny le dice que le cuesta
despertarse por las mañanas y que de todas maneras, tampoco le ve mucho
valor a las reuniones de coordinación. Carlos le describe porque es
importante que todos acudan a tiempo a la reunión y estén preparados para
ella. Le pide a Danny que lo haga igual que el resto de miembros del equipo.
Danny se muestra de acuerdo pero Carlos no está seguro que éste vaya a

cambiar realmente de actitud.

Día 6. Pepa y Ana la analista de negocio dedican dos horas de la tarde a hacer
modelado previo con otros actores, incluyendo Néstor , para explorar las
siguientes ocho historias según la prioridad de la lista de ítems. Durante esta
actividad crean una colección de maquetas de pantalla hechas a mano, un
diagrama del flujo del proceso de negocio al que dan soporte las historias y
otras reglas de negocio que documentan como una lista de frases. Después de
la sesión de modelado Pepa decide agendar una reunión periódica en el
mismo momento del sprint para realizar el modelado previo. Su intención es
invitar a los actores interesados apropiados dos semanas antes de cada
reunión, ya que se da cuenta que la gente con la que tendrá que hablar irá
cambiando de reunión a reunión.
Día 7. Debbie, con la ayuda de Pavel, acaba el trabajo de la historia
Aprobación de petición básica que se había “caído” de la iteración anterior.
Con este trabajo completado, el equipo puede probar que la arquitectura
funciona con código real. Después que Leo verifique que se cumple el
criterio de aceptación de la historia Aprobación de petición básica, puede
confirmar con tranquilidad la reunión ligera de revisión del hito Arquitectura
validada que se había agendado tentativamente para el día 10.
Día 10. De manera parecida a la primera iteración, el equipo invierte la
mayoría de la mañana en actividades para mejorar la robustez. Pepa se
prepara para la demo, practicando varios escenarios con la versión de
demostración actualizada con la funcionalidad añadida en esta iteración.
Pavel y Leo se reúnen durante media hora para finalizar la estrategia que
usaran en la reunión de revisión de hito que tendrán por la tarde.
La demo. Esta vez, la demostración de la iteración va mucho mejor por
dos razones: primero, el equipo completó todo el trabajo al que se había
comprometido al principio de la iteración, cosa que le gustó a Néstor . En
esta iteración el equipo entregó un total de diecinueve puntos, que supone una
mejora sobre los dieciséis que se lograron entregar en la iteración C1. Carlos
explica que es común ver que la velocidad del equipo aumenta durante las
primeras iteraciones tal y como el equipo va aumentando su eficiencia e
implementa las mejoras identificadas en las retrospectivas. Esta vez Pepa
estaba mucho más cómoda haciendo la demo. Ella invitó a la demo a dos
actores interesados de negocio, Kristen y Rod, que habían estado
involucrados en el modelado inicial de los requisitos pero que no habían visto
lo que el equipo había producido hasta ahora. Durante la demo están
entusiasmados con lo que ven pero se quedan perplejos por ver desarrollada
únicamente una parte tan pequeña del producto. Aunque Néstor y Pepa les
habían explicado este nuevo enfoque ágil, no se habían dado cuenta que solo
verían una parte completa de toda la solución. Una vez que superaron este
malentendido comenzaron a sugerir ideas de nuevas funcionalidades que se
podrían añadir. Pepa les invita a llevar estas ideas a la próxima sesión de
modelado que se hará en una semana y media, y les anima a que se
involucren en el proyecto. Kristen y Rod prometen buscar un hueco en sus
agendas, y aún más importante, a pensar más detalladamente lo que necesitan
que haga la solución.
Revisión del hito de Arquitectura validada. Pavel muestra la solución
construida a Alexis el arquitecto empresarial, Robert el responsable de
operaciones y a Samuel el Scrum Master. El resto del equipo, incluyendo a
Pepa, también acuden a esta reunión para poder contestar cualquier duda que
surja y recoger el punto de vista de éstos sobre la arquitectura. Pavel se
concentra en demostrar las tres historias que demuestran que los mecanismos
clave de la arquitectura funcionan: Crear borrador de petición de hipoteca,
Solicitar evaluación online de crédito y Aprobación de petición básica. Pavel
explica estas historias a los actores, mostrando como la implementación
fuerza la capacidad de respuesta de la arquitectura de una manera
significativa. Mientras va explicando las historias destaca los mecanismos
usados en un diagrama que ha dibujado en la pizarra. Alexis hace unas
preguntas para averiguar cómo encaja la estrategia de Pavel con la hoja de
ruta tecnológica de la empresa. Pavel responde que la arquitectura es
responsabilidad de todo el equipo, no solo suya, y a continuación describe
como tuvieron en cuenta esta hoja de ruta durante el modelado inicial de la
arquitectura que el equipo hizo durante la fase de Inicio. Pepa añade que la
actividad para definir el alcance tuvo igualmente una influencia de la hoja de
ruta del negocio.
Al final de esta revisión Samuel pregunta porque la historia Solicitar
evaluación online de crédito se priorizó para el principio del proyecto. Pepa
interviene diciendo que si bien la prioridad del requisito originalmente era
media, Pavel le convenció de ponerla al principio de la lista de ítems de
trabajo para validar la arquitectura. Samuel dice que precisamente esta es su
duda, pues Scrum recomienda a los equipos trabajar según la prioridad de
negocio. Pavel contesta que DAD tiene la ventaja de concentrarse en la
reducción del riesgo al principio del ciclo de vida, incluyendo tanto el riesgo
técnico como propio del negocio. Alexis y Robert están de acuerdo en que
esta estrategia es mucho mejor que la vista anteriormente en muchos equipos
de Scrum, diciendo que les proporciona una comprensión mucho mejor de lo
que está haciendo en realidad el equipo, y añaden que están impresionados
que no solo se han preocupado de los requisitos técnicos, sino que además
han demostrado con código que funcionan. Alexis observa que esto ha
funcionado mejor que las revisiones exhaustivas de la arquitectura que
todavía hacen muchos de los equipos de desarrollo tradicionales dentro de
BigBank.
La retrospectiva. Leo lidera la retrospectiva, comenzando por pedirles a
todos que comenten que piensan que está funcionando bien. La mayoría del
equipo está contento de cómo están yendo las cosas. Les gusta este estilo de
trabajo más colaborativo y todos tienen anécdotas de cómo han aprendido
cosas de los demás a través el trabajo cercano. Todos se han quedado
tranquilos porque el hito de arquitectura validada fue bien, aunque les
preocupa que los requisitos crezcan demasiado, dado en entusiasmo que
mostraron los actores interesados en la demo. El equipo también revisa la
lista de mejoras creada en la iteración previa y repasan donde han hecho
algún avance. Cuando Leo pregunta al equipo donde creen que se debe
mejorar, todos opinan que la calidad es el principal problema. Carlos indica
que la necesidad de dedicar tanto tiempo a pulir la calidad de las
funcionalidades al final de la iteración es una indicación clara que el equipo
no está dedicando suficiente tiempo desde el principio de la iteración a hacer
pruebas y a solucionar los defectos encontrados. Danny dice que a veces
necesita dedicar varios días a programar antes que tenga algo maduro para
que Tara lo pueda probar. Carlos dice que el equipo sigue actualmente la
estrategia “programación sin prueba” en la que los desarrolladores escriben
algo de código y le piden a otro que haga las pruebas. Debbie se defiende
diciendo que ella y Danny están haciendo algunas pruebas unitarias mientras
programan, cosa que Carlos dice que eso es un buen inicio pero que piensa
que los desarrolladores pueden dedicar más tiempo a las pruebas para reducir
el esfuerzo y el tiempo que se ha de dedicar a solucionar problemas con el
código que escriben. Carlos repasa el diagrama de la meta Producir una
solución potencialmente usable, que se muestra a continuación.

Como se puede ver, el marco de trabajo DAD da soporte a dos enfoques

de programación efectivos: la primera es Programar probando después,
donde el equipo escribe algo de código y a continuación lo prueba
exhaustivamente (es ideal hacerlo escribiendo pruebas automatizadas de
regresión), y la segunda es Programar probando antes (o Programación
dirigida por pruebas –o TDD en inglés–) donde se escribe una prueba unitaria
y se crea el código de aplicación suficiente para superar esta prueba. Después
de un poco de discusión respecto las ventajas e inconvenientes de cada
enfoque, el equipo decide probar un enfoque de programar probando después.
Aunque reconocen que un enfoque de programación dirigida por pruebas
sería preferible, intuyen que no tienen suficiente disciplina para hacerlo
funcionar. Carlos indica que una vez que el equipo alcance un buen nivel en
la programación probando después, deberían considerar intentar pasar a la
estrategia de probar antes. Tara se ofrece a estar disponible para trabajar en
pareja con los compañeros que estén escribiendo código para ayudarles a
aprender el estilo de programar probando después. Carlos añade que la
infraestructura de integración continua (CI) está disponible pero el equipo no
la está aprovechando completamente. Todos están de acuerdo y Carlos se
compromete a ayudar a los demás en la siguiente iteración para enseñarles
individualmente a dominar la CI.
Danny pregunta si el equipo debería tomar más puntos de trabajo para la
siguiente iteración, ya que esta iteración superaron los dieciséis puntos
previstos y obtuvieron una velocidad de diecinueve. Carlos recomienda dar
seguimiento a la tendencia de su velocidad durante una o dos iteraciones más
antes de cambiar la velocidad esperada y ajustar la previsión en el plan de
despliegues.
El equipo acaba el día actualizando sus “herramientas de gestión”. La lista
de riesgos se actualiza para reflejar que la arquitectura ha sido probada y
aceptada por los actores interesados apropiados. El equipo también añade el
riesgo que los requisitos crezcan dados los comentarios tan positivos que se
recibieron durante la demo.
 8 CONSTRUCCIÓN: ITERACIÓN C3
La Iteración de Construcción C3 comienza con optimismo. El equipo está
entusiasmado porque la segunda iteración tuvo éxito y existe un consenso
generalizado en que en esta pasará lo mismo. Leo lidera la sesión de
planificación de la iteración, que dura menos de tres horas. Esta mejora
notable en su duración respecto a las planificaciones previas se debe en parte
a la mayor experiencia del equipo con la planificación de iteraciones, pero
principalmente es fruto del modelado previo que han liderado Pepa y Pavel.
Las reuniones de coordinación diarias están funcionando mucho mejor.
Todos están acudiendo puntuales y se concentran mayoritariamente en la
coordinación y no en solucionar problemas técnicos. Aun así, Danny
continua teniendo problemas para llegar pronto a las reuniones.
Día 2. Durante la reunión de coordinación del equipo tanto Danny como
Debbie le piden a Tara si tiene tiempo para trabajar en pareja con ellos, por
separado, para ayudarles a probar su programación. Para hacer esto, Tara se
sienta junto a cada desarrollador y trabaja junto a este ayudándole a escribir
el código de aplicación y pruebas unitarias que validen este nuevo código.
Después de practicar un poco, Tara y el desarrollador intercambian el teclado
regularmente, hablan sobre la lógica usada para probar el código y, más
importante, aprenden mutuamente nuevas habilidades y modos de pensar.
Durante el resto de la iteración Tara invierte dos tercios de su tiempo
trabajando en parejas con Danny, Debbie, Pavel y Leo de este modo. El otro
tercio del tiempo lo usa en otros tipos de pruebas, incluyendo pruebas
funcionales, de integración y de rendimiento. Durante la planificación de la
iteración, Tara había anticipado que pensaba dedicar la mayoría de su tiempo
a trabajar en pareja con sus compañeros para enseñarles a probar.
Día 6. A primera hora de la tarde, Pepa lidera una sesión de modelado
previo, con varios actores interesados, para explorar los próximos requisitos.
Durante esta sesión los actores, no solo describen como deberían funcionar
las historias de la siguiente iteración, sino que identifican varias nuevas
historias y descartan algunos de los requisitos existentes de menor prioridad.
Esto resulta en cambios que parecen incrementar el alcance un 20%.
Pepa se dirige a Carlos con algo de pánico, pidiendo ayuda sobre cómo
tratar este aumento descontrolado del alcance. Habiendo trabajado
anteriormente con otros equipos IT, aunque siempre siguiendo una
metodología tradicional, a Pepa le preocupa que el aumento del alcance
ponga en riesgo el proyecto. Carlos responde que en los proyectos ágiles
suele darse un incremento pronunciado de nuevos requisitos al principio del
proyecto. Es el resultado natural de una mayor involucración de los actores:
cuando produces una solución potencialmente usable de manera regular, se la
enseñas a la gente y les pides su opinión, lo normal es que te la den.
Dado que el objetivo es construir algo que satisfaga a los actores, es
saludable que los requisitos evolucionen, al contrario de lo que pasaría si se
tratara de construir una especificación.

Día 7. Durante la reunión de coordinación diaria

Pepa informa al equipo de los nuevos requisitos. Leo sugiere que el equipo
dedique algo de tiempo durante el día a escuchar una explicación de los
nuevos requisitos por parte de Pepa para que puedan evaluar el impacto real
sobre el proyecto. El equipo decide hacer esto justo después de la comida.
Pepa comienza la sesión describiendo los cambios a los requisitos y los
motivos que los han originado. Después de un poco de discusión sobre cómo
se podrían implementar las nuevas historias, el equipo está convencido que
no tendrán un impacto significativo en la arquitectura y que esto se debe al
modelado inicial que hicieron durante la fase de Inicio.
Leo lidera el equipo en la estimación de los nuevos requisitos utilizando la
técnica del tamaño relativo, tarea que completan en unos treinta minutos. El
tiempo total que han dedicado a la reunión de análisis del impacto ha sido
alrededor de una hora y media. Después de esto, todo el equipo vuelve al
trabajo excepto Leo y Pepa que se dedican a actualizar la tabla de burnup.
Esta gráfica muestra que el equipo probablemente necesite doce iteraciones
de Construcción en total. Como Néstor , el patrocinador del proyecto, ha
dejado claro que la fecha de entrega de la versión es firme, Pepa se da cuenta
que debe convocar una reunión para repensar que requisitos son
imprescindibles para esta versión y cuales pueden esperar a otra versión
futura.
Día 8. Durante la reunión de coordinación Leo y Danny descubren que
han estado trabajando en la misma funcionalidad desde la mañana anterior.
Aunque esto les ha resultado frustrante, también es una lección valiosa para
Danny, que aprende lo que pasa cuando alguien del equipo no participa
activamente en las reuniones de coordinación diarias.
Día 9. Pepa facilita una reunión de una hora con Néstor y los actores
interesados que participaron en la reunión de modelado del día 6. Durante la
reunión ella propone dejar algunos de los requisitos de menor prioridad para
que sean implementados en la siguiente versión. Por suerte la gerencia ha
aprendido que tratar esta iniciativa como una serie de entregas, similar a una
estrategia típica de gestión del producto, que es un mejor enfoque que
presupuestar un único proyecto. Todos los actores interesados saben que
existirá presupuesto para siguientes versiones y eso hace la negociación del
alcance mucho más sencilla. Un 70% de los requisitos, incluyendo la mayoría
de los nuevos, han sido considerados como imprescindibles y serán incluidos
en la primera versión. Todos los demás son marcados como “opcionales” y,
aunque les gustaría que estuvieran disponibles inicialmente, los actores
interesados aceptarán que se retrasen a una segunda versión si finalmente es
necesario. Esta categorización permitirá al equipo cumplir la fecha de
entrega. Leo también asiste a la reunión para representar al equipo, aunque
durante la mayor parte del tiempo se limita a escuchar.
Día 10. El equipo comprueba que necesita mucho menos trabajo para
pulir la calidad obtenida durante esta iteración. Esto se debe a haber hecho
mucho más pruebas desde el principio de la iteración. La demo funciona muy
bien. A los actores interesados les gusta lo que ven y se sienten optimistas
sobre el grado de avance que se está consiguiendo. Esta sensación de
optimismo es nueva para ellos, ya que la anteriores experiencias con IT
siempre habían sido problemáticas. Se dan cuenta que, su participación más
activa en el proyecto y las demostraciones periódicas que realiza el equipo,
hacen que sea más difícil encontrarse con sorpresas desagradables al final del
proyecto como les había pasado frecuentemente en el pasado.
 Leo comparte la tabla de burnup con el
equipo. La tabla muestra dos líneas de requisitos, una muestra el número de
puntos “imprescindibles” y la otra el total de puntos. Pepa explica al equipo
lo que ocurrió durante la sesión de priorización que tuvieron con los
requisitos el día de antes. Leo explica entonces, utilizando la tabla de
burnup, que el punto donde la línea de burnup cruza con la línea de puntos
imprescindibles marca la fecha más temprana en la que se podría desplegar su
trabajo en producción. En este punto ya habrán completado todo el trabajo
solicitado. Este hito se conoce en DAD como el de Suficiente funcionalidad.
La retrospectiva. El equipo comienza con una revisión del estado de las
mejoras al proceso identificadas en las iteraciones anteriores. La manera en
que hacen las pruebas ha mejorado claramente, aunque aún les queda mucho
trabajo por delante. La sesión de planificación de la iteración funcionó mucho
mejor esta vez y todo el mundo espera que incluso sea más efectiva en la
siguiente iteración. Las reuniones de coordinación del equipo también
mejoran día a día, aunque algunas veces todavía se alargan a unos veinte
minutos. Aquí también hay una oportunidad de mejora. Pavel dice que está
algo preocupado sobre el nivel de documentación que está produciendo el
equipo. Unos días antes Robert, el gestor del grupo de operaciones, le
preguntó a Pavel si habían comenzado a trabajar en la documentación del
sistema que forma parte de la solución completa. Pavel dijo que el equipo
había estado tomando notas y fotos de diagramas en su wiki de equipo, pero
que no había comenzado a desarrollar ningún tipo de “documentación
entregable”. Aunque todavía están al principio de la Construcción, Pavel
piensa que deberían ir escribiendo la documentación al mismo ritmo que
desarrollan el software. Esto refleja la filosofía de DAD de desarrollar
soluciones usables, no únicamente software funcional. Carlos sugiere que el
equipo adopte la práctica de Documentación Continua en paralelo al
desarrollo del código. Sugiere que esto se puede
hacer en la wiki, y que todo lo que tiene que hacer el equipo es dedicar un
poco más de tiempo a añadir información en este repositorio. Él se ofrece a
trabajar en pareja con quien necesite ayuda en esta tarea.
Adam revela que en la misma línea, ha estado manteniendo hasta ahora un
modelo de datos detallado. Danny se ríe y dice que esto era un secreto a
voces, porque todos en el equipo sabían que esto estaba sucediendo. Adam
admite que piensa que ha desperdiciado mucho tiempo manteniendo este
modelo detallado. La exploración de requisitos que se hizo esta semana le
obligó a dedicar unas dos horas a actualizar su modelo, incluyendo la
eliminación de estructuras de datos que no se necesitaban porque las historias
relacionadas se quitaron del alcance. Esto le ha hecho darse cuenta vale la
pena evolucionar la base de datos usando técnicas de refactorización porque
es sencillo y seguro, y que elimina la necesidad de hacer un modelado inicial
detallado. Así pues, a partir de ahora piensa hacer el trabajo de diseño de la
base de datos con un enfoque justo a tiempo (JIT).
 9 CONSTRUCCIÓN: ITERACIÓN C7
Estamos en la séptima iteración de Construcción y el equipo está trabajando
con efectividad. En las iteraciones C4, C5 y C6 el equipo continuó
evolucionando el Portal de Peticiones de Hipotecas (PPH), añadiendo valor
cada dos semanas. Ellos mejoraban su efectividad a partir del aprendizaje que
obtenían del trabajo conjunto y de las mejoras que iban identificando en cada
retrospectiva. Hubieron algunos baches durante el camino, especialmente
unas pocas discusiones acaloradas entre miembros del equipo respecto a
cómo implementar ciertas funcionalidades. Por suerte Pavel supo liderar el
equipo en estas decisiones polémicas, tal y como debería hacer el propietario
de la arquitectura.
Colaboración con los actores interesados. Los actores interesados están
muy contentos con el avance que se está logrando y están colaborando con su
opinión durante las sesiones de modelado periódicas y también otras que se
realizan ad-hoc. Pepa se siente cómoda en su posición de propietaria del
producto y encuentra su rol tanto gratificante como exigente. A veces le
resulta difícil tener acceso a los actores interesados apropiados porque estos
tienen mucha carga de trabajo. Y por supuesto los diferentes actores
interesados tienen sus puntos de vista y metas, hecho que le pone difícil a
veces negociar los requisitos y sus prioridades con ellos. Los requisitos
continúan evolucionando, tanto los existentes como otros nuevos que llegan
de manera constante, hecho natural si se busca la participación periódica de
los actores interesados.
Pepa y Néstor comienzan a trabajar con el equipo de Mindy para
desarrollar la estrategia de marketing para el PPH. Esta es la primera ocasión
que tiene este equipo de desarrollar una estrategia para un producto que usará
el cliente y que se irá desplegando en pequeños incrementos. Mindy está
entusiasmada de trabajar con un estilo ágil porque lo siente natural, y le pide
a Pepa una breve formación para entender cómo funciona la agilidad y cómo
pueden interactuar efectivamente con el equipo de desarrollo. Pepa le pide a
Leo y a Carlos si pueden realizar una sesión formativa de unas dos horas para
el equipo de Mindy, y tanto Pepa como Mindy asisten a la reunión para
subrayar la importancia que le da BigBank a esta manera de hacer los
proyectos. A partir de ahora, el equipo de Mindy trabajará coordinadamente
con Pepa y Leo para asegurarse que las estrategias de marketing y de
desarrollo del producto evolucionan de manera sincronizada. El plan es
comenzar la campaña de marketing unos días después que el sistema se
despliegue en producción.
Probar frecuentemente y pronto. Danny, Debbie y Leo están mejorando
sus habilidades de prueba a partir del trabajo en pareja que están haciendo
con Tara. Ella ha comenzado a trabajar también con Ana, la analista de
negocio, en la automatización de las pruebas de aceptación. A Ana le costó
un poco abandonar el estilo de escribir requisitos detallados en documentos y
usarlos para realizar las pruebas, pero pasados unos días comenzó a ver el
valor de capturar estos detalles en forma de pruebas ejecutables. Tara también
trabaja con Adam para crear y mantener los datos usados en las pruebas.
Respecto a la parte técnica, la estrategia de integración continua (CI) del
equipo está funcionando a pleno rendimiento. Durante la iteración C5, las
ejecuciones del conjunto de pruebas eran lentas debido al número creciente
de pruebas de regresión. La respuesta del equipo fue seleccionar un conjunto
de pruebas que pudiera correr en cinco minutos o menos en sus propias
máquinas. Este conjunto de pruebas se concentraba en las funcionalidades
desarrolladas en la iteración anterior y en la actual. Para aumentar la
velocidad de las ejecuciones de las pruebas en las máquinas de los
desarrolladores, Adam introdujo un código para simular la base de datos en la
iteración C6. Un segundo conjunto de pruebas más completo, que se ejecuta
en un entorno de integración del equipo de desarrollo, tarda unos treinta
minutos en total. Este conjunto de pruebas se ejecuta cada vez que alguien
promociona código a este entorno. Existe también un tercer conjunto de
pruebas que se ejecuta por la noche, que tarda varias horas, e incluye tanto las
pruebas de rendimiento como las pruebas funcionales completas.
Scripts de despliegue automatizado. El equipo ha desarrollado un script
para desplegar las compilaciones que superan las pruebas a un entorno de
demo. Este script, que se ejecuta si la compilación nocturna tiene éxito,
elimina la versión del sistema existente del entorno de prueba, incluyendo la
base de datos, y entonces redespliega todo el sistema sobre este entorno
“limpio”. El equipo está pensando evolucionar este mismo script para
desplegar en producción.
Respecto a la base de datos, Adam ha estado evolucionando el esquema de
base de datos según se requería y últimamente ha estado trabajando
activamente en pareja con los demás miembros del equipo para enseñarles las
técnicas fundamentales de base de datos. Él sigue actualizando su modelo
exhaustivo de datos, pero ha dejado de realizar el modelado inicial y ha
eliminado los detalles innecesarios.
Panel de control automatizado. Durante la iteración C4 el equipo
comenzó a usar la funcionalidad de panel de control que proporcionan sus
herramientas de desarrollo. Estas capturan eventos clave del trabajo del
equipo, como si las compilaciones fueron correctas, cuando se ejecutó la
última versión compilada, cuantas pruebas superó, entre otros. Este panel
web muestra gráficas generadas a partir de dichos eventos. Inicialmente los
miembros del equipo acceden al panel desde sus máquinas, pero Carlos, el
Coach de DAD, sugiere a Leo que muestre este panel en el monitor que el
equipo tiene colgado en la pared. DAD llama a esta estrategia como
inteligencia de desarrollo, la aplicación de la inteligencia de negocio (BI) a
los equipos de desarrollo.
Planificación. El equipo se ha comprometido con firmeza a una fecha de
entrega sobre la base de diez iteraciones de Construcción. En la iteración
anterior se pensó que se podría alcanzar el hito de funcionalidad suficiente al
final de la iteración C9 pero Pepa y Leo estuvieron de acuerdo en conservar
la iteración C10 como margen de seguridad. Si todo fuera mal, así se podría
entregar algo más de lo mínimo que se requería.
El equipo también se está poniendo serio sobre la planificación del
despliegue. Están trabajando de manera cercana con Robert el responsable de
operaciones y con Samia la responsable de soporte para asegurar que sus
equipos están listos para aceptar el Portal de Peticiones de Hipoteca (PPH)
que está desarrollando el equipo. Ellos han negociado una ventana de
despliegue con Robert teniendo en cuenta que la política de BigBank dice
que solo se pueden desplegar aplicaciones a producción los domingos entre
las 3h y las 5h de la madrugada. También han comenzado a pensar cómo van
a dar la formación al personal de soporte al usuario que coordina Samira. Ella
también lidera un equipo que realizará la formación a los usuarios del banco.
Leo se ofrece a trabajar con este grupo para asegurarse que estos materiales
se desarrollarán a tiempo.
El equipo, que había incorporado a sus iteraciones la estrategia de
documentación continua, ha mantenido la documentación que ha de
entregarse actualizada desde la iteración C4. Esta documentación incluye una
visión general del sistema, ayuda en formato web para los usuarios finales y
para el grupo de soporte, y por último la información técnica de operación.
La retrospectiva. Leo dice al equipo que Padma, la líder de la oficina de
gestión de proyectos (PMO) a la que debe informar sobre el avance del
proyecto, le ha dicho que no es necesario que le envíe más diagramas de
Gantt porque ella puede consultar la tabla de burnup. Esto supone una
sorpresa agradable para Leo, ya que no esperaba que Padma fuera receptiva a
las estrategias ágiles para dar seguimiento al proyecto.
Las mejoras introducidas a la manera en que el equipo trata la calidad
reducen sensiblemente el esfuerzo necesario para pulir la calidad al final de
las dos últimas iteraciones. Debbie pregunta si se podría utilizar este tiempo
ganado de una manera útil y Carlos responde con la idea de realizar la
planificación de la siguiente iteración el último día de la actual. El equipo
decide seguir esta idea para las siguientes iteraciones de Construcción

10 CONSTRUCCIÓN: ITERACIÓN C10

Esta es la última iteración de Construcción antes de la fase de Transición. El
equipo está funcionando bien en todos los aspectos.
El foco de esta iteración es implementar las historias de alta prioridad que
se identificaron en la iteración anterior y a pulir los últimos aspectos de
calidad en la solución. Durante la iteración C9 Tara pasó de dedicarse a
ayudar al equipo con las pruebas unitarias y la automatización de las pruebas
de aceptación, a principalmente realizar pruebas en el entorno de pre-
producción de BigBank.
A Tara le habría gustado acceder antes a este entorno, pero BigBank tiene
recursos limitados para realizar este tipo de pruebas. Durante el trabajo con el
equipo de pruebas en pre-producción, ella descubrió varios problemas de
integración con características de este entorno que su equipo no había podido
simular en el entorno de desarrollo. Tara también dedica tiempo a probar de
manera exhaustiva los scripts de despliegue dentro del entorno de
pre-producción.
El equipo registra esos defectos como tareas y se incluyen en la lista de
ítems de trabajo con prioridad alta. Asignan un tamaño de cero a estos
defectos para que no cuenten de cara a la velocidad del equipo. La decisión se
basa en considerar el punto de vista de los actores, para los que el equipo
debería haber evitado esos problemas como parte de declarar el trabajo
“hecho”. El equipo lo siente algo frustrante pero reconoce que es una
experiencia de aprendizaje. Carlos comenta que un patrón común en los
equipos nuevos con la agilidad es que acaban dedicando una o más
iteraciones a pulir la calidad. Leo le pide a Tara que dé seguimiento a los
defectos, ordenados por severidad, usando una hoja de cálculo. Para cada
defecto se registra su severidad, una breve descripción y la fecha en que se ha
resuelto. Esta información se resume después en una gráfica de tendencia de
defectos. Tara había hecho estas cosas antes usando herramientas sofisticadas
de gestión de defectos, pero piensa que una hoja de cálculo es suficiente por
el momento para cubrir sus necesidades. Esta gráfica de tendencia se revisará
todas las mañanas en la reunión diaria de coordinación.
Día 3. Durante la mañana Leo revisa el plan de despliegue con Robert y
Samira. Este plan describe como trabajarán conjuntamente el equipo de
desarrollo y el de operaciones, coordinado por Robert, para desplegar esta
solución en producción. El plan también indica cómo se le dará formación al
equipo de Soporte que lidera Samira, a tiempo para el despliegue. Esta
formación debe realizarse en diferentes intervalos del día con partes del
equipo para que el soporte siga funcionando sin interrupción para los clientes
y el personal de BigBank.
Esa tarde se reúnen Leo y Pepa con Mindy, la Vicepresidenta de
Marketing, y con Mary-Jane, que trabaja para Mindy, para finalizar la
programación global del despliegue. Esta reunión ya se había estado
haciendo, con los mismos asistentes, todas las semanas durante media hora
para coordinar las actividades de ambos equipos. Mary-Jane había estado
asistiendo a la demo de las iteraciones para asegurarse que los mensajes de
marketing reflejan lo que está construyendo el equipo.
Día 6. Pepa cancela la reunión habitual de modelado previo y aprovecha
este tiempo para redactar un correo con Leo con objeto de comunicar la fecha
oficial de despliegue del sistema PPH. Aunque los actores clave ya conocían
la fecha candidata para el despliegue, el resto de la comunidad de actores
interesados solo conocía que iba a publicarse pronto. Este correo indica la
fecha esperada de despliegue, una descripción de lo que hace el MAP, una
visión general de su importancia para BigBank y una orientación de cuando
se harán las siguientes comunicaciones. Este correo se envía a Néstor (el
patrocinador de negocio) y a Victoria (la Vicepresidenta de IT) para su
revisión. Al día siguiente ellos envían el correo, de manera conjunta,
a la audiencia designada.
Día 10. Pepa decide realizar una demo global de la solución, de unas dos
horas de duración, a los actores interesados. Mientras que el objetivo de las
demos anteriores era concentrarse en las funcionalidades implementadas en
cada iteración, esta demo recorre las funcionalidades más importantes de la
solución de manera completa. Pepa invitó a todo el mundo que había
participado en las demos anteriores y casi todos pudieron asistir. La meta de
esta demo es por un lado comunicar lo que el equipo ha podido completar y
por el otro asegurarse que se ha producido al funcionalidad suficiente que
justifique desplegar esta solución a producción. Durante la demo varios
actores interesados indican que les gustaría ver más funcionalidades incluidas
en la versión actual, y Pepa les pregunta si estas funcionalidades adicionales
podrían esperar a una siguiente versión. A dos de los actores interesados no
les gusta la idea porque ya han oído promesas parecidas de IT anteriormente
y las versiones prometidas habían tardado años en llegar. Néstor indica que el
plan es lanzar la funcionalidad necesaria que les permita ir a producción lo
antes posible y que tienen la clara intención de comenzar a trabajar en la
siguiente versión tan pronto como la actual esté funcionando correctamente
en producción. Victoria confirma que mantendrá al equipo dedicado a
trabajar en la próxima versión. Estos dos actores interesados se quedan
aliviados al escuchar esto, y no solo dan su consentimiento a esperar esta
funcionalidad para la siguiente versión, sino que además se ofrecen a
participar en futuras sesiones de descubrimiento de requisitos. La demo
resulta en un éxito y todos se muestran entusiasmados al oír que el despliegue
a producción está planificado para hacerse en dos semanas.
La retrospectiva. El equipo está también emocionado por el poco tiempo
que queda para desplegar su trabajo a producción. Varios miembros del
equipo piensan que la fase de Transición va a realizarse sin problemas debido
a la calidad del producto que han conseguido.
Leo actualiza la tabla de burnup y la comparte con el equipo. Les felicita
por haber podido tener en la fecha deseada todas las funcionalidades
identificadas como “importantes” por los actores interesados. Dice además
que hay mucho trabajo pendiente para la siguiente iteración y que espera que
el equipo reciba más requisitos además dada la respuesta positiva que ha
visto en los actores interesados durante la demo que les acaban de hacer.
Tanto Danny como Pavel dicen que están esperando una pausa en el
proyecto, debido que están algo agotados por la alta exigencia de tener que
producir una solución potencialmente usable cada dos semanas. Carlos está
de acuerdo y les comenta que es común en los equipos ágiles irse quemando
poco a poco si no mantienen un ritmo de trabajo sostenible durante la fase de
Construcción. Él piensa que se tendrá que trabajar mejor este aspecto en la
próxima versión, y el equipo se muestra totalmente de acuerdo.
Tara menciona el problema que encontró durante las pruebas de
integración en pre-producción. Mirando hacia atrás, ella piensa que estas
pruebas se comenzaron demasiado tarde en el proyecto, aunque no ve cómo
se podrían haber hecho antes si no se disponía del entorno necesario. Carlos
describe una práctica ágil disciplinada llamada Tests independientes en
paralelo donde el equipo de desarrollo sigue haciendo pruebas lo mejor
posible pero proporciona las versiones funcionales regularmente a un equipo
de pruebas independiente. Este equipo toma las versiones de los diferentes
equipos desarrollando soluciones y las integran en un entorno de pruebas de
pre-producción (llamado algunas organizaciones tradicionales “entorno de
QA”). Este equipo de pruebas hace entonces el tipo de pruebas que los
equipos de desarrollo no suelen poder hacer, e informan a los equipos de
desarrollo de los problemas potenciales que encuentran. Carlos piensa que
esto permitirá al equipo evitar el anti-patrón de dedicar una o más iteraciones
finales a pulir la calidad.

La revisión del hito Funcionalidad suficiente. Leo y Pepa se reúnen con

Padma, la líder de la PMO, Néstor y Victoria para realizar una revisión de
hito. Leo ha intentado mantener esta reunión lo más ligera posible, y
comienza resumiendo el estado actual del equipo e interpretando a
continuación el contenido de las tablas de burnup y de tendencia de los
defectos. Pepa y Néstor le resumen a Padma los resultados de la demo del día
anterior, a la que no había podido asistir. Después de una breve discusión,
todos están de acuerdo en que se ha superado con éxito el hito de
Funcionalidad suficiente.
 11 TRANSICIÓN

El principal objetivo de la fase de Transición en el marco

de trabajo Disciplina Ágil de Desarrollo (DAD) es que el equipo consiga
desplegar una solución usable a producción con éxito. Esto debería hacerse
de la manera más ligera posible. Como se puede ver en el diagrama, la fase
de Transición incluye dos metas de proceso, la primera asegurar que se está
listo para desplegar, mientras que la segunda es efectivamente realizar el
despliegue.
Asegurar que la solución está lista para desplegar. Para hacer esto, el
equipo necesita:

Finalizar las pruebas y la solución de defectos. Las pruebas

finales resultan muy breves, comparado con los demás proyecto
de BigBank, debido al elevado número de pruebas regresión y
al trabajo de pulir la calidad hecho durante la iteración C10.
Tara, Danny y Adam dedicaron mucho tiempo a realizar
pruebas en el entorno de
pre-producción, escribiendo una descripción breve para cada
defecto potencial que encontraron. Los problemas fueron
defectos fueron priorizados por Pepa con una severidad de uno a
cuatro. Cualquier defecto de severidad uno debe ser
solucionado, los defectos de prioridad dos “deberían” ser
solucionados, mientras que se deja la solución de los defectos
de severidades tres y cuatro para una siguiente versión. Se da
seguimiento a estos defectos en la hoja de cálculo de Tara y en
el informe de tendencia de defectos que se presenta en las
reuniones diarias de coordinación. Es común que Néstor y
alguien del equipo de operaciones de Robert acudan a estas
reuniones de coordinación.
Formación del personal de soporte de soporte. La formación
se realiza al equipo de soporte liderado por Samira durante un
periodo de seis días. Cada formación se dedica a una parte del
equipo y dura unas tres horas de media. En todas las sesiones
 está presente Pavel o Leo para solucionar posibles preguntas
que los participantes puedan tener sobre DAD.
Finalizar la documentación entregable . Esta actividad
también se realiza con bastante rapidez debido al esfuerzo de
documentación continua que realizó el equipo durante la
Construcción. Las revisiones finales de cada documento las
realizan los actores clave relacionados y el equipo incorpora las
correcciones necesarias. La mayor parte de los documentos
mostraba pequeñas inconsistencias, un problema habitual
cuando la documentación se va evolucionando durante un
periodo de tiempo (es habitual que la gente olvide repasar todo
el documento cuando solo actualiza una parte).
Realizar videos para la formación a los usuarios finales. Se
pide al equipo que realice siete videos de unos dos minutos de
duración que se entregan como parte de la solución global. Uno
de estos videos describe la solución PPH a nivel general y los
demás son videos formativos del estilo “¿Cómo hacer…?”.
Debbie, Pepa y Ana trabajan conjuntamente con Mary-Jane para
finalizar los guiones de los videos. Mary-Jane contrata un actor
profesional para hacer la narración de los videos.
Validar los scripts de despliegue. Pavel y Tara trabajan con
Oswald, un ingeniero de operaciones del equipo de Robert para
revisar y validar los scripts de despliegue. Tara ha probado de
manera exhaustiva estos scripts en el entorno de pre-
producción, y como resultado lleva varias semanas usándolos
con éxito. Los scripts están escritos de manera que la
información propia de cada entorno como los nombres o las
direcciones IP de las máquinas se mantienen en ficheros de
configuración centralizados. Como resultado de esta decisión de
diseño, la revisión se centra en este fichero de parámetros que
describe el entorno de producción.

Desplegar la solución. Oswald ejecuta los scripts para desplegar la

solución en producción. Debido a necesidades regulatorias, BigBank tiene
una política explícita de separar los roles dedicados al desarrollo y a la
gestión de los despliegues. Así pues, alguien que ha estado involucrado
activamente en el desarrollo no puede realizar los despliegues. Es por ello
que Oswald, una persona del equipo de Robert, es quien realiza esta
operación. La ejecución de los scripts tarda menos de diez minutos en
completar el despliegue.
Prepararse para la siguiente versión. Durante un rato libre del equipo,
se realiza una reunión para planificar la siguiente versión. La actual duró
unos seis meses, tres semanas para el Inicio, veinte para la Construcción y
dos para la Transición, pero a petición de Néstor el equipo decide que la
próxima versión debería durar solo cuatro meses. Pepa realiza algunas
sesiones de descubrimiento de requisitos para reunir funcionalidades que
añadir al producto en la siguiente versión. Estas sesiones se realizan con un
grupo de actores interesados clave y duran unas dos horas, y continúan al día
siguiente con otra sesión de una hora donde se priorizan los requisitos.
Aunque el equipo no tiene tiempo de estimar estos requisitos, tenerlos
identificados antes de comenzar la segunda versión ya supone una buena
ventaja. La estimación se realizará en una fase de Inicio de la segunda
versión, que durará dos semanas.
Cuando se mantiene un equipo unido para trabajar en la siguiente versión
de una aplicación, la fase de Inicio se acorta significativamente (el equipo
está cohesionado y los entornos ya están operativos, entre otros). De hecho, la
mayoría de la fase de Inicio se dedica a definir el alcance y planificar la
próxima versión, actividad que suele ser corta. En el caso de este equipo,
consiguen completarlo durante el tiempo sobrante de la Transición.
Aunque el equipo ágil medio emplea sobre un mes realizando las
actividades de Transición, el equipo del Portal de Peticiones de Hipoteca
(PPH) consigue finalizar la fase en solo dos semanas. Pueden conseguirlo por
la atención continua que han dado a la calidad y a las pruebas durante la fase
de Construcción, por haber adoptado las prácticas de documentación continua
y de desplegar automáticamente las últimas versiones funcionales en los
entornos de demo y de prueba (un gran paso hacia el despliegue continuo), y
por trabajar de manera cercana con los equipos de operaciones y de soporte
en la planificación del despliegue. El equipo incluso podría haber reducido la
Transición a una semana si la formación al equipo de soporte no se hubiera
tenido que distribuir durante una semana. Esperan que la Transición de la
segunda versión sea más rápida porque el sistema no será nuevo y por tanto
se necesitará menos formación.
 12 SIGUIENTES VERSIONES
A largo plazo el Portal de Peticiones de Hipoteca (PPH) se muestra como un
sistema de gran éxito para BigBank. En la primera versión, que se
concentraba en ofrecer información sobre las hipotecas y sus opciones para
clientes existentes de BigBank tiene una gran aceptación. Resulta en una
reducción sensible de las peticiones de información a través del teléfono o de
las oficinas del banco, hecho que supone un ahorro de costes considerable. La
segunda versión, que añade la capacidad de iniciar a través de la web el
proceso de solicitud de hipotecas, tanto para clientes existentes como
potenciales, proporciona una reducción adicional de costes y también un
aumento de ingresos por una mayor tasa de renovaciones. Las versiones
posteriores añaden ofertas nuevas y aún más sofisticadas.
En este capítulo ofrecemos una visión general de la mejora sobre el
proceso del equipo. En el viaje, de varias versiones de duración, que partió de
la adopción inicial de un ciclo de vida basado en Scrum, pasó por un ciclo de
vida lean, y a partir de ahí puede llegar incluso a un ciclo de vida de
despliegue continuo.

Versión 2
La versión dos comienza con una fase de Inicio de dos semanas. Durante este
periodo el equipo dedica varias horas a estimar el esfuerzo de los nuevos
requisitos que Pepa había identificado durante la semana previa. Debbie y
Pavel deciden tomarse la semana de vacaciones y Adam se toma libres los
viernes para poder disfrutar de dos puentes. El equipo recibe un curso
introductorio de tres días en Programación dirigida por pruebas (TDD)
durante la segunda semana del inicio, ya que esta práctica había llamado la
atención de varios miembros del equipo desde que comenzaron a realizar
pruebas de regresión automatizadas en la primera versión. Esta fase también
se solapa con el periodo de garantía de la primera versión, por lo que el
equipo debe estar disponible para solucionar cualquier problema que
aparezca en producción. Durante la primera semana del Inicio aparecen
varios problemas de severidad dos y tres que resultan solucionados. Para ello
se despliega un parche a producción durante el fin de semana, de nuevo por
parte de Oswald.
La fase de construcción consiste en siete iteraciones de dos semanas. A
continuación se resumen los aspectos más destacados:

TDD. La adopción del TDD por parte del equipo resulta difícil
al principio pero da buen resultado a lo largo del tiempo. Carlos
dedica mucho tiempo a entrenar a los miembros del equipo en el
TDD, trabajando en pareja con cada miembro del equipo
durante una hora diaria en las tres primeras iteraciones. Tara
también dedica una cantidad similar de tiempo a trabajar en
pareja con los miembros del equipo para ayudarles a
mejorar su habilidad en la realización de pruebas unitarias. Al
final de la versión todo el equipo se muestra cómodo con el
enfoque del TDD aunque reconocen que les hace falta continuar
trabajando para mejorar su nivel. A los miembros del equipo
con un buen nivel de diseño les resulta más sencillo comenzar a
hacer TDD que a los que no tenían esta experiencia.
Trabajar desde casa. Antes que la agilidad se introdujera en
BigBank era habitual que la gente trabajase uno o dos días a la
semana desde casa. Los coaches de Scrum que había contratado
BigBank insistieron en los equipos ubicados en el mismo
espacio, que es una gran idea desde el punto de vista de reducir
el riesgo. A pesar de eso, desde el punto de vista de los
empleados que están acostumbrados a trabajar desde casa a
veces puede parecer un serio inconveniente. Durante la
iteración C2 Carlos, el Coach DAD, sugirió que ahora que el
equipo está cohesionado puede experimentar con dejar trabajar
a sus miembros desde casa ocasionalmente. Después de
discutirlo con el equipo, Danny y Pavel comenzaron a trabajar
desde casa un día a la semana. Durante la iteración C4 Debbie
también comenzó a trabajar desde casa un día a la semana. Para
dar soporte a un equipo disperso ocasionalmente se comenzaron
a usar las herramientas de Atlassian Jira y HipChat. JIRA
permite a los miembros del equipo trabajar en su lista de ítems
de trabajo, disponer de un tablero de tareas virtual y generar los
informes de gestión más habituales como el burndown de la
iteración y el burnup de la versión. HipChat, como su nombre
implica, es un sistema de conversación que se integra con JIRA
y que ofrece videoconferencia, una funcionalidad que los
miembros del equipo usan frecuentemente para colaborar
cuando alguno de ellos está trabajando desde casa.
Seguimiento de la mejora. Durante la retrospectiva de la
iteración C1, Carlos sugiere que el equipo comience a medir sus
esfuerzos de mejora continua. Él describe una técnica de DAD
llamada Medición de la mejora, donde en cada retrospectiva el
equipo puntúa como de bien están haciendo la implementación
de las mejoras identificadas en las iteraciones anteriores. La
manera en que realizan esta técnica es que recorren la lista de
mejoras, mantenida en una hoja de cálculo, y cada miembro
puntúa como cree que el equipo ha conseguido mejorar en ese
aspecto. La hoja de cálculo permite mostrar la tendencia para
todas las mejoras identificadas a través de las iteraciones,
gráfica que se muestra en la pantalla común del equipo como un
radiador de información. Si el indicador de una mejora muestra
una evolución negativa, el equipo debe concentrarse de nuevo
en esta mejora durante la retrospectiva. Cuando un indicador se
estabiliza durante muchas iteraciones, el equipo decide si se ha
estancado la mejora en este aspecto y debe reactivarse, o ya se
ha mejorado lo posible y se puede dejar de prestar atención a
esta mejora.
El equipo evoluciona. El equipo entrevista a varios candidatos
potenciales a incorporarse a este y finalmente selecciona a
David, un desarrollador externo a BigBank, que comienza en la
segunda semana de la iteración C3. Al principio de la iteración
C5 se une al equipo Doug, un empleado de BigBank, tras ser
entrevistado igualmente por el equipo. Dada la gran importancia
de la colaboración y del trabajo en equipo en los equipos ágiles,
ellos han de tomar la responsabilidad de seleccionar quien se
unirá al equipo. El departamento de personal, o de “recursos
humanos” en muchos casos, puede ayudarles seleccionando una
lista de candidatos para que el equipo entreviste, pero debe ser
el equipo quien tome la decisión final y no un responsable
externo al equipo. Doug se une al equipo porque Debbie va a
pasar a otro equipo. Aunque el equipo ha crecido para ser
extremadamente eficiente e intenta permanecer unido a largo
plazo, es una buena idea rotar sus miembros para mantenerles
estimulados y ofrecerles nuevas oportunidades de aprendizaje.
Tests independientes en paralelo. Carlos había sugerido al
final de la primera versión que el equipo trabajase con el grupo
de aseguramiento de la calidad (QA) de BigBank para que este
pruebe en paralelo el trabajo del equipo durante el desarrollo la
segunda versión. Las negociaciones para establecer esta
colaboración comenzaron en la iteración C1, pero ha costado
casi dos meses que el equipo de QA pudiera tener disponibles a
Thomas y Tatiana, las personas adecuadas para realizar estas
pruebas. La dificultad fue encontrar las personas con suficientes
habilidades para hacer este trabajo. Muchos de los testers del
equipo de QA son de la “vieja escuela” y necesitan trabajar a
partir de una especificación detallada de los requisitos. Esto no
es adecuado para un equipo ágil de pruebas independientes,
porque el equipo de desarrollo no suele producir este tipo de
especificaciones ni probablemente aceptaría el sobreesfuerzo de
hacerlo para disponer de este tipo de soporte con las pruebas. En
vez de esto se necesitan testers con un conjunto más sofisticado
de habilidades, especialmente respecto a tipos de pruebas como
las exploratorias y las de integración del sistema. Carlos debe
trabajar con Quincy, el responsable de QA, para educarle sobre
cómo funcionan los equipos de pruebas ágiles y que
implicaciones tiene esto para su equipo. Todo esto toma tiempo,
y así no es hasta el final de la iteración C4 que el equipo de
pruebas independientes comienza a trabajar en el proyecto PPH.
Thomas y Tatiana usan la herramienta estándar del grupo de
QA, HP Quality Center, para comunicar al equipo los defectos
encontrados. Ellos pensaban usar Jira pero Quincy no lo
autoriza. Al final Tara y Pepa tienen que revisar los defectos
encontrados, y pasarlos a Jira para que puedan ser priorizados
respecto al resto del trabajo y que el equipo pueda trabajar en
ellos con facilidad. A Quincy le sorprende el bajo número de
defectos que encuentra el equipo de pruebas independientes.
Carlos le explica que los buenos equipos ágiles, que ponen
énfasis en la calidad y en realizar pruebas cruzadas del trabajo
de los compañeros durante la iteración, no suelen dejar
“escapar” muchos defectos fuera de la iteración. Para los
 equipos ágiles, “hecho” significa hecho: bien desarrollado y
probado.
Vacaciones. Danny se toma dos semanas de vacaciones durante
la iteración C4 y Leo se toma una durante la iteración C6. Los
miembros de los equipos ágiles, como los de cualquier otro
equipo, pueden solicitar vacaciones. Cuando se prevé que algún
miembro esté fuera, se reduce según corresponde la capacidad
del equipo durante la reunión de planificación de la iteración.

La fase de Transición dura una semana en esta versión, la mitad que en la

primera versión. Este es el resultado de la menor necesidad de formación al
equipo de soporte y de la mejor calidad general obtenida con las pruebas
independientes hechas durante la fase de Construcción. Adicionalmente, el
equipo se beneficia de la inversión realizada en la primera versión para
automatizar tanto los despliegues con scripts como las pruebas unitarias y de
regresión. Las sesiones de formación duraron una hora cada una, un tercio de
lo que se había necesitado en la primera versión, de manera que se pudieron
realizar todas estas sesiones en una única jornada. Las prácticas de pruebas
adoptadas por el equipo, especialmente el TDD y las pruebas independientes
en paralelo, reducen dramáticamente la necesidad de pulir la calidad al final
de la versión. A pesar de esto, todavía se requiere dedicar un poco de tiempo
a pulir detalles de calidad, algo en lo que Carlos espera ayudar al equipo a
mejorar en la siguiente versión.

Versión 3
La duración de la versión 3 se reduce a tres meses, con una semana de Inicio,
seis iteraciones de dos semanas de Construcción y una de Transición. Se
destacan los siguientes aspectos de esta versión:

Formación. Durante el Inicio el equipo asiste a un taller de dos

días de Desarrollo dirigido por tests de aceptación (ATDD),
práctica también conocida como Desarrollo dirigido por
comportamiento (BDD). Después de sus experiencias con el
TDD a nivel unitario y de diseño durante la segunda versión, los
miembros del equipo piensan que podrían dar un paso más y
comenzar a usar el TDD a nivel de requisitos.
Descubrimiento de requisitos. Pepa organiza un taller de
descubrimiento de requisitos de medio día de duración con un
grupo de actores interesados para identificar nuevos requisitos.
Esto ocurre durante el segundo día de la fase de Inicio y todos
los miembros del equipo acuden a la sesión para poder escuchar
directamente lo que piden los actores interesados.
Mejorar la calidad. Durante el periodo de garantía de la
segunda versión se encuentran algunos defectos menores, todos
de severidad tres y cuatro. Estos defectos se priorizan y se
añaden a la lista de ítems de trabajo del equipo. Victoria, la
Vicepresidenta de IT de BigBank, incluye una referencia en su
boletín mensual a la alta calidad del producto PPH y a las
elevadas puntuaciones de satisfacción que los usuarios emiten
periódicamente.
Despliegue continuo. Aunque el equipo comenzó a automatizar
su despliegue durante la primera versión, no es hasta ahora que
se puede considerar un despliegue continuo. Al final de esta
versión 3, el equipo ha montado un sistema de despliegue
automatizado que promociona automáticamente las
compilaciones correctas desde la máquina de un desarrollador al
entorno de integración del equipo, y desde allí a los entornos de
demo y de
pre-producción para que los equipos de pruebas independientes
puedan trabajar sobre estas. Mediante el uso de las
funcionalidades “activables”, el equipo comienza a “activar”
bloques más pequeños de funcionalidad de manera más
frecuente, y así consigue desplegar más frecuentemente a
producción. Diseñando estos pequeños cambios como micro-
servicios aislados, los actores interesados se sienten más
cómodos desplegando estos cambios menores sin la necesidad
de realizar pruebas de regresión exhaustivas.
Adopción de ATDD. Después de recibir la formación en esta
práctica, el equipo comenzó activamente a introducir sus
herramientas y técnicas. Tara invirtió la mitad de su tiempo
durante las tres primeras iteraciones en trabajar en pareja con
Ana, Doug y Danny ayudándoles a desarrollar una habilidad
sólida en el uso de ATDD.
 Una fase de transición breve. La fase de Transición vuelve a durar una
semana, aunque durante esta vez se debió principalmente a que los miembros
del equipo aprovecharon para tomarse algún día libre. La fase de Inicio de la
versión 4 se pudo realizar en paralelo con la Transición de la versión actual.

Versiones 4 y siguientes
El equipo mejora de manera continua, durante las siguientes versiones, la
manera en que trabajan. Los eventos más destacados son:

Se acelera la cadencia de las versiones. Para contribuir al

deseo de Néstor de reducir el tiempo de lanzamiento del
producto PPH y para reducir el riesgo global del proyecto, el
equipo reduce progresivamente la frecuencia de los despliegues:
la versión 4 duró tres meses, las versiones 5 y 6 duraron dos
meses y a partir de la versión 7 se decidió publicar las versiones
cada cuatro semanas.
El ciclo de vida evoluciona. Como resultado de la discusión
que se dio en varias retrospectivas de la versión 5, el equipo
decidió evolucionar hacia el ciclo de vida Lean de DAD. Esta
decisión es viable porque el equipo tiene un acceso fluido a los
actores interesados y porque como equipo está muy bien
cohesionado. Al principio de la versión 6 dejaron de usar el
concepto de iteración para pasar a implementar un flujo
continuo de desarrollo. Esto les permite realizar reuniones
semanales de planificación y de demo, y cualquier miembro del
equipo pueda convocar al resto para hacer una retrospectiva
cuando tiene un asunto que tratar. Durante la versión 8, el
equipo reemplaza la reunión semanal de planificación por
sesiones de rellenado de ítems pendientes, y toma el ítem más
prioritario para su desarrollo en vez de seleccionar el volumen
de trabajo que permite la capacidad de la iteración. El equipo ha
llegado a ser capaz de tomar una nueva funcionalidad de la lista
de ítems de trabajo y rápidamente construirla y desplegarla a los
clientes. Este ciclo de vida tan corto minimiza el trabajo en
curso (WIP) y proporciona un rápido retorno de la inversión.
Como el equipo es capaz de construir, corregir y desplegar el
trabajo manera autónoma, han implementado de hecho la
 práctica DevOps de “tú lo construyes, tú lo ejecutas”. Carlos
destaca que el equipo ha evolucionado con éxito al ciclo de vida
de Despliegue Continuo de DAD, el más avanzado y efectivo.

El equipo deja de estimar. Parte de la decisión de mantenerse en un

ritmo de versiones de un mes tiene el objetivo de proporcionar una
planificación predictible y consistente de versiones para los actores
interesados. Esto permite al equipo proponer a sus actores interesados que les
permitan adoptar la estrategia #NoEstimates[9] donde el equipo ya no incurre
en el coste de estimar el trabajo.

La trasformación ágil global de BigBank

La prueba piloto de DAD con el equipo PPH es un éxito rotundo. Esto se ha
debido a:
La voluntad de BigBank de invertir en la formación y el
coaching del equipo en técnicas ágiles disciplinadas
La voluntad del equipo de aprender juntos y adoptar una
mentalidad ágil
La voluntad del equipo de probar nuevas técnicas de trabajo en
equipo como la programación en pareja y el modelado ágil, que
les ha permitido aprender nuevas habilidades de manera más
rápida
Los miembros del equipo tenían un buen nivel técnico de
partida y querían mejorar su capacidad según fuera necesario

En paralelo hay otros dos equipos que también consiguen adoptar DAD
con éxito, lo que impulsa a BigBank a extenderlo a más equipos de
desarrollo. Esto comienza a ocurrir durante la segunda versión del proyecto
PPH. Un año más tarde, BigBank ya tiene quince equipos usando DAD y
tiene la intención de extender su uso aún más.
Carlos se reúne con los ejecutivos sénior, tanto del ámbito de negocio
como el de IT, para explicarles que es necesario trabajar en la transformación
de algunos aspectos si quieren maximizar los beneficios de DAD y hacerlos
sostenibles. Existen numerosos impedimentos organizativos que necesitan
afrontarse para “lubricar la máquina” de los equipos ágiles. Los ejecutivos
están de acuerdo en incorporar un Coach Corporativo de DAD para facilitar
esos cambios. Mediante el uso del ciclo de vida Exploratorio/Lean Startup de
DAD y la guía que proporciona DAD 2.0, el Coach Corporativo trabaja con
BigBank para mejorar actividades a nivel del departamento IT como son la
Gestión de la cartera de proyectos, la Arquitectura Empresarial, DevOps, la
Gestión de Datos y otras que se describen en el apéndice. Las experiencias de
BigBank en este proceso se describirán con detalle en un próximo libro que
posiblemente se titulará El departamento IT con disciplina ágil (The
Disciplined Agile IT Department).
 13 REFLEXIONES FINALES
Nos gustaría dejar al lector con algunas ideas sobre porqué se debería
considerar adoptar DAD, donde se puede aprender más sobre DAD y como
se puede obtener soporte para llegar a ser más disciplinado en el proceso ágil
de proporcionar soluciones a los clientes.

¿Por qué DAD?

Se debería considerar adoptar el marco de trabajo Disciplina Ágil de
Desarrollo (DAD) cuando:

Se desea un marco de trabajo ágil flexible y pragmático en vez de un

método ágil purista
Ya usa Scrum o XP con éxito y se quiere mejorar los resultados
obtenidos
Su organización está usando la agilidad pero no se han obtenido los
resultados esperados
Los proyectos no siguen la guía de la PMO y se quiere incorporar un
tipo de gobierno ágil para los proyectos
Su organización ha adoptado Scrum pero no tiene claro como
escalar su uso
Se está usando Scrum pero no se sabe cómo integrar con éxito
actividades como la arquitectura, las pruebas o el análisis
Se ha evaluado SAFe en su organización pero parece demasiado
caro y arriesgado de implementar
Su organización ha adoptado SAFe pero la implementación está
encallada porque no se tenía una base sólida de agilidad en sus
equipos
Se desea compatibilizar el uso de diferentes enfoques de agilidad y
lean dentro su organización de desarrollo
Necesita entender cómo combinar con efectividad las iniciativas
ágiles y lean con proyectos que siguen un enfoque tradicional

Como aprender más

 Dado que DAD está en evolución, el último material puede
encontrarse en DisciplinedAgileDelivery.com. Registrándose en la
web permite estar actualizado de todas las novedades a través de su
blog.
El programa de certificación está mantenido por el Disciplined Agile
Consortium y se describe en: DisciplinedAgileConsoritum.org.
Scott Ambler + Associates realiza talleres de DAD. Tanto si se es
nuevo en la agilidad o Lean, como si se tiene experiencia y quiere
llevar su capacidad al siguiente nivel, estos talleres serán su punto
de partida. Las descripciones detalladas de los cursos y de otros
servicios se pueden encontrar en: ScottAmbler.com
Existen más instructores que realizan talleres DAD, y se puede
encontrar el directorio de instructores certificados en
DisciplinedAgileConsortium.org/instructors

Necesita ayuda?
Scott y Mark trabajan con un equipo de experimentados coaches corporativos
y de equipos en Scott Ambler + Associates. Cuando preguntamos a nuestros
clientes “¿Por qué nos llamasteis?”, las respuestas habituales se resumen en
que se enfrentaban a serias dificultades y necesitaban alguien con experiencia
en la solución de estos problemas complejos. La situación habitual son
organizaciones que quieren moverse desde enfoques tradicionales a ágiles o
lean, o bien ya lo han intentado pero no están obteniendo los beneficios que
esperaban. Podemos ayudar tanto si se necesita formación, como coaching en
proyectos ágiles o bien transformación corporativa hacia la agilidad.
Para más información pueden contactarnos en info@scottambler.com
 APÉNDICE: EL DEPARTAMENTO IT CON
DISCIPLINA ÁGIL
Un departamento IT con disciplina ágil es una organización flexible y
orientada al aprendizaje, receptiva a las necesidades de la(s)
organización(nes) a las que da soporte y que puede hacerlo de una manera
financieramente efectiva.
Primero, la historia de DAD, el marco de trabajo para procesos. La
versión 0.x, desarrollada desde 2009 al otoño de 2011 por IBM Rational con
el liderazgo de Scott Ambler, estaba orientada al desarrollo ágil de software.
Estaba basada en la observación que cada equipo es único y trabaja de
maneras únicas, de manera que sus resultados podían mejorarse con una guía
de procesos flexible y ligera. DA 1.x, desarrollada entre el otoño de 2010 y la
primavera de 2015 bajo el liderazgo de Scott Ambler y Mark Lines, está
orientado a ofrecer una aproximación flexible y ligera a la entrega de
soluciones IT, llamada Disciplina Ágil de Desarrollo (DAD). DA 1.0 está
descrito oficialmente en el libro Disciplina Ágil de Desarrollo: A
Practitioner’s Guide to Agile Software Delivery, escrito por Scott y Mark, y
publicado por IBM Press en junio de 2012. Las extensiones y las mejoras del
marco de trabajo fueron publicadas posteriormente en
DisciplinedAgileDelivery.com. En junio de 2014 IBM reconoció
oficialmente al Disciplined Agile Consortium
(DisciplinedAgileConsortium.org) como la fuente oficial de todo aquello
relacionado con DAD.

IT Ágil Disciplinada
DA 2.x, extiende las estrategias ágiles disciplinadas al departamento IT
completo. El desarrollo de DA 2.x comenzó en la primavera de 2014 bajo el
liderazgo de Scott y Mark. DA 2.x está basada en varias observaciones
importantes. La primera es que cada organización es única, y que sus
departamentos IT también lo son a su vez. La segunda es que los
departamentos IT son sistemas complejos dinámicos adaptativos que
evolucionan a lo largo del tiempo. La tercera es que los componentes de los
departamentos IT, equipos y sub-departamentos también evolucionan con el
tiempo. La cuarta es que estos componentes, cuando se les deja actuar por su
cuenta, suelen no estar bien alineados entre sí o con la empresa. Peor aún,
estos equipos pueden estar trabajando según sus “estrategias de mejora”
optimizadas localmente para ellos. Esta falta de alineamiento, debidas a las
visiones de liderazgo en competencia (o menos delicadamente, por “la
política”) y están además exacerbadas por los cuerpos de conocimiento
(BoK) dispares que hay disponibles en nuestra industria:

El movimiento ágil, dispar en sí mismo, basado en el manifiesto

ágil, agilemanifesto.org
El BoK del Project Management Institute (PMI), pmi.org/PMBOK-
Guide-and-Standards.aspx
El BoK de Gestión de datos de DAMA, dama.org/content/body-
knowledge
El BoK de Análisis de negocio, iiba.org/babok-guide.aspx
El marco de trabajo para arquitectura del Open Group (TOGAF),
opengroup.org/togaf/
La Biblioteca de infraestructura de tecnología de información
(ITIL), axelos.com/best-practice-solutions/itil
El marco de trabajo Objetivos de control para tecnologías de la
información y relacionadas (COBIT),
isaca.org/COBIT/Pages/default.aspx
Y muchos otros

Aunque todos estos cuerpos de conocimiento proporcionan información

valiosa, cada uno propone su propia visión optimizada localmente de como
las cosas habrían de funcionar. Estas visiones se solapan entre sí, proponen
consejos inconsistentes y frecuentemente se orientan a una única
especialidad. Por ejemplo, el BA-BOK proporciona una visión centrada en el
analista de negocio, TOGAF proporciona una visión centrada en la
arquitectura, el DM-BoK proporciona una visión centrada en los datos, y así
sucesivamente. Todas son vistas valiosas en sí mismas, pero cuando se
combinan juntas, una práctica común en las organizaciones actuales que
buscan seguir las “mejores prácticas”, prueban resultar en un “batiburrillo”
poco efectivo. DA 2.x proporciona una vista coherente, integrada y de alto
nivel respecto como un departamento podría afrontar estas áreas clave de una
manera flexible y evolutiva. Allá donde es posible, DA 2.x referencia las
ideas efectivas que se encuentran en esos cuerpos de conocimiento y las
complementan con estrategias que son más consistentes con los enfoques
ágiles modernos. El siguiente diagrama resume el marco de trabajo DAD 2.0.
A continuación se describe el contenido del marco de trabajo DA 2.x:

1. Soporte completo al contenido anterior. DA 2.x contiene DA

1.x por completo, extendiéndolo para dar soporte a toda la
función IT. Una extensión es la inclusión explícita del soporte
para gestión de programas, con objeto de afrontar como se
organizan los equipos ágiles/lean grandes.
2. Introducción de las láminas de proceso. DA 2.x se ha
organizado en componentes llamados “láminas de proceso”.
Como se puede ver en el siguiente diagrama, cada lámina de
procesos se dirige a una de las actividades principales dentro de
IT. Ninguna de las láminas es una isla en sí misma, los flujos de
trabajo involucran actividades de varias láminas. Esto implica
que cambios en un área, como una mejora de procesos o un
cambio en la estructura organizativa de las personas
involucradas, afectará a la instanciación de las demás láminas
en la empresa. Esta interconexión de procesos y de estrategias
organizativas es una reflexión del hecho que los departamentos
IT son sistemas complejos adaptativos.
3. DevOps disciplinado. Esto es la integración de las actividades
de desarrollo, operación y soporte de las soluciones IT con
objeto de proporcionar un mejor resultado a la organización.
Esto extiende Disciplina Ágil de Desarrollo para incluir
enfoques ágiles/lean a la organización de IT (muchos
departamentos tienen que compaginar los procesos tradicionales
además de los ágiles/lean), gestión de despliegues, operaciones,
soporte al usuario y gestión de datos.
4. IT disciplinada. Esta parte del marco de trabajo incluye
láminas de proceso que cruzan toda la función IT. Esto incluye
gestión de personas (a veces llamadas recursos humanos o
gestión del talento), gestión de producto, gestión de la cartera
de proyectos, arquitectura empresarial, ingeniería del reúso,
gobierno de IT y mejora continua.

Las láminas de proceso de Agilidad Disciplinada 2.0

Las láminas de proceso son:
 Ágil/Básico. Describe el ciclo de vida completo de desarrollo
del proyecto para equipos que trabajan de manera ágil o
siguiendo Scrum. Esta opción es la habitual para equipos que
sean nuevos a la agilidad, o que se encuentran en situaciones
donde les resultan efectivos los ciclos repetitivos en la
planificación del trabajo.
Despliegue Continuo. Describe el ciclo de vida completo para
la realización de soluciones para equipos que trabajan con
despliegue continuo. Los equipos de proyecto en entornos
DevOps suelen escoger esta estrategia.
Mejora continua. Describe como dar soporte a la mejora de la
estructura organizativa y de los procesos de una manera ligera y
colaborativa, como dar soporte a experimentos de mejora dentro
de los equipos y como gobernar la mejora de procesos dentro de
los departamentos IT.
Gestión de datos. Describe como mejorar la calidad de los
datos, evolucionar activos de datos, como son los datos
maestros o los de soporte a pruebas, y como realizar las
actividades de gobierno de datos en la organización.
Arquitectura empresarial. Incluye estrategias para dar soporte
a los actores interesados y a los equipos de proyecto, resolver
dependencias técnicas entre soluciones, evolucionar la
arquitectura de empresa y a gobernar la arquitectura
empresarial. En las siguientes páginas se muestran dos ejemplos
de diagramas de metas de DA 2.0, las lámina de proceso de
Arquitectura Empresarial y de Gestión de la Cartera de
Proyectos.
Exploratorio/Lean Startup. Describe el ciclo de vida completo
para la realización de soluciones para equipos que trabajan de
una manera exploratoria o “lean startup”. Los equipos que se
encuentran en situaciones que demandan una innovación rápida
suelen escoger habitualmente este ciclo de vida.
Gobierno de IT. Incluye estrategias para consolidar varias
vistas de gobierno, definir y tomar métricas, monitorizar y

crear informes sobre la gestión de indicadores, desarrollar y capturar

guías sobre procesos, definir roles y responsabilidades, compartir
conocimiento dentro de la organización, gestionar riesgos
tecnológicos y coordinar las actividades de gobierno tecnológico
(incluyendo el de la arquitectura empresarial).
Lean/Avanzado. Describe el ciclo de vida completo para la
realización de soluciones para equipos que trabajan según Lean
o Kanban. Los equipos que tienen muchos requisitos pequeños
y relativamente independientes (p.e. peticiones de cambio o
defectos) suelen escoger este ciclo de vida.
Operaciones. Incluye como gestionar los sistemas, evolucionar
la infraestructura de IT, gestionar el cambio dentro del
ecosistema operativo, mitigar desastres y gobernar las
operaciones IT.
Gestión de la cartera de proyectos. Incluye como identificar
valor de negocio que podría obtenerse mediante iniciativas IT,
explorar estas iniciativas potenciales para entenderlas con
mayor detalle, priorizar estas iniciativas, iniciarlas, gestionar a
los proveedores y gobernar la cartera de proyectos de IT.
Gestión de productos. Incluye estrategias para gestionar un
producto, incluyendo estrategias para asignarle las
características, evolucionar la visión de negocio para un
producto, gestionar las dependencias funcionales y
comercializar la línea de productos.
Gestión de programas. Incluye las estrategias para gestionar
grandes equipos de producto o proyecto, asignar los requisitos
entre subequipos, gestionar las dependencias entre subequipos,
coordinar a estos (con cadencias comunes o dispares) y
gobernar un programa.
Gestión de despliegues. Incluye estrategias para planificar la
programación de despliegues IT, coordinar los despliegues de
soluciones (como “trenes de despliegue” o “ventanas de
despliegue”), gestionar la infraestructura de despliegue, dar
soporte a equipos de proyectos y gobernar las actividades de
despliegue.
Gestión de la reutilización. Incluye como identificar y obtener
activos reusables, publicar estos activos para que puedan ser
reusados y dar soporte a los equipos de proyectos en la
reutilización de activos.
Soporte. Incluye como adoptar una estrategia de soporte IT,
como escalar incidentes, como tratar con efectividad estos
 incidentes y el gobierno del soporte IT.

¿Por qué la IT Ágil Disciplinada?

El entorno de negocio está creciendo continuamente en competitividad, con
pequeñas organizaciones ágiles que compiten en los mercados
internacionales con grandes compañías establecidas. Esto pone una mayor
presión a las compañías existentes para responder con rapidez y efectividad.
La única manera en que pueden hacer esto es si tienen departamentos de IT
ágiles y con suficiente capacidad de respuesta. Para hacer este desafío aún
mayor, estos departamentos deben reaccionar a las necesidades cambiantes de
la organización a la vez que mantienen una infraestructura que funcione sin
problemas. Una respuesta efectiva ha de pasar por tomar un enfoque flexible
y holístico sobre la IT. Esto es exactamente lo que pretende la Agilidad IT
Disciplinada.
Donde obtener más información
Existen tres fuentes principales para información sobre Agilidad IT
Disciplinada:

1. La página web de DAD. Nosotros publicamos

frecuentemente artículos y entradas del blog en
DisciplinedAgileDelivery.com.
2. La página web de DAC. En
DisciplinedAgileConsortium.org contiene variedad de
documentación técnica, presentaciones, grabaciones y
posters disponibles para su descarga gratuita.
3. LinkedIn. Existe un grupo sobre Disciplina Ágil de
Desarrollo (DAD) con un foro de discusión muy activo.
4. Nuestro próximo libro. Este libro tiene su fecha de
publicación planificada para el primer trimestre de 2016 y
su título tentativo es The Disciplined Agile IT Department.

El Disciplined Agile Consortium (DAC) está invirtiendo activamente en la

evolución del marco de trabajo Disciplined Agile. Esperamos que escoja
involucrarse en esta iniciativa.
 ÍNDICE

#
#NoEstimates, 96

A
Alcance
descontrol, 72
Arquitectura Empresarial, 40, 105
Aseguramiento de la calidad (QA), 92

B
BDD, 93
Blog de DAD, 5
Burndown, 55, 90

C
Certificación de DAD, 6, 100
Ciclo de vida
Ágil/Básico, 18
Avanzado/Lean, 18
Despliegue continuo, 19
Despliegue Continuo, 89, 96
Exploratorio, 15, 19, 97
COBIT, 102
Compromiso, 57
Conformidad con estándares, 28

D
DAMA, 102
Desarrollo de software lean, 14
Desarrollo dirigido por aceptación, 93
Desarrollo dirigido por comportamiento, 93
Despliegue automatizado, 78
DevOps, 19, 96
DevOps disciplinado, 104
Diagrama de Gantt, 46
Diagrama de meta, 20
Documentación, 12, 75
Continua, 75
Entregable, 86

E
Entorno de desarrollo, 48, 81
Escalar
factores potenciales, 28
la agilidad, 26
Explorar el alcance inicial, 20, 38

F
Fallar rápido, 27
Fase
Construcción, 18
Inicio, 37
Transición, 85
Formación, 37
a soporte, 79
a usuarios finales, 86
Funcionalidades activables, 40

G
Gestión
de la cartera de proyectos, 107
de producto, 104
de programas, 104
Gestión de datos, 102, 105
Gestión de defectos, 81
Gobierno de IT, 105
Gráfica de tendencia, 81

H
historia de DAD, 101
Historias de usuario, 39
Hito
Actores satisfechos, 46
Arquitectura validada, 54, 66
Funcionalidad suficiente, 79, 84
Visión de los actores interesados, 50
Hoja de ruta
de negocio, 67
tecnológica, 40

I
IBM, 101
Integración continua, 7, 19, 64, 78
Inteligencia de desarrollo, 79

K
Kanban, 18

L
Láminas de proceso, 104

M
manual de arquitectura, 42
mapa conceptual, 23
Mapa de Historias, 39
maquetas de pantalla, 63
Medición de la mejora, 91
Micro-servicios, 41, 94
Modelado
de datos, 21
de la arquitectura, 42
de requisitos, 32
de uso, 39
justo a tiempo (JIT), 64
ligero, 38
previo, 60, 63
Modelado Ágil, 12

O
Operaciones, 34, 107

P
Planificación
centrada en alcance, 46
centrada en la fecha, 46
de la iteración, 18
del Plan de entregas, 53
detallada, 45
inicial, 7
Planificación de la iteración, 53, 63, 71
Planning Poker, 44
PMI, 102
Priorización, 74
Programación Extrema, 12, 14
Pruebas
automatizadas, 19
de aceptación, 55
de regresión, 48
exploratorias, 58
independientes en paralelo, 83
unitarias, 55, 71
Pulir la calidad, 68, 74, 81

R
Retrospectiva, 55, 59
Reunión de coordinación, 18, 54
Reutilización, 107
Revisión de la iteración, 55, 58
Riesgo
identificación, 38
riesgo-valor, 12
técnico, 43
Roles
de DAD, 13
principales, 13
secundarios, 13

S
Scrum, 12
sensible al contexto, 28
Solución usable, 15
Soporte, 34
Spike, 43

T
Tablero de tareas, 55
TOGAF, 102

V
Visión de la arquitectura, 40

W
WaterScrumFall , 7
 SOBRE LOS AUTORES

Scott W. Ambler es Socio consultor sénior de Scott Ambler + Associates, y

trabaja con organizaciones de todo el mundo ayudándoles a mejorar sus
procesos de software. Proporciona formación, coaching y mentorización
sobre agilidad disciplinada y estrategias lean a nivel de proyecto y
organizativo. Scott es el fundador de las metodologías Agile Modeling (AM),
Agile Data (AD), Disciplina Ágil de Desarrollo (DAD), y Enterprise Unified
Process (EUP). Es (co-)autor de varios libros, como Disciplina Ágil de
Desarrollo, Refactoring Databases, Agile Modeling, Agile Database
Techniques, The Object Primer 3rd Edition y The Enterprise Unified
Process. Scott escribe sobre DAD en DisciplinedAgileDelivery.com. Scott
es miembro fundador del Disciplined Agile Consortium (DAC), la entidad
certificadora para la agilidad disciplinada.

Mark Lines es Socio director de Scott Ambler + Associates. Es Coach Ágil

Organizativo y co-creador del marco de trabajo Disciplina Ágil de
Desarrollo. Mark es co-autor con Scott Ambler de Disciplina Ágil de
Desarrollo: A Practitioner’s Guide to Agile Software Delivery in the
Enterprise. Mark ayuda a organizaciones de todo el mundo a transformarse
desde enfoques tradicionales a métodos de agilidad disciplinada y lean.
Escribe para varias publicaciones, incluyendo el Cutter Consortium y es un
ponente habitual en conferencias del sector IT. Mark escribe sobre DAD en
DisciplinedAgileDelivery.com y es miembro fundador del Disciplined Agile
Consortium (DAC), la entidad certificadora para la agilidad disciplinada.
 SOBRE EL TRADUCTOR

Àlex Ballarín es director de Itnove.com, consultora sobre

Agilidad, DevOps y Lean IT, desde donde trabaja con clientes
españoles ayudándoles en su transformación ágil y lean de toda la
empresa, incluyendo márketing, desarrollo de software,
operaciones IT o dirección de informática (CIO). Àlex tiene, entre
otras, las siguientes certificaciones profesionales: DAD Yellow
Belt, PMP, Professional Scrum Master, Professional Product
Owner y Management 3.0 Practitioner. Anteriormente trabajó en
Lotus Development Corporation e IBM Rational Software.

[1] Ver ScottAmbler.com/insights.html y Ambysoft.com/surveys/

[2] Vea una extensión del Manifiesto Ágil para empresas en
Disciplinedagiledelivery.com/disciplinedagilemanifesto/

[3] Leer DisciplinedAgileDelivery.com/lifecycle para más información.

[4] Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise
(Ambler and Lines, 2012).
[5] Todos los diagramas de proceso pueden encontrarse en: DisciplinedAgileDelivery.com/process-
goals/
[6] La lista de cursos sobre DAD puede encontrarse en: DisciplinedAgileConsortium.org
[7] Ver User Story Mapping por Jeff Patton, O’Reilly Media 2014.
[8] Para estrategias prácticas, ver Working Effectively with Legacy Code de Michael Feathers (Prentice
Hall 2004) y Refactoring Databases de Scott Ambler y Pramod Sadalage (Addison Wesley 2006).
[9] See http://noestimates.org/blog/