Está en la página 1de 23

UNIVERSIDAD DE ORIENTE

NCLEO DE ANZOTEGUI
COORDINACIN DE POSTGRADO
MAESTRA EN INFORMTICA GERENCIAL
ASIGNATURA: GERENCIA ESTRATGICA DE PROYECTOS

METODOLOGA SCRUM

FACILITADOR:
Prof. Andrs Martnez

PARTICIPANTES:
Mara Santamara
Angel Espinoza
Abraham Morales

Barcelona, Octubre de 2015

NDICE GENERAL
0

1. Introduccin
______________________________________________________________2 1.1
Principales caractersticas
________________________________________________ 2 1.2 Principales
elementos de la metodologa____________________________________ 2 1.3
Esquema general _______________________________________________________
3
2. Herramientas y Practicas
____________________________________________________5 2.1 Product
Backlog List ___________________________________________________5 2.2
Sprints _______________________________________________________________ 5
2.3 Reunin diaria de sincronizacin del equipo (Scrum Daily
Meeting)_____________6
2.4 Demostracin de los requisitos completados (Sprint
Review)____________________7
2.5 Retrospectiva (Sprint
Retrospective)________________________________________8
3. 2.3 Burn down Chart
_______________________________________________________ 6 2.4 Sprint
Backlog_________________________________________________________ 7 2.5
Stabilization Sprints _____________________________________________________
7 2.6 Scrum of Scrums o
MetaScrum____________________________________________ 7
4. El Proceso
________________________________________________________________8 3.1
Pregame Phase ________________________________________________________
9 3.2 Development
Phase____________________________________________________10
5. Roles y
Responsabilidades__________________________________________________11
4.1 Scrum Master
_________________________________________________________11 4.2 Product
Owner ________________________________________________________11 4.3
Scrum Team__________________________________________________________11
4.4 Customer
____________________________________________________________11 4.5
Management _________________________________________________________11
6. Visin General del
Modelo_________________________________________________12
7. Conclusion__________________________________________________________17
8. Bibliografas
_____________________________________________________________13

1. INTRODUCCION
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.
Se comienza con la visin general del producto, especificando y dando
detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo
y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de
30 das).
Cada uno de estos periodos de desarrollo es una iteracin que finaliza con la
produccin de un incremento operativo del producto.
Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su
evolucin a travs de reuniones breves diarias en las que todo el equipo revisa
el trabajo realizado el da anterior y el previsto para el da siguiente.
El ciclo de vida definido por Scrum es incremental iterativo y se caracteriza por
ser muy adaptable.
1.1

Principales caractersticas
Equipos autodirigidos
Utiliza reglas para crear un entorno gil de administracin de proyectos
No prescribe prcticas especficas de ingeniera
Los requerimientos se capturan como tems de la lista Product Backlog
El producto se construye en una serie de Sprints de un mes de duracin

1.2

Principales elementos de la metodologa

Herramientas

Product Backlog
Sprint Backlog

Prcticas

Sprints
Sprint Planning Meeting
Daily Meetings
Sprint Review Meeting
Design Review Meeting
Stabilization Sprints
Meta Scrums

Roles y responsabilidades

1.3

Scrum Master Product


Owner
Scrum Team
Customer
Management

Esquema general

En el esquema anterior se muestra en forma esquemtica el proceso de


