SCRUM

Desarrollo de Soluciones en Software Libre

José Castillejo Tarazona

Valeria León Orellano
EL PROYECTO IDEAL

Al inicio del proyecto

El cliente sabe
perfectamente lo que
necesita Se toman requisitos
detallados y ya no es
necesario volver a hablar
con el cliente hasta el final
del proyecto
Tu sabes como hacer
para conseguirlo Durante el proyecto:
• Con la documentación adecuada que elabora cada especialista, la
siguiente fase encuentra todo lo que necesita, sin que se haya
perdido ninguna información por el camino.
• Viendo moverse estos entregables, todo el mundo está seguro de
que el proyecto está yendo bien. Es suficiente con hacer el control
de calidad al final del proyecto.
• Nada cambia durante el camino.
EL PROYECTO IDEAL

Al final del proyecto el

cliente recibe lo que
esperaba y no hay que
cambiar nada.
EL PROYECTO IDEAL

¿Seguro que el
usuario final recibe Problemas
lo que esperaba? Típicos en
Proyectos
El cliente tarda mucho tiempo en poder utilizar
el resultado del proyecto.

Mientras tanto, el contexto

cambia y los competidores
lanzan nuevos productos.
Si se cancela el proyecto
se habrá gastado el dinero
a cambio de NADA.
 Hay retraso y hay que
entregar ya. Empiezan
El proyecto se complicó
los parches y no hay
más de lo esperado.
tiempo para pruebas /
control de calidad.

Apenas se dedican a
El equipo hace horas cumplir órdenes.
extraordinarias y está Cada
poco motivado. uno hace sólo lo
suyo..

¡¡¡ Pero si el proyecto

¡¡¡ Y ahora el cliente está acabando y no
pide cambios !!! queda ni tiempo ni
presupuesto !!!
¿POR QUÉ
APARECEN
ESTOS PROBLEMAS?
Un proyecto Tradicional:
Dedicamos mucho esfuerzo a objetivos que
aportan poco valor.

De las funcionalidades
desarrolladas:
7% se usan “siempre”
13% se usan “a menudo”
16% “a veces”
19% “pocas veces”
45% “NUNCA”

Dinero y tiempo
tirados a la basura.
¿Quién paga esto?
 Locura: Hacer
lo mismo que la
vez anterior,
pero esperar
resultados
diferentes.”
•
LA
ALTERNATIVA
SCRUM
ÁGIL • Valorar más a los individuos
y su interacción que a los
procesos y las herramientas
• Valorar más el software que
funciona que la
documentación exhaustiva
• Valorar más la colaboración
con el cliente que la
negociación contractual
• Valorar más la respuesta al
cambio que el seguimiento
de un plan
SCRUM
• Es simple
• Es difícil
• Funciona
El espíritu de Scrum
Beneficios: Calidad y Competitividad
• Gestión de expectativas del cliente basada en resultados
tangibles.
• Flexibilidad a cambios: adaptación a las necesidades del
cliente, a cambios en el mercado, etc..
• Resultados anticipados (time to market).
• Mantenibilidad y productividad
• Equipo motivado implicado, creativo y que disfruta.
SCRUM: Proceso de gestión ágil de proyectos y
trabajo en equipo
Es un proceso iterativo e
incremental.
priorizando el producto
por valor de negocio
respecto a costes.
La mejora continua
está integrada. De
manera regular:
• Se muestra producto
final, integrado, probado
y documentado.
• El equipo mejora su
proceso de trabajo.

Es un conjunto de prácticas de
comunicación,
colaboración y trabajo en equipo.
Scrum - Roles
El “Propietario del Producto” es el único representante de
todos los interesados en el proyecto. Puede ser interno
o externo. Tiene la responsabilidad de conocer y definir
los objetivos y los prioriza. Su misión es dirigir los
resultados del proyecto

El equipo es multidisciplinar, autogestionado y con

responsabilidad conjunta y mutua. Normalmente cada
equipo es de 5 a 9 personas*, que trabajan en un espacio
común para permitir la comunicación cara a cara y que se
sincronizan diariamente. Realiza las estimaciones.

El jefe de proyecto pasa a ser un facilitador de la

colaboración intraequipo y con el cliente (por ejemplo en
las reuniones de Scrum) y quita impedimentos para que
el equipo se mantenga enfocado. Es el responsable del
proceso e impide interferencias externas.
Control empírico Iterativo e incremental
Hacer entregas cortas y
Participación del cliente y
regulares
transparencia para que pueda
del producto final (cada 2-4
guiar de manera regular los
semanas) para obtener
resultados del proyecto
feedback e
irse acercando a las
expectativas
del cliente.
Priorización por valor de negocio
Proporcionar resultados
anticipados (“time to market”) Orientar el proyecto a objetivos
para el cliente, no a tareas,
priorizando según el valor de
negocio vs esfuerzo y riesgo.
Artefactos(1)
• Product Backlog
• Contiene los requisitos del sistema con la prioridad respectiva y es
usado en la planificación del proyecto.
• Es dinámico y se desarrolla a medida que el producto y el
ambiente en el que se trabaja, evoluciona.
• Se genera a partir de reuniones que se realizarán para tener una
visión clara y total del sistema.
Artefactos(2)
• Burndown Chart
• Muestra el avance de los equipos de trabajo respecto al trabajo
pendiente. Sirve para predecir cuándo se completará todo el
trabajo.
 Artefactos(3)
