INTRODUCCION

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas

prcticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene origen
en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum est especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener resultados
pronto, donde los requisitos son cambiantes o poco definidos, donde la innovacin,
la competitividad, la flexibilidad y la productividad son fundamentales.

Scrum tambin se utiliza para resolver situaciones en que no se est entregando al cliente
lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la
calidad no es aceptable, cuando se necesita capacidad de reaccin ante la competencia,
cuando la moral de los equipos es baja y la rotacin alta, cuando es necesario identificar y
solucionar ineficiencias sistemticamente o cuando se quiere trabajar utilizando
un proceso especializado en el desarrollo de producto.

SCRUM

Scrum es una metodologa de desarrollo muy simple, que requiere trabajo duro porque no se basa
en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin
del proyecto.

Scrum es una metodologa gil, y como tal:

- Es un modo de desarrollo de carcter adaptable ms que predictivo.
- Orientado a las personas ms que a los procesos.
- Emplea la estructura de desarrollo gil: incremental basada en iteraciones y revisiones.

Adopta una estrategia de desarrollo incremental, en lugar de la planificacin y ejecucin

completa del producto.

Scrum es una forma gil para gestionar un proyecto, por lo general de desarrollo de
software. El desarrollo gil de software con Scrum se percibe a menudo como una
metodologa; pero en lugar de ver Scrum como metodologa, pensar en l como un marco
para la gestin de un proceso.

En el mundo gil Scrum, en lugar de proporcionar descripciones completas y detalladas

de cmo todo lo que se debe hacer en un proyecto, gran parte de ella se queda hasta el
equipo de desarrollo de software de Scrum. Esto se debe a que el equipo sabr mejor
forma de resolver el problema que se presentan.
Es por esto que en el desarrollo de Scrum, por ejemplo, una reunin de planificacin del
sprint se describe en trminos de los resultados deseados (un compromiso con un
conjunto de caractersticas que se desarrollarn en el siguiente sprint) en lugar de un
conjunto de criterios de ingreso, las definiciones de tareas de validacin, criterios, criterios
de salida y as sucesivamente, como se presenta en la mayora de las metodologas.

Scrum se basa en un equipo multifuncional de auto-organizacin. El equipo de scrum se

auto-organiza en que no hay un lder global del equipo que decide qu persona va a hacer
qu tarea o cmo se resolvi un problema. Esas son las cuestiones que se deciden por el
equipo en su conjunto, es decir, todo el mundo es necesario para tomar una caracterstica
de la idea a la ejecucin.

Dentro de desarrollo gil, equipos de Scrum son apoyados por dos roles especficos. El
primero es un ScrumMaster, que pueden ser considerados como un entrenador para el
equipo, los miembros del equipo que ayudan a utilizar el proceso de Scrum para llevar a
cabo al ms alto nivel.

El propietario del producto (PO) es el otro papel, y en el desarrollo de software Scrum,

representa los negocios, clientes o usuarios, y gua al equipo hacia la construccin el
producto adecuado.

EL Origen

Scrum es una metodologa gil de desarrollo de proyectos que toma su nombre y principios de los
estudios realizados sobre nuevas prcticas de produccin por Hirotaka Takeuchi e Ikujijo Nonaka a
mediados de los 80.

En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con

el avance en formacin de mel (scrum en ingls) de los jugadores de Rugby, a raz de lo
cual qued acuado el trmino scrum para referirse a ella.

(V. Navegapolis: El nuevo escenario).

Aunque surgi como modelo para el desarrollo de productos tecnolgicos, tambin se emplea en
entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones
frecuentes en el desarrollo de determinados sistemas de software.

Jeff Sutherland aplic el modelo Scrum al desarrollo de software en 1993 en Easel Corporation
(Empresa que en los macro-juegos de compras y fusiones se integrara en VMARK, luego en
Informix y finalmente en Ascential Software Corporation). En 1996 lo present junto con Ken
Schwaber como proceso formal, tambin para gestin del desarrollo de software en OOPSLA 96.
Ms tarde, en 2001 seran dos de los promulgadores del Manifiesto_gil. En el desarrollo de
software scrum est considerado como modelo gil por la Agile Alliance.
Caractersticas de Scrum

