DESARROLLO ÁGIL

En 2001, Kent Beck y otros 16 notables desarrolladores, escritores y consultores IBEC01) (conocidos como la "Alianza Ágil") firmaron el "Manifiesto para el desarrollo ágil de software", el cual establecía:

Hemos descubierto mejores formas de desarrollar software al construirlo por nuestra cuenta y ayudar a otros a hacerlo. Por medio de este trabajo hemos llegado a valorar:A los individuos y sus interacciones sobre los procesos y las herramientas. Al software en funcionamiento sobre la documentación extensa. A la colaboración del cliente sobre la negociación del contrato. A una respuesta al cambio sobre el seguimiento de un plan.

Esto es, aunque los términos a la derecha tienen valor, nosotros valoramos más los aspectos de la izquierda.

Un manifiesto se asocia por lo general con un movimiento político emergente: aquel que ataca a la vieja vanguardia y sugiere un cambio revolucionario (en el mejor de los casos para mejorar). De alguna forma, esto es con exactitud de lo que se trata el desarrollo ágil

A pesar de que las ideas subyacentes que conducen al desarrollo ágil rían estado presentes por muchos años, no ha sido sino hasta la década pasada que estas ideas han cristalizado en un "movimiento". En esencia, los métodos ágiles1 se desarrollaron en un intento por superar las debilidades advertidas y reales en la ingeniería del software convencional. El desarrollo ágil proporciona beneficios importantes, pero es imposible aplicarlo en todos los proyectos, productos, personas y situaciones.

¿Qué es? La ingeniería de software ágil combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca la satisfacción del cliente y la entrega temprana de software incremental; equipos de proyecto pequeños y con alta motivación; métodos informales; un mínimo de productos de trabajo de la ingeniería del software; y una simplicidad general del desarrollo. Las directrices de desarrollo resaltan la entrega sobre el análisis y el diseño (aun que estas actividades no se descartan), y la comunicación activa y continua entre los desarrolladores y los clientes. ¿Quién lo hace? Los ingenieros de software y otros participantes del proyecto (gerentes, clientes y usuarios finales) trabajan juntos en un equipo ágil: un equipo con organización propia y que controla su propio destino. Un equipo ágil fomenta la comunicación y la colaboración entre todos los que trabajan en él.

¿Por qué es importante? El ambiente moderno de los negocios ocasiona que los sistemas basados en computadoras y los productos de software estén acelerados y en cambio continuos. La ingeniería del software ágil representa una opción razonable a la ingeniería convencional para ciertas clases de software y ciertos tipos de proyectos de software. Ha demostrado su utilidad al entregar sistemas exitosos con rapidez. ¿Cuáles son los pasos? El desarrollo ágil podría llamarse con mayor precisión "ingeniería del software ligera". Las actividades básicas del marco de trabajo -comunicación con el cliente, planeación, modelado, construcción, entrega y evolución- se conservan, pero éstas se conforman como un conjunto mínimo de tareas que empuja al equipo de proyecto hacia la construcción y la entrego (habrá quienes argumenten que esto se hace a costa del análisis del problema y del diseño de la solución).¿Cuál es el producto obtenido? Los clientes e ingenieros de software que han adoptado la filosofía ágil tienen la misma visión: el único producto de trabajo realmente importante es un "incremento de software" en funcionamiento, el cual se entrega al cliente en una fecha prometida.¿Cómo puedo estar seguro de que lo he hecho correctamente? Si el equipo de software está de acuerdo en que el proceso funciona y dicho equipo produce incrementos de software entregables que satisfacen al cliente, entonces el trabajo está bien hecho.No es la antítesis de la práctica sólida de la ingeniería del software y es posible aplicarla como una filosofía predominante para cualquier trabajo de software.

En la economía moderna, a menudo resulta difícil o imposible predecir cómo evolucionarán con el tiempo los sistemas basados en computadoras (por ejemplo, las aplicaciones Web). Las condiciones del mercado cambian con rapidez, las necesidades de los usuarios finales evolucionan, y las nuevas amenazas competitivas emergen sin previo aviso. En muchas situaciones ya es imposible definir por completo los requisitos antes de que comience el proyecto. Los ingenieros de software deben ser tan ágiles como para responder a un ambiente de negocios fluido.¿Lo anterior significa que el reconocimiento de estas realidades modernas ocasiona que se descarten los valiosos principios, conceptos, métodos y herramientas de la ingeniería del software? No, en lo absoluto; Como todas las disciplinas de ingeniería, la ingeniería del software continúa en evolución. Se puede adaptar con faci-lidad para enfrentar los retos que implica una exigencia de agilidad.

En un libro que invita a la reflexión y trata sobre el desarrollo ágil de software, Alistair Cockburn [COC02a] argumenta que los modelos prescriptivos de proceso presentados tienen una falla importante: olvidan las fragilidades de las personas que construyen el software de computadora. Los ingenieros de software no son robots. Ellos muestran una gran variedad en los estilos de trabajo y diferencias significativas en su grado de habilidad, creatividad, orden, consistencia y espontaneidad. Algunos se comunican muy bien en forma escrita, otros no. Cockburn argumenta que los modelos de proceso pueden "enfrentar las debilidades comunes de la gente con disciplina o tolerancia [alguna de las dos]" [COC02a], y que los modelos de proceso más prescriptivos eligen la disciplina. Él establece: "Como la consistencia en la acción es una debilidad humana, las metodologías que exigen un alto grado de disciplina son frágiles" [COC02a],

Los modelos de proceso funcionarán si proporcionan un mecanismo realista que fomente la disciplina necesaria, o deben estar caracterizados de manera que muestren "tolerancia" por la gente que realiza el trabajo de la ingeniería del software. De manera invariable, la gente de software adopta y sostiene más fácilmente las prácticas tolerantes, pero (como Cockburn lo admite) tal vez sea menos productiva. Como la mayoría de las cosas en la vida, se deben considerar los intercambios.

1. QUE ES LA AGILIDAD.

¿Qué es la agilidad en el contexto del trabajo de la ingeniería del software? Ivar Jacobson [JAC02] proporciona una definición útil:

Agilidad se ha convertido actualmente en la palabra de moda en cuanto se describe un moderno proceso de software. Cualquiera es ágil. Un equipo ágil es un equipo rápido que responde de manera apropiada a los cambios. Éstos son, en gran parte, la materia del desarrollo de software. Cambios en el software que se va a construir, cambios entre los miembros del equipo, cambios debidos a las nuevas tecnologías, cambios de todo tipo que pueden incidir en el producto que se construye o en el proyecto que crea el producto. En cualquier actividad de software se debe incluir un soporte para los cambios, esto es algo que adoptamos porque es el alma y el corazón del software. Un equipo ágil reconoce que el software lo desarrollan individuos que trabajan en equipo y que las aptitudes de esta gente, y su capacidad para colaborar, son esenciales para el éxito del proyecto.

De acuerdo con la visión de Jacobson, la insistencia en el cambio es el conductor primordial hacia la agilidad. Los ingenieros de software deben tener pies veloces si quieren ajustarse a los cambios rápidos que describe Jacobson.

Pero la agilidad es más que una respuesta efectiva al cambio. También incluye la filosofía del manifiesto enunciado al principio de este capítulo. Estimula las estructuras y actitudes de los equipos para que la comunicación (entre los miembros del equipo, entre los técnicos y la gente de negocios, entre los ingenieros de software y sus gerentes) sea más fácil. Resalta la entrega rápida del software operativo y le resta importancia a los productos de trabajo intermedio (lo cual no siempre es bueno); adopta al cliente como una parte del equipo de desarrollo y trabaja para eliminar la actitud del tipo "nosotros y ustedes" que aún perjudica a muchos proyectos de software; reconoce que la planeación tiene sus límites en un mundo incierto y que el plan de proyecto debe ser flexible.

La Alianza Ágil [AGI03] define 12 principios para quienes quieren alcanzar la agilidad:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.

2. Bienvenidos los requisitos cambiantes, incluso en fases tardías del desarrollo. La estructura de los procesos ágiles cambia para la ventaja competitiva del cliente.

3. Entregar con frecuencia software en funcionamiento, desde un par de semanas hasta un par de meses, con una preferencia por la escala de tiempo más corta.

4. La gente de negocios y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto.

5. Construir proyectos alrededor de individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado.

6. El método más eficiente y efectivo de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara.

7. El software en funcionamiento es la medida primaria de progreso.

8. Los procesos ágiles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un paso constante de manera indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad el arte de maximizar la cantidad de trabajo no realizado— es esencial.

11. Las mejores arquitecturas, los mejores requisitos y los mejores diseños emergen de equipos auto organizados.

12. A intervalos regulares el equipo refleja la forma en que se puede volver más efectivo; entonces su comportamiento se ajusta y adecúa en concordancia.

La agilidad se puede aplicar en cualquier proceso de software. Sin embargo, para lograrlo es esencial que el proceso sea diseñado en una forma que permita al equipo del proyecto adaptar y coordinar las tareas, conducir la planeación en una forma que entienda la fluidez de un enfoque de desarrollo ágil, eliminar todo pe-ro no los productos de trabajo esenciales y mantenerlos controlados, y enfatizar una estrategia de entrega incremental que proporcione software en funcionamiento al cliente tan rápido como sea factible para el tipo de producto y el ambiente operativo.

2. ¿QUE ES UN PROCESO ÁGIL?Cualquier proceso ágil de software se caracteriza de una manera que refiere tres suposiciones clave [FOW02] acerca de la mayoría de los proyectos de software:

1. Resulta difícil predecir cuáles requisitos del software persistirán y cuáles cambiarán. De igual forma, es difícil presagiar cómo cambiarán las prioridades del cliente mientras se ejecuta un proyecto.

2. Para muchos tipos de software, el diseño y la construcción están intercalados. Esto es, ambas actividades se deben realizar de manera conjunta, de modo que los modelos de diseño sean probados conforme se crean. Resulta difícil predecir cuánto diseño se necesita antes de que la construcción se utilice para probar el diseño.

3. El análisis, el diseño y la construcción no son predecibles (desde el punto de vista de la planeación), lo que sería deseable.

Dados los puntos anteriores, surge una pregunta importante: ¿cómo se crea un proceso susceptible de manipular en forma impredecible? La respuesta, como ya se ha puntualizado antes, reside en la adaptabilidad del proceso (a un proyecto y a condiciones técnicas que cambian con rapidez). Por lo tanto, un proceso ágil debe ser adaptable.

Pero una adaptación continua sin un progreso logra muy poco. Por lo tanto, un proceso ágil de software debe adaptarse en forma incremental Para llevar a cabo una adaptación incremental, un equipo ágil requiere de la retroalimentación con el cliente (para que sea factible realizar las adaptaciones apropiadas). Un catalizador efectivo para la retroalimentación del cliente es un prototipo operacional o una porción de un sistema operacional. Por lo tanto, debe instituirse una estrategia incremental de desarrollo. Los incrementos de software (prototipos ejecutables o una porción de un sistema operacional) deben entregarse en cortos periodos para que la adaptación mantenga un buen ritmo con el cambio (imprevisibilidad). Este enfoque iterativo le permite al cliente evaluar el incremento del software de manera regular, proporcionar la retroalimentación necesaria al equipo de software, e influir sobre las adaptaciones del proceso que se realizan para adecuar la retroalimentación.

3. LAS POLÍTICAS DEL DESARROLLO ÁGILExiste un debate considerable (a veces estridente) sobre los beneficios y la aplicabilidad del desarrollo ágil del software como alternativa a procesos de ingeniería del software más convencionales. Jim Highsmith [HlG02a] (a manera de broma) analiza los extremos cuando caracteriza el sentimiento del campo pro agilidad ("agilitadores"). "Los metodólogos tradicionales son un conjunto de tipos que se arrastran en el lodo y que prefieren producir documentación que no fluye, en vez de un sistema de trabajo que cubra las necesidades del negocio." Como contraparte, establece la posición del campo de la ingeniería del software (de nuevo, en forma de broma): "Los metodólogos 'ligeros' y, en, 'ágiles' son un conjunto de intrusos informáticos que van a estar ahí para dar una maldita sorpresa cuando intenten elevar sus juguetes al nivel de software de la empresa".

Al igual que todos los argumentos sobre la tecnología del software, este debate sobre la metodología corre el riesgo de degenerar en una guerra religiosa. Si estalla la guerra, desaparece el pensamiento racional, y las creencias, en vez de los hechos, guían la toma de decisiones.

Nadie está en contra de la agilidad. La pregunta real es: ¿cuál es la mejor manera de lograrla? Igual de importante es la pregunta: ¿cómo se construye un software que satisfaga hoy las necesidades de los clientes y muestre las características de calidad que le permitan extenderse y escalar para cubrir a largo plazo las necesidades del cliente?

No existen respuestas absolutas para ninguna de estas preguntas. Aun dentro de la escuela ágil se han propuesto varios modelos de proceso (sección 4.3), cada uno con un enfoque sutilmente diferente para el problema de la agilidad. Dentro de cada modelo hay un conjunto de "ideas" (que los agilitado res suelen llamar "tareas de trabajo") que representan una separación significativa de la ingeniería del software convencional. Y aun así, muchos conceptos de agilidad son tan sólo adaptaciones de buenos conceptos de la ingeniería del software. Como punto final, hay mucho que ganar si se considera lo mejor de ambas escuelas, y nada que ganar si se denigra alguno de los dos enfoques.

El lector interesado puede consultar [HIG01], [HIG02a] y [DEM02] para un animado resumen de los aspectos técnicos y políticos importantes.

4. FACTORES HUMANOS

Los defensores del desarrollo ágil del software resaltan la importancia de los "factores de las personas" en un desarrollo ágil exitoso. Como establecen Cockburn y Highsmith [COC01]: "El desarrollo ágil se centra en los talentos y las habilidades de los individuos, puesto que el proceso se ajusta a personas y equipos específicos". El punto clave en esta afirmación es que el proceso se ajusta a las necesidades de las personas y del equipo, y no al revés.1

Si los miembros del equipo de software van a manejar las características del proceso que se aplica para construirlo, debe existir un gran número de rasgos clave entre la gente de un equipo ágil y el equipo mismo:

Competencia. En el contexto de un desarrollo ágil (al igual que en la ingeniería del software convencional), la

1 La mayoría de las organizaciones de software exitosas reconocen esta realidad sin importar el modelo de proceso que elijan.

"competencia" abarca un talento innato, habilidades específicas relacionadas con el software, y un conocimiento general del proceso que el equipo haya elegido aplicar. La habilidad y el conocimiento del proceso pueden y deben enseñarse a toda la gente que funge como miembro de un equipo ágil.

Enfoque común. Aunque los miembros del equipo ágil desempeñen tareas diferentes y aporten distintas habilidades al proyecto, todos deben enfocarse en una meta: entregar al cliente un incremento de trabajo de software dentro del tiempo establecido. Alcanzar esta meta requiere que el equipo también se centre en adap-taciones continuas (pequeñas y grandes) mediante las cuales el proceso satisfará las necesidades del equipo.

Colaboración. La ingeniería del software (sin considerar el proceso) incluye evaluar, analizar y usar información que se comunica al equipo de software; crear información que ayudará al cliente y a otros a entender el trabajo del equipo; y construir información (software de computadora y bases de datos relevantes) que ofrezca un valor comercial para el cliente. Estas tareas se cumplirán si los miembros del equipo colaboran, entre ellos, con el cliente y con sus gerentes.

Habilidad para la toma de decisiones. Todo buen equipo de software (incluidos los equipos ágiles) debe permitirse la libertad de controlar su propio destino. Esto implica que al equipo se le dé autonomía, es decir, autoridad para tomar decisiones en cuanto a cuestiones técnicas y del proyecto.

Capacidad de resolución de problemas confusos. Los gestores de software deben reconocer que el equipo ágil enfrentará ambigüedades y sufrirá golpes de manera continua debido al cambio. En algunos casos, el equipo debe aceptar que el problema que está resolviendo hoy tal vez no sea el problema que debe resolverse mañana. Sin embargo, las lecciones aprendidas en cualquier actividad para la resolución de problemas (incluidas aquellas que sirven para solucionar el problema erróneo) pueden beneficiar al equipo en fases posteriores del proyecto.

Confianza y respeto mutuo. El equipo ágil se debe convertir en lo que De Marco y Lister [DEM98] llaman un equipo "cuajado" (véase el capítulo 21). Un equipo cuajado muestra la confianza y el respeto necesarios para que "se unan con tanta fuerza, que el todo sea mayor que la suma de las partes" [DEM98].

Organización propia. En el contexto del desarrollo ágil, la organización propia implica tres factores: 1) el equipo ágil se organiza a sí mismo para el trabajo que debe hacerse; 2) el equipo organiza el proceso que mejor se ajusta a su ambiente local; 3) el equipo organiza el programa de trabajo con el que se alcance de mejor manera la entrega del incremento del software. La organización propia tiene varios beneficios técnicos, pero lo más importante es que mejora la colaboración y eleva la moral del equipo. En esencia, el equipo sirve como su propia gestoría. Ken Sch-waber [SCH02] puntualiza estos aspectos cuando escribe: "El equipo selecciona la cantidad de trabajo que cree que es capaz de hacer dentro de la iteración, y el equipo se compromete con el trabajo. Nada desalienta más a un equipo que alguien más se comprometa por él. Nada motiva más a un equipo que aceptar la responsabilidad de cumplir los compromisos que él mismo hizo".

5. MODELOS ÁGILES DE PROCESO

La historia de la ingeniería del software está llena de decenas de descripciones y metodologías, métodos de modelado y notaciones, herramientas y tecnologías obsoletas. Cada elemento surgió con notoriedad y después lo eclipsó algo nuevo y (supuestamente) mejor. Con la introducción de un amplio espectro de modelos ágiles de proceso —cada uno en busca de su aceptación dentro de la comunidad del desarrollo de software el movimiento ágil está en la misma ruta histórica.2

En las siguientes secciones se presenta una visión general de cierto número de diferentes modelos ágiles de proceso. Existen muchas similitudes (en filosofía y práctica) entre estos enfoques. La intención es subrayar aquellas

2 Esto no es algo malo. Antes de que uno o más modelos o métodos sean aceptados como un estándar de facto, todos deben competir por los corazones y las mentes de los ingenieros de software. Los "ganadores" evolucionan con la mejoría que proporciona la práctica, mientras que los "perdedores" desaparecen o se unen a los modelos "ganadores".

características de cada método que lo hacen único. Es importante señalar que todos los modelos ágiles se ajustan (en mayor o menor grado) al Manifiesto para el desarrollo de software y a los principios enunciados en la sección 4.1.

6. PROGRAMACIÓN EXTREMA (PE)

A pesar de que los primeros trabajos sobre las ideas y los métodos asociados con la programación extrema (PE) se realizaron a finales de la década de 1980, el trabajo fundamental sobre la materia, escrito por Kent Beck [BEC99], se publicó en 1999. Los libros subsiguientes de Jeffries et al. [JEF01] sobre los detalles técnicos de la PE, y el trabajo adicional de Beck y Fowler [BECOlb] sobre la planeación de la PE expusieron los detalles del método.

La PE utiliza un enfoque orientado a objetos (parte 2 de este libro) como su paradigma de desarrollo preferido. La PE abarca un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades del marco de trabajo: planeación, diseño, codificación y pruebas. En la figura 4.1 se ilustra el proceso de la PE y se observan algunas de las ideas y tareas clave asociadas con cada actividad del marco de trabajo. En los siguientes párrafos se resumen las actividades clave de la PE.

Planeación. La actividad de planeación comienza creando una serie de historias (también llamadas historias del usuario) que describen las características y la funcionalidad requeridas para el software que se construirá. Cada historia (similar a los casos de uso descritos en los capítulos 7 y 8) la escribe el cliente y se coloca en una carta índice. El cliente le asigna un valor (es decir, una prioridad) a la historia basándose en los valores generales del negocio respecto de la característica o la función.3 Los miembros del equipo de la PE evalúan entonces cada historia y le asignan un costo, el cual se mide en semanas de desarrollo. Si la historia requiere más de tres semanas de desarrollo, se le pide al cliente que la divida en historias menores, y se realiza de nuevo la asignación del valor y el costo. Es importante destacar que las historias nuevas pueden escribirse en cualquier momento.

Los clientes y el equipo de PE trabajan juntos para decidir cómo agrupar las historias hacia el próximo lanzamiento (el siguiente incremento de software) para que el equipo de la PE las desarrolle. Una vez establecido el compromiso básico (el acuerdo de las historias que se incluirán, la fecha de entrega y otras cuestiones del proyecto) para un lanzamiento, el equipo de la PE ordena las historias que se desarrollarán de una de las siguientes tres maneras: 1) todas las historias serán implementadas de un modo inmediato (dentro de pocas semanas); 2) las historias con valor más alto se moverán en el programa y se implementarán al principio; o 3) las historias más riesgosas se moverán dentro del programa y se implementarán al principio.

3 El valor de una historia puede depender también de la presencia de otra historia.

Después de que se ha entregado el primer lanzamiento del proyecto (también llamado incremento de software), el equipo de la PE calcula la velocidad del proyecto. Dicho de un modo más simple, la velocidad del proyecto es el número de historias de los clientes implementado durante el primer lanzamiento. Entonces, la velocidad del proyecto puede utilizarse para 1) ayudar a estimar fechas de entrega y el programa para lanzamientos subsecuentes, y 2) determinar si se ha hecho un compromiso excesivo en algunas de las historias de todo el proyecto de desarrollo. Si se presenta un compromiso excesivo, el contenido de los lanzamientos se modifica o se cambian las fechas de las entregas finales.

Conforme avanza el trabajo de desarrollo, el cliente puede agregar historias, cambiar el valor de la historia existente, dividir historias o eliminarlas. Entonces el equipo de la PE considera de nuevo los lanzamientos restantes y modifica sus planes de acuerdo con ello.

Diseño. El diseño de la PE sigue de manera rigurosa el principio MS (mantenerlo simple). Siempre se prefiere un diseño simple respecto de una presentación más compleja. Además, el diseño ofrece una guía de implementación para una historia como está escrita, ni más ni menos. Se desaprueba el diseño de funcionalidad extra 4 (porque el desarrollador supone que se requerirá más tarde).

La PE apoya el uso de tarjetas CRC (capítulo 8) como un mecanismo efectivo para pensar en el software en un contexto orientado a objetos. Las tarjetas CRC (colaborador-responsabilidad-clase) identifican y organizan las clases orientadas al objeto5 que son relevantes para el incremento del software actual. El equipo PE conduce el ejercicio del diseño por medio de un proceso similar al descrito en el capítulo 8 (sección 8.7.4.). Las tarjetas CRC son el único producto de trabajo realizado como parte del proceso de la PE.Si se encuentra un problema difícil de diseño como parte del diseño de la historia, la PE recomienda la creación inmediata de un prototipo operacional de esa porción del diseño. El prototipo del diseño, llamado la solución pico, se implementa y evalúa. El propósito es reducir el riesgo cuando comience la verdadera implementación y validar las estimaciones originales en la historia que contiene el problema del diseño.La PE apoya la re fabricación, una técnica de construcción que también lo es de diseño. Fowler [FOW00] describe la re fabricación de la siguiente manera:

Re fabricación es el proceso de cambiar un sistema de software de tal manera que no altere el comportamiento externo del código y que mejore la estructura interna. Es una manera disciplinada de limpiar el código |y modificar/simplificar el diseño interno), lo que minimiza las oportunidades de introducir errores. En esencia, al re fabricar, se mejora el diseño del código después de que se ha escrito.Debido a que el diseño de la PE virtualmente no utiliza la notación y produce, si acaso, muy pocos productos de trabajo, distintos a las tarjetas de CRC y soluciones pico, el diseño se considera como un artefacto que puede y debe modificarse de manera continua a medida que prosigue la construcción. El propósito de prefabricar es controlar estas modificaciones al sugerir pequeños cambios del diseño que "pueden mejorar de manera radical el diseño" [FOW00]. Sin embargo, debe notarse que el esfuerzo requerido para re fabricar puede aumentar en forma drástica a medida que crece el tamaño de la aplicación.Una noción central en la PE es que el diseño ocurre tanto antes como después del comienzo de la codificación. Re fabricar significa que el diseño ocurre de manera continua a medida que se construye el sistema. De hecho, la actividad de construcción misma le proporcionará al equipo de PE una guía sobre cómo mejorar el diseño.

a) CODIFICACIÓN. La PE recomienda que después de diseñar las historias y realizar el trabajo de diseño preliminar el equipo no debe moverse hacia la codificación, sino que debe desarrollar una serie de pruebas de unidad que ejerciten cada una de las historias que vayan a incluirse en el lanzamiento actual (incremento de software).6 Una vez creada la prueba de unidad, el desarrollador es más capaz de centrarse en lo que debe

4 Estas directrices de diseño se deberían seguir en todos los métodos de ingeniería del software. aunque a veces las notaciones y terminologías sofisticadas que se utilizan en el diseño pueden emplearse de una manera más simple.

5 En el capítulo 8, y a lo largo de la parte 2 del libro, se estudian las clases orientadas a objetos.

implementarse para pasar la prueba de unidad. No se agrega nada extraño (MS). Una vez que el código está completo, la unidad puede probarse de inmediato, y así proporcionar una retroalimentación instantánea a los desarrolladores.

