Metodologias Agiles

Metodologas de Desarrollo de Software giles
Con mucho, el desarrollo de software es una actividad catica,

frecuentemente caracterizada por la frase "codifica y corrige". El software se
escribe con un plan subyacente mnimo, y el diseo del sistema se adoquina
con muchas decisiones a corto plazo. Esto realmente funciona muy bien si el
sistema es pequeo, pero conforme el sistema crece llega a ser cada vez ms
difcil agregar nuevos aspectos al mismo. Adems los bugs llegan a ser cada
vez ms frecuentes y ms difciles de corregir. La sea tpica de tal sistema es
una larga fase de pruebas despus de que el sistema ha sido "completado". Tal
fase larga de pruebas hace estragos con los planes de pruebas y depurado
llegando a ser imposible de incluir en el programa de trabajo.
Hemos vivido con este estilo de desarrollo por mucho tiempo, pero
tambin hemos tenido una alternativa desde hace mucho: Metodologa. Las
metodologas imponen un proceso disciplinado sobre el desarrollo de software
con el fin de hacerlo ms predecible y eficiente. Lo hacen desarrollando un
proceso detallado con un fuerte nfasis en planificar inspirado por otras
disciplinas de la ingeniera.
Las metodologas ingenieriles han estado presentes durante mucho
tiempo. No se han distinguido precisamente por ser muy exitosas. An menos
por su popularidad. La crtica ms frecuente a estas metodologas es que son
burocrticas. Hay tanto que hacer para seguir la metodologa que el ritmo
entero del desarrollo se retarda.
Como una reaccin a estas metodologas, un nuevo grupo de
metodologas ha surgido en los ltimos aos. Durante algn tiempo se
conocan como metodologas ligeras, pero el trmino aceptado ahora es
metodologas giles. Para mucha gente el encanto de estas metodologas
giles es su reaccin ante la burocracia de las metodologas monumentales.
Estos nuevos mtodos buscan un justo medio entre ningn proceso y
demasiado proceso, proporcionando simplemente suficiente proceso para que
el esfuerzo valga la pena.
El resultado de todo esto es que los mtodos giles cambian
significativamente algunos de los nfasis de los mtodos ingenieriles. La
diferencia inmediata es que son menos orientados al documento, exigiendo una
cantidad ms pequea de documentacin para una tarea dada. De muchas
maneras son ms bien orientados al cdigo: siguiendo un camino que dice que
la parte importante de la documentacin es el cdigo fuente.
Sin embargo, ste no es el punto importante sobre los mtodos giles.
La falta de documentacin es un sntoma de diferencias mucho ms profundas:
Los mtodos giles son adaptables en lugar de predictivos. Los mtodos

ingenieriles tienden a intentar planear una parte grande del proceso del
software en gran detalle para un plazo largo de tiempo, esto funciona
bien hasta que las cosas cambian. As que su naturaleza es resistirse al
cambio. Para los mtodos giles, no obstante, el cambio es bienvenido.
Pgina 1 de 35
Intentan ser procesos que se adaptan y crecen en el cambio, incluso al

punto de cambiarse ellos mismos.
Los mtodos giles son orientados a la gente y no orientados al proceso.

La meta de los mtodos ingenieriles es definir un proceso que
funcionar bien con cualquiera que lo use. Los mtodos giles afirman
que ningn proceso podr nunca maquillar las habilidades del equipo de
desarrollo, de modo que el papel del proceso es apoyar al equipo de
desarrollo en su trabajo. Explcitamente puntualizan el trabajar a favor de
la naturaleza humana en lugar de en su contra y enfatizan que el
desarrollo de software debe ser una actividad agradable.
En las secciones siguientes se vern estas diferencias ms en detalle,

para discernir lo que es un proceso adaptable y centrado en la gente, sus
beneficios y desventajas, y qu se debera usar: sea como desarrollador o
como cliente de software.
Qu es una Metodologa gil?

Las Metodologas giles o ligeras constituyen un nuevo enfoque en el
desarrollo de software, mejor aceptado por los desarrolladores de e-projects
que las metodologas convencionales (ISO-9000, CMM, etc) debido a la
simplicidad de sus reglas y prcticas, su orientacin a equipos de desarrollo de
pequeo tamao, su flexibilidad ante los cambios y su ideologa de
colaboracin [1].
Predictivo versus Adaptable

Separacin de Diseo y Construccin
La inspiracin usual para las metodologas han sido disciplinas como las
ingenieras civil o mecnica. Tales disciplinas enfatizan que hay que planear
antes de construir. Los ingenieros trabajan sobre una serie de esquemas que
indican precisamente qu hay que construir y como deben juntarse estas
cosas. Muchas decisiones de diseo, como la manera de controlar la carga
sobre un puente, se toman conforme los dibujos se producen. Los dibujos se
entregan entonces a un grupo diferente, a menudo una compaa diferente,
para ser construidos. Se supone que el proceso de la construccin seguir los
dibujos. En la prctica los constructores se encuentran con algunos problemas,
pero stos son normalmente poco importantes.
Como los dibujos especifican las piezas y cmo deben unirse, actan
como los fundamentos de un plan de construccin detallado. Dicho plan define
las tareas que necesitan hacerse y las dependencias que existen entre estas
tareas. Esto permite un plan de trabajo y un presupuesto de construccin
razonablemente predecibles. Tambin dice en detalle cmo deben hacer su
trabajo las personas que participan en la construccin. Esto permite que la
Pgina 2 de 35
construccin requiera menos pericia intelectual, aunque se necesita a menudo

mucha habilidad manual.
As que lo que vemos aqu son dos actividades fundamentalmente
diferentes. El diseo, qu es difcil de predecir y requiere personal caro y
creativo, y la construccin que es ms fcil de predecir. Una vez que tenemos
el diseo, podemos planear la construccin. Una vez que tenemos el plan de
construccin, podemos ocuparnos de la construccin de una manera ms
predecible. En ingeniera civil la construccin es mucho ms costosa y tardada
que el diseo y la planeacin.
As el acercamiento de muchas metodologas es: queremos un plan de
trabajo predecible que pueda usar gente del ms bajo nivel. Para hacerlo
debemos separar el plan de la construccin. Por consiguiente necesitamos
entender cmo hacer el diseo de software de modo que la construccin pueda
ser sencilla una vez que el plan est hecho.
Qu forma toma este plan? Para muchos, ste es el papel de
notaciones de diseo como el UML. Si podemos hacer todas las decisiones
significativas usando UML, podemos armar un plan de construccin y entonces
podemos dar planes a los programadores como una actividad de construccin.
Pero aqu surgen preguntas cruciales. Es posible armar un plan que
sea capaz de convertir el cdigo en una actividad de construccin predecible?
Y en tal caso, es la construccin suficientemente grande en costo y tiempo
para hacer valer la pena este enfoque?
Todos esto trae a la mente ms preguntas. La primera es la cuestin de
cun difcil es conseguir un diseo UML en un estado que pueda entregarse a
los programadores. El problema con un diseo tipo UML es que puede parecer
muy bueno en el papel, pero resultar seriamente fallido a la hora de la
programacin. Los modelos que los ingenieros civiles usan est basado en
muchos aos de prctica guardados en cdigos ingenieriles. Adems los
problemas importantes, como el modo en que juegan las fuerzas, son dciles al
anlisis matemtico. La nica verificacin que podemos hacer con los
diagramas UML es la revisin cuidadosa. Mientras esto es til trae errores al
diseo que slo se descubren durante la codificacin y pruebas. Incluso los
diseadores experimentados, se sorprenden a menudo cuando convierten
dichos diseos en software.
Otro problema es el costo comparativo. Cuando se construye un puente,
el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el
resto la construccin. En software la cantidad de tiempo gastada codificando es
mucho, mucho menor. Steve McConnell [2] sugiere que para un proyecto
grande, slo 15% del proyecto son cdigo y pruebas unitarias, una inversin
casi perfecta de las proporciones de la construccin del puente. Aun cuando se
consideren las pruebas parte de la construccin, el plan es todava 50% del
total. Esto genera una pregunta importante sobre la naturaleza del diseo en
software comparado con su papel en otras ramas de la ingeniera.
Pgina 3 de 35
Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho

el cdigo fuente es un documento de diseo y que la fase de construccin est
en realidad en la compilacin y el ligado. De hecho cualquier cosa que pueda
tratarse como construccin puede y debe automatizarse.
Estas ideas llevan a algunas conclusiones importantes:
En software la construccin es tan barata que es casi gratis.
En software todo el esfuerzo est en el diseo, de modo que requiere de

personas creativas y talentosas.
Los procesos creativos no se planean fcilmente, de modo que la

previsibilidad bien puede ser una meta imposible.
Debemos ser muy cautos al usar la metfora de la ingeniera tradicional

para construir software. Es un tipo diferente de actividad y por ende
requiere un proceso diferente.
La Impredecibilidad de los Requisitos

Hay un dicho que se oye en cada proyecto problemtico. Los
desarrolladores vienen y me dicen "el problema con este proyecto es que los
requisitos cambian todo el tiempo". Lo sorprendente de esta situacin es que
sorprenda a cualquiera. En el negocio de construccin de software los cambios
en los requisitos son la norma, la pregunta es qu hacemos al respecto.
Una forma es tratar los requisitos cambiantes como el resultado de una
pobre ingeniera de requisitos. La idea detrs de la ingeniera de requisitos es
conseguir un cuadro totalmente entendido de los requisitos antes de empezar a
construir el software, conseguir la firma del cliente sobre estos requisitos, y
entonces preparar procedimientos que limiten los cambios de requisitos
despus de la firma.
Un problema con esto es que simplemente tratar de entender las
opciones para los requisitos es duro. Es aun ms duro porque la organizacin
del desarrollo normalmente no proporciona la informacin del costo en los
requisitos. El cliente termina solicitando algo que el vendedor no puede cotizar
con exactitud. Sin una buena idea del costo, cmo puede el cliente decidir si
quiere pagar por ese pedido?
La estimacin es difcil por muchas razones. En parte porque el
desarrollo de software es una actividad de diseo, difcil de planear y costear.
En parte porque los materiales bsicos cambian rpidamente. En parte por lo
mucho que depende de los individuos involucrados, y los individuos son
difciles de predecir y cuantificar.
La naturaleza intangible del software tambin afecta. Es muy difcil saber
qu valor aporta un rasgo de software hasta que se usa en realidad. Slo
Pgina 4 de 35
cuando se usa realmente una versin temprana de algn software se empieza

