Beneficios y ventajas del mtodo SCRUM

A) A NIVEL DE LA PLANTILLA:

Se crean roles que fomentan el trabajo en equipo: el Product Owner

delimita aquello a construir en el prximo sprint, el equipo de
desarrollo se encarga de llevar a cabo el trabajo y de presentarlo al
cliente. A partir del feedback del cliente se decide cmo se
encaminara el siguiente sprint. Por ltimo el Scrum Masters se
asegura que todo este proceso ocurre de una forma ptima en las
mejores condiciones.
Incremento de la motivacin de los trabajadores: los equipos de
trabajo se autogestionan sus tareas y adems ven los frutos de su
trabajo rpidamente ya que en un breve periodo de tiempo pueden
ensearle su obra al cliente.
Fomenta la creatividad de la plantilla: breves espacios de tiempo con
necesidad de innovar hacen sacar lo mejor de uno mismo y de un
grupo de trabajo.

B) A NIVEL DE PROCESOS:

Transparencia en el desarrollo de los procesos y mayor control de

cada etapa: se trabaja alrededor de un documento llamado sprint
backlog en el cual se especifica cmo el equipo de trabajo va a llevar
a cabo las tareas durante el siguiente sprint Cada tarea especificada
en este documento se divide en horas y no es asignada a un
miembro en concreto sino que es trabajada de un modo conjunto y
multidisciplinar por de los diferentes miembros del equipo.
Feedback continua y ritmo predictible de trabajo: se tiene un gran
control sobre el desarrollo de cada etapa, los errores pueden ser
rectificados rpidamente sin afectar prcticamente al timming (sin la
implementacin del mtodo SCRUM esto sera inviable). Por este
motivo se mejora la calidad del producto/ servicio.
Pone en sintona al cliente con el proveedor (equipo de desarollo),
estrechando los lazos colaborativos cara a cara y creando productos y
servicios adaptados sistemticamente a las necesidades del cliente
(ahorro de tiempo). De este modo se cumple aquello que se
promete!
El mayor coste de su implementacin no es el de una inversin
econmica sino que viene determinado por los esfuerzos y la
capacidad para organizar y gestionar correctamente la adopcin de
esta metodologa.

C) A NIVEL DE RESULTADOS

Mayor productividad: incrementa la productividad fruto del

incremento de la motivacin grupal y del control de cada etapa
contenido en un timeline (que es muy breve y especfico);
conjuntamente propician una reduccin de los riesgos en todo el
proceso.

Permite una adaptabilidad a los cambios continuos del mercado

aportando as una ventaja competitiva: se genera una gran capacidad
de reaccin frente a las novedades empresariales.
Maximiza el retorno de la inversin (ROI): esto se consigue gracias a
invertir el tiempo, dinero y esfuerzo a aquello que realmente ofrece
valor al negocio, la priorizacin de las necesidades del cliente en cada
momento juegan un papel clave.

Desventajas de la metodologa SCRUM:

1. Si no existe una fecha definitiva de finalizacin del proyecto es posible
que se siga solicitando, y aadiendo, nueva funcionalidad.
2. Si una tarea no est bien definido, los costes de tiempo y dinero
estimados del proyecto no sern demasiado exactos. En ese caso, la tarea
se puede extender sobre varios sprints.
3. Si los miembros del equipo no estn centrados y convencidos, el proyecto
nunca se completara o incluso fallar.
4. Est bien para proyectos pequeos, de rpido movimiento ya que trabaja
bien solo con equipos pequeos.
5. Esta metodologa necesita solo miembros de equipo experimentados. Si
el equipo consiste en gente que es junior, el proyecto no puede ser
completado a tiempo.
6. Adems de los recursos sin suficiente experiencia, la falta de direccin
firme pueden llevar a los proyectos a no completarse o incluso fallar.
7. La metodologa Scrum funciona bien cuando el scrum master confa en el
equipo que lleva. Si se practican controles muy estrictos sobre los miembros
del equipo, puede ser extremadamente frustrante para ellos, llevando a la
desmoralizacin y el fallo del proyecto.
8. Si algunos de los miembros del equipo se marcha durante el desarrollo
puede tener un efecto negativo enorme en el desarrollo del proyecto.
9. El control de la calidad del proyecto es difcil de implementar y cuantificar
a menos que el equipo de test puedan llevar a cabo testeo de regresin
despus de cada sprint.

Requisitos para poder utilizar Scrum

Los siguientes puntos son de especial importancia para la implantacin de
una gestin gil de proyectos como Scrum:

Cultura de empresa basada en trabajo en equipo, delegacin,

creatividad y mejora continua.
Compromiso del cliente en la direccin de los resultados del proyecto,
gestin del ROI y disponibilidad para poder colaborar.
Compromiso de la Direccin de la organizacin para resolver
problemas endmicos y realizar cambios organizativos, formando
equipos autogestionados y multidisciplinares y fomentando una
cultura de gestin basada en la colaboracin y en la facilitacin
llevada a cabo por lderes al servicio del equipo.
Compromiso conjunto y colaboracin de los miembros del equipo.
Relacin entre proveedor y cliente basada en ganar-ganar,
colaboracin y transparencia.
Facilidad para realizar cambios en el proyecto.
Tamao de cada equipo entre 5 y 9 personas (con tcnicas
especficas de planificacin y coordinacin cuando varios equipos
trabajan en el mismo proyecto).
Equipo trabajando en un mismo espacio comn para maximizar la
comunicacin.
Dedicacin del equipo a tiempo completo.
Estabilidad de los miembros del equipo

Proyectos en los que no funciona un modelo gil

Aunque parece claro que la direccin de proyectos en cascada no siempre
es la mejor solucin para todo tipo de proyectos, clientes y culturas de
empresa, la atraccin que a veces nos provoca, por lo menos a m, la
gestin de un proyecto de forma gil, requiere tambin un ejercicio de
reflexin antes de abrazarla.
En algunos escenarios simplemente no es factible utilizar el enfoque de
desarrollo gil: la estructura no facilita la toma de decisiones a la velocidad
adecuada, el personal no est motivado para afrontar un cambio de este
tipo, la cultura de empresa es contraria A veces un cambio en las
metodologas a utilizar debe reflejarse en un cambio estructural, cultural,

etc que es posible no estemos preparados para asumir. (Claudia

Alcelay,2015)
La estructura de la organizacin
Existe un condicionante muy importante a la hora de utilizar este tipo de
metodologas: la organizacin. Existen organizaciones en las que la
estructura altamente jerarquizada y la cultura propia de la empresa hacen
que no sean el mejor escenario para un desarrollo gil. Las decisiones se
ralentizan, lo que hace que la concrecin del software sea costosa y larga, lo
que atenta directamente contra la iteracin necesaria dentro de un proyecto
gil.
Imponer el desarrollo gil
La mejor manera de hacer fracasar un proyecto gil es imponiendo el
mtodo de trabajo. Dado que las personas y sus capacidades son el eje
central del desarrollo gil (por encima de los procesos y las herramientas),
debemos aprovechar estas capacidades escuchando qu tienen que decir y
teniendo en cuenta esta opinin. En algunos casos y organizaciones esto
simplemente no es posible, porque no es la poltica de la direccin o por
otras razones, con lo que una implantacin de mtodos giles ser un
fracaso, dado que se estar obviando uno de sus principios bsicos.
Colaboracin con el cliente
Otro escenario donde el desarrollo gil no ser una buena eleccin es aquel
en el que el usuario o cliente (en definitiva quien demanda el desarrollo del
producto o la construccin del software) no est dispuesto a colaborar en el
formato que se solicita dentro de un desarrollo gil. Recordemos que vamos
a necesitar su apoyo y disponibilidad de una manera bastante intensiva
dentro de las reuniones peridicas que llevamos a cabo, adems de otros
momentos puntuales en los que su colaboracin ser requerida para
aclaraciones concretas. Si no tenemos disponibilidad por parte del usuario,
el proyecto no debe tener este formato gil, dado que en muchos casos
encontraremos impedimentos importantes si no contamos con esa
colaboracin.
El grado de definicin e incertidumbre inicial condiciona la metodologa a
emplear.
El propio carcter de los proyectos de software, en general nos inclina a
decir que la mayora de los estos proyectos son susceptibles de gestionarse
de forma gil, dado que es muy laborioso definir totalmente un proyecto
software al comienzo del mismo, lo que inevitablemente conducira a
cambios, especificaciones mal entendidas, errores que conducirn a su
vez, a iterar sobre el producto para refinarlo.

Dicho esto, existen mbitos en los que la criticidad del software en cuestin
no permite ensayos de ningn tipo y necesite una especificacin total
anticipada de los escenarios a afrontar: no es lo mismo desarrollar el
software de una red social en la web que el software que gobierna el

aterrizaje de una nave en la luna, sobre todo en cuanto a la tolerancia a

fallo y las repercusiones de este fallo. En estos escenarios la especificacin
del sistema ser ms larga y costosa y parece razonable que necesita una
fase de especificacin mayor que otros.
Adaptacin al entorno
Inevitablemente, toda incorporacin de los mtodos de desarrollo giles a
un entorno determinado terminarn con un grado de adaptacin al entorno.
Hemos comentado algunos de los problemas habituales a la hora de hacer
una implantacin gil: los perfiles disponibles, la estructura jerrquica de la
organizacin, la experiencia del equipo e incluso su motivacin para probar
cosas nuevas
https://proyectosagiles.org/beneficios-de-scrum/
http://comunidad.iebschool.com/openiebs/marketing/que-es-scrumbeneficios-ventajas-para-negocio/
https://proyectosagiles.org/requisitos-de-scrum/
https://www.linkedin.com/pulse/el-agilismo-siempre-es-la-mejor-opci
%C3%B3n-claudia-alcelay