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

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями. Agile — это обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе. К гибким методологиям, в частности, относят экстремальное программирование, DSDM, Scrum, FDD, BDD и др.

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

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

Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся 2-3 недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

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

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.

Принципы

Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.

Agile Manifesto разработан и принят 11—13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.

Основные идеи:

1. люди и взаимодействие важнее процессов и инструментов;
2. работающий продукт важнее исчерпывающей документации;
3. сотрудничество с заказчиком важнее согласования условий контракта;
4. готовность к изменениям важнее следования первоначальному плану.

Принципы, которые разъясняет Agile Manifesto:

1. удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
2. приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
3. частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
4. тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
5. проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
6. рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
7. работающее программное обеспечение — лучший измеритель прогресса;
8. спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
9. постоянное внимание улучшению технического мастерства и удобному дизайну;
10. простота — искусство не делать лишней работы;
11. лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
12. постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Критика

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

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