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 adouina
con muchas decisiones a corto plazo. Esto realmente funciona muy bien si el
sistema es peueo, pero conforme el sistema crece llega a ser cada vez m!s
difcil agregar nuevos aspectos al mismo. "dem!s los bugs llegan a ser cada
vez m!s frecuentes y m!s difciles de corregir. #a sea tpica de tal sistema es
una larga fase de pruebas despu$s de ue el sistema ha sido "completado". %al
fase larga de pruebas hace estragos con los planes de pruebas y depurado
llegando a ser imposible de incluir en el programa de traba&o.
'emos vivido con este estilo de desarrollo por mucho tiempo, pero
tambi$n hemos tenido una alternativa desde hace mucho( )etodologa. #as
metodologas imponen un proceso disciplinado sobre el desarrollo de software
con el fin de hacerlo m!s predecible y eficiente. #o hacen desarrollando un
proceso detallado con un fuerte $nfasis en planificar inspirado por otras
disciplinas de la ingeniera.
#as metodologas ingenieriles han estado presentes durante mucho
tiempo. *o se han distinguido precisamente por ser muy e+itosas. ",n menos
por su popularidad. #a crtica m!s frecuente a estas metodologas es ue son
burocr!ticas. 'ay tanto ue hacer para seguir la metodologa ue el ritmo
entero del desarrollo se retarda.
Como una reaccin a estas metodologas, un nuevo grupo de
metodologas ha surgido en los ,ltimos aos. -urante alg,n tiempo se
conocan como metodologas ligeras, pero el t$rmino aceptado ahora es
metodologas !giles. .ara mucha gente el encanto de estas metodologas
!giles es su reaccin ante la burocracia de las metodologas monumentales.
Estos nuevos m$todos buscan un &usto medio entre ning,n proceso y
demasiado proceso, proporcionando simplemente suficiente proceso para ue
el esfuerzo valga la pena.
El resultado de todo esto es ue los m$todos !giles cambian
significativamente algunos de los $nfasis de los m$todos ingenieriles. #a
diferencia inmediata es ue son menos orientados al documento, e+igiendo una
cantidad m!s peuea de documentacin para una tarea dada. -e muchas
maneras son m!s bien orientados al cdigo( siguiendo un camino ue dice ue
la parte importante de la documentacin es el cdigo fuente.
/in embargo, $ste no es el punto importante sobre los m$todos !giles.
#a falta de documentacin es un sntoma de diferencias mucho m!s profundas(
#os m$todos !giles son adaptables en lugar de predictivos. #os m$todos
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 ue las cosas cambian. "s ue su naturaleza es resistirse al
cambio. .ara los m$todos !giles, no obstante, el cambio es bienvenido.
)etodologas de -esarrollo de /oftware 0giles .!gina 1 de 23
4ntentan ser procesos ue se adaptan y crecen en el cambio, incluso al
punto de cambiarse ellos mismos.
#os m$todos !giles son orientados a la gente y no orientados al proceso.
#a meta de los m$todos ingenieriles es definir un proceso ue
funcionar! bien con cualuiera ue lo use. #os m$todos !giles afirman
ue ning,n proceso podr! nunca mauillar las habilidades del euipo de
desarrollo, de modo ue el papel del proceso es apoyar al euipo de
desarrollo en su traba&o. E+plcitamente puntualizan el traba&ar a favor de
la naturaleza humana en lugar de en su contra y enfatizan ue el
desarrollo de software debe ser una actividad agradable.
En las secciones siguientes se ver!n estas diferencias m!s en detalle,
para discernir lo ue es un proceso adaptable y centrado en la gente, sus
beneficios y desventa&as, y u$ se debera usar( sea como desarrollador o
como cliente de software.
Qu es una Metodologa gil?
#as )etodologas 0giles o 5ligeras6 constituyen un nuevo enfoue en el
desarrollo de software, me&or aceptado por los desarrolladores de e7pro&ects
ue las metodologas convencionales 84/97:;;;, C)), etc< debido a la
simplicidad de sus reglas y pr!cticas, su orientacin a euipos de desarrollo de
peueo tamao, su fle+ibilidad ante los cambios y su ideologa de
colaboracin =1>.
Predictivo versus Adaptable
Separacin de Diseo ! "onstruccin
#a inspiracin usual para las metodologas han sido disciplinas como las
ingenieras civil o mec!nica. %ales disciplinas enfatizan ue hay ue planear
antes de construir. #os ingenieros traba&an sobre una serie de esuemas ue
indican precisamente u$ hay ue construir y como deben &untarse estas
cosas. )uchas decisiones de diseo, como la manera de controlar la carga
sobre un puente, se toman conforme los dibu&os se producen. #os dibu&os se
entregan entonces a un grupo diferente, a menudo una compaa diferente,
para ser construidos. /e supone ue el proceso de la construccin seguir! los
dibu&os. En la pr!ctica los constructores se encuentran con algunos problemas,
pero $stos son normalmente poco importantes.
Como los dibu&os especifican las piezas y cmo deben unirse, act,an
como los fundamentos de un plan de construccin detallado. -icho plan define
las tareas ue necesitan hacerse y las dependencias ue e+isten entre estas
tareas. Esto permite un plan de traba&o y un presupuesto de construccin
razonablemente predecibles. %ambi$n dice en detalle cmo deben hacer su
traba&o las personas ue participan en la construccin. Esto permite ue la
)etodologas de -esarrollo de /oftware 0giles .!gina ? de 23
construccin reuiera menos pericia intelectual, aunue se necesita a menudo
mucha habilidad manual.
"s ue lo ue vemos au son dos actividades fundamentalmente
diferentes. El diseo, u$ es difcil de predecir y reuiere personal caro y
creativo, y la construccin ue es m!s f!cil de predecir. @na vez ue tenemos
el diseo, podemos planear la construccin. @na vez ue tenemos el plan de
construccin, podemos ocuparnos de la construccin de una manera m!s
predecible. En ingeniera civil la construccin es mucho m!s costosa y tardada
ue el diseo y la planeacin.
"s el acercamiento de muchas metodologas es( ueremos un plan de
traba&o predecible ue pueda usar gente del m!s ba&o nivel. .ara hacerlo
debemos separar el plan de la construccin. .or consiguiente necesitamos
entender cmo hacer el diseo de software de modo ue la construccin pueda
ser sencilla una vez ue el plan est$ hecho.
ABu$ forma toma este planC .ara muchos, $ste es el papel de
notaciones de diseo como el @)#. /i podemos hacer todas las decisiones
significativas usando @)#, podemos armar un plan de construccin y entonces
podemos dar planes a los programadores como una actividad de construccin.
.ero au surgen preguntas cruciales. AEs posible armar un plan ue
sea capaz de convertir el cdigo en una actividad de construccin predecibleC
D en tal caso, Aes la construccin suficientemente grande en costo y tiempo
para hacer valer la pena este enfoueC
%odos esto trae a la mente m!s preguntas. #a primera es la cuestin de
cu!n difcil es conseguir un diseo @)# en un estado ue pueda entregarse a
los programadores. El problema con un diseo tipo @)# es ue puede parecer
muy bueno en el papel, pero resultar seriamente fallido a la hora de la
programacin. #os modelos ue los ingenieros civiles usan est! basado en
muchos aos de pr!ctica guardados en cdigos ingenieriles. "dem!s los
problemas importantes, como el modo en ue &uegan las fuerzas, son dciles al
an!lisis matem!tico. #a ,nica verificacin ue podemos hacer con los
diagramas @)# es la revisin cuidadosa. )ientras esto es ,til trae errores al
diseo ue slo se descubren durante la codificacin y pruebas. 4ncluso los
diseadores e+perimentados, se sorprenden a menudo cuando convierten
dichos diseos en software.
9tro problema es el costo comparativo. Cuando se construye un puente,
el costo del esfuerzo en el plan es apro+imadamente un 1;E del total, siendo el
resto la construccin. En software la cantidad de tiempo gastada codificando es
mucho, mucho menor. /teve )cConnell =?> sugiere ue para un proyecto
grande, slo 1FE del proyecto son cdigo y pruebas unitarias, una inversin
casi perfecta de las proporciones de la construccin del puente. "un cuando se
consideren las pruebas parte de la construccin, el plan es todava F;E del
total. Esto genera una pregunta importante sobre la naturaleza del diseo en
software comparado con su papel en otras ramas de la ingeniera.
)etodologas de -esarrollo de /oftware 0giles .!gina 2 de 23
Esta clase de preguntas llevaron a GacH Ieeves a sugerir ue de hecho
el cdigo fuente es un documento de diseo y ue la fase de construccin est!
en realidad en la compilacin y el ligado. -e hecho cualuier cosa ue pueda
tratarse como construccin puede y debe automatizarse.
Estas ideas llevan a algunas conclusiones importantes(
En software la construccin es tan barata ue es casi gratis.
En software todo el esfuerzo est! en el diseo, de modo ue reuiere de
personas creativas y talentosas.
#os procesos creativos no se planean f!cilmente, de modo ue la
previsibilidad bien puede ser una meta imposible.
-ebemos ser muy cautos al usar la met!fora de la ingeniera tradicional
para construir software. Es un tipo diferente de actividad y por ende
reuiere un proceso diferente.
#a $%predecibilidad de los &e'uisitos
'ay un dicho ue se oye en cada proyecto problem!tico. #os
desarrolladores vienen y me dicen "el problema con este proyecto es ue los
reuisitos cambian todo el tiempo". #o sorprendente de esta situacin es ue
sorprenda a cualuiera. En el negocio de construccin de software los cambios
en los reuisitos son la norma, la pregunta es u$ hacemos al respecto.
@na forma es tratar los reuisitos cambiantes como el resultado de una
pobre ingeniera de reuisitos. #a idea detr!s de la ingeniera de reuisitos es
conseguir un cuadro totalmente entendido de los reuisitos antes de empezar a
construir el software, conseguir la firma del cliente sobre estos reuisitos, y
entonces preparar procedimientos ue limiten los cambios de reuisitos
despu$s de la firma.
@n problema con esto es ue simplemente tratar de entender las
opciones para los reuisitos es duro. Es aun m!s duro porue la organizacin
del desarrollo normalmente no proporciona la informacin del costo en los
reuisitos. El cliente termina solicitando algo ue el vendedor no puede cotizar
con e+actitud. /in una buena idea del costo, Acmo puede el cliente decidir si
uiere pagar por ese pedidoC
#a estimacin es difcil por muchas razones. En parte porue el
desarrollo de software es una actividad de diseo, difcil de planear y costear.
En parte porue los materiales b!sicos cambian r!pidamente. En parte por lo
mucho ue depende de los individuos involucrados, y los individuos son
difciles de predecir y cuantificar.
#a naturaleza intangible del software tambi$n afecta. Es muy difcil saber
u$ valor aporta un rasgo de software hasta ue se usa en realidad. /lo
)etodologas de -esarrollo de /oftware 0giles .!gina J de 23
cuando se usa realmente una versin temprana de alg,n software se empieza
a entender cu!les rasgos son valiosos y cu!les no.
Esto lleva al punto irnico de ue es de esperarse ue los reuisitos
sean cambiables. -espu$s de todo se supone ue el software es "suave". "s
no slo son cambiables los reuisitos, sino ue deben de serlo. %oma mucha
energa conseguir ue los clientes de software corri&an los reuisitos. Es aun
peor si ellos han estado alguna vez en desarrollo de software, porue entonces
"saben" ue el software es f!cil de cambiar.
.ero aun cuando se pudiera controlar todo esto y realmente se pudiera
conseguir un con&unto e+acto y estable de reuisitos, probablemente a,n no
estamos a salvo. En la economa de hoy las fuerzas de negocios
fundamentales cambian el valor de los rasgos de software demasiado
r!pidamente. El ue podra ser un buen con&unto de reuisitos ahora, no ser!
tan bueno en seis meses. ",n cuando el cliente pueda corregir sus reuisitos,
el mundo de negocios no va a detenerse por $l. D muchos cambios en el
mundo de negocios son completamente imprevisibles( cualuiera ue 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 reuisitos. /i no
se pueden obtener reuisitos estables no se puede obtener un plan predecible.
(s $%posible la Previsibilidad?
En general, no. 'ay algunos desarrollos de software dnde la
previsibilidad es posible. 9rganizaciones como el grupo de software del
trasbordador espacial de la *"/" son un e&emplo selecto donde el desarrollo
de software puede ser predecible. Ieuiere mucha ceremonia, mucho tiempo,
un euipo grande y reuisitos estables. 'ay proyectos por ah ue son
transbordadores espaciales. /in embargo no creo ue el software comercial
enca&e en esa categora. .ara $ste se necesita un tipo diferente de proceso.
@no de los grandes peligros es pretender ue se puede seguir un
proceso predecible cuando no se puede. #a gente ue traba&a en metodologas
no es buena en identificar condiciones lmite( los lugares donde la metodologa
pasa de apropiada en inapropiada. #a mayora de los metodologistas uieren
ue sus metodologas sean usadas por todos, de modo ue 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.
'ay una tentacin fuerte para hacer eso. #a previsibilidad es una
propiedad muy deseable. *o obstante creer ue se puede ser predecible
cuando no se puede, lleva a situaciones en donde las personas construyen un
plan temprano, y entonces no pueden mane&ar la situacin cuando el plan se
cae en pedazos. @sted acaba viendo el plan y la realidad flotando aparte.
-urante alg,n tiempo usted podr! pretender ue el plan es v!lido. .ero en
)etodologas de -esarrollo de /oftware 0giles .!gina F de 23
alg,n punto la deriva es demasiada y el plan se cae en pedazos. *ormalmente
la cada es dolorosa.
"s si usted est! en una situacin impredecible no puede usar una
metodologa predictiva. Kse es un golpe duro. /ignifica ue tantos modelos
para controlar proyectos, y muchos de los modelos para llevar la relacin con el
cliente, ya no son ciertos. #os beneficios de la previsibilidad son tan grandes,
ue es difcil de&arlos ir. Como en tantos problemas la parte m!s difcil est!
simplemente en comprender ue el problema e+iste.
-e cualuier modo de&ar ir la previsibilidad no significa ue hay ue
volver al caos ingobernable. )!s bien hace falta un proceso ue pueda dar
control sobre la imprevisibilidad. -e eso se trata la adaptabilidad.
"ontrolando un Proceso $%previsible ) $teraciones
A"s ue cmo nos controlamos en un mundo imprevisibleC #a parte
m!s importante y difcil, es saber con precisin dnde estamos. *ecesitamos
un mecanismo honesto de retroalimentacin ue pueda decirnos con precisin
cu!l es la situacin a intervalos frecuentes.
#a llave para obtener esta retroalimentacin es el desarrollo iterativo.
Esta no es una idea nueva. El desarrollo iterativo ha estado durante alg,n
tiempo ba&o muchos nombres( incremental, evolutivo, escenificado, espiral...
muchos nombres. #a clave del desarrollo iterativo es producir frecuentemente
versiones ue funcionen del sistema final ue tengan un subcon&unto de los
rasgos reueridos. Kstos sistemas son cortos en funcionalidad, pero por otra
parte deben ser fieles a las demandas del sistema final. -eben ser totalmente
integrados y tan cuidadosamente probados como una entrega final.
El punto es ue no hay nada como un sistema probado, integrado para
traer una dosis poderosa de realidad en cualuier proyecto. #os documentos
pueden esconder toda clase de fallas. El cdigo no probado puede esconder
bastantes defectos. .ero cuando las personas realmente se sientan delante de
un sistema y traba&an con $l, entonces las fallas se vuelven aparentes( tanto las
relativas a defectos como las relativas a los reuisitos mal entendidos.
El desarrollo iterativo tambi$n tiene sentido en los procesos predictivos.
.ero es esencial en los procesos adaptables porue un proceso adaptable
necesita poder tratar con los cambios en los rasgos reueridos. 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 ue puede usarse para
basar los planes posteriores.
@na pregunta importante es cu!nto debe durar una iteracin. -iferentes
personas dan respuestas diferentes. L. sugiere iteraciones de entre una y tres
semanas. /CI@) sugiere un mes. Crystal estira aun m!s. #a tendencia, de
cualuier modo, es hacer cada iteracin tan corta como se pueda mane&ar.
)etodologas de -esarrollo de /oftware 0giles .!gina 3 de 23
Esto proporciona la retroalimentacin m!s frecuente, as ue usted sabe m!s a
menudo donde se encuentra.
(l "liente Adaptable
Este tipo de proceso adaptable reuiere un tipo diferente de relacin con
el cliente ue las ue 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 preferir!n un
contrato a precio fi&o. -gale a los desarrolladores lo ue uieren, negocie,
acepte una oferta, y entonces la carga ueda en la empresa de desarrollo para
construir el software.
@n contrato a precio fi&o reuiere reuisitos estables y por tanto procesos
predictivos. #os procesos adaptables y los reuisitos inestables implican ue no
se puede traba&ar con la nocin usual de precio fi&o. %ratar de enca&ar un
modelo de precio fi&o a un proceso adaptable acaba en una e+plosin muy
dolorosa. #a parte sucia de esta e+plosin es ue el cliente ueda herido tanto
como la compaa de desarrollo de software. -espu$s de todo el cliente no
uerra un software a menos ue su negocio lo necesitara. /i no lo consigue su
negocio sufre. "s aun cuando no pague nada a la compaa de desarrollo,
todava pierde. -e hecho pierde m!s de lo ue pagara por el software 8Apor
u$ habra de pagar el software si el valor comercial de ese software fuera
menorC<.
-e modo ue hay peligro para ambos lados al firmar un contrato a precio
fi&o en condiciones donde un proceso predictivo no puede usarse. Esto significa
ue el cliente tiene ue traba&ar de otro modo.
Esto no significa ue no se pueda fi&ar un presupuesto para software por
adelantado. #o ue significa es ue no se puede fi&ar el tiempo, precio y
alcance. #a manera !gil usual es fi&ar tiempo y precio y permitir ue 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. " cada iteracin puede tanto
verificar el progreso como alterar la direccin del desarrollo de software. Esto
lleva a una relacin mucho m!s ntima con los desarrolladores de software, una
verdadera sociedad de traba&o. Este nivel de compromiso no es para cualuier
organizacin cliente, ni para cualuier desarrollador de softwareM pero es
esencial para lograr ue un proceso adaptable funcione apropiadamente.
El beneficio importante para el cliente es un desarrollo de software
mucho m!s sensible. @n sistema usable, aunue mnimo, puede entrar en
produccin pronto. El cliente puede cambiar sus capacidades de acuerdo a los
cambios en el negocio, y tambi$n aprender cmo se usa el sistema en realidad.
@na pieza tan importante como $sta es una visibilidad mayor sobre el
verdadero estado del proyecto. El problema con los procesos predictivos es
)etodologas de -esarrollo de /oftware 0giles .!gina N de 23
ue la calidad del proyecto se mide por la conformidad con el plan. Esto
dificulta a la gente sealar cu!ndo la realidad y el plan divergen. El resultado
com,n es un gran resbaln m!s tarde en el calendario del proyecto. En un
proyecto !gil hay un constante rehacer del plan con cada iteracin. /i las malas
noticias est!n al acecho, tienden a aparecer m!s temprano, cuando aun se
puede hacer algo al respecto. -e hecho este control del riesgo es una venta&a
clave del desarrollo iterativo. #os m$todos !giles van m!s all! manteniendo
corta la duracin de la iteracin, pero tambi$n viendo estas variaciones como
oportunidades.
'ay un aspecto importante en lo ue constituye un proyecto e+itoso. @n
proyecto predictivo se mide a menudo por lo bien ue coincide con el plan. @n
proyecto ue est! a tiempo y en costo es un $+ito. Esta medida no tiene
sentido en un ambiente !gil. .ara el agilista la cuestin es el valor de negocio
8beneficio< ue el cliente consiga, es decir, un software m!s valioso ue el
costo ue puso en $l. @n buen proyecto predictivo ir! de acuerdo al plan, un
buen proyecto !gil construir! algo diferente y me&or ue lo ue se esperaba en
el plan original.
Poniendo a la *ente Pri%ero
*o es f!cil e&ecutar un proceso adaptable. En particular reuiere un
euipo muy eficaz de desarrolladores. El euipo necesita ser eficaz tanto en la
calidad de los individuos como en la manera en ue funcionan &untos en
euipo. 'ay tambi$n una sinergia interesante( no slo la adaptabilidad reuiere
un euipo fuerte, la mayora de los buenos desarrolladores prefieren un
proceso adaptable.
+untar ,nidades de Progra%acin "o%patibles
@no de los ob&etivos 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 ue est!n disponibles
en varios tipos. /e tienen un analista, algunos programadores, algunos
verificadores, un gerente. #os individuos no son tan importantes, slo los roles
lo son. -e esa manera si usted planea un proyecto no importa u$ analista y
u$ verificadores consiga, slo hay ue saber cu!ntos son para saber cmo
afecta su plan el n,mero de recursos.
.ero esto plantea una pregunta clave( Ason las personas involucradas
en el desarrollo de software partes reemplazablesC @no de los rasgos
importantes de los m$todos !giles es el rechazo a esta afirmacin.
Buiz!s el rechazo m!s e+plcito a las personas como recursos lo hace
"listair CocHburn. En su artculo 5Caracterizacin de las .ersonas como
Componentes *o #ineales de .rimer 9rden en el -esarrollo de /oftware6 =2>,
apunta a ue los procesos predecibles reuieren componentes ue se
)etodologas de -esarrollo de /oftware 0giles .!gina O de 23
comporten de manera predecible. /in embargo las personas no son
componentes predecibles. "dem!s sus estudios de proyectos de software lo
han llevado a concluir ue la gente es el factor m!s importante en el desarrollo
de software.
En el ttulo de su artculo se refiere a las personas como "componentes".
"s es como se trata a la gente en la literatura de diseo de procesos P
metodologas. El error de este enfoue es ue las "personas" son altamente
inconstantes y no lineales, con modos ,nicos de $+ito 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 ue vemos a menudo.
@no se pregunta si la naturaleza del desarrollo de software funciona contra uno
au. Cuando programamos una computadora, controlamos un dispositivo
inherentemente predecible. Como estamos en este negocio porue somos
buenos en hacerlo, estamos idealmente hechos para perturbarnos cuando nos
enfrentamos con seres humanos.
"unue "listair CocHburn es el m!s e+plcito en su visin centrada en la
gente del desarrollo de software, la nocin de ue la gente es primero es un
tema com,n para muchos pensadores del software. El problema, demasiado a
menudo, es ue la metodologa se ha opuesto a la nocin de las personas
como el factor de primer orden en el $+ito del proyecto.
Esto crea un fuerte efecto de retroalimentacin positiva. /i usted espera
ue todos sus desarrolladores se &unten en unidades de programacin
compatibles, no intentar! tratarlos como individuos. Esto ba&a la moral 8y la
productividad<. #as personas capaces se buscar!n un lugar me&or donde estar,
y usted acabar! con lo ue usted deseaba( unidades de programacin
compatibles.
-ecidir ue las personas son primero es una gran decisin, ue reuiere
mucha determinacin. #a nocin de la gente como recursos es profundamente
inculcado en el pensamiento de negocios, teniendo sus races en el impacto del
enfoue de #a -ireccin Cientfica de QredericH %aylor. En la administracin de
una f!brica, este enfoue %aylorista tiene sentido. .ero para un traba&o
altamente creativo y profesional, como creo es el desarrollo de software, esto
no se sostiene. 8D de hecho la fabricacin moderna tambi$n se est! saliendo
del modelo %aylorista<.
#os Progra%adores son Profesionales &esponsables
@na parte clave de la nocin %aylorista es ue la gente ue hace el
traba&o no es la me&or gente para entender la me&or manera de hacer el traba&o.
En una f!brica esto puede ser verdad por varias razones. En parte porue la
mayora de los obreros no son las personas m!s inteligentes o creativas, en
parte porue hay una tensin entre la gerencia y los obreros en ue la gerencia
gana m!s dinero y los obreros menos.
)etodologas de -esarrollo de /oftware 0giles .!gina : de 23
#a historia reciente nos demuestra cada vez m!s lo falso ue es esto en
el desarrollo de software. " las personas brillantes y capaces les atrae cada
vez m!s el desarrollo de software, tanto por su ostentacin como por ganancias
potencialmente mayores. 8"mbas razones me tentaron a salir de la ingeniera
electrnica<. Cosas tales como opciones accionarias afirman el inter$s de los
programadores en la compaa.
"u bien puede haber un efecto generacional. @na evidencia
anecdtica me hace preguntarme si m!s 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 &uventud en el negocio de la computacin, como en la
mayora de los cultos se necesita un grano de verdad en $l.
Cuando se uiere contratar y retener a gente capaz, hay ue reconocer
ue son profesionales competentes. Como tales son los me&ores para decidir
cmo dirigir su traba&o t$cnico. #a nocin %aylorista de un departamento de
planificacin separado ue decide cmo hacer las cosas slo funciona si los
planificadores entienden me&or cmo hacer bien el traba&o ue auellos ue lo
hacen. /i usted tiene personas brillantes, motivadas ue hacen bien el traba&o
entonces eso no se sostiene.
Mane-ando un Proceso .rientado a la *ente
#a orientacin a la gente se manifiesta de varias maneras diferentes en
los procesos !giles, lo ue lleva a efectos diferentes, no todos consistentes.
@no de los elementos clave es la aceptacin de un proceso en lugar de
la imposicin de un proceso. " 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. "ceptar un
proceso reuiere compromiso, y como tal se necesita el involucramiento activo
de todo el euipo.
Esto termina con el resultado interesante de ue slo los desarrolladores
pueden escoger seguir un proceso adaptable. Esto es particularmente cierto
para la L., ue reuiere mucha disciplina para e&ecutarse. "u es donde
Crystal es un complemento efectivo ya ue apunta a una disciplina mnima.
9tro punto es ue los desarrolladores deben poder tomar todas las
decisiones t$cnicas. L. llega al corazn de esto cuando en su proceso de
planeacin establece ue slo los desarrolladores pueden estimar cu!nto
tiempo tomar! hacer un traba&o.
%al liderazgo t$cnico es un gran cambio para muchas personas en
posiciones gerenciales. %al acercamiento reuiere compartir una
responsabilidad donde desarrolladores y gerencia tienen un mismo lugar en la
direccin del proyecto. *tese ue di&e igual. #a gerencia aun &uega un papel,
pero reconoce la pericia de los desarrolladores.
)etodologas de -esarrollo de /oftware 0giles .!gina 1; de 23
@na razn importante para esto es el ritmo del cambio de tecnologa en
nuestra industria. -espu$s de unos aos el conocimiento t$cnico se vuelve
obsoleto. Esta vida media de habilidades t$cnicas no tiene parangn en
cualuier otra industria. 4ncluso los t$cnicos tienen ue reconocer ue entrar a
la gerencia significa ue sus habilidades t$cnicas se marchitar!n r!pidamente.
#os e+desarrolladores necesitan reconocer ue sus habilidades t$cnicas
desaparecer!n r!pidamente y necesitan confiar y depender en los
desarrolladores actuales.
#a Dificultad de Medir
/i usted tiene un proceso donde las personas ue dicen cmo hacer el
traba&o son distintas de las personas ue realmente lo hacen, los lderes
necesitan alguna manera de medir cu!n eficaces son los ue lo hacen. En la
-ireccin Cientfica haba un impulso fuerte a desarrollar formas ob&etivas de
medir el rendimiento de las personas.
Esto es particularmente pertinente al software debido a la dificultad de
aplicar medidas al software. " pesar de nuestros me&ores esfuerzos somos
incapaces de medir las cosas m!s simples sobre el software, como la
productividad. /in buenas medidas para estas cosas, cualuier clase de control
e+terno est! condenado.
#a introduccin de gestin medida sin buenas medidas tiene sus propios
problemas. Iobert "ustin =J> hizo una discusin e+celente sobre esto. Kl seala
ue cuando se mide el rendimiento usted tienen ue conseguir todos los
factores importantes ba&o medida. Cualuier cosa ue se olvide tiene el
resultado inevitable ue los hacedores alterar!n lo ue hacen para producir las
me&ores medidas, incluso si eso claramente reduce la verdadera efectividad de
lo ue hacen. Este trastorno de la medida es el taln de "uiles de la gestin
basada en medidas.
#a conclusin de Iobert "ustin es ue usted tiene ue escoger entre la
gestin basada en m$tricas y la gestin delegatoria 8donde los hacedores
deciden cmo hacer el traba&o<. #a gestin basada en m$tricas es m!s
adecuada para el traba&o simple repetitivo, con ba&os reuisitos de
conocimiento y rendimientos f!cilmente medibles 7 e+actamente lo contrario al
desarrollo de software.
El punto de todo esto es ue los m$todos tradicionales han operado ba&o
la asuncin de ue la gestin basada en m$tricas es la manera m!s eficaz de
administrar. #a comunidad !gil reconoce ue las caractersticas del desarrollo
de software son tales ue la gestin basada en m$tricas lleva el trastorno de la
medida a niveles muy altos. Es realmente m!s eficaz usar un estilo delegatorio
de administracin, ue es el tipo de acercamiento central del punto de vista
agilista.
)etodologas de -esarrollo de /oftware 0giles .!gina 11 de 23
(l Papel del #idera/go de 0egocio
.ero los t$cnicos no pueden hacer el proceso entero ellos solos.
*ecesitan una gua en las necesidades del negocio. Esto lleva a otro aspecto
importante de los procesos adaptables( necesitan un contacto muy ntimo con
los e+pertos del negocio.
Esto va m!s all! del compromiso de negocios en la mayora de los
proyectos. #os euipos !giles no pueden e+istir con una comunicacin
ocasional. *ecesitan un acceso continuo a los e+pertos del negocio. "dem!s
este acceso no es algo ue se mane&e a nivel gerencial, es algo ue est!
presente para cada desarrollador. Como los desarrolladores son profesionales
capaces en su propia disciplina, pueden traba&ar como iguales con otros
profesionales de otras disciplinas.
Rran parte de esto, claro est!, se debe a la naturaleza del desarrollo
adaptable. Como la premisa entera del desarrollo adaptable es ue las cosas
cambian r!pidamente, se necesita un contacto constante para avisar a todos
de los cambios.
*o hay nada m!s frustrante para un desarrollador ue ver
desperdiciarse su duro traba&o. "s ue es importante asegurar ue hay pericia
de negocios de buena calidad ue est! disponible al desarrollador y de calidad
suficiente para ue el desarrollador pueda confiar en ella.
(l Proceso Auto1Adaptable
'asta ahora he hablado sobre la adaptabilidad en el conte+to de un
proyecto adaptando frecuentemente su software para enfrentarse a los
reuisitos cambiantes de sus clientes. *o obstante hay otro !ngulo de la
adaptabilidad( el del proceso ue cambia con el tiempo. @n proyecto ue
empieza usando un proceso adaptable no tendr! el mismo proceso un ao
despu$s. Con el tiempo, el euipo encontrar! lo ue funciona me&or para ellos,
y alterar! el proceso a su medida.
#a primera parte de la auto adaptabilidad son las revisiones regulares
del proceso. *ormalmente se hacen con cada iteracin. "l final de cada
iteracin, haga una reunin corta y h!gase las siguientes preguntas 8escogidas
de *orm Serth =F><
ABu$ hicimos bienC
ABu$ hemos aprendidoC
ABu$ podemos hacer me&orC
ABu$ es lo ue nos confundeC
)etodologas de -esarrollo de /oftware 0giles .!gina 1? de 23
Estas preguntas traer!n ideas para cambiar el proceso en la siguiente
iteracin. -e esta manera un proceso ue empieza con problemas puede
me&orar conforme el proyecto avanza, adapt!ndose me&or al euipo ue lo usa.
/i la auto adaptabilidad ocurre dentro de un proyecto, es aun m!s
marcada en una organizacin. .ara ahondar el proceso de la auto
adaptabilidad sugiero ue los euipos hagan una revisin m!s formal e hitos
del proyecto mayores siguiendo las sesiones retrospectivas del proyecto
esbozadas por *orm Serth. Estas retrospectivas involucran reuniones de ?72
das y un facilitador entrenado. Ellas no solo dan aprendiza&e al euipo,
tambi$n dan aprendiza&e a la organizacin entera.
@na consecuencia de la auto adaptabilidad es ue nunca se debe
esperar encontrar una metodologa corporativa ,nica. En cambio cada euipo
debe no simplemente escoger su propio proceso, debe tambi$n afinar
activamente su proceso conforme avanza el proyecto. )ientras ue tanto los
procesos publicados como la e+periencia 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 "/- y Crystal. #as reglas
rgidas de la L. parecen desaprobarla, pero $sa es slo una impresin
superficial ya ue la L. anima a la gente a afinar el proceso. #a diferencia
principal de la L. es ue sus promotores sugieren hacer L. al pie de la letra
por varias iteraciones antes de adaptarlo. "dem!s las revisiones no son
enfatizadas, ni parte del proceso, aunue hay sugerencias de ue las
revisiones deberan ser una de las pr!cticas de la L..
#as Metodologas giles valoran2
En la "lianza 0gil =3> establecen como valores de los )"(
1. "l individuo y las interacciones en el euipo de desarrollo m!s ue a
las actividades y las herramientas.
?. -esarrollar software ue funciona m!s ue conseguir una buena
documentacin, implica minimalismo respecto del modelado y la
documentacin del sistema.
2. #a colaboracin con el cliente m!s ue la negociacin de un contrato.
J. Iesponder a los cambios m!s ue seguir estrictamente una
planificacin.
)etodologas de -esarrollo de /oftware 0giles .!gina 12 de 23
Por 'u surgen las Metodologas giles?
En =N> se destacan los siguientes puntos como los principales motivos de
surgimiento de los )"(
1. -ificultad para implantar metodologas tradicionales. /ofisticadas
herramientas C"/E y notaciones 8@)#<
?. @na solucin a medida para un segmento importante de proyectos de
desarrollo de software
2. .ugna entre comunidades P gur,es
J. "ceptar el cambio
"osto de los "a%bios en la "onstruccin de S3
-e =N> se pudo e+traer la Qigura 1 ue se muestra a continuacin. En la
misma se muestra el costo de producir cambios en el software ue se
desarrolla mediante una metodologa tradicional versus el costo de producir
cambios en el software ue se desarrolla mediante alguna de las metodologas
!giles. Como se puede apreciar, a medida ue avanza el tiempo, el costo es
e+ponencial en el caso de la construccin mediante una metodologa
tradicional.
Qigura 1( Quncin de costos de cambio en el software desarrollado
Manifiesto de las Metodologas giles
En un taller de dos das en /nowbird, @tah, en febrero de ?;;1 se
reunieron los representantes de cada una de las metodologas !giles. 'aba
)etodologas de -esarrollo de /oftware 0giles .!gina 1J de 23
costo del cambio
tiempo
metodologa tradicional
suposicin
metodologa !gil
mucho en com,n, y este reconocimiento era mucho mayor ue las diferencias
entre los procesos.
"dem!s de un contacto ,til entre los lderes de procesos, e+ista tambi$n
la idea de emitir una declaracin con&unta en favor de procesos de desarrollo
de software !giles.
El resultado es un )anifiesto para el -esarrollo de /oftware 0gil =O>, una
declaracin de los principios y valores comunes de los procesos !giles.
'ay tambi$n un deseo de colaborar m!s en el futuro, para animar m!s
tanto a tecnlogos como a gente de negocios para usar y reuerir
acercamientos !giles al desarrollo de software.
El manifiesto fue slo eso, una publicacin ue actu como un punto de
partida para auellos ue compartan estas ideas b!sicas. @no de los frutos del
esfuerzo fue la creacin de un cuerpo m!s longevo, la "lianza 0gil =3>. #a
"lianza 0gil es una organizacin sin fines de lucro ue busca promover el
conocimiento y la discusin de todos los m$todos !giles. )uchos de los lderes
de metodologas de desarrollo de software !giles son miembros y lderes de la
"lianza 0gil.
#os principios ue se establecieron en el manifiesto son(
1. #a prioridad principal es satisfacer al cliente mediante tempranas y
continuas entregas de software ue le reporte un valor.
?. -ar la bienvenida a los cambios. #os )" capturan los cambios para
ue el cliente tenga una venta&a competitiva.
2. Entregar frecuentemente software ue funcione, desde un par de
semanas a un par de meses, con el menor intervalo de tiempo
posible entre una entrega y la siguiente.
J. #a gente del negocio y los desarrolladores deben traba&ar &untos a lo
largo del proyecto.
F. Construir el proyecto entorno a individuos motivados. -arles el
entorno y el apoyo ue necesitan y confiar en ellos para conseguir el
traba&o.
3. El di!logo cara a cara es el m$todo m!s eficiente y efectivo para
comunicar informacin dentro de un euipo de desarrollo.
N. El software ue funciona es la medida principal de progreso.
O. #os procesos !giles promueven un desarrollo sostenible. #os
promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante.
:. #a atencin continua a la calidad t$cnica y al buen diseo me&ora la
agilidad.
)etodologas de -esarrollo de /oftware 0giles .!gina 1F de 23
1;. #a simplicidad es esencial.
11. #as me&ores aruitecturas, reuisitos y diseos surgen de los euipos
organizados por s mismos.
1?. En intervalos regulares, el euipo refle+iona respecto de cmo llegar
a ser m!s efectivo, y seg,n esto a&usta su comportamiento.
"o%paracin gil 1 4gil
Metodologa gil Metodologa 0o gil 56radicional7
.ocos artefactos )!s artefactos
.ocos roles )!s roles
*o e+iste un contrato tradicional o al
menos es bastante fle+ible
E+iste un contrato prefi&ado
El cliente es parte del euipo de
desarrollo 8adem!s in7situ<
El cliente interact,a con el euipo de
desarrollo mediante reuniones
Rrupos peueos 8T 1; integrantes< y
traba&ando en el mismo sitio
Rrupos grandes
)enos $nfasis en la aruitectura #a aruitectura es esencial
Principales Metodologas giles
Crystal )ethodologies, "listarir CocHburn,
www.crystalmethodologies.org
/CI@), Sen /chwaber U Geff /utherland,
www.controlchaos.com
-/-) 8-ynamic /ystems -evelopment )ethod<,
www.dsdm.org
#ean .rogramming, )ary .oppendiecH,
www.poppendiecH.com
Q-- 8Qeature7-riven -evelopment<, .eter Coad U Geff -e #uca,
www.nebulon.comPfdd, www.coad.comPpeterPVfdd
E+treme .rogramming, Sent WecH
www.e+tremeprogramming.org, www.+programming.com
)etodologas de -esarrollo de /oftware 0giles .!gina 13 de 23
"daptative /oftware -evelopment, Gim 'ighsmith
www.adaptivesd.com
)etodologas de -esarrollo de /oftware 0giles .!gina 1N de 23
#as Metodologas
Xarias metodologas enca&an ba&o el estandarte de !gil. )ientras todas
ellas comparten muchas caractersticas, tambi$n hay algunas diferencias
significativas. *o se pueden resaltar todos los puntos en este estudio breve,
pero por lo menos se puede apuntar a algunos lugares donde buscar.
En =:> se puede observar una descripcin introductoria a varias
metodologas !giles.
89 Progra%acin (:tre%a 5;P7
-e todas las metodologas !giles, $sta es la ue ha recibido m!s
atencin. Esto se debe en parte a la notable habilidad de los lderes L., en
particular Sent WecH, para llamar la atencin. %ambi$n se debe a la habilidad
de Sent WecH de atraer a las personas a este acercamiento, y tomar un papel
principal en $l. -e algunas maneras, sin embargo, la popularidad de L. se ha
vuelto un problema, pues ha acaparado la atencin fuera de las otras
metodologas y sus valiosas ideas.
#as races de L. yacen en la comunidad de /malltalH, y en particular la
colaboracin cercana de Sent WecH y Yard Cunningham a finales de los ZO;.
"mbos refinaron sus pr!cticas en numerosos proyectos a principios de los Z:;,
e+tendiendo sus ideas de un desarrollo de software adaptable y orientado a la
gente.
El paso crucial de la pr!ctica informal a una metodologa ocurri en la
primavera de 1::3. " Sent WecH se le pidi revisar el progreso del proyecto de
nmina C2 para Chrysler. El proyecto estaba siendo llevado en /malltalH por
una compaa contratista, y estaba en problemas. -ebido a la ba&a calidad de
la base del cdigo, Sent WecH recomend tirar la base del cdigo en su
totalidad y empezar desde el principio. El proyecto entonces reinici ba&o su
direccin y subsecuentemente se volvi el buue insignia temprano y el campo
de entrenamiento de L..
#a primera fase del C2 fue muy e+itosa y comenz a principios de 1::N.
El proyecto continu desde entonces y despu$s se encontr con dificultades, lo
ue result en la cancelacin del desarrollo en 1:::. 8#o cual prueba, sin
ninguna otra cosa, ue L. no es garanta de $+ito.<
#a metodologa L. empieza con cuatro valores =1;>(
Comunicacin,
Ietroalimentacin,
/implicidad, y
Cora&e.
)etodologas de -esarrollo de /oftware 0giles .!gina 1O de 23
Construye sobre ellos una docena de pr!cticas ue los proyectos L.
deben seguir. )uchas de estas pr!cticas son t$cnicas antiguas, tratadas y
probadas, aunue a menudo olvidadas por muchos, incluyendo la mayora de
los procesos planeados. "dem!s de resucitar estas t$cnicas, L. las te&e en un
todo sin$rgico donde cada una refuerza a las dem!s.
@na de las m!s llamativas, as como inicialmente atractiva, es su fuerte
$nfasis en las pruebas. )ientras todos los procesos mencionan la
comprobacin, la mayora lo hace con muy poco $nfasis. /in embargo L. pone
la comprobacin como el fundamento del desarrollo, con cada programador
escribiendo pruebas cuando escriben su cdigo de produccin. #as pruebas se
integran en el proceso de integracin continua y construccin lo ue rinde una
plataforma altamente estable para el desarrollo futuro.
En esta plataforma L. construye un proceso de diseo evolutivo ue se
basa en refactorizar un sistema simple en cada iteracin. %odo 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
m!s, combina la disciplina con la adaptabilidad de una manera ue
indiscutiblemente la hace la m!s desarrollada de entre todas las metodologas
adaptables.
L. ha desarrollado un liderazgo amplio, muchos de ellos provenientes
del proyecto fundamental C2. Como resultado hay muchas fuentes para m!s
informacin. Sent WecH escribi 5E+treme .rogramming E+plained6, el
manifiesto clave de L. ue e+plica las razones detr!s de la metodologa y es
bastante amplia como para ue la gente pueda saber si se interesan en
seguirla. En el ,ltimo par de aos ha habido una epidemia de libros sobre L.
brillantemente coloreados la mayora de los cuales son bastante similares en
ue describen el proceso entero desde el punto de vista de varios seguidores
tempranos.
"s como los libros, hay un n,mero considerable de recursos en la web.
.ara encontrar un acercamiento m!s estructurado a L., es me&or empezar con
dos sitios de e+ alumnos del C2( Ion Geffries =11> y -on Yells =1?>. )ucha de
la promocin temprana y desarrollo de ideas de L. ocurrieron en el ambiente
de escritura colaborativa en la p!gina wiHi de Yard Cunningham =12>. El wiHi
sigue siendo un lugar fascinante para descubrir, aunue su naturaleza
divagante lo absorbe a uno. 'ay un activo y a menudo interesante Rrupo de
-iscusin L. =1J>. @na de las vistas e+ternas m!s interesantes sobre L. es la
de )arH .aulH ue es uno de los lderes de la comunidad C)) 7 su artculo
mira a la 5L. desde la .erspectiva del C))6 =1F>.
%ambi$n hay otras referencias, ue es tambi$n wiHi
http(PPwww.programacione+trema.orgP =13> y un Rrupo de -iscusin en Dahoo
=1N>.
)etodologas de -esarrollo de /oftware 0giles .!gina 1: de 23
<9 #a =a%ilia de "r!stal de "oc>burn
"listair CocHburn =1O> ha estado traba&ando en metodologas desde ue
la 4W) le encarg escribir sobre metodologas a inicios de los Z:;. *o obstante,
su acercamiento no es como la mayora de los metodologistas. En lugar de
partir solamente de su e+periencia personal para construir una teora de cmo
deben hacerse las cosas, $l complementa su e+periencia directa con la
b,sueda activa de proyectos y ver cmo traba&an. "dem!s $l no teme alterar
sus puntos de vista con base en sus descubrimientos.
/u libro, 5/obreviviendo .royectos 9rientados a 9b&etos6 =1:>, fue su
primer conse&o en proyectos corrientes, y sigue siendo una primera
recomendacin de libro para e&ecutar proyectos iterativos. )!s recientemente
"listair CocHburn escribi un libro de apreciacin de 5-esarrollo de /oftware
0gil6 =?;> ue mira los principios subyacentes de este tipo de metodologas.
-esde ese libro $l ha e+plorado m!s los m$todos !giles, viniendo con la
familia de metodologas Cristal =?1>. Es una familia porue $l cree ue los tipos
diferentes de proyectos reuieren tipos diferentes de metodologas. Kl mira
esta variacin a lo largo de dos e&es(
el n,mero de personas en el proyecto, y
las consecuencias de los errores.
Cada metodologa enca&a en una parte diferente de la re&a, de modo ue
para un proyecto de J; personas ue puede perder dinero discrecionalmente
tiene una metodologa diferente a la de un proyecto vital de seis personas.
Crystal comparte con L. una orientacin humana, pero esta
centralizacin en la gente se hace de una manera diferente. "listair CocHburn
considera ue las personas encuentran difcil seguir un proceso disciplinado,
as ue m!s ue seguir la alta disciplina de L., "listair CocHburn e+plora la
metodologa menos disciplinada ue aun podra tener $+ito, intercambiando
conscientemente productividad por facilidad de e&ecucin. Kl considera ue
aunue Crystal es menos productivo ue L., m!s personas ser!n capaces de
seguirlo.
"listair CocHburn tambi$n pone mucho peso en las revisiones al final de
la iteracin, animando al proceso a ser auto me&orante. /u asercin es ue el
desarrollo iterativo est! para encontrar los problemas temprano, y entonces
permitir corregirlos. Esto pone m!s $nfasis en la gente supervisando su
proceso y afin!ndolo conforme desarrollan.
?9 Software de "digo Abierto 5.SS7
Este ttulo podra sorprender. -espu$s de todo el cdigo abierto 89/ por
su sigla en ingl$s de 9pen /ource< es un estilo de software, no tanto un
proceso. /in embargo hay una manera definida de hacer las cosas en la
)etodologas de -esarrollo de /oftware 0giles .!gina ?; de 23
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 euipos de traba&o fsicamente distribuidos, lo ue es
importante porue la mayora de los procesos adaptables e+igen euipos
locales.
#a mayora de los proyectos de cdigo abierto tienen uno o m!s
mantenedores. @n mantenedor es la ,nica persona a la ue se le permite
integrar un cambio en el almac$n de cdigo fuente. /in embargo otras
personas pueden hacer cambios a la base del cdigo. #a diferencia importante
es ue estas otras personas necesitan enviar su cambio al mantenedor ue
entonces lo revisa y lo aplica a la base del cdigo. *ormalmente estos cambios
son hechos en forma de archivos de parches ue hacen este proceso m!s f!cil.
"s, el mantenedor es responsable de coordinar los parches y mantener la
cohesin en el diseo del software.
.royectos diferentes mane&an el papel del mantenedor de diferentes
maneras. "lgunos tienen un mantenedor para el proyecto entero, algunos lo
dividen en mdulos y tiene un mantenedor por mdulo, algunos rolan el
mantenedor, algunos tienen m,ltiples mantenedores sobre el mismo cdigo,
otros tienen una combinacin de estas ideas. #a mayor parte de la gente de
cdigo abierto son de tiempo parcial, as ue hay una duda en u$ tan bien se
coordina un euipo as para un proyecto de tiempo completo.
@n rasgo particular del desarrollo de cdigo abierto es ue la depuracin
es altamente paralelizable. )uchas 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 ue la mayor
parte del tiempo se gasta en encontrar bugs. %ambi$n es bueno para gente sin
mucha destreza en programacin.
El proceso para el cdigo abierto aun no se ha documentado bien. #a
referencia m!s famosa es el artculo de Eric Iaymond 5#a Catedral y el Wazar6
=??>, ue aunue es una descripcin e+celente tambi$n es bastante informal. El
libro de Sarl Qogel sobre 5-esarrollo de Cdigo "bierto con CX/6 =?2>, tambi$n
contiene varios buenos captulos sobre el proceso de cdigo abierto ue
incluso seran interesantes para auellos ue no uieren usar el CX/. CX/ son
las siglas de Concurrent Xersions /ystem 8/istema de Xersiones
Concurrentes<, un sistema cliente7servidor ue permite a los desarrolladores
realizar el seguimiento de las diferentes versiones del cdigo fuente de un
proyecto. /e trata de una herramienta muy potente ue facilita(
Iegistrar todos los cambios efectuados sobre los archivos de un
proyecto.
Iecuperar versiones anteriores del cdigo de un proyecto.
Conocer u$ cambios se han efectuado sobre un archivo determinado,
ui$n los ha realizado y cu!ndo.
)etodologas de -esarrollo de /oftware 0giles .!gina ?1 de 23
Restionar los conflictos ue pueden producirse en entornos en los ue
los desarrolladores se encuentran distribuidos geogr!ficamente.
El CX/ es especialmente ,til cu!ndo m!s de una persona traba&a sobre
un archivo especfico. En tales situaciones, es posible ue un desarrollador
sobreescriba accidentalmente los cambios ue ha realizado otro desarrollador.
CX/ resuelve este problema haciendo ue cada desarrollador traba&e sobre su
propia copia del cdigo 8lo ue se denomina workspace o espacio de traba&o< y
permitiendo posteriormente unir los cambios de todos los desarrolladores en un
repositorio com,n =?J>.
@9 (l Desarrollo de Software Adaptable 5ASD7 de AigBs%itB
Gim 'ighsmith =?F> ha pasado muchos aos traba&ando con
metodologas predictivas. Kl las desarroll, instal, ense, y concluy ue son
profundamente defectuosas( particularmente para los negocios modernos.
/u reciente libro 5"daptive /oftware -evelopment6 =?3> se enfoca en la
naturaleza adaptable de las nuevas metodologas, con un $nfasis particular en
aplicar las ideas ue se originaron en el mundo de los sistemas comple&os
adaptables 8normalmente conocida como teora del caos<. *o proporciona el
tipo de pr!cticas detalladas como lo hace L., pero proporciona la base
fundamental de por u$ el desarrollo adaptable es importante y las
consecuencias a los m!s profundos niveles de la organizacin y la gerencia.
En el corazn del "/- hay tres fases solapadas, no lineales(
especulacin, colaboracin, y aprendiza&e.
Gim 'ighsmith ve la planificacin como una parado&a en un ambiente
adaptable, ya ue los resultados son naturalmente imprevisibles. En la
planificacin tradicional, las desviaciones del plan son errores ue deben
corregirse. En un ambiente adaptable, en cambio, las desviaciones nos guan
hacia la solucin correcta.
En este ambiente imprevisible se necesita ue las personas colaboren
de la me&or manera para tratar con la incertidumbre. #a atencin de la gerencia
es menor en lo ue tiene ue hacer la gente, y mayor sobre la comunicacin
alentadora para ue las personas puedan proponer las respuestas creativas
ellos mismos.
En ambientes predictivos, el aprendiza&e se desalienta a menudo. #as
cosas se ponen de antemano y entonces se sigue ese diseo.
En un ambiente adaptable, aprender desafa a todos 7 desarrolladores y
sus clientes 7 a e+aminar sus presunciones y usar los resultados de cada ciclo
de desarrollo para adaptar el siguiente. El aprendiza&e como tal es un rasgo
continuo e importante, ue asume ue los planes y los diseos deben cambiar
conforme avanza el desarrollo.
)etodologas de -esarrollo de /oftware 0giles .!gina ?? de 23
El beneficio atropellado, poderoso, indivisible y predominante del Ciclo
de Xida de -esarrollo "daptable es ue obliga a confrontar los modelos
mentales ue est!n en la raz del autoengao de las personas. 9bliga a las
personas a estimar con realismo su habilidad. Con este $nfasis, el traba&o de
Gim 'ighsmith se enfoca directamente en fomentar las partes difciles del
desarrollo adaptable, en particular cmo fomentar la colaboracin y el
aprendiza&e dentro del proyecto. Como tal, su libro ayuda a dar ideas para
fomentar estas !reas "suaves" ue hacen un buen complemento a los
acercamientos basados en una pr!ctica aterrizada como L., Q-- y Crystal.
C9 Scru%
/crum se enfoca en el hecho de ue procesos definidos y repetibles slo
funcionan para atacar problemas definidos y repetibles con gente definida y
repetible en ambientes definidos y repetibles.
/crum divide un proyecto en iteraciones 8ue ellos llaman carreras
cortas< de 2; das. "ntes de ue comience una carrera se define la
funcionalidad reuerida para esa carrera y entonces se de&a al euipo para ue
la entregue. El punto es estabilizar los reuisitos durante la carrera.
/in embargo la gerencia no se desentiende durante la carrera corta.
%odos los das el euipo sostiene una reunin corta 8uince minutos<, llamada
scrum, dnde el euipo discurre lo ue har! al da siguiente. En particular
muestran a los bloues de la gerencia( los impedimentos para progresar ue se
atraviesan y ue la gerencia debe resolver. %ambi$n informan lo ue se ha
hecho para ue la gerencia tenga una actualizacin diaria de dnde va el
proyecto.
#a literatura de /crum 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 pr!cticas de cdigo
de L..
-espu$s de mucho tiempo sin un libro, finalmente Sen /chwaber y )iHe
Weedle escribieron el primer libro de /crum ue lo llamaron 5"gile /oftware
-evelopment with /crum6 =?N>. .robablemente la me&or apreciacin global
sobre /CI@) est! en el sitio http(PPwww.controlchaos.com =?O> de Sen
/chwaber. Geff /utherland siempre ha tenido un sitio web activo sobre temas
de tecnologas de ob&etos e incluye una seccin sobre /crum =?:>. 'ay tambi$n
una buena apreciacin global de las pr!cticas de /crum en el libro de *eil
'arrison, Wrian Qoote, 'ans Iohnert titulado 5.attern #anguages of .rogram
-esign J 8/oftware .atterns /eries<5 =2;>. /crum tiene una lista de discusin en
Dahoo en la @I# http(PPgroups.yahoo.comPgroupPscrumdevelopment =21>.
)etodologas de -esarrollo de /oftware 0giles .!gina ?2 de 23
D9 Desarrollo Mane-ado por &asgos 5=DD7
El -esarrollo )ane&ado por Iasgos 8Q-- por su sigla en ingl$s de
Qeature7-riven -evelopment< fue desarrollado por Geff -e #uca y el vie&o gur,
de la 9rientacin a 9b&etos .eter Coad. Como las otras metodologas
adaptables, se enfoca en iteraciones cortas ue entregan funcionalidad
tangible. En el caso del Q-- las iteraciones duran dos semanas.
El Q-- tiene cinco procesos. #os primeros tres se hacen al principio del
proyecto.
-esarrollar un )odelo Rlobal
Construir una #ista de los Iasgos
.lanear por Iasgo
-isear por Iasgo
Construir por Iasgo
#os ,ltimos dos se hacen en cada iteracin. Cada proceso se divide en
tareas y se da un criterio de comprobacin.
#os desarrolladores entran en dos tipos(
dueos de clases, y
programadores &efe.
#os programadores &efe son los desarrolladores m!s e+perimentados. "
ellos se les asignan rasgos a construir. /in embargo ellos no los construyen
solos. /lo identifican u$ clases se involucran en la implantacin de un rasgo
y &untan a los dueos de dichas clases para ue formen un euipo para
desarrollar ese rasgo. El programador &efe act,a como el coordinador,
diseador lder y mentor, mientras los dueos de clases hacen gran parte de la
codificacin del rasgo.
'asta recientemente, la documentacin sobre Q-- era muy escasa.
Qinalmente hay un libro completo sobre Q-- titulado 5" .ractical Ruide to
Qeature7-riven -evelopment 8%he Coad /eries<6 de la autora de /tephen I
.almer y Gohn ). Qelsing =2?>. Geff -e #uca, el inventor primario, ya tiene un
portal Q-- en la @I# http(PPwww.featuredrivendevelopment.com =22>, con
artculos, blogs y foros de discusin. #a descripcin original estaba en el libro
5Gava )odeling 4n Color Yith @)#6 de .eter Coad et al =2J>. /u compaa,
%ogether/oft =2F>, tambi$n da consultora y entrenamiento en Q--.
)etodologas de -esarrollo de /oftware 0giles .!gina ?J de 23
E9 DSDM 5Mtodo de Desarrollo de Siste%a DinF%ico7
El -/-) 8-ynamic /ystems -evelopment )ethod< =23> empez en
Rran Wretaa en 1::J como un consorcio de compaas del Ieino @nido ue
ueran construir sobre I"- 8Iapid "pplications -evelopment< -esarrollo
I!pido de "plicaciones y desarrollo iterativo. 'abiendo empezado con 1N
fundadores ahora tiene m!s de mil miembros y ha crecido fuera de sus races
brit!nicas. /iendo desarrollado por un consorcio, tiene un sabor diferente a
muchos de los otros m$todos !giles. %iene una organizacin de tiempo
completo ue lo apoya con manuales, cursos de entrenamiento, programas de
certificacin y dem!s. .ero, tambi$n lleva una etiueta de precio, lo cual ha
limitado la investigacin popular sobre su metodologa. /in embargo, Gennifer
/tapleton ha escrito el libro 5-/-)6 =2N> ue da una apreciacin global de la
metodologa.
El m$todo empieza con un estudio de viabilidad y negocio. El estudio de
viabilidad considera si -/-) 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. %ambi$n propone esbozos de aruitecturas del
sistema y un plan del proyecto.
El resto del proceso forma tres ciclos entrete&idos(
el ciclo del modelo funcional produce documentacin de an!lisis 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.
-/-) tiene principios subyacentes ue incluyen una interaccin activa
del usuario, entregas frecuentes, euipos autorizados, pruebas a lo largo del
ciclo. 4gual ue otros m$todos !giles, usan ciclos de plazos cortos de entre dos
y seis semanas. 'ay un $nfasis en la alta calidad y adaptabilidad hacia
reuisitos cambiantes.
*o hay mucha evidencia de su uso fuera del Ieino @nido, pero -/-)
es notable por tener mucha de la infraestructura de las metodologas
tradicionales m!s maduras, al mismo tiempo ue sigue los principios de los
m$todos !giles.
G9 (s &,P un %todo Fgil?
/iempre ue se discuten m$todos 99, inevitablemente se llega a
Iational @nified .rocess =2O>. El .roceso @nificado fue desarrollado como el
proceso complementario al @)#. El I@. es un armazn de proceso y como tal
puede acomodar una gran variedad de procesos. -e hecho $sta es la crtica
principal al I@. por parte de algunos autores( como puede ser cualuier cosa
)etodologas de -esarrollo de /oftware 0giles .!gina ?F de 23
acaba siendo nada. .refieren un proceso ue diga u$ hacer en lugar de dar
opciones infinitas.
Como resultado de esta mentalidad de armazn de procesos, el I@.
puede usarse en un estilo muy tradicional de cascada o de una manera !gil.
Como resultado se puede usar el I@. como un proceso !gil, o como un
proceso pesado 7 todo depende de cmo lo adapte a su ambiente.
Craig #arman es un fuerte defensor de usar el I@. de una manera !gil.
/u libro 5"pplying @)# and .atterns6 =2:> sobre desarrollo 99 contiene un
proceso ue est! muy basado en su pensamiento ligero del I@.. /u visin es
ue mucho del reciente empu&n hacia los m$todos !giles no es nada m!s ue
aceptar desarrollo 99 de la corriente principal ue ha sido capturada como
I@.. @na de las cosas ue hace Craig #arman es pasarse los primeros dos o
tres das de una iteracin mensual con todo el euipo usando el @)# para
perfilar el diseo del traba&o a hacerse durante la iteracin. Esto no es una
norma de la ue no pueda desviarse, sino un boceto ue da una perspectiva
sobre cmo pueden hacerse las cosas en la iteracin.
9tra punta en el I@. !gil es el proceso dL de Iobert )artin =J;>. El
proceso dL es una versin totalmente dcil del I@. ue simplemente es
id$ntico a L. 8girar dL ciento ochenta grados para ver la broma<. El dL est!
diseado para gente ue tiene ue usar el I@. pero uiere usar L.. Como tal
es a la vez L. y I@. y por tanto un buen e&emplo del uso !gil del I@..
/eg,n los crticos, una de las cosas claves ue necesita el I@. es ue
los lderes del I@. en la industria enfaticen su acercamiento al desarrollo de
software. )!s de una vez se oye a la gente ue usa el I@. hablando ue
est!n usando un proceso de desarrollo estilo cascada. .hilippe Sruchten y su
euipo son firmes creyentes en el desarrollo iterativo. Clarificando estos
principios y animando las versiones !giles del I@. tales como los traba&os de
Craig #arman y de Iobert )artin tendr! un efecto importante.
H9 #ean Develop%ent 5#D7 ! #ean Software Develop%ent 5#SD7
#ean -evelopment 8#-< es el m$todo menos divulgado entre los
reconocidamente importantes. #a palabra 5lean6 significa magro, en&utoM en su
sentido t$cnico apareci por primera vez en 1::; en el libro de Games YomacH
#a )!uina ue Cambi al )undo =J1>. #-, iniciado por Wob Charette =J?>, se
inspira en el $+ito del proceso industrial #ean )anufacturing, bien conocido en
la produccin automotriz y en manufactura desde la d$cada de 1:O;. Este
proceso tiene como precepto la eliminacin de residuos a trav$s de la me&ora
constante, haciendo ue el producto fluya a instancias del cliente para hacerlo
lo m!s perfecto posible. #os presentes conceptos han sido e+trados de Carlos
Ieynoso =J2>.
#os procesos a la manera americana corran con sus m!uinas al 1;;E
de capacidad y mantenan inventarios gigantescos de productos y suministrosM
%oyota, en contra de la intuicin, resultaba m!s eficiente manteniendo
)etodologas de -esarrollo de /oftware 0giles .!gina ?3 de 23
suministros en planta para un solo da, y produciendo slo lo necesario para
cubrir las rdenes pendientes. Esto es lo ue se llama Gust in %ime .roduction.
Con G4% se evita adem!s ue el inventario degrade o se torne obsoleto, o
empiece a actuar como un freno para el cambio. %oyota implementaba adem!s
las t$cnicas innovadoras del %otal Buality )anagement de Edward -eming,
ue slo algunos matem!ticos y empresarios de avanzada conocan en
Estados @nidos. 'asta el da de hoy la foto de -eming en %oyota es m!s
grande y esplendorosa ue la del fundador, %oyoda /aHichi.
9tros aspectos esenciales de #ean )anufacturing son la relacin
participativa con el empleado y el trato ue le brinda la compaa, as como una
especificacin de principios, disciplinas y m$todos iterativos, adaptativos, auto7
organizativos e interdependientes en un patrn de ciclos de corta duracin ue
tiene algo m!s ue un aire de familia con el patrn de procesos de los )$todos
0giles. E+iste unanimidad de intereses, consistencia de discurso y
complementariedad entre las comunidades #ean de manufactura y desarrollo
de software.
)ientras ue otros )" se concentran en el proceso de desarrollo, Wob
Charette sostena ue para ser verdaderamente !gil se deba conocer adem!s
el negocio de punta a punta. #- se inspira en doce valores centrados en
estrategias de gestin =JJ>(
1. /atisfacer al cliente es la m!+ima prioridad.
?. .roporcionar siempre el me&or valor por la inversin.
2. El $+ito depende de la activa participacin del cliente.
J. Cada proyecto #- es un esfuerzo de euipo.
F. %odo se puede cambiar.
3. /oluciones de dominio, no puntos.
N. Completar, no construir.
O. @na solucin al O;E hoy, en vez de una al 1;;E maana.
:. El minimalismo es esencial.
1;. #a necesidad determina la tecnologa.
11. El crecimiento del producto es el incremento de sus prestaciones, no
de su tamao.
1?. *unca empu&es #- m!s all! de sus lmites.
-ado ue #- es m!s una filosofa de management ue un proceso de
desarrollo no hay mucho ue decir del tamao del euipo, la duracin de las
iteraciones, los roles o la naturaleza de sus etapas. [ltimamente #- ha
)etodologas de -esarrollo de /oftware 0giles .!gina ?N de 23
evolucionado como #ean /oftware -evelopment 8#/-<M su figura de referencia
es )ary .oppendiecH =JF>.
4gual ue "gile )odeling 8")<, ue cubra sobre todo aspectos de
modelado y documentacin, #- y #/- han sido pensados como complemento
de otros m$todos, y no como una metodologa e+cluyente a implementar en la
empresa. #- prefiere concentrarse en las premisas y modelos derivados de
#ean .roduction, ue hoy constituyen lo ue se conoce como el canon de la
Escuela de *egocios de 'arvard. .ara las t$cnicas concretas de
programacin, #- promueve el uso de otros )" ue sean consistentes con su
visin, como L. o sobre todo /crum.
"unue la formulacin del m$todo es relativamente reciente, la
familiaridad de muchas empresas con los principios de #ean .roduction U #ean
)anufacturing ha facilitado la penetracin en el mercado de su an!logo en
ingeniera de software.
8I9 Agile Modeling
"gile )odeling 8")< fue propuesto por /cott "mbler =J3> no tanto como
un m$todo !gil cerrado en s mismo, sino como complemento de otras
metodologas, sean $stas !giles o convencionales. En el caso de L. los
practicantes podran definir me&or los procesos de modelado ue en ellos
faltan, y en el caso de I@. el modelado !gil permite hacer m!s ligeros los
procesos ue ya usan. ") es una estrategia de modelado 8de clases, de datos,
de procesos< pensada para contrarrestar la sospecha de ue los m$todos
!giles no modelan y no documentan. /e lo podra definir como un proceso de
software basado en pr!cticas cuyo ob&etivo es orientar el modelado de una
manera efectiva y !gil.
#os principales ob&etivos de ") son(
1. -efinir y mostrar de u$ manera se debe poner en pr!ctica una
coleccin de valores, principios y pr!cticas ue conducen al
modelado de peso ligero.
?. Enfrentar el problema de la aplicacin de t$cnicas de modelado en
procesos de desarrollo !giles.
2. Enfrentar el problema de la aplicacin de las t$cnicas de modelado
independientemente del proceso de software ue se utilice.
#os valores de ") incluyen a los de L.( comunicacin, simplicidad,
feedbacH y cora&e, aadiendo humildad. @na de las me&ores caracterizaciones
de los principios subyacentes a ") est! en la definicin de sus alcances(
1. ") es una actitud, no un proceso prescriptivo. Comprende una
coleccin de valores a los ue los modeladores !giles adhieren,
)etodologas de -esarrollo de /oftware 0giles .!gina ?O de 23
principios en los ue creen y pr!cticas ue aplican. -escribe un estilo
de modeladoM no es un recetario de cocina.
?. ") es suplemento de otros m$todos. El primer foco es el modelado y
el segundo la documentacin.
2. ") es una tarea de con&unto de los participantes. *o hay 5yo6 en ").
J. #a prioridad es la efectividad. ") ayuda a crear un modelo o proceso
cuando se tiene un propsito claro y se comprenden las necesidades
de la audienciaM contribuye a aplicar los artefactos correctos para
afrontar la situacin inmediata y a crear los modelos m!s simples ue
sea posible.
5. ") es algo ue funciona en la pr!ctica, no una teora acad$mica. #as
pr!cticas han sido discutidas desde ?;;1 en comunidad
8http(PPwww.agilemodeling.comPfeedbacH.htm<.
3. ") no es una bala de plata.
N. ") es para el programador promedio, pero no reemplaza a la gente
competente.
O. ") no es un ataue a la documentacin. #a documentacin debe ser
mnima y relevante.
:. ") no es un ataue a las herramientas C"/E.
1;. ") no es para cualuiera.
#os principios de ") especificados por /cott "mbler incluyen(
1. Presuponer si%plicidad. #a solucin m!s simple es la me&or.
?. (l contenido es %Fs i%portante 'ue la representacin. .ueden
ser notas, pizarras o documentos formales. #o ue importa no es el
soporte fsico o la t$cnica de representacin, sino el contenido.
2. Abra/ar el ca%bio9 "ceptar ue los reuerimientos cambian.
J. Aabilitar el esfuer/o siguiente9 Rarantizar ue el sistema es
suficientemente robusto para admitir me&oras ulterioresM debe ser un
ob&etivo, pero no el primordial.
F. 6odo el %undo puede aprender de algJn otro. Ieconocer ue
nunca se domina realmente algo.
3. "a%bio incre%ental. *o esperar hacerlo bien la primera vez.
N. "onocer tus %odelos9 /aber cu!les son sus fuerzas y sus
debilidades.
)etodologas de -esarrollo de /oftware 0giles .!gina ?: de 23
O. Adaptacin local. .roducir slo el modelo ue resulte suficiente
para el propsito.
H9 Ma:i%i/ar la inversin del cliente9
1;. Modelar con un propsito9 /i no se puede identificar para u$ se
est! haciendo algo Apara u$ molestarseC
11. Modelos %Jltiples9 ),ltiples paradigmas en convivencia, seg,n se
reuiera.
8<9 "o%unicacin abierta ! Bonesta9
8?9 6raba-o de calidad9
1J. &eali%entacin rFpida9 *o esperar ue sea demasiado tarde.
1F. (l software es el ob-etivo pri%ario9 -ebe ser de alta calidad y
coincidir con lo ue el usuario espera.
13. Kia-ar ligero de e'uipa-e9 *o crear m!s modelos de los necesarios.
1N. 6raba-ar con los instintos de la gente.
#o m!s concreto de ") es su rico con&unto de pr!cticas =JN>, cada una
de las cuales se asocia a lineamientos decididamente narrativos, articulados
con minuciosidad, pero muy le&os de los rigores cuantitativos(
1. Colaboracin activa de los participantes.
?. "plicacin de est!ndares de modelado.
2. "plicacin adecuada de patrones de modelado.
J. "plicacin de los artefactos correctos.
F. .ropiedad colectiva de todos los elementos.
3. Considerar la verificabilidad.
N. Crear diversos modelos en paralelo.
O. Crear contenido simple.
:. -isear modelos de manera simple.
1;. -escartar los modelos temporarios.
11. E+hibir p,blicamente los modelos.
1?. Qormalizar modelos de contrato.
)etodologas de -esarrollo de /oftware 0giles .!gina 2; de 23
12. 4terar sobre otro artefacto.
1J. )odelo en incrementos peueos.
1F. )odelar para comunicar.
13. )odelar para comprender.
1N. )odelar con otros.
1O. .oner a prueba con cdigo.
1:. Ieutilizar los recursos e+istentes.
?;. "ctualizar slo cuando duele.
?1. @tilizar las herramientas m!s simples 8C"/E, o me&or pizarras,
tar&etas, post7its<.
Como ") se debe usar como complemento de otras metodologas, nada
se especifica sobre m$todos de desarrollo, tamao del euipo, roles, duracin
de iteraciones, traba&o distribuido y criticidad, todo lo cual depender! del
m$todo ue se utilice.
#os diagramas de @)# y los artefactos del .roceso @nificado, por
e&emplo, han sido e+plorados en e+tremo detalle describiendo cmo debera
ser su tratamiento en un proceso !gil E@.. E@. es simplemente @.\").
889 Prag%atic Progra%%ing 5PP7
El ttulo en realidad no es totalmente cierto, ya ue no hay un m$todo
llamado programacin pragm!tica, sino ue e+iste un con&unto muy interesante
de las me&ores pr!cticas de programacin publicadas en el libro 5%he .ragmatic
.rogrammer6 =JO>, pero por practicidad se lo llama .rogramacin .ragm!tica
=J:>.
#a .. no tiene proceso, fases, roles distintos productos de traba&o.
Este )" cubre, sin embargo, la mayora de las me&ores pr!cticas de
programacin. 'ay un total de N; recomendaciones ue se enfocan en los
problemas del da a da, pero la filosofa por detr!s de esto es ue son
universales y pueden ser aplicadas a cualuier fase del desarrollo de software.
#a filosofa est! definida en 3 puntos(
1. %ome las responsabilidades para @d., piense en soluciones en lugar
de estar pensando en e+cusas.
?. *o disee o codifiue mal, arregle las inconsistencias o planee
arreglarlas tan pronto como sea posible.
)etodologas de -esarrollo de /oftware 0giles .!gina 21 de 23
2. %ome un rol activo para introducir cambios donde @d. vea ue son
necesarios.
J. 'aga software ue satisfaga a su cliente, pero sepa cu!ndo parar.
F. Constantemente ample su conocimiento.
3. )e&ore sus habilidades de comunicacin.
-esde un punto de vista !gil, la mayora de las pr!cticas m!s
interesantes se enfocan sobre el desarrollo iterativo, incremental, testing
riguroso y diseo centrado en el usuario. El enfoue tiene un punto de vista
muy pr!ctico, y la mayora de las pr!cticas son ilustradas con e&emplos
positivos y negativos, a menudo complementados con preguntas y trocitos de
cdigo. Es un esfuerzo considerable e+plicar cmo disear e implementar
software tal ue pueda resistir cambios. @na de las soluciones ue se plantean
para mantener software a trav$s de los cambios es la refactorizacin.
El enfoue de la .rogramacin .ragm!tica respecto del testing consiste
en testear el cdigo ue est! siendo implementado sobre el cdigo real, y todos
los testeos deben ser hechos en forma autom!tica. #a idea es ue 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.
#a automatizacin se encuentra en la .. en algunas otras tareas
tambi$n. -e hecho llega a sugerir 5*o use procedimientos manuales6. .or
e&emplo, en la creacin de la primera documentacin de cdigo fuente y en la
creacin de cdigo de las definiciones de la base de datos.
Iecomienda conservar las especificaciones a un nivel razonable de
detalle. #a .. demuestra pr!cticas de software simples, responsables y
disciplinadas. #a pr!cticas sugeridas en .. son escritas desde el punto de
vista de un programador, independientemente de los m$todos o procesos ue
se utilicen, para evitar errores tpicos en la codificacin y en el diseo y errores
de comunicacin en el grupo de traba&o.
6esting Dirigido por el "onte:to
-esde el principio han sido los desarrolladores de software uienes han
conducido a la comunidad !gil. /in embargo muchas otras personas envueltas
en el desarrollo de software son afectadas por este nuevo movimiento. @n
grupo obvio es el de los verificadores, ue a menudo viven en un mundo
dominado por el pensamiento de cascada. Con pautas comunes ue declaran
ue 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! le&os de ser claro.
)etodologas de -esarrollo de /oftware 0giles .!gina 2? de 23
Xarias 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 5testing conducido por
el conte+to6. #a me&or descripcin es el libro 5#essons #earned in /oftware
%esting6, cuyos autores son Cem Saner, Games Wach y Wret .ettichord =F;>.
#a comunidad de testing de software es tambi$n muy activa, teniendo
sus sitios en la web Wrian )aricH =F1> 8uno de los autores del manifiesto !gil<,
Wret .ettichord =F?>, Games Wach =F2> y Cem Saner =FJ>.
Debe usted ir a lo Fgil?
#os p!rrafos siguientes son e+tractados de =:>.
El uso de un m$todo !gil no es para todos. 'ay ue tener en cuenta
varias cosas si se decide a seguir por este camino. /in embargo yo creo
ciertamente ue estas nuevas metodologas son e+tensamente aplicables y
deben ser usadas por m!s personas de las ue actualmente lo consideran.
En el ambiente actual, la metodologa m!s com,n es codifica y corrige.
"plicar m!s disciplina ue caos casi seguramente ayudar!, y el acercamiento
!gil tiene la venta&a de ue es mucho menos de un paso ue un m$todo
pesado. )ucha de la venta&a de los m$todos !giles es de hecho su peso ligero.
#os procesos m!s simples son m!s probables de ser seguidos cuando uno no
est! acostumbrado a ning,n proceso en absoluto.
@na de las limitaciones m!s grandes de estas nuevas metodologas es
cmo mane&an euipos m!s grandes. Como muchas nuevas tendencias, ellos
tienden a ser usados primero a escala peuea antes ue a gran escala.
%ambi$n a menudo se han creado con $nfasis en euipos peueos. #a L.
e+plcitamente dice ue est! diseada para euipos de no m!s de veinte
personas. 'ay ue recordar ue muchos euipos de software pueden reducirse
en tamao sin reducir su productividad total.
9tras tendencias !giles est!n destinadas a euipos m!s grandes. #a
Q-- fue diseada originalmente para un proyecto de cincuenta personas.
%houghtYorHs ha usado proyectos influidos por la L. con euipos de cerca de
1;; en tres continentes. /crum se ha usado para mane&ar tamaos similares.
Esperanzadoramente un mensa&e ue ueda claro en este artculo es
ue los acercamientos adaptables son buenos cuando sus reuisitos son
inciertos o vol!tiles. /i usted no tiene reuisitos 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! m!s
eficaz. " menudo la barrera m!s grande au es el cliente. Como yo lo veo es
importante para el cliente entender ue seguir un proceso predictivo cuando los
reuisitos cambian es arriesgado tanto para ellos como para el desarrollo.
)etodologas de -esarrollo de /oftware 0giles .!gina 22 de 23
/i usted va a tomar la ruta adaptable, necesita confiar en sus
desarrolladores e involucrarlos en la decisin. #os procesos adaptables
cuentan en ue usted confa en sus desarrolladores, de modo ue si usted
considera a sus desarrolladores de ba&a calidad y motivacin, usted debe usar
un acercamiento predictivo.
.ara resumir. #os siguientes factores sugieren un proceso adaptable
Ieuisitos inciertos o vol!tiles
-esarrolladores responsables y motivados
Clientes ue entienden y se involucrar!n.
Estos factores sugieren un proceso predictivo
@n euipo de m!s de cien
@n precio fi&o, o m!s correctamente un alcance o contrato fi&o
&eferencias
=1> Elisa Rallo, )iHel Xergara, European /oftware 4nstitute,
http(PPwww.esi.esPWerriHuntza
=?> /teve )cConnell, 5Iapid -evelopment6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P1FF31F:;;FPprogramacione7
?;
=2> "listair CocHburn, 5Characterizing .eople as *on7#inear, Qirst79rder
Components in /oftware -evelopment6,
http(PPalistair.cocHburn.usPcrystalParticlesPcpanfocisdPcharacterizingpeople
asnonlinear.html
=J> Iobert -. "ustin, 5)easuring and )anaging .erformance in
9rganizations6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;:2?322233P1;J7N11NOJ?7
N:;1F22Pprogramacione7?;P1;?7J3ONOO27:F?O:JO
=F> *orman #. Serth, http(PPc?.comPpprPaboutPauthorPnorm.html
=3> "lianza 0gil, http(PPwww.agilealliance.org
[7] .atricio #etelier, -epartamento de /istemas 4nform!ticos y Computacin,
@niversidad .olit$cnica de Xalencia, letelier]dsic.upv.es
=O> )anifiesto para el -esarrollo de /oftware 0gil,
http(PPwww.agilemanifesto.org
=:> )artn Qowler, #a *ueva )etodologa, http(PPwww.programacion.net
=1;> Sent WecH, 5E+treme .rogramming E+plained6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;?;1313J13Pprogramacione7
?;
)etodologas de -esarrollo de /oftware 0giles .!gina 2J de 23
=11> Ion Geffries http(PPwww.+.rogramming.com
=1?> -on Yells http(PPwww.e+treme.rogramming.org
=12> Yard Cunningham, p!gina wiHi, http(PPc?.comPcgiPwiHiC
E+treme.rogrammingIoadmap
=1J> Rrupo de -iscusin L.,
http(PPwww.egroups.comPgroupPe+tremeprogramming
=1F> )arH .aulH, 5L. desde la .erspectiva del C))6,
http(PPwww.sei.cmu.eduPcmmPpapersP+p7cmm7paper.pdf
=13> http(PPwww.programacione+trema.org
=1N> Rrupo de -iscusin en Dahoo, http(PPgroups.yahoo.comPgroupP+pspanish
=1O> "listair CocHburn, http(PPmembers.aol.comPacocHburn
=1:> "listair CocHburn, 5/obreviviendo .royectos 9rientados a 9b&etos6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;?;1J:O2J;Pprogramacione7
?;
=?;> "listair, -esarrollo de /oftware 0gil,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;?;13::3::Pprogramacione7
?;
=?1> Crystal, http(PPmembers.aol.comPacocHburnP
=??> Iaymond 5#a Catedral y el Wazar6, http(PPes.tldp.orgP9trosPcatedral7
bazarPcathedral7es7paper7;;.html
=?2> Sarl Qogel, 5-esarrollo de Cdigo "bierto con CX/6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P1FN31;J:;NPprogramacione7
?;
=?J> Qundacin /idar, http(PPwww.sidar.orgPrecurPdesdiPcvs
=?F> Gim 'ighsmith, http(PPwww.adaptivesd.com
=?3> Gim 'ighsmith, 5"daptive /oftware -evelopment6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;:2?322J;JPprogramacione7
?;
=?N> Sen /chwaber y )iHe Weedle, 5"gile /oftware -evelopment with /crum6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;12;3N32J:Pprogramacione7
?;
=?O> Sen /chwaber, http(PPwww.controlchaos.com
=?:> Geff /utherland, http(PP&effsutherland.comPscrumPinde+.html
=2;> *eil 'arrison, Wrian Qoote, 'ans Iohnert 5.attern #anguages of .rogram
-esign J 8/oftware .atterns /eries< 5,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;?;1J22;JJPprogramacione7
?;
=21> /crum, http(PPgroups.yahoo.comPgroupPscrumdevelopment.
=2?> /tephen I .almer, Gohn ). Qelsing, 5" .ractical Ruide to Qeature7-riven
-evelopment 8%he Coad /eries<6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;12;3N31F?Pprogramacione7
?;
=22> Geff -e #uca, Q--, http(PPwww.featuredrivendevelopment.com
=2J> .eter Coad, 5Gava )odeling 4n Color Yith @)#6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;12;11F1;LPprogramacione7
?;P1;?7J3ONOO27:F?O:JO
=2F> %ogether/oft, http(PPwww.togethersoft.com
=23> -/-), http(PPwww.dsdm.org
)etodologas de -esarrollo de /oftware 0giles .!gina 2F de 23
=2N> Gennifer /tapleton, 5-/-)6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;?;11NOO:2Pprogramacione7
?;
=2O> .hilippe Sruchten, 5%he Iational @nified .rocess6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;?;1N;N1;1Pprogramacione7
?;P1;?7J3ONOO27:F?O:JO
=2:> Craig #arman, 5"pplying @)# and .atterns6,
http(PPwww.amazon.comPe+ecPobidosP"/4*P;12NJOOO;NPprogramacione7
?;P1;?7J3ONOO27:F?O:JO
=J;> Iobert )artin,
http(PPwww.ob&ectmentor.comPresourcesParticlesPI@.vsL..pdf
=J1> Games YomacH, -aniel Gones y -aniel Ioos, 5%he machine that
changed the world( %he story of #ean .roduction6, 'arperWusiness,
1::1.
=J?> Iobert Charette, %he Qoundation /eries on IisH )anagement, Xolume 44(
5Qoundations of #ean -evelopment6, Cutter Consortium, "rlington, ?;;1
=J2> Carlos Ieynoso, 5)$todos 'eterodo+os en -esarrollo de /oftware6,
http(PPwww.microsoft.comPspanishPmsdnParuitecturaProadmap^arPhetero
do+.asp
=JJ> Gim 'ighsmith, 5"gile /oftware -evelopment Ecosystems6, Woston,
"ddison Yesley, ?;;?.
=JF> )ary .oppendiecH, 5#ean .rogramming6,
http(PPwww.agilealliance.orgParticlesParticlesP#ean.rogramming.htm, ?;;1.
=J3> /cott "mbler, 5"gile )odeling( Effective practices for E+treme
.rogramming and the @nified .rocess6, Gohn Yiley U /ons, ?;;?.
=JN> /cott "mbler, 5"gile )odeling and the @nified .rocess6,
http(PPwww.agilemodeling.comPessaysPagile)odelingI@..htm, ?;;?.
=JO> "ndrew 'unt, -avid %homas, 5%he .ragmatic .rogrammer( Qrom
Gourneyman to )aster6, http(PPallconsuming.netPitem.cgiC
isbn_;?;1313??L
=J:> .eHHa "brahamsson, 9uti /alo, Gussi IonHainen U Guhani Yarsta, 5"gile
/oftware -evelopment )ethods( Ieview and "nalysis6, X%%, ?;;?
=F;> Cem Saner, Games Wach, Wret .ettichord, 5#essons #earned in /oftware
%esting6, http(PPwww.amazon.comPe+ecPobidosP"/4*P;JN1;O11?JP1;J7
N11NOJ?7N:;1F22Pprogramacione7?;
=F1> Wrian )aricH, %esting Qoundations, http(PPwww.testing.com
=F?> Wret .ettichord, http(PPpettichord.com
=F2> Games Wach, /atisfice, 4nc. http(PPwww.satisfice.com
=FJ> Cem Saner G.-., .h.-., http(PPwww.Haner.comP
)etodologas de -esarrollo de /oftware 0giles .!gina 23 de 23