Desarrollo de software ágil

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

• Individuos e interacciones por encima de procesos y herramientas
• Software funcional con documentación completa
• Colaboración con el cliente en la negociación del contrato
• Responder al cambio en lugar de seguir un plan

Los profesionales citan la inspiración de nuevas prácticas de la época, incluyendo programación extrema , scrum , método de desarrollo de sistemas dinámicos , desarrollo de software adaptativo y la simpatía por la necesidad de una alternativa a los procesos de desarrollo de software pesados ​​e impulsados ​​por la documentación. ^[3]

Muchas prácticas de desarrollo de software surgieron de la mentalidad ágil. Estas prácticas basadas en la agilidad, a veces llamadas Agile (con A mayúscula) ^[4] incluyen requisitos, descubrimiento y mejora de soluciones a través del esfuerzo colaborativo de equipos autoorganizados y multifuncionales con sus clientes / usuarios finales . ^{[5] [6]}

Si bien hay mucha evidencia anecdótica de que la mentalidad ágil y las prácticas basadas en la agilidad mejoran el proceso de desarrollo de software, la evidencia empírica es limitada y menos que concluyente. ^{[7] [8] [9]}

Los métodos de desarrollo de software iterativos e incrementales se remontan a 1957, ^[10] y la gestión de proyectos evolutiva ^{[11] [12]} y el desarrollo de software adaptativo ^[13] surgieron a principios de la década de 1970. ^[14]

Durante la década de 1990, una serie de métodos de desarrollo de software ligeros evolucionaron en reacción a los métodos pesados ​​predominantes (a menudo denominados colectivamente cascada ) que los críticos describieron como excesivamente regulados, planificados y microgestionados . ^[15] Estos métodos ligeros incluyeron: desarrollo rápido de aplicaciones (RAD), de 1991; ^{[16] [17]} el proceso unificado (UP) y el método de desarrollo de sistemas dinámicos (DSDM), ambos de 1994; Scrum , de 1995; Crystal Clear y programación extrema (XP), ambos de 1996; y desarrollo impulsado por características (FDD), de 1997. Aunque todos ellos se originaron antes de la publicación del Manifiesto Ágil , ahora se los conoce colectivamente como métodos de desarrollo de software ágiles. ^[3]

Ya desde 1991 se habían producido cambios similares en la industria manufacturera ^{[18] [19]} y el pensamiento de gestión ^[20] se derivó de la gestión Lean .

En 2001, diecisiete desarrolladores de software se reunieron en un resort en Snowbird , Utah, para discutir métodos de desarrollo ligeros. Eran: 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 impulsado por pruebas ) y Steve Mellor ( OOA ). El grupo, The Agile Alliance, publicó el Manifiesto para el desarrollo ágil de software . ^[2]

En 2005, un grupo encabezado por Cockburn y Highsmith escribió un apéndice de principios de gestión de proyectos , la Declaración de Interdependencia de PM, ^[21] para guiar la gestión de proyectos de software de acuerdo con métodos de desarrollo de software ágiles.

En 2009, un grupo que trabajaba con Martin escribió una extensión de los principios de desarrollo de software , el Manifiesto de la Artesanía del Software , para guiar el desarrollo de software ágil de acuerdo con la conducta y el dominio profesional .

En 2011, la Agile Alliance creó la Guía de prácticas ágiles (rebautizada como Glosario ágil en 2016), ^[22] un compendio de código abierto en evolución de las definiciones de trabajo de las prácticas, términos y elementos ágiles, junto con interpretaciones y pautas de experiencia de la comunidad mundial de profesionales ágiles.

El manifiesto ágil dice: ^[2]

Estamos descubriendo mejores formas de desarrollar software al hacerlo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

• Individuos e interacciones por encima de procesos y herramientas
• Software funcional con documentación completa
• Colaboración con el cliente en la negociación del contrato
• Responder al cambio en lugar de seguir un plan

Es decir, mientras que los elementos de la derecha tienen valor, valoramos más los de la izquierda.

Scott Ambler explicó: ^[23]

• Las herramientas y los procesos son importantes, pero es más importante contar con personas competentes que trabajen juntas de manera efectiva.
• Una buena documentación es útil para ayudar a las personas a comprender cómo se construye el software y cómo usarlo, pero el objetivo principal del desarrollo es crear software, no documentación.
• Un contrato es importante, pero no sustituye el trabajo en estrecha colaboración con los clientes para descubrir lo que necesitan.
• Un plan de proyecto es importante, pero no debe ser demasiado rígido para adaptarse a los cambios en la tecnología o el entorno, las prioridades de las partes interesadas y la comprensión de las personas sobre el problema y su solución.

Al presentar el manifiesto en nombre de Agile Alliance, Jim Highsmith dijo:

El movimiento Agile no es una antítesis de la metodología; de hecho, muchos de nosotros queremos devolverle credibilidad a la palabra metodología. Queremos restablecer un equilibrio. Aceptamos el modelado, pero no para archivar algún diagrama en un polvoriento repositorio corporativo. Aceptamos la documentación, pero no cientos de páginas de tomos que nunca se mantienen y rara vez se usan. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento. Aquellos que tildan de "hackers" a los defensores de XP o SCRUM o cualquiera de las otras metodologías ágiles son ignorantes tanto de las metodologías como de la definición original del término hacker.

—  Jim Highsmith, Historia: El Manifiesto Ágil ^[24]

Los valores se basan en estos principios: ^[25]

