Если вы член команды или менеджер, заинтересованный в том, чтобы внедрить Agile в свою компанию или улучшить уже работающую в ней практику Agile, то прочитайте всю книгу целиком. Часть I поможет вам понять, как представить идеи Agile коллегам. Остальной материал книги поможет разобраться, как воплотить Agile в жизнь.
Если вы часть Agile-команды и просто хотите получить знания, которые позволят выполнять вашу работу, то можете сосредоточиться на практиках, изложенных в частях II и III. Начните с главы 1, чтобы получить общую картину, затем перейдите к тем практикам, которые использует ваша команда.
Если вы не являетесь частью Agile-команды, но работаете с одной из них, то посоветуйтесь с ними, что почитать. Продакт-менеджеры, владельцы продукта, дизайнеры могут начать с главы 8 и раздела «Цель» главы 7. Сотрудникам отделов безопасности и отделов эксплуатации рекомендую разделы «Сборка для эксплуатации» главы 15, «Обнаружение слепых зон» и «Анализ инцидентов» главы 16. Тестировщики, ознакомьтесь с главой 16.
Если вам просто любопытно узнать об Agile, то начните с главы 1. После этого ознакомьтесь с частями II–IV. Начните с наиболее интересных для вас практик. Можете читать их в любом порядке.
О приглашенных авторах
Эта книга создана в соавторстве с несколькими выдающимися людьми. Гитте Клитгаард написала раздел «Безопасность» главы 7, профессионально осветив тему психологической безопасности. Диана Ларсен написала разделы «Динамики команды» и «Устранение препятствий» главы 11, поделившись своим многолетним опытом организационного и командного развития. Шейн Уорден, мой соавтор первого издания, не смог написать новый материал для второго, но остался надежным и ценным советчиком, и наша работа над первым изданием легла в основу этой книги.
Гитте Клитгаард
Гитте Клитгаард – Agile-коуч, инструктор и наставник, специализирующаяся на помощи организациям в формировании психологической безопасности и ответственности. Гитте сразу переходит к сути дела и помогает людям стать самими собой и таким образом достичь успеха.
Ее вклад в сообщество включает организацию встреч для тренеров и выступления на конференциях, где она поднимает темы психического здоровья и психологической безопасности и делает их доступными для общего понимания. Гитте создает безопасную и уважительную атмосферу на работе и за ее пределами. Она умеет слушать и вовлекать в обсуждение более тихие голоса и малые сообщества.
В свободное время Гитте собирает LEGO, коллекционирует фигурки Йоды и поддерживает связь с друзьями со всего земного шара, многих из которых она считает своей второй семьей.
Гитте является владельцем Native Wired и руководила преобразованиями в таких компаниях, как LEGO, Spotify и Mentimeter.
Диана Ларсен
Более 20 лет Диана Ларсен вносила свой вклад в формирование основ и расширение идей Agile, а также в практику создания и развития квалифицированных команд. Диана – соавтор книг Agile Retrospectives[2 - Дерби Э., Ларсен Д. Agile ретроспектива. Как превратить хорошую команду в великую.], Liftoff, 2nd ed., Five Rules for Accelerated Learning и электронной книги The Agile Fluency Model: A Brief Guide to Success with Agile; кроме того, сейчас пишет две новые книги. Будучи главным коучем, консультантом, координатором, спикером и наставником, она продолжает вносить свой вклад и соответствует своему званию в проекте Agile Fluency – «Главное связующее звено» (Chief Connector). Живет в Портленде, на верхнем левом побережье США.
Шейн Уорден
Шейн Уорден – руководитель инженерно-технической службы и писатель, в частности, соавтор первого издания этой книги, а также книги Masterminds of Programming[3 - Бьянкуцци Ф., Уорден Ш. Пионеры программирования: диалоги с создателями наиболее популярных языков программирования.]. В свободное от работы время он помогает находить животным хорошие дома.
Условные обозначения
В книге используются следующие условные обозначения.
Аудитория
В этих блоках указывается целевая аудитория каждой практики Agile.
См. также
В этих блоках приводятся связанные практики.
Курсив
Курсивом выделены новые термины и важные понятия.
Шрифт одной ширины
Используется для текста программ, а также внутри абзацев для обозначения таких элементов, как переменные и функции, базы данных, типы данных, переменные среды, операторы и ключевые слова, имена файлов и их расширений.
Жирный шрифт одной ширины
Показывает добавленный код в работающих примерах кода.
Перечеркнутый шрифт одной ширины
Показывает удаленный код в работающих примерах кода.
Шрифт без засечек
Используется для обозначения URL, адресов электронной почты, названий кнопок, каталогов.
Использование примеров кода
Дополнительные материалы доступны для скачивания по ссылке https://www.jamesshore.com/v2/books/aoad2.
Пожалуйста, напишите по адресу электронной почты bookquestions@oreilly.com, если у вас технический вопрос или проблема с использованием материалов.
Эта книга призвана помочь в решении ваших задач. В общем случае все примеры кода из книги вы можете использовать в своих программах и в документации. Вам не нужно обращаться в издательство за разрешением, если вы не собираетесь воспроизводить существенные части кода, или если вы разрабатываете программу и используете в ней несколько фрагментов кода из книги, или если будете цитировать эту книгу либо примеры из нее, отвечая на вопросы. Вам потребуется разрешение от издательства O’Reilly, если вы хотите продавать или распространять примеры из книги либо хотите включить существенные объемы программного кода из книги в документацию вашего продукта.
Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов, издательства и ISBN.
Получить разрешение на использование значительных объемов программного кода примеров из этой книги можно по адресу permissions@oreilly.com.
Благодарности
Эта книга вдохновлена бессчетным количеством источников. На протяжении всей книги я поблагодарил скольких мог, но наверняка забыл кого-то. (Пожалуйста, примите мои извинения.) Я хочу выразить особую признательность Кенту Беку, Рону Джеффрису и Уорду Каннингему за то, что они создали экстремальное программирование, с которого я начал мое Agile-путешествие. Алистер Коберн и его круглый стол по программному обеспечению, как и бурные споры и обсуждения Вики-страниц C2 Уорда Каннингема, помогли определить направление в начале этого пути. Благодарю также Диану Ларсен, с которой я работаю много лет – ее точка зрения так хорошо уравновешивает мою. И конечно, Мартина Фаулера, чей вдумчивый стиль письма много лет вдохновляет меня.
Поддержка этого издания со стороны O’Reilly была просто исключительной. Я выражаю огромную благодарность Гэри О’Брайену, моему редактору, обеспечивавшему постоянную обратную связь и поддержку. Благодарю также Мелиссу Даффилд, которая помогла сделать так, чтобы книга пользовалась успехом; Райана Шоу, убедившего меня в том, что пришло время для второго издания; Дебору Бейкер, подготовившую издание ранних выпусков книги; Сюзанну Хьюстон, которая позаботилась о том, чтобы люди узнали о книге; Ника Адамса и команду Tools издательства O’Reilly, которые выстроили производственный процесс и успешно разобрались с моими запутанными и придирчивыми требованиями к оформлению; Кристофера Фоучера, который руководил превращением «сырой рукописи» в «законченную книгу»; Тонью Трибулу и Стефани Инглиш, исправивших мои грамматические чудачества; Кейт Дулли, превратившую мои наброски от руки в понятные рисунки.
Что касается обратной связи, особую признательность выражаю моим рецензентам. Рецензирование было открытым, и мы получили более 700 электронных писем от десятков людей. Практически каждое было содержательным и полезным и в результате улучшило книгу. Кроме того, благодарю тех людей, которые ответили на мои прямые запросы на рецензию. Спасибо всем: Адриану Саттону, Энтони Уильямсу, Ави Кесснер, Басу Водде, Бенджамину Мускалла, Биллу Уэйку, Брэду Эпплтону, Си Кейту Рэйю, Си Джею Джеймсону, Кристиану Дювану, Дэйвиду Пулу, Диане Ларсен, Диего Фонтдевиле, Эмили Бач, Эрику Петерсону, «Эвану M.», Францу Амадору, Джорджу Динвидди, Гойко Аджичу, Джейсону Йипу, Джеффу Григгу, Джеффу Паттону, Джеффри Палермо, Йохану Алуддену, Кену Пью, Кришне Кумару, Лиз Кеог, Луизе Нуньес, Марсело Лопесу, Маркусу Гертнеру, Мартину Фаулеру, Михалу Свободе, Николасу Паесу, Полу Стивенсону, Петеру Гравесу, Реувену Ягелю, Рикардо Майерхоферу, Рону Джеффрису, Рону Квартелу, Саре Хоран Ван Треесе, Стиву Бементу, Томасу Джей Оуэнсу, Тодду Литтлу и Уорду Каннингему.
Особая благодарность тем рецензентам, которые пошли еще дальше, прочитав и прокомментировав почти каждую из частей книги: Басу Водде, Биллу Уэйку, Кену Пью, Мартину Фаулеру и Томасу Джей Оуэнсу.
Процесс открытого рецензирования пошел на пользу и первому изданию, и все его преимущества, в свою очередь, отразились и на этой книге. Спасибо Адриану Ховарду, Адриану Саттону, Энн Баркомб, Энди Лестеру, Энтони Уильямсу, Басу Водде, Биллу Капуто, Бобу Коррику, Брэду Эпплтону, Крису Уилеру, Кларку Чингу, Дади Ингольфссону, Диане Ларсен, Эрику Петерсену, Джорджу Динвидди, Илье Прейсу, Джейсону Йипу, Джеффу Олферту, Джеффри Палермо, Джонатану Кларке, Кейт Рэй, Кевину Рутерфорду, Ким Грэсман, Лизе Криспин, Марку Уайтэ, Николасу Эвансу, Филиппе Антрасу, Рэнди Коулмэн, Роберту Шмитту, Рону Джеффрису, Шейну Доуну, Тиму Хоутону и Тони Бирну за их множественные комментарии и Брайану Марику, Кену Пью и Марку Стрейбеку за их замечания по готовому черновику.
И наконец, еще раз спасибо моей жене Ниру. В этот раз ты знала, на что шла, и все же без колебаний поддерживала меня. Без тебя я бы не смог это сделать.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу 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 - Источником появления подхода Waterfall часто ошибочно считают статью Уинстона Ройса, написанную в 1970 году. Однако применение фазового подхода восходит еще к 1950-м, а статья Ройса не пользовалась широкой известностью до конца 1980-х, когда к ней стали прибегать для описания того, что люди уже давно делали [Bossavit2013, chapt. 7].]. Если вам это кажется похожим на нелепое пугало – считайте, что вам повезло. Не все команды применяли в 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 - Алистер Кокберн, цитата Джима Хайсмита в [Highsmith2001]. Полная цитата: «Лично я не ожидал… что эта конкретная группа приверженцев различных гибких методик сможет договориться о чем-либо по существу… Что касается меня, я в восторге от окончательной формулировки [Манифеста]. Я был удивлен, что и другие оказались так же довольны окончательной формулировкой. Таким образом, мы все же смогли договориться о чем-то по существу».].
