Durante la pasada dcada, las metodologas giles demostraron ser muy beneficiosas ayudando a los

equipos de software TI a la hora de entregar en fecha software de alta calidad que satisficiera las necesidades
de los accionistas. Los equipos de software quieren trabajar con metodologas giles porque necesitan un
proceso que pueda responder de manera eficiente a los cambios en los productos en desarrollo. Las
metodologas giles permiten una mayor flexibilidad que las metodologas tradicionales de desarrollo, que se
bloquean muy pronto en los detalles del proyecto y son menos capaces de ajustarse a las cambiantes
necesidades de los accionistas, del mercado y de los desafos imprevistos que plantea la tecnologa.


Cinco beneficios de las metodologas giles.

1.- Simplificacin de la sobrecarga de procesos
Los equipos que trabajan para crear productos regulados por estndares de la industria, deben demostrar el
cumplimiento de esas normas. Estos equipos suelen adoptar importantes sobrecargas de trabajo para
asegurarse de que cumplen con los estrictos mandatos de cdigo. Las metodologas giles pueden ayudarles
a cumplir los estndares de la industria con menos sobrecarga utilizando iteraciones ms cortas y
empaquetadas. El beneficio neto es un proceso que:

- Puede adaptarse a los cambios que, inevitablemente, surgirn
- Requiere menos sobrecarga en el proceso end-to-end
- Implica menos trabajo a medida que se acerca la fecha final

2.- Calidad mejorada
Las prcticas de desarrollo gil proporcionan la funcionalidad suficiente como para satisfacer las expectativas
de los accionistas con una alta calidad. Piensa en lo que significa ofrecer lo suficiente. Eso es, proporcionar
la mnima funcionalidad con la mxima calidad. La mnima funcionalidad no implica necesariamente una pobre
funcionalidad, implica lo suficiente como para conseguir que el trabajo se realice. Los accionistas suelen
pensar que saben lo que quieren cuando especifican altos niveles de requerimientos para un producto TI o de
software. Sin embargo, la mayora de las veces, cuando ven el producto final, ste no resuelve el problema.
Simplemente, no se han imaginado de forma precisa el mismo, o el problema ha cambiado o, incluso, la
tecnologa no era tan buena como pareca. Tambin puede ser que el producto no funcione realmente del
modo en que las partes interesadas tenan intencin, incluso aunque pensaran que haban descrito los
requerimientos de manera clara. Desarrollar iteraciones en poco tiempo y demostrar a los accionistas los
productos pronto y con frecuencia, permite tanto a los accionistas como a los equipos de desarrollo ponerse
de acuerdo y coincidir en que el producto cumple con cada una de sus necesidades.

3.- Mejorar la previsibilidad a travs de una mejor gestin del riesgo
Cuando los equipos de desarrollo no cumplen con sus fechas de lanzamiento, a menudo se debe a muchas
razones completamente justificables. Puede ser que el equipo no hubiera entendido bien lo difcil que sera
utilizar la nueva tecnologa; los requerimientos podan no estar del todo claros o los clientes cambiaron de
opinin cuando el trabajo estaba prcticamente finalizado. En cualquier caso, los negocios demandan
productos que cumplan con las fechas de entrega, de modo que los planes de negocio directamente
relacionados con ellos puedan cumplirse. Hay muchas formas en las que las metodologas giles pueden
ayudar a que los proyectos TI cumplan con las fechas de lanzamiento previstas.

Dar prioridad a los riegos. Las prcticas giles priorizan los aspectos de desarrollo de alto riesgo
permitiendo as una reduccin de los riesgos iniciales.

Evaluacin de riesgos en paralelo. Para reas de riesgo donde debera haber mltiples soluciones y el
equipo no se pone de acuerdo a la hora de tomar el camino ms adecuado, se debe tener en cuenta la
posibilidad de optar por el desarrollo multi-set. Esto requiere que diferentes equipos trabajen en paralelo
resolviendo el mismo problema con diferentes soluciones. La mayora de los equipos no considerarn ni tan
siquiera esta forma de trabajar, porque estn convencidos de que el tiempo y el coste requeridos para hacer
una evaluacin paralela son demasiado grandes. De hecho, el desarrollo paralelo de alternativas es probable
que traiga consigo las decisiones clave a seguir.