1. Satisfacción del cliente mediante la entrega temprana y continua de software valioso.
2. Bienvenidos a cambiar los requisitos, incluso en las últimas etapas del desarrollo.
3. Entregar software funcional con frecuencia (semanas en lugar de meses).
4. Colaboración estrecha y diaria entre empresarios y desarrolladores.
5. Los proyectos se construyen alrededor de individuos motivados, en quienes se debe confiar.
6. La conversación cara a cara es la mejor forma de comunicación (co-ubicación).
7. El software que funciona es la medida principal del progreso.
8. Desarrollo sostenible, capaz de mantener un ritmo constante.
9. Atención continua a la excelencia técnica y al buen diseño.
10. La simplicidad (el arte de maximizar la cantidad de trabajo no realizado) es esencial.
11. Las mejores arquitecturas , requisitos y diseños surgen de equipos autoorganizados.
12. Periódicamente, el equipo reflexiona sobre cómo ser más eficaz y realiza los ajustes necesarios.

La mayoría de los métodos de desarrollo ágil dividen el trabajo de desarrollo de productos en pequeños incrementos que minimizan la cantidad de planificación y diseño iniciales. Las iteraciones, o sprints, son marcos de tiempo cortos ( timeboxes ) ^[26] que normalmente duran de una a cuatro semanas. ^{[27] : 20} Cada iteración implica un equipo multifuncional que trabaja en todas las funciones: planificación , análisis , diseño , codificación , pruebas unitarias y pruebas de aceptación . Al final de la iteración, se demuestra un producto funcional a las partes interesadas. Esto minimiza el riesgo general y permite que el producto se adapte a los cambios rápidamente. ^{[28] [29]} Una iteración podría no agregar suficiente funcionalidad para justificar un lanzamiento al mercado, pero el objetivo es tener una versión disponible (con errores mínimos ) al final de cada iteración. ^[30] A través del desarrollo incremental, los productos tienen espacio para " fallar a menudo y temprano " a lo largo de cada fase iterativa en lugar de drásticamente en una fecha de lanzamiento final. ^[31] Es posible que se requieran múltiples iteraciones para lanzar un producto o nuevas características. El software funcional es la medida principal del progreso. ^[25]

Una ventaja clave de los enfoques ágiles es la velocidad de comercialización y la mitigación de riesgos. Por lo general, se lanzan al mercado incrementos más pequeños, lo que reduce los riesgos de tiempo y costos de diseñar un producto que no cumple con los requisitos del usuario.

El sexto principio del manifiesto ágil para el desarrollo de software establece que "el método más eficiente y eficaz de transmitir información a un equipo de desarrollo y dentro de él es la conversación cara a cara". El manifiesto, escrito en 2001, cuando las videoconferencias no se utilizaban ampliamente, establece esto en relación con la comunicación de información, no necesariamente con que un equipo deba estar ubicado en el mismo lugar.

El principio de la co-ubicación es que los compañeros de trabajo del mismo equipo deben estar situados juntos para establecer mejor la identidad como equipo y mejorar la comunicación. ^[32] Esto permite la interacción cara a cara , idealmente frente a una pizarra, que reduce el tiempo de ciclo que normalmente se toma cuando las preguntas y respuestas se median a través del teléfono, el chat persistente , la wiki o el correo electrónico. ^[33] Con la adopción generalizada del trabajo remoto durante la pandemia de COVID-19 y los cambios en las herramientas, se han realizado más estudios ^[34] sobre la co-ubicación y el trabajo distribuido que muestran que la co-ubicación es cada vez menos relevante.

Independientemente del método de desarrollo que se siga, cada equipo debe incluir un representante del cliente (conocido como propietario del producto en Scrum ). Este representante es acordado por las partes interesadas para actuar en su nombre y se compromete personalmente a estar disponible para que los desarrolladores respondan preguntas durante toda la iteración. Al final de cada iteración, las partes interesadas del proyecto junto con el representante del cliente revisan el progreso y reevalúan las prioridades con vistas a optimizar el retorno de la inversión (ROI) y garantizar la alineación con las necesidades del cliente y los objetivos de la empresa. La importancia de la satisfacción de las partes interesadas, detallada por la interacción y revisión frecuentes al final de cada fase, es la razón por la que el enfoque a menudo se denota como una metodología centrada en el cliente . ^[35]

En el desarrollo de software ágil, un radiador de información es una pantalla física (normalmente grande), un tablero con notas adhesivas o similar, ubicado de manera destacada cerca del equipo de desarrollo, donde los transeúntes pueden verlo. ^[36] Presenta un resumen actualizado del estado de desarrollo del producto. ^{[37] [38]} También se puede utilizar un indicador de luz de compilación para informar a un equipo sobre el estado actual del desarrollo de su producto.

Una característica común en el desarrollo ágil de software es la reunión diaria (conocida como daily scrum en el marco Scrum). En una sesión breve (p. ej., 15 minutos), los miembros del equipo revisan colectivamente cómo están progresando hacia su objetivo y acuerdan si necesitan adaptar su enfoque. Para cumplir con el límite de tiempo acordado, los equipos suelen usar preguntas codificadas simples (como qué completaron el día anterior, qué pretenden completar ese día y si existen impedimentos o riesgos para el progreso) y retrasan las discusiones detalladas y la resolución de problemas hasta después de la reunión. ^[39]

A menudo se utilizan herramientas y técnicas específicas, como 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 , la refactorización de código y otras técnicas para mejorar la calidad y mejorar la agilidad del desarrollo de productos. ^[40] Esto se basa en diseñar y construir calidad desde el principio y poder demostrar el software a los clientes en cualquier momento, o al menos al final de cada iteración. ^[41]

