9 EJEMPLOS DE METODOLOGÍA DE UN PROYECTO,

SIMPLIFICADOS

La metodología de un proyecto se mantiene en constante evolución, con Agile, Scrum,

Kanban, Lean, XP, Waterfall, PRINCE2 y PMBOK, por lo que puede ser confusa. En esta
guía de metodologías de gestión de proyectos, haremos que todo sea muy simple de entender.
Hay montones de diferentes metodologías de gestión de proyectos que podrías aplicar a
diferentes proyectos, pero saber cuáles son las diferencias entre ellas y cuál es la metodología
correcta al momento de precisar cómo hacer un proyecto puede ser complicado.
Lee esta guía para obtener una descripción general de las metodologías de administración de
proyectos más utilizadas y piensa cómo puedes aprovecharlas mejor para determinar cómo
elaborar un proyecto, los pasos para hacer un proyecto y entregarlo en el mundo de las
agencias digitales.

Visión general de los tipos de metodologías de administración de proyectos:

 Agile: colabora para entregar de forma iterativa cualquier trabajo

 Scrum: permite que un equipo pequeño, multifuncional y autogestionado entregue rápido

 Kanban: mejora la velocidad y la calidad de la entrega al aumentar la visibilidad del trabajo en

progreso y limitando la multitarea.

 Scrumban: limita el trabajo en progreso, como Kanban, con una reunión diaria como Scrum

 Lean: racionaliza y elimina lo innecesario para ofrecer más con menos

 XP: Metodología de Programación Extrema – Realiza desarrollo robusto para garantizar la

calidad

 Waterfall: planifica los proyectos por completo y luego ejecuta las fases

 PRINCE2: gestión de proyectos controlada que no deja nada al azar.

 PMBOK de PMI: aplica estándares universales a la gestión de proyectos en Waterfall

 Introducción A Las Metodologías De Gestión De Proyectos
Tratemos de entender qué es una metodología de gestión de proyectos. El concepto de
metodología de gestión de proyectos brindado por el PMI es útil: ‘Una metodología es un
sistema de prácticas, técnicas, procedimientos y reglas utilizadas por quienes trabajan en una
disciplina’, pero una metodología debe estar arraigada en algo más fundamental que dicte
por qué eliges hacer las cosas de cierta manera, por lo que sugiero que también debería incluir
temas.
Como gerentes de proyectos, hay muchas maneras diferentes de entregar proyectos. En
términos generales, estas formas son nuestras metodologías: aplicar diferentes principios,
temas, marcos, procesos y estándares para ayudar a estructurar la forma en que entregamos
los proyectos.

Algunas metodologías de gestión de proyectos simplemente definen principios, como Agile.

Otros definen un marco de metodología de ‘pila completa’ de temas, principios, procesos y
pasos para elaborar un proyecto, como Prince2. Algunos son una lista extensa de estándares
con algún proceso, como PMBOK o XP de PMI y algunos son muy ligeros, y simplemente
definen el proceso, como Scrum.

Metodologías Comunes De Gestión De Proyectos

