Historias de usuario: ¿Qué son y con qué se comen?


Si eres nuevo en el mundo ágil y quieres conocer sobre los “requerimientos ágiles” esto te interesará…

Para entender qué es una historia de usuario, debemos conocer primeramente quién es y qué hace un product owner.

Un product owner es uno de los principales roles dentro de scrum. Es quien determina qué requerimientos (historias de usuario) se deberán codificar para agregar valor al producto de software que se desarrolla.

Ahora bien, la creación de la historia de usuario es una técnica dentro del framework ágil que permite a los product owners definir tareas ejecutables por un equipo de desarrollo de manera que éstas sean claras y tangibles. Nos ayudan a entender las necesidades del usuario final desde una perspectiva relacionable, facilitando su codificación. 

La historia de usuario más sencilla es aquella que está conformada por la siguiente estructura:

Nos ayuda a identificar dos temas primordialmente:

  1. El actor: la persona o “usuario” que tiene una necesidad a cumplir con el sistema que el equipo de desarrollo está creando de manera iterativa.
  2. La necesidad o deseo: la actividad que dicho usuario desea realizar.

Adicional a estos dos puntos principales, la historia de usuario puede opcionalmente incluir un motivo, un lugar o incluso un tiempo. Por ejemplo:

En este ejemplo, aunque es un poco sencillo, el actor está identificado como el “usuario final”, su necesidad es reflejada por la frase “me gustaría seguir a mis artistas favoritos”, y la información adicional que completa la idea es provista por la frase “para saber cuándo se irán de gira”. 

Cabe mencionar que la información adicional no todos los product owners la incluyen, pero ayuda a englobar la idea de manera más clara para que los desarrolladores trabajen esa historia de usuario como tarea en la ejecución de algún sprint.

Otra parte importante de las historias de usuario son los criterios de aceptación, los cuales ayudan a entender el funcionamiento del producto, y definen qué condiciones se deben cumplir para satisfacer las necesidades del actor. Una vez que cumplamos con todos los criterios de aceptación sabremos que hemos terminado esa historia de usuario.

Existen diferentes técnicas para definir criterios de aceptación, desde un checklist, o una lista numerada, hasta la sintaxis Gherkin (el famoso Given… When… Then… ). Esto dependerá en su mayoría del estilo de trabajo de cada product owner.

Ahora que conocemos qué es una historia de usuario y cómo se construye, te dejamos unos tips que te serán de mucha ayuda…

Tips que no debes olvidar a la hora de redactar historias de usuario.

  • Es importante conocer y entender las reglas de negocio al momento de crear historias de usuario.
  • Recuerda que si una historia de usuario no contiene la estructura “Como <actor>, me gustaría <necesidad> para justificación>” y no cuenta con criterios de aceptación, NO ES UNA HISTORIA DE USUARIO.
  • La historia de usuario debe evitar dependencias fuertes con otras historias de usuario.
  • Procura evitar ambigüedades en su redacción, de lo contrario podrías causar confusión en los desarrolladores y ocasionar retrabajo.
  • Recuerda que no es para cumplir un requerimiento laboral, es para que los desarrolladores entiendan qué es lo que se debe de hacer.
  • No olvides que al definir criterios de aceptación debes tomar en cuenta que estos deben ser:
    • S: Specific (específicos)
    • M: Measurable (medibles)
    • A: Achievable (alcanzables)
    • R: Relevant (relevantes)
    • T: Time-boxed (limitados en tiempo)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: