Wigahluk comenta acerca de las metodologías tradicionales de desarrollo de software y sobre las metodologías express en uno de sus posts (Percepciones acerca de la programación ágil y XP). No soy un experto en la materia, e incluso puedo decir que se mucho menos que él, pero si me puedo aventar a mencionar algunas consideraciones acerca del tema.
Para empezar, me parece que cada tipo de metodología tiene sus pros y contras (wow! descubrí el hilo negro), pero en especial el tema de la documentación presenta muchas dificultades. En el caso de las metodologías más tradicionales y aquellas cercanas al RUP, hacer tanta documentación es totalmente impráctico, pues hacer documentación consume mucho tiempo y cuando se hace una documentación tan extensiva, pues un proyecto puede alargarse por años y felices días antes de siquiera poder comenzar. Además que cuando los documentos son muy largos, en realidad más que dar claridad solo hacen engorroso el proceso de revisión de los mismos, haciendo que el simple hecho de revisar un tema nos lleve toda una tarde o más de lectura, si pensamos en tomarnos el tiempo de revisar toda la documentación a la que por supuesto hará referencia el documento del cual partimos.
Ahora, para las metodologías express, es obvio que aquellos que puedan decir que son metodologías sin documentación o descuidadas simplemente no las conocen. Como Wigahluk comenta en su post, estas metodologías tienen gran cantidad de documentación, pero esta documentación es menos formal y se realiza conforme se progresa en el proyecto, a partir de los talleres y ejecicios que se realicen. Sin embargo, hay una trampa muy oculta en este tipo de documentación, quisiera saber quien en su sano juicio se va a aventar horas y horas de discusiones grabadas porque quiere revisar la definición de requerimientos que se hizo hace un mes o más. De igual manera si pretendemos revisar la fotografía de un pizarrón o una imagen escaneada de una hoja de apuntes corremos el riesgo de no tener la menor idea de que contienen si no disponemos del contexto preciso en que se realizaron. Estas situaciones pueden obligarnos a retrasos debidos al tiempo que nos toma retomar la idea de un pedazo de documentación o a la necesidad de rediscutir un tópico para aclararlo de nuevo. No creo que mucha gente pueda decir de manera honesta, que la arquitectura va saliendo al vuelo como lo hace Beck, el podrá, los demás estamos condenados a sufrir grandes fracasos y frustraciones si nos permitimos que la arquitectura de un software salga “solita”.
En cualquier caso, debemos también tomar en cuenta a nuestro cliente al momento de decidir por una metodología u otra. A los clientes, en especial aquellos no muy duchos en el desarrollo de software, les encanta ver que haya documentos formales conteniendo especificaciones rimbombantes de su proyecto, les brinda mucha seguridad y les permite darse una somera idea de la magnitud del desarrollo. Aquí por supuesto se encuentra otra trampa, si pensando en esto atiborramos a nuestro cliente con volúmenes y volúmenes de documentación, es muy posible que puedan perderse en ese mar de páginas y perder de vista los puntos más críticos a los cuales deben dedicar toda su atención; aunado a esto cuando se enteren que toda esa documentación les infló el costo y el tiempo de desarrollo, porque claro, no se hace sola; van a brincar de alegría!!! (eso obviamente fue sarcasmo, si brincan será del soponcio).
En mi no tan humilde y sí poco formada opinión, un punto medio es lo más apropiado. El MSF pueda tal vez ser un excelente punto de partida, aquellos que no utilizan en este momento ninguna metodología formal de trabajo podrían empezar implementado el uso de los artefactos que juzguen más importantes. La idea que yo propongo, es no casarse con una metodología particular, sino que a traves de la experiencia cada grupo debe formar su propia metodología, sin menoscavar la expectativa y seguridad que requiere el cliente, y limitando la extensión y la profundidad de la documentación para crear artefactos útiles y prácticos para el equipo de desarrollo. Es necesario conocer al menos un poco de las distintas metodologías y conocer el ambiente en el cual se desarrolla (el país, los clientes, el tipo de software en el cual nos enfocamos, etc.), para no terminar con una metodología híbrida sin pies ni cabeza. Casarnos con una metodología formal y bien definida pero que nos resulte incómoda, impráctica o inconveniente en tiempos y costos, seguramente nos llevará a un doloroso (y costoso) fracaso.
