GESTIÓN DE PROYECTOS · TEMA 15
00

Modelos, Métodos, Artefactos y Enfoque Adaptativo

Repaso interactivo del Tema 15: desde los modelos y artefactos del PMBOK 7 hasta los fundamentos del enfoque ágil y SCRUM. Explora la teoría, practica con simuladores y evalúa tu comprensión con los quizzes.

PMBOK 7ª Edición Enfoque Ágil SCRUM ISIL
8
Temas de repaso
4
Simuladores
18
Preguntas de quiz
32+
Técnicas y artefactos
Mapa de temas
🧩

01 · Modelos

Liderazgo, comunicación, motivación, cambio, complejidad y desarrollo de equipos.

Teoría
🛠️

02 · Métodos

Recopilación de datos, estimación y reuniones/eventos del proyecto.

Teoría
📦

03 · Artefactos

Estrategia, bitácoras, planes, diagramas jerárquicos, informes y contratos.

Teoría
🔄

04 · Adaptativo e Iterativo

Diferencias, aplicabilidad y buenas prácticas de cada enfoque.

Simulador
🚀

05 · Proyectos Ágiles

Qué los define, ejemplos reales y buenas prácticas.

Casos
📜

06 · Enfoque Ágil

Manifiesto Ágil: 4 valores y 12 principios fundamentales.

Teoría
🌐

07 · Áreas de Dominio Ágil

Principios y mentalidad ágil aplicados a la entrega de valor.

Teoría
🏃

08 · SCRUM

Roles, proceso, beneficios y simuladores de decisión.

3 simuladores
1 de 11
FUNDAMENTOS PMBOK · MODELOS
01

Modelos

Vistas simplificadas de la realidad que ayudan a optimizar procesos, dar forma al comportamiento y resolver problemas dentro del proyecto.

LiderazgoComunicaciónComplejidadCambio
Definición

Un modelo refleja vistas simplificadas y en pequeña escala de la realidad, presentando escenarios, estrategias o enfoques para optimizar procesos y esfuerzos de trabajo. Puede dar forma al comportamiento y señalar caminos para resolver problemas o satisfacer necesidades. Algunos fueron desarrollados pensando en proyectos y equipos; otros son de naturaleza más general.

Modelos de liderazgo situacional

Así como los equipos de proyecto adaptan procesos, métodos, ciclos de vida y enfoques de desarrollo, también los estilos de liderazgo se adaptan. Describen formas de ajustar el estilo de liderazgo para satisfacer las necesidades del individuo y del equipo.

💡Un mismo líder puede necesitar ser más directivo con un miembro junior y más delegador con un miembro senior, dentro del mismo proyecto.
Modelos de comunicación

Explican cómo los marcos de referencia del emisor y receptor influyen en la eficacia de la comunicación, cómo el medio influye en ella, y qué desconexiones existen entre la realidad y las expectativas del usuario final.

ModeloDescripción
LinealSe envía un mensaje y el receptor lo interpreta.
InteraccionalSe envía un mensaje, el receptor lo interpreta y da retroalimentación.
TransaccionalNo solo se envía un mensaje y una retroalimentación, sino múltiples al mismo tiempo.
Modelos de motivación

Las personas se desempeñan mejor cuando están motivadas, y se motivan por cosas diferentes. Comprender qué motiva a los miembros del equipo y a otros interesados ayuda a adaptar las recompensas a cada persona, generando un involucramiento más eficaz.

1
Estímulo (causa)
→
2
Necesidad (deseos)
→
3
Comportamiento
→
4
Objetivo
Modelos de cambio

Muchos proyectos implican un cambio de sistemas, comportamientos, actividades y, a veces, culturas. Gestionar este tipo de cambio requiere pensar cómo pasar del estado actual al estado futuro deseado.

Modelo ADKAR (Clear → Aware → Ready → Willing → Able)▼
Alinear a los líderes respecto a objetivos estratégicos, comunicar la visión y el caso de cambio para crear compromiso, traducir la visión en realidad para las personas, mover a la organización al estado deseado entregando las herramientas necesarias, y asegurar que el cambio sea sostenible y los resultados se hayan materializado.
Modelos de complejidad — Matriz de Stacey

Similar al marco Cynefin, examina dos dimensiones para determinar la complejidad relativa de un proyecto: la incertidumbre relativa de las necesidades del producto (requisitos) y la incertidumbre de la tecnología a utilizar. Según la combinación, el proyecto se considera simple, complicado, complejo o caótico.

Modelos de desarrollo de equipo

Los equipos de proyecto se mueven a través de diferentes etapas de desarrollo. Entender en qué etapa se encuentra el equipo ayuda a los directores de proyecto a apoyar su crecimiento y desempeño.

🧭

Aplicación de la Matriz de Stacey

Modelo de complejidad · Diagnóstico de enfoque
Antes de elegir un enfoque predictivo, híbrido o ágil, ubica el proyecto en la matriz según qué tan claros están los requisitos y qué tan conocida es la tecnología. Cuanto más lejos de la certeza en ambos ejes, más ágil debe ser el enfoque.
📌Usa la matriz abajo: selecciona una celda combinando el eje de requisitos (filas) y el de tecnología (columnas), luego verifica la zona resultante.
🎯

Simulador: Matriz de Stacey

Clasifica la complejidad relativa de un proyecto

Eje horizontal: incertidumbre tecnológica (T1=certeza → T5=incertidumbre). Eje vertical: incertidumbre de requisitos (R1=acuerdo → R5=desacuerdo).

Caso: Antamina y un nuevo sistema de monitoreo remotoAplicación
▼
Antamina evalúa implementar un sistema de monitoreo remoto de maquinaria con sensores IoT. La tecnología es nueva para la empresa y los requisitos del área de operaciones todavía no están definidos con precisión.
¿En qué zona de la Matriz de Stacey ubicarías este proyecto? ¿Qué enfoque de gestión recomendarías?
El proyecto se ubica en la zona compleja, pues hay incertidumbre alta tanto en requisitos como en tecnología. Se recomienda un enfoque adaptativo/ágil, con iteraciones cortas que permitan aprender sobre la tecnología y refinar los requisitos progresivamente.
Casos prácticos
BCP — Adaptación del estilo de liderazgo en un equipo mixtoLiderazgo situacional
▼
Un jefe de proyecto de BCP lidera un equipo con dos analistas junior recién contratados y dos especialistas senior con más de 8 años de experiencia en el banco.
¿Qué estilo de liderazgo aplicarías con cada grupo, y por qué?
Con los analistas junior conviene un estilo más directivo/instructivo, dando instrucciones claras y supervisión cercana. Con los especialistas senior conviene un estilo delegador, otorgando autonomía y enfocándose en resultados. Esto ilustra por qué los modelos de liderazgo situacional adaptan el estilo según las necesidades del individuo y del equipo.
Yape — Ruido en la comunicación entre Producto y SoporteModelos de comunicación
▼
El equipo de Producto de Yape comunica un cambio de flujo por correo, sin espacio para preguntas. Soporte al cliente empieza a recibir reclamos porque interpretó el cambio de forma distinta a la intención original.
¿Qué modelo de comunicación se está usando y cuál sería más apropiado?
Se está usando un modelo lineal (mensaje sin retroalimentación), lo cual genera desconexión entre la intención y la interpretación. Sería más apropiado un modelo transaccional, con una reunión donde ambos equipos intercambien mensajes y aclaren dudas en tiempo real.
Preguntas frecuentes
¿Los modelos son obligatorios de aplicar en todos los proyectos?▼
No. El PMBOK 7 presenta los modelos como referencias que los equipos pueden adaptar según las necesidades concretas de su proyecto; no son prescriptivos ni de uso obligatorio.
¿En qué se diferencia la Matriz de Stacey del marco Cynefin?▼
Ambos abordan la complejidad, pero la Matriz de Stacey se centra específicamente en dos dimensiones (incertidumbre de requisitos y de tecnología), mientras que Cynefin trabaja con un espectro más amplio de dominios (simple, complicado, complejo, caótico y desorden) aplicable más allá de la gestión de proyectos.
¿Por qué son importantes los modelos de motivación para un director de proyecto?▼
Porque entender qué motiva a cada persona del equipo permite diseñar incentivos y reconocimientos más efectivos, lo que se traduce en mayor involucramiento, productividad y retención del talento en el proyecto.
¿Todos los modelos de cambio siguen los mismos pasos?▼
No, existen varios modelos de gestión del cambio (como ADKAR, Kotter, Lewin). Todos comparten la idea de pasar de un estado actual a uno futuro deseado, pero difieren en el número y énfasis de sus etapas.
¿Qué pasa si un proyecto cae en la zona "caótica" de la Matriz de Stacey?▼
En la zona caótica, la incertidumbre es tan alta en ambos ejes que no conviene planificar en detalle de inmediato. Se recomienda experimentar rápidamente en ciclos muy cortos para generar aprendizaje y reducir la incertidumbre antes de comprometerse con un plan más estructurado.
2 de 11
FUNDAMENTOS PMBOK · MÉTODOS
02

Métodos

Medios para lograr un efecto, salida, resultado o entregable del proyecto, agrupados según su propósito: recopilación de datos, estimación y reuniones/eventos.

Recopilación de datosEstimaciónReuniones
¿Qué es un método?

Un método es un medio para lograr un efecto, salida, resultado o entregable del proyecto. Muchos métodos se relacionan con el propósito al que sirven —como la estimación o la recopilación de datos— y por ello se presentan agrupados. Otros se relacionan con el tipo de actividad realizada, como reuniones y análisis. El PMBOK no describe cómo ejecutar cada método en detalle, solo su propósito.

1
Observación
→
2
Planteamiento del problema
→
3
Hipótesis
→
4
Experimentación
→
5
Análisis de resultados
→
6
Conclusiones
Recopilación y análisis de datos

Se utilizan para recopilar, valorar y evaluar datos e información con el fin de obtener una comprensión más profunda de una situación.

Análisis de alternativas

Compara opciones viables para elegir la más adecuada.

Análisis de supuestos y restricciones

Identifica y valida supuestos, y explora restricciones.

Estudios comparativos

Compara prácticas reales con las de otras organizaciones.

Análisis de tendencias

Proyecta resultados futuros con base en datos históricos.

Análisis de justificación del negocio

Evalúa si el proyecto sigue siendo viable y valioso.

Hoja de verificación

Lista estructurada para recopilar datos de forma organizada.

Costo de la calidad

Estima el costo total de prevenir, evaluar y corregir defectos.

Estimación

Utilizados para desarrollar una aproximación del trabajo, tiempo o costos en un proyecto.

TécnicaUso
Agrupamiento de afinidadAgrupa elementos similares para estimar por tamaño relativo.
Estimación análogaUsa datos de proyectos similares pasados.
Estimación multipuntoCombina estimaciones optimista, pesimista y más probable.
Punto de funciónMide el tamaño funcional del software.
Estimación paramétricaUsa relaciones estadísticas entre variables históricas.
Estimación relativaCompara el tamaño de tareas entre sí, no en unidades absolutas.
Estimación puntualOfrece un único valor de estimación.
Estimación por punto de historiaUsa "story points" comunes en equipos ágiles.
Wideband DelphiConsenso grupal anónimo e iterativo de expertos.
Reuniones y eventos

Son un medio para involucrar al equipo del proyecto y a los demás interesados.

Revisión del proyecto

Evalúa el avance general del proyecto.

Conferencia de oferentes

Reúne a posibles proveedores antes de licitar.

Comité de control de cambios

Evalúa y aprueba solicitudes de cambio.

Daily Standup