En comparación con la ingeniería de software tradicional, el desarrollo de software ágil se centra principalmente en sistemas complejos y desarrollo de productos con propiedades dinámicas, indeterministas y no lineales . A menudo es difícil obtener estimaciones precisas, planes estables y predicciones en las primeras etapas, y es probable que la confianza en ellos sea baja. Los practicantes ágiles utilizan su libre albedrío para reducir el " salto de fe " que se necesita antes de que se pueda obtener cualquier evidencia de valor . ^[42] Se considera que los requisitos y el diseño son emergentes . Las grandes especificaciones iniciales probablemente causarían mucho desperdicio en tales casos, es decir, no son económicamente sólidas. Estos argumentos básicos y experiencias previas de la industria , aprendidas de años de éxitos y fracasos, han ayudado a dar forma a la preferencia del desarrollo ágil por el desarrollo adaptativo, iterativo y evolutivo. ^[43]

Los métodos de desarrollo se desarrollan en un continuo que va desde el adaptativo hasta el predictivo . ^[44] Los métodos de desarrollo de software ágiles se encuentran en el lado adaptativo de este continuo. Una clave de los métodos de desarrollo adaptativos es un enfoque de ola continua para la planificación del cronograma, que identifica hitos pero deja flexibilidad en el camino para alcanzarlos y también permite que los hitos mismos cambien. ^[45]

Los métodos adaptativos se centran en adaptarse rápidamente a las realidades cambiantes. Cuando cambian las necesidades de un proyecto, un equipo adaptativo también cambia. Un equipo adaptativo tiene dificultades para describir exactamente lo que sucederá en el futuro. Cuanto más lejana sea una fecha, más vago será un método adaptativo sobre lo que sucederá en esa fecha. Un equipo adaptativo no puede informar exactamente qué tareas realizará la semana que viene, sino solo qué funciones planean para el mes siguiente. Cuando se le pregunta sobre un lanzamiento dentro de seis meses, un equipo adaptativo podría informar solo la declaración de misión para el lanzamiento, o una declaración del valor esperado frente al costo.

Los métodos predictivos , por el contrario, se centran en analizar y planificar el futuro en detalle y tienen en cuenta los riesgos conocidos. En casos extremos, un equipo predictivo puede informar exactamente qué características y tareas están planificadas para todo el proceso de desarrollo. Los métodos predictivos se basan en un análisis eficaz en las primeras fases y, si esto sale muy mal, el proyecto puede tener dificultades para cambiar de dirección. Los equipos predictivos suelen instituir un comité de control de cambios para asegurarse de que solo se tienen en cuenta los cambios más valiosos.

El análisis de riesgos se puede utilizar para elegir entre métodos adaptativos ( ágiles o basados ​​en valores ) y predictivos ( basados ​​en planes ). ^[46] Barry Boehm y Richard Turner sugieren que cada lado del continuo tiene su propio terreno , de la siguiente manera: ^[47]

Una de las diferencias entre los métodos de desarrollo de software ágil y el modelo en cascada es el enfoque de la calidad y las pruebas. En el modelo en cascada , el trabajo se mueve a través de las fases del ciclo de vida del desarrollo de software (SDLC), y una fase se completa antes de que pueda comenzar otra; por lo tanto, la fase de prueba es independiente y sigue a una fase de compilación . Sin embargo, en el desarrollo de software ágil, las pruebas se completan en la misma iteración que la programación.

Dado que las pruebas se realizan en cada iteración (que desarrolla una pequeña parte del software), los usuarios pueden utilizar con frecuencia esas nuevas piezas de software y validar su valor. Una vez que los usuarios conocen el valor real de la pieza de software actualizada, pueden tomar mejores decisiones sobre el futuro del software. Tener una retrospectiva de valor y una sesión de replanificación del software en cada iteración ( Scrum normalmente tiene iteraciones de solo dos semanas) ayuda al equipo a adaptar continuamente sus planes para maximizar el valor que ofrece. Esto sigue un patrón similar al ciclo de planificar-hacer-verificar-actuar (PDCA), ya que el trabajo se planifica , se realiza , se verifica (en la revisión y la retrospectiva) y se actúa sobre los cambios acordados .

Este enfoque iterativo favorece una mentalidad de producto en lugar de una de proyecto . Esto proporciona una mayor flexibilidad durante todo el proceso de desarrollo, mientras que en los proyectos los requisitos se definen y fijan desde el principio, lo que dificulta su modificación posterior. El desarrollo iterativo de productos permite que el software evolucione en respuesta a los cambios en el entorno empresarial o los requisitos del mercado.

En una carta a IEEE Computer , Steven Rakitin expresó su cinismo sobre el desarrollo de software ágil, calificándolo de " otro intento más de socavar la disciplina de la ingeniería de software " y traduciendo " software funcional en lugar de documentación completa " como " queremos pasar todo nuestro tiempo codificando. Recuerde, los verdaderos programadores no escriben documentación ". ^[48]

Los defensores del desarrollo ágil de software cuestionan este punto y afirman que los desarrolladores deberían escribir documentación si esa es la mejor manera de alcanzar los objetivos pertinentes, pero que a menudo hay mejores maneras de lograr esos objetivos que escribir documentación estática. ^[49] Scott Ambler afirma que la documentación debería ser "apenas lo suficientemente buena" (JBGE), ^[50] que una documentación excesiva o exhaustiva normalmente causaría desperdicio y que los desarrolladores rara vez confían en la documentación detallada porque normalmente no está sincronizada con el código, ^[49] mientras que una documentación insuficiente también puede causar problemas de mantenimiento, comunicación, aprendizaje y compartición de conocimientos. Alistair Cockburn escribió sobre el método Crystal Clear :

