Все о FDD: от основ до лучших практик. Узнайте, как применять FDD для повышения продуктивности и качества разработки продуктов через функциональные возможности.

Функционально–ориентированная разработка, или Feature Driven Development – это гибкий метод управления разработкой, который берет свои корни из Agile. Принцип его работы заключается в том, чтобы отдельные функции и функциональные блоки выполняли только свои задачи. Благодаря ему команда разработчиков может быстро реагировать на новые условия и требования к продукту и реализовать их за короткий срок.

Авторами данного метода разработки выступили Джефф Де Лука и Питер Коад. Впервые они применили подход в 1997 году во время работы над продуктом для банка из Сингапура. Тогда их команда в размере 50 человек смогла выполнить проект за 15 месяцев. За это время они внедрили 2000 различных функций.

Правда, результаты применения функционально–ориентированного метода разработки они опубликовали лишь спустя два года под названием «Java Modeling in Color with UML».

Они предложили некоторую комбинацию, которая включает в себя следующие пять процессов:

• Разработка модели.

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

• Создание списка функций.

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

• Планирование.

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

Выстраивается график работы в соответствии с приоритетностью задач. Разработка каждой функции ограничена во времени. Это позволяет выполнить проект в срок и сосредоточиться только на текущей работе. Кроме того, график позволяет отслеживать прогресс разработки.

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

• Дизайн и разработка.

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

• Реализация.

Этот и предыдущий этап работы над проектом составляют примерно 75% усилий команды. Здесь они проводят проверку кода и модуля, после чего приступают к разработке программного обеспечения.

Данный подход можно сравнить с матрешкой. То есть мы имеем проект, который делится на несколько функциональных блоков. Каждый из них делится ещё на отдельные функции. По возможности каждая функция делится ещё. Таким образом, процесс разработки разделяется на небольшие задачи, которые проще реализовать и измерить их эффективность.

В целом гибкие методы схожи в том, что стараются большую цель разделить на множество задач. Это дает множество преимуществ. Во–первых, таким образом команда разработки имеет возможность равномерно распределить нагрузку и избежать переработки. Если специалист занимается только той задачей, которая актуальна именно сейчас, то он может быть максимально сосредоточен. Это снижает вероятность возникновения ошибок и повышает качество продукта.

Во–вторых, компания таким образом сохраняет гибкость. То есть в случае необходимости они могут внести изменения в продукт быстро и без потери эффективности. Не важно, будь то новые требования рынка или запросы заказчика.

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

Функционально–ориентированная разработка подходит в тех случаях, когда требуется, чтобы продукт был масштабируемым. То есть, если растет компания, то увеличиваются ее потребности, которые программа или софт должны покрывать. Должна быть возможность добавлять новые возможности и оптимизировать старые.

Например, это могут быть средние и большие проекты разной степени сложности. Они нуждаются в гибкости из–за переменчивости рынка, либо из–за высоких темпов развития. Заказная разработка — процесс не самый быстрый. Требуется немало времени на создание программного продукта, а затем его внедрение в процессы заказчика. В случае с FDD, вся работа выполняется постепенно. То есть возможность внедрения изменений как в процессе разработки, так и после ее завершения.

Метод Feature Driven Development, скорее всего, не подойдет в том случае, если при создании проекта требуется соблюдение линейности.

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

• Моделирование объектов предметной области.

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

• Разработка по функциям.

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

• Функциональные группы.

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

• Проверка.

Чтобы обеспечить наилучшее качество разрабатываемого продукта, команда проводит регулярные проверки. Таким образом, они не только находят ошибки, требующие исправления, но и возможности, позволяющие улучшить продукт.

• Управление конфигурацией.

Здесь подразумевается определение исходного кода для каждой функции и постоянное документирование изменений, которые произошли в процессе разработки.

• Регулярный график.

Данная практика предоставляет гарантию заказчику, что у команды всегда будет актуальная система, которую он сможет в любой момент посмотреть. То есть такое своеобразное live–шоу в IT–сфере, позволяющее следить за прогрессом и качеством, а также вносить необходимые изменения для улучшения продукта.

• Отчетность.

