El desarrollo Ágil de software comenzó para atender la problemática humana del desarrollo de software. Es que, en el fondo, el gran asunto en los procesos de desarrollo son siempre las personas que participan de él.
Y, al igual que con las relaciones humanas, a veces basta con hacer un pequeño cambio interno para entrar en un ciclo positivo de sorpresas y mejoras.
Consecuencias, consecuencias
Sin profundizar mucho, se podría resumir la mayoría de los métodos ágiles con estos puntos básicos:
- Iterar en pequeños ciclos.
- Obtener feedback frecuente (idealmente, teniendo al equipo y al cliente en el mismo lugar).
- Entregar después de cada iteración (cuándo sea posible).
- Sólo trabajar en la cosa más importante en un momento dado.
- Construir la calidad desde adentro.
- No trabajar en "fases" (análisis, diseño, codificación, testing)
Es una lista corta y sencilla. Pero de esta pequeña lista surgen infinidad de obstáculos, temas y consecuencias. De hecho, son demasiados para analizarlos a todos. Un resumen de estos temas podría ser:
- No podemos ir rápido a menos que construyamos la calidad desde adentro.
- No podemos construir calidad desde adentro a menos que podamos testear rápidamente.
- No podemos testear rápidamente si no podemos desarrollar rápidamente.
- No podemos testear rápidamente si no separamos los distintos tipos de pruebas.
- No podemos testear rápidamente si las pruebas son manuales.
- No podemos automatizar las pruebas si el código es dificil de probar (porque requiere mucha preparación para cada prueba).
- No podemos crear un código más amigable para probar si no es modular.
- No podemos entregar frecuentemente si no podemos verificar la entrega antes de publicarla.
- No podemos construir calidad desde adentro si publicamos porquerías.
- No podemos obtener feedback sino entregamos software a los clientes.
- etc, etc, etc.
Hay muchas frases de "No podemos" acá arriba, pero notemos que todas son condicionales. Los métodos ágiles no solucionan estos problemas, sino que los exponen y nos ayudan a realizar un análisis de causa-raíz para resolverlos. Veamos un ejemplo.
Si, por ejemplo, tomo mi sistema de software antiguo y realizo un refactor para desacoplar el sistema de lógica en componentes discretos, de repente puedo probarlo más fácilmente, porque puedo probar un componente sin interferencias con otro. Debido a esto, desciende el costo de armar una prueba. Debido a esto aumenta la velocidad de ejecución de pruebas. Esto ocasiona que pueda testear más seguido (posiblemente luego de subir código al repositorio). Esto provoca que pueda hacer cambios más rápidos sin mucho miedo, porque existe una forma de verfiicar las regresiones. A causa de esto voy a tener menos miedo para realizar cambios, como ser limpiar el código base... y así sigue.
El ciclo positivo de feedback
Comenzando con lo que parecía pequeño ajuste logramos crear un ciclo positivo de feedback. Empezar con cambios me permite hacer cambios más fácilmente en el futuro. Y una vez que me estoy moviendo en esta dirección, puedo comenzar a publicar versiones con más frecuencia, porque la rápida verificación del código reduce los costos de entrega. Estoy significa que podría realizar entregas cada tres iteraciones, en vez de cada doce... o incluso cada una iteración. Significa que puedo hacer iteraciones más pequeñas, porque el costo del "fin de la iteración" desciende...
Hay muchos más ciclos de feedback en proceso durante cualquier transición a una forma más ágil de hacer las cosas, y estos ciclos siguen apareciendo a medida que el enfoque ágil vaya encontrando más obstáculos en la organización.
El factor humano
Pero... y este es un gran "pero"... si comenzamos una implementación de un proceso ágil y no cambiamos la forma en la que pensamos en el software, la entrega de software, cómo lo escribimos, cómo lo diseñamos, nos vamos a chocar contra una limitación interna y propia. No podemos movernos rápidos a menos que estemos dispuestos a movernos rápido. Nuestra base de código es parte del entorno en este contexto.
Tenemos que empezar a ayudar a los desarrolladores a moverse en esta dirección, e ir aumentando la velocidad a la cual van haciendo la transición del código existente a una forma de trabajo más eficiente y mejor.