Cuidado con la frase «escribir historias de usuario», que puede ser peligrosa

Las palabras son peligrosas, muy peligrosas, muchas veces revelan lo que pide nuestro subconsciente luchando contra nuestra consciencia (e incluso luchando contra la moda y la opinión pública).

Al igual que «escalar agilidad» es peligroso, porque induce a «añadir», cuando la mayoría de las veces «hay que quitar», más correcto sería «des-escalar agilidad», y ello lleva a muchos a meter y meter procesos y cosas que poco ágiles son (no voy a entrar en algunos frameworks de escalado que ejem…), «escribir historias de usuario» indice a eso… a escribir.

Y si me pongo a «escribir» mucho texto en una historia de usuario, que te quede que claro… ¡ya no es una historia de usuario!, es un requisito camuflado (ojo, de esta parte ya te hablé en ¡2011!, aquí… La historia de usuario no es el “requisito” de las metodologías ágiles), de los de toda la vida, y te has cargado una de las principales esencias de la historia: reducir documentación escrita por interacción y hablar.

Claro, todo aquel al que he escuchado (y te aseguro que son much@s) lo de «hay que escribir mejores historias de usuario» porque «tenemos problemas al implementarlas / de entendernos con los Stakeholders / x» comienza, sin no lo remedia (o lo remedio a tiempo yo) un camino hacia el Lado Oscuro.
chucknorries_user_stories
Al igual que el que quiere bajar de peso y ponerse en forma, muchas veces cae en la diera milagro que nunca funciona, el crece pelo universal, o aprende inglés con 1000 palabras. Mejorar historias de usuario «escribiendo más» tiene la misma pinta.

La solución buena para bajar de peso y ponerse en forma… hacer ejercicio. La solución para tener buenas historias de usuario no es escribir, es hacerlas bien.

Que sean lo más pequeñas posibles

Hay varias cosas esenciales para escribir tener buenas historias de usuario, algunas ya las comentamos hace tiempo. Por ejemplo, que sean lo más pequeñas posible (sobre esto también te puede venir bien estrategias para descomponer y hacer pequeñas historias de usuario).

Sé que es más difícil hacer historias pequeñas que escribir una parrafada, pero esto es así.

Trabaja bien la aceptación

Cosas como los ATDD, BDD (¿ATDD? ¿BDD?… ¿Cómo? Aclarando el lío de siglas en Testing), Gherkin, etc. Incluso trabajar un buen DoD (que, de nuevo, no es meterse a hacer un checklist infinito) mejorar la historia sin meter parrafadas.

Nunca olvides que… “A story card is a promise for a conversation»

Hace un montón de años, casi 20, Alistair Cockburn creo aquella frase de “A story card is a promise for a conversation», la traducción vendría a ser algo así como que una historia de usuario es una promesa de que tendremos una conversación.

La historia de usuario se pensó para dejarnos un recordatorio, para que cuando le llegase su turno cogiéramos el posit de turno y fuésemos a ver al Product Owner, o al cliente, y le digamos que «vamos a ponernos con esta historia ¿qué es lo que querías?». Todo lo contrario a una especificación, requisito, o mucha documentación, que se hacen para que una vez escritos no tengamos que volver a molestar al cliente y tengamos ahí, en el documento, toda la información necesaria.

Te lo habré contado alguna vez, Ron Jeffries comentaba que una historia no es sólo una descripción de una funcionalidad, normalmente en un post-it, una historia de usuario además está formada por otras dos partes más:

  • La conversación que conllevan, ya que son una herramienta para interactuar.
  • El cómo se confirma su implementación, las pruebas y verificación de la misma.

Más info…

Te dejo otros post sobre estos temas que creo que te serán interesantes:

4 comentarios en “Cuidado con la frase «escribir historias de usuario», que puede ser peligrosa”

  1. Hoy me pillas dividido entre darte la razón y quitártela. Yo creo que no es tanto como evitar escribir y sustituirlo por hablar, como evaluar el coste de escribir vs el valor que nos proporciona. En ocasiones una frase nos bastará para describir la historia. En otras será recomendable pararse 5 o 10 minutos y escribir algo parecido a un requisito. No siempre tendrás a mano al usuario o cliente para preguntarle. No siempre podrás asegurar que a quien le han contado lo que se necesitaba, estará allí cuando se empiece a programar.
    No es escribir por escribir extensos documentos de análisis funcional y diseño técnico. Pero tampoco es cogerle asco a escribir y escudarse en que somos ágiles para evitar escribir.

  2. Hola,
    en primer lugar felicitarte por tu blog, creo que es muy interesante.
    Leyendo tu artículo me surge alguna duda debido a experiencias que he tenido. Si la US solo es una descripción de alto nivel y no contiene una especificación detallada, que ocurre si tienes un negocio/PO que donde dijo digo dice Diego?
    Por ejemplo, una US puede ser algo así como «Como cliente quiero añadir el filtro fecha de nacimiento en la búsqueda de clientes para….». Quedarían muchas cosas en el aire, como si la fecha es un valor fijo o un rango, si es un campo obligatorio u opcional, si la selección de fecha se hace sobre un calendario o se introduce manualmente, etc…
    Entiendo que todos estos temas se aclararían durante la conversación y se añadirían a la US en los criterios de aceptación para terminar de definirla, no? Cuando se tendría esa conversación, antes de la planning? Si es así, la US yo la vería como una definición de requisitos. Si es después de la planning, el equipo DEV no podría avanzar mucho hasta aclarar esos temas con el PO y quiza el PO tenga que consultar a negocio lo que deja muy poco tiempo para un sprint de dos semanas y tampoco se podría estimar porque no se sabe que es lo que hay que hacer… Y finalmente, si esos detalles no se añaden a la US y solo son hablados, podría haber problemas en la demo porque el equipo DEV no entendiera bien lo que se quería o porque el negocio haya cambiado de idea y no esta escrito en ningún sitio su necesidad inicial…
    Muchas gracias por tu aclaración!
    Saludos,
    Kike

  3. De acuerdo, aunque considero que buena parte de lo que se requiere no es especificarla como un «requisito» de los clasicos, si no que al final se tenga claro a donde se esperaba llegar, y parte de eso pasa por los criterios de aceptación que pueda tener la historia.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba