Historias de
Usuario
2
Agenda
4.- Historias de usuario Altamente
1.- Antes que nada
Efectivas: INVEST I
2.- Historias de Usuario: Un Nuevo 5.- Historias de usuario Altamente
Orden en los Requisitos Efectivas: INVEST II
3.- Modos de Representación de
6.- User Story Mapping y Storytelling
Historias de Usuario
Antes que
nada...
“...Y cada uno de los equipos de desarrollo
llegaba con documentos de requisitos
gloriosos, hermosos y largos. Inevitablemente
me sentí culpable de que mis propios grupos
Mike Cohn
no produjeran especificaciones de requisitos
tan hermosas...” Cohn
Mike Cohn, User Stories
Applied
¿Qué es una
Historia?
4
“Erase el año de
1900 y
fracción [...]”
Breve Historia de las Historias
de Usuario
5
Book: User
Book: Card Stories
Extreme
User Extreme Conversatio Applied For
Programmin Story
Programming n Agile
g
Explained Confirmatio Software
n Development
,
Historia de las Historias
de Usuario
6
Las Historias de usuarios se originaron con
Extreme Programming (XP)
Extreme Programming fue desarrollada por Kent Beck
en 1996 y a partir de allí refinó el Framework hasta
publicarlo en su libro Extreme Programming
Explained en 1999
La primera descripción escrita de una Historia de
Usuario ocurrió en 1998 donde sólo se afirmó que
los clientes definen el alcance del proyecto “Con
En lugar de ofrecerse
historias como
usuarios que sonuna práctica
como casosdistinta,
de uso” Kent
las historias se describen como una de las "piezas Beck
del juego" utilizadas en el "juego de planificación“
- Planning Game de XP.
Historia de las Historias
de Usuario
7
En 2001 Ron Jeffries propone el modelo - Card,
Conversation, Confirmation - para distinguir
historias de usuarios “Sociales” de prácticas de
requisitos “documentales” como los casos de
uso.
En 2001 Rachel Davies presentó una charla
“Tuning XP" en el XPDay con Tim Mackinnon,
donde
"As presentaron
a role el formato
I want feature de historia que
so that
usaban en Connextra:
benefit“
Ron
Jeffries
Historia de las Historias
de Usuario
18
En 2004 Mike Cohn publica su libro User Stories
Applied For Agile Software Development, donde
ayuda a popularizar el formato de Davies y su
equipo en Connextra.
Mike
Cohn
Sobre la programación
extrema
9
El cliente en el sitio, colabora con los
programadores y planifica las historias de
usuarios que formarán las liberaciones de
más valor.
Tienen tres aspectos críticos:
▹ Card - Tarjeta,
▹ Conversation - Conversación y
▹ Confirmation - Confirmación.
Car
d Customer:
10 Hello, I’d like to order a cake.
Employee:
Sure, what would you like written on it?
Customer:
Could you write “So long, Alicia” in
purple?
Employee: Sure.
Customer: And put stars around it?
Employee:
No problem. I’ve written this up, and will hand it to my cake
decorator right away. We’ll have it for you in the morning.
Car
d
11
Car
d
12
Car
d
13
La tarjeta no contiene toda la información que
conforma el requisito.
Solo tiene texto suficiente para identificar el
requisito y para recordar a todos cuál es la
Como Cliente
historia. quiero
consultar mi
saldo.
La tarjeta es un token que representa el
requisito.
Se entrega cuando está lista para
implementarse, y se devuelve al cliente cuando
se ha implementado.
Car
d
14
“Compartir documentos no significa compartir
entendimiento. La comprensión compartida es
cuando ambos entendemos lo que la otra persona
está imaginando y por qué.”
Jeff Patton
Conversa
ción
15
Es más efectiva si podemos
externar nuestros
pensamientos mediante
dibujos, diagramas o
organizando nuestras ideas
con post its o tarjetas.
Conversa
ción
16
El requisito se comunica del cliente a los programadores a través de la
conversación:
Un intercambio de pensamientos, opiniones y sentimientos.
Se lleva a cabo a especialmente cuando se estima la historia, en la
reunión de planificación de la iteración.
Es en gran parte verbal, puede complementarse con; documentos,
prototipos, diagramas, etc.
Confirmac
ión
17
Este componente es el criterio de
aceptación.
Al comienzo de la iteración, el cliente le
comunica a los programadores lo que
quiere, diciéndoles cómo confirmará
que han hecho lo que es necesario.
Esto define las pruebas de aceptación
que se utilizarán para mostrar que la historia
se ha implementado correctamente.
Confirmac
ión
18
Incluso para situaciones bastante complejas, funciona mejor la
confirmación utilizando ejemplos.
Sugeriría comenzar con la tarjeta, la conversación, la confirmación y
agregar otros documentos solo si son claramente necesarios.
Los programadores implementan la historia, y también implementan los
criterios de aceptación.
La confirmación hace posible el enfoque simple de la tarjeta y la
conversación.
Confirmac
ión
19
Cuando la conversación sobre una tarjeta
llega a los detalles de la prueba de aceptación, el
cliente y el programador resuelven los detalles
finales de lo que debe hacerse.
La confirmación, en términos de pruebas de
aceptación, es lo que hace girar al Círculo de la
Vida.
Stories
Y el Círculo de la Vida ... eso es lo que
User
mantiene vivo tu proyecto.
Métodos Ágiles y las Historias
20 de Usuario
Peopleware y equipos ágiles, Javier Garzás, 2019.
Métodos Ágiles y las Historias
21 de Usuario
Historia
s de
Usuario
Peopleware y equipos ágiles, Javier Garzás, 2019.
Popularidad de las Historias
de Usuario
22 Scru
m
Nivel de
detalle
23
Nivel de
Detalle
24
Épicas
Es una historia de usuario que es demasiado grande para caber en
un sprint. A menudo, este término se utiliza para describir una gran
historia de usuario que tendrá que ser dividida en historias más
pequeñas.
Historia de usuario
Es una representación de un requisito
del usuario en forma escrita, de una o
dos frases utilizando el lenguaje común
del usuario
Épicas e Historias de
Usuario
25
“Una Épica se es una
funcionalidad de alto nivel
escrita en el formato de una
historia de usuario”
Mic
h
Historias de Usuario: Un Nuevo Orden
en los Requisitos
26
Breves.
Descripción corta. La historia de usuario es
un sustituto más ligero
para lo que han sido
Facilidad. nuestros medios
Fáciles de entender y aceptar. tradicionales de
especificar requisitos de
software...
Persistentes.
Sin que tengan que
De franca recordación. escribirse todos los
detalles.
Historias de Usuario: Un Nuevo Orden
en los Requisitos
27
Como Historia de Usuario
Debo Ser cn Recordatorio de una
Conversación 9ue Ła occrrido, o bien, se
tendrá en el futuro
Para Favorecer la Comunicación y
Colaboración entre el Propietario del
Producto y el E9uipo de Desarrollo
¿Por qué funcionan las Historias
de Usuario?
28
La simpleza de las Historias de
Usuario obliga al equipo a estar
en comunicación con el Dueño
de Producto.
En la planificación y durante el
refinamiento.
Algunas Características de las
Historias de Usuario
29
Algunas Características de las
Historias de Usuario
30
Finalización de una Historia
de Usuario
31
Ventajas de las Historias
de Usuario
32
Objetivos de una Historia
de Usuario
33
Formato de una historia
de usuario
34
Como una buena noticia,
las tres partes de la
plantilla de la historia de
usuario comunican
quién, qué y por qué.
Yo como…
quiero… para...
35
Formato básico:
Yo como ROL (persona que va a usar la
funcionalidad),
Deseo / quiero / necesito FUNCIONALIDAD
REQUERIDA
Para BENEFICIO O VALOR PARA EL NEGOCIO.
Mike Cohn sugiere:
▹ ¿Quién quiere la funcionalidad?
▹ ¿Qué es lo que quieren?
▹ ¿Por qué lo quieren?
Historias de Usuario y sus Criterios
de Aceptación
36
● Son los componentes objetivos mediante los cuales
se juzga la funcionalidad de una historia de usuario.
● Los desarrolla el Product Owner según su
experiencia en los requerimientos del cliente.
● Deben delinear explícitamente las condiciones que
deben satisfacer las historias de usuario.
● Al final de cada sprint, el Product Owner los utiliza
para verificar los entregables completados.
● Si son aceptados por el Product Owner, la historia
de usuario se considera entonces como terminada.
Nuestro primer ejemplo de una
Historia de Usuario
37
Por coherencia, muchos de los
ejemplos en el resto del curso
serán para un sitio web de
Bolsa de Trabajo que
llamaremos GodínJobs.com
Yo como Usuario
Un usuario puede Quiero publicar mi
publicar
su Curriculum Vitae Ctf Para
en el
sitio web de completar mi
Jobs.com
perfil personal
Otros ejemplos para
Jobs.com
38 Yo como Usuario
Un usuario puede Quiero buscar
buscar
o$ertas de empleo
trabajos
Para poder
postularme
Una empresa puede Yo como Empresa
publicar nuevas Quiero publicar
ofertas de ofertas de empleo
trabajo
Para atraer talento
Malos ejemplos de Historias
de Usuario Yo como
39 Programador
El software se
escribirá Quiero desarrollar
en C ++. en C++ Para
cumplir con los
requisitos del
El programa se proyecto
conectará
a la base de datos a
Yo como Sistema
través de un grupo
Quiero conectarme
de
a una BQ
Modos de
Representación
de las Historias
de Usuario
“La recopilación y documentación exhaustiva de
requisitos puede matar un proyecto de muchas
maneras.
Cuando el documento se convierte en un
objetivo y cuándo por medio de las
imprecisiones del lenguaje escrito.”
Los Modos de Representación de las
Historias de Usuario
41
Modo 1: Solamente el título
Alto Nivel de madurez del equipo y del Dueño de Producto
HU25: Registro de
Datos
Personales
Los Modos de Representación de las
Historias de Usuario
42
Modo 2: El título la descripción de Mike Cohn
Alto Nivel de madurez del equipo y del Dueño de Producto
HU25: Registro de Datos Personales
Como Posible Candidato
Quiero Ingresar mis Datos Personales
Para Poder ser elegible en una vacante
Los Modos de Representación de las
Historias de Usuario
43
Modo 3: El título + El boceto
Nivel de madurez Intermedio del equipo y del Dueño de
Producto
HU25: Registro de
Datos
Personales
Los Modos de Representación de las
Historias de Usuario
44
Modo 4: El título + La descripción de Mike Cohn + Los criterios de
aceptación en prosa [ + boceto (opcional)]
Nivel de madurez Principiante del equipo y del Dueño de
Producto
Criterios de Aceptación
Campos requeridos; Nombre, Apellidos,
HU25: Registro de Datos Fecha de
Personales
nacimiento, Nacionalidad, Ciudad,
Como Posible Candidato Dirección actual,
Quiero Ingresar mis Datos País de residencia, Estado/Provincia.
Personales
Los campos subrayados serán tomados
Para Poder ser elegible en una de la BD
vacante
Los Modos de Representación de las
Historias de Usuario
45
Modo 5: El título + La descripción de Mike Cohn + Los criterios de
aceptación con BDD [+ boceto (opcional)]
Nivel de madurez Junior del equipo y del Dueño de Producto
HU25: Registro de Datos
Personales
Como Posible Candidato
Quiero Ingresar mis Datos
Personales
Para Poder ser elegible en una
vacante
Los Modos de Representación de las
Historias de Usuario
46
Modo 5: El título + La descripción de Mike Cohn + Los criterios de
aceptación con BDD [+ boceto (opcional)]
Nivel de madurez Junior del equipo y del Dueño de Producto
Criterios de Aceptación: CA1 Ingreso de datos
DADO que el usuario se encuentra en la página de registro
CUANDO seleccione la pestaña de datos personales
ENTONCES el sistema le pedirá los campos requeridos; Nombre,
Apellidos, Fecha de
nacimiento, Nacionalidad, Ciudad, Dirección actual, País de
residencia, Estado/Provincia.
Los Modos de Representación de las
Historias de Usuario
47
Modo 5: El título + La descripción de Mike Cohn + Los criterios de
aceptación con BDD [+ boceto (opcional)]
Nivel de madurez Junior del equipo y del Dueño de Producto
Criterios de Aceptación: CA2 Validación de ingreso de datos
DADO que el usuario ingresó los datos requeridos
Y existe al menos un campo sin ingresar
CUANDO seleccione enviar
ENTONCES el sistema le presentará un mensaje informándole el/los
campo(s) faltante(s)
Y el/los campo(s) faltantes aparecerán marcados en color rojo
En
resumen
48
PREGUNTAS
?
