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 DoD estándar en la STIC, incluyendo notas relativas a la afección que la gestión de demandas urgentes tendría sobre el mismo
Versiónv01r02Fecha publicación30 de Julio de 2021Fecha entrada en vigor30 de Julio de 2021
Alcance
  • Actualización de la numeración: se excluye la cabecera de la tabla de la numeración
  • En el criterio #1, por mantener la consistencia entre DoR y DoD, se añade la nota adicional del DoR
  • En el criterio #3, se actualizan los enlaces de la normativa Gitflow, sustituyéndose el enlace de la normativa de Unifica por el de la misma en Confluence
  • En el criterio #10 del DoD se elimina la mención a la normativa de Unifica, dejándose sólo la mención a la normativa en Confluence. Se incluye un enlace a un resumen de la normativa de Confluence.
  • En el criterio #12, se actualiza el enlace de la normativa verificación de la calidad del código, sustituyéndose el enlace de Unifica por el de Confluence
  • En el criterio #14, en aras a una mejor navegabilidad por la documentación, se incluye enlace a los estándares de entrega de planes de prueba mediante archivos .feature
  • En el criterio #15, en aras a una mejor navegabilidad por la documentación, se incluye enlace a los estándares de automatización de pruebas funcionales. Además, se incluye referencia específica al criterio del DoR relativo a la selección de pruebas automáticas
  • Se sustituye el concepto de "Equipo de desarrollo" por "desarrolladores" de acuerdo a la guía SCRUM del 20 de Noviembre de 2020
  • Se elimina de la sección "Definition of Done (DoD)" la frase ya presente en el último punto de la Introducción, referente al carácter necesario y obligatorio del DoD



Introducción

  • El DoD (Definition of Done) es un compendio de criterios que definen la completa finalización de una historia de usuario.
  • Este documento tiene como propósito establecer un contenido estándar del DoD, que permita alinear las expectativas de las diferentes partes involucradas en proyectos ágiles de cara a evaluar la finalización de una historia de usuario.
  • Esta propuesta pretende cubrir tanto proyectos de nuevo desarrollo como proyectos de largo recorrido (legacy) en los que se ha optado por pasar a adoptar metodologías ágiles.
  • Esta propuesta debe entenderse como un punto de partida, que irá evolucionando y enriqueciéndose progresivamente.

  • Aún no hay normativa publicada en la STIC que module las entregas en proyectos ágiles. No obstante, hasta que no haya una directriz corporativa clara en este sentido todos los puntos del DoD estándar tienen, en principio, carácter necesario y obligatorio para cualquier proyecto ágil.

 

 

 

 

Definition of Done (DoD)

Si en algún proyecto ágil se hiciera necesario acometer alguna modificación o adaptación a algún punto de este DoD, estos cambios deberán alinearse entre los interesados del proyecto (OCA, SMO, Jefatura de Proyectos...).

 


CRITERIO

APLICABLE A

OBJETIVOS

NOTAS

Punto de Partida (Sprint 1)

Medio Plazo

1

Narrativa CA

Todos los proyectosHU con criterios de aceptación en formato estructurado con formato Dado <> cuando <> entonces <>.Sin cambios
  • Los criterios de aceptación irán en formato Dado <> cuando <> entonces  siempre que sea posible, priorizando la  claridad al formato.
2

Cumplimiento CA*

Todos los proyectosCumplimiento de todos los CA.Sin cambios
  • Con revisión automática o manual.
  • Gestión de demanda urgente no planificable: Todos los CA se deberán cumplir y verificar. Sin embargo en caso de que no pueda realizarse una verificacion por Product Owners y/o Oficina de Calidad (incidencias P1, P2), se deja dicha revisión a manos de los desarrolladores.
3

GIT y Gitflow

Todos los proyectosSubida de código al repositorio GIT de la STIC cumpliendo la normativa Gitflow, y también a las particularidades de gestión del código para proyectos ágiles.

Sin cambios.

  • Gestión de demanda urgente no planificable: Es necesario cumplir con normativa GIT/Gitflow salvo indisponibilidad de las herramientas relacionadas, en este caso se buscarán otros medios alternativos para la transferencia del paquete software a los administradores de sistemas y se regularizará en los repositorios tan pronto como sea posible.
4

Compilación Jenkins

Todos los proyectosCompilación Jenkins satisfactoria.

Sin cambios.

  • Gestión de demanda urgente no planificable: Mismo criterio mencionado en el punto anterior.
5

Despliegue de incrementos

Todos los proyectos

Despliegue del incremento correcto en el entorno de validación acordado.

En principio, el entorno de validación será el de desarrollo del proveedor.

Sin cambios.

  • Gestión de demanda urgente no planificable: En caso de caso de que no pueda seguirse la secuencia ordinaria de promoción entre entornos (VAL / PRE / PIL / PRO), se podrá alterar esta secuencia y se regularizará tan pronto como sea posible.
  • En caso de disponer de un sólo entorno compartido para desarrollo y validación del contenido del sprint del que harán uso tanto los desarrolladores como la OCA y PO, será necesario acordar una ventana temporal de validación del sprint finalizado con propósito de no bloquear dicho entorno para nuevos desarrollos (p.ej. durante la primera semana del sprint 2, se dispondrá a la OCA del entorno de validación para validar el contenido del sprint 1).
6

Trazabilidad backlog y tests

Todos los proyectosTrazabilidad completa: Épica - HU** - tests (cuando aplique) - prototipos.

Sin cambios.

  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
7

Prototipos

Todos los proyectosPrototipos versionados publicados en Confluence.

Sin cambios.

  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
  • La actualización de prototipos se realizará cuando se consensúe seguir trabajando sobre el prototipo. Sin embargo, una vez aprobado el prototipo, no se tendrá por qué hacer una revisión del mismo si no se considera necesario.
