Tabla de contenido

Agile ........................................................................................................................ 2

El surgimiento de gil .............................................................................................. 2

El Manifiesto gil ..................................................................................................... 3

Principios de Manifiesto gil.................................................................................... 5

Mtodos giles ........................................................................................................ 6

SCRUM ................................................................................................................ 7

Programacin extrema ......................................................................................... 7

Lean Kanban ........................................................................................................ 8

Mtodos Crystal ................................................................................................... 8

Mtodos de desarrollo de sistemas dinmicos .................................................... 9

Desarrollo orientado a funcionalidades .............................................................. 10

Desarrollo guiado por pruebas ........................................................................... 10

Desarrollo adaptativo de software ...................................................................... 11

Proceso unificado gil ........................................................................................ 11

Desarrollo guiado por el dominio ....................................................................... 12

Beneficios de aplicar la Metodologa gil .............................................................. 12

Principales ventajas y limitaciones de las metodologas giles ............................. 14

Principales ventajas de las metodologas giles ............................................... 14

Desventajas e inconvenientes de las metodologas Agiles ................................ 15

 Tradicionalmente las metodologas de gestin de proyectos como PMBOK y
PRINCE2 han tenido una fuerte orientacin predictiva. Es decir, a partir del detalle
del producto que se quiere elaborar (anlisis funcional/tcnico, requerimientos
funcionales/tcnicos, etc.), se definen fases/actividades perfectamente planificadas
en el tiempo en base a los recursos disponibles. A partir de esta proyeccin inicial,
el objetivo durante el transcurso del proyecto es conseguir que se cumpla aquello
que se haba previsto: calendario, costes y calidad.

En la situacin actual en el que los cambios se producen de manera

increblemente rpida y se producen cambios dentro de los cambios, muchos
autores comentan que las guas tradicionales de gestin de proyectos intentan ver
el futuro. Ahora es necesario modelos que nos ayuden a adaptarnos a los cambios.
Esta afirmacin es mucha ms acertada en el sector de las tecnologas de la
informacin y las comunicaciones (TIC) en el que la velocidad y agilidad al cambio
es fundamental. Por esta razn, surgen las metodologas giles.

Agile
La palabra gil generalmente hace referencia a la capacidad de moverse o
responder con rapidez y facilidad; ser gil. En cualquier tipo de disciplina de
administracin, gil es una calidad, y, por lo tanto, es algo bueno que se debe
buscar. Especficamente, la administracin gil de proyectos implica adaptarse
durante la creacin de un producto, servicio u otro resultado.

Es importante entender que, aunque el desarrollo de mtodos giles es

altamente adaptativo, tambin es necesario considerar la estabilidad en su proceso
de adaptacin.

El surgimiento de gil
Los rpidos cambios en la tecnologa, las demandas y expectativas del
mercado han creado mayores desafos en el desarrollo de productos y servicios
mediante el uso de modelos tradicionales de gestin de proyectos. Esto abri el
camino para la conceptualizacin e implementacin de mtodos y valores giles en
muchas organizaciones. Los modelos de desarrollo gil atienden las deficiencias
asociadas con los modelos tradicionales de gestin de proyectos para satisfacer las
crecientes demandas ambientales y expectativas que enfrentan las organizaciones.
Dado a que los modelos tradicionales de gestin de proyectos en general hacen
hincapi en una amplia planificacin anticipada y que se ajustan al plan una vez que
se establece, tales modelos no tuvieron xito al intentar cumplir la realidad de los
frecuentes cambios ambientales.

gil depende de la planificacin adaptiva y del desarrollo y la entrega

iterativa. Se centra principalmente en el valor de las personas al hacer eficazmente
el trabajo. Aunque las metodologas adaptativas e incrementales han existido desde
los aos cincuenta, nicamente las metodologas que conforman el Manifiesto gil
generalmente se consideran verdaderamente giles.

A finales de los aos 80 y principios de los 90, un grupo de herramientas de

gestin de proyectos se abri paso en el terreno empresarial para intentar resolver
los problemas que los mtodos tradicionales eran incapaces de encarar. La gestin
tradicional era especialmente propensa a creer que los proyectos slo deban ser
intervenidos en su fase final, algo que no slo evitaba una pronta reaccin, sino que,
adems, aumentaba considerablemente los costes y el empleo de recursos.
Inicialmente llamadas herramientas de peso liviano, estas nuevas tcnicas
buscaban un objetivo concreto: agilizar los procesos que tenan lugar en las
organizaciones y, del mismo modo, generar respuestas ms efectivas ante los
eventuales retos. Era tiempo de apostar por nuevas vas de desarrollo y ejecucin.

