PILAR — Metodologías de gestión de proyectos: cuál usar según tu equipo

Antes de evaluar cualquier metodología, respondé dos preguntas:

1. ¿Sé hoy exactamente qué hay que entregar, o lo voy a descubrir en el camino? Si lo sabés, cascada. Si lo vas a descubrir, Agile.
2. ¿El equipo trabaja mejor con ritmos fijos o con flujo continuo? Si el equipo necesita checkpoints regulares para no perder foco, Scrum. Si prefiere no interrumpir el trabajo artificialmente, Kanban.

Todas las metodologías son respuestas a estas dos preguntas. Lo demás (ceremonias, artefactos, roles) es implementación. Elegir la metodología equivocada porque "es la que se usa" en tu industria es la forma más rápida de crear burocracia sin resolver el problema real.

Waterfall planifica todo el proyecto antes de empezar y ejecuta en fases secuenciales: requisitos → diseño → desarrollo → testing → despliegue. No hay vuelta atrás fácil: si descubrís un problema en desarrollo, te cuesta cambiar requisitos porque el diseño ya se aprobó y el presupuesto se asignó.

Cuándo conviene: construcción, cumplimiento regulatorio, migraciones con fecha inamovible, proyectos donde el costo de equivocarse es alto (por ejemplo, hardware). Características clave: alcance fijo, fecha clara, el cliente sabe exactamente qué quiere.

Cuándo NO conviene: productos digitales, marketing, cualquier proyecto donde el feedback del usuario puede cambiar el rumbo. Comparativa completa Waterfall vs Agile.

Agile no es una metodología, es una filosofía: planificamos en ciclos cortos, entregamos valor rápidamente, y ajustamos según lo que aprendemos. Scrum y Kanban son las dos implementaciones más comunes, pero Agile puede ser simplemente "entregar algo cada dos semanas y preguntar al cliente si vamos bien".

Cuándo conviene: productos digitales, marketing, proyectos donde no sabés exactamente qué necesita el usuario hasta que lo ve en acción. Características clave: alcance flexible, feedback temprano, iteración.

Scrum divide el trabajo en sprints de 2-4 semanas. Cada sprint tiene un objetivo claro, una lista de tareas (backlog) y tres ceremonias: sprint planning al inicio, daily standup cada mañana (15 minutos) y retrospectiva al final. Al final del sprint, se entrega algo incrementable — no necesariamente completo, pero funcional.

Cuándo conviene: equipos que se dispersan fácilmente sin ritmos regulares, proyectos donde el stakeholder necesita ver progreso predecible cada sprint. Características clave: tiempo fijo, alcance flexible, roles definidos (Product Owner, Scrum Master, equipo). Ver Qué es Scrum, sin certificaciones para la guía práctica.

Kanban no tiene sprints ni fechas fijas. El trabajo se mueve en un tablero con columnas (por ejemplo, Por hacer / En curso / Hecho) y se aplica el principio de límite WIP (Work In Progress): no se pueden tener más de X tareas en "En curso" a la vez. El límite fuerza a terminar antes de empezar algo nuevo. El foco es el flujo continuo y reducir el tiempo que tarda una tarea en pasar de Por hacer a Hecho.

Cuándo conviene: equipos que trabajan mejor sin interrupciones artificiales, soporte y mantenimiento, proyectos donde las prioridades cambian frecuentemente y no conviene planificar sprints fijos. Características clave: flujo continuo, límites WIP, visualización del trabajo. Ver Kanban en la práctica: límites WIP para cómo implementarlo.

¿Tu proyecto tiene alcance fijo y conocido? → Sí → Waterfall (cascada). No → ¿Tu equipo necesita ritmos fijos? → Sí → Scrum. No → Kanban.

Eso es todo. Las 100 páginas de documentación de cada metodología son para implementar detalles, no para decidir. Si tu equipo ya está usando algo y funciona, no cambies por la guía de otra persona — cambia solo cuando el dolor de la metodología actual sea mayor que el costo de aprender algo nuevo.

La metodología que elijas determina cómo se vive la fase de planificación y seguimiento del proyecto, pero no las fases en sí. Todo proyecto tiene inicio, planificación, ejecución, seguimiento y cierre — la metodología define cuánto tiempo pasás en cada una y con qué herramientas. Lo que no cambia es la pregunta central del seguimiento: ¿vamos a tiempo? Lo que cambia es cómo respondés esa pregunta: con sprints (Scrum), con flujo continuo (Kanban) o con hitos planificados de antemano (Waterfall).