В начале 2001 года на фоне гор Уосатч в городе Сноуберд, штат Юта, собрались 17 человек, чтобы обсудить будущее разработки программного обеспечения. Участников этой группы объединяло беспокойство по поводу текущего положения дел в отрасли. При этом их не пугало, что все они по-разному представляли оптимальное решение.

Они сошлись во мнениях об основной проблеме: компании настолько сосредоточены на избыточном планировании и документировании своих циклов разработки ПО, что забыли о главном — о том, что нужно приносить радость клиентам.

Навязывая корпоративные ценности, такие как «мастерство» и «добросовестность», компании почти не помогали людям (особенно разработчикам ПО) повысить эффективность работы. Это нужно было менять. У многих участников группы Snowbird 17 уже были идеи по поводу того, как открыть новую эру разработки ПО.

Поездка в горы позволила им это обсудить.

Результатом длинных выходных стал Манифест Agile. Этот краткий и выразительный документ состоял всего из 68 слов и навсегда изменил разработку программного обеспечения. За почти два десятилетия, прошедшие с момента его создания, эти слова (и 12 последовавших принципов) были приняты (в той или иной степени) огромным количеством людей, команд и компаний.

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

Сам Манифест появился в то время, когда требовалось найти точки соприкосновения между Scrum, экстремальным программированием, Crystal Clear и другими методиками.

«Они начали понимать, что делают что-то похожее. Но на тот момент они очень сильно конкурировали друг с другом, по крайней мере в том, что касается идей, — говорит Ян Бьюкенен, главный инженер по решениям DevOps в Atlassian. — С учетом обстоятельств то, что они вообще смогли договориться о некоем наборе принципов, уже само по себе знаменательно».

Группа Snowbird 17 хотела посмотреть, смогут ли представители разных дисциплин о чем-то договориться (о чем угодно). И к их удивлению, они смогли это сделать. Они договорились о наборе ценностей, которые определили культуру.

Вот этот набор.

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

Благодаря проделанной работе мы смогли осознать следующее.

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

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

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

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

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

Двенадцать принципов Agile-разработки ПО, также ставшие результатом встречи в Сноуберде, расширяют эти несколько предложений, определяющих ценности.

Это все. С тех пор веб-сайт с Манифестом Agile практически не изменился (а может, не менялся вовсе), чего не скажешь о мире вокруг Agile.

Группе Snowbird 17 удалось объединить различные точки зрения в несколько основных принципов, но на этом дебаты не закончились. Так или иначе методика Agile раздроблена на гораздо большее количество способов применения, чем обсуждали основоположники. Похоже, что у каждого есть свой взгляд на Agile.

На сегодняшний день есть SAFe, LeSS и даже такие реализации Agile, которые не имеют никакого отношения к разработке программного обеспечения, хотя Манифест начинается со следующих слов: «Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим».

Дейв Уэст, генеральный директор Scrum.org, посещающий различные организации, которые реализуют принципы Agile, собрал исследовательскую группу, которая применяет Agile для разработки лечения от генетической слепоты с использованием вирусов.

Следует отметить, что использование методики Agile действительно завоевало популярность вне сферы программного обеспечения, однако создатели Манифеста, скорее всего, даже не рассчитывали на такой результат.

«Эти принципы можно истолковать, но для их качественного воплощения требуется глубокое понимание», — говорит Бьюкенен. Такой уровень понимания не всегда доступен — даже в рамках разработки программного обеспечения.

Многие утверждают, что пагубное влияние методики «псевдо-Agile» и ее злого двойника под названием «темная методика Agile» усугубляется из-за монетизации связанного с ними обучения и консультирования. Некоторые даже называют соответствующие организации «Комплексом производства Agile». 

«Существует карго-культ Agile, когда вы делаете и говорите правильные вещи, но не понимаете основных принципов. В итоге вам не удается достичь результатов», — говорит Бьюкенен.

Некоторые считают, что виновата компания Atlassian, поскольку наши продукты позволяют использовать методики Agile, такие как Scrum и Kanban. Но мы убеждены, что Agile является культурной ценностью, и команды должны иметь возможность работать так, как считают нужным. Методики Agile работают бок о бок с культурными ценностями, но если у вас нет культурной базы, любые действия могут с самого начала оказаться ошибочными.