Crystal considera el desarrollo como una serie de juegos cooperativos y pretende que la documentación sea suficiente para ayudar al siguiente a ganar en el próximo juego. Los productos de trabajo de Crystal incluyen casos de uso, lista de riesgos, plan de iteración, modelos de dominio central y notas de diseño para informar sobre las opciones... sin embargo, no hay plantillas para estos documentos y las descripciones son necesariamente vagas, pero el objetivo es claro, solo la documentación suficiente para el próximo juego. Siempre tiendo a caracterizar esto ante mi equipo como: ¿qué querrías saber si te unieras al equipo mañana?

—Alistair  Cockburn ^[51]

Los métodos de desarrollo de software ágiles respaldan una amplia gama del ciclo de vida del desarrollo de software . ^[52] Algunos métodos se centran en las prácticas (por ejemplo, XP , programación pragmática , modelado ágil), mientras que otros se centran en la gestión del flujo de trabajo (por ejemplo, Scrum, Kanban). Algunos respaldan actividades para la especificación y el desarrollo de requisitos (por ejemplo, FDD ), mientras que otros buscan cubrir el ciclo de vida completo del desarrollo (por ejemplo, DSDM , RUP ).

Los marcos de desarrollo de software ágiles notables incluyen:

El desarrollo de software ágil se apoya en una serie de prácticas concretas que abarcan áreas como requisitos, diseño, modelado, codificación, pruebas, planificación, gestión de riesgos, procesos, calidad, etc. Algunas prácticas de desarrollo de software ágil notables incluyen: ^[53]

En la literatura, se utilizan distintos términos para referirse a la noción de adaptación de métodos, entre ellos, “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 como:

Un proceso o capacidad en el que los agentes humanos determinan un enfoque de desarrollo de sistemas para una situación de proyecto específica a través de cambios receptivos e interacciones dinámicas entre contextos, intenciones y fragmentos de métodos.

—  Mehmet Nafiz Aydin et al., Un método de desarrollo de sistemas de información ágil en uso ^[70]

La adecuación a la situación debe considerarse como una característica distintiva entre los métodos ágiles y los métodos de desarrollo de software más orientados a la planificación, ya que los métodos ágiles permiten a los equipos de desarrollo de productos adaptar las prácticas de trabajo según las necesidades de los productos individuales. ^{[71] [70]} Potencialmente, la mayoría de los métodos ágiles podrían ser adecuados para la personalización de métodos, ^[52] como DSDM adaptado en un contexto CMM . ^[72] y XP adaptado con la técnica de Prácticas de Descripción de Reglas (RDP). ^[73] Sin embargo, no todos los defensores ágiles están de acuerdo, y Schwaber señala que "así es como nos metimos en problemas en primer lugar, pensando que el problema no era tener una metodología perfecta. Los esfuerzos [deberían] centrarse en los cambios [necesarios] en la empresa". ^[74] Bas Vodde reforzó este punto de vista, sugiriendo que, a diferencia de las metodologías tradicionales y grandes que requieren que elijas elementos, Scrum proporciona los conceptos básicos sobre los cuales agregas elementos adicionales para localizar y contextualizar su uso. ^[75] Los profesionales rara vez utilizan métodos de desarrollo de sistemas , o métodos ágiles específicamente, al pie de la letra, y a menudo optan por omitir o adaptar algunas de las prácticas de un método para crear un método interno. ^[76]

En la práctica, los métodos se pueden adaptar mediante diversas herramientas. Se pueden utilizar lenguajes de modelado de procesos genéricos, como el Lenguaje de Modelado Unificado, para adaptar los métodos de desarrollo de software. Sin embargo, también existen herramientas dedicadas a la ingeniería de métodos, como la Teoría de la Esencia de la Ingeniería de Software de SEMAT . ^[77]

El desarrollo de software ágil ha sido ampliamente considerado como muy adecuado para ciertos tipos de entornos, incluidos pequeños equipos de expertos que trabajan en proyectos nuevos , ^{[47] [78]} y los desafíos y limitaciones encontrados en la adopción de métodos de desarrollo de software ágil en una gran organización con infraestructura heredada están bien documentados y comprendidos. ^[79]

En respuesta, ha evolucionado una variedad de estrategias y patrones para superar los desafíos con esfuerzos de desarrollo a gran escala (>20 desarrolladores) ^{[80] [81]} o equipos de desarrollo distribuidos (no ubicados en el mismo lugar), ^{[82] [83]} entre otros desafíos; y ahora hay varios marcos reconocidos que buscan mitigar o evitar estos desafíos.

Existen muchos puntos de vista contradictorios sobre si todos estos son efectivos o si realmente se ajustan a la definición de desarrollo ágil, y esta sigue siendo un área de investigación activa y en curso. ^{[80] [84]}

Cuando el desarrollo de software ágil se aplica en un entorno distribuido (con equipos dispersos en varias ubicaciones de la empresa), se lo suele denominar desarrollo de software ágil distribuido . El objetivo es aprovechar los beneficios únicos que ofrece cada enfoque. El desarrollo distribuido permite a las organizaciones crear software mediante la creación estratégica de equipos en diferentes partes del mundo, creando software virtualmente las 24 horas del día (lo que se conoce más comúnmente como modelo "follow-the-sun"). Por otro lado, el desarrollo ágil proporciona mayor transparencia, retroalimentación continua y más flexibilidad a la hora de responder a los cambios.