Un concepto clave durante la actividad de codificación (y uno de los aspectos de la PE de los que más se ha hablado) es la programación en pareja. La PE recomienda que dos personas trabajen juntas en una estación de trabajo de computadora para crear el código de una historia. Esto proporciona un mecanismo para la resolución de problemas en tiempo real (dos cabezas piensan mejor que una) y el aseguramiento de la calidad en las mismas condiciones. También alienta que los desarrolladores se mantengan centrados en el problema que se tiene a la mano. En la práctica, cada persona tiene un papel sutilmente diferente. Por ejemplo, una persona puede pensar en los detalles de codificación de una porción particular del diseño, mientras que la otra se asegura de que se sigan los estándares de codificación (una parte requerida de la PE) y que el código que se genera "coincida" con el diseño más amplio de la historia. Cuando los programadores completan su trabajo el código que desarrollaron se integra con el trabajo de otros. En algunos casos esto lo lleva a cabo diariamente el equipo de integración. En otros casos, la pareja de programadores es la responsable de la integración. Esta estrategia de "integración continua" ayuda a evitar problemas de compatibilidad e interfaz y proporciona un ambiente de "prueba de humo" (capítulo 13) que ayuda a descubrir los errores desde el principio.

b) PRUEBAS. Ya se ha hecho notar que la creación de una prueba de unidad7 antes de comenzar la codificación es un elemento clave para el enfoque de la PE. Las pruebas de unidad que se crean deben implementarse con un marco de trabajo que permita automatizarlas (por lo tanto, pueden ejecutarse de manera fácil y repetida). Esto apoya una estrategia de regresión de prueba (capítulo 13) cuando el código se modifica (al cual a menudo se le confiere la filosofía de la PE de re fabricar).

Cuando las unidades individuales de prueba se organizan en un "conjunto universal de pruebas" [WEL99], las pruebas de integración y validación del sistema pueden realizarse a diario. Esto proporciona al equipo de PE una indicación continua del progreso y también puede encender luces de emergencia previas si las cosas salen mal. Wells [WEL99] establece: "Arreglar problemas pequeños cada pocas horas toma menos tiempo que arreglar problemas enormes justo antes de la fecha límite".Las pruebas de aceptación de la PE, también llamadas pruebas del cliente, las especifica el cliente y se enfocan en las características generales y la funcionalidad del sistema, elementos visibles y revisables por el cliente. Las pruebas de aceptación se derivan de las historias del usuario que se han implementado como parte de un lanzamiento de software.

7. DESAROLLO ADAPTATIVO DE SOFTWARE (DAS)

El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith [HIGOO] como una técnica para construir software y sistemas complejos. Los apoyos filosóficos del DAS se enfocan en la colaboración humana y la organización propia del equipo. Highsmith [HIG98] expone lo anterior cuando escribe:

La organización propia es una propiedad de los sistemas adaptativos complejos, similar a un "aja" colectivo; es en el momento de energía creativa cuando surge la solución a algún problema persistente. La organización propia emerge cuando los individuos, los agentes independientes (células en un cuerpo, especies en un ecosistema, desarrolladores en un equipo de software) cooperan [colaboran] para crear salidas emergentes. Una salida emergente es una propiedad más allá de la capacidad de cualquier agente individual. Por ejemplo, las neuronas individuales del cerebro no poseen conciencia, pero en forma colectiva

6 Este enfoque es análogo a conocer las preguntas del examen antes de comenzar a estudiar. Esto facilita mucho más el estudio al enfocar la atención sólo sobre las preguntas que serán formuladas.

7 Las pruebas de unidad, que se tratan con detalle en el capítulo 13, se enfocan sobre un componente individual del software, al ejercitar la interfaz de los componentes, las estructuras de datos y la funcionalidad en un esfuerzo por descubrir los errores locales en el componente.

generan la propiedad de la conciencia. Tendemos a ver este fenómeno del surgimiento colectivo como un accidente, o al menos como independiente y sin reglas. El estudio de la organización propia demuestra que dicha visión es errónea.

Highsmith argumenta que un enfoque de desarrollo ágil y adaptativo basado en la colaboración es "tanto como una fuente de orden en las complejas interacciones entre disciplina e ingeniería". Él define un "ciclo de vida" del DAS (figura 4.2), el cual incorpora tres fases: especulación, colaboración y aprendizaje.

a) Especulación. En esta fase se inicia el proyecto y se conduce el ciclo adaptativo de planeación. Este último utiliza información de inicio del proyecto —el enunciado de la misión del cliente, restricciones de proyecto (por ejemplo, fechas de entrega o descripciones del cliente) y los requisitos básicos— para definir el conjunto de ciclos de lanzamiento (incrementos del software) que se requerirán para el proyecto.8

b) Colaboración. La gente motivada trabaja junta de una forma que multiplica su talento y sus salidas creativas más allá de sus números absolutos. Este enfoque de colaboración es un tema recurrente en todos los métodos ágiles, pero la cooperación no es fácil. No es sólo comunicación, aunque la comunicación es parte de ella. No es sólo un asunto de trabajo en equipo, aunque un equipo "cuajado" (capítulo 21) es esencial para la presencia de la colaboración real. No es un rechazo al individualismo, ya que la creatividad individual representa un papel importante en el pensamiento de colaboración. Esto es, por encima de todo, una cuestión de confianza. Las personas que trabajan juntas deben confiar entre sí para 1) criticar sin animosidad; 2) ayudar sin resentimientos; 3) trabajar tan duro o más duro de lo que ya lo hacen; 4) tener el conjunto de aptitudes para contribuir al trabajo en curso; y 5) comunicar los problemas o preocupaciones en una forma que conduzca a la acción efectiva.

c) Aprendizaje. Como miembros de un equipo de DAS se comienzan a desarrollar los componentes integrantes de un ciclo adaptativo, la importancia radica en el aprendizaje y en el progreso a través de un ciclo completo. De hecho, Highsmith [HIGGOO] argumenta que los desarrolladores de software a menudo sobreestiman su comprensión (de la tecnología, el proceso y el proyecto), y que el aprendizaje les podría ayudar a mejorar su grado de entendimiento real. Los equipos del DAS aprenden de tres maneras:

1. Grupos enfocados. El cliente o los usuarios finales proporcionan retroalimentación sobre los incrementos de software que se entregan. Esto indica en forma directa la satisfacción o la insatisfacción de las necesidades del negocio.

8 Obsérvese que el plan del ciclo adaptativo puede adaptarse, y con probabilidad lo hará, al proyecto cambiante y a las condiciones del negocio.

2. Revisiones técnicas formales. Los miembros del equipo del DAS revisan los componentes del software desarrollado mientras mejoran su calidad y su aprendizaje.

