historias de usuario II

Entes ágiles vivos

Primitivo Cachero (@primicachero)

 

Continuamos aplicando valor a las historias de usuario creadas:

(Te recordamos el primer artículo de Historias de Usuario I)

Negociable

Las historias son negociables, son breves descripciones de la funcionalidad deseada por el cliente. Los detalles han de ser negociados en una conversación entre el cliente y el equipo. No se incluyen todos los requisitos muy detallados, pero si recordatorios y detalles imprescindibles. Un detalle extra sobre una historia nos puede hacer pensar erróneamente en la precisión adicional. Pero dichas especificaciones iniciales solo nos crearán complicaciones y más trabajo a futuro. El correcto funcionamiento de una historia de usuario debería de ser:

  • Una frase o dos que actúan como recordatorio para mantener una conversación entre equipo y cliente.
  • Notas sobre cuestiones que deben ser resueltas en dicha conversación.

Aquí surgirán detalles sobre las cuestiones a tener en cuenta, y dichos detalles se convierten tras las conversaciones en pruebas de la historia de usuario. Dichas pruebas son pruebas funcionales para demostrar si funciona como el cliente esperaba.

Valioso

El término valioso nos plantea muchos problemas, ¿Porqué?, Pues porque tenemos valores distintos, una historia puede ser valiosa para el equipo y no para el cliente, o puede ser valiosa para el cliente pero no para el usuario final. Hay que tratar siempre de evitar historias que solo sean valoradas por él equipo, puesto que el fin último es dar valor al cliente.

Hay que tratar de no tener historias técnicas como muestro en el siguiente ejemplo:

  • Todas las conexiones a la base de datos son a través de un pool de conexiones.
  • Hasta 50 usuarios deben ser capaces de utilizar la aplicación simultáneamente.

Tienen que ser más abstractas, no técnicas, para que el usuario pueda considerar correctamente el valor que le aporta. Hay que tratar de que sea el cliente el que escriba dichas historias, porque las escribirá en el lenguaje que a él le aportan valor. Los clientes se sentirán incómodos con esta nueva circunstancia porque pueden pensar que se les volverá en contra, situaciones del tipo, "bueno, el requisito no dijo ..". Hay que hacer que el cliente comience a sentirse cómodo con el concepto de que las historias son un recordatorio del que hablar más tarde, en lugar de compromisos formales o funcionalidad específica.

 Estimable

Es importante que en el equipo sean capaces de estimar o al menos tener una pista de la complejidad de cada historia. Pero pueden surgir problemas cuando:

  • El equipo carece de conocimiento del dominio.
  • El equipo carece de conocimiento técnico.
  • La historia es demasiado grande.

Si el equipo carece del conocimiento del dominio, debería de discutir con el cliente que escribió la historia, aprender con el cliente. No es necesario conocer todos los detalles, pero si un conocimiento general de qué desea el cliente y porqué desea esa historia el cliente.

En segundo lugar, una historia puede tener problemas de estimación por una tecnología no conocida. Una forma de estimar este tipo de historias es dividirlas en dos, con una primera parte de la historia que sea de time box - caja de tiempo para aprender y comprender la tecnología y facilitar la estimación de la siguiente o siguientes historias que involucren a dicha tecnología. La primera historia sirve para reunir información rápidamente y la segunda historia sirve para hacer el trabajo realmente.

Por último, el equipo puede no ser capaz de estimar una historia demasiado grande. Para poder llegar  a estimar esta historia el equipo, deberá desglosar en más pequeñas.

Finalmente, en la próxima entrega veremos historias de usuario pequeñas, sencillas, combinables y comprobables. 

¡Sigue Leyendo, último articulo!