Inicio arrow Blog arrow Ágiles arrow Visión ScrumManager de los requisitos: Producto, historias y tareas Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Visión ScrumManager de los requisitos: Producto, historias y tareas
Valoración del artículo: / 10
MaloBueno 
15.04.2008

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

  1. Nivel de product manager: funcionalidades generales que quiere el cliente
  2. Nivel de usuario: historias de usuario que componen cada funcionalidad
  3. 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.

Safe Creative #0804150586717

Trackback(0)
Comentarios (3)Add Comment
Re: Visión ScrumManager de los requisitos
escrito por Emilio Bravo, April 18, 2008
Hola,
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.
Palabras, palabras...
escrito por Juan Gabardini, May 14, 2008
Hola
Pecando de purista...

Scrum Manager no es la mejor eleccion de nombres (aunque partimos de una muy discutida como Scrum Master smilies/smiley.gif )
Y siguiendo con terminología...
No mezclaría tareas con requerimientos. Aunque hay un relación entre las tareas y los items de backlog, las tareas no son requerimientos.

En todo caso, podría decirse que hay tres niveles de planificación, pero no tres niveles de requerimientos.

Saludos!
...palabras... palabras
escrito por Juan Palacio, May 15, 2008
Hola tocayo!
Tienes razón. Desde una visión purista de scrum, el backlog es único, por eso Scrum Manager o Scrum Management... es mi forma de llamar a un planteamiento no purista, o más flexible en la formas y por tanto más personalizable a las circunstancias de cada organización.

En los proyectos en los que me muevo, me resulta más útil considerar tres niveles de zoom en los requisitos, que aunque en la interpretación Scrum purista no tiene lugar, sería como el modelo de Mike Cohn para emplear con Extreme Programming, con los tres niveles de "Temas" "Historias de usuario" y "tareas".

Saludos!

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative