Curso de FDD (Feature Driven Development) para equipos de desarrollo

Entender Feature Driven Development como una metodología ágil centrada en funcionalidades pequeñas y orientadas a valor.

Diferenciar FDD de Scrum, Kanban, XP, Waterfall, SAFe y desarrollo basado solo en tareas técnicas.

Comprender por qué FDD nació para aportar estructura, visibilidad y disciplina técnica en proyectos complejos.

Reconocer el valor de trabajar con features como unidad de planificación, diseño, seguimiento y entrega.

Analizar problemas que FDD ayuda a resolver: backlog confuso, falta de diseño, dependencias ocultas y avance poco trazable.

Separar “entregar muchas tareas” de “entregar funcionalidad útil y verificable”.

Entender la importancia del modelo general del dominio antes de descomponer features.

Revisar cuándo FDD encaja mejor: sistemas complejos, dominios ricos, equipos medianos, productos empresariales y software con fuerte lógica de negocio.

Detectar cuándo FDD puede resultar excesivo si el producto es pequeño, exploratorio o muy cambiante.

Crear una definición operativa de FDD adaptada al contexto de la empresa.

Trabajar en torno a funcionalidades pequeñas, concretas y orientadas a cliente o usuario.

Mantener un modelo compartido del dominio para que las features no se diseñen de forma inconexa.

Favorecer ciclos cortos de diseño y construcción en lugar de grandes fases previas.

Asegurar ownership técnico mediante roles claros, responsables de clases, componentes o áreas del sistema.

Dar visibilidad del progreso a partir de features terminadas, no solo horas, tareas o actividad.

Incorporar revisión, inspección y calidad como parte natural del flujo.

Evitar documentación pesada, pero mantener modelos y artefactos útiles.

Diseñar antes de construir lo suficiente para reducir retrabajo sin paralizar la entrega.

Coordinar equipos dinámicos alrededor de features concretas.

Mantener una disciplina incremental donde cada feature deja el producto en mejor estado.

Desarrollar un modelo global para comprender dominio, arquitectura, datos, reglas y áreas funcionales.

Construir una lista de features organizada por áreas de negocio, procesos y capacidad del producto.

Planificar por feature teniendo en cuenta prioridad, dependencia, riesgo, tamaño y ownership.

Diseñar por feature mediante equipos pequeños, revisión técnica, secuencias y decisiones de implementación.

Construir por feature con código, pruebas, revisión, integración y cierre formal.

Adaptar estos procesos a equipos que trabajan con sprints, flujo Kanban o ciclos de delivery continuo.

Evitar interpretar los cinco procesos como fases rígidas y secuenciales de tipo waterfall.

Mantener feedback continuo entre modelo, lista de features, implementación y aprendizaje real.

Usar los procesos como marco de disciplina, no como plantilla burocrática.

Definir cómo se verían estos cinco procesos dentro de la herramienta de gestión del equipo.

Crear un modelo inicial del sistema para entender conceptos, relaciones, reglas y límites funcionales.

Identificar áreas principales del dominio: usuarios, operaciones, entidades, procesos, estados, eventos y resultados.

Diferenciar modelo conceptual, modelo técnico, modelo de datos y modelo de arquitectura.

Usar UML, C4, diagramas de dominio, mapas de contexto o representaciones ligeras según necesidad.

Evitar modelos demasiado detallados que intentan anticipar todo el código.

Mantener el modelo suficientemente claro para guiar features, conversaciones y decisiones técnicas.

Conectar el modelo con lenguaje común de negocio para reducir malentendidos.

Revisar el modelo cuando aparecen nuevas features que lo contradicen o amplían.

Usar el modelo como mapa, no como contrato inamovible.

Preparar una práctica de modelado colaborativo entre negocio, arquitectura, desarrollo y QA.

Crear una lista de features derivada del modelo, no solo de peticiones sueltas.

Redactar features con enfoque de acción, resultado y valor observable.

Organizar features por áreas, procesos, capacidades, módulos o dominios funcionales.

