HISTORIAS

DE USUARIO
Aplicadas a metodologías de desarrollo
ágiles
CAPÍTULO 1 - UNA VISIÓN GENERAL
CAPÍTULO 1 - ¿QUE ES UNA HISTORIA DE USUARIO?
Una historia de usuario describe
la funcionalidad que resultará
valiosa a un usuario o consumidor
de un sistema o software. Las
historias de usuarios se componen
de tres aspectos:
● una descripción escrita de la
historia que se utiliza para
la planificación y como
recordatorio
● las conversaciones sobre la
historia que servirán para
dar cuerpo a los detalles
● los tests o pruebas que
transmiten y documentan
los detalles y que pueden
ser usados para determinar
cuando se finaliza
CAPÍTULO 1 - ¿DONDE ESTAN LOS DETALLES?

Al redactar las historias es mejor tener más

historias que tener historias demasiado largas.
No hay ningún inconveniente en hacer
anotaciones en las tarjetas basados en los
debates que se suscitan aunque en la
conversación se encuentra realmente la clave.
Ni los desarrolladores ni el cliente pueden
señalar la tarjeta tres meses después y decir,
"Pero, ves que yo lo dije aquí". Las historias
no son obligaciones contractuales. Como se
verá más adelante, los acuerdos están
documentados en los test que demuestran
que una historia ha sido desarrollada
correctamente.
CAPÍTULO 1 - ¿QUE TAMAÑO DEBEN TENER?

Es muy importante
conocer y comprender las
expectativas de los
usuarios de un proyecto.
Estas expectativas como
mejor se recopilan es en la
forma de los test de
aceptación.
CAPÍTULO 1 - EL EQUIPO DEL CLIENTE

El equipo del cliente incluirá a aquellos que aseguren que

se alcanzan las necesidades de los usuarios implicados.
Esto significa que el equipo de cliente puede incluir testers,
un product-mánager, usuarios reales y diseñadores de
interacciones.

¿Como debe ser el proceso?

Los primero que notaremos en un proyecto guiado por las historias de

usuario es que los clientes y usuarios intervienen a lo largo de todo el
tiempo que dura el proyecto. No se espera, o no se les permite,
desaparecer a mitad del proyecto. Esto es cierto si el equipo está utilizando
Extreme Programming XP, una versión de Procesos Unificados, un proceso
ágil como Scrum, o un proceso ágil y casero, guiado por las experiencias.
CAPÍTULO 1 - EL EQUIPO DEL CLIENTE

¿ Por qué los clientes escriben las historias ?

El equipo del cliente, más que los programadores, escribe las historias de usuario por dos
razones fundamentales. Primero, cada historia debe ser escrita en un lenguaje del negocio, no
en la jerga técnica, de tal forma que el equipo del cliente pueda priorizar las historias para
incluirlas en las iteraciones y las versiones. Segundo, como principales visionarios del producto,
el equipo del cliente está en la mejor posición para describir el comportamiento del producto.

¿ Qué son los test de aceptación ?

Comprobar la aceptación es el proceso de verificar que las historias fueron desarrolladas de

tal manera que funcionan exactamente como el equipo de cliente espera. Una vez que
comienzan las interacciones, los desarrolladores empiezan a escribir el código y el equipo de
cliente a especificar los tests. Dependiendo de las habilidades de los miembros del equipo de
cliente, podrían desde escribir los test en el reverso de las tarjetas hasta implementar los test en
una herramienta automatizada. Un tester debería formar parte del equipo de cliente para estas
tareas más técnicas.
CAPÍTULO 1 - EL EQUIPO DEL CLIENTE

¿ Porqué cambiar ?

En este momento nos podríamos preguntar ¿porqué cambiar?, ¿porqué escribir todas estas
tarjetas de historias y mantener todas estas conversaciones? ¿Porqué no seguir escribiendo los
documentos de requisitos y las guías de uso? Las historias de usuario ofrecen una serie de
ventajas frente a otras alternativas y algunas de las razones son:
● enfatizan la comunicación oral más que la escrita
● son comprensibles por ambas partes
● tienen el tamaño correcto para la planificación
● funcionan para un desarrollo basado en iteraciones
● estimulan posponer los detalles hasta la mejor compresión de lo que se va a tener en
base a lo que se necesita.
CAPÍTULO 2 - ESCRIBIENDO HISTORIAS DE USUARIO

Las historias de usuario bien escritas son esenciales para el

Desarrollo Ágil. Deben ser independientes entre si; se debe
poder negociar los detalles entre los usuarios y los
desarrolladores; las historias deben tener valor para el cliente;
deben ser lo suficientemente claras para que los
desarrolladores puedan estimarlas; deben ser pequeñas; y
deben poder probarse usando los casos de prueba pre-
definidos. El equipo del cliente incluirá a aquellos que
aseguren que se alcanzan las necesidades de los usuarios
implicados. Esto significa que el equipo de cliente puede incluir
testers, un product-mánager, usuarios reales y diseñadores de
interacciones.
CAPÍTULO 2 - ESCRIBIENDO HISTORIAS DE USUARIO

Una buena historia de usuario también sigue el modelo de INVEST: Independiente, Negociable, Estimable,
Pequeña (Small), y Testeable. Veamos lo que significa.
● Independiente - una historia debería ser independiente de otras (lo más posible). Las dependencias
entre las historias hace que sea más dificil 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.
CAPÍTULO 2 - ESCRIBIENDO HISTORIAS DE USUARIO

