Las historias de usuario (US) son de las herramientas más comunes para capturar y comunicar las necesidades del cliente. Sin embargo, es importante entender que las historias de usuario no son requisitos completos por sí mismas. En este artículo, exploraremos la naturaleza de las historias de usuario, la importancia de dividirlas adecuadamente y cómo el framework de las 7 dimensiones de un producto puede ayudar a obtener una visión integral de los requisitos.
¿Qué son realmente las historias de usuario?
A menudo se piensa en las historias de usuario como requisitos, pero en realidad son una aproximación a la parte funcional de un requisito. Siguen el formato "Como [rol] quiero [objetivo/deseo] para [beneficio]", que captura la esencia de lo que un usuario quiere lograr con el sistema. Sin embargo, las historias no especifican en detalle cómo debe comportarse el sistema o qué atributos de calidad debe tener.
Bajo este enfoque, se asume que la entrega del valor será flexible dado unas expectativas de los diferentes interesadps, por lo que se evita el compromiso tempranamente con requisitos detallados que podrían cambiar. También se espera que los deseos de los stakeholders evolucionen a medida que vean el producto desarrollado, por lo que mucho trabajo previo en definir requisitos exhaustivos podría desperdiciarse. De allí radica la importancia de dividir las historias de usuario para que sean efectivas, es decir, es imperativo dividirlas adecuadamente. Las historias demasiado grandes o complejas, conocidas generalmente como "épicas", deben desglosarse en partes más pequeñas y manejables. Esto permite que el equipo de desarrollo comprenda mejor los requisitos, pueda pronosticar con confianza y entregue valor de manera incremental.
Existe mucha bibliografía para dividir las historias, se pueden considerar diferentes aspectos como los pasos del flujo de trabajo, las reglas de negocio, los casos de uso felices y tristes, las opciones de entrada y plataforma, los tipos de datos o parámetros, las operaciones CRUD y los escenarios de prueba. Esto ayuda a obtener un conjunto de historias más detalladas y completas.
Fuente: https://www.humanizingwork.com/wp-content/uploads/2020/10/HW-Story-Splitting-Flowchart-ES.pdf
Tratar las historias de usuario como requisitos completos puede tener varias consecuencias negativas. A continuación, exploraremos algunas de las principales implicaciones de este enfoque erróneo.
- Pérdida de flexibilidad y adaptabilidad: Uno de los principios fundamentales del desarrollo ágil es la capacidad de adaptarse a los cambios y a las nuevas necesidades que surgen durante el proceso. Al tratar las historias de usuario como requisitos rígidos e inamovibles, se pierde la flexibilidad necesaria para ajustar el rumbo del proyecto según las retroalimentaciones y los aprendizajes adquiridos. Esto puede llevar a un producto final que no satisfaga plenamente las expectativas de los usuarios y del negocio.
- Enfoque en la documentación en lugar de la colaboración: Cuando las historias de usuario se consideran requisitos completos, existe el riesgo de caer en la trampa de la documentación excesiva. El equipo puede dedicar demasiado tiempo y esfuerzo a escribir especificaciones detalladas en lugar de fomentar la colaboración y la comunicación directa con los stakeholders. Esto puede generar malentendidos, suposiciones erróneas y una falta de alineación entre las expectativas de los usuarios y lo que se está desarrollando.
- Dificultad para priorizar y planificar: Las historias de usuario están diseñadas para ser granulares y enfocadas en incrementos de valor entregables. Al tratarlas como requisitos completos, se pierde la capacidad de priorizar y planificar de manera efectiva. Las historias pueden volverse demasiado grandes, complejas y difíciles de estimar, lo que dificulta la creación de un backlog manejable y la asignación de recursos adecuados.
- Limitación de la creatividad y la innovación: Cuando las historias de usuario se consideran requisitos estrictos, se puede restringir la creatividad y la capacidad del equipo para proponer soluciones innovadoras. Al centrarse únicamente en cumplir con los requisitos establecidos, se pierde la oportunidad de explorar alternativas y enfoques diferentes que podrían aportar mayor valor al producto.
- Dificultad para responder a los cambios y a las nuevas necesidades: En un entorno ágil, es común que surjan nuevas necesidades y cambios a medida que avanza el proyecto. Si las historias de usuario se tratan como requisitos fijos, se vuelve más difícil incorporar estos cambios de manera fluida. El equipo puede sentirse atado a los requisitos originales y tener dificultades para adaptarse a las nuevas circunstancias, lo que puede resultar en un producto que no satisfaga las necesidades reales de los usuarios.
- Enfoque en la entrega en lugar del valor: Al tratar las historias de usuario como requisitos, existe el riesgo de centrarse más en la entrega de funcionalidades específicas que en el valor que aportan al usuario y al negocio. El equipo puede perder de vista el propósito y los objetivos generales del proyecto, y enfocarse simplemente en cumplir con los requisitos establecidos, sin evaluar si realmente están generando el impacto deseado.
- Dificultad para involucrar a los usuarios y obtener retroalimentación: Cuando las historias de usuario se consideran requisitos completos, puede haber una menor participación de los usuarios y los stakeholders en el proceso de desarrollo. Si se asume que los requisitos ya están completamente definidos, se pierde la oportunidad de obtener retroalimentación continua y de ajustar el rumbo del proyecto según las necesidades y preferencias de los usuarios.
¿Alguna recomendación?
Actualmente acompaño a par de equipos en elevar su excelencia técnica, y me gusta mucho utilizar el framework de las 7 dimensiones de un producto, propuesto por Ellen Gottesdiener. Es una herramienta poderosa para asegurar que se cubran todos los aspectos importantes al dividir las historias de usuario. Este framework considera siete aspectos clave que abarcan tanto los requisitos funcionales como los no funcionales de un producto. A continuación, profundizaremos en cada una de estas dimensiones y cómo contribuyen a crear historias de usuario más completas y efectivas.
- Usuario (User): La dimensión de Usuario se enfoca en identificar quién interactuará con el producto. Esto incluye no solo a los usuarios finales, sino también a otros sistemas o integraciones que puedan interactuar con el producto. Al considerar esta dimensión, el equipo debe hacerse preguntas como: ¿Quiénes son nuestros usuarios objetivo? ¿Qué roles desempeñan? ¿Cuáles son sus necesidades y expectativas? ¿Hay usuarios indirectos o secundarios que debamos tener en cuenta?
- Interfaz (Interface): La dimensión de Interfaz se refiere a cómo el usuario interactuará con el producto. Esto abarca aspectos como la interfaz de usuario, la experiencia de usuario y cualquier otra forma de interacción, como APIs o integraciones con otros sistemas. Al dividir las historias de usuario, es importante considerar preguntas como: ¿Qué tipo de interfaz será más adecuada para cada funcionalidad? ¿Cómo podemos diseñar una experiencia de usuario intuitiva y agradable? ¿Qué consideraciones de accesibilidad debemos tener en cuenta?
- Acción (Action): La dimensión de Acción se enfoca en las acciones específicas que los usuarios realizarán con el producto. Estas acciones deben ser descritas de manera clara y granular, utilizando verbos que representen las tareas o actividades que el usuario necesita llevar a cabo. Al dividir las historias de usuario, es útil preguntarse: ¿Cuáles son las acciones clave que el usuario necesita realizar? ¿Cómo podemos descomponer estas acciones en pasos más pequeños y manejables? ¿Qué acciones alternativas o excepciones debemos considerar?
- Datos (Data): La dimensión de Datos se refiere a los datos que se manejarán y cómo se gestionarán dentro del producto. Esto incluye tanto los datos de entrada que el usuario proporcionará como los datos de salida que el sistema generará. Al dividir las historias de usuario, es importante considerar preguntas como: ¿Qué datos son necesarios para cada funcionalidad? ¿Cómo se recopilarán, almacenarán y procesarán estos datos? ¿Qué requisitos de seguridad y privacidad debemos tener en cuenta?
- Control (Control): La dimensión de Control abarca las reglas de negocio, las restricciones y las validaciones que se aplicarán al producto. Estas reglas y restricciones aseguran que el producto cumpla con los requisitos legales, regulatorios y de negocio. Al dividir las historias de usuario, es crucial preguntarse: ¿Qué reglas de negocio deben aplicarse a cada funcionalidad? ¿Qué restricciones o validaciones son necesarias para garantizar la integridad y consistencia de los datos? ¿Cómo manejaremos los casos excepcionales o los errores?
- Entorno (Environment): La dimensión de Entorno se refiere a los entornos y plataformas en los que el producto funcionará. Esto incluye consideraciones como compatibilidad con diferentes dispositivos, sistemas operativos, navegadores web y cualquier otra dependencia externa. Al dividir las historias de usuario, es importante tener en cuenta preguntas como: ¿En qué entornos y plataformas debe funcionar el producto? ¿Qué requisitos de compatibilidad debemos cumplir? ¿Cómo podemos garantizar un rendimiento óptimo en diferentes entornos?
- Atributo de Calidad (Quality Attribute): La dimensión de Atributo de Calidad se enfoca en los atributos no funcionales que se esperan del producto. Estos atributos incluyen aspectos como rendimiento, seguridad, usabilidad, mantenibilidad, escalabilidad y confiabilidad, entre otros. Al dividir las historias de usuario, es esencial considerar preguntas como: ¿Qué atributos de calidad son críticos para cada funcionalidad? ¿Cómo podemos medir y asegurar el cumplimiento de estos atributos? ¿Qué compromisos o compensaciones pueden ser necesarios entre diferentes atributos de calidad?
Al aplicar el framework de las 7 dimensiones de un producto al dividir las historias de usuario, el equipo puede obtener una visión más completa y equilibrada de los requisitos. Este enfoque asegura que se cubran tanto los aspectos funcionales como los no funcionales, lo que conduce a un producto más sólido y alineado con las necesidades de los usuarios y del negocio. Además, el framework fomenta la colaboración y la comunicación entre los diferentes stakeholders involucrados en el desarrollo del producto. Al considerar cada dimensión, se promueve un diálogo abierto y constructivo entre el equipo de desarrollo, los representantes del negocio y los usuarios finales. Esto permite identificar y resolver posibles conflictos o malentendidos tempranamente, asegurando un entendimiento compartido de los requisitos.
Otra ventaja del framework es que ayuda a identificar dependencias y relaciones entre las diferentes dimensiones. Por ejemplo, una decisión tomada en la dimensión de Interfaz puede tener un impacto en la dimensión de Acción o en los Atributos de Calidad. Al considerar estas interrelaciones, el equipo puede tomar decisiones más informadas y coherentes al dividir las historias de usuario. Sólo recuerda: no existen balas de plata, la máxima o el meta (como me diría mi hijo) es: transparencia, inspección y adaptación.