Potenciando el desarrollo de
software mediante el uso de historias de usuario.
Las
historias de usuario son una técnica para representar una necesidad o requisito
por parte de un usuario, y si es utilizado de manera ingeniosa puede servir también,
para que el levantamiento de requerimientos sea de mayor provecho al arrojar
detalles que durante una entrevista no tan fácil lograría satisfacer.
Antes
de entrar en materia sobre sus posibles usos es conveniente conocer un poco más
sobre las historias de usuario. Las historias de usuario como tal deben ser
pequeñas y prácticas de tal manera que cuentan, de manera muy corta, una
necesidad y su valor que aportan al negocio. Una historia de usuario debe permitirnos
ser escrita en una pequeña tarjeta, nota o post-it de tal forma que evita la
tediosa actividad de escribir una gran especificación de requisitos.
La
sintaxis para escribir una historia de usuario puede ser la siguiente:
As
a (User Role) Iwant to (Do this) so that (Achive that), que en español sería:
Como (Rol de Usuario) Quiero (Hacer esto) Para (Alcanzar o lograr esto).
En
términos más prácticos si nuestro proyecto estuviera orientado en el desarrollo
de un sitio web para la venta de productos electrónicos, en lugar de hacer
especificaciones completas como casos de uso tendríamos los siguientes ejemplos
de historias de usuario.
1.-Busqueda
por Nombre
Como Cliente quiero poder hacer una búsqueda de artículos por
nombre para encontrar más rápidamente el producto que deseo comprar.
2.-Selección
de varios artículos para agregarlos al
carrito de compra
Como Cliente quiero realizar una selección de diferentes
artículos para agregarlos a mi carrito de compra.
3.-Realizar
pago en línea de la compra
Como Cliente quiero realizar el pago en línea de mis artículos
para concluir con mi compra.
Como
nos damos cuenta, la forma de redactar una historia de usuario es completamente
sencilla y especifica una necesidad usando el lenguaje de los usuarios, evitando
la necesidad de especificar a gran detalle elementos de software.
Ahora
para aquellos quienes tienen experiencia realizando análisis de sistemas
mediante Casos de Uso o especificaciones de requerimientos, se preguntaran —¿Bueno
y con esto puedo empezar a construir algo? —, la respuesta es que no del todo, con la
especificación de la historia de usuario acotamos el alcance de una necesidad.
El detalle lo especificamos con los llamados “Criterios de Aceptación”.
Los
Criterios de Aceptación no son otra cosa que aquellas especificaciones mediante
las cuales podemos determinar que un requerimiento está completamente
terminado, aporta detalles para la programación del mismo, define las fronteras
de lo que se va a construir y también ayuda a los testers a verificar que
puntos de la implementación tiene que probar.
Tomemos
uno de los ejemplos anteriores:
1.-Busqueda
por Nombre
Como Cliente quiero poder hacer una búsqueda de artículos por
nombre para encontrar más rápidamente el producto que deseo comprar.
Y
sus criterios de aceptación podrían quedar de la siguiente manera:
- Verificar que el texto introducido se pueda encontrar en cualquier parte del nombre del producto a buscar.
- Verificar que la lista de artículos encontrados los ordene de menor al de mayor precio.
- Verificar que los artículos presentados, por artículo, tengan los siguientes datos:
o
Imagen
del artículo
o
Nombre
Completo
o
Descripción
o
Precio
Como
podemos observar los criterios de aceptación dan un poco más de luz al
programador para que conozca exactamente que tiene que construir y también
ayudan tanto a los usuarios, como al equipo de trabajo a delimitar el esfuerzo
y complejidad del requerimiento.
Como
se mencionó anteriormente la historia de usuario puede ser escrita en una pequeña
tarjeta, nota o post-it, de acuerdo al tamaño de nuestra historia y sus
criterios de aceptación, decidiremos el material que usaremos:
1.-Uso
de post-it
2.-Uso
de tarjetas
También
para dar mayor soporte a las historias de usuario se puede reforzar con
información adicional que los usuarios nos proporcionen para darle solides al
requerimiento, como se muestra en el siguiente ejemplo:
Todo
aquello de vaya relacionado con el requerimiento como prototipos en papel,
información en archivos de Excel, reglas, cálculos, etc. puede ser entregado al
programador como un paquete del requerimiento para su construcción.
Es
conveniente que las historias de usuario sean escritas durante las entrevistas
con los usuarios o durante un taller para la obtención de requerimientos e
involucrar a los mismos sobre la importancia y el porqué de esta técnica, para
apoyar en la mejor comprensión de la problemática ya que nos enfoca en conocer
que parte del sistema aporta el mayor valor al negocio.
No hay comentarios.:
Publicar un comentario