archivo

Archivos diarios: agosto 23, 2012

Para Jim Highsmith (traducción libre): “La gestión de proyectos ágil abarca tanto “hacer” y “ser” ágiles, siendo lo segundo lo más difícil”.

Gestionar proyectos siguiendo metodologías ágiles no hace necesariamente ágil ni a quien gestiona, ni al equipo de proyecto, ni al proyecto, porque la agilidad no se consigue solo con metodologías porque la agilidad está por encima de ellas.

¿Qué pasa si tu contexto de trabajo no te permite aplicar metodologías ágiles?, ¿desenchufas y ya no aplicas un enfoque ágil? Incluso en las circunstancias más adversas para ser ágil existirán resquicios que te permitirán serlo (con mayor o menor trascendencia).

La gestión ágil debe empezar desde el mismo proceso de definición del proyecto, realizando las tareas que sean necesarias para evitar que desde su inicio sea considerado un Death March Project (en este tipo de contextos los árboles siempre impedirán ver el bosque y la presión y el exceso de carga de trabajo dificultará la creación de un clima donde el equipo de proyecto sea colaborativo y esté motivado) y para asegurarse que los stakeholders, sobre todo el área usuaria, tienen la implicación que requiere el proyecto (ellos tienen que definir la línea de desarrollo del producto, especificar los requisitos, indicar sus expectativas).

Si no se logran esos objetivos (y es posible que así sea porque generalmente podremos intentar influir pero el poder de decisión estará lejos de nosotros) seguimos teniendo el proyecto bajo nuestra responsabilidad y aunque las restricciones establecidas hagan daño al modelo de funcionamiento que nos gustaría implantar, no hay que tirar la toalla para la aplicación de enfoques ágiles, es más, nunca hay que tirarla.

Después la gestión ágil debe contextualizar los métodos de trabajo a la naturaleza del proyecto y del equipo de personas que van a participar en él y estar dispuesto a hacer los cambios necesarios para mejorar si fuera preciso y/o para adaptarse al cambio (para esto es fundamental que la estrategia de desarrollo utilizada y la calidad del software creen la menor resistencia posible).

Y tras eso, mucho más, porque la gestión ágil es un día a día con tu equipo (o equipos) de trabajo y el resto de personas o grupos de personas que intervienen de alguna u otra forma en el proyecto, de manera que se consolide una relación de confianza entre todos ellos (y dentro del equipo de proyecto), que el nivel de implicación de todas las partes se mantenga acorde a las necesidades del proyecto, que la comunicación entre todos sea fluida y que todos se sientan importantes.

Muchas veces cuando se cuestiona la visión ágil en el desarrollo de software parece que se viene a decir que los agilistas desean el cambio y que si no lo hay, ellos mismos se encargan de que lo haya.

Mi opinión es que no es así. A todos el mundo le encantaría tener una receta que siguiéndola de principio a fin diera lugar a un proyecto con éxito. Si tuviéramos esa receta la aplicaríamos porque ¿para qué complicarnos la vida?. El cambio da lugar a quebraderos de cabeza, la línea recta es mucho más sencilla, el cambio por regla general no gusta, no es cómodo, salvo en aquellos casos donde el camino iniciado sea incorrecto o estemos en una situación en la que no lleva a ningún sitio. Es decir, el cambio (provocado) solo cobra sentido si es para mejorar un determinado estado o situación

El cambio es el resultado de que todo está en “movimiento” bajo un contexto de incertidumbre (no sabemos qué va a pasar, podemos tener sospechas o predicciones, tener los riesgos bajo supervisión e incluso con contramedidas, pero no es posible tener todo bajo control): el proyecto, el cliente, el negocio, nuestra propia organización, los usuarios, nosotros mismos, etc… Si estos cambios afectan al proyecto hay que reaccionar y cuanto antes mejor y para que la adaptación sea rápida se requiere flexibilidad, actitud y orientación al producto, además de unas condiciones de partida que faciliten (permitan) el cambio: procesos que permitan realizar los ajustes rápidamente, equipos de proyecto que tengan conciencia de la realidad del desarrollo de software, una arquitectura y un software mantenible, etc…