En el desarrollo de software , las prácticas ágiles (a veces escritas Agile ) [1] implican descubrir requisitos y desarrollar soluciones a través del esfuerzo colaborativo de equipos autoorganizados y multifuncionales y sus clientes / usuarios finales . [2] Aboga por la planificación adaptativa, el desarrollo evolutivo, la entrega temprana y la mejora continua , y fomenta respuestas flexibles al cambio. [3] [4] [ se necesita más explicación ]
Fue popularizado por el Manifiesto de 2001 para el desarrollo de software ágil . [5] Los valores y principios propuestos en este manifiesto se derivaron y sustentan una amplia gama de marcos de desarrollo de software , incluidos Scrum y Kanban . [6] [7]
Si bien existe mucha evidencia anecdótica de que la adopción de prácticas y valores ágiles mejora la agilidad de los profesionales, equipos y organizaciones del software, la evidencia empírica es mixta y difícil de encontrar. [8] [9]
Historia
Los métodos de desarrollo de software iterativos e incrementales se remontan a 1957, [10] con la gestión de proyectos evolutivos [11] [12] y el desarrollo de software adaptativo [13] surgiendo a principios de la década de 1970. [14]
Durante la década de 1990, una serie de métodos de desarrollo de software ligero evolucionaron en reacción a los métodos de peso pesado predominantes (a menudo denominados colectivamente en cascada ) que los críticos describieron como excesivamente regulados, planificados y microgestionados . Estos incluyeron: desarrollo rápido de aplicaciones (RAD), desde 1991; [15] [16] el proceso unificado (UP) y el método de desarrollo de sistemas dinámicos (DSDM), ambos de 1994; Scrum , de 1995; Programación Crystal Clear y extrema (XP), ambas de 1996; y desarrollo impulsado por funciones , desde 1997. Aunque todos estos se originaron antes de la publicación del Manifiesto Ágil , ahora se denominan colectivamente métodos de desarrollo de software ágiles. [7] Al mismo tiempo, se estaban llevando a cabo cambios similares en la fabricación [17] [18] y el pensamiento administrativo [ cita requerida ] .
En 2001, estos diecisiete desarrolladores de software se reunieron en un resort en Snowbird , Utah para discutir estos métodos de desarrollo ligeros: Kent Beck , Ward Cunningham , Dave Thomas , Jeff Sutherland , Ken Schwaber , Jim Highsmith , Alistair Cockburn , Robert C. Martin , Mike Beedle , Arie van Bennekum , Martin Fowler , James Grenning, Andrew Hunt , Ron Jeffries , Jon Kern , Brian Marick y Steve Mellor . Juntos publicaron el Manifiesto para el desarrollo de software ágil . [5]
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, [19] para guiar la gestión de proyectos de software de acuerdo con métodos ágiles de desarrollo de software.
En 2009, un grupo que trabajaba con Martin escribió una extensión de los principios de desarrollo de software , el Software Craftsmanship Manifesto , para guiar el desarrollo de software ágil de acuerdo con la conducta y el dominio profesionales .
En 2011, Agile Alliance creó la Guía de prácticas ágiles (rebautizada como Glosario ágil en 2016), [20] un compendio de código abierto en evolución de las definiciones de trabajo de prácticas, términos y elementos ágiles, junto con interpretaciones y pautas de experiencia de la comunidad mundial de practicantes ágiles.
El manifiesto para el desarrollo de software ágil
Valores de desarrollo de software ágil
Basándose en su experiencia combinada de desarrollar software y ayudar a otros a hacer eso, los diecisiete signatarios del manifiesto proclamaron que valoran: [5]
- Individuos e interacciones sobre procesos y herramientas
- Software de trabajo sobre documentación completa
- Colaboración con el cliente sobre la negociación del contrato
- Responder al cambio sobre seguir un plan
Es decir, los elementos de la izquierda se valoran más que los elementos de la derecha. No quiere decir que los elementos de la derecha deban excluirse en favor de los elementos de la izquierda. Ambos lados tienen valor, pero desde el punto de vista del desarrollo ágil, los autores del manifiesto inclinan la balanza a favor de los elementos de la izquierda.
Como aclaró Scott Ambler : [21]
- Las herramientas y los procesos son importantes, pero es más importante contar con personas competentes que trabajen juntas de manera eficaz.
- 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 punto principal del desarrollo es crear software, no documentación.
- Un contrato es importante, pero no sustituye a trabajar 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 medio ambiente, las prioridades de las partes interesadas y la comprensión de las personas sobre el problema y su solución.
Algunos de los autores formaron Agile Alliance, una organización sin fines de lucro que promueve el desarrollo de software de acuerdo con los valores y principios del manifiesto. Al presentar el manifiesto en nombre de Agile Alliance, Jim Highsmith dijo:
El movimiento Agile no es anti-metodología, de hecho muchos de nosotros queremos devolverle credibilidad a la palabra metodología. Queremos restablecer el equilibrio. Adoptamos el modelado, pero no para archivar algún diagrama en un repositorio corporativo polvoriento. Aceptamos la documentación, pero no cientos de páginas de tomos que nunca se mantienen y que rara vez se usan. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento. Aquellos que calificarían a los defensores de XP o SCRUM o cualquiera de las otras metodologías ágiles como "hackers" ignoran tanto las metodologías como la definición original del término hacker.
- Jim Highsmith, Historia: El manifiesto ágil [22]
Principios de desarrollo de software ágil
El Manifiesto para el desarrollo de software ágil se basa en doce principios: [23]
- Satisfacción del cliente mediante la entrega temprana y continua de software valioso.
- Bienvenidos requisitos cambiantes, incluso en el desarrollo tardío.
- Entregue software que funcione con frecuencia (semanas en lugar de meses)
- Cooperación estrecha y diaria entre empresarios y desarrolladores.
- Los proyectos se basan en personas motivadas, en las que se debe confiar.
- La conversación cara a cara es la mejor forma de comunicación (coubicación)
- El software que funciona es la principal medida de progreso
- Desarrollo sostenible, capaz de mantener un ritmo constante
- Atención continua a la excelencia técnica y al buen diseño.
- La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas , requisitos y diseños surgen de equipos autoorganizados
- Regularmente, el equipo reflexiona sobre cómo ser más efectivo y se ajusta en consecuencia.
Descripción general
Iterativo, incremental y evolutivo
La mayoría de los métodos de desarrollo ágiles 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 periodos de tiempo cortos ( timeboxes ) que normalmente duran de una a cuatro semanas. 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 muestra un producto funcional a las partes interesadas. Esto minimiza el riesgo general y permite que el producto se adapte rápidamente a los cambios. [24] Es posible que una iteración no agregue suficiente funcionalidad para garantizar un lanzamiento en el mercado, pero el objetivo es tener una versión disponible (con errores mínimos ) al final de cada iteración. [25] A través del desarrollo incremental, los productos tienen espacio para "fallar a menudo y temprano" en cada fase iterativa en lugar de drásticamente en una fecha de lanzamiento final. [26] Pueden ser necesarias varias iteraciones para lanzar un producto o nuevas funciones. El software que funciona es la principal medida de progreso. [23]
Comunicación eficiente y cara a cara
El principio de la coubicación es que los compañeros de trabajo del mismo equipo deben estar juntos para establecer mejor la identidad como equipo y mejorar la comunicación. [27] 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 realizan a través del teléfono, chat persistente, wiki o correo electrónico. [28]
Independientemente del método de desarrollo que se siga, cada equipo debe incluir un representante del cliente ("Product Owner" en Scrum ). Las partes interesadas acuerdan que esta persona actúe en su nombre y se compromete personalmente a estar disponible para que los desarrolladores respondan preguntas a lo largo de la iteración. Al final de cada iteración, las partes interesadas y el representante del cliente revisan el progreso y reevalúan las prioridades con el fin de optimizar el retorno de la inversión (ROI) y asegurar 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 frecuente y la revisión al final de cada fase, es la razón por la que la metodología a menudo se denota como una "Metodología Centrada en el Cliente". [29]
En el desarrollo de software ágil, un radiador de información es una pantalla física (normalmente grande) ubicada de manera prominente cerca del equipo de desarrollo, donde los transeúntes pueden verla. Presenta un resumen actualizado del estado de desarrollo del producto. [30] [31] Un indicador luminoso de construcción también se puede utilizar para informar a un equipo sobre el estado actual de desarrollo de sus productos.
Bucle de retroalimentación y ciclo de adaptación muy corto
Una característica común en el desarrollo de software ágil es el stand-up diario (un scrum diario en el marco de Scrum). En una breve sesión, los miembros del equipo se informan entre sí lo que hicieron el día anterior para lograr la meta de iteración de su equipo, lo que pretenden hacer hoy para lograr la meta y cualquier obstáculo o impedimento que puedan ver hacia la meta. [32]
Enfoque de calidad
Herramientas y técnicas específicas, tales como la integración continua , automatizada de la unidad de pruebas , la programación en parejas , desarrollo basado en pruebas , patrones de diseño , desarrollo guiado por comportamiento , diseño de dominio impulsada , refactorización de código y otras técnicas se utilizan a menudo para mejorar la calidad y mejorar el desarrollo de productos agilidad. [33] Esto se basa en diseñar y desarrollar la calidad desde el principio y poder demostrar el software a los clientes en cualquier momento, o al menos al final de cada iteración. [34]
Filosofía
En comparación con la ingeniería de software tradicional, el desarrollo de software ágil se dirige principalmente al desarrollo de productos y sistemas complejos con características dinámicas, no deterministas y no lineales. Las estimaciones precisas, los planes estables y las predicciones suelen ser difíciles de obtener en las primeras etapas y es probable que la confianza en ellos sea baja. Los practicantes ágiles buscarán reducir el acto de fe que se necesita antes de que se pueda obtener cualquier evidencia de valor. [35] 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 al desarrollo ágil a favor del desarrollo adaptativo, iterativo y evolutivo. [36]
Adaptativo vs predictivo
Los métodos de desarrollo existen en un continuo desde adaptativo hasta predictivo . [37] Los métodos ágiles de desarrollo de software se encuentran en el lado adaptativo de este continuo. Una clave de los métodos de desarrollo adaptativo es un enfoque de onda 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. [38]
Los métodos adaptativos se centran en adaptarse rápidamente a las realidades cambiantes. Cuando las necesidades de un proyecto cambian, también cambia un equipo adaptativo. Un equipo de adaptación tiene dificultades para describir exactamente lo que sucederá en el futuro. Cuanto más lejana está una fecha, más vago es el método adaptativo sobre lo que sucederá en esa fecha. Un equipo adaptable no puede informar exactamente qué tareas harán la próxima semana, sino solo qué funciones planean para el próximo mes. Cuando se le pregunte acerca de un lanzamiento dentro de seis meses, un equipo de adaptación 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 los extremos, un equipo predictivo puede informar exactamente qué funciones y tareas están planificadas para todo el proceso de desarrollo. Los métodos predictivos se basan en un análisis de fase inicial eficaz y, si esto sale muy mal, el proyecto puede tener dificultades para cambiar de dirección. Los equipos predictivos a menudo instituyen un tablero de control de cambios para garantizar que solo consideren los cambios más valiosos.
El análisis de riesgo se puede utilizar para elegir entre métodos adaptativos ( ágiles o basados en valores ) y predictivos ( basados en planes ). [39] Barry Boehm y Richard Turner sugieren que cada lado del continuo tiene su propio terreno de origen , como sigue: [40]
Métodos basados en valores | Métodos basados en planes | Métodos formales |
---|---|---|
Criticidad baja | Alta criticidad | Criticidad extrema |
Desarrolladores senior | Desarrolladores junior (?) | Desarrolladores senior |
Los requisitos cambian a menudo | Los requisitos no cambian a menudo | Requisitos limitados, funciones limitadas consulte la ley de Wirth [ aclaración necesaria ] |
Pequeño número de desarrolladores | Gran cantidad de desarrolladores | Requisitos que se pueden modelar |
Cultura que responde al cambio | Cultura que exige orden | Calidad extrema |
Ágil contra cascada
Una de las diferencias entre los métodos de desarrollo de software ágiles y la 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 de desarrollo de software (SDLC), con una fase que se completa antes de que otra pueda comenzar, por lo que la fase de prueba es separada y sigue a una fase de construcción . Sin embargo, en el desarrollo de software ágil, las pruebas se completan en la misma iteración que la programación. Otra forma de verlo es “Agile: hágalo sobre la marcha. Cascada: inventa antes de empezar, vive con las consecuencias ”. [41]
Debido a que las pruebas se realizan en cada iteración, que desarrolla una pequeña parte del software, los usuarios pueden usar con frecuencia esas nuevas piezas de software y validar el valor. Una vez que los usuarios conocen el valor real del software actualizado, pueden tomar mejores decisiones sobre el futuro del software. Tener una retrospectiva de valor y una sesión de reprogramación de software en cada iteración ( Scrum generalmente 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 Planificar-Hacer-Verificar-Actuar (PDCA), ya que el trabajo se planifica , se realiza , se verifica (en la revisión y retrospectiva) y se actúa sobre cualquier cambio acordado .
Este enfoque iterativo respalda un producto en lugar de una mentalidad de proyecto . Esto proporciona una mayor flexibilidad durante todo el proceso de desarrollo; mientras que en los proyectos los requisitos se definen y bloquean desde el principio, lo que dificulta su modificación posterior. El desarrollo de productos iterativos permite que el software evolucione en respuesta a cambios en el entorno empresarial o los requisitos del mercado. [42]
Debido al estilo de iteración corta del desarrollo de software ágil, también tiene fuertes conexiones con el concepto de puesta en marcha ajustada.
Código frente a documentación
En una carta a IEEE Computer , Steven Rakitin expresó cinismo sobre el desarrollo ágil de software, llamándolo " otro intento más de socavar la disciplina de la ingeniería de software " y traduciendo " software de trabajo sobre documentación completa " como " queremos pasar todo nuestro tiempo codificando". Recuerde, los programadores reales no escriben documentación ". [43]
Esto es cuestionado por los defensores del desarrollo de software ágil, quienes afirman que los desarrolladores deberían escribir documentación si esa es la mejor manera de lograr los objetivos relevantes, pero que a menudo hay mejores formas de lograr esos objetivos que escribir documentación estática. [44] Scott Ambler afirma que la documentación debería ser "apenas lo suficientemente buena" (JBGE), [45] que demasiada o completa documentación generalmente causaría desperdicio, y los desarrolladores rara vez confían en la documentación detallada porque generalmente no está sincronizada con el código, [ 44] mientras que muy poca documentación también puede causar problemas para el mantenimiento, la comunicación, el aprendizaje y el intercambio de conocimientos. Alistair Cockburn escribió sobre el método Crystal Clear :
Crystal considera el desarrollo como una serie de juegos cooperativos y tiene la intención de que la documentación sea suficiente para ayudar a la próxima victoria en el próximo juego. Los productos de trabajo para 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 suficiente documentación para el próximo juego. Siempre suelo caracterizar esto a mi equipo como: ¿Qué le gustaría saber si se uniera al equipo mañana?
- Alistair Cockburn. [46]
Métodos ágiles de desarrollo de software
Los métodos de desarrollo de software ágiles admiten una amplia gama del ciclo de vida del desarrollo de software . [47] 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). Algunas actividades de apoyo para la especificación y el desarrollo de requisitos (por ejemplo, FDD), mientras que otras buscan cubrir el ciclo de vida completo del desarrollo (por ejemplo, DSDM, RUP ).
Los marcos de desarrollo de software ágiles notables incluyen:
Marco de referencia | Contribuyente (s) principal (es) |
---|---|
Desarrollo de software adaptativo (ASD) | Jim Highsmith , Sam Bayer |
Modelado ágil | Scott Ambler , Robert Cecil Martin |
Proceso unificado ágil (AUP) | Scott Ambler |
Entrega ágil disciplinada | Scott Ambler |
Método de desarrollo de sistemas dinámicos (DSDM) | |
Programación extrema (XP) | Kent Beck , Robert Cecil Martin |
Desarrollo basado en funciones (FDD) | Jeff De Luca |
Desarrollo de software esbelto | Mary Poppendieck, Tom Poppendieck |
Puesta en marcha ajustada | Eric Ries |
Kanban | Taiichi Ohno |
Desarrollo rápido de aplicaciones (RAD) | James Martin |
Melé | Ken Schwaber y Jeff Sutherland |
Scrumban | |
Marco ágil escalado - SAFe | Scaled Agile, Inc. |
Prácticas ágiles de desarrollo de software
El desarrollo de software ágil está respaldado por una serie de prácticas concretas, que cubren áreas como requisitos, diseño, modelado, codificación, pruebas, planificación, gestión de riesgos, proceso, calidad, etc. Algunas prácticas de desarrollo de software ágil notables incluyen: [48]
Práctica | Contribuyente (s) principal (es) |
---|---|
Desarrollo impulsado por pruebas de aceptación (ATDD) | |
Modelado ágil | |
Pruebas ágiles | |
Backlogs (Producto y Sprint) | Ken Schwaber |
Desarrollo impulsado por el comportamiento (BDD) | Dan North, Liz Keogh |
Integración continua (CI) | Grady Booch |
Equipo multidisciplinar | |
Stand-up diario / Scrum diario | James O Coplien |
Diseño controlado por dominio (DDD) | Eric Evans |
Desarrollo iterativo e incremental (IID) | |
Programación en pareja | Kent Beck |
Planificación de póquer | James Grenning y Mike Cohn |
Refactorización | Martin Fowler |
Retrospectivo | |
Eventos de Scrum (planificación de sprint, revisión de sprint y retrospectiva) | |
Especificación por ejemplo | |
Modelado basado en historias | Albert Zündorf |
Desarrollo impulsado por pruebas (TDD) | Kent Beck |
Timeboxing | |
Historia del usuario | Alistair Cockburn |
Seguimiento de velocidad |
Adaptación del método
En la literatura, diferentes términos se refieren a la noción de adaptación de métodos, incluyendo 'adaptación de métodos', 'adaptación de fragmentos de métodos' e 'ingeniería de métodos situacionales'. La adaptación del método 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 sensibles 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 [49]
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 planes, con métodos ágiles que permitan a los equipos de desarrollo de productos adaptar las prácticas de trabajo de acuerdo con las necesidades de los productos individuales. [50] [49] Potencialmente, la mayoría de los métodos ágiles podrían ser adecuados para la adaptación de métodos, [47] como DSDM adaptado en un contexto de CMM . [51] y XP adaptados con la técnica de Prácticas de descripción de reglas (RDP). [52] No todos los defensores ágiles están de acuerdo, sin embargo, con Schwaber señalando 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". [53] Bas Vodde reforzó este punto de vista, sugiriendo que a diferencia de las grandes metodologías tradicionales que requieren que usted elija y elija elementos, Scrum proporciona los conceptos básicos sobre los cuales agrega elementos adicionales para localizar y contextualizar su uso. [54] Los profesionales rara vez utilizan métodos de desarrollo de sistemas, o métodos ágiles específicamente, según el libro, a menudo optan por omitir o adaptar algunas de las prácticas de un método para crear un método interno. [55]
En la práctica, los métodos se pueden adaptar utilizando varias herramientas. Los lenguajes de modelado de procesos genéricos, como el lenguaje de modelado unificado, se pueden utilizar para adaptar los métodos de desarrollo de software. Sin embargo, también existen herramientas dedicadas para la ingeniería de métodos como la Teoría de la Esencia de la Ingeniería de Software de la SEMAT . [56]
A gran escala, costa afuera y distribuida
El desarrollo de software ágil ha sido ampliamente visto como muy adecuado para ciertos tipos de entornos, incluidos pequeños equipos de expertos que trabajan en proyectos nuevos , [40] [57] : 157 y los desafíos y limitaciones encontrados en la adopción de métodos de desarrollo de software ágiles en un Las grandes organizaciones con infraestructura heredada están bien documentadas y comprendidas. [58]
En respuesta, ha evolucionado una serie de estrategias y patrones para superar desafíos con esfuerzos de desarrollo a gran escala (> 20 desarrolladores) [59] [60] o equipos de desarrollo distribuidos (no colocados), [61] [62] entre otros desafíos ; y ahora existen varios marcos reconocidos que buscan mitigar o evitar estos desafíos.
- Marco ágil escalado (SAFe), [63] Dean Leffingwell et al
- Entrega ágil disciplinada (DAD), Scott Ambler et al
- Scrum a gran escala (LeSS), Craig Larman y Bas Vodde
- Nexus (Scrum profesional a escala), [64] Ken Schwaber
- Scrum a escala, [65] Jeff Sutherland , Alex Brown
- Enterprise Scrum, [66] Mike Beedle
- Setchu (marco ligero basado en Scrum), [67] Michael Ebbage
- XSCALE [68]
- Camino ágil [69] -
- Desarrollo de software holístico [70]
Hay muchos puntos de vista contradictorios sobre si todos estos son efectivos o si se ajustan a la definición de desarrollo ágil, y esta sigue siendo un área de investigación activa y en curso. [59] [71]
Cuando el desarrollo de software ágil se aplica en un entorno distribuido (con equipos dispersos en múltiples ubicaciones comerciales), se lo conoce comúnmente como 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 configuración estratégica de equipos en diferentes partes del mundo, creando virtualmente software las 24 horas del día (más comúnmente conocido como modelo de seguimiento del sol). Por otro lado, el desarrollo ágil proporciona una mayor transparencia, retroalimentación continua y más flexibilidad al responder a los cambios.
Dominios regulados
Inicialmente, se consideró que los métodos de desarrollo de software ágiles eran los más adecuados para desarrollos de productos no críticos, por lo que se excluyeron del uso en dominios regulados como los de dispositivos médicos , farmacéuticos, financieros, sistemas nucleares, automotriz y 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. [72] [73] [74] [75] [76]
Existen numerosos estándares que pueden aplicarse en dominios regulados, incluidos ISO 26262 , ISO 9000 , ISO 9001 e ISO / IEC 15504 . Varias preocupaciones clave son de particular importancia en los ámbitos regulados: [77]
- Aseguramiento de la calidad (QA): Gestión de la calidad sistemática e inherente que sustenta un proceso profesional controlado y la confiabilidad 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 del uso indebido no intencionado y malintencionado.
- 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): Integrado en todo el proceso de desarrollo de software (por ejemplo, especificación de requisitos de usuario, especificación funcional, especificación de diseño, revisión de código, pruebas unitarias, pruebas de integración, pruebas del sistema).
Experiencia y adopción
Aunque los métodos de desarrollo de software ágiles se pueden utilizar con cualquier paradigma o lenguaje de programación en la práctica, originalmente estaban estrechamente asociados con entornos orientados a objetos como Smalltalk, Lisp y más tarde Java, C #. Los que adoptaron inicialmente los métodos ágiles fueron generalmente equipos de tamaño pequeño a mediano que trabajaban en sistemas sin precedentes con requisitos que eran difíciles de finalizar y que probablemente cambiarían a medida que se desarrollaba el sistema. Esta sección describe los problemas comunes que encuentran las organizaciones cuando intentan adoptar métodos de desarrollo de software ágiles, así como varias técnicas para medir la calidad y el desempeño de los equipos ágiles. [78]
Midiendo la agilidad
Evaluaciones internas
El índice de medición de la agilidad , entre otros, clasifica los desarrollos en función de cinco dimensiones del desarrollo de productos (duración, riesgo, novedad, esfuerzo e interacción). [79] [80] Otras técnicas se basan en objetivos medibles [81] y un estudio sugiere que la velocidad se puede utilizar como una métrica de agilidad. [82] También hay autoevaluaciones ágiles para determinar si un equipo está utilizando prácticas de desarrollo de software ágiles (prueba de Nokia, [83] prueba de Karlskrona, [84] prueba de 42 puntos). [85]
Encuestas públicas
Uno de los primeros estudios que informaron mejoras en la calidad, la productividad y la satisfacción empresarial mediante el uso de métodos ágiles de desarrollo de software fue una encuesta realizada por Shine Technologies entre noviembre de 2002 y enero de 2003. [86]
Una encuesta similar, State of Agile , se realiza todos los años a partir de 2006 con miles de participantes de toda la comunidad de desarrollo de software. Esto rastrea las tendencias sobre los beneficios percibidos de la agilidad, las lecciones aprendidas y las buenas prácticas. Cada encuesta ha reportado un número creciente 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. [87] Las encuestas también han mostrado sistemáticamente mejores resultados con métodos de desarrollo de productos ágiles en comparación con la gestión de proyectos clásica. [88] [89] En resumen, hay informes de que algunos creen que los métodos de desarrollo ágiles son todavía demasiado jóvenes para permitir una investigación académica exhaustiva de su éxito. [90]
Errores comunes en el desarrollo de software ágil
Las organizaciones y los equipos que implementan el desarrollo de software ágil a menudo enfrentan dificultades para pasar de métodos más tradicionales, como el desarrollo en cascada , como los equipos que tienen un proceso ágil forzado. [91] Estos a menudo se denominan antipatrones ágiles o, más comúnmente, olores ágiles . A continuación se muestran algunos ejemplos comunes:
Falta de diseño general del producto
Un objetivo del desarrollo de software ágil es centrarse más en la producción de software funcional y menos en la documentación. Esto contrasta con los modelos en cascada donde el proceso a menudo está altamente controlado y los cambios menores en el sistema requieren una revisión significativa de la documentación de respaldo. Sin embargo, esto no justifica prescindir completamente de ningún análisis o diseño. No prestar atención al diseño puede hacer que un equipo proceda rápidamente al principio, pero luego se requiera un retrabajo significativo a medida que intentan ampliar el sistema. Una de las características clave del desarrollo de software ágil es que es iterativo. Cuando se hace correctamente, el diseño emerge a medida que se desarrolla el sistema y se descubren los puntos en común y las oportunidades de reutilización. [92]
Agregar historias a una iteración en progreso
En el desarrollo de software ágil, 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. [93] Agregar historias a una iteración en progreso es perjudicial para un buen flujo de trabajo. Estos deben agregarse a la acumulación de productos y priorizarse para una iteración posterior o, en casos excepcionales, la iteración podría cancelarse. [94]
Esto no significa que una historia no pueda expandirse. Los equipos deben lidiar con nueva información, lo que puede producir tareas adicionales para una historia. Si la nueva información impide que la historia se complete durante la iteración, entonces debe transferirse a una iteración posterior. Sin embargo, debe priorizarse frente a todas las historias restantes, ya que la nueva información puede haber cambiado la prioridad original de la historia.
Falta de apoyo del patrocinador
El desarrollo de software ágil a menudo se implementa como un esfuerzo de base en las organizaciones por 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 los socios comerciales, otros equipos de desarrollo y la administración. Además, pueden sufrir sin la financiación y los recursos adecuados. [95] Esto aumenta la probabilidad de falla. [96]
Entrenamiento insuficiente
Una encuesta realizada por VersionOne encontró que los encuestados citaron una capacitación insuficiente como la causa más importante de implementaciones ágiles fallidas [97] Los equipos han caído en la trampa de asumir que los procesos reducidos de desarrollo de software ágil en comparación con otras metodologías como cascada significa que no existen reglas para el desarrollo ágil de software. [ cita requerida ]
La función de propietario del producto no se ha cumplido correctamente
El propietario del producto es responsable de representar a la empresa en la actividad de desarrollo y, a menudo, es el rol más exigente. [98]
Un error común es que el rol de propietario de producto sea ocupado por alguien del equipo de desarrollo. Esto requiere que el equipo tome sus propias decisiones sobre la priorización sin comentarios reales de la empresa. Intentan resolver problemas comerciales internamente o retrasan el trabajo cuando buscan dirección fuera del equipo. Esto a menudo conduce a distracciones y fallas en la colaboración. [99]
Los equipos no están enfocados
El desarrollo de software ágil requiere que los equipos cumplan con los compromisos del producto, lo que significa que deben centrarse en el trabajo solo para ese producto. Sin embargo, a menudo se espera que los miembros del equipo que parecen tener capacidad sobrante realicen otro trabajo, lo que les dificulta ayudar a completar el trabajo al que se había comprometido su equipo. [100]
Preparación / planificación excesiva
Los equipos pueden caer en la trampa de pasar demasiado tiempo preparándose o planificando. Esta es una trampa común para los equipos menos familiarizados con el desarrollo de software ágil, donde los equipos se sienten obligados a tener una comprensión y una especificación completas de todas las historias. Los equipos deben estar preparados para avanzar solo con aquellas historias en las que tengan confianza, luego, durante la iteración, continuar descubriendo y preparando el trabajo para las iteraciones posteriores (a menudo denominadas refinamiento o preparación de la acumulación ).
Resolución de problemas en el standup diario
Una reunión diaria debe ser una reunión enfocada y oportuna en la que todos los miembros del equipo difundan información. Si ocurre la resolución de problemas, a menudo puede involucrar solo a ciertos miembros del equipo y potencialmente no es el mejor uso del tiempo de todo el equipo. Si durante el enfrentamiento diario el equipo comienza a sumergirse en la resolución de problemas, debe dejarse de lado hasta que un sub-equipo pueda discutir, generalmente inmediatamente después de que se completa el enfrentamiento. [101]
Asignar tareas
Uno de los beneficios previstos del desarrollo de software ágil es capacitar al equipo para que tome decisiones, ya que están más cerca del problema. Además, deben tomar decisiones lo más cercanas a la implementación como sea posible, para utilizar información más oportuna en la decisión. Si otros asignan tareas a los miembros del equipo o en una etapa demasiado temprana del proceso, se pueden perder los beneficios de la toma de decisiones localizada y oportuna. [102]
La asignación de trabajo también restringe a los miembros del equipo a ciertos 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. [102] Los propios miembros del equipo pueden optar por realizar tareas que amplíen sus habilidades y brinden oportunidades de capacitación cruzada.
Scrum master como colaborador
En la metodología Scrum, que es una metodología popular que afirma ser coherente con los valores y principios ágiles, un scrum master es la persona responsable de garantizar que se lleve a cabo el proceso de scrum y de entrenar al equipo de scrum a través de ese proceso. Un error común es que un scrum master actúe como colaborador. Si bien no está prohibido por la metodología Scrum, el scrum master debe asegurarse de tener la capacidad de actuar primero en el rol de scrum master y no trabajar en tareas de desarrollo. El papel de un scrum master es facilitar el proceso en lugar de crear el producto. [103]
Tener el scrum master también multitarea puede resultar en demasiados cambios de contexto para ser productivo. Además, como un 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 superar los obstáculos que se aplazan debido a la falta de capacidad. [103]
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 repetidas de unidad, integración y regresión y libera a los desarrolladores y evaluadores para que se concentren en trabajos de mayor valor. [104]
La automatización de pruebas también admite la refactorización continua requerida por el desarrollo de software iterativo. 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 ofrecer nuevas funciones puede resultar en un aumento de la deuda técnica . El equipo debe darse tiempo para corregir los defectos y refactorizar. La deuda técnica obstaculiza la capacidad de planificación al aumentar la cantidad de trabajo no programado, ya que los defectos de producción distraen al equipo de seguir avanzando. [105]
A medida que el sistema evoluciona, es importante refactorizar a medida que la entropía del sistema aumenta naturalmente. [106] Con el tiempo, la falta de mantenimiento constante provoca un aumento de los defectos y los costes de desarrollo. [105]
Intentar asumir demasiado en una iteración
Un error común es que el desarrollo de software ágil permite un cambio continuo, sin embargo, una acumulación de iteraciones es un acuerdo de qué trabajo se puede completar durante una iteración. [107] Tener demasiado trabajo en progreso (WIP) da como resultado ineficiencias como el cambio de contexto y las colas. [108] El equipo debe evitar sentirse presionado para realizar trabajos adicionales. [109]
Tiempo, recursos, alcance y calidad fijos
El desarrollo de software ágil corrige el tiempo (duración de la iteración), la calidad e idealmente los recursos por adelantado (aunque mantener los recursos fijos puede ser difícil si los desarrolladores a menudo se alejan de las tareas para manejar los incidentes de producción), mientras que el alcance sigue siendo variable. El cliente o propietario del producto a menudo presiona por un alcance fijo para una iteración. Sin embargo, los equipos deben mostrarse 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 para agregar alcance al tiempo fijo y los recursos del desarrollo de software ágil pueden resultar en una disminución de la calidad. [110]
Agotamiento del desarrollador
Debido al ritmo enfocado y la naturaleza continua de las prácticas ágiles, existe un mayor riesgo de agotamiento entre los miembros del equipo de entrega. [111]
Gestión ágil
El término gestión ágil se aplica a un método iterativo e incremental de gestionar las actividades de diseño y construcción de ingeniería, tecnología de la información y otras áreas de negocio que tienen como objetivo proporcionar el desarrollo de nuevos productos o servicios de una manera altamente flexible e interactiva, con base en los principios expresados. en el Manifiesto para el desarrollo ágil de software . [112]
Las técnicas Agile X también pueden denominarse gestión de proyectos extremos . Es una variante del ciclo de vida iterativo [113] donde los entregables se presentan 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), [114] mientras que los métodos iterativos evolucionan el conjunto completo de entregables a lo largo del tiempo, completándolos cerca del final del proyecto. Tanto los métodos iterativos como los ágiles se desarrollaron como reacción a varios obstáculos que se desarrollaron en formas más secuenciales de organización de proyectos. Por ejemplo, a medida que los proyectos de tecnología aumentan en complejidad, los usuarios finales tienden a tener dificultades para definir los requisitos a largo plazo sin poder ver prototipos progresivos. Los proyectos que se desarrollan en iteraciones pueden recopilar comentarios constantemente para ayudar a 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 pasado entre los miembros del equipo . [115] Los equipos que utilizaban la planificación en cascada tradicional 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 sin problemas. Por lo general, hay dos estilos de coaching ágil: coaching ágil basado en push y basado en pull . 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. [116]
Los métodos ágiles se mencionan en la Guía para el conocimiento de la gestión de proyectos ( Guía del PMBOK ) en la definición del ciclo de vida del proyecto:
Ciclo de vida adaptable del proyecto , un ciclo de vida del proyecto, también conocido como métodos ágiles o impulsados por el cambio, que está destinado a facilitar el cambio y requiere un alto grado de participación continua de las partes interesadas . Los ciclos de vida adaptativos también son iterativos e incrementales, pero difieren en que las iteraciones son muy rápidas (generalmente de 2 a 4 semanas de duración) y están fijas en tiempo y recursos . [117]
Aplicaciones fuera del desarrollo de software
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 que no son software y para la gestión de proyectos en general, especialmente en áreas de innovación e incertidumbre". El resultado final es un producto o proyecto que satisface mejor las necesidades actuales del cliente y se entrega con costos, desperdicios y tiempo mínimos, lo que permite a las empresas lograr ganancias finales antes que con los enfoques tradicionales. [118]
Los métodos ágiles de desarrollo de software se han utilizado ampliamente para el desarrollo de productos de software y algunos de ellos utilizan ciertas características del software, como tecnologías de objetos. [119] Sin embargo, estas técnicas se pueden aplicar al desarrollo de productos que no son de software, como computadoras, dispositivos médicos, alimentos, ropa y música. [120] Se han utilizado métodos ágiles de desarrollo de software en implementaciones y migraciones de infraestructura de TI que no son de desarrollo . Algunos de los principios más amplios del desarrollo ágil de software también han encontrado aplicación en la gestión general [121] (por ejemplo, estrategia, gobernanza, riesgo, finanzas) bajo los términos agilidad empresarial o gestión empresarial ágil.
Los paradigmas de desarrollo de software ágil 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 conciencia. 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. [122]
Crítica
Las prácticas ágiles pueden ser ineficaces en organizaciones grandes y ciertos tipos de desarrollos. [123] Muchas organizaciones creen que las metodologías de desarrollo de software ágil son demasiado extremas y adoptan un enfoque híbrido [124] que combina elementos de desarrollo de software ágil y enfoques basados en planes. [125] Algunos métodos, como el método de desarrollo de sistemas dinámicos (DSDM), intentan esto de una 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 con una nueva jerga, promueve una mentalidad única para todas las estrategias de desarrollo y enfatiza erróneamente el método sobre los resultados. [126]
Alistair Cockburn organizó una celebración del décimo aniversario del Manifiesto para el desarrollo de software ágil en Snowbird, Utah, el 12 de febrero de 2011, reuniendo a más de 30 personas que habían estado involucradas en la reunión original y desde entonces. Se recopiló una lista de unos 20 elefantes en la sala (temas / problemas ágiles 'indiscutibles'), incluidos aspectos: las alianzas, los fracasos y las limitaciones de las prácticas y el contexto de desarrollo de software ágil (causas posibles: intereses comerciales, descontextualización, ninguna forma obvia de progresar sobre la base del fracaso, la evidencia objetiva limitada, los sesgos cognitivos y las falacias de razonamiento), la política y la cultura. [127] Como escribió Philippe Kruchten :
El movimiento ágil se parece en cierto modo a un adolescente: muy cohibido, revisando constantemente su apariencia en un espejo, aceptando pocas críticas, solo interesado en estar con sus pares, rechazando en bloque toda sabiduría del pasado, solo porque es del pasado, adopta modas y jerga nueva, a veces engreída y arrogante. Pero no tengo ninguna duda de que madurará más, se volverá más abierto al mundo exterior, más reflexivo y, por tanto, más eficaz.
- Philippe Kruchten [127]
El "Manifiesto" pudo haber tenido un impacto negativo en la gestión y el liderazgo de la educación superior, donde sugirió a los administradores que los procesos tradicionales y deliberativos más lentos deberían ser reemplazados por otros más "ágiles". El concepto rara vez encontró aceptación entre los profesores universitarios. [128]
Otra crítica es que, en muchos sentidos, la gestión ágil y las prácticas de gestión tradicionales terminan oponiéndose entre sí. Una crítica común a esta práctica es que el tiempo dedicado 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 Agile y un compromiso firme de todos los miembros de la organización para llevar a cabo el proceso. Problemas como resultados desiguales en toda la organización, demasiados cambios para que los empleados puedan manejarlos o la falta de garantías al final de la transformación son solo algunos ejemplos. [129]
Ver también
- Autogestión de los trabajadores
Referencias
- ^ Rally (2010). "Ágil con mayúscula" A "vs. ágil con minúscula" a " " . Archivado desde el original el 5 de enero de 2016 . Consultado el 9 de septiembre de 2015 .CS1 maint: URL no apta ( enlace )
- ^ Collier, Ken W. (2011). Análisis ágil: un enfoque basado en el valor para la inteligencia empresarial y el almacenamiento de datos . Educación Pearson. págs. 121 y sigs. ISBN 9780321669544.
¿Qué es un equipo autoorganizado?
- ^ Beck, Kent M .; Beedle, Mike; Bennekum, Arie van; Cockburn, Alistair; Cunningham, Ward; Fowler, Martin; Grenning, James; Highsmith, Jim; Hunt, Andy; Jeffries, Ron; Kern, Jon; Marick, Brian; Martin, RC; Mellor, Steve J .; Schwaber, Ken; Sutherland, Jeff; Thomas, Dave. "Manifiesto para el desarrollo ágil de software". Indefinido . S2CID 109006295 .
- ^ "¿Qué es el desarrollo de software ágil?" . Alianza ágil. 8 de junio de 2013 . Consultado el 4 de abril de 2015 .
- ^ a b c 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" . Alianza ágil . Consultado el 14 de junio de 2010 .
- ^ ¿Qué es mejor, Kanban o Scrum? , 4 de marzo de 2016
- ^ a b Larman, Craig (2004). Desarrollo ágil e iterativo: una guía para el gerente . Addison-Wesley. pag. 27. ISBN 978-0-13-111155-4.
- ^ Dyba, Tore; Dingsøyr, Torgeir (1 de agosto de 2008). "Estudios empíricos de desarrollo de software ágil: 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 .
- ^ Lee, Gwanhoo; Xia, Weidong (2010). "Hacia ágil: un análisis integrado de datos de campo cuantitativos y cualitativos sobre la agilidad del desarrollo de software". MIS Quarterly . 34 (1): 87-114. doi : 10.2307 / 20721416 . JSTOR 20721416 . S2CID 26477249 .
- ↑ Gerald M. Weinberg , citado en Larman & Basili 2003 , pp. 47-56 "Estábamos haciendo un desarrollo incremental ya en 1957 en Los Ángeles, bajo la dirección de Bernie Dimsdale en IBM's Service Bureau Corporation . Él era un colega de John von Neumann , así que tal vez lo aprendió allí, o lo asumió como totalmente natural. Recuerdo a Herb Jacobs (principalmente, aunque todos participamos) desarrollando una gran simulación para Motorola, donde la técnica utilizada fue, por lo que puedo decir ... Todos, hasta donde puedo recordar, pensamos 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 de la cascada hizo por nosotros fue hacernos darnos cuenta de que estábamos haciendo algo de lo contrario, algo sin nombre a excepción de 'desarrollo de software' ".
- ^ "Gestión de proyectos evolutivos (página original, archivo externo)" . Gilb. Archivado desde el original el 27 de marzo de 2016 . Consultado el 30 de abril de 2017 .
- ^ "Gestión Evolutiva de Proyectos (Nueva página)" . Gilb . Consultado el 30 de abril de 2017 .
- ^ Edmonds, EA (1974). "Un proceso para el desarrollo de software para usuarios no técnicos como un sistema adaptativo". Sistemas generales . 19 : 215-18.
- ^ Gilb, Tom (1 de abril de 1981). "Desarrollo evolutivo". Notas de ingeniería del software ACM SIGSOFT . 6 (2): 17. doi : 10.1145 / 1010865.1010868 . S2CID 33902347 .
- ^ Martin, James (1991). Desarrollo rápido de aplicaciones . Macmillan. ISBN 978-0-02-376775-3.
- ^ Kerr, James M .; Hunter, Richard (1993). Inside RAD: Cómo construir un sistema completamente funcional en 90 días o menos . McGraw-Hill. pag. 3. ISBN 978-0-07-034223-1.
- ^ Instituto Iacocca (1991). "Estrategia empresarial de fabricación del siglo XXI: una visión dirigida por la industria". Instituto Iacocca, Universidad de Lehigh, Bethlehem, PA.
- ^ Presley, A., J. Mills y D. Liles (1995). "Fabricación aeroespacial ágil". Nepcon East 1995, Boston.
- ^ Anderson, David (2005). "Declaración de interdependencia" . Archivado desde el original el 27 de enero de 2018 . Consultado el 4 de octubre de 2018 .
- ^ 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 .
- ^ "Examinando el Manifiesto Ágil" . Ambysoft Inc . Consultado el 6 de abril de 2011 .
- ^ Jim Highsmith (2001). "Historia: El Manifiesto Ágil" . agilemanifesto.org.
- ^ a b 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" . Alianza ágil. Archivado desde el original el 14 de junio de 2010 . Consultado el 6 de junio de 2010 .
- ^ Moran, A. (2014). Gestión ágil de riesgos . Springer Verlag. ISBN 978-3319050072.
- ^ Beck, Kent (1999). "Abrazar el cambio con una programación extrema". Computadora . 32 (10): 70–77. doi : 10.1109 / 2.796139 .
- ^ 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 .
- ^ Preuss, Deborah Hartmann (13 de octubre de 2006). "Estudio: equipos coubicados frente a la granja de cubículos" . InfoQ . Consultado el 23 de octubre de 2018 .
- ^ Cockburn, Alistair (2007). "Desarrollo de software ágil: el juego cooperativo" . www.pearson.com (2ª ed.). Addison-Wesley Professional . Consultado el 23 de octubre de 2018 .
- ^ 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 7th International Conference on Fiabilidad, Tecnologías de Infocom y Optimización (Tendencias y Direcciones Futuras) (ICRITO) . Noida, India: IEEE: 812–815. doi : 10.1109 / ICRITO.2018.8748529 . ISBN 978-1-5386-4692-2. S2CID 195775457 .
- ^ Cockburn, Alistair (19 de junio de 2008). "Radiador de información" .
- ^ Ambler, Scott (12 de abril de 2002). Modelado ágil: prácticas efectivas para la programación EXTREMA y el proceso unificado . John Wiley e hijos. págs. 12, 164, 363. ISBN 978-0-471-20282-0.
- ^ Vasiliauskas, Vidas (2014). "Desarrollo de prácticas ágiles de gestión de equipos y tareas de proyectos" . Eylean. Archivado desde el original el 15 de septiembre de 2014 . Consultado el 15 de septiembre de 2014 .
- ^ Jeffries, Ron; Anderson, Ann; Hendrickson, Chet (2001). Extreme Programming instalado . Addison-Weslsy. págs. 72-147 . ISBN 978-0201-70842-4.
- ^ Lisa Crispin; Janet Gregory (2009). Pruebas ágiles: una guía práctica para probadores y equipos ágiles . Addison-Wesley.
- ^ Mitchell, Ian (2016). Desarrollo ágil en la práctica . Casa Tamare. pag. 11. ISBN 978-1-908552-49-5.
- ^ Larman, Craig (2004). Desarrollo ágil e iterativo: una guía para el gerente . Addison-Wesley. pag. 27. ISBN 978-0-13-111155-4.
- ^ 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
- ^ Larman, Craig (2004). "Capítulo 11: Consejos prácticos" . Desarrollo ágil e iterativo: una guía para el gerente . pag. 253. ISBN 9780131111554. Consultado el 14 de octubre de 2013 .
- ^ Sliger, Michele; Broderick, Stacia (2008). El puente hacia la agilidad del gerente de proyectos de software . Addison-Wesley. pag. 46. ISBN 978-0-321-50275-9.
- ^ a b 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.
- ^ "Opinión de Paul Downey en Twitter" .
- ^ "En el Kickoff: desarrollo de proyectos vs desarrollo de productos" . AltexSoft Inc . 12 de febrero de 2016 . Consultado el 31 de mayo de 2016 .
- ^ Rakitin, Steven R. (2001). "Manifiesto provoca cinismo: carta del lector al editor por Steven R. Rakitin". Computadora IEEE . 34 (12): 4. doi : 10.1109 / MC.2001.10095 .
El artículo titulado 'Desarrollo de software ágil: el negocio de la innovación' ... es otro intento de socavar la disciplina de la ingeniería de software ... Queremos dedicar todo nuestro tiempo a codificar. Recuerde, los programadores reales no escriben documentación.
- ^ a b Scott Ambler. "Documentación ágil / ajustada: estrategias para el desarrollo de software ágil" .
- ^ Scott Ambler. "Modelos y documentos apenas lo suficientemente buenos: una mejor práctica ágil" .
- ^ Geoffrey Wiseman (18 de julio de 2007). "¿Los métodos ágiles requieren documentación?" . InfoQ. citando Cooper, Ian (6 de julio de 2007). "Señales Staccato: Ágil y Documentación" . WordPress.com .
- ^ a b c 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.
- ^ "Guía de prácticas ágiles" . la Alianza Ágil. Archivado desde el original el 9 de febrero de 2014.
- ^ a b Aydin, MN; Harmsen, F .; Slooten; Stagwee, RA (2004). "Un método ágil de desarrollo de sistemas de información en uso". Turk J Elec Engin . 12 (2): 127-138.
- ^ Morris, David (2015). La paradoja de la transformación ágil: por qué esforzarse demasiado por ser ágiles impide que las organizaciones se vuelvan verdaderamente ágiles . Nueva Zelanda: Universidad de Auckland. doi : 10.13140 / RG.2.2.32698.08640 .
- ^ Abrahamsson, P., Warsta, J., Siponen, MT y Ronkainen, J. (2003). Nuevas direcciones sobre métodos ágiles: un análisis comparativo. Actas de ICSE'03 , 244-254
- ^ 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 escrutinio de 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 .
- ^ Schwaber, K (2006) Scrum es duro y disruptivo.
- ^ Vodde, B (2016) La historia de LeSS. Discurso de clausura. Scrum Australia, Melbourne. Abril de 2016.
- ^ Lagstedt, A. y Dahlberg, T. (2018). Comprensión de la rareza de la selección del método ISD: racionalidad limitada y estupidez funcional. Actas de PACIS 2018. 154. https://aisel.aisnet.org/pacis2018/154 .
- ^ 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.
- ^ Beck, K. (1999). Explicación de la programación extrema: Acepte el cambio . Boston, MA: Addison-Wesley. ISBN 978-0-321-27865-4.
- ^ Evans, Ian. "Entrega ágil en British Telecom" . Consultado el 21 de febrero de 2011 .
- ^ a b W. Scott Ambler (2006) Supersize Me en Dr. Dobb's Journal, 15 de febrero de 2006.
- ^ Schaaf, RJ (2007). Agility XL Systems and Software Technology Conference 2007 Archivado el 13 de marzo de 2016 en Wayback Machine , Tampa, FL.
- ^ "Reduciendo la distancia" . Sdmagazine.com . Consultado el 1 de febrero de 2011 .
- ^ Fowler, Martin. "Utilización de un proceso de software ágil con desarrollo offshore" . Martinfowler.com . Consultado el 6 de junio de 2010 .
- ^ Leffingwell, decano. "Marco ágil escalado" . Marco ágil escalado .
- ^ Schwaber, Ken. "Guía Nexus: la guía definitiva de Nexus: el exoesqueleto del desarrollo Scrum escalado" (PDF) . scrum.org . Consultado el 14 de septiembre de 2015 .
- ^ Sutherland, Jeff; Brown, Alex (23 de julio de 2014). "Scrum a escala: Parte 1" . Consultado el 14 de septiembre de 2015 .
- ^ Beedle, Mike. "Enterprise Scrum" . Consultado el 25 de septiembre de 2015 .
- ^ Ebbage, Michael. "Setchu - Ágil a escala" . Consultado el 30 de septiembre de 2015 .
- ^ "Alianza XSCALE" . Alianza XSCALE . Consultado el 15 de octubre de 2020 .
- ^ "Agilepath - Collaborate.Innovate.Succeed" . Agile-path.com. 18 de enero de 2019 . Consultado el 26 de marzo de 2019 .
- ^ "Copia archivada" . Archivado desde el original el 28 de diciembre de 2018 . Consultado el 18 de septiembre de 2019 .Mantenimiento de CS1: copia archivada como título ( enlace )
- ^ Taller de Procesos Ágiles II Gestión de múltiples proyectos ágiles concurrentes. Washington: OOPSLA 2002
- ^ Cawley, Oisín; Wang, Xiaofeng; Richardson, Ita (2010). Abrahamsson, Pekka; Oza, Nilay (eds.). Metodologías de desarrollo de software ágiles y ajustadas en entornos regulados - Estado del arte . Software y sistemas empresariales ajustados . Apuntes de conferencias sobre procesamiento de información empresarial. 65 . págs. 31–36. doi : 10.1007 / 978-3-642-16416-3_4 . hdl : 10344/683 . ISBN 978-3-642-16415-6.
- ^ McHugh, Martin; McCaffery, Fergal; Coady, Garret (4 de noviembre de 2014). Mitasiunas, Antanas; Rout, Terry; O'Connor, Rory V .; et al. (eds.). Una implementación ágil dentro de una organización de software de dispositivos médicos . Mejora de procesos de software y determinación de capacidad . Comunicaciones en Informática y Ciencias de la Información. 477 . págs. 190–201. doi : 10.1007 / 978-3-319-13036-1_17 . ISBN 978-3-319-13035-4.
- ^ 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 del proceso de software centrado en el producto . Apuntes de conferencias en Ciencias de la Computación. 10611 . págs. 324–340. arXiv : 1703.05375 . Código bibliográfico : 2017arXiv170305375W . doi : 10.1007 / 978-3-319-69926-4_23 . ISBN 9783319699257. S2CID 4585465 .
- ^ "SafeScrum - SINTEF" . Sintef.no . Consultado el 26 de marzo de 2019 .
- ^ 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
- ^ 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 35 ° Congreso Internacional de Ingeniería de Software (ICSE) . págs. 863–872. doi : 10.1109 / ICSE.2013.6606635 . hdl : 10344/3055 . ISBN 978-1-4673-3076-3. S2CID 192403 .
- ^ Beck, Kent (2000). Explicación de la programación extrema . Addison-Wesley. págs. 1–24 . ISBN 978-0201616415.
- ^ Datta, Subhajit (2006). "Índice de medición de la agilidad: una métrica para la encrucijada de metodologías de desarrollo de software". ACM-SE 44 Actas de la 44ª conferencia regional anual del Sudeste . pag. 271. doi : 10.1145 / 1185448.1185509 . ISBN 1595933158.
- ^ "Weblog de David Bock: Weblog" . Jroller.com. Archivado desde el original el 11 de enero de 2006 . Consultado el 2 de abril de 2010 .
- ^ 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 .
- ^ Kurian, Tisni (2006). Métricas de agilidad: un enfoque cuantitativo basado en datos difusos para medir la agilidad de un proceso de software, ISAM-Proceedings of International Conference on Agile Manufacturing'06 (ICAM-2006) , Norfolk, EE. UU.
- ^ Joe Little (2 de diciembre de 2007). "Prueba de Nokia, una prueba específica de scrum" . Agileconsortium.blogspot.com . Consultado el 6 de junio de 2010 .
- ^ Mark Seuffert; Mayberg, Suecia. "Prueba de Karlskrona, una prueba de adopción ágil genérica" . Mayberg.se . Consultado el 5 de abril de 2014 .
- ^ "¿Qué tan ágil eres? (Toma esta prueba de 42 puntos)" . allaboutagile.com/. Archivado desde el original el 5 de mayo de 2014 . Consultado el 3 de abril de 2014 .
- ^ "Resultados de la encuesta de 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 ningún efecto o una reducción de costos ... El 93% afirmó que la productividad era mejor o significativamente mejor ... El 88% declaró que la calidad era mejor o significativamente mejor ... El 83% afirmó que la satisfacción empresarial era mejor o significativamente mejor
- ^ "Informe 2013 State of Agile: ¿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 .
- ^ Status Quo Agile , segundo estudio sobre el éxito y las formas de uso de métodos ágiles. Consultado el 1 de julio de 2015
- ^ Ambler, Scott (3 de agosto de 2006). "Encuesta dice: trabajos ágiles 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ó ningún cambio 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 informan mejoró la satisfacción, mientras que solo el 3% informa una reducción de la satisfacción
- ^ "Responder 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 .
- ^ Shore y Warden , 2008 , p. 47
- ^ Beck, Kent (2000). Explicación de la programación extrema . Addison-Wesley. págs. 48–49 . ISBN 978-0201616415.
- ^ Despierta, Margaret. "Definición de Sprint (desarrollo de software)" . searchsoftwarequality.techtarget.com . Consultado el 2 de octubre de 2015 .
- ^ Goldstein, Ilan (11 de octubre de 2011). "Problemas de sprint: cuando los sprints se convierten en rastreos" . www.axisagile.com.au . Consultado el 8 de junio de 2014 .
- ^ "Distribución de Roles y Responsabilidades del Proyecto" . agile-only.com . Consultado el 15 de junio de 2014 .
- ^ Bourne, Lynda. "¿Qué hace realmente un patrocinador de proyecto?" . blogs.pmi.org . Archivado desde el original el 7 de junio de 2014 . Consultado el 8 de junio de 2014 .
- ^ "Noveno Informe del Estado Ágil" . Etapa de encuesta ágil . VersionOne. Archivado desde el original el 12 de enero de 2015 . Consultado el 8 de junio de 2014 .
- ^ Sims, Chris; Johnson, Hillary Louise (15 de febrero de 2011). Los elementos de Scrum (Kindle ed.). Dymaxicon. pag. 73.
- ^ Rothman, Johanna Rothman (25 de agosto de 2011). "Cuando no tienes ningún propietario de producto" . www.jrothman.com . Consultado el 8 de junio de 2014 .
- ^ Fox, Alyssa (8 de abril de 2014). "Trabajando en múltiples equipos ágiles" . techwhirl.com/ . Consultado el 14 de junio de 2014 .
- ^ "Reunión diaria de Scrum" . www.mountaingoatsoftware.com . Consultado el 14 de junio de 2014 .
- ^ a b Mayo, Robert. "Planificación eficaz de Sprint" . www.agileexecutives.org . Archivado desde el original el 28 de junio 2014 . Consultado el 14 de junio de 2014 .
- ^ a b Berczuk, Steve. "Misión posible: ScrumMaster y colaborador técnico" . www.agileconnection.com . Consultado el 14 de junio de 2014 .
- ^ Namta, Rajneesh. "Reflexiones sobre la automatización de pruebas en Agile" . www.infoq.com . Consultado el 14 de junio de 2014 .
- ^ a b Band, Zvi (22 de marzo de 2014). "Deuda Técnica + Octubre Rojo" . Consultado el 8 de junio de 2014 .
- ^ Shore, James. "El arte del desarrollo ágil: refactorización" . www.jamesshore.com . Consultado el 14 de junio de 2014 .
- ^ "Paso 4: Planificación de Sprint (Tareas)" . www.allaboutagile.com . Archivado desde el original el 29 de junio de 2014 . Consultado el 14 de junio de 2014 .
- ^ 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 .
- ^ "Reunión de planificación de Sprint" . www.mountaingoatsoftware.com . Consultado el 14 de junio de 2014 .
- ^ McMillan, Keith. "Tiempo, Recursos, Alcance ... y Calidad" . www.adeptechllc.com . Consultado el 15 de junio de 2014 .
- ^ "Estudio actual sobre limitaciones de Agile" . Procedia Informática . 78 : 291-297. Enero de 2016. doi : 10.1016 / j.procs.2016.02.056 .
- ^ Moran, Alan (2015). Gestión ágil: estrategia, implementación, organización y personas . Saltador. ISBN 978-3-319-16262-1.
- ^ ExecutiveBrief, ¿Qué ciclo de vida es mejor para su proyecto? , PM Hut. Consultado el 23 de octubre de 2009.
- ^ "Gestión ágil de proyectos" . VersionOne . Consultado el 1 de junio de 2015 .
- ^ "¿Qué es la gestión ágil?" . Project Laneways . Consultado el 1 de junio de 2015 .
- ^ 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
- ^ Project Management Institute , A Guide to the Project Management Body of Knowledge (PMBOK Guide), Quinta edición
- ^ Richet, Jean-Loup (2013). Innovación ágil . Casos e investigación aplicada, n ° 31. ESSEC-ISIS. ISBN 978-2-36456-091-8
- ^ Smith, Preston G. (2007). Desarrollo de producto flexible . Jossey-Bass. pag. 25. ISBN 978-0-7879-9584-3.
- ^ Newton Lee (2014). "Subiendo a 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.
- ^ Moran, Alan (2015). Gestión ágil: estrategia, implementación, organización y personas . Springer Verlag. ISBN 978-3-319-16262-1.
- ^ "Programación ágil - para su familia" .
- ^ Larman, Craig; Bas Vodde (13 de agosto de 2009). Diez impedimentos organizativos principales para la adopción ágil a gran escala . InformIT.
- ^ "Introducción a la gestión de proyectos híbridos" . 20 de julio de 2016.
- ^ Barlow, Jordan B .; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). "Visió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 .
- ^ Kupersmith, Kupe. "Agile es una moda pasajera" .
- ^ a b Kruchten, Philippe (20 de junio de 2011). "¿Crisis adolescente de Agile?" . InfoQ.
- ^ Richard Utz, "Against Adminspeak", Crónica de la educación superior , 24 de junio de 2020.
- ^ Cohn, Mike (2015). Triunfar con Agile . Pearson. págs. 5–10. ISBN 978-0-321-57936-2.
Otras lecturas
- Abrahamsson, P .; Salo, O .; Ronkainen, J .; Warsta, J. (2002). "Métodos ágiles de desarrollo de software: revisión y análisis" . Publicaciones VTT. 478. Archivado desde el original el 7 de septiembre de 2011 . Consultado el 20 de febrero de 2012 .
- Ashmore, Sondra; Runyan, Kristin (2014). Introducción a los métodos ágiles . Addison-Wesley. ISBN 978-0321929563.
- Cohen, D .; Lindvall, M .; Costa, P. (2004). "Una introducción a los métodos ágiles" . En Zelkowitz, Marvin (ed.). Avances en Ingeniería de Software . Avances en informática. 62 . Prensa académica. págs. 1-66. ISBN 978-0-08-047190-7.
- Dingsøyr, Torgeir; Dyba, Tore; Moe, Nils Brede (2010). Desarrollo de software ágil: investigación actual y direcciones futuras . Saltador. ISBN 978-3-642-12575-1.
- Fowler, Martin (2001). "¿El diseño está muerto?" . En Succi, Giancarlo; Marchesi, Michele (eds.). Programación extrema examinada . Addison-Wesley. págs. 3-18 . ISBN 978-0-201-71040-3.
- Larman, Craig; Basili, Victor R. (junio de 2003). "Desarrollo iterativo e incremental: una breve historia". Computadora IEEE . 36 (3): 47–56. doi : 10.1109 / MC.2003.1204375 . S2CID 9240477 .
- Casagni, Michelle; Benito, Robert; Mayfield, Dra. Kathleen M .; Northern, Carlton (8 de septiembre de 2013). "Manual para la implementación ágil en la adquisición de tecnología de la información del Departamento de Defensa" . The Mitre Corporation . INGLETE.
- Moran, Alan (2015). Gestión ágil: estrategia, implementación, organización y personas . Saltador. ISBN 978-3-319-16262-1.
- Riehle, Dirk. "Una comparación de los sistemas de valor del desarrollo de software adaptativo y la programación extrema: cómo las metodologías pueden aprender unas de otras" .En Succi y Marchesi 2001
- Shore, James; Warden, Shane (2008). El arte del desarrollo ágil . O'Reilly Media. ISBN 978-0-596-52767-9.
- Stephens, M .; Rosenberg, D. (2003). Programación extrema refactorizada: el caso en contra de XP . Presione. ISBN 978-1-59059-096-6.
enlaces externos
- Manifiesto ágil
- Glosario ágil de la alianza ágil
- La nueva metodología : descripción de Martin Fowler de los antecedentes de los métodos ágiles
- AgilePatterns.org