¿Cómo representamos los requisitos en Agilidad?
"Los requisitos en agilidad se crean y administran a través del Product Backlog, que por lo general se representan a través de la Historia de Usuario"
Las Historias de Usuario son utilizadas en Agilidad para la representación de requisitos. Y en su definición en relación al software "Estas son una breve descripción muy valiosa de un funcionalidad de software tal y como la percibe el usuario"
Las Historias de Usuario nos ayudan a comprender la proposición de valor del producto desde sus inicios. Por lo que, son un medio poderoso que permite la comunicación tanto escrita como verbal, y fomenta la colaboración y el aprendizaje para los equipos e interesados del proyecto. Además, logran una conexión entre clientes, usuarios y el equipo de trabajo que desarrollará el producto.
Origen de las Historias de Usuario
Su origen viene de la metodología eXtreme Programming (XP) creada por Kent Beck en el año 1999, donde los clientes debían escribir las Historias de Usuario con la intención de forzar la brevedad y crear ambigüedad intencional, con la idea de que está ambigüedad resultaría en más comunicación cara a cara.
Enfoque ágil de requisitos
Las Historias de Usuario son parte de un enfoque ágil que permiten crear y administrar requisitos de valor, sin tener que elaborar una gran cantidad de documentos formales y sin requerir de mucho tiempo para su administración.
Dentro de la ingeniería de requisitos ágiles, encontramos 4 niveles según su orden jerárquico:
La Visión del Producto y sus temas
El Product Backlog compuesto por Épicas e Historias de Usuario
El Sprint Backlog compuesto por tareas.
"Las Historias de Usuario son una breve descripción muy valiosa de una característica o funcionalidad que es necesitada por el usuario".
La principal característica de las Historias de Usuario es que son breves y fáciles de leer para que puedan ser comprendidas por todo el mundo, y son ideales en entornos VUCA. Al ser muy cortas, estas tienen el beneficio de representar pequeños incrementos de valor que pueden ser construidos en días en una iteración.
Adicionalmente, una Historia de Usuario tiene la ventaja de estimar fácilmente su esfuerzo de manera colectiva por el equipo de trabajo. Ya que al ser pequeños requisitos detallados se le puede estimar mediante la aplicación de tiempo ideal o con unidades de medidas relativa para definir su tamaño.
¿Cómo escribir las Historias de Usuario?
Para comenzar escribir Historias de Usuario es de bastante utilidad usar la fórmula de captura de funcionalidades conocida como Las Tres C´s definida en 2001 por Ron Jeffries.
El contenido de una historia de valor debe caber en una tarjeta (card), es decir, solo debe contar con la información necesaria para la iteración. El objetivo de las historias es que generen una conversación (conversation) muy valiosa entre el equipo de trabajo y el Product Owner en relación a su contenido, y así asegurarnos de contar con una confirmación (confirmation) de que el requisito de valor ha sido capturado a la perfección.
Es por ello, que las Historias de Usuario toma la principal información necesaria del Product Backlog para que sean representadas en las instancias de planificación, es decir, Product Backlog e Historias de Usuario son fundamentales para la creación de valor.
A continuación, se listan algunas componentes de una Historia de Usuario tipo a modo de ejemplo:
Descripción
El formato de descripción de las Historias de usuario son una breve síntesis que representa la necesidad, problema o expectativas de un usuario sobre el producto o servicio
Una popular descripción muy utilizada para escribir la descripción de las historias, es la popularizada por Mike Cohn en su libro User stories Applied.
"Como [rol del usuario] Quiero [objetivo] Para poder [Beneficio]"
Estimación
Las estimaciones de los requisitos de valor permiten asegurar y mejorar el ritmo de avance y de entregas a tiempo en el Sprint. Recordar que la estimación es realizada por los Developers de manera colectiva, es decir, por el equipo que realizará el trabajo.
Tiempo Ideal: Considerando el tiempo ideal del equipo de trabajo, ya sea en semanas, días y horas ideales.
Unidades Relativas: Empleo de unidades relativas de estimación, donde la unidad más común son los Puntos de Historia.
No Estimates: Estimaciones de alto nivel donde se busca simplificar y agilizar el proceso de estimación.
Prioridad
Esta componente permite determinar el orden en que las historias serán implementadas. Las técnicas para priorizar los elementos del Product Backlog cómo las Historias de Usuario, pueden ser cualitativas o cuantitativas.
Técnica MoSCoW: Es una forma sencilla de priorizar el Product Backlog y las Historias de Usuario de forma cualitativa para obtener un entendimiento común entre el Team e interesados.
Técnica Return On Invesment: La técnica ROI permite al Product Owner priorizar el Product Backlog a través del retorno de la inversión de cada elemento. Por lo que, el elemento que tenga el ROI más alto será de mayor prioridad.
Técnica Weighted Shortest Job First: La técnica WSJF tiene el objetivo de minimizar el costo de demora y optimizar el valor agregado al final de cada Sprint. Por lo que, el elemento que tenga el WSJF más alto será de mayor prioridad.
Criterios de Validación
Los criterios de validación es una lista que permite ver el cumplimiento de la característica desarrollada. Y a través del Método SMART podemos asegurarnos que la Historia de Usuario cumple con los aspectos de valor, calidad y realizada a tiempo.
Los criterios deben ser específicos (specific) en relación a la característica o funcionalidad a desarrollar
Los criterios deben ser medibles (measurable), es decir, contar con metas para confirmar su resultado
Los criterios deben estar en el contexto de lo que sea lograble (achievable) en base a las circunstancias del negocio, producto, proyecto y el equipo que realiza el trabajo
Los criterios deben ser relevantes (relevant). Por lo que, deben generar valor al negocio y producto
Los criterios de una característica deben ser terminados y entregados a tiempo (time).
Cabe destacar, que la componentes de una Historia de Usuario son libres. Dependerá de qué componentes generen un mayor beneficio y entendimiento de las características a desarrollar para el Team.