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 SCRUM
Es 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 metodología 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 metodología 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.