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.
Introducción
Esta página pretende esclarecer los aspectos fundamentales de las sesiones de gestión de las necesidades del negocio (revisión del backlog de mejoras y de la Wishlist). Se ha de notar que esta es una sesión adaptada específicamente a los proyectos ágiles en producción de la STIC y, por tanto, no es una sesión estándar de ningún marco de trabajo ágil común.
Objetivo
Con el objetivo de asegurar la evaluación continua de las mejoras/sugerencias propuestas por usuarios, durante las sesiones de gestión de las necesidades del negocio los Product Owners (junto con otros miembros que pudieran ser necesarios) realizan las siguientes actividades:
- Aprobación / rechazo de nuevas Mejoras (o Épicas) propuestas en la Wishlist del producto, para ser consideradas para su desarrollo por parte del equipo, pasando las mejoras al backlog del producto.
- Priorización del backlog de Mejoras: las Mejoras de la Wishlist que han sido aceptadas se recogerán en el Backlog de Mejoras y se priorizarán. El orden de prioridad será de arriba hacia abajo quedando, por tanto, las mejoras de mayor prioridad en la parte superior del backlog y las de menor prioridad en la parte inferior.
- Anotación y seguimiento de acciones pendientes: en aquellas Mejoras sobre las que el personal funcional (o Product Owners) no pueda decidir si aceptarlas, rechazarlas o cómo priorizarlas de manera informada, se identificará la relación de acciones que son necesarias para facilitar el proceso (p.ej. solicitando detalles adicionales a la persona que propone la Mejora, consultando otros organismos o equipos, etc). Por otra parte, también esta sesión constituye un momento ideal para revisar las acciones recogidas en sesiones anteriores.
En caso de que los objetivos y necesidades anteriores se consigan de formas alternativas no es obligatorio mantener esta sesión como parte del calendario las ceremonias y reuniones.
Contenido y Agenda típica
La sesión cubre el mantenimiento de dos áreas fundamentales del backlog de alto nivel:
- Revisión Wishlist: A través de MiCS (Mi Centro de Servicios), cualquier usuario de un aplicativo en producción es capaz de enviar sugerencias, mejoras e incidencias relacionadas con dicho aplicativo, registrándose automáticamente en una lista de deseos o Wishlist de JIRA. Con esta actividad se pretende que el personal funcional (o Product Owners) revisen aquellas Mejoras registradas en la Wishlist con el objetivo de que tomen una de las siguientes determinaciones:
- Rechazar la Mejora por incompatibilidad con estrategia de evolución.
- Rechazar la Mejora porque la funcionalidad ya se ha detectado con anterioridad.
- Escalar la Mejora porque no constituye Mejora (p.ej. por ser una incidencia o una petición del estilo a consultas).
- Escalar la Mejora porque el aplicativo no se ha identificado correctamente (p.ej. cuando en nuestra wishlist vemos una mejora correspondiente a otro proyecto).
- Escalar la Mejora por otros motivos: generalmente cuando se necesitan datos adicionales. Por ello es importante especificar en el "mensaje de rechazo" la información que se estima necesaria para tomar una decisión. NOTA: En caso de requerir información adicional, para aligerar el proceso, también se puede establecer contacto directamente con el solicitante de dicha mejora a través de los datos de contacto que registra JIRA.
- Aprobar Mejora: tras lo cual la mejora pasará a formar parte del Backlog de Mejoras.
- Priorización de Backlog de Mejoras: Teniendo en cuenta una serie de criterios (roadmap evolución para el aplicativo, importancia, urgencia, coste, ...), el personal funcional (Product Owners) priorizará las mejoras que han pasado de la lista de deseos hacia el Backlog de Mejoras, de manera que las de mayor prioridad queden en la parte superior del backlog y las de menor prioridad en la parte inferior. Durante el proceso de priorización pueden utilizarse técnicas de apoyo como método de priorización WSJF (Weighted Shortest Job First)
Esta es una sesión propuesta para satisfacer las necesidades de aplicativos en producción de la STIC y, por tanto, no es una sesión estándar de ningún marco de trabajo ágil común. Así mismo, tampoco es estrictamente necesario seguir esta estructura de sesión/reunión siempre y cuando se satisfagan las necesidades de mantenimiento de la lista de deseos del producto (o Wishlist) y del Backlog de Mejoras anteriormente mencionadas.
Responsabilidades
Responsabilidades SCRUM | Descripción |
---|---|
Product Owner |
|
Proxy Product Owner |
|
Scrum Master |
|
Desarrolladores |
|
Preparación de la sesión
- Preparación por parte del personal funcional (Product Owners) de una agenda con expectativas de la sesión y decisiones a tomar durante la sesión.
- Revisión por parte de todos los asistentes del backlog de Mejoras y Wishlist de antemano previo a la sesión.
- Personal funcional (Product Owners) asegurar que se dispone de antemano de toda la información necesaria para la toma de las decisiones previstas.
Buenas Prácticas
Asegurar recurrencia de las sesiones.
Reducir al mínimo exponente posible operativo el tiempo de espera de respuesta a usuarios que proponen Mejoras del aplicativo.
Anti-patrones
Aceptar Mejoras que finalmente quedan indefinidamente despriorizadas o con prioridad baja en el Backlog de Mejoras.
Priorizar Mejoras sin un criterio definido y consistente.
Aumento progresivo de Mejoras acumuladas en la Wishlist.