SCRUM es un modelo de referencia que define un conjunto de prcticas y roles, y que

puede tomarse como punto de partida para definir el proceso de desarrollo que se
ejecutar durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que
mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner,
que representa a los stakeholders (interesados externos o internos), y el Team que incluye
a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por
el equipo), el equipo crea un incremento de software potencialmente
entregable (utilizable). El conjunto de caractersticas que forma parte de cada sprint viene
del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen
el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se
determinan durante la reunin de Sprint Planning. Durante esta reunin, el Product
Owner identifica los elementos del Product Backlog que quiere ver completados y los
hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese
trabajo que puede comprometerse a completar durante el siguiente sprint. 1 Durante el
sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos estn
congelados durante el sprint.

Scrum permite la creacin de equipos auto-organizados impulsando la co-localizacin de

todos los miembros del equipo, y la comunicacin verbal entre todos los miembros y
disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes

pueden cambiar de idea sobre lo que quieren y necesitan (a menudo
llamado requirements churn), y que los desafos impredecibles no pueden ser fcilmente
enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una
aproximacin pragmtica, aceptando que el problema no puede ser completamente
entendido o definido, y centrndose en maximizar la capacidad del equipo de entregar
rpidamente y responder a requisitos emergentes.

Las caractersticas ms marcadas que se logran notar en Scrum seran: gestin regular
de las expectativas del cliente, resultados anticipados, flexibilidad y adaptacin, retorno de
inversin, mitigacin de riesgos, productividad y calidad, alineamiento entre cliente y
equipo, por ltimo equipo motivado. Cada uno de estos puntos mencionados hacen que el
Scrum sea utilizado de manera regular en un conjunto de buenas prcticas para el trabajo
en equipo y de esa manera obtener resultados posibles.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que

van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las
mayores ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco
esfuerzo para comenzarse a utilizar.

Roles en Scrum
Product Owner

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum
trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner
escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los

obstculos que impiden que el equipo alcance el objetivo del sprint. ElScrumMaster no es
el lder del equipo (porque ellos se auto-organizan), sino que acta como una proteccin
entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que
el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las
reglas se cumplan.

Equipo de desarrollo

El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 3 a 9

personas con las habilidades transversales necesarias para realizar el trabajo (anlisis,
diseo, desarrollo, pruebas, documentacin, etc).

Roles Auxiliares

Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no
se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en
cuenta. Un aspecto importante de una aproximacin gil es la prctica de involucrar en el
proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es
importante que esa gente participe y entregue retroalimentacin con respecto a la salida
del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir el
beneficio acordado que justifica su produccin. Slo participan directamente durante las
revisiones del sprint.

Administradores (Managers)

Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum

Daily Scrum o Stand-up meeting

Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se

llama daily standup o Stand-up meeting. El scrum tiene unas guas especficas:

La reunin comienza puntualmente a su hora.

Todos son bienvenidos, pero slo los involucrados en el proyecto pueden hablar.

La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del
equipo.

La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los das.

Durante la reunin, cada miembro del equipo contesta a tres preguntas:

Qu has hecho desde ayer?

Qu es lo que hars hasta la reunin de maana?

Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del
ScrumMaster recordar estos impedimentos).

Cada da normalmente despus del Daily Scrum:

Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocndose

especialmente en reas de solapamiento e integracin.

Asiste una persona asignada por cada equipo.

La agenda ser la misma que la del Daily Scrum, aadiendo adems las siguientes cuatro
preguntas:

Qu ha hecho tu equipo desde nuestra ltima reunin?

Qu har tu equipo antes que nos volvamos a reunir?

Hay algo que demora o estorba a tu equipo?

Ests a punto de poner algo en el camino del otro equipo?

Reunin de Planificacin del Sprint (Sprint Planning Meeting)

Al inicio de cada ciclo de Sprint (cada 15 o 30 das), se lleva a cabo una reunin de
planificacin del Sprint. Se pretende:

Seleccionar qu trabajo se har.

Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que llevar
hacer el trabajo.

Identificar y comunicar cunto del trabajo es probable que se realice durante el actual
Sprint.

Realizarse esta planificacin en ocho horas como tiempo lmite.

