Cómo escribir historias de usuarios: una guía completa

Las historias de usuarios son una parte vital del desarrollo de software ágil adecuado: veamos su función y aprendamos a escribir historias de usuarios.

Los marcos ágiles son una forma popular y efectiva de estructurar el desarrollo de software y delegar tareas. Escribir historias de usuarios (que no debe confundirse con cómo escribir un testimonio) es una herramienta en el desarrollo ágil que permite a los desarrolladores comprender qué se debe hacer y cómo cumplir con un requisito. Eso los convierte en un punto de partida muy importante, pero también significa que deben construirse con cuidado. Esto es lo que debe saber.

¿Qué es una historia de usuario?

Es un término utilizado en el desarrollo de software dentro de un marco ágil. La historia de usuario generalmente se considera la unidad más pequeña en el proyecto ágil o el primer paso para cumplir con un requisito. Se crean cuando un proyecto está totalmente planificado.

¿Entonces que significa eso exactamente? Cada función de software tiene (o debería tener) un propósito particular cuando se agrega a un proyecto. Ese propósito debe influir en todo su desarrollo y en cómo se incorpora al marco general. Los desarrolladores pueden hacer referencia a este propósito siempre que sea necesario para tomar decisiones, especialmente sobre cómo desglosar los objetivos y qué priorizar. La "historia de usuario" es simplemente una forma de describir el propósito de una función.

Las historias de usuario se escriben desde la perspectiva de un usuario, generalmente en solo una oración o dos. Capturan el punto de vista del usuario y lo que ese usuario quiere hacer. Cuando se completan, las buenas historias de usuarios son una manera fácil de hablar sobre objetivos estratégicos, qué características se pueden descartar de manera segura o se deben agregar, y mucho más.

Cómo escribir una historia de usuario

Paso 1. Obtener entrada

Obtenga información de propietarios, posibles usuarios y gerentes de proyectos. Una historia de usuario sólida necesita mucha información para ser precisa. Obtenga explicaciones claras de estos grupos sobre lo que quieren hacer. Recuerde, esto no debe traducirse directamente en la historia del usuario, pero proporcionará la información necesaria. Un propietario podría decir: "Necesito que la gente pueda pagar con PayPal en mi aplicación", lo cual es muy útil, pero no la historia del usuario en sí.

Paso 2. Decide cómo se crean las historias de usuario

Esto depende de su flujo de trabajo. En las primeras etapas, las historias de los usuarios se capturan en fichas o notas adhesivas mientras se planifica el marco general. Posteriormente, se incorporan al software de gestión de proyectos. Algunos miembros del equipo se saltan la etapa de la nota adhesiva, mientras que otros confían en ella, lo que funcione para usted.

Paso 3. Definir, Definir, Definir

Definir el usuario: con la entrada, ahora puede definir el usuario. Tenga en cuenta que este no siempre es el usuario final de las características del producto; puede variar según el tipo de usuario. Cree personajes de usuario si es necesario. Defina la acción que está realizando el usuario y defina el objetivo del usuario al realizar esta acción. Incluya esta información clave cuando elabore su historia de usuario para dirigirse a su público objetivo.

Paso 4. Escribe la historia

Comience a escribir su historia de usuario, solo debe tener una oración o dos para mantener la atención del lector. Es tentador ser preciso y técnico aquí, pero un lenguaje amplio, como declaraciones de misión, puede ser útil. Aclare la historia y asegúrese de que se pueda resolver o completar, de modo que pueda mirar hacia atrás y confirmar: "¡Sí, los usuarios ahora pueden hacer esto!".

Paso 5. Dividir en pasos adicionales

Las historias de usuario pueden necesitar varios pasos para alcanzar el objetivo final, lo que podría requerir un poco de reestructuración según el marco ágil que esté utilizando. Recuerde, la historia de usuario es siempre la unidad más pequeña en el marco. En este nivel granular, las historias de usuario deberían tardar varios días en implementarse.

Si parece que tomarán mucho más tiempo, es una señal para revisar y ver si la experiencia del usuario debe dividirse más y reestructurarse. Si se agregan nuevos requisitos, también deberán dividirse en historias de usuario. Si bien estas pocas oraciones son el núcleo de las historias de usuario efectivas, también se pueden expandir a medida que avanza el desarrollo. Echemos un vistazo más de cerca a eso.

¿Cuáles son las 3 C en las historias de usuario?

