DoR y DoD

Empezar

Guía para su elaboración

Agile Producción Murcia - agile.produccion.murcia@everis.nttdata.com

DoR y DoD

Un buen DoR

Compromiso

Un buen DoD

Definición de Hecho (DoD)

Definición de Listo (DoR)

Artefactos SCRUM

Manual de elaboración de DoR y DoD.

Índice

- Product Backlog. - Sprint Backlog. - Incremento. - Definition of Ready (DoR). - Definition of Done (DoD). - Gráfico de Burndown.

Artefactos SCRUM

- El DoR (Definition of Ready) establece cuándo una Historia está lista para ser desarrollada, y por lo tanto, puede incluirse dentro de un Sprint Backlog. - Incluye las condiciones mínimas consensuadas por el Product Owner y el equipo de Desarrollo. - Cada equipo Agile tiene su DoR particular, adaptado a su producto y proceso.

Definición de Listo (DoR)

- El DoD es cuando la HU cumple con todos los requisitos para ser aceptada por el Product Owner y podrá formar parte de una entrega, para su subida o despliegue en producción. - Incluye condiciones para garantizar la calidad y reducir el retrabajo. - Cada equipo Agile tiene su DoD particular, adaptado a su producto y proceso.

Definición de Hecho (DoD)

- Asegurar el cumplimiento del DoR es responsabilidad del Cliente, a través del Product Owner (o Proxy Product Owner). - Asegurar el cumplimiento del DoD es responsabilidad del equipo de Desarrollo. - Asegurar que tanto el DoR como el DoD están actualizados, aportan valor, responden a las necesidades del producto/proceso y se cumplen, es responsabilidad de todo el equipo SCRUM.

Compromiso

- Para elaborar un buen DoR es necesario reunir, describir y articular los requisitos mínimos que el equipo de Desarrollo necesita para acometer una Historia o Tarea.- Si la organización dispone de un DoR previo conviene ampliarlo para adecuarse a las especificaciones concretas del producto y proceso, pero no modificarlo sustancialmente. - Se puede entender como la entrada que recibe el equipo de Desarrollo.

Un buen DoR

- La Historia o Tarea no debe tener bloqueos que impidan su ejecución. - Las dependencias con aplicaciones de terceros están identificadas y no hay dependencias bloqueantes. - Debe estar aprobada por el Product Owner. - Está estimada. - Cumple con los indicadores del modelo INVEST (Independiente, Negociable, Valorable, Estimable, Pequeña y Testeable). - Está escrita utilizando escenarios. - Está escrita usando Gherkin (GIVEN, WHEN, THEN). - Está priorizada utilizando el enfoque MoSCoW (Must, Should, Could, Would). - El objetivo satisface las características SMART (Específico, Medible, Orientado a la acción, Realista, Limitado en el tiempo).

Ejemplos de ítems del DoR

- Para elaborar un buen DoD es necesario reunir, describir y articular los requisitos mínimos que el Cliente exige para considerar un incremento como valioso.- Si la organización dispone de un DoD previo conviene ampliarlo para adecuarse a las especificaciones concretas del producto y proceso, pero no modificarlo sustancialmente. - Se puede entender como la salida que entrega el equipo de Desarrollo.

Un buen DoD

- Se ha comprobado que la documentación asociada es correcta. - Se obtiene el OK del Product Owner y los stakeholders en el Sprint Review. - El código está almacenado en un sistema control de versiones (GIT ó SVN). - Se han realizado las pruebas unitarias correspondientes. - Se han realizado los tests correspondientes (Jasmine ó JUnit). - Se ha realizado la codificación respetando todas las restricciones de SonarLint. - Se ha realizado un aseguramiento de la calidad (QA) de forma satisfactoria. - Se han realizado pruebas cruzadas en el entorno de Desarrollo. - Se han realizado pruebas integradas en el entorno de Integración. - Se ha documentado el funcionamiento en Enterprise Architect. - Se ha documentado el código en Enterprise Architect. - Se han documentado las pruebas realizadas en HP-ALM. - Todas las incidencias asociadas a están resueltas.

Ejemplos de ítems del DoD