Enumera tu ABC: Aprende administración de proyectos ágiles

La mayoría de los proyectos se manejan actualmente utilizando una metodología de proceso tipo cascada, la cual es lógica y está ordenada por un conjunto de pasos con roles establecidos y responsabilidades para que el equipo de proyecto pueda generar resultados que se reflejen en la calidad de los proyectos entregados a tiempo y en presupuesto. Pero de acuerdo con el Desarrollo Ágil e Iterativo, el uso de la metodología de cascada se ha convertido en poco atractiva desde que:


1.Los usuarios no siempre están seguros de lo que ellos quieren, y una vez que ven el trabajo, ellos van a solicitar cambios

2.Los suficientes detalles de trabajo generalmente llevan a la necesidad de un sofisticado sistema integrado de la administración del cambio antes de que el nuevo detalle de trabajo pueda avanzar

3.Hay un gran impacto de riesgos en este método ya que el trabajo se retrasa dentro del ciclo del proyecto lo que a menudo puede conducir a sobrepasar los costos y el tiempo

Otros de los factores que también son importantes para la administración de proyectos a pesar de la metodología de procesos que pueden llevar al proyecto al fracaso, son:

1.Grandes proyectos (por ejemplo más de 10 millones de dólares y un equipo de más de 100 personas) no tienen mejor oportunidad para lograr el éxito que un proyecto de menor tamaño (por ejemplo menos de un millón de dólares y menos de 20 individuos en el equipo del proyecto)

2.El cambio de los requerimientos abarca alrededor del 25% del tiempo

3.Más del 50% de las solicitudes no son usadas
La administración de proyectos de forma ágil es una de varios esquemas iterativos y adaptivos de proyectos, enfoques diseñados para entregar el máximo valor de negocios a los clientes dentro de los límites de las restricciones de tiempo y costo. En cada iteración, el alcance es ajustado en función de los requerimientos de valor de negocio del dueño del producto.

Dentro de la enseñanza tradicional del PMBOK® la relación de la triple restricción del alcance, tiempo y costo está conectada por liberaciones basadas en la función. Cuando una variable de las restricciones cambia, las otras dos también deben ser revisadas determinando su impacto en el acuerdo de liberación de las entregables prometidos. Pero con el método ágil, la triple restricción es al revés ya que el ámbito de aplicación (un conjunto de características) se acuerda firmemente, antes de que comience el trabajo, por un presupuesto preestablecido (costo) y el calendario (tiempo). Si lo acordado se expande en un conjunto de características, entonces los costos y el tiempo harán lo propio. Este método reduce el riesgo y mejora de forma predecible. Cuando otra variable se introduce, generar una modificación en los costos y el tiempo, ampliando así los factores de cambio dentr del proyecto.


Esto significa que las fechas de entrega pueden ser recortadas al igual que la reducción de costos para la optimización del valor del proyecto: entregar el valor más alto incrementa la funcionalidad, primeramente. Además de, dejar de entregar incrementos cuando el valor de la oportunidad en menor que el costo y dejar de entregar incrementos cuando el valor de la oportunidad es mayor que el valor marginal del siguiente incremento.

El pensamiento ágil fue inspirado por W. Edwards Deming quien debe de sonar familiar si se conoce de la técnica de desarrollo del PMBOK® de los ciclos Planear-Hacer-Revisar-Actuar (PDCA, por sus siglas en inglés). Agile, fue primeramente estructurado en 1986 por las compañías Fuji y Honda de Japón cuando sus altos directivos decidieron construir productos de manera diferente con el fin de:

•Utilizar pequeños equipos multi-funcionales (personas y su rango interacciones sobre los procesos y herramientas)

•Utilizar pequeñas (generalmente 30 días) restricciones del tiempo máximo para trabajar todos los desarrollo (trabajar rangos de software sobre una completa y rápida documentación fuera de fecha)

•Utilizar una mejor filosofía de dirección que cambia a lo largo del camino (La colaboración de los clientes en la negociación del contrato)
Metodología Scrum

Así que, ¿qué es Scrum?. Proviene de un término utilizado en el rugby donde una “scrum” una táctica con ese nombre es usada para reiniciar el juego después que un evento generó su paralización. Cada equipo oponente se forma en un muro humano de tres jugadores de profundidad, empujando el uno contra el otro para patear el balón fuera de su lado. En este contexto, cobra mayor valor el trabajo en equipo y de fortaleza. Si hacemos la analogía con el desarrollo de software, Scrum está basada en múltiples equipos pequeños trabajando de una forma intensa e interdependiente para entregar un software. El flujo de procesos de Scrum está estructurado en ciclos de trabajo llamados “Sprints” y generalmente duran de dos a cuatro semanas. Al inicio de cada Sprint, los equipos seleccionan las características de una cartera de productos priorizados con la intención de desarrollar el primero y más importante (de acuerdo a su valor para el negocio). Un equipo de Scrum pleno tiene más o menos siete miembros, incluyendo al dueño del producto, el ScrumMaster y al equipo de desarrollo.

Si eres un project manager tradicional, ¿dónde colocas tu función en el flujo de procesos de Scrum?. Esto te asigna en el papel de ScrumMaster pero hay algunas diferencias claves en las responsabilidades de un jefe de proyectos tradicional. La responsabilidad del ScrumMaster es en gran parte indirecta, ya que facilita la probabilidad del éxito ayudando al dueño del producto a seleccionar los requerimientos más valiosos que ayuden al equipo a convertir esos requisitos en una funcionalidad valiosa para el producto.

El ScrumMaster es el responsable de enseñar el proceso de Scrum a todos los involucrados al proyecto y debe asegurar que cada uno siga las prácticas y las reglas del Scrum. El equipo de desarrollo central de Scrum es un grupo enfocado al flujo de procesos y sabe lo que se necesita hacer, y no se les dice lo que está hecho por una planificación extensiva y los requerimientos del alcance dentro de una metodología de cascada. El equipo es autogestionado, auto organizado y transversal, también es responsable de determinar cómo convertir los requerimientos en un incremento de funcionalidad con el Sprint. El ScrumMaster es un papel clave para facilitar las reuniones de planificación Scrum, las reuniones diarias de Scrum, Sprint y la reunión de revisión.

Autora: Mary Ann Crow - Es PMP certificada, quien actualmente se dedica a preparar a las personas para los exámenes de certificación como PMP y CAPM, a través de cursos desarrollados completamente por ella misma. Cuenta con 28 años de experiencia en Análisis ede Negocio y Administración de Proyectos dentro de la industria de las telecomunicaciones, específicamente en AT&T, donde ejecutó proyectos exitosos.