Autor: Alejandro Cruz Rojas Sígueme en LinkedIn
Una breve historia
La historia de las historias de usuario se puede resumir de la siguiente manera:
- Año 1998: Las historias de usuario se atribuyen comúnmente a Kent Beck, uno de los autores del Manifiesto Ágil. Beck estaba trabajando en el desarrollo de software en el contexto de Extreme Programming (XP) y propuso un enfoque orientado al usuario para describir requisitos. Aunque la terminología específica «historias de usuario» no se utilizó en ese momento, la idea de centrarse en las necesidades y perspectivas del usuario final estaba presente.
- Años 2000-2010: Las historias de usuario ganaron popularidad como parte de las prácticas de desarrollo ágil, particularmente en el marco Scrum. A medida que más equipos adoptaron metodologías ágiles, las historias de usuario se convirtieron en una forma estándar de describir requisitos y funcionalidades.
- Año 2011 en adelante: Las historias de usuario se han refinado y diversificado en su estructura y uso. Las organizaciones y equipos han adaptado las historias de usuario para satisfacer sus necesidades específicas, y han surgido herramientas y prácticas para gestionarlas de manera eficiente.
¿Qué son las historias de usuario?
Una historia de usuario es un formulario breve, que describe un requerimiento. En teoría, debe ser llenado por un usuario y debe expresar lo que requiere en términos de su contexto (su proceso y sus necesidades dentro de ese proceso). La figura describe su estructura habitual.
Premisas del enfoque
Sobre el usuario o Producto Owner
Este enfoque presupone que un usuario (o un product owner, en un esquema ágil):
- Tiene la suficiente claridad al respecto de los procesos en los que participa
- Ha diagnosticado correctamente un problema y tiene claro que éste, se puede resolver mediante la aplicación de las tecnologías de información.
- Puede identificar qué casos de uso requiere que sean implementados.
- Comprende que su proceso cambiará una vez que se implemente su requerimiento y sabe qué ajustes habrá de hacer.
- Tiene el entrenamiento y las capacidades de comunicación adecuadas para redactar, de modo concreto y específico, sus necesidades en términos que un equipo técnico pueda comprender.
Sobre el equipo técnico (el lado de «sistemas»)
Así mismo, se asume que el equipo técnico:
- Tiene el conocimiento suficiente sobre los procesos de su cliente.
- Comprende las necesidades existentes detrás del requerimiento descrito en la historia de usuario
- Dado su entendimiento, puede identificar falencias y ajustes necesarios en el requerimiento
- Entiende muy bien las aplicaciones involucradas, sus dependencias y estado actual, de modo que es capaz de retroalimentar y enriquecer la historia de usuario
La realidad supera la fantasía
En mi personal experiencia (y entiendo que puedan existir excepciones) he observado que:
- El usuario (o product owner) designado para definir historias de usuario difícilmente tiene dominio sobre su propio proceso de negocio. En muchos casos he observado que incluso se asigna esta responsabilidad a usuarios con responsabilidades menores en el proceso del cliente.
- En algunas ocasiones este rol no cuenta con el peso organizacional que le permita definir las prioridades de implementación en términos de lo que más requiere el negocio o de retornos de inversión.
- Lamentablemente es habitual que tengan algo de aversión a la tecnología o que la perciban como algo intimidante.
- La contraparte dentro de sistemas tampoco conoce los procesos de negocio de su cliente. (Es curioso que a lo largo de muchos años impartiendo seminarios de ingeniería de requerimientos, en poquísimas ocasiones he encontrado a responsables de aplicaciones que dominaran la interrelación entre sus sistemas y los procesos de su cliente)
- Se han creado perfiles especializados en sistemas que no tienen suficiente dominio en los aspectos más técnicos de las aplicaciones. Por ello, tienden a dejar demasiados huecos a la hora de validar y retroalimentar las historias de usuario con sus clientes.
¿Tiene solución?
La buena noticia es que existen técnicas formales para resolver este problema. Hay técnicas que complementan las historias de usuario y que bien usadas pueden mejorar significativamente la ingeniería de requerimientos.
Flujo de trabajo recomendado
El flujo de trabajo adecuado podría ser:
- Llenar una historia de usuario (adelante propongo una versión mejorada) que sirva como punto de partida para poder identificar el o los procesos de negocio involucrados
- Levantar modelos de proceso de alto nivel (no deben ser demasiado detallados para no perder el foco ni la paciencia de los involucrados -especialmente la de los patrocinadores). Esto debe hacerse con una buena técnica que permita sincronizar entrevistas con la elaboración de modelos de procesos (los modelos deben de ser de una complejidad razonable)
- Los modelos de procesos deben alcanzar para contextualizar la historia de usuario. Contextualizar significa que podemos identificar qué subprocesos debemos analizar a mayor detalle para pode hacer un diagnóstico de la situación problemática a resolver (aquí es importante no trivializar)
- Lo siguiente será hacer modelos de mayor detalle de los subprocesos en su estado actual, a fin de identificar la situación problemática (en muchas ocasiones el dolor está en un sitio, pero el origen está en un lugar distinto)
- Hacer un diagnóstico y validarlo usando las evidencias encontradas y los modelos de procesos. La validación deberá ser hecha con los involucrados relevante
- Si se logra un consenso, sigue hacer una propuesta y reformular la historia de usuario para que describa el verdadero problema y solicite una solución acorde al diagnóstico.
- La historia de usuario reformulada pasará a las siguientes etapas del diseño técnico de la solución. Este proceso típicamente involucra: plantear diseños de interfaces de usuario, rediseño de flujos de trabajo del usuario, propuesta de casos de uso y diseño de la arquitectura de información necesaria (a grandes rasgos).
Para cada una de estas actividades tenemos una o más técnicas de gran valor.
Un ejemplo: Cómo mejorar la historia de usuario
El problema
En mi opinión, muchos de los problemas son de índole técnico. Se trata de encontrar la manera de enriquecer una técnica para hacerla más precisa, o más simple de usar (o las dos cosas).
Las historias de usuario, como las conocemos dan libertad de hacer una descripción amplia de una necesidad. Esta amplitud es un problema porque no permite focalizar cómo es que un usuario percibe una necesidad. Parte de una pregunta demasiado compleja en términos de alcances: ¿Qué necesitas?
La propuesta
Si consideramos que:
- un usuario trabaja desempeñando varios roles (un contador puede estar jugando el rol de auditor de pagos, registrador de pólizas, pagador de impuestos, etc.)
- cada uno de esos roles se define en términos de responsabilidades concretas (el pagador de impuestos tiene como responsabilidades calcular las cantidades mínimas a pagar dentro de la ley, pagar oportunamente los impuestos y resolver requerimientos de la autoridad tributaria -entre otras-)
Podemos acotar la pregunta original a una como esta: Trabajando con el rol de “pagador de impuestos” y con la responsabilidad de “resolver requerimientos de la autoridad tributaria” ¿Qué necesitas que haga el sistema y qué beneficio esperas obtener?
La respuesta se hace mucho más concreta. Además, es mucho más simple identificar los procesos que hay detrás del requerimiento. Todo esto, agregando dos rubros a la historia de usuario: el rol y la responsabilidad.
A mi me gusta agregar un rubro más: el beneficio de negocio. Para que sea fácil de usar, lo planteo con el nombre de “de modo que”. En la figura siguiente muestro un par de ejemplos.
Conclusiones
- No basta con una sola herramienta para tener un proceso de ingeniería de requerimientos que sea exitoso.
- Cada técnica es mejorable
- Hay técnicas disponibles para mejorar nuestros procesos de requerimientos
- La mejor estrategia es tener usuarios y técnicos hablando el mismo idioma a partir del uso de técnicas y de un buen entrenamiento.
Seminario de Ingeniería de Requerimientos