Гибкая методология разработки

«Гибкие» методы (методологии, методики, подходы, практики, процессы) разработки ПО (программного обеспечения, программных продуктов, программных систем, программных проектов) (англ. agile software development), agile-разработка, agile-методы, «гибкие» методы — такие методы разработки ПО, в которых используются описанные в документе «agile manifesto» («манифесте»)^[1] 4 идеи и 12 принципов.

К «гибким» методам относят, в частности, XP, DSDM, scrum, FDD, BDD.

Большинство «гибких» методов нацелены на минимизацию рисков путём деления времени разработки на итерации (периоды) — промежутки времени сравнительно малой продолжительности. Итерация обычно длится две-три недели, выглядит как программный проект в миниатюре, включает следующие задачи, необходимые для достижения небольшого прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Одной итерации обычно недостаточно для выпуска новой версии ПО, но подразумевается, что к концу итерации новая версия ПО готова к выпуску. По окончании итерации команда переоценивает приоритеты разработки.

«Гибкие» методы опираются на общение лицом к лицу. Большинство людей работают в одном офисе, который иногда называют англ. bullpen. В офисе работает как минимум «заказчик» (англ. product owner) — заказчик разработки ПО или представитель заказчика, определяющий требования к ПО. Роль «заказчика» может выполнять менеджер проекта, бизнес-аналитик, клиент. В офисе могут работать тестировщики, дизайнеры интерфейса, технические писатели, менеджеры.

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

История

В 1990-е годы преобладали методы разработки ПО, управляемые документацией. Некоторые считали их чрезмерно регулируемыми, планируемыми и микроуправляемыми, от чего назвали их «тяжёлыми». Например, в 1990-е годы золотым стандартом разработки ПО считался так называемый «метод водопада».

В течение 1990-х годов в ответ на преобладающие «тяжёлые» методы были созданы методы, названные «лёгкими». К «лёгким» методам отнесли следующие методы:

• RAD (англ. rapid application development, быструю разработку приложений) (с 1991 года)^[2][3];
• унифицированный процесс и метод разработки динамических систем (с 1994 года);
• scrum (с 1995 года);
• crystal clear (с 1996 года);
• XP (англ. extreme programming, экстремальное программирование) (с 1996 года);
• FDD (англ. feature driven development, функционально-ориентированную разработку) (с 1997 года).

«Лёгкие» методы создавались до публикации «манифеста» и после публикации «манифеста» были отнесены к «гибким» методам.

11-13 февраля 2001 года на лыжном курорте «The Lodge at Snowbird» в горах штата Юта страны США представители методов XP, crystal clear, DSDM, FDD, scrum, adaptive software development, pragmatic programming одобрили, выпустили и подписали документ, названный «англ. agile manifesto» — «манифест гибкой разработки ПО»^[4]. Некоторые компании использовали «гибкие» методы и до принятия «манифеста». После принятия «манифеста» «гибкие» методы стали массовыми.

Принципы

«Гибкие» методы — некоторое количество методов, а не один метод. «Гибкие» методы определяются «манифестом». «Манифест» не включает практики, а определяет ценности и принципы, которыми руководствуются команды.

«Манифест» содержит 4 идеи и 12 принципов, не содержит практических советов.

Идеи:

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

Принципы^[5][6]:

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

Критика

«Гибкие» методы часто критикуют за отсутствие управления требованиями. В процессе управления требованиями создаётся план («дорожная карта», англ. roadmap) разработки (развития) ПО. Если нет управления требованиями, то и нет плана. «Гибкие» методы не подразумевают создания далеко идущих планов, подразумевают возможность заказчика неожиданно (например, в конце итерации) создать новые требования к ПО. Новые требования часто противоречат архитектуре уже созданного и поставляемого ПО. Иногда такое приводит к «авралам» с массовым рефакторингом и переделками практически на каждой итерации.

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

Методологии

Считается, что как минимум следующие методы придерживаются ценностей и принципов, заявленных в «манифесте»:

• agile modeling^[англ.] — понятия, принципы и приёмы (практики), позволяющие выполнять моделирование и документирование в проектах по разработке ПО. Не включают подробную инструкцию по проектированию. Не описывают построение диаграмм на UML. Нацелены на увеличение эффективности моделирования и документирования. Не включают программирование, тестирование, управление проектом, развёртывание, сопровождение. Включают проверку модели кодом^[7];
• agile unified process (AUP) — упрощённая версия «IBM rational unified process» (RUP), разработанная Скоттом Амблером. Описывает модель (приближение) для создания бизнес-приложений;
• agile data method^[англ.] — такие итеративные методы разработки ПО, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд;
• DSDM — метод, основанный на RAD. Итеративный и инкрементный подход, придающий особое значение продолжительному участию пользователя (потребителя) в процессе разработки;
• essential unified process^[англ.] (EssUP);
• XP;
• FDD — метод, в котором используется понятие англ. feature. Feature — функция (свойство) ПО. Понятие «feature» похоже на понятие «прецедент использования», используемое в RUP, отличается от него наличием следующего ограничения: «каждая feature должна допускать реализацию не более, чем за две недели». То есть, сравнительно малый сценарий использования можно сопоставить с одной feature и реализовать на одну итерацию. Сравнительно большой сценарий использования можно сопоставить с более, чем одной feature, и реализовать за более, чем одну итерацию;
• getting real — итеративный подход без функциональных спецификаций, использующийся при разработке веб-приложений. Для программы сперва разрабатывается интерфейс, а потом — функциональная часть;
• OpenUP — итеративно-инкрементальный метод разработки ПО. Разновидность RUP. Делит жизненный цикл проекта на четыре фазы: начальную фазу, фазу уточнения, фазу конструирования ПО, фазу передачи ПО заказчику. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении проекта. Это позволяет контролировать разработку и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл проекта. Конечным результатом проекта является окончательное приложение;
• scrum — метод, устанавливающий правила управления процессом разработки ПО. Позволяет использовать существующие практики кодирования, корректируя требования или внося тактические изменения. Позволяет выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки ПО;
• бережливая разработка ПО (англ. lean software development) — метод, использующий подходы из концепции бережливого производства.