viernes, 25 de noviembre de 2016

¿Cómo sería un buen juego de simulación de un proyecto ágil con Scrum?

Este es un ejercicio del curso de Scrum de
En mis clases presenciales uso una simulación de Scrum que es una gran evolución de "Una simulación Ágil completa en 75 minutos" de Brian Bozzuto y Giora Morein (BigVisible Solutions). El objetivo de las misma es:
Value Stream Mapping

Value Stream Mapping de la compra on-line
La simulación empieza por la selección de un flujo de valor, un proceso de negocio, sobre el que trabajar. Recordemos que la mecanización a través de software trata diferentes flujos de valor a los que hay que dar solución. La propuesta del ejercicio se basa en la construcción de una tienda de venta on-line de libros, un buen ejemplo, ya que la mayoría de nosotros estamos familiarizados con tiendas on-line como Amazon.

 El ejercicio se centra en el flujo de valor que cubre el flujo de compra desde la perspectiva del cliente, ¿qué pasos ha de dar un cliente cuando llega a nuestra web y quiere comprar un libro? Hay otros flujos de valor, como la logística de la entrega o la gestión de devoluciones, pero la simulación requiere un solo flujo y el más conocido por todos es el flujo de compra.

 User Story Mapping

 En este punto le explico a los alumnos que son un equipo de negocio y que han de definir de forma colaborativa cuales son los pasos de su flujo de valor. Comúnmente estos pasos son algo como:
  • Encontrar libro
  • Seleccionar libro
  • Entrar dirección de entrega
  • Pagar
  • Confirmación de compra
Obtenidos los pasos del flujo de valor, los alumnos desarrollan cada paso con funcionalidades que lo cubran, por ejemplo:
  • Encontrar libro:
    • Búsqueda por título
    • Búsqueda por autor
  • Seleccionar libro:
    • Añadir al carrito
    • Modificar carrito
    • Quitar del carrito
  • Pagar:
    • VISA
    • PayPal
    • Contrareembolso
Obtención de las funcionalidades que cubren el flujo de valor a través de un User Story Mapping
Una vez obtenidas las funcionalidades resalto a los alumnos que el conjunto es el "big picture" de nuestro flujo de valor, el proceso que cubre esa parte del producto. Recordemos que a través del User Story Mapping hemos obtenido las funcionalidades de forma colaborativa, lo que implica que están representadas todas las perspectivas del equipo de negocio. Les suelo preguntar a mis alumnos si ese conjunto de funcionalidades sería un buen software... lo es sin duda, todos conocemos la compra on-line y de seguro que no falta nada importante.

 Planificación de release

Amazon se fundó en 1994
y vendió su primer libro en 1995
Para ser una pila de producto es necesario que las funcionalidades estén priorizadas por valor de negocio y en la simulación lo hacemos con una primera planificación de release. Dividimos una hoja de rotafolio en tres áreas con tres releases, R1, R2, R3.

 Les explico a los alumnos que la R1 es el MPV, el Mínimo Producto Viable, para salir al mercado y validar que existe una necesidad de mercado, y que decidan qué funcionalidades van a trasladar del tablero User Story Mapping a esta release, de forma se lance a producción lo mínimo de lo mínimo de lo mínimo.

 Les muestro una imagen de como era la página web de Amazon en sus primeras versiones a mediados de 1990, y les hablo del consejo de Reid Hoffman, cofundador de LinkedIn que dice:

"Si no te avergüenzas de tu primer producto, es que lo lanzaste muy tarde"

En la planificación de release los alumnos trasladan las funcionalidades a 3 releases en función del valor de cada una
En R2, el segundo lanzamiento al mercado, van las MMF, las Minimum Marketable Features, el paquete mínimo de las siguientes funcionalidades importantes que no son necesarias en el MPV, pero son determinantes para nuestro negocio. En R3 va el resto de las funcionalidades, no tiene mucho sentido desglosar en releases más allá, ya que simplemente no sabemos hacia donde nos llevará el mercado. A media que avancemos, entreguemos releases y tomenos feedback del mercado irán apareciendo las subsiguientes, de manera que con 3 releases a la vista es suficiente para una buena hoja de ruta de nuestro proyecto.

 En este punto finaliza la primera parte de la simulación, el equipo se ha sentido en la piel de negocio, ha experimentado la priorización por valor y obtenido una pila de producto inicial.

 Planificación de sprint

Pila de producto con tareas preparadas
En este punto comienza la segunda parte de la simulación en la que los alumnos se ponen en la piel del equipo de Scrum (equipo desarrollo, Propietario del Producto y Scrum Master).

 Es necesario una primera fase preparatoria en la que ocurren las siguientes actividades:

 En primer lugar consideramos que el orden de izquierda a derecha y de arriba a abajo es el orden de prioridad según valor de negocio.

 Hay que poner un ID en cada funcionalidad y esto lo hacemos enumerándolas del 1 en adelante. Otra propiedad de un elemento de la pila de producto es que ha de estar estimado, por tanto han de buscar el elemento más pequeño en esfuerzo, asignarle el 1 y estimar el resto de forma relativa. (Les invito a no ser minuciosos y hacer estimaciones muy rápidas, realmente no importan las estimaciones, lo que importa es que haya variedad de valores).

 Para experimentar autoorganización les indico a los alumnos que deben de dividir todas las funcionalidades en tres tareas (A-Análisis, D-Desarrollo y T-Testing) y que desglosen el valor de la estimación en las tareas de forma que sumen. Esta actividad la han realizar todos ellos en paralelo de manera que en poco tiempo se obtengan todas la tareas. Es interesante observar las diferentes formas que tienen los equipos de organizarse, en algunos casos cada miembro desglosa funcionalidades, en otros casos algunos miembros calculan y otros preparan post-its... cada equipo es único.

 Para acabar el equipo ha de elegir un rol para cada miembro:
