Para entender el origen de Agile, podemos empezar por la gestión tradicional de proyectos. La gestión de proyectos tradicional, a menudo denominada cascada, es el conjunto rígido de normas y prácticas utilizadas para gestionar proyectos de principio a fin. Se rige por el Project Management Book of Knowledge (el PMBOK), que regula todos los documentos y procesos.
Pero, hasta la versión más reciente, apenas se hablaba del valor. Utiliza sus 370 páginas para guiarte en el proceso de entrega. Y o acabas el proyecto o lo abandonas.
Eso es aterrador. La mayoría de nosotros no estamos construyendo puentes, sino intentando aportar valor en nuestro trabajo al tiempo que respondemos al cambio. El liderazgo no está bien definido y la mayoría de las personas son capaces de desempeñar todas las funciones necesarias. Entra Agile.
Agile se desarrolló como una crítica directa a todo lo relacionado con la gestión de proyectos tradicional. Incluso los valores, sobre los que se construyó el Manifiesto Ágil, se enfrentan a lo que el PMBOK ha dicho durante años. Adivina qué, funcionó. Al confrontar los valores que no se ajustan a las necesidades de un proyecto con un enfoque alternativo, la gente fue capaz de tener éxito. Este es ahora el proceso de pensamiento estándar en la mayoría de los proyectos de desarrollo de software.
No sólo eso, sino que todas las áreas de negocio están viendo los beneficios de utilizar Agile en sus prácticas. Una vez más, Agile no es una cosa, pero se puede resumir mejor como la otra cosa. Es la práctica a utilizar cuando el trabajo tradicional no puede aplicarse a tu situación actual. El manifiesto Ágil comienza con cuatro valores, que independientemente de la práctica, proporcionan orientación sobre cómo gobernar los proyectos Ágiles. ¿Cuáles son los valores Agile?
Para mí, se leen como una súplica a las personas en el liderazgo que se tomaron su tiempo para empoderar a las personas que poseen el trabajo. Cada uno es confrontativo, exigente y proporciona un camino claro para lo que los desarrolladores quieren del liderazgo. Su trabajo puede allanar el camino para que cada área de negocio desafíe el statu quo y adopte un nuevo enfoque.
Diferencias entre Agile y Waterfall
A continuación analizamos las diferencias fundamentales entre la gestión de proyectos ágil y la tradicional en cascada.
1. Las personas y la interacción por encima de los procesos y las herramientas
A primera vista, es sencillo. Si valoras y confías en el trabajo de tu gente, podrán hacerlo independientemente de las herramientas. Pero esto se lee como una afrenta directa a las ideas de la Gestión de Proyectos tradicional.
Agile está diciendo a los líderes, que cuando quieren que algo se complete, no pueden dictarse a sí mismos a un objetivo. En su lugar, debe ser colaborativo. Confía en el trabajo que haces y produce algo significativo.
2. Software de trabajo por encima de documentación exhaustiva
En la gestión de proyectos, los resultados provienen del trabajo realizado y los productos terminados. Esto es difícil cuando se trabaja en un entorno dinámico. Las cosas cambian, y los requisitos cambian con ello.
El software es el origen de la iteración, pero está presente en todos los departamentos. El equipo no puede ni debe ser responsable de demostrar su valía. Ese es un proceso de colaboración entre el liderazgo, el equipo y el mundo que va a existir.
3. Colaboración con el cliente por encima de la negociación del contrato
Hablando de colaboración, este punto debería ser muy importante. La mayoría de las personas que hacen el trabajo de entrega no entienden el proceso de negociación de contratos. La colaboración es clave cuando los cambios son frecuentes y necesarios. Muchas personas no tienen una idea clara de lo que quieren, en lugar de basarse en ideas. Permita que el sistema de producción de incrementos de entregables ayude a las partes interesadas a ver lo que es posible. Esto puede ayudar a la colaboración.
4. Responder al cambio en lugar de seguir un plan
Esta es la mayor razón por la que Agile es ahora una práctica reconocida y celebrada. Esta es la razón singular por la que los desarrolladores de software querían cambiar el sistema, pero todos los departamentos toman nota. El mundo en el que vivimos necesita responder al cambio. Los clientes cambian, las partes interesadas cambian y eso está bien. Deja que ocurra y apóyate en ello. Después, encuentra la forma de establecer un proceso para crecer a partir de esos cambios.
No todas las prácticas Agile funcionarán en todos los departamentos. En lugar de eso, deja que sea el marco que ofrezca una alternativa a un enfoque probado para hacer realidad el trabajo que quieres que ocurra. Encuentre lo que necesita cambiar y permita que un proceso impulsado por las personas le haga avanzar.
Si desea obtener más información sobre Agile, consulte nuestras próximas clases o ponte en contacto¡!