Descomponer features grandes hasta que puedan diseñarse y construirse en ciclos cortos.

Evitar features puramente técnicas sin conexión con comportamiento visible o habilitador claro.

Diferenciar features de épicas, historias, tareas, bugs, mejoras, spikes y deuda técnica.

Incorporar criterios de aceptación, datos necesarios, usuarios afectados y dependencias.

Revisar la lista con negocio y equipo técnico para detectar huecos, duplicidades o ambigüedades.

Mantener features trazables desde necesidad, modelo y prioridad hasta código y pruebas.

Crear un backlog FDD que no sea una acumulación infinita, sino un mapa ordenado de capacidades.

Aplicar una estructura simple: acción + resultado + objeto de negocio.

Redactar features suficientemente pequeñas para completarse en pocos días de trabajo efectivo.

Evitar enunciados vagos como “mejorar gestión”, “optimizar módulo” o “hacer integración”.

Separar feature funcional de tarea técnica necesaria para construirla.

Incluir contexto mínimo: usuario, escenario, regla, dato y resultado esperado.

Comprobar si la feature puede probarse de forma objetiva.

Identificar si la feature entrega valor directo o habilita valor posterior.

Revisar si la feature toca demasiadas áreas y debe dividirse.

Añadir ejemplos de entrada/salida cuando reduce ambigüedad.

Crear una guía interna de redacción para que todo el equipo escriba features comparables.

Priorizar features por valor, riesgo, dependencia, urgencia, complejidad y aprendizaje.

Crear planes de entrega basados en funcionalidades completas y no en tareas fragmentadas.

Asignar propietarios técnicos o responsables por clase, componente, módulo o feature.

Identificar dependencias entre features, datos, servicios, APIs, diseño UX e infraestructura.

Agrupar features en paquetes de entrega, releases, iteraciones o milestones.

Estimar tamaño de features con criterios ligeros y comparables.

Detectar features bloqueantes que deben resolverse pronto para reducir incertidumbre.

Balancear features de negocio, features técnicas habilitadoras y deuda técnica necesaria.

Usar el avance de features terminadas como métrica principal de progreso.

Revisar el plan de forma continua según aprendizaje, incidencias y cambios de prioridad.

Entender roles clásicos de FDD: project manager, chief architect, development manager, chief programmer, class owner y domain expert.

Traducir esos roles a equipos actuales: product owner, tech lead, architect, developer, QA, UX, data, DevOps y stakeholder.

Definir quién es responsable de diseñar, construir, revisar, probar, aceptar y desplegar cada feature.

Aclarar ownership técnico de componentes, módulos, clases o servicios para evitar zonas sin responsable.

Evitar que el chief programmer se convierta en cuello de botella.

Crear feature teams pequeños y temporales según la funcionalidad.

Coordinar expertos de dominio con desarrolladores durante diseño y validación.

Asignar responsabilidades de calidad, seguridad y pruebas desde el inicio.

Establecer mecanismos de revisión cruzada para no depender de una sola persona.

Documentar roles de forma ligera para que cada feature tenga responsables claros.

Formar pequeños grupos alrededor de features concretas cuando se necesita diseño y construcción coordinada.

Incluir perfiles necesarios: backend, frontend, QA, UX, datos, arquitectura o DevOps según el caso.

Evitar handoffs largos entre análisis, diseño, desarrollo y pruebas.

Organizar sesiones cortas de diseño por feature antes de codificar.

Revisar dependencias con otros equipos o componentes compartidos.

Mantener comunicación clara entre feature team y responsables de dominio técnico.

Evitar que cada feature team tome decisiones incompatibles con la arquitectura global.

Resolver conflictos entre autonomía del equipo y coherencia del sistema.

Coordinar entregas parciales sin romper el flujo de integración.

Crear prácticas de colaboración que hagan que FDD no sea solo asignación individual de tareas.

Preparar un diseño técnico mínimo antes de construir la funcionalidad.

Identificar clases, servicios, componentes, endpoints, pantallas, eventos, tablas o integraciones afectadas.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.