Experiencia de cambio de metodología "Tradicional a Ágil"

Hola Gente, la idea de esta nota es contarles una experiencia que viví en una empresa muy grande, fue una experiencia de transformación de metodología de trabajo de tradicional a ágil.

Desde hace varios años veníamos trabajando con metodología tradicional de proyectos, cabe aclarar que el sector donde yo trabajaba se hacían desarrollos sobre la pagina Web de la compañía y, la opinión del usuario tenia mucha fuerza.

Particularmente yo estaba en el sector de Testing de sistemas (no de usuario), les detallo algunos problemas que teníamos con la metodología de trabajo que veníamos llevando desde hace años:

•     A veces había tiempos muertos ocasionado por la demora de desarrollo en entregar las funcionalidades a testing. En otras oportunidades eran ocasionadas por estimaciones holgadas de las pruebas.
•    Reiterados pedidos de cambios del software por parte del usuario, esto impactaba directo en la salida productiva.
•    Los usuarios siempre estaban muy disconformes con las soluciones que brindaba sistemas.
•    Poco compromiso con las tareas del proyecto, ocasionado por el mal clima general que se daba por los ítems anteriores.

Un día la empresa contrato una consultará que tenia la responsabilidad de implementar una metodología ágil (Scrum), el proceso habrá durado seis meses en total. Les cuento que a nivel general la situación mejoro bastante.

Les detallo algunos aspectos que mejoraron con esta metodología:

•    Disminuyeron considerablemente los tiempos muertos, al tener reuniones todos los días y contar los avances, la persona encargada de gestionar el proyecto cuando le contabas que estabas terminando una tarea te asignaba otra.
•     El usuario paso a ser parte del equipo de proyecto. Esto trajo aparejado como efecto tener más conciencia sobre los pedidos de cambio que hacía, y si los solicitaba eran tomado mucho antes que en una metodología tradicional siendo menos costosos.
•     Se entregaba valor cada dos semanas, es decir en ese periodo de tiempo les exponíamos los avances al usuario. Podíamos hacer entregas parciales a producción de algunas funcionalidades permitiéndole al negocio aprovechar antes las oportunidades del mercado, y disminuyendo considerablemente los riesgos de las implementaciones.
•       Existía mas compromiso por parte del equipo de trabajo, esto debido a que cuando terminábamos de desarrollar una parte teníamos que exponerla en frente del usuario haciendo una demostración. Obviamente a ninguno del equipo nos gustaba la idea de que en esa “Demo” pasar la vergüenza de que las cosas no funcionen.

Como toda metodología nueva, también trajo algunos problemas. Les comentó algunos inconvenientes que se presentaron en ese periodo de “transformación”.

•     La cantidad de reuniones aumentaron considerablemente, en mi caso particularmente me afecto porque estaba asignado a tres proyectos, ocasionando perdida de tiempo de pruebas. Hay que tener mucho cuidado con la paralelización de proyectos en este tipo de metodología, los expertos recomiendan que no exista y que el grupo de trabajo solo este asignado a un proyecto.
•     El usuario a veces priorizaba erróneamente las funcionalidades a desarrollar, porque no era performante construirlas de esa manera.

En mi opinión la nueva metodología ayudo muchísimo. Con el tema de metodologías ágiles hay que tener cuidado:

•     Como ya mencionamos en la paralelización de proyectos, esta suele generar dificultades.
•     Tener en cuenta que todos los proyectos no pueden llevarse a cabo con esta metodología. Por lo general en los proyectos enlatados, o con el alcance definido no son buenos candidatos.

Vamos a tener que esperar a que pasen los años para ver si este tipo de metodologías es solo una moda o si vino para quedarse. Yo creo que se va a terminar imponiendo en la mayoría de los proyectos de sistemas, por su alto grado de eficiencia y entrega temprana de valor a los usuarios.