Valiosa - cada historia tiene que tener valor para el cliente (para el usuario o para el comprador). Una
forma muy buena de generar historias valiosas es hacer que el cliente las escriba. Una vez que el
cliente se de cuenta que la historia no es un contrato y es negociable, van a sentirse mucho más
cómodos para escribir historias.
Estimable - los desarrolladores necesitan poder estimar una historia de usuario para permitir que se
pueda priorizar y planificar la historia. 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).
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".
Recordemos que desarrollamos aquello que no podemos probar. Si no podemos probarlo, nunca
vamos a saber si lo terminamos. Un ejemplo de historia no testeable sería: "el software tiene que ser
facil de usar".
CAPÍTULO 3 - MODELADO DE ROLES DE USUARIO

En muchos proyectos, las historias se escriben como si sólo hubiera un tipo

de usuario.
Todos las historias están escritos desde la perspectiva de un único tipo de
usuario.

Esta simplificaciones son un falacia y puede llevar a un equipo a perder

historias para los usuarios que no encajan en el tipo de usuario principal del
sistema.
En este capítulo vamos a ver los roles de usuario, modelos de rol, rol
de usuario mapas y personajes y mostrar cómo tomar estos pasos iniciales
conduce a una mejor mejor
software.
CAPÍTULO 3 - MODELADO DE 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
CAPÍTULO 3 - MODELADO DE ROLES DE USUARIO

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
CAPÍTULO 4 - AGRUPAR HISTORIAS DE USUARIO

¿Cómo reunir las historias?

En este capítulo se ofrece asesoramiento sobre cómo
trabajar con los usuarios con el fin de identificar las
historias en conversaciones con ellos.
En este capítulo se describe métodos eficaces para
conseguir a las necesidades reales de los usuarios;
preguntando a los tipos correctos las preguntas
correctas.
CAPÍTULO 4 - RECOLECTAR HISTORIAS DE USUARIO

Lo términos obtención y captura ni deberían ser

permitidos .
Sin embargo , la metáfora de la pesca para la
captura de requisitos muestra que la habilidad
juega un factor en la búsqueda de los requisitos.
Un experto sabrá dónde buscar los requisitos,
mientras que los no calificados perderán el
tiempo con técnicas ineficientes o en los lugares
equivocados.
En este capítulo se trata de aprender las técnicas
que nos hacen eficientes en la pesca de historias
de usuario.
CAPÍTULO 4 - RECOLECTAR HISTORIAS DE USUARIO

Debido a que las historias estaran evolucionando,

yendo y viniendo todo el proyecto, necesitará un
conjunto de técnicas para la recolección de los
historias .
La técnicas que utilizamos deben ser lo
suficientemente ligeras y no intrusivas de tal manera
que se puede aplicar más o menos de forma
continua.
Algunas de las técnicas más valiosas para la creación
de un conjunto de historias son:
CAPÍTULO 4 - RECOLECTAR HISTORIAS DE USUARIO

Entrevistas de usuario
Entrevistar a los usuarios es el método por defecto de
muchos equipos y es, probablemente el que tendrá que
utilizar.
Una de las claves del éxito de las entrevistas es la
selección de los entrevistados.
Se debe entrevistar a usuarios reales siempre que sea
posible.
También debe entrevistar a los usuarios
que llenan diferentes roles de usuario.
CAPÍTULO 4 - RECOLECTAR HISTORIAS DE USUARIO

Cuestionarios
Los cuestionarios pueden ser una técnica eficaz para la
recopilación de información sobre historias que ya
tienes.
Si usted tiene una gran población de usuarios, un
cuestionario puede ser una gran manera de obtener
información acerca de cómo priorizar las historias.
Los cuestionarios son igualmente útil cuando necesita
respuestas de un gran número
de usuarios a preguntas específicas.
CAPÍTULO 4 - RECOLECTAR HISTORIAS DE USUARIO

Observación
Observando como los usuarios interactúan con el software es
una manera maravillosa de recoger percepciones.
Cada vez que he tenido la oportunidad de observar a alguien
usando mi software, me dan ideas sobre cómo mejorar su
experiencia, productividad, o ambos.
Por desgracia, las oportunidades para la observación de usuario
son raras a menos que usted está desarrollando para los
clientes de la casa.
Si usted tiene la oportunidad de observar a los usuarios
trabajar con el software, hágalo. Esta oportunidad da una
retroalimentación rápida y directa de los usuarios.
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE

Como todos sabemos, no siempre es posible contar con acceso directo a

los usuario o clientes, por lo que se hace indispensable utilizar "proxies"
de los mismos. En este capítulo se señalan bastantes detalles que
debemos tener en cuenta cuando trabajemos con personas que hacen
de enlace del usuario final.
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE

Administrador de Usuarios
Al hacer el desarrollo de un proyecto para el uso interno, la organización
puede ser reacia a darle acceso completo e ilimitado a uno o más usuarios,
pero puede estar dispuesta a darle acceso a la gerente de los usuarios.
A menos que el director sea también un verdadero usuario del software es
casi seguro que el gerente tiene diferentes patrones de uso de software que
los del un usuario .

A veces, gerente de los usuarios intercede y quiere jugar el papel de usuario

en el proyecto debido a su ego.
El puede reconocer que no es una típico usuario, pero insistirá en que sabe
más de lo que sus usuarios necesitan que ellos hacer. Naturalmente, sin
embargo, en este tipo de situación que tendrá que tener cuidado de no
ofender administrador del usuario. Pero usted tiene que encontrar una
manera, ade llegas a los usuarios finales para que el proyecto tenga éxito.
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE
Un Gerente de Desarrollo
Es una de las peores opciones posibles para actuar como un proxy
usuario, a menos que tal vez usted está escribiendo software dirigido a gerentes de
desarrolladores.
Es demasiado probable que el también tendrá algunos objetivos en conflicto.