Sincronización diaria breve del equipo.

Planificación de la iteración

Define el alcance del siguiente ciclo de trabajo.

Reunión de estatus

Comunica el avance a los interesados.

Lanzamiento (Kick-off)

Marca el inicio formal del proyecto o fase.

Reunión de lecciones aprendidas

Recoge aprendizajes para futuros proyectos.

Reunión de planificación

Define actividades y responsables.

Cierre del proyecto

Formaliza la finalización del proyecto o fase.

📊

Wideband Delphi para estimación de esfuerzo

Técnica de estimación · Consenso experto
Varios expertos estiman de forma anónima e individual, luego discuten las diferencias y vuelven a estimar en rondas sucesivas hasta converger. Reduce el sesgo de anclaje que ocurre cuando se estima en grupo abiertamente.
✅Es especialmente útil cuando hay alta incertidumbre técnica y se necesita reducir el sesgo individual de estimación.
Pasos típicos de una sesión Wideband Delphi▼
1) Cada experto estima en privado. 2) Se comparten los resultados anónimos. 3) Se discuten las diferencias más grandes. 4) Se vuelve a estimar. 5) Se repite hasta que las estimaciones converjan en un rango aceptable.
🗓️

Reuniones y eventos como método de gobierno

Recopilación y sincronización
El tipo de reunión debe coincidir con su propósito: sincronización rápida (Daily), toma de decisión (Comité de Control de Cambios), o cierre formal (Reunión de cierre). Mezclar propósitos en una sola reunión reduce su eficacia.
Caso: Interbank y una reunión de estatus que se volvió comité de cambiosAplicación
▼
En Interbank, la reunión semanal de estatus terminó discutiendo y aprobando cambios de alcance sin el proceso formal de control de cambios, generando confusión sobre qué fue realmente aprobado.
¿Qué error de método se cometió y cómo lo corregirías?
Se mezcló el propósito de una reunión de estatus (informar avance) con el de un comité de control de cambios (evaluar y aprobar cambios formalmente). La corrección es separar ambos eventos y dirigir cualquier solicitud de cambio detectada en el estatus hacia el proceso formal del comité, con su propia documentación y aprobación.
Casos prácticos
Ferreyros — Estimación de un proyecto de mantenimiento predictivoEstimación
▼
Ferreyros quiere estimar el esfuerzo de un nuevo módulo de mantenimiento predictivo. Tienen datos de 3 proyectos similares anteriores, pero ningún requisito detallado aún.
¿Qué técnica de estimación usarías en esta etapa temprana?
Conviene la estimación análoga, ya que se dispone de datos históricos de proyectos similares y aún no hay suficiente detalle para técnicas más precisas como la paramétrica o el punto de función.
Saga Falabella — Elegir el método correcto de recopilación de datosRecopilación de datos
▼
El equipo de Saga Falabella necesita decidir si continuar invirtiendo en un nuevo canal de venta digital, comparando el costo estimado de mantenerlo contra el valor que sigue aportando al negocio.
¿Qué método de recopilación y análisis de datos aplicarías?
El análisis de justificación del negocio es el más adecuado, pues evalúa si el proyecto o iniciativa sigue siendo viable y sigue generando valor suficiente para continuar invirtiendo en él.
Preguntas frecuentes
¿Cuál es la diferencia entre un método y una herramienta?▼
Un método es el medio o procedimiento para lograr un resultado (ej. estimación análoga), mientras que una herramienta es el recurso concreto usado para aplicar ese método (ej. una plantilla de Excel o un software específico).
¿Por qué el PMBOK 7 agrupa los métodos por propósito y no por proceso?▼
Porque el PMBOK 7 adopta un enfoque basado en principios y dominios de desempeño en lugar de procesos secuenciales, por lo que agrupa los métodos según para qué sirven (estimar, recopilar datos, reunirse) y no según en qué fase del proyecto se usan.
¿Se puede usar más de un método de estimación en el mismo proyecto?▼
Sí. Es común combinar métodos: por ejemplo, usar estimación análoga en etapas tempranas y luego refinar con estimación paramétrica o por punto de historia cuando se tiene más información.
¿Qué diferencia a un Daily Standup de una reunión de estatus tradicional?▼
El Daily Standup es breve (usualmente 15 minutos), diario, y se enfoca en sincronizar al equipo sobre avances y bloqueos. La reunión de estatus suele ser menos frecuente, más formal, y dirigida a comunicar avance a interesados o patrocinadores.
¿La hoja de verificación es lo mismo que un checklist de tareas?▼
No exactamente. La hoja de verificación en gestión de calidad se usa para recopilar datos de forma organizada durante inspecciones o revisiones (ej. contar tipos de defectos), mientras que un checklist de tareas simplemente confirma que se completaron pasos de un proceso.
3 de 11
FUNDAMENTOS PMBOK · ARTEFACTOS
03

Artefactos

Plantillas, documentos, salidas o entregables del proyecto. Sus descripciones son de alto nivel: se espera que el equipo las adapte a las necesidades concretas de su proyecto.

EstrategiaRegistrosPlanesInformes
¿Qué es un artefacto?

Es una plantilla, documento, salida o entregable del proyecto. Las descripciones se presentan a alto nivel, ya que se espera que los directores de proyecto y/o los miembros del equipo adapten su uso a las necesidades de su proyecto concreto (un reporte de control, una aplicación, una presentación, un informe financiero, un cronograma, entre otros).

Artefactos de estrategia

Desarrollados al comienzo de un proyecto y normalmente no cambian, aunque pueden ser revisados a lo largo del proyecto.

01 · Caso de negocio

Justifica la inversión del proyecto.

02 · Lienzo de modelo de negocio

Resume la propuesta de valor y el modelo económico.

03 · Informe del proyecto

Resume viabilidad y alcance inicial.

04 · Acta de constitución

Autoriza formalmente el proyecto.

05 · Declaración de la visión

