Las Metodologías
Varias metodologías encajan bajo el estandarte de ágil. Mientras todas ellas comparten muchas características, también 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 mayoría de ellas. He trabajado bastante en XP, y he visto el RUP en muchas capas, pero para la mayoría de los otros mi conocimiento no es el más adecuado.
XP (Programación Extrema)
De todas las metodologías ágiles, ésta es la que ha recibido más atención. Esto se debe en parte a la notable habilidad de los líderes XP, en particular Kent Beck, para llamar la atención. También 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 atención fuera de las otras metodologías y sus valiosas ideas.
Las raíces de la XP yacen en la comunidad de Smalltalk, y en particular la colaboración cercana de Kent Beck y Ward Cunningham a finales de los 1980s. Ambos refinaron sus prácticas 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 práctica informal a una metodología ocurrió en la primavera de 1996. A Kent se le pidió revisar el progreso del proyecto de nómina C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por una compañía contratista, y estaba en problemas. Debido a la baja calidad de la base del código, Kent recomendó tirar la base del código en su totalidad y empezar desde el principio. El proyecto entonces reinició bajo su dirección 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 después se encontró con dificultades, lo que resultó en la cancelación del desarrollo en 1999. (Lo cual prueba, si ninguna otra cosa, que la XP no es garantía de éxito.)
La XP empieza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y Coraje. Construye sobre ellos una docena de prácticas que los proyectos XP deben seguir. Muchas de estas prácticas son técnicas antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos, incluyendo la mayoría de los procesos planeados. Además de resucitar estas técnicas, la XP las teje en un todo sinérgico dónde cada una refuerza a las demás.
Una de las más llamativas, así como inicialmente atractiva para mí, es su fuerte énfasis en las pruebas. Mientras todos los procesos mencionan la comprobación, la mayoría lo hace con muy poco énfasis. Sin embargo la XP pone la comprobación como el fundamento del desarrollo, con cada programador escribiendo pruebas cuando escriben su código de producción. Las pruebas se integran en el proceso de integración continua y construcción lo que rinde una plataforma altamente estable para el desarrollo futuro.
En esta plataforma XP construye un proceso de diseño evolutivo que se basa en refactorizar un sistema simple en cada iteración. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la más desarrollada de entre todas las metodologías adaptables.
XP ha desarrollado un liderazgo amplio, muchos de ellos provenientes del proyecto fundamental C3. Como resultado hay muchas fuentes para más información. Kent Beck escribió Extreme Programming Explained, el manifiesto clave de la XP que explica las razones detrás de la metodología y bastante explicación como para que la gente pueda saber si se interesan en seguirla. En el último par de años ha habido una epidemia de libros sobre XP brillantemente coloreados la mayoría 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 número considerable de recursos en la web. Para encontrar un acercamiento más 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 promoción temprana y desarrollo de ideas de la XP ocurrieron en el ambiente de escritura colaborativa en la página 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 discusión XP. Una de las vistas externas más interesantes sobre la XP es la de Mark Paulk que es uno de los líderes de la comunidad CMM - su artículo mira a la XP desde la perspectiva del CMM.
[También hay referencias en español, como el sitio donde se hospeda originalmente esta traducción, que es también wiki http://www.programacionextrema.org/ y un grupo de discusión en yahoo. N. del T.]
La Familia de Cristal de Cockburn
Alistair Cockburn ha estado trabajando en metodologías desde que la IBM le encargó escribir sobre metodologías a inicios de los 90. No obstante, su acercamiento no es como la mayoría de los metodologistas. En lugar de partir solamente de su experiencia personal para construir una teoría de cómo deben hacerse las cosas, él complementa su experiencia directa con la búsqueda activa de proyectos y ver cómo trabajan. Además é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 recomendación de libro para ejecutar proyectos iterativos. Más recientemente Alistair escribió un libro de apreciación de desarrollo de software ágil que mira los principios subyacentes de este tipo de metodologías.
Desde ese libro él ha explorado más los métodos ágiles, viniendo con la familia de metodologías Crystal. Es una familia porque él cree que los tipos diferentes de proyectos requieren tipos diferentes de metodologías. Él mira esta variación a lo largo de dos ejes: el número de personas en el proyecto, y las consecuencias de los errores. Cada metodología encaja en una parte diferente de la reja, de modo que para un proyecto de 40 personas que puede perder dinero discrecionalmente tiene una metodología diferente a la de un proyecto vital de seis personas.
Cristal comparte con la XP una orientación humana, pero esta centralización en la gente se hace de una manera diferente. Alistair considera que las personas encuentran difícil seguir un proceso disciplinado, así que más que seguir la alta disciplina de la XP, Alistair explora la metodología menos disciplinada que aun podría tener éxito, intercambiando conscientemente productividad por facilidad de ejecución. Él considera que aunque Cristal es menos productivo que la XP, más personas serán capaces de seguirlo.
Alistair también pone mucho peso en las revisiones al final de la iteración, animando al proceso a ser auto mejorante. Su aserción es que 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.
Código Abierto
A usted podría sorprenderle este título. Después de todo el código abierto es un estilo de software, no tanto un proceso. Sin embargo hay una manera definida de hacer las cosas en la comunidad de código abierto, y mucho de su acercamiento es tan aplicable a los proyectos de código cerrado como a los de código abierto. En particular su proceso engrana equipos físicamente distribuidos, lo que es importante porque la mayoría de los procesos adaptables exigen equipos locales.
La mayoría de los proyectos de código abierto tienen uno o más mantenedores. Un mantenedor es la única persona a la que se le permite integrar un cambio en el almacén de código fuente. Sin embargo otras personas pueden hacer cambios a la base del código. 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 código. Normalmente estos cambios son hechos en forma de archivos de parches que hacen este proceso más fácil. Así, el mantenedor es responsable de coordinar los parches y mantener la cohesión en el diseño del software.
Proyectos diferentes manejan el papel del mantenedor de diferentes maneras. Algunos tienen un mantenedor para el proyecto entero, algunos lo dividen en módulos y tiene un mantenedor por módulo, algunos rolan el mantenedor, algunos tienen múltiples mantenedores sobre el mismo código, otros tienen una combinación de estas ideas. La mayor parte de la gente de código 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 código abierto es que la depuración es altamente paralelizable. Muchas personas pueden involucrarse en el depurado. Cuando encuentran un defecto pueden enviar el parche al mantenedor. Esto es un buen papel para los no mantenedores ya que la mayor parte del tiempo se gasta en encontrar bugs. También es bueno para gente sin mucha destreza en programación.
El proceso para el código abierto aun no se ha documentado bien. La referencia más famosa es el artículo de Eric Raymond La catedral y el bazar, que aunque es una descripción excelente también es bastante informal. El libro de Karl Fogel sobre el almacén de código CVS también contiene varios buenos capítulos sobre el proceso de código abierto que incluso serían interesantes para aquéllos que no quieren usar el cvs.
El Desarrollo de Software Adaptable de Highsmith
Jim Highsmith ha pasado muchos años trabajando con metodologías 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 metodologías, con un énfasis particular en aplicar las ideas que se originaron en el mundo de los sistemas complejos adaptables (normalmente conocida como teoría del caos). No proporciona el tipo de prácticas detalladas como lo hace la XP, pero proporciona la base fundamental de por qué el desarrollo adaptable es importante y las consecuencias a los más profundos niveles de la organización y la gerencia.
En el corazón del ASD hay tres fases solapadas, no lineales: especulación, colaboración, y aprendizaje.
Highsmith ve la planificación como una paradoja en un ambiente adaptable, ya que los resultados son naturalmente imprevisibles. En la planificación tradicional, las desviaciones del plan son errores que deben corregirse. En un ambiente adaptable, en cambio, las desviaciones nos guían hacia la solución correcta.
En este ambiente imprevisible se necesita que las personas colaboren de la mejor manera para tratar con la incertidumbre. La atención de la gerencia es menor en lo que tiene que hacer la gente, y mayor sobre la comunicación 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 diseño.
En un ambiente adaptable, aprender desafía a todos - desarrolladores y sus clientes - a examinar sus presunciones y usar los resultados de cada ciclo de desarrollo para adaptar el siguiente.
[Highsmith]
El aprendizaje como tal es un rasgo continuo e importante, que asume que los planes y los diseños 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 están en la raíz de nuestro autoengaño. Nos obliga a estimar con realismo nuestra habilidad.
[Highsmith]
Con este énfasis, el trabajo de Highsmith se enfoca directamente en fomentar las partes difíciles del desarrollo adaptable, en particular cómo fomentar la colaboración 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 práctica aterrizada como XP, FDD y Cristal.
Scrum
Scrum ha estado durante algún tiempo en los círculos 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 sólo 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 días. 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 días el equipo sostiene una junta corta (quince minutos), llamada scrum, dónde el equipo discurre lo que hará al día siguiente. En particular muestran a los bloques de la gerencia: los impedimentos para progresar que se atraviesan y que la gerencia debe resolver. También informan lo que se ha hecho para que la gerencia tenga una actualización diaria de dónde va el proyecto.
La literatura de Scrum se enfoca principalmente en la planeación iterativa y el seguimiento del proceso. Es muy cercana a las otras metodologías ágiles en muchos aspectos y debe funcionar bien con las prácticas de código de la XP.
Después de mucho tiempo sin un libro, finalmente Ken Schwaber y Mike Beedle escribieron el primer libro de scrum. Ken Schwaber también aloja controlChaos.com qué probablemente es la mejor apreciación global sobre SCRUM. Jeff Sutherland siempre ha tenido un sitio web activo sobre temas de tecnologías de objetos e incluye una sección sobre CRUM. Hay también una buena apreciación global de las prácticas de Scrum en el libro PLoPD 4. Scrum tiene una lista de discusión en Yahoo.
Desarrollo Manejado por Rasgos
El Desarrollo Manejado por Rasgos (FDD por sus siglas en inglés) fue desarrollado por Jeff De Luca y el viejo gurú de la OO Peter Coad. Como las otras metodologías 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
- Diseñar por Rasgo
- Construir por Rasgo
Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación.
Los desarrolladores entran en dos tipos: dueños de clases y programadores jefe. Los programadores jefe son los desarrolladores más experimentados. A ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen solos. Solo identifican qué clases se involucran en la implantación de un rasgo y juntan a los dueños de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe actúa como el coordinador, diseñador líder y mentor mientras los dueños de clases hacen gran parte de la codificación del rasgo.
Hasta recientemente, la documentación sobre FDD era muy escasa. Finalmente hay un libro completo sobre FDD. Jeff De Luca, el inventor primario, ya tiene un portal FDD con artículos, blogs y foros de discusión. La descripción original estaba en el libro UML in Color de Peter Coad et al. Su compañía, TogetherSoft, también da consultoría y entrenamiento en FDD.
DSDM (Método de Desarrollo de Sistema Dinámico)
El DSDM empezó en Gran Bretaña en 1994 como un consorcio de compañías del Reino Unido que querían construir sobre RAD [N. del T. Desarrollo Rápido de Aplicaciones] y desarrollo iterativo. Habiendo empezado con 17 fundadores ahora tiene más de mil miembros y ha crecido fuera de sus raíces británicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros métodos ágiles. Tiene una organización de tiempo completo que lo apoya con manuales, cursos de entrenamiento, programas de certificación y demás. También lleva una etiqueta de precio, lo qué ha limitado mi investigación sobre su metodología. Sin embargo Jennifer Stapleton ha escrito un libro que da una apreciación global de la metodología.
El método 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 dónde tiene lugar el desarrollo. También 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 documentación de análisis y prototipos, el ciclo de diseño del modelo diseña el sistema para uso operacional, y el ciclo de implantación se ocupa del despliegue al uso operacional.
DSDM tiene principios subyacentes que incluyen una interacción activa del usuario, entregas frecuentes, equipos autorizados, pruebas a lo largo del ciclo. Como otros métodos á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 metodologías tradicionales más maduras, al mismo tiempo que sigue los principios de los métodos ágiles. Parece haber una pregunta en si sus materiales animan más de una orientación al proceso y más ceremonia de lo que me gustaría.
Manifiesto para el Desarrollo de Software Ágil
Con tanta similitud entre estos métodos, sería justo un poco de interés en alguna forma de trabajo colaborativo. Los representantes de cada una de estas metodologías fueron invitados a un taller de dos días en Snowbird, Utah en febrero de 2001. Yo asistí sin muchas expectativas. Después de todo cuando se pone un manojo de metodologistas en la misma habitación, lo mejor que se puede esperar es algo de civismo.
Lo que resultó me sorprendió. Todos estábamos conscientes del hecho de que había mucho en común, y este reconocimiento era mucho mayor que las diferencias entre los procesos. Además de un contacto útil entre los líderes de procesos, había también la idea de emitir una declaración conjunta - una llamada a las armas en favor de más procesos de software ágiles. (También estábamos de acuerdo en usar el término "ágil" para referirnos a nuestras ideas comúnes.)
El resultado es un Manifiesto para el Desarrollo de Software Ágil, una declaración de los principios y valores comunes de los procesos ágiles. Hay también un deseo de colaborar más en el futuro, para animar más tanto a tecnólogos como a gente de negocios para usar y requerir acercamientos ágiles al desarrollo de software. Hay un artículo en una revista de desarrollo de software que es un comentario y una explicación del manifiesto.
El manifiesto fue sólo eso, una publicación que actuó como un punto de partida para aquellos que compartían estas ideas básicas. Uno de los frutos del esfuerzo fue la creación de un cuerpo más longevo, la Alianza Agil. La Alianza Agil es una organización sin fines de lucro que busca promover el conocimiento y la discusión de todos los métodos ágiles. Muchos líderes agilistas que he mencionado aquí son miembros y líderes de la Alianza Ágil.
Comprobación 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 comúnes que declaran que el papel de la comprobación 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 esto se aclara, varias personas en la comunidad de verificadores han estado cuestionando mucho de la corriente principal del pensamiento en comprobación desde hace un tiempo. Esto ha llevado a un grupo conocido como la comprobación conducida por el contexto. La mejor descripción es el libro Lecciones aprendidas en Comprobación de Software. Esta comunidad es también 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 método ágil?
Siempre que empezamos discutiendo métodos 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 armazón de proceso y como tal puede acomodar una gran variedad de procesos. De hecho ésta es mi crítica 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 armazón 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 cómo 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 visión es que mucho del reciente empujón hacia los métodos ágiles no es nada más 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 días de una iteración mensual con todo el equipo usando el UML para perfilar el diseño del trabajo a hacerse durante la iteración. Esto no es un cianotipo del que no pueda desviarse, sino un boceto que da una perspectiva sobre cómo pueden hacerse las cosas en la iteración.
Otra tachuela en el RUP ágil es el proceso dX de Robert Martin. El proceso dX es una versión totalmente dócil del RUP que simplemente es idéntico a la XP (girar dX ciento ochenta grados para ver la broma). El dX está diseñado 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 líderes del RUP en la industria enfaticen su acercamiento al desarrollo de software. Más de una vez he oído a la gente que usa el RUP que están 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 métodos ágiles de Alistair Cockburn y Jim Highsmith.
Hay muchos otros artículos y discusiones sobre este tema de los métodos ágiles. Mientras éstas pueden no ser metodologías 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 también se interesan en los métodos adaptables y humanos. Un artículo 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 artículo al XP2000 que compara los sistemas de valor de la XP y el Desarrollo de Software Adaptable. La edición de julio del Boletín de Coad compara la XP al FDD. La edición de julio de IEEE Software incluye varios artículos sobre "diversidad de procesos" que alude a estas metodologías.
Mary Poppendieck escribió un artículo fascinante que compara las metodologías ágiles con la fabricación magra.
Tutoriales
