En el desarrollo de software , las prácticas ágiles (a veces escritas " Ágiles ") [1] incluyen requisitos, descubrimiento y mejora de soluciones a través del esfuerzo colaborativo de equipos autoorganizados y multifuncionales con sus clientes / usuarios finales . [2] [3] Popularizados en el Manifiesto para el desarrollo de software ágil de 2001 , [4] estos valores y principios se derivaron de, y sustentan, una amplia gama de marcos de desarrollo de software , incluidos Scrum y Kanban . [5] [6]
Si bien hay mucha evidencia anecdótica de que la adopción de prácticas y valores ágiles mejora la efectividad de los profesionales, equipos y organizaciones del software, la evidencia empírica es mixta y difícil de encontrar. [7] [8] [9]
Los métodos de desarrollo de software iterativos e incrementales se remontan a 1957, [10] y la gestión de proyectos evolutivos [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 livianos evolucionaron como reacción a los métodos pesados prevalecientes (a menudo denominados colectivamente como cascada ) que los críticos describieron como excesivamente regulados, planificados y microgestionados . [15] Estos métodos ligeros incluían: 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), ambas de 1996; y desarrollo impulsado por características (FDD), de 1997. Aunque todos estos se originaron antes de la publicación del Manifiesto Ágil , ahora se los conoce colectivamente como métodos de desarrollo de software ágiles. [6]
Ya desde 1991 se habían producido cambios similares en la fabricación [18] [19] y en el pensamiento de gestión [20] derivados 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 livianos. Ellos fueron: Kent Beck (Programación extrema), Ward Cunningham (Programación extrema), Dave Thomas ( PragProg , 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 (PragProg, Ruby), Ron Jeffries (Programación extrema), Jon Kern, Brian Marick (Ruby, TDD ) y Steve Mellor ( OOA ). Juntos publicaron el Manifiesto para el desarrollo de software ágil . [4]
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 á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 ágil de software de acuerdo con la conducta y el dominio profesional .
En 2011, 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 prácticas de prácticas, términos y elementos ágiles, junto con interpretaciones y pautas de experiencia de la comunidad mundial de profesionales ágiles.
Basándose en su experiencia combinada en el desarrollo de software y en ayudar a otros a hacerlo, los autores del manifiesto declararon que valoraban: [4]
Es decir, si bien ambos lados tienen valor y los elementos de la derecha deben considerarse, los autores consideraron que los elementos de la izquierda deberían tener más influencia en cómo las personas abordan su trabajo.
Como explicó Scott Ambler : [23]
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 una antimetodología; de hecho, muchos de nosotros queremos devolver credibilidad a la palabra metodología. Queremos restablecer el equilibrio. Adoptamos 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 nunca mantenidos y rara vez utilizados. 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 [24]
El Manifiesto para el Desarrollo Ágil de Software se basa en doce principios: [25]
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 períodos 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] Es posible que una iteración no agregue suficiente funcionalidad para garantizar 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 con frecuencia y temprano " a lo largo de cada fase iterativa en lugar de hacerlo drásticamente en una fecha de lanzamiento final. [31] Es posible que se requieran múltiples iteraciones para lanzar un producto o nuevas funciones. El software funcional es la principal medida del progreso. [25]
Una ventaja clave de los enfoques ágiles es la velocidad de comercialización y la mitigación de riesgos. Por lo general, se lanzan al mercado incrementos más pequeños, lo que reduce los riesgos de tiempo y costos de diseñar un producto que no cumple con los requisitos del usuario.
El sexto principio del manifiesto ágil para el desarrollo de software establece: "El método más eficiente y eficaz de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara". El manifiesto, escrito en 2001, cuando las videoconferencias no se utilizaban ampliamente, afirma esto en relación con la comunicación de información, no necesariamente que un equipo deba compartir su ubicación.
El principio de coubicación es que los compañeros de trabajo del mismo equipo deben ubicarse 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, lo que reduce el tiempo del ciclo que normalmente se toma cuando las preguntas y respuestas se median a través del teléfono, chat persistente , wiki o 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 coubicación y el trabajo distribuido que muestran que la coubicació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 ). Las partes interesadas acuerdan que este representante actúe 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 miras 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 frecuente y la revisión al final de cada fase, es la razón por la que el enfoque a menudo se denomina metodología centrada en el cliente . [35]
En el desarrollo ágil de software, un radiador de información es una pantalla física (normalmente grande), un tablero con notas adhesivas o similar, ubicado en un lugar destacado 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 luminoso de construcción para informar a un equipo sobre el estado actual del desarrollo de su producto.
Una característica común en el desarrollo de software ágil es el stand-up diario (conocido como scrum diario en el marco de Scrum). En una sesión breve (por ejemplo, 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 utilizar preguntas codificadas simples (como qué completaron el día anterior, qué pretenden completar ese día y si hay algún impedimento o riesgo para avanzar), y retrasan las discusiones detalladas y los problemas. resolución hasta después del stand-up. [39]
Herramientas y técnicas específicas, como la integración continua , las pruebas unitarias automatizadas , la programación de pares , el desarrollo basado en pruebas , los patrones de diseño , el desarrollo basado en el comportamiento , el diseño basado en dominios , la refactorización de código y otras técnicas se utilizan a menudo para mejorar la calidad y potenciar el desarrollo de productos. agilidad. [40] Esto se basa en diseñar y construir calidad desde el principio y poder demostrar el software a los clientes en cualquier momento, o al menos al final de cada iteración. [41]
En comparación con la ingeniería de software tradicional, el desarrollo de software ágil se dirige principalmente al desarrollo de sistemas y productos complejos 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 profesionales ágiles utilizan su libre albedrío para reducir el " acto de fe " que se necesita antes de poder obtener cualquier evidencia de valor . [42] Los requisitos y el diseño se consideran 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 las 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. [43]
Los métodos de desarrollo existen en un continuo que va desde los adaptativos hasta los predictivos . [44] 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 ondulante para la planificación del cronograma, que identifica hitos pero deja flexibilidad en el camino para alcanzarlos y también permite que los propios hitos cambien. [45]
Los métodos adaptativos se centran en adaptarse rápidamente a realidades cambiantes. Cuando las necesidades de un proyecto cambian, un equipo adaptativo también cambia. Un equipo adaptativo tiene dificultades para describir exactamente lo que sucederá en el futuro. Cuanto más lejana esté una fecha, más vago será el método adaptativo sobre lo que sucederá en esa fecha. Un equipo adaptativo no puede informar exactamente qué tareas realizarán la próxima semana, sino solo qué funciones planean para el próximo mes. Cuando se les pregunta acerca de un lanzamiento dentro de seis meses, un equipo adaptativo podría informar solo la declaración de la misión del 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 tener en cuenta los riesgos conocidos. En casos extremos, un equipo predictivo puede informar exactamente qué características y tareas están planificadas durante todo el proceso de desarrollo. Los métodos predictivos se basan en un análisis eficaz de las primeras fases 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 asegurarse de considerar solo los cambios más valiosos.
El análisis de riesgos se puede utilizar para elegir entre métodos adaptativos ( ágiles o basados en valores ) y predictivos ( basados en planes ). [46] Barry Boehm y Richard Turner sugieren que cada lado del continuo tiene su propio terreno , de la siguiente manera: [47]
Una de las diferencias entre los métodos ágiles de desarrollo de software y los de cascada es el enfoque de la calidad y las pruebas. En el modelo en cascada , el trabajo avanza a través de las fases del ciclo de vida de desarrollo de software (SDLC), donde una fase se completa antes de que pueda comenzar otra; por lo tanto, la fase de prueba está separada y sigue a una fase de construcción . Sin embargo, en el desarrollo ágil de software, las pruebas se completan en la misma iteración que la programación.
Debido a 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 el valor. Una vez que los usuarios conozcan el valor real del software actualizado, podrán 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 planificar-hacer-verificar-actuar (PDCA), en el que el trabajo se planifica , se realiza , se verifica (en la revisión y en la retrospectiva) y se aplica cualquier cambio acordado .
Este enfoque iterativo respalda una mentalidad de producto más que 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 cambiarlos más adelante. El desarrollo iterativo de productos permite que el software evolucione en respuesta a los cambios en el entorno empresarial o los requisitos del mercado.
En una carta a IEEE Computer , Steven Rakitin expresó cinismo sobre el desarrollo ágil de software, calificándolo de " otro intento más de socavar la disciplina de la ingeniería de software " y traduciendo " software funcional a documentación integral " como " queremos pasar todo nuestro tiempo codificando". Recuerde, los programadores reales no escriben documentación ". [48]
Esto es cuestionado por los defensores del desarrollo ágil de software, 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 maneras de lograr esos objetivos que escribir documentación estática. [49] Scott Ambler afirma que la documentación debe ser "apenas lo suficientemente buena" (JBGE), [50] que demasiada documentación o documentación completa 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, [ 49] mientras que muy poca documentación también puede causar problemas de mantenimiento, comunicación, aprendizaje e intercambio de conocimientos. Alistair Cockburn escribió sobre el método Crystal Clear :
Crystal considera desarrollar una serie de juegos cooperativos y tiene la intención de que la documentación sea suficiente para ayudar a ganar 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, simplemente suficiente documentación para el próximo juego. Siempre tiendo a caracterizar esto a mi equipo como: ¿qué te gustaría saber si te unieras al equipo mañana?
- Alistair Cockburn [51]
Los métodos ágiles de desarrollo de software soportan 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). Algunas actividades de soporte 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:
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, procesos, calidad, etc. Algunas prácticas de desarrollo de software ágil notables incluyen: [ 53]
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 cual 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 [66]
La idoneidad de 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 basados en planes, donde los métodos ágiles permiten a los equipos de desarrollo de productos adaptar las prácticas de trabajo de acuerdo con las necesidades de los productos individuales. [67] [66] Potencialmente, la mayoría de los métodos ágiles podrían ser adecuados para la adaptación de métodos, [52] como DSDM adaptado en un contexto CMM . [68] y XP adaptados con la técnica de Prácticas de descripción de reglas (RDP). [69] Sin embargo, no todos los defensores ágiles están de acuerdo, y Schwaber señaló que "así es como nos metimos en problemas en primer lugar, pensando que el problema era no tener una metodología perfecta. Los esfuerzos [deberían] centrarse en los cambios [necesarios] en la empresa". [70] Bas Vodde reforzó este punto de vista, sugiriendo que a diferencia de las grandes metodologías tradicionales que requieren que usted elija elementos, Scrum proporciona los conceptos básicos sobre los cuales se agregan elementos adicionales para localizar y contextualizar su uso. [71] Los profesionales rara vez utilizan métodos de desarrollo de sistemas , o métodos ágiles específicamente, según las reglas, y a menudo optan por omitir o adaptar algunas de las prácticas de un método para crear un método interno. [72]
En la práctica, los métodos se pueden adaptar utilizando diversas herramientas. Los lenguajes genéricos de modelado de procesos, 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 a la ingeniería de métodos, como la Teoría de la esencia de la ingeniería de software de SEMAT . [73]
El desarrollo de software ágil se ha considerado ampliamente como muy adecuado para ciertos tipos de entornos, incluidos pequeños equipos de expertos que trabajan en proyectos nuevos , [47] [74] y los desafíos y limitaciones encontrados en la adopción de métodos de desarrollo de software ágiles en una organización grande. con infraestructura heredada están bien documentados y comprendidos. [75]
En respuesta, ha evolucionado una variedad de estrategias y patrones para superar los desafíos con esfuerzos de desarrollo a gran escala (>20 desarrolladores) [76] [77] o equipos de desarrollo distribuidos (no ubicados), [78] [79] entre otros desafíos. ; y ahora existen varios marcos reconocidos que buscan mitigar o evitar estos desafíos.
Hay 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 continua. [76] [80]
Cuando el desarrollo de software ágil se aplica en un entorno distribuido (con equipos dispersos en múltiples ubicaciones comerciales), comúnmente se lo denomina 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 de equipos estratégicamente en diferentes partes del mundo, creando software virtualmente las 24 horas del día (más comúnmente conocido como modelo de seguimiento del sol). Por otro lado, el desarrollo ágil proporciona mayor transparencia, retroalimentación continua y más flexibilidad al responder a los cambios.
Inicialmente se consideró que los métodos ágiles de desarrollo de software eran los más adecuados para el desarrollo de productos no críticos, por lo que se excluían de su uso en ámbitos regulados como los sectores de dispositivos médicos , farmacéutico, financiero, de sistemas nucleares, de automoción y de aviónica, etc. Desde hace años, ha habido varias iniciativas para la adaptación de métodos ágiles para estos dominios. [81] [82] [83] [84] [85]
Existen numerosos estándares que pueden aplicarse en dominios regulados, incluidos ISO 26262 , ISO 9000 , ISO 9001 e ISO/IEC 15504 . Una serie de preocupaciones clave son de particular importancia en los dominios regulados: [86]
Aunque los métodos ágiles de desarrollo de software 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 primeros en adoptar métodos ágiles solían ser equipos pequeños y medianos que trabajaban en sistemas sin precedentes con requisitos difíciles de finalizar y que probablemente cambiaran a medida que se desarrollaba el sistema. Esta sección describe los problemas comunes que encuentran las organizaciones cuando intentan adoptar métodos ágiles de desarrollo de software, así como diversas técnicas para medir la calidad y el desempeño de los equipos ágiles. [87]
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). [88] Otras técnicas se basan en objetivos mensurables [89] y un estudio sugiere que la velocidad se puede utilizar 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, [90] prueba de Karlskrona, [91] prueba de 42 puntos). [92]
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. [93]
Una encuesta similar, State of Agile , se lleva a cabo cada año 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 cada vez mayor de personas que afirman que el desarrollo ágil de software les ayuda a entregar software más rápido; mejora su capacidad para gestionar las prioridades cambiantes de los clientes; y aumenta su productividad. [94] Las encuestas también han mostrado consistentemente mejores resultados con métodos ágiles de desarrollo de productos en comparación con la gestión de proyectos clásica. [95] [96] En resumen, hay informes de que algunos consideran que los métodos de desarrollo ágiles aún son demasiado jóvenes para permitir una investigación académica exhaustiva sobre su éxito. [97]
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 los equipos se ven obligados a implementar un proceso ágil. [98] Estos a menudo se denominan antipatrones ágiles o, más comúnmente, olores ágiles . A continuación se muestran algunos ejemplos comunes:
Un objetivo del desarrollo de software ágil es centrarse más en producir software que funcione y menos en la documentación. Esto contrasta con los modelos en cascada, donde el proceso suele estar muy 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 por completo 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 requiera un trabajo importante a medida que intenta ampliar el sistema. Una de las características clave del desarrollo ágil de software es que es iterativo. Cuando se hace 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. [99]
En el desarrollo ágil de software, las historias (similares a las descripciones de casos de uso ) se suelen utilizar para definir requisitos y una iteración es un breve período de tiempo durante el cual el equipo se compromete con objetivos específicos. [100] Agregar historias a una iteración en progreso es perjudicial para un buen flujo de trabajo. Estos deben agregarse al trabajo pendiente del producto y priorizarse para una iteración posterior o, en casos excepcionales, la iteración podría cancelarse. [101]
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, se debe priorizar frente a todas las historias restantes, ya que la nueva información puede haber cambiado la prioridad original de la historia.
El desarrollo de software ágil a menudo se implementa 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 los patrocinadores, los equipos pueden enfrentar dificultades y resistencia por parte de los socios comerciales, otros equipos de desarrollo y la gerencia. Además, pueden sufrir sin la financiación y los recursos adecuados. [102] Esto aumenta la probabilidad de fracaso. [103]
Una encuesta realizada por VersionOne encontró que los encuestados citaron una capacitación insuficiente como la causa más importante de las implementaciones ágiles fallidas [104]. Los equipos han caído en la trampa de asumir procesos reducidos de desarrollo de software ágil en comparación con otros enfoques como el de cascada, lo que significa que no hay procesos reales. Reglas para el desarrollo ágil de software. [ cita necesaria ]
El propietario del producto es responsable de representar a la empresa en la actividad de desarrollo y, a menudo, es la función más exigente. [105]
Un error común es ocupar el puesto de propietario del producto con 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 mientras buscan dirección fuera del equipo. Esto a menudo conduce a distracciones y a una ruptura de la colaboración. [106]
El desarrollo de software ágil requiere que los equipos cumplan con los compromisos del producto, lo que significa que deben centrarse en trabajar únicamente para ese producto. Sin embargo, a menudo se espera que los miembros del equipo que parecen tener capacidad adicional asuman otro trabajo, lo que les dificulta ayudar a completar el trabajo al que se había comprometido su equipo. [107]
Los equipos pueden caer en la trampa de dedicar demasiado tiempo a preparar o planificar. Esta es una trampa común para los equipos menos familiarizados con el desarrollo ágil de software, donde 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 iteraciones posteriores (a menudo denominado refinamiento o preparación del trabajo pendiente).
Una reunión diaria debe ser una reunión enfocada y oportuna donde todos los miembros del equipo difundan información. Si se produce la resolución de problemas, a menudo puede involucrar sólo a ciertos miembros del equipo y potencialmente no es 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, se debe dejar de lado hasta que un subequipo pueda discutirlo, generalmente inmediatamente después de que se complete la reunión. [108]
Uno de los beneficios previstos del desarrollo ágil de software es capacitar al equipo para tomar decisiones, ya que son las más cercanas al 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 otros asignan tareas a los miembros del equipo o demasiado temprano en el proceso, se pueden perder los beneficios de la toma de decisiones localizada y oportuna. [109]
La asignación de trabajo también limita 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. [109] Los propios miembros del equipo pueden optar por asumir tareas que amplíen sus habilidades y brinden oportunidades de capacitación cruzada.
En el marco de Scrum, que pretende ser coherente con los valores y principios ágiles, el rol de scrum master es responsable de garantizar que se siga 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 el marco de Scrum no lo prohíbe, 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. [110]
Hacer que el scrum master también realice múltiples tareas 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 al avanzar las tareas individuales puede no superar los obstáculos que se posponen debido a la falta de capacidad. [111]
Debido a la naturaleza iterativa del desarrollo ágil, a menudo se necesitan varias 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. [112]
La automatización de pruebas también respalda 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.
Centrarse en ofrecer nuevas funciones puede resultar en un aumento de la deuda técnica . El equipo debe darse tiempo para corregir 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. [113]
A medida que el sistema evoluciona, es importante refactorizarlo . [114] Con el tiempo, la falta de mantenimiento constante provoca defectos y costos de desarrollo cada vez mayores. [113]
Un error común es creer que el desarrollo ágil de software permite un cambio continuo; sin embargo, un trabajo pendiente de iteración es un acuerdo sobre qué trabajo se puede completar durante una iteración. [115] Tener demasiado trabajo en progreso (WIP) da como resultado ineficiencias como el cambio de contexto y las colas. [116] El equipo debe evitar sentirse presionado a asumir trabajo adicional. [117]
El desarrollo de software ágil fija 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 ven apartados de las tareas para manejar incidentes de producción), mientras que el alcance sigue siendo variable. El cliente o propietario del producto a menudo exige un alcance fijo para una iteración. Sin embargo, los equipos deberían 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 para agregar alcance al tiempo y los recursos fijos del desarrollo de software ágil pueden resultar en una disminución de la calidad. [118]
Debido al ritmo centrado y la naturaleza continua de las prácticas ágiles, existe un mayor riesgo de agotamiento entre los miembros del equipo de entrega. [119]
La gestión ágil de proyectos es un proceso de desarrollo iterativo, donde se recopilan continuamente comentarios de los usuarios y partes interesadas para crear la experiencia de usuario adecuada. Se pueden utilizar diferentes métodos para realizar un proceso ágil, estos incluyen scrum , programación extrema , lean y kanban . [120] 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 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 . [121] Las métricas ágiles de gestión de proyectos ayudan a reducir la confusión, identificar puntos débiles y medir el desempeño 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, de modo que pueda adaptarse a la 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 para la agilidad estratégica es reconocer los cambios externos con suficiente antelación y asignar recursos para adaptarse a estos entornos cambiantes. [120]
Las técnicas Agile X también pueden denominarse gestión extrema de proyectos . Es una variante del ciclo de vida iterativo [122] donde los entregables se envían en etapas. La principal diferencia entre desarrollo ágil e iterativo es que los métodos ágiles completan pequeñas porciones de los entregables en cada ciclo de entrega (iteración), [123] mientras que los métodos iterativos evolucionan todo el conjunto 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 surgieron en formas más secuenciales de organización de proyectos. Por ejemplo, a medida que los proyectos de tecnología crecen en complejidad, los usuarios finales tienden a tener dificultades para definir los requisitos a largo plazo sin poder ver prototipos progresivos. Los proyectos que se desarrollan en iteraciones pueden recopilar comentarios constantemente para ayudar a perfeccionar esos requisitos.
La gestión ágil también ofrece un marco simple que promueve la comunicación y la reflexión sobre el trabajo anterior entre los miembros del equipo . [124] Los equipos que utilizaban la planificación en cascada tradicional y adoptaron la forma ágil de desarrollo generalmente pasan 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 coaching ágil: coaching ágil basado en push y coaching ágil basado en pull. En este caso, un "sistema de empuje" puede referirse a una estimación inicial de qué tareas se pueden incluir en un sprint (trabajo de empuje), por ejemplo, típico de scrum; mientras que un "sistema pull" puede referirse a un entorno donde las tareas sólo se realizan cuando hay trabajo disponible, por ejemplo, típico de kanban. [ se necesita aclaración ] También se han empleado y adaptado enfoques de gestión ágiles 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. [125]
Los métodos ágiles se mencionan en la Guía de conocimientos sobre gestión de proyectos ( Guía PMBOK, sexta edición ) bajo la definición del ciclo de vida de desarrollo de productos :
Dentro del ciclo de vida de un proyecto, generalmente hay una o más fases que están asociadas con el desarrollo del producto, servicio o resultado. A estos se les llama ciclo de vida de desarrollo (...) Los ciclos de vida adaptativos son ágiles, iterativos o incrementales. El alcance detallado se define y aprueba antes del inicio de una iteración. Los ciclos de vida adaptativos también se conocen como ciclos de vida ágiles o impulsados por cambios. [126]
Según Jean-Loup Richet (investigador del Instituto ESSEC de Innovación y Servicios Estratégicos) "este enfoque puede aprovecharse eficazmente para productos que no son software y para la gestión de proyectos en general, especialmente en áreas de innovación e incertidumbre". El resultado es un producto o proyecto que mejor satisface las necesidades actuales de los clientes y se entrega con costos, desperdicios y tiempo mínimos, lo que permite a las empresas lograr ganancias finales antes que a través de enfoques tradicionales. [127]
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 las tecnologías de objetos . [128] 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. [129] Los métodos ágiles de desarrollo de software 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 ágil de software también han encontrado aplicación en la gestión general [130] (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 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. [131]
Las prácticas ágiles han sido citadas como potencialmente ineficientes en grandes organizaciones y ciertos tipos de desarrollo. [132] Muchas organizaciones creen que las metodologías ágiles de desarrollo de software son demasiado extremas y adoptan un enfoque híbrido [133] que combina elementos de desarrollo ágil de software y enfoques basados en planes. [134] 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 pasajera de gestión que simplemente describe las buenas prácticas existentes bajo una nueva jerga, promueve una mentalidad única para todas las estrategias de desarrollo y enfatiza erróneamente el método sobre los resultados. [135]
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 participado en la reunión original y desde entonces. Se recopiló una lista de alrededor de 20 elefantes en la sala (temas/problemas ágiles 'no discutibles'), incluidos aspectos: las alianzas, fallas y limitaciones de las prácticas de desarrollo de software ágil y el contexto (posibles causas: intereses comerciales, descontextualización, falta de una forma obvia de progresar basándose en el fracaso, la evidencia objetiva limitada, los sesgos cognitivos y las falacias de razonamiento), la política y la cultura. [136] Como escribió Philippe Kruchten :
El movimiento ágil es en cierto modo un poco como un adolescente: muy consciente de sí mismo, controlando constantemente su apariencia en un espejo, aceptando pocas críticas, sólo interesado en estar con sus pares, rechazando en bloque toda sabiduría del pasado, simplemente porque es del pasado, adopta modas pasajeras y nuevas jergas, a veces engreídas y arrogantes. Pero no tengo dudas de que madurará más, se volverá más abierta al mundo exterior, más reflexiva y, por tanto, más eficaz.
—Philippe Kruchten [136]
El "Manifiesto" puede 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. [137]
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 aprenderla e implementarla 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 gestión ágil y un compromiso firme de todos los miembros de la organización para llevar a cabo el proceso. Cuestiones como resultados desiguales en toda la organización, demasiados cambios para la capacidad de los empleados para manejarlos o falta de garantías al final de la transformación son solo algunos ejemplos. [138]
{{cite web}}: CS1 maint: unfit URL (link)El artículo titulado 'Desarrollo de software ágil: el negocio de la innovación'... es otro intento más 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.
El 95% afirmó que no hubo ningún efecto o 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
Sólo 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 que una mayor satisfacción, mientras que sólo el 3% reporta una reducción de la satisfacción.
¿Qué es un equipo autoorganizado?
{{cite book}}: CS1 maint: location missing publisher (link)