MANUAL TE GP AGILES

MANUAL GESTIÓN DE PROYECTOS ÁGILES

habituales en las metodologías tradicionales dificulten que el equipo de trabajo tenga claro el objetivo final del proyecto así como los pasos que deben darse para alcanzar dicho objetivo.

No hay que olvidar que mientras en el caso de las metodologías tradicionales, la especificación de requisitos del producto final suele ser detallada y cerrada por motivos contractuales, en un proyecto “ágil”, la flexibilidad y el cambio son habituales e incluso predominantes. Para que tanto los cambios solicitados por el cliente sean reflejados en el proyecto lo antes posible, como que las dudas que surjan en el equipo reciban una respuesta lo antes posible, las líneas de comunicación entre ambos, cliente y equipo, deben ser lo más directas posibles. Sin embargo, en casi ningún proyecto es habitual que el equipo de trabajo pueda tener línea directa con el cliente, ni tampoco sería recomendable, ya que es lógico que el cliente tenga un interfaz único de comunicación con la empresa para que la información no se disgregue y sea persistente en el proyecto. Ya se ha nombrado en varias ocasiones el concepto de equipo de trabajo, que si bien en otras metodologías se podría dividir a su vez en una serie de roles (probablemente con un sentido jerárquico) en Scrum serán considerados como una sola entidad. Por otro lado, ya comentamos que las metodologías ágiles, lejos de ser sencillas o indisciplinadas, están regidas por una serie de principios que deben seguirse para que un proyecto no se convierta en caótico. Dichos principios podrían interpretarse de manera que beneficiase a algunas de las partes implicadas en el proceso, en este caso al Product Owner o al equipo en caso de que surgiesen complicaciones. Este rol Scrum lo denomina Product Owner, ya que más allá de su comunicación con el cliente, su responsabilidad final dentro del proyecto será el producto entregado.

Para mediar en cualquier conflicto y asegurarse que la metodología se sigue convenientemente, existe un tercer rol muy importante en Scrum, el Scrum Master.

Pese a que se ha utilizado la palabra “mediar” para definir una de las responsabilidades del Scrum Master, no se debe pensar en él como un intermediario de la comunicación entre el Product Owner y el equipo, sino como un facilitador de la comunicación entre ambos:

123

European Open Business School