desarrollo de Scrum.
El trabajo a ser realizado en un proyecto Scrum es listado en el Product
Backlog, que es una lista de todos los cambios requeridos sobre un producto.
Los proyectos se realizan durante una serie de iteraciones de un mes de
duracin llamadas Sprints. Al comienzo de cada Sprint tiene lugar una Sprint
Planning Meeting durante la cual el Product Owner prioriza el Product Backlog y
el Scrum Team selecciona las tareas que sern completadas durante el Sprint
que va a comenzar. Esas tareas son removidas del Product Backlog para ser
llevadas al Sprint Backlog.
Durante el Sprint el equipo se mantiene en contacto a travs de las Daily
Meetings. Y al final del Sprint debe mostrar la funcionalidad completa en la
Sprint Review Meeting.
Cmo funciona la Metodologia Scrum?
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos
(iteraciones de un mes natural y hasta de dos semanas, si as se necesita).
Cada iteracin tiene que proporcionar un resultado completo, un
incremento de producto final que sea susceptible de ser entregado con el
mnimo esfuerzo al cliente cuando lo solicite.
El proceso parte de la lista de objetivos/requisitos priorizada del producto,
que acta como plan del proyecto. En esta lista el cliente prioriza los objetivos
balanceando el valor que le aportan respecto a su coste y quedan repartidos en
iteraciones y entregas. De manera regular el cliente puede maximizar la
utilidad de lo que se desarrolla y el retorno de inversin mediante la
replanificacin de objetivos que realiza al inicio de cada iteracin.
Planificacin de la iteracin
El primer da de la iteracin se realiza la reunin de planificacin de la
iteracin. Tiene dos partes:
1. Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la
lista de requisitos priorizada del producto o proyecto. El equipo pregunta al
cliente las dudas que surgen y selecciona los requisitos ms prioritarios que se
compromete a completar en la iteracin, de manera que puedan ser
entregados si el cliente lo solicita.

2. Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de


tareas de la iteracin necesarias para desarrollar los requisitos a que se ha
comprometido. La estimacin de esfuerzo se hace de manera conjunta y los
miembros del equipo se autoasignan las tareas.
Ejecucin de la iteracin
Cada da el equipo realiza una reunin de sincronizacin (15 minutos mximo).
Cada miembro del equipo inspecciona el trabajo que el resto est realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteracin,
obstculos que pueden impedir este objetivo) para poder hacer las
adaptaciones necesarias que permitan cumplir con el compromiso adquirido.
En la reunin cada miembro del equipo responde a tres preguntas:
Qu he hecho desde la ltima reunin de sincronizacin?
Qu voy a hacer a partir de este momento?
Qu impedimentos tengo o voy a tener?
Durante la iteracin el Facilitador se encarga de que el equipo pueda cumplir
con su compromiso y de que no se merme su productividad.
Elimina los obstculos que el equipo no puede resolver por s mismo.
Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.
Inspeccin y adaptacin
El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin.
Tiene dos partes:
1. Demostracin (4 horas mximo). El equipo presenta al cliente los requisitos
completados en la iteracin, en forma de incremento de producto preparado
para ser entregado con el mnimo esfuerzo. En funcin de los resultados
mostrados y de los cambios que haya habido en el contexto del proyecto, el
cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la
primera iteracin, replanificando el proyecto.
2. Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera
de trabajar y cules son los problemas que podran impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El
Facilitador se encargar de ir eliminando los obstculos identificados.

2. HERRAMIENTAS Y PRACTICAS
Scrum no requiere ni provee prcticas de Ingeniera. En lugar de eso, especifica
prcticas y herramientas de gerencia que se aplican en sus distintas fases para
evitar el caos originado por la complejidad e imposibilidad de realizar
predicciones.
2.1

Product Backlog List

Es una lista priorizada que define el trabajo que se va a realizar en el proyecto.


Cuando un proyecto comienza es muy difcil tener claro todos los
requerimientos sobre el producto. Sin embargo, suelen surgir los ms
importantes que casi siempre son ms que suficientes para un Sprint.
La Product Backlog List puede crecer y modificarse a medida que se obtiene
ms conocimiento acerca del producto y del cliente. Con la restriccin de que
solo puede cambiarse entre Sprints. El objetivo es asegurar que el producto
definido al terminar la lista es el ms correcto, til y competitivo posible y para
esto la lista debe acompaar los cambios en el entorno y el producto.
Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere
realizar cualquier modificacin sobre la lista por ejemplo: agregar o
incrementar la prioridad de sus elementos tiene que convencer al Product
Owner.
6

2.2

Sprints

Un Sprint es el procedimiento de adaptacin de las cambiantes variables del


