Con Scrum, los productos se construyen en una serie de iteraciones de longitud fija (sprints). Esto permite a los equipos entregar software a intervalos regulares, recibir retroalimentación rápida y adaptarse rápidamente a los requisitos cambiantes.
Aquí se presenta una lista de las mejores prácticas de Scrum que han demostrado su efectividad para ayudar a mejorar la calidad y aumentar la productividad, para entregar un producto que aporte valor y que cumpla con los objetivos de negocio.
Equipo
- Los miembros del equipo trabajan en roles multifuncionales
- El equipo tiene el equilibrio adecuado entre los desarrolladores y el QA (2: 1 o 4: 1)
- Los miembros del equipo colaboran para entregar en primer lugar historias de alta prioridad
- Los miembros del equipo piden ayuda proactivamente
- Los miembros del equipo se dan feedback constructivo mutuamente y de manera oportuna
- El SM facilita la autoorganización del equipo
- El SM se enfoca en remover impedimentos (problemas de recursos, problemas o desobediencia en la implementación de prácticas de Scrum)
- El SM protege al equipo de distracciones externas e internas
- El SM permite una estrecha cooperación en todos los roles
- El SM interactúa con la alta dirección
- El PP interactúa con el equipo y todas las partes interesadas (Stakeholders) para crear el backlog o la pila de producto
- El PP escribe historias de usuario y criterios de aceptación
- El PP prioriza la pila de producto y decide sobre las fechas de lanzamiento de las diferentes versiones
- El PP acepta o rechaza historias de usuario
- El PP cancela el sprint si piensa que el objetivo del sprint ya no tiene sentido
- Cada historia de usuario cumple los criterios del DoD
- Todos los miembros del equipo y el PP conocen de memoria el DoD y lo respetan
- El PP obtiene estimaciones a partir del equipo
- Sólo estima el equipo
- Cada miembro del equipo participa en la estimación
- El equipo estima usando la técnica del planning poker
- Todos los miembros del equipo participan
- El PP presenta las historias de usuario priorizadas al equipo
- Todas las historias del sprint están estimadas
- La reunión da como resultado un plan de sprint
- El equipo entrega algo después de cada sprint
- El equipo sigue las prioridades marcadas por el PP
- El equipo alerta al PP cuando tienen problemas
- El equipo trata los problemas cuando ocurren (no más tarde)
- La longitud de sprint no cambia después de cada sprint
- Las historias que se han empezado terminan dentro del mismo sprint
- La PS está visible y es de fácil acceso para el equipo
- La PS se actualiza todos los días
- Las estimaciones de las tareas se actualizan todos los días
- Los miembros del equipo actualizan la PS por ellos mismos
- Las historias están claramente mapeadas
- El SD tiene ocurre a la misma hora y lugar todos los días
- El SD comienza y termina puntualmente
- Todos los miembros del equipo están involucrados
- El PP participa en la reunión por lo menos unas pocas veces por semana
- El equipo revisa el gráfico de burndown y toma medidas si van retrasados
- El SD dura como mucho 15 minutos – todas las discusiones tienen lugar después
- La demo formal se realiza después de cada sprint
- Sólo las historias aceptadas por PP se demuestran
- Todos los interesados se han invitado para la demo con antelación
- Se anima a las partes interesadas a dar su opinión durante la demo
- La retrospectiva tiene lugar después de cada sprint
- Todos los miembros del equipo y el PP comparten el feedback
- El equipo analiza los datos y decide que acciones emprender
- Las acciones se priorizan e implementan en los próximos sprints
Mis agradecimientos a Gertrudis López por la traducción conjunta, link al post en su blog "Agile: lo bueno, lo feo y lo malo"
No hay comentarios:
Publicar un comentario