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
  • Documento en el que se detallan las características, definición y diferencias entre la demanda planificada y la no planificada, incluyendo una descripción del impacto en el flujo de actividades para tratar ambas.




Introducción

Por simplicidad, de cara al flujo de trabajo y ceremonias, en los proyectos ágiles se hará distinción entre:

  • Demanda Planificada: aquellas HUs que pueden planificarse en la Sprint Planning.
  • Demanda No Planificable: aquella con carácter urgente que hay que desarrollar en un Sprint sin que fuese planificada previamente.

Puesto que la Demanda No Planificable puede tener un considerable impacto negativo sobre el ritmo de trabajo y actividades de un Sprint, sólo se considerará una Historia de Usuario (HU) como Demanda No Planificable cuando se cumplan las condiciones recogidas en la definición de la misma. Es en este sentido cuando es relevante atender a la clasificación de Demanda Planificada VS Demanda No Planificable.

La demanda No Planificable, como tal, no podrá planificarse durante la Sprint Planning. No obstante, durante la Sprint Planning se guardará una reserva de la capacidad para la gestión de Demanda Urgente que pudiera ser solicitada en el transcurso del Sprint, de acuerdo al mejor conocimiento disponible.

Para la Demanda No Planificable, el DoR podría flexibilizarse pero siempre manteniendo una definición clara y precisa del alcance y criterios de aceptación de las historias de usuario relacionadas, así como de sus estimaciones. El DoD se cumplirá de acuerdo al estándar (a pesar de que el equipo de calidad de la STIC no lo verifique antes de la subida a producción).


Clasificación de Desarrollo Planificable Vs. No Planificable

Es necesario un criterio predefinido entre desarrollos planificados y no planificables, con el que ser consistente para evitar caer en la gestión urgente de la demanda de manera sistemática. Con este propósito se precisan las siguientes distinciones:



Desarrollo PlanificableDesarrollo NO Planificable
Definición
  • Toda demanda que, teniendo impacto sobre la capacidad del equipo de desarrollo, se pueda planificar durante una Sprint Planning. Es decir, toda demanda que no sea No Planificable.
  • Todo aquel desarrollo que cumpla lo siguiente:
    1. Tenga impacto sobre la capacidad del equipo de desarrollo.
    2. Tras evaluación y consenso entre los interesados del proyecto se determine que tiene carácter. urgente(tiempo de respuesta < 3 semanas) y por tanto no es posible esperar a la siguiente Sprint Planning para planificar y desarrollar el contenido.
    3. No pueda ser planificado durante una Sprint Planning por falta de certidumbre en el contenido relacionado y/o en la estimación del esfuerzo asociado.


Ejemplos
  • Historias de Usuario refinadas o al menos estimables. Incluyendo aquellas que con carácter "No Planificable" previo, han sido transmitidas de un Sprint a otro.
  • Spikes no urgentes (o Historia de Usuario limitada en tiempo/esfuerzo y orientada a investigar mejor un problema o posibles soluciones con el propósito de despejar la incertidumbre de otra Historia de Usuario).
  • Incidencias de impacto menor (algunas P3) que requieren intervención por parte del equipo de desarrollo y pueden esperar al siguiente Sprint Planning para ser planificadas y desarrolladas.
  • Incidencias de alto impacto (P1 y P2) que requieren intervención por parte del equipo de desarrollo.
  • Evolutivo urgente requerido tras subida a producción.
  • Evolutivo urgente requerido por decreto urgente.
  • Peticiones funcionales asociadas a situaciones críticas y de alta urgencia (p.ej. peticiones excepcionales por crisis sanitarias).
Otras características generales
  • Requisitos claros y definidos antes de Sprint Planning → cumplimiento DoR (o podría cumplirse).
  • Versiones planificadas y lanzadas mediante PL normal.
  • Gestión del código tras subida a GIT mediante ramas Develop.
  • Requisitos difusos / desconocidos antes de una Sprint Planning → incumplimiento DoR (ni podría cumplirse).
  • Subida a producción, por lo general, mediante versiones urgentes y PLUs.
  • Gestión del código tras subida a GIT generalmente mediante ramas Hotfix debido a su urgencia.