Metodología Agile: colabora para entregar de forma iterativa cualquier trabajo
Comencemos con la palabra de moda favorita de todos, Agile. La verdad es que Agile no es
en realidad una metodología de un proyecto, sino un conjunto de principios para desarrollar
software. Los principios se describen en el manifiesto ágil que describe cuatro valores:
individuos e interacciones por encima de procesos y herramientas; Software de trabajo por
encima de documentación completa; Colaboración del cliente por encima de negociación de
contratos; Responder a los cambios por encima de seguir un plan, por lo que ser ágil es más
una filosofía y un conjunto de valores y principios a seguir, en lugar de un proceso para
aplicar a un proyecto.
Cuando las personas hablan de una metodología ágil de gerencia de proyectos, lo que
generalmente describen es un proceso de diseño y construcción flexible e iterativo. Los
proyectos ágiles se caracterizan por una serie de tareas que se conciben, ejecutan y adaptan
según lo requiera la situación, en lugar de un proceso pre-planificado. Ser ágil ayuda a los
equipos a responder a la imprevisibilidad a través de procesos de trabajo incrementales e
iterativos.
De la misma manera en que un buen cocinero prueba la comida a medida que la cocina y
agrega ingredientes faltantes a medida que avanza, un proceso ágil de gestión de proyectos
requiere que los equipos de proyectos pasen por un proceso de planificación, ejecución y
evaluación a medida que avanzan.
Agile es diferente de otros métodos de administración de proyectos que generalmente asumen
que las cosas que afectan al proyecto son predecibles, por lo que enfatiza la adaptabilidad a
situaciones cambiantes, la comunicación adecuada y continua entre el equipo del proyecto y
entre ellos y el cliente. Las metodologías ágiles son excelentes para usar en entornos
dinámicos donde existe la posibilidad de cambiar requisitos, como el desarrollo de software
y juegos.
Como conjunto de principios, Agile es el más grande, y tiende a utilizarse como un término
general para sus implementaciones, como Scrum, Extreme Programming (XP), Kanban y
Scrumban. En resumen, y para hacer las cosas confusas, Agile no es una metodología de un
proyecto o proceso que puedes usar; si estás de acuerdo con los principios, aún necesitas
definir los procesos para entregar proyectos.

Metodología Scrum: permite que un equipo pequeño, multifuncional y autogestionado

entregue rápido
Scrum es una metodología de administración de proyectos que propone principios y procesos
para mejorar la entrega. Dentro del desarrollo de software, Scrum es uno de las estructuras
más populares y sencillas para poner en práctica los principios de Agile.
El objetivo de Scrum es mejorar la comunicación, el trabajo en equipo y la velocidad de
desarrollo.
Scrum no es realmente una metodología de gestión de proyectos, sino una estructura para el
desarrollo y mantenimiento continuo de productos complejos. Scrum es un enfoque ligero y
define un conjunto simple de roles, reuniones y herramientas para entregar de manera
eficiente, iterativa e incrementalmente una funcionalidad valiosa y distribuible.
Fundamentalmente, Scrum trata de capacitar a un equipo autogestionado para cumplir y
definir roles y responsabilidades para crear una tensión saludable entre entregar lo correcto,
de la manera correcta, lo más rápido posible.
Scrum aboga por el uso de un equipo pequeño y multifuncional de hasta 9 personas que
trabajan en artículos en una cartera de pedidos (una colección de historias de usuario
(requisitos)) que han sido definidos y priorizados por el Propietario del Producto.
El trabajo se divide en “iteraciones”, un ciclo de desarrollo de generalmente de 2 a 4 semanas,
durante el cual se llevan a cabo “scrums” (reuniones) diarios donde el equipo informa sobre
el progreso y los obstáculos. Al final de cada iteración, el trabajo se revisa en una reunión de
demostración de requisitos completados, para determinar, junto con el propietario del
producto, si pasa la definición de finalización (DoD).
Scrum es facilitado y atendido por un Facilitador (Scrum Master), que habilita y dirige los
scrums, la demostración de los requisitos completados y las revisiones, lo que lleva al equipo
de desarrollo a hacer su mejor trabajo, así como a una ‘retrospectiva’ después de cada
iteración, para garantizar que el equipo esté en continua mejora y optimización.
Scrum se diseñó originalmente para el desarrollo de software, por lo que si bien hay artefactos
ágiles de scrum que se pueden aprovechar, Scrum no encaja perfectamente en el mundo de
las agencias, el cual usualmente es más estratégico y creativo. Incluso en los proyectos web
de la agencia, los presupuestos fijos, los plazos y el alcance proporcionan una falta de
flexibilidad para un equipo de scrum autogestionado, en un proyecto con un principio y un
final definidos.
Esto no quiere decir que no funcione en proyectos de desarrollo: los gerentes de proyectos
de las agencias pueden actuar como facilitadores y los clientes como propietarios de
productos en un equipo híbrido. Pero normalmente es más complicado que eso, con
presupuestos y alcance fijos que brindan fuertes restricciones. Es por eso que muchas
agencias toman algunos de los conceptos de scrum: equipos pequeños, autoorganizados,
multifuncionales, presentaciones diarias, demostraciones de progreso y retrospectivas, y los
utilizan en algún tipo de enfoque híbrido.