4.- 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. El desarrollo tradicional suele mostrar un patrn de trabajo parecido a un palo de hockey,
empezando con un ciclo de diseo de abajo arriba, movindose hasta una fase de prototipo para pasar luego
a un ciclo de desarrollo largo, seguido por otro ciclo totalmente impredecible en el que se integran las piezas
para pasar, por ltimo, a la fase de prueba final. A medida que el proyecto progresa, los equipos tienen que
trabajar juntos de manera ms coherente, confiando en que todas las piezas trabajen juntas tal y como
esperan. Pero lo cierto es que esto raramente ocurre, de modo que la interaccin entre los equipos aumenta a
medida que lo hacen los problemas de integracin. Por ltimo, la fase de pruebas lleva todo esto al lmite.
Trabajando juntos como un nico equipo en fases verticales del producto desde el principio del ciclo de
produccin, se evita el ciclo de productividad tradicional de palo de hockey. Los equipos giles tienden a ser
muy productivos desde la primera iteracin hasta su lanzamiento y su ritmo tiene que ser gestionado de modo
que no se produzca agotamiento. Los equipos giles que mantienen este cdigo de trabajo con cada iteracin,
permiten realizar pruebas de rendimiento y sistemas desde el principio, pudiendo empezar en las primeras
iteraciones. 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.

5.- Capacidad para aprovechar las inversiones realizadas
Adoptar las tcnicas giles de manera satisfactoria precisa un importante soporte de herramientas. La
mayora de los equipos invierten fuertemente en buenas herramientas de software y necesitan elevar esa
inversin y reducir la cantidad de cambios cuando empiezan a adoptar las metodologas giles. La inversin
ms crtica es una buena planificacin y una herramienta de gestin del trabajo que proporcione una cartera
de pedidos del equipo visible y que asocie el trabajo con cada elemento de trabajo en cartera. Idealmente, esa
herramienta de planificacin se integra con otras herramientas de desarrollo, lo que permite a los equipos
mantener la trazabilidad de la cartera de pedidos en otros aspectos, incluyendo:

- Los requerimientos que la impulsan.
- La arquitectura bajo desarrollo.
- El software de la solucin.
- Las pruebas que validan la solucin.

Las herramientas de Rational trabajan muy bien juntas y con otros productos para ayudar a entregar con xito
proyectos giles. IBM Rational Team Concert es el componente central de colaboracin y flujo de trabajo de la
solucin IBM Rational para ingeniera de software y sistemas. Proporciona una interfaz Open Services for
Lifecycle Collaboration (OSLC) que permite a las herramientas capacitadas OSLC integrarse sin problemas.
Rational Team Concert proporciona al equipo planificacin gil, visible y probada. De hecho, su adopcin para
simplemente ese propsito ha sido viral en IBM Software Group. Rational Team Concert proporciona gestin
de elementos, planificacin de equipos asociada a cargas de trabajo y visibilidad de proyectos, todos ellos,
elementos crticos en los proyectos giles. Los elementos de trabajo en Rational Team Concert son muy
flexibles en su uso y pueden asociarse con lanzamientos, equipos y dems.




Lun, 02/04/2013 - 09:48

