Scrum

Historia
Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka
Takeuchi a principios de los 80, al analizar cmo desarrollaban los
nuevos productos las principales empresas de manufactura tecnolgica:
Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard
(Nonaka & Takeuchi, The New New Product Development Game, 1986).
En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo
en equipo, con el avance en formacin de scrum de los jugadores de
Rugby, a raz de lo cual qued acuado el trmino scrum para referirse
a ella.
Aunque esta forma de trabajo surgi en empresas de productos
tecnolgicos, es apropiada para proyectos con requisitos inestables y
para los que requieren rapidez y flexibilidad, situaciones frecuentes en el
desarrollo de determinados sistemas de software.
En 1995 Ken Schwaber present Scrum Development Process en
OOPSLA 95 (Object-Oriented Programming Systems & Applications
conference)(SCRUM Development Process), un marco de reglas para
desarrollo de software, basado en los principios de scrum, y que l haba
empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa
Easel Corporation (compaa que en los macrojuegos de compras y
fusiones, se integrara en VMARK, y luego en Informix y finalmente en
Ascential Software Corporation)

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 autoorganizados 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
Roles Principales
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. El ScrumMaster 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:2

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

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?

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 llevarn a cabo: 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.
Beneficios 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 diseada 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.3

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 el sprint backlog nunca son
asignadas, son tomadas por los miembros del equipo del modo que les
parezca oportuno.
Burn down chart
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.

Explicando Scrum a mi abuela

Introduccin
El otro da me encontraba hablando con un compaero de trabajo a
travs del telfono mvil, cuando mi abuela me escuch nombrar
palabras
raras
en
la
conversacin.
Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo
que ms atencin la llam, as que cuando colgu, lo primero que me
pregunt fue con quin hablaba, de qu hablaba, y que era eso de
Scrum.
Imaginaros la cara que se me qued, porque... cmo explicar Scrum a
mi
abuela?.
Aunque mi abuela es muy avanzada para la mayora de la gente de su
edad, la verdad es que no es fcil explicarla muchos de los aspectos
tecnolgicos emergentes, pero bueno, es mi abuela y tena que intentar
explicrselo
de
forma
convincente.
Aqu, os transcribo aquella inverosmil conversacin.
La conversacin y sus explicaciones
De que hablabas?, pareca interesante eso que decas de Scrum. Qu
es
exactamente?
Ah s! Scrum es una metodologa.
Y para que se utiliza?
Se utiliza en mi profesin, en el desarrollo del Software concretamente,
aunque hay gente por ah que la usa o la quiere usar en otras
profesiones y reas.
Y para eso del desarrollo del Software tenis que usar ese tal Scrum?
En realidad no. No es estrictamente necesario.
Scrum por sus caractersticas no es vlido para cualquier proyecto ni
para cualquier persona o equipo de personas. Es ms, Scrum segn
muchos especialistas de esta metodologa, es ptima para equipos de

trabajo de hasta 8 personas, aunque hay empresas que han utilizado

Scrum con xito con equipos ms grandes.
Yo dira que para el 90% de los proyectos y empresas, es una
metodologa vlida, pero no es una metodologa vlida al 100%. Es ms,
no hay metodologa mejor que otra ni vlida al 100% para todas las
personas y empresas.
Scrum es por lo tanto, una metodologa ms de las muchas que hay, y
sta en concreto, se basa en la filosofa del desarrollo gil que fue
expuesto por dos japoneses alrededor del ao 1986.
Siempre estos japoneses... has dicho desarrollo gil varias veces... que
es eso exactamente?, a m eso s que me suena a japons o a chino
El desarrollo gil pone de manifiesto bsicamente lo siguiente:

El mercado actual es altamente competitivo y la tecnologa es muy

cambiante. En el desarrollo del Software se pide bsicamente
rapidez, calidad y reduccin de costes, pero para asumir estos
retos, es necesario tener agilidad y flexibilidad.

Los ciclos de desarrollo por otro lado, acostumbran a ser largos, y

lo que se exige por otra parte, es que esos ciclos sean lo ms
cortos posibles.

El desarrollo gil aboga por estas premisas principalmente.

Hay ms detalles, pero no los voy a abordar ahora para no marearte con
informacin que nos desve la atencin de la propia explicacin
de Scrum.
Informacin adicional
Empiezo a entender algo ms esto...pero...
exactamente
eso
de
Scrum es como deca antes, una metodologa gil.

en

qu

consiste
Scrum?

Obedece a las necesidades anteriormente citadas, y no responde a

ninguna moda, sino a una necesidad realmente demandada en el
desarrollo
del
Software.
Scrum no es ni la mejor metodologa ni la nica, antes te deca que hay
muchas, pero s, es una metodologa que est empujando muy fuerte
por la facilidad de implantacin y por su agilidad en cuanto a cambios y
lo que propiamente aporta en comparacin con otras metodologas.
Por un lado, Scrum evita la burocracia y la generacin documental. No
es que con Scrum no se deba o no se pueda documentar, si no que con

Scrum no se exige documentar nada para iniciar un proyecto, algo que

en
otras
metodologas
es
impensable.
Con Scrum por otro lado, la idea principal es la de ponerse a trabajar
prcticamente desde el primer momento y empezar a sacar frutos de
ese trabajo para que el cliente vaya viendo los avances y se quede
satisfecho con lo que se est haciendo y cmo se est haciendo.
S s, vale... pero cmo muestras al cliente esos progresos en el
trabajo?.
Bien bien, no te he contado an mucho sobre Scrum, slo el cascarn
que lo envuelve, pero ya que preguntas y te veo realmente interesada,
te
voy
a
contar
todo
lo
que
hay
con
ms
detalle.
De forma resumida y global, en Scrum vamos a diferenciar dos aspectos
importantes, los actores y las acciones.
Vaya, esto se pone interesante, sigue sigue que me est empezando a
gustar
esto
del
Scrum.
Ja!, pues espera a que te cuente, que esto no ha hecho nada ms que
comenzar.
Te deca que hay dos aspectos fundamentales a diferenciar, los actores y
las
acciones.
Los actores son los que ejecutarn obviamente las acciones.
Estos de forma general, sern:

Product Owner

Scrum Master

Scrum Team

Usuarios o Clientes

Algo que no te he dicho an, es que para que un proyecto Software

tenga xito, el Usuario o Cliente, debe involucrarse s o S.
Esto vale para todos TODOS los proyectos, aunque no todos los
Usuarios y Clientes lo entienden as, pero nuestra misin es tambin
hacrselo
ver.
Prosigo.
El Product Owner conoce y marca las prioridades del proyecto o
producto.
El Scrum Master es la persona que asegura el seguimiento de la
metodologa guiando las reuniones y ayudando al equipo ante cualquier

problema que pueda aparecer. Su responsabilidad es entre otras, la de

hacer
de
paraguas
ante
las
presiones
externas.
El Scrum Team son las personas responsables de implementar la
funcionalidad o funcionalidades elegidas por el Product Owner.
Los Usuarios o Cliente, son los beneficiarios finales del producto, y son
quienes viendo los progresos, pueden aportar ideas, sugerencias o
necesidades.
Y lo de las acciones?
Te veo con hambre de conocimiento, eso est bien.
Las acciones tienen relacin directa con los actores. Sin ellas, todo sera
un
caos.
En Scrum se indican claramente las acciones a acometer y como
acometerlas. Nuestra responsabilidad es hacerlo siempre de una forma
adecuada y algo rgida para impedir que se aplique errneamente esta
metodologa.
Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por
lo que el mecanismo y forma de trabajar que a continuacin se indica,
tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en
el desarrollo.
Las acciones fundamentales de Scrum son:

Product Backlog

Sprint Backlog

Daily Scrum Meeting

El Product Backlog corresponde con todas las tareas, funcionalidades o

requerimientos a realizar. Antes deca que el Product Owner es la
persona que se encarga de marcar las prioridades, y es al fin y al cabo,
la persona que mantiene y actualiza dado el caso, la lista de tareas.
El Sprint Backlog corresponde con una o ms tareas que provienen del
Product Backlog. Es decir, del Product Backlog se saca una o ms tareas
que van a formar parte del Sprint Backlog. Las tareas del Sprint Backlog
se deben acometer (recomendado) en unas 2 semanas 4 semanas.
Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas.
Eso debe de ser marcado antes de iniciar el Sprint Backlog, de hecho,
del Product Backlog se sacar la tarea o tareas realistas para acometer
el Sprint Backlog. Una norma fundamental es que mientras un Sprint

Backlog se inicia, ste NO puede ser alterado o modificado. Hay que

esperar a que concluya el Sprint Backlog para realizar la correspondiente
modificacin o alteracin cuya tarea, formara parte de otro Sprint
Backlog.
El Daily Scrum Meeting es una tarea iterativa que se realiza todos los
das que dure el Sprint Backlog con el equipo de desarrollo o de trabajo.
Se trata de una reunin operativa, informal y gil, de un mximo de 30
minutos, en la que se le hace 3 preguntas a cada integrante del equipo.

Qu tareas ha realizado desde la ltima reunin (que he hecho).

Sobre qu va a trabajar en el da actual (que voy a hacer hoy).

Identificacin de obstculos o riesgos que impiden o pueden

impedir el normal avance (que ayuda necesito). El Scrum
Master, debe eliminar aqu cualquier obstculo que encuentre.

