Planificación incremental

Nada verdaderamente valioso se construye de una sola vez. Cada pieza de software —y, de hecho, toda creación significativa— es el resultado de un proceso iterativo e incremental.

Tendemos a romantizar los grandes descubrimientos: el momento Eureka, el genio que escribe una obra maestra en un fin de semana, el producto perfecto nacido de un solo impulso de inspiración. Pero en realidad, todo lo que perdura —todo lo que funciona— ha sido moldeado, probado y refinado con el tiempo.

Esa es la esencia del desarrollo incremental: reconocer que aprendemos mientras construimos, y que la perfección se alcanza tras un proceso iterativo de perfeccionamiento. Un buen producto no se diseña: evoluciona.

Lo mismo ocurre con el plan.

Imagina un plan de vida o muerte. Un plan de batalla. Las personas más inteligentes, con la mejor información disponible, trabajando en él como si sus vidas dependieran de ello. Incluso en ese escenario, hay un dicho: “Ningún plan sobrevive al contacto con el enemigo.”

Por suerte, en el desarrollo de software tenemos la suerte de enfrentarnos al enemigo y volver al día siguiente con un plan mejor.

Todo buen plan de desarrollo evoluciona gracias a su contacto con la realidad.

La primera versión del plan es solo un borrador —que igual ni nos gusta—, es solo la expresión de un conjunto de hipótesis que queremos validar.

Luego llega el contacto con el enemigo: escribimos algo de código, tenemos una sensación intuitiva de si tiene sentido, descubrimos cosas que no sabíamos y aportamos como desarrolladores el feedback que como arquitectos necesitábamos saber. Cosas que si hubieramos sabido antes, habríamos escrito un borrador diferente.

Porque esta es la verdad: aunque somos a la vez arquitectos y desarrolladores, somos un poco diferentes en cada rol.

Cada mentalidad tiene sus propias herramientas y puntos ciegos. Y la mejor manera de que los puntos fuertes de cada rol suplan las deficiencias de los puntos débiles del otro rol, es la iteración.

Así que planificamos, construimos, aprendemos y ajustamos. Nunca enamorados de la iteración actual. Siempre mirando hacia la siguiente.

Y, a veces, tendremos la suerte de descubrir que las premisas iniciales eran totalmente erroneas, y que necesitamos empezar de nuevo.

¿Suerte? Sí —porque la alternativa es mucho peor: descubrirlo demasiado tarde, cuando ya es demasiado caro o imposible cambiar, cuando estamos en medio de la batalla y realmente se convierte en una cuestión de vida o muerte.

Cuanto antes falle un plan, mejor.

Porque nadie puede garantizar un plan inicial perfecto solo dibujando diagramas y jugando con palabras, ideas y experiencias pasadas, sin entrar jamás en contacto con la realidad del problema. Ni siquiera se puede garantizar un plan aceptable.

Los planes deben ponerse a prueba y validarse, antes de que sea demasiado tarde.