Diferencia entre revisiones de «Mapa de historias»
De Dos Ideas.
(→Proceso de construcción de un mapa de historias) |
|||
| (No se muestran 4 ediciones intermedias del mismo usuario) | |||
| Línea 23: | Línea 23: | ||
== Proceso de construcción de un mapa de historias == | == Proceso de construcción de un mapa de historias == | ||
| − | #Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada | + | #Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada. La recomendación es utilizar un color que diferencie las tarjetas de este nivel. |
| − | # | + | #Ordenar las tarjetas según el uso, de izquierda a derecha. |
| − | #Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una | + | #Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una tarjeta, utilizando un color diferente de las actividades planteadas más arriba. |
| − | #Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. | + | #Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Es posible que no represente una secuencia estricta que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas. |
| − | que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas | + | #Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Hacer la siguiente pregunta: ¿ lo que vemos es una imagen completa de lo que el producto tiene que ofrecer ?. Actualizar y modificar las actividades y tareas según sea necesario. |
| − | #Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. | + | #Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al realizar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superior de sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general. |
| − | #Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente | ||
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario. | #Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario. | ||
| − | #Mantener el mapa de historias | + | #Mantener el mapa de historias en forma conjunta para proporcionar una vista del producto completo. La recomendación es indicar en el mapa cuando las historias está completa. |
== Ventajas == | == Ventajas == | ||
| Línea 37: | Línea 36: | ||
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. | * Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. | ||
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto. | * Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto. | ||
| − | * Hace foco en el negocio y no en el detalle de las historias | + | * Hace foco en el negocio y no en el detalle de las historias. |
== Desventajas == | == Desventajas == | ||
| Línea 45: | Línea 44: | ||
== Ejemplo gráfico de un mapa de historias == | == Ejemplo gráfico de un mapa de historias == | ||
| − | + | '''FALTA GRAFICO (PUEDE SER UNA FOTO DEL PROYECTO MODELO EN PIVOTAL)''' | |
== Ejercicio para hacer un mapa de historias == | == Ejercicio para hacer un mapa de historias == | ||
| Línea 55: | Línea 54: | ||
# Cuando llega a cero el socio se de de baja automáticamente. | # Cuando llega a cero el socio se de de baja automáticamente. | ||
| − | == | + | == Material de Referencia == |
* http://prezi.com/fj534uoemif6/story-mapping/ | * http://prezi.com/fj534uoemif6/story-mapping/ | ||
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02 | * http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02 | ||
| + | |||
| + | == Ver también == | ||
| + | |||
* [[Historia de usuario]] | * [[Historia de usuario]] | ||
* [[Backlog Del Producto]] | * [[Backlog Del Producto]] | ||
* [[Scrum]] | * [[Scrum]] | ||
* [[Backlog Del Sprint]] | * [[Backlog Del Sprint]] | ||
Revisión actual del 13:07 11 sep 2012
Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto.
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.
Contenido
- 1 ¿ Cómo surge esta técnica ?
- 2 ¿ Cómo generar un mapa de historias ?
- 3 Consideraciones a tener en cuenta
- 4 Proceso de construcción de un mapa de historias
- 5 Ventajas
- 6 Desventajas
- 7 Ejemplo gráfico de un mapa de historias
- 8 Ejercicio para hacer un mapa de historias
- 9 Material de Referencia
- 10 Ver también
¿ Cómo surge esta técnica ?
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.
¿ Cómo generar un mapa de historias ?
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:
- el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.
- el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.
Consideraciones a tener en cuenta
- Empezar por los objetivos de negocio.
- Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.
- Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?
- Generar las etapas con las historias de usuario.
Proceso de construcción de un mapa de historias
- Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada. La recomendación es utilizar un color que diferencie las tarjetas de este nivel.
- Ordenar las tarjetas según el uso, de izquierda a derecha.
- Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una tarjeta, utilizando un color diferente de las actividades planteadas más arriba.
- Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Es posible que no represente una secuencia estricta que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas.
- Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Hacer la siguiente pregunta: ¿ lo que vemos es una imagen completa de lo que el producto tiene que ofrecer ?. Actualizar y modificar las actividades y tareas según sea necesario.
- Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al realizar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superior de sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.
- Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.
- Mantener el mapa de historias en forma conjunta para proporcionar una vista del producto completo. La recomendación es indicar en el mapa cuando las historias está completa.
Ventajas
- Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil.
- Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.
- Hace foco en el negocio y no en el detalle de las historias.
Desventajas
- Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.
Ejemplo gráfico de un mapa de historias
FALTA GRAFICO (PUEDE SER UNA FOTO DEL PROYECTO MODELO EN PIVOTAL)
Ejercicio para hacer un mapa de historias
- Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.
- El sistema debe admitir el alta y la baja de socios y de libros.
- Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado.
- Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente.
- Cuando llega a cero el socio se de de baja automáticamente.
Material de Referencia
- http://prezi.com/fj534uoemif6/story-mapping/
- http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02