a entender cules rasgos son valiosos y cules no.
Esto lleva al punto irnico de que es de esperarse que los requisitos
sean cambiables. Despus de todo se supone que el software es "suave". As
no slo son cambiables los requisitos, sino que deben de serlo. Toma mucha
energa conseguir que los clientes de software corrijan los requisitos. Es aun
peor si ellos han estado alguna vez en desarrollo de software, porque entonces
"saben" que el software es fcil de cambiar.
Pero aun cuando se pudiera controlar todo esto y realmente se pudiera
conseguir un conjunto exacto y estable de requisitos, probablemente an no
estamos a salvo. En la economa de hoy las fuerzas de negocios
fundamentales cambian el valor de los rasgos de software demasiado
rpidamente. El que podra ser un buen conjunto de requisitos ahora, no ser
tan bueno en seis meses. An cuando el cliente pueda corregir sus requisitos,
el mundo de negocios no va a detenerse por l. Y muchos cambios en el
mundo de negocios son completamente imprevisibles: cualquiera que diga otra
cosa est mintiendo, o ya ha hecho mil millones en la bolsa de valores.
Casi todo en el desarrollo de software depende de los requisitos. Si no
se pueden obtener requisitos estables no se puede obtener un plan predecible.
Es Imposible la Previsibilidad?
En general, no. Hay algunos desarrollos de software dnde la
previsibilidad es posible. Organizaciones como el grupo de software del
trasbordador espacial de la NASA son un ejemplo selecto donde el desarrollo
de software puede ser predecible. Requiere mucha ceremonia, mucho tiempo,
un equipo grande y requisitos estables. Hay proyectos por ah que son
transbordadores espaciales. Sin embargo no creo que el software comercial
encaje en esa categora. Para ste se necesita un tipo diferente de proceso.
Uno de los grandes peligros es pretender que se puede seguir un
proceso predecible cuando no se puede. La gente que trabaja en metodologas
no es buena en identificar condiciones lmite: los lugares donde la metodologa
pasa de apropiada en inapropiada. La mayora de los metodologistas quieren
que sus metodologas sean usadas por todos, de modo que no entienden ni
publican sus condiciones lmite. Esto lleva a la gente a usar una metodologa
en malas circunstancias, como usar una metodologa predictiva en una
situacin imprevisible.
Hay una tentacin fuerte para hacer eso. La previsibilidad es una
propiedad muy deseable. No obstante creer que se puede ser predecible
cuando no se puede, lleva a situaciones en donde las personas construyen un
plan temprano, y entonces no pueden manejar la situacin cuando el plan se
cae en pedazos. Usted acaba viendo el plan y la realidad flotando aparte.
Durante algn tiempo usted podr pretender que el plan es vlido. Pero en
Pgina 5 de 35
algn punto la deriva es demasiada y el plan se cae en pedazos. Normalmente

la cada es dolorosa.
As si usted est en una situacin impredecible no puede usar una
metodologa predictiva. se es un golpe duro. Significa que tantos modelos
para controlar proyectos, y muchos de los modelos para llevar la relacin con el
cliente, ya no son ciertos. Los beneficios de la previsibilidad son tan grandes,
que es difcil dejarlos ir. Como en tantos problemas la parte ms difcil est
simplemente en comprender que el problema existe.
De cualquier modo dejar ir la previsibilidad no significa que hay que
volver al caos ingobernable. Ms bien hace falta un proceso que pueda dar
control sobre la imprevisibilidad. De eso se trata la adaptabilidad.
Controlando un Proceso Imprevisible Iteraciones

As que cmo nos controlamos en un mundo imprevisible? La parte
ms importante y difcil, es saber con precisin dnde estamos. Necesitamos
un mecanismo honesto de retroalimentacin que pueda decirnos con precisin
cul es la situacin a intervalos frecuentes.
La llave para obtener esta retroalimentacin es el desarrollo iterativo.
Esta no es una idea nueva. El desarrollo iterativo ha estado durante algn
tiempo bajo muchos nombres: incremental, evolutivo, escenificado, espiral...
muchos nombres. La clave del desarrollo iterativo es producir frecuentemente
versiones que funcionen del sistema final que tengan un subconjunto de los
rasgos requeridos. stos sistemas son cortos en funcionalidad, pero por otra
parte deben ser fieles a las demandas del sistema final. Deben ser totalmente
integrados y tan cuidadosamente probados como una entrega final.
El punto es que no hay nada como un sistema probado, integrado para
traer una dosis poderosa de realidad en cualquier proyecto. Los documentos
pueden esconder toda clase de fallas. El cdigo no probado puede esconder
bastantes defectos. Pero cuando las personas realmente se sientan delante de
un sistema y trabajan con l, entonces las fallas se vuelven aparentes: tanto las
relativas a defectos como las relativas a los requisitos mal entendidos.
El desarrollo iterativo tambin tiene sentido en los procesos predictivos.
Pero es esencial en los procesos adaptables porque un proceso adaptable
necesita poder tratar con los cambios en los rasgos requeridos. Esto lleva a un
estilo de planear donde los planes a largo plazo son muy fluidos, y los nicos
planes estables son a corto plazo hechos para una sola iteracin. El desarrollo
iterativo da un fundamento firme en cada iteracin que puede usarse para
basar los planes posteriores.
Una pregunta importante es cunto debe durar una iteracin. Diferentes
personas dan respuestas diferentes. XP sugiere iteraciones de entre una y tres
semanas. SCRUM sugiere un mes. Crystal estira aun ms. La tendencia, de
cualquier modo, es hacer cada iteracin tan corta como se pueda manejar.
Pgina 6 de 35
Esto proporciona la retroalimentacin ms frecuente, as que usted sabe ms a

menudo donde se encuentra.
El Cliente Adaptable
Este tipo de proceso adaptable requiere un tipo diferente de relacin con
el cliente que las que se consideran a menudo, particularmente cuando el
desarrollo es hecho por otra empresa. Cuando contrate una empresa separada
para hacer el desarrollo del software, la mayora de los clientes preferirn un
contrato a precio fijo. Dgale a los desarrolladores lo que quieren, negocie,
acepte una oferta, y entonces la carga queda en la empresa de desarrollo para
construir el software.
Un contrato a precio fijo requiere requisitos estables y por tanto procesos
predictivos. Los procesos adaptables y los requisitos inestables implican que no
se puede trabajar con la nocin usual de precio fijo. Tratar de encajar un
modelo de precio fijo a un proceso adaptable acaba en una explosin muy
dolorosa. La parte sucia de esta explosin es que el cliente queda herido tanto
como la compaa de desarrollo de software. Despus de todo el cliente no
querra un software a menos que su negocio lo necesitara. Si no lo consigue su
negocio sufre. As aun cuando no pague nada a la compaa de desarrollo,
todava pierde. De hecho pierde ms de lo que pagara por el software (por
qu habra de pagar el software si el valor comercial de ese software fuera
menor?).
De modo que hay peligro para ambos lados al firmar un contrato a precio
fijo en condiciones donde un proceso predictivo no puede usarse. Esto significa
que el cliente tiene que trabajar de otro modo.
Esto no significa que no se pueda fijar un presupuesto para software por
adelantado. Lo que significa es que no se puede fijar el tiempo, precio y
alcance. La manera gil usual es fijar tiempo y precio y permitir que el alcance
vare de manera controlada.
En un proceso adaptable el cliente tiene mucho control a escala fina
sobre el proceso de desarrollo de software. A cada iteracin puede tanto
verificar el progreso como alterar la direccin del desarrollo de software. Esto
lleva a una relacin mucho ms ntima con los desarrolladores de software, una
verdadera sociedad de trabajo. Este nivel de compromiso no es para cualquier
organizacin cliente, ni para cualquier desarrollador de software; pero es
esencial para lograr que un proceso adaptable funcione apropiadamente.
El beneficio importante para el cliente es un desarrollo de software
mucho ms sensible. Un sistema usable, aunque mnimo, puede entrar en
produccin pronto. El cliente puede cambiar sus capacidades de acuerdo a los
cambios en el negocio, y tambin aprender cmo se usa el sistema en realidad.
Una pieza tan importante como sta es una visibilidad mayor sobre el
verdadero estado del proyecto. El problema con los procesos predictivos es
Pgina 7 de 35
que la calidad del proyecto se mide por la conformidad con el plan. Esto
dificulta a la gente sealar cundo la realidad y el plan divergen. El resultado
comn es un gran resbaln ms tarde en el calendario del proyecto. En un
proyecto gil hay un constante rehacer del plan con cada iteracin. Si las malas
noticias estn al acecho, tienden a aparecer ms temprano, cuando aun se
puede hacer algo al respecto. De hecho este control del riesgo es una ventaja
clave del desarrollo iterativo. Los mtodos giles van ms all manteniendo
corta la duracin de la iteracin, pero tambin viendo estas variaciones como
oportunidades.
Hay un aspecto importante en lo que constituye un proyecto exitoso. Un
proyecto predictivo se mide a menudo por lo bien que coincide con el plan. Un
proyecto que est a tiempo y en costo es un xito. Esta medida no tiene
sentido en un ambiente gil. Para el agilista la cuestin es el valor de negocio
(beneficio) que el cliente consiga, es decir, un software ms valioso que el
costo que puso en l. Un buen proyecto predictivo ir de acuerdo al plan, un
buen proyecto gil construir algo diferente y mejor que lo que se esperaba en
el plan original.
Poniendo a la Gente Primero

No es fcil ejecutar un proceso adaptable. En particular requiere un
equipo muy eficaz de desarrolladores. El equipo necesita ser eficaz tanto en la
calidad de los individuos como en la manera en que funcionan juntos en
equipo. Hay tambin una sinergia interesante: no slo la adaptabilidad requiere
un equipo fuerte, la mayora de los buenos desarrolladores prefieren un
proceso adaptable.
Juntar Unidades de Programacin Compatibles

Uno de los objetivos de las metodologas tradicionales es desarrollar un
proceso donde las personas involucradas sean partes reemplazables. Con tal
proceso se puede tratar a las personas como recursos que estn disponibles
en varios tipos. Se tienen un analista, algunos programadores, algunos
verificadores, un gerente. Los individuos no son tan importantes, slo los roles
lo son. De esa manera si usted planea un proyecto no importa qu analista y
qu verificadores consiga, slo hay que saber cuntos son para saber cmo
afecta su plan el nmero de recursos.
Pero esto plantea una pregunta clave: son las personas involucradas
en el desarrollo de software partes reemplazables? Uno de los rasgos
importantes de los mtodos giles es el rechazo a esta afirmacin.
Quizs el rechazo ms explcito a las personas como recursos lo hace
Alistair Cockburn. En su artculo Caracterizacin de las Personas como
Componentes No Lineales de Primer Orden en el Desarrollo de Software [3],
apunta a que los procesos predecibles requieren componentes que se
Pgina 8 de 35
comporten de manera predecible. Sin embargo las personas no son

