Las metodologías ágiles Reid Holmes Traducción: Jorge Pincay Ponce Las metodologías ágiles surgieron a principios de la década de 2000 como una respuesta directa a metodologías de desarrollo más tradicionales, en procura de ajustar el ciclo de retroalimentación entre el equipo de desarrollo y los clientes, al tiempo de permitir a los desarrolladores ser más flexibles y lograr un mayor desarrollo de software en menor tiempo. Uno de los documentos centrales que surgió como parte de la revolución de la metodología ágil es el conocido como manifiesto ágil, mismo que tiene 12 principios claves, pero creo que son cuatro de ellos los que realmente ilustran la intención del documento. Así que hablemos de ellos ahora mismo. El primero es favorecer las interacciones individuales sobre los procesos y las herramientas, esto se trata realmente de valorar a las partes interesadas que están involucradas en el proceso de desarrollo de software. El siguiente es favorecer el software en funcionamiento por sobre una extensa documentación. En enfoques ágiles, como tema común veremos que el software siempre debe ser compilable y ejecutable. A continuación, está el favorecer las interacciones con los clientes por sobre las negociaciones de contrato. En esto realmente se busca atraer al cliente al equipo de desarrollo para que podamos recibir comentarios de ellos y responder a estos de manera rápida y efectiva. Y finalmente queremos favorecer la agilidad sobre la planificación, que de lo que trata es de ser flexible a los tipos de comentarios que esos clientes te están dando y respondiendo mediante la construcción de un producto que refleje con mayor precisión sus necesidades y deseos. Estos principios fueron desarrollados para aumentar la responsabilidad del cliente dentro del equipo de desarrollo, involucrarlos y hacerlos participar en el proceso de desarrollo; lo que implica que como desarrolladores seamos capaces de responder a sus necesidades y mantenerlos al tanto de lo que está pasando a medida que el producto se desarrolla. Otro aspecto sobre metodologías ágiles es que aumentan la velocidad de desarrollo al disminuir la cantidad de tiempo que los equipos de desarrollo gastan construyendo lo posiblemente incorrecto. Esto también permite que los equipos de desarrollo experimenten más probando diferentes alternativas de diseño y descubriendo cuáles funcionan mejor para el cliente. Por lo tanto, les da a los desarrolladores un poco más de flexibilidad para probar diferentes cosas y ver cómo funcionan en la práctica. La programación extrema, o XP, fue una de las primeras metodologías ágiles más influyentes, la programación extrema consistía en tener un sistema facturable en todo momento. En ella el equipo de desarrollo comenzaría siendo muy pequeño y crecería lentamente de acuerdo con el sistema a lo largo del tiempo en respuesta a los comentarios de los clientes. Y esto está en contraste con los enfoques más tradicionales donde comenzamos por adelantado con un gran esfuerzo de planificación construyendo nuestros sistemas de arriba hacia abajo. En XP se comienza en la parte inferior y se construyen sistemas de abajo hacia arriba.
1
Los sistemas que están construidos con XP siguen cinco principios claves. El primero es la comunicación, es que cuando pensamos en la comunicación, queremos que sea para que los desarrolladores puedan obtener comentarios de los clientes lo más rápido posible y que los clientes también tengan acceso al equipo de desarrollo. Luego, los proyectos basados en XP a menudo favorecen la solución más simple posible en lugar de diseñar grandes soluciones complicadas, ¿queremos construir una solución simple?, pruébalo con los clientes y mira si funciona, porque si lo hace, es genial, es lo suficientemente buena. Luego podemos avanzar hacia otras tareas de desarrollo. Lo siguiente es la retroalimentación, donde queremos alentar a los clientes y a los desarrolladores para hablar el uno con el otro con la expectativa de que una vez que el equipo de desarrollo recibe comentarios del cliente, tratarán de actuar en consecuencia, pero también que el equipo de desarrollo puede presionar al cliente y dejar que ellos sepan cuando sus comentarios no van a funcionar o van a ser realmente abrumadores o costosos. Por tanto, esta retroalimentación funciona en ambos sentidos. Tanto del cliente al desarrollador, como del equipo de desarrollo a los clientes. A continuación, tenemos el coraje, lo que puede parecer extraño en principio, pero se trata de empoderar al equipo de desarrollo para probar diferentes experimentos y obtener retroalimentación por parte de los clientes para ver si tales experimentos mejoran el producto. Si no lo hacen, podemos descartarlos ahora, pero valorándolos como una oportunidad para aprender sobre el sistema, para hacerlo mejor. Y finalmente tenemos el respeto, lo cual trata de respetar todas las opiniones de los interesados y su tiempo. La forma más obvia de codificar esto en XP es este apodo "no rompa la cuenta". Así, cuando los desarrolladores ingresan código en el repositorio existe la expectativa de que el código que han construido siempre funcione, que no rompa las cuentas y que el resto del equipo de desarrollo no se ralentiza. Todo esto vuelve a una de las ideas centrales de XP, que se trata de tener siempre un sistema facturable. Todos los proyectos basados en XP siguen estos cinco principios claves.
2