Desarrollo de software ágil (Agile software development)

El desarrollo de software ágil abarca una variedad de metodologías para la creación de software, unificadas por los valores y principios fundamentales establecidos en 2001 por The Agile Alliance, un colectivo de 17 profesionales del software. Su documento fundamental, el Manifiesto para el desarrollo de software ágil, articula estos valores rectores:

Desarrollo de software ágil es un término general para enfoques de desarrollo de software que reflejan los valores y principios acordados por The Agile Alliance, un grupo de 17 profesionales del software, en 2001. Como se documenta en su Manifiesto para el desarrollo de software ágil, los profesionales valoran:

• Priorizar a las personas y sus interacciones sobre procesos y herramientas rígidos.
• Enfatizar el software funcional sobre la documentación extensa.
• Valorar la colaboración del cliente por encima de la estricta negociación del contrato.
• Favorecer la capacidad de respuesta al cambio frente a la adherencia a un plan predeterminado.

Los profesionales se inspiraron en metodologías contemporáneas como la programación extrema, Scrum, el método de desarrollo de sistemas dinámicos y el desarrollo de software adaptativo. También reconocieron la necesidad de una alternativa a los procesos de desarrollo de software pesados ​​y con uso intensivo de documentación predominantes.

Numerosas prácticas de desarrollo de software han evolucionado a partir de la filosofía ágil. Estos enfoques ágiles, a menudo denominados Agile (en mayúscula), implican la obtención de requisitos, el descubrimiento y la mejora continua de soluciones, logrados a través de los esfuerzos colaborativos de equipos autoorganizados y multifuncionales que trabajan en estrecha colaboración con los clientes o usuarios finales.

Aunque una considerable evidencia anecdótica sugiere que la mentalidad ágil y sus prácticas asociadas mejoran el proceso de desarrollo de software, los datos empíricos que respaldan estas afirmaciones siguen siendo limitados y no concluyentes.

Contexto histórico

Las metodologías de desarrollo de software iterativo e incremental tienen raíces históricas que se remontan a 1957, con los conceptos de gestión de proyectos evolutivos y desarrollo de software adaptativo que aparecieron a principios de los años 1970.

La década de 1990 fue testigo del surgimiento de varios métodos de desarrollo de software ligeros, desarrollados en respuesta a las metodologías pesadas dominantes (frecuentemente categorizadas como en cascada), que Los críticos lo caracterizan como excesivamente regulado, planificado y microgestionado. Los enfoques ligeros notables de este período incluyen el Desarrollo Rápido de Aplicaciones (RAD) en 1991; el Proceso Unificado (UP) y el Método de Desarrollo de Sistemas Dinámicos (DSDM), ambos introducidos en 1994; Melé en 1995; Crystal Clear y Extreme Programming (XP), ambos de 1996; y Desarrollo impulsado por funciones (FDD) en 1997. A pesar de ser anteriores al Manifiesto Ágil, estos métodos ahora se clasifican colectivamente como enfoques de desarrollo de software ágiles.

Al mismo tiempo, desde 1991, se habían estado desarrollando cambios análogos en las filosofías de fabricación y gestión, influenciados por principios de gestión eficiente.

