agile - terminado - Su definición de Scrum de Done
metodologia scrum fases (5)
Si bien Scrum es fácil en teoría y difícil en la práctica, quería escuchar tu definición de Done; es decir, cuáles son las puertas (prueba de unidad, cobertura de código> 80%, revisiones de código, pruebas de carga, prueba de rendimiento, pruebas funcionales, etc.) que debe realizar su producto antes de poder etiquetar el producto como "Hecho"
Hay tres buenos artículos de Mitch Lacey , Dhaval Panchal y Mayank Gupta sobre esto en el sitio web de ScrumAlliance.
EDITAR: Básicamente, el punto es que el equipo define los proyectos por proyecto . La necesidad básica es acordar la definición, no cuál es la definición.
Yo diría que depende de tu equipo decidir. Habla con el dueño del producto. Lo ideal sería hacerlo cuando una historia está en producción y se está utilizando. Sin embargo, hay un intervalo de tiempo entre el desarrollo de una historia y el Live. Hace que sea difícil hacer un seguimiento del desarrollo de una historia.
En mi equipo, nuestra definición de hecho es cuando el desarrollador completa una historia y hace un "show and tell" al resto del equipo (probadores, propietario del producto), y si todos están contentos, entra en el baúl de subversión.
Las pruebas adicionales se realizan desde una estructura automatizada desde el tronco.
En TargetProcess utilizamos la siguiente definición de Hecho para la historia del usuario:
- Short Spec creado
- Pruebas implementadas / unitarias creadas
- Pruebas de aceptación creadas
- 100% Pruebas de aceptación pasadas
- Demo del propietario del producto aprobada
- Errores conocidos corregidos
En un mundo perfecto, el producto estará en un estado enviable al final de cada iteración.
Ahora esto realmente depende de su producto, su mercado, sus clientes y podría no ser posible.
Si no puede lograr esto, entonces se aplica el siguiente horizonte de planificación: el lanzamiento. El equipo en su conjunto debe decidir qué se requiere para enviar el producto y planificar en consecuencia.
Lo que ayuda aquí es definir "hecho" en el nivel de la tarea. Definir aquí es mucho más simple: una tarea se realiza cuando puede iniciar otra: todo se prueba, se integra. El Equipo puede definir este estado: documentado, revisado, incluido en la construcción automática, sin problemas conocidos, aceptado por el Cliente en el Sitio ...
Tener todas sus tareas realmente "hechas", Tener todos los ítems de atrasos de viaje (o Historias de usuarios, como todos los llaman) realmente "hechos" permiten ser "hechos" en cada iteración, lo que ayuda a preservar el producto en un estado enviable o desplegable.
Todo lo que hará que su "período de estabilización" (es decir, el trabajo requerido entre la congelación del código y la versión para el cliente) sea más corto.