Planificación de recursos para desarrollo planificado y desarrollos no planificables

Durante el Sprint Planning se ajustará una reserva de la capacidad del equipo para gestión de la demanda no planificable, y la planificación del contenido del sprint se hará con la capacidad restante.





Flujo de actividades para gestión de la Demanda Planificada y No Planificable en proyectos ágiles


Demanda Planificada

Para el desarrollo de Demanda Planificada se seguirá el flujo de actividades común de SCRUM, esto es:

  1. Asegurar el registro en JIRA (en el backlog del producto) de la Mejora / Incidencia.
  2. Refinamiento y estimación durante Sprint Refinement.
  3. Cumplimiento con DoR estándar del Proyecto.
  4. Planificación durante Sprint Planning.
  5. Desarrollo hasta cumplimiento con el DoD.
  6. Revisión en Sprint Review.


Demanda No Planificable

Puesto que el flujo de actividades anterior proporciona un marco de trabajo estable, una vez más, se hace especial énfasis en la necesidad de evaluar si realmente cualquier demanda urgente puede ser programada para el siguiente Sprint para así evitar romper con el anterior flujo de actividades. No obstante, siempre que sea imposible postergar el comienzo del desarrollo de cualquier Mejora urgente/Incidencia hasta el comienzo del siguiente sprint, se tratará como Demanda No Planificable y se seguirá la siguiente secuencia de actividades:


Demanda no planificable - Nuevas funcionalidades urgentes

  1. Asegurar el registro en JIRA (en el backlog del producto) de la Mejora.
  2. Cumplimiento de la Demanda con las características de "Demanda No Planificable".
  3. Etiquetado de la Mejora como "FUNCIONALIDAD_URGENTE".
  4. Creación de HUs para la Mejora / Incidencia y etiquetado como "FUNCIONALIDAD_URGENTE".
  5. Creación y asignación de versión antes de desarrollo.
  6. Autoasignación de urgencias por el equipo.
  7. Refinamiento Ad-Hoc (si es necesario) entre solicitante y la parte del equipo asignada. Estimación en puntos de la urgencia por el equipo asignado.
  8. DoR: Para la demanda no planificable el DoR podría flexibilizarse, pero siempre manteniendo una definición clara y precisa del alcance y criterios de aceptación de las historias de usuario relacionadas, así como de sus estimaciones.
  9. Seguimiento tras sesión de refinamiento en el tablero Kanban correspondiente hasta la finalización del desarrollo.
  10. Decisión por parte del director de proyectos de lanzamiento de si es necesaria una PL (Petición de Lanzamiento) normal o urgente.
  11. DoD: El DoD se tendrá que cumplir según estándar del proyecto. No obstante, en aquellos casos en los que sea necesario subir a producción sin que se haya podido verificar el cumplimiento con el DoD, se revisará en la medida de lo posible dicho cumplimiento en la Sprint Review.
  12. Alineamiento desarrollo durante la Sprint Review y análisis del DoD para normalización del desarrollo.
  13. Generar HU que iguale ambos entornos (si aplica).


Demanda no planificable - Incidencias de producción con impacto en el equipo de desarrollo

  1. Asegurar el registro en JIRA (en el backlog del producto) de la Incidencia.
  2. Etiquetado de la Incidencia como "OPERACIÓN_URGENTE".
  3. Creación de HUs para la Incidencia y etiquetado como "OPERACIÓN_URGENTE".
  4. Refinamiento Ad-Hoc (si es necesario) entre solicitante y la parte del equipo asignada. Estimación en puntos de la urgencia por el equipo asignado.
  5. Seguimiento tras sesión de refinamiento en el tablero Kanban correspondiente hasta la finalización del desarrollo.
  6. Alineamiento de desarrollo durante la Sprint Review y análisis del DoD para normalización del desarrollo.
  7. Generar HU que iguale ambos entornos (si aplica).


Resumen gráfico

Nota 1: Cuando se lance una PL de carácter urgente (PLU), el Servicio de Verificación de Entrega (SVE) por parte de la OCA se gestionará de acuerdo a los estándares actuales de la STIC (click aquí).