Los métodos de desarrollo de software ágiles fueron vistos inicialmente como los más adecuados para desarrollos de productos no críticos, por lo que se excluyeron de su uso en dominios regulados como dispositivos médicos , farmacéuticos, financieros, sistemas nucleares, automotrices y sectores de aviónica, etc. Sin embargo, en los últimos años, ha habido varias iniciativas para la adaptación de métodos ágiles para estos dominios. ^{[85] [86] [87] [88] [89]}

Existen numerosas normas que pueden aplicarse en dominios regulados, entre ellas ISO 26262 , ISO 9000 , ISO 9001 e ISO/IEC 15504. Una serie de cuestiones clave son de particular importancia en los dominios regulados: ^[90]

• Garantía de calidad (QA): Gestión de calidad sistemática e inherente que sustenta un proceso profesional controlado y la fiabilidad y corrección del producto.
• Seguridad y protección: Planificación formal y gestión de riesgos para mitigar los riesgos de seguridad para los usuarios y protegerlos de forma segura contra usos indebidos no intencionales y maliciosos.
• Trazabilidad : Documentación que proporciona evidencia auditable del cumplimiento normativo y facilita la trazabilidad y la investigación de problemas.
• Verificación y validación (V&V): Integrada en todo el proceso de desarrollo de software (por ejemplo, especificación de requisitos del usuario, especificación funcional, especificación de diseño, revisión de código, pruebas unitarias, pruebas de integración, pruebas del sistema).

Aunque los métodos de desarrollo de software ágiles se pueden utilizar en la práctica con cualquier paradigma o lenguaje de programación, originalmente estaban estrechamente asociados con entornos orientados a objetos como Smalltalk, Lisp y más tarde Java, C#. Los primeros en adoptar los métodos ágiles eran, por lo general, equipos pequeños o medianos que trabajaban en sistemas sin precedentes con requisitos que eran difíciles de concretar y que probablemente cambiarían a medida que se desarrollaba el sistema. Esta sección describe los problemas comunes que las organizaciones encuentran cuando intentan adoptar métodos de desarrollo de software ágiles, así como varias técnicas para medir la calidad y el rendimiento de los equipos ágiles. ^[91]

El índice de medición de agilidad , entre otros, califica los desarrollos en función de cinco dimensiones del desarrollo de productos (duración, riesgo, novedad, esfuerzo e interacción). ^[92] Otras técnicas se basan en objetivos mensurables ^[93] y un estudio sugiere que la velocidad puede utilizarse como una métrica de agilidad. También existen autoevaluaciones ágiles para determinar si un equipo está utilizando prácticas de desarrollo de software ágiles (prueba de Nokia, ^[94] prueba de Karlskrona, ^[95] prueba de 42 puntos). ^[96]

Uno de los primeros estudios que informaron ganancias en calidad, productividad y satisfacción empresarial mediante el uso de métodos de desarrollo de software ágiles fue una encuesta realizada por Shine Technologies entre noviembre de 2002 y enero de 2003. ^[97]

Cada año, desde 2006, se lleva a cabo una encuesta similar, State of Agile , con miles de participantes de toda la comunidad de desarrollo de software. Esta rastrea las tendencias sobre los beneficios percibidos de la agilidad, las lecciones aprendidas y las buenas prácticas. Cada encuesta ha informado de un número cada vez mayor de personas que dicen que el desarrollo de software ágil les ayuda a entregar software más rápido; mejora su capacidad para gestionar las prioridades cambiantes de los clientes; y aumenta su productividad. ^[98] Las encuestas también han mostrado sistemáticamente mejores resultados con los métodos de desarrollo de productos ágiles en comparación con la gestión de proyectos clásica. ^{[99] [100]} En balance, hay informes de que algunos sienten que los métodos de desarrollo ágiles aún son demasiado jóvenes para permitir una investigación académica exhaustiva de su éxito. ^[101]

Las organizaciones y los equipos que implementan el desarrollo de software ágil a menudo enfrentan dificultades al realizar la transición desde métodos más tradicionales, como el desarrollo en cascada , como cuando se les impone un proceso ágil. ^[102] Estos suelen denominarse antipatrones ágiles o, más comúnmente, olores ágiles . A continuación, se presentan algunos ejemplos comunes:

Un objetivo del desarrollo ágil de software es centrarse más en producir software funcional y menos en la documentación. Esto contrasta con los modelos en cascada, en los que el proceso suele estar muy controlado y los cambios menores en el sistema requieren una revisión significativa de la documentación de apoyo. Sin embargo, esto no justifica prescindir por completo de cualquier análisis o diseño. No prestar atención al diseño puede hacer que un equipo proceda rápidamente al principio, pero que luego requiera una importante reelaboración a medida que intenta ampliar el sistema. Una de las características clave del desarrollo ágil de software es que es iterativo. Cuando se realiza correctamente, el desarrollo ágil de software permite que el diseño surja a medida que se desarrolla el sistema y ayuda al equipo a descubrir puntos en común y oportunidades de reutilización. ^[103]

En el desarrollo ágil de software, las historias (similares a las descripciones de casos de uso ) se utilizan normalmente para definir requisitos y una iteración es un período corto de tiempo durante el cual el equipo se compromete con objetivos específicos. ^[104] Añadir historias a una iteración en curso es perjudicial para un buen flujo de trabajo. Estas deben añadirse al backlog del producto y priorizarse para una iteración posterior o, en casos excepcionales, la iteración podría cancelarse. ^[105]

