Функционально-ориентированная разработка (FDD) — это методология разработки, в которой основное внимание уделяется предоставлению небольших дополнительных функций или единиц функциональности в качестве основного средства прогресса. Это гибкий подход, который призван реагировать на меняющиеся требования и приоритеты. Основателями Feature Driven Development были Джефф Де Лука и эксперт по моделированию Питер Коад. Впервые FDD был применен в 1997 году при работе над продуктом для сингапурского банка. На создание продукта ушло 15 месяцев, принимало участиет 50 человек. После успеха его использовали во втором проекте, длившемся уже 18 месяцев и рассчитанном на 250 человек.
Итак, выделим основные принципы функционально-ориентированной разработки:
- Моделирование объектов предметной области. Команды создают диаграммы для описания объектов в предметной области и отношений между ними. Этот процесс экономит время, помогая вам определить, какую функцию добавить в продукт.
- Разработка по функциям. Если функцию невозможно реализовать в течение двух недель, ее следует разбить на более мелкие, управляемые функции.
- Функциональные группы. Хотя за производительность и качество каждого класса отвечает один человек, функция может включать более одного класса, поэтому каждый член функциональной группы вносит свой вклад в решения по проектированию и реализации.
- Проверки. Команды FDD проводят проверки для выявления дефектов и обеспечения наилучшего качества.
- Управление конфигурацией. Эта практика включает в себя определение исходного кода для всех функций и документирование изменений.
- Регулярный график «сборки». Эта передовая практика гарантирует, что у команды всегда будет актуальная система, которую можно продемонстрировать клиенту.
- Отчеты о ходе работы. Руководители проектов должны часто предоставлять отчеты о ходе выполненной работы.
Группа моделирования FDD включает в себя следующие основные роли:
- Менеджер проекта контролирует весь проект.
- Главный архитектор отвечает за моделирование системы. Он работает с другими опытными разработчиками на этапе планирования цикла разработки.
- Менеджер по разработке возглавляет и наставляет команду разработчиков, а также контролирует повседневную деятельность по программированию.
- Главный программист помогает с анализом и проектированием, а также может быть назначен руководителем небольших групп разработчиков.
- Владелец класса является членом небольшой группы разработчиков, возглавляемой главным программистом. В его обязанности входит проектирование, кодирование, тестирование и документирование функций.
- Эксперт в предметной области — это член команды, который понимает проблему, которую необходимо решить клиенту. Разработчики полагаются на знания экспертов в предметной области, чтобы гарантировать, что они работают и предоставляют то, что наиболее важно для клиента.
Перейдем к действиям, которые предпринимаются в рамках работы с функционально-ориентированной разработкой:
Шаг 1. Разработка общей модели.
На этом этапе создается план, определяющий модель предметной области — бизнес-задача, которую вы хотите решить в рамках проекта разработки программного обеспечения. Команда тесно сотрудничает с главным архитектором, чтобы определить объем и контекст системы. Несколько моделей предметной области следует объединить в одну общую модель в качестве основы для вашей системы.
Шаг 2. Создание списка функций.
Список функций аналогичен бэклогу продукта Scrum. Определите функции, которые важны для клиента. Функции выражаются в виде действия, результата и объекта (например, «подтвердить номер учетной записи пользователя»). Разработка любой конкретной функции не должна занимать более двух недель. Если создание функции займет больше времени, ее следует разбить на более мелкие функции.
Шаг 3. Планирование по функциям.
Определяется порядок, в котором функции из списка будут разрабатываться и реализовываться. Учитывайте потенциальные риски, зависимости, командную и индивидуальную рабочую нагрузку, а также любые другие препятствия, которые могут помешать разработке функций.
Шаг 4. Дизайн по функциям.
Главный программист определяет, какие функции будут спроектированы и реализованы за двухнедельную итерацию. Он же определяет приоритеты функций, кто будет участвовать в функциональной команде. Прежде чем двигаться дальше, вся команда должна провести анализ дизайна.
Шаг 5. Создание по функциям.
На этом этапе реализуются все элементы, необходимые для поддержки проектирования функций. Разработан пользовательский интерфейс, создан и протестирован прототип функции. Если функция пройдет тестирование и будет одобрена, завершенную версию можно будет добавить в основную сборку и сделать доступной клиентам.
Использование функционально-ориентированной разработки имеет множество преимуществ, таких как четкое управление проектами, минимизация сложности и создание более качественных продуктов.
