¿Qué es Scrum?

Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP

Visual Developer - Visual Basic
http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx

Por Erwin Fischer

 ¿Qué es exactamente?
• Scrum es una metodología

• ¿Y para que se utiliza?

– Se utiliza, en el desarrollo del Software
concretamente, aunque hay gente por ahí que la
usa o la quiere usar en otras profesiones y áreas.
¿Y para eso del desarrollo del Software
tenéis que usar ese tal Scrum?
• No es estrictamente necesario
• Scrum por sus características no es válido para
cualquier proyecto.
• Es óptima para equipos de trabajo de hasta 8 personas,
– Yo diría que para el 90% de los proyectos y empresas, es
una metodología válida, pero no es una metodología válida
al 100%.
• Scrum es por lo tanto, una metodología más de las
muchas que hay, y ésta en concreto, se basa en la
filosofía del desarrollo ágil que fue expuesto por dos
japoneses alrededor del año 1986
has dicho desarrollo ágil varias veces...
¿que es eso exactamente?
• En el desarrollo del Software se pide básicamente
rapidez, calidad y reducción de costos, pero para
asumir estos retos, es necesario tener agilidad y
flexibilidad.
• Los ciclos de desarrollo por otro lado,
acostumbran a ser largos, y lo que se exige por
otra parte, es que esos ciclos sean lo más cortos
posibles.
• Para mas detalle sobre metodologías Agiles ver Manifiesto ágil y
Desarrollo ágil de Software
 ¿en qué consiste exactamente eso de
Scrum?
• Scrum es como decía antes, una metodología
ágil.
• Obedece a una necesidad realmente demandada
en el desarrollo del Software.
• Scrum no es ni la mejor metodología ni la única,
pero sí, es una metodología que está empujando
muy fuerte por
– la facilidad de implantación y
– Por su agilidad en cuanto a cambios y
– lo que propiamente aporta en comparación con otras
metodologías.
 ¿en qué consiste exactamente eso de
Scrum?
• Por un lado, Scrum evita la generación
documental burocrática. ¿Qué opinan?
• Con Scrum por otro lado, la idea principal es la
de ponerse a trabajar prácticamente desde el
primer momento y empezar a sacar frutos de
ese trabajo muy pronto.
 ¿cómo muestras al cliente esos
progresos en el trabajo?.
• En Scrum diferenciamos dos aspectos importantes, los
actores y las acciones
• Los actores son los que ejecutarán obviamente las
acciones.
• Estos de forma general, serán:
– Product Owner
– Scrum Master
– Scrum Team
– Usuarios o Clientes
• Para que un proyecto Software tenga éxito, el Usuario
• o Cliente, debe involucrarse sí o SÍ.
 Los roles de los actores
• El Product Owner conoce y marca las prioridades del
proyecto o producto.
• El Scrum Master asegura el seguimiento de la metodología
guiando las reuniones y ayudando al equipo ante cualquier
problema que pueda aparecer. Su responsabilidad es entre
otras, controlar las presiones externas.
• El Scrum Team son las personas responsables de
implementar la funcionalidad o funcionalidades elegidas
por el Product Owner.
• Los Usuarios o Cliente, son los beneficiarios finales del
producto, y son quienes viendo los progresos, pueden
aportar ideas, sugerencias o necesidades.
 ¿Y lo de las acciones?
• Las acciones tienen relación directa con los
actores. Sin ellas, todo sería un caos.
• En Scrum se indican claramente las acciones a
acometer y como acometerlas.
– hacerlo siempre de una forma adecuada y algo rígida
para asegurar resultados.
• Las acciones de Scrum forman parte de un ciclo
iterativo repetitivo,
– objetivo minimizar el esfuerzo y maximizar el
rendimiento en el desarrollo.
Las acciones fundamentales de Scrum
son:
• El Product Backlog corresponde con todas las
tareas, funcionalidades o requerimientos a
realizar.
– el Product Owner es la persona que se encarga de
marcar las prioridades, y es la persona que
mantiene y actualiza la lista de tareas.
Product Backlog
(Pila de Producto)
Con qué se cuenta
 A la hora de hacer una estimación
1. Las estimaciones son estimaciones, es decir,
aunque le dediques mucho tiempo, no
llegaremos a una precisión del 100%
2. Las estimaciones se deciden colaborativamente,
incluyendo a quienes harán la tarea ( esto último
es muy importante)
3. Se deben realizar como la combinación de:
• Opinión del experto
• Analogía: comparar con otras tareas ya estimadas
• Disgregación: separar una tarea en varias
 Sprint Backlog