El Manifiesto gil
En febrero del 2001, un grupo de 17 gurs de la informtica, desarrolladores
de software y administradores, se reunieron para discutir los mtodos de desarrollo
de software ligero. Formaron la Alianza gil (Agile Alliance) y las discusiones en
estas reuniones resultaron despus en un Manifiesto para el desarrollo gil de
software (Manifesto for Agile Software Development). El manifiesto fue escrito por
Flowler y Highsmith (2001) y suscrito despus por todos los participantes a fin de
establecer los lineamientos bsicos de cualquier metodologa gil.
El propsito del Manifiesto gil se plasm de la siguiente forma:

Estamos descubriendo formas mejores de desarrollar software tanto por

nuestra propia experiencia como ayudando a terceros. A travs de este
trabajo hemos aprendido a valorar:

Las cuatro contrapartes del Manifiesto gil se elaboran de la siguiente forma:

1. Individuos e interacciones sobre procesos y herramientas

Aunque los procesos y las herramientas ayudan a terminar con xito un

proyecto, son las personas quienes asumen, participan e implementan un proyecto
y determinan cules procesos y herramientas utilizar. Por lo tanto, los actores clave
en cualquier proyecto son las personas, por ello, el nfasis debe estar en ellos y en
sus interacciones en vez de los complicados procesos y herramientas.

2. Software funcionando sobre documentacin extensiva

 Aunque la documentacin es necesaria y til para cualquier proyecto, muchos
equipos se centran en la recopilacin y el registro de descripciones cualitativas y
cuantitativas de los entregables, cuando el valor real que se le entrega al cliente es
en forma de un software funcional. Por lo tanto, en vez de la documentacin
detallada, el enfoque gil est en la entrega de un software de buen funcionamiento
en incrementos a lo largo del ciclo de vida del producto.

3. Colaboracin con el cliente sobre negociacin contractual

Tradicionalmente a los clientes se les ha visto como participantes externos,

involucrados principalmente al inicio y al final del ciclo de vida del producto y cuya
relacin se basaba en contractos y en su cumplimiento. gil cree en un enfoque de
valor compartido en el cual los clientes se consideran colaboradores. El equipo de
desarrollo y el cliente trabajan unidos para evolucionar y desarrollar el producto.

4. Responder ante el cambio sobre seguir un plan

En mercado actual donde los requerimientos del cliente, las tecnologas

disponibles y los patrones empresariales cambian constantemente, es
fundamental abordar el desarrollo de productos en una forma adaptativa que
permita la incorporacin de cambio y rpidos ciclos de vida de desarrollo de
producto en vez de enfatizar el seguimiento de planes formados probablemente con
informacin obsoleta.

Principios de Manifiesto gil

Los 12 principios del Manifiesto gil de Fowler y Highsmith (2001) son los
siguientes:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana

y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardas del
desarrollo. Los procesos giles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
 3. Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo ms corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de
forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles
el entorno y el apoyo que necesitan, y confiarles la ejecucin del trabajo.
6. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de
desarrollo y entre sus miembros es la conversacin cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos giles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
9. La atencin continua a la excelencia tcnica y al buen diseo mejora la
agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
11. Las mejores arquitecturas, requisitos y diseos emergen de equipos auto-
organizados.
12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para
a continuacin ajustar y perfeccionar su comportamiento en consecuencia.

Mtodos giles
En la dcada de los noventa y a principios del 2000, se origin y obtuvo fuerza
una serie de metodologas giles. Aunque difieren en una variedad de aspectos, lo
que tienen en comn se deriva de su apego al Manifiesto gil.

De entre todos los mtodos de desarrollo gil, se describen las siguientes, siendo
las que ms denominan las primeras tres:

SCRUM
Programacin extrema (Extreme Programming)
Lean Kanban
Mtodos Crystal (Crystal Methods)
 Mtodos de desarrollo de sistemas dinmicos (Dynamic Systems
Development Methods)
Desarrollo orientado a funcionalidades (Feature Driven Development)
Desarrollo guiado por pruebas (Test Driven Development)
Desarrollo adaptativo de software (Adaptive Software Development)
Proceso unificado gil (Agile Unified Process)
Desarrollo guiado por el dominio (Domain Driven Development)

