Metodología SCRUM

1. ¿Qué es SCRUM? Es un proceso en el que se aplican de manera regular un conjunto

de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

2. Origen de SCRUMEs un modelo de desarrollo ágil caracterizado por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.

Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en

la calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de

cascada.

3. Beneficios

Cumplimento de expectativas.

Flexibilidad a cambios.

Mayor calidad del software.

Mayor productividad.

Reducción de riesgos.

4. Visión de SCRUM

Un marco de trabajo por el cual las personas pueden acometer problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente. Scrum es:

Ligero.

Fácil de entender.

Extremadamente difícil de llegar a dominar.

5. Teoría de SCRUM:

Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.

Tres pilares soportan toda la implementación del control de procesos empírico:

Transparencia Inspección Adaptación

6. Roles:

El Equipo Scrum (Scrum Team)

El Dueño de Producto (Product Owner)

El Equipo de Desarrollo (Development Team)

El Scrum Master

El Equipo Scrum (Scrum Team)

Consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master. Los Equipos Scrum son autoorganizados y multifuncionales. Los equipos autoorganizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación.

El Dueño de Producto (Product Owner)

Es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar ampliamente entre distintas organizaciones, Equipos Scrum e individuos.

El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog).

El Dueño de Producto (Product Owner)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; y,

Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.

El Equipo de Desarrollo (Development Team)

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.

El Equipo de Desarrollo (Development Team)

Los Equipos de Desarrollo tienen las siguientes características:Son autoorganizados.

Los Equipos de Desarrollo son multifuncionales.

Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo.

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 de Desarrollo como un todo.

El Equipo de Desarrollo (Development Team)

Tamaño del Equipo de Desarrollo

El tamaño óptimo del Equipo de Desarrollo es lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para completar una cantidad de trabajo significativa.

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.

El Scrum Master

El Servicio del Scrum Master al Dueño de Producto

Encontrar técnicas para gestionar la Lista de Producto de manera efectiva.

Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos.

Entender la planificación del producto en un entorno empírico.

Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor.

Facilitar los eventos de Scrum según se requiera o necesite.

El Scrum Master

El Servicio del Scrum Master al Equipo de Desarrollo

Guiar al Equipo de Desarrollo en ser auto organizado y multifuncional.

Ayudar al Equipo de Desarrollo a crear productos de alto valor.

Eliminar impedimentos para el progreso del Equipo de Desarrollo.

Facilitar los eventos de Scrum según se requiera o necesite.

Guiar al Equipo de Desarrollo en el entorno de organizaciones en las que Scrum aún no ha sido adoptado y entendido por completo.

El Scrum Master

El Servicio del Scrum Master a la Organización

Liderar y guiar a la organización en la adopción de Scrum.

Planificar las implementaciones de Scrum en la organización.

Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto.

Motivar cambios que incrementen la productividad del Equipo Scrum.

Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.

7. Eventos de SCRUM

Reunión de Planificación del sprint.

Scrum diario.

Revisión del sprint.

Retrospectiva del sprint.

Planificación del sprint

Descripción: En esta reunión se toman como base las prioridades y necesidades de negocio del cliente, y se determinan cuáles y cómo van a ser las funcionalidades que se incorporarán al producto en el siguiente sprint.

Se trata de una reunión conducida por el responsable del funcionamiento del marco scrum a la que deben asistir el propietario del producto y el equipo completo, y a la que también pueden asistir otros implicados en el proyecto.

Esta reunión debe dar respuesta a dos cuestiones:

Qué se entregará al terminar el sprint.

Cuál es el trabajo necesario para realizar el incremento previsto, y cómo lo llevará a cabo el equipo.

Scrum diario

Descripción: Reunión diaria breve, de no más de 15 minutos, en la que el equipo sincroniza el trabajo y establece el plan para las 24 horas siguientes.

Entradas:

Pila del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior.

Información del avance de cada miembro del equipo.

Resultados

Pila del sprint y gráfico de avance (burn-down) actualizados.

Identificación de posibles necesidades e impedimentos.

Formato de la reunión

Se recomienda realizarla de pie junto a un tablero con la pila del sprint y el gráfico de avance del sprint, para que todos puedan compartir la información y anotar.

En esta reunión cada miembro del equipo de desarrollo explica:

Lo que ha logrado desde el anterior scrum diario.

Lo que va a hacer hasta el próximo scrum diario.

Si están teniendo algún problema, o si prevé que puede encontrar algún impedimento.

Al final de la reunión:

El equipo refresca el gráfico de avance del sprint, con las estimaciones actualizadas,

