В феврале 2001 года на курорте Snowbird в штате Юта 17 разработчиков программного обеспечения встретились, чтобы обсудить упрощенные методы разработки. Результатом их встречи был следующий Agile Manifesto для разработки программного обеспечения —
Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к оценке —
То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.
Удовлетворенность клиентов — Наивысший приоритет отдается удовлетворению потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
Welcome Change — Изменения неизбежны при разработке программного обеспечения. Всегда приветствуются постоянно меняющиеся требования, даже на поздней стадии разработки. Гибкие процессы должны работать для увеличения конкурентных преимуществ клиентов.
Поставьте работающее программное обеспечение — поставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, учитывая более короткие сроки.
Сотрудничество. Деловые люди и разработчики должны работать вместе в течение всей жизни проекта.
Мотивация — Проекты должны быть построены вокруг мотивированных людей. Обеспечьте среду для поддержки отдельных членов команды и доверия к ним, чтобы они чувствовали себя ответственными за выполнение работы.
Разговор лицом к лицу. Разговор лицом к лицу является наиболее эффективным и действенным способом передачи информации в команду разработчиков и внутри нее.
Измеряйте прогресс в соответствии с рабочим программным обеспечением — рабочее программное обеспечение является ключевым и должно быть основной мерой прогресса.
Поддержание постоянного темпа — Agile процессы направлены на устойчивое развитие. Бизнес, разработчики и пользователи должны иметь возможность поддерживать постоянный темп проекта.
Мониторинг — Регулярное внимание уделяйте техническому совершенству и хорошему дизайну для повышения маневренности.
Простота. Сохраняйте простоту и используйте простые термины, чтобы измерить работу, которая еще не завершена.
Самоорганизующиеся команды . Гибкая команда должна быть самоорганизующейся и не должна сильно зависеть от других команд, поскольку лучшие архитектуры, требования и проекты возникают из самоорганизующихся команд.
Регулярно проверяйте работу — Проверяйте работу, выполняемую через регулярные промежутки времени, чтобы группа могла подумать о том, как стать более эффективной, и соответствующим образом скорректировать свое поведение.