16/11/2006 9:29
Augusto Ruiz
"UML no sirve para nada" - Reflexiones
En el post menos afortunado de este blog hubo un comentario acerca de UML en el que se aseguraba que UML no vale para nada. Yo contesté que UML no vale para nada si se utiliza mal. Quiero aprovechar para matizar este comentario en este post.
Creo que RUP tiene un problema serio, es demasiado pesado. Y en mi opinión sólo vale para generar toneladas de papel que luego casi nadie se lee. Y si bien la idea de UML de ser una "lingua franca" es interesante, en este tiempo que vivimos, con un auge de las metodologías ágiles, puede parecer un método un tanto draconiano de comunicar las ideas. También es cierto que UML según fue evolucionando se alejó bastante de ser un lenguaje sencillo (con los estereotipos, etc...) Y a día de hoy, alguno de sus creadores reniega de él.
Veo las ventajas que puede tener una metodología ágil en un equipo pequeño, y mucho más si ese equipo está compuesto por programadores muy competentes, ya que eliminar de un plumazo el peso que puede tener una metodología más pesada, en la que se dedica casi más tiempo en generar documentación no entregable que a generar código, es una ganancia de productividad muy interesante. Ojo, que no digo que no haya que generar documentación, y más en un negocio en el que la gente cambia con bastante frecuencia de trabajo, con lo que si no tienes una documentación suficiente, la curva de aprendizaje de una persona que entre para cubrir una vacante será bastante dura de superar.
Lo que no termino de ver es cómo puede encajar una metodología ágil en un proyecto en el que esté involucrado un equipo numeroso de programadores. Cuanto más numeroso es el equipo, más heterogéneo suele ser. Es decir, que las habilidades de los programadores no están equilibradas. En un proyecto de estas características tendrás un equipo de personas que se encarguen de recoger requisitos del cliente, y de alguna forma se tienen que comunicar a las personas que los van a implementar. A ser posible, debería de ser de una forma que sólo tenga una posible interpretación. Y de alguna forma se tiene que planificar o establecer cómo se van a comunicar los diferentes componentes de nuestro sistema, o los diferentes sistemas entre sí.
También he de confesar que las metodologías ágiles no son mi fuerte. De ser así, no tendría las dudas que expongo. Así que aprovecho para lanzar un par de preguntas al aire:
- ¿Qué libros pueden explicar la problemática expuesta anteriormente? Me refiero a cómo encaja una metodología ágil en un proyecto grande.
- Ya que UML está condenado, o al menos así parece... ¿Cuáles son las alternativas? ¿Algo similar a UML con colorines como los diagramas de clases de Visual Studio 2005? Creo que estamos todos de acuerdo en que simplemente explicar con palabras la arquitectura de un sistema no sirve, y que es necesario tener algún lenguaje de interpretación única (característica que no posee el lenguaje natural) para poder explicarla. Y lo mismo pasa con muchos otros aspectos, como por ejemplo el despliegue de las aplicaciones, la interacción con el sistema...
- El hecho de que UML no sirva... No quiere decir que sigamos utilizando aquello que puede ser útil, no? Por ejemplo un diagrama de casos de uso, o diagramas de clases, de estados...
En fin, que estoy pidiendo que me iluminéis... Y que me comentéis vuestras opiniones :)
Archivado en: Opinión,Reflexiones
Comparte este post: