Criterios de Aceptación y metodología MoSCoW para la gestión del alcance en Historias de Usuario
Desafortunadamente he visto pasar numerosos proyectos y personas subestimando la importancia de la definición de requisitos y la gestión del alcance a corto y largo plazo de grandes ideas, aunque estas son las fases más importantes en el desarrollo de software. Existen numerosos sistemas para llevar a cabo la definición de requisitos, algunos más sencillos como las Historias de usuario y otros con criterios de aceptación con sintaxis Gherkin que podría ser más completa, pero lo más importante es que cualquier framework Agile como estos, fomentan un entendimiento común en el equipo y son el núcleo del control de calidad. En este artículo explicaré qué son y qué técnica puede ser útil para controlar efectivamente el alcance de una Historia de Usuario con el método MoSCoW para tus proyectos.
¿Cómo define Agile los requisitos?
Antes de llegar al punto principal, necesito explicar algunos conceptos básicos de Agile.
Product Backlog
Un Product Backlog es un artefacto central que consolida toda la información relacionada con un producto, como requisitos, estimación, comunicación, estado de progreso, etc. En la gestión en cascada, se denomina ticket, issue o tarea. Un Product Backlog consta de cuatro capas de jerarquía: Tema, Épica, Historia de usuario y Tarea.
- El tema representa una estrategia de producto a largo plazo que abarca varios meses o años.
- Épica tiene un valor enorme, impacta la inversión empresarial y requiere más que un Sprint durante varios meses.
- Historia de usuario es el pequeño valor que se debe entregar en cada Sprint.
- Tarea es un desglose de la Historia de Usuario que se puede terminar en unos días.
Historia del usuario
Una Historia de Usuario debe tener tres elementos esenciales para aclarar los requisitos: una Historia de Usuario (frase), Criterios de Aceptación e imagen visual. Una historia de usuario (frase) describe lo que los usuarios quieren lograr a través de un producto con quién, qué y por qué. A continuación se muestra un ejemplo.
Como usuario (quién), quiero iniciar sesión en la plataforma con la dirección de correo electrónico y la contraseña (qué) para poder usar la plataforma de forma segura (por qué).
Las imágenes visuales pueden ser bocetos, prototipos o diseños sofisticados que apoyan el entendimiento común y estimulan la conversación. Como la historia de usuario y los criterios de aceptación son expresiones basadas en texto, las imágenes visuales ayudan a las personas a imaginar cómo debería comportarse el software.
¿Qué son los criterios de aceptación?
Los criterios de aceptación son una de las prácticas de Agile para redactar de manera efectiva los requisitos que debes cumplir antes de su finalización, en definitiva se trata de la historia de usuario para definir requisitos y funcionalidades.
Como la definición de requisitos es el proceso más difícil y que requiere más tiempo en el desarrollo de software, Agile creó una forma de escribir requisitos de manera efectiva y eficiente. Los criterios de aceptación se utilizan no sólo para los requisitos sino también para las pruebas de aceptación, por lo que el equipo de desarrollo no tiene que escribir ambos por separado.
Si bien existen varios formatos para redactar los criterios de aceptación, Gherkin Syntax, creada por Aslak Hellesøy, el fundador de Cucumber, puede ser una de las opciones ideales al ser de las más completas. La sintaxis de Gherkin consta de cuatro elementos simples: escenario, dado, cuándo y entonces, que describen cómo debe comportarse el software. El marco cubre de manera integral todos los aspectos necesarios del comportamiento del software, por lo que es adecuado para definir requisitos detallados. Puedes ver la explicación y el ejemplo de cada elemento a continuación.
Contexto de la gestión del alcance de la historia de usuario
Una Historia de Usuario debe ser lo suficientemente pequeña como para completarse dentro de un Sprint a fin de realizar una entrega constante e iterativa. Por lo tanto, gestionar el alcance de la historia de usuario es fundamental porque el alcance tiene un gran impacto en la estimación. Según el cono de incertidumbre, la relación del estudio entre la etapa de desarrollo y la precisión de la estimación, concluyó que los requisitos y el alcance claros mejoran más la precisión de la estimación. También está demostrado por el fenómeno de “desplazamiento del alcance” (también llamado desplazamiento de requisitos o síndrome del fregadero de la cocina) de que el alcance se expande a medida que avanza el desarrollo si un equipo de desarrollo no aclara los requisitos y el alcance antes de codificar.
Otra consideración es el triángulo de la gestión de proyectos, que describe tres limitaciones (alcance, costo y tiempo) que afectan el proceso de toma de decisiones. Como los recursos del proyecto siempre son limitados, debemos tomar decisiones inteligentes.
Un punto clave aquí es que la gestión del alcance es más crítica en Agile que en Waterfall. En Agile, los recursos y el tiempo son fijos, mientras que el alcance es flexible. Como Agile está diseñado para una entrega rápida e iterativa, un manager de producto piensa en cómo maximizar el valor del producto con tiempo y recursos limitados. Si el alcance es demasiado grande para completarse en el tiempo previsto, se debe reducir mediante la priorización. En cambio, en Waterfall el alcance es fijo, mientras que los recursos y el tiempo son flexibles.
Con base en estos estudios y prácticas, el flujo general (contexto) de la gestión de historias de usuario será el siguiente.
- Aclara los requisitos con una historia de usuario, criterios de aceptación e imágenes visuales.
- El alcance se discute con base en los Criterios de Aceptación. El alcance no se puede gestionar sin requisitos. Este paso y la definición de requisitos generalmente se realizan juntos. Aquí es donde pienso que el método MoSCoW es de gran utilidad.
- Una Historia de Usuario se estima en función de su alcance. Como mencioné anteriormente, los requisitos y el alcance claros son los que más contribuyen a la precisión de la estimación. Si una Historia de usuario es demasiado grande, algunos requisitos deben dividirse en otras Historias de usuario para gestionarlas más adelante.
- La decisión final se basa en los requisitos, el alcance y la estimación. Por lo general, se determina en Sprint Planing en Agile.
¿Qué es MoSCoW?
MoSCoW (Debe tener, Debería tener, Podría tener, No tendrá) es un método de priorización desarrollado por Dai Clegg en 1994 para su uso en el desarrollo rápido de aplicaciones (RAD). Se utilizó ampliamente por primera vez con el método de desarrollo de sistemas dinámicos (DSDM) en 2002. MoSCoW prioriza los requisitos con cuatro categorías: Debe tener, Debería tener, Podría tener y No tendrá.
- Debe tener: Se deben implementar los requisitos. Si no se implementan, las funciones no se podrán utilizar y la entrega se considerará un fracaso. MUST también se considera un acrónimo de Subconjunto Mínimo Utilizable.
- Debería tener: Los requisitos no son tan críticos como los "Debe tener", pero deben implementarse. Aunque las funciones se pueden utilizar sin requisitos, generalmente se implementan para satisfacer la satisfacción del cliente.
- Podría tener: Los requisitos mejoran la UI/UX, lo que lleva a una mejor satisfacción del cliente. Generalmente se implementan cuando el tiempo y el costo lo permiten.
- No tendrá: Los requisitos no son necesarios en este momento y se pueden considerar más adelante.
Ejemplo Historia de Usuario y MoSCoW
Vemos cómo utilizar los criterios de aceptación y MoSCoW junto con un ejemplo. Para simplificar, usaré la siguiente imagen de inicio de sesión.
- Escribe todos los Criterios de Aceptación que se te ocurran. Usaré los cuatro escenarios siguientes como ejemplo.
Después de escribir los Criterios de aceptación (Historias de usuario), clasifica cada escenario en categorías MoSCoW como la que se muestra a continuación. Luego, decide hasta dónde estás dispuesto a desarrollar, lo mejor sería centrarte en Must have para definir un Producto Mínimo Viable (MVP). En el siguiente ejemplo, "Debe tener" y "Debería tener" son el alcance, y "Podría tener" y "No tendrá" están fuera del alcance y se desarrollarán en diferentes Historias de usuario.
Conclusión
La gestión efectiva del alcance en las historias de usuario es fundamental para el éxito de los proyectos de desarrollo de software. La utilización de métodos como los criterios de aceptación y la metodología MoSCoW no solo facilita la claridad en los requisitos, sino que también permite una priorización eficiente, asegurando que los elementos esenciales se abordan primero. Esto es crucial en un entorno Agile, donde el tiempo y los recursos son limitados, y el alcance debe ser flexible para adaptarse a cambios rápidos. La correcta implementación de estos enfoques fomenta una mejor estimación, planificación y, en última instancia, entrega de productos de alta calidad.
Referencias