Reflexión "reposada" sobre las metodologías ágiles

A lo largo de los años de experiencia que tengo en el sector de la informática he visto pasar muchas tendencias de largo. Algunas eran buenas ideas mal planteadas, (otras malas directamente) que simplemente no consiguen hacerse un hueco en la comunidad de stakeholders implicados.

En ocasiones han fracasado porque cargaban la balanza de un único lado dejando fuera a la otra parte del negocio. Nos guste o no, estamos obligados a entendernos puesto que en esto que este negocio de la informática tan importante es vender como desarrollar. Como una de las dos partes de la ecuación se sienta fuera del juego nunca una metodología podrá cuajar a alto nivel.

Hace ya un tiempo que estamos oyendo hablar de las metodologías ágiles y con la perspectiva que nos da el tiempo, podemos decir que estas tienen algún que otro as en la manga que las pueden hacer triunfar donde otras fracasaron. (Es verdad que la cosa es más fácil cuando el vecino ya se ha pelado la barba…)

Podemos decir que las cosas están cambiando y más rápido de lo esperado.

Poco a poco, el sector del desarrollo del software se va haciendo un hombrecito. Desde luego este proceso no se ha pospuesto por falta de esfuerzos. La industria, cual madre concienciada, haciendo palanca a través de la Ingeniería del Software ha intentado estandarizar de muchas maneras el “artístico” proceso de crear software. Algunos de estos intentos han sido más forzados que otras (UML, CMMI, Métricas de calidad… ), pero casi todos, por diversos motivos, han demostrado la misma poca efectividad. (Por cierto el VS2010 incluye soporte para los 6 documentos principales de UML!!)

Dichos intentos “encauzadores” de mamá industria han quedado a medio camino por la misma razón, partían de un axioma equivocado:

Todas las metodologías predictivas asumen el resultado del proceso de análisis y diseño como verdades inmutables que constituyen los cimientos sobre los que edificar el resto del proyecto.

Centrando sus esfuerzos en conseguir un terreno firme en el que apoyarse, la realidad, obstinada, nos demuestra que realmente lo hacían sobre arenas movedizas. No por que el resultado de tales esfuerzos estuviera mal hecho  (existen toneladas de documentación sobre como optimizar el proceso de toma de requisitos…) sino por simplificar en exceso el contexto (desestimando el factor cambiante) de cualquier proyecto de Software.

¿Cuantas veces nos ha ocurrido al terminar un proyecto que si lo volviésemos a empezar lo atacaríamos de otra forma…? En relación a otras ciencias (y entornos productivo-económicos) el desarrollo de software avanza muy rápido obligándonos a descartar metodologías de éxito en otros ámbitos por la naturaleza de nuestro negocio.

Alcanzar esta velocidad de crucero implica que hay mucho que mejorar y obliga al sector a reinventarse continuamente. La tecnología, los modelos de negocio, el alcance de la funcionalidad de las aplicaciones, la automatización de procesos, la integración y orquestación de unidades de negocio… todo está en ebullición. Como todos sabemos, no se puede estandarizar lo que no deja de cambiar, por lo que los intentos realizados se han ido quedando anticuados antes de alcanzar su madurez.

Pero en ese reinventarse ha cambiado la perspectiva…

Un buen día nos damos cuenta de que estamos peleando contra la realidad. Nos liberamos y dejemos de atacar y evitar el cambio como un enemigo. Es una actitud provocada por el convencimiento que surge desde dentro de que no hay otra opción. Debemos asumir (cuanto antes mejor) el cambio como algo que está ahí, nos guste o no, no podemos evitarlo. ¡¡Todo cambia!!

En las metodologías predictivas se destinan gran parte de los recursos a ser capaz de predecir lo que se va a desarrollar en los próximos años. Por muy concienzudo que sea dicho estudio, el contexto varía, las necesidades del cliente cambian, surgen nuevas oportunidades y riesgos. El que mayor capacidad de cambio demuestre, contará con una ventaja competitiva significativa.

Por lo tanto, permitir que nuestro cliente marque el siguiente paso a dar (o mejor dicho, pasito…) nos permite alinear el camino a recorrer con las necesidades del cliente que sobre la marcha surjan, aportando un mayor valor al software y satisfacción al cliente, que es (o debería ser) nuestro objetivo.

2 comentarios sobre “Reflexión "reposada" sobre las metodologías ágiles”

  1. Reflexion bastante acertada, aunque todavia esta por demostrar si CMMI esta de verdad reñido 100% con las metodologias ágiles. De eso quedo una charla pendiente en la aos2011.

    Esperemos algun dia pueda alguien desde la experiencia enseñarnos por qué sí o por qué no.

    Un saludo mister!

  2. Hola Fank!

    No creo que CMMI y las metodologías ágiles estén reñidos. Si pones a dos expertos a discutir sobre los temas principales en cinco minutos han llegado a acuerdo.

    Convergencia hacia el sentido común, esa es la clave!!

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *