Suscríbete a DeepL Pro para poder editar este documento.

Entra en www.DeepL.com/pro para más información.

¿Qué es una historia de usuario?

Una historia de usuario describe la funcionalidad que será valiosa para el usuario o el comprador de
un sistema o software. Las historias de usuario se componen de tres aspectos:

- una descripción escrita de la historia utilizada para la planificación y como recordatorio

- conversaciones sobre la historia que sirven para concretar los detalles de la historia

- pruebas que transmiten y documentan los detalles y que pueden utilizarse para determinar cuándo
una historia está completa

Las tarjetas "representan los requisitos del cliente en lugar de documentarlos".

Las historias de usuarios representan una funcionalidad que será valorada por los usuarios,

¿Dónde están los detalles?

¿Qué valores pueden buscar los usuarios? ¿Estado? ¿Ciudad? ¿Título del trabajo? ¿Palabras clave?

- ¿El usuario tiene que ser miembro del sitio?

- ¿Se pueden guardar los parámetros de búsqueda?

Muchos de estos detalles pueden expresarse como historias adicionales. De hecho, es mejor tener
más historias que tener historias demasiado grandes.

pero como punto de partida es bueno tener historias que puedan ser codificadas y probadas entre
medio día y quizás dos semanas por uno o un par de programadores.

Cuando una historia es demasiado grande, a veces se le llama épica. Las epopeyas pueden dividirse
en dos o más historias de menor tamaño.

Sin embargo, la conversación es la clave, no la nota en la tarjeta de la historia. Ni los desarrolladores

ni el cliente pueden señalar la tarjeta tres meses después y decir, "Pero, mira lo que dije allí." Las
historias no son obligaciones contractuales.

"¿Cuánto tiempo tiene que ser?"

Si usas tarjetas de papel, puedes darle la vuelta a la tarjeta y capturar estas expectativas allí. Las
expectativas se escriben como recordatorios de cómo probar la historia

Las descripciones de la prueba están pensadas para ser cortas e incompletas. Las pruebas pueden
ser añadidas o quitadas en cualquier momento. El objetivo es transmitir información adicional sobre
la historia para que los desarrolladores sepan cuando están terminadas.

El equipo del cliente

En un proyecto ideal tendríamos una sola persona que priorice el trabajo para los desarrolladores,
responda omniscientemente a sus preguntas, use el software cuando esté terminado y escriba todas
las historias. Esto es casi siempre demasiado para esperar, así que establecemos un equipo de
clientes.

El equipo del cliente incluye a aquellos que aseguran que el software cumplirá con las necesidades
de los usuarios a los que está destinado. Esto significa que el equipo del cliente puede incluir
probadores, un gerente de producto, usuarios reales y diseñadores de interacción.

¿Cómo será el proceso?

Un proyecto que utiliza historias tendrá un sentido y un ritmo diferente al que usted puede estar
acostumbrado. El uso de un proceso tradicional orientado a las cascadas lleva a un ciclo de escribir
todos los requisitos, analizar los requisitos, diseñar una solución, codificar la solución, y finalmente
probarla. Muy a menudo, durante este tipo de proceso, los clientes y usuarios participan al principio
para escribir los requisitos y al final para aceptar el software, pero la participación de los usuarios y
clientes puede desaparecer casi por completo entre los requisitos y la aceptación.

Lo primero que se nota en un proyecto basado en una historia es que los clientes y los usuarios
permanecen involucrados durante toda la duración del proyecto. No se espera (¡o se permite!) que
desaparezcan durante la mitad del proyecto.

Los clientes y los usuarios previstos del nuevo software deberían planear tomar un papel muy activo
en la redacción de las historias de los usuarios

Las historias iniciales de un proyecto suelen escribirse en un taller de escritura de historias, pero las
historias pueden escribirse en cualquier momento a lo largo del proyecto.

todo el mundo hace una lluvia de ideas con tantas historias como sea posible. Armados con un
conjunto inicial de historias, los desarrolladores estiman el tamaño de cada una.

En colaboración, el equipo del cliente y los desarrolladores seleccionan una duración de la iteración,
de quizás una a cuatro semanas. Se utilizará la misma duración de iteración para la duración del
proyecto. Al final de cada iteración los desarrolladores serán responsables de entregar código
totalmente utilizable para algún subconjunto de la aplicación.

El equipo del cliente se mantiene muy involucrado durante la iteración, hablando con los
desarrolladores sobre las historias que se desarrollan durante esa iteración. Durante la iteración el
equipo del cliente también especifica las pruebas y trabaja con los desarrolladores para automatizar
y ejecutar las pruebas. Además, el equipo del cliente se asegura de que el proyecto esté en
constante movimiento hacia la entrega del producto deseado.

Una vez seleccionada la duración de la iteración, los desarrolladores estimarán cuánto trabajo
podrán hacer por iteración.

