| Este es un ejercicio del curso CSD de |
 |
En este post quiero presentar un juego pensado para desarrollar en noventa minutos, en el que los participantes practican cómo incorporar historias técnicas en la planificación de sprint y así reducir la deuda técnica y mantenerla bajo control durante el proyecto.
El objetivo del juego es que equipo de desarrollo ponga de relieve el valor que aporta resolver deuda para el Propietario de Producto, y balancear historias de usuario y técnicas para maximizar el valor entregado al cliente a largo plazo. Este juego proporciona al equipo el espíritu de colaboración necesario para organizarlo en su propia organización con el Propietario del Producto y mostrar la importancia, para el éxito del proyecto, de la incorporación de historias técnicas que ayuden a disminuir la deuda técnica existente.
 |
| Material del juego |
El juego incorpora las historias de usuario que tratan funcionalidades para la construcción de una tienda de venta on-line e historias técnicas que implementan técnicas ágiles como integración continua, refactorización y pruebas automatizadas.
Este juego ha sido inspirado en el "
The Technical Debt Game de David Croley de Agile Velocity.
He incorporado una serie de variaciones para incorporar elementos para una simulación de Scrum más pedagógica y completa.
Para el juego hacen falta 5 personas, un rol de Propietario de Producto y 4 miembros de equipo. El trainer o facilitador, experto en el juego, hará de Scrum Master. Las tareas del Propietario del Producto serán las rellenar la hoja de registro y de negociar con el equipo la deuda técnica a incluir en el sprint según las siguientes directrices:
Las tareas del equipo serán las de debatir las historias de usuario y deuda técnica a incluir y ejecutar la simulación de cada sprint.
Paso 0
Dibujar el tablero sobre una hoja de rotafolios:
Paso 1
 |
| Hoja de registro marcada con el área cumplimentada en cada paso |
Calcular la capacidad del equipo, para ello el Propietario del Producto sumará el impacto de la deuda técnica que afecta a los sprints (sección B). El impacto lo apuntará en la hoja de registro en la fila del impacto y la resta entre la capacidad teórica y el impacto en la capacidad actual para el sprint.
Paso 2
Paso 3
- Cada miembro jugará una tirada de dado por cada uno de los cinco días de la semana, una tirada representará los puntos realizados por persona/día.
- Los puntos de dado se aplicarán restando al coste de las historias de usuario y deuda técnica y se moverán a la columna "En curso" (Sección D). Si el coste queda a 0 se pasarán a la columna "Finalizado" (Sección E).
- El Propietario del Producto anotará el total del equipo en el día correspondiente en la sección de la ejecución del sprint.
Paso 4
 |
| Alumnos en plena ejecución del juego |
Paso 5
 |
| Tablero scrumboard del juego en curso |
- El Propietario del Producto completará el gráfico del sprint utilizando 1 color diferente para dibujar la evolución de cada uno de los siguientes valores:
- Si se acaba de finalizar el segundo sprint, coger 2 tarjetas de deuda técnica y ponerlas en la zona de la pila de producto que afecta al sprint (Sección B), si es el tercer sprint mover la última.
- Coger una tarjeta de sprint (Sección F) y seguir las instrucciones.
- Reiterar y seguir por el paso 1 hasta que se hayan completado los 5 sprints.
Debate final
Con el gráfico delante el equipo sacará conclusiones sobre cómo ha gestionado la deuda técnica y que mejoraría para la próxima partida.
 |
| Hoja de registro con los diferentes gráficos de evolución |
Observando la hoja de registro de un juego real podemos ver las diferentes evoluciones del juego:
Descargas / Downloads
 |
| Primera iteración del juego |
A principios de 2015 impulsado por mi compañero Miguel para crear un curso que tratara la deuda técnica, y habiendo visto el artículo de David Croley, me animé a crear la primera versión del juego. Mis compañeros de entonces me apoyaron en las primeras partidas y me dieron su feedback.
Experimentaron como equilibrar la deuda técnica con las historias de usuario, cómo resolverla les permitía aumentar la velocidad, y como si no lo hacían acababan ahogados por la misma. Recuerdo que comentario que experimentaron lo que todos los equipos de Scrum; los equipos noveles son optimistas y tienen la tendencia a meter mas en los sprints de lo que pueden afrontar.
 |
| Gracias chicos por jugarlo por primera vez y dar feedback, gracias Javier, Roberto y Juan |
Las tarjetas con las historias de usuario para el final de cada sprint.
No hay comentarios:
Publicar un comentario