Implementar una metodología basada en el marco de trabajo SCRUM, es una necesidad hoy en día en los proyectos tecnológicos pero para poder adoptar estas buenas prácticas es necesario comprender de manera detallada los componentes que tiene, basados en la guía del SCRUM de Ken Schwaber y Jeff Sutherland en el 2017.
Para el correcto desarrollo del proceso SCRUM es requerido tener en cuenta los siguientes roles dentro del equipo de proyecto.
El Dueño de Producto: Es el responsable de maximizar el valor del producto y del trabajo del equipo de desarrollo y la única persona responsable de gestionar la lista del producto (Product Backlog).
La gestión de la lista del producto incluye:
- Expresar claramente los elementos de la lista del producto
- Ordenar los elementos en la lista del producto para alcanzar los objetivos y misiones de la mejor manera posible
- Optimizar el valor del trabajo desempeñado por el equipo de desarrollo
- Asegurar que la lista del producto es visible, transparente y clara para todos, y que muestra aquello en lo que el equipo trabajará a continuación
- Asegurar que el equipo de desarrollo entiende los elementos de la lista del producto al nivel necesario.
El Scrum Master es el responsable de asegurar que Scrum es entendido y adoptado. Los Scrum Masters hacen esto asegurándose de que el equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum.
Es un líder que está al servicio del equipo Scrum en donde también ayuda a las personas externas al equipo Scrum a entender qué interacciones con el equipo Scrum pueden ser de ayuda y cuáles no.
La gestión de la lista del producto incluye:
- Encontrar técnicas para gestionar la lista de producto de manera efectiva
- Facilitar los eventos de Scrum según se requiera o necesite
- Guiar al equipo de desarrollo en ser auto-organizado y multifuncional
- Eliminar impedimentos para el progreso del equipo de desarrollo
- Liderar y guiar a la organización en la adopción de Scrum
- Motivar cambios que incrementen la productividad del equipo Scrum.
El Equipo de Desarrollo: consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de producto “Terminado”, que potencialmente se pueda poner en producción, al final de cada Sprint. Solo los miembros del equipo de desarrollo participan en la creación del incremento.
Estos son estructurados y empoderados por la organización para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del equipo de desarrollo.
- Son auto-organizados. Deben definir cómo convertir elementos de la lista del producto en incrementos de funcionalidad potencialmente desplegables
- Scrum no reconoce sub-equipos, no importan los dominios particulares que requieran ser tenidos en cuenta, como pruebas o análisis de negocio.
- Los miembros individuales del equipo de desarrollo pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el equipo como un todo.
Lista de Impedimentos:
Los impedimentos son barricadas, obstáculos “no problemas”. En términos de Scrum, son «bloqueadores» que evitan que el equipo Scrum complete el trabajo, lo que a cambio impacta la velocidad. Cualquier cosa que prohíba al equipo hacer trabajo se considera un impedimento y debe estar en una lista priorizada y monitoreada por el SCRUM MASTER.
Existen dos clases de impedimentos:
- Impedimentos del equipo
- Impedimentos organizativos.
Product Backlog / Lista de Producto
La lista de producto es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El dueño de producto (Product Owner) es el responsable de la lista de producto, incluyendo su contenido, disponibilidad y ordenación.
Product Backlog /Burn- Down
Es una herramienta de medición visual que muestra el trabajo completado por día contra la tasa de finalización proyectada para el lanzamiento actual del proyecto, su propósito es permitir que el proyecto esté en camino de entregar la solución esperada dentro del cronograma deseado.
Si la velocidad de un equipo Scrum es, por ejemplo, 30 puntos de historia y la cantidad total de trabajo restante es de 155, podemos predecir que necesitamos alrededor de 6 Sprint para completar todas las historias en el Backlog.
Sprint Backlog
La lista de pendientes del Sprint es el conjunto de elementos de la lista de producto seleccionados para el Sprint, más un plan para entregar el incremento de producto y conseguir el objetivo del Sprint. La Lista de pendientes del Sprint es una predicción hecha por el equipo de desarrollo acerca de qué funcionalidad formará parte del próximo incremento y del trabajo necesario para entregar esa funcionalidad en un incremento “Terminado”.
La lista de pendientes del Sprint hace visible todo el trabajo que el equipo de desarrollo identifica como necesario para alcanzar el objetivo del Sprint.
Sprint Backlog / Burn – Down
El Sprint Burndown Chart hace visible el trabajo del equipo, es una representación gráfica que muestra la velocidad a la que se completa el trabajo y cuánto trabajo queda por hacer.
La tabla se inclina hacia abajo durante la duración del Sprint y a través de los puntos de historia completados, lo que hace que el gráfico sea una herramienta de informes efectiva es que muestra el progreso del equipo hacia el objetivo Sprint, no en términos de tiempo invertido sino en términos de cuánto trabajo queda.
Product Backlog / Delta – Report
Contiene los cambios realizados en el Product Backlog entre los Sprint’s, donde las historias pueden estar en un estado diferente (es decir, en progreso, completado) después de cada Sprint. El propietario del producto puede modificar la cartera de productos durante la línea de tiempo del proyecto agregando, eliminando o cambiando las historias de acuerdo con los cambios requeridos.
CEREMONIAS
Actualizar el alcance del proyecto es generalmente viable dentro de proyectos SCRUM.
Estos tipos de cambios son actualizaciones al Product Backlog, y deben ser evaluados por todo el equipo SCRUM.
Estimarse y contemplar tanto los nuevos tiempos, o generación de nuevos Sprint´s como los riesgos asociados a las nuevas Solicitudes de los usuarios.
La planificación de Sprint tiene un límite de tiempo de hasta ocho horas para un Sprint de un mes. Para Sprint’s más cortos, el evento suele ser más corto. El Scrum Master asegura que el evento se lleve a cabo y que los asistentes comprendan su propósito. El Scrum Master le enseña al Equipo Scrum a mantenerlo dentro del tiempo.
El Equipo de Desarrollo usa el Scrum diario para inspeccionar el progreso hacia la meta de Sprint y para inspeccionar la tendencia del progreso hacia completar el trabajo en el Backlog de Sprint. El Daily Scrum optimiza la probabilidad de que el equipo de desarrollo cumpla con el objetivo Sprint. Todos los días, el equipo de desarrollo debe comprender cómo pretende trabajar juntos como un equipo auto-organizado para lograr el objetivo Sprint y crear el incremento previsto al final del Sprint.
Durante la revisión de Sprint, el equipo Scrum y las partes interesadas colaboran sobre lo que se hizo en Sprint. En base a eso y a cualquier cambio en el Backlog del Producto durante el Sprint, los asistentes colaboran en las siguientes cosas que podrían hacerse para optimizar el valor, esta es una reunión informal, no una reunión de estado, y la presentación del incremento tiene como objetivo obtener comentarios y fomentar la colaboración.
La retrospectiva de Sprint ocurre después de la revisión de Sprint y antes de la próxima planificación de Sprint.
Esta es una reunión de tres horas como máximo para Sprint’s de un mes y para Sprint’s más cortos, el evento suele ser más corto.
El Scrum Master asegura que el evento se lleve a cabo y que los asistentes comprendan su propósito, esta es la oportunidad para que el equipo Scrum mejore y todos los miembros deben estar presentes como:
- Lo que salió bien en el Sprint
- ¿Qué podría mejorarse?
- ¿Qué nos comprometeremos a mejorar en el próximo Sprint?.
