Historias de usuario

Joan Sebastián Ramírez Pérez2016

Agenda

• Historias de usuario• Spike• Visual Story Mapping• Bibliografía

Agenda

• Historias de usuario• Spike• Visual Story Mapping• Bibliografía

¿Por qué usar historias de usuario?

• Porque siguen los principios básicos de requerimientos ágiles, estos son: • Potencian la participación del equipo en la toma de decisiones. • Se crean y evolucionan a medida que el proyecto avanza. • Peticiones concretas y pequeñas• Contiene la información imprescindible. Menos es más. • Apoyan la cooperación, colaboración y conversación entre los

miembros del equipo, lo que es fundamental.

Historia de usuario

• Una historia de usuario describe una funcionalidad que, por sí misma, aporta valor al usuario.

• Debe ser breve (para ser memorizable) e idealmente debe poderse automatizar.

• Es una invitación a conversar.• Puede representar requisitos funcionales, no funcionales o

defectos.• Proviene de XP.

3C

• Card: descripción.• Confimation: Criterios de Aceptación.• Conversation: explicación.

Card

• Hace alusión a la descripción de la necesidad del usuario.• Se suele usar el formato:

• Yo como <rol> quiero <acción> para <valor del negocio u objetivo>

Confirmation

• Hace referencia a los criterios de aceptación.• Para hacer ATDD se suele usar Gherkins.• Es lo que debe probar tanto el equipo de desarrollo como

el Product Owner para marcar como completada la historia.

• Los criterios de aceptación acompañan el Definition of Done. Por lo cual para que la historia este completa debe cumplir los criterios de aceptación y el Definition of Done.

Conversation

• Es el momento en el cual el equipo asimila la necesidad. Entiende cual es el problema que tiene el usuario y asimila cual es el camino correcto para dar solución.

• Resultado de esta conversación hay claridad entre las partes y se refina la historia para dejar claros aquellos vacíos que pueda tener.

INVEST

• Independent• Negotiable• Valuable• Estimable• Small• Testable

Independiente

• Una historia debe ser independiente de otras (lo más posible). Las dependencias entre las historias hace que sea más difícil planificar, priorizar y estimar.

• A menudo, se puede reducir las dependencias haciendo una combinación de historias, o partiendo historias de forma diferente.

Negociable

• Una historia de usuario es negociable. La "tarjeta" de la historia es tan sólo una descripción corta que no incluye detalles. Los detalles se trabajan durante la etapa de "Conversación". Una tarjeta con demasiados detalles limita la conversación con el cliente.

Valiosa

• Cada historia tiene que tener valor para el cliente. • Apunta a un objetivo claro.

Estimable

• El equipo de desarrollo necesita poder estimar una historia de usuario para permitir que se pueda priorizar y planificar.

• Los problemas que pueden impedirle a los desarrolladores estimar una historia son: falta de conocimiento del dominio (en cuyo caso se necesita más Negociación / Conversación); o si la historia es muy grande (en cuyo caso se necesita descomponer la historia en historias más pequeñas, Slicing).

Pequeña

• Una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo. Una historia que es más grande va a tener más errores asociados a la estimación y alcance.

Testeable

• Una historia necesita poder probarse para que ocurra la etapa de "Confirmación".

• Un ejemplo de historia no testeable sería: "el software tiene que ser fácil de usar".

Notación Gerkins

• Usado para BDD y ATDD.• Precondición-Acción-Resultado esperado= Given-when-

then.• Se escriben los criterios de aceptación como escenarios.

Estos escenarios deberán ser automatizado mediante pruebas.

Historias épicas

• Son historias de usuario muy grande, más que una porción de funcionalidad describe un deseado.

• Por ejemplo:• Filtros de búsqueda.• Sistema de búsqueda de texto libre para ofertas de trabajo.• Presentación de listado con detalle de la búsqueda.

Ejemplos descripción• Como usuario de la aplicación quiero pagar mi compra con tarjeta de crédito para poder

acceder al producto que necesito.• Como usuario de la aplicación quiero interactuar por chat con las personas de soporte al

cliente para obtener claridad sobre mi PQR• Como persona interesada en ser usuario de la aplicación quiero una sección de

preguntas frecuentes para aclarar aquellos vacíos que no me permiten dar el paso a ser usuario de la aplicación

• Como usuario de la aplicación quiero realizar mis pagos a través de un dispositivo móvil para que la compra se adapte a mi disponibilidad de tiempo.

• Como usuario de la biblioteca quiero realizar el préstamo de un libro para poder leer la información que requiero a través de los recursos de la biblioteca

• Como administrador de la biblioteca quiero restringir el préstamo de libros por usuario y tomo para garantizar la disponibilidad de recursos a los miembros acorde a la capacidad de la biblioteca

Agenda

• Historias de usuario• Spike• Visual Story Mapping• Bibliografía

Spike

• Practica adoptada de XP.• Un Spike es un espacio de exploración que busca dar

certidumbre sobre una necesidad que el equipo de desarrollo requiere atender al cliente.

• Se puede usar para: consultar, generar espacios para definiciones de diseño o arquitectura de la aplicación.

• Teóricamente no llevan tiempo definido.

Agenda

• Historias de usuario• Spike• Visual Story Mapping• Bibliografía

Visual Story Mapping

• Técnica creada por Jeff Patton• Es una representación visual del sistema completo.• Permite identificar Historias de Usuario faltantes en el

Backlog, planificar Releases, visualizar cómo se distribuyen las funcionalidades de acuerdo a las diferentes áreas del sistema.

• Se va a dividir el sistema completo en planes de salida (Releases), se debería poder sacar versiones a producción en medio del Release.

¿Cómo se hace un Visual Story Mapping?

1. Identificar las funcionalidades en las que podemos dividir nuestro sistema (actividades) de forma secuencias.

2. Descomponer las actividades en las funcionalidades que hace el usuario (Historias de Usuario)

3. Identificar cuales sub tareas deben ser desarrolladas, las más valiosas.

La fila de grandes funcionalidades serán Historias Epicas y se conocerán con el nombre de The backbone.

The Walking Skeleton: las actividades más básicas que ofrecen una funcionalidad de punta a punta en nuestro sistema.

Agenda

• Historias de usuario• Spike• Visual Story Mapping• Bibliografía

Bibilografía•  User Stories - Answers On A Postcard http://

www.agile-software-development.com/2008/01/user-stories-answers-on-postcard-please.html

• Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP

• Example of a User Story http://www.agile-software-development.com/2008/01/example-of-user-story.html

• Writing Good User Stories http://www.agile-software-development.com/2008/04/writing-good-user-stories.html

• Introducing User Stories http://www.slideshare.net/rsrivastava91/introducing-agile-user-stories?src=related_normal&rel=4664999

• New to User Stories? http://www.scrumalliance.org/articles/169-new-to-user-stories• Las 6 características de una buena historia de usuario  http://

www.dosideas.com/noticias/metodologias/456-las-6-caracteristicas-de-una-buena-historia-de-usuario.html

• Las historias de usuario son más que una tarjeta http://www.dosideas.com/noticias/metodologias/895-las-historias-de-usuario-son-mas-que-una-tarjeta.html