Sobre Historias de Usuario debe haber, a ojo, una decena de post en el blog, te dejo algunos de los que me gustan más al final de este, por si quieres continuar leyendo sobre el tema.
Y, a pesar de haber muchos post, el tema me sigue dando para muchos y muchos más. Y es que las supuestas Historias de Usuario, las Historias de Usuario sospechosas, son un coladero para mantener el «Cascada Lifestyle» (estilo de vida cascada) vistiéndolo de Ágil.
Una clase mía grabada hablando de la idea de Historia de Usuario, hay más clases en el canal de YouTube del blog
Así que, de vez en cuando, como hoy, escribiré un post, un capítulo más, de «Historias de Usuario sospechosas».
Como «disclaimer» antes de que sigamos, puedes, por supuesto, no hacer caso a nada de lo que te cuente ahora (o en otros post) y tener un modelo de trabajo súper potente, feliz, y que no es Ágil (aunque es difícil en estos tiempos). Y puedes haber empezado con cosas como las que cuento aquí (o en otros post) y haberlas evolucionado, cosa que suena muy bien (aplícate el Shuhari). Pero, en cualquier caso, lo que yo te voy a contar son cosas que suenan muy raras, muy raras, muy dudosamente ágiles, cosas como…
Que una Historia empiece por «Como Product Owner quiero…»
La Historia de Usuario me mira. Yo la miro a ella. Jugamos con las miradas. Ahora sé que me está engañando…
El juego que habrá dado, y seguirá dando, el famoso formato «Como <rol> quiero <funcionalidad> para <cuál es el beneficio que obtengo con ello>», cuyo objetivo inicial era forzarnos a que las Historias tuvieran un <rol> a quien ofrecer su funcionalidad (evitando caer en colar Tareas por Historias) y que pensáramos al hacerlas en el beneficio que obtenía ese rol con esa Historia, pensar en el valor, en ese para <cuál es el beneficio que obtengo con ello>.
Hay muchas retorcidas y canallas maneras de retorcer el «Como <rol> quiero…», pero entre todas ellas destaca el… «Como Product Owner quiero…»
¿Cómo que como Product Owner quiero? Pero vamos a ver, si una Historia es un incremento de valor a un producto (ojo, en un desarrollo software o en otra índole) será un futuro usuario (o algún rol más específico que encaje dentro del rol de usuario) de la Historia el que quiera esa funcionalidad… no tú. Es que hay que pensar en el incremento de valor funcional (que una Historia es funcional) al usuario, no en el «yo quiero» ¿Cómo que yo quiero?
Yo reflexionaría sobre los formatos, porque nos gustan mucho los formatos, así no tenemos que pensar y ya tenemos una regla que seguir y que piensa por nosotros. La idea de las Historias era un muy pequeño aporte de valor funcional (no una tarea como hacer Testing u otra), y como es aporte de valor es… a un usuario del producto (sea cual sea el producto).
Ya estoy viendo a más de uno, después de leer este post, remplazando automáticamente en Jira (Buscar – Remplazar) los «Como Product Owner quiero» por «Como Usuario quiero», ay, que duro es esto…
Otros post sobre Historias de usuario y el Reverso Tenebroso
Cuidado con la frase “escribir historias de usuario” que puede ser peligrosa
¿Por qué las Historias de Usuario deben ser lo más pequeñas posible?
La importancia de llamar a las cosas por su nombre
50 sombras (Ágiles) de Jira).
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
Jejejeje No soy de los que corrieron a «reemplazar» en JIRA, pero si de los que se sentaron a re-plantear el uso del formato, por que hasta ahora le habia visto un beneficio y un valor a esos 3 componentes de la descripción, pero si es cierto y entiendo, que pueden aparecer historias de usuario sospechosas y del lado oscuro de la fuerza, en especial por que es dificil por ejemplo definir completamente el beneficio que podría recibir o percibir un usuario con cada entrega de nuevo valor, pero entonces «Nota Mental: Revisar y discutir con los equipos, el valor o no que otorga la estructura de las historias de usuario»
Como responsable funcional quiero migrar a una arquitectura basada en microservicios para mejorar el rendimiento y poder introducir nuevas funcionalidades ahorrando tiempo y pruebas.
¿Empezariais un proyecto de este tipo (migracion arquitectura), con esa historia de usuario? A partir de esta saldrian historias hijas con la funciomalidad que se va a migrar.
Respecto a la documentacion asociada a este proyecto, la idea es convertir las historias actuales y aglutinarlas en un documento con requisitos funcionales y no funcionales (utilizando enterprise architect) para planificar el orden en el que se migraran las funcionalidades. Es posible que tambien se elabore un diagrama SIPOC con el objetivo de comprender mejor las necesidades y funcionalidades actuales.
Gracias por tus maravillosos posts y por compartir tu sabiduría!