Historias de Usuario: un nuevo orden en los requisitos del software

Las Historias de Usuario no requieren almacenarse en
documentos pesados o especiales

VademeScrum, Sección 2: Las Historias de Usuario 1

Estoy escribiendo un artículo sobre Scrum sin Historias de Usuario, pero entonces noté que quizás muchos de mis lectores no sabrían que es una historia de usuario y por qué se usan en Scrum. Así es que tomé la decisión de cambiar el curso del destino y escribir primero sobre este asunto. En el desarrollo ágil, la historia de usuario es un sustituto más ligero para lo que han sido nuestros medios tradicionales de especificar requisitos de software: documentos de especificaciones de requisitos de software, especificaciones de casos de uso y similares.

Ejemplo 1: La historia de usuario “Leer un libro”

Pensemos en una historia de usuario como una manera de dejar un legado, algo que trascienda más allá del tiempo, por ejemplo, de un proyecto y que permita que las culturas sobrevivan. Para ello, las historias tienen que ser simples, cortas, fáciles de entender y de aceptar y de franca recordación sin que tengan que escribirse todos sus detalles. Ese es el gran poder de las historias de usuario. Veamos, por ejemplo, la siguiente historia de un caso no software pero que ilustra perfectamente la estructura y comportamiento de una historia de usuario:

Como: crítico literario

Quiero: leer un libro

Para: escribir una reseña sobre el libro

Estos tres elementos conforman el núcleo de toda historia de usuario. En el primero (Como) se establece quién es el usuario o grupo de usuarios que “intervienen” en la historia, típicamente es un rol de usuario, en el desarrollo de software este elemento responde a la pregunta “quién usará la funcionalidad” descrita por esta historia. El segundo elemento (Qué) es la actividad, el eje de la historia, qué hace el usuario en la historia. Y el tercer elemento (Para) es el propósito de la historia, la meta que quiere alcanzar el usuario al ejecutar la historia. Todos, en conjunto, describen una finalidad, más que un requisito.

Definición

En resumen, una Historia de Usuario es una corta declaración de intención que describe algo que el sistema necesita hacer para el usuario. Se describe desde el punto de vista de quien usará la funcionalidad, es decir, su usuario. Pero ya que definimos qué es una historia de usuario, dejemos claro también qué no es: no es una especificación detallada de requisitos de software, algo que el sistema debe hacer, es más bien, un contrato negociable de intención que indica que el sistema necesita hacer algo más o menos así.

Algunas características de las historias de usuario son:

• Son cortas y fáciles de leer, entendibles por los desarrolladores, interesados y usuarios
• Representan incrementos pequeños de funcionalidad valorada, que puede ser desarrollada en un período de días o semanas
• Son relativamente fáciles de estimar porque el esfuerzo de implementar la funcionalidad puede determinarse rápidamente
• No se llevan en documentos grandes o pesados, sino más bien en listas organizadas que pueden ordenarse más fácilmente y reordenarse a medida que se descubre nueva información
• No se detallan al principio del proyecto, sino que se elaboran sobre una base JIT – evitando así especificidad demasiado pronto, retardos en el desarrollo, inventario de requisitos y una declaración sobre-restringida de la solución.
• Necesitan poco o ningún mantenimiento y se pueden desechar con seguridad después de la implementación
• Las historias de usuario, y el código que se crea rápidamente a continuación, sirven como insumo para la documentación, la cual también es elaborada de manera incremental.

Ejemplo 2: La historia de usuario “Ingresar a la red social”

Un aspecto que viene con la simplicidad y el tamaño relativamente pequeño de las historias de usuario es que, por lo general, representan funcionalidades parciales, es decir, no indican funciones o procedimientos complejos y grandes que el sistema debe hacer. Por ejemplo, podríamos tener una historia llamada “Ingreso Básico a la Red” para especificar la entrada a una red social en Internet. El usuario es un “miembro de la red” y lo que hace más habitualmente este miembro es compartir enlaces con sus contactos. La historia luciría más o menos así:

Como: miembro de la red social

Quiero: ingresar a la red

Para: compartir un enlace

La “Narración” de las Historias de Usuario

Pero y ¿dónde están los detalles de la historia de usuario? ¿Cómo sabemos que efectivamente la historia descrita en el ejemplo anterior es simple y representa una funcionalidad parcial? ¿Cómo ingresa el usuario a la red? Estos pormenores se dan durante la Conversación y se especifican en los Criterios de Aceptación de la Historia. La Conversación representa una discusión entre el equipo, el usuario, el propietario del producto y los otros interesados, que es necesaria para determinar el comportamiento más detallado requerido para implementar la intención.

En el ejemplo citado, la conversación puede responder a preguntas como:

• ¿Qué información necesita el usuario proporcionar al sistema para ingresar?
• ¿Es obligatoria toda la información o puede ser parcial, esto es, hay datos opcionales?
• ¿Qué ocurre cuando la información está incorrecta o incompleta?

