Programacin extrema

La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos. Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software.

Contenido

1 Valores 2 Caractersticas fundamentales 3 Vase tambin 4 Enlaces externos

[editar] Valores
Los Valores originales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto, fue aadido en la segunda edicin de Extreme Programming Explained. Los cinco valores se detallan a continuacin:

Simplicidad:

La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo simple a medida que crece. Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo debe comentarse en su justa medida, intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, mtodos y clases. Los nombres largos no decrementan la eficiencia del cdigo ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorizacin que existen actualmente. Aplicando la simplicidad junto con la autora colectiva del cdigo y la programacin por parejas se asegura que cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el sistema completo.

Comunicacin:

La comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado. Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un mtodo. Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases y los mtodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que caractersticas tienen prioridad y siempre debe estar disponible para solucionar dudas.

Retroalimentacin (feedback):

Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante. Considrense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El cdigo tambin es una fuente de retroalimentacin gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el cdigo.

Coraje o valenta:

Los puntos anteriores parecen tener sentido comn, entonces, por qu coraje?. Para los gerentes la programacin en parejas puede ser difcil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores est escribiendo cdigo. Hay que ser valiente para confiar en que la programacin por parejas beneficia la calidad del cdigo sin repercutir negativamente en la productividad. La simplicidad es uno de los principios ms difciles de adoptar. Se requiere coraje para implementar las caractersticas que el cliente quiere ahora sin caer en la tentacin de optar por un enfoque ms flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo (frameworks) mientra el cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de desarrollo no recibe retroalimentacin para saber si va en la direccin correcta. La forma de construir marcos de trabajo es mediante la refactorizacin del cdigo en sucesivas aproximaciones.

Respeto:

El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compaeros. Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin

del cdigo. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, sino orientndolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de produccin en el equipo.

[editar] Caractersticas fundamentales

Las caractersticas fundamentales del mtodo son:

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres ltimas inspiradas en JUnit. Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo. Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.

La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores.

La Nueva Metodologa
Martin Fowler Chief Scientist, ThoughtWorks

Texto original: The New Methodology Traduccin: Alejandro Sierra, marzo/abril de 2003. Ultima actualizacin significativa: Abril 2003. Desde hace unos pocos aos ha habido un inters creciente en las metodologas giles (lase "livianas"). Caracterizadas alternativamente como antdoto a la burocracia o licencia para hackear han suscitado inters en el panorama del software. En este ensayo exploro las razones de los mtodos giles, enfatizando no tanto su peso sino su naturaleza adaptativa y su orientacin a la gente. Tambin doy un resumen y referencias a los procesos en esta escuela y considero los factores que deberan influir en su decisin de seguir o no por esta nueva ruta.

De Nada a Monumental a Agil Predictivo contra Adaptable o Separacin de Diseo y Construccin o La Impredecibilidad de los Requisitos o Es Imposible la Previsibilidad? o Controlando un Proceso Imprevisible o El Cliente Adaptable Poniendo a la Gente Primero o Juntar Unidades de Programacin Compatibles o Los Programadores son Profesionales Responsables o Manejando un Proceso Orientado a la Gente o La Dificultad de Medir o El Papel del Liderazgo de Negocio El Proceso Auto-Adaptable Las Metodologas o XP (la Programacin Extrema) o La Familia de Cristal de Cockburn o Cdigo Abierto o El Desarrollo de Software Adaptable de Highsmith o Scrum o Desarrollo Manejado por Rasgos o DSDM (Mtodo de Desarrollo de Sistema Dinmico) o Manifiesto para el Desarrollo de Software gil o Comprobacin Dirigida por el Contexto o Es RUP un mtodo gil? o Otras Fuentes Debe usted irse a lo gil? Reconocimientos

De Nada a Monumental a Agil

Con mucho el desarrollo de software es una actividad catica, frecuentemente caracterizada por la frase "codifica y corrige". El software se escribe con un mnimo un plan subyacente, 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 poner 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 las metodologas ligeras, pero el trmino aceptado ahora es metodologas giles. Para mucha gente el encanto de estas metodologas giles es su reaccin a 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 todos 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. En 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 yo no creo que ste sea 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 grande 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. 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 explorar estas diferencias ms a detalle, para que usted pueda entender lo que es un proceso adaptable y centrado en la gente, sus beneficios y desventajas, y si es algo que debera usar: sea como desarrollador o como cliente de software.

Predictivo contra 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 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, como me considero a m mismo, nos sorprendemos a menudo cuando convertimos 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. McConnell 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. 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 tratar 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 oigo en cada proyecto problemtico con que me he encontrado. Los desarrolladores vienen y me dicen "el problema con este proyecto es que los requisitos cambian todo el tiempo". Lo que yo encuentro sorprendente sobre 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. Usted termina en la situacin dnde quisiera tener un quemacocos en su automvil, pero el vendedor no puede decirle si agrega 10 al costo del automvil, o 10,000. Sin una buena idea del costo, cmo puede usted decidir si quiere pagar por ese quemacocos? La estimacin es difcil por muchas razones. En parte porque el desarrollo de software es una actividad de diseo, difcil de planear y costar. 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 cuando se usa realmente una versin temprana de algn software se empieza a entender qu rasgos son valiosos y cuales 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 estando 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. Aun 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 o 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 transbordador 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 dnde 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 predecible 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 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, no son ciertos ms. 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 cual 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 bugs como las relativas a los requisitos mal entendidos.

El desarrollo iterativo tambin tiene sentido en los procesos predecibles. 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. Cristal estira aun ms. La tendencia, de cualquier modo, es hacer cada iteracin tan corta como se pueda manejar. 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 dnde 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 varie 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 que la calidad del proyecto se mide por la conformidad con el plan. Esto dificulta a la gente sealar cuando 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 - si el cliente consigue 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 papeles 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, apunta a que los procesos predecibles requieren componentes que se 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] me refiero 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. - [Cockburn, non-linear]

Uno se pregunta si no 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 disturbarnos cuando nos enfrentamos con seres humanos. Aunque 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 decisin grande, 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. La historia reciente nos demuestra cada vez ms lo falso que es esto para 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 aqullos 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 puede escoger seguir un proceso adaptable. Esto es particularmente cierto para la XP, que requiere mucha disciplina para ejecutarse. Aqu es donde Cristal 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. 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 dnde 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 objectivas de medir el rendimiento de las personas. This 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 hizo una discusin excelente de 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 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 que est en el centro del punto de vista agilista.

El Papel del Liderazgo de Negocio

Pero los tcnicos no pueden hacer el proceso entero ellos solos. Necesitan una gua en las necesidades comerciales. 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 maneja a nivel gerencial, es algo que est presente para cada desarrollador. Como los desarrolladores son profesionales capaces en su propia disciplina, necesitan poder 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 trabajo duro. 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)

Qu Qu Qu Qu

hicimos bien? hemos aprendido? podemos hacer mejor? es lo que nos confunde?

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 Cristal. 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
Varias metodologas encajan bajo el estandarte de gil. Mientras todas ellas comparten muchas caractersticas, tambin hay algunas diferencias significativas. No puedo

resaltar todos los puntos en este estudio breve, pero por lo menos puedo apuntar a algunos lugares donde buscar. Tampoco puedo hablar con experiencia significativa sobre la mayora de ellas. He trabajado bastante en XP, y he visto el RUP en muchas capas, pero para la mayora de los otros mi conocimiento no es el ms adecuado.
XP (Programacin Extrema)

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 la XP yacen en la comunidad de Smalltalk, y en particular la colaboracin cercana de Kent Beck y Ward Cunningham a finales de los 1980s. Ambos refinaron sus prcticas en numerosos proyectos a principios de los 90s, 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 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 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 la 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, si ninguna otra cosa, que la XP no es garanta de xito.) La XP empieza con cuatro valores: Comunicacin, Retroalimentacin, Simplicidad y Coraje. 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, la XP las teje en un todo sinrgico dnde cada una refuerza a las dems. Una de las ms llamativas, as como inicialmente atractiva para m, es su fuerte nfasis en las pruebas. Mientras todos los procesos mencionan la comprobacin, la mayora lo hace con muy poco nfasis. Sin embargo la 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 refactorar 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, lo que es ms, combina la disciplina con la

