Buscar en Gazafatonario IT

domingo, agosto 04, 2013

Historias de Usuario Altamente Efectivas, 2

VademeScrum, Sección 2: Las Historias de Usuario 2

INVEST es un acrónimo acuñado por Bill Wake para referirse a ciertas propiedades que debería tener una buena historia de usuario:


- Independiente
- Negociable
- Valiosa
- Estimable
- Sucinta

- cerTificable

Una presentación previa de este tema la hice en:
Cualidad :: Independiente
Para entender mejor este rasgo de las historias de usuario, veamos un par de historias dependientes entre sí:
Historia Dependiente 1
Como: Editor
Quiero: establecer las reglas de seguridad de la contraseña de los blogueros
Para: que los blogueros se obliguen a crear y retener contraseñas seguras, manteniendo seguro el sistema.
Historia Dependiente 2
Como: Bloguero
Quiero: Seguir las reglas de seguridad de las contraseñas establecidas por el Editor
Para: que mi cuenta se mantenga bastante segura.
A todas luces es evidente que completar la historia del Editor no deja el producto en un estado de potencialmente distribuible, por lo tanto, no tiene valor o no es valiosa por sí sola para el negocio. Esto ocurre porque la historia del Editor solo es verificable en cuanto a establecer, eliminar y preservar la política, pero no es verificable cuando de hacerla cumplir al bloguero. Reconsiderando las historias y el diseño del sistema, podemos eliminar la dependencia dividiendo las historias de una manera diferente, en este caso, a través de los tipos de políticas de seguridad aplicadas y combinando la configuración de la política con normas para hacerlas cumplir en cada historia:
Historia independiente 1
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.
Historia Independiente 2
Como: Editor
Quiero: establecer las características de solidez de la contraseña
Para: que los blogueros deban crear contraseñas difíciles de jaquear o de descifrar.
Ambas historias están escritas desde el punto de vista del Editor. Esto es así porque los blogueros simplemente “usan” o “consumen” las restricciones impuestas por el Editor. En el segundo ejemplo, cada historia puede valerse (y valorarse) por sí misma y puede desarrollarse, verificarse y entregarse independientemente. Una buena práctica es preguntarnos para cada Historia de Usuario si hemos hecho todo lo posible para que esta sea independiente del resto. La independencia permite además construir la historia, es decir, convertirla en software funcionando, en iteraciones diferentes o aun en entregas distintas del mismo proyecto.
Ahora bien, la dependencia entre historias de usuario se presenta de distintas formas. Bill Wake, el creador del modelo INVEST, describe4 tres tipos comunes de dependencia: de Superposición, de Orden y de Contención.
Dependencia por Superposición de Funciones
El primero de estos casos es el más doloroso de todos. El siguiente par de historias nos muestran esta situación:
Figura 1: Historias dependientes por superposición de funciones
Figura 1: Historias dependientes por superposición de funciones (Haga clic sobre la imagen para ampliarla)
Observemos la actividad (el “Quiero”) de estas historias. La conjunción “Y” presente en cada una de ellas ya hace que estas historias sean “sospechosas”. Por supuesto, la superposición se da entre dos o más historias y lo que procede es tratar de reducir o de eliminar la trasposición de funciones. En el caso actual podemos convertir estas dos historias en tres, teniendo en cuenta que “Agregar comentarios a las entradas” se repite en ambas historias:
Figura 2: Historias independientes luego de remover la superposición de funciones
Figura 2: Historias independientes luego de remover la superposición de funciones (Haga clic sobre la imagen para ampliarla)
Como siempre debe ocurrir con las historias de usuario, las estamos viendo desde el punto de vista del usuario, no de lo que tenemos que hacer para implementarla. En este sentido, seguramente parte de la funcionalidad de agregar comentarios, sino toda, se comparte con la de Responder a Comentarios, pero eso es un asunto técnico que poco o nada interesa a quien usará las funcionalidades una vez estén expuestas. No se trata de interposición técnica, sino funcional.
Dependencia por Orden de Funciones
Esta es quizás la dependencia a la que estamos más atentos. Se trata de esas funciones de la solución que se deben implementar antes que otras. Pero también son dependencias fáciles de remover cuando se presentan. Por ejemplo, para agregar o responder a comentarios a las entradas, el lector del blog debe identificarse primero y para ello debe registrarse primero. Es la secuencia del proceso de negocio y, por consiguiente, funcional. Estas historias pueden lucir como se muestra en la figura a continuación:
Figura 3: Historias dependientes por orden de funciones
Figura 3: Historias dependientes por orden de funciones (Haga clic sobre la imagen para ampliarla)
En principio, el registro (registrarse) puede evitarse matriculando “a mano” las primeras cuentas para que el sistema comience a funcionar o, incluso, se puede usar la funcionalidad de Ingresar al Blog para hacer el registro sin que el usuario esté consciente de ello. Pero Ingresar al Blog también se puede dejar para después de Agregar Comentarios y realizar una entrega de la solución donde los lectores puedan adicionar comentarios sin tener que identificarse. Como siempre lo que prima es implementar primero lo de mayor valor para el negocio (para el Dueño del Producto) y lo de mayor riesgo. En este caso, con la historia Agregar Comentarios se logran ambos cometidos.
Dependencia por Contención
Se trata de esas historias que hacen parte de otra, llamadas así sub-historias o algo por el estilo. La confusión se hace latente cuando decidimos aceptar la jerarquía típica de las historias en Épicas y Temas, que son técnicas para describir un sistema de software. Pero dejando de lado esa clasificación, lo que debemos tener en cuenta es que la ordenación o estructura de un sistema casi nunca coincide con la agenda de su implementación. Pensemos por ejemplo en la historia Ingresar al Blog de la sección anterior.
Esta historia podría incluir una funcionalidad para recordar el nombre de usuario al lector del blog o una para restablecer la contraseña si está se ha olvidado, o ambas. Decimos que estas dos funcionalidades adicionales están contenidas en la funcionalidad de la historia Ingresar al Blog que se transforma así en una épica. La carta de intención de estas historias podría lucir como en la siguiente figura:
Figura 4: Historias dependientes por contención de funciones
Figura 4: Historias dependientes por contención de funciones (Haga clic sobre la imagen para ampliarla)
Lo que puede ocurrir al implementar la historia Ingresar al Blog como un todo es que hayan dos enlaces rotos en la funcionalidad (“Restablecer contraseña” y “Recordar usuario”) hasta tanto estas dos últimas historias no se implementen. Y si esto no se logra durante la misma iteración (Sprint) entonces no tendríamos un incremento del software funcionando potencialmente distribuible, al menos, no uno completo.
En cambio, si tratamos estas historias como totalmente independientes y los enlaces “Restablecer contraseña” y “Recordar usuario” los tratamos en cada historia respectiva, al terminar de implementar la historia Ingresar al Blog sí tendremos un incremento funcional distribuible. Otra vez, el valor para el negocio y el riesgo son dos aspectos muy importantes a tener en cuenta a la hora de tomar una decisión sobre cual historia implementar primero y cual historia construir después. En este caso, el tamaño (cualidad que abordaré en otra sección), también juega un papel significativo.
Comentarios Finales
Aplicar el modelo INVEST a cada historia de usuario es una tarea compleja y lleva tiempo lograr los resultados que queremos. En particular, lograr que todas las historias sean independientes es una labor colosal que puede retrasar el proyecto innecesariamente si no tenemos la experiencia suficiente. Contar con un equipo multidisciplinario, maduro y conocedor profundo de estos atributos ayuda. De lo contrario, la I de INVEST no será por Independiente sino por Imposible. La buena noticia es que no tenemos que hacerlo todo de una vez. Como siempre, aplicamos el enfoque iterativo y a medida que refinamos el Backlog del producto, podemos tratar los asuntos de dependencia entre una historia y otra.
Hasta aquí mi enfoque sobre la independencia en las buenas historias de usuario. En la próxima entrada abordaré el no menos espinoso asunto de la Negociabilidad de las historias de usuario.
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:
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:
Referencias
  1. INVEST in Good Stories, and SMART Tasks: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
  2. A User Story Primer, by Dean Leffingwell with Pete Behrens
  3. User Stories Applied, by Mike Cohn
  4. Independent Stories in the INVEST Model: http://xp123.com/articles/independent-stories-in-the-invest-model/



