FDD — Feature Driven Development
Движущая сила: функция (feature) — клиенто-ориентированная единица ценности, на которую разбивается вся работа.
Уровень применения: команда и организация (процесс и планирование).
Статус: устоявшийся, но нишевый (Jeff De Luca / Peter Coad, 1997; книга Palmer/Felsing, 2002).
Не путать с: Fear Driven Development (антипаттерн, совпадение аббревиатуры FDD) — рассматривается в отдельной статье серии.
Общее
Feature Driven Development (FDD) — модельно-ориентированная методология разработки, в которой первичной движущей силой выступает функция (feature) — небольшая, клиенто-ориентированная единица ценности, на которую декомпозируется вся работа. Модель предметной области строится до начала разработки, на общей рабочей сессии команды и экспертов; затем модель разбивается на список функций, каждая из которых реализуется за короткий цикл (до двух недель) небольшой командой во главе с ведущим программистом. Ключевой тезис De Luca: крупный проект выигрывается не хаотичной гибкостью, а чёткой структурой, ведомой от модели к функции и от функции к коду; сама функция здесь — одновременно и единица планирования, и единица отчётности, и единица инспекции.
Подход был сформулирован Джеффом Де Лукой (Jeff De Luca) в 1997 году для проекта кредитной системы крупного банка в Сингапуре (команда около 50 человек, длительность около 15 месяцев). Де Лука должен был «приземлить» команду такого размера на работающий процесс и опирался при этом на две идеи: «хирургическую команду» Фредерика Брукса (один ведущий и поддерживающие его роли) и цветовое моделирование Питера Коуда (Peter Coad) — способ визуализации объектной модели предметной области. Коуд принёс само понятие «фичи» как единицы декомпозиции и формат её записи. Первая публикация подхода — глава, написанная Де Лука и Коудом совместно с Эриком Лефевром в книге Java Modeling in Color with UML (Coad, Lefebvre, De Luca, 1999). Операционно метод был систематизирован Стивеном Палмером и Маком Фельсингом в книге A Practical Guide to Feature-Driven Development (Palmer & Felsing, 2002), которая остаётся каноническим справочником.
Принципиальное отличие FDD от остальных «*DD» в этой серии — её движущая сила. Если в TDD дизайн направляют тесты, в BDD — диалог о поведении в сценариях Given-When-Then, а в DDD — модель предметной области, то в FDD всё это подчинено процессу доставки функции: модель нужна, чтобы знать, какие функции строить; тесты нужны, чтобы функция работала; поведение функции определено её клиенто-ориентированной формулировкой. FDD — это прежде всего организационная методология: она отвечает на вопрос «как команде из 20–50 человек предсказуемо поставлять ценность», а не «как отдельному разработчиему писать код». Отсюда вытекает иное: цикл работы выглядит не как минутный Red-Green-Refactor (это уровень TDD), а как пятиэтапный процесс, первые три этапа которого — разовые для проекта, и лишь два последних повторяются на каждой фиче.
FDD исторически входит в число исходных «agile-методов»: наряду со Scrum и XP она упоминается как классика гибких методологий. Но её характер радикально иной: Scrum задаёт каркас управления (роли, события, артефакты) и не предписывает инженерных практик; XP задаёт инженерные практики (парное программирование, TDD, непрерывная интеграция) и слабо регламентирует планирование крупными командами. FDD делает обратное: она жёстко описывает и процесс работы с моделью и фичами, и инженерную механику (sequence-диаграммы, инспекции, владение классами). Это делает её более тяжёлой, зато лучше приспособленной к крупным командам и к проектам, где нужна управленческая отчётность.
Ключевые принципы
FDD — это не «писать фичи» (это любая разработка), а набор принципов, которые в совокупности меняют то, как крупная команда проходит от модели к коду. Ниже — формулировка каждого с пояснением, какую конкретную проблему он решает.
Модель прежде кода (model-centric). До начала разработки команда проводит общую сессию моделирования и строит объектную модель предметной области. Проблема: команда из 30–50 человек, начавшая кодить «каждый в свою сторону», неминуемо получает десяток нестыкующихся моделей; согласование их post-factum стоит дороже самой разработки. Общая модель, построенная до кода, задаёт общий словарь и границы — тот же смысл, что и стратегический DDD, но в FDD модель не «живёт и эволюционирует», а фиксируется как стартовая точка для декомпозиции.
Фича как единица работы. Вся работа декомпозируется на функции — небольшие клиенто-ориентированные элементы, каждая из которых реализуется за срок до двух недель (на практике — за несколько дней). Фича записывается в жёстком формате: <action> the <result> <by|for|with> <object> — например, «calculate the total of a sale by the line items». Проблема: технические задачи («рефакторинг модуля оплаты», «настройка CI») и пользовательские истории («как покупатель, я хочу…») живут в разных мирах и по-разному оцениваются; формулировка фичи в виде действия над объектом модели связывает бизнес-результат и кодовую единицу в одной строке, измеримой по времени.
Пятиэтапный процесс. Работа организована как пять процессов (processes): первые три выполняются один раз для всего проекта, два последних повторяются на каждой фиче. Проблема: в большой команде без общей шашечки «кто что делает и на каком этапе» каждый подпроект изобретает свой процесс, и предсказуемость исчезает. Пять процессов — это общий каркас, в который вкладывается любая работа; подробнее — в разделе «Как это работает».
Chief Programmer-команды (по Бруксу). Команда организована как набор небольших групп во главе с ведущим программистом (Chief Programmer), который отвечает за результат своей группы. Это прямое воплощение «хирургической команды» из The Mythical Man-Month (Brooks, 1975): один ведущий «режиссёр» и поддерживающие его исполнители. Проблема: «плоская» команда из 40 разработчиков не имеет работоспособной структуры принятия решений; делегирование «по горизонтали» ведёт к размытой ответственности. Вертикальное деление на Chief Programmer-команды фиксирует ответственность и создаёт естественные точки эскалации.
Владение классами (class ownership), а не коллективный код. Каждый класс в модели имеет владельца (class owner) — разработчика, отвечающего за него; этот же разработчик вносит в класс основные изменения. Проблема: коллективное владение кодом (как в XP) хорошо работает в небольшой команде, но в команде из десятков человек приводит к конфликтам слияний и к тому, что «никто не отвечает ни за что». Явное владение классом даёт экспертную ответственность и стабильность кода. Платой становится меньшая гибкость: изменение, затрагивающее несколько классов, требует координации их владельцев (эту координацию и ведёт Chief Programmer).
Инспекции вместо парного программирования. Качество обеспечивается формальными дизайн- и код-инспекциями (design inspection, code inspection), а не парным программированием. Проблема: парное программирование требует удвоения ресурсов и в большой команде работает как контроль лишь на моменте написания; инспекция позволяет одному ведущему ревьюить работу нескольких, фиксирует дефекты как явные артефакты и масштабируется на команду любого размера. Инспекции в FDD привязаны к milestone-ам фичи (см. ниже).
Регулярные сборки и конфигурационное управление. Каждая завершённая фича интегрируется в общую сборку; сборка запускается регулярно (как минимум — раз в несколько дней). Проблема: команды, копящие код «в ветках до релиза», получают интеграционный ад; регулярная сборка делает интеграцию непрерывной, а ошибки интеграции — локализованными. Это тот же принцип, что и continuous integration в XP, но в FDD он подчинён ритму фич.
Отчётность по фичам (progress reporting). Прогресс проекта измеряется долей завершённых фич и их milestone-ов, а не абстрактными «story points» или «часами». Проблема: часы и story points слабо связаны с реальной ценностью и плохо сообщаются нетехническим стейкхолдерам; «из 480 фич выполнено 210 (44 %)» — это понятная и проверяемая метрика, не зависящая от трактовок.
Принципы — система, а не меню. Модель без формата фичи превращается в «нарисовали и забыли»; формат фичи без Chief Programmer-команд оставляет вопрос «кто это делает»; Chief Programmer без владения классами теряет рычаг контроля; инспекции без регулярных сборок дают «чистый код, который не интегрируется». Частичное внедрение создаёт «FDD-theatre» — формальные списки фич и парковки (parking lots) без реальной дисциплины модели и инспекций; полное — даёт предсказуемость и масштабируемость, ради которых FDD и создавалась.
Как это работает
FDD оперирует пятью процессами и трёхуровневой структурой декомпозиции домена. Ниже — механика.
Структура декомпозиции: бизнес-активность → набор фич → фича
Модель предметной области разбивается на иерархию из трёх уровней:
| Уровень | Что это | Пример |
|---|---|---|
| Business Activity (мажорный набор фич) | Крупная область бизнеса, часть общей модели | «Оформление продажи» |
| Feature Set (набор фич) | Подобласть внутри бизнес-активности, объединяющая родственные фичи | «Расчёт итога заказа» |
| Feature (фича) | Единичная клиенто-ориентированная функция, ≤2 недели работы | «calculate the total of a sale by the line items» |
Каждая фича форматируется строго: <action> the <result> <by|for|with> <object> — глагол действия, результат и объект модели, над которым совершается действие. Формат не косметический: он гарантирует, что фича привязана к объекту модели (значит — кодируется в конкретном классе), выражает клиентскую ценность (значит — её можно приоритизировать) и измерима по времени (значит — её можно запланировать).
Пять процессов FDD
| # | Процесс | Тип | Что делает |
|---|---|---|---|
| 1 | Develop an Overall Model | Разовый | Команда и эксперты совместно строят объектную модель предметной области; выход — общая модель и общий словарь |
| 2 | Build a Features List | Разовый | Модель декомпозируется на бизнес-активности, наборы фич и отдельные фичи по формату выше |
| 3 | Plan by Feature | Разовый | Фичи упорядочиваются, назначаются на Chief Programmer-команды; формируется последовательность и приоритет |
| 4 | Design by Feature (DBF) | Повторяемый | Chief Programmer-команда выбирает пакет фич, проводит domain walkthrough, проектирует sequence-диаграммы и уточняет модель |
| 5 | Build by Feature (BBF) | Повторяемый | Владельцы классов реализуют код, пишут юнит-тесты, проходят дизайн- и код-инспекции, интегрируют фичу в сборку |
Первые три процесса — инвестиция в старт проекта: без общей модели и списка фич остальные два не имеют смысла. Процессы 4 и 5 — это рабочий цикл: Chief Programmer-команда берёт пакет фич (обычно одну бизнес-активность или набор), проходит DBF → BBF, отчитывается о завершении, берёт следующий пакет. Цикл не минутный (как Red-Green-Refactor в TDD), а длится дни-недели на пакет фич.
Six milestone-ов фичи
Внутри процессов DBF и BBF каждая фича проходит шесть контрольных точек (milestones), которые и служат основой отчётности:
- Domain Walkthrough — короткий разбор предметной области с экспертом.
- Design — проектирование (sequence-диаграммы, уточнение модели).
- Design Inspection — формальная инспекция дизайна.
- Code — реализация и юнит-тесты.
- Code Inspection — формальная инспекция кода.
- Promote to Build — интеграция в общую сборку.
Каждый milestone имеет целевую долю в общей оценке фичи (например, Domain Walkthrough — 1 %, Design — 4 %, Design Inspection — 4 %, Code — 45 %, Code Inspection — 25 %, Promote to Build — 1 %; распределение настраивается под проект). Сумма завершённых milestone-ов даёт процент выполнения фичи; сумма по всем фичам — процент выполнения проекта.
Parking lots — визуализация прогресса
Прогресс по наборам фич визуализируется «парковками» (parking lots): таблица, где каждая бизнес-активность или набор фич показаны прямоугольником с числом фич, долей выполнения и цветовой индикацией (зелёный — в графике, жёлтый — отставание, красный — блокер). Parking lots читаются нетехническими стейкхолдерами за секунды и дают управленческую картину без погружения в код.
Влияние на команду и процесс
FDD часто обсуждают как «ещё один agile-метод». Это сужение: устойчивый эффект возникает только тогда, когда пятиэтапный процесс встроен в ролевую структуру команды и в управленческую отчётность. Ниже — что именно меняется. Этот блок адресован прежде всего руководителям.
Ролевая структура вместо «плоской команды». FDD описывает явный набор ролей, в отличие от минималистичной тройки Scrum (Scrum Master / Product Owner / Dev Team). Базовые роли FDD:
| Роль | Зона ответственности | Аналог в других методах |
|---|---|---|
| Project Manager | Расписание, ресурсы, отчётность, управление рисками | Project Manager / Scrum Master (частично) |
| Chief Architect | Общая модель и её целостность, архитектурные решения | Технический руководитель / Solution Architect |
| Development Manager | Координация повседневной разработки, разрешение конфликтов | Роль отсутствует в Scrum; близок к Engineering Manager |
| Chief Programmer | Ведущий небольшой команды (6–8 человек), отвечает за пакет фич | Squad Lead / Tech Lead |
| Class Owner | Владелец класса модели, реализует изменения в нём | Developer (но с явной ответственностью за класс) |
| Domain Expert | Предметная экспертиза, walkthrough-ы, уточнения модели | Product Owner / SME |
Проблема, которую решает эта структура: в команде из 40 человек «плоская» модель ответственности не работает — решения тонут, эскалация непрозрачна. FDD задаёт явные точки принятия решений и эскалации.
Chief Programmer как ключевая роль. Сердце FDD — ведущий программист, ведущий пакет фич. Это не «менеджер, который не кодит»: Chief Programmer сам проектирует (DBF), ведёт инспекции и часто пишет ключевые части. Эта роль — операционный мост между моделью и кодом, между планированием и исполнением. Слабые Chief Programmer-ы — самая частая причина провала FDD-внедрения: процесс есть, а качества нет.
Отчётность, понятная бизнесу. Прогресс, выраженный в процентах завершённых фич и в цветах parking lots, понятен нетехническому руководителю и заказчику без перевода. Это принципиальное преимущество FDD перед методами, где прогресс измеряется «часами» или «story points» — метриками, требующими трактовки. В проектах с жёсткой управленческой отчётностью (банкинг, госбизнес) это часто решающий фактор выбора.
Масштабируемость на крупные команды. FDD создавалась под команду в 50 человек и хорошо переносит рост: добавление новых Chief Programmer-команд не ломает процесс, потому что они вкладываются в уже заданный каркас из пяти процессов и трёхуровневой декомпозиции. В этом FDD принципиально отличается от XP и Scrum, которые в чистом виде плохо масштабируются за пределы команды-двойной-пиццы и требуют надстроек (LeSS, SAFe, Nexus).
Контраст с XP: модель и структура против лёгкости. FDD и XP — два полюса раннего agile. XP лёгкая, документационно-минимальная, опирается на парное программирование и коллективное владение кодом; FDD тяжёлая, опирается на модель, явное владение классами и инспекции. Выбор между ними диктуется размером команды и контекстом: маленькой инженерно-зрелой команде подойдёт XP; большой команде в формальном окружении — FDD.
Связь с iterative и incremental разработкой. FDD естественно ложится на итеративную и инкрементную модели: первые три процесса дают разовый старт, процессы 4–5 повторяются как итерации над пакетами фич, а каждая завершённая фича — это инкремент ценности. Подробнее о месте итеративности — в материалах о жизненном цикле разработки.
Преимущества
Предсказуемость через список фич. Полный список фич, построенный в процессе 2, превращает проект в набор измеримых единиц. Прогресс отслеживается как процент завершённых фич и их milestone-ов — это честная, мало подверженная трактовкам метрика, в отличие от «часов» или «story points».
Масштабируемость на крупные команды. Каркас из пяти процессов и Chief Programmer-команд выдерживает рост команды до десятков и сотен человек без потери управляемости. Это редкое свойство среди agile-методов в их исходном виде.
Чёткое владение классами и ответственность. Каждый класс модели имеет владельца; каждый пакет фич имеет ведущего (Chief Programmer). Это устраняет «ничьё» зоны кода и создаёт явные точки экспертизы и эскалации.
Читаемая доменная модель. Процесс 1 (Develop an Overall Model) и формат фичи, привязанный к объекту модели, дают команде общий словарь — тот же эффект, что и стратегический DDD, но в FDD модель используется операционно (для декомпозиции), а не только концептуально.
Управленческая отчётность. Parking lots и процент завершённых фич дают картину, которую читают нетехнические стейкхолдеры. В проектах с регуляторной или корпоративной отчётностью это часто решающий плюс.
Контроль качества через инспекции. Формальные дизайн- и код-инспекции, привязанные к milestone-ам фичи, систематически вылавливают дефекты раньше, чем они попадут в сборку. Инспекции масштабируются лучше парного программирования, особенно в больших командах.
Недостатки и риски
Зависимость от сильного Chief Architect и Chief Programmer-ов. Слабый Chief Architect даёт плохую модель — и весь процесс строится на шатком фундаменте; слабые Chief Programmer-ы не ведут свои пакеты фич. Это узкое место (bus-factor): уход одного-двух ключевых людей может остановить проект. Симптом: формально все пять процессов идут, а качество и темп проседают.
Меньше гибкости к смене модели «на лету». Модель строится разово в процессе 1, и значительная перестройка предметной области посреди проекта болезненна: список фич, владение классами, parking lots — всё завязано на исходную модель. Для проектов с высокой неопределённостью требований это слабое место.
Тяжесть для малых команд. Ролевая структура, инспекции, парковки и формальная декомпозиция — накладные расходы, оправданные при команде от 10–15 человек. Для команды из 3–5 разработчиков FDD избыточна: те же цели достигаются XP или Scrum дешевле.
Нишевая литература и сообщество. FDD не получила массового распространения; каноническая литература ограничена книгой Palmer/Felsing (2002) и материалами De Luca (nebulon.com/fdd). Найти живое сообщество, зрелые инструменты и экспертов для найма сложнее, чем для Scrum или Kanban. Это повышает порог входа и риски долгосрочной поддержки процесса.
Инспекции как узкое место. Формальные инспекции требуют времени ведущих (Chief Programmer, Chief Architect). При плохом планировании инспекции становятся очередью, тормозящей все фичи; symptом — фичи надолго «зависают» между milestone-ами Code и Code Inspection.
Риск «FDD-theatre». Как и с любым методом, формальное внедрение без сути даёт фасад: списки фич и parking lots есть, но модель не строится по-настоящему, инспекции превращаются в «проставление галочек», а Chief Programmer-ы — в номинальных ведущих без реальной ответственности. Результат — бюрократия без предсказуемости.
Когда использовать
- Крупные команды и проекты. Команды от 10–15 до сотен человек, где «плоская» структура захлёбывается, — главный случай применимости FDD.
- Стабильная, понятная предметная область. Домен, который можно смоделировать на старте без радикальных перестроек (банкинг, страхование, биллинг, корпоративные системы) — естественная среда для FDD.
- Нужна управленческая отчётность и предсказуемость. Проекты с внешними стейкхолдерами, регуляторными требованиями, фиксированными сроками и бюджетом — где процент завершённых фич и parking lots решают управленческую задачу.
- Домен, допускающий объектное моделирование. FDD опирается на объектную модель; для систем с доминирующей UI-вёрсткой, data-pipeline или инфраструктурным характером её механика ложится плохо.
- Есть сильный архитектор и сильные ведущие. Это предусловие, а не пожелание: без них FDD вырождается в «FDD-theatre».
- Долгоживущий проект. Инвестиция в модель и ролевую структуру окупается на горизонте месяцев и лет; для коротких engagement-ов накладные расходы не оправданы.
Когда НЕ использовать
- Стартапы и исследовательская разработка. Когда предметная область плохо понята и быстро меняется, разовая модель в процессе 1 быстро устаревает; гибкость важнее структуры. Здесь работают Agile в лёгкой форме, Lean Startup или итеративная разработка с короткими петлями.
- Малые команды. Команды из 3–5 человек получают от FDD больше накладных расходов, чем выгоды; им ближе XP или Scrum.
- Продукты с быстро меняющимися требованиями. Если приоритеты и состав функций переворачиваются раз в месяц, списки фич и parking lots не успевают за реальностью и превращаются в шум.
- Чисто инфраструктурные и data-centric задачи. Домены, где объектное моделирование неестественно (CI/CD, ETL, ML-pipeline), плохо ложатся на FDD; там работают другие подходы (например, итеративная или инкрементная модель без объектной декомпозиции).
- Команда без сильных ведущих. Нет людей уровня Chief Architect / Chief Programmer — нет и FDD; процесс превратится в формальность.
Связанные подходы
FDD — не единственный «*DD» в разработке; за разными аббревиатурами стоят разные «движущие силы». Статья входит в серию материалов о driven-подходах; ниже — краткая карта, со ссылками на уже опубликованные материалы базы знаний.
| Подход | Движущая сила | Что управляет дизайном | Уровень применения |
|---|---|---|---|
| TDD | Тесты | Тесты как исполняемая спецификация (Red-Green-Refactor) | Код и команда |
| DDD | Домен | Модель предметной области и единый язык | Команда и организация |
| BDD | Поведение | Сценарии Given-When-Then на уровне требований | Команда и заказчик |
| FDD (этот материал) | Функция (фича) | Процесс доставки фичи: модель → список фич → реализация | Команда и организация |
| ATDD | Критерии приёмки | Тесты приёмки как спецификация | Команда и заказчик |
| HDD | Бизнес-гипотеза | Эксперимент с метрикой (Build-Measure-Learn) | Продукт и организация |
- TDD — Test Driven Development — родственный подход, где движущей силой выступают тесты как исполняемая спецификация. FDD и TDD не конкурируют, а дополняют друг друга: FDD задаёт процесс и планирование на уровне организации, TDD страхует реализацию отдельной фичи на уровне кода.
- BDD — Behaviour Driven Development — родственный подход, где движущей силой выступает поведение в сценариях Given-When-Then. Концептуально BDD ближе к требованиям и коммуникации, FDD — к процессу и масштабированию; обе методологии работают с «фичами», но понимают их по-разному (сценарий поведения vs единица доставки).
- DDD — Domain Driven Design — родственный подход, где движущей силой выступает домен. FDD разделяет с DDD опору на модель предметной области, но использует её операционно (для декомпозиции на фичи), тогда как DDD — как непрерывно эволюционирующий язык и архитектурный каркас.
- MDD — Model Driven Development — родственный модельно-ориентированный подход. FDD строит модель предметной области до кода (как MDD), но использует её для декомпозиции на фичи, а не как источник для автоматической генерации кода.
- ATDD — Acceptance Test Driven Development — родственный подход на уровне приёмки. FDD задаёт процесс доставки фичи, ATDD — её приёмку; на практике сочетаемы.
- HDD — Hypothesis Driven Development — концептуальный контрапункт FDD. В FDD фича — это требование к реализации с заранее известным результатом; в HDD фича — это вопрос к реальности (проверяемая гипотеза), ответ на который заранее неизвестен. FDD уместен там, где ценность фичи очевидна; HDD — там, где она под вопросом.
- XP — Extreme Programming — методология-антипод в рамках раннего agile: XP лёгкая и опирается на парное программирование и коллективное владение кодом, FDD тяжёлая и опирается на модель, владение классами и инспекции. Выбор между ними диктуется размером команды и контекстом.
- Agile и Scrum — процессные рамки, рядом с которыми FDD живёт как конкретный процесс для крупных команд. Scrum задаёт каркас управления, FDD — инженерный процесс и декомпозицию; на практике их можно сочетать.
- SDLC — где FDD живёт внутри жизненного цикла: процессы 1–3 закрывают фазы анализа и проектирования, процессы 4–5 — фазы разработки и тестирования.
- Декомпозиция проекта — трёхуровневая декомпозиция FDD (бизнес-активность → набор фич → фича) как конкретный метод содержательной декомпозиции.
- Итеративная и инкрементная модель — FDD сочетает разовый старт (процессы 1–3) с повторяемым циклом (процессы 4–5), что типично для гибридных итеративно-инкрементных подходов.
Родственные driven-подходы — TDD, ATDD, BDD, DDD, MDD, HDD, а также «сатирические» варианты вроде Fear Driven Development (совпадение аббревиатуры FDD; рассматривается в отдельной статье серии) — рассматриваются в соответствующих статьях серии.
Краткий вердикт для руководителя
FDD — это методология для крупных команд и формальных проектов, а не способ сделать маленькую команду быстрее. Эффект: предсказуемый прогресс по измеримым фичам, масштабируемость на десятки и сотни человек, читаемая доменная модель, управленческая отчётность, понятная нетехнарям. Цена: тяжёлая фаза моделирования, ролевая структура и инспекции, зависимость от сильного Chief Architect и Chief Programmer-ов, нишевое сообщество и литература. Берите, если команда крупная, домен стабилен и объектно-моделируем, нужна отчётность, а в команде есть сильные ведущие. Не берите, если команда малочисленна, требования летают, продукт — стартап или инфраструктура, или нет людей уровня Chief Architect / Chief Programmer. Оценивать FDD на горизонте одного спринта — ошибка; эффект проявляется на горизонте месяцев, когда список фич и parking lots становятся работающей системой предсказуемости.
Источники и материалы
Первоисточники и ключевые публикации
- Jeff De Luca. Feature Driven Development (nebulon.com/fdd) — первоисточник от автора методологии: история создания, описание пяти процессов, глоссарий FDD.
- Stephen Palmer, Mac Felsing. A Practical Guide to Feature-Driven Development. Pearson, 2002 — канонический справочник, операционное описание процессов, ролей, milestone-ов и parking lots.
- Peter Coad, Eric Lefebvre, Jeff De Luca. Java Modeling in Color with UML. Prentice Hall, 1999 — первая публикация FDD (как глава) и цветовое моделирование, лёгшее в основу процесса «Develop an Overall Model».
- Frederick P. Brooks Jr. The Mythical Man-Month. Addison-Wesley, 1975 (юбилейные издания — 1995, 2008) — «хирургическая команда», ставшая прообразом Chief Programmer-команд в FDD.
- Agile Alliance. Feature-Driven Development (FDD) — обзорная статья о месте FDD среди agile-методов.
- Paul Oldfield. материалы и доклады по FDD — практика применения и адаптации методологии в корпоративных проектах.
Связанные материалы базы знаний
- TDD — Test Driven Development — родственный driven-подход; TDD страхует реализацию отдельной фичи, FDD задаёт процесс доставки фич.
- BDD — Behaviour Driven Development — родственный driven-подход; обе методологии работают с «фичами», но в BDD это сценарий поведения, в FDD — единица доставки.
- DDD — Domain Driven Design — общий источник опоры на модель предметной области; FDD использует модель операционно для декомпозиции, DDD — как непрерывно эволюционирующий язык.
- MDD — Model Driven Development — родственный модельно-ориентированный подход; FDD использует модель для декомпозиции на фичи, MDD — как источник для кодогенерации.
- XP — Extreme Programming — методология-антипод FDD в раннем agile: лёгкость против структуры, парное программирование против инспекций.
- Agile и Scrum — процессные рамки, с которыми FDD сочетается как конкретный инженерный процесс для крупных команд.
- SDLC — место FDD в жизненном цикле разработки.
- Декомпозиция проекта — трёхуровневая декомпозиция FDD как метод содержательного разбиения системы.
