VademeScrum, Sección 2:
Las Historias de Usuario 4
Cualidad :: Valiosa (y Valuada)
 |
| Las Historias de Usuario deben tener Valor para los usuarios |
Veamos esta situación:
Historia
de Poco Valor
Como: Lector
del blog
Quiero: ver la
lista de temas tratados en el blog
Para: buscar
las entradas que más se acomoden a mis intereses personales
Es mejor escribir esta historia desde
el punto de vista del Bloguero:
Historia
de Mucho Valor
Como: Bloguero
Quiero: mostrar a
los lectores los nuevos temas tratados en mi blog
Para: que ellos
continúen más propensos a leer más entradas del blog
Con esta historia tenemos una
perspectiva más clara del valor real de la historia. La implementación de esta
podría llevar a más lectores a leer más entradas del blog con lo que se
incrementaría el tráfico en el sitio Web y posicionarían al bloguero como
experto en los temas de su dominio. Mientras que ambas historias son pequeñas,
negociables, independientes, y pueden tener los demás atributos de las buenas
historias de usuario, el valor de la segunda es mucho más alto para el negocio
que el valor de la primera.
Al negociar la funcionalidad de una
historia también tenemos en cuenta su valor para el negocio. Una visión que
siempre debemos tener los equipos ágiles es encontrar ese 20% de la
funcionalidad que se usa el 80% de las veces o ese 20% del producto que tiene
el 80% del valor para el negocio, recordemos que la filosofía ágil se basa en
entregar valor al usuario. Esto quiere decir que si tenemos una funcionalidad
como la siguiente:
Como: Bloguero
Quiero: ingresar
a mi blog con usuario y contraseña
Para: mantener
la seguridad y confiabilidad de la información del blog
Criterios de Aceptación:
- Debo ser capaz de cambiar la contraseña cuando lo desee
- El sistema debe enviarme un correo electrónico para confirmar el cambio de contraseña
- El usuario puede ser un nombre seleccionado por mí o una dirección de correo electrónico
- El sistema debe bloquear la cuenta cuando haga tres intentos fallidos consecutivos
- El sistema debe permitir que ingrese automáticamente si uso el mismo computador o dispositivo
- Si olvidé la contraseña, el sistema debe preguntarme por la dirección de correo asociada a mi cuenta o por mi nombre de usuario y enviarme un enlace para establecer una nueva contraseña
- [Siguen…]
Esta es, a todas luces, una historia
que se puede dividir en varias historias dado el alto número de criterios de
confirmación que tiene. Con los usuarios buscamos lo que proporcione mayor
valor para el negocio y lo que se vaya a usar más, por ejemplo: “el sistema
debe permitir establecer una nueva contraseña cuando lo desee”, y salir en la
primera iteración o entrega con esta funcionalidad. Las demás se van
adicionando a medida que avanzan las iteraciones o las entregas. Y como antes,
algunos de estos criterios quizás nunca lleguen a implementarse, por ejemplo,
el de bloquear la cuenta después de varios intentos errados.
Finalmente, quien mejor conoce el
valor de una historia de usuario es precisamente el usuario, personificado en
alguien como el Dueño del Producto, que habla como una sola voz ante el equipo
de desarrollo y que representa los intereses del negocio. Es a esta persona a
quien debemos apoyar para que los esfuerzos de desarrollo sean conducidos
efectiva y eficientemente.
A estas alturas solo hace falta
recordar que el Valor es el atributo más importante en el modelo INVEST. Cada
historia de usuario debe proporcionar algún valor, el mayor posible, al
usuario, al cliente o a cualquier interesado en el producto. Con esto en mente,
debemos entonces reorientar nuestras estructuras de descomposición funcional
del software de un enfoque horizontal a uno vertical, esto es, para el usuario
o interesado no tiene prácticamente ningún valor si cierta funcionalidad
requiere de uno o varios procedimientos almacenados, o de uno o varios
componentes en las capas intermedias de la solución.
El usuario necesita de la
funcionalidad que le permite interactuar con el sistema, es lo que tiene valor
para él/ella. Entonces debemos crear historias que atraviesen la arquitectura
para poder presentar valor al usuario y obtener así la mejor retroalimentación
en el menor tiempo posible. Esto es consistente con los modelos de gestión
ágiles como Scrum, donde el Dueño de Producto es quien orienta los esfuerzos
del equipo de desarrollo y prioriza las historias de usuario teniendo en cuenta
su valor para el negocio. Y normalmente el Dueño de Producto no conoce de los
aspectos puramente técnicos que subyacen a una historia de usuario
(procedimientos almacenados, clases, componentes, Web services,
etcétera).
En este punto llegamos al no menos peliagudo
asunto de los requisitos técnicos o no funcionales, del software. Dos
estrategias se usan habitualmente: la primera de ellas es que estas condiciones
técnicas hagan parte de los criterios de aceptación de la historia, como en:
Como: Editor
Quiero: establecer
el período de expiración de la contraseña
Para: que los
blogueros se vean forzados a cambiar sus contraseñas periódicamente.
Criterios de Aceptación:
- La contraseña se debe poder cambiar antes de finalizar el período de expiración
- Ninguna persona distinta a su creador debe tener acceso a la contraseña
El segundo criterio, relacionado con
el acceso a la contraseña, es una restricción típica de seguridad que bien
puede ser establecida por un usuario, en este caso, por el Editor; también
puede ser un Administrador de la Aplicación. Este enfoque de incluir las
características no funcionales de una historia como parte de esta tiene la
ventaja de permitir al mismo usuario reconocer su valor y al equipo completo de
negociar su implementación.
La segunda táctica es crear historias
independientes para cada propiedad o condición técnica, o para un grupo de
estas, como en:
Como: Bloguero
Quiero: que mis
entradas de blog soporten hasta 10 mil comentarios cada una
Para: mantenerme
en contacto con el mayor número de personas posible
Criterios de Aceptación:
- Cada comentario debe contener hasta 500 palabras o 4000 caracteres
En este ejemplo, tanto la acción
expuesta en la historia de usuario, como el criterio de confirmación son
requisitos no funcionales que se pueden implementar. Este segundo enfoque ayuda
a independizar las historias de usuario y a aplicar criterios a un grupo de
funcionalidades (este no es el caso en el ejemplo); sin embargo, estas
historias tienen la desventaja de que los usuarios o interesados (el Dueño del
Producto) no le vean ningún valor y son difíciles de negociar con ellos/ellas.
En la práctica se usa una combinación
de las dos estrategias. Ahora bien, hay que decir es que no existe tal cosa
como la historia del desarrollador o la del arquitecto del software, ni mucho
menos la del Dueño del Producto, como en:
Historias de Poco o Ningún
Valor
Como: Desarrollador
Quiero: matricular
mi aplicación en Jenkins
Para: tener
integración continua automatizada
Como: Arquitecto
Quiero: que las
transacciones de la aplicación se tarden menos de 1 segundo
Para: poner en
producción una solución de alto desempeño
Como: Analista
de Pruebas
Quiero: automatizar
los casos de prueba de la aplicación
Para: hacer
pruebas de regresión de manera eficiente y efectiva
Como: Desarrollador
Quiero: implementar el procedimiento almacenado
spAdicionarComentario
Para: que la
aplicación tenga la capacidad de añadir comentarios a las entradas de blogs
Simplemente estas historias no
deberían existir, de hecho, no son historias de usuario del todo, ningún
usuario final las usa. Para el usuario no es importante, por ejemplo, donde se
registran los errores de una aplicación, quizás ni le interese si se registran
en alguna herramienta; tampoco es de valor conocer el número de inconformidades
que tiene el código fuente frente a las buenas prácticas de programación. El
usuario da por hecho que el equipo de desarrollo sabe, precisamente, construir
productos de software y que le va a entregar el mejor posible y el de mayor
valor.
Conclusiones Finales
Es un hecho, sin importar que tanto
trabajemos como equipo de desarrollo en poner a punto el ambiente de pruebas,
en tener los mejores servidores de integración continua disponibles, en usar
las mejores prácticas de escritura de código fuente, en crear componentes
reutilizables de alta calidad o procedimientos almacenados optimizados, el Bloguero
de nuestro sistema de publicaciones no puede crear una entrada de blog
con el reporte que genera el analizador de código estático de nuestro entorno
de desarrollo al compilar el código fuente, ni con las docenas o cientos de
procedimientos almacenados implementados sobre el motor de la base de datos, ni
con la implementación del algoritmo Blowfish para encriptar las contraseñas.
Simplemente necesita de una interfaz
de usuario que pueda utilizar para realizar todas sus operaciones.
Artículos Relacionados
El artículo donde presento las
Historias de Usuario, a manera de introducción: Historias de Usuario: un
nuevo orden en los requisitos del software, lo encuentran en:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html
La primera parte de esta serie de
artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 1. Lo encuentran en:
La parte 2 de esta serie de artículos
sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Independiente.
Lo encuentran en:
La parte 3 de esta serie de artículos
sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Negociable.
Lo encuentran en:
Referencias
- INVEST in Good Stories, and SMART Tasks:
- A User Story Primer, by Dean Leffingwell with Pete Behrens
- User Stories Applied, by Mike Cohn
