FDD: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Meta-bok|min=4}} | {{Meta-bok|min=4}} | ||
'''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. | '''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 == | == 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). | 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 == | == Los cinco procesos de FDD == | ||
FDD define cinco procesos principales: | FDD define cinco procesos principales: | ||
=== 1. Desarrollar un modelo general === | === 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. | 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 === | === 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. | 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 === | === 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. | 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 === | === 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. | 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 === | === 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. | 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 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. | 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. | 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 == | == Error frecuente == | ||
<div class="bok-aviso"> | <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. | '''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> | </div> | ||
== Referencias == | == Referencias == | ||
* Coad, Peter; Lefebvre, Eric; De Luca, Jeff. (1999). ''Java Modeling in Color with UML: Enterprise Components and Process''. Prentice Hall. | * Coad, Peter; Lefebvre, Eric; De Luca, Jeff. (1999). ''Java Modeling in Color with UML: Enterprise Components and Process''. Prentice Hall. | ||
== Véase también == | == Véase también == | ||
<div class="bok-tags"> | <div class="bok-tags"> | ||
[[Extreme programming]] [[Crystal]] [[DSDM]] [[Agile Unified Process]] [[El manifiesto ágil]] [[Mapa de metodologías]] | [[Extreme programming]] [[Crystal]] [[DSDM]] [[Agile Unified Process]] [[El manifiesto ágil]] [[Mapa de metodologías]] [[SAFe]] [[Nexus]] | ||
</div> | </div> | ||
<div class="bok-ecosistema"> | <div class="bok-ecosistema"> | ||
<div class="texto"> | <div class="texto"> | ||