En 2001, diecisiete desarrolladores de software se reunieron en un resort en Snowbird, Utah, para deliberar sobre metodologías de desarrollo ligeras. Los asistentes incluyeron a Kent Beck (Programación extrema), Ward Cunningham (Programación extrema), Dave Thomas (Programación pragmática, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (Desarrollo de software adaptativo), Alistair Cockburn (Crystal), Robert C. Martin (SOLID), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler (OOAD y UML), James Grenning, Andrew Hunt (Programación pragmática, Ruby), Ron Jeffries (Programación extrema), Jon Kern, Brian Marick (Ruby, desarrollo basado en pruebas) y Steve Mellor (OOA). Este colectivo, conocido como The Agile Alliance, publicó posteriormente el Manifiesto para el desarrollo de software ágil.

En 2005, un equipo liderado por Cockburn y Highsmith fue autor de la Declaración de interdependencia de PM, un apéndice que describe los principios de gestión de proyectos destinados a guiar la gestión de proyectos de software en alineación con las metodologías ágiles de desarrollo de software.

En 2009, un grupo colaborativo que trabajó con Martin desarrolló el Software Craftsmanship Manifesto, una extensión de principios de desarrollo de software diseñados para dirigir el desarrollo de software ágil hacia una conducta y dominio profesionales.

En 2011, Agile Alliance estableció la Guía de prácticas ágiles, que luego pasó a llamarse Glosario ágil en 2016. Este recurso funciona como un compendio de código abierto en evolución que proporciona definiciones prácticas de prácticas, terminología y componentes ágiles, complementados con interpretaciones y pautas experienciales aportadas por la comunidad global de profesionales ágiles.

Valores y principios fundamentales

Valores fundamentales

El Manifiesto para el desarrollo de software ágil establece:

"Continuamente descubrimos métodos superiores para el desarrollo de software a través de la práctica directa y ayudando a otros en este esfuerzo. Nuestro trabajo nos ha llevado a priorizar los siguientes valores:"

• Las personas y las interacciones se valoran más que los procesos y las herramientas.
• El software que funciona se valora más que la documentación completa.
• La colaboración del cliente se valora más que la negociación del contrato.
• Se valora más responder al cambio que seguir un plan rígido.

Esto implica que, si bien los elementos de la derecha poseen un valor inherente, a los de la izquierda se les concede mayor importancia.

Scott Ambler articuló esta perspectiva afirmando:

• Si bien las herramientas y los procesos son importantes, la eficacia colaborativa de personas competentes es primordial.
• Aunque la documentación completa facilita la comprensión de la arquitectura y el uso del software, el objetivo principal del desarrollo sigue siendo la creación de software, no la generación de documentación.
• Un acuerdo contractual es importante, pero no puede reemplazar la necesidad de una estrecha colaboración con los clientes para determinar sus requisitos.
• Los planes de proyecto son cruciales, pero deben mantener suficiente flexibilidad para adaptarse a las tecnologías en evolución, los cambios ambientales, las prioridades de las partes interesadas y las mejoras en la comprensión de problemas y soluciones.

Jim Highsmith, al presentar el manifiesto en nombre de Agile Alliance, declaró:

El movimiento Agile no se opone a las metodologías; de hecho, muchos de sus defensores pretenden restablecer la credibilidad del término "metodología" y restaurar el equilibrio. Si bien se adopta el modelado, su propósito no es simplemente archivar diagramas en repositorios corporativos obsoletos. De manera similar, se valora la documentación, pero no en forma de volúmenes extensos, sin mantenimiento y poco utilizados. Se lleva a cabo la planificación, pero se reconocen sus limitaciones inherentes dentro de entornos dinámicos. Las personas que etiquetan a los defensores de XP, SCRUM u otras metodologías ágiles como "hackers" demuestran una falta de comprensión tanto de estas metodologías como de la definición original del término "hacker".

Principios básicos

Los valores antes mencionados se sustentan en los siguientes principios:

1. Lograr la satisfacción del cliente mediante la entrega rápida y continua de software de alto valor.
2. Acomodarse a los requisitos cambiantes, incluso durante etapas avanzadas de desarrollo.
3. Lanzamiento de software funcional a intervalos frecuentes (medidos en semanas, no en meses).
4. Fomentar la colaboración diaria y continua entre las partes interesadas del negocio y los equipos de desarrollo.
5. Estructurar proyectos en torno a personas motivadas, que garanticen confianza y autonomía.
6. Reconocer la interacción cara a cara como el método de comunicación más eficaz (lo que implica la coubicación).
7. Priorizar el software funcional como principal métrica para la evaluación del progreso.
8. Garantizar prácticas de desarrollo sostenible que faciliten un ritmo operativo consistente.
9. Mantener un enfoque perpetuo en lograr la excelencia técnica y un diseño sólido.
10. Hacer hincapié en la simplicidad, definida como la optimización estratégica del trabajo no ejecutado, como principio fundamental.
11. Reconocer que las arquitecturas, los requisitos y los diseños óptimos se originan en equipos autoorganizados.
12. Facilitar la introspección regular del equipo para mejorar la eficacia, seguida de adaptaciones apropiadas.

Descripción general

Desarrollo iterativo, incremental y evolutivo

La mayoría de las metodologías de desarrollo ágiles segmentan el desarrollo de productos en incrementos pequeños y manejables, minimizando así la planificación y el diseño iniciales extensos. Estos incrementos, a menudo denominados iteraciones o sprints, representan períodos de tiempo breves y fijos (timeboxes) que normalmente abarcan de una a cuatro semanas. Cada iteración involucra a un equipo multifuncional responsable de todas las funciones de desarrollo, incluida la planificación, el análisis, el diseño, la codificación, las pruebas unitarias y las pruebas de aceptación. Al finalizar una iteración, se presenta un producto funcional a las partes interesadas. Este enfoque mitiga significativamente el riesgo general del proyecto y permite una rápida adaptación a los requisitos cambiantes. Si bien una sola iteración puede no producir suficiente funcionalidad para un lanzamiento al mercado, el objetivo es producir una versión desplegable (con defectos mínimos) al final de cada ciclo. El desarrollo incremental permite que los productos "fallen con frecuencia y tempranamente" a lo largo de cada fase iterativa, evitando fallas catastróficas en la fecha de lanzamiento final. En consecuencia, pueden ser necesarias múltiples iteraciones para lanzar un producto o introducir nuevas funciones. La funcionalidad del software sirve como principal indicador de progreso.

Comunicación eficiente y directa

El sexto principio del Manifiesto Ágil para el desarrollo de software afirma: "El método más eficiente y eficaz de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara". Esta declaración, formulada en 2001 antes de la adopción generalizada de la videoconferencia, enfatiza la eficacia del intercambio directo de información en lugar de exigir la ubicación conjunta del equipo.

El principio de coubicación postula que los miembros del equipo deben estar físicamente agrupados para fomentar la identidad del equipo y mejorar la comunicación. Esta disposición facilita las interacciones directas cara a cara, idealmente utilizando una pizarra, lo que reduce el tiempo de ciclo típico asociado con los intercambios de preguntas y respuestas mediados por teléfono, chat persistente, wikis o correo electrónico. Sin embargo, estudios recientes, impulsados ​​por la adopción generalizada del trabajo remoto durante la pandemia de COVID-19 y los avances en las herramientas, indican una relevancia cada vez menor de la coubicación en los entornos de trabajo contemporáneos.

Independientemente de la metodología de desarrollo elegida, cada equipo debe incorporar un representante del cliente, designado como propietario del producto dentro del marco de Scrum. Esta persona está autorizada por las partes interesadas para representar sus intereses y se compromete a ser accesible para los desarrolladores para consultas durante cada iteración. Al finalizar cada iteración, las partes interesadas del proyecto y el representante del cliente evalúan colectivamente el progreso y reevalúan las prioridades. Este proceso tiene como objetivo optimizar el retorno de la inversión (ROI) y garantizar la congruencia con los requisitos del cliente y los objetivos organizacionales. El énfasis en la satisfacción de las partes interesadas, lograda a través de la interacción regular y revisiones de final de fase, subraya por qué este enfoque se caracteriza frecuentemente como una metodología centrada en el cliente.

Radiador de información

Dentro del desarrollo de software ágil, un radiador de información se refiere a una pantalla física típicamente grande, como una pizarra con notas adhesivas o una ayuda visual similar, ubicada estratégicamente cerca del equipo de desarrollo para la visibilidad pública. Su propósito es proporcionar un resumen actual del estado de desarrollo del producto. Además, un indicador luminoso de construcción puede servir para informar al equipo sobre el estado de desarrollo actual de su producto.

Bucles de retroalimentación acelerados y ciclos de adaptación

Una característica definitoria del desarrollo ágil de software es la reunión diaria, denominada scrum diario dentro del marco de Scrum. Durante esta sesión concisa, que suele durar unos 15 minutos, los miembros del equipo evalúan colectivamente su progreso hacia sus objetivos y determinan si son necesarios ajustes en su estrategia. Para cumplir con la limitación de tiempo estipulada, los equipos frecuentemente emplean preguntas estructuradas (como los logros del día anterior, los objetivos del día actual y cualquier impedimento o riesgo identificado) y posponen las discusiones en profundidad y la resolución de problemas hasta que concluya la reunión.

Énfasis en la calidad

Con frecuencia se emplean diversas herramientas y técnicas especializadas, incluida la integración continua, las pruebas unitarias automatizadas, la programación en pares, el desarrollo basado en pruebas, los patrones de diseño, el desarrollo basado en el comportamiento, el diseño basado en el dominio y la refactorización de código, para elevar la calidad del producto y aumentar la agilidad del desarrollo. Este enfoque se basa en el principio de incorporar la calidad desde las fases iniciales de diseño y construcción, permitiendo la demostración de software funcional a los clientes en cualquier momento, o como mínimo, al finalizar cada iteración.

Fundamentos filosóficos

A diferencia de la ingeniería de software convencional, el desarrollo de software ágil aborda principalmente el desarrollo de sistemas y productos complejos caracterizados por atributos dinámicos, indeterminados y no lineales. Obtener estimaciones precisas, planes estables y predicciones confiables durante las primeras etapas suele ser un desafío, lo que genera poca confianza en su precisión. Los profesionales ágiles se esfuerzan por mitigar el "acto de fe" necesario antes de que se pueda obtener evidencia tangible de valor. Los requisitos y el diseño se consideran emergentes. En tales contextos, las especificaciones iniciales extensas generalmente se consideran ineficientes y económicamente poco sólidas. Estos argumentos fundamentales, junto con ideas extraídas de años de éxitos y fracasos de la industria, han influido en la preferencia del desarrollo ágil por metodologías adaptativas, iterativas y evolutivas.

Metodologías adaptativas versus predictivas

Las metodologías de desarrollo abarcan un espectro que va desde las adaptativas hasta las predictivas. Los enfoques ágiles de desarrollo de software se sitúan en el extremo adaptativo de este espectro. Una característica fundamental de los métodos de desarrollo adaptativo es la adopción de un enfoque de ola continua para la planificación del cronograma. Esta estrategia implica identificar hitos clave manteniendo la flexibilidad en el camino de ejecución para alcanzarlos, y también permite la modificación de los propios hitos a medida que avanza el desarrollo.

adaptativas priorizan el ajuste rápido a las circunstancias cambiantes. En consecuencia, un equipo adaptable modifica fácilmente su enfoque en respuesta a los requisitos cambiantes del proyecto. Estos equipos enfrentan inherentemente desafíos a la hora de delinear con precisión los resultados futuros. La especificidad de un método adaptativo disminuye proporcionalmente con la distancia temporal de una fecha determinada. Por ejemplo, un equipo adaptativo no puede proporcionar un cronograma exacto de tareas para la próxima semana, sino que describe las características planificadas para el mes siguiente. Cuando se les pregunta sobre un lanzamiento programado con seis meses de anticipación, es posible que un equipo adaptativo solo pueda articular la declaración de la misión del lanzamiento o una proyección de su valor anticipado en relación con el costo.

En contraste, las metodologías predictivas enfatizan el análisis meticuloso y la planificación futura detallada, incorporando disposiciones para los riesgos identificados. En su forma más rigurosa, los equipos predictivos pueden articular con precisión las características y tareas programadas para todo el ciclo de vida de desarrollo. La eficacia de los métodos predictivos depende de un análisis sólido en la fase inicial; errores importantes en esta etapa pueden impedir gravemente la capacidad de un proyecto para alterar su trayectoria. Los equipos predictivos frecuentemente establecen un tablero de control de cambios para garantizar que solo se consideren las modificaciones más impactantes.

El análisis de riesgos sirve como una herramienta crucial para seleccionar entre metodologías adaptativas (ágiles o basadas en valores) y predictivas (basadas en planes). Barry Boehm y Richard Turner proponen que cada extremo de este continuo metodológico posee su terreno de origen distinto, caracterizado de la siguiente manera:

Agile versus cascada

Una distinción principal entre los métodos ágiles de desarrollo de software y el modelo en cascada radica en sus respectivos enfoques para el control de calidad y las pruebas. Dentro del modelo en cascada, el ciclo de vida de desarrollo de software (SDLC) avanza a través de fases secuenciales, donde la finalización de una fase es un requisito previo para el comienzo de la siguiente. En consecuencia, la fase de prueba es una etapa distinta y posterior a una fase de construcción. Por el contrario, en el desarrollo de software ágil, las actividades de prueba se integran y completan simultáneamente con la programación dentro de la misma iteración.

La integración de las pruebas en cada iteración, que desarrolla componentes de software incrementales, permite a los usuarios interactuar con frecuencia y validar el valor de estas nuevas funcionalidades. Esta retroalimentación temprana de los usuarios sobre el valor real del software actualizado facilita decisiones más informadas sobre su desarrollo futuro. La inclusión de una retrospectiva de valor y una sesión de replanificación del software en cada iteración (Scrum, por ejemplo, normalmente emplea iteraciones de dos semanas) permite al equipo adaptar continuamente sus planes, maximizando así el valor entregado. Este proceso iterativo refleja el ciclo planificar-hacer-verificar-actuar (PDCA), en el que el trabajo se planifica, realiza, verifica (durante las sesiones de revisión y retrospectivas) y los cambios acordados se aplican posteriormente.

Esta metodología iterativa fomenta una mentalidad centrada en el producto, en lugar de una centrada en el proyecto. Esta distinción confiere una mayor flexibilidad durante todo el proceso de desarrollo; En los proyectos tradicionales, los requisitos suelen estar definidos y fijados de forma rígida desde el principio, lo que impide modificaciones posteriores. Por el contrario, el desarrollo iterativo de productos facilita la evolución del software en respuesta directa a los cambios en el entorno empresarial o las demandas del mercado.

Código versus documentación

En una carta publicada a IEEE Computer, Steven Rakitin expresó su escepticismo con respecto al desarrollo ágil de software, caracterizándolo como "otro intento más de socavar la disciplina de la ingeniería de software". Interpretó el principio ágil de "trabajar software sobre documentación integral" como un deseo implícito de "dedicar todo nuestro tiempo a codificar", añadiendo la afirmación: "Recuerde, los programadores reales no escriben documentación".

Los defensores del desarrollo de software ágil cuestionan esta perspectiva, afirmando que la documentación debe ser producida por los desarrolladores cuando representa el medio más eficaz para lograr objetivos específicos. Sin embargo, sostienen que a menudo existen métodos alternativos y más eficientes en comparación con la generación de documentación estática. Scott Ambler postula que la documentación debería ser "apenas lo suficientemente buena" (JBGE), argumentando que una documentación excesiva o demasiado completa normalmente conduce a la ineficiencia. Además, señala que los desarrolladores rara vez dependen de documentación detallada debido a su frecuente desincronización con el código base, mientras que una documentación insuficiente puede impedir el mantenimiento, la comunicación, el aprendizaje y la transferencia de conocimientos. Alistair Cockburn, al hablar del método Crystal Clear, afirmó:

Crystal ve el desarrollo como una secuencia de juegos cooperativos, con documentación diseñada para facilitar el éxito en etapas posteriores. Los artefactos producidos por Crystal abarcan casos de uso, registros de riesgos, planes de iteración, modelos de dominio central y fundamentos de diseño. Si bien no existen plantillas específicas para estos documentos y sus descripciones son inherentemente generales, el objetivo general es proporcionar documentación suficiente para la fase de desarrollo posterior. Este enfoque se puede conceptualizar como proporcionar la información esencial que un nuevo miembro del equipo necesitaría al unirse.

Métodos

Las metodologías ágiles de desarrollo de software abarcan un amplio espectro del ciclo de vida del desarrollo de software. Ciertos métodos enfatizan prácticas específicas, como la Programación Extrema (XP), la programación pragmática y el modelado ágil. Por el contrario, otros priorizan la gestión del flujo de trabajo, ejemplificados por Scrum y Kanban. Además, algunos métodos respaldan actividades relacionadas con la especificación y el desarrollo de requisitos, como el desarrollo basado en características (FDD), mientras que otros apuntan a cubrir todo el ciclo de vida del desarrollo, incluido el método de desarrollo de sistemas dinámicos (DSDM) y el proceso unificado racional (RUP).

Los marcos de desarrollo de software ágiles destacados incluyen:

Prácticas de desarrollo de software ágil

El desarrollo de software ágil se sustenta en una variedad de prácticas concretas que abordan dominios como la ingeniería de requisitos, el diseño, el modelado, la codificación, las pruebas, la planificación, la gestión de riesgos, la optimización de procesos y el control de calidad. Las prácticas clave de desarrollo de software ágil incluyen:

Desarrollo basado en pruebas de aceptación

Modelado ágil

Pruebas ágiles

Atrasos

Desarrollo impulsado por el comportamiento

Integración continua

Equipo multifuncional

Levantamiento diario

adaptación de métodos

En la literatura académica, varios términos denotan el concepto de adaptación de métodos, como "adaptación de métodos", "adaptación de fragmentos de métodos" e "ingeniería de métodos situacionales". La adaptación de métodos se define formalmente como:

Un proceso o capacidad en el que agentes humanos establecen un enfoque de desarrollo de sistemas para un contexto de proyecto particular mediante la implementación de modificaciones receptivas y el fomento de interacciones dinámicas entre contextos, intenciones y fragmentos de métodos.

El concepto de adecuación a la situación sirve como un diferenciador clave entre las metodologías ágiles y los enfoques de desarrollo de software más basados en planes, ya que los métodos ágiles permiten a los equipos de desarrollo de productos personalizar sus prácticas de trabajo en función de los requisitos específicos de los productos individuales. En consecuencia, la mayoría de los métodos ágiles son potencialmente susceptibles de adaptación de métodos; por ejemplo, DSDM se puede adaptar dentro de un contexto de CMM y XP se puede adaptar utilizando la técnica de Prácticas de descripción de reglas (RDP). Sin embargo, no todos los defensores del desarrollo ágil coinciden con esta perspectiva. Schwaber, por ejemplo, observó que "así es como nos metimos en problemas en primer lugar, pensando que el problema era no tener una metodología perfecta. Los esfuerzos [deberían] centrarse en los cambios [necesarios] en la empresa". Bas Vodde apoyó además esta postura, postulando que, a diferencia de las metodologías tradicionales extensas que requieren la adopción selectiva de elementos, Scrum ofrece principios fundamentales sobre los cuales se pueden construir componentes adicionales para localizar y contextualizar su aplicación. En la práctica, los métodos de desarrollo de sistemas, particularmente los ágiles, rara vez se implementan estrictamente "según las reglas"; Los profesionales frecuentemente optan por omitir o modificar ciertas prácticas para formular una metodología interna personalizada.

En la aplicación práctica, las metodologías se pueden personalizar mediante la utilización de diversas herramientas. Los lenguajes genéricos de modelado de procesos, como el Lenguaje Unificado de Modelado (UML), son aplicables para personalizar los métodos de desarrollo de software. Sin embargo, también se encuentran disponibles herramientas especializadas para la ingeniería de métodos, incluida la Teoría de la esencia de la ingeniería de software desarrollada por SEMAT.

Desarrollo distribuido, offshore y a gran escala

Tradicionalmente, el desarrollo de software ágil se ha percibido como particularmente adecuado para entornos específicos, como pequeños equipos de especialistas involucrados en proyectos totalmente nuevos. Por el contrario, las dificultades y limitaciones asociadas con la implementación de metodologías ágiles dentro de grandes organizaciones que poseen infraestructura heredada están ampliamente documentadas y comprendidas.

En consecuencia, ha surgido una variedad de estrategias y patrones para abordar las complejidades inherentes a las iniciativas de desarrollo a gran escala (que involucran a más de 20 desarrolladores) o equipos de desarrollo distribuidos (no ubicados), entre otras dificultades. Actualmente, varios marcos establecidos tienen como objetivo aliviar o sortear estos desafíos.

Persiste un debate importante sobre la eficacia de todos estos enfoques y su congruencia con la definición establecida de desarrollo ágil, lo que lo convierte en un campo dinámico y continuo de investigación académica.

Cuando el desarrollo de software ágil se implementa en un entorno distribuido, en el que participan equipos geográficamente dispersos en múltiples ubicaciones comerciales, normalmente se denomina desarrollo de software ágil distribuido. El objetivo principal es aprovechar las distintas ventajas inherentes a ambos enfoques. El desarrollo distribuido permite a las organizaciones construir software posicionando estratégicamente equipos a nivel mundial, facilitando así el desarrollo continuo de software, a menudo denominado modelo "seguir el sol". Por el contrario, el desarrollo ágil ofrece mayor transparencia, mecanismos de retroalimentación consistentes y una mayor adaptabilidad para responder a los requisitos cambiantes.

Dominios regulados

Inicialmente, las metodologías ágiles de desarrollo de software se consideraban más apropiadas para el desarrollo de productos no críticos, lo que impedía su uso en sectores altamente regulados como los de dispositivos médicos, productos farmacéuticos, finanzas, sistemas nucleares, automoción y aviónica. Sin embargo, en los últimos años hemos sido testigos de varias iniciativas destinadas a adaptar métodos ágiles para su aplicación dentro de estos dominios estrictos.

Numerosos estándares son aplicables en dominios regulados, incluidos ISO 26262, ISO 9000, ISO 9001 e ISO/IEC 15504. Dentro de estos contextos, varias preocupaciones clave tienen particular importancia:

• Aseguramiento de la calidad (QA): abarca la gestión de calidad sistemática e intrínseca, formando la base para un proceso profesional controlado y garantizando la confiabilidad y corrección del producto.
• Seguridad y protección: esto implica una planificación formal y estrategias integrales de gestión de riesgos diseñadas para mitigar los riesgos de seguridad para los usuarios y protegerlos tanto de errores no intencionados como de explotación maliciosa.
• Trazabilidad: se refiere a la documentación que proporciona evidencia auditable del cumplimiento normativo y facilita el seguimiento y la investigación de posibles problemas.
• Verificación y validación (V&V): estos procesos se integran a lo largo de todo el ciclo de vida del desarrollo de software, abarcando actividades como la especificación de requisitos del usuario, la especificación funcional, la especificación de diseño, la revisión del código, las pruebas unitarias, las pruebas de integración y las pruebas del sistema.

Experiencia y adopción

Aunque los métodos ágiles de desarrollo de software son prácticamente compatibles con cualquier paradigma o lenguaje de programación, históricamente estuvieron estrechamente asociados con entornos orientados a objetos como Smalltalk, Lisp y, posteriormente, Java y C#. Los primeros en adoptar metodologías ágiles generalmente estaban compuestos por equipos pequeños y medianos involucrados en sistemas novedosos caracterizados por requisitos que eran difíciles de finalizar y propensos a modificaciones durante todo el proceso de desarrollo. Esta sección describe los desafíos comunes que enfrentan las organizaciones durante la adopción de métodos ágiles de desarrollo de software, junto con varias técnicas para evaluar la calidad y el desempeño de los equipos ágiles.

Medición de la agilidad

Evaluaciones internas

El índice de medición de agilidad, entre otras herramientas, evalúa los proyectos de desarrollo en cinco dimensiones del desarrollo de productos: duración, riesgo, novedad, esfuerzo e interacción. Otras metodologías se basan en objetivos cuantificables y un estudio propone que la velocidad puede servir como métrica de la agilidad. Además, existen herramientas ágiles de autoevaluación para determinar el cumplimiento de un equipo con las prácticas ágiles de desarrollo de software, como la prueba de Nokia, la prueba de Karlskrona y la prueba de 42 puntos.

Encuestas públicas

Una de las primeras investigaciones que informó mejoras en la calidad, la productividad y la satisfacción empresarial mediante la aplicación de métodos ágiles de desarrollo de software fue una encuesta realizada por Shine Technologies entre noviembre de 2002 y enero de 2003.

Desde 2006 se lleva a cabo una encuesta anual comparable, el Estado de Agile, en la que participan miles de participantes de la comunidad mundial de desarrollo de software. Esta encuesta monitorea las tendencias relacionadas con las ventajas percibidas de la agilidad, las lecciones aprendidas y las prácticas efectivas. Cada iteración de la encuesta ha indicado consistentemente un número cada vez mayor de encuestados que informan que el desarrollo ágil de software facilita una entrega de software más rápida, mejora su capacidad para gestionar las prioridades cambiantes de los clientes y aumenta su productividad. Además, las encuestas han demostrado consistentemente resultados superiores con métodos ágiles de desarrollo de productos en comparación con los enfoques tradicionales de gestión de proyectos. Sin embargo, algunos informes sugieren que los métodos de desarrollo ágiles aún son demasiado incipientes para respaldar una investigación académica exhaustiva sobre su éxito general.

Errores comunes del desarrollo de software ágil

Las organizaciones y los equipos que adoptan el desarrollo de software ágil frecuentemente enfrentan desafíos al realizar la transición desde metodologías convencionales como el desarrollo en cascada, particularmente cuando se les imponen procesos ágiles. Estos problemas suelen denominarse antipatrones ágiles o, más frecuentemente, olores ágiles. A continuación se describen varios ejemplos frecuentes:

Diseño de producto integral insuficiente

Si bien el desarrollo ágil de software prioriza la entrega de software funcional sobre una documentación extensa, en contraste con los modelos en cascada altamente controlados y con mucha documentación donde las alteraciones menores del sistema requieren revisiones sustanciales, este énfasis no niega la importancia del análisis o el diseño. Desatender las consideraciones de diseño puede acelerar inicialmente el progreso de un equipo, pero a menudo conduce a una considerable reelaboración al escalar el sistema. Una característica fundamental del desarrollo ágil es su naturaleza iterativa, que, cuando se ejecuta correctamente, facilita la evolución del diseño durante el desarrollo del sistema y ayuda a los equipos a identificar puntos en común y potencial de reutilización.

Incorporación de nuevas historias en una iteración continua

Dentro del desarrollo de software ágil, las historias, que se asemejan a descripciones de casos de uso, sirven para delinear requisitos, mientras que una iteración representa un período breve y definido durante el cual un equipo se compromete a lograr objetivos particulares. La introducción de nuevas historias en una iteración activa altera la eficiencia del flujo de trabajo. En cambio, dichas historias deben agregarse al trabajo pendiente del producto y posteriormente priorizarse para una iteración futura o, en circunstancias excepcionales, la iteración actual puede finalizarse.

Este principio no excluye la expansión de una historia existente. Los equipos frecuentemente encuentran nueva información que puede generar tareas adicionales para una historia. Si esta nueva información impide la finalización de la historia dentro de la iteración actual, debe posponerse para una iteración posterior. Sin embargo, su prioridad debería reevaluarse frente a todas las demás historias destacadas, ya que los nuevos datos podrían haber alterado su importancia inicial.

Ausencia de respaldo del patrocinador

El desarrollo de software ágil con frecuencia se inicia como un esfuerzo de base por parte de los equipos de desarrollo dentro de las organizaciones, con el objetivo de optimizar los procesos y garantizar la coherencia durante todo el ciclo de vida del desarrollo de software. Sin el apoyo adecuado de los patrocinadores, estos equipos pueden encontrar desafíos y resistencia importantes por parte de las partes interesadas del negocio, otros grupos de desarrollo y la gerencia. Además, corren el riesgo de funcionar sin financiación ni recursos esenciales, lo que aumenta la probabilidad de que fracase la implementación.

Provisión de capacitación inadecuada

Una encuesta realizada por VersionOne indicó que los encuestados identificaron una capacitación insuficiente como el principal factor que contribuye a las implementaciones ágiles fallidas.

Cumplimiento inadecuado del rol de propietario de producto

El propietario del producto tiene la responsabilidad de representar los intereses comerciales dentro del proceso de desarrollo y frecuentemente asume las responsabilidades más exigentes.

Un error frecuente consiste en asignar el rol de propietario del producto a un miembro del equipo de desarrollo. Esto obliga al equipo a tomar decisiones de priorización sin comentarios comerciales auténticos. En consecuencia, pueden intentar resolver problemas comerciales internamente o experimentar retrasos mientras buscan orientación externa, lo que a menudo resulta en distracciones y un deterioro de los esfuerzos de colaboración.

Falta de enfoque en el equipo

El desarrollo de software ágil exige que los equipos cumplan los compromisos del producto, lo que requiere centrarse exclusivamente en las tareas relacionadas con ese producto específico. Sin embargo, a los miembros del equipo que se percibe que tienen un exceso de capacidad con frecuencia se les asignan responsabilidades adicionales, lo que impide su capacidad para contribuir a la finalización del trabajo comprometido de su equipo principal.

Sobrepreparación y planificación excesiva

Los equipos pueden, sin darse cuenta, dedicar demasiado tiempo a la preparación o planificación. Este error es particularmente común entre equipos con menos experiencia en el desarrollo de software ágil, quienes pueden sentirse obligados a lograr una comprensión completa y una especificación detallada de todas las historias. En lugar de ello, los equipos deben estar preparados para comenzar a trabajar en historias en las que tengan suficiente confianza, y posteriormente utilizar la iteración en curso para descubrir y preparar tareas para iteraciones futuras, un proceso a menudo denominado refinamiento o preparación del trabajo pendiente.

Resolución de problemas durante las reuniones diarias

Una reunión diaria pretende ser un foro conciso y puntual para que todos los miembros del equipo difundan información crítica. Si surgen discusiones para la resolución de problemas, estas a menudo involucran solo a miembros específicos del equipo y pueden no constituir un uso óptimo del tiempo colectivo de todo el equipo. En consecuencia, si un equipo comienza a participar en la resolución de problemas durante una reunión diaria, dichas discusiones deben posponerse hasta una reunión específica del subequipo, generalmente programada inmediatamente después de la conclusión de la reunión.

Protocolos de asignación de tareas

Una ventaja fundamental de las metodologías ágiles de desarrollo de software es la potenciación de los equipos de desarrollo para tomar decisiones autónomas, dada su proximidad a los desafíos técnicos. Además, lo ideal sería que las decisiones se tomaran lo más cerca posible del punto de implementación, aprovechando la información más actualizada disponible. En consecuencia, las asignaciones de tareas prematuras o impuestas externamente pueden disminuir las ventajas asociadas con los procesos de toma de decisiones localizados y oportunos.

La práctica de la asignación de trabajo externo puede limitar inadvertidamente a los miembros del equipo a roles especializados (por ejemplo, un individuo específico que maneja constantemente tareas relacionadas con la base de datos), restringiendo así las oportunidades de diversificación de habilidades y capacitación cruzada. Por el contrario, cuando a los miembros del equipo se les permite seleccionar tareas, pueden realizar de manera proactiva tareas que desafíen sus capacidades existentes y fomenten un valioso desarrollo multifuncional.

El papel del Scrum Master como colaborador

Dentro del marco Scrum, que pretende alinearse con valores y principios ágiles, el scrum master es el principal responsable de mantener el proceso Scrum y brindar orientación al equipo Scrum durante su ejecución. Un desafío frecuente surge cuando un scrum master asume el papel de colaborador directo. Aunque el marco de Scrum no lo prohíbe explícitamente, es imperativo que el scrum master priorice su capacidad para cumplir con sus deberes básicos de facilitación antes de emprender cualquier tarea de desarrollo. La función fundamental de un scrum master es habilitar el proceso, no producir directamente el producto.

Un scrum master que realiza múltiples tareas puede generar un número excesivo de cambios de contexto, lo que disminuye la productividad general. Además, dado que un scrum master tiene la tarea de identificar y resolver los impedimentos para el progreso del equipo, cualquier ganancia a corto plazo derivada del avance de una tarea individual puede verse anulada por el aplazamiento de la resolución de obstáculos críticos debido a una capacidad insuficiente.

Automatización de pruebas insuficiente

El paradigma iterativo inherente al desarrollo ágil con frecuencia requiere numerosos ciclos de prueba. Las pruebas automatizadas mitigan significativamente los gastos generales asociados con las pruebas unitarias, de integración y de regresión repetitivas, lo que permite a los desarrolladores y al personal de control de calidad concentrarse en actividades de mayor valor estratégico.

Además, la automatización de pruebas es fundamental para respaldar los procesos de refactorización continua integrales del desarrollo de software iterativo. Al permitir a los desarrolladores ejecutar pruebas rápidamente para validar que las operaciones de refactorización no hayan alterado inadvertidamente la funcionalidad de la aplicación, esta práctica puede reducir la carga de trabajo de desarrollo y mejorar la confianza de que los esfuerzos de optimización del código no han introducido nuevos defectos.

Acumulación de Deuda Técnica

Un enfoque exclusivo en la entrega de funcionalidades novedosas puede generar un aumento sustancial de la deuda técnica. Es imperativo que los equipos de desarrollo dediquen tiempo dedicado a la corrección de defectos y la refactorización del código. La deuda técnica impide una planificación eficaz al aumentar el volumen de trabajo no programado, ya que la resolución de defectos de producción desvía la atención del equipo del progreso de desarrollo planificado.

La refactorización continua es crucial a medida que evoluciona un sistema de software. Una ausencia sostenida de mantenimiento regular conduce inevitablemente a una escalada tanto de los defectos de software como de los gastos de desarrollo asociados con el tiempo.

Compromiso excesivo dentro de una iteración

Un error frecuente postula que el desarrollo ágil de software se adapta al cambio perpetuo; sin embargo, una acumulación de iteraciones representa fundamentalmente un consenso sobre el alcance del trabajo que se puede lograr dentro de una iteración determinada. El exceso de trabajo en progreso (WIP) genera invariablemente ineficiencias, incluidos frecuentes cambios de contexto y retrasos en las colas. En consecuencia, los equipos de desarrollo deben resistir las presiones externas para realizar trabajo adicional más allá de su capacidad acordada.

Restricciones de tiempo, recursos, alcance y calidad

Las metodologías de desarrollo de software ágiles suelen establecer parámetros fijos de tiempo (duración de la iteración) y calidad, e idealmente de recursos por adelantado (aunque la estabilidad de los recursos puede ser un desafío si los desarrolladores se desvían con frecuencia para abordar incidentes de producción), manteniendo al mismo tiempo el alcance como variable principal. Aunque los clientes o propietarios de productos a menudo abogan por un alcance fijo dentro de una iteración, los equipos de desarrollo deben tener cuidado al comprometerse con tiempo, recursos y alcance bloqueados simultáneamente, una configuración comúnmente conocida como triángulo de gestión de proyectos. Es muy probable que los intentos de ampliar el alcance manteniendo el tiempo y los recursos fijos dentro de un marco ágil comprometan la calidad del producto.

Síndrome de agotamiento del desarrollador

El ritmo intenso y las demandas operativas continuas inherentes a las prácticas ágiles elevan significativamente el riesgo de agotamiento entre los miembros del equipo de entrega de software.

La gestión ágil de proyectos constituye una metodología de desarrollo iterativa, que incorpora continuamente comentarios de los usuarios y partes interesadas para optimizar la experiencia del usuario. Varios enfoques, como Scrum, Extreme Programming, Lean y Kanban, facilitan la implementación de procesos ágiles. El concepto de gestión ágil denota un marco iterativo e incremental para supervisar las actividades de diseño y construcción en ingeniería, tecnología de la información y otros dominios comerciales. Este enfoque tiene como objetivo ofrecer nuevos productos o servicios con alta flexibilidad e interactividad, adhiriéndose a los principios articulados en el Manifiesto para el Desarrollo Ágil de Software. Las métricas ágiles de gestión de proyectos son fundamentales para mitigar la ambigüedad, identificar vulnerabilidades y evaluar la eficacia del equipo durante todo el ciclo de vida del desarrollo. Además, la agilidad de la cadena de suministro se refiere a la capacidad de una cadena de suministro para gestionar las fluctuaciones e incertidumbres tanto en la oferta como en la demanda. Una cadena de suministro ágil puede ajustar rápidamente su capacidad operativa, adaptándose así a los requisitos dinámicos de los clientes. Por último, la agilidad estratégica representa la capacidad de una organización para modificar su trayectoria operativa en respuesta a la evolución de las condiciones ambientales. Esencial para la agilidad estratégica es la identificación oportuna de cambios externos y la asignación juiciosa de recursos para facilitar la adaptación a estos contextos cambiantes.

Las técnicas Agile X a veces se denominan gestión extrema de proyectos, y representan una variación del ciclo de vida iterativo en el que los entregables del proyecto se presentan de forma incremental. Una distinción clave entre desarrollo ágil e iterativo radica en su enfoque de los entregables: las metodologías ágiles finalizan segmentos más pequeños de entregables dentro de cada iteración, mientras que los métodos iterativos desarrollan progresivamente todo el conjunto de entregables, culminando con su finalización hacia la conclusión del proyecto. Tanto el paradigma iterativo como el ágil surgieron como respuestas a los desafíos inherentes a estructuras de gestión de proyectos más secuenciales. Por ejemplo, a medida que los proyectos tecnológicos aumentan en complejidad, los usuarios finales frecuentemente encuentran dificultades para articular requisitos integrales a largo plazo sin el beneficio de revisar prototipos progresivos. Los proyectos que emplean desarrollo iterativo pueden solicitar retroalimentación continuamente, lo que facilita el refinamiento de estos requisitos.

Las técnicas ágiles X también pueden denominarse gestión de proyectos extrema. Es una variante del ciclo de vida iterativo donde los entregables se envían por etapas. La principal diferencia entre desarrollo ágil e iterativo es que los métodos ágiles completan pequeñas porciones de los entregables en cada ciclo de entrega (iteración), mientras que los métodos iterativos evolucionan todo el conjunto de entregables con el tiempo, completándolos cerca del final del proyecto. Tanto los métodos iterativos como los ágiles se desarrollaron como reacción a varios obstáculos que surgieron en formas más secuenciales de organización de proyectos. Por ejemplo, a medida que los proyectos de tecnología crecen en complejidad, los usuarios finales tienden a tener dificultades para definir los requisitos a largo plazo sin poder ver prototipos progresivos. Los proyectos que se desarrollan en iteraciones pueden recopilar comentarios constantemente para ayudar a perfeccionar esos requisitos.

La gestión ágil además proporciona un marco optimizado que fomenta una mejor comunicación y fomenta el análisis retrospectivo entre los miembros del equipo. Las organizaciones que pasan de la planificación en cascada tradicional al desarrollo ágil suelen pasar por una fase de transformación significativa, a menudo aprovechando la experiencia de los entrenadores ágiles para facilitar una transición sin problemas. El coaching ágil generalmente se manifiesta en dos estilos principales: basado en empujar y basado en tirar. Un "sistema de empuje" normalmente implica una estimación inicial de las tareas que se pueden asignar a un sprint, característica de metodologías como Scrum, donde el trabajo se "empuja" al ciclo. Por el contrario, un "sistema pull" describe un entorno operativo donde las tareas se inician sólo cuando hay suficiente capacidad disponible. También se han adoptado y personalizado metodologías de gestión ágil en diversos ámbitos empresariales y gubernamentales. Por ejemplo, dentro del gobierno federal de los Estados Unidos, la Agencia de los Estados Unidos para el Desarrollo Internacional (USAID) implementa una estrategia colaborativa de gestión de proyectos que integra principios de colaboración, aprendizaje y adaptación (CLA) para refinar y ajustar iterativamente su programación.

Se hace referencia a las metodologías ágiles en la Guía de los conocimientos sobre gestión de proyectos (Guía PMBOK, sexta edición) como parte del Ciclo de vida del desarrollo de productos. definición, indicando:

Dentro del ciclo de vida de un proyecto, generalmente hay una o más fases asociadas con el desarrollo del producto, servicio o resultado. A estos se les llama ciclo de vida de desarrollo (...) Los ciclos de vida adaptativos son ágiles, iterativos o incrementales. El alcance detallado se define y aprueba antes del inicio de una iteración. Los ciclos de vida adaptativos también se conocen como ciclos de vida ágiles o impulsados por el cambio.

Aplicaciones más allá del desarrollo de software

Jean-Loup Richet, investigador del Instituto ESSEC de Innovación y Tecnología Estratégicas. Services, afirma que "este enfoque puede aprovecharse eficazmente para productos que no son software y para la gestión de proyectos en general, especialmente en áreas de innovación e incertidumbre". En consecuencia, esta metodología produce productos o proyectos que abordan de manera óptima los requisitos de los clientes contemporáneos, entregados con costos, desperdicios y tiempo reducidos, lo que permite a las organizaciones obtener beneficios financieros más rápidamente que a través de métodos convencionales.

Los métodos de desarrollo de software ágiles se han adoptado ampliamente para el desarrollo de productos de software, y algunos incorporan características de software específicas, como tecnologías orientadas a objetos. Sin embargo, estas metodologías también son aplicables al desarrollo de productos que no son software, incluidas computadoras, dispositivos médicos, alimentos, prendas de vestir y composiciones musicales. Además, se han empleado métodos ágiles de desarrollo de software en implementaciones de infraestructura de TI y proyectos de migración que no son de desarrollo. Los principios más amplios del desarrollo ágil de software también han extendido su aplicación a dominios de gestión general, como estrategia, gobernanza, riesgo y finanzas, a menudo denominados agilidad empresarial o gestión empresarial ágil. Además, se han integrado metodologías de software ágiles en el proceso de ingeniería de aprendizaje, que es un enfoque iterativo basado en datos que utiliza un diseño centrado en el ser humano y una toma de decisiones basada en datos para facilitar el apoyo y el desarrollo del alumno.

Los paradigmas de desarrollo de software ágiles también son aplicables a otros ámbitos de la vida, incluida la crianza de los hijos. Su eficacia en el desarrollo infantil puede surgir de principios de gestión fundamentales como la comunicación, la adaptabilidad y la conciencia situacional. Por ejemplo, Bruce Feiler presentó en una charla TED su aplicación de paradigmas ágiles básicos a la gestión del hogar y la crianza de los niños.

Crítica

Las prácticas ágiles han sido identificadas como potencialmente ineficientes dentro de grandes organizaciones y contextos de desarrollo específicos. En consecuencia, numerosas organizaciones perciben las metodologías ágiles de desarrollo de software como demasiado rígidas y optan por enfoques híbridos que integran elementos de metodologías ágiles y basadas en planes. Ciertas metodologías, como el Método de Desarrollo de Sistemas Dinámicos (DSDM), se esfuerzan por lograr esta integración de manera sistemática, sin comprometer los principios básicos.

La creciente prevalencia de prácticas ágiles también ha generado críticas, caracterizándose como una tendencia de gestión que simplemente renombra las buenas prácticas establecidas con terminología novedosa, fomenta un enfoque universalista para las estrategias de desarrollo y prioriza inapropiadamente la metodología sobre los resultados tangibles.

El 12 de febrero de 2011, Alistair Cockburn orquestó una conmemoración del décimo aniversario del Manifiesto para el Desarrollo de Software Ágil en Snowbird, Utah, convocando a más de 30 personas que habían participado en la reunión inicial y los desarrollos posteriores. Se identificaron aproximadamente 20 "elefantes en la sala": temas o cuestiones ágiles que no se pueden discutir. Estos abarcaron varios aspectos, incluidas las alianzas, los fracasos y las limitaciones contextuales de las prácticas ágiles de desarrollo de software. Los posibles factores contribuyentes citados fueron los intereses comerciales, la descontextualización, la ausencia de caminos claros para el progreso después de los fracasos, la escasez de evidencia objetiva y la influencia de sesgos cognitivos y falacias de razonamiento, junto con consideraciones políticas y culturales más amplias. Philippe Kruchten observó:

El movimiento ágil es en cierto modo un poco como un adolescente: muy consciente de sí mismo, controlando constantemente su apariencia en un espejo, aceptando pocas críticas, interesado sólo en estar con sus pares, rechazando en bloque toda sabiduría del pasado, simplemente porque es del pasado, adoptando modas y nuevas jergas, a veces arrogantes y arrogantes. Pero no tengo dudas de que madurará más, se volverá más abierto al mundo exterior, más reflexivo y, por tanto, más eficaz.

El "Manifiesto" ejerció potencialmente una influencia adversa en la gestión y el liderazgo de la educación superior, al implicar a los administradores que los procesos deliberativos convencionales, a menudo más lentos, deberían ser suplantados por alternativas más "ágiles". Sin embargo, este concepto rara vez obtuvo aceptación entre los profesores universitarios.

Otra crítica postula que la gestión ágil y las prácticas de gestión tradicionales frecuentemente exhiben una oposición inherente. Una preocupación frecuente con respecto a este enfoque es el costo sustancial asociado con el tiempo requerido para el aprendizaje y la implementación, a pesar de sus ventajas potenciales. La transición de una gestión tradicional a una gestión ágil requiere un cumplimiento total de los principios ágiles y un compromiso inquebrantable por parte de todos los miembros de la organización para garantizar la finalización exitosa del proceso. Desafíos como resultados inconsistentes en toda la organización, una carga de cambio excesiva para los empleados o la ausencia de resultados garantizados después de la transformación representan ejemplos ilustrativos de estas dificultades.

• Falla rápida (negocios), un tema relacionado en la gestión empresarial
• Liderazgo ágil
• Referencias

Referencias

• Glosario ágil de Agile Alliance
• 'La nueva metodología' de Martin Fowler ofrece una descripción completa de los principios fundamentales y el contexto histórico de los métodos ágiles.