Las metodologas giles de desarrollo de software son imprescindibles en un mundo en el que
las cosas cambian a velocidad de vrtigo. Los programadores vivimos preocupados sobre
cuales son las ltimas tendencias, que lenguajes o prcticas quedan obsoletos y con la
constante espada de Damocles de pensar que lo que estamos desarrollando hoy quizs no
sirva para nada maana.
El mundo del desarrollo, para bien o para mal, ha evolucionado desde un modelo en el que se
planificaban y estructuraban minuciosamente todas las fases a un modelo en el que el
desarrollo debe ser lo ms rpido y eficiente posible. Personalmente soy un gran fan de
los metodologas giles de desarrollo de software, cutos principios estn enunciados en
este manifiesto.
Estas son los mtodos de desarrollo gil de pginas que dominan el panorama a da de
hoy:
SCRUM
Scrum es una metodologa gil fantstica para desarrolladores. Consiste en un modelo de
asignacin de tareas diarias basado en reuniones rpidas y control de la evolucin de los
procesos. Es muy bueno para llevar un seguimiento de las tareas que se estn llevando a
cabo y saber en que puntos se ha atascado el equipo. Adems la profundidad de las tareas
que se asignan en SCRUM tiende a ser incremental, y esto coincide exactamente con el
devenir normal de un desarrollo.
Es genial para empresas de desarrollo de software orientadas a varios clientes.
XP o Xtream Programming
Programacin Extrema es un mtodo gil que se suele utilizar en equipos con muy pocos
programadres que tienen muy pocos procesos abiertos al mismo tiempo. Consiste
principalmente en disear, implementar, programar e implantar lo ms rpido posible en
equipos de programadores muy pequeos, principalmente parejas, saltandose la
documentacin y los procedimientos tradicionales. Se fundamente el la capacidad del equipo
para comunicarse entre si y las ganas de aprender de los errores propios inherentes en un
programador. Las gran ventaja que tiene este sistema es la increble capacidad de respuesta
del equipo ante imprevistos, aunque es una metodologa para la que es difcil documentar.
XP es un mtodo estupendo para equipos extremadamente pequeos que se centran en un
solo cliente.
Desarrollo Lean
Lean Software Development, tambin conocido como Lean Programming es un conjunto de
tcnicas que engloban una metodologa de desarrollo gil de software orientado a
conseguir exactamente lo que necesita el cliente. Es una evolucin del Mtodo Toyota de
Produccin aplicado al desarrollo y que est muy de moda entre los equipos de desarrollo
en startups. Principalmente consiste en ciclos de evolucin de software incrementales en los
que se postponen las decisiones lo ms posible hasta haber obtenido un feedback del cliente
y as reaccionar lo ms rpido y eficazmente posible a sus necesidades. Se fundamenta en
tener un equipo potente y comprometido y el principio de aprendizaje continuo sobre el
producto.
El Desarrollo Lean una metodologa fantastica para startups que estn desarrollando un
software orientado a tener xito en el mercado, como desarrolladores de videojuegos o apps
para mviles.

El mundo del desarrollo con metodologas giles fue mi puerta hacia el mundo de
la productividad personal y creo que ambas prcticas estn ntimamente interrelacionadas.
Un desarrollo gil necesita de personas productivas y las personas productivas necesitan de
un entorno de trabajo donde puedan explorar todo su potencial.









Metodologas giles vs tradicionales

Introduccin
Mi experiencia en los proyectos tecnolgicos comenz en dos multinacionales del software y la tecnologa,
donde pude experimentar en mis carnes las glorias y las miserias de proyectos innovadores y en contextos
organizativos frecuentemente complejos.
El abuso del modelo heroico, donde equipos altamente motivados pero no bien organizados, alcanzan los
objetivos del proyecto al precio de un alto sobreesfuerzo personal que asumen (ms o menos
voluntariamente) los miembros del equipo, me hizo entrar con entusiasmo en el mundo de las metodologas
de desarrollo y gestin de proyectos (RUP, PMBOK, SCRUM, Metrica3, etc.).
Consegu trasladar este inters personal a la prctica profesional y me dediqu unos aos a la venta de
metodologa y herramientas para el desarrollo y gestin de grandes proyectos. En este periodo tuve varias
oportunidades para conocer las metodologas giles en sus inicios a travs depractitioners entusiastas de
estas y de tener con stos encendidos debates acerca de cul era el mejor enfoque.
En mi tercera etapa profesional dentro del mundo de la tecnologa aplicada a la gestin, me dedico a la
consultora general sobre tecnologa y a la mejora de procesos TIC en organizaciones que adoptan
crecientemente metodologas giles. De hecho, la adopcin de SCRUM que hace unos pocos aos era
marginal, ahora si no es mayoritaria si es muy frecuente.
As pues, a partir del enfoque de alguien que ha conocido el caos (creativo), las metodologas tradicionales y
tambin las metodologas giles, tanto como usuario como consultor que ha ayudado a implantarlas, espero
hacer una aportacin interesante a este LAB de SCRUM.
En una serie de tres artculos, me propongo introducir el contexto de las metodologas y los modelos,
identificar como las aplicar con xito las metodologas en funcin del contexto del equipo y como combinar el
modelo CMMI y la metodologa SCRUM.


