Curso de FDD (Feature Driven Development) 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 FDD (Feature Driven Development)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 FDD (Feature Driven Development) 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 FDD (Feature Driven Development) ante FUNDAE.
Ordena el trabajo alrededor de funcionalidades reales
Forma a tu equipo en FDD (Feature Driven Development) A Medida, mejora entregas y calidad, bonificable por FUNDAE en la plantilla. Solicita propuesta a medida.
Mejora planificación y trazabilidad Permite conectar necesidades, modelo de dominio, features, responsables, código, pruebas, releases y métricas de avance.
1
Refuerza diseño sin burocracia El curso enseña a diseñar lo suficiente antes de construir, evitando tanto la improvisación como el análisis excesivo.
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
Partir de una necesidad sencilla de negocio para entender cómo FDD transforma una idea amplia en funcionalidades concretas.
Identificar el área del dominio afectada, los usuarios implicados, los datos relevantes y el resultado esperado.
Redactar una primera feature con estructura clara, orientada a acción y valor observable.
Diferenciar una feature FDD de una tarea técnica, una épica, una historia de usuario genérica o una incidencia.
Revisar qué información mínima necesita el equipo para diseñar y construir la feature sin ambigüedad.
Ubicar la feature dentro de un modelo general del sistema, evitando tratarla como una pieza aislada.
Estimar su tamaño, dependencia, complejidad, riesgo y posible propietario técnico.
Diseñar un mini flujo de trabajo: análisis, diseño, construcción, revisión, prueba, integración y cierre.
Detectar errores habituales desde el primer ejemplo: features demasiado grandes, técnicas, vagas o sin criterio de aceptación.
Cerrar el recorrido entendiendo la lógica completa de FDD: modelar, listar, planificar, diseñar y construir por funcionalidades.
Partir de una necesidad sencilla de negocio para entender cómo FDD transforma una idea amplia en funcionalidades concretas.
Identificar el área del dominio afectada, los usuarios implicados, los datos relevantes y el resultado esperado.
Redactar una primera feature con estructura clara, orientada a acción y valor observable.
Diferenciar una feature FDD de una tarea técnica, una épica, una historia de usuario genérica o una incidencia.
Revisar qué información mínima necesita el equipo para diseñar y construir la feature sin ambigüedad.
Ubicar la feature dentro de un modelo general del sistema, evitando tratarla como una pieza aislada.
Estimar su tamaño, dependencia, complejidad, riesgo y posible propietario técnico.
Diseñar un mini flujo de trabajo: análisis, diseño, construcción, revisión, prueba, integración y cierre.
Detectar errores habituales desde el primer ejemplo: features demasiado grandes, técnicas, vagas o sin criterio de aceptación.
Cerrar el recorrido entendiendo la lógica completa de FDD: modelar, listar, planificar, diseñar y construir por funcionalidades.
Usar diagramas ligeros de secuencia, componentes, flujo o estados cuando aclaran la implementación.
Revisar reglas de negocio, validaciones, errores, permisos y casos límite.
Conectar el diseño con pruebas esperadas y criterios de aceptación.
Detectar si la feature exige cambio arquitectónico, refactorización o nueva integración.
Evitar diseñar únicamente desde la pantalla o desde la base de datos.
Incluir revisión de seguridad, rendimiento y mantenibilidad cuando la feature lo requiere.
Documentar decisiones relevantes sin crear documentos extensos que nadie actualiza.
Cerrar el diseño con una lista clara de tareas técnicas coherentes con la feature.
Tema 12: Construcción por feature
Implementar código enfocado en completar una feature concreta, evitando mezclar cambios ajenos.
Mantener commits, ramas o pull requests alineados con la feature.
Desarrollar verticalmente cuando sea posible: interfaz, API, dominio, datos, pruebas y documentación.
Evitar dejar funcionalidades a medias integradas en producción sin control.
Aplicar pruebas unitarias, integración, contrato, UI o aceptación según el tipo de feature.
Revisar código con atención a diseño, claridad, cobertura y efectos secundarios.
Integrar pronto para evitar grandes ramas divergentes.
Documentar cambios relevantes en modelo, API, datos o comportamiento.
Validar la feature contra criterios definidos antes de marcarla como terminada.
Crear una definición de done específica para features FDD.
Tema 13: Inspecciones, revisiones y calidad técnica
Recuperar la idea FDD de inspección como revisión disciplinada de diseño y código.
Diferenciar revisión de diseño, revisión de código, revisión de pruebas y revisión funcional.
Crear checklists ligeros para revisar claridad, responsabilidad, duplicación, seguridad, rendimiento y pruebas.
Evitar inspecciones pesadas que ralenticen el delivery sin aportar valor.
Revisar features pequeñas con más rapidez y profundidad.
Detectar defectos antes de que entren en integración o producción.
Mantener estándares de código, arquitectura, naming, pruebas y documentación.
Usar pull requests como mecanismo moderno de inspección.
Registrar aprendizajes de revisión para mejorar futuras features.
Convertir calidad en parte del flujo, no en auditoría tardía.
Tema 14: Seguimiento de avance y reporting por feature
Medir progreso por features completadas, en diseño, en construcción, bloqueadas o aceptadas.
Crear tableros que muestren estado real de la funcionalidad y no solo tareas movidas.
Relacionar avance con áreas del dominio y capacidad del producto.
Detectar features bloqueadas por dependencias, dudas de negocio, deuda técnica o falta de datos.
Usar burn-up, cumulative flow, throughput o métricas de ciclo aplicadas a features.
Evitar reportes de porcentaje subjetivo que ocultan problemas.
Mostrar progreso de forma entendible para negocio, dirección y equipo técnico.
Medir tiempo de diseño, tiempo de construcción, tiempo de revisión y tiempo de aceptación.
Analizar defectos por feature para detectar áreas problemáticas.
Crear una cadencia de revisión de features que conecte delivery, calidad y roadmap.
Tema 15: FDD y Scrum: convivencia sin mezclarlo todo
Entender que Scrum organiza ciclos de trabajo y FDD organiza el desarrollo alrededor de funcionalidades.
Convertir features FDD en elementos de backlog compatibles con épicas, historias o PBIs.
Preparar refinements usando modelo de dominio y lista de features.
Planificar sprints con features completas o partes coherentes de features grandes.
Usar daily scrum para detectar bloqueos por feature.
Revisar en sprint review funcionalidades terminadas, no solo tareas técnicas.
Incorporar retrospectivas sobre calidad de features, tamaño, diseño y entrega.
Evitar que FDD duplique ceremonias Scrum innecesariamente.
Mantener Product Backlog y Feature List alineados sin crear dos verdades.
Diseñar un flujo híbrido Scrum + FDD aplicable a equipos reales.
Tema 16: FDD y Kanban: flujo continuo de funcionalidades
Organizar features como unidades de flujo en un sistema Kanban.
Definir columnas de trabajo: modelado, lista, diseño, construcción, revisión, pruebas, aceptación y desplegado.
Limitar WIP para evitar demasiadas features abiertas a la vez.
Medir lead time y cycle time por feature.
Detectar cuellos de botella en diseño, construcción, QA, revisión o aceptación.
Diferenciar flujo de features pequeñas y flujo de cambios técnicos habilitadores.
Incorporar clases de servicio para urgencias, experimentos, deuda técnica o mantenimiento.
Usar políticas explícitas para mover una feature entre estados.
Revisar bloqueos recurrentes y mejorar el sistema de trabajo.
Aplicar FDD en equipos sin sprints que necesitan entrega continua y trazable.
Tema 17: FDD, DDD y modelado de dominio
Conectar FDD con Domain-Driven Design para crear features alineadas con lenguaje de negocio.
Usar bounded contexts para organizar áreas de features.
Derivar features de capacidades del dominio, procesos y eventos relevantes.
Evitar que la lista de features se base solo en pantallas o endpoints.
Modelar entidades, value objects, agregados, servicios de dominio y eventos cuando aporta claridad.
Relacionar features con invariantes, reglas y casos de uso.
Mantener coherencia entre modelo de dominio y código implementado.
Detectar features que cruzan demasiados contextos y requieren rediseño.
Usar expertos de dominio para validar feature lists y reglas.
Crear una práctica FDD + DDD útil para sistemas con lógica compleja.
Tema 18: FDD en arquitectura hexagonal, microservicios y APIs
Mapear features a casos de uso, puertos, adaptadores, controladores, servicios y repositorios.
Diseñar features que atraviesan varias capas sin romper separación de responsabilidades.
Definir cuándo una feature pertenece a un microservicio y cuándo requiere colaboración entre varios.
Crear contratos API alineados con features y no solo con tablas.
Revisar eventos, colas y procesos asíncronos cuando una feature cruza límites de servicio.
Evitar que cada feature cree acoplamientos nuevos sin control arquitectónico.
Planificar features que requieren cambios coordinados en backend, frontend, datos e infraestructura.
Documentar decisiones de arquitectura derivadas de una feature.
Usar tests de contrato y pruebas de integración para validar features distribuidas.
Mantener trazabilidad entre feature, servicio, endpoint, evento y despliegue.
Tema 19: FDD, UX y diseño de experiencia
Traducir necesidades de usuario en features que expresen comportamiento y resultado.
Evitar features formuladas únicamente desde la perspectiva técnica.
Integrar prototipos, flujos de pantalla y criterios de usabilidad en el diseño por feature.
Detectar features que requieren investigación previa antes de entrar en construcción.
Conectar criterios de aceptación con experiencia de usuario, accesibilidad y mensajes de error.
Dividir features UX grandes en incrementos comprobables.
Validar features con usuarios internos, clientes o representantes de negocio.
Medir adopción, fricción y satisfacción tras liberar la funcionalidad.
Evitar que UX quede como fase previa desconectada del desarrollo.
Crear una colaboración fluida entre producto, diseño y feature teams.
Tema 20: FDD y QA basado en funcionalidades
Definir pruebas desde la feature y no solo desde módulos técnicos.
Crear criterios de aceptación verificables antes de construir.
Diseñar pruebas unitarias, integración, contrato, regresión y aceptación según riesgo.
Relacionar casos de prueba con features y reglas de negocio.
Usar matrices de cobertura por feature para detectar huecos.
Priorizar regresión según features afectadas por un cambio.
Incluir QA en diseño por feature para anticipar casos límite.
Medir defectos por feature, fase de detección y causa raíz.
Evitar que QA sea un paso final cuando la feature ya está cerrada técnicamente.
Construir una definición de calidad por feature aceptada por producto y tecnología.
Tema 21: FDD, DevOps y entrega continua
Conectar features con ramas, commits, pull requests, builds, despliegues y releases.
Usar CI/CD para validar cada feature con pruebas, análisis estático, seguridad y calidad.
Aplicar feature flags cuando una funcionalidad necesita desplegarse sin activarse.
Relacionar despliegue técnico con entrega funcional.
Medir si una feature desplegada se usa, falla o genera incidencias.
Preparar rollback o desactivación para features de riesgo.
Evitar grandes releases con muchas features mezcladas y difícil trazabilidad.
Documentar cambios de configuración, infraestructura o datos necesarios por feature.
Integrar observabilidad en features críticas desde el diseño.
Crear un flujo DevOps donde cada feature sea construida, validada, desplegada y observada.
Tema 22: Gestión de deuda técnica dentro de FDD
Identificar deuda técnica que bloquea o encarece features futuras.
Diferenciar deuda técnica habilitadora de refactorizaciones sin impacto claro.
Convertir deuda técnica en features técnicas trazables cuando aporta capacidad futura.
Incluir refactorización dentro de features funcionales cuando reduce riesgo inmediato.
Evitar ocultar deuda técnica dentro de tareas invisibles sin prioridad.
Medir impacto de deuda en tiempo de ciclo, defectos, bloqueos y complejidad.
Planificar mejoras de arquitectura junto a features de negocio.
Crear criterios para aceptar, reducir o posponer deuda.
Revisar ownership de componentes con más deuda o defectos.
Mantener FDD como marco para entregar valor sin deteriorar el sistema.
Tema 23: Métricas de FDD y mejora continua
Medir número de features completadas por periodo sin convertirlo en métrica de presión individual.
Analizar tamaño medio, ciclo, bloqueo, defectos y retrabajo por feature.
Observar distribución de features por área del dominio, equipo, riesgo y tipo de trabajo.
Comparar previsión frente a entrega real para mejorar planificación.
Medir calidad: defectos en revisión, defectos en QA, defectos en producción y defectos recurrentes.
Evaluar tiempo dedicado a diseño frente a tiempo de construcción y corrección.
Detectar features que se repiten como incidentes o cambios mal definidos.
Usar métricas para mejorar el sistema, no para castigar personas.
Conectar métricas FDD con outcomes de producto cuando sea posible.
Crear retrospectivas basadas en datos de features, no solo en percepciones.
Tema 24: Herramientas para aplicar FDD en equipos modernos
Configurar herramientas como Jira, Azure Boards, Linear, YouTrack o Trello para representar features y estados FDD.
Crear tipos de issue, campos, etiquetas, áreas de dominio, owners y relaciones.
Relacionar features con épicas, historias, tareas, bugs, pull requests y releases.
Usar repositorios Git para conectar cambios de código con features.
Crear dashboards de progreso por feature, dominio, estado y release.
Integrar documentación técnica con Confluence, Markdown, Notion, SharePoint o wikis.
Usar diagramas ligeros con Mermaid, PlantUML, Miro, FigJam, Draw.io o herramientas de arquitectura.
Evitar que la herramienta imponga un flujo demasiado complejo.
Automatizar trazabilidad cuando sea posible mediante convenciones de ramas, commits y PRs.
Diseñar una configuración mínima viable de herramienta para empezar con FDD sin fricción.
Tema 25: Antipatrones habituales en Feature Driven Development
Crear features demasiado grandes que en realidad son épicas o proyectos completos.
Redactar features como tareas técnicas sin valor observable.
Mantener una lista de features desconectada del modelo de dominio.
Diseñar demasiado antes de construir y convertir FDD en waterfall encubierto.
Construir sin diseñar y reducir FDD a una lista de tickets.
Asignar ownership excesivamente rígido que impide colaboración.
Medir solo cantidad de features y no calidad, valor o impacto.
Ignorar deuda técnica porque no aparece como feature de negocio.
Duplicar Scrum, Kanban y FDD generando burocracia innecesaria.
Permitir que la feature se cierre sin pruebas, revisión, aceptación o integración real.
Tema 26: Implantación progresiva de FDD en una organización
Evaluar cómo trabaja actualmente el equipo: backlog, planificación, diseño, desarrollo, QA y entrega.
Elegir un producto o área piloto donde FDD pueda aportar visibilidad y orden.
Crear un modelo de dominio inicial ligero para orientar la lista de features.
Convertir parte del backlog actual en una feature list estructurada.
Definir roles mínimos, estados, criterios de ready, criterios de done y responsables.
Configurar la herramienta de gestión sin sobrediseñar campos y procesos.
Aplicar FDD durante varias iteraciones o semanas para observar resultados.
Medir tamaño, flujo, bloqueos, defectos, satisfacción del equipo y claridad de roadmap.
Ajustar el método antes de escalarlo a otros equipos.
Preparar una guía interna de aplicación FDD adaptada a la empresa.
Tema 27: Proyecto final integrador de Feature Driven Development
Seleccionar un producto o sistema de ejemplo con dominio, usuarios, procesos, datos y necesidades funcionales.
Crear un modelo global ligero que represente áreas principales, entidades, relaciones, flujos y límites.
Construir una lista de features organizada por dominios o capacidades del producto.
Redactar features con estructura clara, tamaño adecuado, criterios de aceptación y dependencias.
Priorizar y planificar un primer paquete de features para una entrega incremental.
Diseñar técnicamente varias features mediante diagramas, componentes afectados, pruebas y decisiones de arquitectura.
Preparar el flujo de construcción con tareas técnicas, ownership, revisión, QA, integración y documentación.
Configurar un tablero FDD en una herramienta de gestión con estados, responsables y métricas.
Definir métricas de seguimiento: features terminadas, ciclo, bloqueos, defectos, avance por área e impacto esperado.
Presentar la propuesta final como una metodología FDD aplicable a un equipo real, incluyendo riesgos, ajustes y plan de adopción.
Perfiles profesionales
Pensado para quienes deben dominar FDD (Feature Driven Development) en su día a día
Tech leads y responsables de desarrollo
Perfiles que necesitan mejorar la organización técnica del equipo, dividir el trabajo en funcionalidades pequeñas, reducir dependencias, revisar diseño y mantener calidad sin perder velocidad de entrega.
Arquitectos de software y solución
Profesionales que quieren conectar modelo de dominio, arquitectura, componentes, servicios, clases, APIs y entregas incrementales sin que el diseño se pierda en tareas aisladas.
Product owners y product managers técnicos
Responsables de producto que necesitan transformar necesidades de negocio en features concretas, priorizables, medibles y alineadas con valor, riesgo, dependencia y roadmap.
Preguntas frecuentes
Resolvemos todas tus dudas sobre nuestra formación en FDD (Feature Driven Development)
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.
FDD, Feature Driven Development, es una metodología ágil centrada en desarrollar software a partir de funcionalidades pequeñas, orientadas a valor y construidas mediante ciclos cortos de diseño y construcción.
Scrum define un marco de trabajo por eventos, roles y sprints. FDD se centra en cómo modelar, listar, planificar, diseñar y construir funcionalidades. Pueden combinarse.
No necesariamente. Kanban puede gestionar el flujo continuo de trabajo, mientras FDD aporta estructura para definir, diseñar y seguir funcionalidades.
Es una funcionalidad pequeña, concreta y valiosa, redactada de forma que represente un resultado observable para usuario, cliente, negocio o sistema.
Sí. Puede ayudar a mapear features con bounded contexts, servicios, APIs, eventos, pruebas e integraciones, manteniendo trazabilidad en sistemas distribuidos.
No debería serlo. Bien aplicada, FDD aporta disciplina ligera: modelo suficiente, lista de features, diseño breve, construcción, revisión y seguimiento.
Sí. Las features pueden convivir con historias de usuario. El curso enseña a relacionarlas sin duplicar backlogs ni crear burocracia.
Sí. Se trabaja diseño por feature, arquitectura, DDD, APIs, microservicios, QA, DevOps, métricas, deuda técnica y revisión de código.
Features enormes, backlog confuso, tareas técnicas sin valor visible, falta de diseño, dependencias ocultas, baja trazabilidad y cierres sin pruebas reales.
Sí. Al tratarse de formación corporativa orientada a empresa, puede bonificarse hasta el 100% mediante FUNDAE según el crédito disponible y las condiciones aplicables de la organización.
FDD, Feature Driven Development, es una metodología ágil centrada en desarrollar software a partir de funcionalidades pequeñas, orientadas a valor y construidas mediante ciclos cortos de diseño y construcción.
Scrum define un marco de trabajo por eventos, roles y sprints. FDD se centra en cómo modelar, listar, planificar, diseñar y construir funcionalidades. Pueden combinarse.
No necesariamente. Kanban puede gestionar el flujo continuo de trabajo, mientras FDD aporta estructura para definir, diseñar y seguir funcionalidades.
Es una funcionalidad pequeña, concreta y valiosa, redactada de forma que represente un resultado observable para usuario, cliente, negocio o sistema.
Sí. Puede ayudar a mapear features con bounded contexts, servicios, APIs, eventos, pruebas e integraciones, manteniendo trazabilidad en sistemas distribuidos.
No debería serlo. Bien aplicada, FDD aporta disciplina ligera: modelo suficiente, lista de features, diseño breve, construcción, revisión y seguimiento.
Sí. Las features pueden convivir con historias de usuario. El curso enseña a relacionarlas sin duplicar backlogs ni crear burocracia.
Sí. Se trabaja diseño por feature, arquitectura, DDD, APIs, microservicios, QA, DevOps, métricas, deuda técnica y revisión de código.
Features enormes, backlog confuso, tareas técnicas sin valor visible, falta de diseño, dependencias ocultas, baja trazabilidad y cierres sin pruebas reales.
Sí. Al tratarse de formación corporativa orientada a empresa, puede bonificarse hasta el 100% mediante FUNDAE según el crédito disponible y las condiciones aplicables de la organización.
Diseñemos hoy el curso que tu empresa necesita
Cuéntanos tus objetivos de negocio y prepararemos una propuesta formativa bonificable totalmente ad hoc
Encaja con equipos ágiles actuales FDD se adapta a Scrum, Kanban, DevOps, CI/CD, DDD, microservicios, arquitectura hexagonal y herramientas modernas de gestión.
3
Reduce ambigüedad y retrabajo Features mejor definidas, ownership claro y revisiones tempranas reducen malentendidos, defectos, dependencias ocultas y cambios tardíos.
4
Aporta visibilidad para negocio y tecnología El avance se comunica por funcionalidades entregadas, no solo por tareas completadas, horas consumidas o actividad interna del equipo.
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
Perfiles que acompañan equipos ágiles y quieren incorporar prácticas de FDD para mejorar planificación, seguimiento, ownership, visibilidad de avance y entrega basada en funcionalidades.
Desarrolladores backend, frontend y full stack
Equipos técnicos que quieren trabajar con mayor claridad: saber qué feature se construye, qué diseño la soporta, qué clases o módulos toca, cómo se revisa y cómo se considera terminada.
Equipos de QA y calidad técnica
Profesionales que necesitan conectar funcionalidades con pruebas, criterios de aceptación, revisiones, cobertura, defectos, trazabilidad y validación real del incremento entregado.
