¿Qué debemos conocer de SCRUM cuando llega a nuestras organizaciones?
¿Qué debemos conocer de SCRUM cuando llega a nuestras organizaciones?
Este artículo está dirigido para todos los que están pasando por cambios en sus organizaciones hacia la agilidad, ya sea en sus proyectos, equipos o nuevas maneras de estructuración.
Generalmente este cambio cuando deciden desde arriba, los que se enteran al final son los equipos de trabajo, ¡justamente los que van a tener que interactuar más con el cambio!
Esto en si ya es una incertidumbre. Aquí abordaremos lo que deberíamos saber para poder afrontar este cambio.
Primero daremos un repaso acerca de lo que se entrega de agilidad para iniciar la adaptación en las organizaciones:
• Valores y principios ágiles
• Roles y responsabilidades
• Ceremonias agiles
• Artefactos scrum
Luego del repaso, sumaremos el cómo afrontar este cambio transformacional en nuestras organizaciones sin importar el rol que tengamos.
VALORES Y PRINCIPIOS ÁGILES
Agilidad en una imagen
Valores del manifiesto ágil
Valores del manifiesto ágil
12 principios del manifiesto ágil
12 principios del manifiesto ágil
ROLES Y RESPONSABILIDADES
Para la parte de roles y responsabilidades he tomado las definiciones de la Guía Scrum de Scrum.org
• Scrum Master: Es responsable de establecer Scrum como se define en la Guía de Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Scrum Team como de la organización. El Scrum Master es responsable de lograr la efectividad del Scrum Team. Lo hace apoyando al Scrum Team en la mejora de sus prácticas, dentro del marco de trabajo de Scrum.Los Scrum Masters son verdaderos líderes que sirven al Scrum Team y a la organización en general.
• Product Owner: Es responsable de la gestión efectiva del Product Backlog, lo que incluye:-Desarrollar y comunicar explícitamente el Objetivo del Producto;-Crear y comunicar claramente los elementos del Product Backlog;-Ordenar los elementos del Product Backlog;-Asegurarse de que el Product Backlog sea transparente, visible y se entienda.
• Developers: Las habilidades específicas que necesitan los Developers suelen ser amplias y variarán según el ámbito de trabajo. Sin embargo, los Developers siempre son responsables de:-Crear un plan para el Sprint, el Sprint Backlog;-Inculcar calidad al adherirse a una Definición de Terminado;-Adaptar su plan cada día hacia el Objetivo del Sprint;-Responsabilizarse mutuamente como profesionales.
CEREMONIAS ÁGILES
En la gráfica observamos las ceremonias Scrum dentro del ciclo de sprint:
Funcionamiento de Scrum
Sprint Planning
El trabajo a realizar durante el Sprint se planifica en la Sprint Planning. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.
Daily Scrum
Reunión que busca sincronizar las actividades y el plan del equipo de desarrollo para las siguientes 24 horas.
Refinamiento
Presentar las próximas historias al equipo que van a entrar tanto para el siguiente sprint como para los 2 o tres próximos y discutir aspectos sobre ellos, como los insumos, riesgos y dependencias.
Sprint Review
Es una reunión informal, no de seguimiento, donde mediante la presentación del incremento, se busca facilitar la retroalimentación y la colaboración.
Retrospectiva
La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint
El Scrum Master se asegura de que la reunión sea positiva y productiva.
ARTEFACTOS SCRUM
Incremento:
El incremento es la suma de todos los elementos del producto completados durante un sprint y el valor de los incrementos de todos los sprints anteriores. El incremento debe ser potencialmente entregable al final de cada sprint y debe cumplir con la definición de "Terminado" acordada por el equipo.
Ejemplo: Si estamos desarrollando un software de gestión de tareas, un incremento podría ser la funcionalidad de agregar nuevas tareas a la lista, junto con la capacidad de marcarlas como completadas. Este incremento sería una versión funcional y usable del producto que podría entregarse al cliente al finalizar el sprint.
Product Backlog:
El Product Backlog es una lista dinámica y priorizada de todos los elementos del trabajo que podrían ser necesarios para completar el producto. Estos elementos pueden ser características, funciones, mejoras, correcciones de errores, y otros requerimientos relacionados con el producto. El Product Backlog es propiedad del Product Owner.
Ejemplo: En el mismo software de gestión de tareas, el Product Backlog podría incluir elementos como la capacidad de asignar tareas a usuarios específicos, la integración con calendarios externos, o la funcionalidad de establecer recordatorios para tareas pendientes. Estos elementos se priorizan en función del valor para el cliente y se refinan continuamente para mantenerse al día con los cambios en los requisitos y las necesidades del negocio.
Backlog del Sprint:
El backlog del sprint es una selección de elementos del Product Backlog que el equipo se compromete a completar durante el sprint. Estos elementos se seleccionan durante la planificación del sprint y representan el trabajo específico que el equipo planea realizar durante ese período.
Ejemplo: Para el próximo sprint en el proyecto de software de gestión de tareas, el backlog del sprint podría incluir elementos específicos como "Implementar la funcionalidad de asignar tareas a usuarios", "Diseñar e integrar un sistema de notificaciones para recordatorios de tareas", y "Optimizar el rendimiento de la búsqueda de tareas en la aplicación". Estos elementos se seleccionan en función de su prioridad y viabilidad para el sprint en cuestión.
Y llegando a esta parte, luego del repaso anterior del conocimiento brindado en los parrafos anteriores, ahora nos toca ver el cómo debemos afrontar de manera correcta la transformación en nuestra organización o proyecto:
• TRABAJEMOS EN EQUIPO JUNTO A LOS DEMÁS MIEMBROS DEL SQUAD PARA ALCANZAR EL OBJETIVO DE CADA SPRINT.
• COLABOREMOS EN EQUIPO PARA MANTENER LA CORRECTA APLICACIÓN DEL FRAMEWORK.
• DURANTE TODO EL SPRINT, CUALQUIER MIEMBRO DEL SQUAD DEBE IDENTIFICAR RIESGOS Y COMUNICAR A TODO EL SQUAD.
• EN CASO DE TENER IMPEDIMENTOS EN LOS DESARROLLOS, TENGAMOS LA LIBERTAD DE COMUNICARLO PARA ANTICIPAR POSIBLES RIESGOS DEL DESARROLLO DURANTE EL SPRINT.
• BRINDARSE APOYO Y COMPARTIR CONOCIMIENTO ENTRE TODOS LOS MIEMBROS DEL SQUAD, YA QUE EL CONSEGUIR CERRAR EL SPRINT ES COMPROMISO Y LOGRO DE TODOS LOS MIEMBROS DEL SQUAD.
• NO TENER MIEDO EN SOLICITAR AYUDA ENTRE MIEMBROS DEL SQUAD.
• TENGAMOS APERTURA A LOS CAMBIOS QUE PUEDAN PRESENTARSE DURANTE EL SPRINT, SIN DEJAR DE LADO LOS ACUERDOS QUE SOSTIENE EL SQUAD.
Deja un comentario