 |
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.