Describe el estado futuro deseado.

06 · Hoja de ruta

Cronograma visual de alto nivel.

Bitácoras y registros

Se utilizan para documentar aspectos en continua evolución del proyecto; se actualizan a lo largo de este.

RegistroPropósito
Registro de supuestosDocumenta supuestos y su validación.
Lista de trabajo pendienteÍtems por completar (backlog).
Registro de cambiosHistorial de solicitudes de cambio.
Registro de incidentesSeguimiento de problemas activos.
Registro de lecciones aprendidasAprendizajes documentados durante el proyecto.
Trabajo pendiente ajustado al riesgoBacklog priorizado considerando riesgos.
Registro de riesgosRiesgos identificados y su análisis.
Registro de interesadosInformación sobre stakeholders clave.
Planes

Describen aspectos individuales de un proyecto y/o combinan esa información en un plan global.

01 Plan de control de cambios

02 Plan de gestión de comunicaciones

03 Plan de gestión de costos

04 Plan de gestión de adquisiciones

05 Plan para la dirección del proyecto

06 Plan de gestión de la calidad

07 Plan de liberación

08 Plan de gestión de requisitos

09 Plan de gestión de recursos

Diagramas jerárquicos

Suelen elaborarse progresivamente en mayores niveles de detalle a medida que se conoce más información sobre el proyecto.

EDT — Estructura de Desglose del Trabajo▼
Representa el alcance total del trabajo a realizar en el proyecto.
EDO — Estructura de Desglose de la Organización▼
Muestra las actividades y áreas de la organización que las realizarán.
EDP — Estructura de Desglose del Producto▼
Componentes y entregables del producto.
EDR — Estructura de Desglose de Recursos▼
Recursos por categoría y tipo.
Estructura de Desglose del Riesgo▼
Posibles fuentes de riesgos del proyecto.
Líneas base, cronogramas y presupuesto
ArtefactoDescripción
Línea base (LB)Versión aprobada de un producto o plan de trabajo.
Línea base del alcanceVersión aprobada del enunciado del alcance y la EDT.
LB para medición del desempeñoAlcance, cronograma y costos integrados.
Cronograma del proyectoActividades planificadas y recursos asignados.
Cronograma de hitosPresenta hitos con fechas planificadas.
PresupuestoEstimación aprobada para el proyecto.
Datos e información visuales

Organizan y presentan datos e información en formato visual: tablas, gráficos, matrices y diagramas.

Diagrama de afinidadBurndown/BurnupCausa-efecto CFDTiempo de cicloTableros Diagrama de flujoGanttRadiador de información Tiempo de entrega
Informes

Registros o resúmenes formales que comunican información pertinente a los interesados.

Informe de calidad

Recomendaciones de acciones correctivas y resumen de control de calidad.

Informe de riesgos

Riesgos individuales y nivel de riesgo general.

Informe de estado

Avance desde el último informe y pronósticos de costo/cronograma.

Acuerdos y contratos

En los proyectos, los acuerdos adoptan la forma de contratos.

TipoDescripción
Precio fijoEstablece un precio fijo para un resultado.
Costo reembolsablePagos por costos reales incurridos más honorarios.
Tiempo y materialesEstablece una tarifa fija por tiempo/material.
Entrega indefinida, cantidad indefinidaCon límites y en un periodo determinado.
Otros acuerdosMemorando de entendimiento, memorando de acuerdo, SLA, acuerdo básico de pedidos.
🧠

Integrando Modelos, Métodos y Artefactos

Repaso cruzado · Clasificación
Antes de avanzar al enfoque ágil, es clave distinguir con claridad a qué categoría pertenece cada concepto visto hasta ahora. Un modelo explica o representa una realidad; un método es un medio para lograr un resultado; un artefacto es la plantilla o entregable en sí.
🧩Arrastra cada elemento del banco hacia la categoría correcta: Modelos, Métodos o Artefactos.
🧩

Simulador: Clasifica Modelos, Métodos y Artefactos

Arrastra cada ítem a su categoría correcta
Casos prácticos
Alicorp — Selección de artefactos para un nuevo proyecto de trazabilidadSelección de artefactos
▼
Alicorp inicia un proyecto de trazabilidad de insumos. El sponsor pide un documento que justifique la inversión y otro que autorice formalmente el inicio del proyecto.
¿Qué dos artefactos de estrategia corresponden a cada solicitud?
Para justificar la inversión corresponde el caso de negocio; para autorizar formalmente el inicio del proyecto corresponde el acta de constitución del proyecto. Ambos son artefactos de estrategia que se elaboran al inicio y suelen mantenerse estables.
Preguntas frecuentes
¿Todos los artefactos son documentos escritos?▼
No. Un artefacto puede ser un documento, pero también una aplicación, una presentación, un cronograma visual o cualquier salida/entregable del proyecto, según la definición del PMBOK 7.
¿Cuál es la diferencia entre una bitácora y un plan?▼
Una bitácora o registro documenta aspectos que evolucionan continuamente y se actualiza a lo largo del proyecto (ej. registro de riesgos), mientras que un plan describe cómo se gestionará un aspecto específico o el proyecto completo, y suele ser más estable en el tiempo.
¿Qué distingue a una línea base de un plan?▼
La línea base es la versión aprobada de un producto de trabajo o plan (por ejemplo, la línea base del alcance), y sirve como punto de comparación para medir el desempeño; el plan describe cómo se ejecutará y gestionará ese aspecto.
¿Los diagramas jerárquicos se elaboran una sola vez?▼
No necesariamente. Suelen elaborarse de forma progresiva, aumentando el nivel de detalle conforme se conoce más información del proyecto (elaboración progresiva).
¿Qué tipo de contrato conviene cuando el alcance no está bien definido?▼
Cuando el alcance no está bien definido, suele preferirse un contrato de tiempo y materiales o de costo reembolsable, ya que un precio fijo implicaría un riesgo alto para el proveedor si el alcance cambia.
4 de 11
ENFOQUES DE TRABAJO · ADAPTATIVO E ITERATIVO
04

Enfoque Adaptativo y Enfoque Iterativo

Dos formas complementarias de gestionar la incertidumbre y mejorar progresivamente el producto o servicio del proyecto.

Retroalimentación continuaCiclos de trabajo
Definiciones
EnfoqueDefinición
AdaptativoMetodología que permite realizar ajustes durante el desarrollo del proyecto en función de la retroalimentación continua y la evolución de los requisitos. Esencial en entornos de alta incertidumbre donde los cambios son frecuentes.
IterativoSe centra en la repetición de ciclos de trabajo (iteraciones), donde se revisa y mejora el producto o servicio progresivamente. Cada iteración incluye planificación, diseño, desarrollo, pruebas y revisión.
Ejemplos de aplicabilidad

Enfoque Adaptativo

Un proyecto de desarrollo de software donde los requisitos cambian con frecuencia según las necesidades del cliente.

Enfoque Iterativo

El desarrollo de un videojuego, donde cada iteración produce una versión jugable que se prueba y mejora con base en la retroalimentación de los usuarios.

Buenas prácticas
🔷Adaptativo: involucrar a los stakeholders frecuentemente, fomentar la transparencia, y estar preparados para cambios rápidos.
🔁Iterativo: asegurar que cada iteración termine con una entrega funcional, y mantener un backlog priorizado para orientar el trabajo futuro.
⚖️

Cómo elegir entre adaptativo e iterativo

Diagnóstico de enfoque
No son mutuamente excluyentes: SCRUM, por ejemplo, combina ambos —itera en Sprints y se adapta según la retroalimentación del Product Owner y los stakeholders. La pregunta clave no es "cuál elegir" sino "cuánto de cada uno necesita mi proyecto".
Señales de que necesitas más enfoque adaptativo▼
Los requisitos cambian con frecuencia, el cliente no tiene claridad total del producto final, y el entorno de negocio es volátil (nuevas regulaciones, competencia, tecnología emergente).
Señales de que necesitas más enfoque iterativo▼
El producto se beneficia de validarse por partes (prototipos, versiones jugables, MVPs), y el equipo puede entregar incrementos funcionales en ciclos cortos y predecibles.
Casos prácticos
Rappi Perú — Requisitos cambiantes en la app de deliveryEnfoque adaptativo
▼
El equipo de producto de una app de delivery en Perú recibe feedback constante de los repartidores sobre la funcionalidad de rutas, y los requisitos cambian casi cada semana según la temporada y el clima.
¿Qué enfoque conviene aplicar y qué prácticas concretas ayudarían?
Conviene el enfoque adaptativo, dada la alta frecuencia de cambio en los requisitos. Se recomienda involucrar a los repartidores y stakeholders frecuentemente, fomentar la transparencia sobre el estado del backlog, y mantener al equipo preparado para pivotar rápido.
Preguntas frecuentes
¿El enfoque iterativo siempre entrega software funcional?▼
No siempre software: puede ser cualquier producto o servicio que se beneficie de mejoras progresivas, como el desarrollo de un videojuego o incluso un plan de marketing revisado en ciclos.
¿Puede un proyecto ser adaptativo sin ser iterativo?▼
Sí, aunque es poco común en la práctica ágil. Un proyecto podría ajustarse continuamente a cambios sin necesariamente organizar el trabajo en ciclos formales de iteración, aunque combinar ambos suele dar mejores resultados.
¿SCRUM es adaptativo, iterativo, o ambos?▼
SCRUM es ambos: itera en Sprints de duración fija (enfoque iterativo) y se adapta continuamente según la retroalimentación del Product Owner y los stakeholders durante el Sprint Review (enfoque adaptativo).
¿Qué riesgo existe si se aplica un enfoque predictivo a un proyecto de alta incertidumbre?▼
El riesgo principal es la falta de flexibilidad ante cambios inevitables, generando retrabajos costosos, sobrecostos y baja satisfacción del cliente, ya que el plan detallado inicial rápidamente queda desactualizado.
¿Cómo se mide el éxito en un enfoque iterativo?▼
Principalmente por la entrega de incrementos funcionales al final de cada iteración y por la mejora progresiva del producto en función de la retroalimentación recibida, más que por el cumplimiento exacto de un plan fijo inicial.
5 de 11
MUNDO ÁGIL · INTRODUCCIÓN
05

Introducción a Proyectos Ágiles

Proyectos que adoptan flexibilidad, colaboración y entrega incremental de valor en lugar de planificar todo el detalle desde el inicio.

FlexibilidadColaboraciónEntrega incremental
¿Qué es un proyecto ágil?

Los proyectos ágiles son aquellos que adoptan un enfoque ágil: basado en la flexibilidad, la colaboración y la entrega incremental de valor. En lugar de planificar todo el proyecto en detalle desde el principio, los proyectos ágiles evolucionan a medida que se trabaja en ellos.

Ejemplos de proyectos ágiles

Desarrollo de software con Scrum

Un equipo entrega funcionalidades en sprints cortos.

Marketing digital iterativo

Un proyecto que se ajusta continuamente según resultados de campañas anteriores.

Buenas prácticas
1
Ambiente colaborativo
→
2
Dividir en unidades manejables
→
3
Priorizar por valor al cliente
🧱

Descomponer el trabajo en unidades manejables

