Curso de DSDM (Dynamic Systems Development Method) hasta 100% Bonificable a través de FUNDAE
Tu bonificación paso a paso
Forma a tu equipo sin costes mediante la bonificación estatal. Este programa de DSDM (Dynamic Systems Development Method)para empresas es subvencionable hasta el 100%.
Potencia las habilidades de edición y automatización de tus profesionales.
Accede a una formación avanzada en DSDM (Dynamic Systems Development Method) práctica y orientada a resultados.
Prepara a tu equipo para los retos documentales del entorno laboral actual.
Gestionamos gratis tu bonificación de este curso corporativo de DSDM (Dynamic Systems Development Method) ante FUNDAE.
Protege plazos sin sacrificar calidad El enfoque DSDM ayuda a entregar a tiempo ajustando alcance mediante MoSCoW, en lugar de recortar calidad o sobrecargar al equipo. Esto mejora previsibilidad y reduce entregas tardías con bajo valor.
1
Aumenta la implicación real del negocio DSDM define roles de negocio activos y mecanismos de colaboración continua. Esto evita que el equipo técnico avance con supuestos y que los usuarios aparezcan solo al final para rechazar la solución.
Personaliza el temario al 100% para tu equipo
Diseñamos una formación a medida utilizando los documentos y flujos de trabajo reales de tu empresa.
Nueva Plataforma de E-learningFormación en directo con plataforma de apoyo para reforzar el aprendizaje
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Programa formativo
Temario del curso
Encuentra todo el temario del curso aquí.
Temario
¿Qué es DSDM y por qué se considera un marco ágil orientado a entregar valor de negocio con disciplina, roles claros y control de proyecto?
¿Para qué sirve DSDM en una empresa cuando ya se utilizan Scrum, Kanban, PRINCE2, PMO, procesos internos o gestión tradicional de proyectos?
¿Qué diferencia a DSDM de otros enfoques ágiles más centrados en equipo, producto o flujo continuo de trabajo?
¿Cuándo conviene aplicar DSDM en proyectos con plazos relevantes, dependencias empresariales, necesidad de gobierno y participación activa del negocio?
¿Cuándo puede no encajar DSDM, especialmente si la organización no puede aportar usuarios de negocio, tomar decisiones rápidas o aceptar alcance variable?
¿Qué significa en DSDM fijar tiempo, coste y calidad, dejando el alcance como variable de ajuste mediante priorización realista?
¿Qué tipos de proyectos se benefician más: implantaciones IT, productos digitales, procesos internos, transformación, data, automatización o soluciones empresariales?
¿Qué riesgos pretende reducir DSDM: entregas tardías, falta de alineación con negocio, requisitos sobredimensionados, baja calidad y decisiones bloqueadas?
¿Qué responsabilidades asume la organización cuando decide trabajar con DSDM y no solo “pedir agilidad” al equipo técnico?
¿Qué criterios ayudan a decidir si DSDM debe adoptarse completo, adaptarse parcialmente o combinarse con otros marcos existentes?
¿Qué es DSDM y por qué se considera un marco ágil orientado a entregar valor de negocio con disciplina, roles claros y control de proyecto?
¿Para qué sirve DSDM en una empresa cuando ya se utilizan Scrum, Kanban, PRINCE2, PMO, procesos internos o gestión tradicional de proyectos?
¿Qué diferencia a DSDM de otros enfoques ágiles más centrados en equipo, producto o flujo continuo de trabajo?
¿Cuándo conviene aplicar DSDM en proyectos con plazos relevantes, dependencias empresariales, necesidad de gobierno y participación activa del negocio?
¿Cuándo puede no encajar DSDM, especialmente si la organización no puede aportar usuarios de negocio, tomar decisiones rápidas o aceptar alcance variable?
¿Qué significa en DSDM fijar tiempo, coste y calidad, dejando el alcance como variable de ajuste mediante priorización realista?
¿Qué tipos de proyectos se benefician más: implantaciones IT, productos digitales, procesos internos, transformación, data, automatización o soluciones empresariales?
¿Qué riesgos pretende reducir DSDM: entregas tardías, falta de alineación con negocio, requisitos sobredimensionados, baja calidad y decisiones bloqueadas?
¿Qué responsabilidades asume la organización cuando decide trabajar con DSDM y no solo “pedir agilidad” al equipo técnico?
¿Qué criterios ayudan a decidir si DSDM debe adoptarse completo, adaptarse parcialmente o combinarse con otros marcos existentes?
Tema 1: ¿Qué es DSDM y cuándo tiene sentido aplicarlo?
¿Qué es DSDM y por qué se considera un marco ágil orientado a entregar valor de negocio con disciplina, roles claros y control de proyecto?
¿Para qué sirve DSDM en una empresa cuando ya se utilizan Scrum, Kanban, PRINCE2, PMO, procesos internos o gestión tradicional de proyectos?
¿Qué diferencia a DSDM de otros enfoques ágiles más centrados en equipo, producto o flujo continuo de trabajo?
¿Cuándo conviene aplicar DSDM en proyectos con plazos relevantes, dependencias empresariales, necesidad de gobierno y participación activa del negocio?
¿Cuándo puede no encajar DSDM, especialmente si la organización no puede aportar usuarios de negocio, tomar decisiones rápidas o aceptar alcance variable?
¿Qué significa en DSDM fijar tiempo, coste y calidad, dejando el alcance como variable de ajuste mediante priorización realista?
¿Qué tipos de proyectos se benefician más: implantaciones IT, productos digitales, procesos internos, transformación, data, automatización o soluciones empresariales?
¿Qué riesgos pretende reducir DSDM: entregas tardías, falta de alineación con negocio, requisitos sobredimensionados, baja calidad y decisiones bloqueadas?
¿Qué responsabilidades asume la organización cuando decide trabajar con DSDM y no solo “pedir agilidad” al equipo técnico?
¿Qué criterios ayudan a decidir si DSDM debe adoptarse completo, adaptarse parcialmente o combinarse con otros marcos existentes?
Tema 2: Filosofía, valores y principios de DSDM
Comprender la filosofía de DSDM basada en entregar valor de negocio mediante colaboración, entregas frecuentes y personas motivadas con capacidad de decisión.
Analizar los ocho principios de DSDM como guía de comportamiento, no como frases decorativas en una presentación. Agile Business Consortium señala que estos principios dan vida a los valores ágiles y orientan la actitud del equipo.
Aplicar “Focus on the business need” para asegurar que cada decisión del proyecto protege el valor real y no solo la lista inicial de funcionalidades.
Trabajar “Deliver on time” como disciplina de gestión donde el plazo importa y el alcance se adapta mediante priorización honesta.
Usar “Collaborate” para estructurar interacción real entre negocio, tecnología, QA, dirección, usuarios y proveedores.
Interpretar “Never compromise quality” como acuerdo explícito sobre nivel de calidad, pruebas, aceptación y estándares desde el inicio.
Aplicar “Build incrementally from firm foundations” para evitar arrancar entregas sin una base mínima de visión, arquitectura, riesgos y enfoque.
Usar “Develop iteratively” para aprender con feedback temprano, no para repetir ciclos sin validación ni mejora.
Convertir “Communicate continuously and clearly” en prácticas concretas de visualización, workshops, reporting, decisiones y transparencia.
Aplicar “Demonstrate control” para demostrar gobierno sin caer en documentación excesiva o control burocrático sin valor.
Tema 3: Ciclo de vida DSDM y visión completa del proyecto
Entender el ciclo de vida DSDM como una estructura iterativa e incremental con fases orientadas a viabilidad, base firme, desarrollo, despliegue y beneficios.
Revisar las seis fases del proceso DSDM: Pre-Project, Feasibility, Foundations, Evolutionary Development, Deployment y Post-Project.
Usar Pre-Project para confirmar que el proyecto merece iniciarse, tiene patrocinio, dirección estratégica y encaje organizativo.
Aplicar Feasibility para explorar coste, beneficio, riesgo, enfoque, complejidad y capacidad real antes de comprometer grandes inversiones.
Construir Foundations como base suficiente para arrancar con control: visión, arquitectura, gobierno, roles, plan inicial y riesgos principales.
Ejecutar Evolutionary Development mediante timeboxes, feedback, colaboración y entregas incrementales alineadas con prioridades de negocio.
Gestionar Deployment como actividad planificada de puesta en producción, transición, formación, comunicación y preparación operativa.
Usar Post-Project para comprobar beneficios reales, lecciones aprendidas, adopción, retorno y oportunidades de mejora.
Evitar interpretar el ciclo de vida como cascada encubierta; las fases aportan control, pero el desarrollo sigue siendo incremental.
Diseñar un mapa de proyecto DSDM completo con fases, decisiones, productos esperados y puntos de control ligeros.
Tema 4: Roles DSDM y responsabilidades reales
Comprender que DSDM define roles para asegurar negocio, dirección, gestión, desarrollo, pruebas, análisis, facilitación y apoyo especializado.
Diferenciar roles de negocio, roles de solución, roles de gestión y roles de soporte para evitar que una única persona asuma responsabilidades incompatibles.
Analizar el papel del Business Sponsor como responsable último del caso de negocio, inversión, dirección y toma de decisiones estratégicas.
Definir el rol de Business Visionary como figura que mantiene visión funcional, valor, prioridades y coherencia de la solución.
Entender el rol de Project Manager dentro de DSDM como facilitador de control, coordinación, riesgos, planificación y gobernanza.
Situar Business Ambassador, Business Analyst, Solution Developer, Solution Tester y Team Leader dentro del Solution Development Team. Agile Business Consortium describe estos roles como el “engine room” del proyecto.
Aclarar el papel de Technical Coordinator para proteger coherencia técnica, arquitectura, calidad técnica y decisiones transversales.
Incorporar Workshop Facilitator y DSDM Coach cuando la organización necesita ayuda para facilitar colaboración o adoptar el enfoque.
Evitar asignar roles por cargo formal sin comprobar disponibilidad, autoridad, conocimiento y capacidad real de decisión.
Construir una matriz de roles y responsabilidades para un proyecto empresarial con negocio, IT, QA, PMO y proveedores.
Tema 5: Preparación organizativa y factores de éxito
Evaluar si la empresa está preparada para trabajar con DSDM antes de iniciar un proyecto relevante.
Revisar disponibilidad real de usuarios de negocio, patrocinio, decisión rápida, colaboración, aceptación de priorización y cultura de transparencia.
Identificar factores que bloquean DSDM: negocio ausente, comité lento, contratos rígidos, miedo a cambiar alcance y baja confianza entre áreas.
Definir acuerdos de trabajo entre negocio, equipo técnico, PMO, dirección, proveedores y áreas de soporte.
Establecer expectativas sobre participación, workshops, revisiones, feedback, priorización y aceptación incremental.
Preparar mecanismos de escalado para decisiones que superan al equipo y no pueden esperar semanas.
Alinear DSDM con políticas internas de seguridad, arquitectura, compras, compliance, legal, datos y operaciones.
Medir riesgo de adopción cuando la organización quiere “entregas ágiles” pero mantiene aprobaciones secuenciales muy pesadas.
Crear un plan de habilitación inicial con formación, coaching, roles, calendario, herramientas y criterios de éxito.
Construir una evaluación de readiness DSDM con fortalezas, brechas, riesgos y acciones previas al arranque.
Tema 6: Pre-Project: justificar y seleccionar bien los proyectos
Definir el propósito de Pre-Project como filtro para evitar iniciar iniciativas sin valor claro, patrocinio suficiente o encaje estratégico.
Formular el problema de negocio antes de discutir funcionalidades, herramientas o soluciones técnicas.
Identificar objetivos, beneficios esperados, urgencia, restricciones, stakeholders y relación con estrategia corporativa.
Validar patrocinio real y capacidad de decisión, evitando proyectos que nacen sin owner ejecutivo claro.
Revisar alternativas: no hacer nada, mejorar proceso, adaptar sistema existente, comprar solución, desarrollar a medida o ejecutar piloto.
Definir criterios de éxito iniciales que permitan decidir si merece pasar a Feasibility.
Identificar riesgos tempranos de financiación, dependencia externa, disponibilidad del negocio, datos, regulación o tecnología.
Evitar convertir Pre-Project en un business case extenso cuando solo se necesita información suficiente para decidir.
Documentar una ficha ligera de iniciativa con problema, valor, sponsor, alcance inicial, restricciones y recomendación.
Construir un caso Pre-Project para una iniciativa empresarial priorizada dentro de portfolio.
Tema 7: Feasibility: viabilidad, riesgos y decisiones tempranas
Explorar la viabilidad funcional, técnica, económica, operativa y organizativa antes de comprometer un proyecto completo.
Definir preguntas clave de Feasibility: valor potencial, riesgos, complejidad, dependencias, incertidumbre y capacidad de entrega.
Crear prototipos, spikes, análisis de datos o validaciones tempranas cuando existen dudas relevantes.
Identificar requisitos de alto nivel sin pretender cerrar todo el detalle funcional en esta fase.
Evaluar restricciones de arquitectura, seguridad, integración, compliance, infraestructura, proveedores y disponibilidad de usuarios.
Revisar opciones de solución y recomendar enfoque con suficiente evidencia, no por preferencia del equipo.
Estimar tamaño inicial, complejidad, coste aproximado y posibles timeboxes sin vender una falsa precisión.
Decidir si continuar, parar, rediseñar, dividir, ejecutar piloto o aplazar la iniciativa.
Documentar conclusiones de Feasibility con riesgos abiertos, supuestos, decisiones, recomendación y próximos pasos.
Construir un análisis de viabilidad para un proyecto DSDM con incertidumbre técnica y dependencia de negocio.
Tema 8: Foundations: construir una base firme sin caer en análisis eterno
Definir Foundations como fase para crear una base suficiente de visión, alcance, arquitectura, gobierno, planificación y enfoque de entrega.
Acordar visión de negocio, objetivos, beneficios esperados, prioridades iniciales y criterios de éxito.
Definir arquitectura de alto nivel, integración, datos, seguridad, calidad, entornos y restricciones técnicas principales.
Identificar productos DSDM necesarios y nivel de formalidad apropiado para el contexto de la organización.
Crear un plan de entrega inicial con timeboxes, releases, hitos, dependencias y enfoque de despliegue.
Definir Definition of Done, criterios de aceptación, estrategia de pruebas y nivel de calidad no negociable.
Establecer roles, disponibilidad, governance, reporting, escalado, herramientas y calendario de ceremonias.
Priorizar requisitos iniciales mediante MoSCoW, dejando claro qué es imprescindible y qué puede ajustarse.
Evitar prolongar Foundations hasta convertirlo en una fase de especificación completa previa al desarrollo.
Construir un Foundations Summary con visión, alcance, arquitectura, plan inicial, riesgos y acuerdos de trabajo.
Tema 9: Evolutionary Development: iterar con feedback y control
Organizar el desarrollo evolutivo mediante timeboxes donde el equipo entrega incrementos verificables y recibe feedback frecuente.
Traducir prioridades MoSCoW en objetivos concretos de timebox, evitando comprometer más Must Haves de los que caben con calidad.
Combinar análisis, diseño, construcción, prueba y revisión dentro de cada ciclo, no como fases aisladas y tardías.
Incorporar usuarios de negocio en revisiones, aclaraciones, pruebas, decisiones y aceptación progresiva de la solución.
Usar feedback temprano para ajustar solución, detalle de requisitos, prioridad, diseño y experiencia de usuario.
Mantener visibilidad de progreso mediante tableros, métricas, demostraciones, riesgos y productos actualizados.
Gestionar cambios sin dramatismo, siempre que se respeten tiempo, calidad, valor y prioridades acordadas.
Detectar desviaciones dentro del timebox para renegociar alcance antes de comprometer calidad o plazo.
Evitar iteraciones que solo producen documentación, prototipos sin validación o software no integrado.
Construir un plan de Evolutionary Development con varios timeboxes, objetivos, entregables y revisiones de negocio.
Tema 10: Deployment y transición a operación
Planificar Deployment como parte del proyecto desde el inicio, no como una actividad técnica final improvisada.
Definir estrategia de despliegue: piloto, release parcial, rollout por áreas, despliegue completo o transición gradual.
Preparar formación, comunicaciones, soporte, documentación, datos, accesos, procesos operativos y plan de incidencias.
Validar readiness de usuarios, operaciones, soporte, seguridad, infraestructura y stakeholders antes de liberar.
Coordinar despliegues con ventanas de negocio, dependencias externas, integraciones, cambios organizativos y disponibilidad de equipos.
Gestionar criterios de go/no-go con evidencias de prueba, riesgos conocidos, mitigaciones y responsables de decisión.
Diseñar rollback, contingencia, soporte de hiper-cuidado y seguimiento postdespliegue.
Evitar desplegar funcionalidad técnicamente completa pero no adoptable, sin formación ni proceso operativo definido.
Medir primeras señales de uso, incidencias, feedback, adopción y valor generado tras la puesta en marcha.
Construir un plan de Deployment para una solución empresarial con usuarios, datos, comunicación y soporte.
Tema 11: Post-Project: beneficios, aprendizaje y mejora continua
Evaluar beneficios reales frente a beneficios esperados, revisando adopción, uso, impacto económico, eficiencia o satisfacción.
Diferenciar entrega de funcionalidades y realización de beneficios, porque una solución desplegada puede no generar valor si no se usa.
Definir responsables de medir beneficios tras el cierre formal del proyecto.
Revisar indicadores de negocio, métricas operativas, feedback de usuarios, incidencias y deuda pendiente.
Identificar lecciones aprendidas sobre roles, colaboración, timeboxing, priorización, calidad, despliegue y gobierno.
Decidir acciones posteriores: mejoras, nuevas releases, retirada de funcionalidades, refuerzo formativo o cambios de proceso.
Documentar aprendizaje de forma útil para próximos proyectos, evitando actas extensas que nadie consulta.
Revisar si los productos DSDM usados fueron suficientes, excesivos o mal adaptados.
Incorporar hallazgos a estándares internos, PMO, comunidades ágiles y modelos de adopción.
Construir un informe Post-Project con beneficios, desviaciones, aprendizaje y backlog de mejora.
Tema 12: Productos DSDM y documentación útil
Comprender los productos DSDM como artefactos de gobierno y colaboración, no como documentación obligatoria sin valor.
Diferenciar productos evolutivos, productos de gestión, productos técnicos y productos orientados a negocio.
Ajustar nivel de detalle de cada producto según tamaño, riesgo, criticidad, regulación y madurez de la organización.
Usar Business Case para conectar inversión, valor, beneficios, riesgos y decisiones de continuidad.
Crear Prioritised Requirements List como base viva de alcance, valor, prioridad, dependencias y decisiones.
Mantener Delivery Plan y Timebox Plans alineados con realidad, no como documentos estáticos para cumplir expediente.
Documentar Architecture Definition y Development Approach con lo justo para orientar decisiones técnicas y colaboración.
Usar Solution Increment y Evolving Solution como evidencia de progreso real, no solo avance administrativo.
Evitar duplicar productos DSDM con documentación corporativa existente si puede integrarse o adaptarse.
Construir un set mínimo de productos DSDM para un proyecto de riesgo medio en una organización con PMO.
Tema 13: MoSCoW: priorización real y gestión del alcance
Aplicar MoSCoW para separar Must Have, Should Have, Could Have y Won’t Have de forma útil y negociable.
Definir Must Have como requisito sin el cual la solución no es viable, legal, segura o útil para el objetivo acordado.
Evitar que todo se clasifique como Must Have por presión política, miedo a perder alcance o falta de decisión de negocio.
Usar Should Have para funcionalidades importantes que aportan valor, pero que podrían diferirse temporalmente si el plazo lo exige.
Gestionar Could Have como margen de flexibilidad para absorber incertidumbre sin comprometer calidad ni fecha.
Documentar Won’t Have this time para proteger foco y evitar debates recurrentes sobre elementos fuera de la entrega actual.
Relacionar MoSCoW con timeboxing, planificación, gestión de cambios, comunicación y expectativas de stakeholders.
Revisar prioridades en función de feedback, riesgos, aprendizaje y evolución del caso de negocio.
Crear criterios de priorización transparentes: valor, riesgo, dependencia, cumplimiento, urgencia, coste de demora y aprendizaje.
Construir una priorización MoSCoW completa con negociación real entre negocio, tecnología y dirección.
Tema 14: Timeboxing: entregar a tiempo sin degradar calidad
Entender el timebox como contenedor de trabajo con objetivo, duración fija, prioridades claras y revisión al cierre.
Diseñar timeboxes con tamaño adecuado, capacidad real, objetivos alcanzables y margen para pruebas, feedback y ajuste.
Dividir el trabajo dentro del timebox en investigación, desarrollo, prueba, revisión y preparación de entrega.
Relacionar timeboxing con MoSCoW para ajustar alcance cuando aparece incertidumbre o falta de capacidad.
Evitar usar timeboxes como sprints de nombre distinto sin disciplina de prioridades, calidad y gestión de expectativas.
Definir criterios de entrada y salida para que cada timebox arranque con claridad y cierre con evidencia verificable.
Gestionar interrupciones, dependencias externas, cambios urgentes y bloqueos sin romper el compromiso temporal.
Revisar resultados del timebox con negocio, no solo con el equipo técnico.
Medir cumplimiento, calidad, feedback, defectos, capacidad y aprendizaje para mejorar timeboxes siguientes.
Construir un calendario de timeboxes para un proyecto DSDM con objetivos, entregables, riesgos y revisiones.
Tema 15: Workshops facilitados y colaboración efectiva
Diseñar workshops como mecanismo central para tomar decisiones, aclarar requisitos, resolver conflictos y alinear stakeholders.
Preparar cada workshop con objetivo, participantes, agenda, materiales, decisiones esperadas y criterios de éxito.
Facilitar sesiones de priorización, modelado, riesgos, requisitos, arquitectura, beneficios, retrospectiva o planificación.
Incluir a las personas con autoridad real de decisión para evitar reuniones donde todo queda pendiente.
Usar técnicas visuales, dinámicas de grupo, timeboxing de conversación y registro de decisiones.
Gestionar conflictos entre áreas, presión por alcance, criterios de negocio contradictorios y expectativas no realistas.
Evitar workshops convertidos en presentaciones unidireccionales donde no se decide ni se construye nada.
Documentar acuerdos, decisiones, dudas abiertas, responsables y próximos pasos de forma ligera y accionable.
Medir efectividad de workshops por decisiones tomadas, ambigüedad reducida y avance real del proyecto.
Construir una agenda completa para un workshop de Foundations y otro de priorización MoSCoW.
Tema 16: Modelado y prototipado para reducir incertidumbre
Usar modelado como herramienta para pensar, comunicar y validar, no como producción de diagramas por obligación.
Crear modelos de proceso, experiencia de usuario, datos, arquitectura, integración o reglas de negocio según necesidad del proyecto.
Aplicar prototipos para descubrir expectativas, validar flujos, reducir riesgo y mejorar conversación con usuarios.
Diferenciar prototipo exploratorio, prototipo evolutivo, mockup, prueba técnica y solución lista para producción.
Evitar que los prototipos se conviertan en compromisos funcionales no validados ni en código productivo sin calidad.
Modelar lo suficiente para tomar decisiones, detectar dependencias y orientar construcción, sin bloquear el avance.
Incorporar usuarios de negocio en revisión de modelos y prototipos para descubrir errores temprano.
Documentar decisiones derivadas del modelado, especialmente cuando afectan arquitectura, experiencia o procesos operativos.
Usar herramientas colaborativas para que modelos sean visibles, comentables y actualizables por el equipo.
Construir modelos ligeros de proceso, datos y solución para una iniciativa DSDM antes de arrancar desarrollo.
Tema 17: Requisitos, user stories y criterios de aceptación en DSDM
Gestionar requisitos como elementos vivos priorizados por valor, riesgo y necesidad de entrega, no como contrato cerrado al inicio.
Combinar requisitos de alto nivel, user stories, casos de uso, reglas de negocio, prototipos y criterios de aceptación según contexto.
Escribir user stories que expresen necesidad de usuario, valor y resultado esperado sin esconder requisitos técnicos críticos.
Definir criterios de aceptación verificables que permitan validar funcionalidad, calidad, seguridad, rendimiento o cumplimiento.
Mantener trazabilidad entre objetivo de negocio, requisito, prioridad MoSCoW, timebox, prueba y entrega.
Evitar backlog saturado con historias pequeñas sin relación clara con beneficios, procesos o decisiones de negocio.
Identificar requisitos no funcionales como seguridad, disponibilidad, accesibilidad, rendimiento, datos, compliance y soporte.
Revisar prioridades y detalle de requisitos de forma iterativa conforme aumenta el aprendizaje del equipo.
Incluir requisitos técnicos habilitadores cuando son necesarios para entregar valor sostenible.
Construir una Prioritised Requirements List con historias, criterios, MoSCoW, dependencias y riesgos.
Tema 18: Calidad no negociable y pruebas desde el inicio
Definir nivel de calidad esperado antes de construir, incluyendo criterios funcionales, técnicos, regulatorios y operativos.
Integrar pruebas desde el inicio del timebox, evitando fases tardías de QA que descubren problemas cuando ya no hay margen.
Diseñar estrategia de pruebas combinando pruebas de aceptación, unitarias, integración, exploratorias, seguridad, rendimiento y regresión.
Establecer criterios de aceptación comunes entre negocio, QA, desarrollo y dirección.
Evitar reducir calidad para cumplir plazo, porque DSDM permite ajustar alcance, no degradar la solución.
Definir Definition of Done adaptada a DSDM con pruebas, documentación mínima, revisión, despliegue y aceptación.
Gestionar defectos por severidad, prioridad, impacto de negocio y relación con Must Haves.
Incluir usuarios de negocio en validación temprana para detectar malentendidos antes de final de release.
Medir calidad mediante defectos, retrabajo, pruebas completadas, aceptación, incidencias postdespliegue y deuda acumulada.
Construir un plan de calidad DSDM para un proyecto con restricciones de seguridad, integración y operación.
Tema 19: Gestión de riesgos e issues en proyectos DSDM
Identificar riesgos desde Pre-Project y Feasibility, revisándolos durante Foundations, timeboxes, despliegue y postproyecto.
Clasificar riesgos por negocio, tecnología, personas, proveedores, datos, seguridad, cumplimiento, integración y adopción.
Usar la entrega iterativa para reducir incertidumbre temprano, no para posponer riesgos hasta fases finales.
Mantener riesgos visibles, con owner, impacto, probabilidad, estrategia de respuesta y fecha de revisión.
Gestionar issues como problemas reales que ya impactan el proyecto, diferenciándolos de riesgos potenciales.
Escalar decisiones bloqueadas cuando el equipo no tiene autoridad para resolverlas dentro del timebox.
Evitar registros de riesgos extensos que nadie actualiza ni utiliza para tomar decisiones.
Relacionar riesgos con MoSCoW, timeboxing, despliegue, calidad y plan de beneficios.
Revisar riesgos en cada punto de control, demostración, planificación o reunión de gobierno.
Construir un risk log y un issue log adaptados a DSDM con acciones, owners y decisiones asociadas.
Tema 20: Planificación, estimación y control sin falsa precisión
Crear planificación progresiva que combina visión de alto nivel con detalle suficiente para el siguiente timebox.
Estimar con participación del equipo, considerando incertidumbre, dependencias, disponibilidad real y trabajo no productivo.
Evitar planes cerrados al inicio que ignoran aprendizaje, feedback, cambios de prioridad y riesgos emergentes.
Usar MoSCoW para proteger fechas mediante ajuste de alcance en lugar de presión constante sobre el equipo.
Definir releases, increments, timeboxes y milestones con relación clara a valor de negocio.
Mantener Delivery Plan como herramienta viva de decisión, no como documento contractual inmóvil.
Revisar capacidad considerando reuniones, soporte, incidencias, dependencias, vacaciones, formación y actividades no planificadas.
Medir progreso por valor entregado, Must Haves completados, calidad validada y riesgos reducidos.
Gestionar cambios en planificación con transparencia hacia sponsor, PMO, usuarios y equipo.
Construir un plan de entrega DSDM con releases, timeboxes, prioridades, dependencias y supuestos.
Tema 21: Gobierno, reporting y relación con PMO
Diseñar reporting DSDM orientado a decisiones: valor, plazo, calidad, riesgos, alcance variable, beneficios y bloqueos.
Traducir información ágil a formatos comprensibles para dirección, PMO, comités, sponsors y áreas de control.
Evitar reportes extensos que describen actividad pero no muestran decisiones necesarias ni riesgos reales.
Definir puntos de control ligeros en fases, timeboxes, releases y despliegues.
Integrar DSDM con prácticas de portfolio, priorización estratégica, presupuesto, compras y gestión de proveedores.
Mantener trazabilidad suficiente para auditoría sin convertir el proyecto en un proceso documental pesado.
Usar métricas como cumplimiento de timebox, avance de Must Haves, defectos, cambios de prioridad, riesgos y beneficios.
Gestionar excepciones cuando fecha, coste, calidad o viabilidad se ven amenazados.
Alinear PMO y equipos ágiles para que control y autonomía no se perciban como fuerzas opuestas.
Construir un cuadro de gobierno DSDM para dirección con indicadores, decisiones y riesgos accionables.
Tema 22: Integración de DSDM con Scrum, Kanban, PRINCE2 y enfoques híbridos
Entender cómo DSDM puede convivir con Scrum cuando el equipo usa sprints, eventos, backlog y roles de producto.
Usar DSDM para aportar visión de proyecto, gobierno, roles de negocio, productos y control cuando Scrum se queda en nivel de equipo.
Integrar Kanban para gestión de flujo, soporte, mantenimiento o equipos con demanda continua dentro de un entorno DSDM.
Combinar DSDM con PRINCE2 o gobierno corporativo cuando la organización necesita control formal de inversión, riesgos y etapas.
Evitar híbridos incoherentes donde se suman ceremonias y documentos sin eliminar duplicidades ni aclarar decisiones.
Definir qué marco aporta qué: gestión de proyecto, entrega de equipo, flujo, gobierno, portfolio, producto o control de cambios.
Adaptar lenguaje y artefactos para que negocio, PMO y equipos ágiles no trabajen con vocabularios incompatibles.
Revisar contratos con proveedores cuando se quiere aplicar DSDM en entornos con alcance variable y fecha fija.
Documentar el modelo híbrido con responsabilidades, eventos, productos, decisiones, métricas y excepciones.
Construir un mapa de integración DSDM-Scrum-PMO para una organización con varios equipos de entrega.
Tema 23: DSDM en proyectos digitales, datos, IA y transformación
Aplicar DSDM a productos digitales donde negocio, UX, tecnología, datos y operación deben trabajar con feedback continuo.
Usar Feasibility y Foundations para reducir incertidumbre en proyectos de datos, IA, automatización o integración compleja.
Gestionar requisitos no funcionales de IA, datos, seguridad, ética, privacidad, explicabilidad y calidad desde el inicio.
Priorizar casos de uso de transformación según valor, riesgo, viabilidad técnica, adopción y capacidad organizativa.
Usar prototipos, pruebas de concepto y experimentos controlados sin confundir aprendizaje con solución productiva.
Diseñar timeboxes para explorar datos, validar modelos, construir pipelines, revisar procesos o automatizar tareas.
Incluir áreas legales, seguridad, datos y operación cuando el proyecto afecta información sensible o decisiones relevantes.
Gestionar despliegue y adopción como parte crítica de proyectos de transformación, no como comunicación final.
Medir beneficios más allá de entrega técnica: eficiencia, reducción de errores, adopción, satisfacción y capacidad de cambio.
Construir un caso DSDM aplicado a una iniciativa de automatización o IA con incertidumbre inicial.
Tema 24: Adopción de DSDM en la empresa
Diseñar una implantación gradual de DSDM con pilotos, formación, coaching, selección de proyectos y medición de resultados.
Identificar proyectos adecuados para empezar: suficiente valor, sponsor comprometido, equipo disponible y riesgo controlado.
Crear comunidad interna de práctica para compartir plantillas, aprendizajes, ejemplos, métricas y dificultades.
Formar a roles de negocio, no solo a equipos técnicos, porque DSDM depende de colaboración y decisión frecuente.
Adaptar productos, ceremonias y reporting a la cultura corporativa sin eliminar principios esenciales.
Gestionar resistencia de perfiles acostumbrados a alcance fijo, aprobaciones secuenciales o documentación exhaustiva.
Crear un modelo de madurez para evaluar colaboración, priorización, calidad, gobierno, beneficios y capacidad de entrega.
Medir adopción con indicadores de negocio, no solo número de proyectos que dicen usar DSDM.
Ajustar estándares internos tras cada piloto para mejorar plantillas, roles, timeboxes y gobierno.
Construir un roadmap de adopción DSDM de 30, 60 y 90 días para una organización.
Tema 25: Proyecto final integrador: implantación DSDM de un proyecto empresarial
Seleccionar un caso de proyecto empresarial con necesidad de negocio clara, restricciones de tiempo, varios stakeholders y cierta incertidumbre.
Preparar Pre-Project con problema, sponsor, valor esperado, encaje estratégico, riesgos iniciales y recomendación de continuidad.
Ejecutar Feasibility con análisis de viabilidad, alternativas, riesgos, dependencias, enfoque de solución y decisión razonada.
Construir Foundations con visión, roles, productos, arquitectura de alto nivel, plan inicial, MoSCoW y acuerdos de trabajo.
Diseñar Prioritised Requirements List con requisitos, historias, criterios de aceptación, dependencias y clasificación MoSCoW.
Planificar varios timeboxes con objetivos, entregables, responsables, workshops, pruebas, revisiones y gestión de riesgos.
Crear productos de gobierno adaptados: Business Case, Delivery Plan, Timebox Plan, Risk Log, Definition of Done y Benefits Assessment.
Simular revisión de timebox, decisión de ajuste de alcance, gestión de cambio y comunicación con sponsor o PMO.
Preparar Deployment con plan de transición, formación, soporte, comunicación, go/no-go y seguimiento inicial.
Presentar el caso final con ciclo completo DSDM, decisiones, beneficios esperados, métricas, riesgos y plan de mejora continua.
Perfiles profesionales
Pensado para quienes deben dominar DSDM (Dynamic Systems Development Method) en su día a día
Project managers y responsables de proyecto
Este curso encaja con responsables que necesitan gestionar proyectos ágiles sin perder visibilidad sobre alcance, riesgos, planificación, entregas, roles y beneficios. Aprenderán a usar DSDM para equilibrar flexibilidad y control, manteniendo foco en valor de negocio, cumplimiento de plazos y calidad acordada.
Product owners, business owners y perfiles de negocio
Los perfiles de negocio podrán entender cómo participar activamente en DSDM, definir prioridades, validar entregas, tomar decisiones y proteger el valor del producto. La formación les ayuda a dejar de actuar como meros solicitantes y pasar a ser parte activa de la entrega.
Preguntas frecuentes
Resolvemos todas tus dudas sobre nuestra formación en DSDM (Dynamic Systems Development Method)
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
El curso se centra en DSDM como marco ágil de proyecto, tomando como referencia el DSDM Project Framework de Agile Business Consortium, sus principios, roles, productos, prácticas y ciclo de vida.
No. Es una formación corporativa práctica sobre DSDM aplicada a proyectos empresariales. Puede ayudar a comprender conceptos relacionados con AgilePM, pero no sustituye una preparación oficial de certificación.
Sí. Scrum suele centrarse en el equipo y el desarrollo iterativo, mientras que DSDM aporta una visión más amplia de proyecto, gobierno, negocio, roles, productos, fases y beneficios. Puede complementar Scrum si se adapta bien.
El proceso DSDM se estructura en seis fases: Pre-Project, Feasibility, Foundations, Evolutionary Development, Deployment y Post-Project.
DSDM mantiene gobierno, planificación y control, pero trabaja con entrega incremental, colaboración frecuente, priorización MoSCoW, timeboxing y alcance variable. La diferencia clave es controlar sin bloquear el aprendizaje.
MoSCoW es una técnica de priorización que clasifica requisitos como Must Have, Should Have, Could Have y Won’t Have this time. En DSDM es clave para proteger plazos y calidad ajustando alcance.
No solo perfiles técnicos. DSDM requiere negocio, dirección, PMO, project managers, analistas, QA, desarrollo, producto y stakeholders con capacidad de decisión, porque la colaboración es parte central del marco.
Sí. Aunque DSDM nació vinculado al desarrollo de sistemas, sus principios y prácticas pueden aplicarse a transformación, procesos, operaciones, datos, productos digitales y proyectos empresariales con entrega incremental.
Sí. El curso cubre productos DSDM, reporting a PMO, roles, riesgos, beneficios, control de timeboxes, decisiones de escalado y adaptación a entornos corporativos con gobierno formal.
Sí, siempre que se adapte el nivel de formalidad. DSDM permite demostrar control, documentar decisiones, gestionar calidad y mantener trazabilidad sin renunciar a iteración y feedback temprano.
Sí. Al tratarse de una formación corporativa en gestión de proyectos, agilidad, productividad, colaboración, transformación y competencias profesionales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
El curso se centra en DSDM como marco ágil de proyecto, tomando como referencia el DSDM Project Framework de Agile Business Consortium, sus principios, roles, productos, prácticas y ciclo de vida.
No. Es una formación corporativa práctica sobre DSDM aplicada a proyectos empresariales. Puede ayudar a comprender conceptos relacionados con AgilePM, pero no sustituye una preparación oficial de certificación.
Sí. Scrum suele centrarse en el equipo y el desarrollo iterativo, mientras que DSDM aporta una visión más amplia de proyecto, gobierno, negocio, roles, productos, fases y beneficios. Puede complementar Scrum si se adapta bien.
El proceso DSDM se estructura en seis fases: Pre-Project, Feasibility, Foundations, Evolutionary Development, Deployment y Post-Project.
DSDM mantiene gobierno, planificación y control, pero trabaja con entrega incremental, colaboración frecuente, priorización MoSCoW, timeboxing y alcance variable. La diferencia clave es controlar sin bloquear el aprendizaje.
MoSCoW es una técnica de priorización que clasifica requisitos como Must Have, Should Have, Could Have y Won’t Have this time. En DSDM es clave para proteger plazos y calidad ajustando alcance.
No solo perfiles técnicos. DSDM requiere negocio, dirección, PMO, project managers, analistas, QA, desarrollo, producto y stakeholders con capacidad de decisión, porque la colaboración es parte central del marco.
Sí. Aunque DSDM nació vinculado al desarrollo de sistemas, sus principios y prácticas pueden aplicarse a transformación, procesos, operaciones, datos, productos digitales y proyectos empresariales con entrega incremental.
Sí. El curso cubre productos DSDM, reporting a PMO, roles, riesgos, beneficios, control de timeboxes, decisiones de escalado y adaptación a entornos corporativos con gobierno formal.
Sí, siempre que se adapte el nivel de formalidad. DSDM permite demostrar control, documentar decisiones, gestionar calidad y mantener trazabilidad sin renunciar a iteración y feedback temprano.
Sí. Al tratarse de una formación corporativa en gestión de proyectos, agilidad, productividad, colaboración, transformación y competencias profesionales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Diseñemos hoy el curso que tu empresa necesita
Cuéntanos tus objetivos de negocio y prepararemos una propuesta formativa bonificable totalmente ad hoc
Mejora priorización y toma de decisiones La formación enseña a priorizar con criterios transparentes, gestionar Must Haves de forma rigurosa y usar timeboxes como herramienta de foco. Esto reduce discusiones interminables sobre alcance.
3
Facilita integración con PMO y marcos existentes DSDM puede adaptarse a organizaciones que ya usan Scrum, Kanban, PRINCE2, PMO o modelos híbridos. El curso enseña a integrarlo sin duplicar ceremonias, roles ni documentación innecesaria.
4
Refuerza calidad desde el inicio El principio de no comprometer calidad se traduce en criterios de aceptación, pruebas tempranas, Definition of Done, validación continua y gestión de defectos. Esto reduce retrabajo y problemas al desplegar.
5
Orienta la entrega a beneficios El curso insiste en que el proyecto no termina al entregar funcionalidades. DSDM permite conectar necesidad de negocio, solución, adopción, medición de beneficios y aprendizaje postproyecto.
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Ejercicios prácticos
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Practica y mejora con nuestra plataforma
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
Los equipos técnicos y funcionales podrán aplicar DSDM en el día a día mediante timeboxes, colaboración, pruebas tempranas, requisitos priorizados, modelado, definición de calidad y entregas incrementales. El curso les aporta claridad sobre responsabilidades, expectativas y forma de trabajar.
PMO, transformación y gobierno corporativo
Los perfiles de PMO y transformación podrán adaptar DSDM a entornos empresariales donde existen comités, presupuestos, reporting, auditoría, dependencias, arquitectura, seguridad y control de beneficios. La formación ayuda a implantar agilidad con trazabilidad y no como una capa informal paralela.
Scrum Masters, agile coaches y facilitadores
Los facilitadores podrán incorporar prácticas de DSDM para mejorar priorización, workshops, gobierno de proyecto, colaboración con negocio y planificación orientada a plazos. El curso les ayuda a complementar Scrum con una visión de proyecto más completa.
Dirección y responsables de área
Los responsables de área podrán comprender qué exige DSDM a nivel de patrocinio, decisiones, disponibilidad del negocio y medición de beneficios. La formación permite evaluar si la organización está preparada para trabajar de forma ágil sin delegar todo en el equipo técnico.