Metodologas giles vs tradicionales
1. Historia de las metodologas y de los modelos.
Desde el inicio del desarrollo masivo de software [1] se ha querido encontrar las mejores prcticas y distribuir
la experiencia obtenida a travs de la prctica. Esto se ha hecho tradicionalmente mediante metodologas
impulsadas por universidades y grandes empreses de tecnologa a travs de metodologas, como la
programacin estructurada (1969), SSADM (1980), RAD (1991), RUP y SCRUM (1998) o XP (1999).
Adems, se han generado diferentes modelos de calidad que identifican actividades del desarrollo
determinadas como buenas prcticas (el QUE) pero que no prescriben la manera de realizarlas
concretamente (el COMO), de manera que los equipos que los adoptan pueden elegir cual es la manera de
realizar estas prcticas que mejor se adapta a sus contextos y caractersticas.
2. Donde aplican cada uno
Simplificndolo mucho, se puede decir que las metodologas tradicionales (SSAD, RUP, etc.) ponen por
encima de lo dems los objetivos de la definicin y del control del trabajo, mientras que las metologas giles
priman la libertad del equipo, la comunicacin entre el cliente y el equipo, realizar slo las tareas que aportan
valor al cliente, y finalmente definir el trabajo tal y como ste se va realizando para el conocimiento adquirido
durante su desarrollo evite realizar tareas innecesarias.
Una consideracin importante es el tamao de los equipos. La inmensa mayora de los proyectos se realizan
por empresas o equipos muy pequeos (p.e. 1-10 personas) donde las metodologas tradicionales son
difciles de aplicar, e incluso imposibles si se quiere hacer de manera exhaustiva.
Otro aspecto influyente es el contexto y misin de los equipos, que pueden ser estables en su actividad (p.e.
desarrollo de un producto) o cambiar ms o menos frecuentemente de miembros o proyecto.

3. Mitos y realidades
Mi experiencia pasando por muchas organizaciones que desarrollan software me dice varias cosas:
1. Cada empresa es un mundo, lo que funciona en un sitio puede fracasar en otro.
2. El compromiso de la direccin con la mejora est por encima de todo lo dems. Cuando toca cambiar
los roles de las personas, introducir actividades que no se realizaban antes o atajar malas prcticas, si
la direccin no marca pblicamente el camino y acepta los problemas temporales que trae el cambio, la
mejora fracasar parcial o totalmente.
3. La experiencia y capacidad de las personas lo cambia todo, un gran mtodo de trabajo no suplir el
valor de las personas.
4. Una de las principales dificultades radica en el cambio de las personas. Conseguimos que stas
entiendan y se adapten a los roles que les asigna la metodologa? O por el contrario, el nuevo proceso
se ve limitado a los cambios que los miembros estn dispuestos a aceptar.
Existen diversas creencias falsas que pueden perjudicar la adopcin de una nueva metodologa, sea del tipo
que sea.
1. Las metodologas tradicionales son pesadas y que suponen obligatoriamente un todo o nada.
2. Las metodologas giles son ms modernas y mejores que cualquiera de las tradicionales.
3. Las actividades de calidad son intiles y slo funcionan en equipos grandes, no se adaptan a nuestros
proyectos. Cualquier cosa que nos quite tiempo de tareas tcnicas (programar, etc.) es una prdida de
tiempo.
4. Trabajar con una metodologa gil no supone aplicar disciplina alguna, sin que es una manera fcil de
dar estructura su caos imperante sin aadir actividades de calidad. Seguir SCRUM evita realizar
testing?
Como resmen, existen dos grandes conclusiones:
1. No hay varitas mgicas para conseguir mejorar la calidad y rendimiento de los equipos de manera
radical sin cambiar profundamente la manera de trabajar. Y esto no supone en absoluto que los cambios
sean difciles si la direccin y los miembros de la organizacin creen en ello decididamente.
2. Cada organizacin en mundo. Aplicar una metodologa estndar de manera rpida y sin trabajar abierta
y reflexivamente con los miembros de un equipo suele ser una buena receta para el desastre.
En los siguientes artculos se entrar en detalle en los factores que pueden ayudar a aplicar correctamente los
modelos y las metodologas a equipos segn su tamao, su objetivo o su contexto.
Para leer ms
[1] http://en.wikipedia.org/wiki/Software_development_methodology
[2] http://www.softwarepurist.com/blog/index.php/characteristics-of-sw-co-size/