Buena práctica ágil
Dividir el alcance en piezas pequeñas que se puedan entregar en corto plazo reduce el riesgo, permite retroalimentación temprana y facilita priorizar según el valor real que aporta cada pieza al cliente.
✅Una buena señal: cada unidad de trabajo puede describirse y entregarse en días o pocas semanas, no en meses.
Casos prácticos
Backus — Campaña de marketing digital ajustada en tiempo realProyecto ágil
▼
El equipo de marketing digital de una cervecera peruana lanza una campaña y ajusta el presupuesto de pauta cada semana según qué anuncios generan más conversión, en lugar de mantener un plan fijo de 3 meses.
¿Por qué este proyecto es un ejemplo de proyecto ágil?
Es ágil porque el equipo no planifica todo el detalle desde el inicio: evoluciona la estrategia constantemente basándose en resultados reales (retroalimentación), priorizando la asignación de presupuesto según el valor/conversión que genera cada línea de la campaña.
Preguntas frecuentes
¿Un proyecto ágil no tiene ninguna planificación?▼
Sí tiene planificación, pero a un nivel más alto al inicio y con mayor detalle a corto plazo (por ejemplo, planificación de cada Sprint), en lugar de detallar todo el proyecto de principio a fin desde el día uno.
¿Todos los proyectos ágiles usan Scrum?▼
No. Scrum es uno de los marcos ágiles más populares, pero existen otros como Kanban, Extreme Programming (XP) o enfoques híbridos que también aplican principios ágiles.
¿Los proyectos ágiles solo aplican a software?▼
No. Aunque nacieron en el desarrollo de software, los principios ágiles se aplican hoy en marketing, recursos humanos, construcción y muchas otras industrias donde la flexibilidad y la entrega incremental aportan valor.
¿Cómo se prioriza el trabajo en un proyecto ágil?▼
Principalmente según el valor que cada tarea o funcionalidad entrega al cliente, manteniendo un backlog priorizado que se revisa y ajusta constantemente.
¿Qué diferencia a un proyecto ágil de uno tradicional en cuanto a riesgo?▼
El proyecto ágil reduce el riesgo entregando valor en incrementos pequeños y frecuentes, permitiendo detectar y corregir problemas temprano, mientras que el enfoque tradicional suele concentrar el riesgo hacia el final del proyecto, cuando ya se ha invertido la mayor parte del presupuesto.
6 de 11
MUNDO ÁGIL · ENFOQUE ÁGIL
06

Introducción al Enfoque Ágil

Un conjunto de métodos y prácticas basadas en los valores y principios del Manifiesto Ágil, creado en 2001.

Manifiesto Ágil4 valores12 principios
Enfoque ágil

Es un conjunto de métodos y prácticas basadas en los valores y principios del "Manifiesto Ágil". Enfatiza la colaboración entre equipos multidisciplinarios, la entrega continua de valor al cliente y la capacidad de responder al cambio rápidamente.

Valores del Manifiesto Ágil (2001)
#Valor
01Individuos e interacciones sobre procesos y herramientas.
02Software funcional sobre documentación extensiva.
03Colaboración con el cliente sobre negociación contractual.
04Respuesta al cambio sobre seguir un plan.
Los 12 principios del Manifiesto Ágil
1–4 · Satisfacción del cliente y entregas frecuentes▼
1) Satisfacción del cliente mediante entrega continua y temprana de software valioso. 2) Acoger el cambio incluso en etapas tardías para dar ventaja competitiva. 3) Entregas frecuentes de software funcional, desde semanas hasta un par de meses, preferentemente en plazos cortos. 4) Colaboración diaria entre negocio y desarrollo durante todo el proyecto.
5–8 · Personas motivadas y comunicación efectiva▼
5) Crear proyectos con personas motivadas, brindándoles entorno, apoyo y confianza. 6) La conversación cara a cara es el método más eficiente de transmitir información. 7) El software funcional es la principal medida de progreso. 8) Los procesos ágiles promueven un ritmo de trabajo sostenible e indefinido.
9–12 · Excelencia técnica, simplicidad y mejora continua▼
9) Excelencia técnica y buen diseño que mejoran la agilidad. 10) Simplicidad: maximizar el trabajo no realizado. 11) Autoorganización de los equipos para mejorar diseño, requisitos y arquitectura. 12) Reflexión y ajuste continuo: a intervalos regulares el equipo reflexiona y ajusta su comportamiento.
🎤

Comunicación cara a cara como técnica de trabajo

Principio 6 del Manifiesto Ágil
Priorizar conversaciones directas (presenciales o por videollamada) sobre largas cadenas de correos reduce malentendidos y acelera la toma de decisiones. En equipos remotos, esto se traduce en preferir una llamada corta sobre un hilo extenso de mensajes.
⚠️No confundir "cara a cara" con "reuniones innecesarias": el principio busca eficacia en la comunicación, no maximizar el número de reuniones.
Casos prácticos
Interbank — Documentación extensa vs. software funcionalValores del manifiesto
▼
Un equipo de TI de Interbank dedica 3 semanas a documentar exhaustivamente los requisitos de una nueva funcionalidad antes de escribir una sola línea de código, retrasando la primera entrega funcional.
¿Qué valor del Manifiesto Ágil se está pasando por alto?
Se está priorizando la documentación extensiva sobre el software funcional, contradiciendo el segundo valor del Manifiesto Ágil: "Software funcional sobre documentación extensiva". Esto no significa eliminar la documentación, sino mantenerla suficiente y priorizar entregar valor funcional pronto.
Preguntas frecuentes
¿El Manifiesto Ágil dice que no se debe documentar nada?▼
No. El valor dice "software funcional sobre documentación extensiva", lo cual prioriza la entrega de valor funcional, pero no elimina la documentación necesaria; solo evita que sea excesiva o el objetivo principal.
¿Quiénes crearon el Manifiesto Ágil y cuándo?▼
Fue creado en 2001 por un grupo de desarrolladores de software que buscaban una alternativa más flexible a los métodos tradicionales de gestión de proyectos de software.
¿Los 4 valores y los 12 principios son lo mismo?▼
No. Los 4 valores son declaraciones de alto nivel sobre qué se prioriza; los 12 principios son guías más específicas que orientan cómo poner esos valores en práctica día a día.
¿"Responder al cambio sobre seguir un plan" significa no planificar?▼
No. Sí se planifica, pero se reconoce que el plan puede y debe ajustarse cuando aparece información nueva o cambian las necesidades del cliente, en lugar de seguir rígidamente el plan original a pesar de la evidencia de que ya no es óptimo.
¿Qué principio se relaciona con la sostenibilidad del equipo?▼
El principio 8 indica que los procesos ágiles promueven un ritmo de trabajo constante e indefinido, evitando el desgaste (burnout) del equipo de desarrollo a largo plazo.
7 de 11
MUNDO ÁGIL · ÁREAS DE DOMINIO
07

