martes, diciembre 15, 2015

Buenas y Malas Prácticas en el Review / Demo de Scrum

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).

Ejemplos de Artefactos Empleados en Metodologías Ágiles / Scrum UNAB 2015-02

Hola a todos

Siempre he reconocido en los ejemplos el poder de ayudarnos a comprender mejor los conceptos.

Nuevamente les comparto el resultado del trabajo de la cátedra TÓPICOS TÉCNICOS  II, que impartí en la ESPECIALIZACIÓN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DEL SOFTWARE, de la Universidad Autónoma de Bucaramanga (Colombia).

En esta materia vimos tanto el Agile Inception, el desarrollo y ejecución de un proyecto empleando Scrum, como la atención de un area de gestión de incidentes empleando Kanban (debo un post sobre este tema).

Los entregables desarrollados son:

  • Agile Inception
    • Mapa de Impacto (Impact Map)
    • Product Vision Board
      • Visión
      • Grupos de usuarios
      • Necesidades
      • Funcionalidades
      • Beneficios
    • Product Backlog  Board
      • Técnica Personas
      • Restricciones
        • Lo que no nos deja dormir (Riesgos)
        • Sería genial que pasara (Oportunidades)
        • Prioridades (alcance, tiempo, costo, calidad, usabilidad, adaptabilidad, seguridad, etc)
        • Incluido en el alcance
        • Fuera del alcance
      • Modelos /Diagramas
        • Despliegue
        • Procesos
        • Diagrama de contexto
        • Mockups
    • User Story Map / Construcción del Release Plan 
    • Calculo del tiempo y costo de la construcción del producto,  empleando una hoja de cálculo de mi autoría (clic aquí para acceder a la hoja de cálculo y su explicación)
    • Construcción del Product Backlog basado en requerimientos con historias de usuario
  • Simulación de Scrum
    • Simulación de tres sprints de scrum, durante una sesión de 4 horas, generando los siguientes entregables:
      • Historias de usuario
      • Bocetos asociados a las historias de usuario
      • Gráfica de Burndown de cada Sprint
      • Gráfica de Velocidad
      • Gráfica de Release Burn Up
      • Mejoras identificas cada sprint


En estos links encontrarán los cuatro proyectos con los entregables citados:

  • SerVIP -Sistema para la notificación oportuna de daño en los servicios públicos  link
  • Enjoytravel -Sistema planear un viaje empleando un vehículo propio- link

Espero los disfruten y les ayude en sus proyectos.

Saludos ágiles

Jorge Abad

sábado, diciembre 05, 2015

Ejemplo User Story Map - Solicitud de Crédito

Hola a todos

Les comparto este Mapa de Historias de Usuario - User Story Map, para un proceso de solicitud de crédito.

User Story Map - Sin Priorizar



User Story Map - Con Releases



Espero les sea útil.


Saludos Ágiles

Jorge Abad.





viernes, diciembre 04, 2015

Ejemplo Mapas de Impacto - Impact Map

Hola a todos

Les comparto dos mapas de impacto que elaboré en clase, bien recibido el feedback.

Mapa de Impacto - Reducción de tiempo de solicitud de Crédito

Mapa de Impacto - Reducción de accidentalidad


Saludos ágiles
Jorge Abad