Al final del ciclo Sprint se hacen dos reuniones ms: la reunin de revisin del Sprint y
la retrospectiva del Sprint.
Reunin de Revisin del Sprint (Sprint Review Meeting)

Revisar el trabajo que fue completado y no completado

Presentar el trabajo completado a los interesados (alias demo)

El trabajo incompleto no puede ser demostrado

Cuatro horas como lmite

Retrospectiva del Sprint (Sprint Retrospective)

Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los
miembros del equipo dejan sus impresiones sobre el sprint recin superado. El propsito
de la retrospectiva es realizar una mejora continua del proceso. Esta reunin tiene un
tiempo fijo de cuatro horas.

Sprint

El Sprint es el perodo en el cual se lleva a cabo el trabajo en s. Es recomendado que la

duracin de los sprints sea constante y definida por el equipo con base en su propia
experiencia. Se puede comenzar con una duracin de sprint en particular (2 o 3 semanas)
e ir ajustndolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final
de cada sprint, el equipo deber presentar los avances logrados, y el resultado obtenido
es un producto potencialmente entregable al cliente. Asimismo, se recomienda no agregar
objetivos al sprint o sprint backlog a menos que la falta de estos objetivos amenace al
xito del proyecto. La constancia permite la concentracin y mejora la productividad del
equipo de trabajo.

Benefi cios de Scrum

Flexibilidad a cambios. Gran capacidad de reaccin ante los cambiantes requerimientos

generados por las necesidades del cliente o la evolucin del mercado. El marco de trabajo
est diseado para adecuarse a las nuevas exigencias que implican proyectos complejos.

Reduccin del Time to Market. El cliente puede empezar a utilizar las caractersticas ms
importantes del proyecto antes de que est completamente terminado.

Mayor calidad del software. El trabajo metdico y la necesidad de obtener una versin de
trabajo funcional despus de cada iteracin, ayuda a la obtencin de un software de alta
calidad.

Mayor productividad. Se logra, entre otras razones, debido a la eliminacin de la

burocracia y la motivacin del equipo proporcionado por el hecho de que pueden
estructurarse de manera autnoma.
Maximiza el retorno de la inversin (ROI). Creacin de software solamente con las
prestaciones que contribuyen a un mayor valor de negocio gracias a la priorizacin por
retorno de inversin.

Predicciones de tiempos. A travs de este marco de trabajo se conoce la velocidad media

del equipo por sprint, con lo que es posible estimar de manera fcil cuando se podr
hacer uso de una determinada funcionalidad que todava est en el Backlog.

Reduccin de riesgos El hecho de llevar a cabo las funcionalidades de mayor valor en

primer lugar y de saber la velocidad a la que el equipo avanza en el proyecto, permite
despejar riesgos efectivamente de manera anticipada.

Documentos

Product backlog

El product backlog es un documento de alto nivel para todo el proyecto. Contiene

descripciones genricas de todos los requisitos, funcionalidades deseables, etc.
priorizadas segn su retorno sobre la inversin (ROI) . Es el qu va a ser construido. Es
abierto y solo puede ser modificado por el product owner. Contiene estimaciones
realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de
desarrollo requerido. Esta estimacin ayuda al product owner a ajustar la lnea temporal
(KEV) y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos
caractersticas tienen el mismo valor de negocio la que requiera menor tiempo de
desarrollo tendr probablemente ms prioridad, debido a que su ROI ser ms alto.

Sprint backlog

El sprint backlog es un documento detallado donde se describe el cmo el equipo va a

implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas pero
ninguna tarea con una duracin superior a 16 horas. Si una tarea es mayor de 16 horas,
deber ser dividida en otras menores. Las tareas en elsprint backlog nunca son
asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.

Burn down char

La burn down chart es una grfica mostrada pblicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando
una lnea que conecte los puntos de todos los Sprints completados, podremos ver el
progreso del proyecto. Lo normal es que esta lnea sea descendente (en casos en que
todo va bien en el sentido de que los requisitos estn bien definidos desde el principio y
no varan nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha
terminado (no hay ms requisitos pendientes de ser completados en el Backlog). Si
durante el proceso se aaden nuevos requisitos la recta tendr pendiente ascendente en
determinados segmentos, y si se modifican algunos requisitos la pendiente variar o
incluso valdr cero en algunos tramos.