Esto no significa que una historia no pueda expandirse. Los equipos deben lidiar con nueva información, lo que puede generar tareas adicionales para una historia. Si la nueva información impide que la historia se complete durante la iteración, entonces debe trasladarse a una iteración posterior. Sin embargo, debe priorizarse con respecto a todas las historias restantes, ya que la nueva información puede haber cambiado la prioridad original de la historia.

El desarrollo ágil de software se implementa a menudo como un esfuerzo de base en las organizaciones por parte de equipos de desarrollo de software que intentan optimizar sus procesos de desarrollo y garantizar la coherencia en el ciclo de vida del desarrollo de software. Al no contar con el apoyo de un patrocinador, los equipos pueden enfrentar dificultades y resistencia por parte de socios comerciales, otros equipos de desarrollo y la gerencia. Además, pueden verse afectados por la falta de fondos y recursos adecuados. ^[106] Esto aumenta la probabilidad de fracaso. ^[107]

Una encuesta realizada por VersionOne encontró que los encuestados citaron la capacitación insuficiente como la causa más importante de las implementaciones ágiles fallidas ^[108]. Los equipos han caído en la trampa de asumir que los procesos reducidos de desarrollo de software ágil en comparación con otros enfoques como la cascada significan que no hay reglas reales para el desarrollo de software ágil. ^{[ cita requerida ]}

El propietario del producto es responsable de representar al negocio en la actividad de desarrollo y a menudo es el rol más exigente. ^[109]

Un error común es asignar el rol de propietario del producto a alguien del equipo de desarrollo. Esto requiere que el equipo tome sus propias decisiones sobre la priorización sin recibir comentarios reales de la empresa. Intentan resolver los problemas de la empresa internamente o retrasan el trabajo mientras buscan orientación fuera del equipo. Esto a menudo conduce a distracciones y a una ruptura de la colaboración. ^[110]

El desarrollo ágil de software requiere que los equipos cumplan con los compromisos de producto, lo que significa que deben centrarse únicamente en el trabajo para ese producto. Sin embargo, a menudo se espera que los miembros del equipo que parecen tener capacidad de sobra se encarguen de otras tareas, lo que les dificulta ayudar a completar el trabajo al que se comprometió su equipo. ^[111]

Los equipos pueden caer en la trampa de dedicar demasiado tiempo a la preparación o planificación. Esta es una trampa común para los equipos menos familiarizados con el desarrollo de software ágil, en el que los equipos se sienten obligados a tener una comprensión y especificación completa de todas las historias. Los equipos deben estar preparados para avanzar solo con aquellas historias en las que tienen confianza y, luego, durante la iteración, continuar descubriendo y preparando el trabajo para las iteraciones posteriores (lo que a menudo se conoce como refinamiento o preparación del backlog ).

Una reunión diaria debe ser una reunión puntual y centrada en la que todos los miembros del equipo difundan información. Si se resuelve un problema, a menudo puede involucrar solo a ciertos miembros del equipo y posiblemente no sea el mejor uso del tiempo de todo el equipo. Si durante la reunión diaria el equipo comienza a sumergirse en la resolución de problemas, debe dejarse de lado hasta que un subequipo pueda discutirlo, generalmente inmediatamente después de que finalice la reunión. ^[112]

Uno de los beneficios previstos del desarrollo ágil de software es permitir que el equipo tome decisiones, ya que están más cerca del problema. Además, deben tomar decisiones lo más cerca posible de la implementación, para utilizar información más oportuna en la decisión. Si a los miembros del equipo se les asignan tareas por parte de otros o demasiado temprano en el proceso, se pueden perder los beneficios de la toma de decisiones localizada y oportuna. ^[113]

La asignación de trabajo también restringe a los miembros del equipo a determinados roles (por ejemplo, el miembro del equipo A siempre debe hacer el trabajo de la base de datos), lo que limita las oportunidades de capacitación cruzada. ^[113] Los propios miembros del equipo pueden optar por asumir tareas que exijan sus capacidades y proporcionen oportunidades de capacitación cruzada.

En el marco de Scrum, que afirma ser coherente con los valores y principios ágiles, el rol del Scrum Master es responsable de garantizar que se siga el proceso Scrum y de entrenar al equipo Scrum a través de ese proceso. Un error común es que el Scrum Master actúe como colaborador. Si bien el marco de Scrum no lo prohíbe, el Scrum Master debe asegurarse de tener la capacidad de actuar en el rol de Scrum Master primero y no trabajar en tareas de desarrollo. El rol de un Scrum Master es facilitar el proceso en lugar de crear el producto. ^[114]

Si el Scrum Master también realiza varias tareas a la vez, es posible que se produzcan demasiados cambios de contexto para que el equipo sea productivo. Además, como el Scrum Master es responsable de garantizar que se eliminen los obstáculos para que el equipo pueda avanzar, el beneficio obtenido por las tareas individuales que avanzan puede no compensar los obstáculos que se posponen debido a la falta de capacidad. ^[115]

Debido a la naturaleza iterativa del desarrollo ágil, a menudo se necesitan múltiples rondas de pruebas. Las pruebas automatizadas ayudan a reducir el impacto de las pruebas unitarias, de integración y de regresión repetidas y liberan a los desarrolladores y evaluadores para que se concentren en trabajos de mayor valor. ^[116]

