Software agil

Contextualización del desarrollo de software ágil

Philippe Kruchten

Departamento de Ingeniería Eléctrica e Informática, Universidad de Columbia Británica, Vancouver, BC, Canadá

Resumen

Este documento presenta un modelo contextual para el desarrollo de sistemas intensivos en software para guiar la adopción y adaptación de prácticas ágiles de desarrollo de software. Este modelo se encontró especialmente útil cuando el contexto del proyecto se aparta significativamente del "punto dulce ágil", es decir, de las condiciones ideales en las que se originaron las prácticas ágiles de desarrollo de software, y donde son más propensos a tener éxito, "de fábrica ". Este es el caso de los grandes sistemas, el entorno de desarrollo distribuido, los sistemas críticos para la seguridad, la re- quiring de un sistema de arquitectura novedosa, o los sistemas con un modelo de negocio poco ortodoxo o modelo de gobierno.

1. Introducción

1. Agilidad definida

Basándonos en definiciones anteriores de Jim Highsmith [1] o de Steve Adolph y el bucle OODA [2], definimos la agilidad como "la capacidad de una organización para reaccionar a los cambios en su entorno más rápido que la velocidad de estos cambios". Esta definición utiliza el propósito o la función final de ser ágil para un negocio, en lugar de definir la agilidad mediante un conjunto etiquetado de prácticas (por ejemplo, eres ágil cuando haces XP [3], Lean [4-6] o Scrum [7-9]) o por un conjunto de propiedades definidas en oposición a otro conjunto: el enfoque de manifiesto ágil [10]. Esta definición no está muy lejos de la de Kieran Conboy llegó en su encuesta de literatura de desarrollo de procesos ágiles [11]. Una analogía podría ser la definición de un camino. ¿Definiría una carretera como algo hecho de rocas trituradas y alquitrán, o la definiría como una superficie que es negra en lugar de blanca, plana en lugar de ondulada, y con líneas pintadas en lugar de monocromática? ¿O prefiere definir una carretera como un componente de un sistema de transporte, permitiendo mover personas y mercancías en la superficie del suelo desde el punto B hasta el punto B? Y luego dejar que las propiedades o componentes de la carretera se deriven de esta definición funcional, permitiendo algunos enfoques novedosos en el diseño de la carretera, en lugar de definirlo de forma estrecha utilizando una receta común.

Tenga en cuenta también que es muy posible adoptar un conjunto etiquetado de prácticas ágiles: Crystal [12], SCRUM, FDD [13], DSDM [14,15], o un conjunto de prácticas que se ajusten perfectamente al manifiesto ágil [10] y no se vuelvan ágiles. Entonces "harías ágil", pero no eres ágil. *Correspondencia a: Philippe Kruchten, Departamento de Ingeniería Eléctrica e Informática, Universidad de Columbia Británica, Vancouver, BC, Canadá. "E-mail: pbkGece.ubc.ca Copyright O 2011 John Wiley € Sons, Ltd.

1.2 Los éxitos de los métodos ágiles

Los métodos de desarrollo de software ágiles sin duda tienen éxito en contextos que son idénticos o muy similares a los contextos en los que se han creado inicialmente. Como estos contextos, el "punto dulce ágil" [l6], son muy frecuentes en el desarrollo de software, lo que representa más del 70% de todo el software que se está desarrollando, esto puede haber llevado a veces a sus proponentes a una cierta complacencia: pensando que su método tiene valor, que representa una receta definitiva, el santo grial de la ingeniería de software.

Los métodos ágiles pueden fallar de varias maneras cuando se aplican "fuera de la caja", es decir, sin ninguna o poca adaptación, en contextos que están muy lejos, al menos en alguna dimensión, del contexto en el que se han creado originalmente. En lugar de un análisis de la causa raíz, esto generalmente desencadena gritos de "no debe haber hecho bien" por sus proponentes. Y esto de nuevo conduce a discusiones de "pureza", "scrumbuts", y así sucesivamente [39]. Los métodos ágiles se pueden estirar con un éxito variable fuera del contexto en el que se han creado; por ejemplo, escalarlos a proyectos más grandes o entre equipos distribuidos. En nuestra experiencia, los factores contextuales que tienen mayores riesgos de descarrilar proyectos ágiles son:

• Tamaño
• Grandes sistemas con falta de enfoque
• Desarrollo de software no impulsado por la demanda de los clientes
• La falta de apoyo de las partes interesadas circundantes, la gobernanza tradicional
• Equipo novato
• Restricción muy alta en algún atributo de calidad (sistema crítico para la seguridad, restricciones en tiempo real).

Como señalaron muchos autores en los últimos años [17,18], no podemos depender simplemente de los actos de fe de los gurús del proceso elocuente para ayudarnos a definir el proceso adecuado, o conjunto de prácticas fuera del punto dulce ágil. Se requiere una investigación imparcial y con cabeza fría. Esta investigación generalmente no es muy fácil de llevar a cabo; a menudo es cualitativo, más que cuantitativo, se extrae más de las ciencias sociales que de la informática, no es fácil de publicar, no es fácil tallar hasta el tamaño de la mordedura de la tesis de los maestros.

1.3. Visión general de este documento

En este artículo, a partir de nuestra experiencia en Rational Software y, posteriormente, en KESL en consultoría de compromisos con varias organizaciones que han intentado realizar la transición a métodos ágiles de desarrollo de software, presentamos un marco o modelo contextual para situar prácticas ágiles. Definimos varios factores que caracterizan el contexto de desarrollo de software, que afectan significativamente a la adopción de métodos ágiles, especialmente cuando los proyectos están fuera del "punto dulce ágil" en el que se han definido estos métodos y en los que operan en Mejor. Describimos cuatro organizaciones que están desarrollando software fuera de este "punto dulce" y se han cometido con dificultades aplicando métodos ágiles de desarrollo de software "fuera de la caja". Comparamos nuestro modelo con otras propuestas similares. El propósito final de este trabajo, sin embargo, es proporcionar medios para que las organizaciones configuren rápidamente su método, proporcionando orientación sobre qué práctica ágil utilizar en qué circunstancias.

...