archivo

Archivos diarios: marzo 1, 2013

Lo importante realmente en la predisposición a modificar la agenda, ahí es donde está la clave de todo esto. Esa predisposición supone haber entendido la incertidumbre del desarrollo de software y la necesidad de adaptarse al cambio y a los nuevos contextos que surjan durante su ejecución.

Sin embargo, son muchos años aplicando la filosofía de la llave en mano, de la gestión de agendas, de ciclo de vida clásico, de pensar que un proyecto de desarrollo de software es solo proceso y que no tiene por qué verse afectado por su contexto. Respeto ese cuerpo de conocimiento ya que supuso el primer intento de crear un orden dentro del caos y tuvieron un cierto éxito en comparación con el estado del arte anterior en el que sencillamente los proyectos, por regla general, no se gestionaban.

Pero tampoco supusieron la solución definitiva, solo un primer avance, sin embargo muchas organizaciones, muchos profesionales de reconocido prestigio creyeron ver ahí la solución a la ejecución de los proyectos software. El tiempo vino a demostrar que no, como tal vez el tiempo venga a demostrar que los enfoques ágiles tampoco lo son, sino una siguiente aproximación a otro modelo que permita obtener mejores resultados.

En cualquier caso y sea cual sea el enfoque a aplicar, lo realmente importante es el valor del producto y considerar la agenda como algo inamovible es atentar precisamente contra ese principio.

Recomiendo la lectura, si no lo habéis hecho ya a esta serie de artículos que si bien están orientados a los enfoques iterativos incrementales tratan, en esencia, de este mismo problema:

La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas: Parte I, Parte II y Parte III.

La gestión de una agenda con falta de flexibilidad en sus parámetros supone no la gestión del proyecto en sí, sino la gestión del desgaste en las relaciones entre los diversos participantes, las cuales se irán deteriorando conforme vaya avanzando el proyecto porque no se terminarán de llegar a acuerdos que sean satisfactorios para ambas partes. La gestión del desgaste tratará de buscar puntos de equilibrio en ese caos en el que se habrá convertido la situación, con el objetivo de intentar exprimir al máximo un fruto al que prácticamente no le queda jugo.

Absolutamente. Requiere implicación porque tendrá que tomar decisiones sobre la línea de desarrollo del producto, él tiene la última palabra al respecto. Requiere implicación porque es el responsable de proporcionar la “materia prima” necesaria a los desarrolladores. Esa “materia primera” son las especificaciones de las historias de usuario y también otros productos como son, por ejemplo, el valor de determinados dominios de datos, el contenido de determinadas tablas maestras (si quiere que estén precargadas en la entrega), etc…

Esta implicación se consigue cuando el product owner entiende el papel fundamental que juega en el proyecto.

Esto no es fácil porque siempre se tiende a cargar la responsabilidad al desarrollador creyendo que entre sus funciones se encuentra también definir funcionalidades o ayudar a completarlas, y no es así (independientemente de que se asesore o no en determinados temas), ni debe ser así, incluso cuando el desarrollador esté dispuesto a asumir esa carga porque no olvidemos que, al final, ese producto será para un conjunto de usuarios y no para el desarrollador.

El product owner debe saber cuál es su papel, lo que requiere la intervención de su responsable, en el caso de que el product owner no tenga experiencia en estas tareas, para dejarle claro que el resultado final de los trabajos también es responsabilidad suya y cuáles son sus funciones. También será necesario que le ofrezca los medios necesarios para hacer su trabajo: dedicación, autoridad para la toma de decisiones (independientemente de que decida hacer consultas puntuales) y para solicitar la colaboración de otras personas del área usuaria, etc…

Pero no solo se trata de implicación, también resulta fundamental su capacidad para analizar las contingencias que se pueden producir en el proyecto, así como otros impedimentos que pueden provocar que en determinadas iteraciones no se cumplan los compromisos o que el nivel de acabado de algunas historias de usuario no sea el esperado. No es fácil reaccionar de manera adecuada a situaciones de crisis o a situaciones que se interpreten como tales (siendo la gravedad mucho menor que la que se percibe) y en cómo se reacciona a ellas hay una buena parte del éxito del proyecto.

En todo proyecto, ágil o clásico, el responsable funcional o product owner (con los papeles que le quiera dar cada metodología) es clave, para bien o para mal, como mínimo tan importantes como los desarrolladores, siendo en la mayoría de los casos responsables para bien o para mal, del resultado de los proyectos.