2 comentarios:

  1. He visto algunos formatos de HU que mencionan un aparte que dice "PERSPECTIVA DEL PRODUCTO" y su descripción parece mas un Caso de Uso. Podrías darme tu opinión? Su narración dice:
    El Sistema debe permitir a un administrador crear cuentas de vendedores las cuales puedan estar ligadas a la información del sistema, cada usuario con su contraseña podrá modificar su información y obtener reportes.
    Esto es correcto?
    "

    ResponderBorrar
    Respuestas
    1. ¿Y cuáles son los otros apartes? ¿Cuál es el resto de la forma que están usando en la historia?

      Aunque las historias de usuario no se ciñen a una forma específica, se usa mucho la estructura de las 3C, Carta - Conversación - Confirmación, como expongo en este otro artículo: http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

      Esta "Perspectiva del Producto" que mencionas aquí parece algo de la parte Conversación de la historia.

      En cualquier caso lo que se debe tener en cuenta es el contexto en el que se usan la historias de usuario. Si estamos hablando de un proyecto ágil, gestionado con Scrum, por ejemplo, sabemos que hay un Dueño de Producto involucrado en el equipo. Si los usuarios del negocio están trabajando juntos con el equipo de TI, cotidianamente y durante todo el proyecto, las historias se convierten en un recordatorio de una conversación que tendrán unos y otros más adelante, una intención de algo que los usuarios quieren que el sistema haga, quizás no es necesario llegar a especificarla con los detalles que teníamos en un caso de uso.

      Saludos,

      Borrar