Plan, cambio y riesgo en el desarrollo de software

El rechazo es una de las actitudes más habituales que me encuentro cuando explico metodologías de gestión de proyectos a los veteranos del desarrollo de software. Cualquiera que haya participado en suficientes proyectos de desarrollo sabe que las metodologías tradicionales acaban siendo más un escollo que una ayuda para el equipo del proyecto. En mi opinión, esa es una de las claves del triunfo de las metodologías ágiles. Recordemos un momento los valores que enfatiza el manifiesto ágil:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Es evidente que esto choca de frente contra el paradigma de una gestión de proyectos clásicos, que viene del ciclo de Deming (Plan, Do, Check, Act), y que pone lo planificado como los cimientos del proyecto, y cuyo cambio puede implicar riesgos que hay que controlar. ¿Cómo reconciliamos ambas filosofías? Evidentemente, hay respuestas establecidas a este conflicto, bastante más elaboradas que lo que se puede resumir en un artículo de un blog. Sin embargo, hay algunas actitudes que para mi son la base para poder operar desde ambos puntos de vista con comodidad. Vamos a verlos.

 

 

Abraza el cambio

La primera realidad que tenemos que entender es que, en el desarrollo de software, el cambio es frecuente e inevitable. Especialmente en los requisitos del proyecto. De hecho, lo que las metodologías ágiles ofrecen es una forma de forzar que el cambio salga a flote lo antes posible, de adelantar entregables parciales del proyecto a los stakeholders para que estos a su vez propongan nuevos requisitos o modifiquen los anteriores, y con las sucesivas iteraciones llegar a los requisitos finales del proyecto. Dado que es parte de la naturaleza del desarrollo ágil, asumamos que va a pasar con frecuencia, y que vamos a tener que dedicar mucho más tiempo a estos procesos de cambio que en una gestión de proyectos tradicional. Esto no significa que vayamos a eliminar la revisión de la planificación: sigue estando ahí, y es nuestra labor mantener actualizadas las líneas base de coste, tiempo y alcance, porque seguirán siendo de utilidad para contrastarlas contra estimaciones a futuro y anticipar las desviaciones sobre el plan inicial.

 

Aprende a vivir con la incertidumbre

Sin embargo, esas estimaciones iniciales en proyectos de desarrollo del software son menos fiables que en otros proyectos, especialmente cuando los equipos de trabajo están constituidos recientemente. De nuevo, esto es independiente de la metodología: es una certeza propia de la naturaleza de nuestro trabajo. Un alto riesgo de síndrome del lavadero  es una constante en todos los proyectos de desarrollo. Hay que anticiparlo,  asumir que tendrá una probabilidad mayor de la que nos gustaría, y a partir de ahí, permanecer vigilantes.

Lo importante es que los stakeholders de los proyectos entiendan estas peculiaridades, y estén informados y preparados para decidir prioridades a la hora de aprobar y priorizar nuevas características en un producto, o por el contrario ampliar el presupuesto del proyecto. Al comunicar el plan de proyecto, que siempre será menos detallado en la descomposición de tareas que un proyecto tradicional, debemos acompañarlo siempre de una estimación de su fiabilidad, extrapolando datos a partir de proyectos anteriores o métricas de referencia de las metodologías que estemos empleando. Conforme avance el proyecto, iremos informando a los stakeholders de cómo el plan va concretándose y se va reduciendo el riesgo con las sucesivas iteraciones, al ir conociendo cada vez más y mejor los requisitos ‘ocultos’ del proyecto. Esto repercutirá en una mejora de la confianza de los stakeholders, y ayudará a motivarlos para que sigan participando en el proyecto, lo cual es clave para el siguiente punto…

 

Lleva al stakeholder de la mano

En la mayoría de los casos, el stakeholder y/o sponsor ni conoce las peculiaridades del desarrollo ágil, ni le interesan. Si le preguntamos al principio del proyecto, lo quiere todo: control del proyecto, feedback continuo durante el desarrollo, alcances flexibles pero coste y tiempo inamovibles, y a ser posible con poco trabajo por su parte. Es nuestra función como jefes del proyecto explicar y preparar al stakeholder para la realidad del desarrollo de software, las ventajas y desventajas de la metodología ágil, y los posibles. Además, la participación de los stakeholders en un desarrollo ágil es mucho mayor, pues toman parte en las decisiones de priorización y adición de funcionalidad. Cuando los proyectos se alargan en el tiempo, es importante mantener la motivación de los mismos para que sigan involucrándose en el proceso, sigan entendiendo los motivos y las consecuencias de los cambios, y a la vez no pierdan nunca de vista la situación del proyecto dentro del marco de los constreñimientos de tiempo, presupuesto y alcance. Todo esto hace que tengamos que invertir más tiempo y esfuerzo de lo habitual en atender a los stakeholders, pues ellos mismos son potenciales fuentes de riesgo.

 

Post By Jose Sanchez del Rio (13 Posts)

Ingeniero informático y PMP. Experto en metodologías de gestión de TI, gestión de proyectos y de desarrollo de aplicaciones. Puedes ver mi perfil completo en linkedin

Website: →

Connect

,

No comments yet.

Deja un comentario

Leave your opinion here. Please be nice. Your Email address will be kept private.

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies
Translate »