Universidad Catlica de La Plata

Facultad de Ciencias Exactas e Ingeniera

Ingeniera de Sistemas I
Metodologa Scrum
Es una metodologa gil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es
maximizar el retorno de la inversin para la empresa (ROI). Se basa en construir primero la
funcionalidad de mayor valor para el cliente y en los principios de inspeccin continua, adaptacin, autogestin e innovacin.
Con Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteracin a
iteracin. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio
de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva
iteracin.
Esta metdica de trabajo promueve la innovacin, motivacin y compromiso del equipo que forma parte
del proyecto, por lo que los profesionales encuentran un mbito propicio para desarrollar sus
capacidades.
Beneficios
Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le
aporta cada requisito / historia del proyecto, el equipo los estima y con esta informacin el
Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product
Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al
equipo.
Flexibilidad a cambios: Alta capacidad de reaccin ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodologa est
diseada para adaptarse a los cambios de requerimientos que conllevan los proyectos
complejos.
Reduccin del Time to Market: El cliente puede empezar a utilizar las funcionalidades ms
importantes del proyecto antes de que est finalizado por completo.
Mayor calidad del software: La metdica de trabajo y la necesidad de obtener una versin
funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad superior.
Mayor productividad: Se consigue entre otras razones, gracias a la eliminacin de la burocracia y
a la motivacin del equipo que proporciona el hecho de que sean autnomos para organizarse.
Maximiza el retorno de la inversin (ROI): Produccin de software nicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de
inversin.
Predicciones de tiempos: Mediante esta metodologa se conoce la velocidad media del equipo
por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar
fcilmente para cuando se dispondr de una determinada funcionalidad que todava est en el
Backlog.
Reduccin de riesgos: El hecho de llevar a cabo las funcionalidades de ms valor en primer
lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.
Desarrollo:
1. Product Backlog y Product Owner
Al empezar el proyecto, el responsable del proyecto, que conoce lo que tiene que hacer, que no va a
codificar y que est en contacto ms estrecho con el cliente , debe crear una lista de funciones que
quiere que implemente el programa. Le pondremos un nombre en ingls al cliente, que es el que le da
Scrum, le llamaremos Product Owner.

Las funciones de la lista deben ser algo "tangible", es decir, que si nuestro programa implementa una de
esas funciones, un usuario que use nuestro programa puede ver que esa funcin est implementada.
Estas funciones "cuadran" muy bien con las historias de usuario de la programacin extrema.
A esta lista, tambin le daremos un nombre en ingls decidido por Scrum y la llamaremos Product
Backlog.
A lo largo del proyecto se podrn aadir ms funcionalidades a esta lista, o quitarlas o modificarlas. Slo
el Product Owner -el jefe- podr ordenarla y deber mantenerla ordenada, de forma que las primeras
funciones del Product Backlog -la lista- se harn antes.
2. Sprint Planning Meeting y Spring Backlog
El primer da que empecemos a trabajar en el proyecto, se hace una reunin, en la que estarn el
Product Owner y los programadores -Scrum Team- que van a participar en el proyecto. Esta reunin
tambin tiene nombre decidido por Scrum y se llama Sprint Planning Meeting.
En esa reunin se elige un plazo de tiempo que Scrum aconseja que sea un mes. De todas formas, en
funcin del proyecto, necesidades y dems, puede elegirse otro plazo: una semana, dos semanas o lo
que sea. Nunca debera ser un plazo muy largo.
Una vez elegido ese plazo de tiempo, se toma el Product Backlog y se van mirando las tareas
empezando por la primera. Se pregunta al Scrum Team ... puede la primera tarea estar hecha dentro
de un mes?. El Scrum Team la examina, descompone en subtareas si hace falta, estiman el tiempo que
tardarn en hacerla y dicen "s". Si dicen que no, habr que descomponerla en tareas ms sencillas
hasta que digan el menos que s a una de ellas.
Se toma la segunda tarea y se pregunta al Scrum Team ... puede estar la primera y la segunda en un
mes?. Vuelven a estimar y dicen "s".
Se repite el proceso con las siguientes tareas hasta que el Scrum Team empiece a dudar si s o si no va
a estar todo eso. Si el Product Owner quiere que est alguna tarea que no va a estar, puede cambiarla
por otra que s est, o "reducir" el alcance de una de las que ha entrado para que entre otra. En fin, este
es el momento de "negociar" entre los programadores y el jefe qu va a entrar o no en un mes. El jefe
puede decidir el orden, intercambiar tareas, modificarlas o partirlas, pero los programadores tienen la
ltima palabra de cunto tiempo necesitan para cada tarea. El tiempo necesario para todas las tareas
seleccionadas no puede superar el mes.
Una vez llegado a un acuerdo, esas funcionalidades se pasan a una nueva lista, llamada Sprint
Backlog. Hemos quedado todos de acuerdo que dentro de un mes vamos a entregar al Product Owner
una versin del programa que tenga todas las tareas del Srpint Backlog funcionando.
3. Daily Scrum Meeting y Scrum Master
Despus de la reunin anterior en la que se decide el Spring Backlog, vamos todos a trabajar. A partir
de ese da, todos los das, preferiblemente a primera hora, el Scrum Team se rene y cada uno contesta
a tres preguntas:

