stringtranslate.com

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]

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]

Historia

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.

Valores y principios

Valores

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:

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

Scott Ambler explicó: [23]

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]

Principios

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.

Descripción general

Iterativo, incremental y evolutivo

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.

Comunicación eficiente y cara a cara

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]

Información del radiador

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.

Ciclo de retroalimentación y adaptación muy corto

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]

Enfoque en la calidad

Programación en pares , una técnica de desarrollo ágil utilizada en XP

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]

Filosofía

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]

Adaptativo vs. predictivo

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]

Agile vs. cascada

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.

Código vs. documentación

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]

Métodos

Soporte al ciclo de vida del desarrollo de software [52]
El proceso unificado ágil (AUP) se basa en un proceso unificado (un marco de proceso de desarrollo de software iterativo e incremental).

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:

Prácticas de desarrollo de software ágil

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]

Desarrollo basado en pruebas de aceptación

El desarrollo impulsado por pruebas de aceptación (ATDD) es una metodología de desarrollo basada en la comunicación entre los clientes comerciales, los desarrolladores y los evaluadores. [54] ATDD abarca muchas de las mismas prácticas que la especificación por ejemplo (SBE), [55] [56] el desarrollo impulsado por el comportamiento (BDD), [57] el desarrollo impulsado por ejemplos (EDD), [58] y el desarrollo impulsado por soporte también llamado desarrollo impulsado por pruebas de historias (SDD). [59] Todos estos procesos ayudan a los desarrolladores y evaluadores a comprender las necesidades del cliente antes de la implementación y permiten que los clientes puedan conversar en su propio lenguaje de dominio.

Modelado ágil

El modelado ágil (AM) es una metodología para modelar y documentar sistemas de software basada en las mejores prácticas. Es un conjunto de valores y principios que se pueden aplicar en un proyecto de desarrollo de software (ágil). Esta metodología es más flexible que los métodos de modelado tradicionales, lo que la hace más adecuada para un entorno que cambia rápidamente. [60] Forma parte del conjunto de herramientas de desarrollo de software ágil.

Pruebas ágiles

Las pruebas ágiles son una práctica de pruebas de software que sigue los principios del desarrollo ágil de software. Las pruebas ágiles involucran a todos los miembros de un equipo ágil multifuncional, con experiencia especial aportada por los evaluadores, para garantizar la entrega del valor comercial deseado por el cliente a intervalos frecuentes, trabajando a un ritmo sostenible. La especificación mediante ejemplos se utiliza para capturar ejemplos de comportamiento deseado y no deseado y guiar la codificación.

Atrasos

En la gestión ágil de proyectos , el product backlog se refiere a una lista priorizada de funcionalidades que debe contener un producto. A veces se lo denomina lista de tareas pendientes [ 61] y se lo considera un "artefacto" (una forma de documentación) dentro del marco de desarrollo de software Scrum . [62] El product backlog se conoce con diferentes nombres en diferentes marcos de gestión de proyectos, como product backlog en Scrum, [62] [63] lista de elementos de trabajo en Agile disciplinado [63] [ 64] y pool de opciones en Lean . [63] En el marco Scrum, la creación y el mantenimiento continuo del product backlog es parte de la responsabilidad del propietario del producto . [65]

Desarrollo impulsado por el comportamiento

El desarrollo impulsado por el comportamiento (BDD) implica nombrar las pruebas de software utilizando el lenguaje del dominio para describir el comportamiento del código .

Integración continua

La integración continua (CI) es la práctica de integrar cambios en el código fuente con frecuencia y garantizar que la base de código integrada esté en un estado funcional.

Equipo multifuncional

Un equipo multifuncional (XFN), también conocido como equipo multidisciplinario o equipo interdisciplinario, [66] [67] [68] es un grupo de personas con diferentes conocimientos funcionales que trabajan para alcanzar un objetivo común. [69] Puede incluir personas de los departamentos de finanzas , marketing , operaciones y recursos humanos . Por lo general, incluye empleados de todos los niveles de una organización. Los miembros también pueden provenir de fuera de una organización (en particular, de proveedores, clientes clave o consultores).

Stand-up diario

Una reunión de pie (stum) es una reunión en la que los asistentes suelen participar de pie . La incomodidad de estar de pie durante períodos prolongados tiene como objetivo que las reuniones sean breves.

Adaptación de métodos

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]

A gran escala, offshore y distribuido

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.

