Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Contenido


Resumen
  • Versión: v01r02
  • Fecha publicación: 30 de Julio de 2021
  • Entrada en vigor desde: 30 de Julio de 2021


Histórico de cambios

Los cambios en los estándares vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.


Versiónv01r01Fecha publicación29 de Octubre de 2020Fecha entrada en vigor29 de Octubre de 2020
Alcance
  • Descripción del DoR utilizado de manera estándar en la STIC
Versiónv01r02Fecha publicación30 de Julio de 2021Fecha entrada en vigor30 de Julio de 2021
Alcance
  • Se incluye enumeración de los criterios.
  • En el criterio 9 se sustituyen enlaces externos por las imágenes que capturan la esencia del mensaje a transmitir por los anteriores



Introducción:

  • El DoR (Definition of Ready) es un compendio de criterios que definen el estado mínimo de refinamiento de una historia de usuario para que pueda ser planificada para un sprint.
  • Este documento tiene como propósito establecer un contenido estándar del DoR, que permita alinear las expectativas de las diferentes partes involucradas en proyectos ágiles antes de planificar Historias de Usuario en un sprint.
  • Esta propuesta debe entenderse como un punto de partida, que irá evolucionando y enriqueciéndose progresivamente.




Definition of Ready (DoR)



CRITERIO

OBJETIVO

NOTAS

1

Dependencias

HU* sin dependencias no resueltas (API, prototipos, otras HUs...).
2

Narrativa HUs

HU con narrativa con formato Como <> quiero/necesito <> para <> y al menos, un CA**.


3

Alineamiento contenido

HU clara para todo el equipo.


4

HUs estimadas

HU estimada en puntos de historia.
5

HU testeable

HU testeable, que cubra todos sus CA.


6

Tamaño HU

HU de tamaño adecuado para que entre en un Sprint.
7

Prototipo HU

HU prototipo enlazado con HU desarrollo.

  • Los prototipos estarán previamente validados por el PO.
8

Criterios de aceptación

La Historia de Usuario debe tener los CA aceptados tanto por el PO, como el equipo.

  • Los criterios de aceptación irán en formato Dado <> cuando <> entonces  siempre que sea posible, priorizando la  claridad al formato.
9

Identificación pruebas automáticas

Criterios de aceptación cuyas pruebas se van a automatizar identificados mediante acuerdo OCA / PO / PPO***/ equipo.
  • Los criterios de selección de pruebas automáticas tendrán como objetivo último maximizar el ROI de dichos tests a través de la adopción de una estrategia de mitigación de riesgo (ver ejemplo aquí) y teniendo en consideración los esfuerzos asociados a la mantenibilidad, desarrollo, relevancia para el usuario final y tiempo de ejecución (ver ejemplo aquí).

(*)   HU: Historia de Usuario.

(**) CA: Criterio de aceptación.

(***) PPO: Proxy Product Owners.