Por ejemplo, el gerente de desarrollo puede dar prioridad a las historias de manera
diferente que un usuario real, ya que hacerlo le permite acelerar la introducción de
una emocionante, nueva tecnología.
Además, el gerente de desarrollo puede no interesarle los objetivos corporativos: tal
vez su bono anual está ligado a una conclusión
fecha en el proyecto, lo que podría causar que considere el proyecto completo
antes de que un usuario real lo haría..
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE
Vendedores
El peligro en el uso de un vendedor como un proxy del usuario es que no conduce a
una visión integral del producto que se construirá.
La historia más importante para un vendedor suele ser la historia cuya ausencia le
costó la última venta.
Los vendedores son, sin embargo, un gran conducto para los usuarios y debe usarlos
de este modo.
Pídales que presentarles a los clientes, ya sea por teléfono o
acompañelo a lo largo de una visita de ventas
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE
Expertos de dominio
Los expertos del dominio, a veces llamados expertos en la materia, son los recursos críticos por
lo bien que entienden el dominio del software se orientará
Naturalmente algunos dominios son más difíciles de entender que otras.
Yo solía escribir una gran cantidad de software para abogados y asistentes legales, y mientras
que el software era a veces complejo, usualmente podía entender lo que estaban pidiendo.
Mucho más tarde, yo estaba involucrado con la escritura de software para los genetistas
estadísticos.
Este dominio estaba lleno de palabras como fenotipo, centimorgan y haplotipo.
Estas fueron las palabras que nunca había escuchado antes, lo que hizo el dominio mucho
más difícil de entender. Esto hizo que a cada uno de los desarrolladores mucho más
dependientes de un expertos para ayudarnos a entender lo que estábamos desarrollando.
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE
¿Qué hacer cuando se trabaja con un Proxy usuario?
Aunque no es ideal, todavía es posible escribir gran software con un proxy de usuario
en lugar de un usuario real. Hay una serie de técnicas que se pueden aplicar a
aumentar sus posibilidades de éxito en estos casos

Cuando Usuarios existe, pero el acceso es limitado

Si el acceso a los usuarios reales se bloquea y el equipo está en su lugar dijo que trabajar a
través de una
proxy de usuario que va a tomar todas las decisiones del proyecto, el equipo tendrá que
trabajar con
el proxy, sino también establecer una conexión con las manos en los usuarios. Uno de los
mejores
técnicas para hacer esto es pedir permiso para iniciar un grupo de trabajo del usuario.
Cuando realmente hay disponible No User
Cuando no hay realmente disponible para el usuario y debe recurrir a un proxy de usuario,
una
valiosa técnica es usar más de un representante usuario. Esto ayuda a reducir el
posibilidad de construir un sistema que cumple exactamente las necesidades de una
persona. Cuándo
utilizando más de un representante de usuario, asegúrese de usar diferentes tipos de proxy
de usuario.
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE
¿Puede hacerlo usted mismo?
Cuando no se puede encontrar, o conseguir acceso a un usuario real, no caer en la trampa
de
pensando sabes mentes de los usuarios y no necesita o puede ignorar su usuario
proxy. Aunque cada tipo de proxy de usuario tiene algún tipo de deficiencia que hace
la menos deseable que un usuario real, la mayoría de los desarrolladores cuentan con aún
más corto
idas por pretender ser un usuario real. En general, los desarrolladores no tienen
fondos de marketing que les permitan comprender el valor relativo de la característica
ras, que no tienen la misma cantidad de contacto con los clientes como vendedores,
que no son expertos en el dominio, y así sucesivamente.

Constituyendo el equipo cliente

En primer lugar, recuerde siempre que un usuario real late un proxy cualquier momento.
Siempre que sea
lugar sible usuarios reales en el equipo cliente. Sin embargo, cuando no se puede obtener la
combinación adecuada de los usuarios reales, complementar el equipo cliente con uno o
más usuarios
proxies. El equipo cliente debe estar construido de manera que los puntos fuertes de una
miembro de equilibrar las debilidades del otro miembro. Hay cuatro pasos en la creación
Ating un equipo cliente.
CAPÍTULO 5 - TRABAJAR CON LOS USUARIOS ENLACE
En segundo lugar, identificar un solo campeón proyecto o "primero entre iguales" en la
equipo cliente. En las empresas de software comercial que es muy a menudo un producto
gerente, pero podría ser otra persona. Este proyecto se convierte en campeón sabilidad
ponsable de la coordinación de la colaboración del equipo cliente. Todos los miembros de la
Customs
equipo tomer están, en la medida en que se puede lograr, responsable de la entrega de un
mensaje coherente. Si bien puede no ser un cliente, tiene que haber una
la voz del cliente.
En tercer lugar, determinar los factores críticos para el éxito del proyecto. Esto variará de
un proyecto a otro. Por ejemplo, si el proyecto es la creación de una nueva generación versión
de un producto existente, entonces un factor crítico de éxito será la facilidad
los usuarios existentes pueden pasar al nuevo sistema. Complementar el equipo cliente con
proxies de usuario con el correspondiente conocimiento, las habilidades y la experiencia para
hacer frente a la
factores críticos de éxito del proyecto. En nuestro ejemplo de mover los usuarios existentes a
un
nuevo sistema, esto podría significar la adición de un entrenador para el equipo cliente.
Capítulo 6 .

PRUEBAS DE ACEPTACIÓN DE USUARIOS

HISTORIAS DE USUARIO

● Parecidas a los casos de uso, pero más relajadas.

● Son redactadas por el cliente, no por el equipo de

desarrollo.

● Sirven luego para crear las pruebas de aceptación.

● A cada historia se le estima un tiempo.

¿POR QUE?
PORQUE ?