SCRUM
Scrum-Team

El Scrum es un proceso de la Metodologa gil que se usa para minimizar los

riesgos durante la realizacin de un proyecto, pero de manera colaborativa.

Entre las ventajas se encuentran la productividad, calidad y que se realiza un

seguimiento diario de los avances del proyecto, logrando que los integrantes estn
unidos, comunicados y que el cliente vaya viendo los avances. La profundidad de
las tareas que se asignan en SCRUM tiende a ser incremental, caso que coincide
exactamente con el devenir normal de un desarrollo.

Programacin extrema
La programacin extrema (conocida en ingls como: Extreme Programming),
creada en la Chrysler Corporation, obtuvo impulso en la dcada de 1990. La
programacin extrema, o XP, por sus siglas en ingls, evita el aumento radical del
costo de software cambiante con el paso del tiempo. Las caractersticas claves del
XP incluyen el desarrollo incremental, horarios flexibles, cdigos de prueba
automatizados, comunicacin verbal, diseo en evolucin constante, as como la
colaboracin de cerca a corto y largo plazo se deriva de todos los que participan.

La programacin extrema valora la comunicacin, la retroalimentacin, la

simplicidad y el valor. Los distintos roles en el enfoque de XP incluyen: el cliente,
desarrollador, seguidor (tracker) y el coach.

Prescribe varias prcticas de codificacin, de desarrollo y empresariales, as

como eventos y artefactos para lograr un desarrollo eficaz y eficiente. El extreme
programming ha sido adoptado extensamente debido a sus prcticas de ingeniera
bien definidas.

Lean Kanban
El concepto de Lean optimiza el sistema de una organizacin para producir
resultados valiosos sobre la base de sus recursos, necesidades y alternativas,
mientras se reducen las perdidas. Las prdidas (waste) pudieran ser por la
fabricacin de algo equivocado, la imposibilidad de aprender o de prcticas que
impidan el proceso. Debido a que estos factores tienen una naturaleza dinmica,
una organizacin Lean evala la totalidad de su sistema y refina constantemente
sus procesos. El fundamento de Lean es la reduccin de la duracin de cada ciclo
(cada interaccin), lo cual lleva a un aumento en la productividad mediante la
reduccin de retrasos y ayuda a detectar errores en las primeras etapas, reduciendo
en consecuencia la cantidad total del trabajo necesario para finalizar una tarea. Los
principios del software Lean se han implementado con xito en el desarrollo de
software. Kanban literalmente significa cartel o letrero, e implica el uso de ayuda
visual para dar seguimiento a la produccin. El concepto fue introducido por Taiichi
Ohno, considerado como el padre de los Sistemas de Produccin Toyota (TPS, por
sus siglas en ingls). El uso de ayuda visual es eficaz y se ha convertido en una
prctica comn. Algunos ejemplos incluyen: tarjetas de tarea, tableros de Scrum y
grficas de trabajo terminado (Burndown Charts). Dichos mtodos generaron
atencin debido a su prctica en Toyota, empresa lder en gestin de procesos.
Lean Kanban integra el uso de mtodos de visualizacin segn lo prescrito por
Kanban aunado a los principios de Lean, creando as un sistema visual de gestin
de proceso evolutivo incremental.

Mtodos Crystal
Las metodologas Crystal para el desarrollo de software fueron introducidas
por Alistair Cockburn a principios de la dcada de 1990. La intencin de los mtodos
Crystal es centrarse en las personas; ser ligeros y fciles de adaptar. Debido a que
las personas son primordiales, el proceso de desarrollo y las herramientas no son
fijas, sino que se ajustan a los requerimientos y caractersticas especficas del
proyecto. Se utiliza el espectro de colores para decidir sobre la variante de un
proyecto. Los factores tales como la comodidad, el dinero a discrecin, dinero
esencial y la vida, juegan un papel importante para determinar el peso de la
metodologa, lo cual se representa en varios colores del espectro.

La familia Crystal se divide en: Crystal Clear (claro como el cristal), Crystal
Yellow (cristal amarillo), Crystal Orange (cristal naranja), Crystal Orange Web
(cristal naranja web), Crystal Red (cristal rojo), Crystal Maroon (cristal marrn),
Crystal Diamond (cristal diamante) y Crystal Sapphire (cristal zafiro).

