Marcos de gestión de proyectos

📐 Fundamento

Predictivo (waterfall, plan-driven):

[Requerimientos] → [Diseño] → [Construcción] → [Pruebas] → [Despliegue]

Asume: requerimientos estables, predecibles, conocibles al inicio.
Plan completo al inicio, ejecución según plan.

Bueno para: construcción civil, manufactura, sistemas con regulación estricta.
Malo para: software con requisitos cambiantes (la mayoría).

Adaptativo (Agile):

[Sprint 1] → [Sprint 2] → [Sprint 3] → ...
   ↓            ↓            ↓
producto      producto     producto
incremental   refinado     más completo

Asume: requerimientos cambian, descubrimos lo que necesitamos al construir.
Pequeños ciclos, feedback constante, ajustes continuos.

Bueno para: software, productos digitales, innovación.
Malo para: proyectos donde el cambio es prohibitivamente caro.

El espectro:

Más predictivo                                    Más adaptativo
Waterfall ──── PMBOK ──── PRINCE2 ──── SAFe ──── Scrum ──── Kanban ──── XP
   1970         1980         1990         2010      2001       2010      1999

Notar que SAFe es "agile a escala" pero conserva mucho de planning predictivo. Kanban es continuo (sin sprints), más adaptativo.

📐 Fundamento

PMBOK (Project Management Body of Knowledge) del PMI: el marco "tradicional" más conocido.

5 grupos de procesos:

Inicio → Planificación → Ejecución → Control → Cierre

10 áreas de conocimiento:

Documentos típicos PMBOK:

• Project Charter — autoriza el proyecto, define al PM.
• WBS (Work Breakdown Structure) — descomposición jerárquica del trabajo.
• Scope Statement — qué se incluye, qué no.
• Schedule (Gantt) — cronograma con dependencias.
• Budget — costos detallados.
• Risk Register — riesgos identificados y planes de mitigación.
• Stakeholder Register — quién es quién y cómo se comunica.

Crítica común: demasiada documentación, poca flexibilidad. Para software puro, raramente se usa "puro" — más bien se toman conceptos sueltos.

Cuándo PMBOK tiene sentido:

• Gobierno, defensa, salud, infraestructura crítica.
• Proyectos con regulación estricta (FDA, banking, aviación).
• Cuando el contrato exige metodología definida.
• Proyectos físicos con software como un componente.

PMP (Project Management Professional): la certificación. Reconocida globalmente, requiere experiencia + examen.

📐 Fundamento

(Ya cubrimos Scrum en detalle en Ingeniería de Software cap. 2. Recap rápido aquí.)

Roles:

• Product Owner: dueño del producto, prioriza el backlog.
• Scrum Master: facilita, remueve impedimentos.
• Development Team: 3-9 personas, autoorganizado.

Eventos:

• Sprint: ciclo de 1-4 semanas.
• Sprint Planning: ¿qué hacemos este sprint? (max 8h para sprint de 4 semanas).
• Daily: 15 min, sincronización.
• Sprint Review: demo al final.
• Retrospective: ¿cómo mejorar?

Artefactos:

• Product Backlog: todo lo que podría hacerse.
• Sprint Backlog: lo del sprint actual.
• Increment: producto funcionando al final del sprint.

Funciona bien para: equipos pequeños (~7), producto con incertidumbre alta, requisitos cambiantes.

Problemas comunes (Scrum mal aplicado = "Scrum-but"):

• "Hacemos Scrum pero sin Sprint Planning" → no hay foco.
• "Hacemos Scrum pero el PO no decide" → no hay priorización.
• "Hacemos Scrum pero los devs no estiman" → estimaciones top-down sin base.
• "Hacemos Scrum pero los retros no cambian nada" → no hay mejora.

📐 Fundamento

Kanban viene del sistema de producción Toyota. Aplicado a software:

Principios:

1. Visualizar el trabajo (Kanban board).
2. Limitar el WIP (Work In Progress).
3. Gestionar el flujo.
4. Hacer las políticas explícitas.
5. Mejorar continuamente.

Tablero típico:

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ Backlog  │ To Do    │ In       │ In       │ Done     │
│          │ (max 5)  │ Progress │ Review   │          │
│          │          │ (max 3)  │ (max 2)  │          │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│  □       │  □       │  □       │  □       │  □       │
│  □       │  □       │  □       │  □       │  □       │
│  □       │  □       │  □       │          │  □       │
└──────────┴──────────┴──────────┴──────────┴──────────┘

WIP limits son la regla más importante: si una columna está llena, no podés agregar trabajo nuevo ahí — primero hay que mover algo a la siguiente.

Métricas Kanban:

• Lead time: tiempo desde que se solicita hasta que se entrega.
• Cycle time: tiempo desde que se empieza hasta que se entrega.
• Throughput: tareas completadas por unidad de tiempo.
• WIP: trabajo en progreso.

Ley de Little: WIP = Throughput × Lead Time. Reducir WIP → reduce lead time.

Scrum vs Kanban:

Scrumban: combinación, en la práctica muchos equipos usan elementos de ambos.

📐 Fundamento

SAFe (Scaled Agile Framework): para empresas grandes con cientos/miles de devs en muchos equipos coordinados.

Niveles:

Portfolio  ← decisiones estratégicas
   ↓
Solution   ← múltiples ARTs trabajando en una solución grande
   ↓
ART (Agile Release Train)  ← 50-125 personas, 5-12 equipos
   ↓
Team       ← Scrum/Kanban tradicional

PI Planning (Program Increment): cada 8-12 semanas, todos los equipos del ART se reúnen 2 días para planificar juntos. Es la actividad central de SAFe.

Críticas a SAFe:

• "Agile" pero con mucho proceso y jerarquía.
• "Scaled bureaucracy" según los críticos.
• Funciona para algunas empresas grandes, mal aplicado en startups.

Alternativas para escalar agile:

• LeSS (Large-Scale Scrum) — más minimalista, más fiel al espíritu Scrum.
• Spotify Model (squads, tribes, chapters, guilds) — más flexible.
• Disciplined Agile — toolkit de prácticas.

Cuándo SAFe:

• Empresas grandes (1000+ devs).
• Productos complejos con muchos sistemas integrados.
• Cuando ya hay cultura de procesos pesados (transición desde waterfall).

Cuándo NO SAFe:

• Startups, equipos pequeños — overkill total.
• Equipos cohesivos que ya funcionan — agrega burocracia.

📐 Fundamento

La mayoría de proyectos reales no son puros. Combinan:

Waterfall + Agile:

• Planificación a alto nivel waterfall (roadmap del año).
• Ejecución sprint-by-sprint Agile.
• Releases incrementales con milestones.

Scrum + Kanban:

• Scrum para el desarrollo de features.
• Kanban para el equipo de soporte/bugs.

Estimación + descubrimiento:

• Estimación inicial para presupuesto.
• Reajuste continuo basado en velocity real.

Ejemplo: La Esquina Cloud expansión