Desarrollo ágil de software

El manifiesto para el desarrollo ágil de software dice: ^{[ 2 ]}

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

• Los individuos y las interacciones por encima de los procesos y las herramientas.
• Software funcional por encima de una documentación exhaustiva
• Colaboración con el cliente en la negociación de contratos
• Responder al cambio en lugar de seguir un plan.

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

Scott Ambler explicó: ^{[ 23 ]}

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

Al presentar el manifiesto en nombre de la Alianza Ágil, Jim Highsmith dijo:

El movimiento Agile no es antimetodología; de hecho, muchos queremos devolverle credibilidad al término. Buscamos un equilibrio. Adoptamos el modelado, pero no para archivar diagramas en un repositorio corporativo polvoriento. Adoptamos la documentación, pero no cientos de páginas de tomos que nunca se actualizan y rara vez se usan. Planificamos, pero reconocemos las limitaciones de la planificación en un entorno turbulento. Quienes tachan de "hackers" a los defensores de XP, SCRUM o cualquier otra metodología Agile desconocen tanto las metodologías como la definición original del término.

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

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

La mayoría de los métodos de desarrollo ágil dividen el trabajo de desarrollo de productos en pequeños incrementos que minimizan la cantidad de planificación y diseño iniciales. Las iteraciones, o sprints, son períodos de tiempo cortos ( timeboxes ) ^{[ 26 ]} que suelen durar de una a cuatro semanas. ^{[ 27 ] : 20} Cada iteración involucra 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. ^{[ 28 ] [ 29 ]} Una iteración puede no agregar suficiente funcionalidad como para justificar un lanzamiento al mercado, pero el objetivo es tener un lanzamiento disponible (con mínimos errores ) al final de cada iteración. ^{[ 30 ]} A través del desarrollo incremental, los productos tienen espacio para " fallar a menudo y temprano " a lo largo de cada fase iterativa en lugar de drásticamente en una fecha de lanzamiento final. ^{[ 31 ]} Es posible que se requieran múltiples iteraciones para lanzar un producto o nuevas funciones. El software funcional es la principal medida de progreso. ^{[ 25 ]}

El sexto principio del manifiesto ágil para el desarrollo de software afirma: «El método más eficiente y eficaz para transmitir información a un equipo de desarrollo y dentro del mismo es la conversación cara a cara». El manifiesto, redactado en 2001, cuando las videoconferencias no estaban muy extendidas, se refiere a la comunicación de información, no necesariamente a que un equipo deba estar ubicado en el mismo lugar.

El principio de la coubicación es que los compañeros de trabajo del mismo equipo deben estar ubicados 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 de ciclo que normalmente se toma cuando las preguntas y respuestas se median a través del teléfono, el chat persistente , la wiki o el correo electrónico. ^{[ 33 ]} Con la adopción generalizada del trabajo remoto durante la pandemia de COVID-19 y los cambios en las herramientas, se han realizado más estudios ^{[ 34 ]} sobre la 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 ). Este representante es acordado por las partes interesadas para actuar en su nombre y se compromete personalmente a estar disponible para que los desarrolladores respondan a sus 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 el fin de 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 mediante la interacción frecuente y la revisión al final de cada fase, es la razón por la que este enfoque se suele denominar metodología centrada en el cliente . ^{[ 35 ]}

Una característica común en el desarrollo ágil de software es la reunión diaria de pie (conocida como Daily Scrum en el marco de Scrum). En una breve sesión (por ejemplo, 15 minutos), los miembros del equipo revisan colectivamente su progreso hacia el objetivo y deciden si necesitan adaptar su enfoque. Para ajustarse al límite de tiempo acordado, los equipos suelen utilizar preguntas sencillas predefinidas (como qué completaron el día anterior, qué pretenden completar ese día y si existen impedimentos o riesgos para el progreso), y posponen las discusiones detalladas y la resolución de problemas hasta después de la reunión diaria de pie. ^{[ 38 ]}