Todos los mtodos Crystal tienen cuatro roles: patrocinador ejecutivo

(Executive sponsor), diseador lder (lead designer), desarrolladores y usuarios
experimentados. Los mtodos Crystal recomiendan varias estrategias y tcnicas
para lograr agilidad. Un ciclo de proyecto Crystal consiste de la implementacin del
acta constitutiva (chartering), ciclo de entrega y cierre (wrap-up).

Mtodos de desarrollo de sistemas dinmicos

El marco del sistema de desarrollo de sistemas dinmicos (DSMS, por sus siglas
en ingls) fue publicado inicialmente en 1995 y lo administra el Consorcio DSMS. El
DSMS fija la calidad y el esfuerzo en trminos de costo y tiempo al principio y ajusta
los entregables del proyecto para cumplir con los criterios fijos mediante la
priorizacin de los entregables en las categoras:

Debe tener Must have

Debera tener Should have
Podra tener Could have
No tendr Wont have

Con el uso de la tcnica de priorizacin MoSCoW. El DSMS es un mtodo

orientado en sistemas con seis fases distintas: pre-proyecto; viabilidad;
fundamentos; exploracin e ingeniera; desplazamiento y evaluacin de beneficios.
En el 2007 se introdujo una nueva versin del sistema de desarrollo de sistemas
dinmicos, conocida como DSMS Atern, misma que se enfoca tanto en la
priorizacin de entregables como en el usuario consistente o colaboracin del
cliente. La nueva versin se inspira en Arctic Tern, hacindola un marco de
desarrollo de software centrado en el desarrollador para la entrega de
caractersticas del proyecto a tiempo y dentro de los lmites del presupuesto y en
control de calidad.

Desarrollo orientado a funcionalidades

El desarrollo orientado en funcionalidades (FDD, por sus siglas en ingls) fue
introducido por Jeff De Luca en 1997 y opera bajo el principio de concluir un proyecto
mediante su fragmentacin en pequeas funciones valoradas por el cliente que
puedan presentarse en menos de dos semanas. El desarrollo orientado en
funcionalidades tiene dos principios fundamentales: el desarrollo de software es una
actividad humana y es una funcionalidad valorada por el cliente.

El FDD define seis roles principales: Gerente del proyecto, arquitecto en jefe,
gerente de desarrollo, programadores jefes, propietarios de clase y expertos del
dominio, aunados a una serie de funciones complementarias. El proceso FDD es
iterativo y consiste en el desarrollo de un modelo general; en crear una lista de
caractersticas y despus planificar, disear y crear con base en la caracterstica.

Desarrollo guiado por pruebas

Conocido tambin como desarrollo primero por pruebas (del ingls: Test-
First Development), el desarrollo guiado por pruebas fue introducido por Kent Beck,
uno de los creadores de la programacin extrema. El desarrollo guiado por pruebas
es un mtodo de desarrollo de software que implica redactar primero cdigos de
prueba automticos y desarrollar la cantidad mnima de cdigo necesario para
avanzar despus hacia la siguiente prueba. La totalidad del proyecto se divide en
pequeas caractersticas valoradas por el cliente que deben desarrollase en el ciclo
de desarrollo ms breve posible. Las pruebas se redactan con base en los
requerimientos y especificaciones del cliente. Las pruebas diseadas en la etapa
anterior se utilizan para disear y redactar el cdigo de produccin.

El desarrollo guiado por pruebas (TDD, por sus siglas en ingls), se puede
clasificar en dos niveles: Aceptacin de TDD (ATDD, en ingls), lo cual requiere de
una prueba distinta de aceptacin, y Desarrollador TDD (DTDD en ingls) que
implica la redaccin de una sola prueba de desarrollo. El TDD se ha popularizado
debido a las numerosas ventajas que ofrece como los resultados confiables, la
retroalimentacin constante y la reduccin de tiempo de depuracin (debugging).

Desarrollo adaptativo de software

El desarrollo adaptativo de software (ASD, por sus siglas en ingls) surgi a
partir del rpido trabajo de desarrollo de aplicaciones por parte de Jim Highsmith y
Sam Bayer. Los aspectos ms destacados del ASD son la constante adaptacin de
procesos al trabajo con el que se cuenta, el suministro de soluciones a los
problemas que surgen en los grandes proyectos, as como el desarrollo iterativo e
incremental con prototipos continuos.

Al ser un mtodo de desarrollo impulsado por el riesgo y tolerante al cambio,

