h1

The Software Project Manager’s Bridge to Agility

01/12/2012

Wizbook [Icon By Buuf]  Libros.

La esencia de la gestión de proyectos:

Bueno – Barato – Rápido.

Escoge dos.

— Desconocido.

El libro The Software Project Manager’s Bridge to Agility de Michele Sliger y Stacia Broderick es una buena guía para aquellos administradores de proyecto que utilizan técnicas provenientes del Project Management Body of Knowledge – PMBOK y deseen conocer la diferencia entre la forma en que actualmente llevan sus proyectos y la administración ágil. El tema central del libro consiste en mapear las diferentes áreas del PMBOK a sus contrapartes ágiles, identificando los procesos y herramientas de los que se hace uso. Por ejemplo, la gestión de alcance (Scope Management) pasa a ser una planeación de características a realizar (product backlog), definiendo qué se hará durante cada iteración del proyecto (sprint backlog) como herramienta de ejecución y control.

Nota: Para efectos de la certificación como PMI-ACP, los dos capítulos más importantes del libro son aquellos relacionados con la gestión de riesgo y la gestión de la comunicación. Por ello los incluyo como parte de esta reseña.

Gestión de la comunicación

De acuerdo al PMBOK, la gestión de la comunicación emplea una serie de procesos que aseguren en tiempo y forma la apropiada generación, recolección, distribución, almacenamiento, recuperación y disposición de la información relacionada al proyecto. En la administración tradicional, esto se logra a través de un plan de comunicación de proyecto donde se determina quién, cómo y cuándo se comunicará la información relacionada al proyecto, incluyendo procesos de escalamiento, reuniones de seguimiento y otras medidas de reporteo de estatus de tareas o desempeño del equipo de trabajo.

Según el libro, la gestión ágil debe enfatizar la confianza entre los diferentes participantes del proyecto, alineando sus intereses y buscando obtener retroalimentación temprana para evitar confusión y riesgos innecesarios. Así, un administrador de proyectos ágil no gestiona la comunicación, sino que facilita y comprende el poder de la gente en grupo para tomar decisiones sobre situaciones que afectan al proyecto. Esto se logra al resaltar el intercambio de información frente a frente, ya que muchas metodologías tradicionales confían tan sólo en el intercambio de documentación. El propio PMBOK destaca la importancia de esta clase de comunicación, porque “las reuniones presenciales son el medio más efectivo para comunicarse y resolver problemas con los stakeholders.”

Face-to-face communication

La comunicación cara a cara es el medio más efectivo para comunicar el avance del proyecto, determinar riesgos y sus posibles soluciones. (Fuente: Gigaom.com)

Desde un principio, es necesario identificar a quiénes es necesario comunicar el avance del proyecto, mostrándoles la mecánica de distribución de la información. Las metodologías ágiles poseen tres herramientas específicas para este fin:

• Reuniones diarias. Cada miembro del equipo se sincroniza con los demás, anunciando sus dependencias y obstáculos, comprometiéndose a tomar acción para resolver las tareas que él o ella se ha auto-asignado. Es necesario recordar al equipo que esta reunión no es para resolver los problemas o reportarse ante el project manager, sino para facilitar la comunicación entre ellos mismos.

• Retrospectivas. Durante estas reuniones, el project manager busca recopilar información que ayude a mejorar el proceso – qué funcionó y qué no – para adaptar la mecánica de ejecución e implementar la siguiente iteración con una mayor efectividad y eficiencia. En algunos casos será necesario redactar un documento formal para discutir estos problemas con la gerencia, especialmente si éstos se encuentran fuera de la capacidad del equipo.

• Radiadores de información. Los radiadores se componen de gráficas, tablas, tableros o cualquier otro despliegue que muestre el estatus actual del proyecto: plan de liberación, plan de la iteración actual, demostraciones, método de comunicación de tiempo, alcance y riesgo. Una herramienta mostrada de manera indirecta en el libro es una “bitácora de seguimiento”, que en realidad es un wiki usado para listar los problemas o contener la documentación del proyecto.

Gestión del riesgo

Según el PMBOK, los objetivos de la gestión del riesgo son incrementar la probabilidad e impacto de eventos positivos al mismo tiempo que se disminuye la probabilidad e impacto de eventos adversos al proyecto. Siendo uno de los capítulos más importantes del libro, éste define cómo las metodologías ágiles “fomentan la gestión de riesgos de manera orgánica, como un hecho intrínseco del ciclo de vida de desarrollo.” A continuación se enumeran los riesgos más comunes al emprender un proyecto y cómo son mitigados por las metodologías ágiles:

• Falla de programación intrínseca (Intrinsic Schedule Flaw). Estimaciones erróneas e inalcanzables desde el día uno, generalmente basadas en buenos deseos. Al hacer el cambio a ágil, no es posible eliminar esta tendencia, ya que muchos proyectos son aceptados debido a estimaciones ideales de costo y tiempo. Sin embargo, al utilizar las herramientas apropiadas, es posible detectar estimaciones inválidas con rapidez, permitiendo modificar el tamaño de la liberación. Entre dichas herramientas las más importantes son que el mismo equipo sea dueño de sus propias estimaciones y que el project manager lleve un seguimiento de la velocidad de ejecución (ver más abajo), para detectar cualquier desviación del plan original.

