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
  • Presentación de una clasificación de los distintos tipos de error que suelen ocurrir durante la fase de desarrollo (previo a la subida a producción) así cómo de las pautas para gestionar el retrabajo asociado a dichos errores

Introducción

Este documento pretende sintetizar la casuística que pueda resultar en un retrabajo durante el desarrollo de proyectos ágiles, así como establecer unas pautas operativas de cara a gestionar dicho retrabajo.




Casuística de retrabajos durante el desarrollo y su gestión

Las respuestas aquí planteadas antes las diferentes casuísticas que generan un retrabajo en un equipo de desarrollo intentan responder a la siguiente visión:

  • La alineación de requisitos es una responsabilidad compartida entre la STIC y el proveedor.
  • El Product Owner y/o el Proxy Product Owner participan proactivamente de la definición de QUÉ impacto quiere conseguirse con cada HU.
  • El equipo de desarrollo participa proactivamente del entendimiento de QUÉ quiere conseguirse con cada HU.
  • El equipo de desarrollo participa proactivamente de la definición de CÓMO va a lograrse el impacto buscado (teniendo en cuenta las pautas de la STIC).

A continuación veremos un resumen de esta casuística, cómo se gestiona cada caso en términos operativos y en quién recae la responsabilidad principal de dicho retrabajo:


RESUMEN CASUÍSTICAGESTIÓN OPERATIVA*RESPONSABLE DEL RETRABAJO

Problemas en la definición o alineamiento de la historia de usuario

En la Sprint Review (o antes de la misma) se entrega HU que aunque cubre todos los criterios de aceptación definidos en la historia así como los casos de uso definidos, se detecta que hay criterios de aceptación pendientes de definición que amplían el alcance funcional de la HU y, por tanto, están pendientes de desarrollo.
  • Se acepta HU.
  • Se registra nueva HU para cubrir el nuevo criterio de aceptación.

STIC

En la Sprint Review (o antes de la misma) se entrega HU en la que NO se consigue proporcionar el valor principal esperado según el criterio del Proxy Product Owner / Product Owner debido a una definición deficiente de la historia de usuario o a un malentendido entre el equipo y Product Owner.
  • Se acepta HU.
  • Se planifica próximos sprints nueva HU para realinear expectativas y desarrollo.

Responsabilidad compartida entre la STIC y el proveedor.

Criterios de aceptación definidos y no cubiertos en el desarrollo

En la Sprint Review (o antes de la misma) se entrega HU en la que SÍ se consigue proporcionar el valor principal esperado a criterio del Proxy Product Owner / Product Owner a pesar de que hay criterios de aceptación menores que no se cumplan aún estando definidos en la historia de usuario.
  • Tras valoración conjunta de los riesgos e implicaciones de este hecho entre los interesados relevantes del proyecto, se podrán contemplar varios escenarios:

    1. Riesgos/relevancia bajos del CA incompleto: Se acepta HU y se registra una No Conformidad con el esfuerzo asociado a la corrección correspondiente del Bug. Este Bug computa como deuda técnica. Se planifica en próximos sprints el desarrollo de una HU que solucione dicha No Conformidad.

    2. Riesgos/relevancia considerable del CA incompleto: No se acepta HU. Se replanifica para siguientes sprints.
    3. Si el Product Owner considera que el CA incompleto es irrelevante, se actualiza la HU eliminando dicho CA

Proveedor

En la Sprint Review (o antes de la misma) se entrega HU en la que NO se consigue proporcionar el valor principal esperado según el criterio del Proxy Product Owner / Product Owner debido a criterios de aceptación no desarrollados aún estando definidos en la historia de usuario.
  • No se acepta HU.
  • Se replanifica para siguientes sprints.

Proveedor

Faltan casos de uso por cubrir

En la Sprint Review (o antes de la misma) se entrega HU que aunque cubre todos los criterios de aceptación definidos en la historia, se detecta que hay casos de uso no contemplados, impidiendo ello el correcto funcionamiento del aplicativo o la obtención del valor esperado de la HU.
  • No se acepta HU.
  • Se amplía el alcance de la HU y se reestima (si fuese necesario).
  • Se replanifica para siguientes sprints.

Proveedor

En la Sprint Review (o antes de la misma) se entrega HU que aunque cubre todos los criterios de aceptación definidos en la historia, se detecta que hay casos de uso no contemplados que NO amplían el alcance funcional de la HU, sin que ello impida el correcto funcionamiento del aplicativo u obtener el valor esperado de la HU.
  • Se acepta HU.
  • Se planifica en próximos sprints una nueva HU que contemple el esfuerzo asociado a la cobertura de los casos de uso detectados.

Responsabilidad compartida entre la STIC y el proveedor.

En la Sprint Review (o antes de la misma) se entrega HU que aunque cubre todos los criterios de aceptación definidos en la historia, se detecta que hay casos de uso no contemplados que amplían el alcance funcional de la HU, sin que ello impida el correcto funcionamiento del aplicativo u obtener el valor esperado de la HU.
  • Se acepta HU.
  • Se planifica en próximos sprints una nueva HU que contemple el esfuerzo asociado a la cobertura de los casos de uso detectados.

STIC

DoD no cubierto

En la Sprint Review (o antes de la misma) se entrega una HU funcionalmente completa (CAs y casos de uso cubiertos), pero hay pendientes tareas asociadas al cumplimiento del DoD (p.ej. pendiente de subida a GIT, compilación Jenkins exitosa o umbrales mínimos de Sonar).
  • No se acepta HU.

Proveedor

Errores desarrollo

En la Sprint Review (o antes de la misma) se entrega HU funcionalmente completa (CAs y casos de uso cubiertos), aunque presenta errores asociados menores y de bajo impacto (p.ej. errores tipográficos).
  • Se acepta HU y se registra una No Conformidad con el esfuerzo asociado a la corrección correspondiente del Bug. Este Bug computa como deuda técnica.
  • Se planifica en próximos sprints el desarrollo de una HU que solucione dicha No Conformidad.

Proveedor

*Nota: el término responsable en este contexto hace referencia a la persona/grupo obligado a responder de algo. Siguiendo la nomenclatura de matrices de responsabilidad RASCI, el término responsable aquí empleado hace referencia al rol "Accountable", mientras que el rol "Responsible" siempre se debe entender asociado al proveedor.

  • Sin etiquetas