el desarrollo adaptativo de software indica que un plan no puede aceptar
incertidumbres y riesgos, ya que esto sera indicativo de un plan deficiente y fallido.
El desarrollo adaptativo de software se basa en caractersticas y se gua por metas.

La primera fase en este tipo de desarrollo es la especulacin (a diferencia de la

planificacin), seguida de las fases de colaboracin y aprendizaje.

Proceso unificado gil

El proceso unificado gil (AUP, por sus siglas en ingls) evolucion del
proceso unificado racional de IBM (del ingls: IBMs Rational Unified Process). El
proceso unificado gil, desarrollado por Scott Ambler, combina tcnica giles
probadas y examinadas por la industria tales como el desarrollo guiado por pruebas
(TDD), modelos giles, gestin gil de cambios y refactorizacin de base de datos,
a fin de brindar un producto funcional de la mejor calidad.

El proceso unificado gil modela sus procesos y tcnicas con base en los
valores de las herramientas de la simplicidad, agilidad, personalizacin, auto-
organizacin e independencia y se enfoca en actividades de alto valor. Los
principios y valores del proceso unificado gil se ponen en accin en las fases de:
incepcin (inicio), elaboracin, construccin y transicin.
Desarrollo guiado por el dominio
El desarrollo guiado por el dominio (DDD, por sus siglas en ingls) es un
mtodo de desarrollo gil diseado para administrar diseos complejos con la
implementacin vinculada a un modelo evolutivo. Fue conceptualizado en el 2004
por Eric Evans y gira en torno al diseo de un dominio central. La palabra dominio
se define como un rea de actividad en la cual el usuario aplica un programa o
funcionalidad.

Muchas de estas reas se procesan en lotes y se disea un modelo. El

modelo consiste en un sistema de abstracciones que se pueden utilizan para
disear un proyecto general y resolver los problemas relacionadas a los dominios
en lote. Los valores centrales del DDD incluyen: el diseo orientado en el dominio,
diseo guiado por el modelo, el lenguaje ubicuo y el contexto limitado.

En el DDD, se establece un lenguaje ubicuo y se modela el dominio. Despus

sigue el diseo, el desarrollo y la evaluacin. La refinacin y refactorizacin del
modelo del dominio se lleva a cabo hasta que sea satisfactorio.

Beneficios de aplicar la Metodologa gil

RSI superior (ndice de fuerza relativa)

Cuando se lidia con proyectos mltiples y no se aplican metodologas giles,

lo normal es esperar a que se complete un proceso antes de arrancar con el
segundo. Para poder lidiar con este tipo de operacin de proyectos se estila buscar
el cmo finalizar entregas lo ms pronto posibles lo cual significa un inmenso riesgo
de recorte de funcionalidades o calidad.

El desarrollo con metodologa gil refuerza las entregas mltiples lo cual

contra el cliente es un indicador operante y de cierto modo representara un capital
en trabajo. Como tal se refuerza ms bien la lista de funcionalidades del acuerdo de
entrega y en el promedio implica un enfoque en desarrollar la funcionalidad que se
considere ms vital para el proyecto desde el simple inicio.

El desarrollo gil aumenta la productividad

 La metodologa gil sirve para enfocar la atencin de los partidos por
disciplina en el espacio que se les necesita e inmediatamente liberar el talento para
que puedan moverse entre zonas de trabajo.

Aplicar un sistema de tarea discretas contra las personas que las ejecutan
simplifican la distribucin de entrega de informacin y consecuentemente del mismo
sentido de capacidad de control del mismo empleado lo cual resulta en un deseo
inherente de procesar las tareas lo ms simple y rpidamente posible.

Simplifica el manejo de la sobrecarga de procesos

Los equipos que trabajan sobre normas y regulaciones han de validar su

trabajo constantemente lo cual representa un doble sentido de trabajo. Las
metodologas por iteracin simplifican el proceso de entrega versus validacin lo
cual adems permite adoptar cambios sobre la marcha del alcance del proyecto.

Mejor perfil de productividad

Los equipos giles son ms productivos que aquellos que utilizan mtodos
tradicionales a lo largo de todo el ciclo de desarrollo. Si no se aplica un sistema gil
se presenta un patrn de desarrollo tipo palo de hockey donde la mayora del
trabajo sucede en las primeras etapas y ya que anden los equipos se van haciendo
ajustes sobre el trabajo anterior. La realidad es que casi nunca suele suceder que
las piezas en equipo terminan trabajando juntos de manera coherente.