Metodología de Kanban: mejora la velocidad y la calidad de la entrega al aumentar la

visibilidad del trabajo en progreso y limita la multitarea.
Kanban es una metodología de gestión de proyectos centrada en los principios Lean y un
proceso estricto para aumentar la eficiencia. Es similar en muchos aspectos a Scrum: todo
busca lanzar los proyectos temprano y, a menudo, con un equipo colaborativo y
autogestionado. Pero en comparación con Scrum, Kanban es un cambio más evolutivo, y es
un aterrizaje más suave en el mundo de Agile, ya que es menos prescriptivo.
Kanban es ligero en el proceso, es flexible, no tiene roles prescritos y simplemente intenta
mejorar el rendimiento aumentando el enfoque del equipo en las cosas realmente importantes.
Las prácticas principales son visualizar el flujo de trabajo, limitar el trabajo en progreso,
medir el tiempo de entrega, hacer que las políticas de proceso sean explícitas y evaluar
continuamente las oportunidades de mejora.
El enfoque de Kanban está en el trabajo que se libera continuamente, más rápido y con mejor
calidad. Es ideal para entornos operativos o de mantenimiento donde las prioridades pueden
cambiar con frecuencia. Kanban se centra en medir el tiempo de entrega: cuánto tiempo
demoras, después de ser informado, en entregar.
Con Kanban, los gestores de proyectos suelen usar notas adhesivas en una ‘pizarra Kanban’
o en una herramienta en línea como Trello a través de un diagrama de Gantt, para representar
el flujo de trabajo del equipo, con categorías tan simples como “Tareas pendientes”, “En
proceso” y “Hechas”.
Esto visualiza lo que quieres hacer y limita el trabajo en progreso (WIP) para que el flujo de
trabajo mejore a medida que mides y optimizas el tiempo promedio para completar los
elementos.
También le da al equipo una presentación visual de lo que viene a continuación, lo que facilita
la reorganización, la resolución de problemas del proceso y previene que las tareas se
estanquen. También les ayuda a ver cómo cualquier nueva tarea puede afectar el trabajo en
curso.
Kanban está bien adaptado para trabajos que requieren un rendimiento constante, como
producción o soporte y mantenimiento. Dentro del mundo de las agencias, también puede ser
una herramienta útil, ya que es más complaciente con los cambios, y a los clientes les gusta
cambiar de opinión constantemente. Si Scrum te parece un enfoque demasiado rígido para el
desarrollo de un proyecto, pero quieres ser ágil’, Kanban es una alternativa más simple.

La metodología de Scrumban: limita el trabajo en progreso como Kanban con una reunión
diaria como Scrum
Scrumban es una metodología de gerencia de proyectos híbrida relativamente nueva que
combina un enfoque mixto de scrum y Kanban para la gerencia de proyectos. Toma la
flexibilidad de Kanban y agrega parte de la estructura de scrum para crear una nueva forma
de administrar proyectos.
En lugar de trabajar en iteraciones con tiempo limitado y potencialmente restrictivas,
Scrumban utiliza un principio de planificación a pedido para completar el trabajo acumulado
y las tareas son asignadas por el equipo que las realiza, ya que pueden acomodarlas, como en
Kanban. Esto significa que el trabajo en progreso es limitado y el equipo de desarrollo se
mantiene enfocado en la tarea en cuestión en lugar de preocuparse por la reunión de revisión
y por lo que el equipo se comprometió a entregar en la iteración.
Sin embargo, no todo es Kanban: Scrumban conserva el “scrum diario” con revisiones y
retrospectivas para mejorar el proceso que solo se usan cuando es necesario. Además, sin la
restricción de las iteraciones, la planificación se realiza según sea necesario en lugar de
alrededor de una iteración, lo que ahorra tiempo.
Scrumban realmente sólo agrega algo de flexibilidad a Scrum eliminando las iteraciones y
permitiendo un enfoque adaptativo a la planificación. O podrías verlo también como añadir
una estructura muy necesaria a Kanban con reuniones que pueden ayudar con la colaboración
y la optimización del proceso.
Scrumban puede ser bueno para el desarrollo de proyectos o productos donde hay una visión
poco clara, donde hay requisitos en evolución o no hay una hoja de ruta clara y si el proceso
necesita incluir trabajo de soporte y mantenimiento en el proceso.

Metodología Lean: racionaliza y elimina lo innecesario para entregar más con menos
Lean es una metodología de gestión de proyectos centrada en el tema de la eficiencia. Podría
decirse que es “el Padrino de Agile” – Lean se trata de hacer más con menos. Comienza por
identificar el valor y luego lo maximiza a través de la mejora continua al optimizar el flujo
de valor y eliminar lo innecesario.
Es un tema con principios, en lugar de una metodología de un proyecto que dicta procesos y
cosas que hacer. Sugiere que puede hacer más con menos abordando las tres disfunciones
que generan desperdicios; Muda, Mura y Muri, también conocidos como las 3Ms.
Muda se trata de erradicar el proceso de eliminación de desperdicios o cualquier cosa que,
en última instancia, no agregue valor al cliente. En el mundo digital, esto podría ser eliminar
las rondas de revisiones.
Mura se trata de eliminar variaciones: eliminar la sobrecarga que crean las variaciones en el
proceso estándar. Para nosotros, esto podría significar la estandarización de informes y
procesos de aprobación.
Muri trata de eliminar la sobrecarga: la capacidad óptima es trabajar al 60-70%; Más que eso,
y todo se ralentiza. Podríamos aplicar esto para minimizar la cantidad de proyectos que
intentamos ejecutar a través de la agencia.
Lean se enfoca en cambiar la forma en que operamos para concentrarnos en la entrega de
valor. Se trata de cambiar el enfoque de la optimización de tecnologías separadas, activos y
departamentos verticales a la optimización de los proyectos de flujo a través de flujos de
valor completos que fluyen horizontalmente a través de tecnologías, activos y departamentos
para los clientes.
Lean puede ser una mentalidad útil a adoptar cuando revises el proceso de entrega de tu
proyecto: piensa cómo puedes volver a desviar el proceso de tu proyecto a lo esencial que
ofrece valor y eliminar las cosas que son solo pelusas, o la forma en que siempre lo has hecho
– y estarás pensando en Lean.

XP – Metodología de programación extrema: realiza el desarrollo de manera robusta para

garantizar la calidad
Extreme Programming (XP) es una metodología de administración de proyectos de
desarrollo de software que define valores y procesos para mejorar la calidad del software y
garantizar la capacidad de respuesta a la evolución requerimientos del cliente. Los valores o
principios son muy similares a scrum, en torno a la simplicidad, la comunicación, la
retroalimentación, el respeto y el coraje.
Donde realmente se desvía de Scrum es en la definición de reglas o procesos prescriptivos.
Algunos de estos son similares a Scrum, pero existen reglas en torno a las prácticas técnicas
relacionadas con el diseño, la codificación y las pruebas que lo hacen específico para
proyectos de desarrollo. Estas reglas incluyen hacer obligatorio; Incluir historias de usuario,
desarrollo impulsado por pruebas (TDD), programación de pares e integración continua,
entre muchos otros.

Metodología de Waterfall: la planificación completa de proyectos, luego la ejecución a