Encontrar respuestas  a estas y a otras cuestiones relacionadas delimita la funcionalidad de la historia. Por ejemplo, en una primera entrega del software o salida a producción del mismo, podemos acordar con los usuarios tener solo la funcionalidad básica de ingreso, de allí el nombre de la historia establecido en la sección anterior. O sea, solo se solicitará un nombre de usuario y una contraseña con algunas características. A continuación, el sistema validará que el par nombre de usuario + contraseña coincidan y permitirá el ingreso del usuario, nada más. En caso contrario mostrará un mensaje advirtiendo la imposibilidad de ingreso a la red.

Entre tanto, los criterios de aceptación, llamados también Confirmación, representan las condiciones de satisfacción que se aplicarán para determinar si la historia cumple o no la intención así como los requisitos más detallados. Es precisamente la Prueba de Aceptación del usuario, que muestra cómo el usuario confirmará que la historia se ha implementado a su entera satisfacción. Los flujos alternativos en la actividad, los límites de aceptación y otras clarificaciones deberían capturarse junto con la historia. Muchos de estos se pueden convertir en casos de pruebas de aceptación u otros casos de pruebas funcionales, para la historia.

En la historia “Ingreso Básico a la Red”, estos criterios de aceptación podrían incluir:

• El nombre de usuario es la dirección de correo electrónico del usuario.
• La contraseña debe contener letras y números.
• La contraseña debe ser de al menos 8 caracteres y máximo de 32.
• El usuario ya debe estar registrado en la red social.
• Si la contraseña no coincide con el nombre de usuario, el sistema mostrará el mensaje “Combinación incorrecta de correo electrónico/contraseña”.
• Entre otros.

Notamos de inmediato que en esta historia “Ingreso Básico a la Red” no se estableció nada acerca de olvido de la contraseña o del nombre de usuario, o qué ocurre luego de mostrar el mensaje sobre datos incorrectos, o de cambio de contraseña o de otras funcionalidades adicionales al ingreso como “No cerrar sesión”, restablecer la contraseña, usar el número de teléfono móvil en vez del correo electrónico para ingresar o si la cuenta se bloquea al hacer varios intentos de ingreso fallidos y qué se debe hacer para restablecer el acceso, entre muchas otras cosas que giran alrededor del ingreso a la red. Estos detalles pueden hacer parte de otras historias a construirse más adelante para la versión actual del producto o para otras versiones sucesivas del producto.

Lo que hicimos con este ejemplo fue encontrar la historia de mayor valor para el negocio, es decir, esa funcionalidad o parte de la funcionalidad que será usada la mayor parte del tiempo por los usuarios y que, por consiguiente, permite obtener el máximo valor de negocio o el retorno de inversión más rápidamente posible. Recordemos que cuando se trata de desarrollo de software, las prácticas ágiles lo son porque permiten entrega rápida de valor. Hablaremos de este asunto en otra oportunidad porque me parece vital a la hora de acoger los principios o pilares ágiles.

Ejemplo 3: La historia de usuario “Quiero publicar una entrada básica de blog”

Veamos un ejemplo completo de una historia de usuario relacionada con la creación de blogs y la publicación de entradas al blog.

Carta:

Como Bloguero (<rol de usuario>) quiero ser capaz de publicar entradas en un blog (<lo que hago con el sistema>) para aumentar mi credibilidad y posicionarme como experto en el área de mi interés (<valor del negocio que recibo>).

Conversación:

P1. ¿Cuál es su área de interés? (El equipo al Bloguero)

R1. El área de mi interés es la literatura contemporánea hispanoamericana

P2. ¿Cuál es el público esperado?

R2. El público esperado es el compuesto por jóvenes y adultos

P3. ¿Cuál es la frecuencia de publicación?

R3. El objetivo es publicar una entrada quincenal

(Sigue…)

En el caso de Scrum, esta conversación se da típicamente durante la planeación del sprint, al principio del mismo, y durante el sprint.

Confirmación (criterios de aceptación): 

El contenido de las entradas debe ser texto principalmente

El sistema debe permitir entradas de hasta tres mil palabras

Cada entrada debe llevar un título de hasta 256 caracteres

Cada entrada debe publicarse en una página separada

(Sigue…)

Este esquema estructural de la historia de usuario es lo que se conoce como la “Aliteración Carta, Conversación, Confirmación”, propuesta por Ron Jeffries, uno de los co-creadores de eXtreme Programming o XP.

¿Cuándo se usan las historias de usuario?

Dado su carácter de simplicidad y tamaño (pequeño), la poca información explícita que contienen, las historias de usuario se usan o son beneficiosas cuando hay requisitos cambiantes, lo que ocurre la mayor parte del tiempo, pero y más importante, cuando los usuarios o representantes de estos están disponibles sin protocolo para que el equipo de desarrollo resuelva todas las inquietudes que se le presenten mientras convierten la historia en funcionalidad. En Scrum, por ejemplo, ese representante de los usuarios e interesados en el producto es precisamente el Dueño del Producto.

En otros artículos proporcionaré más ejemplos, buenas prácticas para identificar y documentar historias de usuario y hablaré de los principales atributos de toda historia de usuario, agrupados bajo las siglas INVEST.

Otros artículos de esta serie:

Sobre los atributos INVEST de las historias de usuario:

Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)
http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_19.html