Los Project Managers (PM) tradicionales suelen mirar a las metodologias agiles como algo raro, distinto y, por lo tanto, las encaran con desconfianza. Y es que, realmente, son un enfoque completamente distinto al sugerido por las metodologias tradicionales (o "pesadas", como se les dice desde en el mundo ágil). Sin embargo, es posible encontrar algunos puntos de encuentro, un área común desde donde poder comenzar un dialogo, y empezar a caminar un recorrido distinto para la gestión de proyectos.
Este artículo intenta encontrar ese punto en comun y acompañar a los PM hacia un primer vistazo a una alternativa cada vez más utilizada en todo el mundo para la gestión de proyectos de sistemas.
Un enfoque distinto
Como dijimos, existen puntos de encuentro entre las metodologías pesadas y las ágiles. Empezando por el obvio: ambos mundos persiguen el objetivo de poder crear software de calidad que satisfaga las necesidades del cliente.
Pero no nos engañemos, porque las metodologías ágiles encaran este problema desde un enfoque completamente distinto al tradicional. A diferencia de las técnicas tradicionales, las metodologías ágiles tienen como prioridad a la gente, y no al proceso. Lo importante son las personas trabajando juntas, colaborando entre ellas para la creación de software (o cualquier otra cosa). El proceso (Scrum, XP, o el que sea) es importante, pero más lo son las personas que lo llevan adelante. El proceso por si mismo es algo inerte, un concepto sin vida ni funcionamiento propio. Son las personas que lo adoptan quienes se potencian con el proceso y generan algo de valor.
Por lo tanto, es necesario tener un profundo conocimiento de la gente que llevará adelante el proceso, para que el mismo sea exitoso. Constantemente se debe motivar a las personas, entenderlas y liderarlas hacia sus objetivos. El líder motivador es un elemento esencial para mantener al equipo unido, creativo y enfocado.
Este enfoque constante en la gente es, a mi entender, la principal diferencia con otras metodologías. Primero se prioriza a las personas, recién luego aparecen los reportes. El tener en claro la principal fuente de atención logra poner en perspectiva lo realmente importante, que además es lo éticamente correcto: ayudar a las personas, acompañarlas en su crecimiento, ocuparse de ellas. Lograr incorporar esta filosofía es un cambio radical y de resultados sorprendentes.
Prioridades del proyecto
Los PM tradicionalmente utilizan el conocido triángulo de hierro para comprender las variables de su proyecto. Suelen partir de un alcance conocido ("quiero un sistema que haga A, B y C"), y con estos datos negocian costo y tiempos.
Sin embargo, el mundo cambiante en el que vivimos demostró las falencias de este enfoque. El cliente no suele conocer completamente el alcance, y muchas veces tan sólo tiene una vaga idea de sus necesidades. Luego, el cálculo de los costos y tiempos quedan completamente errados.
Las metodologías ágiles fomentan invertir el triángulo, dejando al cliente las variables que más domina. El cliente ya conoce el costo (cuánto dinero dispone!), y la fecha (para ayer!). Queda entonces negociar el alcance. En ágil, el cliente y el equipo negocian el alcance continuamente, iteración a iteración.
El cliente periódicamente, al final de cada iteración, recibe un incremento del producto de valor, que lo ayuda a continuar formando el rumbo y alcance final de su sistema. El cliente determina la importancia de cada característica de su producto, y decide en qué se trabajara en cada iteración. El cliente está en control del alcance.
El cliente puede decidir terminar el proyecto en cualquier momento, quedándose con partes ya terminadas del mismo, las cuales son con calidad productiva y utilizables. De hecho, puede seguir formando el producto (y su alcance) hasta que se alcance un resultado "lo suficientemente bueno" para su situación. O puede dirigir al equipo a un nuevo desafio que surge por cambios en el mercado. El cliente está en control del costo.
Por último, el cliente recibe periódicamente incrementos del producto, y puede decidir qué nuevas funcionalidades se agregaran en cada iteración. Además, estas decisiones las puede cambiar en cualquier iteración, al ver la evolución real del producto. El cliente está en control de los tiempos.
|
Triángulo Tradicional |
Triángulo Ágil |
En resumen, las metodologías ágiles incluyen al cliente dentro del proceso, pasa a ser protogonista (y responsable) de su producto. Toma decisiones, ve resultados y es quien determina el alcance, costos y tiempo que le dedicará al proyecto.
Planificando el comienzo
Todo suena muy bien, pero ¿cómo comenzar? Mi sugerencia para empezar un proyecto ágil es usar la misma filosofía que impulsan las metodologías ágiles: simplemente hacerlo. La exploración es fundamental para el aprendizaje; no hay ningún libro ni charla que pueda reemplazar a la experiencia real de llevar un proyecto ágil.
Y lo mejor, empezar con ágil es facil: se va avanzando paso a paso, resolviendo los temas y aprendiendo a medida que van surgiendo los distintos acontecimientos. En ágil, en vez de planear todo el camino y recorrido hacia la meta, nos vamos adaptando hacia ese final, haciendo camino a medida que avanzamos. Sólo planificamos cada iteración, ya que reconocemos nuestra imposiblidad de ver el futuro (¡aunque nos gustaría!).
Esto no quiere decir que no tengamos una estrategia, o que no sea importante. Pensamos y establecemos una estrategia, pero reaccionamos ante la realidad. Para esto planificamos continuamente, utilizando técnicas rápidas y útiles para el equipo.
El equipo
Como vimos, en ágil nos enfocamos primero en las personas. Nos importan las personas, y confiamos en ellas. Buscamos crear una nueva relación de confianza dentro del equipo, y entre el equipo y el cliente, haciendo de la sinceridad un valor fundamental para el equipo.
Debido a esta confianza, y apuntando a motivar y dar responsablidades, dejamos que el equipo se auto-gestione, elija sus tareas y forma de resolverlas, evitando así perder tiempo en la microgestión. Las mismas personas planifican su día, avanzan y se coordinan entre ellas. Más aún, es el propio equipo quien estima el tiempo que le llevará realizar las tareas. Es decir, ni el cliente ni el PM estiman, sino el propio equipo, quienes estarán todos los días trabajando en las tareas.
Fomentamos la participación de todos, en especial del cliente, a quien invitamos a las reuniones de planificación y estimación. Todos los demás interesados también estan invitados a unirse y participar en las reuniones.
Somos transparentes, exponemos y reaccionamos ante la realidad. No ocultamos los problemas, sino que los enfrentamos.
Estrategia y táctica
Como vimos, en ágil nos enfocamos en la planificación de una única iteración (la que comienza), lo que nos permite adaptarnos rápidamente al cambio. De esta manera evitamos perder tiempo en costosas sesiones de estimación y planificación que luego, inevitablemente, tienen que replantearse.
Sin embargo, planificamos estratégicamente junto al cliente para poder establecer un aproximado de cuántas iteraciones existirán, y cuando se produciránn los release a producción. Y ante todo, primamos el reaccionar a la realidad a seguir el plan.
Por otro lado, es el propio equipo quien crea la planificación táctica para resolver la iteración en curso, separando las historias en tareas más pequeñas y manejables.
Gestión de integración
Existen varios conceptos que utilizan las metodologías tradicionales que tienen un equivalente ágil, o al menos una forma de encarar la misma problemática.
| Metodologías tradicionales | El enfoque ágil |
| Planificación del proyecto | Planificación de la iteración y de los release |
| Ejecución del plan del proyecto | Trabajo diario en cada iteración |
| Dirigir, administrar, monitorear, controlar | Facilitar, inspeccionar, adaptar |
| Proceso para Control de Cambios | Backlog priorizado de historias |
Calidad del producto
Los PM tradicionales suelen tener tres etapas básicas que apuntan a mantener la calidad del desarrollo: "Planificación de Calidad", "Aseguramiento de la Calidad" y "Control de la calidad".
En ágil nos preocupamos por la calidad del desarrollo continuamente. De hecho, planificamos la calidad al utilizar técnicas como TDD, que nos permita tener calidad desde el principio. En ágil, la calidad no es un proceso separado e independiente, sino que es una parte intrínseca del propio desarrollo. Creamos un producto de calidad desde el primer día, utilizando técnicas y herramientas que nos faciliten este objetivo (generalmente TDD como práctica, y herramientas como Integración Continua, Checkstyle y Cobertura).
Por último, controlamos la calidad a través de las reuniones de Revisión (o demo) y Retrospectiva.
Resumen
En las empresas con metodologías en cascada es común encontrar a project managers con enfoques más tradicionales. Sin embargo, es posible encontrar puntos en común para comenzar a avanzar juntos hacia un enfoque con más valor para el cliente, comenzado los primeros pasos para agilizar la organización en cascada.
En resumen, las metodologías ágiles (como Scrum) son un enfoque para construir software basados en el Valor, en estrecha colaboración con el cliente e incorporando contínuamente el cambio. Se podría entonces listar algunas características fundamentales de una metodología ágil:
- proceso iterativo e incremental.
- mejora continua de las personas y el proceso.
- calidad desde el primer día.
- priorización de requerimientos de acuerdo a su valor para el cliente.
- equipos dedicados y auto-gestionados.
- estrecha y continua colaboración con el cliente.
- incoporación del cambio como una realidad.
- utilización de práctias de ingenieria modernas.