Para planear un lanzamiento, clasificamos las historias en varios montones, cada uno de los cuales
representa una iteración. Cada pila contendrá un cierto número de historias, cuyas estimaciones no
superan la velocidad estimada. Las historias de mayor prioridad van en el primer montón. Cuando
ese montón está lleno, las siguientes historias de mayor prioridad pasan a un segundo montón (que
representa la segunda iteración). Esto continúa hasta que se han hecho tantos montones que no se
tiene tiempo para el proyecto o hasta que los montones representan una nueva versión deseable del
producto.

Antes del comienzo de cada iteración el equipo del cliente puede hacer correcciones a mitad de
curso del plan. A medida que se completan las iteraciones, aprendemos la velocidad real del equipo
de desarrollo y podemos trabajar con ella en lugar de la velocidad estimada. Esto significa que cada
pila de historias puede necesitar ser ajustada añadiendo o quitando historias. Además, algunas
historias resultarán ser mucho más fáciles de lo previsto, lo que significa que el equipo a veces
querrá que se le dé una historia adicional para hacer en esa iteración. Pero algunas historias serán
más difíciles de lo previsto.

¿Por qué el cliente escribe las historias?

El equipo del cliente, más que los desarrolladores, escribe las historias de los usuarios por dos
razones principales. En primer lugar, cada historia debe ser escrita en el lenguaje de la empresa, no
en la jerga técnica, para que el equipo del cliente pueda priorizar las historias para incluirlas en las
iteraciones y lanzamientos. Segundo, como los principales visionarios del producto, el equipo del
cliente está en la mejor posición para describir el comportamiento del producto.

Planificación de liberaciones e iteraciones

Una liberación se compone de una o más iteraciones. La planificación de la liberación se refiere a

disuadir la extracción de un equilibrio entre una línea de tiempo proyectada y un conjunto de
funciones deseadas. La planificación de la iteración se refiere a la selección de historias para su
inclusión en esta iteración. El equipo del cliente y los desarrolladores están involucrados en la
planificación de la liberación y la iteración.

Para planear un lanzamiento, el equipo del cliente empieza por priorizar las historias. Mientras
priorizan querrán considerar:

- La conveniencia de la característica para una amplia base de usuarios o clientes

- La conveniencia de la característica para un pequeño número de usuarios o clientes importantes

Los desarrolladores tienen diferentes prioridades para muchas de las historias. Pueden sugerir que
se cambie la prioridad de un relato en función de su riesgo técnico o porque es complementario de
otro relato. El equipo del cliente escucha sus opiniones pero luego prioriza las historias de manera
que se maximice el valor entregado a la organización. Las historias no pueden ser priorizadas sin
considerar sus costos.

El costo de una historia es la estimación que le dan los desarrolladores. A cada historia se le asigna
una estimación en puntos de historia, que indica el tamaño y la complejidad de la historia en
relación con otras historias. Así pues, se espera que un relato estimado en cuatro puntos de historia
dure el doble que un relato estimado en dos puntos de historia.

El plan de liberación se construye asignando historias a las iteraciones en la liberación. Los

desarrolladores declaran su velocidad esperada, que es el número de puntos de historia que creen
que completarán por cada iteración. El cliente entonces asigna historias a las iteraciones,
asegurándose de que el número de puntos de historia asignados a cualquier iteración no exceda la
velocidad esperada del equipo.

¿Qué son las pruebas de aceptación?

Las pruebas de aceptación son el proceso de verificar que las historias se desarrollaron de tal
manera que cada una funciona exactamente como el equipo del cliente esperaba que funcionara.
Una vez que comienza una iteración, los desarrolladores empiezan a codificar y el equipo del cliente
empieza a especificar pruebas. Esto puede significar cualquier cosa, desde escribir pruebas en el
reverso de la tarjeta de la historia hasta poner las pruebas en una herramienta de pruebas
automatizada.

Las pruebas deben ser escritas tan pronto como sea posible en una iteración. Escribir las pruebas
temprano es extremadamente útil porque más de las suposiciones y expectativas del equipo del
cliente se comunican antes a los desarrolladores

¿Por qué cambiar? (Con respecto al enfoque tradicional)

algunas de las razones son:

- Las historias de los usuarios hacen hincapié en la comunicación verbal más que en la escrita.

- Las historias de los usuarios son comprensibles tanto para usted como para los desarrolladores.

- Las historias de usuarios tienen el tamaño adecuado para la planificación.

- Las historias de usuarios funcionan para el desarrollo iterativo.

Debido a que las historias de los usuarios cambian el énfasis hacia el habla y se alejan de la escritura,
las decisiones importantes no quedan plasmadas en documentos que es poco probable que se lean.
En cambio, los aspectos importantes de las historias se capturan en pruebas de aceptación
automatizadas y se ejecutan con frecuencia

Cada historia de usuario representa una pieza discreta de funcionalidad, es decir, algo que un
usuario probablemente haría en un solo escenario. Esto hace que las historias de usuarios sean
apropiadas como herramienta de planificación. Un proceso iterativo es aquel que avanza a través de
refinamientos sucesivos.

Con cada iteración, el software se mejora mediante la adición de más detalles. Las historias
funcionan bien para el desarrollo iterativo porque también es posible iterar sobre las historias