MANUAL TE GP AGILES

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Además de la presentación, se preparó documentación que se puso a su disposición y aquellos que habían recibido formación se ofrecieron a responderles cualquier duda o inquietud que les pudiese surgir. Por otro lado, se les pidió que también devolviesen un feedback de las sensaciones que el cambio producía en ellos y expusiesen todas aquellas ideas y mejoras que creían serían positivas para el periodo de transición.



Puesta en marcha

Sin embargo, el mayor cambio que tenía que llevar a cabo el equipo no era el más evidente cuando se empieza a trabajar con scrum, que suele ser el hecho de que el equipo se autoorganice, era algo todavía más básico: trabajar en equipo. Hasta ese momento, la estructura de la empresa, como la de tantas otras dedicadas al desarrollo de oftware y sobre todo en aquellas con cierta envergadura organizativa, consistía en una división por departamentos que diferenciaban claramente cada fase del desarrollo de un proyecto: por un lado estaban los diseñadores, por otro los programadores, los responsables de calidad, de pruebas, de experiencia de usuario, resolución de incidencias y mantenimiento, etc. El trabajo del día a día era más parecido a una cadena de montaje en una fábrica: el proyecto pasa por un departamento, una vez han terminado pasa al siguiente, una vez han terminado al siguiente y así sucesivamente hasta que se termina y se pone en producción. Sin embargo, existe una diferencia fundamental con una cadena de montaje: en este caso no se ensamblan copias de un mismo diseño o producto, sino que cada unidad que pasa por la cadena es única e irrepetible… por tanto, tiene que ser probada en su totalidad para darla por buena. Ese era el punto que más invitaba a cambiar de metodología. El trabajo del primer grupo podía necesitar ser cambiado mucho tiempo después de haber “terminado” el trabajo. Lógicamente, ese grupo de gente no podía estar meses, ni semanas, ni días de brazos cruzados esperando a que el resto terminasen su labor para saber si había terminado realmente el producto, sino que cuando le volvía cualquier modificación, ya estaban inmersos en nuevos proyectos, con sus planificaciones, sus tiempos, etc. Encontrar un fallo en un proyecto implicaba retrasos no solo en ese mismo proyecto (más retraso cuanto más cerca estaba el grupo que encontraba el error, del final de la cadena de montaje, ya que implicaba volver a tener que pasar todos los pasos intermedios), sino también en el proyecto en que se encontrasen inmersos en ese momento.

169

European Open Business School