Tarjeta : la fase Tarjeta se refiere a escribir historias de usuario para el equipo de desarrollo en una o dos oraciones. Se llama tarjeta porque las historias de usuario se escribieron originalmente en fichas y muchos equipos aún prefieren hacerlo de esa manera. La Tarjeta es el núcleo de su requisito de software específico y el punto de partida para todas las discusiones. También es fácil verificar si su historia de usuario es demasiado larga: si no cabe en una ficha que todos puedan leer, debe acortarse.

Conversación : una vez que se han creado las oraciones de la tarjeta, es hora de trabajar en los detalles. Esto generalmente comienza como una serie de preguntas entre los desarrolladores, como "¿Cuánto tiempo llevará implementar esto?" o “¿Cómo podemos incorporar esta acción?” o "¿Esta historia de usuario es esencial aquí?" Etcétera.

Es probable que este examen minucioso de la historia del usuario genere preguntas adicionales para los gerentes de proyecto y los propietarios de productos, quienes deben participar en la conversación según sea necesario. A medida que continúa la conversación, las historias de los usuarios se pueden cambiar, refinar, fusionar o eliminar hasta que todos estén en la misma página. A medida que se finalizan las historias de usuario, se trasladan a la implementación, una señal de que la conversación prácticamente ha terminado.

Confirmación : la confirmación tiene que ver con las pruebas de aceptación, también conocidas como criterios de aceptación. Una vez que se ha implementado el cambio y los desarrolladores informan que está listo, que la historia del usuario se ha cumplido, es hora de probarlo.

Las pruebas de aceptación deben crearse con la entrada del propietario del producto y vincularse directamente a la historia del usuario. En el mejor de los casos, es un usuario que simplemente intenta hacer lo que indica la historia del usuario y ve si puede hacerlo. Pero las pruebas de aceptación pueden variar y no siempre se realizan teniendo en cuenta las historias de los usuarios, como debería ser. Si esto crea un problema, es hora de volver al paso Conversación hasta que las pruebas de aceptación y las historias de usuario estén correctamente alineadas. Si se completan todas las pruebas de aceptación, la historia de usuario está encantada. Ahora es el momento de pasar al siguiente paso en el desarrollo del producto o lanzar la función.

¿Un cuarto C? : Curiosamente, algunos argumentan que hay un 4º C: Contexto esencial. En este caso, la historia de usuario se ve junto con las otras historias de usuario en el marco más amplio del proyecto. Aquí, los desarrolladores preguntan si la historia de usuario complementa otras historias de usuario sin problemas o si hay lagunas, cosas que el usuario debe hacer o comprender que se han perdido entre las historias de usuario.

Idealmente, esto se detecta durante la fase de conversación, pero eso no siempre sucede. Algunos equipos de desarrollo pueden querer una revisión final de cómo la historia de usuario completa encaja en el todo mayor y si es necesario realizar algún trabajo adicional.

¿Qué es un buen formato para una historia de usuario?

Repasemos dos técnicas de formato que son muy útiles al crear oraciones de historias de usuario. El primero es muy simple: "¿Quién, qué y por qué?" En una plantilla de oración, eso se puede describir así:

Como [Quién es el usuario], quiero [Lo que el usuario quiere] (para que [Por qué lo quiere el usuario]).

Esta plantilla también se puede enmarcar como: "Como [rol], quiero [acción], (para que [beneficio])", para simplificar la terminología. Seguir este formato básico es suficiente para crear la mayoría de las historias de usuarios. Por lo general, es todo lo que necesita y puede ayudarlo a ahorrar mucho tiempo cuando se usa para cada historia de usuario.

A veces, sin embargo, las historias de usuario son más difíciles de definir en proyectos más complejos. En este caso, una segunda técnica de plantilla de historia de usuario puede ser útil. Se llama INVEST, un acrónimo que significa:

• Independiente : las historias deben ser completamente independientes entre sí y, como resultado, las historias deben poder trabajarse fuera de secuencia.
• Negociable : las historias deben diseñarse para modificarse durante la parte de conversación del proceso.
• Valioso : la historia de usuario debe demostrar un valor claro para el proyecto. Si no puede, puede ser un desperdicio de recursos.
• Estimable : una historia de usuario debe medirse en valor y priorización para ayudar a decidir en qué trabajar en orden de importancia.
• Pequeño : las historias de usuario deben ser la unidad de funcionalidad más pequeña y, de lo contrario, deben desglosarse aún más.
• Comprobable : la historia de usuario debe declararse de forma comprobable durante el proceso de confirmación.

Preguntas frecuentes sobre cómo escribir historias de usuario

También te puede interesar nuestra guía sobre cómo escribir una reseña de un juego.