 |
| Imagen tomada de Pixabay |
Las historias de usuario no son para
escribirlas
La pregunta que debes hacer no es “¿cómo escribir mejores
historias de usuario? El objetivo no debe ser escribir historias de usuario. Cámbiala
más bien por ¿cómo mejorar mis conversaciones con historias de usuario? Las
historias de usuario son un instrumento de comunicación social y sabemos que la
forma más efectiva de comunicar información es la conversación, ojalá cara a
cara. La forma más efectiva de evolucionar las historias de usuario es vía
conversaciones, primero entre los usuarios e interesados y el Product Owner
y luego, entre este y los miembros del equipo.
Puedes leer mi artículo Las
historias de usuario como instrumentos de negociación para saber más
sobre este tema. Clic aquí
para leerlo.
Las historias de usuario te ayudan a
encontrar tu por qué
Las historias de usuario son una herramienta para iniciar
el descubrimiento del producto con el usuario, consumidor o cliente, no es para
finalizarlo. De esta manera, tanto el Product Owner, como los
desarrolladores (quienes hacen el trabajo finalmente) deberían ver las
historias de usuario como algo que describe el por qué están haciendo lo que
hacen, no precisamente qué están haciendo. Como siempre, si un usuario no
estuvo involucrado en el descubrimiento y desarrollo de las historias de usuario,
estas quizás no sean historias de usuario del todo; quizás sean más bien “quimeras
imaginadas”.
Conoce a los usuarios
Por eso, mi primerísima recomendación, concisa, si eres responsable
de las historias de usuario, es: habla con las personas que tienen la necesidad,
el problema, indaga por el problema detrás del problema, la causa raíz. Esto aumentará
tu comprensión de lo que se necesita y por qué. Acompaña esta práctica con un
conocimiento profundo y empático del usuario o consumidor: quién es, qué hace,
con quién lo hace, qué información intercambia y cómo lo hace, son algunas de
las cuestiones a escudriñar si quieres tener éxito con historias de usuario.
En mi artículo Qué
hay de "usuario" en las historias de usuario profundizo sobre
este asunto. Clic aquí
para leerlo.
Las historias de usuario y el product
backlog
Una historia de usuario no está sola, aislada del resto
del producto. Así que es importante pensar sobre ella como un componente de
primer orden del product backlog. Y en este punto, es de mucha
importancia considerar la transparencia del backlog. Recordemos que
transparencia significa que todos los interesados, usuarios y equipo comparten
el mismo significado de las cosas, por ejemplo, qué significa que algo está
terminado.
Las cosas así, las historias de usuario deben ser
transparentes y estar disponibles para todos los interesados, para que estos
tengan visibilidad de lo que está haciendo el equipo, en qué orden y por qué.
En particular, resuelve preguntas como:
- ¿Los interesados saben cómo acceder a las historias de
usuario?
- Cuando acceden a las historias de usuario, ¿el
contenido los ilustrará o los confundirá?
En mi artículo El
extraño caso de las historias de usuario técnicas pongo de manifiesto
que una “historia de usuario técnica” es una práctica disfuncional. Clic aquí
para leer el artículo. Este otro artículo también te puede dar ideas al
respecto: Buenas
y “malas” historias de usuario. Clic aquí
para leerlo.
Desarrollo de producto dirigido por hipótesis
y experimentos
Las historias de usuario son hipótesis. Trátalas como
tal. Haz experimentos y comprueba esas hipótesis. La última línea de defensa es
el consumidor final, el usuario. Mientras tanto, no dejarán de ser eso precisamente:
supuestos o conjeturas. En este apartado entran en escena las entregas tempranas
y frecuentes y, sobre todo, la retroalimentación directa que logres de los
clientes o usuarios. Es de esta manera que podrás adaptarte al entorno y tomar
mejores decisiones en el futuro inmediato que beneficien a los usuarios. Para
lograrlo, tus historias de usuario deben ser realmente pequeñas. Piensa que
solo tienes algunas horas para implementarlas o construirlas, hasta unos muy
pocos días, dos o tres a lo sumo.
En este apartado, una anotación especial para desarrolladores
de software: si todavía te encuentras con el escenario de “mini cascadas”, es
decir, primero un “subequipo” desarrolla la historia y luego otro “subequipo”
prueba la historia, entonces tus historias de usuario deben ser aún más pequeñas.
No te imaginas cómo sufren los analistas de prueba mientras esperan a que
desarrollo les entregue las historias para empezar a probar cuando el final del
sprint ya está encima. Como siempre, el mejor antídoto contra todo esto, es empezar
a cambiar radicalmente las técnicas de desarrollo, incursionando en TDD, BDD y automatización,
entre otras. Pero tengo que confesarlo, esto es más fácil decirlo que hacerlo.
Por eso hago toda esta recomendación especial.
Quieres saber más
Estos y otros temas de interés hacen parte de mi curso de
historias de usuario. En febrero estaré facilitando una nueva edición del curso.
Toda la información en https://bit.ly/cursohu.
