REDPIXEL - stock.adobe.com
Una inmersión profunda en la gestión ágil de proyectos
En este video, Samuel Brown nos explica a detalle cómo pueden las organizaciones empezar a trabajar con un enfoque ágil, qué recursos se requieren, cuáles son los roles del equipo, y más.
TechTarget presenta este video sobre la gestión ágil de proyectos a través de una asociación con Global Knowledge. A continuación, presentamos una transcripción (editada, por motivos de extensión) de los puntos más relevantes expuestos en el video.
Mi nombre es Samuel Brown. Estoy ubicado en Raleigh, Carolina del Norte. He estado con Global Knowledge durante aproximadamente 15 años y he estado en el campo de la gestión de proyectos y la capacitación durante varias décadas.
Al hablar sobre la Gestión Ágil de Proyectos, primero hay que describir qué es Agile, de qué se trata y cómo se aplica en la gestión de proyectos.
Agile es un grupo de metodologías. No es una metodología. Hay muchos ejemplos diferentes, pero todos comparten dos cosas en común. Todos valoran una mentalidad pragmática y todos valoran y brindan un enfoque flexible para satisfacer las expectativas de nuestros accionistas. Agile se desarrolló a partir del desarrollo de software y hay varios sabores o metodologías, por así decirlo, bajo el paraguas Agile. Probablemente esté familiarizado con algunos, siendo Scrum uno de los más populares. Pero la programación extrema (XP), Lean, Kanban, todos están relacionados bajo este paraguas Agile.
Cuando hablamos de la mentalidad pragmática en mi empresa, realmente reconocemos que, al principio, no sabemos mucho. Sabemos menos de lo que necesitamos saber para planificar de manera eficaz, por lo que no tiene sentido intentar hacer una planificación detallada por adelantado. A medida que hacemos las cosas, aprendemos. Y no solo aprendemos, sino que nuestro cliente aprende. Por lo tanto, lo que nuestro cliente nos dice que quieren por adelantado es lo que quieren según su mejor conocimiento y su mejor capacidad para describirlo en ese momento. Pero a medida que empezamos a trabajar con ellos, van a aprender cosas, van a entender cosas que no entendían antes y eso va a cambiar su forma de ver, su forma de describir lo que necesitan al final y eso nos va a ayudar.
Entonces, desde un punto de vista Ágil, debemos pensar en los proyectos como una asociación entre nosotros y el cliente. Necesitamos adaptarnos a los cambios que probablemente sucedan a través de la comprensión evolutiva del cliente, y entender que nuestros equipos trabajarán de manera más eficiente cuando puedan tener cierta autonomía y cierto control en la forma en que trabajan.
Pero una parte importante de la mentalidad pragmática es reconocer que no deberíamos tratar de controlar algo que no es controlable, como los cambios, y, por lo tanto, acortar nuestro horizonte, enfocarnos en planificar solo lo que sabemos, lo que significa unos días, unas pocas semanas, tal vez un mes o dos o tres en el futuro, porque eso es realmente todo lo que podemos saber con un alto grado de confianza.
Entendiendo los principios del Manifiesto Agile
Los procesos y las herramientas son importantes, pero desde una perspectiva Ágil, las personas y las interacciones con esas personas son más importantes. La documentación es importante, pero es más importante que el software funcione. Las negociaciones contractuales, obviamente, son importantes, pero la colaboración con el cliente es más importante. Y ser capaz de responder al cambio y seguir adelante es más importante que ceñirse a un plan estricto.
La planificación es importante, la planificación es necesaria, pero es más importante ser flexible y adaptable que ceñirse rígidamente a un plan. A partir de esta lógica se desarrollaron los 12 principios del Manifiesto Ágil, con un enfoque en satisfacer al cliente; aceptar el cambio a medida que avanzamos; entregar software de forma incremental que funcione; trabajar con las partes interesadas para comprender lo que quieren, lo que necesitan y cómo esas necesidades evolucionan y cambian; trabajar con personas motivadas, miembros motivados del equipo y conseguirles un entorno que apoye ese tipo de motivación; tratar con las personas cara a cara es más eficaz que tratar con ellas de forma desconectada. En la mayor medida posible, deberíamos hacer nuestros proyectos Agile de forma conjunta. No siempre es posible y Agile funciona para la colaboración virtual, pero el principio es trabajar juntos.
La Gestión Ágil de Proyectos (APM), entonces, es la forma en que intentamos implementar el manifiesto y los 12 principios. Aunque surgió del desarrollo de software, es útil en todo tipo de entornos, industrias y proyectos. La gestión de proyectos ágil debe ser pragmática; reconocer lo que no sabemos, que siempre deberíamos estar aprendiendo; que el cambio no será predecible ni controlable; y que la Ley de Murphy está viva y siempre en funcionamiento. Y tenemos que ser flexibles. Necesitamos tomar las cosas que aprendemos y ver cómo se pueden aplicar a lo que estamos haciendo y cómo lo estamos haciendo. Y el objetivo de esa adaptabilidad, esa flexibilidad, siempre se centra en asegurarnos de que estamos satisfaciendo a nuestro cliente.
Roles del equipo ágil
Hay algunos roles de rutina bastante comunes que vemos en entornos y equipos Agile. Uno de ellos es el Scrum Master, quien debe permanecer al frente del equipo e identificar las cosas que podrían interferir con la capacidad del equipo para funcionar, identificar los obstáculos organizacionales y trabajar para eliminar esos obstáculos y sacarlos del camino del equipo.
El entrenador Agile trabaja con el equipo, brinda orientación, se enfoca en desarrollar a las personas dentro del equipo, asesorarlas y garantizar una buena aplicación de las prácticas ágiles.
El propietario del producto es algo así como un patrocinador del proyecto. Ellos definen cuál es la necesidad que estamos tratando de satisfacer, y ayudan a asegurarnos de que, a medida que hacemos el trabajo, nos mantengamos encaminados con esa visión.
Y luego, por supuesto, el equipo y los miembros dentro de ese equipo son los que están tomando la comprensión de esa visión y definiendo lo que se necesita hacer para implementarla.
Finalmente, el gerente de proyecto actúa como el coordinador entre el Scrum Master, el entrenador, el propietario del producto e incluso el equipo, para garantizar que no dupliquemos, que no seamos redundantes y que sea capaz de funcionar en colaboración de la manera más eficaz y eficiente posible.
Cabe resaltar que el entrenador no solo capacita al equipo, también entrena a otras partes interesadas clave en el proyecto Agile. Colabora con el equipo y el cliente, se asegura de que entendamos lo que quieren, que nos estamos adaptando a ello, que podemos descubrir cómo lograr técnicamente lo que el cliente quiere, que estamos enfocados en la excelencia mientras lo hacemos, y que lo hacemos dentro de nuestros principios y prácticas Ágiles. Pero también necesita entrenar al propietario del producto sobre lo que significa ser propietario del producto, qué se espera del propietario del producto, cuál es la relación entre el propietario del producto y el equipo y entrenarlo para que comprenda que es el portavoz, el representante de la comunidad de usuarios o los clientes a los que el proyecto intenta entregar.
Además, el coach también necesita trabajar con la alta dirección para ayudarle a comprender los principios y prácticas de Agile y para ayudar a gestionar las expectativas de la alta dirección en torno a lo que Agile puede y hará y cómo se va a producir. El entrenador, entonces, debe tomar lo que está haciendo el equipo, cómo lo está haciendo, dónde está, y comunicarlo al propietario del producto, a la alta dirección y a otras partes interesadas en términos comerciales, en términos del valor de lo que hace el equipo para la organización. El entrenador necesita trabajar para resolver conflictos de recursos, problemas de disponibilidad, problemas de coordinación entre esos recursos y ser el animador del trabajo que está haciendo el equipo, hablarlo, resaltar sus éxitos, resaltar sus logros, y luego protegerlos de la interferencia externa con lo que el equipo está tratando de hacer.
En resumen: el entrenador, al igual que en un equipo deportivo, asegura la eficacia, facilita la colaboración, elimina obstáculos y proporciona la interfaz desde el proyecto hasta la organización. El equipo hace las cosas, colabora entre ellos, se enfoca en producir cosas que funcionen y en ser autogestionado y autodirigido. El propietario del producto establece la visión, define el estado futuro que estamos tratando de lograr, identifica, prioriza nuestros requisitos y luego es el punto de responsabilidad en un proyecto Ágil.
Sentando las bases
Una vez definidos los roles del equipo, ¿cómo empezamos? Bueno, comenzamos definiendo la visión. ¿Qué queremos al final? ¿Qué necesitamos para llegar allí? ¿Por qué necesitamos ese producto al final? ¿Qué tipo de limitaciones, recursos, tiempo, tal vez dinero? ¿Cuánto vamos a intentar hacer? Y luego, basándonos en esa definición de alcance de alto nivel y de grano grueso, necesitamos una estimación de alto nivel. ¿Cuánto tiempo creemos que llevará cumplir la visión? ¿Cuántas publicaciones de resultados funcionales produciremos sobre la marcha que, en última instancia, encajarán para cumplir la visión?
Y eso debe expresarse fácil y claramente. Piense en ello como un discurso de ascensor, donde necesita comunicar seis componentes en una breve explicación: ¿Para quién estamos haciendo esto? ¿Que necesitan? ¿Cómo llamamos a lo que estamos trabajando? ¿Cuáles son los beneficios de esto? ¿Qué lo hace diferente de lo que tenemos? ¿Y qué lo hace diferente de otras cosas que podríamos tener?
Bueno, ahora que tenemos una visión, tenemos la lista de trabajo y las prioridades, ¿cómo definimos las iteraciones de trabajo? El primer paso es planificar la meta. ¿Qué queremos lograr en la próxima semana, o dos, tres o cuatro, dependiendo de la duración de nuestras iteraciones? Una vez que hayamos definido nuestro objetivo, seleccionaremos historias que se alinearán con ese objetivo y comenzaremos a desglosar esas historias para identificar lo que se necesita hacer. Y luego el equipo va a auto-seleccionar quién hace qué. Y aquellos que son dueños de cada tarea estimarán el esfuerzo en esa tarea, y luego el equipo buscará tratar de equilibrar la carga de trabajo entre ellos si es necesario, en la medida en que lo necesiten. Cabe destacar que, si bien el enfoque está en las historias de alta prioridad, es importante dar seguimiento a otras historias si tenemos tiempo libre en la iteración.
Los planes de actividades de cada iteración deben darnos suficiente tarea como para que no se postergue el enfoque de las cosas. Básicamente, la idea de que el plan de iteración sea agresivo es que queremos evitar la ley de Parkinson, según la cual el trabajo siempre se expandirá para cubrir el tiempo disponible. Bueno, si tengo un plan agresivo, entonces el Parkinson no nos va a molestar mucho porque no hay tiempo extra disponible para expandir el trabajo.
Ahora que tenemos un plan para la iteración, necesitamos ejecutar el plan, hacer el trabajo y desarrollar el incremento del producto. Aquí es donde dividimos nuestras historias de usuario en requisitos detallados. Eso significará colaboración con nuestro cliente y esa colaboración será directa entre el cliente y los desarrolladores, los que hacen el trabajo. Necesitamos enfocarnos en la calidad. Necesitamos asegurarnos de adoptar un enfoque multifuncional e incluir todas las diferentes disciplinas, todas las diferentes perspectivas para que lo que entregamos no solo funcione, sino que también funcione en la producción.
Y necesitamos saber, a medida que el equipo hace el trabajo, que se cumple con esos criterios. No es un objetivo en movimiento. Es algo que hemos identificado, definido y acordado y ahora tenemos que cumplirlo. Y vamos a realizar esas reuniones diarias para revisar nuestro estado, identificar obstáculos y planificar lo que sigue. Deben ser breves, deben tener una agenda ajustada y debemos ceñirnos a la agenda y ceñirnos al propósito de la reunión.
A menudo el equipo y el entrenador son los únicos que necesitan estar en esas reuniones. Si necesitamos información del propietario del producto, si queremos informar o hacer preguntas a otra parte interesada, ellos también pueden estar allí, pero es una reunión de 15 minutos y se centra en estos tres puntos de la agenda: ¿Qué se ha hecho? ¿Qué vamos a hacer ahora? ¿Y qué obstáculos tenemos que sacar del camino?
Parte de esta revisión de la iteración también es lo que normalmente llamamos lecciones aprendidas: necesitamos ver lo que hicimos durante esa iteración y lo que funcionó, lo que no funcionó y lo que podría mejorarse. Y vamos a capturar eso y luego eso se convierte en una entrada para planificar la próxima iteración. Así, Agile se alinea muy bien con la idea de mejora continua. Estamos haciendo breves períodos de trabajo, identificamos nuestras fortalezas, nuestras debilidades, nuestros bordes de crecimiento en cada iteración y aplicamos lo que hemos aprendido en la siguiente iteración para no repetir nuestros errores y estamos mejorando a medida que avanzamos.
Conclusión del proyecto
Una vez que una tarea se acepta, se considera completa. Si se acepta, pero necesita un pequeño ajuste, aún se completará, pero creamos una nueva historia de usuario y la agregamos a la lista de trabajos pendientes para esos ajustes. Si es aceptable, pero nos ha hecho darnos cuenta de que hay otras cosas que desearíamos tener, entonces se completa y se crean nuevas historias de usuarios para abordar esas ideas. Si es aceptable y hemos ido más allá con una nueva historia de usuario, se completará y la nueva historia entrará en la lista de trabajos pendientes. Sin embargo, si la historia es rechazada o no acertamos del todo en el blanco, entonces trabajamos para reescribir la historia del usuario para reflejar mejor lo que el cliente necesita y lo volvemos a poner en el backlog. Si la historia es rechazada porque lo que la historia abordó no es algo que realmente necesitamos, lo borramos y agregamos una nueva historia a la acumulación para anular ese incremento.
Las revisiones deben ocurrir entre cada iteración, no solo al final del proyecto.
Finalmente, cabe destacar que la disponibilidad del tipo de recursos que necesitamos afectará la capacidad del equipo para hacer el trabajo. Los cambios se reflejarán a través de nuevas estimaciones, estimaciones revisadas, historias revisadas, etc., en nuestra cartera de pedidos y en modificaciones del ritmo de nuestro trabajo, pero debido a nuestros cortos ciclos de trabajo, podemos adaptarnos a estos cambios a medida que avanzamos en el proyecto. Y así, nos adaptamos al cambio a medida que pasamos de iteración en iteración a la siguiente iteración. Pero tenemos que trabajar dentro de nuestras limitaciones, y lo hacemos ajustando los requisitos, las funciones y enfocándonos en la capacidad del equipo para ser lo más productivo posible.