componentes predecibles. Adems sus estudios de proyectos de software lo
han llevado a concluir que la gente es el factor ms importante en el desarrollo
de software.
En el ttulo de su artculo se refiere a las personas como "componentes".
As es como se trata a la gente en la literatura de diseo de procesos /
metodologas. El error de este enfoque es que las "personas" son altamente
inconstantes y no lineales, con modos nicos de xito y fracaso. Esos factores
son de primer orden, factores no despreciables. El fracaso de los diseadores
de procesos y metodologas para responder a esto contribuye a la clase de
trayectorias de proyectos no planeados que vemos a menudo.
Uno se pregunta si la naturaleza del desarrollo de software funciona contra uno
aqu. Cuando programamos una computadora, controlamos un dispositivo
inherentemente predecible. Como estamos en este negocio porque somos
buenos en hacerlo, estamos idealmente hechos para perturbarnos cuando nos
enfrentamos con seres humanos.
Aunque Alistair Cockburn es el ms explcito en su visin centrada en la
gente del desarrollo de software, la nocin de que la gente es primero es un
tema comn para muchos pensadores del software. El problema, demasiado a
menudo, es que la metodologa se ha opuesto a la nocin de las personas
como el factor de primer orden en el xito del proyecto.
Esto crea un fuerte efecto de retroalimentacin positiva. Si usted espera
que todos sus desarrolladores se junten en unidades de programacin
compatibles, no intentar tratarlos como individuos. Esto baja la moral (y la
productividad). Las personas capaces se buscarn un lugar mejor donde estar,
y usted acabar con lo que usted deseaba: unidades de programacin
compatibles.
Decidir que las personas son primero es una gran decisin, que requiere
mucha determinacin. La nocin de la gente como recursos es profundamente
inculcado en el pensamiento de negocios, teniendo sus races en el impacto del
enfoque de La Direccin Cientfica de Frederick Taylor. En la administracin de
una fbrica, este enfoque Taylorista tiene sentido. Pero para un trabajo
altamente creativo y profesional, como creo es el desarrollo de software, esto
no se sostiene. (Y de hecho la fabricacin moderna tambin se est saliendo
del modelo Taylorista).
Los Programadores son Profesionales Responsables

Una parte clave de la nocin Taylorista es que la gente que hace el
trabajo no es la mejor gente para entender la mejor manera de hacer el trabajo.
En una fbrica esto puede ser verdad por varias razones. En parte porque la
mayora de los obreros no son las personas ms inteligentes o creativas, en
parte porque hay una tensin entre la gerencia y los obreros en que la gerencia
gana ms dinero y los obreros menos.
Pgina 9 de 35
La historia reciente nos demuestra cada vez ms lo falso que es esto en

el desarrollo de software. A las personas brillantes y capaces les atrae cada
vez ms el desarrollo de software, tanto por su ostentacin como por ganancias
potencialmente mayores. (Ambas razones me tentaron a salir de la ingeniera
electrnica). Cosas tales como opciones accionarias afirman el inters de los
programadores en la compaa.
Aqu bien puede haber un efecto generacional. Una evidencia
anecdtica me hace preguntarme si ms gente brillante se han aventurado en
el desarrollo de software en los ltimos diez aos. En ese caso sta sera una
razn para ese culto a la juventud en el negocio de la computacin, como en la
mayora de los cultos se necesita un grano de verdad en l.
Cuando se quiere contratar y retener a gente capaz, hay que reconocer
que son profesionales competentes. Como tales son los mejores para decidir
cmo dirigir su trabajo tcnico. La nocin Taylorista de un departamento de
planificacin separado que decide cmo hacer las cosas slo funciona si los
planificadores entienden mejor cmo hacer bien el trabajo que aquellos que lo
hacen. Si usted tiene personas brillantes, motivadas que hacen bien el trabajo
entonces eso no se sostiene.
Manejando un Proceso Orientado a la Gente

La orientacin a la gente se manifiesta de varias maneras diferentes en
los procesos giles, lo que lleva a efectos diferentes, no todos consistentes.
Uno de los elementos clave es la aceptacin de un proceso en lugar de
la imposicin de un proceso. A menudo los procesos de software se imponen
desde la gerencia. Como tales se les resiste a menudo, particularmente cuando
la gerencia ha estado fuera del desarrollo activo un buen tiempo. Aceptar un
proceso requiere compromiso, y como tal se necesita el involucramiento activo
de todo el equipo.
Esto termina con el resultado interesante de que slo los desarrolladores
pueden escoger seguir un proceso adaptable. Esto es particularmente cierto
para la XP, que requiere mucha disciplina para ejecutarse. Aqu es donde
Crystal es un complemento efectivo ya que apunta a una disciplina mnima.
Otro punto es que los desarrolladores deben poder tomar todas las
decisiones tcnicas. XP llega al corazn de esto cuando en su proceso de
planeacin establece que slo los desarrolladores pueden estimar cunto
tiempo tomar hacer un trabajo.
Tal liderazgo tcnico es un gran cambio para muchas personas en
posiciones gerenciales. Tal acercamiento requiere compartir una
responsabilidad donde desarrolladores y gerencia tienen un mismo lugar en la
direccin del proyecto. Ntese que dije igual. La gerencia aun juega un papel,
pero reconoce la pericia de los desarrolladores.
Pgina 10 de 35
Una razn importante para esto es el ritmo del cambio de tecnologa en

nuestra industria. Despus de unos aos el conocimiento tcnico se vuelve
obsoleto. Esta vida media de habilidades tcnicas no tiene parangn en
cualquier otra industria. Incluso los tcnicos tienen que reconocer que entrar a
la gerencia significa que sus habilidades tcnicas se marchitarn rpidamente.
Los exdesarrolladores necesitan reconocer que sus habilidades tcnicas
desaparecern rpidamente y necesitan confiar y depender en los
desarrolladores actuales.
La Dificultad de Medir
Si usted tiene un proceso donde las personas que dicen cmo hacer el
trabajo son distintas de las personas que realmente lo hacen, los lderes
necesitan alguna manera de medir cun eficaces son los que lo hacen. En la
Direccin Cientfica haba un impulso fuerte a desarrollar formas objetivas de
medir el rendimiento de las personas.
Esto es particularmente pertinente al software debido a la dificultad de
aplicar medidas al software. A pesar de nuestros mejores esfuerzos somos
incapaces de medir las cosas ms simples sobre el software, como la
productividad. Sin buenas medidas para estas cosas, cualquier clase de control
externo est condenado.
La introduccin de gestin medida sin buenas medidas tiene sus propios
problemas. Robert Austin [4] hizo una discusin excelente sobre esto. l seala
que cuando se mide el rendimiento usted tienen que conseguir todos los
factores importantes bajo medida. Cualquier cosa que se olvide tiene el
resultado inevitable que los hacedores alterarn lo que hacen para producir las
mejores medidas, incluso si eso claramente reduce la verdadera efectividad de
lo que hacen. Este trastorno de la medida es el taln de Aquiles de la gestin
basada en medidas.
La conclusin de Robert Austin es que usted tiene que escoger entre la
gestin basada en mtricas y la gestin delegatoria (donde los hacedores
deciden cmo hacer el trabajo). La gestin basada en mtricas es ms
adecuada para el trabajo simple repetitivo, con bajos requisitos de
conocimiento y rendimientos fcilmente medibles - exactamente lo contrario al
desarrollo de software.
El punto de todo esto es que los mtodos tradicionales han operado bajo
la asuncin de que la gestin basada en mtricas es la manera ms eficaz de
administrar. La comunidad gil reconoce que las caractersticas del desarrollo
de software son tales que la gestin basada en mtricas lleva el trastorno de la
medida a niveles muy altos. Es realmente ms eficaz usar un estilo delegatorio
de administracin, que es el tipo de acercamiento central del punto de vista
agilista.
Pgina 11 de 35
El Papel del Liderazgo de Negocio

Pero los tcnicos no pueden hacer el proceso entero ellos solos.
Necesitan una gua en las necesidades del negocio. Esto lleva a otro aspecto
importante de los procesos adaptables: necesitan un contacto muy ntimo con
los expertos del negocio.
Esto va ms all del compromiso de negocios en la mayora de los
proyectos. Los equipos giles no pueden existir con una comunicacin
ocasional. Necesitan un acceso continuo a los expertos del negocio. Adems
este acceso no es algo que se maneje a nivel gerencial, es algo que est
presente para cada desarrollador. Como los desarrolladores son profesionales
capaces en su propia disciplina, pueden trabajar como iguales con otros
profesionales de otras disciplinas.
Gran parte de esto, claro est, se debe a la naturaleza del desarrollo
adaptable. Como la premisa entera del desarrollo adaptable es que las cosas
cambian rpidamente, se necesita un contacto constante para avisar a todos
de los cambios.
No hay nada ms frustrante para un desarrollador que ver
desperdiciarse su duro trabajo. As que es importante asegurar que hay pericia
de negocios de buena calidad que est disponible al desarrollador y de calidad
suficiente para que el desarrollador pueda confiar en ella.
El Proceso Auto-Adaptable
Hasta ahora he hablado sobre la adaptabilidad en el contexto de un
proyecto adaptando frecuentemente su software para enfrentarse a los
requisitos cambiantes de sus clientes. No obstante hay otro ngulo de la
adaptabilidad: el del proceso que cambia con el tiempo. Un proyecto que
empieza usando un proceso adaptable no tendr el mismo proceso un ao
despus. Con el tiempo, el equipo encontrar lo que funciona mejor para ellos,
y alterar el proceso a su medida.
La primera parte de la auto adaptabilidad son las revisiones regulares
del proceso. Normalmente se hacen con cada iteracin. Al final de cada
iteracin, haga una reunin corta y hgase las siguientes preguntas (escogidas
de Norm Kerth [5])
Qu hicimos bien?
Qu hemos aprendido?
Qu podemos hacer mejor?
Qu es lo que nos confunde?
Pgina 12 de 35
Estas preguntas traern ideas para cambiar el proceso en la siguiente