• Corresponde con una o más tareas que provienen del Product
Backlog.
– se saca una o más tareas que van a formar parte del Sprint Backlog.
• Las tareas del Sprint Backlog se recomienda realizarlas en unas 2 ó 4
semanas.
– Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas.
– Eso debe de ser marcado antes de iniciar el Sprint Backlog, de hecho,
del Product Backlog se sacará la tarea o tareas realistas para acometer
el Sprint Backlog.
• Cuando un Sprint Backlog se inicia, éste NO puede ser alterado o
modificado.
– Hay que esperar a que concluya el Sprint Backlog para realizar la
modificación cuya tarea, formaría parte de otro Sprint Backlog.
Generando el Sprint Backlog
 Daily Scrum Meeting
• Es una tarea iterativa realizada todos los días que dure
el Sprint Backlog con el equipo de trabajo. Es una
reunión operativa, informal y ágil, de un máximo de 30
minutos, en la que se le hace 3 preguntas a cada
integrante del equipo.
– Qué tareas ha realizado desde la última reunión (que he
hecho).
– Sobre qué va a trabajar en el día actual (que voy a hacer
hoy).
– Identificación de obstáculos o riesgos que impiden o
pueden impedir el normal avance (que ayuda necesito). El
Scrum Master, debe eliminar aquí cualquier obstáculo que
encuentre.
Actualización diaria del Sprint
Gráfica de Trabajo Restante del Sprint
 ¿que se hace cuando una tarea del
Sprint Backlog se finaliza?
• Sprint Backlog, una vez que se inicia, no se toca.
Es decir, que una tarea se acaba, y punto
– Se continúa con otra tarea del Sprint Backlog y así
hasta que se acaben
• Lo que debemos tener claro, es que al finalizar un
Sprint Backlog (ya sea de 2 ó 4 semanas),
debemos haber acabado las tareas del Sprint
Backlog.
• Recordar: Las tareas del Sprint Backlog deben de
ser realistas.
 Al finalizar un Sprint Backlog
• Deberíamos tener algo, un entregable o algo
que se pueda mostrar y que enseñe los
avances acometidos en el Sprint.
• En el Product Backlog tendremos más tareas, y
es posible incluso que
– hayan salido nuevas tareas o que
– otras hayan desaparecido,
• Cuando se acaba el Sprint Backlog, debemos
hacer varias cosas importantes
 Sprint Planning Meeting
• Es una reunión Entre el Product Backlog y el Sprint Backlog
que tiene por objetivo, planificar el Sprint a partir del
Product Backlog.
• El objetivo de esta reunión es la de mover las tareas del
Product Backlog al Sprint Backlog.
• En esta reunión, suelen participar el
– Product Owner (quien prioriza las tareas),
– El Scrum Master y
– El Scrum Team.
• Del Sprint Planning Meeting, sale también el Sprint Goal,
que es un pequeño documento o una breve descripción
que indica lo que el Sprint intentará alcanzar.
 Sprint Review
• Se revisa en unas 2 horas como máximo el Sprint
finalizado.
• Al llegar a este punto, debemos tener "algo" que el
Cliente o el Usuario pueda ver y tocar.
• En esta reunión, suelen asistir
– Product Owner,
– Scrum Master,
– Scrum Team y
– personas que podrían estar involucradas en el proyecto.
• El Scrum Team es quién muestra los avances realizados
en el Sprint.
 Sprint Retrospective
• Se inicia al finalizar un Sprint Backlog y el Sprint
Review,
• El Product Owner revisará con el equipo los
objetivos marcados inicialmente en el Sprint
Backlog concluido,
– Se aplicarán los cambios y ajustes si son necesarios, y
– Se marcarán los aspectos
• positivos (para repetirlos) y los aspectos
• negativos (para evitar que se repitan)
– del Sprint.
 Pila de Entrega
(subconjunto de la Pila de Producto)
Gráfica de Trabajo Restante de la
Entrega
¿Y porque es eso de las 2 ó 4 semanas?
• Cada equipo, cada empresa, cada proyecto,
puede poner la franja horaria y frecuencia
temporal que considere oportuno así como
cambiar aspectos de Scrum,
– Pero es mejor hacer esto así que de otra forma.

¿Porqué?
 El ajuste temporal de 2 ó 4 semanas
• En término medio que está basado en la experiencia de
muchas personas en muchos proyectos.
• No es lo mismo reconducir el proyecto perdiendo 2 ó 4
semanas, que reconducirlo perdiendo 6 meses por
ejemplo.
• La idea de la metodología ágil es que
– adopte los cambios, que se pueda reconducir el proyecto
en un momento dado, y que afecte lo menos posible a
• los costos,
• los tiempos y
• al equipo de trabajo
Resultados encuesta
 referencias
• http://geeks.ms/blogs/jorge/archive/2007/05
/09/explicando-scrum-a-mi-abuela.aspx
• http://scrumtraininginstitute.com/home/strea
m_download/scrumprimer-es