Сбор данных для отчетности производится постоянно. Это необходимо для того, чтобы иметь возможность контролировать процесс, находить в нем узкие места и возможности для оптимизации. Это повышает качество продукта, а также позволяет компании держать руку на пульсе и поддерживать высокий уровень конкурентоспособности. Таким образом, команда обеспечивает удовлетворенность клиента результатами не только по окончании проекта, но и в процессе разработки.

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

Согласно принципам Feature Driven Development, процесс разработки должен быть наглядным. Это необходимо для того, чтобы команда, менеджер проекта, заказчик и другие заинтересованные лица имели представление о прогрессе работы.

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

Менеджер проекта.

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

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

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

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

Главный архитектор.

Выступает в роли лидера команды, который составляет модель функций. Вместе с менеджером проекта он формирует команду, которая будет разрабатывать продукт.

Архитектор следит за тем, чтобы специалисты следовали плану работ и способствует оптимизации процессов. Он решает технические вопросы, выступает в роли консультанта, помогает внести изменения в проект.

В зависимости от размера компании и сложности проекта, количество главных архитекторов может варьироваться. Если над одним и тем же продуктом трудится множество команд, то у каждой будет свой.

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

Менеджер по разработке.

По сути, является ещё одним типом руководителя, который взаимодействует с командой. Но тем не менее его обязанности и зона ответственности все–таки отличаются.

Во–первых, менеджер координирует взаимодействие команды, главного архитектора и менеджера проекта. Во–вторых, он следит за ежедневной деятельностью каждого участника разработки. Благодаря этому он может проверить, правильно ли была распределена нагрузка, справляются ли специалисты со своими задачами. Кроме того, это дает возможность следить за прогрессом и определять узкие места в процессах, требующие оптимизации. В–третьих, он выступает в качестве посредника в конфликтах между членами команды. Менеджер старается определить суть конфликта и разрешить его оптимальным путем для обеих сторон. Это важно для поддержания эффективности команды.

Главный программист.

Помогает разработчикам следовать плану работы. Обладает самыми прокачанными скиллами и опытом, что наделяет его полномочиями наставника. Может консультировать по различным вопросам разработки и даже руководить отдельно взятыми группами внутри проекта. Участвует в работе только над одним проектом, даже если компания ведет несколько разработок.

Владелец класса.

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

Эксперт в предметной области.

По сути это любой член команды, который имеет самый прокаченный hard skill в определенной области. Может быть полезен в решении спорных и сложных вопросов в разработке.

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

В конечном счете все сводится к тому, что ни один из методов разработки не является идеальным. В некоторых случаях команды берут лучшие практики из разных подходов и применяют их в одном проекте, чтобы добиться наилучшего результата. Ниже рассмотрим преимущества и недостатки Feature Driven Development.

Преимущества FDD.

Наглядность.

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

Параллельная работа команд.

В отличие от каскадного метода, FDD позволяет командам заниматься своими задачами одновременно. То есть тестировщики не будут сидеть без дела, пока разработчики пишут код для очередной функции внутри функции. Это, в свою очередь, позволяет сократить время разработки. Кроме того, таким образом можно своевременно обнаружить ошибки кода, которые требуется исправить, чтобы улучшить продукт.

Постоянное взаимодействие внутри команды.

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

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

Масштабизация.

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

Гибкость.

Каждая функция делится на ещё меньшие функции, что позволяет упростить процесс разработки. Также это дает возможность внедрять изменения в продукт, исправлять ошибки и улучшать его качество. Это, в свою очередь, повышает уровень удовлетворенности клиента.

Рост и развитие команды.

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

Недостатки FDD.

Метод рассчитан только на средние и большие проекты.

В случае, если команда занимается разработкой простых продуктов, то данный подход не будет эффективным. Также он не подойдет в том случае, если при работе над проектом используется каскадный подход.

Зависимость от главного программиста и ведущих разработчиков.

Качество продукта и эффективность процесса разработки во многом зависит от уровня hard skill и soft skill главного программиста и ведущих разработчиков. То есть они должны обладать достаточно высоким уровнем компетенций и обширным опытом, чтобы иметь возможность решать задачи разной степени сложности. Если компания по какой–то причине потеряет одну из ключевых позиций, это может негативно отразиться на эффективности разработки.

Не существует стандартной процедуры итерации.

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