A menudo se utilizan herramientas y técnicas específicas, como la integración continua , las pruebas unitarias automatizadas , la programación en parejas , el desarrollo guiado por pruebas , los patrones de diseño , el desarrollo guiado por el comportamiento , el diseño guiado por el dominio , la refactorización de código y otras técnicas para mejorar la calidad y aumentar la agilidad del desarrollo de productos. ^{[ 39 ]} Esto se basa en diseñar e incorporar 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. ^{[ 40 ]}

Los métodos de desarrollo existen en un continuo que va desde lo adaptativo hasta lo predictivo . ^{[ 43 ]} Los métodos de desarrollo de software ágil se sitúan en el lado adaptativo de este continuo. Una clave de los métodos de desarrollo adaptativo es un enfoque de onda rodante 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. ^{[ 44 ]}

Los métodos adaptativos se centran en adaptarse rápidamente a las realidades cambiantes. Cuando cambian las necesidades de un proyecto, un equipo adaptativo también cambia. Un equipo adaptativo tiene dificultades para describir con exactitud lo que sucederá en el futuro. Cuanto más lejana sea una fecha, más vago será el método adaptativo respecto a lo que ocurrirá en esa fecha. Un equipo adaptativo no puede informar con precisión qué tareas realizará la próxima semana, sino solo qué funcionalidades planea para el próximo mes. Si se le pregunta sobre un lanzamiento dentro de seis meses, un equipo adaptativo podría informar únicamente la declaración de misión del lanzamiento o una declaración del valor esperado en relación con el costo.

Los métodos predictivos , en cambio, se centran en analizar y planificar el futuro en detalle y contemplan los riesgos conocidos. En casos extremos, un equipo predictivo puede informar con precisión sobre las características y tareas planificadas para todo el proceso de desarrollo. Estos métodos dependen de un análisis eficaz en las primeras fases, y si este análisis falla gravemente, el proyecto podría tener dificultades para cambiar de rumbo. Los equipos predictivos suelen establecer un comité de control de cambios para garantizar que solo se consideren las modificaciones más valiosas.

El análisis de riesgos puede utilizarse para elegir entre métodos adaptativos ( ágiles o impulsados ​​por el valor ) y predictivos ( impulsados ​​por la planificación ). ^{[ 45 ]} Barry Boehm y Richard Turner sugieren que cada extremo del continuo tiene su propio terreno , como sigue: ^{[ 46 ]}

Una de las diferencias entre los métodos de desarrollo de software ágil y el modelo en cascada radica en 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 del desarrollo de software (SDLC), donde una fase se completa antes de que pueda comenzar la siguiente; por lo tanto, la fase de pruebas es independiente y sigue a la fase de compilación . En cambio, en el desarrollo de software ágil, las pruebas se completan en la misma iteración que la programación.

Dado que las pruebas se realizan en cada iteración —que desarrolla una pequeña parte del software—, los usuarios pueden utilizar con frecuencia esas nuevas partes del software y validar su valor. Una vez que los usuarios conocen el valor real de la parte actualizada del software, pueden tomar mejores decisiones sobre su futuro. Contar con una retrospectiva de valor y una sesión de replanificación del software en cada iteración —Scrum suele tener 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 la retrospectiva) y se implementan los cambios acordados .

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

En una carta a IEEE Computer , Steven Rakitin expresó su cinismo sobre el desarrollo ágil de software, calificándolo como "otro intento más de socavar la disciplina de la ingeniería de software" y traduciendo "software funcional por encima de documentación exhaustiva" como "queremos pasar todo nuestro tiempo programando. Recuerden, los verdaderos programadores no escriben documentación". ^{[ 47 ]}

Esto es refutado 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. ^{[ 48 ]} Scott Ambler afirma que la documentación debería ser "apenas suficiente" (JBGE), ^{[ 49 ]} que demasiada documentación o documentación exhaustiva 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, ^{[ 48 ]} 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 pretende que la documentación sea suficiente para ayudar al siguiente a ganar en el siguiente juego. Los productos de trabajo para Crystal incluyen casos de uso, lista de riesgos, plan de iteración, modelos de dominio principales y notas de diseño para fundamentar las decisiones... sin embargo, no hay plantillas para estos documentos y las descripciones son necesariamente vagas, pero el objetivo es claro: la documentación suficiente para el siguiente juego. Siempre tiendo a explicar esto a mi equipo de la siguiente manera: ¿qué querrías saber si te unieras al equipo mañana?

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

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 de métodos se define como:

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