iteracin. De esta manera un proceso que empieza con problemas puede
mejorar conforme el proyecto avanza, adaptndose mejor al equipo que lo usa.
Si la auto adaptabilidad ocurre dentro de un proyecto, es aun ms
marcada en una organizacin. Para ahondar el proceso de la auto
adaptabilidad sugiero que los equipos hagan una revisin ms formal e hitos
del proyecto mayores siguiendo las sesiones retrospectivas del proyecto
esbozadas por Norm Kerth. Estas retrospectivas involucran reuniones de 2-3
das y un facilitador entrenado. Ellas no solo dan aprendizaje al equipo,
tambin dan aprendizaje a la organizacin entera.
Una consecuencia de la auto adaptabilidad es que nunca se debe
esperar encontrar una metodologa corporativa nica. En cambio cada equipo
debe no simplemente escoger su propio proceso, debe tambin afinar
activamente su proceso conforme avanza el proyecto. Mientras que tanto los
procesos publicados como la experiencia de otros proyectos pueden actuar
como una inspiracin y una lnea de fondo, la responsabilidad profesional de
los desarrolladores es adaptar el proceso a la tarea en mano.
Esta auto adaptabilidad es muy marcada en ASD y Crystal. Las reglas
rgidas de la XP parecen desaprobarla, pero sa es slo una impresin
superficial ya que la XP anima a la gente a afinar el proceso. La diferencia
principal de la XP es que sus promotores sugieren hacer XP al pie de la letra
por varias iteraciones antes de adaptarlo. Adems las revisiones no son
enfatizadas, ni parte del proceso, aunque hay sugerencias de que las
revisiones deberan ser una de las prcticas de la XP.
Las Metodologas giles valoran:

En la Alianza gil [6] establecen como valores de los MA:
1.
Al individuo y las interacciones en el equipo de desarrollo ms que a

las actividades y las herramientas.
2.
Desarrollar software que funciona ms que conseguir una buena

documentacin, implica minimalismo respecto del modelado y la
documentacin del sistema.
3.
La colaboracin con el cliente ms que la negociacin de un contrato.
4.
Responder a los cambios ms que seguir estrictamente una

planificacin.
Pgina 13 de 35
Por qu surgen las Metodologas giles?

En [7] se destacan los siguientes puntos como los principales motivos de
surgimiento de los MA:
1.
Dificultad para implantar metodologas tradicionales. Sofisticadas

herramientas CASE y notaciones (UML)
2.
Una solucin a medida para un segmento importante de proyectos de

desarrollo de software
3.
Pugna entre comunidades / gures
4.
Aceptar el cambio
Costo de los Cambios en la Construccin de SW

De [7] se pudo extraer la Figura 1 que se muestra a continuacin. En la
misma se muestra el costo de producir cambios en el software que se
desarrolla mediante una metodologa tradicional versus el costo de producir
cambios en el software que se desarrolla mediante alguna de las metodologas
giles. Como se puede apreciar, a medida que avanza el tiempo, el costo es
exponencial en el caso de la construccin mediante una metodologa
tradicional.
costo del cambio
metodologa tradicional
suposicin
metodologa gil
tiempo
Figura 1: Funcin de costos de cambio en el software desarrollado
Manifiesto de las Metodologas giles

En un taller de dos das en Snowbird, Utah, en febrero de 2001 se
reunieron los representantes de cada una de las metodologas giles. Haba
Pgina 14 de 35
mucho en comn, y este reconocimiento era mucho mayor que las diferencias
entre los procesos.
Adems de un contacto til entre los lderes de procesos, exista tambin
la idea de emitir una declaracin conjunta en favor de procesos de desarrollo
de software giles.
El resultado es un Manifiesto para el Desarrollo de Software gil [8], una
declaracin de los principios y valores comunes de los procesos giles.
Hay tambin un deseo de colaborar ms en el futuro, para animar ms
tanto a tecnlogos como a gente de negocios para usar y requerir
acercamientos giles al desarrollo de software.
El manifiesto fue slo eso, una publicacin que actu como un punto de
partida para aquellos que compartan estas ideas bsicas. Uno de los frutos del
esfuerzo fue la creacin de un cuerpo ms longevo, la Alianza gil [6]. La
Alianza gil es una organizacin sin fines de lucro que busca promover el
conocimiento y la discusin de todos los mtodos giles. Muchos de los lderes
de metodologas de desarrollo de software giles son miembros y lderes de la
Alianza gil.
Los principios que se establecieron en el manifiesto son:
1.
La prioridad principal es satisfacer al cliente mediante tempranas y

continuas entregas de software que le reporte un valor.
2.
Dar la bienvenida a los cambios. Los MA capturan los cambios para

que el cliente tenga una ventaja competitiva.
3.
Entregar frecuentemente software que funcione, desde un par de

semanas a un par de meses, con el menor intervalo de tiempo
posible entre una entrega y la siguiente.
4.
La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto.
5.
Construir el proyecto entorno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir el
trabajo.
6.
El dilogo cara a cara es el mtodo ms eficiente y efectivo para

comunicar informacin dentro de un equipo de desarrollo.
7.
El software que funciona es la medida principal de progreso.
8.
Los procesos giles promueven un desarrollo sostenible. Los

promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante.
9.
La atencin continua a la calidad tcnica y al buen diseo mejora la

agilidad.
Pgina 15 de 35
10.
La simplicidad es esencial.
11.
Las mejores arquitecturas, requisitos y diseos surgen de los equipos

organizados por s mismos.
12.
En intervalos regulares, el equipo reflexiona respecto de cmo llegar

a ser ms efectivo, y segn esto ajusta su comportamiento.
Comparacin gil - gil

Metodologa gil
Pocos artefactos
Pocos roles
No existe un contrato tradicional o al
menos es bastante flexible
El cliente es parte del equipo de
desarrollo (adems in-situ)
Grupos pequeos (< 10 integrantes) y
trabajando en el mismo sitio
Menos nfasis en la arquitectura
Metodologa No gil (Tradicional)

Ms artefactos
Ms roles
Existe un contrato prefijado
El cliente interacta con el equipo de
desarrollo mediante reuniones
Grupos grandes
La arquitectura es esencial
Principales Metodologas giles

Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org
SCRUM, Ken Schwaber & Jeff Sutherland,
www.controlchaos.com
DSDM (Dynamic Systems Development Method),
www.dsdm.org
Lean Programming, Mary Poppendieck,
www.poppendieck.com
FDD (Feature-Driven Development), Peter Coad & Jeff De Luca,
www.nebulon.com/fdd, www.coad.com/peter/#fdd
Extreme Programming, Kent Beck
www.extremeprogramming.org, www.xprogramming.com
Adaptative Software Development, Jim Highsmith
www.adaptivesd.com
Pgina 16 de 35
Las Metodologas
Varias metodologas encajan bajo el estandarte de gil. Mientras todas
ellas comparten muchas caractersticas, tambin hay algunas diferencias
significativas. No se pueden resaltar todos los puntos en este estudio breve,
pero por lo menos se puede apuntar a algunos lugares donde buscar.
En [9] se puede observar una descripcin introductoria a varias
metodologas giles.
1.
Programacin Extrema (XP)
De todas las metodologas giles, sta es la que ha recibido ms

atencin. Esto se debe en parte a la notable habilidad de los lderes XP, en
particular Kent Beck, para llamar la atencin. Tambin se debe a la habilidad
de Kent Beck de atraer a las personas a este acercamiento, y tomar un papel
principal en l. De algunas maneras, sin embargo, la popularidad de XP se ha
vuelto un problema, pues ha acaparado la atencin fuera de las otras
metodologas y sus valiosas ideas.
Las races de XP yacen en la comunidad de Smalltalk, y en particular la
colaboracin cercana de Kent Beck y Ward Cunningham a finales de los 80.
Ambos refinaron sus prcticas en numerosos proyectos a principios de los 90,
extendiendo sus ideas de un desarrollo de software adaptable y orientado a la
gente.
El paso crucial de la prctica informal a una metodologa ocurri en la
primavera de 1996. A Kent Beck se le pidi revisar el progreso del proyecto de
nmina C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por
una compaa contratista, y estaba en problemas. Debido a la baja calidad de
la base del cdigo, Kent Beck recomend tirar la base del cdigo en su
totalidad y empezar desde el principio. El proyecto entonces reinici bajo su
direccin y subsecuentemente se volvi el buque insignia temprano y el campo
de entrenamiento de XP.
La primera fase del C3 fue muy exitosa y comenz a principios de 1997.
El proyecto continu desde entonces y despus se encontr con dificultades, lo
que result en la cancelacin del desarrollo en 1999. (Lo cual prueba, sin
ninguna otra cosa, que XP no es garanta de xito.)
La metodologa XP empieza con cuatro valores [10]:
Comunicacin,
Retroalimentacin,
Simplicidad, y
Coraje.
Pgina 17 de 35
Construye sobre ellos una docena de prcticas que los proyectos XP

deben seguir. Muchas de estas prcticas son tcnicas antiguas, tratadas y
probadas, aunque a menudo olvidadas por muchos, incluyendo la mayora de
los procesos planeados. Adems de resucitar estas tcnicas, XP las teje en un
todo sinrgico donde cada una refuerza a las dems.
Una de las ms llamativas, as como inicialmente atractiva, es su fuerte
nfasis en las pruebas. Mientras todos los procesos mencionan la
comprobacin, la mayora lo hace con muy poco nfasis. Sin embargo XP pone
la comprobacin como el fundamento del desarrollo, con cada programador
escribiendo pruebas cuando escriben su cdigo de produccin. Las pruebas se
integran en el proceso de integracin continua y construccin lo que rinde una
plataforma altamente estable para el desarrollo futuro.
En esta plataforma XP construye un proceso de diseo evolutivo que se
basa en refactorizar un sistema simple en cada iteracin. Todo el diseo se
centra en la iteracin actual y no se hace nada anticipadamente para
necesidades futuras. El resultado es un proceso de diseo disciplinado, es
ms, combina la disciplina con la adaptabilidad de una manera que
indiscutiblemente la hace la ms desarrollada de entre todas las metodologas
adaptables.
XP ha desarrollado un liderazgo amplio, muchos de ellos provenientes
del proyecto fundamental C3. Como resultado hay muchas fuentes para ms
informacin. Kent Beck escribi Extreme Programming Explained, el
manifiesto clave de XP que explica las razones detrs de la metodologa y es
bastante amplia como para que la gente pueda saber si se interesan en
seguirla. En el ltimo par de aos ha habido una epidemia de libros sobre XP
brillantemente coloreados la mayora de los cuales son bastante similares en
que describen el proceso entero desde el punto de vista de varios seguidores
tempranos.
As como los libros, hay un nmero considerable de recursos en la web.
Para encontrar un acercamiento ms estructurado a XP, es mejor empezar con
dos sitios de ex alumnos del C3: Ron Jeffries [11] y Don Wells [12]. Mucha de
la promocin temprana y desarrollo de ideas de XP ocurrieron en el ambiente
de escritura colaborativa en la pgina wiki de Ward Cunningham [13]. El wiki
sigue siendo un lugar fascinante para descubrir, aunque su naturaleza
divagante lo absorbe a uno. Hay un activo y a menudo interesante Grupo de
Discusin XP [14]. Una de las vistas externas ms interesantes sobre XP es la
de Mark Paulk que es uno de los lderes de la comunidad CMM - su artculo
mira a la XP desde la Perspectiva del CMM [15].
Tambin
hay
otras
referencias,
que
es
tambin
wiki
http://www.programacionextrema.org/ [16] y un Grupo de Discusin en Yahoo
[17].
Pgina 18 de 35
2.
La Familia de Crystal de Cockburn
Alistair Cockburn [18] ha estado trabajando en metodologas desde que