Los equipos giles que mantienen un nivel de revisin por unidades discretas
de entrega de trabajo con cada iteracin permiten realizar pruebas de rendimiento
y sistemas desde el principio. De este modo, defectos crticos como problemas de
integracin se descubren antes, la calidad general del producto es mayor y el equipo
funciona de manera ms productiva durante todo el ciclo de desarrollo.

Una mejor gestin del riesgo

No siempre se logra cumplir con las metas de lanzamiento cuando se trabaja

con software, mientras ms lejanas sean las entregas contra cliente o equipo ms
se maximiza el riesgo de potencial desviacin de la entrega contra la definicin del
proyecto inicial. Las metodologas giles permiten repasar en ciclos continuos
progreso in media res de entregables y productos semi-cerrados. Cuando fallan las
entregas la metodologa gil permite ajustar el ciclo de trabajo para enfocar el
talento en zonas de mayor o menor riesgo a justificacin de defender un proyecto
en su totalidad.

Principales ventajas y limitaciones de las metodologas giles

Las metodologas giles surgieron a finales de los aos 90 como respuesta
a los modelos tradicionales de gestin empresarial. Fue un momento en que el
sector exiga nuevas dinmicas y soluciones para afrontar los retos del nuevo siglo,
caracterizado mayoritariamente por la expansin de Internet y las nuevas
tecnologas. La premisa era una sola: renovarse en la gestin.

A partir de entonces, muchas disciplinas se acogieron a la metodologa gile

para la puesta en marcha de sus proyectos, especialmente los que tenan que ver
con el sector del software. Scrum fue la ms empleada. Entre otras novedades,
gile introdujo el mtodo de clasificacin de las etapas de un proyecto en pequeos
bloques tambin llamados iteraciones, que a su vez albergaban las tareas
propias de cada etapa. Del mismo modo, supuso una optimizacin de los recursos
al clasificar las tareas en las que tienen un mayor impacto en los proyectos y las
que no. De esta manera se logr una jerarquizacin ms ptima de las prioridades.

Principales ventajas de las metodologas giles

Adems de las mencionadas en el apartado anterior, las metodologas gile
supusieron beneficios como los que sealamos a continuacin:

Rpida respuesta a los cambios. Al ser procesos evolutivos, los equipos de

trabajo pueden implementar soluciones sobre la marcha. Ya no es necesario
esperar hasta el final para corregir fallos.
Intervencin del cliente en el proceso. El cliente interviene de una forma
activa en cada una de las etapas del proceso. Puede aportar ideas y opinar
sobre los resultados que se le van entregando progresivamente.
 Entregas del producto a intervalos. Las entregas parciales o en bloques
mejoran la optimizacin de recursos y optimizan las labores de seguimiento
y control. El producto final es, en realidad, la suma de varios productos
parciales que han sido monitorizados varias veces.
Eliminacin de tareas innecesarias. Al priorizar las tareas de un proceso, los
responsables del mismo saben con certeza cules tienen un mayor peso y
cules resultan secundarias o, incluso, innecesarias. Esta distincin ayuda a
centralizar esfuerzos y a unificar criterios de actuacin.

Desventajas e inconvenientes de las metodologas Agiles

Sin embargo, no todos los sectores empresariales han acogido las
metodologas gile con el mismo entusiasmo. Las empresas que son ms
partidarias de poner en marcha procesos basados en el Ciclo de Vida de los
productos han encontrado en ellas serios inconvenientes para la consecucin de
sus objetivos:

Fuerte dependencia de los lderes. Los equipos de trabajo dependen en

buena medida del liderazgo de la persona responsable. Las reuniones
continuas y las evaluaciones peridicas hacen que la persona que encabeza
el proyecto centralice casi todas las decisiones y responsabilidades.
Falta de documentacin. Las metodologas gile no plantean alternativas a
para la recoleccin de la informacin de los proyectos. Simplemente plantea
la manera cmo se llevarn a cabo las acciones.
Soluciones errneas en etapas largas. Cuando las iteraciones tienden a ser
muy largas, se corre el riesgo de que las soluciones esbozadas al inicio de
las etapas no sean las correctas. Una fase larga puede evolucionar mientras
se est ejecutando y, por tanto, las medidas tomadas tienen a perder
vigencia.