Utilizamos las historias de usuario porque siguen los principios básicos de

requerimientos ágiles:

•Potencian la participación del equipo en la toma de decisiones.

•Se crean y evolucionan a medida que el proyecto avanza.

•Son 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.
¿QUE SON?
QUE SON ?

❏ Una manera Simple de describir una tarea concisa que aporta valor al
usuario o al negocio.

❏ No se detalla más hasta el momento que la historias de usuario se

vaya a desarrollar.

❏ Las historias de usuario pueden ser creadas durante las conversación

con los usuarios interesados (stakeholders) sobre nuevas
funcionalidades o mejoras del proyecto.

❏ La historias de usuario es una invitación a la conversación.

 CREACIÓN DE HISTORIAS DE USUARIO

❏ Tarjeta. Una descripción escrita en lenguaje de

negocio que sirve como identificación y recordatorio
del requerimiento y ayuda para la planificación
mediante la priorización.

❏ Conversación. El diálogo que ocurre entre los

miembros del equipo y el Product Owner para aclarar
los detalles y dudas sobre esa Historia de Usuario
(HU). Es la parte más importante de la historia.

❏ Confirmación. Que pruebas se llevarán a cabo para

poder decir que la HU se ha completado con éxito.
Puede añadirse en la conversación entre el team y el
Product Owner
PRUEBAS DE
ACEPTACION
PRUEBAS DE ACEPTACIÓN
HORNEAR UN PASTEL
PRUEBAS DE ACEPTACIÓN DE USUARIO

❏ Proporcionan criterios básicos que se pueden utilizar para determinar

si una historia se aplica plenamente.

❏ Se utilizan para expresar los detalles que resultan de conversaciones

entre un cliente y un desarrollador.

❏ Son redactadas por el cliente, no por el equipo de desarrollo

❏ Se escriben antes que el programador empiece a codificar.

RESPONSABILIDADES: DESARROLLADOR Vs.
CLIENTE

DESARROLLADOR CLIENTE

Ejecutar la automatización Escribir las pruebas de

de las pruebas de aceptación
aceptación en el equipo de
desarrollo
Saber que hacer con las Verificar que se ejecuten las
pruebas de aceptación pruebas de aceptación
adicionales al inicio del
desarrollo de una nueva
Historia de Usuario
Realizar test unit al código,
pero no es necesario
detallarlas en las pruebas de
aceptación
Capítulo 7 .

DIRECTRICES PARA BUENAS HISTORIAS

DIRECTRICES PARA BUENAS HISTORIAS DE
USUARIO

Son una buena base para escribir, identificar roles, las

pruebas de aceptación y algunas pautas adicionales
para escribir buenas historias. (HU)
DIRECTRICES PARA BUENAS HISTORIAS DE
USUARIO
OBJETIVOS DE LAS HISTORIAS

Identificar los roles de usuario y su interacción con el

software

DIVISIÓN DE LAS PARTES

Dividir en partes las historias de usuario que proporcione

un cierto nivel de funcionalidad.
DIRECTRICES PARA BUENAS HISTORIAS DE
USUARIO

HISTORIAS CERRADAS

Ejemplo: Gestionar anuncios colocados en un sitio web.

Puede ser elaborado como un conjunto de historias cerradas
DIRECTRICES PARA BUENAS HISTORIAS DE
USUARIO

● Una historia cerrada es parte de una historia original que no ha sido

cerrada
● Estas historias deben ser pequeñas para poder ser estimadas,
programadas en una iteración.

RESTRICCIONES DE LA TARJETAS

● No se las estima
● Las prueba de aceptación pueden ser descritas para que las
restricciones se cumplan

Ejemplo: El sitio web para anuncios debe poder soportar 50 usuarios

simultáneamente
DIRECTRICES PARA BUENAS HISTORIAS DE
USUARIO

TAMAÑO DE LA HISTORIA

● Las historias deben ser escritas en tamaños que puedan planificarse en

las respectivas interacciones
● Ejemplo: El sitio web para anuncios

➢ El sitio web puede buscar anuncios de trabajo.

➢ El sitio web puede publicar anuncios de trabajo.

Se debe incluir los roles al escribir una historia de usuario. (En lugar de
pensar, usuarios suaves, sin rostro intercambiables, el desarrollador
comenzará a pensar en usuarios reales)
DIRECTRICES PARA BUENAS HISTORIAS DE
USUARIO

● Las historias generalmente son más legible cuando se escribe para un

solo usuario.

● Las historias de usuario son más fáciles de leer y entender cuando se

escribe en voz activa.

● El cliente tiene la responsabilidad de escribir las historias de usuario,

dar prioridad y lo más importante que éste las entienda.

● No enumerar las historias de usuario

● Identificar los roles que tendrán interacción con el sistema.

● Crear tarjetas de restricción o bien colocarlas en la pared como un

recordatorio
ESTIMACIÓN Y
PLANIFICACIÓN
ESTIMACIÓN DE HISTORIAS DE USUARIO

● Proporciona información útil sobre nuestro progreso y el trabajo

restante.

● Se utiliza para planificar los releases.

● Se reúnen el cliente y el equipo de desarrolladores, se distribuyen

tarjetas en blanco y el cliente selecciona una historia de usuario al azar
y lo lee para todo el equipo.

● Si el equipo pregunta todas las dudas que tengo al cliente, y éste

responde, caso contrario se aplaza la estimación de dicha historia de
usuario.
ESTIMACIÓN DE HISTORIAS DE USUARIO

● Cada desarrollador escribe su respectiva estimación en una tarjetas en

blanco

● Cada desarrollador muestra su respectiva estimación escrita en su

