CMMI (Capability Maturity Model Integration), SPICE, Métrica, Prince2, RUP (Rational Unified Process), XP (eXtreme Programming), MSF (Microsoft Solution Framework)... ¿Hasta qué punto una metodología del software es realmente útil?.
La historia del software es aún muy reciente, y le queda aún mucho por madurar. En esa infancia avanzada, cercana a la pubertad, la criatura experimenta muchos cambios en su propia naturaleza, a ritmos frenéticos y sin saber por qué. Y ese huracán de metamorfosis interna es la que está sacudiendo cada célula de esa criatura llamada software.
Desde los primeros pasitos de la criatura, el padre de la misma ha visto necesario crear un ángel de la guardia para velar por su seguridad y por un crecimiento sano y sin peligros. Dicho ángel protector dejaría tranquilo al padre bajo la falsa esperanza de un futuro mejor para el retoño.
La vida real nos demuestra que no existe ni el padre ni el hijo perfectos. Que cada ente es diferente, y que todo lo planeado se viene abajo en cualquier momento, porque las circunstancias son caprichosas y Murphy es un bromista ingenioso que juega alevosamente.
Las metodologías hacen el papel del ángel protector, y fueron creadas por el padre que es humano, el más estúpido de todos los seres, el que más yerra, el que en su nube de soberbia y en su falsa perfección cree tenerlo todo controlado. El rol de las metodologías es definir y aplicar un conjunto de Best Practices (mejores prácticas), con el que en teoría, el retoño se formará, se educará, crecerá y madurará de la mejor manera posible. Pero ya sabemos todos que una cosa es la teoría y otra cosa bien distinta es la práctica.
La perfección de este mundo se basa en que todo, absolutamente todo, es libre de ser imperfecto y de tener un margen muy amplio para el libre albedrío y el caos (qué bonito me ha quedado). Poner orden en este mundo caótico es una labor muy ardua y difícil, que requiere un consumo de energía, una dedicación y una constancia muy grandes. Un descuido en la tarea significará que todo ese esfuerzo sólo ha servido durante ese tiempo. Eso es como construir un castillo de naipes o un gran circuito de fichas de dominó y pretender que duren siempre. Aunque se protejan dentro de un búnker, siempre habrá un momento, tarde o temprano, en el que una leve vibración, el peso de una mota de polvo, o el desgaste natural del tiempo en las moléculas de los componentes, haga perder el equilibrio de la obra. ¿O quizá ese equilibrio antinatural en realidad era un desequilibrio para la propia naturaleza del caos?.
Retomando el hilo del artículo, las metodologías pretenden perfeccionar el desarrollo del software, y para ello se definen baterías de consejos que funcionaron muy bien en algunos casos, y que lograron con éxito algún aspecto o detalle de la vida de un porcentaje importante del software existente. Viene a ser como decir: "con buenos chuletones de buey y mucho ejercicio, tendrás un muchacho musculoso y perfecto". Eso podría funcionar con un porcentaje elevado del censo actual de niños, pero hay que tener en cuenta que muchos niños no pueden realizar ejercicio debido a algún problema de salud, o bien no les gustan los chuletones o bien desean un mundo más intelectual que deportivo.
El gran error de las metodologías es, precisamente, creer que van a lograr que obtengamos un software perfecto, ya que cada proyecto, como cada niño, es diferente, con entidad propia, y requerirá de una serie de atenciones distintas en cada caso. Los consejos están muy bien, pero no funcionan siempre con todos los proyectos.
Hace tiempo trabajé para un importante banco, en el que las metodologías suponían un lastre burrocrático, que hacía más daño que bien en el desarrollo de los proyectos. La metodología se había convertido en la espina dorsal de todos los proyectos informáticos de la organización, y era de obligado cumplimiento que todos los procesos se cumplieran. Puedo contaros que, en una semana, tuve que modificar tres veces un modelo conceptual y un modelo lógico de una simple portal presencial web, sólo porque el departamento de metodología había modificado tres veces la metodología. Hubo, por supuesto, un acalorado debate cerrado entre varios despartamentos, gerentes, jefes de proyecto y directores, ya que era una pérdida de tiempo trabajar inútilmente varias veces por capricho de la metodología. Al final hubo un terrible final, como toda historia dramática, e imperó la metodología sobre todas las cosas.
Mi caso no era único, pues cuando se pedía una mejora o un añadido a un desarrollo antiguo, había que aplicar todo lo nuevo o no pasaba el test de calidad. Un simple pase podía suponer un mes o mes y medio, y, lo peor de todo, es que durante ese tiempo, la metodología cambiaba o añadía algo nuevo que, en el proceso de calidad, te tiraban la entrega para que adaptaras estos cambios a tu desarrollo.
Este caso extremo sigue vivo en aquella organización y doy gracias por no encontrarme ahora trabajando allí. Aquello es como tener a un padre paranoico que no deja a su hijo ni respirar.
Las metodologías, por otra parte, requieren de un tiempo y unos esfuerzos extra que no se tienen en cuenta. Cuando se planifica un proyecto, casi nunca se tiene en cuenta el tiempo que va a suponer aplicar y supervisar sus consejos, así como tampoco se tiene en cuenta qué personas lo van a aplicar. Al final, hay que echar horas extras, y somos nosotros mismos los que hemos de aplicar estas best practices, en detrimento de nuestra productividad y la calidad.
Un escenario ideal para que las metodologías fueran efectivas y tuvieran sentido, sería el de un proyecto de larga duración (al menos de un año), y en el que se implique un amplio número de recursos humanos, con varios equipos distintos trabajando de forma conjunta. En este escenario debería haber uno o varios recursos dedicados en exclusiva a ser "el ángel de la guarda" del proyecto, identificando qué best practices realmente necesita el proyecto (de entre todo ese océano que propone la metodología), aplicando dichas best practices, realizando supervisiones continuas, midiendo la productividad y la efectividad, detectando desviaciones, generar y aplicar contingencias, etc.
Las metodologías son valiosas y útiles si se saben aplicar de manera juiciosa. En primer lugar, hay que contar con un experto en metodología dedicado en exclusiva a esa labor dentro del proyecto. En segundo lugar, hay que identificar con qué "niño" se está tratando, saber sus problemas, sus ambiciones, sus deseos, y elegir cuidadosamente qué métodos aplicar al niño para que sea beneficioso tanto para él como para su padre. En tercer lugar, también hay que tener en cuenta los costes que de la aplicación de estas prácticas se derivan, y que estén en concordancia con los tiempos y entregas del proyecto.
Todos los expertos en consultoría informática sabemos que la calidad está reñida con la productividad, y que la "burrocracia" puede ser un lastre muy pesado. La mayor parte de los proyectos son de muy corta duración, y no tiene sentido aplicar una metodología axfisiante, que suponga más tiempo y esfuerzos que el propio desarrollo del software (incluyendo la gestión del proyecto, el análisis, el diseño técnico, el desarrollo, las pruebas y la implantación). En estos casos, la metodología debería ser flexible y contar con un mínimo de puntos a cumplir, entre ellos la documentación mínima requerida (documento de requisitos, análisis funcional, diseño técnico, plan de pruebas, documento de instalación, guía de usuario...). Para este tipo de proyectos, debería aplicarse la metodología con un mínimo juego de puntos básicos que aseguren una calidad aceptable.
Los proyectos medios son más complejos de prever, ya que debe ser el experto en metodología el que tenga la habilidad innata de conocer la naturaleza del "niño", identificar sus puntos débiles y fuertes, sus deseos o apetencias, los objetivos a alcanzar y qué aspectos va a contemplar, con el fin de definir un plan de metodología adecuado y a medida. El balanceo de las posibilidades en este tipo de proyectos es un gran reto para el metodólogo.
Las metodologías no son la panacea ni un seguro para un software "perfecto" o de la más alta calidad, aunque sí un recurso valioso si se aplican sus recomendaciones, dentro de un margen de prudencia y de sentido común, sin excesos ni carencias en su aplicación. Es decir, en su justa medida.
¿Cuál es tu experiencia en la aplicación de metodologías?. ¿Las consideras realmente útiles?. ¿Cómo crees que sería el escenario ideal para la aplicación de metodologías?. ¿Cuál crees que es la mejor metodología?. ¿Qué casos conoces en el que la aplicación de una metodología ha sido un gran éxito o un rotundo fracaso?.
Tu opinión es importante y bienvenida. Los comentarios son moderados, por lo que se omitirán aquellos comentarios con descalificativos a personas, organizaciones o empresas.