Dominios regulados

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]

Experiencia y adopción

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]

Medición de la agilidad

Evaluaciones internas

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]

Encuestas públicas

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]

Errores comunes en el desarrollo de software ágil

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:

Falta de diseño general del producto

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]

Agregar historias a una iteración en progreso

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.

Falta de apoyo de patrocinadores

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]

Formación insuficiente

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 rol de propietario del producto no está completado correctamente

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]

Los equipos no están concentrados

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]

Preparación/planificación excesiva

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 ).

Resolución de problemas en la reunión diaria

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]

Asignación de tareas

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.

Scrum master como colaborador

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]

Falta de automatización de pruebas

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.

Permitir que se acumule la deuda técnica

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]

Intentar abarcar demasiado en una iteración

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]

Tiempo, recursos, alcance y calidad fijos.

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]

Agotamiento del desarrollador

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]

Gestión ágil

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]

Aplicaciones fuera del desarrollo de software

Conferencia Agile Brasil 2014

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]

Crítica

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]

Véase también

Referencias

  1. ^ "¿Qué es Agile?". Agile Alliance . Consultado el 16 de julio de 2024 .
  2. ^ abc Kent Beck ; James Grenning; Robert C. Martin ; Mike Beedle; Jim Highsmith ; Steve Mellor ; Arie van Bennekum; Andrew Hunt ; Ken Schwaber ; Alistair Cockburn ; Ron Jeffries ; Jeff Sutherland ; Ward Cunningham ; Jon Kern; Dave Thomas ; Martin Fowler ; Brian Marick (2001). "Manifiesto para el desarrollo ágil de software". Agile Alliance . Consultado el 14 de junio de 2010 .
  3. ^ ab Larman, Craig (2004). Desarrollo ágil e iterativo: una guía para gerentes . Addison-Wesley. pág. 27. ISBN 978-0-13-111155-4.
  4. ^ Rally (2010). «Agile con «A» mayúscula frente a agile con «a» minúscula». Archivado desde el original el 5 de enero de 2016 . Consultado el 9 de septiembre de 2015 .{{cite web}}: CS1 maint: unfit URL (link)
  5. ^ Collier 2011.
  6. ^ "¿Qué es el desarrollo de software ágil?". Agile Alliance. 8 de junio de 2013. Consultado el 4 de abril de 2015 .
  7. ^ Dybå, Tore; Dingsøyr, Torgeir (1 de agosto de 2008). "Estudios empíricos del desarrollo ágil de software: una revisión sistemática". Tecnología de la información y el software . 50 (9–10): 833–859. doi :10.1016/j.infsof.2008.01.006. ISSN  0950-5849. S2CID  2244031.
  8. ^ Lee, Gwanhoo; Xia, Weidong (2010). "Hacia Agile: Un análisis integrado de datos de campo cuantitativos y cualitativos sobre la agilidad en el desarrollo de software". MIS Quarterly . 34 (1): 87–114. doi :10.2307/20721416. JSTOR  20721416. S2CID  26477249.
  9. ^ Kroll, J.; Richardson, I.; Prikladnicki, R.; Audy, JL (2018). "Evidencia empírica en el desarrollo de software de seguimiento solar: un estudio de mapeo sistemático". Tecnología de la información y el software . 93 : 30–44. doi :10.1016/j.infsof.2017.08.011. hdl : 10344/6233 .
  10. ^ Gerald M. Weinberg , citado en Larman & Basili 2003, pp. 47–56 "Estábamos haciendo desarrollo incremental ya en 1957 en Los Ángeles, bajo la dirección de Bernie Dimsdale en Service Bureau Corporation de IBM . Era colega de John von Neumann , así que quizás lo aprendió allí, o lo asumió como algo totalmente natural. Recuerdo a Herb Jacobs (principalmente, aunque todos participamos) desarrollando una gran simulación para Motorola, donde la técnica utilizada fue, hasta donde puedo decir... Todos nosotros, hasta donde puedo recordar, pensábamos que la cascada de un gran proyecto era bastante estúpida, o al menos ignorante de las realidades. Creo que lo que la descripción en cascada hizo por nosotros fue hacernos darnos cuenta de que estábamos haciendo otra cosa, algo sin nombre excepto 'desarrollo de software'".
  11. ^ "Gestión evolutiva de proyectos (página original, archivo externo)". Gilb. Archivado desde el original el 27 de marzo de 2016. Consultado el 30 de abril de 2017 .
  12. ^ "Gestión evolutiva de proyectos (Nueva página)". Gilb . Consultado el 30 de abril de 2017 .
  13. ^ Edmonds, EA (1974). "Un proceso para el desarrollo de software para usuarios no técnicos como un sistema adaptativo". General Systems . 19 : 215–18.
  14. ^ Gilb, Tom (1 de abril de 1981). "Desarrollo evolutivo". Notas de ingeniería de software de ACM SIGSOFT . 6 (2): 17. doi :10.1145/1010865.1010868. S2CID  33902347.
  15. ^ Swamidass, PM, ed. (2000), "Organización de proyectos de peso pesadoORGANIZACIÓN DE PROYECTOS DE PESO PESADO", Enciclopedia de gestión de producción y fabricación , Boston, MA: Springer US, págs. 261-262, doi :10.1007/1-4020-0612-8_400, ISBN 978-1-4020-0612-8, consultado el 22 de junio de 2022
  16. ^ Martin, James (1991). Desarrollo rápido de aplicaciones. Macmillan. ISBN 978-0-02-376775-3.
  17. ^ Kerr, James M.; Hunter, Richard (1993). Inside RAD: Cómo construir un sistema completamente funcional en 90 días o menos . McGraw-Hill. pág. 3. ISBN 978-0-07-034223-1.
  18. ^ Instituto Iacocca (1991). "Estrategia de empresa manufacturera del siglo XXI: una visión impulsada por la industria". Instituto Iacocca, Universidad de Lehigh, Bethlehem, PA.
  19. ^ Presley, A., J. Mills y D. Liles (1995). "Fabricación aeroespacial ágil". Nepcon East 1995, Boston.
  20. ^ Sanchez, Luis (noviembre 2010). "Una revisión de los sistemas de manufactura ágil". Revista Internacional de Investigación en Producción (39(16):3561-3600).
  21. ^ Anderson, David (2005). «Declaración de interdependencia». Archivado desde el original el 27 de enero de 2018. Consultado el 4 de octubre de 2018 .
  22. ^ McDonald, Kent (1 de noviembre de 2016). "Cómo puede ayudar a Agile Alliance a ayudarlo". Blog de Agile Alliance . Consultado el 4 de julio de 2017 .
  23. ^ "Examinando el Manifiesto Ágil". Ambysoft Inc. Recuperado el 6 de abril de 2011 .
  24. ^ Jim Highsmith (2001). "Historia: El Manifiesto Ágil". agilemanifesto.org.
  25. ^ ab Kent Beck ; James Grenning; Robert C. Martin ; Mike Beedle; Jim Highsmith ; Steve Mellor ; Arie van Bennekum; Andrew Hunt ; Ken Schwaber ; Alistair Cockburn ; Ron Jeffries ; Jeff Sutherland ; Ward Cunningham ; Jon Kern; Dave Thomas ; Martin Fowler ; Brian Marick (2001). "Principios detrás del Manifiesto Ágil". Agile Alliance. Archivado desde el original el 14 de junio de 2010 . Consultado el 6 de junio de 2010 .
  26. ^ Project Management Institute 2021, 2.3.3 Enfoques de desarrollo.
  27. ^ Rubín 2013.
  28. ^ Project Management Institute 2021, §3.12 Permitir el cambio para lograr el estado futuro previsto.
  29. ^ Moran, A. (2014). Gestión ágil de riesgos . Springer Verlag. ISBN 978-3319050072.
  30. ^ Beck, Kent (1999). "Aceptando el cambio con programación extrema". Computer . 32 (10): 70–77. doi :10.1109/2.796139.
  31. ^ Mergel, Ines (julio de 2016). "Gestión ágil de la innovación en el gobierno: una agenda de investigación". Government Information Quarterly . 33 (3): 516–523. doi :10.1016/j.giq.2016.07.004.
  32. ^ Preuss, Deborah Hartmann (13 de octubre de 2006). «Estudio: equipos ubicados en el mismo lugar que la granja de cubículos». InfoQ . Consultado el 23 de octubre de 2018 .
  33. ^ Cockburn, Alistair (2007). "Desarrollo ágil de software: el juego cooperativo". www.pearson.com (2.ª ed.). Addison-Wesley Professional . Consultado el 23 de octubre de 2018 .
  34. ^ "Gestión transformada | Investigación".
  35. ^ Jain, Parita; Sharma, Arun; Ahuja, Laxmi (agosto de 2018). "El impacto del proceso de desarrollo de software ágil en la calidad del producto de software". 2018 7.ª Conferencia internacional sobre confiabilidad, tecnologías de la información y la comunicación y optimización (tendencias y direcciones futuras) (ICRITO) . Noida, India: IEEE. págs. 812–815. doi :10.1109/ICRITO.2018.8748529. ISBN . 978-1-5386-4692-2.S2CID 195775457  .
  36. ^ Project Management Institute 2021, §2.7.3.2 Radiadores de información.
  37. ^ Cockburn, Alistair (19 de junio de 2008). "Radiador de información".
  38. ^ Ambler, Scott (12 de abril de 2002). Modelado ágil: prácticas efectivas para programación extrema y el proceso unificado . John Wiley & Sons. págs. 12, 164, 363. ISBN 978-0-471-20282-0.
  39. ^ Vasiliauskas, Vidas (2014). "Desarrollo de prácticas ágiles de gestión de tareas y equipos de proyectos". Eylean. Archivado desde el original el 15 de septiembre de 2014. Consultado el 15 de septiembre de 2014 .
  40. ^ Jeffries, Ron; Anderson, Ann; Hendrickson, Chet (2001). Extreme Programming installed. Addison-Wesley. págs. 72-147. ISBN 978-0201-70842-4.
  41. ^ Lisa Crispin; Janet Gregory (2009). Pruebas ágiles: una guía práctica para evaluadores y equipos ágiles . Addison-Wesley.
  42. ^ Mitchell, Ian (2016). Desarrollo ágil en la práctica . Tamare House. pág. 11. ISBN 978-1-908552-49-5.
  43. ^ Larman, Craig (2004). Desarrollo ágil e iterativo: una guía para gerentes . Addison-Wesley. pág. 27. ISBN 978-0-13-111155-4.
  44. ^ Boehm, B .; R. Turner (2004). Equilibrar la agilidad y la disciplina: una guía para los perplejos . Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.Apéndice A, páginas 165–194
  45. ^ Larman, Craig (2004). "Capítulo 11: Consejos prácticos". Desarrollo ágil e iterativo: guía para gerentes . Addison-Wesley Professional. pág. 253. ISBN 9780131111554. Recuperado el 14 de octubre de 2013 .
  46. ^ Sliger, Michele; Broderick, Stacia (2008). El puente del gerente de proyectos de software hacia la agilidad . Addison-Wesley. pág. 46. ISBN 978-0-321-50275-9.
  47. ^ ab Boehm, B. ; R. Turner (2004). Equilibrar la agilidad y la disciplina: una guía para los perplejos . Boston, MA: Addison-Wesley. págs. 55–57. ISBN 978-0-321-18612-6.
  48. ^ Rakitin, Steven R. (2001). "Manifiesto provoca cinismo: Carta de un lector al editor por Steven R. Rakitin". IEEE Computer . 34 (12): 4. doi :10.1109/MC.2001.10095. S2CID  221106984. El artículo titulado 'Desarrollo ágil de software: el negocio de la innovación' ... es otro intento más de socavar la disciplina de la ingeniería de software ... Queremos pasar todo nuestro tiempo codificando. Recuerde, los verdaderos programadores no escriben documentación.
  49. ^ por Scott Ambler (16 de abril de 2023). "Documentación ágil/lean: estrategias para el desarrollo ágil de software".
  50. ^ Scott Ambler. "Modelos y documentos apenas lo suficientemente buenos: una práctica recomendada de Agile". Archivado desde el original el 8 de octubre de 2014. Consultado el 24 de enero de 2014 .
  51. ^ Geoffrey Wiseman (18 de julio de 2007). "¿Los métodos ágiles requieren documentación?". InfoQ.citando a Cooper, Ian (6 de julio de 2007). "Señales Staccato: Agile y documentación". WordPress.com .
  52. ^ abc Abrahamson P, Salo O, Ronkainen J, Warsta J (2002). Métodos ágiles de desarrollo de software: Revisión y análisis (PDF) (Informe técnico). VTT . 478.
  53. ^ "Guía de prácticas ágiles". Agile Alliance. Archivado desde el original el 9 de febrero de 2014.
  54. ^ Pugh, Ken (2011). Desarrollo basado en pruebas de aceptación ágil y esbelta: mejor software mediante la colaboración . Addison-Wesley. ISBN 978-0321714084.
  55. ^ Adzic, Gojko. (2009) Cerrando la brecha de comunicación: especificación mediante ejemplos y pruebas de aceptación ágiles , Neuri Limited,
  56. ^ Adzic, Gojko (2011). Especificación mediante el ejemplo: cómo los equipos exitosos entregan el software adecuado . Manning. ISBN 978-0-321-27865-4.
  57. ^ Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp y Dan North. El libro de RSpec: desarrollo impulsado por la conducta con RSpec, Cucumber y amigos. The Pragmatic Bookshelf.
  58. ^ "Example Driven Design" (Diseño basado en ejemplos) . Consultado el 15 de abril de 2013 .
  59. ^ "Desarrollo basado en pruebas de historias" (PDF) . Consultado el 15 de abril de 2013 .
  60. ^ Página de inicio de modelado ágil (AM), prácticas efectivas para modelado y documentación
  61. ^ Atlassian. "El product backlog: su lista definitiva de tareas pendientes". Atlassian . Consultado el 19 de diciembre de 2021 .
  62. ^ ab "¿Qué es un Product Backlog?". Scrum.org . Consultado el 19 de diciembre de 2021 .
  63. ^ abc "Agile Core Practice: Prioritized Requirements" (Práctica básica ágil: requisitos priorizados). agilemodeling.com . Consultado el 19 de diciembre de 2021 .
  64. ^ "Artefacto: Listado de elementos de trabajo". www.utm.mx . Consultado el 19 de diciembre de 2021 .
  65. ^ "Produkteier | Digitaliseringsdirektoratet" . Consultado el 15 de noviembre de 2021 .
  66. ^ ¿Qué es un equipo multifuncional? Definición y significado
  67. ^ Uso de XFN como abreviatura
  68. ^ Un blog de liderazgo llamado XFN.
  69. ^ Krajewski, LJ y LP Ritzman. 2005. Gestión de operaciones: procesos y cadenas de valor. Pearson Education, Upper Saddle River.
  70. ^ ab Aydin, MN; Harmsen, F.; Slooten; Stagwee, RA (2004). "Un método de desarrollo de sistemas de información ágil en uso". Turk J Elec Engin . 12 (2): 127–138.
  71. ^ Morris, David (2015). La paradoja de la transformación ágil: por qué esforzarse demasiado para ser ágil impide que las organizaciones se vuelvan verdaderamente ágiles . NZ: Universidad de Auckland. doi :10.13140/RG.2.2.32698.08640.
  72. ^ Abrahamsson, P., Warsta, J., Siponen, MT y Ronkainen, J. (2003). Nuevas direcciones en métodos ágiles: un análisis comparativo. Actas de ICSE'03 , 244-254
  73. ^ Mirakhorli, M.; Rad, AK; Shams, F.; Pazoki, M.; Mirakhorli, A. (2008). "Técnica RDP: una práctica para personalizar XP". Actas del taller internacional de 2008 sobre el análisis de las prácticas ágiles o tiroteo en el corral ágil (APOS '08) . ACM. págs. 23–32. doi :10.1145/1370143.1370149. ISBN . 978-1-60558-021-0.S2CID 9528636  .
  74. ^ Schwaber, K (2006) Scrum es difícil y disruptivo.
  75. ^ Vodde, B (2016) La historia de LeSS. Discurso de clausura. Scrum Australia, Melbourne. Abril de 2016.
  76. ^ Lagstedt, A. y Dahlberg, T. (2018). Entendiendo la rareza de la selección de métodos ISD – Racionalidad limitada y estupidez funcional. Actas de PACIS 2018. 154. https://aisel.aisnet.org/pacis2018/154.
  77. ^ Park, JS, McMahon, PE y Myburgh, B. (2016). Scrum impulsado por Essence. Notas de ingeniería de software de ACM SIGSOFT, 41(1), págs. 1–8.
  78. ^ Beck, K. (1999). Explicación de la programación extrema: acepte el cambio . Boston, MA: Addison-Wesley. ISBN 978-0-321-27865-4.
  79. ^ Evans, Ian. "Agile Delivery at British Telecom" (Entrega ágil en British Telecom) . Consultado el 21 de febrero de 2011 .
  80. ^ ab W. Scott Ambler (2006) Supersize Me en el diario del Dr. Dobb, 15 de febrero de 2006.
  81. ^ Schaaf, RJ (2007). Conferencia sobre sistemas y tecnología de software Agility XL 2007 Archivado el 13 de marzo de 2016 en Wayback Machine , Tampa, FL
  82. ^ "Bridging the Distance" (Cerrando la distancia). Sdmagazine.com . Consultado el 1 de febrero de 2011 .
  83. ^ Fowler, Martin. "Uso de un proceso de software ágil con desarrollo offshore". Martinfowler.com . Consultado el 6 de junio de 2010 .
  84. ^ Taller de procesos ágiles II: gestión de múltiples proyectos ágiles simultáneos. Washington: OOPSLA 2002
  85. ^ Cawley, Oisín; Wang, Xiaofeng; Richardson, Ita (2010). "Metodologías de desarrollo de software ágil/esbelto en entornos regulados: estado del arte". En Abrahamsson, Pekka; Oza, Nilay (eds.). Software y sistemas empresariales esbeltos . Apuntes de clase sobre procesamiento de información empresarial. Vol. 65. págs. 31–36. doi :10.1007/978-3-642-16416-3_4. hdl :10344/683. ISBN 978-3-642-16415-6.
  86. ^ McHugh, Martin; McCaffery, Fergal; Coady, Garret (4 de noviembre de 2014). "Una implementación ágil dentro de una organización de software de dispositivos médicos". En Mitasiunas, Antanas; Rout, Terry; O'Connor, Rory V.; et al. (eds.). Mejora de procesos de software y determinación de capacidad. Comunicaciones en informática y ciencias de la información. Vol. 477. págs. 190–201. doi :10.1007/978-3-319-13036-1_17. ISBN 978-3-319-13035-4.
  87. ^ Wang, Yang; Ramadani, Jasmin; Wagner, Stefan (29 de noviembre de 2017). "Un estudio exploratorio sobre la aplicación de un proceso de desarrollo Scrum para sistemas críticos para la seguridad". Mejora de procesos de software centrados en el producto . Lecture Notes in Computer Science. Vol. 10611. págs. 324–340. arXiv : 1703.05375 . Bibcode :2017arXiv170305375W. doi :10.1007/978-3-319-69926-4_23. ISBN : 9783319699257.S2CID 4585465  .
  88. ^ "SafeScrum-SINTEF". Sintef.no . Consultado el 26 de marzo de 2019 .
  89. ^ Thor Myklebust, Tor Stålhane, Geir Kjetil Hanssen, Tormod Wien y Børge Haugset: Scrum, documentación y el estándar de software IEC 61508-3:2010, http://www.sintef.no/globalassets/ec-61508-documentation-and -safescrum-psam12.pdf
  90. ^ Fitzgerald, B.; Stol, K.-J.; O'Sullivan, R.; O'Brien, D. (mayo de 2013). "Escalado de métodos ágiles a entornos regulados: un estudio de caso de la industria". 2013 35th International Conference on Software Engineering (ICSE) . págs. 863–872. doi :10.1109/ICSE.2013.6606635. hdl :10344/3055. ISBN 978-1-4673-3076-3.S2CID 192403  .
  91. ^ Beck, Kent (2000). Explicación de la programación extrema. Addison-Wesley. págs. 1–24. ISBN 978-0201616415.
  92. ^ Datta, Subhajit (2006). "Índice de medición de agilidad: una métrica para la intersección de las metodologías de desarrollo de software". ACM-SE 44 Actas de la 44.ª conferencia regional anual del sudeste . pág. 271. doi :10.1145/1185448.1185509. ISBN 1595933158.
  93. ^ Peter Lappo; Henry CT Andrew. "Evaluación de la agilidad" (PDF) . Archivado desde el original (PDF) el 15 de septiembre de 2009. Consultado el 6 de junio de 2010 .
  94. ^ Joe Little (2 de diciembre de 2007). "Nokia test, A scrum-specific test". Agileconsortium.blogspot.com . Consultado el 6 de junio de 2010 .
  95. ^ Mark Seuffert; Mayberg, Suecia. "Karlskrona test, A generic agile adoption test". Mayberg.se . Consultado el 5 de abril de 2014 .
  96. ^ "¿Qué tan ágil eres? (Haz esta prueba de 42 puntos)". allaboutagile.com/. Archivado desde el original el 5 de mayo de 2014. Consultado el 3 de abril de 2014 .
  97. ^ "Resultados de la encuesta sobre metodologías ágiles" (PDF) . Shine Technologies. Enero de 2003. Archivado desde el original (PDF) el 21 de agosto de 2010 . Consultado el 3 de junio de 2010 . El 95 % afirmó que no hubo efecto o que hubo una reducción de costos ... El 93 % afirmó que la productividad fue mejor o significativamente mejor ... El 88 % afirmó que la calidad fue mejor o significativamente mejor ... El 83 % afirmó que la satisfacción empresarial fue mejor o significativamente mejor
  98. ^ "Informe sobre el estado de Agile en 2013: ¿Por qué Agile?". stateofagile.com. 27 de enero de 2014. Archivado desde el original el 28 de agosto de 2014. Consultado el 13 de agosto de 2014 .
  99. ^ Status Quo Agile, Segundo estudio sobre el éxito y las formas de uso de los métodos ágiles. Consultado el 1 de julio de 2015
  100. ^ Ambler, Scott (3 de agosto de 2006). "La encuesta dice: Agile funciona en la práctica". Dr. Dobb's . Consultado el 3 de junio de 2010 . Solo el 6% indicó que su productividad se redujo ... El 34% de los encuestados no informó cambios en la productividad y el 60% informó un aumento de la productividad ... El 66% [respondió] que la calidad es mayor ... El 58% de las organizaciones informa una mejora en la satisfacción, mientras que solo el 3% informa una reducción de la satisfacción.
  101. ^ "Respondiendo a la pregunta "¿Dónde está la prueba de que los métodos ágiles funcionan?"". Agilemodeling.com. 19 de enero de 2007. Consultado el 2 de abril de 2010 .
  102. ^ Shore & Warden 2008, pág. 47
  103. ^ Beck, Kent (2000). Explicación de la programación extrema. Addison-Wesley. págs. 48-49. ISBN 978-0201616415.
  104. ^ Rouse, Margaret. "Definición de sprint (desarrollo de software)". searchsoftwarequality.techtarget.com . Consultado el 2 de octubre de 2015 .
  105. ^ Goldstein, Ilan (11 de octubre de 2011). "Problemas de sprint: cuando los sprints se convierten en travesías". www.axisagile.com.au . Consultado el 8 de junio de 2014 .
  106. ^ "Roles del proyecto y distribución de responsabilidades". agile-only.com . Consultado el 15 de junio de 2014 .
  107. ^ Bourne, Lynda. "¿Qué hace realmente un patrocinador de proyectos?". blogs.pmi.org . Archivado desde el original el 7 de junio de 2014. Consultado el 8 de junio de 2014 .
  108. ^ "9th State of Agile Report". Encuesta sobre el estado de Agile . VersionOne. Archivado desde el original el 12 de enero de 2015. Consultado el 8 de junio de 2014 .
  109. ^ Sims, Chris; Johnson, Hillary Louise (15 de febrero de 2011). Los elementos de Scrum (edición Kindle). Dymaxicon. pág. 73.
  110. ^ Rothman, Johanna Rothman (25 de agosto de 2011). "Cuando no tienes ningún Product Owner". www.jrothman.com . Consultado el 8 de junio de 2014 .
  111. ^ Fox, Alyssa (8 de abril de 2014). "Working on Multiple Agile Teams" (Trabajar en varios equipos ágiles). techwhirl.com/ . Consultado el 14 de junio de 2014 .
  112. ^ "Reunión diaria de Scrum". www.mountaingoatsoftware.com . Consultado el 14 de junio de 2014 .
  113. ^ ab May, Robert. "Planificación eficaz del sprint". www.agileexecutives.org . Archivado desde el original el 28 de junio de 2014. Consultado el 14 de junio de 2014 .
  114. ^ Berczuk, Steve. "Misión posible: ScrumMaster y colaborador técnico". www.agileconnection.com . Consultado el 14 de junio de 2014 .
  115. ^ "Cómo implementar Agile Scrum" . Consultado el 4 de enero de 2022 .
  116. ^ Namta, Rajneesh. "Reflexiones sobre la automatización de pruebas en Agile". www.infoq.com . Consultado el 14 de junio de 2014 .
  117. ^ ab Band, Zvi (22 de marzo de 2014). «Deuda técnica + Octubre rojo» . Consultado el 8 de junio de 2014 .
  118. ^ Shore, James. "El arte del desarrollo ágil: refactorización". www.jamesshore.com . Consultado el 14 de junio de 2014 .
  119. ^ "Paso 4: Planificación del sprint (tareas)". www.allaboutagile.com . Archivado desde el original el 29 de junio de 2014 . Consultado el 14 de junio de 2014 .
  120. ^ George, Claire (3 de marzo de 2014). "Por qué es importante limitar el trabajo en curso". leankit.com . Consultado el 14 de junio de 2014 .
  121. ^ "Reunión de planificación del sprint". www.mountaingoatsoftware.com . Consultado el 14 de junio de 2014 .
  122. ^ McMillan, Keith (13 de mayo de 2010). "Tiempo, recursos, alcance... y calidad". www.adeptechllc.com . Consultado el 15 de junio de 2014 .
  123. ^ "Estudio actual sobre las limitaciones de Agile". Procedia Computer Science . 78 : 291–297. Enero de 2016. doi : 10.1016/j.procs.2016.02.056 .
  124. ^ ab "El llamado a la agilidad en las compras: ¿qué significa?". 1 de noviembre de 2019.
  125. ^ Moran, Alan (2015). Gestión ágil: estrategia, implementación, organización y personas . Springer. ISBN 978-3-319-16262-1.
  126. ^ "¿Cuál es el mejor ciclo de vida para su proyecto?". PMHut . 22 de octubre de 2008. Consultado el 23 de octubre de 2009 .
  127. ^ "Gestión ágil de proyectos". VersionOne . Consultado el 1 de junio de 2015 .
  128. ^ "¿Qué es la gestión ágil?". Project Laneways . Consultado el 1 de junio de 2015 .
  129. ^ Benson, Jim; De Maria Barry, Tonianne (2011). Kanban personal: mapear el trabajo, navegar por la vida (1.ª ed.). Seattle, WA: Modus Cooperandi Press. p. 38. ISBN 978-1-4538-0226-7.
  130. ^ USAID. "Política operativa del ciclo del programa del capítulo 201 de ADS" Archivado el 23 de octubre de 2019 en Wayback Machine . Consultado el 19 de abril de 2017.
  131. ^ Project Management Institute , Guía de los Fundamentos de Dirección de Proyectos (Guía del PMBOK), sexta edición
  132. ^ Richet, Jean-Loup (2013). Innovación ágil . Casos e Investigación Aplicada, n°31. ESSEC-ISIS. ISBN 978-2-36456-091-8 
  133. ^ Smith, Preston G (2007). Desarrollo de productos flexibles . Jossey-Bass. pág. 25. ISBN 978-0-7879-9584-3.
  134. ^ Newton Lee (2014). "Entrar en las listas de Billboard: producción musical como desarrollo de software ágil", Digital Da Vinci: Computers in Music. Springer Science+Business Media. ISBN 978-1-4939-0535-5.
  135. ^ Moran, Alan (2015). Gestión ágil: estrategia, implementación, organización y personal . Springer Verlag. ISBN 978-3-319-16262-1.
  136. ^ Barrett, M.; Goodell, J. (2022), "Herramientas de desarrollo ágil y esbelto", Learning Engineering Toolkit , Routledge, págs. 269-278, doi :10.4324/9781003276579-16, ISBN 978-1-003-27657-9
  137. ^ "Programación ágil – para tu familia".
  138. ^ Larman, Craig; Bas Vodde (13 de agosto de 2009). Los diez principales impedimentos organizacionales para la adopción de metodologías ágiles a gran escala. InformIT.
  139. ^ "Introducción a la gestión de proyectos híbridos". 20 de julio de 2016.
  140. ^ Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). "Descripción general y orientación sobre el desarrollo ágil en grandes organizaciones". Comunicaciones de la Asociación de Sistemas de Información . 29 (1): 25–44. doi : 10.17705/1CAIS.02902 .
  141. ^ Kupersmith, Kupe (4 de julio de 2011). "Agile es una moda pasajera".
  142. ^ ab Kruchten, Philippe (20 de junio de 2011). "¿La crisis adolescente de Agile?". InformaciónQ.
  143. ^ Richard Utz, "Contra el lenguaje administrativo", Chronicle of Higher Education, 24 de junio de 2020.
  144. ^ Cohn, Mike (2015). Cómo tener éxito con Agile . Pearson. Págs. 5-10. ISBN. 978-0-321-57936-2.

Lectura adicional

Enlaces externos