tarjeta y luego se debate con todo el grupo para llegar a un consenso de
la estimación de la historia.
ESTIMACIÓN DE HISTORIAS DE USUARIO

TRIANGULAR: Compara estimaciones

ESTIMACIÓN DE HISTORIAS DE USUARIO

● Al final de la iteración el equipo cuenta los puntos de la historia

completado.
● Estos puntos se utilizan como previsión de cuantos puntos historias se
van a culminar en las próximas historias de la misma longitud.
● La suma de las estimaciones para las tareas no tiene que ser igual a
la estimación de la inicial historia.
● Estimaciones basadas en puntos de historia, estimaciones relativas a
la complejidad, esfuerzo o duración de la historia.
● Triangular una estimación comparándolo con otras estimaciones.
● Sea o no un programas del equipo en parejas no tiene impacto en las
estimaciones puntuales historia. Par de programación afecta a la
velocidad del equipo, no sus estimaciones.
Capítulo 9 .

PLANIFICACIÓN DE UN RELEASE
PLANIFICACIÓN DE UN RELEASE

● Antes de planificar un comunicado que es necesario saber

aproximadamente cuando el cliente desea el release y las prioridades
relativas de las historias.
● Las historias deben ser priorizadas en un orden específico (primero,
segundo, tercero, etc.) en lugar de en grupos (muy alto, alto, medio y
así sucesivamente).
● Las historias son priorizados por el cliente pero con el aporte de los
desarrolladores.
● Las estimaciones, que son en días ideales, se convierten en tiempo de
calendario usando la velocidad.
● A menudo es necesario para estimar la velocidad inicial de un equipo.
Capítulo 10.

PLANIFICACIÓN DE UNA ITERACIÓN

PLANIFICACIÓN DE UNA ITERACIÓN

● Al determinar la velocidad de recuento sólo historias terminados, es

decir, historias que pasan sus pruebas de aceptación. No contar
historias del equipo parcialmente completo durante la iteración.

● Una buena manera de monitorear las diferencias entre la velocidad real

y la prevista en un gráfico tanto el número de puntos de la historia
previstas y las efectivamente completado para cada iteración.

● No trate de predecir las velocidades después de sólo uno o dos

iteraciones.

● El número de horas reales gastadas en completar una tarea o una

historia tiene nobearing de la velocidad.
PLANIFICACIÓN DE UNA ITERACIÓN

● Poner grandes gráficos, visibles en las zonas comunes donde todos

puedan verlos.
● Un gráfico de punto de la historia acumulativa es útil porque muestra
el número total de puntos de la historia completa a través del final de
cada iteración.
● Una carta burndown iteración muestra tanto el progreso en forma de
puntos de la historia completa, así como cambios en el número de
puntos de la historia planificadas para el resto de la liberación.
● Un gráfico de burndown diaria, que muestra las horas que quedan
en cada día de una iteración, es muy útil durante una iteración.
● Gráficos para ver los defectos de un equipo por cada punto de
historias ayuda a indicar si los aumentos de velocidad vienen a
expensas de los defectos
CAP.11 MIDIENDO Y MONITOREANDO LA VELOCIDAD

● El número de puntos de la historia completados en una iteración se

conoce como la velocidad del proyecto.

Medición de Velocidad
Para determinar la velocidad de una historia se debe contar sólo los puntos
de historias completas, es decir no contar historias parcialmente completas
durante la iteración.
CAP.11 MIDIENDO Y MONITOREANDO LA VELOCIDAD

La velocidad no
usa tiempo real

✓ Tenga en cuenta que los cálculos de velocidad se realizan con los

valores de los puntos asignados a las historias antes del comienzo de
la iteración.
Ej. Una historia tiene estimado cuatro puntos para su historia, pero es
mucho más grande. Después del trabajo, el equipo entiende y acepta que
deberían haber estimado siete puntos pero solo se suman 4 y el saldo
queda como indicador para la siguiente vez.
CAP.11 MIDIENDO Y MONITOREANDO LA VELOCIDAD

Velocidad estimada y velocidad real

Una buena forma de verificar si la velocidad real se aparta de la velocidad
planeada es graficar la velocidad prevista y real de cada iteración.
CAP.11 MIDIENDO Y MONITOREANDO LA VELOCIDAD
Gráficos de trabajo pendiente (BURNDOWN)
Una tabla burndown indica visualmente la cantidad de trabajo de tareas que
queda por hacer y el número de puntos de historia aceptados para la
iteración.
PARTE III

TEMAS DISCUTIDOS
FRECUENTEMENTE
Cap.12

¿Qué historias no son?

Cómo las historias de usuario difieren una de otra, enfoques comunes para
requisitos: casos de uso, software IEEE 830 requisitos, especificaciones, y
escenarios de diseño de interacción.
CAP.12 TEMAS DISCUTIDOS FRECUENTEMENTE

Historias del usuario no son IEEE 830

Las recomendaciones de la IEEE incluyen tópicos como organización del
documento de especificación de requerimientos, el rol de los prototipos, y
las características que debe poseer un buen requerimiento.
La mayor característica de esta norma, es el uso de la frase "El sistema
deberá... ", que es la forma recomendada por el IEEE para escribir
requisitos funcionales. Ej.:
➢ El sistema deberá permitir a una empresa a pagar por una oferta de
trabajo con una tarjeta de crédito.
➢ El sistema deberá aceptar Visa, MasterCard y American Express.
➢ El sistema deberá cargar la tarjeta de crédito antes de la tarea anuncio
se coloca en el sitio.
CAP.12 TEMAS DISCUTIDOS FRECUENTEMENTE

documentación de
requerimientos tediosa,
No acepta
propensa a errores y consume
cambios a corto
plazo esfuerzo. !

