14.5 Разработка, управляемая функциональностью (Feature driven development, FDD)

В 1995 году один из крупнейших банков Сингапура , United Overseas Bank, стартовал масштабный проект полного реинжениринга своей системы крдитования. Спустя 2 года после старта, руководством банка и выполнявшей проект консалтинговой компанией, проект был признан провальным. В 1997 году к проекту подключился Джефф Де Люка (Jeff DeLuca)– успешный разработчик и менеджер проектов , создатель консалтинговой компании Nebulon Pty Ltd (Australia), прошедший за 11 лет в компании IBM путь от посыльного до старшего системного стратега. Джефф ДеЛюка собрал небольшую команду первоклассных специалистов и через 4-ре месяца продемонстрировал руководству банка работоспособность системы. Через год, в 1999 году, команда из 50-ти человек завершила проект в установленные сроки и в рамках первоначального (!) бюджета, реализовав в системе более 2000 функций. Методологию, которую выработал Джефф Де Люка и применил в проекте, он назвал Feature driven development, FDD – разработка, управляемая функциональностью.

Впервые методология была опубликована в книге «Применение Java в моделировании цветом с UML: Организация и производство (Java Modelingin Color with UML: Enterprise Componentsand Process)» в соавторстве Петером Коудом (Peter Coad), а в 2002 году вышла отдельной книгой «Практическое руководство по функционально-ориентированной разработке ПО (A Practical Guide to Feature-Driven Development)».

Методология, созданная Д.ДеЛюком объединяла передовые практики разработки программ, ориентированных на потребности заказчика:

•  Объектное моделирование предметной области – исследование и описание проблем области, которые необходимо решить. Разработка системы ведется в рамках созданной модели.
• Разработка по функциям – разбиение требований на функции, скорость реализации которых не превышает 2 недели небольшой командой разработки.
• Индивидуальное владение классом (кодом) – закрепление за каждым классом разработчика-владельца , отвечающего за  согласованность, производительность и целостность своего класса.
• Команды разработки функций – небольшие, динамически формируемые команды разработчиков, совместно проектирующие и реализующие функции системы.
• Ревью кода – проверки кода, направленные на оценку качества и раннее выявление дефектов.
• Управление конфигурацией -    идентификация общего для функций исходного кода, ведение истории изменений.
• Регулярная сборка – регулярная сборка кода, которая гарантирует наличие собираемой системы в любой момент времени.
• Мониторинг прогресса и результатов – регулярные достоверные отчеты о выполнении задач со всех уровней проекта.

Результатом комбинации данных практик стал подход, состоящий из 5-ти базовых активностей (Рисунок 1). 

Одно из достоинств данного метода – возможность масштабирования команды разработчиков в активностях «Проектирование по функциям» и «Разработка по функциям». Масштабирование становится возможным благодаря наличию общей модели и декомпозиции функционала.

Возможность интенсивной слаженной работы большой команды разработчиков из 50 человек, индивидуальное закрепление ответственных разработчиков по классам, разработка общей модели и планирование функционала на начальной стадии работ - отличительные черты методологии FDD от традиционного восприятия подхода Agile. Ценность квалифицированных специалистов, высокая вовлеченность сотрудников, командная работа, итеративная разработка - те черты, которые роднят Feature Driven Development с Agile. Поэтому участие Джона Керна (Jon Kern) - представителя FDD и соратника Джеффа Де Люка по проекту в United Overseas Bank, - в Agile альянсе и его соавторство Agile манифеста является естественным и закономерным.