entorno (requerimientos, tiempo, recursos, conocimiento, tecnologa). Son
ciclos iterativos en los cuales se desarrolla o mejora una funcionalidad para
producir nuevos incrementos. Durante un Sprint el producto es diseado,
codificado y probado. Y su arquitectura y diseo evolucionan durante el
desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea
fcil de recordar y est siempre presente en el equipo. Es posible definir una
serie de restricciones que el equipo deba aplicar durante un Sprint.
Un Sprint tiene una duracin planificada de entre una semana y un mes. No es
posible introducir cambios durante el Sprint, por lo tanto para planificar su
duracin hay que pensar en cuanto tiempo puedo comprometerme a mantener
los cambios fuera del Sprint. Dependiendo del tamao del sistema, la
construccin de un release puede llevar entre 3 y 8 Sprints. Por otra parte
podran formarse equipos para desarrollar en forma paralela distintos grupos
de funcionalidad.
Las actividades que se desarrollan durante del Sprint son: Sprint Planning
Meeting, Sprint Backlog, Daily Scrum Meetings y Sprint Review Meeting. En la
siguiente grfica se pueden ver las prcticas involucradas en un Sprint.

2.3 Reunin diaria de sincronizacin del equipo (Scrum Daily Meeting)


El objetivo de esta reunin es facilitar la transferencia de informacin y
la colaboracin entre los miembros del equipo para aumentar su productividad,
al poner de manifiesto puntos en que se pueden ayudar unos a otros.
Cada miembro del equipo inspecciona el trabajo que el resto est
realizando (dependencias entre tareas, progreso hacia el objetivo de la
iteracin, obstculos que pueden impedir este objetivo) para al finalizar la
reunin poder hacer las adaptaciones necesarias que permitan cumplir con el
compromiso conjunto que el equipo adquiri para la iteracin (en la reunin de
planificacin de la iteracin).
Cada miembro del equipo debe responder las siguientes preguntas en un
timebox de cmo mximo 15 minutos:
Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo
lo que tena planeado? Cul fue el problema?
Qu voy a hacer a partir de este momento?
Qu impedimentos tengo o voy a tener para cumplir mis compromisos en
esta iteracin y en el proyecto?
Como apoyo a la reunin, el equipo cuenta con la lista de tareas de la
iteracin, donde se actualiza el estado y el esfuerzo pendiente para cada tarea,
as como con el grfico de horas pendientes en la iteracin.
Beneficios
Aumentar la productividad en el proyecto y potencia el compromiso de
equipo, dado que cada miembro pone de manifiesto delante del resto:
Las tareas que pueden afectar a otros miembros del equipo, por que
impactan en su trabajo o por que hay dependencias (especialmente si
existe un retraso).
Los impedimentos con que se encuentra. El resto de miembros del
equipo pueden ofrecer ayuda a otros en la realizacin de tareas o para
resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum
Master) se encargar de solucionar los impedimentos que el equipo no
puede solucionar por s solo o que le quitan tiempo para cumplir con su
compromiso fundamental de desarrollo de requisitos.
Las tareas no planeadas que est realizando que el equipo no conoce y
puede que no estn alineadas con el compromiso del equipo, aunque l
crea que lo que est haciendo es lo mejor que se puede hacer.
Cules son sus necesidades. Cada miembro entiende las necesidades de
los otros miembros del equipo respecto a su trabajo, de manera que
8

pueden colaborar y adaptar sus trabajos para que den el mximo valor y
no realizar tareas que no proporcionan ningn beneficio al resto del
equipo.
Cul es su ritmo de trabajo. Se hace visible si de manera continua un
miembro del equipo est realizando tareas por debajo del rendimiento
esperado. Se evita que una persona seale con el dedo a otra, dado que
la reunin de sincronizacin pone a todos los miembros del equipo en la
misma situacin de tener que explicar en qu tareas estn trabajando.
Cules son los criterios que est utilizando para realizar sus tareas, de
manera que estn alineados con los objetivos comunes del equipo.
Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver
cmo trabajan los otros segn sus especialidades y experiencias.
Conocer el estado de la iteracin, ver si es posible completar los requisitos a
que se comprometi el equipo, en vista de las desviaciones y de las tareas
pendientes.
Restricciones
La reunin diaria de estado y sincronizacin del equipo no es para resolver
problemas, los problemas se resuelven despus de la reunin.
No a todos los miembros del equipo les interesan todos los detalles de
cada tema.
En la reunin los miembros del equipo programan reuniones entre ellos
donde colaborar sincronizando tareas, ayudando a resolver problemas,
etc.
No puede haber una persona explicando su estado mientras otras "se
han apartado" de la reunin para comentar un tema particular. Si
apareciese alguna conversacin de inters comn (que debe ser rpida),
debe poder ser escuchada por todo el equipo sin distraer el principal
objetivo de que todos conozcan en qu estn trabajando los dems. Si
la mini conversacin no es del inters de todos, debe hacerse despus
de la reunin.
El equipo debe contar con unos criterios consensuados sobre el proceso de
ejecucin de las de tareas
El proceso de ejecucin de las tareas debe estar consensuado para
evitar que cada reunin sea una exposicin de discrepancias entre los
miembros del equipo.
Recomendaciones
Realizar la reunin diaria de sincronizacin de pie, para que los miembros del
equipo no se relajen ni se extiendan en ms detalles de los necesarios.
9