Áreas de Dominio Ágil

Principios y mentalidad que guían a los equipos en la implementación de métodos ágiles, con foco en la entrega continua de valor.

PrincipiosMentalidad ágilEntrega de valor
Definición

Las áreas de dominio ágil incluyen un conjunto de principios y una mentalidad que guía a los equipos en la implementación de métodos ágiles. Los principios fundamentales incluyen la entrega continua de valor, la bienvenida al cambio, la colaboración cercana con el cliente, y la simplicidad.

Principios

Uno de los principios clave es "la atención continua a la excelencia técnica y un buen diseño mejora la agilidad", que en la práctica se traduce en la adopción de estándares de codificación y pruebas automáticas en el desarrollo de software.

Mentalidad ágil
🌱Fomentar una cultura donde el aprendizaje continuo y la mejora incremental sean valorados y practicados por todo el equipo.
Entrega de valor a la organización

La entrega de valor en el contexto ágil se refiere a la capacidad de un equipo para proporcionar productos o resultados que tengan un impacto positivo y tangible en la organización y sus clientes, de manera rápida y continua.

Ejemplo 1

Un equipo de desarrollo entrega incrementos de software en ciclos cortos, permitiendo a la organización reaccionar rápido a las necesidades del mercado.

Ejemplo 2

Un equipo de marketing ajusta sus estrategias basándose en el análisis de datos en tiempo real, aportando valor continuo a la empresa.

🧪

Pruebas automáticas como excelencia técnica

Aplicación de principios ágiles
Adoptar estándares de codificación y pruebas automáticas reduce defectos y facilita entregar valor de forma rápida y sostenible, sin sacrificar calidad por velocidad.
💡La calidad no es un paso adicional al final: se integra en cada iteración mediante pruebas automatizadas y revisión continua de código.
Casos prácticos
Antamina — Mentalidad ágil en un equipo de mantenimientoMentalidad ágil
▼
Un equipo de mantenimiento predictivo en Antamina comienza a realizar retrospectivas quincenales para identificar mejoras en su proceso de inspección de maquinaria, incluso sin usar Scrum formalmente.
¿Este comportamiento refleja un área de dominio ágil? ¿Cuál?
Sí. Refleja la mentalidad ágil: aunque el equipo no use un marco ágil formal como Scrum, está fomentando una cultura de aprendizaje continuo y mejora incremental, que es precisamente lo que busca esta área de dominio.
Preguntas frecuentes
¿Las áreas de dominio ágil requieren usar un framework específico?▼
No. Son principios y una mentalidad que pueden aplicarse independientemente del marco de trabajo específico (Scrum, Kanban, XP) o incluso sin adoptar uno formal.
¿Qué significa "entrega continua de valor" en la práctica?▼
Significa que el equipo produce resultados con impacto positivo y tangible de manera frecuente, en lugar de esperar hasta el final del proyecto para entregar todo el valor de una sola vez.
¿Cómo se relaciona la simplicidad con la agilidad?▼
La simplicidad busca maximizar el trabajo no realizado, es decir, evitar construir funcionalidades o procesos innecesarios, lo que permite avanzar más rápido y con menos complejidad de mantenimiento.
¿La mentalidad ágil se puede medir?▼
No de forma exacta como un KPI numérico, pero se pueden observar señales indirectas: frecuencia de retrospectivas efectivas, apertura al feedback, y evidencia de mejoras incrementales aplicadas en el tiempo.
¿Un equipo de marketing puede aplicar áreas de dominio ágil?▼
Sí. Como muestra el ejemplo de ajustar estrategias según datos en tiempo real, las áreas de dominio ágil no están limitadas al desarrollo de software; aplican a cualquier equipo que busque entregar valor de forma rápida y continua.
8 de 11
MUNDO ÁGIL · SCRUM
08

SCRUM

Una de las metodologías ágiles más utilizadas, destinada al desarrollo y mantenimiento de proyectos rápidos y flexibles mediante Sprints.

SprintProduct OwnerScrum MasterScrum Team
¿Qué es SCRUM?

SCRUM es una de las metodologías ágiles más utilizadas en la actualidad, destinada principalmente al desarrollo y mantenimiento de proyectos rápidos y flexibles. El elemento más importante de SCRUM es el Sprint, un miniproyecto que da visibilidad de los entregables en corto plazo.

El Sprint o proceso de "iteraciones" plantea el desarrollo de un producto en ciclos de pocas semanas. En cada ciclo, el equipo desarrolla el avance del proyecto sobre la base de una lista de requisitos previamente priorizada, dando lugar al terminar cada ciclo a un producto entregable.

Beneficios de SCRUM

Time to market

Entrega de resultados con periodicidad quincenal o mensual.

Gestión de expectativas

Basada en resultados tangibles del cliente.

Flexibilidad

Adaptación a cambios de mercado y del cliente.

Gestión del ROI

Retorno de inversión gestionado sistemáticamente.

Mitigación de riesgos

De forma sistemática durante el proyecto.

Productividad y calidad

Incremento sostenido en ambas dimensiones.

Alineamiento

Entre cliente y equipo de desarrollo.

Equipo motivado

Mayor compromiso y satisfacción laboral.

Roles principales de SCRUM
👤

Product Owner

