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

Área de Gobernanza y Calidad

Contenido


Resumen
  • Versión: v01r01
  • Fecha publicación: 29 de Octubre de 2020
  • Entrada en vigor desde: 29 de Octubre de 2020


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



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

Dependencias

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

Narrativa HUs

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


Alineamiento contenido

HU clara para todo el equipo.


HUs estimadas

HU estimada en puntos de historia.

HU testeable

HU testeable, que cubra todos sus CA.


Tamaño HU

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

Prototipo HU

HU prototipo enlazado con HU desarrollo.

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

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.

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 (ejemplo aquí) y teniendo en consideración los esfuerzos asociados a la mantenibilidad, desarrollo, relevancia para el usuario final y tiempo de ejecución (ejemplo aquí).

(*)   HU: Historia de Usuario.

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

(***) PPO: Proxy Product Owners.