8

HU Actualizadas

Todos los proyectosSi durante el desarrollo se realizan adaptaciones en la implementación sobre la narrativa de la HU o de los CA se deberá dejar actualizado al final del Sprint acorde a la implementación.Sin cambios.
  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
9

Doc. Técnica de HU

Todos los proyectosEn la HU que aplique, documentación técnica actualizada en Confluence y enlace desde la HU correspondiente en JIRA.Sin cambios.
  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
  • Spike, PoC (Prueba de Concepto), etc...
10

Normativa

Todos los proyectosCumplimiento del resto del catálogo normativo del SAS publicado en Confluence (enlace aquí)Sin cambios.
11

Requisitos no funcionales

Todos los proyectosCumplimiento de los Requisitos No Funcionales definidos por las Oficinas Técnicas del SAS para el proyecto.Sin cambios.
12

Umbrales Mínimos de Calidad de Código Fuente

Proyectos Nuevo DesarrolloUmbral Mínimo para Cobertura >=65%, así como una clasificación A en mantenibilidad, confiabilidad y seguridad.Sin cambios.
Proyectos LegacyAl menos cumplimiento con Normativa de Verificación de Calidad de Código Fuente (enlace aquí).

Cumplimiento con un Umbral Mínimo de Cobertura >=65%, así como una clasificación A en mantenibilidad, confiabilidad y seguridad.

  • Durante el SPRINT 0, el objetivo de partida para los Umbrales Mínimos se consensuará entre Jefes de proyecto, equipo del proyecto y la OCA en función del contexto del proyecto, pero siempre cumpliendo al menos con la Normativa de Verificación de Calidad de Código Fuente (enlace aquí) y se establecerá un roadmap para alcanzar objetivos a medio plazo.
13

Manual de Usuario

Proyectos Nuevo DesarrolloSe actualizará en Confluence un Manual de Usuario, en el caso de que aplique en la HU.Sin cambios.
  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
Proyectos LegacyA revisar en cada proyecto. A revisar en cada proyecto.
  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
  • En caso de no disponer de un Manual de Usuario para el producto antes del lanzamiento ágil, este punto se ha de consensuar de manera específica para cada proyecto.
14

Plan de pruebas

Todos los proyectosPlan de pruebas completo para todas las HU funcionales del sprint de acuerdo a los estándares definidos en la STIC (enlace aquí)Sin cambios.
  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
  • Todos los planes de prueba estarán documentados. Los casos de prueba automatizados se documentarán en archivos .feature.
  • Mientras no exista una directriz corporativa base, el grado de cobertura de los archivos .feature será el acordado en el marco del proyecto de forma inicial y se irá revisando de forma progresiva en un esfuerzo conjunto con la oficina de Calidad.
  • En caso de bloqueos debido a sobresfuerzos asociados a la generación de archivos .feature, se consensuará adoptar una alternativa mínima viable para la entrega del plan de pruebas.
15

Automatización de pruebas

Proyectos Nuevo DesarrolloPruebas automatizadas desarrolladas de acuerdo a la normativa de la STIC (enlace aquí) y superadas para todos aquellos CA que se decidieron automatizar al comienzo del sprint, así como entrega de los archivos .feature asociados.Sin cambios.
  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
  • Ver recomendaciones para la selección de pruebas automáticas incluidas en el criterio #9 del DoR.
  • En caso de bloqueo por sobre-esfuerzos, la prioridad del desarrollo de las pruebas automáticas se revisará en función del contexto del proyecto.
Proyectos LegacyCumplimiento de los objetivos de automatización de pruebas planificados para el sprint.Pruebas automatizadas desarrolladas de acuerdo a la normativa de la STIC (enlace aquí) y superadas para todos aquellos CA que se definieron para el sprint, así como entrega de los archivos .feature asociados.
  • Gestión de demanda urgente no planificable: en caso de no ser posible seguir un flujo ordinario debido al grado de urgencia, se regularizará a posteriori.
  • Notas anteriores igualmente aplicables.
  • En proyectos con Legacy Code, se entiende que la estrategia de Automatización deberá ser estudiada con detenimiento. Por ello, durante el SPRINT 0 se consensuará entre las partes relevantes del proyecto un borrador de roadmap para desarrollar una estrategia de automatización (***) que muestre el compromiso del equipo por la adopción de pruebas automáticas, siempre teniendo en cuenta el contexto del proyecto.

(*) CA: criterio de aceptación.

(**) HU: historia de usuario.

(***) EJEMPLO de Roadmap para Desarrollar una Estrategia de Automatizacion:

Corto Plazo: Elaboración estrategia y primer contacto con la automatización de pruebas automáticas.

      1. En los 3 primeros meses se organizarán los talleres de trabajo necesarios para trazar una estrategia de implementación de pruebas automáticas orientada a generar una estructura base de pruebas automáticas. Esto podría traducirse en un backlog de HU relacionadas con la automatización de pruebas (spikes + desarrollos) que se irán implementando en los subsecuentes sprints.

Medio Plazo: Cierre de estrategia de automatización, compromiso con fecha límite de preparación de estructura base de pruebas automáticas y ejecución de la estrategia.

      1. A partir del fin del tercer sprint se reservará un 15% (aprox) de la capacidad de cada sprint para la implementación del Backlog de HU de Automatización de Pruebas (p.ej. lanzamiento spikes).
      2. Como punto de partida, se darán 6 meses (9º sprints) como fecha límite objetivo para desarrollar una estructura base de pruebas automáticas. Esta fecha podrá ser revisada durante el período de elaboración de la estrategia de automatización, es decir durante los primeros 3 meses, siempre y cuando este cambio esté debidamente justificado.