Una cascada iterativa no es ágil
En los últimos dos años he notado una tendencia preocupante, en equipos de todas partes del mundo.
Es la tendencia a crear un proceso de cascada iterativo y llamarlo "ágil".
Una cascada iterativa
En un Sprint, alguien (quizás un Business Analyst junto con el Product Owner), intenta averiguar qué se debe desarrollar.
Como se quiere ser ágil, se trabaja con User Stories. Pero en lugar de tratar las User Stories como marcadores de posición para conversaciones posteriores, cada User Story se convierte en un pequeño documento de especificación de tres a cinco páginas de contenido, y he visto algunos incluso más largos.
Estas mini-especificaciones/User Stories documentan casi todo lo que se pueda imaginar al respecto.
Como se necesita un Sprint entero para averiguar y documentar todo esto, se dedica un segundo Sprint al diseño de la interfaz de usuario de la User Story. A veces el equipo intenta ser un poco más ágil (al menos en teoría) y comienza con el trabajo de diseño poco antes de que la mini-especificación de una User Story esté completamente escrita.
Muchos miembros del equipo ven esto como peligroso, porque las especificaciones aún no están completamente capturadas. Pero bueno, ahí es donde entra la agilidad.
Los programadores reciben entonces dos documentos. Uno muestra clara y detalladamente cómo debe verse la User Story al final, y el otro proporciona todos los detalles relevantes sobre el comportamiento de la Story.
No se puede empezar a programar hasta que estos dos artefactos estén terminados. En algunas empresas, son los propios programadores quienes fuerzan esta forma de trabajar. Tienen la actitud de desarrollar todo lo que se quiera, pero es mejor que se les diga exactamente qué se necesita al inicio del Sprint.
Algunas organizaciones van un paso más allá y hacen que los testers trabajen una iteración por detrás de los programadores. Esto aparentemente sucede porque las User Stories de un equipo se vuelven más grandes cuando cada Story necesita una mini-especificación y un diseño de UI completo antes de poder escribir código.
Afortunadamente, la mayoría de los equipos entienden que programadores y testers deben trabajar juntos en la misma iteración, sin embargo, no extienden esta teoría a todo un equipo que colabora en conjunto.
Esto conduce al siguiente proceso
Una primera iteración se dedica al análisis. Una segunda iteración (que puede solaparse ligeramente con la primera) se dedica al diseño de experiencia de usuario, y la tercera iteración es para codificar y probar. Esto no es ágil. Podría ser el primer paso de una organización para volverse ágil. Pero no es ágil.
Es una cascada iterativa.
En el desarrollo tradicional con cascada, un equipo realiza todo el análisis para todo el proyecto al principio. Luego se aborda todo el diseño para el proyecto. Luego se escribe todo el código para el proyecto. Luego se realizan todas las pruebas para el proyecto.
En el proceso de cascada iterativa descrito anteriormente, el equipo hace básicamente lo mismo, pero cada Story se trata como su propio pequeño proyecto. Primero se completa todo el análisis para la Story, luego el diseño para esa Story, luego se escribe todo el código y se prueba todo. Es un proceso de cascada iterativo, no un proceso ágil.
En un proceso ágil, idealmente todo el trabajo se completaría exactamente al mismo tiempo. El equipo terminaría al mismo tiempo el análisis del problema, el diseño de la solución, el código y las pruebas para esa solución. Las cuatro disciplinas (y otras que no he mencionado en este ejemplo) terminarían exactamente al mismo tiempo.
Es algo ingenuo creer que se puede lograr esto al 100%. (A veces se puede lograr.) Sin embargo, puede ser un objetivo hacia el que un equipo trabaje.
Un equipo siempre debería intentar realizar la mayor cantidad de trabajo posible de forma simultánea. Todas las consideraciones que se hacen de antemano (análisis, diseño, etc.) deberían realizarse lo más tarde posible, no ser demasiado detalladas y al mismo tiempo permitir que el trabajo se pueda completar durante la iteración.
Si estás tratando tus User Stories como pequeños documentos de especificación, deja de hacerlo. En su lugar, comienza a ver cada Story como un marcador de posición para una conversación. Puedes añadir a las Stories algunas notas sobre cosas que no quieres olvidar en la próxima reunión. Pero estas notas deberían ser opcionales y no un paso necesario en un proceso secuencial. Esto mantiene la agilidad y evita que el proceso se convierta en una cascada.
Este texto proviene del blog de Mike Cohn y fue traducido al español.
Gestión de Stakeholders
=> Aprende los consejos y trucos más importantes de Roman Pichler sobre gestión de Stakeholders
Definition of Done: simple y a la vez compleja
=> Descubre cómo la Definition of Done te ayuda en el trabajo ágil.
¿Cómo funciona una Sprint Review?
=> Aquí encontrarás una agenda de ejemplo para la Sprint Review
