Historias de usuarios

Historias de usuarios: Qué son, por qué y cómo utilizarlas

Así que. Historias de usuarios.

Conoce las historias. Ha crecido con ellas. Como todos nosotros. Las historias y la narración tienen un largo historial en la historia de la humanidad.

¿Pero las historias de usuario? ¿De qué se trata?

Bueno, vamos a echar un vistazo más de cerca a ellas. Qué son, y por qué y cómo se utilizan en el desarrollo ágil.

Kanban Development Board

¿Qué es una historia de usuario?

En Agile, una historia de usuario es una descripción breve, informal y en lenguaje sencillo de lo que un usuario quiere hacer dentro de un producto de software para obtener algo que le resulte valioso.

Las historias de usuario suelen seguir el patrón (o plantilla) rol-función-beneficio:

  • Como [tipo de usuario],
  • quiero [una acción]
  • para que [un beneficio/valor]

Como unidad de trabajo más pequeña en un entorno ágil, las historias de usuario son una herramienta clave en el  desarrollo incremental.

¿Por qué utilizar historias de usuarios? ¿Cuáles son sus beneficios?

Con las historias de usuario se pone a los usuarios en el centro de la conversación sobre lo que hay que añadir o cambiar en un producto de software. Son la encarnación del primer principio del Manifiesto Ágil (el énfasis es mío):

Agile Principles

Con las historias de usuario se da al equipo de desarrollo el contexto y el porqué de lo que están creando. Esto les ayuda a entender cómo están aportando valor a la empresa y a mantener al usuario/cliente como prioridad.

Las historias de usuario proporcionan la esencia necesaria para priorizarlas.

No es necesario añadir detalles como los requisitos hasta que se decida que es el momento de ponerlos en práctica. Aparte quizás de lo que Mike Cohn llama condiciones de satisfacción con las que un usuario puede ampliar y explicar conceptos. Se añaden otros detalles a medida que se acerca el momento de implementar la historia. Por ejemplo, durante la fase de exploración en el  Desarrollo Dirigido por el Comportamiento (BDD).

La brevedad te permite cambiar de opinión hasta el último momento posible (responsable) sin tirar mucho esfuerzo. Esto te ayuda con el segundo principio del Manifiesto Ágil:

«Acoge los requisitos cambiantes, incluso en las últimas fases del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente».

La naturaleza concisa y el enfoque en el usuario de las historias de usuario también ayuda a separar quién se ocupa de lo que vas a hacer (el cliente o el gestor de productos) y quién se ocupa de cómo lo vas a hacer (los desarrolladores).

Y, por último, como las historias de usuario son pequeñas unidades de trabajo autónomas, disfrutarás de muchas pequeñas victorias a medida que vayas completando una tras otra. Eso es bueno para coger impulso.

¿Cómo no beneficiarse de las historias de usuario – Errores comunes?

user story

Los errores más comunes y clásicos al trabajar con historias de usuario son:

  • Partir de un documento de requisitos creado de forma no ágil y acabar con historias artificiales.
  • Añadir detalles y requisitos demasiado pronto. Las historias que están a punto de ser implementadas necesitan el mayor nivel de detalle y claridad. Las historias a punto de ser implementadas pueden hacerlo con menos. Y las historias a más de 2 o 3 iteraciones no necesitan ninguno.
  • No tener una conversación sobre la historia con todos los implicados, clientes, usuarios, desarrolladores, probadores, profesionales de la empresa, antes de empezar la implementación. Esta conversación es esencial para añadir de forma colaborativa los detalles, los criterios de aceptación, que evitarán la repetición del trabajo.

¿Qué es una buena historia de usuario?