adaptabilidad de una manera que indiscutiblemente la hace la ms desarrollada 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 la XP que explica las razones detrs de la metodologa y bastante explicacin 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 la XP, es mejor empezar con dos sitios de ex alumnos del C3: Ron Jeffries xProgramming.com y Don Wells extremeProgramming.org. Mucha de la promocin temprana y desarrollo de ideas de la XP ocurrieron en el ambiente de escritura colaborativa en la pgina wiki de Ward Cunningham. 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. Una de las vistas externas ms interesantes sobre la 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. [Tambin hay referencias en espaol, como el sitio donde se hospeda esta traduccin, que es tambin wiki http://www.programacionextrema.org/ y un grupo de discusin en yahoo. N. del T.]
La Familia de Cristal de Cockburn

Alistair Cockburn ha estado trabajando en metodologas desde que la IBM le encarg escribir sobre metodologas a inicios de los 90. Su acercamiento no es como la mayora de los metodologistas, no obstante. 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 ver cmo trabajan. Adems l no teme alterar sus puntos de vista con base en sus descubrimientos: todo lo cual lo hace mi metodologista favorito. Su libro, Sobreviviendo Proyectos Orientados a Objetos, fue su primer consejo en proyectos corrientes, y sigue siendo mi primera recomendacin de libro para ejecutar proyectos iterativos. Ms recientemente Alistair escribi un libro de apreciacin de desarrollo de software gil 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 Crystal. 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.

Los Cristales comparten con la XP una orientacin humana, pero esta centralizacin en la gente se hace de una manera diferente. Alistair considera que las personas encuentran difcil seguir un proceso disciplinado, as que ms que seguir la alta disciplina de la XP, Alistair explora la metodologa menos disciplinada que aun podra tener xito, intercambiando conscientemente productividad por facilidad de ejecucin. l considera que aunque Cristal es menos productivo que la XP, ms personas sern capaces de seguirlo. Alistair 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.
Cdigo Abierto

Usted puede sorprenderse por este ttulo. Despus de todo el cdigo abierto es un estilo de software, no tanto un proceso. Sin embargo hay una manera definida de hacer las cosas haciendo en la 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 se engrana a equipos fsicamente distribuidos, lo qu 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. El mantenedor as 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 bug 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 escribe bien. La referencia ms famosa es el artculo de Eric Raymond The Catedral and the Bazar, que aunque es una descripcin excelente tambin es bastante informal. El libro de Karl Fogel sobre el almacn de cdigo CVS tambin contiene varios buenos captulos sobre el proceso de cdigo abierto que incluso seran interesantes para aqullos que no quieren hacer una actualizacin cvs.

El Desarrollo de Software Adaptable de Highsmith

Jim Highsmith 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 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 la 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. 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 el ambiente adaptable, sin embargo, 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 asunciones y usar los resultados de cada ciclo de desarrollo para adaptar el siguiente. -[Highsmith]

El aprendizaje como tal es un rasgo continuo e importante, uno que asume que los planes y los diseos deben cambiar conforme avanza el desarrollo.
El beneficio atropellado, poderoso, indivisible y predominante del Ciclo de Vida de Desarrollo Adaptable es que nos obliga a confrontar los modelos mentales que estn en la raz de nuestro autoengao. Nos obliga a estimar con realismo nuestra habilidad. -[Highsmith]

Con este nfasis, el trabajo de 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 Cristal.

Scrum

Scrum ha estado durante algn tiempo en los crculos orientados a objetos, aunque confesar que yo no estoy muy al tanto de su historia o desarrollo. De nuevo 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 junta 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 agiles en muchos aspectos y debe funcionar bien con las prcticas de cdigo de la XP. Despus de mucho tiempo sin un libro, finalmente Ken Schwaber y Mike Beedle escribieron el primer libro de scrum. Ken Schwaber tambin aloja controlChaos.com qu probablemente es la mejor apreciacin global sobre SCRUM. Jeff Sutherland siempre ha tenido un sitio web activo sobre temas de tecnologas de objetos e incluye una seccin sobre SCRUM. Hay tambin una buena apreciacin global de las prcticas de Scrum en el libro PLoPD 4. Scrum tiene una lista de discusin en Yahoo.
Desarrollo Manejado por Rasgos

El Desarrollo Manejado por Rasgos (FDD por sus siglas en ingls) fue desarrollado por Jeff De Luca y el viejo gur de la OO 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. Solo 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. Jeff De Luca, el inventor primario, ya tiene un portal FDD con artculos, blogs y foros de discusin. La descripcin original estaba en el libro UML in Color de Peter Coad et al. Su compaa, TogetherSoft, tambin da consultora y entrenamiento en FDD.
DSDM (Mtodo de Desarrollo de Sistema Dinmico)

El DSDM empez en Gran Bretaa en 1994 como un consorcio de compaas del Reino Unido que queran construir sobre RAD [N. del T. 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. Tambin lleva una etiqueta de precio, lo qu ha limitado mi investigacin sobre su metodologa. Sin embargo Jennifer Stapleton ha escrito un libro 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 dnde tiene lugar el desarrollo. Tambin propone arquitecturas de esbozos 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. Como 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 he visto 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. Parece haber una pregunta en si sus materiales animan ms de una orientacin al proceso y ms ceremonia de lo que me gustara.
Manifiesto para el Desarrollo de Software gil

Con tanta similitud entre estos mtodos, sera justo un poco de inters en alguna forma de trabajo colaborativo. Los representantes de cada una de estas metodologas fueron invitados a un taller de dos das en Snowbird, Utah en febrero de 2001. Yo asist sin

muchas expectativas. Despus de todo cuando se pone un manojo de metodologistas en el mismo cuarto, lo mejor que se puede esperar es algo de civismo. Lo que result me sorprendi. Todos estbamos conscientes del hecho de que haba 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, haba tambin la idea de emitir una declaracin conjunta - una llamada a las armas en favor de ms procesos de software giles. (Tambin estbamos de acuerdo en usar el trmino "gil" para referirnos a nuestras ideas comnes.) El resultado es un Manifiesto para el Desarrollo de Software gil, 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. Hay un artculo en una revista de desarrollo de software que es un comentario y una explicacin del manifiesto. 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 Agil. La Alianza Agil es una organizacin sin fines de lucro que busca promover el conocimiento y la discusin de todos los mtodos giles. Muchos lderes agilistas que he mencionado aqu son miembros y lderes de la Alianza gil.
Comprobacin Dirigida 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 comnes que declaran que el papel de la comprobacin es asegurar la conformidad del software con las especificaciones escritas de antemano, el papel de los verificadores en el mundo gil esta lejos de ser claro. En lo que se aclara eso, varias personas en la comunidad de verificadores han estado cuestionando mucho de la corriente principal del pensamiento en comprobacin por un tiempo ya. Esto ha llevado a un grupo conocido como la comprobacin conducida por el contexto. La mejor descripcin de esto es el libro Lecciones aprendidas en Comprobacin de Software. Esta comunidad es tambin muy activa en la web, eche una mirada a sitios organizados por Brian Marick (uno de los autores del manifiesto gil), Brett Pettichord, James Bach, y Cem Kaner.
Es RUP un mtodo gil?

Siempre que empezamos discutiendo mtodos en la arena OO, inevitablemente salimos con el papel del Rational Unified Process. El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de la Rational 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 mi crtica principal al RUP - como

puede ser cualquier cosa acaba siendo nada. Yo prefiero un proceso que dice 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 usted 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 excelente libro introductorio 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 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 un cianotipo del que no se pueda desviarse, sino un boceto que da una perspectiva sobre cmo pueden hacerse las cosas en la iteracin. Otra tachuela en el RUP gil es el proceso dX de Robert Martin. El proceso dx es una versin totalmente dcil del RUP que simplemente es idntico a la XP (voltear dX al revs 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. Para m, una de las cosas clave que necesita el RUP es que los lderes del RUP en la industria enfaticen su acercamiento al desarrollo de software. Ms de una vez he odo a la gente que usa el RUP que estn usando un proceso de desarrollo estilo cascada. Gracias a mis contactos en la industria, s que 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 y de Robert tendr un efecto importante.
Otras Fuentes

Recientemente hemos visto aparecer dos buenos libros qu miran al amplio tema de los mtodos giles de Alistair Cockburn y Jim Highsmith. Hay muchos otros artculos y discusiones sobre este tema de los mtodos giles. Mientras stas pueden no ser metodologas completas, ofrecen luz sobre este campo creciente. El congreso Patterns Language of Programming ha incluido a menudo material que menciona este asunto, tan solo porque muchos de los interesados en patrones tambin se interesan en los mtodos adaptables y humanos. Un artculo temprano sobresaliente fue el de Jim Coplien en el PLoP1. El lenguaje de Episodios de Ward Cunningham apareci el en PLoP2. Jim Coplein ahora mantiene el sitio OrgPatterns, un wiki que colecciona patrones organizacionales. Dirk Riehle envi un artculo al XP2000 que compara los sistemas de valor de la XP y el Desarrollo de Software Adaptable. La edicin de julio del Boletn de Coad compara

la XP al FDD. La edicin de julio de IEEE Software incluye varios artculos sobre "diversidad de procesos" que alude a estas metodologas. Mary Poppendieck escribi un artculo fascinante que compara las metodologas giles con la fabricacin magra.

Debe usted irse a lo gil?

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 ciertamente creo 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. 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

Reconocimientos
He tomado muchas ideas de otras personas para este artculo, ms de las que puedo listar. Para sugerencias concretas me gustara agradecer a Marc Balcer, Kent Beck, Alistair Cockburn, Ward Cunningham, Bill Kimmel y Frank Westphal. Recuerde que ste es un artculo web en evolucin y es probable que cambie cuando se me ocurra. Agregar un registro de cambios significativos, sin embargo los cambios menores ocurrirn sin ningn comentario.

Historia de la revisin
Aqu esta una lista de las actualizaciones mayores a este artculo

Abril de 2003: Varias secciones revisadas. Nuevas secciones sobre dificultad de medir y comprobacin dirigida por contexto. Junio de 2002: Referencias puestas al da Noviembre de 2001: Puesta al da de algunas referencias recientes Marzo de 2001: Actualizado para reflejar la aparicin de La Alianza gil Noviembre de 2000: Seccin de ASD actualizada y secciones de DSDM aadidas y RUP Diciembre de 2000: La versin compendiada se public Software Development bajo el ttulo de "Ponga Su Proceso a Dieta" Julio de 2000: Publicacin original en martinfowler.com

Copyright Martin Fowler, all rights reserved

Derechos reservados de la traduccin Alejandro Aguilar Sierra. Si desea comentar sobre el artculo o la traduccin, oprima aqu.