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

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

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

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

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

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

В течение 1990-х годов в ответ на преобладающие «тяжёлые» методы были созданы методы, названные «лёгкими». К «лёгким» методам отнесли следующие методы: RAD (, быструю разработку приложений) (с 1991 года); унифицированный процесс и метод разработки динамических систем (с 1994 года); scrum (с 1995 года); crystal clear (с 1996 года); XP (, экстремальное программирование) (с 1996 года); FDD (, функционально-ориентированную разработку) (с 1997 года). «Лёгкие» методы создавались до публикации «манифеста» и после публикации «манифеста» были отнесены к «гибким» методам.

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

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

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

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

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

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

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

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

Примечания

Литература

Категория:Разработка программного обеспечения