Feature Driven Development

Еще одна известная гибкая методология разработки — это Future Driven Development (FDD), которая совмещает преимущества ХР и Scrum с модельно-ориентированными подходами. Подходу FDD удалось решить главную проблему предшественников: возможность работы только с небольшими командами. FDD, напротив, используется для работы над большими проектами. Первое использование произошло в целях создания банковской системы высокого уровня.

В рамках методологии FDD все проектные работы требуется разделить на пять процессов (рис. 6.3). Во время нулевой итерации (первичной проектной деятельности в терминах FDD) происходит реализация трех процессов. Разрабатывается общая модель, составляется иерархический список необходимых функций, производится оценка функций с точки зрения трудозатрат.

Рис. 63. Схема методологии FDD.

После выделения основных функций для клиента начинается процесс их реализации, который происходит итеративно (рис. 6.4). Ранее созданная модель системы может корректироваться и уточняться. В конце каждой итерации результатом становится работающая функция, которая уже установлена на промышленный сервер. Особый акцент в FDD делается на проектировании модели системы, в связи с чем высоко значение так называемого моделирования в цвете при помощи UML.

Па этапе моделирования создается несколько конкурирующих моделей за авторством разных команд, независимых друг от друга. После этого совместными усилиями строится общая модель, которая содержит лучшие решения из каждой модели. За каждую отдельную итерацию рассматривается только один кусок модели, который предварительно уточняется и детализируется (производятся так называемые дизайн-сессии).

Рис. 6.4. Схема процесса FDD¹

Процесс разработки контролируется за счет плана, который составляется заранее. Также для контроля определяют ответственных лиц. Методология FDD предполагает, что результат должен быть видимым, иначе менеджеру будет тяжело понять, на каком этапе находятся работы, но проекту.

Наличие ответственных лиц снижает коммуникационную проблему внутри команды и позволяет эффективно работать географически распределенным группам. Ответственным за последовательность выполнения считается ведущий разработчик. Он планирует работы, на основании которых ответственные по классам самоорганизуются с целью получить требуемый результат.

FDD уделяет пристальное внимание проверкам на этапе разработки. Использование проверок несет в себе следующие преимущества:

• • обмен опытом и культурой разработки;
• • соответствие стандартам.

Несмотря на очевидные плюсы, методология FDD обладает ярко выраженными недостатками. Прежде всего, в методологии отсутствует практика проведения встреч между разработчиками. В результате страдает доверие к коллегам.

Другой недостаток — наличие правил только по вопросам управления разработкой и проектированием. Для управления требованиями потребуется использовать иной подход. Сравнение подходов Scrum, FDD и ХР приведено на рис. 6.5.^[1]

Рис. 6.5. Сравнение методологий Scrum, FDD, ХР^1.

• [1] Бибичев Л. Проектирование больших информационных систем в Agile // Материалыкомпании CustlS, конф. SECR-2009, 2009, 30 окг. URL: http://www.slideshare.net/biBIGine/agile-2 382 913 (дата обращения: 07.10.2016).