martes, 19 de abril de 2016

Una historia dice más que mil palabras (Cont. 1)


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