Los costos
del producto no pueden
calcularse sino hasta
haber finalizado el
documento
CAP.12 TEMAS DISCUTIDOS FRECUENTEMENTE

Las historias de usuario no son casos de uso

✓ Un caso de uso es una descripción general de las interacciones

entre el sistema y uno o más actores, ya sean usuarios o sistemas
externos. Las historias de usuario son más acotadas dado que deben
ser desarrolladas en iteraciones cortas.

✓ Longevidad, CU son artefactos permanentes, las HU no sobreviven

más allá de una iteración.

✓ Objetivos diferentes, los CU quieren llegar a un acuerdo sobre lo

que en él se ha especificado. Las HU se escriben con el propósito
de facilitar la planificación de los releases y servir como
recordatorio de llevar a cabo una serie de conversaciones sobre las
necesidades de negocio
CAP.12 TEMAS DISCUTIDOS FRECUENTEMENTE

• Detallado. • Breve.
• Se implementa en varias • Se implementa en una
iteraciones interacción.
• Lo escribe un analista. • Lo escribe el cliente.
• No se usa para • Se usa para planificar
planificar.
CAP.12 TEMAS DISCUTIDOS FRECUENTEMENTE

Historias de usuarios no son escenarios

Escenario representa el flujo exitoso más
simple o habitual para un caso de uso.
Secuencia de pasos que realiza el actor
principal o el sistema, cada paso se escribe
como una oración sobre una meta que se
cumple

✓ Un entorno
✓ Actores
✓ Metas u objetivos
✓ Acciones y eventos
CAP.13 ¿POR QUÉ HISTORIAS DE USUARIOS?
Comunicación Verbal

Las palabras escritas

no siempre son
precisas

palabras escritas ayudan a

superar limitaciones:
El usuario puede introducir un nombre.
memoria a corto plazo,
Puede ser de 127 caracteres.
distracciones e
¿Puede significa que debe escribirlo
siempre o puede no escribir nada? interrupciones
¿El nombre de la carpeta puede ser de
otra longitud o debe ser siempre de
127? Conversación evita
falsa apariencia de
HU: Escribir una frase corta que precisión y exactitud
recuerde a desarrolladores y clientes
que existe cuando se
futuras conversacione
escribe.
CAP.13 ¿POR QUÉ HISTORIAS DE USUARIOS?
Historias de usuarios son Comprensibles

Ventaja que nos llevan a través de

IEEE 830 para especificaciones de
requisitos de software es que son
comprensibles tanto por los
usuarios y por los desarrolladores.

Las historias son concisas y están escritas para

demostrar el valor para el usuario y son de fácil
comprensión por la gente de negocios y Las historias van más
desarrolladores. lejos y son aún más
comprensibles que los
casos de uso o
escenarios
CAP.13 ¿POR QUÉ HISTORIAS DE USUARIOS?
las historias de usuario son del tamaño
adecuado en la planificación, no
demasiado grande, ni demasiado
pequeño, pero justo

Las historias de usuario funcionan bien

con el desarrollo iterativo, ya que es fácil
de empezar con una historia épica y
después dividirlo en varias historias de
usuarios más pequeños.

HU animan a detallar. HU individuales son

escritos muy rápidamente, y también es
fácil de escribir historias grandes.
CAP.13 ¿POR QUÉ HISTORIAS DE USUARIOS?
El equipo fácilmente accede y se
desplaza entre los niveles altos y bajos
de los detalles, se descubren
oportunidades.

Historias MEJORAN el nivel de

conocimiento tácito en el equipo.

Razones para no usar HU, En grandes proyectos,

puede ser difícil de mantener cientos o miles de
historias organizados; que pueden necesitar ser
aumentada con la documentación complementaria
para la trazabilidad; también las conversaciones
no se adaptan adecuadamente a sustituir por
completo los documentos escritos en grandes
proyectos
CAP.14 HISTORIAS CON MAL OLOR

Indicad
ores de que algo
anda mal.
CAP.14 HISTORIAS CON MAL OLOR

✓ El cliente no escribe las HU

✓ El cliente no da prioridad a las HU
✓ Priorizar es responsabilidad del
desarrollador.
✓ La responsabilidad se comparte para
detectar olores y trabajar para
corregir cosas que afecten al
proyecto.
CAP.15 USANDO HISTORIAS SON SCRUM
CAP.15 USANDO HISTORIAS SON SCRUM
CAP.15 USANDO HISTORIAS SON SCRUM
CAP.15 USANDO HISTORIAS SON SCRUM
CAP.15 USANDO HISTORIAS SON SCRUM
USER STORIES
APPLIED FOR
SOFTWARE
DEVELOPMENT

Benito Vargas Cuellar

CAP.16 TEMAS ADICIONALES

● En este capítulo nos dirigiremos a.

- Manejo de los requisitos no funcionales.

- Si el equipo deben utilizar notas de papel o software.
- El impacto de las historias de usuario en la interfaz
de usuario.
- Si las historias de usuario deben ser retenidos
después de que fueron desarrollados.
- La relación entre los informes de fallos e historias.
Manejo de los Requerimientos No Funcionales

- Rendimiento.
- Precision.
- Portabilidad.
- Reutilización.
- Mantenimiento.
- Interoperabilidad.
- Disponibilidad.
- Usabilidad.
- Seguridad.
- Capacidad.
Papel o Software

- Ni las tarjetas de notas, ni un sistema de software es la mejor manera de

escribir historias de usuario.
- Se debe acordar con el equipo la herramienta con la que se va a trabajar
en el proyecto.

Historias de Usuario y las Interfaces de Usuario