Ya en 2003 Bill Wake introdujo el INVEST para ayudarle a recordar las características de una buena historia de usuario:

  • Independientes. Desea que las historias de usuario sean independientes entre sí para poder moverlas libremente por el backlog del producto a medida que cambian las prioridades.
  • Negociables. Los detalles de una historia de usuario se establecen en colaboración entre el cliente y el equipo que la implementará. Esta colaboración incluye la negociación del alcance: qué incluirá y qué no incluirá la implementación.
  • Valiosa. Una buena historia de usuario tiene valor para el cliente (que puede ser un usuario interno). Sin ese valor, no tiene sentido dedicar ningún esfuerzo a la historia.
  • Estimable. Si no puede estimar una historia, significa que aún no entiende el alcance lo suficientemente bien, o que el alcance es demasiado grande para estimarlo fácilmente. No necesita estimaciones exactas, pero cuando puedes estimar una historia también es más negociable. Además, podrás diferenciar entre las historias valiosas de bajo esfuerzo y las no tan valiosas de alto esfuerzo.
  • Pequeño. El esfuerzo para implementar una historia de usuario debe ser pequeño. Como máximo, unas pocas semanas (por una persona), aunque muchos equipos utilizan «unos pocos días» como límite. Las historias pequeñas son más fáciles de estimar. Las historias grandes son más difíciles de estimar y, por tanto, menos negociables.
  • Comprobables. Si su cliente, en colaboración con el equipo de ejecución y con la ayuda de éste, no puede decirle cómo verificar que ha implementado lo que quiere, todavía no ha creado suficiente claridad sobre la historia. Escribir los criterios de aceptación, también conocidos como especificación por ejemplo en BDD, antes de implementar la historia, hace que un equipo sea más productivo al evitar el retrabajo como resultado de malentendidos.

Escribir historias de usuario no es el objetivo

El punto es la conversación entre usuarios, profesionales de la empresa, desarrolladores y probadores. Es esa conversación, el ir y venir entre las diferentes perspectivas de cada participante, lo que les aportará soluciones mejores, más sencillas y más valiosas a los problemas de los usuarios.

Las historias de usuario que escribes son el medio para comunicarlas y mantener el enfoque y el valor para el usuario durante el desarrollo.

Cómo escribir una historia de usuario en 4 sencillos pasos

Writing User Story

  1. Empezar por el final

El desarrollo ágil consiste en ofrecer un software valioso que satisfaga las necesidades de los clientes. Así que ahí es donde se empieza: el objetivo final, o el valor, que busca un usuario.

Puede ser útil pensar en ello en términos del problema que busca resolver.

  1. Trabajar hacia atrás

Con el usuario y el objetivo final claramente en mente, se elaboran los pasos que un usuario tendría que dar para alcanzar su objetivo.

Intentar averiguar cuál es el primer paso para alcanzar un objetivo es difícil. Simplemente hay demasiadas opciones para elegir y no hay manera de elegir una sobre otra..

La salida es trabajar hacia atrás desde el objetivo.

Digamos que su objetivo es disfrutar de un batido de fresas. Así que se empieza por ahí: un batido de fresas terminado, listo para ser disfrutado.

¿Qué necesita para ello? Obviamente, un vaso, una pajita, un batido y todo lo necesario para ello.

  • conseguir un vaso
  • conseguir una pajita gruesa
  • prepara el batido
  • verter el batido en el vaso
  • introducir la pajita en el batido

Tiene un vaso adecuado, pero le faltan pajitas gruesas, así que

  • comprar pajitas gruesas

Nunca ha hecho un batido, pero sabe que necesita una licuadora, así que

  • sacar la batidora
  • seguir a receta

Para seguir una receta, es necesario

  • encontrar una receta
  • comprar los ingredientes especificados en la receta
  1. Pequeño es Hermoso

Los pasos grandes son bestias difíciles de manejar que esconden suposiciones y detalles. Si quiere añadir detalles a un paso para aclararlo, a menudo es mejor dividir el paso en otros más pequeños.

Por ejemplo, el batido del ejemplo de la sección anterior. A menos que todo el mundo sepa exactamente cómo hacer el batido que tiene en mente, es mejor dividirlo en pasos más pequeños.

  1. Pluma y papelTarjetas

Cuando tengas claros los pasos y el valor que aportan para resolver el problema con el que empezó, estará listo para escribir las historias de usuario. Una historia para cada paso.

Escribir las historias en tarjetas, una por tarjeta, las hace más tangibles. Puede manipular las tarjetas directamente: moverlas sobre una mesa o un tablero. Y esa sigue siendo la forma más fácil de priorizar y programar.