3. Post mortem. El equipo de DAS se vuelve introspectivo al vigilar su propio desempeño y proceso (con el propósito de aprender acerca de su enfoque y después mejorarlo).

Es importante destacar que la filosofía del DAS es meritoria sin importar el modelo de proceso empleado. El acento general en la dinámica de la organización propia en los equipos, la colaboración interpersonal y el aprendizaje individual y por equipo conduce grupos de proyectos de software con una mayor posibilidad de éxito.

8. MÉTODO DE DESARROLLO DE SISTEMAS DINÁMICOS (MDSD)

El método de desarrollo de sistemas dinámicos [STA97] es un enfoque de desarrollo de software ágil que "proporciona un marco de trabajo para construir y mantener sistemas con restricciones de tiempo muy estrechas mediante el empleo de la construcción de prototipos increméntales en un ambiente de proyecto controlado" [CCS02]. Similar a algunos aspectos del proceso DRA descrito en el capítulo 3, el MDSD sugiere una filosofía tomada de una modificación del principio de Pareto. En este caso, 80 por ciento de la aplicación se puede entregar en 20% del tiempo que tomaría entregar 100 por ciento de la aplicación (sistema completo).

Al igual que la PE y el DSA, el MDSD sugiere un proceso iterativo de software. Sin embargo, el enfoque del MDSD en cada iteración sigue la regla del 80 por ciento. Esto es, sólo se necesita el trabajo suficiente para cada incremento y para facilitar el movimiento hacia el nuevo incremento. Los detalles restantes se pueden completar posteriormente cuando se conozcan más los requisitos de negocios o cuando los cambios hayan sido solicitados o ajustados.

En la red mundial hay una organización (DSDM Consortium, www.dsdm.org) que de manera colectiva asume el papel de "conservador" del método. Esta organización ha definido un modelo ágil de proceso, llamado el ciclo de vida del MDSD. Este método define tres ciclos iterativos diferentes, a los cuales preceden dos actividades del ciclo de vida adicionales:

Estudio de factibilidad: establece los requisitos básicos de negocio y las restricciones asociadas con la aplicación del método y para evaluar si la aplicación es una candidata viable para el proceso del MDSD.

Estudio de negocios: establece los requisitos funcionales y de información que permitirán que la aplicación proporcione un valor al negocio; también define la arquitectura básica de la aplicación.

Iteración de modelo funcional: produce una serie de prototipos increméntales que demuestran la funcionalidad para el cliente (nota: todos los prototipos del MDSD están diseñados para evolucionar hacia la aplicación entregable). El propósito durante este ciclo iterativo es recopilar requisitos adicionales mediante la retroalimentación de lo que obtiene el usuario, mientras éste trabaja con el prototipo.

Iteración de construcción y diseño: revisa la construcción de prototipos durante la iteración del modelo funcional para asegurar que cada uno de ellos ha sido desarrollado de una manera que le permitirá proporcionar un valor operativo de negocios para los usuarios finales. En algunos casos, la iteración del modelo funcional y el diseño y la iteración de construcción suceden en forma concurrente.

Implementación: coloca el incremento de software más reciente (un prototipo "operacionalizado") en el ambiente operativo. Se debe destacar que 1) el incremento puede no estar 100 por ciento completo o 2) se pueden requerir cambios cuando el incremento se coloca en el sitio. En cualquier caso, el trabajo de desarrollo del MDSD continúa al regresar a la actividad de iteración del modelo de función.

El MDSD se puede combinar con la PE para obtener un enfoque conjunto que define un modelo sólido de proceso (el ciclo de vida del MDSD) con los aspectos prácticos (PE) necesarios para construir incrementos de software. Además, los conceptos del DAS de colaboración y equipos auto organizados se pueden adaptar a un modelo de proceso combinado.

9. MELÉ

Melé (término derivado de una jugada de rugby9) es un modelo ágil de proceso que desarrollaron Jeff Sutherland y su equipo a principios de la década de 1990. En años recientes, Schwaber y Beedle [SCH01] han presentado el desarrollo posterior de los métodos de melé. Los principios de la melé [ADM96] son consistentes con el manifiesto ágil.

• Los equipos de trabajo pequeños están organizados para "maximizar la comunicación, minimizar los gastos generales y maximizar el hecho de compartir conocimiento tácito e informal".

• El proceso debe adaptarse a los cambios técnicos y de negocios "para asegurar que se produzca el mejor producto posible".

• El proceso produce incrementos frecuentes de software "los cuales se pueden inspeccionar, ajustar, probar, documentar y construir".

• El trabajo de desarrollo y la gente que lo realiza están divididos en "particiones o paquetes de bajo acoplamiento".

• Conforme se construye el producto se realizan pruebas y documentación constantes.• Los procesos de melé proporcionan la "capacidad de declarar un producto como 'realizado' siempre que

