 |
| Cortesía de freedigitalphotos.net |
Este checklist representa una serie de preguntas que cualquier equipo de desarrollo ágil puede plantearse, tanto en el arranque de un proyecto basado en Scrum como en cualquier fase de construcción de un producto, para comprobar su grado de adopción al marco de trabajo.
El grado de adopción será la cantidad de checks cumplidos sobre 65, por encima de un 80% podemos obtener un grado que aporte beneficios en la productividad del equipo y no haber caído en un ScrumBut, pero hemos de recordar que sólo podemos afirmar que trabajamos con Scrum con un grado del 100%.
El checklist se divide en dos secciones: cuestiones sobre aspectos generales y preguntas a tener en cuenta en cada una de las fases del ciclo de Scrum.
ASPECTOS GENERALES
A. PREGUNTAS MÁS IMPORTANTES
Esta parte de checklist es la más importante y a la vez un resumen del resto. La teoría es que si respondemos positivamente a las siguientes cuestiones el resto perderían importancia.
☐ A.1. Entregamos software funcionando y probado cada 4 semanas o menos.
☐ A.1.1. Cada entrega se realiza en un entorno controlado o al que puede acceder el cliente.
☐ A.1.2. Se llevan a cabo liberaciones de versiones antes de cada entrega.
☐ A.2. Entregamos primero lo que aporta más valor de negocio.
☐ A.2.1. Está involucrado el Propietario del Producto en el proceso de priorización de las historias de usuario.
☐ A.3. El proceso de desarrollo se está mejorando continuamente.
B. EN RELACIÓN A LA FIGURA DEL PROPIETARIO DEL PRODUCTO
☐ B.1. El Propietario del Producto está claramente definido.
☐ B.1.1. Tiene la potestad para priorizar.
☐ B.1.2. Tiene el conocimiento para priorizar.
☐ B.1.3. Tiene contacto directo con el equipo y resuelve sus dudas.
☐ B.1.4. Tiene contacto directo con los interesados (clientes finales) y les traslada las dudas que no sabe resolver por sí solo.
C. EN RELACIÓN A LA FIGURA DEL SCRUM MASTER
☐ C.1. Existe un Scrum Master bien definido.
☐ C.2. El Scrum Master está accesible por todos los miembros del equipo.
☐ C.3. El Scrum Master tiene una estrategia para solucionar los impedimentos del equipo.
☐ C.4. El Scrum Master puede escalar fácilmente los impedimentos que no puede solucionar.
D. EN RELACIÓN A LAS ITERACIONES
☐ D.1. No exceden de la duración predefinida.
☐ D.2. El equipo no es interrumpido por agentes externos.
☐ D.3. El equipo generalmente entrega lo que se compromete a hacer.
E. EN RELACIÓN AL EQUIPO
☐ E.1. El equipo tiene las habilidades necesarias para desarrollar las tareas de las historias de usuario del sprint.
☐ E.2. El equipo puede dedicar tiempo a formarse.
☐ E.3. El equipo ve como positiva la metodología y además se divierte siguiéndola.
☐ E.4. Se trabajan 8 horas al día (o el límite de la jornada) y los sobreesfuerzos son voluntarios.
☐ E.5. Se discute, se critica y se experimenta con la metodología.
CICLO DE SCRUM
1. PRODUCT BACKLOG
Se mantiene a lo largo de todo el proyecto con todas las historias de usuario.
☐ 1.1. Están definidas todas las historias, incluidos los epics.
☐ 1.2. Las historias están escritas por el Propietario del Producto o en su lenguaje.
☐ 1.3. El equipo tiene acceso a toda la documentación sobre las mismas y está centralizado en la herramienta de gestión del proyecto.
☐ 1.4. Se ha realizado una estimación de todas las historias del backlog, en la que ha participado todo el equipo.
☐ 1.5. Se actualiza la información después de cada sprint (en función de la velocidad y la estimación dada, la fecha de release de una versión del backlog puede variar).
☐ 1.6. Es de propiedad exclusiva del equipo o hay historias que pertenecen a otros equipos de desarrollo.
☐ 1.7. El Propietario del Producto sabe explicar la motivación de cada historia de usuario para poder priorizarlas.
☐ 1.8. Está priorizado conforme al valor de negocio de cada historia.
☐ 1.9. Las historias tienen una estimación tal que es posible implementarlas en el ámbito de un sprint.
2. SPRINT PLANNING
Se lleva a cabo en el arranque de cada sprint.
☐ 2.1. El equipo completo participa junto con el Propietario del Producto.
☐ 2.2. El Propietario del Producto viene a la reunión de planificación con el listado de historias de usuario priorizadas para el siguiente sprint.
☐ 2.3. El Propietario del Producto ha comunicado con anterioridad el listado priorizado de las historias del siguiente sprint al equipo para que puedan prepararse mínimamente la reunión de planificación.
☐ 2.4. El equipo lleva a cabo una división de las historias en tareas técnicas.
☐ 2.5. Para cada historia se define un DONE, qué entendemos para dar como finalizada una historia, esto es, cuáles son los casos de prueba de la misma.
☐ 2.6. El equipo viene a la reunión con las cartas para estimar.
☐ 2.7. El equipo realiza una nueva estimación de todas las historias.
☐ 2.8. Se estima con una medida relativa de puntos de historia en vez de en tiempo.
☐ 2.9. Por orden, se designa a un miembro del equipo como responsable de preparar la demostración del sprint que estamos planificando.
☐ 2.10. Tras la reunión se actualiza tanto el panel físico como la herramienta de gestión del proyecto con la información actualizada resultado de la reunión de planificación.
☐ 2.11. Tras la reunión se genera el gráfico de burndown recogiendo el total de puntos de historia que incluye el sprint.
3. DAILY MEETING
Ocurre todos los días a una hora prefijada.
☐ 3.1. Ocurre todos los días y participa todo el equipo.
☐ 3.2. No dura más de 15 minutos.
☐ 3.3. Se realiza de pie frente al panel.
☐ 3.4. Cada miembro del equipo habla de lo que ha hecho desde el último daily meeting y de lo que va a hacer hasta el siguiente (hay una estimación de tiempos) señalando las tareas en el panel con las que ha trabajado y va a trabajar.
☐ 3.5. Cada miembro del equipo expone los impedimentos que ha tenido para desarrollar sus tareas con el resto del equipo.
☐ 3.6. Cada miembro del equipo, en caso de estar implementando una tarea, ha validado antes el diseño de la misma con otro miembro del equipo.
☐ 3.7. Cada miembro del equipo, en caso de haber terminado una tarea, le ha demostrado que funciona conforme al DONE de la tarea a otro miembro del equipo.
☐ 3.8. Cada miembro del equipo firma la tarea con la que está para hacerla suya.
☐ 3.9. Cada miembro del equipo sabe lo que los demás están haciendo.
☐ 3.10. El Propietario del Producto participa de la reunión al menos un par de días por semana.
☐ 3.11. Existe un gráfico de burndown que se actualiza diariamente.
4. DEMO
Se realiza al finalizar el sprint para demostrar que se han implementado todas las historias del sprint.
☐ 4.1. El responsable de la demostración prepara una presentación o una guía en la que se documenta qué historias se van a probar y qué pruebas se van a realizar de cada una de ellas.
☐ 4.2. Se realiza en un entorno controlado por el cliente o accesible al mismo y no en un equipo local de desarrollo.
☐ 4.3. Se realiza una demostración al Propietario del Producto de todas las historias aceptadas conforme a su DONE en el sprint.
☐ 4.4. Recibimos retroalimentación del Propietario del Producto sobre el resultado de las implementaciones.
5. RETROSPECTIVA
Se realiza al finalizar el sprint después de la demostración al cliente.
☐ 5.1. Ocurre al final de cada sprint.
☐ 5.2. El Scrum Master documenta el gráfico de burndown y actualiza qué velocidad media tiene el equipo. Adicionalmente documenta qué historias han formado parte del presente sprint y qué impedimentos han surgido en la consecución del mismo.
☐ 5.3. Se utilizan técnicas de retrospectiva para fomentar la participación de todos los miembros del equipo.
☐ 5.4. El resultado de la retrospectiva son propuestas concretas de mejora del proceso y la metodología.
☐ 5.5. El resultado de la retrospectiva se documenta en la herramienta de gestión del proyecto.
☐ 5.6. Se inspeccionan las propuestas de retrospectivas anteriores para ver las que han implementado realmente.
☐ 5.7. Participa todo el equipo incluido el Propietario del Producto.
Quiero agradecer a Nicolás Escobar el que comparta su Checklist de Scrum con quién tenga interés, gracias :-D
No hay comentarios:
Publicar un comentario