Qu hiciste ayer?
Qu vas a hacer hoy?
Qu ayuda necesitas?

Uno de los programadores hace de moderador de la reunin y se le llama Scrum Master. Este no es
jefe de los dems, simplemente debe encargarse de que la reunin no dure ms de un cuarto de
hora /media hora y de que las ayudas/ problemas que plantean los programadores se resuelvan a lo
largo del da. El Product Owner tambin debera colaborar en eso de "quitar obstculos", estar

disponible para consultas, etc. La ayuda necesaria puede ser de cualquier tipo: "no conozco este tema y
necesito alguien que me ayude", "necesitara tener datos en la base de datos para hacer pruebas",
"necesito tener mi PC conectado al osciloscopio", etc. En fin, cualquier cosa que uno de los
programadores considere que le facilita el trabajo -y que sea razonable, que hay de todo-.
En esta reunin tambin se aprovecha para volver a estimar el tiempo de las tareas en curso. Puede
que una tarea, el primer da, se dijera que se iba a tardar ocho horas. Resulta que hoy, despus de
haber trabajado el da de ayer en ella, sale un problema inesperado y hoy decidimos que vamos a tardar
10 horas ms en resolverla, se apunta y listo.
Despus de varios das de reuniones se ver rpidamente de esta forma si vamos segn lo previsto o
nos vamos a pasar en tiempo. Nuestro Product Owner, adems, puede verlo, sobre todo si vamos
registrando en algn grfico el da a da indicando cuantas horas suponemos que nos quedan para
acabar en el eje vertical y los das en el eje horizontal. El grfico de la figura, por ejemplo

Aunque en teora Scrum dice que la lista de tareas a hacer Sprint Backlog no se toca, hay mucha gente
que decide aadir o quitar tareas en caso de ir adelantados o retrasados. Lo importante es entregar a
final de mes una versin con determinadas funcionalidades implementadas y no irse ni demasiado all
ni demasiado ac en ese mes.
4. Sprint Review y Sprint Retrospective
Ya ha pasado el mes de plazo. Si estimamos bien, tenemos nuestra versin del programa con todas las
funcionalidades del Sprint Backlog. Si estimamos mal, quizs esta versin tenga alguna funcionalidad
menos o alguna de ms.
Ahora se hace una reunin de aproximadamente un par de horas, llamada Sprint Review, a la que
acude el Scrum Team, el Scrum Master, el Product Owner y cualquier otra persona interesada en el
producto. En ella el Scrum Master ensea la versin a los dems. Los asistentes pueden dar opiniones,
posibles mejoras, etc.
Inmediatamente despus, se hace otra reunin, llamada Sprint Restropective, en la que el Scrum
Master, el Scrum Team y el Product Owner analizan qu cosas pueden mejorarse a la hora de trabajar
para el siguiente Sprint, si la comunicacin ha sido bueno o debe mejorarse, si hay algn problema que
deba subsanarse. En general, con un ambiente distendido y espritu constructivo, ver cmo se puede
mejorar la forma de trabajo en el Sprint Backlog del siguiente mes.

Y vuelta a empezar, otro Sprint Planning Meeting para ver qu funcionalidades va a tener la nueva
versin del mes que viene, un nuevo Sprint Backlog
Consideraciones:
Como vemos, Scrum no dice nada de si hacer o no hacer diseo, si hacer o no hacer Test Unitarios, si
hacer o no hacer documentacin, si trabajar en parejas o no, etc, etc. Scrum nicamente nos indica
cmo conseguir que todos trabajen con el mismo objetivo, a corto plazo y deja bastante visible como
avanza el proyecto da a da.
Lo ideal es complementarlo con una metodologa de desarrollo software gil, como la programacin
extrema. El Product Backlog pueden ser perfectamente las historias de usuario, el trabajo se puede
hacer perfectamente en parejas, con sus test unitarios previos al cdigo, etc.
Tambin podra utilizarse algn otro tipo de metodologa. Por ejemplo, pueden dedicarse unos das al
principio de mes para disear cmo se van a implementar las funcionalidades de ese mes, re-disear lo
que ya hay hecho para acoger lo nuevo, en cada tarea puede considerarse el tiempo necesario para
generar la documentacin que se pida de forma que la cada tarea tardar un poco ms por la
documentacin asociada y ese tiempo se tiene en cuenta en la estimacin, etc, etc.