Aplicación de metodologías en proyectos de desarrollo SW

Se habla, en mi opinión en exceso, de estándares, buenas prácticas, que si normas ISO por aquí, que si ITIL por allí, para aplicar metodología y gestionar la calidad en las Organizaciones y en el desarrollo de SW en particular. Sin ser un detractor de estas normas, lo único que está claro a día de hoy es que la ingeniería del SW no es lo suficientemente madura como para afirmar que hay una metodología o unas pautas concretas que son las correctas, y son las que hay que aplicar sí o sí en aras a obtener los mejores resultados posibles. De hecho en la corta historia de esta ingeniería se ha pasado de modelos clásicos predictivos y en cascada más parecidos a cómo se afronta la construcción en otras ingenierías, a modelos evolutivos cíclicos y prototipados. Ambos presentan ventajas y desventajas así que otros apuestan por seguir modelos mixtos de los dos anteriores buscando las bonanzas de cada metodología. De momento no se ha demostrado que una metodología sea mejor que otra y esto es debido en parte a que la forma de construir SW es un proceso más analítico y creativo que físico lo que provoca que sea diferente a otros tipos de ingenierías (interesante el artículo de Javier Garzas que habla de esto más detalladamente).

Yo como persona práctica que siempre trato de ser soy de los que piensan que cada maestrillo tiene su librillo y que cumpliendo unos mínimos imprescindibles es mejor sentirse cómodo con el método de trabajo a que te impongan una forma de trabajo con la que no te identificas. En el tenis, deporte sobre el que tengo bastante conocimiento, se puede apreciar este concepto muy bien. Por ejemplo, para aquellos que recuerden la forma de jugar de Alberto Berasategui saben que no era muy ortodoxa pero no por ello igual de eficiente que la mejor de las técnicas aconsejadas. Es más que probable que si su entrenador le hubiese impuesto una técnica más “clásica” no hubiese llegado a donde lo hizo.

Eso sí, Miguel Vallés que fue mi jefe cuando entré en la administración y me enseño muchísimo (gracias Miguel si me estás escuchando) siempre decía una frase:

“Lo importante no es decidir si usar esta metodología o esta otra, sino que lo importante es aplicar una”. Estoy completamente de acuerdo porque si no reina el caos.

De todos modos a mí lo que sí me interesa y mucho es como aplicar metodología y calidad a nivel práctico en mi trabajo y en esas dándole vueltas estoy. Sin ánimo de aleccionar a nadie, pero si de compartir una experiencia, resumo a continuación mi forma de proceder.

Tras analizar con cierto detenimiento mi trabajo ligado al desarrollo SW me doy cuenta que simplificando al máximo tengo dos tipos diferentes de aplicaciones que gestionar:

• Aplicaciones todavía en un estado incipiente y que requieren de una puesta en producción de nuevas versiones de forma ágil para que los usuarios se comprometan con la aplicación y no abandonen el barco. Se trata de atender con rapidez los posibles errores que notifiquen los usuarios y ajustar aquellos procesos que no estén bien diseñados.
• Aplicaciones muy consolidadas. Aquí no es necesario tanto la agilidad porque lo importante ya está resuelto y se trata de pulir ciertos detalles o mejorar ciertos aspectos consecuencia de cualquier cambio que se produzca ya sea normativo, procedimental, etc.

Y mediante esta categorización aplico dos metodologías diferentes.

- Así para el primer grupo de aplicaciones trato de usar metodología mucho más basadas en el concepto de “metodologías ágiles”. En ellas primo la agilidad y celeridad, a veces eso conlleva cometer algún error. Sin embargo creo que los usuarios se involucran mucho más con la aplicación y respetan el introducir algún fallo porque se dan cuenta que están participando en la definición de la aplicación. Se ponen en producción nuevas versiones con bastante frecuencia trabajando de forma cíclica y evolutiva mediante prototipos.

- Para el segundo grupo de aplicaciones soy bastante más procedimental y trato de controlar mucho más las puestas en producción cumpliendo una serie de pasos donde las pruebas son una parte esencial. En estas aplicaciones procuro que cada paso que se dé siempre sea sumar y nunca tratar de introducir errores ya solucionados en el pasado. Como resultado las puestas en producción son más espaciosas pero más controladas. No se aplica una metodología tan ágil como en el anterior grupo sino que la metodología tira más hacia lo “clásico” por así llamarlo.

Por tanto me parece conveniente afirmar que cada aplicación puede necesitar una metodología diferente para optimizar y hacer más eficiente y eficaz su progresión en función de sus requisitos y grado de madurez, entre otros factores. No midamos con el mismo rasero cualquier proyecto sin tener en cuenta su idiosincrasia particular.

En conclusión, distintas aplicaciones pueden requerir distintas metodologías. No es lo mismo aplicaciones con requisitos muy cerrados desde el comienzo, como por ejemplo sw empotrado (diseñadas para cubrir necesidades muy detalladas y específicas) que aplicaciones no muy definidas en las fases iniciales donde el usuario final tiene una idea pero no la foto final de lo que necesita. A su vez, no parece lógico aplicar metodologías similares a proyectos bastante consolidados y con muchos usuarios trabajando en producción, que a proyectos muy incipientes y con pocos usuarios todavía trabajando en entorno real.