Манифест гибкой разработки программного обеспечения (англ. Agile Manifesto) — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения, разработанный в феврале 2001 года на встрече 17 независимых практиков нескольких методик программирования на горнолыжном курорте в штате Юта.

Текст манифеста переведен более чем на 50 языков, и включает в себя 4 ценности, 12 принципов.

Текст agile-манифеста на русском языке звучит следующим образом.

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

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Основные принципы Agile-манифеста

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

Коллектив 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.