Искусство Agile-разработки. Теория и практика гибкой разработки ПО

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

Особая благодарность тем рецензентам, которые пошли еще дальше, прочитав и прокомментировав почти каждую из частей книги: Басу Водде, Биллу Уэйку, Кену Пью, Мартину Фаулеру и Томасу Джей Оуэнсу.

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

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

От издательства

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

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

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

I Улучшая гибкость

Глава 1. Что есть Agile

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

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

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

Происхождение Agile

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

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

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

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

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