Máximo responsable de las funcionalidades
Es el máximo responsable de las funcionalidades que se deben incluir en el proyecto y de priorizarlas, generando el Product Backlog.

Funciones: expresar y clarificar funcionalidades del backlog, decidir sobre implementación, priorizar y mantener el Product Backlog, conocer el negocio, revisar el producto y responder por la rentabilidad del proyecto.

🧭

Scrum Master

Facilitador del proceso
Gestiona el proyecto: su principal objetivo es verificar que las etapas del sprint se cumplan y evitar cuellos de botella o dificultades en el desarrollo.

Funciones: transmitir correctamente Scrum al Product Owner y al equipo, evitar interferencias de terceros, prever problemas y cuellos de botella, resolver conflictos, fomentar un clima colaborativo y motivar al equipo.

👥

Scrum Team

Equipo de desarrollo
Es el equipo de desarrolladores del producto, normalmente compuesto por personal con diferentes perfiles que cubren las áreas y tecnologías del proyecto.

Funciones: llevar el Backlog de producto a desarrollos potencialmente funcionales y operativos, y asegurar la calidad de los productos.

Proceso SCRUM
1
Product Backlog
→
2
Sprint Planning Meeting
→
3
Sprint Backlog
→
4
Sprint (1-4 semanas) + Daily Scrum (24h)
→
5
Finished Work
→
6
Sprint Review + Retrospective
🧭

Decisiones del Scrum Master ante obstáculos

Facilitación · Protección del marco de trabajo
El Scrum Master protege el proceso: facilita conversaciones, traslada discusiones fuera de su timebox, y evita que se rompan los principios de SCRUM (Sprint fijo, backlog priorizado por el Product Owner, foco del equipo).
🧭

Simulador: Flujo de decisiones del Scrum Master

Elige la mejor acción en cada escenario
🔁

Ordenar el proceso SCRUM completo

Secuencia del ciclo de trabajo
Reconstruir el orden correcto del proceso SCRUM —desde el Product Backlog hasta la Retrospectiva— ayuda a fijar la secuencia lógica del marco de trabajo.
🔢

Simulador: Constructor del proceso SCRUM

Arrastra los pasos al orden correcto
Casos prácticos
BCP — Product Owner sobrecargado de solicitudesRoles SCRUM
▼
Varios gerentes de BCP envían solicitudes directamente al equipo de desarrollo, saltándose al Product Owner, generando confusión sobre qué se debe priorizar en el siguiente Sprint.
¿Qué rol debería intervenir y qué acción tomaría?
Debería intervenir el Scrum Master, cuya función incluye controlar que en el proyecto cada uno tenga su papel y evitar que terceras personas interfieran directamente con el equipo. Debe canalizar todas las solicitudes hacia el Product Owner, quien es el único responsable de priorizar el Product Backlog.
Preguntas frecuentes
¿Cuánto dura un Sprint en SCRUM?▼
Generalmente entre 1 y 4 semanas, según lo que el equipo defina como duración estándar para todos sus Sprints, manteniéndola constante a lo largo del proyecto.
¿El Scrum Master es el jefe del equipo de desarrollo?▼
No. El Scrum Master es un facilitador que protege el proceso y elimina obstáculos, pero no tiene autoridad jerárquica sobre el Scrum Team; el equipo se autogestiona en cuanto a cómo realizar el trabajo técnico.
¿Qué diferencia al Sprint Review de la Sprint Retrospective?▼
El Sprint Review se enfoca en inspeccionar el incremento del producto con los stakeholders y ajustar el Product Backlog; la Retrospectiva se enfoca en cómo trabajó el equipo internamente y qué mejoras de proceso aplicar en el siguiente Sprint.
¿Se puede cambiar el Sprint Backlog a mitad del Sprint?▼
En general no se recomienda; el Sprint Backlog se fija en la Sprint Planning Meeting. Cambios de alcance urgentes se evalúan con cuidado y, si es necesario agregarlos, normalmente implican renegociar el objetivo del Sprint junto con el Product Owner.
¿SCRUM elimina completamente el riesgo del proyecto?▼
No. SCRUM permite una mitigación sistemática de riesgos gracias a la retroalimentación frecuente y la entrega incremental, pero ningún marco de trabajo elimina el riesgo por completo.
9 de 11
EVALUACIÓN · QUIZ 1
Q1

Quiz 1 — Fundamentos PMBOK

Evalúa tu comprensión de Modelos, Métodos, Artefactos y el Enfoque Adaptativo/Iterativo (Temas 01 a 04).

9 preguntas4 opciones c/u
10 de 11
EVALUACIÓN · QUIZ 2
Q2

Quiz 2 — Mundo Ágil y SCRUM

Evalúa tu comprensión de Proyectos Ágiles, Enfoque Ágil, Áreas de Dominio Ágil y SCRUM (Temas 05 a 08).

10 preguntas4 opciones c/u
Conclusiones del Tema 15

La gestión de proyectos ágiles se hace importante debido al dinamismo actual en los negocios, las tecnologías emergentes y la necesidad de las empresas de reaccionar rápidamente ante estos cambios. La gestión tradicional no siempre cuenta con metodologías que permitan cambiar rápido o entregar resultados en el corto plazo, mientras que metodologías como SCRUM permiten entregas rápidas y flexibles, gestionando al mismo tiempo los requerimientos cambiantes de los usuarios.

Bibliografía
ReferenciaDetalle
PMI (2021)A Guide to the Project Management Body of Knowledge, 7ª Edición. ISBN: 978-1-62825-664-2. Pennsylvania, USA.
PMI (2017)A Guide to the Project Management Body of Knowledge, 6ª Edición. ISBN: 978-1-62825-194-4. Pennsylvania, USA.
Project Management Institutepmi.org
🎓Has completado el repaso del Tema 15. Puedes volver a cualquier sección desde la barra lateral o reintentar los quizzes para reforzar tu aprendizaje.
11 de 11