Использование подверсий Agile (их называют «псевдо-версиями», «темными версиями» или «карго-культом») зачастую приводит к ситуациям, которые полностью противоречат концепции Манифеста. Наиболее разрушительными чрезмерный контроль, приводящий к выгоранию темп работы, отсутствие поставки и предпочтение процессов принципам являются — даже если у практикующих специалистов есть сертификат. К сожалению, подобный опыт применения «темной» версии Agile заставляет некоторых людей полностью отказаться от методики (или переписать ее, чтобы отразить свой опыт практической работы).

Рон Джеффрис, один из участников группы Snowbird 17, попытался решить эти отклонения с помощью следующего уточнения: «Здесь и в других работах я использую слово "Agile" в кавычках для обозначения множества примеров, подходов и процессов, которые описываются как Agile, но при этом не всегда следуют духу и букве гибкой методики разработки ПО, о которой мы писали в Манифесте Agile. Иногда я буду употреблять слово "псевдо-Agile", чтобы подчеркнуть различия с исходной методикой, или "темная методика Agile" для описания действительно неудачных "Agile-подходов". Я также могу упоминать "Манифест Agile", чтобы указать на основные идеи Манифеста, в которые я по-прежнему верю».

Но если учесть широкое (и порой некорректное) внедрение Agile, имеет ли смысл по-прежнему ссылаться на Манифест?

Поговорив с сотнями клиентов Atlassian, внутренними и внешними тренерами по Agile, энтузиастами и активными практикующими специалистами (не говоря уже об огромном количестве публикаций в социальных сетях), я могу с уверенностью ответить: да.Манифест по-прежнему актуален. Думаю, сейчас он актуален как никогда раньше.

Мои коллеги, Дэн Рэдиган, старший корпоративный тренер по Agile, и Иэн Бьюкенен, ежедневно работающий с клиентами, подтвердили, что регулярно акцентируют внимание новых клиентов на этом Манифесте. 

Таннер Уортэм, тренер по Agile и старший менеджер по техническим программам в LinkedIn, говорит, что он тоже часто цитирует Манифест. Уортэм отслужил 10 лет в морской пехоте и начал практиковать методику Agile еще до того, как узнал, что для нее есть название. Для себя он называл ее просто «руководство морской пехотой». Сам Уортэм считает, что для решения проблемы важно сперва ее назвать.

«Любому явлению нужно дать название, чтобы понять, что с ним делать. По-моему, именно эту задачу и выполнил Манифест — он присвоил методике название, и все стали называть ее Agile. Скорее всего, она существовала и раньше, но благодаря названию всем стало легче ее идентифицировать».

Дейв Уэст, генеральный директор Scrum.org, отмечает, что принципы Agile существовали и раньше. Просто они стали применяться по-другому.

«Когда я смотрю на принципы, лежащие в основе Манифеста, я вижу, что мы не изобретали их», — говорит Уэст. — «Это принципы научного метода, применявшиеся еще Галилеем и Архимедом».

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

Итак, принципы Agile существовали до создания Манифеста. Люди применяли их для разработки программного обеспечения. Эти ценности были зафиксированы в Манифесте Agile. Затем эти принципы взяли и начали применять в работе. Может, по итогам трансформации идей пришло время обновить Манифест?

Необязательно.

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

«Манифест во многом определяет направление беседы, — говорит Уортэм. — Я понимаю его вот так. А как понимаете его вы? Хорошо, давайте выясним, как нам работать вместе».

Здесь, пожалуй, важен не один священный документ, с которым все могли бы согласиться, а то, сможет ли группа людей (от команды до организации в целом) применить идеи Манифеста к конкретной ситуации, не упустив из виду его истинный смысл. Если сделать все правильно, перед нами откроются безграничные возможности.

«Думаю, если мы сделаем все правильно, мир сможет нас удивить. Мы сможем победить рак. Возможно, мои дети доживут до 150 или 175 лет, — говорит Уэст. — Я считаю, что нам это под силу и мы справимся».

Особая благодарность Аманде О'Каллаган, Иэну Бьюкенену, Дэну Радигану, Дэвиду Уэсту и Таннеру Уортэму за то, что поделились своими мыслями и опытом для этой статьи.