la IBM le encarg escribir sobre metodologas a inicios de los 90. No obstante,
su acercamiento no es como la mayora de los metodologistas. En lugar de
partir solamente de su experiencia personal para construir una teora de cmo
deben hacerse las cosas, l complementa su experiencia directa con la
bsqueda activa de proyectos y ver cmo trabajan. Adems l no teme alterar
sus puntos de vista con base en sus descubrimientos.
Su libro, Sobreviviendo Proyectos Orientados a Objetos [19], fue su
primer consejo en proyectos corrientes, y sigue siendo una primera
recomendacin de libro para ejecutar proyectos iterativos. Ms recientemente
Alistair Cockburn escribi un libro de apreciacin de Desarrollo de Software
gil [20] que mira los principios subyacentes de este tipo de metodologas.
Desde ese libro l ha explorado ms los mtodos giles, viniendo con la
familia de metodologas Cristal [21]. Es una familia porque l cree que los tipos
diferentes de proyectos requieren tipos diferentes de metodologas. l mira
esta variacin a lo largo de dos ejes:
el nmero de personas en el proyecto, y
las consecuencias de los errores.
Cada metodologa encaja en una parte diferente de la reja, de modo que

para un proyecto de 40 personas que puede perder dinero discrecionalmente
tiene una metodologa diferente a la de un proyecto vital de seis personas.
Crystal comparte con XP una orientacin humana, pero esta
centralizacin en la gente se hace de una manera diferente. Alistair Cockburn
considera que las personas encuentran difcil seguir un proceso disciplinado,
as que ms que seguir la alta disciplina de XP, Alistair Cockburn explora la
metodologa menos disciplinada que aun podra tener xito, intercambiando
conscientemente productividad por facilidad de ejecucin. l considera que
aunque Crystal es menos productivo que XP, ms personas sern capaces de
seguirlo.
Alistair Cockburn tambin pone mucho peso en las revisiones al final de
la iteracin, animando al proceso a ser auto mejorante. Su asercin es que el
desarrollo iterativo est para encontrar los problemas temprano, y entonces
permitir corregirlos. Esto pone ms nfasis en la gente supervisando su
proceso y afinndolo conforme desarrollan.
3.
Software de Cdigo Abierto (OSS)
Este ttulo podra sorprender. Despus de todo el cdigo abierto (OS por
su sigla en ingls de Open Source) es un estilo de software, no tanto un
proceso. Sin embargo hay una manera definida de hacer las cosas en la
Pgina 19 de 35
comunidad de cdigo abierto, y mucho de su acercamiento es tan aplicable a

los proyectos de cdigo cerrado como a los de cdigo abierto. En particular su
proceso engrana equipos de trabajo fsicamente distribuidos, lo que es
importante porque la mayora de los procesos adaptables exigen equipos
locales.
La mayora de los proyectos de cdigo abierto tienen uno o ms
mantenedores. Un mantenedor es la nica persona a la que se le permite
integrar un cambio en el almacn de cdigo fuente. Sin embargo otras
personas pueden hacer cambios a la base del cdigo. La diferencia importante
es que estas otras personas necesitan enviar su cambio al mantenedor que
entonces lo revisa y lo aplica a la base del cdigo. Normalmente estos cambios
son hechos en forma de archivos de parches que hacen este proceso ms fcil.
As, el mantenedor es responsable de coordinar los parches y mantener la
cohesin en el diseo del software.
Proyectos diferentes manejan el papel del mantenedor de diferentes
maneras. Algunos tienen un mantenedor para el proyecto entero, algunos lo
dividen en mdulos y tiene un mantenedor por mdulo, algunos rolan el
mantenedor, algunos tienen mltiples mantenedores sobre el mismo cdigo,
otros tienen una combinacin de estas ideas. La mayor parte de la gente de
cdigo abierto son de tiempo parcial, as que hay una duda en qu tan bien se
coordina un equipo as para un proyecto de tiempo completo.
Un rasgo particular del desarrollo de cdigo abierto es que la depuracin
es altamente paralelizable. Muchas personas pueden involucrarse en el
depurado. Cuando encuentran un defecto pueden enviar el parche al
mantenedor. Esto es un buen papel para los no mantenedores ya que la mayor
parte del tiempo se gasta en encontrar bugs. Tambin es bueno para gente sin
mucha destreza en programacin.
El proceso para el cdigo abierto aun no se ha documentado bien. La
referencia ms famosa es el artculo de Eric Raymond La Catedral y el Bazar
[22], que aunque es una descripcin excelente tambin es bastante informal. El
libro de Karl Fogel sobre Desarrollo de Cdigo Abierto con CVS [23], tambin
contiene varios buenos captulos sobre el proceso de cdigo abierto que
incluso seran interesantes para aquellos que no quieren usar el CVS. CVS son
las siglas de Concurrent Versions System (Sistema de Versiones
Concurrentes), un sistema cliente-servidor que permite a los desarrolladores
realizar el seguimiento de las diferentes versiones del cdigo fuente de un
proyecto. Se trata de una herramienta muy potente que facilita:
Registrar todos los cambios efectuados sobre los archivos de un

proyecto.
Recuperar versiones anteriores del cdigo de un proyecto.
Conocer qu cambios se han efectuado sobre un archivo determinado,

quin los ha realizado y cundo.
Pgina 20 de 35
Gestionar los conflictos que pueden producirse en entornos en los que

los desarrolladores se encuentran distribuidos geogrficamente.
El CVS es especialmente til cundo ms de una persona trabaja sobre

un archivo especfico. En tales situaciones, es posible que un desarrollador
sobreescriba accidentalmente los cambios que ha realizado otro desarrollador.
CVS resuelve este problema haciendo que cada desarrollador trabaje sobre su
propia copia del cdigo (lo que se denomina workspace o espacio de trabajo) y
permitiendo posteriormente unir los cambios de todos los desarrolladores en un
repositorio comn [24].
4.
El Desarrollo de Software Adaptable (ASD) de Highsmith
Jim Highsmith [25] ha pasado muchos aos trabajando con

metodologas predictivas. l las desarroll, instal, ense, y concluy que son
profundamente defectuosas: particularmente para los negocios modernos.
Su reciente libro Adaptive Software Development [26] se enfoca en la
naturaleza adaptable de las nuevas metodologas, con un nfasis particular en
aplicar las ideas que se originaron en el mundo de los sistemas complejos
adaptables (normalmente conocida como teora del caos). No proporciona el
tipo de prcticas detalladas como lo hace XP, pero proporciona la base
fundamental de por qu el desarrollo adaptable es importante y las
consecuencias a los ms profundos niveles de la organizacin y la gerencia.
En el corazn del ASD hay tres fases solapadas, no lineales:
especulacin, colaboracin, y aprendizaje.
Jim Highsmith ve la planificacin como una paradoja en un ambiente
adaptable, ya que los resultados son naturalmente imprevisibles. En la
planificacin tradicional, las desviaciones del plan son errores que deben
corregirse. En un ambiente adaptable, en cambio, las desviaciones nos guan
hacia la solucin correcta.
En este ambiente imprevisible se necesita que las personas colaboren
de la mejor manera para tratar con la incertidumbre. La atencin de la gerencia
es menor en lo que tiene que hacer la gente, y mayor sobre la comunicacin
alentadora para que las personas puedan proponer las respuestas creativas
ellos mismos.
En ambientes predictivos, el aprendizaje se desalienta a menudo. Las
cosas se ponen de antemano y entonces se sigue ese diseo.
En un ambiente adaptable, aprender desafa a todos - desarrolladores y
sus clientes - a examinar sus presunciones y usar los resultados de cada ciclo
de desarrollo para adaptar el siguiente. El aprendizaje como tal es un rasgo
continuo e importante, que asume que los planes y los diseos deben cambiar
conforme avanza el desarrollo.
Pgina 21 de 35
El beneficio atropellado, poderoso, indivisible y predominante del Ciclo

de Vida de Desarrollo Adaptable es que obliga a confrontar los modelos
mentales que estn en la raz del autoengao de las personas. Obliga a las
personas a estimar con realismo su habilidad. Con este nfasis, el trabajo de
Jim Highsmith se enfoca directamente en fomentar las partes difciles del
desarrollo adaptable, en particular cmo fomentar la colaboracin y el
aprendizaje dentro del proyecto. Como tal, su libro ayuda a dar ideas para
fomentar estas reas "suaves" que hacen un buen complemento a los
acercamientos basados en una prctica aterrizada como XP, FDD y Crystal.
5.
Scrum
Scrum se enfoca en el hecho de que procesos definidos y repetibles slo

funcionan para atacar problemas definidos y repetibles con gente definida y
repetible en ambientes definidos y repetibles.
Scrum divide un proyecto en iteraciones (que ellos llaman carreras
cortas) de 30 das. Antes de que comience una carrera se define la
funcionalidad requerida para esa carrera y entonces se deja al equipo para que
la entregue. El punto es estabilizar los requisitos durante la carrera.
Sin embargo la gerencia no se desentiende durante la carrera corta.
Todos los das el equipo sostiene una reunin corta (quince minutos), llamada
scrum, dnde el equipo discurre lo que har al da siguiente. En particular
muestran a los bloques de la gerencia: los impedimentos para progresar que se
atraviesan y que la gerencia debe resolver. Tambin informan lo que se ha
hecho para que la gerencia tenga una actualizacin diaria de dnde va el
proyecto.
La literatura de Scrum se enfoca principalmente en la planeacin
iterativa y el seguimiento del proceso. Es muy cercana a las otras metodologas
giles en muchos aspectos y debe funcionar bien con las prcticas de cdigo
de XP.
Despus de mucho tiempo sin un libro, finalmente Ken Schwaber y Mike
Beedle escribieron el primer libro de Scrum que lo llamaron Agile Software
Development with Scrum [27]. Probablemente la mejor apreciacin global
sobre SCRUM est en el sitio http://www.controlchaos.com [28] de Ken
Schwaber. Jeff Sutherland siempre ha tenido un sitio web activo sobre temas
de tecnologas de objetos e incluye una seccin sobre Scrum [29]. Hay tambin
una buena apreciacin global de las prcticas de Scrum en el libro de Neil
Harrison, Brian Foote, Hans Rohnert titulado Pattern Languages of Program
Design 4 (Software Patterns Series) [30]. Scrum tiene una lista de discusin en
Yahoo en la URL http://groups.yahoo.com/group/scrumdevelopment [31].
Pgina 22 de 35
6.
Desarrollo Manejado por Rasgos (FDD)
El Desarrollo Manejado por Rasgos (FDD por su sigla en ingls de

Feature-Driven Development) fue desarrollado por Jeff De Luca y el viejo gur
de la Orientacin a Objetos Peter Coad. Como las otras metodologas
adaptables, se enfoca en iteraciones cortas que entregan funcionalidad
tangible. En el caso del FDD las iteraciones duran dos semanas.
El FDD tiene cinco procesos. Los primeros tres se hacen al principio del
proyecto.
Desarrollar un Modelo Global
Construir una Lista de los Rasgos
Planear por Rasgo
Disear por Rasgo
Construir por Rasgo
Los ltimos dos se hacen en cada iteracin. Cada proceso se divide en

