April 6, 2011 Escribiendo Historias de Usuario Kane Mar, 7 de setiembre, 2006 Traducido por Víctor Bustamante.

Presentación del tema: "April 6, 2011 Escribiendo Historias de Usuario Kane Mar, 7 de setiembre, 2006 Traducido por Víctor Bustamante."— Transcripción de la presentación:

1 April 6, 2011 Escribiendo Historias de Usuario Kane Mar, 7 de setiembre, 2006 Traducido por Víctor Bustamante

2 April 6, 2011 El problema con los usuarios… … es que ellos siempre quieren algo!!! Los requerimientos son un problema de comunicación entre los aquellos que tienen un problema y quienes pueden darle una solución.

3 April 6, 2011 Negociación sobre contratos “Puesto que los usuarios no saben como resolver sus problemas, tenemos que dejar de preguntarles… y en lugar de ello involucrarlos” - Mike Cohn

4 April 6, 2011 Agenda Escribiendo historias de usuario Descomponiendo Epics Escribiendo criterios de aceptación

5 April 6, 2011 Qué es una historia de usuario? “La promesa para una conversación futura” - Ron Jeffries

6 April 6, 2011 What is a Story not? Las historias no son: –“mini” Use Cases –Una especificación completa –Un contrato –Destinadas a ser interpretadas sin un Product Owner

7 April 6, 2011 Plantilla para Historias de Usuario. “Como un quiero de modo que ” Ejemplo: Como Tesorero, quiero ser capaz de retirar fondos de mi cuenta corriente, de modo que pueda realizar la compra de materiales.

8 April 6, 2011 ¿Qué es un Epic? Son por lo general historias compuestas, que pueden dividirse en historias mas pequeñas y centradas. Pueden involucrar algunos Sprints de trabajo (iteraciones)

9 April 6, 2011 Algunas guías para escribir buenas historias de usuario Testable. Pruebas de aceptación tangibles pueden ser escritas contra cualquier entrega de software. El alcance de la historia de usuario es lo suficientemente manejable para que el equipo pueda proporcionar una estimado Independientes y no depender de otras historias. De tamaño apropiado. Significar un nivel de esfuerzo de modo que el equipo la pueda terminar cómodamente en la duración de una sola iteración.

10 April 6, 2011 Agenda Escribiendo historias de usuario Descomponiendo Epics Escribiendo criterios de aceptación

11 April 6, 2011 Algunos sitios donde considerar dividir Epics En los limites de CRUD En los limites de un sistema donde 2 sistemas necesitan una interfaz En los limites de Happy-Path / Exception-Path

12 April 6, 2011 En los límites de CRUD: Esta solución se utiliza comúnmente en entornos que interactúen con una base de datos Ejemplo: Como tesorero, quiero abrir una cuenta corriente… Como tesorero, quiero depositar un cheque en mi cuenta corriente… Como tesorero, quiero visualizar el balance actualizado en mi cuenta corriente…

13 April 6, 2011 En los limites del sistema: Se Utiliza donde hay un gran número de sistemas legados Puede ser utilizada: –Cuando hay una separación clara entre 2 sistemas –Donde la interfaz entre los 2 sistemas esta bien entendida Una advertencia: tenga cuidado de crear dependencias entre 2 proyectos diferentes

14 April 6, 2011 En los límites de Happy-Path / Exception-Path: Utilizado cuando estamos haciendo la transición desde casos de uso El escenario happy-path puede necesitar descomposición. Descomponer casos de uso puede significar mucho trabajo… es mejor comenzar utilizando historias de usuario

15 April 6, 2011 Agenda Escrinbiendo historias de usuario Descomponiendo Epics Escribiendo criterios de aceptación

16 April 6, 2011 ¿Qué es un criterio de aceptación? Son las expectativas del propietario de producto sobre las cuales será entregado el producto Los criterios de aceptación incluyen: –Funcionalidad que el sistema debe realizar –El look and feel de la interfaz –La documentación necesaria (ejemplo documentación de cumplimiento de SOX)

17 April 6, 2011 Algunas guías para escribir buenos criterios de aceptación Sea explicito –“El sistema mostrará la fecha.” … –¿En qué formato? Es “2006, Abril 1 st” aceptable? Proveer ejemplo para clarificar –“La fecha del sistema será mostrada en el formato 13/4/06” Listar cualquier suposición que el equipo puede no tener presente

18 April 6, 2011 Algunas guías para escribir buenos criterios de aceptación Incluya lo que espera que el sistema haga … –“El balance de la cuenta será actualizado con la cantidad ingresada por el usuario.” … y donde haya ambigüedad, lo que se espera que el sistema no haga –“No se espera en este momento que se realice la conciliación con la cantidad de fondos depositados.”

19 April 6, 2011 Referencias “Users Stories Applied”, Mike Cohen “Agile Estimating and Planning”, Mike Cohen http://www.ScrumAlliance.org