Realizar las reuniones de colaboracin entre miembros del equipo justo


despus de la de sincronizacin.
2.4 Demostracin de los requisitos completados (Sprint Review)
Reunin informal donde el equipo presenta al cliente los requisitos
completados en la iteracin, en forma de incremento de producto preparado
para ser entregado con el mnimo esfuerzo, haciendo un recorrido por ellos lo
ms real y cercano posible al objetivo que se pretende cubrir.
En funcin de los resultados mostrados y de los cambios que haya habido en el
contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera
objetiva, ya desde la primera iteracin, replanificando el proyecto. Se realiza en
un timebox de cmo mximo 4 horas.
Beneficios

El cliente puede ver de manera objetiva cmo han sido desarrollados los
requisitos que proporcion, ver si se cumplen sus expectativas, entender
ms qu es lo que necesita y tomar mejores decisiones respecto al proyecto.
El equipo puede ver si realmente entendi cules eran los requisitos que
solicit el cliente y ver en qu puntos hay que mejorar la comunicacin entre
ambos.
El equipo se siente ms satisfecho cuando puede ir mostrando los resultados
que va obteniendo. No est meses trabajando sin poder exhibir su obra.

Restricciones

Slo se pueden mostrar los requisitos completados, para que el cliente no se


haga falsas expectativas y pueda tomar decisiones correctas y objetivas en
funcin de la velocidad de desarrollo y el resultado realmente completado.
Un requisito no completado quedar como un requisito ms a replanificar.

2.5 Retrospectiva (Sprint Retrospective)


Con el objetivo de mejorar de manera continua su productividad y la
calidad del producto que est desarrollando, el equipo analiza cmo ha sido su
manera de trabajar durante la iteracin, por qu est consiguiendo o no los
objetivos a que se comprometi al inicio de la iteracin y por qu el incremento
de producto que acaba de demostrar al cliente era lo que l esperaba o no:

Qu cosas han funcionado bien.


Cuales hay que mejorar.
Qu cosas quiere probar hacer en la siguiente iteracin.
Qu ha aprendido.
10

Cules son los problemas que podran impedirle progresar


adecuadamente. El Facilitador se encargar de ir eliminando los
obstculos identificados que el propio equipo no pueda resolver por s
mismo.

Notar que esta reunin se realiza despus de la reunin de demostracin


al cliente de los objetivos conseguidos en la iteracin, para poder incorporar su
feedback y cumplimiento de expectativas como parte de los temas a tratar en
la reunin de retrospectiva
Se realiza en un timebox de cmo mximo 3 horas (si la iteracin es mensual).
Beneficios

Incrementa la productividad en el proyecto, la calidad del producto (cosa


que permite hacerlo crecer de manera sostenida) y potencia el aprendizaje
del equipo de manera sistemtica, iteracin a iteracin, con resultados a
corto plazo.
Aumenta la motivacin del equipo dado que participa en la mejora de
proceso, se siente escuchado, toma decisiones consensuadas (y ms
sostenibles) para ir eliminando lo que molesta e impide que sea ms
productivo.

Restricciones

En necesario que el Equipo y el Facilitador dispongan de autoridad,


mecanismos y recursos para ir mejorando su forma de trabajar y el contexto
del proyecto. Es frustrante encontrar sistemticamente los mismos
obstculos y no poder solucionarlos