Ejemplos de historias de usuario

software development

Aquí hay algunos ejemplos de historias de usuario para que todo sea más concreto.

  • Como gestor de productos con un equipo remoto, quiero poner las historias de usuario en un tablero digital, para que todos podamos ver la que estamos discutiendo en una reunión en línea.
  • Como gestor de productos con un equipo remoto, quiero invitar a los miembros de mi equipo y a un máximo de 10 personas más a una reunión en línea, para que podamos colaborar para detallar las historias de usuario que se implementarán pronto.
  • Como gestor de productos con un equipo remoto, quiero crear y editar una lista con los miembros de mi equipo, para añadirlos a todos a una invitación sin tener que añadirlos individualmente.

Cómo desarrollar software a partir de historias de usuarios

Las historias de usuario son narraciones de alto nivel que carecen de los detalles que necesitan los desarrolladores y probadores.

Por lo tanto, cuando una historia de usuario se va a implementar pronto, hay que añadir los detalles que mantendrán a todo el mundo en el camino y evitarán el (re)trabajo innecesario.

Ron Jeffries ideó las 3Cs, aspectos críticos, de trabajar y desarrollar software empezando por las historias de usuario.

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

  • Tarjeta

Escriba sus historias en tarjetas y utilícelas para priorizar, estimar y programar. Puede añadir notas sobre las prioridades y los costes, pero deja otros detalles para el…

  • Conversación

Se llevan a cabo conversaciones, discusiones abiertas, entre el cliente y las personas que participan en la aplicación para llegar a los requisitos específicos y proporcionar la claridad necesaria para la aplicación.

Los ejemplos concretos son la mejor manera de aportar claridad. Y los ejemplos ejecutables le dan…

  • Confirmación

La confirmación son las pruebas de aceptación que confirman si el software cumple los criterios de aceptación. Los criterios de aceptación son los ejemplos de la conversación. Preferiblemente en forma ejecutable, ya que los ejemplos ejecutables ahorran mucho esfuerzo en la construcción de las pruebas de aceptación.

Preguntas frecuentes sobre las historias de los usuarios

Q: ¿Cuál es la diferencia entre las historias de usuario y las características?

Las historias de usuario describen el valor que un tipo específico de usuario obtiene de una actividad.

Las características se refieren a lo que el software puede hacer. Es muy posible, y por desgracia muy común, especificar características que no aportan ningún valor.

Q: ¿Cuál es la diferencia entre las historias de usuario y los requisitos?

Las historias de usuario describen el valor que un tipo específico de usuario obtiene de una actividad.

Los requisitos se refieren a lo que tiene que hacer el software y cómo lo hace. Por lo general, los requisitos establecen los criterios que deben satisfacer las características del software.

Por lo general, se añaden requisitos a una historia de usuario en forma de criterios de aceptación colaborando con el cliente. En otras palabras: una historia de usuario tiene requisitos en forma de criterios de aceptación.

Q: ¿Quién crea las historias de usuario en Agile?

En Agile, crear y escribir historias de usuario es un esfuerzo de colaboración. Se obtienen los mayores beneficios de las historias de usuario cuando se crean en discusiones abiertas entre clientes, profesionales de la empresa, desarrolladores, probadores, diseñadores y otras personas interesadas en el software.

Conviértase en un contador de historias y sorprenda a sus clientes

Como ya sabe, las historias de usuario son una gran manera de mantener a todo el mundo centrado en la entrega de valor para sus usuarios. Uh, clientes. Uh, ambos.

Y llevar a cabo conversaciones de colaboración en torno a las historias de usuario garantizará que se creen soluciones que sean mejores, más sencillas y más valiosas. Soluciones que son exactamente lo que sus usuarios necesitan. Se acabaron las conjeturas y el bombeo de características que sonaban bien, pero que a nadie le interesan.

Así que, sal y conviértase en un contador de historias.

User Stories: What They Are and Why and How to Use Them

¡La vida es buena cuando sus equipos ágiles están sincronizados!

Solicite una demostración personalizada de SwiftEnterprise.