¿Cómo se sabe si una tarea, una historia de usuario o un sprint están completos y tienen la calidad necesaria? Puedes tener toneladas de tareas que deben ser realizadas, sin embargo, ¿Cómo sabes si son liberables o no? ¿O si la historia del usuario está completa?.
Podrías preguntar a alguien cada vez, sin embargo, eso está lejos de la mentalidad de Scrum, necesitas ser independiente. ¿Cómo? Teniendo un buen definitions of Done.
¿Qué es la Definition of Done (dod)?
Requisito(s) necesario(s) para determinar que un elemento o incremento de la cartera de productos está completo. Se utiliza para evaluar cuándo se ha completado el trabajo.
Para aplicar la transparencia y facilitar la inspección, es necesario que los requisitos sean claros y correctos.
Los DoDs impulsan la calidad del trabajo y se crean para que todos los miembros del Equipo Scrum sepan cuándo se ha completado una Historia de Usuario.
Es importante tener una definición clara de definition of Done porque ayuda a eliminar la ambigüedad y permite al Equipo adherirse a los estándares de calidad requeridos.
Cada equipo/empresa/proyecto tiene su propia definición de hecho. Es un acuerdo compartido de lo que una tarea o historia necesita para considerarse completa
La definición de definition of Done puede incluir cualquier cosa de esta lista:
- Han sido revisadas por otros miembros del equipo.
- Se ha completado la prueba de unidad de la historia de usuario.
- Conclusión de las pruebas de control de calidad.
- Conclusión de toda la documentación relacionada con la historia de usuario.
- Todas las cuestiones corregidas.
- Demostración satisfactoria a las partes interesadas y/o a los representantes de la empresa.
1. ejemplos of DoD
Para entender qué es un ejemplo de lista de Definition of Done:
| De forma sencilla | Más detalles |
|
|
¿Por qué tu necesitas Definition of Done?
- El DoD proporciona una lista de comprobación que guía de forma útil las actividades previas a la implementación: discusión, estimación, diseño.
Tener un producto potencialmente entregable y utilizable al final de cada sprint. - Es crucial para el equipo Scrum de alto rendimiento porque se aseguran de que la tarea coincida con las características de funcionalidad y calidad.
- La definición de Hecho limita el coste de retrabajo.
- La transparencia, evita los malentendidos entre todos, y saben qué hacer para decidir que la historia está completa.
- Determinar un nivel de calidad común. Una vez acordados todos los criterios de terminación, todos los puntos de vista de cada miembro especialista, lo que permite salvar cualquier brecha.
- Calidad. Para asegurarse de que se tienen en cuenta los requisitos básicos y determinar el nivel de calidad que coincide con los valores del cliente.
¿Definición de “Done” Vs “criterios de aceptación”?
Resulta confuso ver la definición de Definition of Done y los criterios de aceptación, ¿verdad?.
La diferencia es sencilla:
Los criterios de aceptación son únicos para una historia de usuario individual.
Y recuerde que, la Definition of Done son un conjunto de reglas aplicables a todas las historias de usuario en un Sprint.
Recordatorio:
La historia de usuario cuenta una breve historia sobre alguien que utiliza el producto. Contiene un nombre, una breve narración, y los criterios de aceptación y las condiciones para que la historia esté completa.
Tipo de Scrum Definition of Done
No se trata de una clasificación oficial, pero es posible que el DoD esté presente en toda esta parte del proceso.
Definition of Done durante la planificación
Es necesario determinar la Definition of Done durante el Sprint Cero, la primera reunión de planificación, durante la reunión de planificación para que el Equipo de Desarrollo pueda estimar adecuadamente el esfuerzo necesario para alcanzar los objetivos del proyecto.
Definition of Done durante la Planificación del Sprint
Afecta a las tareas específicas que los miembros del equipo de desarrollo deben realizar en cada iteración creando una lista más detallada para cada fase. En este caso, los miembros pueden determinar también los esfuerzos necesarios para alcanzar el objetivo de cada Sprint.
Es a nivel de historia, a nivel de sprint y a nivel de producto
Tres niveles, el nivel básico relacionado con la historia de usuario, el nivel intermedio del Sprint, y el nivel superior relacionado con el lanzamiento del producto o el incremento.
Definition of Done para una historia de usuario
El nivel más básico de DoD es para la historia de usuario o característica (a veces la característica no necesita ningún otro requisito aparte de la propia característica).
No todas las historias de usuario deben ser completadas. Más bien, significa que la característica puede ser suficiente para satisfacer la necesidad. Una vez aceptada, la función realizada contribuirá a la velocidad de lanzamiento.
Aquí comprobaremos la comprensión del equipo con los supuestos de cada elemento del backlog que se describe. La característica es la capa estratégica y una historia de usuario es para la ejecución. Las historias de usuario son parte de su Sprint, por lo que para que cada historia sea liberable (funcional) como parte del Producto, debe cumplir con Definition of Done del Producto y con sus propios criterios especiales de acentuación.
Definition of Done para un Sprint
El Sprint debe crear un Incremento de Producto y esto significa que la Definition of Done debe cumplirse en cada Sprint para que el Producto sea liberable. Esto lo hacemos comprobando si hemos implementado todas las historias de usuario de tal manera. Además, confirmamos si se cumplen todas las condiciones antes del despliegue en producción.
Definition of Done para una Liberación
Principalmente porque el producto es liberado la DoD siempre está en el nivel de Producto. Esta es la etapa final y de alto nivel que incluye una comprobación tanto de la historia de usuario como del sprint.
Sin embargo, al ser un proceso ágil e iterativo, esta comprobación será específica para la liberación, ya que sólo si han pasado el sprint pueden llegar a esta etapa. El feedback retrospectivo del sprint se recoge para hacer una lista de comprobación detallada para una versión.
¿Quién actualiza Definition of Done y Cuándo?
Las Definitions of Done se pueden modificar y deben actualizarse según sea necesario; por lo general, durante la Retrospectiva del Sprint se analiza la Definition of Done si es necesario. Sin embargo, no se recomienda durante un Sprint. Es responsabilidad del Equipo Scrum estar al tanto, señalar si se requiere algún cambio y discutirlo.
¿Quién está al cargo del Definition of Done?
Definition of Done es típicamente determinada y documentada por el Órgano de Orientación de Scrum.
Los registros y datos necesarios para cumplir con los requisitos de documentación del proyecto pueden ser engendrar a medida que el Equipo avanza a través de sprints e incrementos.
El Cuerpo de Orientación de Scrum (SGB), puede consistir en un grupo de expertos o un conjunto de documentos sobre normas y procedimientos de la organización- define las directrices y los parámetros que se utilizarán para evaluar el valor del negocio.
Sin embargo, cada Product Owner es responsable de llevar a cabo las actividades de verificación y seguimiento del valor del negocio para sus respectivos proyectos, programas o carteras.
Y más allá de la planificación y en relación con las historias de usuario, el Product Onwer y el Equipo de Desarrollo trabajarán en un Definition of Done más madura/definida y/o en criterios de aceptación.
¿Cómo crear Definition of Done?
Cada proyecto es especial, porque las circunstancias pueden cambiar, el presupuesto, el equipo, la visión, debido a muchas razones. Así que revise los siguientes puntos para caminar en la dirección correcta:
- La naturaleza del producto que se desarrolla – Qué se desarrolla
- La tecnología utilizada – Cómo se desarrolla
- Organización de la construcción del producto – QUIEN lo desarrolla
- Obstáculos que afectan a las posibilidades – QUÉ desafíos se enfrentan
¿Cuál es la diferencia entre shippable y releasable?
Shippable es casi hecho, Definición de casi hecho (DoAD) . Shippable suele significar que necesita algunas aprobaciones finales, por lo que aún no puede ser lanzado al mercado. En palabras más directas, podría entenderse como, cuando estamos “Hecho” con el trabajo, mientras que la aprobación está pendiente, por ejemplo, de las Pruebas de Aceptación del Usuario (UAT) o Legal o como resultado de cualquier documentación pendiente.
Los errores más comunes de Definition of Done
- Centrarse demasiado en Definition of Done, puede ir en contra de la productividad. La lista tiene que contener el trabajo mínimo comúnmente requerido.
- Definition of Done que nadie conoce es inútil, elimine esa DdD o si es importante, encuentre por qué el Equipo no la conoce.
- Olvídese de los criterios de aceptación que requiere una historia de usuario singular.
- La DdD debe ser más bien un contrato para todo el equipo más que un entendimiento compartido.
- Cuando se empieza con Scrum, se definen unos requisitos iniciales para la DdD que se van refinando en los primeros sprints. Cada equipo y proyecto es diferente, sólo mantener un ojo, si el incremento de seguir fallando la razón podría ser la definición de hecho o criterios de aceptación.
- No te olvides de la DdD o de los criterios de aceptación. Una buena idea puede ser tenerlos siempre visibles desde el tablero Kanban, en una pared, o en la pantalla principal del programa, que recuerde rápidamente a todos.
¿Cómo mejorar Definition of Done con el equipo Scrum?
Haga ejercicios con su equipo.
Como practicantes de Scrum, tienes que hacerlo y cambiar y mejorar con la práctica. Por lo tanto, la parte de la teoría se entiende y se hace, ahora, es el momento de aplicar en la realidad con su equipo. Sí, este cómo debe ser el conjunto de la mente de un Scrum Master o ciudadano del mundo Scrum, con ejemplos y sesiones interactivas para hacer que usted domine todos los conceptos de scrum.
Cosas que se requieren para el ejercicio de DoD
Consigue tu Equipo Scrum, post-it, un bolígrafo y una sala de conferencias.
Pasos:
- Haz una lluvia de ideas para decidir los supuestos con el Equipo
- Clasificar las sesiones y discutir el DoD
- Clasificar el DoD en historia de usuario, sprint y release
- Haga la lista de comprobación y deje que todo el equipo se ponga de acuerdo.
- Esto le ayudará a usted y al equipo a entender la DdD y a preparar una lista de comprobación no fija por su cuenta.
El mayor maestro es el fracaso
Aprendemos de nuestros errores, simple y llanamente. Si practicas, te equivocas y fracasas, caminarás hacia el éxito!!.
Especialista en Scrum