2.6

Burn down Chart

En Scrum se planifica y mide el esfuerzo restante necesario para desarrollar el


producto. Esta grfica suele utilizarse en lugar de un diagrama de PERT debido
a que el camino crtico en un desarrollo gil cambia diariamente. Esto hara
obsoleto el diagrama de PERT cada da. Es por esto que no es til una
herramienta que modele el camino crtico a partir de actividades. La solucin
es utilizar una tcnica que permita medir la velocidad de desarrollo. Para esto
se utiliza el criterio del equipo a partir del cual se calcula diariamente el
camino crtico. Esto permite recalcular el plan y la velocidad en que se realiza
el trabajo. En funcin de esto el equipo puede trabajar para acelerar o
desacelerar el trabajo para cumplir con la fecha de entrega.

11

2.7

Sprint Backlog

Es el punto de entrada de cada Sprint. Es una lista que tiene los tems de la
Product Backlog List que van a ser implementados en el siguiente Sprint.
Los tems son seleccionados por el Scrum Team, el Scrum Master y el Product
Owner en la Sprint Planning Meeting a partir de la priorizacin de los tems y
los objetivos que se marcaron para ese Sprint. A partir de los objetivos a
cumplir durante el Sprint el Scrum Team determina que tareas debe
desempear para cumplir el objetivo. De esto surge el Sprint Backlog. Es
importante destacar que es el equipo quien se organiza para alcanzar el
objetivo. El Manager no asigna tareas a los individuos y tampoco toma
decisiones por el equipo. El equipo puede agregar nuevas tareas o remover
tareas innecesarias en cualquier momento si lo considera necesario para
cumplir el objetivo. Pero el Sprint Backlog solo puede ser modificado por el
equipo. Las estimaciones se actualizan cada vez que aparece nueva
informacin.
2.8

Stabilization Sprints

En estos Sprints el equipo se concentra en encontrar defectos, no en agregar


funcionalidad. Suelen aplicarse cuando se prepara un producto para el release.
Son tiles cuando se estn realizando pruebas beta, se est introduciendo a un
equipo en la metodologa de Scrum o cuando la calidad de un producto no
alcanza los lmites esperados.
No fueron definidos por Scrum pero han sido recomendados por su utilidad al
aplicar esta metodologa.
2.9

Scrum of Scrums o MetaScrum

12

Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo est
metodologa ha sido aplicada en proyectos que involucran ms de 600
personas. Esto ha sido llevado a cabo dividiendo a los accionistas en equipos
de pequeos de hasta 10 personas aproximadamente. Y definiendo
jerrquicamente personas que pertenecen a dos equipos, es decir, adems de
su rol especfico dentro de un equipo tienen el rol de enlace en un equipo
superior.

3 EL PROCESO
Scrum consta de tres fases: Pregame, Development y Postgame.

La fase de Pregame incluye dos subfases: Planning y Architecture

Planning

Consiste en la definicin del sistema que ser construido. Para esto se crea la
lista Product Backlog a partir del conocimiento que actualmente se tiene del
sistema. En ella se expresan los requerimientos priorizados y a partir de ella se
estima el esfuerzo requerido. La Product Backlog List es actualizada
constantemente con tems nuevos y ms detallados, con estimaciones ms
precisas y cambios en la prioridad de los tems.

Architecture / High level Design


13

El diseo de alto nivel del sistema se planifica a partir de los elementos


existentes en la Product Backlog List. En caso de que el producto a construir
sea una mejora a un sistema ya existente, se identifican los cambios
necesarios para implementar los elementos que aparecen en la lista Product
Backlog y el impacto que pueden tener estos cambios. Se sostiene una Design
Review Meeting para examinar los objetivos de la implementacin y tomar
decisiones a partir de la revisin. Se preparan planes preliminares sobre el
contenido de cada release.

La fase de Development tambin llamada Game Phase es la parte gil de


