¿Qué es FDD o Feature Driven Development?

FDD (Feature Driven Development), o Desarrollo Guiado por Funcionalidades, es una metodología ágil de desarrollo de software que organiza todo el trabajo alrededor de funcionalidades (features) pequeñas y valoradas por el cliente. Fue creada por Jeff De Luca y Peter Coad en 1997 durante un proyecto de gran escala para el United Overseas Bank en Singapur, un sistema con más de 2.000 funcionalidades y 50 desarrolladores.

A diferencia de otros enfoques ágiles como Scrum o Extreme Programming (XP), FDD se diseñó específicamente para proyectos grandes y complejos donde la coordinación de múltiples equipos es crítica. Su enfoque en funcionalidades granulares (que deben completarse en un máximo de dos semanas) permite mantener la trazabilidad del progreso y ofrecer visibilidad constante a los stakeholders.

FDD se basa en un principio fundamental: las funcionalidades son la unidad básica de planificación, trabajo y seguimiento. Cada funcionalidad se expresa en el formato: "acción - resultado - objeto", por ejemplo: "Calcular el total de una venta" o "Validar la dirección de envío del cliente". Este formato estandarizado asegura que cada funcionalidad sea comprensible tanto para el equipo técnico como para el negocio.

FDD se estructura en cinco procesos secuenciales que guían el desarrollo desde la concepción hasta la entrega:

1. Desarrollar un modelo global (Develop an Overall Model)

El equipo, junto con expertos del dominio, construye un modelo de objetos de alto nivel que representa el sistema completo. Este proceso combina sesiones de modelado colaborativo (domain walkthroughs) donde los expertos del negocio explican el dominio y los desarrolladores crean diagramas UML que capturan la estructura.

Duración típica: 1-2 semanas para proyectos medianos.

Resultado: un modelo de dominio que sirve como mapa del sistema.

2. Construir una lista de funcionalidades (Build a Features List)

A partir del modelo global, el equipo identifica y documenta todas las funcionalidades necesarias. Las funcionalidades se agrupan en áreas de negocio (subject areas) y conjuntos de funcionalidades (feature sets), creando una jerarquía de tres niveles:

Área de negocio: Gestión de Pedidos ├── Feature Set: Procesamiento de pagos │ ├── Feature: Calcular el subtotal de un pedido │ ├── Feature: Aplicar descuentos promocionales al pedido │ ├── Feature: Validar los datos de la tarjeta de crédito │ └── Feature: Procesar el cobro con la pasarela de pago ├── Feature Set: Gestión de envíos │ ├── Feature: Calcular el coste de envío según destino │ ├── Feature: Generar la etiqueta de envío │ └── Feature: Notificar al cliente el estado del envío └── Feature Set: Devoluciones ├── Feature: Registrar la solicitud de devolución ├── Feature: Calcular el reembolso del cliente └── Feature: Actualizar el inventario tras la devolución

Regla fundamental: cada funcionalidad debe poder completarse en un máximo de 2 semanas. Si es más grande, se descompone en funcionalidades más pequeñas.

3. Planificar por funcionalidad (Plan by Feature)

El equipo de gestión del proyecto establece el orden de desarrollo de las funcionalidades, asignando cada feature set a un Chief Programmer y estableciendo fechas de entrega. La planificación considera:

• Dependencias entre funcionalidades.
• Complejidad técnica.
• Prioridad de negocio.
• Disponibilidad de los desarrolladores.

4. Diseñar por funcionalidad (Design by Feature)

Para cada funcionalidad (o grupo pequeño de funcionalidades relacionadas), el Chief Programmer forma un Feature Team temporal y lidera el diseño detallado:

• Creación de diagramas de secuencia.
• Definición de las clases y métodos necesarios.
• Diseño de la interfaz pública de cada componente.
• Revisión del diseño con el equipo.

Resultado: un paquete de diseño (Design Package) que incluye diagramas actualizados, especificaciones de clases y notas del diseño.

5. Construir por funcionalidad (Build by Feature)

Los developers implementan la funcionalidad según el diseño:

# Ejemplo: Feature "Calcular el coste de envío según destino" class CalculadorEnvio: TARIFAS_POR_ZONA = { "nacional": {"base": 4.99, "por_kg": 0.50}, "europa": {"base": 12.99, "por_kg": 1.20}, "internacional": {"base": 24.99, "por_kg": 2.50}, } def calcular_coste(self, peso_kg: float, zona: str) -> float: """Calcula el coste de envío basado en peso y zona.""" tarifa = self.TARIFAS_POR_ZONA[zona] return tarifa["base"] + (tarifa["por_kg"] * peso_kg) def aplicar_envio_gratuito(self, total_pedido: float, coste: float) -> float: """Envío gratuito para pedidos superiores a 50 EUR.""" if total_pedido >= 50.0: return 0.0 return coste

El proceso incluye:

• Codificación de la funcionalidad.
• Pruebas unitarias y de integración.
• Inspección de código (code review).
• Integración en el build principal.

Cada funcionalidad completada se marca como "Done" y se registra el progreso.

FDD define roles específicos que aseguran la coordinación en equipos grandes:

El concepto de Class Ownership

Una característica distintiva de FDD es la propiedad individual de clases: cada clase del sistema tiene un propietario (Class Owner) responsable de su diseño, implementación y calidad. Cuando una funcionalidad requiere modificar múltiples clases, el Chief Programmer forma un Feature Team temporal con los Class Owners relevantes.

Este modelo contrasta con el code ownership colectivo de XP y Scrum, donde cualquier developer puede modificar cualquier código. FDD argumenta que la propiedad individual genera mayor responsabilidad y conocimiento profundo, especialmente en equipos grandes.

