Ios

Roberto Andrés

Evidentemente y atendiendo a estos puntos de partida casi todos, sobre todo los programadores, se podrán ver interesados o atraídos por ciertas características de estos métodos. En este artículo no se pretenden exponer las virtudes, pros o contras de estas metodologías ágiles, ni tampoco justificar o explicar los posibles problemas encontrados a lo largo de la implantación de proyectos pasados o futuros, sino simplemente realizar una recopilación de la existente literatura al respecto de estos métodos menos conocidos, a la vez que desde mi doble punto de vista como diseñador y desarrollador, exponer alternativas a los métodos que se llevan usando desde hace ya más de 30 años. No nos engañemos, Ken Beck, uno de sus creadores y principales valedores lo puso en marcha para rescatar el proyecto C3 de Chrysler a finales de los 90 y este proyecto tuvo que ser finalmente cancelado, luego podemos casi asegurar que no se trata de la panacea que arregle todos nuestros problemas, pero evidentemente encontraremos algunos puntos que nos serán fácilmente identificables como útiles para su aplicación en nuestros proyectos.

Como ya comentábamos, estos métodos suponen principalmente un choque entre dos estilos; el diseño evolutivo/adaptativo y el diseño planeado/predictivo.

Esencialmente, evolutivo significa que el diseño del sistema crece conforme se implanta el sistema; el diseño es parte del proceso de programación y conforme el programa evoluciona el diseño cambia. Habitualmente esto se convertirá en un desastre; el diseño en estos casos se reduce a una serie de decisiones puntuales tomadas sobre la marcha que irán inevitablemente complicando la posibilidad de mantenimiento del código a medio y largo plazo. Conforme el diseño se deteriora, igualmente se deteriora la capacidad de cambio y con él se facilita la generación exponencial de errores que cada vez serán más difíciles (y costosos) de eliminar. Estas son principalmente las complicaciones del típico “codifica y corrige” al que en gran parte nos hemos acostumbrado los programadores. Los teóricos de la metodología denominan a este fenómeno como la Entropía del Software.

El diseño planeado al contrario, se basa en prácticas extraídas de la ingeniería. Si queremos construir por ejemplo un edificio, no podemos empezar a poner ladrillos a lo loco sino que realizaremos ciertos estudios, esquemas, códigos y diagramas utilizando diversas técnicas matemáticas y de estructuras, tras lo cual podremos abordar su construcción o encargársela a otra empresa para que lo construya.

En software todo debería funcionar de manera similar. Los diseñadores no pensamos en programar ya que solo lo estamos planeando, se piensa en los problemas con anticipación, y por ello utilizamos diferentes técnicas que dejan de lado los detalles de programación de bajo nivel para dedicarnos a un nivel más abstracto. Al igual que en el edificio estamos convencidos de poder diseñar un software a imagen y semejanza de una lógica de negocio y que podemos pasarlo después a los programadores o bien a otra compañía para que construya dicho software.

Así llevamos ya cerca de 30 años y aunque a priori parece mejor que el sistema de codificar y corregir, nuestra experiencia sabe que esto no siempre es así.

Sabemos que es totalmente imposible en un sistema de una complejidad media el haber pensado en todos los problemas que se necesitan tratar al programar y que aparecerán inevitablemente problemas que pondrán al diseño en entredicho, además no contaremos ni con un plazo suficientemente amplio para la realización del proyecto a la vez que tendremos unos márgenes comerciales más ajustados.

Normalmente en estos casos se realizará un cambio rápido en el diseño por la presión de tiempo a la que casi seguro estaremos sometidos, provocando con esto de nuevo el crecimiento de nuestra famosa Entropía, siendo en ocasiones obligados a lanzar el software incluso con un conjunto en teoría conocido de defectos y deficiencias. El software es lanzado con esos defectos conocidos porque el valor del software en un determinado nivel de calidad (teóricamente) compensa el impacto de los defectos y deficiencias conocidas.