|
 A mi forma de ver, a scrum le falta un nivel de zoom, o de detalle en como trata los requisitos, por eso, definir las tareas de la pila del producto, o product backlog, se suele terciar de forma confusa.
¿Qué es cada elemento de un product backlog?: ¿una funcionalidad? ¿una historia de usuario? ¿un caso de uso?.
Aclara bastante trabajar con tres niveles de requisitos: - Nivel de product manager: funcionalidades generales que quiere el cliente
- Nivel de usuario: historias de usuario que componen cada funcionalidad
- Nivel del equipo: tareas de programación en las que se descompone cada historia
Los podemos llamar así, si tenemos en cuenta el rol de quien emplea los requisitos a ese nivel. También se podrían llamar: nivel de producto, nivel de versión y nivel de sprint; es sólo cuestión de adoptar un criterio de nombres conocido y válido en la organización.
Está claro que en la pila del sprint o sprint backlog , están apuntados los requisitos de nivle 3: las tareas en las que el propio equipo ha descompuesto la parte de producto que va a desarrollar durante el sprint. Lo ha troceado en tareas de entre 4 y 16 horas de trabajo, y se las han auto-asignado.
A partir de aquí, una sugerencia "ScrumManager " es considerar no sólo una pila de producto, sino una pila de producto y una pila de versiones. La primera compuesta por funcionalidades, y la segunda por historias de usuario: las historias de usuario en las que se descompone cada funcionalidad. La primera define en grandes funcionalidades el producto y es la base de trabajo del plan de producto ágil: el gráfico burn-up .
A modo de ejemplo, si el producto fuera un sitio web de asesoría jurídica, las funcionalidades que podrían componer la pila del producto: "la pila del product manager" sería:
1.- Páginas de información corporativa
2.- Área de clientes: registro y modificación de datos...
3.- Tienda virtual de libros
4.- Consulta de jurisprudencia
5.- Consulta de legislación
6.- Noticias legislativas
7.- Consultas frecuentes
...
Con ellas el product manager asignando una estimación de esfuerzo a cada una (igual formato que un product backlog al uso), y conociendo la velocidad del equipo, realiza el plan ágil del producto: esfuerzos y versiones previstas.
Partiendo de la pila del producto, el propietario del producto, o rol de cliente integrado en el equipo de desarrollo, elabora la "pila del usuario", que sería lo que para scrum ha sido siempre el único product backlog.
Por ejemplo, la funcionalidad "Tienda virtual de libros" se podría descomponer en la pila de usuario:
1.- Identificación: login
2.- Consulta del catálogo
3.- Consulta del carro de la compra
4.- Pago
5.- Consulta de pedidos realizados Esta es el elemento de entrada para la reunión de inicio del sprint, de la cual saldrá la pila del sprint o sprint backlog. 
Trackback(0)
 |
TrackBack URI para esta entrada
RSS Comentarios
) 
La aproximación para la gestión de los requerimientos me parece muy buena, se ve de una manera clara la descomposición de los requerimientos.
Quizás yo haría una pequeña distinción en los nombres de las pilas, las funcionalidades de nivel alto las metería en una pila de características o necesidades, y la pila del producto seguiría siendo la que contiene las historias a implementar. Puede parecer una tontería pero como ya estoy acostumbrado a llamar al product backlog pila de producto me resulta mas intuitivo.
En el libro "Visión Managing Software Requirements: A Use Case Approach, Second Edition", realiza una aproximación similar pero claro esta desde el punto de vista de RUP. Utiliza una pirámide para aclarar los diferentes niveles de zoom en los requerimientos.
Saludos.