Habrá muchas más, pero si hay una buena práctica típica Ágil que cuesta mucho que se lleve a cabo medianamente bien es la de… las famosas Historias de Usuario. Cuestión que podría generalizarse a qué va en un Product Backlog (tema que ya tratamos en la serie de post cualquier cosa que pida un cliente, y pague por ello… ¿Va al Product Backlog? ¿Qué va a un Product Backlog? (1/2))
En estos últimos tiempos no tanto, pero de hace tiempo hay muchos post en el blog hablando sobre Historias de Usuario. Aunque, siendo rigurosos (si que haya un necesario rigor prescripitvo), un Product Backlog contiene Items, que es muy genérico, lo típico es que el concepto de Historia de Usuario (como un tipo de Item) ayude a centrar si lo que hay en un Product Backlog tiene buena pinta.
Los principales problemas que me suelo encontrar aquí son los siguientes:
- Historias que no son Historias, son Tareas (un cómo en vez de un qué), por lo que no son un «end to end» que terminado aporte valor por sí mismo a un usuario.
- Historias que son excesivamente grandes (¿Por qué las Historias de Usuario deben ser lo más pequeñas posible? y estrategias para descomponer y hacer pequeñas historias de usuario)
Superados los anteriores, podríamos entrar en el Valor que aportan, sin se pueden probar, si el formato clásico para escribir Historias es el más apropiado (Shu-Ha-Ri), si aplica más la idea de By Example, los DoD, los DoR, etc. Pero la realidad es que, la mayoría de las veces, no llegamos a estos puntos porque no pasamos de los dos que te contaba antes.
El problema se acentúa aún más cuando entras en entornos que están aplicando Agilidad y no son puramente de desarrollo software. Ahí se hace más fuerte el síndrome del “Es que nuestro caso es especial, somos diferentes”, no podemos hacer Historias (o llamamos Historia a cualquier cosa que, sin serla, se meta en un Product Backlog).
Uno de esos entornos, entre otros tantos, que tiene su especial «lucha» con las Historias de Usuario es el de BI (Business Intelligence), donde el principal argumento es que «lo que hacemos lleva mucho tiempo, semanas, como para poder aplicar la idea de Historia de Usuario», que suene ser algo pensado para terminarse en días (en los post previos que te cité trato más este punto del tamaño de las Historias).
Si es tu caso, para darte esperanzas en la lucha, a día de hoy, aún no me he encontrado una situación en BI en la que, funcionalmente, analizando el caso, explicando bien el concepto, no se pudiese trabajar con Historias de Usuario de las de verdad. Si ha sido imposible que sean pequeñas no ha sido por problemas de carácter funcional, ha sido por problemas de tecnología «legacy», externalizaciones y silos, y cosas del estilo.
Hay mucho material por ahí de cómo descomponer grandes Historias (que probablemente por eso no sean Historias), y no era objeto de ese post tratar el detalle de las descomposición (hay un post antiguo, de carácter general, que trató esto, el de estrategias para descomponer y hacer pequeñas historias de usuario). Pero que sepas que… raramente es imposible por naturaleza funcional no poder descomponer funcionalidad en Historias (también en BI).
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Totalmente de acuerdo contigo Javier. Y más en el caso de BI.
Hola, Javier
Podrías proponer algunos ejemplos de historias de usuario reales para un sprint de un equipo de BI? Podría ser bastante útil.
Me interesa sobre todo que sean relacionadas con el diseño, desarrollo de un de un Datawarehouse.