Agile Manifesto

Зимой 2001 года на горнолыжном курорте в штате Юта собрались представители SCRUM, Extreme Programming, Crystal, DSDM, Pragmatic Programming, Adaptive Software Development и др.. В результате этого 13 февраля был выпущен Agile Manifesto – декларация разработчиков ПО, подписанная авторским коллективом из 17 человек.

Содержание манифеста

КонцепцииСодержание манифеста состояло из 4-х ценностей и 12 принципов, определяющих общие правила разработки востребованного потребителем продукта с «гибким» подходом к процессу постановки и решения задачи. При этом манифест не содержал готовых практик по воплощению проектов в жизнь. Для этого нужно было использовать инструментарий других методов управления проектами (например, SCRUM, Crystal, Kanban и др.).

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

Так, принципы манифеста гласят, что:

  • приоритетными являются потребности заказчика и ежедневное взаимодействие разработчика с ним,
  • изменение требований добавляет конкурентные преимущества продукту, поэтому приветствуется на любой стадии разработки,
  • работающий продукт надо выпускать максимально часто, и он же будет основным показателем прогресса,
  • мотивация и профессионализм разработчиков должны быть на высоком уровне, чтобы поддерживать устойчивый ритм без ограничения времени,
  • команда должна самоорганизовываться и совершенствоваться.

Кроме того, следует упрощать процессы, минимизируя количества лишних операций.

Ценности Agile

4 ценности манифеста звучат так:

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

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

  • С одной стороны – работа в прежнем стиле: аналитик собирает требования в документ установленного им же образца и передаёт его в проектный отдел, откуда получает замечания и затем на столе разработки использует инструмент управления изменёнными требованиями.
  • Работа в Agile-стиле в этой же ситуации предполагает как вариант предварительный митинг (публичный разговор с аналитиком) с целью выяснить, как складывалась концепция функционала. Во время такого общения разработчики и тестировщики сразу дадут уточнения по деталям. И пока аналитик будет составлять документацию и связываться с заказчиком, разработчики на архитектурной сессии начнут обсуждение влияния новой фичи на функционал ПО. Здесь важно то, что и процессы запускаются параллельно, и то, что формируется единое видение проекта.

Поскольку манифест Agile цитируется в российской бизнес-среде в основном в переводе, Вячеслав Цырульник (директор сервисного ресурса по управлению процессами) дал свои уточняющие комментарии к некоторым переводным тезисам. Так слово «важней» в оригинале звучит как «over» - «над», что, например, в случае с первым утверждением надо переводить как «Люди и взаимодействие над процессами и инструментами». По мнению Вячеслава, этот тезис правильнее понимать так: люди и стиль их взаимодействия становятся определяющим фактором в выборе необходимых процессов и инструментов.