- Un procesos iterativo puede conducir a cambios iterativos en la interfaz de

Usuario.
- Por tanto se debe considerar la adición de algunas prácticas de Diseño
Ágil Centrado en el Uso para evitar la iteración de la interfaz.
Conservando las historias de Usuario

- Se pueden deshechar o resguardar las tarjetas de historias de usuario.

- Errar por el lado seguro y resguardarlos es recomendable.
- En caso de que las historias no se registren el software se recomienda
engrampados para su resguardo.

Historias de Bugs

- Si un error es considerado que tomara el tiempo de un historia tipica, este

se trata como cualquier historia.
- En caso de que el Error se requiere ser resuelto rápidamente el equipo
puede dividir el error en historias más pequeñas.
.
Acerca de los Colores

- Algunos prefieren utilizar distintos colores para las historias. Rojo para los
errores y Azul para las de ingeniería.
- En teoría es buena idea el uso de colores, pero en la práctica no vale la
pena.
- Se recomienda el uso de tarjetas de un solo color, generalmente blancas.

Responsabilidades del Desarrollador

- Es responsable de lo que sugiere y el uso de técnicas alternativas y

métodos para expresar los requisitos cuando sea apropiado.
- Comparte la responsabilidad de decidir lo que es correcto para su
proyecto: nota, tarjetas o un sistema de software.
- Comparte una responsabilidad de comprender las ventajas y desventajas
de considerar la interfaz de usuario en general al comienzo del proyecto.
.
Responsabilidades del Cliente

- Es responsable de solicitar o utilizar técnicas y métodos para expresar los

requisitos.
- Comparte la responsabilidad de decidir lo que es correcto para su
proyecto: nota, tarjetas o un sistema de software.
- Comparte una responsabilidad de comprender las ventajas y desventajas
de considerar la interfaz de usuario en general al comienzo del proyecto.
.
PARTE IV

UN EJEMPLO
Cap.17: LOS ROLES DE LOS USUARIOS
El Proyecto

La empresa Suministros Náuticos de la Costa Sur, vendió suministros de

vela a través catálogo impreso por 30 años. Nuestros catálogos cuentan con
elementos como GPS, relojes, equipos de clima, la navegación y el trazado
de equipos, balsas salvavidas, chalecos inflables, gráficos, mapas y libros.
Hasta ahora nuestra presencia en internet fue un simple sitio en la que
mostramos un número gratuito para que puedan solicitar un catálogo.

Nuestro jefe decidió que finalmente deberíamos empezar a vender nuestros

productos a través de Internet. Sin embargo en lugar de comenzar con la
venta de nuestros artículos, quiere que empezemos vendiendo solo libros
Identificación del Cliente

Los clientes para este producto son los marineros que compran los libros y
todos son externos a la empresa. Por los tanto necesitamos un cliente que
pueda actuar como proxy, para los clientes reales de los usuarios finales.
Para ello el jefe, designa a Lori quien es el vicepresidente de Ventas y
Marketing.
Identificación de algunos roles iniciales.
- Hardcore Sailor.
- Novice Sailor.
- New Sailor
- Gift – Buyer.
- Non – Sailing Spouse.
- Administrator.
- Sales Vice President.
- Charter Captain
- Experiented Sailor
- Sailing School
- Library
- Instructor.
Consolidación y estrechamiento.

Posicionando las tarjetas de roles. Roles luego de la consolidacion y discusión inicial.

Modelado de roles.

- Novice Sailor: comprador web con experiencia.

- Instructor: se espera que utilice el sitio con frecuencia. Como una vez por
semana al menos
- Hard Core Marinero: Generalmente con experiencia en la computadoras.
Gran comprador de libros.
- Experiented Sailor: capaz con las computadoras. Se espera que solicite
una o dos veces por trimestre.
- Non-Sailing Gift Buyer: No es marinero.
- Librarian: sabe exactamente lo que busca y prefiere ordenar por ISBN.
- Administrator:Muy habil en las computadoras. Accede al back-end del
sistema como parte de su trabajo diario.
- Visor de Informes: Aptitud moderada con las computadoras. Prefiere
programas de negocios, hojas de calculo.
Adicionando personas.

- A veces es necesario añadir a más personas en el sistema.

- En este caso es debatible si vale la pena o no añadir más personas.
- Pero con con el fin de proporcionar un ejemplo más completo se añadirán
a Teresa y el Capitán Ron.
Cap. 18: LAS HISTORIAS.
Historias de Teresa.

- Un usuario puede buscar libros por autor, título o número ISBN.

- Un usuario puede ver información detallada de un libro. Por
ejemplo,número de páginas, fecha de publicación y una breve descripción.
- Un usuario puede poner libros a un “carrito de compras” y comprarlos
cuando se realiza la compra.
- Un usuario puede eliminar libros de su compra antes de completar la orden
- Para comprar un libro que el usuario introduzca su dirección de
facturación, los gastos de envío e información de la tarjeta de crédito.
Historias de Teresa.

Las historias de Lori a partir de las historias de Teresa.

- Un usuario puede calificar y comentar libros.

- Un usuario puede establecer una cuenta que se recuerde el envio de
información de facturación.
- Un usuario puede editar su información de cuenta (tarjeta de crédito,
dirección de envio, dirección de facturación y así sucesivamente).
- Un usuario puede poner los libros en una “lista de deseos” que es visible
para otros visitantes del sitio.
- Un usuario puede colocar un elemento de una lista de deseos(incluso de
otra persona) en su cesta de compra.
- Un cliente habitual debe ser capaz de buscar un libro y completar una
orden en menos de 90 segundos. (restricción)
Historias del Capitán Ron.
- Un usuario puede ver una historia de todos sus órdenes anteriores.
- Un usuario puede volver a comprar fácilmente los elementos al ver los
pedidos anteriores.
- El sitio muestra siempre los 3 ultimos articulos que haya visto un
comprador y proporciona los enlaces a estos (esto funciona incluso entre
sesiones anteriores).
- Un usuario puede ver los libros que recomendamos en una variedad de
temas.
Historias de un Non-Sailing Gift Buyer.

