La academia, las prácticas ágiles y el UML

La manera más fácil para aprobar una tesis de ingeniería es mentir. Llenar páginas y páginas, preferentemente con tablas y viñetas, de contenidos vacuos y tediosos que seguramente nadie, mucho menos los evaluadores, leerán. Sólo hay que prestar atención a que sean muchas páginas y lo más simétricas posibles.

El ejemplo paradigmático de esto son las especificaciones formales de casos de uso, pasión de burócratas que tienen cabida donde no hace falta demostrar mucho.

Pero también el UML, me atrevo a decir, en su mayor parte y nivel de detalle es secuaz de esta ignominia que pauperiza el nivel del software académico: en vez de saber programar y poder leer código, se presta atención a los dibujitos, poniendo el grito en el cielo si la flechita es negra en vez de blanca, como dice Sommerville que debe ser.

Como no me gusta mentir, la facilidad no me seduce de más (tampoco la dificultad) y estoy bastante conforme con lo que hice me animé a ser sensato en expresar cómo hice mi trabajo.

No me encerré 6 meses a hacer dibujitos que resultarían perfectos, inescrutables y luego harían la programación trivial. Eso, al menos en mi experiencia, no existe (sospecho que ellos todos lo saben, lo que exacerba la hipocresía). Sí, en cambio, hice algunos dibujitos que me ayudaran a entender (y dar a entender) cómo iba la cosa, mientras iba programando y evaluando si estaba bien encaminado.

Este espíritu es el que cobijan las prácticas ágiles, que es el marco conceptual (metodológico) que adopté.

La cuestión es que, para ganarle al unknow how de los hombres de corbata, hay que justificar con nombres que les suenen admirables. Hay que mencionar mucho IBM, Microsoft, C#, Intel. Esas son las voces que respetan, aunque sean pura falacia

Yo justifiqué así:

Según afirma Terry Quatrani, evangelizadora de las metodologías ágiles de IBM, en The Truth About Agile Modeling :

Aunque sigas un proceso ágil, estarás realizando cierto grado de modelado – sólo que no lo realizarás tanto como si utilizaras un proceso tradicional. La falta de formalidad en el modelado ágil no significa que no estás modelando, sino que te pones el foco en los beneficios de este sin las desventajas y confusiones de documentos extraños y burocráticos.

Por su parte, Robert Martin sostiene en *Agile Principles, Patterns, and Practices in C#* que el modelado basado en UML en el desarrollo ágil es útil como instrumento de comunicación, pero su detalle no aporta valor significativo:

No gastes mucho tiempo en esta tarea, no necesitas tanto detalle. Los modelos y los planos son necesarios en la arquitectura y la construcción civil porque es caro construir una casa para demostrar que su diseño funciona. El software no es así – puedes validar tu idea con sólo codificarla, en igual tiempo que el que insume hacer un modelo UML que nada prueba por sí mismo.

Aun más escéptico, Alans Stevens, reconocido ingeniero en software [1] y conferencista, opina en un artículo:

No uso UML y noto que ninguno de mis colegas lo usa. Tengo sensaciones mezcladas acerca de su necesidad. Parece perfectamente razonable que debamos acordar como industria un conjunto de símbolos comunes para representar la programación orientada a objetos, pero UML tiene la típica apariencia de "diseñado por un comité".

(...) El aspecto más crítico en un diseño inicial, en mi experiencia, es la interfaz entre la UI y el modelo de objetos. Lamentablemente UML no aborda este problema y en cambio parece obsesionado por las minucias en una parodia de distracción académica.