través de las fases
Waterfall, a menudo denominada “Ciclo de Vida del Desarrollo de Software” (SDLC, por
sus siglas en inglés) es una metodología de gestión de proyectos con un enfoque muy simple
que valora la planificación sólida, hacer las cosas una vez y hacerlas bien, en lugar del
enfoque ágil de la entrega incremental e iterativa. Es fácil de entender, pues simplemente
haces un buen plan y lo ejecutas.
El administrador del proyecto tiende a estar a cargo, y el trabajo se planifica ampliamente
por adelantado y luego se ejecuta, en estricta secuencia, cumpliendo con los requisitos, para
entregar el proyecto en un solo ciclo, generalmente muy largo.
Los requisitos se definen en su totalidad al principio, en la parte superior de la cascada, antes
de comenzar cualquier trabajo. El trabajo luego cae en cascada, como el agua en una cascada
a través de las fases del proyecto. En un modelo de Waterfall, cada fase debe completarse
antes de que la siguiente pueda comenzar y no haya superposición en las fases. Normalmente,
en un enfoque de Waterfall, el resultado de una fase actúa como entrada para la siguiente fase
de forma secuencial.
Una vez que se aprueba el plan, hay poco margen para adaptarlo -a menos que sea
absolutamente necesario-, y los cambios que son necesarios generalmente requieren de
solicitudes. El proyecto luego fluye a través del proceso desde los requisitos, hasta el diseño,
la implementación, las pruebas y el mantenimiento.
Debido al enfoque de ciclo único, en un proyecto de Waterfall, hay poco margen para reflejar,
revisar y adaptar una vez que haya completado algo. Una vez que estás en la etapa de prueba,
es muy difícil regresar y cambiar algo que no estaba bien diseñado en la etapa de concepto.
Tampoco hay nada que mostrar al cliente a medida que avanzas. Completas el proyecto con
una gran fanfarria y rezas para que al cliente le guste. Eso es muy arriesgado.
Waterfall generalmente es visto con cierto desdén dentro de las agencias como un enfoque
de gestión de proyectos tradicional, ineficiente y obsoleto. Pero Waterfall puede ser un
enfoque útil y predecible dependiendo de la naturaleza del proyecto: si los requisitos son
fijos, están bien documentados y son claros, la tecnología se entiende y está madura, el
proyecto es corto y no se gana ningún valor adicional al “ser ágil”. Un enfoque de Waterfall
en realidad puede proporcionar un resultado final más predecible para el presupuesto, el
calendario y el alcance.

Metodología PRINCE2: gestión de proyectos controlada que no deja nada al azar

PRINCE2 es una metodología de gestión de proyectos en cascada de “pila completa” que
incluye principios, temas y procesos. Fue creada por el gobierno del Reino Unido en 1996
originalmente para proyectos de TI. “PRINCE” significa “Proyectos en entornos
controlados”. Es una metodología muy orientada a los procesos, que divide los proyectos en
múltiples etapas, cada una con sus propios planes y procesos a seguir. La metodología define
entradas y salidas para cada etapa de un proyecto para que nada quede al azar.
El sistema enfatiza la justificación del curso realizado por una empresa, por lo que el primer
paso es identificar una necesidad clara para el proyecto, quién es el cliente al que va dirigido,
si existen beneficios realistas y una evaluación de costos exhaustiva. Una junta de proyecto
es propietaria del proyecto y es responsable de su éxito. Esta junta define las estructuras para
el equipo, mientras que el gerente de proyecto supervisa las actividades diarias de nivel
inferior. Esta metodología se basa en ocho procesos de alto nivel y brinda a los equipos un
mayor control de los recursos y la capacidad de reducir el riesgo de manera efectiva.
Como metodología de un proyecto, es increíblemente exhaustiva: es una estructura excelente
para ejecutar proyectos empresariales grandes y predecibles. Aclara lo que se entregará,
asegura un enfoque en la viabilidad del proyecto, define claramente los roles y
responsabilidades, las partes de un proyecto, respalda la gestión por excepción (posiblemente
un principio ágil) y de manera similar a PMBOK, proporciona un vocabulario común que
podemos aplicar a otras metodologías. Por otro lado, mientras que los principios y los temas
son excelentes, el proceso puede hacer que sea laborioso y oneroso para proyectos pequeños.
PRINCE2 está diseñado para proyectos de TI a gran escala, por lo que nunca funcionaría en
una agencia como una metodología de gestión de proyectos. Sin embargo, el énfasis en
desarrollar un buen modelo comercial con KPI’s y el valor ganado, roles y responsabilidades
claras, administrar cambios y riesgos es útil cuando consideramos administrar proyectos para
nuestros clientes.