Metodologa gil. Mtodo que permite incorporar cambios con rapidez en el desarrollo de software.En
muchas ocasiones, los modelos de gestin tradicionales no sirven para afrontar un reto que hoy en da resulta
fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto.
Contenido
[ocultar]
1 Fundamentacin
2 Historia
3 Manifiesto gil
4 Algunas Metodologas
giles
5 Fuente
Fundamentacin
Se trata de evitar lo que tantas veces ha ocurrido: cuando el proyecto se encuentra bastante avanzado y no va
por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios obligan
a desechar todo el trabajo realizado hasta entonces, lo que impide acabar en el plazo previsto. Dado que los
cambios nunca van a dejar de existir, es necesario ser capaces de gestionar los proyectos de una forma ms
gil. Con ese objetivo, en los aos 80 los japoneses Takeuchi y Nonaka estudiaron las prcticas de empresas
con buenos resultados de rapidez y flexibilidad en la
produccin: Xerox, Canon, Honda, NEC, Epson, Brother, 3M yHewlett-Packard. De ah extrajeron la base de
la metodologa gil SCRUM que, aunque naci en el mbito tecnolgico, ha ido creciendo hasta consolidarse
en campos de actividad muy diferentes.
Historia
La definicin moderna de metodologa gil de software evolucion a mediados de los aos 1990 como parte
de una reaccin contra las metodologas de "peso pesado", muy estructuradas y estrictas, extradas del
modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como
burocrtico, lento, degradante e inconsistente con las formas de desarrollo de software que realmente
realizaban un trabajo eficiente. Las metodologas de desarrollo giles e iterativas pueden ser vistas como un
retroceso a las prcticas observadas en los primeros aos del desarrollo de software (aunque en ese tiempo
no haba metodologas tradicionales). Inicialmente, las metodologas giles fueron llamadas metodologas de
"peso liviano". En el ao 2001, miembros prominentes de la comunidad se reunieron enSnowbird, Utah, y
adoptaron el nombre de " metodologas giles". Poco despus, algunas de estas personas formaron la
"alianza gil", una organizacin sin fines de lucro que promueve el desarrollo gil de aplicaciones. Muchas
metodologas similares a las giles fueron creadas antes del 2000. Entre los ms notables se encuentran:
Scrum (1986), Crystal Clear (cristal transparente), programacin extrema (en ingls eXtreme Programming
o XP, 1996), desarrollo de software adaptativo, feature driven development, Mtodo de desarrollo de sistemas
dinmicos (en ingls Dynamic Systems Development Method o DSDM, 1995). Kent Beck cre la metodologa
de Programacin Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto
del Sistema exhaustivo de compensaciones de Chrysler (C3). Mientras Chrysler cancelaba ese proyecto, la
metodologa fue refinada por Ron Jeffries. El punto de partida de esta reunin fue el Manifiesto gil, un
documento que resume la filosofa gil.
Manifiesto gil
Segn el Manifiesto se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es
el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que
construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el
equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de
desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es .no
producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin
importante. Estos documentos deben ser cortos y centrarse en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una
interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que
marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios
que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)
determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino
flexible y abierta.