La automatización de pruebas también respalda la refactorización continua que requiere el desarrollo iterativo de software. Permitir que un desarrollador ejecute pruebas rápidamente para confirmar que la refactorización no ha modificado la funcionalidad de la aplicación puede reducir la carga de trabajo y aumentar la confianza de que los esfuerzos de limpieza no han introducido nuevos defectos.

Centrarse en la entrega de nuevas funcionalidades puede generar una mayor deuda técnica . El equipo debe darse tiempo para la corrección de defectos y la refactorización. La deuda técnica obstaculiza las capacidades de planificación al aumentar la cantidad de trabajo no programado, ya que los defectos de producción distraen al equipo de seguir avanzando. ^[117]

A medida que el sistema evoluciona es importante refactorizarlo . ^[118] Con el tiempo, la falta de mantenimiento constante provoca un aumento de defectos y costos de desarrollo. ^[117]

Un error muy común es pensar que el desarrollo de software ágil permite un cambio continuo, pero un backlog de iteración es un acuerdo sobre qué trabajo se puede completar durante una iteración. ^[119] Tener demasiado trabajo en progreso (WIP) genera ineficiencias como cambios de contexto y colas. ^[120] El equipo debe evitar sentirse presionado a asumir trabajo adicional. ^[121]

El desarrollo ágil de software fija el tiempo (duración de la iteración), la calidad e idealmente los recursos por adelantado (aunque mantener recursos fijos puede ser difícil si los desarrolladores a menudo se apartan de las tareas para manejar incidentes de producción), mientras que el alcance sigue siendo variable. El cliente o el propietario del producto a menudo presionan para que se fije un alcance para una iteración. Sin embargo, los equipos deben ser reacios a comprometerse con el tiempo, los recursos y el alcance bloqueados (comúnmente conocido como el triángulo de gestión de proyectos ). Los esfuerzos por agregar alcance al tiempo y los recursos fijos del desarrollo ágil de software pueden resultar en una disminución de la calidad. ^[122]

Debido al ritmo concentrado y la naturaleza continua de las prácticas ágiles, existe un mayor riesgo de agotamiento entre los miembros del equipo de entrega. ^[123]

La gestión ágil de proyectos es un proceso de desarrollo iterativo, en el que se recopilan continuamente comentarios de los usuarios y las partes interesadas para crear la experiencia de usuario adecuada. Se pueden utilizar diferentes métodos para realizar un proceso ágil, entre ellos, scrum , programación extrema , lean y kanban . ^[124] El término gestión ágil se aplica a un método iterativo e incremental de gestión de las actividades de diseño y construcción de ingeniería, tecnología de la información y otras áreas comerciales que tienen como objetivo proporcionar el desarrollo de nuevos productos o servicios de una manera altamente flexible e interactiva, basada en los principios expresados ​​​​en el Manifiesto para el desarrollo ágil de software . ^[125] Las métricas de gestión ágil de proyectos ayudan a reducir la confusión, identificar puntos débiles y medir el rendimiento del equipo a lo largo del ciclo de desarrollo. La agilidad de la cadena de suministro es la capacidad de una cadena de suministro para hacer frente a la incertidumbre y la variabilidad de la oferta y la demanda. Una cadena de suministro ágil puede aumentar y reducir su capacidad rápidamente, por lo que puede adaptarse a una demanda de los clientes que cambia rápidamente. Finalmente, la agilidad estratégica es la capacidad de una organización para cambiar su curso de acción a medida que evoluciona su entorno. La clave de la agilidad estratégica es reconocer los cambios externos con suficiente antelación y asignar recursos para adaptarse a esos entornos cambiantes. ^[124]

Las técnicas Agile X también pueden denominarse gestión extrema de proyectos . Es una variante del ciclo de vida iterativo ^[126] donde los entregables se envían en etapas. La principal diferencia entre el desarrollo ágil e iterativo es que los métodos ágiles completan pequeñas porciones de los entregables en cada ciclo de entrega (iteración), ^[127] 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 una reacción a varios obstáculos que se desarrollaron 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 constantemente retroalimentación para ayudar a refinar esos requisitos.

La gestión ágil también ofrece un marco simple que promueve la comunicación y la reflexión sobre el trabajo anterior entre los miembros del equipo . ^[128] Los equipos que utilizaban la planificación tradicional en cascada y adoptaron la forma ágil de desarrollo suelen pasar por una fase de transformación y, a menudo, reciben ayuda de entrenadores ágiles que ayudan a guiar a los equipos a través de una transformación más fluida. Normalmente, existen dos estilos de entrenamiento ágil: el basado en push y el basado en pull. En este caso, un "sistema push" puede referirse a una estimación inicial de qué tareas se pueden incluir en un sprint (trabajo push), por ejemplo, típico con scrum; mientras que un "sistema pull" puede referirse a un entorno en el que las tareas solo se realizan cuando hay capacidad disponible. ^[129] También se han empleado y adaptado enfoques de gestión ágil a los sectores empresarial y gubernamental. Por ejemplo, dentro del gobierno federal de los Estados Unidos , la Agencia de los Estados Unidos para el Desarrollo Internacional (USAID) está empleando un enfoque de gestión de proyectos colaborativos que se centra en incorporar estrategias de colaboración, aprendizaje y adaptación (CLA) para iterar y adaptar la programación. ^[130]

Los métodos ágiles se mencionan en la Guía de los Fundamentos de Dirección de Proyectos ( Guía del PMBOK, sexta edición ) en la definición del Ciclo de vida del desarrollo del producto :

Dentro del ciclo de vida de un proyecto, generalmente hay una o más fases asociadas con el desarrollo del producto, servicio o resultado. Estas se denominan 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. ^[131]