Un dado determina el trabajo hecho en un día
La unidad en que se estima el tamaño de las funcionalidades es el punto de dado. Les explico a los alumnos que para introducir variabilidad en la simulación el que va a determinar el trabajo hecho por un miembro de equipo en un día será el dado. Una tirada aplicada a la especialidad del que ha tirado el dado, puntúa doble, sino simplemente puntúa lo que marca. A veces es mejor ayudar a un compañero para así terminar y entregar un sprint con más valor.
A partir del segundo sprint animo al Propietario del Producto a cambiar las prioridades de la pila de producto y a introducir nuevas funcionalidades. Entre otras les propongo explicar que hemos observado que los clientes de nuestra web están siendo predominantemente padres de familia que están comprando libros de texto, y que hay que introducir una nueva funcionalidad muy prioritaria, la búsqueda por ISBN.

El equipo ejecuta las tareas, cada miembro del equipo lanza el dado para determinar el esfuerzo que realizará en ese turno:
  • Más de una persona puede trabajar sobre la misma tarea
  • No hay dependencias entre tareas, se puede testear antes de desarrollar
  • Una vez que una persona finaliza su tarea (por ejemplo, análisis) puede colaborar en otra
  • Recordar que las personas que trabajan en su especialidad trabajan el doble de rápido (se multiplica por 2 el resultado de lanzar el dado)
  • Si un analista lanza un 1, entonces no trabaja porque hay una cuestión sobre una funcionalidad. El equipo debe añadir 2 puntos a la funcionalidad de análisis
  • Si un desarrollador lanza un 1, entonces no trabaja porque hay una cuestión sobre una tarea. El equipo debe añadir 2 puntos a la funcionalidad de análisis
  • Si un tester lanza un 1, no trabaja porque se ha encontrado un error en las pruebas. El equipo debe añadir 2 puntos a la funcionalidad de desarrollo para corregir el error
Tablero Kanban con tareas avanzando
Burndown

Tablero de gráficos burndown
A lo largo de las reuniones diarias de los tres sprints el equipo registra los puntos de dado pendientes en un gráfico burndown para hacer visible su avance y tomar decisiones en caso de alejarse de la linea ideal.

 Empezado el tercer sprint sorprendo al equipo a medio sprint y me presento con el "Presidente de la compañía" que intenta colarles de forma "dura" una funcionalidad: el informe de ventas. La idea es intentar romper el sprint y el compromiso del equipo, cosa que de seguro pasará en su realidad, y así impregnar al equipo de Scrum con que no deben de permitir que rompan su compromiso. Guío primero al equipo, luego al Scrum Master y finalmente al Propietario del Producto en como argumentar al presidente que es una mala idea:

El equipo simplemente debe de tomar nota de la nueva funcionalidad, mencionar que se la trasladarán al Propietario del Producto quién es el quién conoce el negocio y es responsable del producto. No deben de aceptar la funcionalidad, incluirla en el sprint y comprometerse, su foco debe de estar en seguir trabajando en el sprint actual tal como se planificó.

 El Scrum Master debe de argumentar al presidente desde el marco de Scrum, explicar que Scrum funciona por sprints de 5 días en los que el trabajo está en consonancia con la capacidad del equipo, y por tanto incluir algo no planificado pone en riesgo la entrega para el siguiente viernes. ¿Seguro que quiere eso Sr.Presidente? ¿El informe no puede esperar al lunes que viene cuando empiece el siguiente sprint?

 Finalmente vienen los argumentos del Propietario del Producto, en la realidad este tiene muchos ya que conoce el negocio. En la simulación hago para que con ese sprint se finalice una release, así que el Propietario del Producto tiene un argumento muy sólido ya que con ese sprint salimos a producción y cualquier interferencia puede poner en riesgo el lanzamiento, ¿Quiere eso Sr.Presidente?
Aspecto de los tableros y post-its de la simulación
Los alumnos se lo pasan francamente bien y aprenden motivados con esta simulación de cuatro horas, os animo a probarla, es muy completa y sin duda la recordarán por mucho tiempo :-)
Historias técnicas en la pila
Las buenas ideas siempre surgen cuando hay choques de ideas de diferentes personas. En un curso reciente el equipo le pidió al Scrum Master que intentara conseguir un segundo dado... y nos pusimos el reto de como podría hacerse eso.

 ¿Cómo podemos aumentar la velocidad de un equipo de una forma tan espectacular? Pues reduciendo el coste de transacción, en otras palabras, implementado integración continua y pruebas automatizadas.

Equipo que pidió un segundo
dado en plena simulación :-D
Creamos dos post-its con ambas historias técnicas, azules en la imagen, el equipo las estima y las da al Propietario del Producto para que las añada a la pila de producto. Tendrán que negociar con él, esas historias no tienen valor de negocio, y explicarle las consecuencias deseables si se realizan. El dado también se lo damos al Propietario del Producto, en cuanto este priorice las historias técnicas y se hayan completado en un sprint, el equipo recibe el dado para incrementar su velocidad.

 Quiero dar mis agradecimientos a todos los asistentes a mis clases que han hecho la simulación conmigo, ellos han aportado ideas, sus tableros para las fotos y sus ganas de aprender :-D
Publicado por en

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)