ExtendiendoElIncrementalismo
Escrito por Martin Fowler
Traducido por Jesús Pérez
Revisado por Carmen Vidal
De vez en cuando la gente se pregunta si una especialidad particular puede ser usada de forma incremental: " No se puede hacer (seguridad | diseño de interfaz de usuario| bases de datos | internacionalización | *) con un proyecto ágil porque este aspecto tiene que ser desarrollado realizando un gran diseño inicial".
Cuando se me hace una pregunta como esta, me encuentro perdido porque desconozco esa especialidad. El diseño de aplicaciones es algo de lo que pienso que puedo hablar, pero no sobre diseño seguridad - y mi interrogador bien puede ser un reconocido experto en este campo.
A pesar de mis limitaciones reconocidas en el campo del que se habla, no voy a decir que sólo se puede usar diseño planificado en ese área. Lo que puedo decir es que realmente no sabemos si se puede hacer el diseño incremental en aquella área. He visto bastantes casos en los que la gente ha dicho " no se puede usar el diseño incremental para x " sólo para averiguar que se puede. El diseño de aplicación es de una forma, el diseño de bases de datos es de otra. De esto modo, hasta que la gente pruebe el diseño incremental de un modo serio, no estoy dispuesto a excluirlo.
Parte de la dificultad de evaluar esta pregunta está en que es demasiado fácil hacer el diseño incremental mal. Si se hace el diseño incremental de un forma incontrolada, con alta probabilidad se termina con un lío de diseño - para hacer el trabajo de diseño incremental se necesita algo que haga el diseño convergir al orden. En el articulo "Está el Diseño Muerto" me referí a éstas como prácticas de habilitación. Para el diseño de software, las pruebas, integración continua y refactorizar son las prácticas clave que permiten que el diseño del software converja y evitar la entropía del software. Cuando hablamos de algo más, como el diseño de UI, la cuestión encontrar cuáles son las prácticas de habilitación. Pueden ser similares o inspiradas por las del diseño de software, o pueden ser diferentes. En el diseño de base de datos, por ejemplo, la migración de datos incremental es una práctica de habilitación clave. Hasta que se encuentre un buen conjunto de prácticas de habilitación, el diseño incremental es algo frágil.
A pesar de aquella debilidad, realmente pienso que un acercamiento incremental es tan positivo, que merece la pena experimentar para encontrar la forma correcta. Aproximaciones basadas en un gran diseño inicial fallan demasiado frecuentemente - además no ayuda en el caso de requisitos que cambian – lo que veo como un factor inevitable, al menos en el desarrollo de software de la empresa.
La mayor razón, sin embargo, que favorece el incrementalismo es la más vieja – el control de riesgos. Sin probar los diseños, se es demasiado vulnerable a cosas que no funcionan de la forma esperada, demasiado vulnerable a retrasos en el desarrollo. Estos riesgos son razón suficiente para buscar modos de introducir incrementalismo en más aspectos del desarrollo de software.
