o El Review no es una reunión de Testing
Hola a todos
En la medida que se va implantando Scrum, sprint tras sprint, el Scrum Master debe enfocarse cada vez más en que cada una de las reuniones de Scrum y la ejecución del mismo conserven el espíritu del agilismo: dar valor al negocio, con la menor cantidad de software posible a pequeños incrementos.
En este ejercicio se debe velar por que no se caigan en malas prácticas durante las reuniones de Scrum, en este post me enfocaré en la reunión del Review / Revisión / Demostración / Demo (la verdad me gusta más la palabra Demo) la cual esta definida según la guía como:
"Una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración."(1)
A continuación comparto unos tips y malas prácticas que he observado en los Demos:
- Malas prácticas
- Creer que la reunión de Demo es una reunión de User Acceptance Testing (UAT), revisando paso por paso los casos de prueba:
- Esto hace que la reunión se vuelva extensa, que no se cumpla el timebox (2), además ¿Cuándo se logra probar en una reunión de 2 horas el software que se produjo en 2 semanas?, implicando que se desconfía en el "Done" / "Terminado" que asegura el equipo y/o los testers encargados de realizar las pruebas.(3)
- Realizar la Demo con capturas de pantalla (pantallazos) de los casos de prueba que lograron el Done durante el Sprint
- La ventaja del Demo es esa, poder hacer una demo de lo que se hizo, y el hecho de presentar los pantallazos, no cumple con uno de los principios ágiles "software funcionando es la principal media de progreso". Es necesario poder navegar y "jugar" con el software durante la demo.
- No invitar a Interesados / Stakeholders claves a la reunión
- El Product Owner debe trabajar para que haya inspección y adaptación sobre el producto, de esta forma dentro de la reunión del review se brinda a stakeholders claves la posiblidad de realizar feedback sobre el producto y poder dar lineamientos sobre su progreso, el demo es el espacio para realizarlo, y no hacerlo en este tiempo es perder tiempo valioso.
- Buenas prácticas
- Preparar la Demo
- El equipo debe preparar la demo y guardar un tiempo al final del sprint para preparar data a ser usada, ambientes, etc. en caso contrario el review puede llegar a ser fallido, o alguno de los ítems del incremento no funcionar correctamente y no darse por aprobado.
- Cuidar el Timebox
- El Scrum Master debe velar para que el timebox del la reunión se cumpla, proporcionando feedback oportuno a cualquiera de los asistentes cuando alguna solicitud vaya en contra del propósito de la reunión o el tiempo del a misma.
- Realizar revisiones JIT (Just in Time / Justo a Tiempo)
- Esta práctica consiste en que durante el Sprint el equipo cuando alcanza el Done de algún item del Sprint Backlog, lo presenta al Product Owner para recibir feedback, aceptación y/o rechazo del mismo, de forma que no se espera hasta el review, y de esta forma recibir feedback oportuno.
- Esta práctica tiene la ventaja de hacer un review (o demo) más exitoso y más liviano en el tiempo.
Hasta acá esta pequeña lista, espero sea de ayuda y provecho para los demos en sus equipos
Saludos ágiles
Jorge Abad
Referencias y Aclaraciones
(1) Guia de Scrum - scrumguides.org
(2) Timebox de las reuniones de Scrum - clic aquí -.
(3) Existen equipos que no tienen alguien destinado específicamente al testing y existen equipos en que sí, en general lo que hay que garantizar es que el equipo sea multifucional, no polivalente (cada persona sabe realizar bien todos los roles).
