Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.
Comentarios: v01r02


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

Área de Gobernanza y Calidad

Contenido

Tabla de contenidos
maxLevel5
indent20px
exclude(Subdirección de las Tecnologías de la Información y Comunicaciones|Área de Gobernanza y Calidad)


Resumen
Sugerencia
  • Versión: v01r01 v01r02
  • Fecha publicación: 29 30 de Octubre Julio de 20202021
  • Entrada en vigor desde: 29 30 de Octubre Julio de 20202021


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.

Expandir
titleHistórico de cambios


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 

(*)   HU: Historia de Usuario.

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

(***) PPO: Proxy Product Owners.