• Sprint Backlog
• Define el trabajo que el
equipo desarrollará para
poder convertir el product
backlog en un incremento
funcional del producto;
además contendrá las tareas
necesarias para cubrir la
funcionalidad del sprint.
Existirá un documento de
este tipo por cada iteración
que se desarrolle en el
proyecto. Cada tarea
realizada pasará a formar en
la iteración una parte
completa y funcional del
producto.
Artefactos(4)
• Scrum Taskboard
• La lista de objetivos a completar en
la iteración se puede gestionar
mediante un tablero o pizarra de
tareas (Scrum Taskboard) que
actúa como radiador de
información.
• Difunde el estado actual de la
iteración por lo que debe estar
visible desde los puestos de
trabajo del equipo con sólo hacer
un movimiento de cabeza. Es útil
en las reuniones que se realizan
durante la iteración, por lo que en
él se pone aquella información que
se quiera consultar cuando se
tenga conversaciones delante del
tablero.
Valores
• Delegación de atribuciones (empowerment) al equipo
para que pueda auto-organizarse y tomar las decisiones
sobre el desarrollo.
• Respeto entre las personas. Los miembros del equipo
deben confiar entre ellos y respetar sus conocimientos y
capacidades.
• Responsabilidad y auto-disciplina.
• Trabajo centrado en el valor para el cliente y el desarrollo
de lo comprometido.
• Información, transparencia y visibilidad del desarrollo del
proyecto.
Desventajas
• No gestiona riesgos que son considerados externos al
proyecto.
• Requiere delegar responsabilidades al equipo, incluso permite
fallar si es necesario.
• Dificultad de aplicación en grandes proyectos.
• Parte del paradigma consiste en usar el método “tal cual”,
evitando adaptarlo a la empresa.
• Plantea un problema si el desarrollo está restringido por una
fecha de entrega y un precio de entrega cerrados por contrato.
• Asume que el equipo está muy formado y motivado.
• Presupone que el cliente está muy involucrado en el
desarrollo, participa de forma activa y continua, y revisa
frecuentemente el avance de la funcionalidad conforme salen a
la luz los sprints.
 Caso práctico

Un cliente se pone en contacto con una empresa que fabrica robots.

El cliente les realiza el pedido.

Quiero un robot que me sirva

de escolta
 Caso práctico

El Cliente se reune con el Dueño de producto, que toma nota de lo que tiene en su
cabeza.

Cliente Dueño de Producto

 Caso práctico

El Dueño del Producto divide el proyecto en historias que son las que componen la
pila de producto.

Dueño de Producto

Pila de Producto
 Caso práctico

El equipo se reune para estimar el coste de cada historia de la pila de producto.

Equipo
 Caso práctico

El cliente, una vez aprobado el presupuesto, reordena la pila de producto para que
el equipo vaya trabajando según la prioridad del cliente.

Menos imporantes

Cliente

Urgentes
 Caso práctico

El equipo comienza su trabajo desglosando la primera historia de la pila de

producto, la cual subdividen en tareas menores para crear la pila de sprint.
 Caso práctico

La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de 15 días

en tareas mas pequeñas, que tarden como mucho dos días.
 Caso práctico

Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto, que ha
consultado con el cliente, antes de comenzar el sprint.

Menos imporantes

Dueño de Producto

Urgentes
 Caso práctico

El equipo comienza el sprint tomando las tareas priorizadas.

Una vez concluida una se toma la siguiente de la lista.
Se convoca todos los días una reunión del equipo donde se cuenta las tareas
realizadas el día anterior y cuales se van a realizar ese día.
 Caso práctico

Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el resultado

del trabajo realizado.
El cliente ya tiene el primer contacto con su encargo y además puede volver a
priorizar la pila de producto antes de que comience otro sprint.

Buen trabajo

Dueño de Producto Cliente

 Caso práctico

El equipo de trabajo celebra su buen hacer con una reunión de retrospectiva,

donde se analiza lo ocurrido durante el sprint.
Esta reunión se celebra fueras de la oficina, normalmente con comida y bebidas de
por medio.
Referencias
• ftp://200.37.45.117/Experiencia%20Profesional%20-
%20Documentacion%20Inicial/Tesis/SCORM.2004.3ED.DocSuite/scrum-y-xp-desde-
las-trincheras.pdf
• http://bibdigital.epn.edu.ec/bitstream/15000/3760/1/CD-3537.pdf
• http://repositorio.utp.edu.co/xml/bitstream/handle/123456789/791/0053L155mc.pdf?se
quence=1
• http://santimacnet.wordpress.com/2010/11/05/proyectos%C2%A0agiles-con-scrum/
• http://www.clubdesarrolladores.com/articulos/mostrar/63-metodologia-scrum/2
• http://www.cyta.com.ar/ta1101/v11n1a4.htm
• http://www.mastersoft.com.ar/MsWeb/otros_archivos/NotaScrumPCUsers.pdf
• http://www.mountaingoatsoftware.com/topics/scrum
• http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf
• http://www.optimus-software.com/noticias/2011/11/28/desventajas-del-scrum/
• http://www.proyectosagiles.org/que-es-scrum
• http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20ES.pdf#view=fit
• http://www.scrummanager.net/files/sm_proyecto.pdf
• http://www.slideshare.net/jparra2K/introduccon-a-scrum
• http://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-
1516220