Reunión AgileCanarias: Historias de usuarios

Antes de ponerme a hacer el resumen de la última reunión del grupo, me gustaría volver a hacer una aclaración que es extensible al blog, y que por mi forma de hablar, comportarme o expresarme puede no ser aparente, y creo que quedó un poco borrosa en la reunión. Cuando digo o propongo algo, es siempre una opinión personal basada en mi experiencia o en mis lecturas previas, no es ningún tipo de ley universal ni nada que se le parezca. Mi única intención tanto con las reuniones como con el blog es expresar mis experiencias para que quien quiera las pueda compartir u opinar al respecto, y no deben ni tienen porque se compartidas por todo el mundo. Venga, creo que ha quedado claro ¿no? :-D

De vuelta al tema que nos trae aquí, en la última reunión de AgileCanarias celebrada ayer viernes se habló sobre las historias de usuarios. @yurenaghm hizo de facilitadora e introdujo el tema fantásticamente, proponiendo que le resolviésemos entre todos sus dudas e inquietudes al respecto.

Introducción a las historias de usuarios

Basándonos en la experiencia previa de otros grupos ágiles del panorama español, empezamos por aclarar que son las tres C y las cualidades INVEST de una historia de usuario.

Las tres C hace referencia a las partes básicas de una historia de usuario.

• Card: Indica que vamos a utilizar una tarjeta para escribir la historia de usuario. Esto no quiere decir que no se puedan utilizar sistemas electrónicos, aunque se prefiere el lápiz y el papel.
• Conversation: Es una parte fundamental e indica que antes de implementar la historia habrá que mantener una conversación con el cliente para obtener los detalles.
• Confirmation: Crearemos una serie de tests de aceptación que nos permitirán determinar si el cliente estará de acuerdo o no con la funcionalidad aportada. Además se requiere de la confirmación por parte del cliente para dar dicha historia por concluida.

Por otro lado el acrónimo INVEST hace referencia a las cualidades deseables en toda historia de usuario:

• Independent: Las historias deben ser descritas de forma independiente unas a otras, o en otras palabras, cualquier historia debe poder ser la siguiente a implementar. Veremos que en el mundo real esto puede no ser siempre tan fácil de decir como de hacer.
• Negotiable: Una historia es la promesa de que se mantendrá una conversación, pero no es un contrato vinculante.
• Valuable (to the customer): Toda historia debe tener valor para el cliente evitando las historias técnicas, como bien indicó @carlosble en la reunión. Esto es importante porque yo tiendo a mezclar un poco tareas con historias de usuarios, aunque modifique el texto para que no lo parezca sigue siendo una tarea técnica y eso no es deseable.
• Estimable: Es simple, una historia debe poder ser estimada con cierta facilidad, pero es un concepto abstracto, por eso se recomienda que las historias sean pequeñas facilitando la característica de que sea estimable.
• Small: En este punto yo me voy a quedar con la opción de que la historia debe ser lo suficientemente pequeña para entrar en una iteración, de esta forma se evita un poco la discusión de ¿cuánto es pequeña?.
• Testable: Es obvio, debe existir una regla, parámetro, test ... como quieras llamarlo, que permita saber cuando una historia está completa.

Historias de usuarios VS Casos de uso

Una vez finalizada la introducción, @chozero realizó una pregunta que genero un buen debate acerca de las historias de usuario y los casos de uso, a grandes rasgos aparecen las siguientes conclusiones:

• Un caso de uso puede almacenar información acerca de un cliente que la historia de usuario no, tampoco es para lo que se quiere una historia de usuario.
• Una historia de usuario fuerza una conversación con el cliente, mientras que el caso de uso es una análisis que una vez finalizado rara vez se modifica.
• Un caso de uso no puede ser testeado como una historia de usuario.

¿Significa que uno es mejor que otro?, no. Son herramientas distintas y útiles en función de como las utilices. Yo personalmente defiendo los casos de uso solo cuando pertenecen a una documentación viva que evoluciona con el proyecto hasta su finalización, y no cuando se usan al estilo waterfall para definir lo que hay que construir sin posibilidad de cambio.

Creo que otra conclusión pudo ser que waterfall le ha hecho mucho daño a los casos de uso :-)

NOTA: En este punto @pgonyan recomendó "Writting effective use cases" de Alistair Cockburn como una lectura interesante.

Caso práctico

Para entrar en materia yo empecé haciendo de cliente, pero surgió una cuestión interesante, mi sistema que era un sustituto de Jira se prestaba mucho a cosas como, "Jira ya te resuelve ese problema". Eso es correcto, si ya existe algo que hace dicha tarea, ¿para qué reinventar la rueda?. Esto ocurre porque probablemente, antes de entrar a saco con historias de usuario debíamos haber realizado un Agile Inception Deck, de manera que debates como este no tendrían lugar en este punto, porque ya habría quedado claro si el cliente necesita de verdad el producto o no.

Después de intentar reorientar el tema, @chozero hizo de cliente y la cosa empezó a marchar un poco mejor. Después de estar debatiendo largo y tendido y que saliesen algunas historias de usuario ... lamento decirlo pero se acabó el tiempo :-S

Salieron algunas historias y se habló un poco de como priorizarlas y estimarlas, pero muy por encima. Creo que es un tema que requiere mucho tiempo y como ya propuso José Manuel Beas, en el post que referencio anteriormente, sería una idea estupenda hacer un User Stories Retreat :-) te apoyo totalmente en esta idea tío!!! (nota mental: ¿sería interesante una sesión de User Stories Dojo en la AOS2011?)

Y con esto y un bizcocho hasta la próxima reunión que tratará sobre: ¿Cómo medir la calidad del código? .. pedazo de ladrillaco les voy a soltar a los que acudan a esa :-D