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

Área de Gobernanza y Calidad

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.

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 flexibilizarsepero 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:

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í).