Cuando se decide adoptar metodologías ágiles se presume muchas veces que es un cambio que solo afecta al equipo de desarrollo. Sin embargo, una adopción exitosa requiere de un cambio también en la línea de Management.
¿En que se diferencia la gestión de proyectos tradicional de la gestión de proyectos ágiles? Aquí las clave para entender la diferencia y el impacto en algunos roles tradicionales.
La diferencia en los roles
Migrar de la gestión tradicional de proyectos a la gestión ágil tiene un impacto particular en cada uno de los roles funcionales:
– Developers deberán asumir mayor responsabilidad y compromiso. No bastará con completar tareas asignadas sino que se serán responsables de entregar el producto requerido funcionando y con calidad integrada.
– Testers tendrán que ser un miembro más del equipo de desarrollo, codificar tests, colaborar en el diseño, validación y verificación del software como una actividad paralela a la codificación.
– Product Managers tendrán que definir requerimientos en incrementos más pequeños, trabajar de manera más colaborativa con el equipo a lo largo del ciclo de vida del proyecto y hacer las actividades de planificación de manera progresiva adaptándose a los cambios del negocio.
– Los ejecutivos y gerentes liderando organizaciones ágiles tendrán que comunicar la visión de manera eficiente, poner a las personas correctas en las posiciones correctas con los recursos adecuados para permitir a los equipos hacerse cargo de los problemas y las soluciones, confiando en la capacidad del equipo y adoptar un perfil más orientado a la facilitación.
– Project Managers tradicionales no tendrán lugar en un proyecto ágil, sus responsabilidades están ahora distribuidas entre los otros roles.
La gestión tradicional de proyectos
La mayoría de los proyectos tradicionales comienzan con un alcance determinado como restricción principal. El alcance se define como una larga lista de requerimientos que el producto deberá incluir. El Project Manager es responsable de recolectar la información necesaria para estimar el esfuerzo de implementar cada funcionalidad. Las estimaciones se expresan en horas y está basada en información muy limitada acerca de como esos requerimientos van a ser realmente implementados.
Las estimaciones se utilizan para saber cuando el proyecto podrá estar completo y se usan además como base para calcular la cantidad de personas que el proyecto necesita tener asignados y por lo tanto cuanto costará.
En este sentido las personas se consideran recursos. En muchos casos, para mayor conveniencia, estos «recursos» son «divisibles», donde es válido asignar sólo medio recurso a un proyecto. Dicho en otras palabras, la persona destinará la mitad de su tiempo a un proyecto y el resto a otro, con los problemas escondidos que esto tendrá durante la ejecución.
En la etapa inicial del proyecto, el equipo tiene muy poca información real para poder estimar la cantidad de trabajo. Por otra parte el Project Manager puede no saber específicamente qué personas serán asignadas para llevar a cabo el trabajo.
Los Project Managers, con muy poca información concreta y muchas suposiciones se ven en la tarea de crear un GANTT o línea de tiempo de tareas anidadas que culminan en la fecha límite (deadline) del proyecto.
Durante la ejecución los Project Managers deberán hacer su mejor esfuerzo para gestionar las tareas conforme al plan. El progreso se medirá a través de completar las tareas planificadas.
El hecho de no completar todas las funcionalidades definidas en el alcance para la fecha límite suele considerarse como un fracaso para el proyecto. Motivo por el cual Project Managers con experiencia suelen multiplicar los tiempos por algún factor de seguridad, basado en experiencias anteriores.
Gestión ágil de proyectos
La gestión ágil de proyectos comienza con la premisa de que los proyectos de software son impredecibles y que el mercado va a generar cambios inciertos. Esto implica que los requerimientos van a cambiar durante el ciclo de vida del proyecto.
Como en estas condiciones no tiene sentido fijar el alcance, se pone al tiempo y al costo como restricciones principales. Los Stakeholders analizan el tiempo y el dinero que están dispuestos a invertir para poner el producto en el mercado.
Los requerimientos ágiles son escritos como porciones verticales de todo el sistema y se construyen de manera que sean lo más independientes posibles una de otra, lo que permite que cada funcionalidad de priorice de acuerdo a su importancia y no a limitaciones técnicas.
Escribir requerimientos en porciones más pequeñas e independientes es crítico para poder variar el alcance con el menor impacto al proyecto. Los equipos ágiles miden que tan rápido son capaces de completar porciones de funcionalidad para entender cuanta funcionalidad puede ser implementada dentro de los límites de tiempo y dinero.
En la gestión de proyectos ágiles importan dos factores: el tamaño del backlog y la velocity. El backlog es la lista de requerimientos a implementar en el producto y se representa como una colección priorizada por importancia o ROI de funcionalidades listas para ser implementadas mientras que la velocity es la medida en que el equipo puede convertir requerimientos en software funcionando, con calidad integrada.
Gestión de un equipo ágil
Los equipos ágiles toman responsabilidad por entregar y deben estar permitidos de auto-organizarse de manera de maximizar el éxito. El equipo tiene autonomía para decidir como implementar los requerimientos definidos.
Los gerentes pueden ayudar reconociendo el poder de decisión del equipo y entablando un contexto acorde. Gestionar el ambiente para promover las decisiones del equipo y la autonomía siempre que sea posible. Un gerente debe esperar lo mejor de cada persona. Promueve una cultura de equipo que valora a las personas y las relaciones saludables.
A cambio de la autonomía se espera entrega frecuente de software funcionando, siendo ésta la única medida de progreso del proyecto. El equipo se compromete en cada iteración de entregar las funcionalidades planificadas.
Habilidades para un manager ágil
Un manager ágil se basa mucho más en habilidades de facilitación de equipos que en la gestión tradicional. Su rol es el de facilitar las discusiones necesarias entre los miembros del equipo, ayudar a remover impedimentos organizacionales que se interpongan en e camino.
The Radical Management
Steve Denning escribió un excelente libro dirigido a Managers, explicando en profundidad el enfoque requerido para una organización ágil exitosa. En mi otro post «The Radical Management» detalle más sobre el mismo.
Referencias para este Post
Para elaborar este post traduje extractos de los papers «The Agile Executive» de Jim Magers y «The Agile Project Manager» de Mike Cottmeyer, complementado con información de mi experiencia personal.
Damián Buonamico
Twitter: @dbuo
LinkedIn: http://www.linkedin.com/in/buonamico
[mc4wp_form id=»228″]
Camino Ágil 