Una pregunta ms... has dicho que del Product Backlog se sacan tareas
que van al Sprint Backlog, pero entiendo que no todas las tareas del
Product Backlog van a la vez al Sprint Backlog, as que... que se hace
cuando
una
tarea
del
Sprint
Backlog
se
finaliza?
Bien, esta es una pregunta tpica.
Quizs no me he explicado bien, pero el Sprint Backlog, una vez que se
inicia,
ni
se
toca.
Es decir, que una tarea se acaba, y punto.
Se contina con otra tarea del Sprint Backlog y as hasta que se acaben.
Lo que debemos tener claro, es que al finalizar un Sprint Backlog (ya sea
de 2 semanas de 4 semanas), debemos haber acabado las tareas del
Sprint
Backlog.
Reitero que las tareas del Sprint Backlog deben de ser realistas.
As que cuando se ha finalizado un Sprint Backlog, deberamos tener
algo, un entregable o algo que se pueda mostrar y que ensee los
avances
acometidos
en
el
Sprint.
En el Product Backlog tendremos ms tareas, y es posible incluso que
hayan salido nuevas tareas o que otras hayan desaparecido, por lo que
es cuando se acaba el Sprint Backlog, cuando debemos hacer varias
cosas importantes y que te indico a continuacin.
Esto me est gustando muchsimo...
Me alegro, a m me parece interesantsimo, y es ms, Scrum es de
sentido comn, tanto, que yo sin saberlo ya lo utilizaba hace algunos
aos
sin
saber
que
era
realmente
Scrum.
Bueno, prosigo con esta explicacin.

Como te deca, adicionalmente a las acciones

comentadas encontramos otras acciones ms.

anteriormente

Antes para no saturarte, no te dije que entre el Product Backlog y el

Sprint Backlog, hay algo, una reunin concretamente, que se denomina
Sprint Planning Meeting.

El Sprint Planning Meeting es una reunin que tiene por

objetivo, planificar el Sprint a partir del Product Backlog. El
objetivo de esta reunin es la de mover las tareas del Product
Backlog al Sprint Backlog. En esta reunin, suelen participar el
Product Owner que es como te dije antes quien prioriza las tareas,
el Scrum Master y el Scrum Team.

Del Sprint Planning Meeting, sale tambin el Sprint Goal, que

es un pequeo documento o una breve descripcin que indica lo
que el Sprint intetar alcanzar.

En el Sprint Review se revisa en unas 2 horas como mximo el

Sprint finalizado. Al llegar a este punto, debemos tener "algo" que
el Cliente o el Usuario pueda ver y tocar. En esta reunin, suelen
asistir el Product Owner, el Scrum Master, el Scrum Team y
personas que podran estar involucradas en el proyecto. El Scrum
Team es quin muestra los avances realizados en el Sprint.

Al finalizar un Sprint Backlog y el Sprint Review, se inicia el Sprint

Retrospective. El Product Owner revisar con el equipo los
objetivos marcados inicialmente en el Sprint Backlog concluido, se
aplicarn los cambios y ajustes si son necesarios, y se marcarn
los aspectos positivos (para repetirlos) y los aspectos negativos
(para evitar que se repitan) del Sprint.

Mira, te pintar un diagrama que espero te ayude a entender todas las

acciones de Scrum.

Y porque es eso de las 2 4 semanas?. No sera ms fcil que cada

equipo pusiera su franja de tiempo?
S claro, cada equipo, cada empresa, cada proyecto, puede poner la
franja horaria y frecuencia temporal que considere oportuno as como
cambiar aspectos de Scrum, pero te voy a poner un sencillo ejemplo con
el cul entenders que es mejor hacer esto as que de otra forma.
Supongamos el caso de la construccin de un rascacielos o de un
edificio.
Si con el fin de controlar el proyecto y que no se te escape nada ni
metamos la pata en algo, me preguntas cada da en varias ocasiones
como estoy haciendo las cosas, como lo llevo y cuales son mis avances,
te aseguro que no terminaremos la construccin del edificio en el tiempo
planificado ni de broma. Adems, seguro que querrs cambiar o
modificar algo cada da o incluso varias veces en el mismo da.
Si me preguntas cada 6 meses por ejemplo, avanzar mucho sin
interrupciones, pero a buen seguro que el riesgo de desviaciones es
mucho mayor y seguramente si ocurren, reajustar esas desviaciones al
proyecto tendr costes elevados asociados.

Un trmino medio es el ajuste temporal de 2 4 semanas que est

basado en la experiencia de muchas personas en muchos proyectos. No
es lo mismo reconducir el proyecto perdiendo 2 4 semanas, que
reconducirlo
perdiendo
6
meses
por
ejemplo.
La idea de la metodologa gil es fundamentalmente que adopte los
cambios, que se pueda reconducir el proyecto en un momento dado, y
que afecte lo menos posible a los costes, los tiempos y al equipo de
trabajo.
No es la metodologa ideal. Yo siempre digo que si hubiera algo ideal,
todo el mundo lo usara, pero s te digo, que Scrum se acerca bastante a
esa idea general de la gestin ideal de proyectos.
A m personalmente es la que ms me gusta y la que por experiencia,
mayor satisfaccin suele dar, tanto al cliente o al usuario final como al
equipo de trabajo.
Y no te creas que hay mucho ms que saber de Scrum, esta es la
filosofa o idea general que espero te haya quedado clara y te haya
servido para entender lo que hablaba con mi compaero de trabajo.
Sin duda que me ha parecido muy interesante. Muchas gracias.
Nota: queda prohibida la reproduccin parcial o total de este artculo sin
la correspondiente autorizacin.
P.D.: muchas gracias a mi amigo y compaero Rodrigo Corral, el Mster
de Scrum, quin me ha aleccionado sobre Scrum y quien me ha revisado
esta historieta.