tareas y se da un criterio de comprobacin.
Los desarrolladores entran en dos tipos:
dueos de clases, y
programadores jefe.
Los programadores jefe son los desarrolladores ms experimentados. A

ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen
solos. Slo identifican qu clases se involucran en la implantacin de un rasgo
y juntan a los dueos de dichas clases para que formen un equipo para
desarrollar ese rasgo. El programador jefe acta como el coordinador,
diseador lder y mentor, mientras los dueos de clases hacen gran parte de la
codificacin del rasgo.
Hasta recientemente, la documentacin sobre FDD era muy escasa.
Finalmente hay un libro completo sobre FDD titulado A Practical Guide to
Feature-Driven Development (The Coad Series) de la autora de Stephen R
Palmer y John M. Felsing [32]. Jeff De Luca, el inventor primario, ya tiene un
portal FDD en la URL http://www.featuredrivendevelopment.com [33], con
artculos, blogs y foros de discusin. La descripcin original estaba en el libro
Java Modeling In Color With UML de Peter Coad et al [34]. Su compaa,
TogetherSoft [35], tambin da consultora y entrenamiento en FDD.
Pgina 23 de 35
7.
DSDM (Mtodo de Desarrollo de Sistema Dinmico)
El DSDM (Dynamic Systems Development Method) [36] empez en

Gran Bretaa en 1994 como un consorcio de compaas del Reino Unido que
queran construir sobre RAD (Rapid Applications Development) Desarrollo
Rpido de Aplicaciones y desarrollo iterativo. Habiendo empezado con 17
fundadores ahora tiene ms de mil miembros y ha crecido fuera de sus races
britnicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a
muchos de los otros mtodos giles. Tiene una organizacin de tiempo
completo que lo apoya con manuales, cursos de entrenamiento, programas de
certificacin y dems. Pero, tambin lleva una etiqueta de precio, lo cual ha
limitado la investigacin popular sobre su metodologa. Sin embargo, Jennifer
Stapleton ha escrito el libro DSDM [37] que da una apreciacin global de la
metodologa.
El mtodo empieza con un estudio de viabilidad y negocio. El estudio de
viabilidad considera si DSDM es apropiado para el proyecto. El estudio de
negocio es una serie corta de talleres para entender el rea de negocio donde
tiene lugar el desarrollo. Tambin propone esbozos de arquitecturas del
sistema y un plan del proyecto.
El resto del proceso forma tres ciclos entretejidos:
el ciclo del modelo funcional produce documentacin de anlisis y

prototipos,
el ciclo de diseo del modelo disea el sistema para uso operacional, y
el ciclo de implantacin se ocupa del despliegue al uso operacional.
DSDM tiene principios subyacentes que incluyen una interaccin activa

del usuario, entregas frecuentes, equipos autorizados, pruebas a lo largo del
ciclo. Igual que otros mtodos giles, usan ciclos de plazos cortos de entre dos
y seis semanas. Hay un nfasis en la alta calidad y adaptabilidad hacia
requisitos cambiantes.
No hay mucha evidencia de su uso fuera del Reino Unido, pero DSDM
es notable por tener mucha de la infraestructura de las metodologas
tradicionales ms maduras, al mismo tiempo que sigue los principios de los
mtodos giles.
8.
Es RUP un mtodo gil?
Siempre que se discuten mtodos OO, inevitablemente se llega a

Rational Unified Process [38]. El Proceso Unificado fue desarrollado como el
proceso complementario al UML. El RUP es un armazn de proceso y como tal
puede acomodar una gran variedad de procesos. De hecho sta es la crtica
principal al RUP por parte de algunos autores: como puede ser cualquier cosa
Pgina 24 de 35
acaba siendo nada. Prefieren un proceso que diga qu hacer en lugar de dar
opciones infinitas.
Como resultado de esta mentalidad de armazn de procesos, el RUP
puede usarse en un estilo muy tradicional de cascada o de una manera gil.
Como resultado se puede usar el RUP como un proceso gil, o como un
proceso pesado - todo depende de cmo lo adapte a su ambiente.
Craig Larman es un fuerte defensor de usar el RUP de una manera gil.
Su libro Applying UML and Patterns [39] sobre desarrollo OO contiene un
proceso que est muy basado en su pensamiento ligero del RUP. Su visin es
que mucho del reciente empujn hacia los mtodos giles no es nada ms que
aceptar desarrollo OO de la corriente principal que ha sido capturada como
RUP. Una de las cosas que hace Craig Larman es pasarse los primeros dos o
tres das de una iteracin mensual con todo el equipo usando el UML para
perfilar el diseo del trabajo a hacerse durante la iteracin. Esto no es una
norma de la que no pueda desviarse, sino un boceto que da una perspectiva
sobre cmo pueden hacerse las cosas en la iteracin.
Otra punta en el RUP gil es el proceso dX de Robert Martin [40]. El
proceso dX es una versin totalmente dcil del RUP que simplemente es
idntico a XP (girar dX ciento ochenta grados para ver la broma). El dX est
diseado para gente que tiene que usar el RUP pero quiere usar XP. Como tal
es a la vez XP y RUP y por tanto un buen ejemplo del uso gil del RUP.
Segn los crticos, una de las cosas claves que necesita el RUP es que
los lderes del RUP en la industria enfaticen su acercamiento al desarrollo de
software. Ms de una vez se oye a la gente que usa el RUP hablando que
estn usando un proceso de desarrollo estilo cascada. Philippe Kruchten y su
equipo son firmes creyentes en el desarrollo iterativo. Clarificando estos
principios y animando las versiones giles del RUP tales como los trabajos de
Craig Larman y de Robert Martin tendr un efecto importante.
9.
Lean Development (LD) y Lean Software Development (LSD)
Lean Development (LD) es el mtodo menos divulgado entre los

reconocidamente importantes. La palabra lean significa magro, enjuto; en su
sentido tcnico apareci por primera vez en 1990 en el libro de James Womack
La Mquina que Cambi al Mundo [41]. LD, iniciado por Bob Charette [42], se
inspira en el xito del proceso industrial Lean Manufacturing, bien conocido en
la produccin automotriz y en manufactura desde la dcada de 1980. Este
proceso tiene como precepto la eliminacin de residuos a travs de la mejora
constante, haciendo que el producto fluya a instancias del cliente para hacerlo
lo ms perfecto posible. Los presentes conceptos han sido extrados de Carlos
Reynoso [43].
Los procesos a la manera americana corran con sus mquinas al 100%
de capacidad y mantenan inventarios gigantescos de productos y suministros;
Toyota, en contra de la intuicin, resultaba ms eficiente manteniendo
Pgina 25 de 35
suministros en planta para un solo da, y produciendo slo lo necesario para

cubrir las rdenes pendientes. Esto es lo que se llama Just in Time Production.
Con JIT se evita adems que el inventario degrade o se torne obsoleto, o
empiece a actuar como un freno para el cambio. Toyota implementaba adems
las tcnicas innovadoras del Total Quality Management de Edward Deming,
que slo algunos matemticos y empresarios de avanzada conocan en
Estados Unidos. Hasta el da de hoy la foto de Deming en Toyota es ms
grande y esplendorosa que la del fundador, Toyoda Sakichi.
Otros aspectos esenciales de Lean Manufacturing son la relacin
participativa con el empleado y el trato que le brinda la compaa, as como una
especificacin de principios, disciplinas y mtodos iterativos, adaptativos, autoorganizativos e interdependientes en un patrn de ciclos de corta duracin que
tiene algo ms que un aire de familia con el patrn de procesos de los Mtodos
giles. Existe unanimidad de intereses, consistencia de discurso y
complementariedad entre las comunidades Lean de manufactura y desarrollo
de software.
Mientras que otros MA se concentran en el proceso de desarrollo, Bob
Charette sostena que para ser verdaderamente gil se deba conocer adems
el negocio de punta a punta. LD se inspira en doce valores centrados en
estrategias de gestin [44]:
1.
Satisfacer al cliente es la mxima prioridad.
2.
Proporcionar siempre el mejor valor por la inversin.
3.
El xito depende de la activa participacin del cliente.
4.
Cada proyecto LD es un esfuerzo de equipo.
5.
Todo se puede cambiar.
6.
Soluciones de dominio, no puntos.
7.
Completar, no construir.
8.
Una solucin al 80% hoy, en vez de una al 100% maana.
9.
El minimalismo es esencial.
10.
La necesidad determina la tecnologa.
11.
El crecimiento del producto es el incremento de sus prestaciones, no

de su tamao.
12.
Nunca empujes LD ms all de sus lmites.
Dado que LD es ms una filosofa de management que un proceso de

desarrollo no hay mucho que decir del tamao del equipo, la duracin de las
iteraciones, los roles o la naturaleza de sus etapas. ltimamente LD ha
Pgina 26 de 35
evolucionado como Lean Software Development (LSD); su figura de referencia

