El desarrollo ágil es un término derivado del Manifiesto Ágil, redactado en 2001 por un grupo formado por los creadores de Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) y Crystal; un representante del desarrollo basado en características; y varios otros líderes de opinión de la industria del software. El Manifiesto Ágil estableció un conjunto común de valores y principios generales para todas las metodologías ágiles del momento. En él se detallan cuatro valores fundamentales para conseguir equipos de alto rendimiento.

• Los individuos y sus interacciones
• Software operativo
• Colaboración con los clientes
• Responder al cambio

Estos valores fundamentales se apoyan en 12 principios, que puede consultar en el siguiente sitio web: Manifiesto para el desarrollo ágil de software.

Estos valores no son sólo algo que los creadores del Manifiesto Ágil pretendían ensalzar de boquilla y luego olvidar. Son valores que funcionan. Cada metodología ágil aborda estos valores de una forma ligeramente diferente, pero todas ellas tienen procesos y prácticas específicos que fomentan uno o más de estos valores.

Software operativo con documentación completa

El software de trabajo es una de las grandes diferencias que aporta el desarrollo ágil. Todas las metodologías ágiles representadas en el Manifiesto Ágil hacen hincapié en la entrega al cliente de pequeñas piezas de software funcional a intervalos determinados.

Todos los equipos ágiles deben establecer a qué se refieren cuando dicen "software funcional", lo que suele conocerse como la definición de hecho. A un alto nivel, una parte de la funcionalidad está completa sólo cuando sus características pasan todas las pruebas y pueden ser operadas por un usuario final. Como mínimo, los equipos deben ir más allá de las pruebas unitarias y probar el sistema. Los mejores equipos también incluyen pruebas de integración, pruebas de rendimiento y pruebas de aceptación del cliente en su definición de lo que significa haber completado una funcionalidad.

Una empresa CMMI de nivel 5 ha demostrado, a través de datos exhaustivos sobre muchos proyectos, que definir las pruebas de aceptación junto con la característica, implementar las características en serie y en orden de prioridad, ejecutar inmediatamente las pruebas de aceptación en cada característica y corregir cualquier error que se identifique como de máxima prioridad duplicará sistemáticamente la velocidad de producción y reducirá los defectos en un 40 por ciento. Y esto en una empresa que ya tiene una de las tasas de defectos más bajas del mundo.

El Manifiesto Ágil recomienda que los equipos entreguen software funcional a intervalos determinados. Acordar una definición de "hecho" es una de las formas prácticas que tienen los equipos ágiles de lograr el alto rendimiento y la alta calidad necesarios para alcanzar este objetivo.

Colaboración con el cliente por encima de la negociación de contratos

En las dos últimas décadas, los índices de éxito de los proyectos se han más que duplicado en todo el mundo. Esto se atribuye a proyectos más pequeños y entregas frecuentes, que permiten al cliente dar su opinión sobre el software en funcionamiento a intervalos regulares. Los redactores del manifiesto dieron en el clavo al subrayar que implicar al cliente en el proceso de desarrollo de software es esencial para el éxito.

Las metodologías ágiles fomentan este valor haciendo que un defensor del cliente trabaje mano a mano con el equipo de desarrollo. El primer equipo Scrum, por ejemplo, tenía miles de clientes. Como no era factible implicarlos a todos en el desarrollo del producto, seleccionaron a un apoderado del cliente, llamado propietario del producto, para que representara no sólo a todos los clientes sobre el terreno, sino también a la dirección, ventas, soporte, servicios al cliente y otras partes interesadas. El propietario del producto se encargaba de actualizar la lista de requisitos cada cuatro semanas a medida que el equipo lanzaba el software en funcionamiento, teniendo en cuenta la realidad actual y los comentarios de los clientes y las partes interesadas. De este modo, el cliente podía ayudar a dar forma al software que se estaba creando.

El primer equipo XP comenzó con un proyecto informático interno. Pudieron contar en su equipo con un usuario final de la empresa que trabajaba con ellos a diario. Aproximadamente el 10% de las veces, las consultorías y los equipos internos pueden encontrar un usuario final que trabaje con el equipo a diario. El otro 90% de las veces, deben nombrar a un apoderado. Este apoderado del cliente, al que los equipos de XP llaman cliente, trabaja con los usuarios finales para proporcionar una lista clara y priorizada de características que los desarrolladores deben implementar.

