Historias de usuario. Sesión 7a. Metodologías Ágiles de Desarrollo de Software Domingo Gallardo, DCCIA, Univ. Alicante

Transcripción

1 Historias de usuario Sesión 7a

2 Historias de usuario La forma ágil de definir funcionalidades de la aplicación Resaltan el punto de vista funcional y del usuario final Se escriben en forma de ficha y contienen tres elementos principales: Descripción escrita de la historia, usada para planificación y como recordatorio Conversaciones sobre la historia que sirven para refrescar los detalles Pruebas de aceptación que definen los detalles y se utilizan para determinar cuando la historia está completa 2

3 Las 3 Cs de Ron Jeffries 3

4 Formato de la historia Título: Generar el PDF del expediente Como estudiante quiero generar un PDF con mi expediente para guardar un resumen de mi expediente y poder entregarlo a quien me lo pida <Título> Como <rol> quiero <característica> para <beneficio> Una historia no se resuelve con un método de un API. Debemos implementar todos sus aspectos: interfaz de usuario, código de cliente, servidor, base de datos, etc. 4

5 Dónde están los detalles? En la historia de usuario anterior hay muchos elementos desconocidos: Qué habrá en el expediente? Se incluye alguna cabecera con los datos de la universidad? Deben aparecer los datos personales del estudiante? Qué asignaturas aparecerán, sólo las aprobadas o también las suspendidas? En qué orden? La información del expediente es configurable? Qué formato se debe dar al listado? Tiene que validarse el expediente con alguna firma digital? Estos elementos deben descubrirse en la conversación originada por la historia Pueden anotarse en la parte de detrás de la ficha (dos o tres frases como mucho) Los detalles adicionales se deben definir como tests 5

6 Descomponiendo historias Una historia típica debe poder terminarse y testearse entre medio día y un par de semanas como máximo por un o dos programadores (Cohn: User Stories Applied) Una historia grande se suele denominar épica (epic) Debemos descomponerla en historias más pequeñas En el backlog del sprint (o tablero Kanban), la historia se descompone en ítems de trabajo (que pueden referirse a detalles técnicos) Veremos la técnica del mapa de historias de usuarios (user story mapping) de Jeff Patton que permite analizar en amplitud y profundidad todas las historias de usuario de un proyecto 6

7 Descomponiendo historias 1 Henrik Kniberg 7

8 INVEST Una buena historia tiene que tener seis atributos: Independiente: dependencias entre las historias crean problemas de priorización y estimación Negociable: no son contratos, son recordatorios de conversaciones Independent Negotiable Valuable Estimable Small Testable Acrónimo creado por Bill Wake Valiosa: las historias deben ser valiosas para los que pagan el software Estimable: el tamaño de la historia debe poder ser estimado, aunque sea de forma gruesa Pequeña: para poder estimarse correctamente, es recomendable que la historia sea pequeña; hay que dividir las épicas Testable: las historias deben ser probadas y los tests deben poder ser automatizados 8

9 Roles de usuario Es muy importante identificar los distintos tipos de roles que pueden acceder a la aplicación Realizar un brainstorming rápido para buscar un conjunto inicial de roles Organizar el conjunto de roles Consolidar los roles Refinar los roles Personas: representación imaginaria de una persona de cada uno de los roles Mike 35 años, 1 hijo Tom, entrena al equipo de béisbol de su hijo, muy ocupado John abuelo jubilado, experiencia limitada con ordenadores, ayuda en la educación de su nieto Linda 28 años, muy activa en el trabajo, el tiempo libre lo dedica al deporte 9

10 El backlog del producto debe estar balanceado Henrik Kniberg 10

11 Mapas de historias de usuario Técnica propuesta por Jeff Patton Workshop de discusión con clientes finales en el que se van descubriendo las historias y se agrupan y ordenan para contar una historia con distintos niveles de prioridad El resultado final es muy similar a un storyboard de cine 11

12 Storyboards en el cine 12

13 Storyboards en el cine The purpose of Storyboarding (You Tube) 13

14 El propósito de un storyboard Los storyboards se usan en el cine para: Desarrollar, discutir y probar la historia (Disney, Pixar,...) Medio de comunicación entre los distintos equipos (cámaras, iluminación, sonido, escenografía, localización, etc.), para ayudar a visualizar escenas Estimar el coste de la producción Se realizan a partir de otro modelo más impreciso todavía: el guión 14

15 Bocetos y protipos de baja fidelidad Mockups de pantallas e interfaces de usuario Permiten mostrar a bajo coste el aspecto del producto final Se usan también storyboards donde se explica los distintos pasos de la aplicación Se pueden hacer con tijeras y papel o con aplicaciones (por ejemplo, balsamic) 15

16 Prototipos de papel (paper prototyping) 16

17 Ejercicio práctico 1. Vemos las transparencias de Jeff Patton sobre mapas de historias de usuario 2. Hacemos 4 equipos de 6 personas (1 portavoz) para hacer el mapa del proyecto Aplicación web para la Escuela Infantil Natura 4. 5 cada equipo para poner en común los resultados 17

18 Lecturas Jeff Patton - The new user story is a map Jeff Patton - It s all in how you slice it 18