esto se requiera (porque la competencia acaba de hacer un lanzamiento, porque la compañía necesita el dinero, porque el usuario/cliente necesita las funciones, porque ya se está en el momento en que se prometió..." [ADM96].

Con los principios de la melé se guían las actividades dentro de un proceso que incorpora las siguientes actividades del marco de trabajo; requisitos, análisis, diseño, evolución y entrega. En cada actividad del marco de trabajo las tareas de trabajo suceden dentro del patrón de proceso (tratado en el párrafo siguiente) llamado sprint. El trabajo realizado dentro de un sprint (el número requerido de sprints variará de acuerdo con el tamaño y la complejidad del producto) se adapta al problema y con frecuencia lo modifica en tiempo real el equipo de melé. En la figura 4.3 se ilustra el flujo general del proceso de melé.

La melé subraya el uso de un conjunto de "patrones de proceso de software" [NOY02] que ha probado su efectividad en proyectos con tiempos de entrega muy reducidos, requisitos cambiantes y condiciones críticas en los negocios. Cada uno de estos patrones de proceso define un conjunto de actividades de desarrollo:

Retrasos: son una lista que considera la prioridad de los requisitos o características de proyecto que proporcionan un valor comercial para el cliente. En cualquier momento se pueden agregar elementos a los retrasos (así se introducen los cambios), El gerente de producto evalúa los retrasos y actualiza las prioridades de acuerdo con lo requerido.

9 Un grupo de jugadores se alinea alrededor del balón y los compañeros de equipo trabajan juntos (algunas veces de manera violenta) para desplazar el balón hacia el lado contrario del campo de juego

Sprint: consiste en unidades de trabajo que se requieren para satisfacer un requisito definido en los retrasos en un periodo predefinido (el lapso usual es de 30 días). En esta etapa, los elementos de los retrasos a los que se dirigen las unidades de trabajo del sprint están congelados (es decir, durante el sprint no se introducen cambios). Por lo tanto, el sprint permite a los miembros del equipo trabajar en un ambiente enfocado al corto plazo, pero estable.

Reuniones de melé: son reuniones cortas (por lo general de 15 minutos) y las realiza a diario el equipo de melé. Existen tres preguntas que plantean y responden todos los miembros del equipo.

¿Qué hiciste desde la última reunión?¿Cuáles obstáculos encontraste?¿Qué esperas lograr para la siguiente reunión del equipo?

Un líder de equipo, llamado "maestro de la melé", preside la reunión y evalúa las respuestas de cada persona. Cada reunión de melé ayuda al equipo a descubrir problemas potenciales tan pronto como sea posible. Estas reuniones diarias también conducen a la "socialización del conocimiento" [BEE99] y, por ende, a promover una estructura de equipo con organización propia.

Demostración: se entrega el incremento de software al cliente de forma que éste demuestre y evalúe la funcionalidad implementada. Es importante señalar que la de-mostración quizá no contenga toda la funcionalidad planeada, sino aquellas funciones susceptibles de entregarse dentro del periodo establecido.

Beedle y sus colegas [BEE99] presentan un análisis completo de estos patrones y establecen: "La MELÉ supone la existencia del caos...". El patrón de proceso de la melé permite que un equipo de desarrollo de software trabaje de manera exitosa en un mundo donde la eliminación de la incertidumbre es imposible.

10. CRISTAL

Alistair Cockburn [COC02a] y Jim Highsmith [HIG02b] crearon la familia cristal de los métodos ágiles'' con el fin de lograr un enfoque de desarrollo de software que coloca un premio en la "manejabilidad" durante lo que Cockburn caracteriza como "un juego cooperativo de inventiva y comunicación con recursos limitados, con una meta primaria consistente en la entrega de software útil y en funcionamiento y una meta secundaria de prepararse para el juego siguiente" [COC02b].

Para alcanzar la manejabilidad, Cockburn y Highsmith definieron un conjunto de metodolog ías, cada una de ellas con elementos esenciales comunes a todas, y funciones, patrones de proceso, productos de trabajo y prácticas únicas en cada una de ellas. En realidad, la familia cristal es un conjunto de procesos ágiles, los cuales

han probado su efectividad en diferentes tipos de proyectos. El objetivo es permitir que los equipos ágiles seleccionen el miembro de la familia cristal más apropiado para su proyecto y ambiente.

11. DESARROLLO CONDUCIDO POR CARACTERÍSTICAS (DCC)

El desarrollo conducido por características (DCC) lo concibieron originalmente Peter Coad y sus colegas [COA99] como un modelo de proceso práctico para la ingeniería del software orientada a objetos. Stephen Palmer y John Felsing [PAL02] han extendido y mejorado el trabajo de Coad, al describir un proceso adaptativo y ágil que puede aplicarse en proyectos de software de tamaño moderado y grande.

En el contexto del DCC una característica "es una función valuada por el cliente que puede implementarse en dos semanas o menos" [COA99]. La importancia que se le concede a la definición de características proporciona los siguientes beneficios.

• Como las características son bloques pequeños de funcionalidad entregable, los usuarios las describen con mayor facilidad, pueden entender cómo éstas se relacionan con otras con mayor rapidez, y pueden revisarlas de mejor manera en búsqueda de ambigüedades, errores u omisiones.

• Las características se pueden organizar en un agrupamiento jerárquico relacionado con el negocio.• Como una característica es el incremento de software entregable, el equipo desarrolla características

operativas cada dos semanas.• Debido a que las características son pequeñas, sus diseños y representaciones de código son más fáciles de

inspeccionar de manera efectiva.• La planeación del proyecto, la elaboración de su programa y su rastreo los guía la jerarquía de la

característica, en lugar de hacerlo un conjunto de tareas de ingeniería del software adaptado en forma arbitraria.

Coad y sus colegas [COA99] sugieren la siguiente plantilla para definir una característica:

<Acción> el <resultado> <porlparaldela> un <objeto>

Donde un <objeto> es "una persona, sitio o cosa (incluyendo papeles, momentos en el tiempo o intervalos de tiempo, o descripciones del tipo de catálogo de entrada)". Los ejemplos de las características para una aplicación de comercio electrónico podrían ser:

Agregar el producto a un carrito de supermercado. Desplegar las especificaciones técnicas de un producto. Almacenar la información

de navegación para un cliente.

Un conjunto de características agrupa características relacionadas en categorías relacionadas con el negocio y se define como [COA991:

<Acción><-ar, -er, -ir> un <objeto>

Por ejemplo: hacer la venta del producto es un conjunto de características que podría abarcar las características relacionadas con anterioridad y otras.

El enfoque del DCC define cinco actividades de "colaboración" dentro del marco de trabajo (en el DCC éstas se llaman "procesos") como se muestra en la figura 4.4.

El DCC concede una mayor importancia a las directrices y técnicas de la gestión del proyecto que muchos otros métodos ágiles. Cuando los proyectos crecen en tamaño y complejidad, con frecuencia la gestión ad hoc del proyecto es inadecuada. Resulta esencial para los desarrolladores, sus gerentes y el cliente entender el estatus del proyecto: cuáles logros se han tenido y cuáles programas se han encontrado. Si la presión de la fecha límite es significativa, resulta crítico determinar si los incrementos de software (características) están programados de manera apropiada. Para lograrlo el DCC define seis puntos de fijación durante el diseño y la implementación de una característica: "ensayo del diseño, diseño, inspección del diseño, código, inspección del código, promoción de la construcción" [COA99].

12. MODELADO ÁGIL (MA)

En muchas situaciones los ingenieros de software deben construir sistemas grandes y críticos para los negocios. El ámbito y la complejidad de dichos sistemas se deben modelar de forma que 1) todas las circunscripciones entiendan mejor lo que se debe lograr; 2) el problema se divida de manera efectiva entre la gente que lo debe resolver; y 3) la calidad se evalúe en cada paso conforme el sistema se desarrolla y construye.