es Mary Poppendieck [45].
Igual que Agile Modeling (AM), que cubra sobre todo aspectos de
modelado y documentacin, LD y LSD han sido pensados como complemento
de otros mtodos, y no como una metodologa excluyente a implementar en la
empresa. LD prefiere concentrarse en las premisas y modelos derivados de
Lean Production, que hoy constituyen lo que se conoce como el canon de la
Escuela de Negocios de Harvard. Para las tcnicas concretas de
programacin, LD promueve el uso de otros MA que sean consistentes con su
visin, como XP o sobre todo Scrum.
Aunque la formulacin del mtodo es relativamente reciente, la
familiaridad de muchas empresas con los principios de Lean Production & Lean
Manufacturing ha facilitado la penetracin en el mercado de su anlogo en
ingeniera de software.
10.
Agile Modeling
Agile Modeling (AM) fue propuesto por Scott Ambler [46] no tanto como
un mtodo gil cerrado en s mismo, sino como complemento de otras
metodologas, sean stas giles o convencionales. En el caso de XP los
practicantes podran definir mejor los procesos de modelado que en ellos
faltan, y en el caso de RUP el modelado gil permite hacer ms ligeros los
procesos que ya usan. AM es una estrategia de modelado (de clases, de datos,
de procesos) pensada para contrarrestar la sospecha de que los mtodos
giles no modelan y no documentan. Se lo podra definir como un proceso de
software basado en prcticas cuyo objetivo es orientar el modelado de una
manera efectiva y gil.
Los principales objetivos de AM son:
1.
Definir y mostrar de qu manera se debe poner en prctica una

coleccin de valores, principios y prcticas que conducen al
modelado de peso ligero.
2.
Enfrentar el problema de la aplicacin de tcnicas de modelado en

procesos de desarrollo giles.
3.
Enfrentar el problema de la aplicacin de las tcnicas de modelado

independientemente del proceso de software que se utilice.
Los valores de AM incluyen a los de XP: comunicacin, simplicidad,

feedback y coraje, aadiendo humildad. Una de las mejores caracterizaciones
de los principios subyacentes a AM est en la definicin de sus alcances:
1.
AM es una actitud, no un proceso prescriptivo. Comprende una

coleccin de valores a los que los modeladores giles adhieren,
Pgina 27 de 35
principios en los que creen y prcticas que aplican. Describe un estilo

de modelado; no es un recetario de cocina.
2.
AM es suplemento de otros mtodos. El primer foco es el modelado y

el segundo la documentacin.
3.
AM es una tarea de conjunto de los participantes. No hay yo en AM.
4.
La prioridad es la efectividad. AM ayuda a crear un modelo o proceso

cuando se tiene un propsito claro y se comprenden las necesidades
de la audiencia; contribuye a aplicar los artefactos correctos para
afrontar la situacin inmediata y a crear los modelos ms simples que
sea posible.
5.
AM es algo que funciona en la prctica, no una teora acadmica. Las

