Planificar un proyecto en base a actividades es como seguir un manual de instrucciones paso a paso para armar un mueble de IKEA. No puedes saltarte ningún paso o modificar el orden de las instrucciones, porque sino te arriesgas a terminar con un mueble desastroso. Por otro lado, planificar un proyecto en base a funcionalidades es como construir un rompecabezas. Cada pieza es importante para completar el rompecabezas, pero se pueden mover y ajustar sin afectar las otras piezas. De esta manera, se puede tener flexibilidad para adaptarse a los cambios y evolucionar el proyecto a medida que se desarrolla.
Dado que al universo no le importan nuestros planes, las organizaciones necesitamos adoptar nuevas formas de desarrollar e implementar nuevos productos, servicios e iniciativas. En los últimos 20 años nos hemos dado cuenta de que no podemos seguir implementando iniciativas de la misma forma que lo hacíamos en los años 50. Primero que nada, el mundo va mucho más rápido que antes. Segundo, nos hemos dado cuenta de que la certidumbre no existe más que en los planes. Y tercero, las técnicas de implementación ágil nos han mostrado que planear de forma flexible y adaptable no se contrapone con lograr nuestros objetivos dentro del tiempo y presupuesto estimados.
El Manifiesto Ágil nació en 2001 de una reunión de expertos en desarrollo de software. Los enfoques tradicionales de planeación eran costosos y lentos, y no siempre satisfacían las necesidades del cliente. El grupo decidió crear un framework más ágil que permitiera la flexibilidad y adaptabilidad de los equipos. El Manifiesto Ágil establece los valores y principios fundamentales del desarrollo ágil de software. Uno de estos valores es la aceptación de cambios en los requisitos del cliente, incluso en etapas avanzadas. Los métodos tradicionales asumen que se deben definir todas las actividades desde el inicio, lo que es imposible en un mundo cambiante. La capacidad de evolucionar en tiempo real es una ventaja competitiva para las organizaciones y les permite ser más responsivos a las necesidades cambiantes de los usuarios finales.
Uno de los cambios de paradigma más importantes que propone este manifiesto es la planificación en función de las necesidades del cliente, en lugar de planificar actividades secuenciales detalladas. Los métodos ágiles proponen planear funciones en lugar de actividades, ya que los productos y servicios son un conjunto de funciones que satisfacen las necesidades de los clientes. Una analogía útil es la fabricación de un rompecabezas. Bajo un método tradicional, se define la imagen, se consigue el cartón, se imprime la imagen, se cortan las piezas, se embolsan y luego se empacan. Bajo un esquema ágil, se desarrolla pieza por pieza, permitiendo que la imagen evolucione durante el proceso. Cada pieza es una funcionalidad independiente que entrega valor en sí misma.
Los métodos tradicionales usan una gráfica de Gantt para mostrar la secuencia de actividades a realizar. La herramienta que viene a sustituir a esta gráfica es el project backlog. Este enlista funcionalidades a desarrollar en lugar de actividades. Esto permite priorizar cuáles son las que más valor entregan al usuario final en menor tiempo, y de esta forma el usuario recibe valor desde antes de que el producto o servicio esté finalizado. De hecho, la implementación ágil parte de la idea de que las cosas nunca están terminadas, solamente mejoran en el tiempo. Desde este punto de vista, todo lo que se desarrolla es modular y, por lo tanto, más flexible y ágil.
Planear funcionalidades utilizando un backlog tiene ventajas sobre planear actividades usando una gráfica de Gantt. Primero, porque las actividades se definen con detalle desde el principio, mientras que las funcionalidades se detallan hasta que se trabajan. Segundo, porque las actividades dependen unas de otras, mientras que las funcionalidades son completamente independientes. Tercero, porque las actividades de un proyecto no permiten adaptarse al entorno, mientras que las funcionalidades pueden cambiar o ser desechadas. Cuarto, debido a que las actividades no se pueden poner a prueba hasta el final, mientras que las funcionalidades se prueban antes de ser lanzadas. Quinto, las actividades no entregan valor hasta el final, mientras que las funcionalidades ofrecen valor a medida que se van liberando.
