Процесс открытого рецензирования пошел на пользу и первому изданию, и все его преимущества, в свою очередь, отразились и на этой книге. Спасибо Адриану Ховарду, Адриану Саттону, Энн Баркомб, Энди Лестеру, Энтони Уильямсу, Басу Водде, Биллу Капуто, Бобу Коррику, Брэду Эпплтону, Крису Уилеру, Кларку Чингу, Дади Ингольфссону, Диане Ларсен, Эрику Петерсену, Джорджу Динвидди, Илье Прейсу, Джейсону Йипу, Джеффу Олферту, Джеффри Палермо, Джонатану Кларке, Кейт Рэй, Кевину Рутерфорду, Ким Грэсман, Лизе Криспин, Марку Уайтэ, Николасу Эвансу, Филиппе Антрасу, Рэнди Коулмэн, Роберту Шмитту, Рону Джеффрису, Шейну Доуну, Тиму Хоутону и Тони Бирну за их множественные комментарии и Брайану Марику, Кену Пью и Марку Стрейбеку за их замечания по готовому черновику.

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

Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Agile везде. И, как ни парадоксально, нигде.

Двадцать лет назад локомотив Agile с ревом ворвался в сознание разработчиков программного обеспечения. За это время количество компаний, называющих себя Agile, возросло на порядки. А сколько команд действительно применяет Agile-подход в своей работе? Не так много. Agile, легко повторяемое название, пользуется огромным успехом. А как насчет идей, стоящих за названием? Вообще-то большинство из них игнорируется.

Исправим это.

В 1990-е считалось, что разработка ПО находится в кризисе. Это явление так и называлось: «Кризис программного обеспечения». Проекты разработки выходили за рамки бюджетов, задерживались, не отвечали требованиям, и (согласно часто цитируемому и зловеще именуемому «Отчету о Хаосе» (CHAOS Report)) почти треть их была полностью отменена [Standish1994].

Agile не был ответом на этот кризис. Отнюдь нет. Agile стал ответным подходом.

Чтобы взять под контроль разработку ПО, большие организации придумали высокодетализированный процесс, точно определявший, как ПО должно создаваться. Все жестко контролировалось, чтобы исключить возможность ошибки. (Во всяком случае, в теории.)

Сначала бизнес-аналитики должны были опрашивать стейкхолдеров (stakeholders, заинтересованные стороны) и документировать системные требования. Далее архитекторы программного обеспечения должны были изучить документы с требованиями и создать подробную проектную документацию, определяющую каждый компонент системы и их взаимосвязь друг с другом. Затем программисты должны были конвертировать проектную документацию в код. В некоторых организациях такое выполнение механического перевода считалось низкоквалифицированной работой.

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

Подход, основанный на фазах, получил название водопадной (waterfall development) или каскадной разработки (phase-gate development)[4]. Если вам это кажется похожим на нелепое пугало – считайте, что вам повезло. Не все команды применяли в 1990-х перегруженный документацией каскадный процесс, но он широко признавался как логичный и разумный метод работы. Конечно, нужно было определить требования, разработать проект, затем выполнить реализацию и следом – тестирование. Конечно, нужно было документировать каждую фазу. Это была дисциплина. Это была инженерия. Как еще можно было добиться успеха?

Крупные компании расписывали свои процессы в мельчайших деталях. Роли, ответственности, шаблоны документов, языки моделирования, советы по контролю за изменениями… каждый аспект разработки строго регламентировался и контролировался. Если проект заканчивался провалом (а согласно CHAOS Report, менее одной шестой доли проектов были успешны), причиной считалась недостаточная детализация процесса: нужно больше документов, больше согласований. Это порождало огромное количество документации. Мартин Фаулер описывал это в своей статье The Almighty Thud [Fowler1997].

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

И тогда несколько человек создали более простые, изящные и менее директивные методы разработки программного обеспечения. Они назывались легковесными в отличие от тяжеловесных, использовавшихся большими компаниями. Эти методы носили такие названия, как адаптивная разработка программного обеспечения (Adaptive Software Development), Crystal, разработка на основе функциональности (Feature-Driven Development, FDD), метод разработки динамических систем (Dynamic Systems Development Method, DSDM), экстремальное программирование (ХР) и Scrum.

К концу 1990-х эти методы стали привлекать серьезное внимание. Экстремальное программирование, в частности, вызвало вспышку массового интереса среди программистов. В 2001 году 17 сторонников легковесной методологии встретились на горнолыжном курорте в штате Юта, чтобы обсудить объединение усилий.

«Лично я не ожидал, что эта конкретная группа [людей] сможет договориться о чем-либо по существу», – позже говорил Алистер Кокберн.

И действительно, за два дня они смогли договориться только о двух вещах: названии Agile и заявлении о четырех ценностях новой методологии (рис. 1.1). В течение следующих нескольких месяцев, переписываясь по электронной почте, эти люди сформулировали 12 сопутствующих принципов (рис. 1.2) [Beck2001].

Рис. 1.1. Ценности Agile

Рис. 1.2. Принципы Agile

Это стало Манифестом Agile, который изменил мир. «Таким образом, – продолжил Алистер, – они в конце концов все же смогли договориться о чем-то по существу»[5].

Однако единого метода Agile не было. Его никогда не было и никогда не будет. Agile подразумевает три составляющие: название, ценности и принципы. И все. Это не что-то, что можно делать. Это философия. Это способ мышления, посвященный разработке программного обеспечения. Невозможно «использовать» Agile или «делать» Agile… вы только можете быть Agile. Или не быть. Если ваши команды воплощают философию Agile, то вы – Agile. Если не воплощают – то нет.

Мартин Фаулер сделал карьеру, превращая сложные вопросы о программировании в тщательно продуманные, беспристрастно точные объяснения. Его определение «Суть разработки программного обеспечения по Agile» – одно из лучших: