Манифест гибкой разработки программного обеспечения (англ. Agile Manifesto) — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения, разработанный в феврале 2001 года на встрече 17 независимых практиков нескольких методик программирования на горнолыжном курорте в штате Юта.
Текст манифеста переведен более чем на 50 языков, и включает в себя 4 ценности, 12 принципов.
Текст agile-манифеста на русском языке звучит следующим образом.
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Основные принципы Agile-манифеста
- Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Коллектив Agile Alliance
Авторский коллектив документа, разработавших и подписавших манифест, именующих себя «Agile Alliance»:
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thoma |
Ограничения Agile
Большие и маленькие компании натыкаются на ошибки при использовании приципов, которые декларирует манифест гибкой разработки Agile. Есть непонимание ограничений, которые приводят к эпичным провалам. Один из последних примеров — разработка Британской системы социальных платежей Universal Credit.
Бывают провалы просто по непониманию. Типичные деревянные самолеты без двигателя, которые не хотят взлетать. Например, из совсем недавнего: «Мы не пишем тесты, мы используем Agile методы, у нас и так хороший код».
Я предлагаю вам посмотреть на ограничения, по которым вы можете оценить, подходит вам Agile или не подходит:
Про критичность, размер команды и кол-во изменений все понятно. Самыми проигнорированными оказываются шкала Квалификация и шкала Культура. Agile подводит к тому, что не стоит уделять слишком много времени жесткому процессу. Может показаться, что это несет некоторые послабления. В какой-то мере так и есть, но это послабление требует гораздо большей ответственности и квалификации от каждого участника процесса разработки ПО. Эта часть ключевая и не надо про нее забывать.
Более подробно про тему ограничений рекомендую прочитать в книге Balancing Agility and Discipline: A Guide for the Perplexed.