Putting it together

by Luismi Cavallé

[ACTUALIZACIÓN: InfoQ acaba de publicar el vídeo de la charla Modifiability: Or is there Design in Agility? de Martin Fowler y varios ThoughtWorkers en la QCon 2007 que inspiró este post]

No sé si habréis observado esa tendencia que parece que tenemos muchos desarrolladores a pensar en la solución a un problema según vamos conociéndolo. Parece que nuestra maquinaria se pone a trabajar según la información va llegando, de manera que prácticamente antes de que un cliente acabe de explicarnos por primera vez su problema, ya tenemos en la cabeza una primera aproximación no solo a la solución, sino a su implementación. Y no se si habréis observado también que esa solución suele ser simplista e ingenua pues está basada en muy poca información. Ser ágil supone buscar las soluciones más simples que probablemente puedan funcionar. Las más simples, no soluciones simplistas, no lo primero que se nos ocurre, no soluciones estúpidas…

La metodología Lean Software Development propone la idea de retrasar la toma de decisiones hasta el último momento responsable. Tomar cualquier tipo de decisión supone asumir el riesgo de que esa decisión haya sido equivocada. Algunas decisiones, además, una vez tomadas son difícilmente reversibles, con lo que tomar una decisión irreversible antes de que sea necesario no parece que contribuya a la modificabilidad de una solución. No suena muy ágil. Es por ello que la recomendación del Lean Development sea precisamente la de no tomar una decisión hasta que sea necesario hacerlo.

Resolviendo en nuestra cabeza un problema en la primera aproximación al mismo estamos tomando decisiones mucho antes de que sea necesario tomarlas. La idea de retrasar la toma de decisión contribuye a que estas se tomen cuando se tiene la mayor cantidad información posible, con lo que la probabilidad de tomar la decisión acertada sea mayor.

El enfoque que propone el Big Design Up-Front, propio de las metodologías de desarrollo en cascada, se basa en la clásica curva del coste del cambio que indica que a medida que se avanza en las distintas fases del desarrollo el coste de realizar un cambio aumenta exponencialmente. Es por ello por lo que se propone dedicar las primeras fases a tomar las decisiones más importantes: como cambiarlas más adelante resultaría muy costoso la propuesta es dedicarle la mayor parte de los recursos y tiempo a estas primeras fases. Lo que no tiene en cuenta este enfoque son dos aspectos: Por un lado, la toma de la decisiones se realiza en las primeras fases del proyecto cuando se tiene un menor conocimiento del problema, y ningún feedback. Por otro lado, precisamente es la propia naturaleza secuencial del proceso la que convierte casi todas las decisiones en irreversibles, y, por lo tanto, la que contribuye precisamente a acentuar la curva del coste del cambio.

Los ciclos de vida iterativos atacan la raiz de este problema permitiendo retrasar la mayor parte de las decisiones hasta el momento en que realmente se tengan que tomar, es decir, en fases del desarrollo mucho más avanzadas, cuando se disponga de más información y del feedback producto de la naturaleza iterativa del proceso. Este enfoque entiende que no todos los cambios son iguales, no todas las decisiones son irreversibles, la mayor parte sigue una curva de coste del cambio bastante estable en el tiempo. El objetivo de las metodologías ágiles es conseguir que la mayor parte de los cambios sigan esta segunda curva.