Agil
(Redirigido desde Desarrollo Agil De Software)
El Desarrollo gil de Software es un paradigma de las Metodologias De Desarrollo basado en
procesos giles. Los procesos giles de desarrollo de software, conocidos anteriormente como
metodologas livianas, intentan evitar los tortuosos y burocrticos caminos de las
metodologas tradicionales enfocndose en la gente y los resultados.
El proceso gil usa un enfoque basado en el Valor para construir software, colaborando con el
cliente e incoporando los cambios continuamente.
Es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en
el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de
desarrollo gil; la mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo.
El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar
de una a cuatro semanas. Cada iteraciones del ciclo de vida incluye: planificacin, anlisis de
requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar
demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta
es tener un demo (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo
vuelve a evaluar las prioridades del proyecto.
Los mtodos Agiles enfatizan las comunicaciones cara a cara a travs de la documentacin.
La mayora de los equipos Agiles estn localizados en una simple oficina abierta. La oficina
debe incluir revisores, diseadores de iteracin, escritores de documentacin y ayuda y
directores de proyecto.
Contenido
[ocultar]
1 Manifiesto gil
o 1.1 Valores del Manifiesto gil
1.1.1 Valorar ms a los individuos y su interaccin que a los procesos y las herramientas
1.1.2 Valorar ms el software que funciona que la documentacin exhaustiva
1.1.3 Valorar ms la colaboracin con el cliente que la negociacin contractual
1.1.4 Valorar ms la respuesta al cambio que el seguimiento de un plan
2 Principios giles
3 Caractersticas de un desarrollo gil
4 Metodologas y prcticas giles
5 Ver tambin
Manifiesto gil
Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y
ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interaccin, por encima de los procesos y las herramientas.
El software que funciona, por encima de la documentacin exhaustiva.
La colaboracin con el cliente, por encima de la negociacin contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda.
Valores del Manifiesto gil
Valorar ms a los individuos y su interaccin que a los procesos y las
herramientas
Este es posiblemente el principio ms importante del manifiesto. Por supuesto que los
procesos ayudan al trabajo. Son una gua de operacin. Las herramientas mejoran la
eficiencia, pero sin personas con conocimiento tcnico y actitud adecuada, no producen
resultados.
Las empresas suelen predicar muy alto que sus empleados son lo ms importante, pero la
realidad es que en los aos 90 la teora de produccin basada en procesos, la re-ingeniera de
procesos ha dado a stos ms relevancia de la que pueden tener en tareas que deben gran
parte de su valor al conocimiento y al talento de las personas que las realizan.
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la
organizacin, a los equipos y a las personas; y no al revs. La defensa a ultranza de los
procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con
personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos
necesitan creatividad e innovacin.
Valorar ms el software que funciona que la documentacin exhaustiva
Poder ver anticipadamente como se comportan las funcionalidades que se esperan sobre
prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy
estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un
primer momento, y difcilmente se podran incluir al redactar un documento de requisitos
detallados antes de comenzar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentacin,
permiten la transferencia del conocimiento, registran informacin histrica, y en muchas
cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes
que los productos que funcionan. Menos trascendentales para aportar valor al producto.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generacin de valor que
se logra con la comunicacin directa entre las personas y a travs de la interaccin con los
prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mnimo
indispensable el uso de documentacin, que genera trabajo que no aporta un valor directo al
producto.
Si la organizacin y los equipos se comunican a travs de documentos, adems de perder la
riqueza que da la interaccin con el producto, se acaba derivando a emplear a los documentos
como barricadas entre departamentos o entre personas.
Valorar ms la colaboracin con el cliente que la negociacin contractual
Las prcticas giles estn especialmente indicadas para productos difciles de definir con
detalle en el principio, o que si se definieran as tendran al final menos valor que si se van
enriqueciendo con retro-informacin continua durante el desarrollo. Tambin para los casos en
los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.
Para el desarrollo gil el valor del resultado no es consecuencia de haber controlado una
ejecucin conforme a procesos, sino de haber sido implementado directamente sobre el
producto. Un contrato no aporta valor al producto. Es una formalidad que establece lneas
divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales
entre cliente y proveedor.
En el desarrollo gil el cliente es un miembro ms del equipo, que se integra y colabora en el
grupo de trabajo. Los modelos de contrato por obra no encajan.
Valorar ms la respuesta al cambio que el seguimiento de un plan
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor
inherente al cambio y la evolucin rpida y continua, resulta mucho ms valiosa la capacidad
de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los
principales valores de la gestin gil son la anticipacin y la adaptacin; diferentes a los de la
gestin de proyectos ortodoxa: planificacin y control para evitar desviaciones sobre el plan.
Principios giles
Los principios fundamentales de una metodologa gil se pueden resumir:
Nuestra principal prioridad es satisfacer al cliente a travs de la entrega temprana y
continua de software de valor.
Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los
procesos giles se doblegan al cambio como ventaja competitiva para el cliente.
Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta
un par de meses, con preferencia en los periodos breves.
Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a
travs del proyecto.
Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el
respaldo que necesitan y procurndoles confianza para que realicen la tarea.
La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un
equipo de desarrollo es mediante la conversacin cara a cara.
El software que funciona es la principal medida del progreso.
Los procesos giles promueven el desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
La atencin continua a la excelencia tcnica enaltece la agilidad.
La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
Las mejores arquitecturas, requisitos y diseos emergen de equipos que se auto-
organizan.
En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su
conducta en consecuencia.

Caractersticas de un desarrollo gil
Proceso iterativo e incremental
Mitigacin del riesgo mediante iteraciones fijas
Mejora continua
Calidad desde el primer da
Priorizacin de requerimientos de acuerdo a su valor
Equipos dedicados y auto-gestionados
Colaboracin continua con el cliente
Incorporar al cambio
Prcticas de desarrollo modernas
Metodologas y prcticas giles
Scrum
Extreme Programming
Test Driven Development
Sinceridad Como Valor Agil
Juegos Agiles
Behavior Driven Development