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

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

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

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

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

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

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

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

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

Двадцать лет назад локомотив 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

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

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

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

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

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

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

Суть Agile

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

Agile-разработка является скорее адаптивной, чем предиктивной; ориентированной скорее на людей, чем на процессы^[6].

Адаптивность вместо предиктивности

Помните, в CHAOS Report утверждалось, что всего одна шестая часть проектов в области программного обеспечения успешна? В отчете успешность определена очень специфическим образом:

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

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

 неуспешный – проект отменен в какой-либо момент в течение цикла разработки.

Эти определения прекрасно иллюстрируют предиктивный тип мышления. Они все говорят о соответствии запланированному. Если вы сделали то, что собирались сделать, то вы успешны. А если нет, то неуспешны! Все просто.

На первый взгляд, это разумно. Но посмотрим повнимательнее. Тут чего-то не хватает. Райан Нельсон писал в журнале CIO Magazine [Nelson2006]:

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

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

Взгляните еще раз на Манифест (см. рис. 1.1 и 1.2). Найдите пару минут, чтобы вдумчиво изучить ценности и принципы Agile. Сколько из них относятся к поставкам ценного программного обеспечения и адаптации к полученной обратной связи?

Ориентированность на людей, а не на процессы

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

Agile заявляет, что люди – главный фактор успеха в разработке программного обеспечения. Не только их знания и навыки, но и все аспекты человеческой природы. Насколько хорошо сработались члены команды. Насколько часто они отвлекаются. Насколько комфортно и безопасно для них высказывать свое мнение. Насколько они увлечены своей работой.

У Agile-команд тоже есть процессы (у любой команды они есть, пусть и неявные), но они находятся на службе у человека, а не наоборот. И Agile-команды сами отвечают за свои процессы. Желая улучшить методы работы, люди меняют процессы.

Посмотрите на Манифест еще раз (см. рис. 1.1 и 1.2). Какие ценности и принципы имеют отношение к концепции «люди на первом месте»?

Почему Agile победил

В течение первых десяти лет после появления Манифеста Agile столкнулся с небывалой критикой. Его называли «недисциплинированным». Говорили, что он никогда не будет работать. Следующие десять лет критики молчали. Agile был уже везде, по крайней мере это название. Тяжеловесные водопадные методы практически умерли. Молодые программисты вообще не верили в то, что кто-то когда-то мог работать таким образом.

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