En los últimos 30 años se ha propuesto una amplia variedad de métodos y notación para el modelado de ingeniería del software en el análisis y diseño (tanto arquitectónico como al nivel de componentes). Estos métodos tienen un mérito significativo, pero se ha comprobado que su aplicación enfrenta dificultades y es desafiante poderlos sostener (sobre muchos proyectos). Parte del problema es el "peso" de estos métodos de modelado. Con esto se hace referencia al volumen de notación requerida, el grado de formalismo sugerido, el tamaño de los modelos para proyectos grandes, y la dificultad para el mantenimiento del modelo conforme ocurren los cambios. Aun así, el modelado del análisis y el diseño tiene un beneficio sustancial para los proyectos grandes: por ninguna otra razón que hacer que estos proyectos sean manejables en el sentido intelectual. ¿Existe un enfoque ágil para el modelado de la ingeniería del software que pudiera proporcionar una alternativa?En el "Sitio oficial del modelado ágil", Scott Ambler [AMB02] describe el modela do ágil (MA) de la siguiente manera:

El modelado ágil (MA) es una tecnología basada en la práctica para el modelado efectivo de los sistemas basados en software. Dicho de una forma más simple, el modelado ágil es una colección de valores, principios y prácticas para el modelado de software que puede aplicarse en un proyecto de desarrollo de software de una manera efectiva y ligera. Los modelos ágiles son más efectivos que los tradicionales porque son sólo lo suficientemente buenos, no tienen que ser perfectos [AMB02J:

Además de los valores consistentes con el manifiesto ágil, Ambler sugiere valor y humildad. Un equipo ágil debe tener el valor para tomar decisiones que ocasionarán el rechazo y la re fabricación de un diseño. Debe tener la humildad de reconocer que quienes manejan la tecnología no tienen todas las respuestas, y que los expertos en negocios y otros participantes de la empresa son dignos de respeto y consideración.

A pesar de que el MA sugiere un arreglo amplio de principios de modelados “esenciales” y “suplementarios", los responsables de que el MA sea único son los siguientes [AMB02J:

Modelar con un propósito. Un desabollador que use el MA debe tener una meta específica en mente (por ejemplo, comunicar información al cliente o ayudarle a en tender mejor algún aspecto del software) antes de crear el modelo. Una vez identificada la meta para el modelo, el tipo de notación que se usará y el grado de detalle requerido serán más obvios.

Usar múltiples modelos. Existen muchos modelos y notaciones diferentes con los cuales describir el software. Sólo un pequeño subconjunto es esencial para la mayoría de los proyectos. El MA sugiere que para proporcionar la visión necesaria cada modelo debe presentar un aspecto diferente del sistema, y sólo aquellos modelos que proporcionen un valor para la audiencia a la que están dirigidos deben usarse.

Viajar ligero. La realización de trabajo de la ingeniería del software requiere conservar sólo los modelos que proporcionarán valor a largo plazo y descartar el resto. Cada producto de trabajo que se conserve debe recibir mantenimiento conforme se presentan cambios. Esto representa un trabajo que reduce la velocidad del equipo. Ambler [AMB02] observa que "cada vez que se decide conservar un modelo se intercambia la

agilidad por la conveniencia de tener la información disponible para el equipo de una forma abstracta (por ende, existe una posibilidad de mejorar la comunicación dentro del equipo, así como con los propietarios del proyecto)".

El contenido es más importante que la representación. El modelado debe comunicar información a la audiencia a la que está dirigido. Un modelo sintácticamente perfecto que comunique sólo un poco del contenido útil no tiene tanto valor como un modelo con una notación defectuosa que, sin embargo, comunique un contenido valioso para su audiencia.

Conocer los modelos y las herramientas con que se crean. Es necesario entender las fortalezas y debilidades de cada modelo y las herramientas con los que se creó.

Adaptar en forma local. El enfoque del modelado se debe adaptar a las necesidades del equipo ágil.13. RESUMEN

Una filosofía ágil para la ingeniería del software se relaciona con cuatro aspectos clave: la importancia de la organización propia de los equipos, los cuales controlan el trabajo que realizan; comunicación y colaboración entre los miembros del equipo y entre los profesionales y sus clientes; un reconocimiento de que el cambio representa una oportunidad; y un especial cuidado en la entrega rápida del software que satisfaga al cliente. Los modelos de proceso ágil se diseñaron para cumplir con cada uno de estos aspectos. La programación extrema (PE) es el proceso ágil que más se utiliza. Organizada como cuatro actividades del marco de trabajo planeación, diseño, codificación y pruebas, la PE sugiere algunas técnicas innovadoras y poderosas que permiten a un equipo ágil crear frecuentes lanzamientos de software al entregar características y funcionalidad que describe y después prioriza el cliente. El desarrollo de software adaptativo (DSA) destaca la colaboración humana y la organización propia del equipo. Organizado con tres actividades del marco de trabajo especulación, colaboración y aprendizaje, el DSA utiliza un proceso iterativo que incorpora la planeación del ciclo adaptativo, métodos de recopilación de requisitos relativamente rigurosos y un ciclo iterativo de desarrollo que incorpora grupos enfocados en el cliente y revisiones técnicas formales como mecanismos de re-realimentación en tiempo real. El método de desarrollo de sistemas dinámicos (MDSD) define tres diferentes ciclos iterativos iteración funcional del modelo, iteración de diseño y construcción e implementación precedidos por dos actividades del ciclo de vida adicionales: estudio de factibilidad y estudio de negocios. El MDSD aboga por el uso de programas y sugiere que sólo se requiere el trabajo suficiente para cada incremento de software y así facilitar el movimiento hacia el incremento próximo. La melé subraya el uso de un conjunto de patrones de proceso de software que han probado su efectividad en proyectos con límites de tiempo muy ajustados, requisitos cambiantes y que son críticos para el negocio. Cada patrón de proceso define un conjunto de tareas de desarrollo y permite al equipo de melé construir un proceso que se adapte a las necesidades del proyecto. Cristal es una familia de modelos ágiles de proceso que pueden adaptarse a las características específicas de un proyecto. Como otros enfoques ágiles, cristal adopta una estrategia iterativa, pero se ajusta al rigor del proceso para incluir proyectos de tamaños y complejidades diferentes. El desarrollo conducido por características (DCC) es algo más "formal" que otros métodos ágiles, pero aun así mantiene la agilidad al enfocar al equipo de proyecto en el desarrollo de características, funciones que evalúa el cliente y que se pueden implementar en dos semanas o menos. El DCC concede una mayor importancia al proyecto y a su gestión que otros enfoques ágiles. El modelado ágil (MA) sugiere que el modelado es esencial para todos los sistemas, pero que la complejidad, tipo y tamaño del modelo debe ajustarse al software que será construido. Mediante la proposición de una serie de principios de modelados esenciales y complementarios, el MA proporciona una guía útil para los profesionales durante las tareas de análisis y diseño.