lunes, 4 de diciembre de 2017

¿Cómo mostrar el impacto de la deuda técnica en una simulación de Scrum?

La deuda técnica ha de gestionarse
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.

La deuda técnica prudente nos hace ser ágiles

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:
Tablero scrumboard del juego que incorpora la deuda técnica
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

Acabado el sprint:
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

No hay comentarios:

Publicar un comentario