En los anteriores posts empezamos a introducirnos en el mundo del relevamiento, en la ingeniería de requisitos para ser concretos. Entendimos la importancia de tener un buen relevamiento previo antes de desarrollar y analizamos las diferentes técnicas existentes para elicitar requisitos.  

Hoy vamos a meternos en las historias de usuarios, la cual nos permite formalizar los requisitos.  

¡Manos a la obra! 

¿Qué es una historia de usuario? 

Una historia de usuario es una herramienta usada en metodologías agiles para describir una funcionalidad valiosa desde la perspectiva de algún usuario.  

Las historias de usuario se suelen escribir en tarjetas que siguen algún estándar en común, pero esto no es lo importante. La tarjeta por sí sola no tiene valor alguno, sino que es un simple recordatorio de una conversación que debemos tener con el usuario. Es por ello que a la hora de escribir la tarjeta describimos la funcionalidad sin detalle alguno de la posible implementación. Estos detalles debemos salir a buscarlos con el usuario. 

Además, debemos también acordar los criterios de aceptación con los cuales vamos a definir el alcance de nuestra historia. 

Por lo que podemos decir que una historia de usuario esta abarcada por 3 aspectos importantes: 

• Una tarjeta con una descripción la cual nos servirá de recordatorio para tener una conversación con el usuario. 
• La conversación con el usuario en la cual se buscan refinar los detalles de la misma. 
• Los criterios de aceptación con los cuales vamos a determinar que nuestra historia se encuentra finalizada 

 

¿Cuál es el formato de una historia de usuario? 

El formato más común a la hora de escribir una historia de usuario es el siguiente: 

Dicho formato nos permite tener en la tarjeta quien es el usuario, que es lo que se quiere y lo más importante, el para que de lo que se quiere (el beneficio) 

Recordemos que la tarjeta es simplemente un recordatorio de una conversación que debemos tener. Utilizando este formato, basta con leer la tarjeta para entender la problemática y lograr tener una conversación más fructífera con el usuario. 

Existe una forma de garantizar que nuestras historias de usuarios se encuentren correctamente escritas. Para ello se utiliza el modelo INVEST a la hora de redactarlas. 

 

¿Qué es el modelo INVEST? 

El modelo INVEST es una serie de criterios estándares que se tienen que cumplir a la hora de redactar una historia de usuario.  

Nuestra historia debería ser: Independiente, Negociable, Valiosa, Estimable, Small (Pequeña) y Testeable 

A continuación, detallamos cada una de las características: 

Independiente 

Una historia de usuario debería poder trabajarse en cualquier orden sin tener que depender de otras. A la hora de redactar una historia de usuario debemos tener cuidado con establecer dependencias con otras. El establecer una relación entre las misma implica que nos va a costar hacer cambios de priorización a la hora de planificar. 

Negociable 

Dado que las historias no incluyen detalles de implementaciones, debemos ser capaces de negociarlos junto con el usuario. Recordemos que las historias de usuarios son recordatorios de conversaciones que debemos tener para ultimar detalles de la misma.  

El tener una historia detallada nos hará creer que sabemos que tenemos que hacer, lo que provocara que el aspecto de conversación con el usuario se pierda. Además, nos quedaremos con una única solución sin tener en cuenta que existen otros caminos que pueden proveer un mejor incremento de producto  

Valiosa 

Las historias que escribamos deben tener valor para el usuario. Debemos evitar a toda costa tener historias que solo tienen valor para el equipo de desarrollo. Es posible que detrás de esas historias tengamos beneficios, solamente debemos encontrar en que se beneficiara el usuario. La mejor forma de garantizar que una historia es valiosa es escribirla junto al usuario. 

Estimable 

Es importante que el equipo de desarrollo sea capaz de estimar la cantidad de tiempo que puede llevar a cabo una historia. Si no se puede estimar es probable que tengamos algunos de los siguientes problemas: Falta de conocimiento del dominio, Falta de conocimiento técnico o la historia puede ser muy grande. 

Para la falta de conocimiento del dominio es probable que el equipo de desarrollo no entienda en que consiste la historia. Debemos tener conversaciones con el usuario con el fin de comprender la misma. No es necesario tener todos los detalles sino los indispensables a la hora de estimar 

Para solucionar la falta de conocimiento técnico, se suele dedicar un timebox para realizar investigaciones y pruebas. El fin es tener una idea de la parte técnica (tecnologías usadas, por ejemplo) y encontrarse en condiciones de estimar la historia. 

En el caso de que la historia sea muy grande y no se puede estimar es recomendable buscar la forma de dividirlas en historias más chicas que sean capaces de estimar. 

Pequeña 

Las historias deberían ser los suficientemente pequeñas para que en una interacción podamos entregar un incremento de producto. En caso de que la historia no sea pequeña es probable que nos encontremos ante una épica y debemos encontrar la forma de poder reducirla los posible. 

Testeable 

Debemos ser capaces de testear las historias que escribimos. Esta es una forma de garantizar que una historia se encuentre terminada. Si no podemos testearla ¿Como podemos garantizar que terminamos lo que estamos codeando? 

 

¿Qué son los criterios de aceptación de una historia de usuario? 

Una vez finalizada una historia de usuario, ¿Como puedo garantizar que cumpla con las necesidades del usuario? Para remediar esto, existen los criterios de aceptación.  

Los criterios de aceptación son una lista formalizada de los requerimientos y escenarios los cuales son necesarios cumplir para dar por terminada una historia de usuario.  

El tenerlos definidos de antemano nos ayudara a eliminar ambigüedades y alcanzar un consenso con el usuario acerca de lo que se va a desarrollar. Dado esto, los criterios de aceptación además nos permiten definir el alcance de una historia de usuario haciendo que se facilite la planificación y estimación de la misma. 

Los criterios de aceptación los puede escribir tanto el equipo de desarrollo como el usuario, la única regla es que se deben evitar detalles de implementación y deben quedar claros y específicos para el equipo de desarrollo. 

 

Conclusiones 

Hasta acá llegamos con el artículo. En el mismo repasamos que es una historia de usuario, como está compuesta, el modelo INVEST y los criterios de aceptación.  

La idea de este artículo es que nos haga reflexionar cómo estamos escribiendo nuestras historias. Al escribirla la misma en la planificación y poner el “para que” que nosotros creemos tiene sus riesgos. Es probable que no entendamos la verdadera necesidad y tengamos que realizar muchos cambios sobre el desarrollo de la misma lo que provocara que nos sintamos frustrados   

Las historias de usuario que hayamos representado con una tarjeta describiendo la necesidad, que conversemos acerca de la misma con el usuario y acordemos los criterios de aceptación tiene grandes probabilidades de convertirse en un incremento de producto acorde a las expectativas del usuario..  

Algo que no tenemos que descuidar es acordar con el usuario los criterios de aceptación. Es importante definir el alcance de la historia para saber hasta qué punto podemos darla por finalizada y no tener alguna situación indeseable en el cual tenemos “la historia sin fin” (SIC). 

En el próximo post analizaremos que son los casos de usos, para que se utilizan y finalmente haremos una comparativa de los mismos con las historias de usuarios. 

¡Nos vemos!