UNIVERSIDAD NACIONAL DE TRUJILLO

15

UNIVERSIDAD NACIONAL DE TRUJILLO

Metodologa SCRUM
RESUMEN: SCRUM est considerada como una metodologa gil de desarrollo de
proyectos de Sistemas de Informacin y software, orientada a proyectos medianos y
pequeos y en los que el usuario no tiene una idea cabal de sus requerimientos.

1.

INTRODUCCIN
Scrum es un marco de trabajo para la gestin y desarrollo de software basada en un
proceso iterativo e incremental utilizado comnmente en entornos basados en el
desarrollo gil de software.
Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software,
puede ser utilizado en equipos de mantenimiento de software, o en una
aproximacin de gestin de programas: Scrum de Scrums.
Esta metodologa tiene mayor ventaja en proyectos tercerizados o de outsourcing,
es decir cuando el equipo de desarrollo es externo a la empresa o institucin.

2.

SCRUM
En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximacin
holstica que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos
productos comerciales.

2.1. Que es Scrum?

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.

15

UNIVERSIDAD NACIONAL DE TRUJILLO

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.

2.2. Roles en Scrum

2.2.1. Roles Principales
2.2.1.1 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.
2.2.1.2 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. El ScrumMaster no es el lder del equipo (porque ellos se autoorganizan), 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.
2.2.1.3 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).

2.2.2 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.

15

UNIVERSIDAD NACIONAL DE TRUJILLO

2.2.2.1

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.

2.2.2.2 Administradores (Managers)

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

2.3. Reuniones en Scrum

2.3.1

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:3
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?

15

UNIVERSIDAD NACIONAL DE TRUJILLO

2.3.2

Scrum de Scrum
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?

2.3.3

Reunin de Planificacin del Sprint (Sprint Planning Meeting)

Al inicio del ciclo Sprint (cada 15 o 30 das), una Reunin de
Planificacin del Sprint se lleva a cabo.
Seleccionar qu trabajo se har
Preparar, con el equipo completo, el Sprint Backlog que
detalla el tiempo que tomar hacer el trabajo.
Identificar y comunicar cunto del trabajo es probable que
se realice durante el actual Sprint
Ocho horas como lmite
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la
Reunin de Revisin del Sprint y la Retrospectiva del Sprint

2.3.4

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

15

UNIVERSIDAD NACIONAL DE TRUJILLO

2.3.5

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.

2.4. 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.

2.5. Documentos
2.5.1 Product backlog
El product backlog es un documento de alto nivel para todo el proyecto.
Contiene descripciones genricas de todos los requerimientos,
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.

15

UNIVERSIDAD NACIONAL DE TRUJILLO

2.6. Tecnicas
2.6.1 Planning poker
Planning poker es una tcnica para calcular una estimacin basada en el
consenso, en su mayora utilizada para estimar el esfuerzo o el tamao
relativo de las tareas de desarrollo de software.
El pquer de planeamiento est basado en una lista de caractersticas para
ser entregados y una baraja de cartas. La lista de caractersticas, por lo
general una lista de historias de usuario, describen un software que necesita
ser desarrollado.

3.

CARACTERSTICAS DEL 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. Durante el sprint, nadie
puede cambiar el Sprint Backlog, lo que significa que los requisitos estn
congelados durante el sprint.
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

15

UNIVERSIDAD NACIONAL DE TRUJILLO

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.

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.

4. SCRUM APLICADO AL DESARROLLO DE SOFTWARE

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 1995 lo present junto con Ken Schwaber como proceso formal,
tambin para gestin del desarrollo de software en OOPSLA 95. 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.

15

UNIVERSIDAD NACIONAL DE TRUJILLO

5. APLICACIN DE SCRUM EN UN PROYECTO

En este caso trata de una Empresa la cual necesita Robots para su rea de
manufactura y se pone en contacto con una Empresa que los fabrica.

Pasos que si sigue al Aplicar

1. El cliente le realiza el Pedido.

Queremos
un Robot

El cliente hace el pedido de acuerdo a su necesidad en este caso quiere

la construccin de un robot

2. El cliente se rene con el Product Owner (dueo de producto), el cual anota

lo que quiere el cliente

15