prcticas han sido discutidas desde 2001 en comunidad
(http://www.agilemodeling.com/feedback.htm).
6.
AM no es una bala de plata.
7.
AM es para el programador promedio, pero no reemplaza a la gente

competente.
8.
AM no es un ataque a la documentacin. La documentacin debe ser

mnima y relevante.
9.
AM no es un ataque a las herramientas CASE.
10.
AM no es para cualquiera.
Los principios de AM especificados por Scott Ambler incluyen:

1.
Presuponer simplicidad. La solucin ms simple es la mejor.
2.
El contenido es ms importante que la representacin. Pueden

ser notas, pizarras o documentos formales. Lo que importa no es el
soporte fsico o la tcnica de representacin, sino el contenido.
3.
Abrazar el cambio. Aceptar que los requerimientos cambian.
4.
Habilitar el esfuerzo siguiente. Garantizar que el sistema es

suficientemente robusto para admitir mejoras ulteriores; debe ser un
objetivo, pero no el primordial.
5.
Todo el mundo puede aprender de algn otro. Reconocer que

nunca se domina realmente algo.
6.
Cambio incremental. No esperar hacerlo bien la primera vez.
7.
Conocer tus modelos. Saber cules son sus fuerzas y sus

debilidades.
Pgina 28 de 35
8.
Adaptacin local. Producir slo el modelo que resulte suficiente

para el propsito.
9.
Maximizar la inversin del cliente.
10.
Modelar con un propsito. Si no se puede identificar para qu se

est haciendo algo para qu molestarse?
11.
Modelos mltiples. Mltiples paradigmas en convivencia, segn se

requiera.
12.
Comunicacin abierta y honesta.
13.
Trabajo de calidad.
14.
Realimentacin rpida. No esperar que sea demasiado tarde.
15.
El software es el objetivo primario. Debe ser de alta calidad y

coincidir con lo que el usuario espera.
16.
Viajar ligero de equipaje. No crear ms modelos de los necesarios.
17.
Trabajar con los instintos de la gente.
Lo ms concreto de AM es su rico conjunto de prcticas [47], cada una

de las cuales se asocia a lineamientos decididamente narrativos, articulados
con minuciosidad, pero muy lejos de los rigores cuantitativos:
1.
Colaboracin activa de los participantes.
2.
Aplicacin de estndares de modelado.
3.
Aplicacin adecuada de patrones de modelado.
4.
Aplicacin de los artefactos correctos.
5.
Propiedad colectiva de todos los elementos.
6.
Considerar la verificabilidad.
7.
Crear diversos modelos en paralelo.
8.
Crear contenido simple.
9.
Disear modelos de manera simple.
10.
Descartar los modelos temporarios.
11.
Exhibir pblicamente los modelos.
12.
Formalizar modelos de contrato.
Pgina 29 de 35
13.
Iterar sobre otro artefacto.
14.
Modelo en incrementos pequeos.
15.
Modelar para comunicar.
16.
Modelar para comprender.
17.
Modelar con otros.
18.
Poner a prueba con cdigo.
19.
Reutilizar los recursos existentes.
20.
Actualizar slo cuando duele.
21.
Utilizar las herramientas ms simples (CASE, o mejor pizarras,

tarjetas, post-its).
Como AM se debe usar como complemento de otras metodologas, nada

se especifica sobre mtodos de desarrollo, tamao del equipo, roles, duracin
de iteraciones, trabajo distribuido y criticidad, todo lo cual depender del
mtodo que se utilice.
Los diagramas de UML y los artefactos del Proceso Unificado, por
ejemplo, han sido explorados en extremo detalle describiendo cmo debera
ser su tratamiento en un proceso gil EUP. EUP es simplemente UP+AM.
11.
Pragmatic Programming (PP)
El ttulo en realidad no es totalmente cierto, ya que no hay un mtodo

llamado programacin pragmtica, sino que existe un conjunto muy interesante
de las mejores prcticas de programacin publicadas en el libro The Pragmatic
Programmer [48], pero por practicidad se lo llama Programacin Pragmtica
[49].
La PP no tiene proceso, fases, roles distintos productos de trabajo.
Este MA cubre, sin embargo, la mayora de las mejores prcticas de
programacin. Hay un total de 70 recomendaciones que se enfocan en los
problemas del da a da, pero la filosofa por detrs de esto es que son
universales y pueden ser aplicadas a cualquier fase del desarrollo de software.
La filosofa est definida en 6 puntos:
1.
Tome las responsabilidades para Ud., piense en soluciones en lugar

de estar pensando en excusas.
2.
No disee o codifique mal, arregle las inconsistencias o planee

arreglarlas tan pronto como sea posible.
Pgina 30 de 35
3.
Tome un rol activo para introducir cambios donde Ud. vea que son
necesarios.
4.
Haga software que satisfaga a su cliente, pero sepa cundo parar.
5.
Constantemente ample su conocimiento.
6.
Mejore sus habilidades de comunicacin.
Desde un punto de vista gil, la mayora de las prcticas ms

interesantes se enfocan sobre el desarrollo iterativo, incremental, testing
riguroso y diseo centrado en el usuario. El enfoque tiene un punto de vista
muy prctico, y la mayora de las prcticas son ilustradas con ejemplos
positivos y negativos, a menudo complementados con preguntas y trocitos de
cdigo. Es un esfuerzo considerable explicar cmo disear e implementar
software tal que pueda resistir cambios. Una de las soluciones que se plantean
para mantener software a travs de los cambios es la refactorizacin.
El enfoque de la Programacin Pragmtica respecto del testing consiste
en testear el cdigo que est siendo implementado sobre el cdigo real, y todos
los testeos deben ser hechos en forma automtica. La idea es que si cada bug
corregido no es agregado dentro de la biblioteca del test y si los tests de
regresin no se corren peridicamente, el tiempo y el esfuerzo se gastan en
encontrar los mismos bugs repetidamente, y los efectos adversos de cambios
en el cdigo no pueden detectarse suficientemente temprano.
La automatizacin se encuentra en la PP en algunas otras tareas
tambin. De hecho llega a sugerir No use procedimientos manuales. Por
ejemplo, en la creacin de la primera documentacin de cdigo fuente y en la
creacin de cdigo de las definiciones de la base de datos.
Recomienda conservar las especificaciones a un nivel razonable de
detalle. La PP demuestra prcticas de software simples, responsables y
disciplinadas. La prcticas sugeridas en PP son escritas desde el punto de
vista de un programador, independientemente de los mtodos o procesos que
se utilicen, para evitar errores tpicos en la codificacin y en el diseo y errores
de comunicacin en el grupo de trabajo.
Testing Dirigido por el Contexto

Desde el principio han sido los desarrolladores de software quienes han
conducido a la comunidad gil. Sin embargo muchas otras personas envueltas
en el desarrollo de software son afectadas por este nuevo movimiento. Un
grupo obvio es el de los verificadores, que a menudo viven en un mundo
dominado por el pensamiento de cascada. Con pautas comunes que declaran
que el papel del testing es asegurar la conformidad del software con las
especificaciones escritas de antemano, el papel de los verificadores en el
mundo gil est lejos de ser claro.
Pgina 31 de 35
Varias personas en la comunidad de verificadores han estado

cuestionando mucho la corriente principal del pensamiento en testing desde
hace un tiempo.
Esto ha llevado a formar un grupo conocido como testing conducido por
el contexto. La mejor descripcin es el libro Lessons Learned in Software
Testing, cuyos autores son Cem Kaner, James Bach y Bret Pettichord [50].
La comunidad de testing de software es tambin muy activa, teniendo
sus sitios en la web Brian Marick [51] (uno de los autores del manifiesto gil),
Bret Pettichord [52], James Bach [53] y Cem Kaner [54].
Debe usted ir a lo gil?

Los prrafos siguientes son extractados de [9].
El uso de un mtodo gil no es para todos. Hay que tener en cuenta
varias cosas si se decide a seguir por este camino. Sin embargo yo creo
ciertamente que estas nuevas metodologas son extensamente aplicables y
deben ser usadas por ms personas de las que actualmente lo consideran.
En el ambiente actual, la metodologa ms comn es codifica y corrige.
Aplicar ms disciplina que caos casi seguramente ayudar, y el acercamiento
gil tiene la ventaja de que es mucho menos de un paso que un mtodo
pesado. Mucha de la ventaja de los mtodos giles es de hecho su peso ligero.
Los procesos ms simples son ms probables de ser seguidos cuando uno no
est acostumbrado a ningn proceso en absoluto.
Una de las limitaciones ms grandes de estas nuevas metodologas es
cmo manejan equipos ms grandes. Como muchas nuevas tendencias, ellos
tienden a ser usados primero a escala pequea antes que a gran escala.
Tambin a menudo se han creado con nfasis en equipos pequeos. La XP
explcitamente dice que est diseada para equipos de no ms de veinte
personas. Hay que recordar que muchos equipos de software pueden reducirse
en tamao sin reducir su productividad total.
Otras tendencias giles estn destinadas a equipos ms grandes. La
FDD fue diseada originalmente para un proyecto de cincuenta personas.
ThoughtWorks ha usado proyectos influidos por la XP con equipos de cerca de
100 en tres continentes. Scrum se ha usado para manejar tamaos similares.
Esperanzadoramente un mensaje que queda claro en este artculo es
que los acercamientos adaptables son buenos cuando sus requisitos son
inciertos o voltiles. Si usted no tiene requisitos estables, entonces no est en
la posicin tener un plan estable y seguir un proceso planeado. En stas
situaciones un proceso adaptable puede ser menos cmodo, pero ser ms
eficaz. A menudo la barrera ms grande aqu es el cliente. Como yo lo veo es
importante para el cliente entender que seguir un proceso predictivo cuando los
requisitos cambian es arriesgado tanto para ellos como para el desarrollo.
Pgina 32 de 35
Si usted va a tomar la ruta adaptable, necesita confiar en sus

desarrolladores e involucrarlos en la decisin. Los procesos adaptables
cuentan en que usted confa en sus desarrolladores, de modo que si usted
considera a sus desarrolladores de baja calidad y motivacin, usted debe usar
un acercamiento predictivo.
Para resumir. Los siguientes factores sugieren un proceso adaptable
Requisitos inciertos o voltiles
Desarrolladores responsables y motivados
Clientes que entienden y se involucrarn.
Estos factores sugieren un proceso predictivo
Un equipo de ms de cien
Un precio fijo, o ms correctamente un alcance o contrato fijo
Referencias
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
Elisa Gallo, Mikel Vergara, European Software Institute,

http://www.esi.es/Berrikuntza
Steve McConnell, Rapid Development,
http://www.amazon.com/exec/obidos/ASIN/1556159005/programacione20
Alistair Cockburn, Characterizing People as Non-Linear, First-Order
Components in Software Development,
http://alistair.cockburn.us/crystal/articles/cpanfocisd/characterizingpeople
asnonlinear.html
Robert D. Austin, Measuring and Managing Performance in
Organizations,
http://www.amazon.com/exec/obidos/ASIN/0932633366/104-71178427901533/programacione-20/102-4687883-9528948
Norman L. Kerth, http://c2.com/ppr/about/author/norm.html
Alianza gil, http://www.agilealliance.org
Patricio Letelier, Departamento de Sistemas Informticos y Computacin,
Universidad Politcnica de Valencia, letelier@dsic.upv.es
Manifiesto para el Desarrollo de Software gil,
http://www.agilemanifesto.org
Martn Fowler, La Nueva Metodologa, http://www.programacion.net
Kent Beck, Extreme Programming Explained,
Pgina 33 de 35
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
Ron Jeffries http://www.xProgramming.com

Don Wells http://www.extremeProgramming.org
Ward Cunningham, pgina wiki,
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Grupo de Discusin XP,
http://www.egroups.com/group/extremeprogramming
Mark Paulk, XP desde la Perspectiva del CMM,
http://www.sei.cmu.edu/cmm/papers/xp-cmm-paper.pdf
http://www.programacionextrema.org
Grupo de Discusin en Yahoo, http://groups.yahoo.com/group/xpspanish
Alistair Cockburn, http://members.aol.com/acockburn
Alistair Cockburn, Sobreviviendo Proyectos Orientados a Objetos,
Alistair, Desarrollo de Software gil,
Crystal, http://members.aol.com/acockburn/
Raymond La Catedral y el Bazar, http://es.tldp.org/Otros/catedralbazar/cathedral-es-paper-00.html
Karl Fogel, Desarrollo de Cdigo Abierto con CVS,
Fundacin Sidar, http://www.sidar.org/recur/desdi/cvs
Jim Highsmith, http://www.adaptivesd.com
Jim Highsmith, Adaptive Software Development,
Ken Schwaber y Mike Beedle, Agile Software Development with Scrum,
Ken Schwaber, http://www.controlchaos.com
Jeff Sutherland, http://jeffsutherland.com/scrum/index.html
Neil Harrison, Brian Foote, Hans Rohnert Pattern Languages of Program
Design 4 (Software Patterns Series) ,
Scrum, http://groups.yahoo.com/group/scrumdevelopment.
Stephen R Palmer, John M. Felsing, A Practical Guide to Feature-Driven
Development (The Coad Series),
Jeff De Luca, FDD, http://www.featuredrivendevelopment.com
Peter Coad, Java Modeling In Color With UML,
http://www.amazon.com/exec/obidos/ASIN/013011510X/programacione20/102-4687883-9528948
TogetherSoft, http://www.togethersoft.com
DSDM, http://www.dsdm.org
Pgina 34 de 35
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
Jennifer Stapleton, DSDM,

Philippe Kruchten, The Rational Unified Process,
http://www.amazon.com/exec/obidos/ASIN/0201707101/programacione20/102-4687883-9528948
Craig Larman, Applying UML and Patterns,
http://www.amazon.com/exec/obidos/ASIN/0137488807/programacione20/102-4687883-9528948
Robert Martin,
http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
James Womack, Daniel Jones y Daniel Roos, The machine that
changed the world: The story of Lean Production, HarperBusiness,
1991.
Robert Charette, The Foundation Series on Risk Management, Volume II:
Foundations of Lean Development, Cutter Consortium, Arlington, 2001
Carlos Reynoso, Mtodos Heterodoxos en Desarrollo de Software,
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/hetero
dox.asp
Jim Highsmith, Agile Software Development Ecosystems, Boston,
Addison Wesley, 2002.
Mary Poppendieck, Lean Programming,
http://www.agilealliance.org/articles/articles/LeanProgramming.htm, 2001.
Scott Ambler, Agile Modeling: Effective practices for Extreme
Programming and the Unified Process, John Wiley & Sons, 2002.
Scott Ambler, Agile Modeling and the Unified Process,
http://www.agilemodeling.com/essays/agileModelingRUP.htm, 2002.
Andrew Hunt, David Thomas, The Pragmatic Programmer: From
Journeyman to Master,
http://allconsuming.net/item.cgi?isbn=020161622X
Pekka Abrahamsson, Outi Salo, Jussi Ronkainen & Juhani Warsta, Agile
Software Development Methods: Review and Analysis, VTT, 2002
Cem Kaner, James Bach, Bret Pettichord, Lessons Learned in Software
Testing, http://www.amazon.com/exec/obidos/ASIN/0471081124/1047117842-7901533/programacione-20
Brian Marick, Testing Foundations, http://www.testing.com
Bret Pettichord, http://pettichord.com
James Bach, Satisfice, Inc. http://www.satisfice.com
Cem Kaner J.D., Ph.D., http://www.kaner.com/
Pgina 35 de 35

Metodologias Agiles

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologias Agiles

Cargado por

Copyright:

Formatos disponibles

Metodologas de Desarrollo de Software giles

Con mucho, el desarrollo de software es una actividad catica,

Los mtodos giles son adaptables en lugar de predictivos. Los mtodos

Metodologas de Desarrollo de Software giles

Intentan ser procesos que se adaptan y crecen en el cambio, incluso al

Los mtodos giles son orientados a la gente y no orientados al proceso.

En las secciones siguientes se vern estas diferencias ms en detalle,

Qu es una Metodologa gil?

Predictivo versus Adaptable

Metodologas de Desarrollo de Software giles

construccin requiera menos pericia intelectual, aunque se necesita a menudo

Metodologas de Desarrollo de Software giles

Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho

En software la construccin es tan barata que es casi gratis.

En software todo el esfuerzo est en el diseo, de modo que requiere de

Los procesos creativos no se planean fcilmente, de modo que la

Debemos ser muy cautos al usar la metfora de la ingeniera tradicional

La Impredecibilidad de los Requisitos

Metodologas de Desarrollo de Software giles

cuando se usa realmente una versin temprana de algn software se empieza

Metodologas de Desarrollo de Software giles

algn punto la deriva es demasiada y el plan se cae en pedazos. Normalmente

Controlando un Proceso Imprevisible Iteraciones

Metodologas de Desarrollo de Software giles

Esto proporciona la retroalimentacin ms frecuente, as que usted sabe ms a

Metodologas de Desarrollo de Software giles

Poniendo a la Gente Primero

Juntar Unidades de Programacin Compatibles

comporten de manera predecible. Sin embargo las personas no son

Los Programadores son Profesionales Responsables

Metodologas de Desarrollo de Software giles

La historia reciente nos demuestra cada vez ms lo falso que es esto en

Manejando un Proceso Orientado a la Gente

Metodologas de Desarrollo de Software giles

Una razn importante para esto es el ritmo del cambio de tecnologa en

Metodologas de Desarrollo de Software giles

El Papel del Liderazgo de Negocio

Qu podemos hacer mejor?

Qu es lo que nos confunde?

Metodologas de Desarrollo de Software giles

Estas preguntas traern ideas para cambiar el proceso en la siguiente

Las Metodologas giles valoran:

Al individuo y las interacciones en el equipo de desarrollo ms que a

Desarrollar software que funciona ms que conseguir una buena

La colaboracin con el cliente ms que la negociacin de un contrato.

Responder a los cambios ms que seguir estrictamente una

Metodologas de Desarrollo de Software giles

Por qu surgen las Metodologas giles?

Dificultad para implantar metodologas tradicionales. Sofisticadas

Una solucin a medida para un segmento importante de proyectos de

Pugna entre comunidades / gures

Costo de los Cambios en la Construccin de SW

costo del cambio

Manifiesto de las Metodologas giles

Metodologas de Desarrollo de Software giles

La prioridad principal es satisfacer al cliente mediante tempranas y

Dar la bienvenida a los cambios. Los MA capturan los cambios para

Entregar frecuentemente software que funcione, desde un par de

La gente del negocio y los desarrolladores deben trabajar juntos a lo

Construir el proyecto entorno a individuos motivados. Darles el

El dilogo cara a cara es el mtodo ms eficiente y efectivo para

El software que funciona es la medida principal de progreso.

Los procesos giles promueven un desarrollo sostenible. Los

La atencin continua a la calidad tcnica y al buen diseo mejora la