• Desglose de la especificación (Specification Breakdown). Falla al lograr un consenso entre los stakeholders sobre qué hay que construir. Esto se mitiga al tener un dueño único del producto (product owner), cuya responsabilidad sea determinar qué debe hacer el producto, cómo debería verse y cuál debe ser su desempeño. También puede mitigarse este riesgo a través de un método denominado “desarrollo basado en características” (Feature-Driven Development), que se enfoca en desarrollar software orientado a cumplir con funcionalidad de valor al cliente (las características o features).

• Arrastramiento de alcance (Scope Creep). Requerimientos adicionales que inflan el alcance inicial, postergando la fecha de liberación o provocando la así denominada “marcha de la muerte“. En ágil, el cambio es aceptado como parte del desarrollo de software, sin embargo es necesario recordar a los stakeholders que cambios adicionales afectarán al plan de liberación inicial: por ello es muy importante tenerlo siempre a la vista y revisarlo al final de cada iteración – para recordar a todos cuál es el objetivo final del proyecto.

• Pérdida de personal (Personnel Loss). Una buena parte de la gente que abandona un proyecto lo hace debido a una moral muy baja, por lo que facilitando la auto-organización del equipo y proporcionar mayor empowerment mejorará en gran medida esta situación. Adicionalmente, los equipos ágiles comparten continuamente su conocimiento, a través de la comunicación frente a frente; por ello, todos los miembros del equipo se vuelven “expertos” en el sistema. Esta transferencia de conocimiento ayudará a mitigar la pérdida de personal.

• Variación de la productividad (Productivity Variation). Diferencias entre el desempeño esperado del equipo contra el real. La variación de la productividad se puede medir con un concepto denominado “velocidad de ejecución“. Primero, el equipo proporciona su propia estimación y en base a la información histórica de dos o tres iteraciones, es posible obtener la cantidad promedio de entregables que se pueden terminar por cada iteración. El Planning Poker es una herramienta especialmente efectiva para estimar mientras que la “tabla de quemado” (burn down chart) es la mejor manera de determinar la productividad a lo largo del tiempo.

El proceso de gestión de riesgo cambia radicalmente entre el PMBOK y las metodologías ágiles. Tradicionalmente, los stakeholders requerían varias reuniones con el afán de obtener un documento de gestión de riesgos, que incluía roles y responsabilidades, presupuesto, calendario de revisiones, definiciones, medidas, matrices de impacto y probabilidad, formatos de reporteo y actividades de seguimiento. Esto se simplifica en las metodologías ágiles, ya que lo primordial es definir cómo se identificarán, rastrearán y atacarán los diversos riesgos presentes en un proyecto conforme se vayan presentando. La identificación de riesgos es más fácil de realizar durante el inicio y fin de cada iteración (risk audit) así como en cada reunión diaria; es posible detectar problemas potenciales haciendo simples preguntas como “¿bajo qué supuestos estamos trabajando?” y “¿a qué retos te enfrentarás el día de hoy?”. Luego, esta información debe recopilarse y mostrarse a todos los stakeholders en un pizarrón o panel. El equipo definirá su criticidad en conjunto con el product owner a base de juicio, intuición y experiencia (análisis cualitativo) dejando cualquier compromiso derivado de esta discusión en el panel de tareas. Para llevar a cabo el adecuado seguimiento se utiliza una “tabla de quema de riesgo” (risk burn down chart) que muestre cuántos problemas han sido resueltos y cuántos faltan por hacer.

Risk burn down chart

Un risk burn down chart. La gráfica muestra los problemas encontrados a lo largo del proyecto (verde), los problemas que se van creando día a día (azul), la tendencia de disminución (rojo) y el número de impedimentos que deberían estar mitigándose día con día (naranja) para llevar a cabo un buen control del riesgo. (Fuente: Atlassian.com)

(Click en imagen para ver a mayor escala)

Conclusiones

Este libro está orientado a los PMPs certificados, explicando por qué “ágil” no es sinónimo de chambón o informal, derribando los más grandes mitos relacionados a este tipo de metodologías:

• Ágil significa “cero documentación” o “codificación sin control” (Cowboy coding).

• Pensar que es posible implementar prácticas individuales de la metodología ágil aquí y allá obteniendo los mismos beneficios.

• Creer que la metodología ágil sólo tiene que ver con el equipo de ingeniería sin afectar al resto de la organización.

• Creer que por usar ágil el equipo puede decir “Lo tendremos cuando terminemos. Ahora sólo planeamos una iteración a la vez”.

• Suponer que ser ágiles significa decir al equipo “Ustedes ya son auto-organizados. Arréglenselas como puedan“.

De hecho, muchos project managers asumen que el desarrollo en cascada es la mejor manera de terminar un proyecto. Sin embargo, esto se dio porque en aquél entonces – 1987, año en que fue publicada la primera edición del PMBOK – éste modelo era el de mayor adopción, pero en ningún lugar del PMBOK se propone a la cascada como la mejor solución y tampoco se opone al uso de modelos iterativos e incrementales de desarrollo; por ello, las metodologías y procesos ágiles también pueden ser considerados parte, aunque sea de forma indirecta, de sus mejores prácticas. Por lo tanto es muy recomendable leer este libro, ya que ilustra de forma relativamente breve las diferencias y similitudes entre las metodologías ágiles y el PMBOK y dará a entender a PMPs y administradores tradicionales que ágil no es “un juguete”, sino que es una excelente opción en proyectos para hombrecitos.

One comment

  1. […] (por ejemplo, la “puerta del refrigerador” es mejor conocida como “radiadores de información” en el ámbito ágil), todos estos patrones permiten mejorar la productividad del equipo, […]



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: