sábado, noviembre 26, 2016

¿Vale la pena ser precisos a la hora de escribir una historia de usuario?

Hola a todos 

Este tema es un pendiente a resolver de los entrenamientos y equipos a que he tenido la fortuna de acompañar.

En los entrenamientos de ágil se insiste en la necesidad de la conversación cara a cara, tanto cuando se explica el manifiesto agil, como cuando se "juega" la construcción del requisito especificado y el colaborativo (1).

Y los creadores del concepto de historias del usuario invitan a maximizar el contacto entre el usuario (o Product Owner,  en el caso de Scrum) y el equipo teniendo la excusa de una "necesidad" mal especificada.

Algunas frases de estos referentes son.
  • No sigamos especificando historias y comencemos a explicarlas (Jeff Patton) 
  • Prefiero una historia ambigua que una bien especificada,  la primera requerirá explicación mientras la segunda no. (debo la referencia) 
  • Una historia de usuario debe ser tan pequeña que requiera ser explicada (debo la referencia) 
  • Si una historia de usuario no cabe en media hoja,  trata de escribirla en un papel más pequeño. (debo la referencia) 
  • Debe ser suficiente con un título y un wireframe explicado (Jeff Patton) 
  • No entiendo por qué insisten en usar un formato (uno de los creadores de XP al referirse al formato propuesto por Mike Cohn: YO COMO ROL,  DESEO FUNCIONALIDAD, PARA UN BENEFICIO DE NEGOCIO)
  • son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, (debo la referencia)

La verdad en mis entrenamientos enseño las 4 formas que conozco  de trabajar historias de usuario:
  • un solo titulo 
  • un título más un wireframe o boceto 
  • el formato de MIke Cohn: YO COMO ROL,  DESEO FUNCIONALIDAD, PARA UN BENEFICIO DE NEGOCIO; más los criterios de aceptación,
  • o la anterior forma pero con los criterios de aceptación escritos en formato Gerkin (Given, When, Then - Dado, Cuando, Entonces), propuesto por Dann North.

Con los consabidos tips:
  • que la historia de usuario tome de 3 a 5 días en lograr la definición de terminado (o  de DONE)
  • que tenga máximo 6 criterios de aceptación (tendiendo a menos no a más) 
  • un buen Sprint Backlog debe contar entre 6 y 10 historias de usuario,  tendiendo al número mayor o más y todas en lo posible de tamaño uniforme.


Por último,  recordemos que las historias de usuario buscan maximizar la comunicación,  independientemente de  lo que usemos como formato desde que estás sean explicadas por el cliente o Product Owner y el equipo las comprenda logrando una confirmación de ellas (PRINCIPIO DE LAS CCC: CARDS CONVERSACIÓN Y CONFIRMACIÓN (2)) la tarea estará bien hecha y habremos logrado el propósito de esta práctica.

Lo que funcione será lo mejor,  hagamos inspección y adaptación, y no nos detengamos de buscar mejores formas de hacer las cosas y de hacer software.

Saludos ágiles
Jorge Abad


Notas, aclaraciones, comentarios y referencias

  1. Juego en el que los participantes se dividen en parejas y unos son los especificadores y los otros los artistas,  y los especificadores durante un timebox de 10 minutos describen de forma escrita (y aislada) un dibujo,  luego esta especificación se le entrega a los artistas y durante un tiempo igual construyen lo especificado (los resultados no son muy satisfactorios en algunos casos,  o la mayoría dependiendo del dibujo o la habilidad de las personas para escribir o interpretar),  y luego durante un tiempo igual de 10 (luego de intercambiar los roles)  los nuevos especificadores de forma colaborativa (y conjunta) le dictan un dibujo más complejo sin dejarlo ver a los artistas,  los resultados son asombrosos: menos tiempo, mayor calidad del dibujo y por ende mayor satisfacción.
  2. Adicional el criterio INVEST

No hay comentarios.:

Publicar un comentario