Scrum:
En esta fase se espera que ocurran cosas impredecibles. Para evitar el caos
Scrum define prcticas para observar y controlar las variables tcnicas y del
entorno, as tambin como la metodologa de desarrollo que hayan sido
identificadas y puedan cambiar. Este control se realiza durante los Sprints.
Dentro de variables de entorno encontramos: tiempo, calidad, requerimientos,
recursos, tecnologas y herramientas de implementacin. En lugar de tenerlas
en consideracin al comienzo del desarrollo, Scrum propone controlarlas
constantemente para poder adaptarse a los cambios en forma flexible.
La fase de PostGame:
Contiene el cierre del release. Para ingresar a esta fase se debe llegar a un
acuerdo respecto a las variables del entorno por ejemplo que los
requerimientos fueron completados. El sistema est listo para ser liberado y es
en esta etapa en la que se realiza integracin, pruebas del sistema y
documentacin.
3.6

Pregame Phase

Entrada: La concepcin inicial del producto que tienen los accionistas o


interesados.
Tareas
Nombre de la
tarea

Crear la Product Backlog


List y controlar su
consistencia

Descripcin

Posibles elementos de esta lista son


requerimientos tcnicos y del negocio,
funciones, errores a reparar, defectos,
mejoras y actualizaciones tecnolgicas
requeridas.
Es importante controlar la consistencia de la
lista. Para esto se agregan, modifican,
eliminan, especifican y priorizan sus

14

Responsabl
es

Requerid
a/
Opcional

Product Owner

Requerida

Priorizar la Product
Backlog List

Effort Estimation

Design Review Meeting

elementos
Esta actividad se basa en considerar que
elementos tienen ms o menos influencia en
el xito del proyecto en un momento dado;
considerando que los elementos con mayor
prioridad se realizan primero.
Es un proceso iterativo que rene toda la
informacin que haya acerca un elemento
para tener un mayor nivel de precisin en la
estimacin.
Siempre se mide el esfuerzo que falta para
cumplir con el / los objetivos tanto a nivel de
la lista Product Backlog como para el Sprint
Backlog (lo que resta).
En esta instancia se comunica el diseo a los
interesados para revisar el cumplimiento de
los tems especificados en el Product Backlog

Product Owner

Requerida

Product Owner
Requerida
Scrum Team

Requerida

Verificacin: Deben estar realizadas todas las tareas requeridas


Salida: Product Backlog List, Arquitectura

3.7

Development Phase

Entrada: Product Backlog List


Tareas

Nombre de la tarea

Sprint Planning Meetin

Daily Scrum Meeting

Descripcin

Responsables

Es una reunin organizada por el Scrum


Master, que se realiza en dos fases.
La primera fase tiene como objetivo
establecer que tems de la Product Backlog
List van a ser realizados durante el Sprint.
Esto se realiza a partir de lo que el Scrum
Team considera que puede construir durante
el Sprint.
En la segunda fase se decide como se van a
alcanzar los objetivos del Sprint. En esta fase
se crea la Sprint Backlog, indicando qu
tareas debe desempear el equipo para
cumplir con dichos objetivos.
Las reuniones se realizan en el mismo lugar y
a la misma hora cada da. Idealmente en la
maana para definir el trabajo para el da.
Tienen una duracin de 15 minutos y los
participantes se quedan parados. Estas
reuniones no se utilizan para resolver
problemas. En ellas se realizan tres
preguntas:

Qu hiciste ayer?

Qu hars hoy?

15

Requerida/
Opcional

Scrum Master
Customer, User
Management
Product Owner
Scrum Team
Requerida
Scrum Team
Scrum Master
Product Owner

Sprint Review Meeting

Qu obstculos ves en tu camino?


Los participantes son clasificados segn el
compromiso que tengan con las actividades
del proyecto en dos categoras: gallinas y
chanchos1 . Los chanchos son los que estn
ms comprometidos y por lo tanto son los que
pueden hablar y brindar opiniones. Esto
ayuda a evitar reuniones innecesarias.
Estas reuniones no pueden ser sustituidas por
reportes va mail por dos motivos:

El equipo entero ve todo el paisaje


cada da

Es un elemento de presin para que


el individuo haga lo que dijo que va a
hacer
Es una reunin informal que tiene como regla
que su preparacin no puede tomar ms de 2
horas. En ella el equipo presenta lo que ha
logrado durante el Sprint. Generalmente toma
la forma de una demo de las nuevas
caractersticas o la arquitectura