Metodología PMBOK del PMI: aplicación de estándares universales a la gestión de

proyectos en cascada
La metodología de gerencia de proyectos del PMI (Project Management Institute) no es
realmente una metodología, sino un conjunto de estándares que se refieren a los cinco pasos
para realizar un proyecto, que describen su Project Management Body of Knowledge
(PMBOK). Estos son iniciar, planear, ejecutar, controlar y cerrar.
Esto no es tanto una metodología de un proyecto como un marco de estándares,
convenciones, procesos, mejores métodos, terminologías y pautas que se aceptan como
estándares dentro de la industria de la administración de proyectos. Contiene muchos
procesos y técnicas de administración de proyectos para evaluar o completar la forma en que
ejecutas tus proyectos o la metodología que utilizas.
Es, por lo tanto, más teórico, una guía de referencia, en la que puedes verificar que, aunque
popular en TI, realmente no va bien en el mundo de las agencias. Realmente no puedes
ejecutar un proyecto PMI o PMBOK, pero puedes aprovechar los estándares para crear un
lenguaje universal y los mejores métodos para un proyecto. Al comparar con PRINCE2,
posiblemente podrías pensar que PMBOK y PRINCE2 de PMI son complementarios entre sí
en lugar de dos enfoques de cascada diferentes o separados.
Esta no es, de ningún modo, una lista exhaustiva de metodologías de gestión de proyectos.
Existen metodologías como el Método Crystal, en el que los procesos del proyecto reciben
una prioridad baja, mientras que se enfatiza en la comunicación del equipo, las habilidades
de los miembros del equipo, las personas y la interacción; o la metodología del Marco
Adaptativo, en la que el alcance del proyecto es variable, pero el tiempo y el costo son
constantes, lo que hace posible ajustar el alcance del proyecto durante la ejecución para
obtener el máximo valor de negocio del proyecto. Otros como PRiSM, Critical Path, PERT
y muchos más existen, pero no son tan relevantes para el mundo de la gestión de proyectos
en las agencias.

En Conclusión
Elegir la metodología de un proyecto más adecuada puede ser complicado. Depende de tantas
variables, muchas de las cuales están fuera de nuestro control.
Pero lo que realmente importa es mirar más allá de la “guerra territorial” entre las
metodologías de la industria. Las metodologías de gestión de proyectos son solo herramientas
para ayudarnos a entregar proyectos. Realmente no vale la pena discutir sobre los detalles de
cada una; en lugar de eso, deberíamos centrarnos en el panorama general. Ya sea Kanban,
Waterfall o algún otro método, en realidad no importa.
Lo que importa es el compromiso de hacer un trabajo de calidad, que satisfaga las
necesidades de los usuarios y ofrezca un gran valor a nuestros clientes.
La mejor metodología de un proyecto es aquella que mejora continua y orgánicamente, se
adapta y, a través de una colaboración sólida, aumenta el valor de la producción, por lo que
la suma es mucho mayor que las partes.
Es una metodología que sorprende y deleita al cliente al entregar valor con frecuencia y
hacerlo bien. Y para hacer esto, debes ser pragmático, en lugar de dogmático acerca de la
metodología que utilizas.