Hay cinco niveles de requisitos ágiles que se van desgranando paulatinamente desde arriba a abajo a medida que se avanza en un proyecto ágil. Es como un embudo en el que entran los requisitos en una forma más general y altamente granulada y se van desgranando y concretando a medida que avanzan en base al valor que aportan. Acaban saliendo como tareas detalladas para la pila de sprint en la parte inferior. Con ello la ingeniería de requisitos ágil trata de establecer un estado de flujo continuo en que se van concretando los requisitos desde la entrada al embudo hasta su salida.
Niveles de requisitos ágiles, cortesía de Scrum Manager |
- Visión del producto: un resumen muy corto de las funcionalidades deseadas y los objetivos del producto a construir compartido por todos
- Tema: representa una colección de epics relacionados para describir un sistema o subsistema en su totalidad
- Epic: una superhistoria de usuario que se distingue por su gran tamaño y su alta granularidad
- Historia de usuario: una descripción breve de una funcionalidad de software tal y como la percibe el usuario
- Tarea: resultado de la descomposición de las historias de usuario en unidades de trabajo o tareas con las que el equipo puede trabajar
Niveles de planificación ágil |
Hoja de ruta del producto: se trata de la planificación de las etapas a recorrer para llegar a la visión, dado que en Agilidad se trata de entrega frecuente, en cada etapa se determinan los releases que serán incluidos. Usualmente se trata de una representación gráfica de releases previstos junto con sus contenidos en forma de temas que se comparte con todos los interesados.
Planificación de release: esta planificación es propia del Propietario del Producto. El equipo estima por encima la pila de producto compuesta por epics e historias de usuario, luego el Propietario del Producto proyecta los sprints futuros en base a la velocidad del equipo y planifica en rangos de fechas futuros releases. Aquí, dado que deben de participar todos los equipos del proyecto, es donde se coordinan estos entre si y surgen las dependencias entre historias de usuario que pueda haber entre equipos. Usualmente el Propietario del Producto planifica entregas que coincidan con uno o más temas, estas se representan con gráfico de producto o gráfico burnup que, focalizándose en el siguiente release, muestra visualmente la evolución previsible de los releases visibles del producto.
Planificación de sprint: se trata de la reunión en que el equipo toma historias de usuario de la pila de producto según la prioridad marcada por el Propietario del Producto, y las desgrana junto con este en las tareas correspondientes. Al desgranarlas y reestimarlas, es en esta reunión donde se va minimizando la incertidumbre. El equipo decide el incremento del sprint cuando decide hasta qué historia de usuario incluirá el sprint y se compromete a realizarlas al 100% dentro del mismo.
Planificación diaria: esta ocurre en el daily-srcum cuando los miembros del equipo informan del trabajo hecho y eligen la siguiente tarea en que van a trabajar. Esta planificación se materializa en el gráfico de avance o burndown que es actualizado día a día.
Cuadro de planificación por niveles
Nivel
|
Cuando
|
Actores principales
|
Salidas
|
Una vez, antes del inicio
|
Propietario del Producto (opcional: Equipo de
|
||
Antes de algunas releases
|
Propietario del Producto (opcional: Equipo de
Desarrollo)
|
||
Antes de cada release
|
Desarrollo (opcional:
interesados)
|
||
En cada inicio de sprint
|
Pila de sprint y objetivo de sprint
|
||
Cada día de trabajo
|
Muy bueno
ResponderEliminarComo sugerencia "pintaría" en líneas de trabajo paralelas
Saludos
Angel Casado