En nuestro grupo trabajamos con Scrum o Kanban, según la dimensión del cambio o proyecto. Con Scrum, al terminar un Sprint convocamos a todos los participantes del proyecto: desarrolladores, arquitecto, dueño del producto, certificadores. Y hacemos una demostración del software que estamos entregando. Con Kanban, hacemos lo mismo al dar por terminada una tarjeta de nuestro tablero.
Llevamos más de un año haciendo demostraciones de nuestros Sprints y algunos meses haciendo demostraciones de lo planificado en nuestro tablero Kanban. ¿Qué aprendimos hasta ahora?
Nuestras demostraciones hacen foco en:
- contar las historias terminadas, mostrando el software o el entregable que correponda para la historia
- mostrar nuestra integración contínua, con sus indicadores de calidad en el software y la cantidad de software cubierto con pruebas automáticas
- gestión del conocimiento, compartiendo investigaciones o cosas nuevas que surjieron en el Sprint
En el primer caso, logramos que el usuario o certificador que viene a la demo verifique que el software hace lo acordado en cada historia. Y en este punto, ¿qué ocurre si en la demo no tenemos dueño del producto ni certificadores? A priori, parecería ser que si nosotros hicimos todo lo necesario para que las cosas estén como queremos y aún así nuestras demos no tienen auditorio, nada podemos hacer. La pregunta podría ser: ¿hacemos todo lo necesario?
Les comparto algunos consejos de Richard Lawrence:
- Enfoque en los criterios de aceptación: Usted ha definido lo que significa hacer de la historia, entonces enfoque la demo en lo que hizo realmente.
- Comience el desarrollo con la demo en mente: No espere a pensar en la demo hasta que haya terminado con la historia. Usted puede ser capaz de escribir pruebas como scripts de demostración. Y lo mejor es planificar su demo para una historia mientras está fresca en su mente, antes de pasar a la siguiente historia.
- Prepare. No improvise. Piense a través de un interesante escenario para demostrar que cubre con los criterios de aceptación. Cree los datos de prueba. Utilice herramientas para conseguir que la aplicación esté en un estado donde usted puede comenzar una demostración interesante.
- Práctique. Ejecute la demostración por lo menos una vez. Cuando esté empezando, es posible que desee hacerse con una versión de prueba y que sirva de ayuda memoria. Dolorosa, ¿eh? Eso sólo significa que usted necesita trabajarlo.
- Cuente una historia. Centre la demostración en torno a un usuario realista resolviendo un problema real. La cuestión no es sólo para mostrar que el software funciona, sino para mostrar que es valioso.
- Sea breve. Si usted trabaja en sus historias de una a la vez y logra su aceptación cuando estén listas, usted no necesita abarcar exhaustivamente todos los criterios de aceptación en su demo. En su lugar, centrar su demo en lo que es interesante y valioso en la nueva funcionalidad.
La demo debería ser la parte más emocionante de Scrum. Es cuando el equipo tiene que mostrar a todos todo el valor que estamos entregando. Que vale la pena invertir un poco de tiempo para hacerlo bien. Usted puede encontrar que los interesados previamente desinteresadamente empiezan a llegar justo para la muestra.
¿Qué ha funcionado bien para usted en las demos? ¿Qué no ha funcionado?
