FDD: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Meta-bok|min=4}} | |||
= | |||
<div class="bok-def"> | |||
'''FDD''' (''Feature-Driven Development'', desarrollo dirigido por funcionalidades) es un proceso ágil de desarrollo de software iterativo e incremental, organizado en torno a la entrega de funcionalidades concretas y priorizadas. Fue diseñado para equipos grandes y proyectos complejos donde los métodos más ligeros tienen dificultades para escalar. | |||
</div> | |||
La | == Origen == | ||
== | |||
Jeff De Luca diseñó FDD para un proyecto de software del banco de Singapur en 1997, que iba a realizar un equipo de 50 personas durante 15 meses. La primera descripción formal fue publicada en el capítulo 6 del libro ''Java Modeling in Color with UML'' (Coad, Lefebvre y De Luca, 1999). | |||
== Los cinco procesos de FDD == | |||
FDD define cinco procesos principales: | |||
=== 1. Desarrollar un modelo general === | |||
El equipo construye una visión general del sistema mediante sesiones de modelado en grupo. El resultado es un modelo de dominio —habitualmente con UML— que todo el equipo comparte. | |||
=== 2. Construir una lista de funcionalidades === | |||
A partir del modelo general, el equipo identifica todas las funcionalidades del sistema. Cada funcionalidad se expresa con la fórmula: ''[acción] [resultado] [objeto]''. Por ejemplo: "Calcular el total de una factura". Las funcionalidades se agrupan en conjuntos de funcionalidades relacionadas. | |||
=== 3. Planificar por funcionalidades === | |||
Los jefes de desarrollo y el equipo ordenan los conjuntos de funcionalidades por prioridad y dependencia, y asignan cada conjunto a un desarrollador jefe responsable de su entrega. | |||
=== 4. Diseñar por funcionalidades === | |||
El desarrollador jefe selecciona un subconjunto de funcionalidades para completar en las próximas dos semanas. Junto con los propietarios de las clases afectadas, diseña en detalle cómo implementarlas. | |||
=== 5. Construir por funcionalidades === | |||
Los programadores implementan el diseño, realizan pruebas unitarias y revisan el código entre pares. Al finalizar, la funcionalidad se integra en la build principal. | |||
== FDD en perspectiva == | |||
FDD fue influyente en la primera década de 2000 porque respondía a una necesidad real: cómo aplicar principios ágiles en proyectos con docenas o cientos de desarrolladores, cuando Scrum todavía no había desarrollado marcos de escalado. Su énfasis en el modelado de dominio compartido y la propiedad por clases fue innovador para su época. | |||
Hoy su adopción directa es limitada: ha sido desplazado por marcos de escalado más documentados como SAFe o Nexus. Su valor actual es principalmente histórico y conceptual. | |||
== Error frecuente == | |||
<div class="bok-aviso"> | |||
'''Creer que FDD y Scrum son incompatibles.''' FDD y Scrum pueden combinarse: FDD aporta la estructura de modelado y propiedad de funcionalidades; Scrum aporta la cadencia iterativa y los eventos de inspección y adaptación. En la práctica, algunos equipos usan el sprint de Scrum como cadencia para el proceso 5 de FDD (construir por funcionalidades) mientras mantienen el modelado y la planificación de FDD en los procesos anteriores. | |||
</div> | |||
== Referencias == | |||
* Coad, Peter; Lefebvre, Eric; De Luca, Jeff. (1999). ''Java Modeling in Color with UML: Enterprise Components and Process''. Prentice Hall. | |||
== Véase también == | |||
<div class="bok-tags"> | |||
[[Extreme programming]] [[Crystal]] [[DSDM]] [[Agile Unified Process]] [[El manifiesto ágil]] [[Mapa de metodologías]] | |||
</div> | |||
<div class="bok-ecosistema"> | |||
<div class="texto"> | |||
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span> | |||
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span> | |||
</div> | |||
<div class="botones"> | |||
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div> | |||
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div> | |||
</div> | |||
</div> | |||
[[Category:Glosario de términos]] | [[Category:Glosario de términos]] | ||
[[Category: | [[Category:Marcos y modelos]] | ||
[[Category:Metodologías ágiles]] | [[Category:Metodologías ágiles]] | ||
Revision as of 15:44, 14 May 2026
FDD (Feature-Driven Development, desarrollo dirigido por funcionalidades) es un proceso ágil de desarrollo de software iterativo e incremental, organizado en torno a la entrega de funcionalidades concretas y priorizadas. Fue diseñado para equipos grandes y proyectos complejos donde los métodos más ligeros tienen dificultades para escalar.
Origen
Jeff De Luca diseñó FDD para un proyecto de software del banco de Singapur en 1997, que iba a realizar un equipo de 50 personas durante 15 meses. La primera descripción formal fue publicada en el capítulo 6 del libro Java Modeling in Color with UML (Coad, Lefebvre y De Luca, 1999).
Los cinco procesos de FDD
FDD define cinco procesos principales:
1. Desarrollar un modelo general
El equipo construye una visión general del sistema mediante sesiones de modelado en grupo. El resultado es un modelo de dominio —habitualmente con UML— que todo el equipo comparte.
2. Construir una lista de funcionalidades
A partir del modelo general, el equipo identifica todas las funcionalidades del sistema. Cada funcionalidad se expresa con la fórmula: [acción] [resultado] [objeto]. Por ejemplo: "Calcular el total de una factura". Las funcionalidades se agrupan en conjuntos de funcionalidades relacionadas.
3. Planificar por funcionalidades
Los jefes de desarrollo y el equipo ordenan los conjuntos de funcionalidades por prioridad y dependencia, y asignan cada conjunto a un desarrollador jefe responsable de su entrega.
4. Diseñar por funcionalidades
El desarrollador jefe selecciona un subconjunto de funcionalidades para completar en las próximas dos semanas. Junto con los propietarios de las clases afectadas, diseña en detalle cómo implementarlas.
5. Construir por funcionalidades
Los programadores implementan el diseño, realizan pruebas unitarias y revisan el código entre pares. Al finalizar, la funcionalidad se integra en la build principal.
FDD en perspectiva
FDD fue influyente en la primera década de 2000 porque respondía a una necesidad real: cómo aplicar principios ágiles en proyectos con docenas o cientos de desarrolladores, cuando Scrum todavía no había desarrollado marcos de escalado. Su énfasis en el modelado de dominio compartido y la propiedad por clases fue innovador para su época.
Hoy su adopción directa es limitada: ha sido desplazado por marcos de escalado más documentados como SAFe o Nexus. Su valor actual es principalmente histórico y conceptual.
Error frecuente
Creer que FDD y Scrum son incompatibles. FDD y Scrum pueden combinarse: FDD aporta la estructura de modelado y propiedad de funcionalidades; Scrum aporta la cadencia iterativa y los eventos de inspección y adaptación. En la práctica, algunos equipos usan el sprint de Scrum como cadencia para el proceso 5 de FDD (construir por funcionalidades) mientras mantienen el modelado y la planificación de FDD en los procesos anteriores.
Referencias
- Coad, Peter; Lefebvre, Eric; De Luca, Jeff. (1999). Java Modeling in Color with UML: Enterprise Components and Process. Prentice Hall.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.