- Un usuario, especialmente un comprador Non-Sailing Gift buyer, puede

encontrar fácilmente las listas de deseos de otros usuarios.
- Un usuario puede elegir items de regalo.
- Un usuario puede optar por incluir una tarjeta de regalo y puede escribir su
propio mensaje para la tarjeta.
Historias de un Report Viewer.

- Un visor de informes puede ver los informes de compras diarias

desglosados por categoría de libros, tráfico, mejores y peores libros
vendidos.
- Un usuario debe estar autenticado correctamente antes de ver informes.
- Los pedidos realizados en el sitio web tienen que terminar en el mismo
orden de base de datos como los pedidos telefónicos (restricción)
Historias del Administrador.
- Un administrador puede agregar nuevos libros al sitio.
- Un administrador debe aprobar o rechazar las críticas antes que estén
disponibles en el sitio.
- Un administrador puede borrar un libro.
- Un administrador puede editar la información acerca de un libro existente.

Ajustar hacia arriba.

Los desarrolladores preguntan si no hay mas historias y ella aporta con las
siguientes:
- Un usuario puede comprobar el estado de sus pedidos recientes. Si un
pedido no fue enviado, se puede agregar o quitar libros, cambiar el metodo
de envio, la dirección de entrega y la tarjeta de crédito.
- El sistema debe soportar el uso hasta un máximo de 50 usuarios
concurrentes (restricción).
Capt. 19 ESTIMACIÓN DE LAS HISTORIAS.
Estimation de las Historias.
Las historias de usuario escrito en el taller fueron 27 historias.
- El próximo objetivo es crear un plan de lanzamiento que mostrará Lori al
cliente lo que los desarrolladores esperan lograr y si el sitio puede ser
- operativo dentro del plazo de treinta días.
- Con el fin de crear el plan de liberación se necesita una estimación para
cada historia.

La Primera Historia.
No es necesario iniciar con la primera historia de la lista, pero en este caso
es una buena opción empezar con esta.
- Para estimar las historias tres programadores Rafe, Jay y Maria estiman la
1ra historia con Lori, cada uno tiene su estimación en la primera iteración:
Rafe=1, Jay= ½, Maria=2.
- Luego discuten sus estimaciones, luego realizan la estimación nuevamente
con los resultados siguientes: Rafe=1, Jay=1 y Maria=1.
Cap. 20 EL PLAN DE LANZAMIENTO
Plan de Lanzamiento.
- Seleccionar la longitud de la iteración.
- Estimar la velocidad.
- Priorizar las historias.
- Asignar historias a una o más iteraciones.

Estimando la Velocidad
- Maria y Rafe son desarrolladores del proyecto, Jay ayuda a estimar pero
otros compromisos le impiden ayudar al desarrollo.
- Cuando se estiman historias, deciden el tiempo que les llevará entre dos y
tres días reales de hacer, un dia seria lo ideal.
- Con dos semanas (10 días) de iteraciones y dos desarrolladores, habrá 20
programas por iteración. Maria y Rafe estima que van a ser capaces de
completar entre siete y diez puntos de la historia durante cada iteración.
- La decision de ser conservador para la primera iteración, estiman a una
velocidad de 8.
 Priorizando las Historias

. - Lori prioriza las historias. El principal factor en determinación de la

prioridad en una historia es el valor que se entregará a la empresa.
- Para priorizar los ordena en 4 pilas en función a su importancia.
- Tiene, Debe tener, Deberia tener, Podria tener, y no tendrá.
Priorizando las Historias
.
 Priorizando las Historias
.
 El Plan de lanzamiento final
- Es la que se comunica al resto de la organización.
El Plan de lanzamiento final
.
Cap. 21 PRUEBAS DE ACEPTACIÓN.
El Plan de Aceptación.
.
- Las pruebas de aceptación de una historia se utilizan pàra determinar si la
historia está completa hasta el punto donde el cliente puede aceptar.
- El cliente tendrá la ayuda de un tester.
Pruebas de la busqueda.
- Un usuario puede hacer una búsqueda básica simple que busca una
palabra o fras en ambos campos de autor y título.
- Un usuario puede buscar por libros ingresando valores de cualquier
combinación de autor, título y ISBN.

Pruebas de Carrito de Compras.

- Un usuario puede adicionar libros al carrito y realizar la compra.

- Un usuario puede eliminar libros de su carrito antes de completar la orden.
- Un usuario puede ajustar la cantidad de cualquier artículo en su carrito.
Cuando la cantidad llega a 0 elimina el item de la compra.
Compra de Libros.

- Para comprar un libro los usuario ingresan su direccion de facturacion, la

direccion de envio y la información de la tarjeta de crédito.
Administracion.
- Un administrador puede adicionar nuevos libros al sitio.
- Un administrador puede eliminar un libro.
- Un administrador puede editar la información de libros existentes.

Pruebas de Restricciones.
.
- Los pedidos realizados en el sitio web tienen que terminar en la misma
base de datos que los pedidos por telefono.
- El sistema debe ser compatible con el uso máximo de hasta 50 usuarios
concurrentes. Simular con con 50 usuarios realizando varias búsquedas y
tomando ordenes. Asegurarse que la pantalla no toma más de 4 segundos
en mostrarse sino la orden se pierde.
GRACIAS...