UNIVERSIDAD NACIONAL DE TRUJILLO

El cliente le dice al Product Owner que es lo que quiere como quiere que
funcione su robot, que caractersticas va a tener, etc.

3. El dueo del producto divide el proyecto en componentes los cuales forman

la lista de productos o pila de producto.

El Product Owner divide todo el proyecto en este caso vemos que ha divido en
robot en diferentes partes para que se pueda trabajar mejor.

4. El Scrum Master es un miembro del equipo que tiene el papel de comunicar

y gestionar las necesidades del dueo del producto.

15

UNIVERSIDAD NACIONAL DE TRUJILLO

El Product Owner le entrega al Scrum Manager la lista de materiales que

se necesitara para hacer el robot l ya se encargara de estimar el coste del
producto.

5. El equipo se rene para estimar el coste de cada elemento de la pila de

productos
Para esto utilizan Planning Poker

Scrum Manager se rene con su equipo y ve los costos de las piezas para
armar el robot para poder hacerlo mejor utilizan la tcnica Planning Poker

6. El cliente una vez aprobado el presupuesto, reordena la pila de producto para

que el equipo vaya trabajando segn la prioridad del cliente

15

UNIVERSIDAD NACIONAL DE TRUJILLO

Luego de que sacaron el presupuesto para hacer el robot el cliente lo ve

para aprobarlo y reordenar la lista segn su prioridad.

7. El Equipo comienza su trabajo desglosando el primer producto de la pila de

productos, la cual se subdivide en tareas menores para crear la pila del Sprint

Ahora el equipo de programadores comenzara a hacer una de cada tarea de la

lista, la cual lo subdividir para hacer la lista del Sprint

15

UNIVERSIDAD NACIONAL DE TRUJILLO

8. La pila del Sprint tiene como Utilidad fraccionar el trabajo de un periodo de
15 das en tareas ms pequeas, que tarden como mucho 2 das.

Ahora se divide la lista que tenemos del Sprint en partes ms pequeas de por lo menos
2 das as se puede construir la placa delantera, placa trasera, etc.

9. Estas tareas se colocan en una pila, la cual prioriza el dueo del producto,
que ha consultado el cliente antes de comenzar con el Sprint

Con las tareas ya dividida ahora el Product Owner prioriza con cual hay que avanzar
en este caso empiezan con la placa delantera, luego el pivote, lateral izquierdo, etc.

10. El equipo comienza el sprint tomando las tareas priorizadas, una vez
concluida una se toma la siguiente de la lista.

15

UNIVERSIDAD NACIONAL DE TRUJILLO

El equipo empieza con las tareas priorizadas una vez concluida empieza la
siguiente y sigue un orden en este caso hay 3 pendientes, una en desarrollo y
una que ya esta terminada.

11. Una vez finalizado el Sprint el dueo del producto le muestra al cliente el
resultado del trabajo realizado

Una vez acabado las tareas de ese Sprint se presenta al cliente en este caso
ya est hecha una parte del robot y as se repetir este proceso del Sprint
hasta acabar todo el robot.

12. El equipo de trabajo celebra su buen hacer con una reunin de retrospectiva
donde se analiza lo ocurrido durante el Sprint

15

UNIVERSIDAD NACIONAL DE TRUJILLO

Despus de haber acabado el proyecto el equipo se rene como que analiza

lo ocurrido durante el Sprint

6. CONCLUSIONES
SCRUM es quizs la metodologa gil de desarrollo ms adoptada en los ltimos
aos, es un mtodo iterativo e incremental que se caracteriza por entregar partes
ejecutables del sistema en cada iteracin, se centra en los cambios y ofrece como
ventajas una buena estimacin de costos y tiempos as como parmetros de
medicin exactos del avance de un proyecto.
SCRUM es por eso una de las principales opciones a la hora de desarrollar
proyectos por su versatilidad, facilidad de manejo y una fcil aplicacin.
7. LINKOGRAFIAS
[1]. http://es.wikipedia.org/wiki/Scrum
[2]. http://digitalcrossroads.com.mx/?p=400
[3]. http://www.proyectosagiles.org/que-es-scrum
[4]. http://www.dtic.ua.es/jdare10/presentaciones/JDARE10-07.pdf

15