Si te dedicas al desarrollo de software, debes haber oído hablar de las historias de usuario. Quizás incluso las escribas como gestor. O tal vez usted es un cliente y su desarrollador de software quiere que usted enmarque las solicitudes de características como historias de usuario.

En este post, usted encontrará todo lo que siempre quiso saber acerca de las historias de usuario.

¿Qué es una historia de usuario en el desarrollo de software?

Una historia de usuario es un formato para enmarcar las características y/o requisitos del software. Como la parte de «usuario» sugiere, las historias de usuario están escritas en primera persona del singular y describen una característica como es percibida por el usuario de la aplicación.

Una historia de usuario típica sigue esta estructura (si estamos hablando del proceso de desarrollo ágil):

Como ,
quiero ,
Para que.

La primera parte (como…) especifica el papel del usuario en la aplicación, que normalmente se asocia con lo que se permite hacer allí.

La segunda parte (la característica) señala la pieza de funcionalidad que se utiliza en este caso.

La tercera parte (el resultado deseado) es el valor que el usuario quiere obtener de la característica. Aquí hay algunos ejemplos.

Ejemplo 1

Como usuario registrado,
quiero que me avisen cuando un amigo vaya a un evento cercano
Para poder reaccionar ante la noticia o unirme a ellos en el evento.

Ejemplo 2

Como usuario,
quiero obtener un 10% de descuento cada 10 viajes
para que me recompensen por gastar dinero de forma constante en el servicio.

Hay razones de peso para este tipo de estructura. Cuando los gestores de productos/proyectos tratan con requisitos de software que provienen de diversas fuentes, a veces les resulta difícil lograr la uniformidad. También puede no estar claro qué categoría de usuarios cubre la función o dónde reside el valor empresarial. El formato de historia de usuario ayuda a capturar estos detalles críticos.

Enfoques para componer historias de usuario

Las historias de usuario se pueden escribir de varias maneras, dependiendo de quién va a trabajar con ellas.

La manera Gherkin

Gherkin es un lenguaje de texto plano que describe el comportamiento sin especificar su implementación. He aquí un ejemplo sencillo de la sintaxis de Gherkin:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Como habrás notado, la sangría define la estructura en Gherkin. Los parámetros básicos son Dado/Cuando/Cuando, y estos pueden ser añadidos por múltiples Y si es necesario. Sin embargo, la sintaxis va más allá de estos parámetros básicos. Si estás realmente decidido a dominar Gherkin, aquí hay un buen tutorial.

Si bien Gherkin puede no ser la mejor opción cuando estás reuniendo los requisitos iniciales para el proyecto, puede ser beneficioso (especialmente para el equipo de control de calidad) cuando se desarrollan más historias de usuario. Las historias de usuario escritas en Gherkin son fáciles de convertir en casos de prueba.

El camino ágil

Muchas aplicaciones de gestión de proyectos ágiles ofrecen una funcionalidad para introducir historias de usuario. Por ejemplo, hemos utilizado la aplicación Taiga en algunos de nuestros proyectos internos. Te ayuda a organizar el trabajo en torno a las historias de usuario que se pueden desglosar en tareas individuales en el backlog.

Fuente: Interfaz de Taiga.io

Si lo piensas, tiene mucho sentido tener historias de usuario como elementos del backlog y luego añadir múltiples tareas a una historia de usuario. ¿Por qué? Porque, digamos, tienes una característica (=historia de usuario) y tres personas trabajando en ella; necesitarás tareas separadas para esas personas. Necesitarás un diseñador para diseñar la interfaz, un programador HTML/JavaScript para programar la interfaz, y el DevOps para liberar la interfaz en producción.

Otras herramientas como Pivotal Tracker (que introduce el concepto de «epopeyas» para agrupar historias relacionadas) también te permiten crear historias que pueden ser de diferentes tipos: Features, Chores, Bugs o Releases.

Fuente: PivotalTracker.com

Aparte de los diferentes enfoques que utilizan las distintas empresas, recuerda que hay una forma sencilla y directa de redactar las historias de usuario, cuyos ejemplos has visto al principio de este post.

¿Quién debe escribir historias de usuario?

Entonces, ¿de quién es la responsabilidad de escribir historias de usuario? Bueno, depende. Si su equipo ha acordado capturar características en forma de historias de usuario, lo más probable es que vengan de los accionistas a través del Product Owner. Por lo tanto, puede ser el PO quien realmente las escriba.

También podría ser un Gerente de Proyecto o un QA que también puede trabajar con el cliente para discutir las características y requisitos. O, tal vez usted es una startup de 15 personas y usted es el CEO, CTO y CMO? En este caso, podría dar ejemplo y empezar a utilizar historias de usuario para documentar las características.

Muchos en TI también hablan de «desarrollo de historias de usuario», que es el proceso de registrar primero los detalles de alto nivel (por ejemplo, comenzando con una simple lista de características) y luego desarrollarlos en historias más detalladas mediante la adición de tareas, escenarios, etc.

En Conclusión

Al final del día, la formulación de características en forma de historias de usuario le ayuda a mantenerse centrado en los objetivos de negocio. También te ayuda a que los requisitos sean completos. Y, como se ha dicho, la plantilla/campos exactos que utilices pueden ser diferentes, dependiendo de la situación.