Дайте описание методологии « Kanban »

Дайте описание методологии «Feature Driven Development»

Feature Driven Development (FDD) - это гибкая методология разработки программного обеспечения, появившаяся в 1980 году, в результате сотрудничества Джеффа Де Люка и Питера Кода, совместившая преимущества других гибких подходов таких как Scrum и eXtreme Programming с методами модели-ориентированных подходов.

В отличие от методологий Scrum и XP, которые ориентированы на небольшие команды разработки, FDD позволяет решать проблемы, возникающие в более крупных проектах.

Согласно FDD, вся работа на проекте разбивается на 5 процессов (см. Рисунок 8). В первую очередь, в рамках нулевой итерации, или как это называется в методологии FDD, первичной проектной деятельности [30] реализуются три процесса: разработка общей модели, составление иерархического списка необходимых функций и оценка каждой функции с точки зрения трудозатрат и ответственных за реализацию.

Рисунок 8. Схема 5 процессов методологии FDD

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

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

Большое внимание в методологии FDD уделяется проверкам для того, чтобы обеспечить высокое качество проектирования и разработки. У проверок есть дополнительные преимущества:

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

· 2. Соответствие стандартам. После того как код разработчиков не прошел проверку, по причине несоответствия стандартам проектирования или разработки, значительно вероятнее, что следующий раз он постарается учитывать требования к стандартам.

Например, Страховая компания Aetna с помощью практики проверок нашла 82% ошибок в программе и, тем самым, снизила затраты на разработку на 25% [31].

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