Рис. 1.1. Практики экстремального программирования создают возможности быстрого обучения посредством множественных слоев петли обратной связи

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

Одновременно с этим, в 1991 году, Алистеру Коуберну, методологу, работающему в новой консалтинговой группе компании IBM, дали задание найти причины успеха проектных групп. Углубившись в изучение проектов на Smalltalk и С++, Коуберн обнаружил, что в литературе того времени не были описаны факторы, делающие проектные группы успешными. Опросив десятки таких групп, он выделил ключевые элементы успешных команд в семейство методологий Crystal: серию легких процессов, подходящих к определенным типам проектов. Основная идея заключается в том, что каждому проекту нужна своя методология и методы должны меняться так же, как меняется ситуация [18] .

Пока эти лидеры мнений искали способы написать лучшее ПО, индустрия сама по себе находилась в плачевном состоянии. На протяжении 1970–1990-х было несколько происшествий, породивших заголовки о крупных превышениях сметы, хронических проблемах с качеством и возмутительных задержках продукта. В 1994 году группа из Стандиша опубликовала отчет CHAOS (акроним, англ. chaos – хаос), согласно которому среднее превышение запланированных расходов на проекты программного обеспечения составляло 189 % [19] . Отчет часто цитировали. Согласно другим данным, примерно половина проектов работали, но немногие из них считались успешными. Кроме того, три четверти всех крупных программных продуктов, представленных потребителям, не отвечали их требованиям.

Ситуация не осталась без внимания программистов. Они поняли, что текущая ситуация неустойчива. На протяжении 1990-х профессионалы сферы ПО регулярно встречались и делились идеями. Что общего есть у появляющихся подходов? Какими способами можно улучшить написание ПО? Люди понимали, что ситуацию надо менять, но их идеи еще не могли срастись во что-то значимое.

Нужно было что-то делать. Поскольку XP начало продвигаться в сообществе, Мартин встретился в Чикаго с Мартином Фаулером, экспертом XP, с которым он познакомился на конференции Кента Бека XP Leadership осенью 2000 года. Вместе они пришли к выводу, что необходимо организовать что-то вроде саммита, чтобы люди с похожими взглядами смогли собраться и создать манифест легких процессов. Мартин и Фаулер начали подбирать участников этой встречи так, чтобы на ней были представлены разные взгляды. Одним из тех, кто получил приглашение на «саммит легких процессов» по электронной почте, был Алистер Коуберн.

Коуберн, который в тот момент был занят организацией похожей встречи по тем же причинам, что и Мартин с Фаулером, с радостью принял приглашение, предложил взять на себя логистику и организовать встречу неподалеку от его дома в Юте [20] .

Несколько месяцев спустя, в феврале 2001 года, Бек, Коуберн, Мартин, Фаулер, Швабер, Сазерленд и еще одиннадцать опытных лидеров мнений собрались в городе Сноуберде, чтобы понять, что не так в способах создания ПО. Они задались вопросом: как они могли бы улучшить способы разработки ПО, используя свой опыт? Как разработчики ПО, они истово гордились собственным ремеслом, однако их не удовлетворяло ни состояние отрасли в целом, ни негативное восприятие разработки ПО как профессии. Они хотели создавать ПО, которое нравится потребителям, и повлиять на организации, формировавшие среду с лучшим ПО [21] , [22] .

Через несколько дней споров и обсуждений разработчики создали «Манифест гибкой разработки программного обеспечения» (Agile-манифест), состоящий из четырех ценностей и двенадцати принципов [23] .

Следом за ценностями через несколько недель после встречи в Сноуберде были разработаны двенадцать принципов.

Цели и принципы Agile-манифеста были вдохновлены движениями, сформированными на протяжении нескольких лет: Scrum, Crystal, Extreme Programming, Dynamic Systems Development Method (DSDM) и Feature-Driven Programming (в главе 3 вы узнаете больше об этих методологиях). Все эти методологии и философии, лежащие в их основе, направлены на разработку лучшего ПО, однако авторы манифеста поняли, что создали нечто более глубокое и основательное, чем программный документ.