Scrum Team

Requerida

Customers
Management
Product Owner
otros
interesados

Requerida

Verificacin: Durante un sprint se puede acortar funcionalidad pero la fecha


de entrega debe ser respetada.
Salida: Incremento del producto

4 ROLES Y RESPONSABILIDADES
4.6

Scrum Master

Es un rol de administracin que debe asegurar que el proyecto se est llevando


a cabo de acuerdo con las prcticas, valores y reglas de Scrum y que todo
funciona segn lo planeado. Su principal trabajo es remover impedimentos y
reducir riesgos del producto. Este rol suele ser desempeado por un Gerente
de Proyecto o Lder de equipo.
4.7

Product Owner

Es el responsable del proyecto, administra, controla y comunica la Backlog List.


Es el responsable de encontrar la visin del producto y reflejarla en la Backlog
List. Generalmente esta persona puede ser el Product Manager, Marketing,
Internal Customer, etc.
4.8

Scrum Team

1 Esto proviene del siguiente cuento: En una tortila de jamn y huevo, la


gallina participa pero el chancho est comprometido, porque l deja la vida,
mientras que la gallina solo pone los huevos.
16

Es el equipo del proyecto que tiene la autoridad para decidir como organizarse
para cumplir con los objetivos de un Sprint. Sus tareas son: Effort Estimation
(Estimar Esfuerzo), crear el Sprint Backlog, revisar la Product Backlog List y
sugerir obstculos que deban ser removidos para cumplir con los items que
aparecen.
Tpicamente es un equipo de entre 5 y 10 personas cada una especializada en
algn elemento que conforma los objetivos a cumplir, por ejemplo:
Programadores, Diseadores de Interfaz de usuario, etc. La dedicacin de los
miembros del equipo debera ser full-time con algunas excepciones. La
membresa solo puede cambiar entre sprints (no durante).
4.9

Customer

El cliente participa en las tareas que involucran la lista Product Backlog.


4.10 Management
Es el responsable de tomar las decisiones finales, acerca de estndares y
convenciones a seguir durante el proyecto. Participa en la seleccin de
objetivos y requerimientos y en la seleccin del Scrum Owner. Tiene la
responsabilidad de controlar el progreso y trabaja junto con el Scrum Master en
la reduccin de la Product Backlog List

17

18

5 VISIN GENERAL

19

Conclusin
Scrum se basa en el desarrollo incremental de los requisitos del proyecto
en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta
de dos semanas, si as se necesita). La priorizacin de los requisitos por
20

valor para el cliente y coste de desarrollo en cada iteracin. El control


emprico del proyecto. Por un lado, al final de cada iteracin se demuestra
al cliente el resultado real obtenido, de manera que pueda tomar las
decisiones necesarias en funcin de lo que observa y del contexto del
proyecto en ese momento. Por otro lado, el equipo se sincroniza
diariamente y realiza las adaptaciones necesarias.
La potenciacin del equipo, que se compromete a entregar unos
requisitos y para ello se le otorga la autoridad necesaria para organizar su
trabajo. La sistematizacin de la colaboracin y la comunicacin tanto entre
el equipo y como con el cliente. El timeboxing de las actividades del
proyecto, para ayudar a la toma de decisiones y conseguir resultados.
Estas prcticas se apoyan unas a otras y su seleccin tiene origen en
un estudio de la manera de trabajar de equipos altamente productivos.

7 BIBLIOGRAFIA

Schwaber, K. (1995). SCRUM Development Process. Burlington: OOPSLA 95.


21

[AgileJournal] Revista electrnica sobre metodologas de desarrollo de software.


Agile Journal, n1, Marzo-2006. Http:// www.agilejournal.com. Accedido
05/12/2011.

Abrahamsson, Salo, Ronkainen & Warsta (2002) Agile software development


methods. Review and analysis. www.info.vtt.fi/pdf/ Sutherland, Jeff (2001)
Inventing and Reinventing SCRUM in Five Companies

MountainGoatSoftware
http://www.mountaingoatsoftware.com/scrum/index.php

22

También podría gustarte