Según Jean-Loup Richet (investigador del Instituto ESSEC de Innovación y Servicios Estratégicos), "este enfoque se puede aprovechar de manera eficaz para productos no relacionados con software y para la gestión de proyectos en general, especialmente en áreas de innovación e incertidumbre". El resultado es un producto o proyecto que satisface mejor las necesidades actuales de los clientes y se entrega con un mínimo de costos, desperdicio y tiempo, lo que permite a las empresas lograr ganancias en los resultados finales antes que con los enfoques tradicionales. ^[132]

Los métodos de desarrollo de software ágiles se han utilizado ampliamente para el desarrollo de productos de software y algunos de ellos utilizan ciertas características del software, como las tecnologías de objetos . ^[133] Sin embargo, estas técnicas se pueden aplicar al desarrollo de productos que no son software, como computadoras, dispositivos médicos, alimentos, ropa y música. ^[134] Los métodos de desarrollo de software ágiles se han utilizado en implementaciones y migraciones de infraestructura de TI que no son de desarrollo . Algunos de los principios más amplios del desarrollo de software ágil también han encontrado aplicación en la gestión general ^[135] (por ejemplo, estrategia, gobernanza, riesgo, finanzas) bajo los términos de agilidad empresarial o gestión empresarial ágil. Las metodologías de software ágiles también se han adoptado para su uso con el proceso de ingeniería de aprendizaje , un proceso iterativo basado en datos que aplica las ciencias del aprendizaje , el diseño centrado en el ser humano y la toma de decisiones basada en datos para apoyar a los estudiantes y su desarrollo. ^[136]

Los paradigmas de desarrollo de software ágiles se pueden utilizar en otras áreas de la vida, como la crianza de los hijos. Su éxito en el desarrollo infantil podría basarse en algunos principios básicos de gestión: comunicación, adaptación y concienciación. En una charla TED , Bruce Feiler compartió cómo aplicó paradigmas ágiles básicos a la gestión del hogar y la crianza de los hijos. ^[137]

Las prácticas ágiles se han citado como potencialmente ineficientes en grandes organizaciones y ciertos tipos de desarrollo. ^[138] Muchas organizaciones creen que las metodologías de desarrollo de software ágiles son demasiado extremas y adoptan un enfoque híbrido ^[139] que mezcla elementos del desarrollo de software ágil y enfoques basados ​​en planes. ^[140] Algunos métodos, como el método de desarrollo de sistemas dinámicos (DSDM), intentan esto de manera disciplinada, sin sacrificar los principios fundamentales.

La creciente adopción de prácticas ágiles también ha sido criticada por ser una moda de gestión que simplemente describe las buenas prácticas existentes bajo una nueva jerga, promueve una mentalidad única para las estrategias de desarrollo y enfatiza erróneamente el método por sobre los resultados. ^[141]

Alistair Cockburn organizó una celebración del décimo aniversario del Manifiesto para el Desarrollo Ágil de Software en Snowbird, Utah, el 12 de febrero de 2011, reuniendo a más de 30 personas que habían participado en la reunión original y desde entonces. Se recopiló una lista de unos 20 temas /cuestiones ágiles "imposibles de discutir", incluidos aspectos como las alianzas, los fracasos y las limitaciones de las prácticas y el contexto del desarrollo ágil de software (posibles causas: intereses comerciales, descontextualización, falta de una forma obvia de avanzar en base a los fracasos, evidencia objetiva limitada, sesgos cognitivos y falacias de razonamiento), política y cultura. ^[142] Como escribió Philippe Kruchten :

El movimiento ágil es en algunos aspectos un poco como un adolescente: muy consciente de sí mismo, que constantemente se mira al espejo, que acepta pocas críticas, que sólo le interesa estar con sus iguales, que rechaza en bloque toda la sabiduría del pasado, sólo porque es del pasado, que adopta modas y jergas nuevas, a veces arrogante y engreído. Pero no tengo dudas de que madurará aún más, se volverá más abierto al mundo exterior, más reflexivo y, por lo tanto, más eficaz.

—Philippe  Kruchten ^[142]

El "Manifiesto" puede haber tenido un impacto negativo en la gestión y el liderazgo de la educación superior, ya que sugería a los administradores que los procesos tradicionales y deliberativos más lentos debían reemplazarse por otros más "ágiles". El concepto rara vez encontró aceptación entre el personal docente universitario. ^[143]

Otra crítica es que, en muchos sentidos, la gestión ágil y las prácticas de gestión tradicionales acaban siendo opuestas entre sí. Una crítica habitual a esta práctica es que el tiempo que se dedica a intentar aprender e implementar la práctica es demasiado costoso, a pesar de los posibles beneficios. Una transición de la gestión tradicional a la gestión ágil requiere una sumisión total a la ágil y un compromiso firme de todos los miembros de la organización para llevar a cabo el proceso. Cuestiones como la desigualdad de resultados en toda la organización, demasiados cambios para que los empleados puedan gestionarlos o la falta de garantías al final de la transformación son sólo algunos ejemplos. ^[144]

• Automatización ágil
• Equipo multifuncional
• Scrum (desarrollo de software)
• Fracasar rápidamente (en los negocios) , un tema relacionado con la gestión empresarial
• Kanban
• Liderazgo ágil
• Contratos ágiles
• Proceso unificado racional

• Manifiesto Ágil
• Glosario ágil de Agile Alliance
• La nueva metodología: descripción de Martin Fowler sobre los antecedentes de los métodos ágiles
• AgilePatterns.org