El Scrum Master realiza las gestiones adecuadas para resolver las necesidades o impedimentos identificados

Revisión del sprint

Descripción: Reunión realizada al final del sprint para comprobar el incremento

No debe durar más de 4 horas, en el caso de revisar sprints largos. Para sprints de una o dos semanas, con una o dos horas de duración debería ser suficiente.

Objetivos:

El propietario del producto comprueba el progreso del sistema. Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto.

El propietario del producto identifica las funcionalidades que se pueden considerar “hechas” y las que no.

Al ver y probar el incremento, el propietario del producto, y el equipo en general obtienen feedback relevante para revisar la pila del producto.

Otros ingenieros y programadores de la empresa también pueden asistir para conocer cómo trabaja la tecnología empleada.

Revisión del sprint

Precondiciones:

Se ha concluido el sprint.

Asiste todo el equipo de desarrollo, el propietario del producto, el Scrum Master y todas las personas implicadas en el proyecto que lo deseen.

Entradas:

Incremento terminado.

Resultados:

Feedback para el propietario del producto: hito de seguimiento de la construcción del sistema, e información para mejorar el valor de la visión del producto.

Convocatoria de la reunión del siguiente sprint.

Retrospectiva

El equipo revisa los objetivos cumplidos del Sprint terminado. Se anota lo bueno y lo malo, para no volver a repetir los errores. Esta etapa sirve para implementar mejoras desde el punto de vista del proceso del desarrollo.

El objetivo de la revisión del sprint es analizar “QUÉ” se está construyendo, mientras que una reunión retrospectiva se centra en “CÓMO” lo estamos construyendo: “CÓMO” estamos trabajando, con el objetivo de analizar problemas y aspectos mejorables.

8.Medición y estimación ágil

La información es la materia prima para la toma de decisiones, y la que puede ser cuantificada proporciona criterios objetivos de gestión y seguimiento.

Desde el nivel concreto de la programación, hasta los más generales de la gestión global de la organización, tres son los fondos de escala o niveles de zoom con los que se puede medir el trabajo:

Desarrollo y gestión de la solución técnica.

Gestión de proyecto.

Gestión de la organización.

Flexibilidad y sentido común

Medir es Costoso: Antes de incorporar un procedimiento de medición, se debe cuestionar su conveniencia, y la forma en la que se aplicará.

Medir no es un fin en sí mismo: No se deben implantar procesos de medición simplemente por que sí.

Tomar una lista más o menos prestigiosa de métricas, e incorporarla a los procedimientos de la empresa puede seducir, al ofrecer un marco de trabajo monitorizado con indicadores y mediciones, pero no dice mucho a favor de las razones por las que se han adoptado.

Criterios para el diseño y aplicación de métricas

Cuantas menos, mejor

Medir es costoso.

Medir añade burocracia.

El objetivo de un equipo scrum es ofrecer la mejor relación valor / simplicidad.

Sura implementa la métodologia Scrum

Seguros Suramericana (Sura) anunció que ha elegido a Kleer para capacitar en metodologías ágiles y Scrum a más de 500 personas que integran las áreas de negocios, desarrollo, infraestructura y operaciones.

Un 60% de esas personas trabajan directamente en el área de TI, y el restante 40% son profesionales orientados al desarrollo de negocios.

Sura implementa la métodologia Scrum

el arquitecto de software Jubel Alberto Correa fue designado como product owner del proyecto.

“Logramos que el área de TI pase de recibir pedidos, a involucrarse realmente en la creación de las soluciones. Ahora las áreas de negocios también participan más en la construcción del software. Valoramos en primer lugar la interacción entre nosotros. Y sobre todo valoramos el software funcionando, la entrega temprana de valor y la adaptación al cambio. ¡Es emocionante! El trabajo en equipo es sin dudas más fuerte, y está todo orientado a lograr victorias tempranas”

Con las metodologías ágiles las cosas también cambiaron para los usuarios. 

“Esta nueva manera de trabajar a los usuarios les gusta mucho más; se sienten más escuchados y acompañados. Fue muy refrescante para mi trabajo, ahora siento que estoy haciendo una tarea de innovación, nos sacó de lo exclusivamente técnico. Fue un cambio radical en mi vida”

Sura implementa la métodologia Scrum

Scrum es el método ágil de manejo de proyectos más utilizado actualmente, una manera de trabajar útil a la hora de crear productos en contextos complejos, por ejemplo una campaña de marketing, una identidad corporativa o, como en el caso de Sura, sistemas informáticos. Gracias a Scrum es posible hacer frente a problemas complejos e impredecibles que emergen en este tipo de trabajo creativo e innovador.