Colaborar a diario con el cliente (o su representante) es una de las razones clave por las que los datos del sector muestran que los proyectos ágiles tienen más del doble de éxito que los proyectos tradicionales de media mundial. Las metodologías ágiles lo reconocen y, por ello, han creado un lugar en sus equipos de desarrollo específico para el representante del cliente.

Responder al cambio en lugar de seguir un plan

Responder al cambio es esencial para crear un producto que satisfaga al cliente y aporte valor empresarial. Los datos del sector muestran que más del 60 por ciento de los requisitos de productos o proyectos cambian durante el desarrollo de software. Incluso cuando los proyectos tradicionales terminan a tiempo, dentro del presupuesto y con todas las características previstas, los clientes suelen estar descontentos porque lo que encuentran no es exactamente lo que querían. La "ley de Humphrey" dice que los clientes nunca saben lo que quieren hasta que ven el software en funcionamiento. Si los clientes no ven el software en funcionamiento hasta el final del proyecto, es demasiado tarde para incorporar sus comentarios. Las metodologías ágiles buscan la opinión del cliente a lo largo de todo el proyecto para poder incorporar sus comentarios y nueva información a medida que se desarrolla el producto.

Todas las metodologías ágiles llevan incorporados procesos para cambiar sus planes a intervalos regulares en función de los comentarios del cliente o de su representante. Sus planes están diseñados para ofrecer siempre primero el mayor valor empresarial. Como el 80% del valor está en el 20% de las características, los proyectos ágiles bien ejecutados tienden a terminar pronto, mientras que la mayoría de los proyectos tradicionales terminan tarde. Como resultado, los clientes están más contentos y los desarrolladores disfrutan más de su trabajo. Las metodologías ágiles se basan en el conocimiento de que, para tener éxito, deben planificar el cambio. Por eso han establecido procesos, como revisiones y retrospectivas, diseñados específicamente para cambiar las prioridades con regularidad en función de los comentarios de los clientes y el valor empresarial.

Agile es un paraguas: las metodologías son implementaciones

El desarrollo ágil no es una metodología en sí misma. Es un término paraguas que describe varias metodologías ágiles. Cuando se firmó el Manifiesto Ágil en 2001, estas metodologías incluían Scrum, XP, Crystal, FDD y DSDM. Desde entonces, las prácticas Lean también han surgido como una valiosa metodología ágil, por lo que se incluyen bajo el paraguas del desarrollo ágil en la ilustración que aparece más adelante en este tema.

Cada metodología ágil tiene un enfoque ligeramente distinto para poner en práctica los valores fundamentales del Manifiesto Ágil, del mismo modo que muchos lenguajes informáticos manifiestan las características fundamentales de la programación orientada a objetos de formas diferentes. Una encuesta reciente muestra que alrededor del 50% de los profesionales ágiles afirman que su equipo está haciendo Scrum. Otro 20% dice que está haciendo Scrum con componentes XP. Un 12 por ciento adicional dice que está haciendo XP solo. Debido a que más del 80 por ciento de las implementaciones ágiles en todo el mundo son Scrum o XP, MSF for Agile Software Development v5.0 se centra en los procesos y prácticas centrales de Scrum y XP.

Scrum es un marco para procesos de desarrollo ágiles. No incluye prácticas de ingeniería específicas. A la inversa, XP se centra en prácticas de ingeniería pero no incluye un marco general de procesos de desarrollo. Esto no significa que Scrum no recomiende ciertas prácticas de ingeniería o que XP no tenga procesos. Por ejemplo, el primer Scrum implementó todas las prácticas de ingeniería que ahora se conocen como XP. Sin embargo, el marco de Scrum para el desarrollo de software se diseñó para que un equipo empezara en dos o tres días, mientras que las prácticas de ingeniería suelen tardar muchos meses en implementarse. Por lo tanto, dejaba en manos de cada equipo la cuestión de cuándo (y si) aplicar prácticas específicas. Jeff Sutherland y Ken Schwaber, cocreadores de Scrum, recomiendan que los equipos de Scrum se pongan en marcha de inmediato y elaboren una lista de impedimentos y un plan de mejora del proceso. A medida que las prácticas de ingeniería se identifican como impedimentos, los equipos deben buscar en las prácticas de XP una forma de mejorar. Los mejores equipos aplican Scrum complementado con prácticas XP. Scrum ayuda a XP a escalar, y XP ayuda a Scrum a funcionar bien.