Imaginemos que una empresa de seguros implementa FDD para desarrollar su nuevo sistema de gestión de pólizas con un equipo de 30 developers:

Fase 1 - Modelo Global (Semana 1-2):

Los expertos del dominio (actuarios, agentes de seguros, directores de siniestros) realizan domain walkthroughs con los desarrolladores. Resultado: un modelo de dominio con las entidades principales (Póliza, Cliente, Siniestro, Cobertura, Prima).

Fase 2 - Lista de Funcionalidades (Semana 2-3):

Se identifican 450 funcionalidades agrupadas en 35 feature sets y 8 áreas de negocio:

• Gestión de clientes: 45 features
• Emisión de pólizas: 78 features
• Cálculo de primas: 52 features
• Gestión de siniestros: 95 features
• Reaseguro: 38 features
• Reportes regulatorios: 62 features
• Facturación: 48 features
• Administración: 32 features

Fase 3 - Planificación (Semana 3):

Se priorizan los feature sets y se asignan a 5 Chief Programmers, cada uno liderando un sub-equipo de 5-6 developers.

Fase 4-5 - Diseño y construcción (Semanas 4-52):

Cada funcionalidad pasa por el ciclo de diseño y construcción en 2-10 días. El tracking de progreso utiliza un parking lot chart:

┌─────────────────────────────────────────────┐ │ PROGRESO DEL PROYECTO - Mes 3 │ ├──────────────────┬──────────────────────────┤ │ Gestión clientes │ ████████████░░░░ 73% │ │ Emisión pólizas │ ██████████░░░░░░ 62% │ │ Cálculo primas │ ████████░░░░░░░░ 48% │ │ Siniestros │ █████░░░░░░░░░░░ 31% │ │ Reaseguro │ ███░░░░░░░░░░░░░ 18% │ │ Reportes │ ██░░░░░░░░░░░░░░ 12% │ │ Facturación │ ████░░░░░░░░░░░░ 25% │ │ Administración │ ██████████████░░ 88% │ ├──────────────────┼──────────────────────────┤ │ TOTAL PROYECTO │ ██████████░░░░░░ 42% │ └──────────────────┴──────────────────────────┘

Este nivel de visibilidad es una de las grandes fortalezas de FDD en proyectos grandes: en cualquier momento, los stakeholders pueden ver exactamente qué porcentaje del sistema está completado.

Ventajas

• Escalabilidad: diseñado para equipos grandes con múltiples sub-equipos.
• Visibilidad del progreso: el tracking por funcionalidad permite reportes de progreso granulares.
• Entrega frecuente de valor: funcionalidades completadas cada 2-10 días.
• Modelo de dominio sólido: la fase de modelado reduce malentendidos entre negocio y desarrollo.
• Responsabilidad clara: la propiedad de clases genera accountability individual.

Desventajas

• Dependencia del Chief Programmer: si el Chief Programmer no es competente, el Feature Team sufre.
• Menos colaborativo que XP: la propiedad individual de código puede crear silos de conocimiento.
• Documentación: requiere más documentación que Scrum o XP.
• Menos flexible: los cinco procesos son más prescriptivos para cambios de último momento.

1. Invertir en el modelo global: un buen modelo de dominio ahorra semanas de retrabajo.
2. Mantener features pequeñas: si una feature no cabe en 2 semanas, dividirla.
3. Inspecciones de código regulares: son obligatorias en FDD, no opcionales.
4. Tracking visible: usar herramientas como Jira con parking lot charts para que todos vean el progreso.
5. Combinar con prácticas modernas: FDD se complementa bien con CI/CD, TDD y BDD.

¿FDD sigue siendo relevante hoy en día?

Sí, especialmente para organizaciones grandes con proyectos complejos. Aunque Scrum domina el mercado ágil, FDD ofrece ventajas en contextos donde la escala del equipo y la complejidad del dominio requieren más estructura que la que Scrum proporciona. Muchos equipos adoptan elementos de FDD (como el modelado de dominio y la descomposición en features) incluso si no siguen el framework completo.

¿Cuál es la diferencia entre FDD y Scrum?

La diferencia principal es la unidad de trabajo y la escala. Scrum organiza el trabajo en Sprints de duración fija con equipos pequeños auto-organizados. FDD organiza el trabajo alrededor de funcionalidades individuales con roles jerárquicos definidos. Scrum es más flexible y colaborativo; FDD ofrece más estructura y trazabilidad para equipos grandes.

¿Se puede combinar FDD con Scrum?

Sí. Muchos equipos usan un enfoque híbrido: adoptan los Sprints y ceremonias de Scrum pero utilizan la descomposición en features y el modelo de dominio de FDD. SAFe (Scaled Agile Framework) incorpora elementos de FDD en su enfoque de escalado.

¿Qué tamaño de equipo necesita FDD?

FDD fue diseñado para equipos de 10 a 250 desarrolladores. Para equipos menores de 10, Scrum o XP suelen ser más adecuados por su menor overhead. Para equipos de más de 50, FDD ofrece ventajas claras en coordinación y visibilidad del progreso.

¿FDD requiere UML?

No obligatoriamente, pero el modelado visual es una parte integral del proceso. Si el equipo prefiere otras notaciones o herramientas de modelado, pueden sustituir UML, siempre que el modelo global cumpla su función de crear un entendimiento compartido del dominio.

¿Cómo mido el progreso en FDD?

FDD utiliza el porcentaje de funcionalidades completadas como métrica principal. Cada funcionalidad pasa por seis hitos de completado (domain walkthrough, diseño, inspección de diseño, código, inspección de código, build exitoso), cada uno con un peso porcentual. Esto permite medir el progreso de forma objetiva y granular.