archivo

Archivos diarios: mayo 11, 2011

En este artículo toca analizar el último de los principios, tras haber revisado los tres anteriores (introducción al manifiesto ágil, principio primero, principio segundo y principio tercero).

Principio 4: El valor de la respuesta al cambio, por encima del seguimiento de un plan.

En este caso se hace hincapié a la naturaleza adaptativa del proceso de desarrollo de software. Si no tenemos en cuenta que las personas (tanto del cliente como del proveedor) que intervienen en un proyecto no aciertan siempre, no tienen claras las funcionalidades del sistema y cómo quieren interoperar con ellas, las mismas no son con frecuencia bien interpretadas y/o implementadas, etc… y que en el propio proceso de desarrollo se pueden producir infinidad de contingencias, estamos ejecutando un proyecto que va en contra de como fluyen las circunstancias y cuando se va contracorriente todo es más difícil.

Un plan es necesario, sin él no hay referencias y es fundamental que exista un marco de trabajo temporal para que el proyecto fluya. Es como si en nuestra lista de tareas pendientes no ponemos fecha a algunas, aunque sea de manera tentativa, lo que pasará con estas tareas es que quedarán normalmente en segundo plano porque al no haber fechas no las consideraremos importantes y siempre llegarán otras que se considerarán más prioritarias.

Ahora bien, el plan debe adaptarse de la misma manera que lo debe hacer el proyecto, si se toma conciencia de que determinados hitos no se van a poder cumplir en la fecha y forma pactada mantenerlos perjudicará al desarrollo:

– Si un hito que parece muy complicado de conseguir se alcanza, lo hará probablemente a cambio de una pérdida de calidad en el mismo y/o de un sobreesfuerzo del equipo de proyecto. No se puede tener a un grupo de personas sometidas a un overtime constante, ya que mermará su productividad, su motivación y estarán cansados, por lo que lo mismo todo el esfuerzo invertido para el cumplimiento de un hito, provocará la no consecución de los siguientes.

– Si no se replanifica, se estará trabajando con fechas de consecución de hitos irreales, por lo que las ventajas de que exista una planificación se diluyen, ya que cuando el equipo de proyecto observa que las fechas objetivo no sirven para nada, será lo mismo que si no existieran.

Hay proyectos que necesariamente deben estar en una fecha. Y lo pueden estar, pero hay que tener en cuenta que el cumplimiento de una fecha en muchos casos es solo eso, entregar un producto en unas condiciones mínimas de funcionamiento, y que para llegar a la misma, si el tiempo que ha existido para la realización del proyecto no ha sido el necesario para su alcance y/o para las contingencias que ha habido, habrán tenido que existir renuncias.

Las personas que han tomado la decisión de que el proyecto esté en una fecha determinada tendrán que valorar si no es posible hacer un reajuste de la misma y ser conscientes de que existirán repercusiones en el producto final en el caso de no hacerlo.

Para esto es muy importante que exista transparencia en los trabajos que se están haciendo y en los plazos reales, requiriéndose para ello una comunicación continua entre las partes. Si no se va a poder alcanzar un hito, lo mejor es comunicarlo cuanto antes. Cuanto más se tarde más problemáticas existirán y se dejará menos margen para posibles acciones correctoras en el proyecto u orientadas a los destinatarios finales del sistema de información.

Continuemos con el análisis del manifiesto ágil.