Calidad en el marco de metodología Scrum
- mateosolorzanov
- 26 oct 2024
- 5 Min. de lectura
Introducción
En Scrum, la calidad no solo significa que un producto funcione bien, sino que cumple con las expectativas del cliente y aporta el valor esperado. Este enfoque se aplica a proyectos de cualquier tamaño o sector. Scrum permite alcanzar estos niveles de calidad de manera iterativa, adaptándose y mejorando con cada sprint.
Figura 1. La calidad como parte fundamental para cumplir las expectativas del cliente
Guía de Roles
La gestión de calidad en Scrum involucra a todos los roles:
Product Owner: Debe tener una comprensión completa de los requisitos de calidad y trabajar de cerca con el cliente para definirlos en el backlog.
Scrum Master: Facilita el cumplimiento de estos estándares, eliminando obstáculos y ayudando al equipo a mantener un ritmo sostenible.
Equipo Scrum: Es el responsable de implementar los requisitos de calidad en cada sprint, asegurándose de que los entregables cumplen con las expectativas.
Figura 2. Cada miembro del equipo Scrum cumplirá un rol para presentar un producto de calidad
Definición de calidad
Definimos calidad como la capacidad del producto final para cumplir con los criterios de aceptación y el valor esperado. Scrum mantiene una mejora continua mediante sprints que permiten detectar y corregir defectos de forma temprana, manteniendo el backlog actualizado.
Figura 3. Definición de la calidad en Scrum
3.1. Calidad y alcance
El alcance incluye todos los incrementos del producto y el trabajo necesario. La calidad es cumplir los requisitos y satisfacer al cliente, balanceando necesidades de negocio y capacidad organizativa.
Los requerimientos de alcance y calidad para un proyecto se determinan al tomarse en cuenta varios factores tales como los siguientes:
La necesidad del negocio que habrá de cumplir el proyecto
La capacidad y la disposición de la organización para cumplir con las necesidades del negocio
Las necesidades futuras y actuales del público meta
3.2. Calidad y valor del negocio
Establece que calidad y valor están ligados; para que un proyecto aporte valor, debe cumplir con la calidad esperada y las necesidades del negocio.
Criterios de aceptación y backlog priorizado del producto
El backlog priorizado del producto contiene historias de usuario con criterios de aceptación bien definidos. Estos criterios no son solo un checklist; son la guía que asegura que cada funcionalidad cumple con lo que el cliente espera. Además, cada sprint termina con una "definición de terminado", una serie de estándares que deben cumplirse para que una historia sea considerada finalizada. Esta estructura evita ambigüedades y asegura consistencia en la calidad.
Las historias de usuario que corresponden a los entregables rechazados se agregan de nuevo al backlog priorizado del producto para ser desarrollados en futuros sprints, aumentando el flujo del proyecto.
Figura 4. Diagrama del flujo del incremento del proyecto
4.1. Redacción de criterios de aceptación
Describe cómo escribir criterios de aceptación detallados y relevantes para cada historia de usuario.
4.2. Definición de listo
La “definición de listo” incluye reglas que cada historia debe cumplir antes de iniciar un sprint. Esto facilita estimaciones precisas y alineación del equipo.
Algunos de los criterios en la definición de listo pudieran ser los siguientes:
Las historias de usuario se escriben con suficiente detalle a fin de que los Equipos Scrum las puedan entender y puedan ser utilizadas en las estimaciones;
Todas las historias de usuario cuentan con criterios de aceptación bien definidos;
Incluyen cualquier documentación relacionada que pudiera explicar mejor la historia de usuario;
4.3. Definición de terminado (o criterios de terminado)
Se aplican criterios generales a todas las historias de usuario para asegurar que cumplen con los estándares de calidad necesarios al finalizar un sprint.
Los criterios de terminado pueden incluir cualquiera de los siguientes:
Fueron revisados por otros miembros del equipo;
Completaron la prueba de unidad de la historia de usuario;
Conclusión de las pruebas de garantía de calidad;
Conclusión de toda la documentación relacionada a la historia de usuario;
Se corrigieron todos los problemas;
Demostración satisfactoria a los interesados del negocio o representantes del negocio.
4.4. Criterios mínimos de terminado
Organizaciones de alto nivel pueden establecer criterios mínimos de terminado que aplican a todas las historias de usuario, asegurando un estándar básico de calidad.
La introducción a estos criterios de aceptación puede llevar a una serie en cascada de criterios de aceptación para el portafolio, el programa y el proyecto.
Tabla 1. Criterios terminado en cascada
4.5. Aceptación o rechazo de elementos del backlog priorizado del producto
El Product Owner evalúa los elementos del backlog completados en cada sprint y puede rechazarlos si no cumplen los criterios de aceptación.
Criterios de aceptación y backlog priorizado del producto
Describe tres actividades esenciales: planificación, control y garantía de calidad. El enfoque en la voz del cliente asegura que el producto final cumpla con los requisitos, mientras se minimiza la deuda técnica acumulada.
Para cualquier proyecto Scrum, el cliente puede ser cualquiera de los siguientes:
Interno (dentro de la misma organización)
Externo (fuera de la organización)
La gestión de calidad les permite a los clientes conocer cualquier problema en el proyecto en forma anticipada, ayudándoles a reconocer si el proyecto habrá o no de funcionarles.
En Scrum, la gestión de calidad se facilita mediante tres actividades interrelacionadas:
Planificación de calidad
Control de calidad
Garantía de calidad
5.1. Planificación de calidad
La planificación de calidad prioriza los requisitos más importantes del cliente y evita deuda técnica acumulada. Define claramente los entregables y la metodología a seguir.
La deuda técnica, conocida también como deuda de diseño o deuda de código, es el trabajo al que los equipos dan menor prioridad. La deuda técnica se acumula y se debe saldar a futuro.
Como resultado, la deuda técnica se acumula, llevando a un mantenimiento considerablemente más elevado, integración y costos de liberación del producto en las etapas finales de su liberación.
5.1.1. Planificación de calidad
En Scrum, mantener un ritmo sostenible es esencial para asegurar la satisfacción del equipo y la precisión en las estimaciones, lo que lleva a un producto de alta calidad y clientes satisfechos. Para lograrlo, se realizan actividades de integración y evaluación de forma continua en cada sprint, utilizando técnicas como la integración continua, en lugar de acumular este trabajo al final. Esto permite al equipo trabajar de manera equilibrada, evitando picos de trabajo intensos y asegurando un esfuerzo constante entre sprints, lo que contribuye a un desarrollo más eficiente y estable.
5.2. Garantía de calidad y control de calidad
La calidad es necesaria no solo en los productos, sino también en los procesos. La garantía de calidad implica evaluar procesos para asegurar relevancia, mientras que el control se enfoca en actividades para lograr entregables de calidad. Las retrospectivas permiten mejoras continuas.
5.3. Ciclo de planificar, hacer, verificar y actuar (PDCA)
El ciclo PDCA (planificar, hacer, verificar y actuar) impulsa la mejora continua en cada sprint, ayudando al equipo a adaptarse y perfeccionar el producto.
Figura 5. Ciclo PDCA en Scrum
Resumen de responsabilidades
Define responsabilidades relacionadas con la calidad para cada rol, desde el Product Owner hasta el Scrum Guidance Body, quienes establecen directrices para calidad en el equipo y el proyecto.
Tabla 2. Resumen de las responsabilidades pertinentes a la calidad
Scrum vs. Gestión tradicional de proyectos
La principal diferencia entre Scrum y la gestión tradicional de proyectos radica en la flexibilidad. En Scrum, los entregables están listos para el cliente al final de cada sprint, permitiendo adaptaciones constantes a las necesidades cambiantes. En métodos tradicionales, los cambios son más rígidos y costosos, mientras que en Scrum, el Product Owner colabora con el equipo para ajustar los requisitos en cada ciclo, siempre buscando mejorar el producto en función del feedback constante.
Kommentare