Gestión
de requerimientos y compromisos.-Haciendo mejores requerimientos mediante
historias de usuario.
Como se ha
podido ver en la entrada anterior, las historias de usuario pueden ser una
técnica muy práctica al momento de identificar y concretar requisitos, tratando
siempre de especificar detalles muy claros de lo que necesita y como lo
requiere el usuario aplicado en el software.
Para
determinar si estamos haciendo buenas historias de usuario que nos ayuden a
tener información obtenida realmente útil para la construcción de las
funcionalidades en el sistema, es importante recordar que las historias de
usuario nos sirven para a iniciar una conversación centrada en requisitos muy
particulares y las características de los mismos; así mismo permiten facilitar
el camino de la exploración de requisitos, ayudando a que el usuario
especifique los que requiere y como lo quiere (Criterios de Aceptación), pero
solo el uso frecuente de esta técnica nos permitirá ir puliendo la forma de
llevar una conversación más provechosa en la obtención de mejores
requerimientos.
Para
evaluar de forma inicial si nuestra historia de usuario es hasta cierto modo
factible o correcta, es importante conocer sus características desde la visión
del modelo INVEST: Independet, Negotiable, Valuable, Estimable, Small y
Testable (En Inglés), que transformado
al español quedaría de la siguiente manera:
*Independiente:
La historia de usuario no debe ser dependiente de otra, aunque para esta
característica podemos hacer ciertas excepciones.
*Negociable:
Puede ser negociable en el caso de que puede ser ejecutada durante una
iteración; así como ser reemplazada por otra del mismo tamaño para su
construcción.
*Valiosa:
Debe generar valor al proyecto, negocio o los usuarios finales.
*Estimable:
Puede ser estimada en tiempo y esfuerzo, dejando el mínimo de incertidumbre al
programador para su construcción.
*Pequeña
(Small): Debe ser lo más pequeña que se pueda, para poder cumplir con la
característica anteriormente señalada.
*Testeable:
Debe tener las características de presentación o comportamiento para ser
testeada o en consecuencia que tenga criterios que determine que está
terminada.
Ahora
bien para detallar de forma un poco más completa la manera de mejorar nuestras
historias de usuario, veamos como las características basadas en el modelo
INVEST nos permiten ir filtrando los buenos requisitos de los ambiguos. Las
características fueron ordenadas mediante una secuencia lógica de construcción
y agregación de valor a la historia de usuario:
1.-Valiosa:
La historia de usuario tiene que ser de utilidad y para saber esto recordemos
que en la misma estructura de la historia, se especifica el “para que” es
requerida. Mediante este sencillo prefijo conoceremos si genera valor para el
usuario o está fuera del alcance.
2.-Pequeña:
La historia de usuario debe ser lo más compacta posible, al referirnos a esto
debemos buscar que siempre auto contenga solo una funcionalidad o satisfaga una
sola necesidad a la vez; por ejemplo: Como
responsable de ventas quiero realizar la consulta del índice de ventas semanal
por región comercial para conocer cual tiene el mayor y menor índice de ventas,
como se observa la especificación es muy concreta en lo que se requiere hacer y
por lo tanto pequeña. No se entra en ambigüedades de alguna funcionalidad
adicional.
3.-Independiente:
Debemos procurar que nuestras historias sean independientes unas de otras de
tal forma que puedan ser construidas sin impactar en labores de construcción de
otra. Como vimos en la característica anterior, entre más auto contenidas sean
las funcionalidades más independencia le daremos a la historia de usuario, pero
en ocasiones para esta característica es conveniente hacer ciertas excepciones,
puesto que en algún momento tendremos historias de usuario que inevitablemente
tendrán relación con otra (dependencia), ejemplo:
· Historia de usuario inicial: Como responsable de ventas
quiero realizar la consulta del índice de ventas semanal por región comercial
para conocer cual tiene el mayor y menor índice de ventas.
·
Historia de usuario dependiente: Como responsable de ventas
quiero enviar comentarios o sugerencias vía correo electrónico a la región
comercial con el menor índice de ventas.
4.-Estimable:
Al tener en nuestra historia de usuario las características de ser pequeña e
independiente, es más fácil dar al equipo de trabajo, y en un caso muy especial
al programador, los elementos necesarios para que pueda determinar el esfuerzo
(días de trabajo) que tiene que hacer para la construcción de ese
requerimiento.
Para
lograr una estimación más certera es conveniente que se divida la historia de
usuario en tareas técnicas, las cuales nos especifican que se tiene que hacer
para construir la funcionalidad, ejemplo: adecuación a una tabla en base de
datos, codificación de una vista o procedimiento almacenado, configuración de
un archivo o clase, diseño de formularios, etc.
5.-Negociable:
Cuando una historia de usuario tiene una estimación razonable del esfuerzo
requerido para su construcción, es más fácil tener argumentos para poder
negociar ante los usuarios o el product owner (promotor del proyecto), para
aquellos casos cuando se quiera cambiar el enfoque del requerimiento o se
pretenda sustituir por otro durante una iteración que ya se tiene en ejecución.
6.-Testeable:
La historia de usuario debe tener una serie de especificaciones que permitan
determinar cómo debe ser testeada, tanto en su funcionalidad como en
completitud, esto se logra mediante la especificación de criterios de
aceptación, concepto el cual mencionamos en la entrada anterior. Al ser una
funcionalidad auto contenida debe dar cierta facilidad ejecutar las pruebas,
basado tanto en lo visual como en lo funcional.
Como
podemos observar profundizar y armar las características de la historia de
usuario bajo la secuencia de pasos anterior, del modelo INVEST, nos permite
tener una guía para comprender que puntos debemos considerar al momento de obtener
y armar mejores requerimientos basados en esta técnica.
No hay comentarios.:
Publicar un comentario