Introducción
Se trataría de un taller donde podríamos enseñar cada uno:
- nuestra manera de escribir historias de usuario
- podríamos ver el patrón "Como [rol / personaje] quiero [funcionalidad] para [objetivo]"
- el formato de las tarjetas
- cómo manejamos las "definition of done" de las historias
También podríamos ver defectos típicos:
- historias indefinidas
- historias demasiado concretas
- no saber para qué se hace una historia
Otros temas que se pueden tratar:
- estimar historias de usuario
- ¿cuándo dividir una historia de usuario?
- ¿cuándo fusionar historias?
Material para preparar la reunión
User Stories Applied: For agile Software Development
Addison-Wesley Professional (March 11, 2004)
http://books.google.es/books?id=SvIwuX4SVigC&source=gbs_navlinks_sEnlaces
http://elblogdelfrasco.blogspot.com/2008/07/user-stories.htmlhttp://www.dosideas.com/metodologias/456-las-6-caracteristicas-de-una-buena-historia-de-usuario.htmlReflexión inicial
En la toma de requisitos de software hay un problema de comunicación entre los clientes, usuarios, consultores y el equipo técnico.
Lo que necesitamos es una manera de trabajar juntos y tomar decisiones basados en la información que tenemos a mano durante toda la duración del proyecto.
La primera cosa que se debe de notar en un proyecto basado en historias de usuario es
que los clientes y usuarios siguen participando durante toda la
duración del proyecto.
Las historias se pueden escribir en cualquier momento a lo largo del proyecto.
¿Qué es una historia de usuario?
Una historia de usuario describe la funcionalidad que será valiosa.
Se compone de tres aspectos:
- Una descripción escrita de la historia
- Conversaciones a cerca de la historia
- Pruebas que determinan que la historia está completa
¿ Qué nivel de detalle debe de tener mi historia ?
El nivel de detalle inicial de una historia será el necesario para empezar a codificar las pruebas.
Estos detalles se irán ampliando en conversaciones con el cliente cuando los detalles se vuelvan importantes.
¿ Como describir las expectativas del usuario en una historia ?
Las expectativas del usuario son capturadas en la forma de pruebas de aceptación.
¿Por qué el cliente debe escribir las historias?
- Cada historia debe ser escrita en la lengua de los negocios, no en la jerga técnica
- El cliente está en la mejor posición para describir el comportamiento del producto.
¿ Como preparar un Plan de versiones y las iteraciones ?
Priorizando las historias de usuario maximizando el valor entregado a la organización.
- El cliente da prioridad a las historias de forma coherente.
- Cada historia se le asigna una estimación historia en
puntos, lo que indica el tamaño y la complejidad de la historia en
relación con otras historias.
- Establecer la velocidad esperada del equipo, que es el número de puntos de historia que se terminan por iteración completa.
- El cliente selecciona las historias de la iteración sin sobrepasar la velocidad esperada.
¿Qué son las pruebas de aceptación?
La prueba de aceptación es el proceso de verificación de las historias que se han desarrollado.
Estas pruebas deben ser escritas al principio de la iteración (o incluso un poco antes de la iteración)
¿Por qué utilizar historias de usuario?
- Hacen hincapie en la comunicación verbal en lugar de la escrita.
- Son comprensibles por el cliente y por los desarrolladores.
- Son del tamaño adecuado para la planificación.
- Aplazan la descripción del detalle hasta que haya una comprensión mejor de lo que realmente se necesita.
- Los aspectos importantes sobre historias son capturados en las pruebas de aceptación automática y sirven de documentación.
- El software es iterativamente refinado basado en las conversaciones entre el cliente y el equipo de desarrolladores.
Resumen
Agustín traía una presentación que utiliza en la UPM. (Estaría bien tener el enlace)
El papel del PO (Analista de negocio) ayuda al cliente a definir mejor
Cuando el PO sabe el tamaño de las historias, la planificacón es muy sencilla porque el planning poker ya no sirve
Las 3 C
- Card
- Conversation
- Confirmation
Las cinco W
Como usuario (who) quiero poder
pulsar el botón de nuevo comentario en el foro (what) situado en la
parte inferior de la página (where) después de leer un tema (when) para
poder expresar una opinión en el foro (why).
Personas (personajes)
Discrepancias sobre when y where (se pueden asumir cuando el equipo
Hola, me gustaría proponer el siguiente material. Es corto y va al grano.
http://www.dosideas.com/metodologias/456-las-6-caracteristicas-de-una-buena-historia-de-usuario.html
También me gustaría proponer que NO hablemos en esta sesión de estimaciones de historias de usuario sino de cómo debe escribirse una historia de usuario: la mejor forma de redactarla (p.ej. "como [rol] quiero [funcionalidad] para [beneficio]"), el mejor formato para las tarjetas, cómo se maneja la "definition of done" (expectativas del usuario), qué pasa cuando las expectativas del usuario no se pueden capturar todas como pruebas de aceptación automatizadas, etc.