La adecuación a la situación debe considerarse una característica distintiva entre los métodos ágiles y los métodos de desarrollo de software más orientados a la planificación, ya que los métodos ágiles permiten a los equipos de desarrollo de productos adaptar las prácticas de trabajo según las necesidades de cada producto. ^{[ 71 ] [ 70 ]} Potencialmente, la mayoría de los métodos ágiles podrían ser adecuados para la adaptación de métodos, ^{[ 51 ]} como DSDM adaptado en un contexto CMM . ^{[ 72 ]} y XP adaptado con la técnica de Prácticas de Descripción de Reglas (RDP). ^{[ 73 ]} Sin embargo, no todos los defensores de la metodología ágil están de acuerdo, como señala Schwaber: «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». ^{[ 74 ]} Bas Vodde reforzó este punto de vista, sugiriendo que, a diferencia de las metodologías tradicionales y extensas que requieren seleccionar elementos, Scrum proporciona los fundamentos sobre los cuales se agregan elementos adicionales para localizar y contextualizar su uso. ^{[ 75 ]} Los profesionales rara vez utilizan los métodos de desarrollo de sistemas , o los métodos ágiles específicamente, al pie de la letra, optando a menudo por omitir o adaptar algunas de las prácticas de un método para crear un método propio. ^{[ 76 ]}

En la práctica, los métodos pueden adaptarse utilizando diversas herramientas. Los lenguajes genéricos de modelado de procesos, como el Lenguaje Unificado de Modelado (UML), pueden utilizarse para adaptar los métodos de desarrollo de software. Sin embargo, también existen herramientas específicas para la ingeniería de métodos, como la Teoría Esencial de la Ingeniería de Software de SEMAT . ^{[ 77 ]}

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

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

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

Cuando el desarrollo ágil de software se aplica en un entorno distribuido (con equipos dispersos en múltiples ubicaciones), se suele denominar desarrollo ágil de software distribuido . El objetivo es aprovechar las ventajas únicas que ofrece cada enfoque. El desarrollo distribuido permite a las organizaciones crear software mediante la creación estratégica de equipos en diferentes partes del mundo, desarrollando software prácticamente las 24 horas del día (modelo conocido como "seguir al sol"). Por otro lado, el desarrollo ágil proporciona mayor transparencia, retroalimentación continua y más flexibilidad para responder a los cambios.

Inicialmente, se consideró que los métodos de desarrollo de software ágil eran 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 de dispositivos médicos , farmacéutico, financiero, sistemas nucleares, automoción y aviónica, entre otros. Sin embargo, en los últimos años, se han llevado a cabo varias iniciativas para la adaptación de los métodos ágiles a estos ámbitos. ^{[ 85 ] [ 86 ] [ 87 ] [ 88 ] [ 89 ]}

Existen numerosos estándares que pueden aplicarse en dominios regulados, entre ellos ISO 26262 , ISO 9000 , ISO 9001 e ISO/IEC 15504. Una serie de aspectos clave revisten especial importancia en los dominios regulados: ^{[ 90 ]}

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

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

Según Jean-Loup Richet (investigador del Instituto ESSEC para la Innovación Estratégica y los Servicios), «este enfoque puede aprovecharse eficazmente para productos que no son de software y para la gestión de proyectos en general, especialmente en áreas de innovación e incertidumbre». El resultado es un producto o proyecto que satisface mejor las necesidades actuales del cliente y se entrega con costes, desperdicios y tiempo mínimos, lo que permite a las empresas obtener beneficios antes que con los enfoques tradicionales. ^{[ 132 ]}

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

Los paradigmas de desarrollo de software ágil pueden utilizarse en otros ámbitos 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. ^{[ 137 ]}