Искусство Agile-разработки
Искусство Agile-разработки
Искусство Agile-разработки
ВТОРОЕ ИЗДАНИЕ
Джеймс Шор
Диана Ларсен, Гитте Клитгаард, Шэйн Уорден
2024
ББК 32.973-018
УДК 004.4:005.8
Ш79
Права на издание получены по соглашению с O’Reilly. Все права защищены. Никакая часть данной книги не может
быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надеж-
ные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гаран-
тировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки,
связанные с использованием книги. В книге возможны упоминания организаций, деятельность которых запрещена
на территории Российской Федерации, таких как Meta Platforms Inc., Facebook, Instagram и др. Издательство не
несет ответственности за доступность материалов, ссылки на которые вы можете найти в этой книге. На момент
подготовки книги к изданию все ссылки на интернет-ресурсы были действующими.
ISBN 978-1492080695 англ. Authorized Russian translation of the English edition of The Art of Agile
Development 2E, ISBN 9781492080695 © 2022 James Shore and Big Blue
Marble LLC.
This translation is published and sold by permission of O’Reilly Media, Inc.,
which owns or controls all rights to publish and sell the same.
ISBN 978-5-4461-2386-5 © Перевод на русский язык ООО «Прогресс книга», 2023
© Издание на русском языке, оформление ООО «Прогресс книга», 2023
© Серия «Бестселлеры O’Reilly», 2023
Оглавление
https://t.me/it_boooks/2
Отзывы.........................................................................................................................................................................21
Предисловие.............................................................................................................................................................24
Введение.....................................................................................................................................................................26
Для прагматиков..............................................................................................................................................27
Что нового во втором издании..................................................................................................................27
Для кого предназначена книга..................................................................................................................28
О приглашенных авторах.............................................................................................................................29
Гитте Клитгаард..........................................................................................................................................29
Диана Ларсен..............................................................................................................................................30
Шейн Уорден...............................................................................................................................................30
Условные обозначения.................................................................................................................................30
Использование примеров кода................................................................................................................31
Благодарности...................................................................................................................................................31
От издательства................................................................................................................................................32
Контекст............................................................................................................................................................. 163
Запишите контекст в устав................................................................................................................. 163
Обновляйте контекст........................................................................................................................... 168
Вопросы..................................................................................................................................................... 168
Предварительные требования........................................................................................................ 168
Показатели................................................................................................................................................ 168
Альтернативы и эксперименты....................................................................................................... 169
Согласование.................................................................................................................................................. 169
Запишите договоренности в устав................................................................................................ 170
Обновляйте соглашения..................................................................................................................... 174
Придерживайтесь договоренностей............................................................................................ 175
Вопросы..................................................................................................................................................... 177
Предварительные требования........................................................................................................ 177
Показатели................................................................................................................................................ 177
Альтернативы и эксперименты....................................................................................................... 178
Энергичная работа....................................................................................................................................... 178
Как быть энергичным........................................................................................................................... 179
Поддерживайте энергичную работу............................................................................................. 179
Делайте перерывы................................................................................................................................ 181
Вопросы..................................................................................................................................................... 181
Предварительные требования........................................................................................................ 182
Показатели................................................................................................................................................ 182
Альтернативы и эксперименты....................................................................................................... 182
Литература для дополнительного чтения.................................................................................. 183
Показатели................................................................................................................................................ 245
Альтернативы и эксперименты....................................................................................................... 245
Инкрементные требования...................................................................................................................... 246
Изменяемый документ с требованиями..................................................................................... 246
Когда эксперты не являются частью команды......................................................................... 247
Работайте инкрементно...................................................................................................................... 247
Документация.......................................................................................................................................... 249
Вопросы..................................................................................................................................................... 251
Предварительные требования........................................................................................................ 252
Показатели................................................................................................................................................ 252
Альтернативы и эксперименты....................................................................................................... 253
Литература для дополнительного чтения.................................................................................. 253
Показатели................................................................................................................................................ 430
Альтернативы и эксперименты....................................................................................................... 430
Литература для дополнительного чтения.................................................................................. 431
Единый язык.................................................................................................................................................... 431
Дилемма экспертных знаний в предметной области........................................................... 431
Говорить на одном языке................................................................................................................... 432
Как создать единый язык................................................................................................................... 432
Вопросы..................................................................................................................................................... 435
Предварительные требования........................................................................................................ 435
Показатели................................................................................................................................................ 436
Альтернативы и эксперименты....................................................................................................... 436
Литература для дополнительного чтения.................................................................................. 436
Вопросы..................................................................................................................................................... 547
Предварительные требования........................................................................................................ 547
Показатели................................................................................................................................................ 548
Альтернативы и эксперименты....................................................................................................... 548
Литература для дополнительного чтения.................................................................................. 548
Флаги функций............................................................................................................................................... 549
Замковый камень .................................................................................................................................. 549
Флаги функций........................................................................................................................................ 550
Предварительные требования........................................................................................................ 552
Показатели................................................................................................................................................ 553
Альтернативы и эксперименты....................................................................................................... 553
Литература для дополнительного чтения.................................................................................. 553
Непрерывное развертывание................................................................................................................ 554
Как использовать непрерывное развертывание.................................................................... 554
Обнаружение сбоев развертывания............................................................................................ 555
Устранение сбоев развертывания................................................................................................. 555
Инкрементные релизы........................................................................................................................ 557
Миграция данных ................................................................................................................................. 558
Предварительные требования........................................................................................................ 559
Показатели................................................................................................................................................ 559
Альтернативы и эксперименты....................................................................................................... 559
Литература для дополнительного чтения.................................................................................. 560
Эволюционная системная архитектура.............................................................................................. 560
Вам действительно это понадобится? ......................................................................................... 561
Нацеленность на простоту................................................................................................................ 562
Контроль сложности ........................................................................................................................... 563
Рефакторинг системной архитектуры ........................................................................................ 565
Предварительные требования........................................................................................................ 568
Показатели................................................................................................................................................ 569
Альтернативы и эксперименты....................................................................................................... 569
Литература для дополнительного чтения.................................................................................. 569
Библиография........................................................................................................................................................ 615
Об авторе................................................................................................................................................................. 623
Отзывы
В этой книге есть все: от кода до поставки готового продукта. Заработанные деся-
тилетиями тяжелого труда знания превратились в легкочитаемый и доступный для
восприятия материал — обязательный к прочтению для всех, кто работает с командой
разработчиков программного обеспечения или в ней.
Ави Кесснер, инженер, Forter
Первое издание этой книги заворожило меня до такой степени, что до сих пор стоит
на моей книжной полке в качестве справочника. Второе издание сохраняет шарм
своего предшественника и содержит еще больше знаний, накопленных за последнее
десятилетие.
Бенджамин Мускалла,
старший инженер-программист, GitHub
Тысячи книг об Agile. Какую из них прочитать? Я советую вам эту. Джеймс рабо-
тает с Agile с первых дней его появления и знает свое дело. Книга разбирает весь
бессмысленный мусор в нашей отрасли, окружающий это понятие, и предлагает
тщательно выверенный, целостный подход. Этот подход не будет быстрым и лег-
ким, но он того стоит. Мне понравилась книга «Искусство Agile-разработки». Это
книга с характером!
Бас Водде, соавтор LeSS
Двадцать лет назад мне повезло найти свое место в компании Thoughtworks,
где наши команды используют такие навыки, чтобы создавать для наших клиентов
новые программные продукты и заменять ими устаревшие. Как и Джеймс, мы обна-
ружили, что техники экстремального программирования служили надежной основой
для нашей работы, и мы весьма успешно применяли их в течение последних двух
десятилетий. Поэтому я очень рад, что Джеймс переписал свою книгу, добавив в нее
опыт еще одного десятилетия своей работы в роли коуча. В результате получился
прочный фундамент для изучения тех навыков, которые нам так помогли. Как и все
действительно стоящее, обучение займет время, и на вашем пути будут разочаро-
вания. Но этот путеводитель может вам помочь — избавив от безрезультативных
церемоний и приведя к источнику силы, которую мы с Джеймсом почувствовали,
впервые применив эти методы много лет назад.
Мартин Фаулер, Chief Scientist, Thoughtworks
Введение
ДЛЯ ПРАГМАТИКОВ
А что, если вы не хотите овладевать так называемым «искусством»? Что, если вы
хотите просто разрабатывать хорошее ПО?
Не волнуйтесь. Эта книга и для вас тоже. На основе моего многолетнего опыта
Agile-разработки я создал единый, четко определенный, комплексный подход.
Это позволяет мне использовать простой язык. Я даю много практических сове-
тов. Я честно пишу, когда мой подход не будет работать и какие альтернативы можно
рассмотреть в таком случае. Глава 2 поможет вам начать.
Есть и обратная сторона обсуждения только одного подхода: ни один под-
ход не применим ко всем случаям. Мой совет может быть непригоден для вашей
команды или организации. Прочтите главы 4 и 5, чтобы понять, на каких общих
условиях возможен успех, и изучите подраздел «Предварительные требования»
каждой практики.
Не стоит сразу думать, что какая-либо конкретная практика вам не подходит.
Некоторые практики, описанные в этой книге, противоречат здравому смыслу или
просто не кажутся интересными. Большинство из них лучше всего работают в со-
четании с другими. Если можете, то попробуйте применять практики, как написано,
в течение нескольких месяцев, получите реальный опыт их работы в ваших условиях
и потом измените их.
Я применяю эти идеи в реальной работе уже более 20 лет. В правильной среде
они действительно работают. Agile оказывается более увлекательным и успешным,
чем любой другой подход к разработке программного обеспечения, который я про-
бовал. Присоединяйтесь.
1
Agile Fluency — зарегистрированный товарный знак Agile Fluency Project LLC.
Введение 29
О ПРИГЛАШЕННЫХ АВТОРАХ
Эта книга создана в соавторстве с несколькими выдающимися людьми. Гитте
Клитгаард написала раздел «Безопасность» главы 7, профессионально осветив
тему психологической безопасности. Диана Ларсен написала разделы «Динамики
команды» и «Устранение препятствий» главы 11, поделившись своим многолетним
опытом организационного и командного развития. Шейн Уорден, мой соавтор
первого издания, не смог написать новый материал для второго, но остался на-
дежным и ценным советчиком, и наша работа над первым изданием легла в основу
этой книги.
Гитте Клитгаард
Гитте Клитгаард — Agile-коуч, инструктор и наставник, специализирующаяся на
помощи организациям в формировании психологической безопасности и ответ-
ственности. Гитте сразу переходит к сути дела и помогает людям стать самими собой
и таким образом достичь успеха.
Ее вклад в сообщество включает организацию встреч для тренеров и выступления
на конференциях, где она поднимает темы психического здоровья и психологической
безопасности и делает их доступными для общего понимания. Гитте создает без-
опасную и уважительную атмосферу на работе и за ее пределами. Она умеет слушать
и вовлекать в обсуждение более тихие голоса и малые сообщества.
В свободное время Гитте собирает LEGO, коллекционирует фигурки Йоды
и поддерживает связь с друзьями со всего земного шара, многих из которых она
считает своей второй семьей.
Гитте является владельцем Native Wired и руководила преобразованиями в таких
компаниях, как LEGO, Spotify и Mentimeter.
30 Введение
Диана Ларсен
Более 20 лет Диана Ларсен вносила свой вклад в формирование основ и расширение
идей Agile, а также в практику создания и развития квалифицированных команд.
Диана — соавтор книг Agile Retrospectives1, 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 Programming2.
В свободное от работы время он помогает находить животным хорошие дома.
УСЛОВНЫЕ ОБОЗНАЧЕНИЯ
В книге используются следующие условные
обозначения. Аудитория
Курсив В этих блоках указывается целевая
Курсивом выделены новые термины аудитория каждой практики Agile.
и важные понятия.
Шрифт одной ширины
Используется для текста программ, а так- В блоках-выносках выделены
же внутри абзацев для обозначения таких важные концепции.
элементов, как переменные и функции, базы
данных, типы данных, переменные среды,
операторы и ключевые слова, имена файлов
и их расширений. См. также
Жирный шрифт одной ширины
В этих блоках приводятся связанные
Показывает добавленный код в работа- практики.
ющих примерах кода.
Перечеркнутый шрифт одной ширины
Показывает удаленный код в работающих примерах кода.
Шрифт без засечек
Используется для обозначения URL, адресов электронной почты, названий
кнопок, каталогов.
1
Дерби Э., Ларсен Д. Agile ретроспектива. Как превратить хорошую команду в великую.
2
Бьянкуцци Ф., Уорден Ш. Пионеры программирования: диалоги с создателями наиболее попу-
лярных языков программирования.
Введение 31
БЛАГОДАРНОСТИ
Эта книга вдохновлена бессчетным количеством источников. На протяжении всей
книги я поблагодарил скольких мог, но наверняка забыл кого-то. (Пожалуйста, при-
мите мои извинения.) Я хочу выразить особую признательность Кенту Беку, Рону
Джеффрису и Уорду Каннингему за то, что они создали экстремальное программиро-
вание, с которого я начал мое Agile-путешествие. Алистер Коберн и его круглый стол
по программному обеспечению, как и бурные споры и обсуждения Вики-страниц C2
Уорда Каннингема, помогли определить направление в начале этого пути. Благодарю
также Диану Ларсен, с которой я работаю много лет — ее точка зрения так хорошо
уравновешивает мою. И конечно, Мартина Фаулера, чей вдумчивый стиль письма
много лет вдохновляет меня.
Поддержка этого издания со стороны O’Reilly была просто исключительной. Я вы-
ражаю огромную благодарность Гэри О’Брайену, моему редактору, обеспечивавшему
постоянную обратную связь и поддержку. Благодарю также Мелиссу Даффилд, кото-
рая помогла сделать так, чтобы книга пользовалась успехом; Райана Шоу, убедившего
меня в том, что пришло время для второго издания; Дебору Бейкер, подготовившую
издание ранних выпусков книги; Сюзанну Хьюстон, которая позаботилась о том,
чтобы люди узнали о книге; Ника Адамса и команду Tools издательства O’Reilly,
которые выстроили производственный процесс и успешно разобрались с моими за-
путанными и придирчивыми требованиями к оформлению; Кристофера Фоучера,
который руководил превращением «сырой рукописи» в «законченную книгу»; Тонью
Трибулу и Стефани Инглиш, исправивших мои грамматические чудачества; Кейт
Дулли, превратившую мои наброски от руки в понятные рисунки.
32 Введение
ОТ ИЗДАТЕЛЬСТВА
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected]
(издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На сайте издательства www.piter.com вы найдете подробную информацию о на-
ших книгах.
I
УЛУЧШАЯ ГИБКОСТЬ
ГЛАВА 1
Что есть Agile
https://t.me/it_boooks/2
ПРОИСХОЖДЕНИЕ AGILE
В 1990-е считалось, что разработка ПО находится в кризисе. Это явление так и на-
зывалось: «Кризис программного обеспечения». Проекты разработки выходили за
рамки бюджетов, задерживались, не отвечали требованиям, и (согласно часто ци-
тируемому и зловеще именуемому «Отчету о Хаосе» (CHAOS Report)) почти треть
их была полностью отменена [Standish1994].
Agile не был ответом на этот кризис. Отнюдь нет. Agile стал ответным подходом.
Чтобы взять под контроль разработку ПО, большие организации придумали
высокодетализированный процесс, точно определявший, как ПО должно создаваться.
Все жестко контролировалось, чтобы исключить возможность ошибки. (Во всяком
случае, в теории.)
Сначала бизнес-аналитики должны были опрашивать стейкхолдеров (stakeholders,
заинтересованные стороны) и документировать системные требования. Далее ар-
хитекторы программного обеспечения должны были изучить документы с требо-
ваниями и создать подробную проектную документацию, определяющую каждый
компонент системы и их взаимосвязь друг с другом. Затем программисты должны
были конвертировать проектную документацию в код. В некоторых организациях
такое выполнение механического перевода считалось низкоквалифицированной
работой.
Тем временем руководители тестирования должны были создавать планы тестиро-
вания, используя те же документы, и когда кодирование завершалось, бесчисленные
специалисты по обеспечению качества должны были вручную выполнять эти планы,
фиксируя отклонения как дефекты. По завершении каждой фазы все должно было
быть задокументировано, проверено и подписано.
Глава 1. Что есть Agile 35
РОЖДЕННЫЙ ИЗ КРИЗИСА
Крупные компании расписывали свои процессы в мельчайших деталях. Роли, от-
ветственности, шаблоны документов, языки моделирования, советы по контролю
за изменениями… каждый аспект разработки строго регламентировался и контро-
лировался. Если проект заканчивался провалом (а согласно 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). В течение
1
Источником появления подхода Waterfall часто ошибочно считают статью Уинстона Ройса,
написанную в 1970 году. Однако применение фазового подхода восходит еще к 1950-м, а статья
Ройса не пользовалась широкой известностью до конца 1980-х, когда к ней стали прибегать для
описания того, что люди уже давно делали [Bossavit2013, chapt. 7].
36 Часть I. Улучшая гибкость
Это стало Манифестом Agile, который изменил мир. «Таким образом, — продол-
жил Алистер, — они в конце концов все же смогли договориться о чем-то по
существу»1.
Однако единого метода Agile не было. Его
никогда не было и никогда не будет. Agile Если ваши команды воплощают
подразумевает три составляющие: название, философию Agile, то вы — Agile.
ценности и принципы. И все. Это не что-то, Если не воплощают — то нет.
что можно делать. Это философия. Это спо-
соб мышления, посвященный разработке программного обеспечения. Невозможно
«использовать» Agile или «делать» Agile… вы только можете быть Agile. Или не быть.
Если ваши команды воплощают философию Agile, то вы — Agile. Если не воплоща-
ют — то нет.
СУТЬ AGILE
Мартин Фаулер сделал карьеру, превращая сложные вопросы о программировании
в тщательно продуманные, беспристрастно точные объяснения. Его определение
«Суть разработки программного обеспечения по Agile» — одно из лучших:
Мартин Фаулер
1
Алистер Кокберн, цитата Джима Хайсмита в [Highsmith2001]. Полная цитата: «Лично я не ожи-
дал… что эта конкретная группа приверженцев различных гибких методик сможет договориться
о чем-либо по существу… Что касается меня, я в восторге от окончательной формулировки [Мани-
феста]. Я был удивлен, что и другие оказались так же довольны окончательной формулировкой.
Таким образом, мы все же смогли договориться о чем-то по существу».
2
Фаулер выражал эту идею множество раз в течение нескольких лет. Оригинальную версию можно
найти в статье [Fowler2000].
38 Часть I. Улучшая гибкость
Посмотрите на Манифест еще раз (см. рис. 1.1 и 1.2). Какие ценности и принципы
имеют отношение к концепции «люди на первом месте»?
1
Источники: Mueller’s February 3, 2005, testimony to Congress (https://oreil.ly/GlQSa) и Inspector
General Glenn Fine’s May 2, 2005, testimony to Congress (https://oig.justice.gov/node/672).
Глава 1. Что есть Agile 41
Карго-культы
Корни этой истории уходят в 1940-е1, когда американские войска высадились
на далеком острове. Местные жители никогда не встречались с современной
цивилизацией, и люди и материалы, привезенные союзными войсками, изумили
аборигенов. Они наблюдали, как солдаты строили взлетно-посадочную полосу
и башню управления воздушным трафиком, надевали наушники и вызывали
с небес на землю больших металлических птиц, нагруженных ценным грузом
(карго). Когда птицы приземлялись, часть груза распределялась между всеми
островитянами, благодаря чему те жили в благополучии и комфорте.
Однажды войска покинули остров, и большие металлические птицы перестали
прилетать. Успевшие привыкнуть к комфорту островитяне сплели из бамбука
собственную взлетно-посадочную полосу. Они построили высокую платформу,
посадили на нее своего вождя и надели ему на голову кокосы, которым придали
форму наушников. Но как бы ни старались островитяне, большие металлические
птицы так больше никогда и не вернулись.
1
Впервые я прочел эту историю в трудах Ричарда Фейнмана, где в числе прочего была пред-
ставлена его речь на церемонии вручения дипломов в Калтехе в 1974 году [Feynman1974].
История основана на реальных ритуалах, практиковавшихся в Меланезии после Второй
мировой войны.
Глава 1. Что есть Agile 43
https://t.me/it_boooks/2
ПРАКТИКА AGILE
У каждой команды есть свой подход к работе — процессы, или методы, которым
она следует, зачастую формально не задокументированы. Эти методы отра
жают лежащую в их основе философию разработки программного обеспечения,
хотя она не всегда бывает четко сформулирована и не обязательно последова-
тельна.
Чтобы быть Agile, вам нужно изменить
свои методы так, чтобы они стали отражать Чтобы быть Agile, вам нужно
философию Agile. Это одновременно и про- изменить свои методы так, чтобы они
ще, и сложнее, чем кажется. Это просто, по- стали отражать философию Agile.
скольку в большинстве случаев вы можете
начать с одного из готовых Agile-методов, например, представленного в этой книге.
И это сложно, так как вам понадобится перестроить свой стиль работы, а это под-
разумевает изменение многих привычек.
Сообщество Agile называет эти привычки практиками. Им посвящена значитель-
ная часть данной книги. Под практиками подразумеваются сессии планирования,
автоматизированные сборки и демо для стейкхолдеров. Большинство этих практик
существует десятилетиями. В методах Agile они скомбинированы уникальным обра-
зом — выделяются компоненты, поддерживающие философию Agile, отбрасываются
остальные и добавляется ряд новых идей. В результате получается экономичный,
эффективный, взаимоусиливающий комплект.
Практики Agile часто имеют двойное и тройное назначение, решая одновременно
множество проблем и поддерживая друг друга разумными и неожиданными спосо-
бами. Вам не удастся по-настоящему понять, как работает метод Agile, до тех пор,
пока вы некоторое время не понаблюдаете за ним в действии.
Таким образом, несмотря на соблазн сразу настроить метод Agile под себя, лучше
все же начать со стандартного, «книжного» подхода. Идея удалить наименее знакомые
Глава 2. Как быть Agile 45
практики выглядит заманчиво, но именно они и будут вам нужны больше всего, если
вы действительно собираетесь перейти на Agile. Именно с этими практиками связаны
главные изменения в философии.
1
Эта последовательность действий следует из рассуждений Алистера Кокберна о сюхари
(Shu-Ha-Ri).
46 Часть I. Улучшая гибкость
С ЧЕГО НАЧАТЬ?
Ваши первые шаги зависят от того, чего вы хотите. Вы присоединяетесь к действу-
ющей команде Agile, внедряете Agile в работу одной или нескольких команд или
стремитесь улучшить свою команду Agile?
Введение Agile
Если вы помогаете своей организации сформировать Agile-команды или только хо-
тите убедить ее сделать это, то оставшиеся главы части I помогут вам начать. Чтобы
структурировать процесс, используйте чек-лист, представленный ниже.
Глава 2. Как быть Agile 47
Совершенствование
действующих Agile-команд
Если у вас уже есть действующие Agile-команды и вы хотите улучшить их работу, то
ваш подход будет зависеть от того, какие именно улучшения вам нужны.
Если вы заинтересованы в небольшой регулировке уже работающих процессов
вашей команды, то перейдите к частям II–IV и прочитайте об интересующих вас
практиках. Если вы хотите более масштабных улучшений, то процесс будет таким же,
как и при внедрении Agile в команду, за исключением того, что вам понадобится со-
средочиться на конкретных элементах, требующих изменений.
В качестве руководства используйте чек-листы из предыдущего подраздела
«Внедрение Agile» данной главы.
Если Agile не срабатывает в вашей организации, то ознакомьтесь с врезкой «Ру-
ководство по устранению неполадок» в главе 4.
48 Часть I. Улучшая гибкость
Нет смысла использовать Agile ради него самого. Задайте себе два вопроса.
1. Поможет ли нам Agile стать более успешными?
2. Чего нам будет стоить достижение этого успеха?
Ответив на эти вопросы, вы поймете, нужен ли вам Agile.
Каждый уровень связан с набором преимуществ. Чтобы обрести их, команде не-
обходимо свободно (уверенно) владеть навыками, относящимися к этому уровню.
Считается, что команда свободно владеет навыками, если способна применять все
навыки этого уровня, не прикладывая сознательных усилий.
ПРИМЕЧАНИЕ
Несмотря на то что на рис. 3.1 представлен прямой путь от одного уровня к друго-
му, в реальности все более беспорядочно. Команды могут достигать уверенного
владения навыками на любом уровне, в любом порядке, хотя продвижение,
показанное на рис. 3.1, типично.
1
Временные рамки, приведенные в этой главе, приблизительны и основаны на моем опыте. Ваш
опыт может быть другим.
Глава 3. Выберите свою гибкость 53
Поставка
zz Основные преимущества: мало дефектов и высокая производительность,
техническая долговечность.
zz Инвестиции: навыки разработки, слияние тестирования и эксплуатации.
zz Примерные сроки: падение производительности на 2–6 месяцев, достижение
владения навыками в течение 3–24 месяцев.
Оптимизация
zz Основные преимущества: повышение уровня ценности релизов и улучшенные
продуктовые решения.
zz Инвестиции: встроенное управление продуктом, команда несет ответствен-
ность за бюджет и планы.
zz Примерные сроки: падение производительности на 1–3 месяца, достижение
владения навыками в течение 3–9 месяцев.
Как мы видим из предыдущей главы, для того чтобы команды получили все пре-
имущества Agile, ваша организация должна приобщиться к его основополагающей
философии. Не просто тратить деньги (это сравнительно легко), а выполнять реаль-
ные, осмысленные изменения в организационных структурах, системах и рабочих
привычках...
Если это выглядит как очень трудозатратное дело… что ж, так и есть. Неужели
эти инвестиции действительно настолько важны?
Да, действительно настолько.
Инвестировать в Agile важно, поскольку
вы инвестируете в изменение границ, ко- По большей части команды
торые вас сдерживают. По большей части сдерживают не процессы, которым
команды сдерживают не процессы, которым они следуют, а ограничения,
они следуют, а ограничения, в которых они в которых они находятся.
находятся. Попробуйте делать эти инвести-
ции и не следовать практикам, и ваши команды, вероятно, все же покажут улучшение
результатов. А если, наоборот, следовать практикам и игнорировать инвестиции?
Тогда командам придется тяжело.
Как сказал Мартин Фаулер1, «я вижу поразительную параллель между ДХХ
(Давид Хейнемейер Ханссон, создатель Ruby on Rails) и Кентом Беком (создатель
экстремального программирования). Любой из них, получив в подарок ограничен-
ный мир, посмотрит на его ограничения, которые мы принимаем как должное, со-
чтет их несущественными и создаст новый мир без них… они просто подложат под
них заряд интеллектуального динамита и двинутся дальше. Именно поэтому они
могут создавать такие вещи, как экстремальное программирование и Rails, которые
встряхивают всю индустрию».
Делайте инвестиции — в них секрет успеха Agile.
В следующих разделах рассказывается об инвестициях, которые нужны вашим
командам от вашей организации. Возможно, вы не сможете получить их все, поэтому
я предлагаю вам альтернативы. При этом альтернативы возможны ценой снижения
эффективности, поэтому лучше приложите все усилия, чтобы добиться как можно
больше инвестиций. Я включил в список только те, которые важны.
1
Отрывок из статьи Мартина Фаулера Enterprise Rails (http://martinfowler.com/bliki/Enter
priseRails.html).
Глава 4. Инвестируйте в гибкость 57
zz Объедините в каждой команде все нужные навыки разработки, такие как тести-
рование и эксплуатация (см. раздел «Выберите или создайте Agile-команды»
текущей главы).
zz Предоставьте каждой команде коуча, который сможет научить ее практикам
поставки (см. раздел «Выберите Agile-коучей» текущей главы).
zz Доверьте каждой команде контроль над ее процессами разработки, сборки,
тестирования и релиза (см. раздел «Делегируйте полномочия и ответствен-
ность команде» текущей главы).
zz Для получения первого опыта работы в Agile выберите задачу, предполага-
ющую написание кода с нуля (green-field codebase), если коуч не сочтет, что
в этом нет необходимости (см. раздел «Выберите команде подходящую для
обучения задачу» текущей главы).
zz Разберитесь с вопросами безопасности, которые мешают коллективной раз-
работке (см. раздел «Решите проблемы, связанные с безопасностью» текущей
главы).
Команды оптимизации
zz Рассчитывайте на 1–3 месяца пониженной производительности каждой коман
ды (см. раздел «Найдите время на обучение» текущей главы).
zz Включите в команду экспертов в области бизнеса, рынка и продукта (см. раз-
дел «Выберите или создайте Agile-команды» текущей главы).
zz Предоставьте каждой команде коуча, который сможет научить ее практикам
оптимизации (см. раздел «Выберите Agile-коучей» текущей главы).
zz Передайте каждой команде ответственность за ее бюджет, планы и результаты
(см. раздел «Делегируйте полномочия и ответственность команде» текущей
главы).
ВЫБЕРИТЕ AGILE-КОУЧЕЙ
Каждой команде нужен коуч, который поможет ей научиться быть эффективной
Agile-командой. В подразделе «Навыки коучинга» главы 7 содержатся подробности.
Краткое описание коуча представлено ниже.
zz Каждой команде необходим тот, кто может помочь ей научиться быть эффектив-
ной и сплоченной.
zz Командам фокусировки нужен тот, кто может научить практикам планирования,
описанным в части II.
zz Командам поставки нужен тот, кто может научить техническим практикам, из-
ложенным в части III.
zz Командам оптимизации нужен тот, кто сможет научить практикам развития
бизнеса, описанным в части IV.
Некоторые коучи могут охватить сразу несколько категорий. Каждый коуч может
работать с одной или двумя командами.
ДЕЛЕГИРУЙТЕ ПОЛНОМОЧИЯ
И ОТВЕТСТВЕННОСТЬ КОМАНДЕ
Уважение к человеческим способностям
лежит в центре философии Agile, и нигде Уважение к человеческим способностям
это не очевидно настолько, как в подходе лежит в центре философии Agile.
Agile к полномочиям и ответственности.
Секрет первоклассного выполнения работы заключается в правильном понима-
нии деталей, а никто не понимает их лучше, чем непосредственные исполнители
этой работы… Имея необходимую квалификацию и направляемые лидером, они
будут принимать наилучшие технические решения и воплощать их лучше, чем
кто-либо другой смог бы сделать за них [Poppendieck2003].
Мэри и Toм Поппендик
1
Спасибо Джорджу Динвидди за это замечание.
Глава 4. Инвестируйте в гибкость 67
Так что это нормально — застраховать свои ставки на физическое рабочее про-
странство. Заложите на это средства в бюджете (в конце концов вам понадобится
хорошее помещение для команды, если вы сработаетесь с Agile), но в краткосрочной
перспективе вы можете реквизировать для каждой команды одну из больших комнат
для собраний или часть открытого пространства офиса.
Что бы вы ни решили, начните работать над этим как можно раньше. Организация
физического помещения занимает много времени.
1
Спасибо Джею Базузи за то, что обратил мое внимание на эти соглашения о commit-сообщениях
(https://oreil.ly/7vSmz).
72 Часть I. Улучшая гибкость
Вы решили, что Agile сделает вашу команду более успешной. Вы знаете, какие уровни
предлагают наилучший компромисс между затратами и выгодой. Вы определились
с инвестициями, которые должна сделать ваша компания. Теперь осталось понять,
как все это сделать на практике.
ОСОЗНАНИЕ ИЗМЕНЕНИЙ
Изменения разрушительны, и внедрение Agile —
не исключение. Степень разрушительности зависит Изменения разрушительны,
от того, скольких команд они коснулись и насколь- и внедрение Agile —
ко успешно вы управляете этими изменениями. не исключение.
Если у вас одна команда, жаждущая попробовать
Agile при полной поддержке со стороны организации, то это не должно быть боль-
шой проблемой. Если вы пытаетесь изменить 50 команд в организации, не знакомой
с идеями Agile… что ж, это очень большая проблема.
Понять, как люди реагируют на изменения, можно с помощью модели изменений
Вирджинии Сатир (рис. 5.1)1. Согласно рисунку, существует пять ступеней перемен.
Они применимы к Agile следующим образом.
1. Имеющийся статус-кво. Это стиль работы, который был до Agile. Он удобен
и всем хорошо знаком. Все знают, чего от них ждут и как делать свою работу.
Некоторые, тем не менее, не очень довольны и считают, что Agile должен помочь.
Они хотят перемен.
2. Сопротивление. Люди, желающие перемен, начинают получать поддержку,
и какие-то изменения в направлении Agile становятся возможными. Это назы-
вается внешним элементом изменения. Люди начинают по-разному реагировать
на возможность перемен. Многие противостоят им. Они говорят, что в Agile нет
необходимости, что вряд ли его внедрение будет успешным или что это пустая
трата времени. Некоторые злятся. Чем больше людей касаются изменения, тем
больше сопротивления вы встречаете.
3. Хаос. Проект изменений одобрен, и команды начинают использовать практики
Agile. Старые методы работы и привычные ожидания больше не действуют.
1
У Стивена Смита есть хорошая статья об этой модели (https://oreil.ly/1KQ38), включающая
советы о том, как помочь команде на каждом этапе.
76 Часть I. Улучшая гибкость
Рис. 5.1. Модель изменений Вирджинии Сатир (The Satir Change Model)
особенности личности также имеют значение; одним людям нравится пробовать все
новое, в то время как другие хотят стабильности и предсказуемости.
Вы можете снизить (но не полностью устранить!) хаос, применив технику, ко-
торой я научился у Дианы Ларсен: поддержка, информация и структура (Support,
Information, Structure — SIS)1.
zz Поддержка. Помогите людям разобраться, как выполнять работу в изменившейся
окружающей среде. Организуйте обучение, коучинг или найдите любые другие
способы оказать помощь людям, не внушая им мысль, что их оценивают. Сде-
лайте необходимые инвестиции, описанные в главе 4. Убедитесь, что у каждого
есть кто-то, с кем он может поговорить на работе или в частной жизни, когда
чувствует себя перегруженным.
zz Информация. Обеспечьте прозрачность информации в отношении того, что про-
исходит, что известно и с чем еще предстоит определиться. Не оставляйте без
внимания озабоченность людей карьерными вопросами. Если вы можете сделать
это честно, то дайте твердое обещание, что никто не будет уволен в результате
изменений. Сообщайте даже больше, чем считаете нужным2.
zz Структура. Людям нужна твердая почва под ногами, поэтому предоставьте им
дорожную карту грядущих изменений. Если вы используете эту книгу в качестве
основы для ваших изменений, то раздайте всем ее копии и расскажите, какие части
в данный момент используете. Когда что-то неясно, объясните, что нужно сделать,
чтобы внести определенность, и когда, по вашим ожиданиям, это произойдет.
Если нужен промежуточный шаг, например временные команды, то дайте ясно
понять, что это временно, и объясните, что будет дальше.
МАСШТАБНЫЕ ИЗМЕНЕНИЯ
Изменения, затрагивающие множество людей, гораздо более разрушительны, чем те,
которые касаются лишь нескольких команд. Это разрушение имеет тенденцию уси-
ливаться. Появляются слухи, люди начинают беспокоиться о своих рабочих местах,
и грядущие перемены становятся предметом ежедневного обсуждения.
Большие перемены (непосредственно затрагивающие 30–70 и более человек)
требуют профессионального управления изменениями. В зависимости от размеров
вашей организации ваш отдел кадров может иметь в своем составе специалистов по
изменениям, которые могут вам помочь. Если вы нанимаете внешних консультантов
Agile на этот проект, то поинтересуйтесь их опытом и подходом в области управле-
ния изменениями.
Руководители организаций часто недо-
оценивают важность управления измене Не стоит недооценивать важность
ниями. Это большая ошибка! Используя тер- управления изменениями.
минологию модели Сатир, к тому времени,
1
Спасибо Диане Ларсен за помощь в составлении этого списка.
2
Диана говорит: «Коммуницируйте, пока вас не затошнит. И даже потом продолжайте».
78 Часть I. Улучшая гибкость
ПРОЦЕССЫ ИЗМЕНЕНИЙ
Кайдзен — общий термин в сообществе Agile. Это японское слово, означающее «со-
вершенствование». В Agile-сообществе этот термин означает непрерывное постепенное
совершенствование1.
Непрерывное совершенствование — неотъемлемая часть Agile, так не нужен ли
кайдзен в первую очередь для того, чтобы направить ваши усилия к Agile? Пара-
доксально… но, наверное, нет. Кайдзен предназначен для улучшения существующих
методов работы. Если в вашей компании особое значение имеют документы, то
кайдзен поможет вам рационализировать документооборот. Если культура вашей
организации основана на обвинениях, то кайдзен поможет вам точнее устанавливать
вину. Но он не поможет вам перейти с любой культуры на Agile.
Чтобы перейти с одного стиля работы на другой, вам понадобится другое япон-
ское слово — кайкаку. Оно означает «трансформационное изменение». Вместо того
чтобы постепенно улучшать существующие процессы работы, как это делает кайдзен,
кайкаку фундаментально меняет основополагающий подход.
Все лучшие команды Agile, которые я знаю, начинали с кайкаку. Они разобра-
лись, что им нужно от Agile, как они собираются инвестировать в достижение этого
результата, и пошли ва-банк.
Я вижу команды Agile, которые работают посредственно, значительно чаще, чем
те, которые функционируют прекрасно. Первых объединяет то, что их компании
в свое время не пошли ва-банк. Они пытались проложить свой путь к Agile через
кайдзен. Поначалу кажется, что это работает, но потом все неизбежно останавливается.
Люди выгорают из-за несовпадения идей Agile и ценностей компании. Они устают
впитывать новые идеи. Изменения вызывают переутомление, прогресс начинает
тормозиться и после многолетних усилий полностью останавливается. По иронии
1
Термин «кайдзен» был импортирован в Agile из концепции бережливого производства (lean
manufacturing), которая, в свою очередь, основывается на революционной производственной
системе компании Toyota, — отсюда и японский термин. Рифмуется с английским I win — «я вы-
игрываю».
Глава 5. Инвестируйте в изменения 79
1. Начните с разговора
Все начинается с разговора. Часто проще всего разговаривать один на один, вы
получите наилучший результат, если будете общаться лично или, по крайней мере,
по видеосвязи. Начните с одного из влиятельных руководителей, которому вы до-
веряете, и завербуйте его в свои союзники. Он поможет разобраться, с кем еще вам
нужно поговорить и как найти к ним подход.
В этих разговорах, начиная с того самого первого руководителя, говорите о про-
блемах в разработке ПО, с которыми сталкивается ваша организация. Возьмите за
основу преимущества, описанные в предисловиях к частям II–IV, и расскажите о том,
насколько, по вашему мнению, разработка программного обеспечения могла бы
вестись лучше в вашей компании. Не монополизируйте разговор; вовлеките в него
80 Часть I. Улучшая гибкость
Мы поговорили спустя две недели. Ему понравилось то, что я сказал, и еще через
полторы недели мы обедали с его боссом — директором по продукту. Он и был
экономичным покупателем.
Во время того обеда директор по продукту высказал ряд опасений, касающихся
его организации. Мы обсудили несколько способов, как я могу помочь, и в ка-
честве продолжения запланировали встречу между мной и их директором по
управлению продуктами, который также присутствовал на том обеде.
Я встретился с директором через неделю. Он не являлся покупателем, поэтому
моей целью было не убедить его, а узнать больше информации о компании. Я также
хотел убедиться, что мы правильно понимаем друг друга, поскольку нам предстоя
ло тесно сотрудничать. К счастью, мы были на одной волне, и мой собеседник
запланировал еще одну встречу с участием нас двоих и директора по продукту.
Эта встреча состоялась на следующей неделе. Наша предыдущая встреча за
обедом была нашим шансом познакомиться друг с другом, тогда как эта встреча
была моим шансом заручиться поддержкой директора по продукту.
Я не пытался развернуть рекламную кампанию. Я никогда не считал полезным
говорить людям, что они должны хотеть. Вместо этого я задавал вопросы. У меня
была реальная цель: я хотел понять потребности директора по продукту и про-
информировать его о тех моментах, которые чреваты трудностями или даже
проблемами. Я спросил его, как он представляет себе успех, как он поймет, что
успех достигнут, и как, по его ожиданиям, в итоге это повлияет на бизнес.
К концу встречи, которая заняла час, я узнал достаточно, чтобы обрисовать при-
мерный подход и ценовой диапазон. Я спросил, правильно ли я все понял, и мой
собеседник ответил утвердительно. Мы ударили по рукам, и я обещал к концу
следующего рабочего дня представить детальное предложение, что и сделал.
Его рассмотрели в течение недели (директор держал меня в курсе того, что проис-
ходило в компании) и одобрили на следующей неделе, внеся небольшие поправки.
Окончательное одобрение заняло еще некоторое время, которое ушло на то,
чтобы пробиться сквозь корпоративную бюрократию, однако на тот момент это
был уже решенный вопрос. От первой встречи до первого одобрения прошло
пять встреч и семь недель. Это довольно быстрый результат для организации та-
кого размера, но они были очень мотивированы. У них была серьезная проблема,
которая блокировала прогресс, и они верили, что я могу помочь им решить ее.
Вот те ингредиенты, которые понадобятся и вам: мотивирующая проблема и вера
в то, что вы можете ее решить.
1
Обратите внимание, что метод Kanban — это значительно более широкое понятие, чем доска
Kanban, применяемая некоторыми командами для визуализации планирования.
84 Часть I. Улучшая гибкость
Изменить организацию
Вы можете изменить свою организацию или сменить ее.
Мартин Фаулер
Изменить организацию изнутри непросто, но возможно. Это отнимает много сил
и времени, и не всегда оказывается, что оно того стоило. Поэтому более простой
способ изменить организацию — сменив работу — может оказаться более разумным
выбором. Для тех, кто все же хотел бы попытаться, ниже приведены 13 советов,
почерпнутых из моего собственного опыта изменения организации изнутри.
1. Задумывайтесь о своих мотивах. Отвечает ли Agile в наивысшей степени ин-
тересам организации или он нужен вам по личным причинам? Есть ли у вас
время, энергия и энтузиазм, чтобы проповедовать эти изменения? Есть ли у вас
стратегия поиска выхода из проблем, которые могут возникнуть вследствие
ваших усилий? Если ответ на любой из этих вопросов — «нет», то смена работы
может оказаться лучшим выходом.
2. Организуйте надежную сеть поддержки. Изменения в направлении снизу
вверх — неблагодарная работа, часто ведущая к разочарованию. Полагайтесь
на семью и друзей, уходите домой вовремя и не живите рабочими проблемами
в нерабочее время.
3. Находите для себя маленькие удовольствия. Без поддержки сверху органи-
зационные изменения в значительной мере находятся вне вашего контроля.
Находите небольшие ежедневные рабочие задачи, благодаря выполнению
которых вы будете чувствовать удовлетворение.
4. Не сдавайтесь. Небольшие изменения накапливаются. Поначалу эффект от
ваших усилий будет незаметным, но они будут постепенно менять стиль
мышления людей в сфере решения проблем. В конце концов, по достижении
некоего порога все внезапно начнет меняться.
5. Уважение — ваша валюта. Чем больше люди уважают вас, тем больше ваш
авторитет. Завоевывайте авторитет своими действиями и уважительно от-
носитесь к другим, даже в мыслях.
6. Оставайтесь внутри сферы своего влияния. Изменения снизу требуют по-
стоянного повторения. Пытайтесь вносить изменения только в тех отделах
организации, с которыми вы находитесь в постоянном контакте.
7. Пополняйте ряды сторонников. Найдите хотя бы одного человека, который
уважает вас и ваши идеи и имеет большее влияние, чем вы. Привлеките его
к распространению ваших идей.
8. Находите пробелы. Люди должны хотеть изменений, но они будут их хотеть,
только если это дает им что-то, что они не могут получить другим способом,
или если это убережет их от потери чего-то ценного для них. Фокусируйтесь
на этих моментах.
Глава 5. Инвестируйте в изменения 85
9. Вникайте в причины. Всегда есть причины, почему что-то делается именно так,
а не иначе, и вы можете сделать свое вмешательство более эффективным,
если разберетесь, что это за причины.
10. Повторяйте. Продвигайте свою идею изменений снова и снова, разными
способами и разным людям. Но старайтесь не быть назойливым.
11. Не критикуйте все подряд. Выберите что-то одно и работайте с этим. Если
вы будете находить проблемы во всем, то люди просто перестанут вас
слушать.
12. Не ищите признания. Если вы успешны, то люди начнут повторять ваши идеи,
как если бы они были их собственными. Это не плагиат. Ваши усилия на са-
мом деле могут изменить мышление людей, при этом они даже не будут это
осознавать. Пусть они так думают. Они будут более усердно трудиться ради
собственных идей.
13. Будьте осторожны в своих желаниях. Если ваш проект изменений будет
успешен, то готовы ли вы взять на себя ответственность за то, что будет
дальше?
Если вы захотите прочесть историю изменений, вдохновившую автора на эти
советы, то можете найти ее онлайн на веб-странице [Shore2006]. Подробное
руководство по изменениям изнутри содержится в книге More Fearless Change:
Strategies for Making Your Ideas Happen [Manns2015].
ЗАИНТЕРЕСУЙТЕ КОМАНДУ
Agile ставит интересы людей на первое место, поэтому для вас не должно стать сюр-
призом, что нужно получить согласие вашей будущей Agile-команды на то, чтобы
попробовать новый подход. Можно заставить людей согласно кивнуть, стиснув зубы,
но (и я говорю это, основываясь на моем нелегком опыте) это обычно приводит
к потере кадров.
Когда меня просят помочь компаниям с внедрением Agile, я всегда разговариваю
с каждой командой отдельно от ее руководителей. Нужно дать членам команды
возможность высказаться в комфортных для них условиях, не опасаясь возмездия.
Пригласите на встречу и коуча команды, и если вы сами руководитель, то начните
разговор с того, что поддержите решение команды, каким бы оно ни было. Затем
дайте людям поговорить с коучем без вас.
Вы или коуч можете сказать команде, что ее выбрали возможным кандидатом
на тестирование Agile. Я обычно объясняю, почему руководство заинтересовано
в Agile, какие выгоды он принесет организации и как это повлияет на членов команды
лично. Я также объясняю, что изменение рабочих привычек — это стресс и команде
следует ожидать хаоса (обычно на период до трех месяцев), пока каждый разберется,
как сработаться с Agile. Еще я часто рисую набросок и поясняю модель изменений
Вирджинии Сатир (см. рис. 5.1).
Я говорю: «Если вы согласитесь, то я предложу вам попробовать стандартный
вариант Agile в течение трех месяцев. После этого мы оценим, что работает, что нет,
86 Часть I. Улучшая гибкость
и попробуем что-то улучшить1. Спустя шесть месяцев у вас будет возможность при-
нять решение — продолжаем мы работать с Agile или остаемся с тем, что есть сейчас».
Затем я даю всем возможность задать вопросы. У команд обычно множество
вопросов касательно процесса, но один вопрос возникает всегда: «Что будет, если
мы скажем “нет”?» Мой ответ всегда один и тот же: «Ничего не произойдет». Это
важно! Должна быть реальная возможность наложить вето. Если вы не дадите людям
возможность сказать «нет», то их «да» ничего не будет значить. Давая людям шанс
отказаться сейчас и конкретную возможность передумать позже, вы позволяете им
в безопасном режиме попробовать что-то новое.
Выделите достаточно времени на то, чтобы ответить на все вопросы. Встреча
обычно занимает около часа, но иногда может затянуться. Ответив на все вопросы,
напомните, что не будет никаких последствий для проголосовавших против. Еще
раз подчеркните это. И затем приступите к голосованию.
1
Это не совсем правда. Agile подразумевает постоянное совершенствование, поэтому мы оценим,
что работает, а что нет, уже в течение нескольких недель. Но по истечении трех месяцев мы делаем
паузу, чтобы дать более значительную оценку.
Глава 5. Инвестируйте в изменения 87
1
Алистер Кокберн называет этот феномен организационными антителами. Чем более успешна
инициатива по изменениям, тем больше люди беспокоятся о ее влиянии на них и тем сильнее
сопротивляются изменениям.
88 Часть I. Улучшая гибкость
против даже их руководство высокого уровня, то, возможно, хорошим решением будет
убедить их попробовать сделать пилотный проект, ограничивающийся только одной
командой. В этом случае выберите команду, стейкхолдеры которой одновременно
влиятельны и стремятся пробовать новые идеи. Это может занять какое-то время
(даже год или два), но им понравятся прозрачность и контроль, свойственные Agile,
и они убедят своих коллег дать новому подходу шанс.
Иногда организации, разрабатывающие программное обеспечение, пытаются
навязать Agile своим стейкхолдерам. Это даже может получаться, если эти органи-
зации обладают достаточной политической властью. Но в долгосрочной перспективе
это может привести к негативным последствиям. И если вы столкнулись с широ-
комасштабным сопротивлением, активным до такой степени, что даже пробный
пилотный проект не является приемлемым решением, — значит, Agile не подходит
вашей организации.
1
Дерби Э. Психология управления изменениями. Семь главных правил.
ГЛАВА 6
Масштабирование гибкости
МАСШТАБИРОВАНИЕ СВОБОДНОГО
ВЛАДЕНИЯ НАВЫКАМИ
Организации довольно часто пытаются мас-
штабировать Agile, при этом не ставя на первое Организации довольно часто
место способность быть Agile. Они инвести- пытаются масштабировать Agile,
при этом не инвестируя
руют много времени и денег в некое грандиоз-
ни в команды, ни в потенциал
ное «фирменное блюдо» под названием Agile, самой организации.
не инвестируя ни в свободное владение коман-
дами навыками, ни в потенциал самой органи-
зации. И это никогда не работает.
Чтобы масштабировать Agile, вам понадобится масштабировать и способность
вашей организации быть Agile. В эту задачу входят работы по трем направлениям:
организацонному потенциалу, коучинговому потенциалу и потенциалу команд.
Организационный потенциал
Одна из самых больших ошибок, которую совершают организации при попытке
внедрить Agile, — отказ от инвестиций, описанных в главе 4. Но даже если ваша
организация серьезно относится к этим инвестициям, могут обнаружиться другие
скрытые проблемные места.
Глава 6. Масштабирование гибкости 91
Коучинговый потенциал
Вам понадобится коуч или коучи, которые помогут разобраться с общей картиной
масштабирования Agile: кросс-командной координацией, потенциальными возмож-
ностями организации, управлением продуктом/портфолио и управлением измене-
ниями. С помощью книг и тренингов вы можете сами взрастить этих коучей внутри
организации, однако лучше все же нанять кого-то со стороны.
Вам также понадобятся опытные коучи командного уровня, и это, вероятно, будет
главным ограничением при масштабировании. Это люди, которые помогают команде
достичь уровня уверенного владения навыками, и они ей жизненно необходимы.
Каждой команде понадобится по меньшей мере один коуч, как обсуждается в под-
разделе «Навыки коучинга» главы 7.
Кроме того, вы можете как нанять опытных коучей командного уровня, так и вос-
питать собственных внутри организации. Если вы выбираете второй вариант, то
учтите, что каждому будущему коучу понадобятся обучающие ресурсы, такие как,
например, эта книга.
Вы можете расширяться быстрее, поощряя опытных коучей командного уровня
переходить в другую команду, как только их текущая команда начнет приближать-
ся к уровню свободного владения навыками. (Чек-листы в начале частей II–IV
помогут вам оценить прогресс.) К этому моменту некоторые члены команды,
возможно, уже сами будут обладать квалификацией, достаточной для того, чтобы
выступать в качестве коучей командного уровня, и смогут развивать свои новые
навыки в более опытных командах. Убедитесь, что такие горизонтальные пере-
мещения улучшают карьеру ваших коучей, а не вредят ей, иначе их поток может
иссякнуть1.
1
Спасибо Эндрю Стельману за то, что в Twitter-посте указал на опасность горизонтального
перемещения (https://oreil.ly/E0EaB).
92 Часть I. Улучшая гибкость
Потенциал команды
Коучи помогут вашим командам достичь свободного владения навыками. Чем
больше опыта у коучей, тем быстрее пойдут дела, но все же это займет некоторое
время. В разделе «Найдите время на обучение» главы 4 представлены примерные
цифры.
Вы можете форсировать события, наняв крупную консалтинговую компанию,
чтобы укомплектовать ваши команды опытными Agile-разработчиками в соотно-
шении 50 % и более. Достаточно высокое соотношение позволяет достичь уровня
компетентности почти мгновенно при условии, что вы уже приложили достаточно
усилий для мобилизации потенциала вашей организации.
Однако применяйте этот подход с осторожностью. Стратегия разумная, хотя
и дорогостоящая, но ее реализация имеет тенденцию давать сбои. Люди, которыми
вы дополняете ваши команды, оказывают огромное влияние на успех этого подхо-
да, и есть вполне реальный риск нанять неправильную фирму. Все говорят, что их
сотрудники имеют Agile-навыки, но даже в случае компаний с широко известными
именами тут больше бравады, чем реальных возможностей. За несколькими исклю-
чениями, если добавленный персонал и имеет какие-то знания в Agile, то обычно они
ограничиваются уровнем фокусировки.
Еще один риск усиления штата с помощью внешнего персонала связан с навыками
коучинга. Даже если добавленные сотрудники и будут иметь навыки, необходимые
для мгновенного перехода на уровень свободного владения навыками (в чем дале-
ко не всегда можно быть уверенным), маловероятно, что они также будут владеть
и навыками коучинга. Изменения в направлении Agile могут не состояться, если
консалтинг не даст результата.
Подход с добавлением внешнего персонала может сработать, если вы наймете
подходящую фирму. Выбрав этот вариант, постарайтесь воспитывать при этом
собственных коучей. Не ждите, что компания, добавляющая вам персонал, сделает
это за вас; тут нужен совершенно другой набор навыков. Обратитесь в небольшие
фирмы и к независимым консультантам, которые специализируются на Agile-
трансформациях и услугах обучения коучей. Люди, которых вы нанимаете, имеют
большее значение, чем вендор, особенно в случае этих конкретных навыков, и ма-
ленькие консалтинговые компании делают эту работу лучше.
Глава 6. Масштабирование гибкости 93
МАСШТАБИРОВАНИЕ ПРОДУКТОВ
И ПОРТФЕЛЕЙ
Свободное владение навыками — основа
успешного масштабирования Agile, но само- Успешное масштабирование Agile —
го по себе этого недостаточно. Вам понадо- это вопрос правильного управления
взаимозависимостями.
бится способ координации работы команд,
если только они не работают совершенно
независимо. Это труднее, чем кажется, поскольку команды обычно зависят друг от
друга, что вызывает появление узких мест в рабочем процессе, задержек, проблем
и ошибок коммуникации. Успешное масштабирование Agile — это вопрос правиль-
ного управления взаимозависимостями.
Есть две базовые стратегии масштабирования Agile: вертикальное, нацеленное
на увеличение количества команд, способных работать друг с другом, не образуя
узких мест, и горизонтальное, которое пытается ликвидировать узкие места путем
изоляции зон ответственности команд. Обе стратегии можно использовать вместе.
Вертикальное масштабирование
Вертикальное масштабирование означает увеличение количества команд, которые
могут совместно владеть продуктом или портфелем. Под «совместным владением»
я имею в виду, что у них нет четко определенной области работы. Каждая команда
может работать над любой частью продукта и участвовать в написании любого кода.
94 Часть I. Улучшая гибкость
Я рассмотрю два подхода к тому, как это сделать: LeSS и FAST. Для ясности буду
использовать терминологию из этой книги вместо терминов, которые применяются
в каждом из подходов, но приведу их в скобках.
LeSS
LeSS, который расшифровывается как Large-Scale Scrum, — один из оригинальных
подходов в Agile-масштабировании. Он был создан Крейгом Ларманом и Басом
Водде в 2005 году1.
Базовый LeSS применим для 2–8 команд, численностью до восьми человек каждая.
Все команды работают по одному визуальному плану (который в LeSS называется
бэклогом продукта) и совместно являются владельцами всего общего кода. Кроме
того, существует LeSS Huge, который применяется при значительно большем коли-
честве команд. Это мы обсудим позже.
Группу команд LeSS возглавляет продакт-менеджер (LeSS называет их вла-
дельцами продукта), отвечающий за принятие решений о направлении развития
продукта. Команды работают итерациями фиксированной длительности, обычно
составляющими две недели. В начале каждой итерации команды собираются, чтобы
вместе посмотреть на визуальный план и решить, над какими историями заказчика
(пунктами из бэклога, или функциональностями) будет работать каждая из них.
Команды работают только над историями, имеющими самый высокий приоритет.
Время от времени команды собираются на игру в планирование (пересмотреть
бэклог — рефайнмент). Обычно это происходит в середине каждой итерации.
Команды могут добавлять истории к визуальному плану и предлагать приоритеты
продакт-менеджеру.
Каждая команда LeSS — это команда функциональности; то есть команда работает
над историей целиком, от начала до конца, независимо от того, какой код потребуется
для ее реализации. Как только команда берет ответственность за историю, она ста-
новится ее владельцем. Ожидается, что она будет работать с заказчиком и другими
стейкхолдерами, чтобы прояснить детали, а также будет изменять и улучшать любые
части кодовой базы, которые потребуются для завершения каждой истории. В LeSS
нет концепции владения кодом на командном уровне.
В какой-то момент может оказаться, что нескольким командам требуется внести
поправки в один и тот же код, поэтому ожидается, что они сами будут договариваться
между собой, чтобы избежать проблем. Эта координация обычно происходит спонтан-
но, при необходимости и напрямую между задействованными участниками. Члены
команды знают, когда им будет нужно договориться, поскольку они обсуждали это,
работая вместе при выборе историй.
Коллективное владение кодом возможно благодаря использованию непрерывной
интеграции (Continuous Integration, CI), которая предполагает слияние последнего
кода, написанного каждым программистом, с общей основной ветвью каждые не-
сколько часов. LeSS также включает в себя разнообразные механизмы координации,
наставничества и обучения.
1
Большое спасибо Басу Водде за отзывы по теме LeSS.
Глава 6. Масштабирование гибкости 95
Внедрение LeSS
Материалы этой книги полностью соответствуют LeSS, за исключением того,
что в большинстве упоминаний командного владения чем-либо подразумевается,
что LeSS-команды владеют этим все вместе, а не какая-либо одна из них. Это осо-
бенно верно в отношении менеджмента продукта и владения кодом. Вдобавок не-
которые термины LeSS отличаются от тех, которые используются в этой книге.
Непрерывная интеграция особенно важна для LeSS, и коммит (фиксация) сборки
должен быть быстрым. Возможно, вам необходимо использовать многоступенчатые
сборки (см. подраздел «Многоступенчатые интеграционные сборки» главы 13) более
интенсивно, чем рекомендует книга. В частности, вам может понадобиться перенести
некоторые, а возможно, даже все тесты на вторичную сборку, несмотря на возрас-
тающий риск ее поломки.
Если вы ищете устоявшийся, хорошо про-
веренный подход к масштабированию Agile, См. также
то начните с LeSS. Вам понадобится развить
свободное владение навыками на уровнях фо- Коллективное владение кодом
(глава 12)
кусировки и поставки. Уровень фокусировки —
это фундамент, а уровень поставки необходим, Разработка через тестирование
(глава 13)
чтобы команды могли совместно владеть об-
щим кодом. Как минимум вам понадобятся Непрерывная интеграция
практики коллективного владения кодом, раз- (глава 13)
работки через тестирование и непрерывной
интеграции.
Больше информации о LeSS доступно на сайте less.work или в книге о LeSS Large-
Scale Scrum: More with LeSS [Larman2015].
FAST
FAST расшифровывается как Fluid
Scaling Technology. Это детище Рона FAST — один из самых многообещающих
Куартела и один из наиболее многообе- подходов к масштабированию, который
щающих подходов к масштабированию, я когда-либо видел.
который я когда-либо видел. К сожа-
лению, на момент написания этой книги и наименее проверенный. Я включил его
в книгу, поскольку думаю, что он заслуживает вашего внимания1.
Рон Куартел создал FAST в одной из страховых компаний в Вашингтоне. На пике
подхода у него было 65 человек, которые работали как одна команда. Он начал с экс-
тремального программирования в качестве основы, затем наложил его на техноло-
гию открытого пространства (Open Space Technology, OST), помогающую большим
группам людей самоорганизовываться вокруг какой-либо цели или задачи.
По сравнению с LeSS подход FAST гораздо более, так сказать, подвижный. LeSS
основывается на итерациях и долгосрочных командах, владеющих определенными
1
Большое спасибо Рону Куартелу за отзывы по теме FAST.
96 Часть I. Улучшая гибкость
1
Буквально «приращение», «добавка». Часть (или версия) создаваемого продукта, потенциально
готовая к использованию и увеличивающая ценность для конечных пользователей/потребителей.
Инкремент необходимо показывать конечным потребителям для получения от них обратной
связи (отзывов, замечаний и предложений).
Глава 6. Масштабирование гибкости 97
Внедрение FAST
FAST не настолько точно совпадает с техниками, представленными в этой книге, как
LeSS. Например, многие практики из уровня фокусировки не будут применимы.
В частности:
zz все места в книге, где упоминается термин
«команда», относятся к FAST-трайбу в целом; См. также
zz у вас будут дополнительные требования к ко-
Командная комната (глава 7)
мандной комнате, хотя настоящее руковод-
ство остается в силе, особенно для удаленных Согласование (глава 7)
команд; Ретроспективы (глава 11)
zz согласование и ретроспективы должны быть Визуальное планирование
настроены для работы с более крупными груп- (глава 8)
пами людей, и им, вероятно, понадобится более Игра в планирование (глава 8)
опытный фасилитатор, особенно для удален-
Планирование задач (глава 9)
ных команд;
Потенциал (глава 9)
zz визуальное планирование применимо в том
виде, в котором описывается здесь, но в него Резерв времени (глава 9)
больше не включается ничего мельче, чем один Стендап-митинги (глава 9)
ценный инкремент (Valuable Increment);
Прогнозирование (глава 10)
zz игра в планирование, планирование задач и по-
тенциал больше не нужны; Динамики команды (глава 11)
Горизонтальное масштабирование
Применительно к крупномасштабному Agile я предпочитаю вертикальное масшта-
бирование. Но многие организации вместо этого обращаются к горизонтальному.
В нем основное внимание уделяется тому, чтобы позволить командам работать
изолированно. Вместо того чтобы коллективно владеть продуктом или портфелем,
как это происходит в вертикальном масштабировании, горизонтальное разделяет
продукт или портфель на индивидуальные зоны ответственности, которыми владеют
отдельные команды.
Задача горизонтального масштабирования состоит в определении зон ответствен-
ности команды таким образом, чтобы они оставались максимально изолированными.
Глава 6. Масштабирование гибкости 99
Отчасти причина того, что в работе начались сбои, когда этот стартап разросся
до 80 команд, — в том, что организация не поддерживала в актуальном состоя-
нии зоны ответственности команд. Мы спроектировали механизм пересмотра
и обновления обязанностей команд (это была работа команды архитекторов), но,
как это часто случается, о нем забыли на фоне выполнения других обязанностей.
А вертикально масштабированные группы не нуждаются в таком же объеме со-
провождения. Они могут намного легче адаптироваться к меняющимся условиям
бизнеса.
Другими словами, вы можете комбинировать вертикальное и горизонтальное
масштабирование, представляя себе свои вертикально масштабированные группы
как одну «команду» с точки зрения горизонтального масштабирования. При этом
почти каждая может быть поточно-ориентированной, возможно, за исключением
группы, занятой вашей операционной платформой.
Моя рекомендация
Резюмируем: как вам масштабировать вашу Agile-организацию?
Начните с формирования компетентной команды. Наиболее частая ошибка,
которую допускают организации, — это начать широко распространять Agile, не до-
бившись свободного владения навыками
у команд. В большинстве случаев хоро- Начните с формирования у команды
шее масштабирование потребует от ваших свободного владения навыками.
команд развития компетентности на уров-
нях фокусировки и поставки.
Делайте вертикальное масштабирование прежде, чем горизонтальное. В боль-
шинстве случаев лучшим выбором является LeSS. Если у вас есть опыт и вы хотите
экспериментировать, то попробуйте FAST.
Если вы достигли пределов вертикального масштабирования (вероятно, около
60–70 человек, хотя FAST, возможно, способен и на дальнейшее масштабиро-
вание), то разделитесь на множество вертикально масштабированных групп.
Каждая должна быть поточно-ориентированной. Вам вряд ли понадобится ко-
манда сложных подсистем или вспомогательная команда, поскольку ваши группы
будут достаточно велики, чтобы иметь все необходимые знания. В некоторых
случаях вы можете захотеть сформировать отдельную группу платформ, чтобы
заботиться об общей инфраструктуре — обычно о платформе эксплуатации или
развертывания.
Если вы используете LeSS, то LeSS Huge описывает этот тип разделения при
горизонтальном масштабировании, хотя и с небольшими различиями. Он сохраняет
присущий LeSS акцент на коллективном владении кодом, даже двумя группами (ко-
торые LeSS называет «областями»). Однако в действительности группы склоняются
к специализации.
Но помните: успех масштабирования зависит от свободного владения навыками
команд. Этому посвящена вся оставшаяся часть книги. Мы начнем со свободного
владения навыками на уровне фокусировки.
102 Часть I. Улучшая гибкость
1
См. https://www.scaledagileframework.com/features-and-components по состоянию на 30 июня
2021 года.
II
ФОКУС НА ЦЕННОСТЬ
Ханна садится, и Шайна берет инициативу в свои руки. Некоторое время назад вы
решили (это был другой эксперимент с ретроспективами), что тот, кто ведет ретроспек-
тиву, будет фасилитировать все собрания команды в течение недели. Вы не слышали,
чтобы какие-либо другие команды работали подобным образом, но наличие заранее
назначенного фасилитатора помогает вам придерживаться выбранного направления,
тем более сейчас, когда ваш коуч перешел в другую команду.
Шайна переворачивает планировочную доску. На обратной стороне ваш план
на неделю. «Окей, вы знаете упражнение, — говорит она, указывая на пять карточек
с историями, выбранными Ханной. — Разложите их, и начнем мозговой штурм.
Нужно выписать задачи на желтые карточки. Я приготовлю доску».
Члены команды собираются вокруг стола и начинают записывать задачи на жел-
тых карточках. В процессе этого они высказывают свои соображения, что, в свою
очередь, вдохновляет всех на дополнительные идеи. «Обновить схему DB так, чтобы
она содержала цветовую схему». «Вынести переменные CSS». «Сделать для каждого
реселлера отдельный файл CSS». «Добавить CSS-файл реселлера к шаблону верх-
него уровня». Вскоре появляется упорядоченная сеть карточек, показывающая все,
что команде нужно сделать за эту неделю. Шайна помогает перенести все на белую
доску. Вы слышали, что другие команды визуализируют свои планы по-другому, но
вам нравится именно этот подход.
«Давайте соберемся на стендап», — говорит Шайна. Вы собираетесь вокруг белой
доски и сначала кратко обсуждаете, над чем будете работать, а затем каждый участ-
ник снимает с доски карточку с задачей. На каждую задачу уходит всего несколько
часов, поэтому, как только она завершена, вы помечаете ее как выполненную и берете
с белой доски новую. Каждый день вы проводите новый стендап-митинг вокруг
доски, чтобы оценить ваш прогресс и убедиться, что неделя идет должным образом.
«Думаю, на этом все», — говорит Шайна. Стендап занял всего несколько минут,
а вся сессия планирования продолжалась менее часа. Учитывая ретроспективу и демо,
время приближается к полудню. «Кто на обед?»
1
Эти списки взяты из [Shore2018b].
106 Часть II. Фокус на ценность
ВСЯ КОМАНДА
У нас есть все навыки, необходимые для достижения
отличных результатов. Аудитория
Коучи
Современная разработка ПО требует множества на-
выков. Речь идет не только о навыках программирования,
но и о навыках общения с людьми. Художественных навыках. Технических навыках.
И когда команда не имеет этих навыков, производительность падает. Вместо того
чтобы сконцентрироваться на функциональности и завершить ее, члены команды
должны жонглировать множеством задач, отправляя электронные письма, ожидая
ответы и улаживая недоразумения.
Чтобы избегать подобных проблем, Agile-команды
создаются как кросс-функциональные команды. Они со- См. также
стоят из людей, имеющих разные навыки и опыт, кол-
лективно обладающих всеми данными, позволяющими Цель (глава 7)
людям выполнять свое предназначение. В широком
1
III — его полное имя. Произносится как «три».
110 Часть II. Фокус на ценность
смысле эти навыки могут быть сгруппированы в навыки в сфере деятельности за-
казчика, навыки разработки и навыки коучинга.
Обратите внимание, что Agile-командам нужны
навыки, а не роли. Иногда из старших программистов, Agile-командам нужны
давно работающих в компании, получаются лучшие навыки, а не роли.
продакт-менеджеры. Иногда руководители проектов
обладают великолепными навыками в тестировании. И вдобавок Agile-команды
учатся и растут. Каждый работает над расширением своих навыков, особенно в от-
ношении сферы деятельности заказчика.
В тексте этой книги, когда я пишу «продакт-менеджер» или «разработчик»,
я имею в виду кого-то в команде, кто имеет такие навыки, а не того, чья должность
в команде носит буквально такое название. Agile-команды работают наилучшим
образом, когда люди вносят вклад в соответствии с их навыками и опытом, а не по-
зицией в организационной структуре.
К А Р ГО - К УЛ ЬТ
Провальная команда
«Окей, теперь вы Agile», — говорит ваш руководитель и немедленно
исчезает за дверью офиса.
Вы вчетвером нервно смотрите друг на друга. Вы — команда фрон-
тенд-программистов и не совсем понимаете, что вам делать. До вас
доходили слухи о новой инициативе и о том, что ваша команда будет
участвовать в ней… как?
На следующий день вбегает Клодин. «Привет! Я ваш Scrum-мастер, — говорит
она. — Извините, вчера меня не было. У меня еще четыре команды, и я только
что узнала, что буду работать еще и с вами. Рамонита будет вашим владельцем
продукта, но она сегодня не сможет присутствовать. Я назначила встречу через
неделю».
Клодин вводит вас в курс дела касательно продукта, над которым вы будете
работать. Ваша команда создает пользовательский интерфейс, а несколько
других команд делают микросервисы бэкенда. Тестирование будет проводиться
отделом контроля качества, как обычно, и когда вы будете готовы к разверты-
ванию, то отправите заявку в отдел эксплуатации, который будет отвечать за
мониторинг и бесперебойную работу. «Вот макет интерфейса, подготовленный
отделом дизайна, — говорит Клодин, — и Рамонита добавит в трекер задач
истории со всеми требованиями. Я буду встречаться с вами каждый день на
стендап-митинге. Просто сообщайте мне, что вы сделали, и я буду обновлять
трекер задач».
Клодин выбегает, и ее голос, затихая, доносится из глубины коридора. «Дайте
мне знать, если вам что-то понадобится!» Вы смотрите друг на друга, пожима-
ете плечами и открываете трекер задач. Истории не совсем понятные, поэтому
вы отправляете несколько электронных писем с вопросами. И начинаете раз-
работку.
Глава 7. Командная работа 111
Навыки разработки
Великая цель требует надежной реализации. Если навыки в сфере деятельности за-
казчика позволяют разобраться, что нужно делать, то навыки разработки нужны для
того, чтобы понять, как это сделать. Люди, имеющие навыки разработки, отвечают
за то, чтобы найти наиболее эффективный способ поставки ПО.
ПРИМЕЧАНИЕ
Некоторые называют навыки разработки техническими навыками, что мне кажет-
ся не совсем верным. В конце концов химики-аналитики или актуарии не являются
техническими специалистами. Поэтому за неимением лучшего термина я буду
описывать людей, которые пишут, тестируют и выпускают ПО, как имеющих на-
выки разработки.
Тестирование
Люди, имеющие навыки тестирования,
помогают команде поставки создавать См. также
качественные результаты с самого начала.
Поэтапные требования (глава 8)
Благодаря их критическому мышлению
заказчики при представлении будущего Примеры заказчика (глава 9)
продукта могут рассматривать все воз- Обнаружение слепых зон (глава 16)
можности. Эти люди также выступают
Без багов (глава 16)
в роли технических экспертов команды,
Глава 7. Командная работа 115
Эксплуатация (Operations)
В командах поставки нужны люди, имеющие
навыки эксплуатации ПО. Они помогают раз- См. также
вертывать, контролировать, управлять ПО
и обеспечивать его безопасность в производ- Непрерывное развертывание
стве. В небольших организациях эти люди так- (глава 15)
же могут отвечать за обеспечение и управление Сборка для эксплуатации
аппаратными средствами (hardware). В более (глава 15)
крупных организациях они могут быть заняты Анализ инцидентов (глава 16)
координацией с центральной эксплуатацион-
ной группой.
В навыки эксплуатации также входит помощь команде в поддержании рабочих
реалий: планирование потребностей отдела эксплуатации, таких как безопасность,
производительность, масштабирование, контроль и управление; справедливое
распределение смен дежурств на линии поддержки (при необходимости); помощь
в анализе и предотвращении инцидентов.
Навыки коучинга
Командам — новичкам в Agile надо научиться многому: им нужно понять, как при-
менять практики Agile, вдобавок им следует научиться работать всем вместе как
эффективные самоорганизующиеся команды.
Их организациям также надо научиться способам поддержки своих команд.
Большую часть этой поддержки они дают в виде инвестиций, описанных в главе 4,
но всегда необходимы дополнительные изменения. И хотя лучше, если организации
делают нужные командам инвестиции заранее, командам часто приходится доби-
ваться необходимых инвестиций уже после того, как работа началась.
Люди, имеющие навыки коучинга, помогают командам учиться быть эффектив-
ными Agile-командами. Они обучают практикам, помогают в дискуссиях, направля-
ют самоорганизацию и развитие и показывают, как работать с руководителями
и другими бизнес-стейкхолдерами, чтобы получить нужные инвестиции.
Команды — новички в Agile обычно имеют в своем
составе одного, иногда двух человек, однозначно опре- Работа коуча —
деляемых как коучи команды. Работа этих людей — помогать команде
помогать команде стать независимо компетентной, стать независимо
чтобы все ее члены могли выполнять свои задачи компетентной.
без участия коуча. Это не значит, что коуч уходит из
116 Часть II. Фокус на ценность
команды, но это значит, что он мог бы, и если остается, то постепенно становится
постоянным членом команды.
ПРИМЕЧАНИЕ
Даже после того как команда станет независимо владеть навыками, будет по-
лезно присоединять к ней опытного коуча (скажем, раз в год или около того),
чтобы помочь ей вспомнить забытые практики и попробовать новые.
Коучи-практики
Для меня наиболее предпочтительный тип коуча в Agile — это коуч-практик: че-
ловек, который имеет реальный опыт применения практик Agile и может подавать
пример. Его основные усилия направлены на помощь команде и организацию обуче
ния, а не на поставку продукта, но у него есть навыки и опыт, чтобы показывать,
а не рассказывать, а это часто подразумевает помощь членам команды в их работе.
Опытный коуч-практик может работать с одной-двумя командами одновременно
или руководить работой коучей-игроков в нескольких командах.
Коучи-игроки
Один из вариантов коуча-практика — это коуч-игрок (играющий тренер, player-
coach), который имеет опыт в практиках Agile и некие навыки коучинга, но больше
сфокусирован на поставке, чем на помощи командам в обучении. В эту категорию
Глава 7. Командная работа 117
часто попадают «доморощенные» коучи (их должность может называться а-ля «тех-
нический руководитель» или «ведущий инженер»), как и большинство опытных
Agile-разработчиков.
Коучи-игроки могут быть очень эффективными, помогая командам в применении
практик Agile, вплоть до уровня свободного владения навыками. Но они могут быть
менее успешными там, где командам нужно стать самостоятельно владеющими на-
выками. Этим коучам также может быть трудно понять, как и когда нужно влиять на
организационные изменения. Они должны быть приписаны только к одной команде.
Коучи-фасилитаторы
Один из наиболее часто встречающихся типов коучей — коуч-фасилитатор, также
называемый Scrum-мастером1, который поддерживает коллег как бы со стороны,
помогая в общении и разбираясь с организационными препятствиями. Такие коу-
чи обычно обучают практикам на уровне фокусировки и помогают командам стать
самодостаточными. Они могут выступать в защиту нужных инвестиций, поэтому
полезны и командам, которые в своей работе сталкиваются со множеством препят-
ствий. Коуч-игрок и коуч-фасилитатор могут быть хорошей командой, поскольку
их сильные и слабые стороны взаимодополняемы.
Опытный коуч-фасилитатор может работать с одной или двумя командами
одновременно. Один из недостатков роли коуча-фасилитатора заключается в том,
что он не вносит вклад в ежедневную разработку. Из-за этого организации часто
считают таких коучей недостаточно занятыми и назначают им в работу одновремен-
но слишком большое количество команд. Но тогда коучи лишаются возможности
полноценно присутствовать в жизни команды и понимать проблемы, с которыми
она сталкивается. В этой ситуации многие коучи в конце концов просто постоянно
занимаются организацией собраний, что является не очень хорошей областью при-
менения их талантов.
1
Название Scrum-мастер пришло из популярного метода Scrum. Оно вводит в заблуждение:
предполагает кого-то, кто достиг мастерства в понимании Scrum, а не того, кто имеет власть или
контроль над командой.
118 Часть II. Фокус на ценность
Комплектование команды
Точные названия должностей и ролей в вашей команде неважны, пока в ней пред-
ставлены все необходимые навыки. Должности больше имеют отношение к традициям
в вашей компании, чем к чему-либо еще.
ПРИМЕЧАНИЕ
В недавно сформированных Agile-командах полезно четко обозначить продакт-
менеджера и коуча. Для опытных команд четкие роли могут только мешать,
но новичкам в Agile будет полезно точно знать, к кому обращаться в случае
вопросов.
Глава 7. Командная работа 119
1
В личном общении.
120 Часть II. Фокус на ценность
Даже если кто-то временно является частью вашей команды, договоритесь, чтобы
эти люди были полностью приписаны к вам на этот период. Лучше иметь кого-то,
назначенного в команду на полный рабочий день на одну неделю, а потом — к дру-
гой команде на другую неделю, чем того же человека, назначенного в обе команды
одновременно на две недели.
Стабильные команды
Команде может потребоваться несколько ме-
сяцев на то, чтобы научиться эффективно См. также
работать вместе. В некоторых организациях
команды создаются и расформировываются Динамики команды (глава 11)
для каждого нового проекта. Однако сохра-
нять состав команды — менее расточительный вариант. Даже если цель команды
достигнута или жизненный цикл продукта завершен, не распускайте команду. Вместо
этого дайте ей новую цель или продукт.
То же самое применимо и к изменению состава. Если вы добавляете человека
в существующую команду, то он встраивается в ее культуру и нормы. А если вы до-
бавляете нескольких, то команда практически начинает все с нуля. Мое правило —
добавлять или удалять не больше одного человека в месяц.
Размер команды
Рекомендации в этой книге предназначены для команд численностью 3–20 человек.
Для новых команд хорошей отправной точкой будет численность 4–8 человек. Пре-
высив количество в 12 человек, вы начнете замечать проблемы в общении, так что
будьте осторожны при создании больших команд. И наоборот, если у вас очень
маленькие команды, то подумайте о том, чтобы объединить их. Это уменьшит рас-
ходы, и вы будете менее чувствительны к текучести персонала.
Для большинства команд программирова-
ние поначалу будет узким местом. Поэтому,
См. также
планируя размер команды, начните с того,
чтобы подумать, сколько времени уходит Парное программирование
на программирование. Для удобства я буду (глава 12)
называть человека, на 100 % занятого про-
Групповое программирование
граммированием, «один программист», но это (глава 12)
не значит, что в вашей команде должны быть
строго обозначенные роли.
zz Команды, которые не используют парное или групповое программирование,
должны состоять из 3–5 программистов. По мере увеличения команды у них
начинаются проблемы с координацией.
zz Команды с парным программированием должны состоять из 4–10 программистов.
Оптимальное количество — шесть. Команды — новички в практиках поставки
не должны насчитывать больше 6–7 программистов, пока не приобретут доста-
точного опыта.
Глава 7. Командная работа 121
Команда единомышленников
Никто в команде не отвечает за других. Далеко не каждое решение подлежит об-
суждению; но люди имеют решающий голос в своей экспертной области. Например,
программисты не могут не учитывать мнение заказчиков о приоритетах продукта,
а заказчики не могут не принимать во внимание мнение программистов о техниче-
ских необходимостях. Вдобавок у вас есть старшие члены команды, которые берут на
себя принятие важных решений. Но внутри нее нет иерархии подчиненности. Даже
люди с впечатляющими должностями, наподобие «продакт-менеджер», не управ-
ляют командой.
Это понимание важно для самоорганизующейся команды. Она сама решает, кто
возьмет на себя инициативу в любой задаче. И это нельзя считать трудным решением;
в командах, которые хорошо знают друг друга, это обычно происходит автоматически.
Таким человеком будет тот, кто лучше всех знаком с задачей, или тот, кто больше
всех заинтересовался получением дополнительной информации, или следующий
в очереди, или кто-нибудь еще.
При этом трудно передать, насколько весело и с удовольствием проводят время
высокопродуктивные Agile-команды. Брайан Марик, один из авторов Манифеста
Agile, говорил, что радостный настрой (Joy) — еще одна ценность Agile1. И он прав.
Отличные Agile-команды ее ощущают. Они оптимисты, энтузиасты своего дела
и получают истинное удовольствие от совместной работы. Есть чувство превосход-
ства, но они не воспринимают его слишком серьезно. Например, когда есть задача,
за которую никто не хочет браться, разговор о том, кто ее будет делать, может вестись
в игривой и веселой манере. И он протекает быстро. Эффективные Agile-команды
легко принимают решения.
Такая эффективность требует значитель-
См. также
ного времени и работы над собой. В прак-
тике «Динамики команды» показано, как Динамики команды (глава 11)
это сделать.
КЛЮЧЕВАЯ ИДЕЯ
Самоорганизующиеся команды
Agile-команды самостоятельно решают, над чем работать, кто будет это делать
и как. Это основная идея Agile: люди, которые выполняют работу, достаточно ква-
лифицированны, чтобы решать, как ее делать. Поэтому в данной книге так много
практик в областях планирования, взаимодействия и работы со стейкхолдерами.
За все это отвечают команды, а не менеджеры. От команд ожидается, что они
коллективно возьмут на себя ответственность и будут совместно работать для
достижения своей цели.
Это не значит, что руководителям нечем заняться. Фактически, делегируя де-
тали своим командам, руководители освобождают свое время, чтобы иметь
1
Марик определял четыре ценности, которые он видел в ранних Agile-командах: навык,
[само]дисциплина, легкость, радостный настрой [Marick2007a].
Глава 7. Командная работа 123
Вопросы
А что, если не хватает людей, чтобы обеспечить каждую команду всеми необходимыми
ей навыками, или определенный навык нужен команде не постоянно?
Для начала проверьте, не нанимает ли ваша компания слишком много програм-
мистов по сравнению с остальными экспертами, нужными командам разработки
ПО. Это распространенная ошибка. Если это так, то попробуйте изменить при-
оритеты найма.
Если у вас несколько команд, работающих над одним продуктом, то рассмотрите
возможность использования вертикального масштабирования, что позволит разумно
объединить их усилия, как описано в подразделе «Вертикальное масштабирование»
главы 6.
Если эти варианты не сработают, то ваша компания может сформировать вспомо-
гательную команду, ответственную за инструкции, стандарты и тренинг для других
команд, как описано в подразделе «Горизонтальное масштабирование» главы 6.
Например, какая-либо UX-команда может создать руководство по стилям и научить
людей, как его использовать применительно к программному обеспечению, разраба-
тываемому их командами. Это позволяет командам решать собственные проблемы,
не нуждаясь в полноценном опыте.
Когда требуется больше навыков, вы можете запросить, чтобы соответствующего
специалиста назначили в вашу команду временно. За этот период он сможет обучить
членов команды. Отложите любую работу, требующую определенных навыков, до
тех пор пока они не появятся. Таким образом вы не останетесь с наполовину выпол-
ненной работой, что ведет к потерям, как обсуждается во врезке «Минимизируйте
объем незавершенной работы» в главе 8.
Младшие члены команды наравне с остальными?
Члены команды необязательно наравне (у всех разная квалификация и опыт),
но они коллеги. Для младших членов команды будет разумным обращаться за со-
ветом и наставничеством к более опытным коллегам. А для тех, в свою очередь, раз-
умным будет обращаться ко всем с уважением, создавать товарищеские отношения
и помогать младшим коллегам расти, иногда делая шаг назад и позволяя им взять
инициативу в свои руки.
Как члены команды могут развить определенные навыки, не работая в команде,
специализирующейся на этом навыке?
Многие Agile-организации формируют сообщества практик вокруг функцио-
нальных специализаций. Их может вести руководитель, централизованная команда
поддержки или просто те, кому это интересно. Обычно эти люди проводят множество
тренингов, встреч и предлагают другие возможности для развития навыков.
Предварительные требования
Создание кросс-функциональной команды требует вовлеченности и поддержки от
руководства, а также согласия команды работать вместе как Agile-команда. В главе 5
можно найти больше подробностей о формировании такой вовлеченности.
Глава 7. Командная работа 125
Показатели
Когда ваша команда кросс-функциональна:
zz она способна решать проблемы и выполнять свою задачу, не дожидаясь внешних
специалистов;
zz люди в команде работают, выходя за рамки своей специализации, чтобы предот-
вратить появление узких мест и замедление работы;
zz команда способна принимать решения легко и эффективно;
zz люди в команде плавно перенимают роли лидерства от задачи к задаче.
Альтернативы и эксперименты
Теория, лежащая в основе этой практики, очень простая. Чтобы избежать задержек
и проблем в общении, следует:
1) найти всех, кто нужен для достижения ваших целей;
2) собрать их всех в одну команду;
3) организовать согласованную работу команды так, чтобы она достигла этих
целей.
Это основная идея Agile, и на самом деле нет никаких альтернатив, соответ
ствующих философии Agile. Но есть много возможностей для оптимизации де
талей. Накопив опыт использования этой практики, несколько месяцев применяя
ее буквально, как написано в этой книге, попробуйте немного поэксперименти-
ровать.
Например, как ваша команда может экспериментировать с изменением способов
принятия решений? Улучшается ли процесс, если назначить специального человека
для фасилитации дискуссий? Или пусть дискуссии текут свободно? Следует ли воз-
лагать некоторые решения на конкретных людей? Или ответственность руководства
должна быть более гибкой?
Простых ответов на эти вопросы не существует. Сделайте предположение.
Проверьте его, посмотрите, как все работает, и сделайте другое предположение.
Проверьте и его. Никогда не переставайте экспериментировать. Только так можно
достичь мастерства.
1
Катценбах Дж., Смит Д. Командный подход: Создание высокоэффективной организации.
126 Часть II. Фокус на ценность
К А Р ГО - К УЛ ЬТ
Окончание истории
Вы — программист, работающий в команде над какой-то историей,
и вам нужны пояснения по одному из требований. Вы отправляете
электронное письмо вашему эксперту в предметной области,
Линн, и делаете перерыв, чтобы размять ноги и выпить кофе.
Когда вы возвращаетесь, ответа от Линн все еще нет, поэтому вы
заглядываете в пару блогов по теме разработки, которые соби-
рались почитать. Через полчаса вы получаете ответ Линн.
Эх, кажется, она не поняла ваше сообщение и ответила не на тот вопрос. Вы от-
правляете другое письмо, но дальше ждать уже не можете. Вы предполагаете,
каким мог бы быть ее ответ, и возвращаетесь к работе.
Днем позже, обменявшись еще несколькими письмами, вы вместе с Линн нащупы-
ваете правильный ответ. Он не совсем такой, как вы предполагали, но довольно
близок к этому. Вы возвращаетесь к тому месту в коде и корректируете его. В этот
момент вы вдруг понимаете, что есть еще один связанный случай, которым еще
никто не занимался.
Конечно, вы можете еще раз спросить Линн, но это очень странный случай. Скорее
всего, в реальной жизни он никогда не произойдет. Кроме того, Линн очень за-
нята, а вы обещали закончить с этой историей еще вчера. (Фактически все и было
готово вчера, кроме этих мелких придирок.) Вы снова делаете предположение
и продолжаете работу, не зная, что ваше предположение было неверным.
понять неправильно. К тому же это удлиняет процесс разработки: прежде чем при-
ступить к работе, людям нужно потратить много времени на написание, передачу
и чтение документов.
Поэтому Agile-команды используют общую команд-
ную комнату, чтобы разговаривать напрямую. Это место, См. также
физическое или виртуальное, в котором команда рабо-
тает и взаимодействует друг с другом. Вместо того Вся команда (глава 7)
чтобы назначать кого-то для общения с экспертами
в предметной области и готовить документы, которые потом будут читать програм-
мисты, Agile-команды включают в свой состав экспертов в предметной области
и других локальных заказчиков. Когда программистам надо понять, что делать, они
разговаривают с локальными заказчиками напрямую.
Совместная работа в одной комнате дает огромные
преимущества. В полевых исследованиях шести со- См. также
вмещенных рабочих команд [Teasley2002] было об-
Поэтапные требования
наружено, что работа в одном помещении удваивала
(глава 8)
продуктивность и ускоряла выход на рынок почти до
трети от базового расчетного уровня компании.
Это сто́ит того, чтобы повторить еще раз: команды поставляли ПО за треть
обычного времени. После пилотного исследования еще 11 команд достигли того же
результата.
КЛЮЧЕВАЯ ИДЕЯ
Личное общение
Непосредственное общение является наиболее практичным и эффектив-
ным способом обмена информацией как с самой командой, так и внутри
нее.
Манифест Agile для разработки
программного обеспечения
Несмотря на успехи технологий, непосредственное, личное общение остается
самым эффективным способом общения. Перефразируя [Cockburn2006] (гл. 3),
существует несколько осей эффективности общения. Удаление каждой из них
делает его менее эффективным.
zz Сотрудничество лучше, чем разговоры. Под сотрудничеством я понимаю со-
вместную работу над общим ви́дением или другим артефактом. Это делает
идеи реальными, выявляя предположения и разницу в смыслах, которые
скрываются за словами.
zz Лично лучше, чем виртуально. В личном общении участники видят все нюансы
и сигналы, такие как малейшие движения глаз и едва различимые знаки языка
тела. Люди двигаются, общаясь с помощью поз, прикосновений (например,
кладя руку на плечо) и неосознанной синхронизации. Эти нюансы (неосознан-
но) помогают участникам лучше понимать друг друга.
zz Видео лучше, чем только аудио. Аудио лучше, чем текст. В аудио люди исполь-
зуют интонации и паузы, чтобы дать место юмору, выразить беспокойство,
128 Часть II. Фокус на ценность
Секреты сотрудничества
Чтобы ваша командная комната была максималь-
но полезной, ваша команда должна быть единой См. также
и полной. Вы не получите всех преимуществ кросс-
функционального сотрудничества, если люди, с кото- Вся команда (глава 7)
рыми вам надо общаться, не являются членами вашей
команды. Убедитесь, что кто-то из членов команды может заменить тех, кого работа
часто заставляет покидать командную комнату (обычно в эту категорию попадают
продакт-менеджеры).
Даже если ваша команда пока неполная, тем не менее совместная работа в одной
комнате позволит придать новый импульс вашему сотрудничеству. Ниже я описал
несколько моих любимых техник.
команды в целом. Поэтому вместо того, чтобы избегать прерываний, ищите способы,
как сделать так, чтобы они не отвлекали.
Лучший способ избежать длительного от-
влечения в случае прерываний — использовать См. также
парное или групповое программирование. В слу-
чае парного программирования, пока один че- Парное программирование
(глава 12)
ловек отвечает на вопросы, второй может про-
должать размышлять над текущей задачей. Групповое программирование
По завершении прерывания вопрос «На чем мы (глава 12)
остановились?» вернет процесс в прежнее русло.
В случае группового программирования прерывание становится еще меньшей про-
блемой; как правило, оно имеет тенденцию вовсе не происходить, поскольку все
работают вместе. А когда происходит, тот, кого отвлекли, просто отходит в сторону,
а остальные продолжают работать.
Если парное и групповое программирование
для вас не вариант, то вашей команде понадобит- См. также
ся заключить рабочие соглашения относительно
прерываний работы, требующей глубокой со- Согласование (глава 7)
средоточенности. Один из вариантов — выбрать
какой-либо показатель (например, наушники при личном общении или специаль-
ный статус в программе при виртуальном), который будет означать «пожалуйста,
не отвлекайте». Но все же не забывайте, цель — повысить продуктивность команды,
а не отдельных лиц.
1
Закон мобильности, или закон двух ног, пришел из «Технологий открытого пространства»
Харрисона Оуэна — прекрасного подхода к организации продуктивных дискуссий в больших
группах.
130 Часть II. Фокус на ценность
Создавайте визуализации
В момент общения каждый его участник держит в голове собственную модель
окружающего мира. И если ментальные модели слишком сильно различаются, про-
исходит недопонимание.
Чтобы это предотвратить, превратите вашу внутреннюю модель во внешнюю. Соз-
дайте визуализацию, которую каждый сможет увидеть, сравнить с собственной моделью
и изменить. Подойдут рисунки на белой доске, но еще лучше — модели, которые
способствуют сотрудничеству. Отлично работают индексные карточки и стикеры или
их виртуальные эквиваленты. Записывайте ваши идеи на карточках и передвигайте
их, чтобы наглядно представить взаимосвязи.
Вы будете встречать примеры таких визуализа-
ций в этой книге, например визуальное планирова- См. также
ние или практики планирования задач. Не ограничи-
Визуальное планирование
вайтесь визуализациями, описанными здесь. Всякий (глава 8)
раз, когда у вас возникает дискуссия, особенно если
Планирование задач
люди никак не могут понять друг друга или прийти
(глава 9)
к согласию, создавайте модель, которой участники
смогут управлять.
Работайте одновременно
При совместной работе не позволяйте процессу
проходить через узкое место, которым может стать, Не позволяйте процессу
например, единственный специалист. Убедитесь, что проходить через узкое
все могут вносить свой вклад одновременно. Напри- место, которым может стать
мер, при планировании избегайте того, чтобы один единственный специалист.
человек сидел за компьютером и вносил все данные
в электронную систему планирования. Вместо этого визуализируйте план с помощью
индексных карточек или их виртуального эквивалента. Таким образом множество
людей могут писать новые карточки одновременно, менять план (и обсуждать из-
менения), передвигая карточки и указывая на них.
Глава 7. Командная работа 131
ПРИМЕЧАНИЕ
Помните, что критиковать идеи во время мозгового штурма не нужно. И он
лучше всего работает, когда состоит из двух частей: первая — генерация идей
в свободной форме, где годится все; вторая — уточнение и фильтрация идей.
Стремитесь к согласию
Как вы поступаете, когда люди не согласны? Единоличные решения заставляют
людей отстраняться. Правило большинства приводит к разочарованию тех, кто
в меньшинстве. А поиск консенсуса очень долог и может зайти в тупик.
Вместо всего этого используйте голосование согласием (consent vote). При таком
способе голосования кто-то высказывает предложение, и затем все голосуют одним
из следующих способов: «Я согласен» (большой палец вверх при личном общении,
«+1» — в групповом чате), «Я вместе с группой» (большой палец в сторону или «+0»)
или «Я не согласен и хочу объяснить почему» (большой палец вниз или «–1»). Чтобы
избежать случайного давления друг на друга, вы можете договориться, что каждый
раскрывает свой вариант голосования на счет три.
Если никто не выбирает вариант «Я согласен», предложение не принимается из-
за отсутствия интереса. И наоборот, если отсутствуют несогласные, оно проходит.
Если все же кто-то не согласен, то объясняет свои возражения, и группа корректирует
предложение, чтобы устранить их. Предложение не проходит, пока не устранены
все возражения.
Голосование согласием работает по двум причинам. Во-первых, оно дает людям
возможность воздержаться от поддержки, не блокируя предложение полностью.
Во-вторых, если кто-то чувствует себя достаточно сильным, чтобы наложить вето
на предложение, то должен объяснить причины, что позволяет группе разрешить
их сомнения.
Соглашайтесь на эксперимент
Некоторые решения не имеют очевидного ответа или имеют множество одинаково
допустимых вариантов. Обсуждения этих решений легко могут перейти в бесконечные
рассуждения о том, что может пойти не так.
Когда вы замечаете, что дискуссия пере-
ходит в домыслы, предложите конкретный Когда вы замечаете, что дискуссия
эксперимент. Например, в экстремальном переходит в домыслы, предложите
программировании есть правило десяти ми- конкретный эксперимент.
нут: если двое спорят о направлении дизайна
более десяти минут, то они разделяются. Каждый пишет временный код, иллюстри-
рующий идею дизайна, а потом оба сравнивают результаты.
Множество команд
Из комнат, где сидят Agile-команды, обычно доносится ровный гул голосов, перио
дически перекрываемый возгласами торжества. Это вряд ли будет мешать членам
вашей команды, но может беспокоить ваших соседей. Убедитесь, что командная
комната хорошо шумоизолирована.
Если командам необходимо часто сотрудничать, то разместите их рядом и дайте
возможность слышать друг друга. Команды, которым взаимодействие не требуется,
можно разделить, используя расстояние или шумозащитные экраны.
1
Один из восьми человек имеет ту или иную форму дальтонизма.
Глава 7. Командная работа 135
1
Профессиональный совет: следы от перманентного маркера на белой доске можно удалять, рисуя
поверх него маркером для белой доски и немедленно стирая.
136 Часть II. Фокус на ценность
Командные помещения Spotify были лучшими из тех, что я видел, но, по словам
людей, с которыми я разговаривал, и они имели ряд недостатков. Перегородка
между рабочими комнатами команды и коридором изначально должна была быть
стеклянной, но вместо этого ее сделали своего рода сетью (видимо, вследствие
требований пожарной безопасности), из-за чего шум разговоров в коридоре мешал
команде. Кроме того, планировке комнат не хватало гибкости: Spotify имел комнаты
разного размера для команд разной численности, но людям не нравилось переезжать
из комнаты в комнату, когда команды увеличивались или, наоборот, уменьшались.
Рабочее пространство на рис. 7.2 основывается на комнате, созданной одним пер-
спективным стартапом, когда они переехали в новый офис. У них не было средств
на шикарное рабочее пространство, поэтому им пришлось обходиться тем, что име-
лось. Они поставили пять рабочих станций для парного программирования вдоль
длинной стены с окнами. Два стола были высокими для работы стоя, а оставшиеся
три были переделаны из сегментов круглого стола для переговоров. Второй круглый
стол для переговоров использовался для группового общения. Пространство было
разграничено перегородками с белыми досками. В распоряжении членов команды
Глава 7. Командная работа 137
1
Гибридно-удаленная команда в одни дни работает в режиме личного общения, а в другие —
в удаленном режиме. В частично удаленной команде часть людей работает в офисе, а часть —
удаленно.
Глава 7. Командная работа 139
1
Спасибо Дэйву Пулу, Габриель Хокнесс, Александру Берду, Крису Фентону, Брайану Шефу
и Дэйву Руни за то, что поделились своими приемами в Twitter (https://oreil.ly/vwWli). Кроме
того, спасибо Бренту Миллеру, Дэннису Макмиллану, Сету Маккарти, Джеффу Олферту, Матту
Плавкану за их советы.
140 Часть II. Фокус на ценность
Бьерн Фриман-Бенсон.
Три проблемы распределенных команд
Вопросы
В физической комнате моей команды слишком шумно, я не могу сосредоточиться.
Что мне делать?
Иногда команда становится чрезмерно шумной
и непоседливой. И это нормально — попросить вести См. также
себя потише. Когда вы обсуждаете рабочие соглаше-
ния при начальном согласовании, поговорите о том, Согласование (глава 7)
как удовлетворить пожелания каждого. Если этого Ретроспективы (глава 11)
будет недостаточно, поднимайте этот вопрос также
во время ретроспектив.
Помните, что парное программирование — отличный способ отвлечь ваше вни-
мание от фонового шума. Вы просто не заметите этот шум, разговаривая с вашим
партнером. Точно так же эта проблема не свойственна и групповому программиро-
ванию за счет фокусировки общего внимания на одной общей теме.
Когда начинается разговор, вся команда перестает делать то, что делала,
и начинает слушать. Что мы можем сделать, чтобы люди перестали так легко
отвлекаться?
Возможно, всей команде действительно нужно слышать эти разговоры, особенно
в самом начале. Это помогает установить контакт и привести всех к общему по-
ниманию. Со временем команды разберутся, какие разговоры можно с легкостью
игнорировать.
Если проблема продолжается, особенно в физической рабочей комнате, то попро-
буйте отходить немного подальше от остальных коллег, когда начинается разговор.
Заинтересованные члены команды сами присоединятся к обсуждению, в то время
как остальная команда продолжит работу.
Предварительные требования
Членам команды приходится проводить вместе несколько основных часов, чтобы
эффективно сотрудничать, даже если они работают удаленно. Если они настолько
широко разбросаны по часовым поясам, что общее время невозможно подобрать,
то у вас на самом деле несколько команд и вам нужно спланировать работу соот-
ветствующим образом. (В главе 6 представлена более подробная информация о том,
как масштабироваться до нескольких Agile-команд.)
Самое сложное — организовать пространство физической командной комнаты.
Обычно требуются согласование с административно-хозяйственным отделом и под-
держка руководства. На это могут потребоваться недели, а то и месяцы, поэтому
начинайте организацию рабочего пространства как можно раньше.
Вдобавок к получению поддержки руководства и административно-хозяйствен-
ного отдела убедитесь как можно раньше, что члены команды согласны работать
142 Часть II. Фокус на ценность
Показатели
Когда у вас хорошая командная комната:
zz члены команды взаимодействуют быстро и эффективно;
zz вы знаете, когда люди работают над проблемами, в решение которых вы можете
внести свой вклад, и они будут рады, если вы присоединитесь к дискуссии;
zz вам не нужно угадывать ответ. Если кто-либо в команде его знает, вы можете
спросить у него и получить быстрый ответ;
zz члены команды самостоятельно формируют кросс-функциональные группы для
решения проблем;
zz в команде царит атмосфера товарищества и взаимного уважения.
Альтернативы и эксперименты
Эта практика предназначена для беспрепятственного общения, и неважно, есть у вас
буквально командная комната или нет. Но если у вас нет опыта непринужденного
взаимодействия в пространстве такой комнаты (особенно физической), то попро-
буйте подобное общение в течение нескольких месяцев, прежде чем перейти к экс-
периментам с альтернативами. Трудно оценить, насколько это эффективно, пока
не увидишь своими глазами.
Группповое программирование еще
больше расширяет возможности сотруд- См. также
ничества, поскольку все члены команды
работают за одним компьютером. Воз- Групповое программирование (глава 12)
можно, это звучит странно, но в некото-
ром смысле это «простой режим» совместной работы. Он особенно эффективен для
команд, работающих удаленно, которым иначе пришлось бы очень постараться, прежде
чем они добились бы той же эффективности, что и команды, работающие в офисе.
Пожалуй, помимо группового программирования, больше ничто не приближа-
ется по эффективности к центральной идее общего рабочего пространства. Экспе-
риментировать можно с деталями. Как вы можете улучшить общение? Можно ли
Глава 7. Командная работа 143
БЕЗОПАСНОСТЬ Аудитория
Гитте Клитгаард Вся команда
Мы без страха делимся противоречивыми точ-
ками зрения.
1
Первая половина этого определения психологической безопасности («возможность быть со-
бой») основывается на [Kahn1990]. Вторая половина («возможность выдвигать идеи») — на
[Edmonson2014].
Глава 7. Командная работа 145
Будьте любознательны
Демонстрируйте неподдельный интерес к чужому мнению. Если кто-то молчит
и не очень хочет говорить, то спросите его, что он думает. Это даст понять, что его
голос ценен. Но имейте в виду, что такому человеку может быть некомфортно,
если к нему обратятся в присутствии большого количества людей. Если сомнева-
етесь, то перенесите обсуждение в меньшую группу — возможно, даже с глазу на
глаз.
Слушайте, чтобы понять, а не чтобы ответить.
Очень легко начать концентрироваться на том, Слушайте, чтобы понять,
что вы хотите сказать в ответ, вместо того чтобы а не чтобы ответить.
слушать, что говорит другой человек. Если у вас
уже наготове ваш следующий вопрос или заявление, значит, вы слушаете, чтобы от-
ветить. Вместо этого сосредоточьтесь на том, что вам говорят или пытаются передать.
Используйте эмпатию
Люди подвержены фундаментальной ошибке атрибуции: мы склонны думать, что
люди делают что-то из-за своих личных качеств, а не из-за ситуации, в которой
оказались. Например, если мы подрезали кого-то на шоссе, это потому, что мы чуть
не проскочили свой поворот. Если нас подрезал кто-то другой, это потому, что он
плохой водитель и не уважает других.
Когда вы не согласны с кем-то, поставьте
себя на его место. Вместо того чтобы подо- Когда вы не согласны с кем-то,
зревать злонамеренность или некомпетент- предположите, что у него добрые
ность, предположите добрые намерения: намерения.
человек такой же умный и имеет благие
намерения, как и вы, просто пришел к другому выводу. Попробуйте понять его по-
зицию и причины, по которым его вывод отличается от вашего.
Вы можете развить в себе эмпатию, разыгрывая разногласие по ролям постфак-
тум. Попросите кого-нибудь послушать, как вы будете объяснять это разногласие.
Объясните с вашей точки зрения, а потом с точки зрения оппонента. Приведите
лучший, наиболее разумный аргумент для его позиции.
Agile Conversations [Squirrel2020] — отличный ресурс, который позволит начать
понимать последствия разговоров и научиться быть более эффективными.
148 Часть II. Фокус на ценность
Организационная безопасность
Мой опыт помощи компаниям в построении безопасности во всей организации
заключается в том, что если безопасность отсутствует с самого начала, то нужно
начинать с малого. Чувство безопасности — внутреннее, оно может быть чем-то,
что человек испытывает только с одним-двумя людьми. Кроме того, нормально
чувствовать себя в безопасности только в своей команде. Если организация
озаботится безопасностью, то может совершить прорыв и люди начнут испы-
тывать чувство безопасности сначала в своем отделе, а затем, наконец, во всей
компании.
Роль лидера
Люди, находящиеся у власти, оказывают огромное влияние на безопасность. Это
могут быть как традиционные источники власти, например начальник отдела или
менеджер, так и неформальные, когда, например, старший разработчик общается
с младшим.
Если вы у власти, то ваши слова и поступки весьма значимы. Относитесь к этому
серьезно. Это значит, что вы не можете высказываться небрежно, как вам, возможно,
хотелось бы, по крайней мере поначалу. Научитесь считывать состояние людей: об-
ратите внимание на то, как ваши слова и поступки действуют на других.
Техники, представленные ниже, помогут вам создать атмосферу безопасности
в ваших командах.
Глава 7. Командная работа 149
Не уклоняйтесь от конфликта
Безопасность не означает, что люди всегда полу-
чают то, чего хотят. Она подразумевает, что все Безопасность не означает,
мнения принимаются во внимание. что люди всегда получают то,
Пытаясь создать ощущение безопасности, не- чего хотят.
которые команды вместо этого создают ложную
гармонию. Они начинают избегать конфликтов и подавлять инакомыслие. Это может
казаться безопасным, но конфликт никуда не уйдет и будет лишь подспудно расти.
Некоторые лидеры совершают ошибку, поощряя позитивность в своих коман-
дах. Они говорят что-то вроде «не будь таким негативным» или «будь командным
игроком» — подразумевая «иди вместе со всей командой». Таким образом, люди
понимают, что высказывать свое мнение небезопасно.
Вместо этого, если вы заметили, что люди подавляют свое мнение, попросите их
поделиться. Если кажется, что люди потакают ложной гармонии, то спросите их,
какие негативные стороны они видят в какой-либо идее. Если вы видите проблему,
которую никто другой не упомянул, то вынесите ее на обсуждение, но в доброже-
лательной манере.
В то же время будьте готовы ошибаться. Концентрируйтесь не на том, чтобы быть
всегда правым, а на том, чтобы вынести все мнения на открытое обсуждение, в ходе
которого можно их обдумать, оспорить и улучшить.
Ложная гармония и групповое мышление —
обычные проблемы команд, находящихся на См. также
стадии развития, называемой нормализацией.
Больше информации об этом вы найдете в пункте Динамики команды (глава 11)
«Стадия нормализации: мы — № 1» главы 11.
150 Часть II. Фокус на ценность
Вопросы
Что бы я ни делал, один из членов команды не хочет высказываться. Как я могу ему помочь?
Как и со многими командными вопросами, лучшее, что можно сделать для нача-
ла, — это слушать. Поговорите с этим человеком, почему он не хочет высказываться.
Подчеркните, что это не проблема, которую должен решить он. Это проблема команды.
Вы хотите, чтобы ему стало легче вносить свой вклад в общее дело.
Когда будете обсуждать возможности, имейте в виду, что хотя вы и хотите, что-
бы его голос был услышан, это вовсе не обязательно должен быть именно голос.
Некоторым людям удобнее излагать свои мысли в письменном виде, чем делиться
ими спонтанно.
Еще один вариант для такого человека — проговорить свои идеи с приятелем
в команде. Это позволит заранее отрепетировать то, что он хочет сказать, или он
может попросить приятеля представить его точку зрения.
Я видел кое-что и знаю, что это повлияло на одного человека. Но меня беспокоит,
что он не чувствует себя в достаточной безопасности, чтобы рассказать об этом.
Что мне делать?
Это зависит от сложности ситуации и от того, чувствуете ли вы себя в достаточной
безопасности, чтобы действовать самостоятельно.
В большинстве случаев можно начать с разговора с пострадавшим. Спросите,
все ли у него нормально и не хочет ли он обсудить это. Если можете, то предложите
поднять этот вопрос от его имени. Даже если вы не сможете это сделать, ваше пред-
ложение поможет человеку понять, что его замечают и кому-то не все равно.
Глава 7. Командная работа 151
Предварительные требования
Практически каждая команда может достичь психологической безопасности. В неко
торых компаниях принято подавлять разногласия или искать виноватых, и это может
затруднить обеспечение безопасности. Но вы все же можете организовать островок
безопасности внутри своей команды.
Если у вас удаленная команда, то будьте осторожны при записи разговоров. Если
в команде безопасно и люди могут свободно самовыражаться, то вы же не хотите,
чтобы организация в будущем смогла использовать это против членов команды?
По возможности настройте ваш чат на удаление старых записей и не записывайте
видеозвонки, если на это нет особых причин.
Показатели
Когда в вашей команде царит атмосфера психологической безопасности:
zz члены команды говорят о своих ошибках и чему они их научили;
zz они конструктивно выражают несогласие;
zz они выносят на общее обсуждение идеи и проблемы;
zz команда создает лучшие продукты, содержащие больше идей;
zz легче нанимать и удерживать людей с разнообразным опытом.
Альтернативы и эксперименты
Психологическая безопасность позволяет учиться, делиться знаниями, не соглашать-
ся и высказывать свое мнение. Эта практика помогает найти и упростить способы
изменения вашей окружающей среды.
152 Часть II. Фокус на ценность
ЦЕЛЬ
Аудитория
Мы понимаем, ради чего работаем.
Продакт-менеджеры, коучи
У каждой команды есть цель: причина суще-
ствования команды и ожидания от результатов ее работы. Но слишком часто команде
эту цель не озвучивают. Вместо этого членам команды сообщают много подробностей
о том, что им нужно делать… но не почему им надо это делать или как это поможет
компании достичь ее целей.
1
Эдмонсон Э. Работа без страха. Как создать в компании психологически безопасную среду для
максимальной командной эффективности.
Глава 7. Командная работа 153
В практике «Цель» объясняется, как сделать так, чтобы каждый понимал общую
картину, а не только детали.
Начните с ви́дения
Прежде чем у продукта появляется команда, у кого-то в компании рождается идея.
Предположим, это некто в компании Wizzle-Frobitz (выдуманное название).
«Эй! — восклицает он (или она), в порыве воодушевления смахивая свой кофе со
стола. — Мы могли бы frobitz наши wizzle намного лучше, если бы у нас было ПО,
которое сначала сортировало бы wizzle!»
Как правило, обычно это происходит не так драматично. Основная мысль в том,
что цель команды начинается как идея, ориентированная на результат. Продавать
больше «железа», комплектуя его лучшим ПО. Привлекать более крупных заказ-
чиков, более эффективно масштабируя. Продавать больше облачных сервисов,
предоставляя технологию машинного обучения. Это все реальные примеры команд,
с которыми я работал.
Где-то в процессе перехода от идеи к команде часто теряется важная часть — ви́де
ние лучшего будущего. Его загораживают детали. Вам нужно укомплектовать коман-
ду программистами, экспертами в предметной области и UX-дизайнерами. Вам
нужно определиться с функциональностью, запланировать релизы и отчитываться
о прогрессе. Быстрее, народ, поторапливайтесь!
И это позор, поскольку нет ничего важнее, чем
предоставить ви́дение. Если цель — продать боль- Нет ничего важнее, чем
ше облачных сервисов с помощью машинного обу- предоставить ви́дение.
чения, то даже самый лучший продукт машинного
обучения недостаточно хорош, если он не является частью облачной платформы.
Если вы производите масштабирование с целью привлечь более крупного заказчика,
то вам нужно убедиться, что выбранный вами способ масштабирования подходит
для его потребностей. И наоборот, если вы ищете способ привлечь заказчиков,
для которых вряд ли вообще требуется масштабирование, то какая разница, как
вы его сделали?
Идентифицируйте цель
Деньги для вашей команды приходят из чьего-то бюджета. Этих людей обычно на-
зывают исполнительными спонсорами команды. Технически у спонсора решающее
слово в отношении цели команды, однако на самом деле все не так просто. На спон-
соров влияет множество людей, называемых ключевыми стейкхолдерами, поддержка
которых позволит вашей команде быть успешной.
Кто-то должен объединить все идеи в одну цель. Нужно убедиться, что исполни-
тельный спонсор относится к цели с энтузиазмом, команда понимает ее, ключевые
стейкхолдеры согласны с ней и другие стейкхолдеры принимают ее. Как обсуждается
154 Часть II. Фокус на ценность
Задокументируйте цель
Продакт-менеджеры в процессе обсуж-
дений с ключевыми стейкхолдерами Задача обсуждений — согласовать
и спонсором уточняют идеи и собирают работу команды.
их в проект документа о цели. Задача об-
суждений — согласовать, над чем команда должна работать, почему она работает над
этим и как выглядит успех. Это общее понимание отражается в вашем документе
о цели. Вы будете его регулярно пересматривать и обновлять.
Проект документа о цели — первый примерный набросок в документировании
этого обсуждения. Он используется для того, чтобы развивать дискуссию. Формат
документа зависит от стандартов вашей компании. Некоторые компании любят
использовать ключевые показатели эффективности (Key Performance Indicators,
KPIs) или подход OKR (Objectives and Key Results — цели и основные результаты).
Каким бы ни был формат, вам в конечном итоге нужно ответить на три вопроса.
1. Ви́дение. Почему работа команды ценная? Опишите, как мир (или, по крайней
мере, его маленькая часть) изменится, когда команда добьется успеха. Поясните,
почему это важно для компании и ее заказчиков. Думайте о долгосрочной пер-
спективе и сосредоточьтесь на ценности.
2. Миссия. Как команда может реализовать концепцию в следующие 3–6 месяцев?
Опишите, что, по ожиданиям, команда должна выполнить и что лежит за преде-
лами объема работ, но на высоком уровне. Оставьте больше пространства команде
для проработки деталей. Сосредоточьтесь на итогах и ценности до результатов.
Может быть полезным сначала подумать о конкретных результатах, но двигаться
в обратном направлении, то есть начать с «почему», а не «что».
3. Показатели. Как члены команды узнают, что они на верном пути? Опишите до
пяти кратких показателей успеха. Будьте конкретны и недвусмысленны. Избегай-
те разговоров о конкретных функциональностях (например, «поставить функцио
нальность Х к дате Y»). Вместо этого пишите о коммерческих результатах, кото-
рых ожидают стейкхолдеры. Объясните, как понять по показателю, что ценность
миссии была достигнута. Если это трудно сделать, то, вполне возможно, ваша
миссия не сфокусирована на ценности.
Документ о цели — это ориентир, а не
набор четких и жестких правил. Это способ Документ о цели описывает
помочь людям понять, чего команда пыта- механизм сотрудничества,
ется достичь. Таким образом, он отражает а не является контрактом.
понимание ситуации на сегодняшний день.
Если показатели не достигнуты, это не означает, что команду надо наказать. Если
достигнуты, это не значит, что все перестают работать.
Вспомните Манифест Agile: «Сотрудничество с заказчиком важнее согласова-
ния условий контракта». Документ о цели описывает механизм сотрудничества,
а не является контрактом. В процессе работы и по мере накопления командой знаний
о рынке цели будут меняться.
156 Часть II. Фокус на ценность
Пример цели
Ви́дение: команда «Снежный человек» помогает другим командам взаимодей-
ствовать на дальних расстояниях. Наши заказчики добиваются того же высокого
уровня взаимодействия в случаях, когда команды сидят в одном рабочем по-
мещении. Используя обычные инструменты для демонстрации экрана, человек
становится узким местом для всего обсуждения. Наши инструменты позволяют
участвовать каждому. Это превращает взаимодействие на расстоянии в эффек-
тивное и приятное занятие, в то же время давая нам возможность зарабатывать
на оплате подписки лояльными клиентами.
(Обратите внимание, ви́дение фокусируется на ценности в долгосрочной пер-
спективе.)
Миссия: наша первая миссия — создание инфоповода. Наша цель на данный мо-
мент — не в создании постоянного дохода, а в том, чтобы доказать жизнеспособ-
ность идеи и привлечь внимание к нашему уникальному взгляду на удаленное
сотрудничество.
Мы будем это делать, создавая инструмент для одновременной работы, повто-
ряющей принцип работы с индексными карточками на столе. Это не инструмент
продакт-менеджмента, не инструмент для отслеживания или проведения ретро-
спектив. Это «песочница» свободной формы, способная выполнять любую из этих
задач. Она сфокусирована на взаимодействии и простоте. Она выделяется своим
качеством. Она не предоставляет возможности для чата или видеоконференции,
но по-прежнему сфокусирована на базовой функции «песочницы» для одновре-
менного сотрудничества.
(Обратите внимание, что миссия начинается с ценности, затем переходит к де-
талям конечного продукта.)
Показатели
1. Мы представим первый макет и план для как минимум 20 потенциальных
заказчиков. Мы будем считать, что достигли успеха, если 70 % из них скажут,
что это решает их проблемы с взаимодействием. Так мы узнаем, является ли
наш подход жизнеспособным.
2. Мы проведем демонстрацию ранней версии на стенде во время отраслевого
мероприятия. Мы будем считать, что достигли успеха, если минимум 100 чело
век остановятся и проявят интерес и по меньшей мере 50 подпишутся на
бета-версию. Это будет означать, что люди заинтересованы в продукте.
3. Выпустив открытую бета-версию, мы будем считать, что достигли успеха, если
минимум 500 команд подпишутся на нее за первый месяц. Это будет означать,
что люди заинтересованы в продукте.
4. Через четыре месяца после запуска бета-версии продукта мы будем считать,
что достигли успеха, если минимум 100 команд будут оплачивать продукт
и пользоваться им регулярно, что будет определяться как минимум одной
авторизацией и изменением в течение каждых двух недель. Это будет означать,
что продукт полезен в реальной жизни.
(Обратите внимание, что каждый показатель описывает, как он соотносится с це-
лью. Существует множество способов, позволяющих команде оценивать свой
прогресс уже на раннем этапе.)
Глава 7. Командная работа 157
Совершенствуйте миссию
За ви́дение отвечает спонсор, а за миссию — коман-
да. Именно она отвечает за претворение миссии За ви́дение отвечает спонсор,
а за миссию — команда.
в жизнь, поэтому должна взять на себя и ответ-
ственность за нее.
Чтобы помочь с формированием этой ответственности, запросите у команды
обратную связь о миссии. (Пока не о показателях. Только о самой миссии.) Попро-
сите дать реакции и комментарии, затем разделите команду на небольшие группы:
кросс-функциональный коллектив, состоящий из членов команды и стейкхолдеров.
1
На сессии не всегда готовится устав как документ, скорее это сессия, устанавливающая или
стартующая проект. Далее оставим вариант «сессия подготовки устава». — Примеч. науч. ред.
2
Данная программа основана на [Larsen2016] (гл. 6), с небольшими изменениями.
158 Часть II. Фокус на ценность
Пусть каждая группа внесет в миссию улучшения: как небольшие поправки в фор-
мулировки, так и более значительные изменения.
По истечении отведенного времени каждая группа представляет свои поправки
и их обоснование, а остальная часть группы дает обратную связь. Фасилитатор по-
могает всем объединить их идеи в общую миссию. Для этого может потребоваться
еще один раунд обсуждения в небольших группах. Иногда полезно перемешать
состав групп.
Как только команда скорректирует миссию, проведите еще один раунд голосова-
ния за согласие. Соответствует ли скорректированная миссия ви́дению? Удовлетво-
рены ли стейкхолдеры тем, что миссия будет отвечать их потребностям? Готова ли
команда взять на себя ответственность за достижение миссии? Когда вы будете вести
это голосование, подчеркните, что миссия не обязательно должна быть идеальной.
Она будет меняться со временем. Она должна быть просто достаточно хорошей на
текущий момент.
Пересмотрите показатели
И наконец, время пересмотреть показатели. Эта часть может быть самой спорной,
поскольку они должны быть максимально конкретными. Хорошие показатели долж-
ны быть недвусмысленными. И это может пугать.
Напомните всем, что показатели не являются
контрактом. Они служат ориентиром. Это способ Показатели — это ориентир,
проверить, находится ли команда на верном пути. а не контракт.
Если ваша команда не достигает показателей, это
значит, что вам нужна помощь или следует понизить ожидания. Если вы превы-
шаете показатели, это значит, что вы готовы поднять планку и повысить ожидания.
Показатели будут пересматриваться, как и все остальное, и они — не единственная
бизнес-метрика, которой следует уделить внимание.
Чтобы пересмотреть показатели, снова разделитесь на маленькие кросс-функ
циональные группы. Поделите показатели между группами. Убедитесь, что с помощью
каждого показателя можно проверять прогресс по достижению миссии, что для него
возможен ясный ответ «да» или «нет» и команда способна достичь этого показателя.
Проверьте изменения в большой группе, удостоверьтесь в общем согласии и продол-
жайте проверку, пока все возражения не будут благополучно разрешены.
Пока группа работает над каждой частью, вы можете обнаружить новые детали,
которые заставят вас вернуться и пересмотреть предыдущие части цели. Это нор-
мально и ожидаемо. Это итеративный процесс.
Стремитесь к цели
Когда закончите, проведите заключительное голосование о согласии с целью. Соглас-
ны ли все присутствующие, что цель ясна, имеет ценность и достижима? Если да,
то пора начать стремиться к ней. Попросите каждого из присутствующих зафикси-
ровать обязательства с помощью физической подписи (если у вас личная встреча)
или электронной (если виртуальная).
Глава 7. Командная работа 159
После того как цель будет утверждена, пригласите вашего спонсора, если он
(она) еще не с вами. Вместе просмотрите изменения в цели, попросите поддержки
и получите подпись спонсора.
ПРИМЕЧАНИЕ
Если во время вашей сессии подготовки устава вы обсуждаете и цель, и контекст
(см. раздел «Контекст» далее в этой главе), то можете обсудить контекст и только
потом пригласить спонсора.
Продвигайте цель
Как только цель утверждена, сделайте ее
краеугольным камнем проекта. Ссылай- См. также
тесь на нее в отчетах о работе команды,
предназначенных для стейкхолдеров, Информативное рабочее пространство
и в разговорах о ваших планах и при- (глава 9)
оритетах. Вывесите постер с целью на Визуальное планирование (глава 8)
видном месте в командной комнате и об- Демо для стейкхолдеров (глава 10)
ращайтесь к ней во время сессий плани-
рования.
Не забывайте вовлекать в процесс работы вашего спонсора и других ключевых
стейкхолдеров. Приглашайте их на визуальные сессии планирования. Убедитесь,
что эти люди видят демо, даже если это происходит на сессиях с ограниченным
доступом. Запрашивайте у них обратную связь относительно прогресса и просите
помощи в улучшении ваших планов.
Вовлекать стейкхолдеров может быть непросто, но вы все же пытайтесь. Энтузи-
азм и воодушевление этих людей могут говорить гораздо больше, чем любой документ.
Если члены команды часто общаются со своими ключевыми стейкхолдерами, то
будут лучше понимать свою цель и выдвигать больше идей, которые позволят повы-
сить ценность продукта и снизить затраты.
Ели гора не идет к команде, значит, коман-
да должна идти к горе. Другими словами, если Попытайтесь вовлечь
стейкхолдеры не хотят приходить на сессии пла- ключевых стейкхолдеров.
нирования, то командные продакт-менеджеры
Глава 7. Командная работа 161
Обновляйте цель
Цель команды будет меняться со временем. Показатели будут устаревать, и команда
будет узнавать что-то новое о своих стейкхолдерах, заказчиках и рынке. В результате
вам понадобится обновлять цель. Это изменяемый документ.
Установите конкретное время для пересмотра и корректировки цели. Например,
каждые 3–6 месяцев. Подготовьте новый черновик и соберите всех на новую сессию
подготовки устава. Скорее всего, она пройдет значительно быстрее, чем в первый раз.
Обычно концепция сильно не меняется, миссию потребуется слегка скорректировать,
а показатели нужно будет обновить или заменить.
Вопросы
Может ли вся команда участвовать в обсуждении проекта цели?
Конечно! Это прекрасный способ для команды узнать поближе своих стейкхолде-
ров. Обычно одни члены команды больше заинтересованы, чем другие. Обсудите, как
разделить работу внутри команды, возлагая ее на тех участников, кто имеет больше
опыта работы со стейкхолдерами.
Обсуждение цели привело нас к спорам, и согласия не предвидится. Должны ли мы
продолжать в любом случае?
С целью команды должен быть согласен не каждый стейкхолдер, а лишь ключе-
вые стейкхолдеры. Даже если обсуждение цели команды привело к ожесточенным
спорам, вам все же необходимо стремиться к общему ви́дению и цели. Иначе вы
выпустите ПО, которое будет фрагментированным и никого не удовлетворит.
Вероятно, вы сможете разбить цель на множество этапов, которые команда сможет
выполнять последовательно. Если это не сработает, то попробуйте привлечь про-
фессионального фасилитатора, который может выступать посредником в дискуссии.
Наш спонсор постоянно меняет свое мнение. Как можно заставить его выбрать
одно направление и придерживаться его?
Как правило, быстро меняют цели спонсоры с предпринимательским мышлением.
Это происходит не из-за отсутствия ви́дения или последовательности; просто они
видят множество возможностей и меняют направление, чтобы использовать их все.
Постоянное изменение цели может служить зна-
ком, что то, что вы принимаете за цель команды, — на
См. также
самом деле временная стратегия в более крупной
общей цели. Адаптивное планирование
Если вам удастся идентифицировать эту более (глава 8)
крупную цель, то адаптивное планирование сможет
162 Часть II. Фокус на ценность
помочь вам двигаться наравне с вашим спонсором. Здесь также может пригодиться
свободное владение навыками на уровне оптимизации. Его акцент на обучение и ис-
пользование всех возможностей будет прекрасно сочетаться с предпринимательской
натурой вашего спонсора.
Ваш спонсор может продолжать менять направления быстрее, чем вы будете
воплощать в жизнь его идеи. В этом случае продакт-менеджер может выступать по-
средником, защищая команду от быстрых изменений и объясняя спонсору, какой
объем работы команда может выполнить в данный момент.
Предварительные требования
Любой команде нужна цель. Она не обязательно должна быть выражена в представ-
ленном здесь формате, но каждой команде необходимо знать, чего от нее ожидают
и почему. Правильно определить цель может быть непросто. Для этого потребуется
вовлечь стейкхолдеров и людей, имеющих достаточные навыки в области менедж
мента продукта.
Если у вас нет человека с необходимыми навыками, то ваша компания рискует
потратить много денег на неверные результаты. Прежде чем продолжить, попросите
вашего исполнительного спонсора помочь устранить этот риск.
Показатели
Когда у вашей команды есть понятная и убедительная цель, которую разделяет вся
команда и стейкхолдеры:
zz легко приоритизировать функциональности;
zz продакт-менеджеры без труда обосновывают перед стейкхолдерами свои решения
по приоритизации;
zz разработчики вносят свой вклад в принятие решений при планировании, пред-
лагая способы того, как повысить ценность, одновременно снизив затраты;
zz ключевые стейкхолдеры уверены, что команда разрабатывает именно то, что им
нужно;
zz организация поддерживает усилия команды.
Альтернативы и эксперименты
В конечном итоге эта практика нужна для того, чтобы убедиться, что все одинаково
понимают, что и почему в работе команды. Точный способ достижения этого пони-
мания не так важен. Вы можете использовать сессию подготовки устава и документ
о цели, как я описывал здесь, а можете попробовать и другие подходы.
Один стартап, с которым я работал, начинал с нормального документа о цели,
но потом люди обнаружили, что их бизнес меняется слишком быстро, чтобы этот
документ оставался полезным. Вместо него они стали вести доску со стикерами, на
которых были записаны бизнес-приоритеты. Стикеры распределялись по категори-
ям («Развитие бизнеса», «Контроль затрат», «Производительность» и «Снижение
рисков»), и один или два из самых приоритетных закреплялись за каждой командой.
Глава 7. Командная работа 163
КОНТЕКСТ
Мы знаем, с кем и с чем мы должны работать.
Аудитория
Какие навыки доступны для вашей команды?
Продакт-менеджеры, коучи
Какие ресурсы у вас есть? Кто ваши стейкхол
деры?
Все это — часть контекста вашей команды:
более широкой системы, в которую она встрое-
на. Понимание контекста важно для снижения Если вы не понимаете
риска. Если вы не понимаете контекст, то люди контекст, то люди и ожидания
или ожидания, о существовании которых вы даже могут застать вас врасплох.
не подозревали. легко могут застать вас врасплох.
1
Аджич Г. Impact mapping: Как повысить эффективность программных продуктов и проектов по
их разработке.
164 Часть II. Фокус на ценность
Доступные навыки
Начните с просмотра навыков, доступных вашей команде. Попросите каждого члена
команды представиться и описать навыки и опыт, которыми они владеют. Эти люди
также могут рассказать о любых своих связях или разрешениях, имеющих отношение
к делу. Пока человек будет говорить, фасилитатор может записывать ответы на флип-
чарт. Для удаленных команд можно выделить пространство на вашей виртуальной
белой доске и использовать его в качестве виртуального флипчарта. Назовите этот
список «Перечень навыков».
ПРИМЕЧАНИЕ
В «Разрешения» входят электронные разрешения (допуски), такие как «я имею
возможность просматривать базу данных в эксплуатационной среде»; юридиче-
ские разрешения, такие как «у меня есть корпоративная кредитная карта и право
подписи при покупке оборудования»; социальные разрешения, такие как «мне
разрешается разговаривать с тем расстроенным заказчиком».
1
Этот план основан на [Larsen2016] (гл. 7), с некоторыми изменениями. Я добавил перечень
навыков, частично вдохновленный активностью «Основная группа», и удалил их активность
«Перспективный анализ», чтобы сохранить ее в разделе «Визуальное планирование» главы 8.
Глава 7. Командная работа 165
Границы и взаимодействия
Далее вы создадите контекстную диаграмму, выявляющую все разнообразие групп
людей, с которыми придется работать вашей команде. Начните с подготовки большой
поверхности для диаграммы. (Лучше приготовить ее заранее.) Она должна быть боль-
шой, поэтому скрепите вместе несколько флипчартов на стене или столе либо исполь-
зуйте большую белую доску. Удаленные команды будут использовать виртуальную
доску, как обычно. Нарисуйте в центре круг, представляющий вашу команду.
Когда будете готовы, предложите участникам мозговой штурм, чтобы записать
каждую группу стейкхолдеров, с которой команде необходимо взаимодействовать,
на отдельный стикер. Мыслите очень широко: важен каждый, кто влияет или под-
вергается влиянию работы команды как в позитивном, так и в негативном ключе.
Сюда входят команды разработчиков ПО, с которыми взаимодействует ваша команда,
включая команды — владельцы систем, с которыми будет коммуницировать ваше
ПО; другие группы в компании, отвечающие за маркетинг, продажи и эксплуатацию;
группы вне компании, такие как ваши заказчики, конкуренты и поставщики; и даже
еще более отдаленные группы, например государственные регулирующие органы.
Когда идеи закончатся, пусть люди разместят стикеры вокруг центрального круга,
представляющего вашу команду. Одинаковые стикеры можно объединить. Например,
вы можете сгруппировать вендоров программ в один стикер под названием «Вендоры
ПО», но оставьте отдельный стикер для вашего провайдера облачной инфраструкту-
ры. Похожим образом стикеры с указанием групп, имеющих минимальное влияние
на вашу команду (и наоборот), можно выбросить.
После того как все стикеры окажутся на доске, попросите участников подумать над
тем, что они дают каждой группе стейкхолдеров и что получают от каждой группы.
Пусть они обозначат все эти взаимодействия стрелками и добавят краткое описание.
Если вы рисуете вашу диаграмму на бумаге, то начните с чего-нибудь временного,
типа карандаша или другого стикера, чтобы было легко вносить изменения.
Пока участники работают над диаграммой контекста, подготовьте еще несколько
флипчартов. Озаглавьте их «Необходимые ресурсы» и «Коммуникации, которые не-
обходимо обеспечить» и прикрепите рядом с флипчартами «Необходимые навыки»
и «Необходимые разрешения».
ПРИМЕЧАНИЕ
Agile-команды избегают называть людей ресурсами. Это обезличивает. Под
ресурсами я имею в виду такие понятия, как время, деньги, товары и сервисы.
166 Часть II. Фокус на ценность
ПРИМЕЧАНИЕ
Если принятие решения о том, как продолжить коммуникации, занимает больше,
чем несколько минут, то отложите его до конца встречи. (Только не забудьте по-
том!) Не нужно тратить время остальных участников понапрасну.
Выделенные ресурсы
По завершении двух предыдущих упражнений у вас должно быть три диаграммы,
описывающие, что нужно вашей команде: «Необходимые навыки», «Необходимые
разрешения», «Необходимые ресурсы». Теперь пусть участники одновременно по-
работают над сортировкой стикеров из каждой диаграммы, сгруппировав их в четыре
категории: «строго необходимо», «необходимо», «желательно», «не нужно»1. В про-
цессе сортировки люди могут добавить новые пункты.
Проверьте результаты вместе со всеми присутствующими и убедитесь, что ко-
манды и стейкхолдеры достигли согласия в вопросе о необходимых пунктах и их
категоризации. Небольшие разногласия — это нормально, так что не стремитесь
к совершенству.
1
Это называется приоритизация MoSCoW (must have, should have, could have and won’t have).
Последняя категория обычно называется «не будет» (won’t have), но я называл ее «не нужно»
(don’t need), чтобы отличать от того, что вы хотели бы, но не можете получить.
Глава 7. Командная работа 167
Обязательства спонсора
Завершите обсуждение контекста, снова пригласив
спонсора в комнату, если он не присутствовал при об- См. также
суждении. Если вы также обсуждали изменения в уставе,
имеющие отношение к цели, то сейчас подходящее время Цель (глава 7)
для того, чтобы спонсор утвердил эти поправки. Затем
обратите внимание на потребности команды.
Просмотрите навыки, разрешения и ресурсы, которые ваша команда не мо-
жет получить самостоятельно, и попросите спонсора взять на себя обязательство
обеспечить их. Если он сделает это, то задача выполнена. Решите, кто в коман-
де будет ответственным за напоминания по этим обязательствам и кто еще бу-
дет дополнительно напоминать о них, как было описано в предыдущем подраз-
деле.
Если ваш спонсор не может предоставить
все необходимое, то внимательно изучите воз- Если ваш спонсор не может
можные компромиссы. Как нехватка каждого предоставить все необходимое,
из ресурсов, навыков или разрешений влияет то откровенно поговорите с ним
на способность команды достичь цели? От- о компромиссах.
кровенно поговорите со спонсором о том, чем
он рискует и чего хочет от команды.
В ходе разговора помните, что спонсор должен сделать нелегкий выбор. Обычно
эти люди оказываются перед выбором одной из двух плохих возможностей. Да, спон-
соры владеют бюджетом команды, но их ресурсы не безграничны. Иногда спонсоры
должны сделать трудный выбор между тем, чтобы дать команде все, о чем она просит,
или надеяться на то, что она найдет достаточно ресурсов, позволяющих добиться
результатов и без спонсорской поддержки.
Некоторые элементы все же будут существенными, и без них команда не сможет
достичь своей цели. Если вы не можете получить какие-либо важные ресурсы, то
вам нужно будет проработать со спонсором возможности изменить или отменить
цель либо отложить ее достижение.
168 Часть II. Фокус на ценность
Обновляйте контекст
Когда сессия подготовки устава будет окончена, сохра-
ните копию перечня навыков, контекстную диаграмму См. также
и подтвержденные ресурсы в месте, легкодоступном для
вашей команды. Вы будете обращаться к ним и обнов- Командная комната
(глава 7)
лять их по мере необходимости. Вывесите контекстную
диаграмму на видном месте командной комнаты.
Помните, что вам нужно выделить время на то, чтобы просмотреть планы комму-
никации, которые вы создали, определяя границы и взаимодействия. Обязательно
проконсультируйтесь с вашим спонсором по поводу выделенных ресурсов.
Первые несколько раз, после каждого контакта с группами ваших стейкхолдеров,
уделите некоторое время оценке и корректировке плана коммуникации. Со временем
ваше общение станет комфортным для всех.
Необходимо пересматривать контекст время от времени (примерно каждые шесть
месяцев), чтобы освежить его в памяти каждого участника, обновить информацию
и пересмотреть план коммуникации. Вам не обязательно проводить полномасштаб-
ную встречу с участием стейкхолдеров; будет достаточно провести быстрый пере-
смотр в вашей командной комнате. Пригласите продакт-менеджера, если он еще
не является постоянным членом команды.
Вопросы
Что, если у нас отсутствуют необходимые ресурсы, но спонсор не хочет слушать?
Это трудная ситуация. Если вы знакомы с кем-то имеющим навыки дипломатии
(например, продакт-менеджером, менеджером проекта или коучем), попросите их
помочь донести это сообщение до спонсора. Тем временем работайте с тем, что есть,
и продолжайте напоминать спонсору и бизнес-стейкхолдерам, что от вас ожидают,
что вы сделаете X, Y и Z, но вы можете сделать только X и Z из-за ограниченности
в ресурсах.
Предварительные требования
Описанный здесь сбор информации о контексте требует участия людей, знаю-
щих, как работает ваша организация. Постарайтесь подключить таких людей
к проекту.
Показатели
Когда ваша команда понимает свой контекст и обладает необходимыми подтверж-
денными ресурсами:
zz она имеет доступ ко всему, что ей требуется для выполнения задачи;
zz ее не застать врасплох внезапно появившейся и неизвестной ранее группе стейк-
холдеров или требованию;
zz общение с группами стейкхолдеров ровное и стабильное.
Глава 7. Командная работа 169
Альтернативы и эксперименты
Работа над контекстом для устава позволяет вам получить много информации о си-
туации, в которой находится команда, но особенно важны следующие три результата.
1. Знание того, кто ваши группы стейкхолдеров и что вам нужно друг от друга.
2. Определение способов, с помощью которых вы будете общаться друг с другом.
3. Корректировка вашей цели и ожиданий стейкхолдеров в соответствии с навы-
ками, разрешениями и ресурсами, доступными команде.
Программа сессии подготовки устава, представленная здесь, — это только один из
способов, позволяющих достичь этих результатов. Вы можете применить любой подход.
Некоторые организации, вместо того чтобы проводить сессии подготовки уста-
ва, поручают руководителям проектов или бизнес-аналитикам провести интервью
со стейкхолдерами и, исходя из результатов, создать набор документов. Это рабо-
чий способ, но все же не стоит недооценивать значимость коллективной работы
команды и заинтересованных сторон над тем, чтобы узнать точки зрения друг друга.
Проведение сессии в сотрудничестве с ключевыми стейкхолдерами — прекрасная
возможность создать взаимосвязи и обоюдную эмпатию. Это нечто гораздо более
интуитивное и запоминающееся, чем пачка документов, на чтение которых некоторые
люди так и не найдут времени.
Вы все еще сможете проводить эксперименты, даже если будете придерживаться
базовой идеи сессии подготовки устава. Начните с практики, описанной здесь, пред-
почтительно задействовав опытного фасилитатора, просто чтобы получить некоторые
представления о том, как это должно работать. Затем начните экспериментировать.
Например, долгая двухдневная встреча может быть очень изнуряющим мероприя
тием. А что, если разделить ее на несколько более коротких? А как насчет специ-
альных видов деятельности? Можете подумать о способах, позволяющих улучшить
или заменить эти виды чем-то другим. Что, если сделать больше подготовительной
работы заранее или пригласить других людей?
Если ваша организация большая, то предложите провести такие сессии для
других команд. Они ценны для любых команд, не только Agile, и даже не только
команд разработки ПО. Эти сессии проводятся не только тогда, когда команда лишь
создается; если она раньше не согласовывала устав, то ей наверняка будет полезна
такая сессия независимо от того, насколько долго люди работают вместе. У вас будет
много возможностей для эксперимента, и есть множество вещей, которые вы можете
попробовать. Подумайте, чему вы можете научиться.
СОГЛАСОВАНИЕ
Мы договорились о том, как будем работать
вместе. Аудитория
1
Эта программа основана на [Larsen2016] (гл. 6), с некоторыми изменениями.
Глава 7. Командная работа 171
3. Почему я думаю, что эта группа хорошо подходит для достижения цели команды?
4. Каков самый важный факт из того, что другие должны знать обо мне, чтобы эф-
фективно работать со мной?
5. Что все это для меня значит? Что я хочу получить от участия в работе команды
и достижении ее цели?
Сделайте круг по комнате, задавайте один вопрос за раз, дайте ответить каждому.
Люди могут пропустить свою очередь, если им надо время подумать. Вернитесь к ним
позже, прежде чем переходить к следующему вопросу.
Этот разговор поможет членам команды увидеть друг друга как людей в целом,
а не только имена, лица и названия должностей. Если у вас удаленная команда, то
постарайтесь провести этот разговор с включенным видео.
Задайте стандарты
Стандарты — это особые рабочие соглашения, применяемые к определенным типам
задач. Примерами могут служить стандарты кодирования, рекомендации по UI-
дизайну и эксплуатационные стандарты.
Стандарты могут становиться источниками конфликтов, если к ним не обра-
щаются, поэтому будет лучше сразу дать им определение. Их содержание не очень
важно. Вы будете их расширять и корректировать с течением времени. Помните,
Глава 7. Командная работа 173
что в Agile мало решений, которые нельзя изменить. Уорд Каннингем сказал об этом
так (https://oreil.ly/IcikH):
«Переломный момент в моей программистской карьере наступил, когда я осоз-
нал, что мне не нужно побеждать в каждом споре. Допустим, я разговаривал
с кем-то о коде и говорил: “Я думаю, что лучший способ это сделать — это А”.
А они отвечали: “Мы думаем, что лучший способ это сделать — это Б”. Я гово-
рил: “Нет же. Это точно А”. Они отвечали: “А мы хотим это сделать с помощью
способа Б”. Поворотный момент настал, когда я смог сказать: “Хорошо. Делайте
с помощью способа Б. Если я ошибаюсь, это не причинит нам особого вреда.
Даже если я прав, а вы делаете Б — нам и это не слишком повредит, поскольку мы
можем исправить ошибки. Так что давайте узнаем, является ли это ошибкой”».
Помимо форматирования
Однажды я вел команду из четырех программистов, имевших очень сильно
различающиеся подходы к форматированию. Когда мы обсуждали стандарты
кодирования, я перечислил три разных подхода к скобкам и табуляции. У каж-
дого был свой ярый сторонник. Я не хотел, чтобы мы погрязли в спорах, поэтому
сказал, что все участники команды могут использовать тот стиль скобок, который
они предпочитают.
Результат был предсказуем: у нас было три разных подхода к форматированию
нашего кода. Я даже увидел три разных варианта отступа в пределах одного
короткого метода.
Знаете, что меня удивило? Это было не так уж плохо. Конечно, текст программы
выглядел скверно, и я бы предпочел что-то более последовательное, но все же
код был читаемым. В конце концов, остальные наши стандарты кодирования
имели большее значение, чем форматирование.
Мы договорились, что важно именовать переменные и короткие методы понятным
образом. Мы договорились использовать утверждения (assertions), чтобы быстро
обнаруживать неправильно работающий код, не оптимизировать без измерений
и никогда не передавать пустые ссылки (ссылки, которые не ссылаются ни на какой
объект, null references) между объектами. Мы договорились о том, как надо и не надо
обрабатывать исключения (exceptions), что делать с отладочным кодом (debugging
code), когда и куда регистрировать события (events). Эти стандарты помогли нам
гораздо больше, чем это мог бы сделать единый стиль форматирования. Каждый
стандарт приносил конкретную пользу. Вероятно, именно поэтому мы смогли до-
говориться о них, когда не смогли договориться о форматировании.
Не поймите меня неправильно: иметь единое форматирование было бы лучше!
Но, собирая в единое целое ваши стандарты программирования, не загоняйте
себя в ловушку бесконечных споров о форматировании.
Обновляйте соглашения
Ваш список рабочих соглашений, не включая стандарты, позволит сформировать
привычки, над созданием которых вы активно работаете. Лучше будет ограничить
этот список пятью пунктами. Когда привычка станет автоматической, удалите ее из
списка, чтобы освободить место для нового соглашения.
Глава 7. Командная работа 175
Придерживайтесь договоренностей
Люди совершают ошибки. Предположим, ваши коллеги профессиональны и имеют
добрые намерения. Если кто-то не выполняет соглашения, то допустим, что у него
есть причина, несмотря на свидетельства обратного. Ваша задача — найти эту при-
чину и разобраться с ней. Такой подход продемонстрирует уважение к другим и по-
высит их уважение по отношению к вам.
Используя парное и групповое програм-
мирование, а также коллективное владение См. также
кодом, команда может находить ошибки
и поддерживать самодисциплину. Кроме Парное программирование (глава 12)
того, эти практики позволяют обсуждать Групповое программирование
вопросы, не касающиеся ваших командных (глава 12)
соглашений. Вдобавок они дают прекрасную Коллективное владение кодом
возможность улучшить ваши стандарты; на- (глава 12)
много легче предлагать улучшение, сначала
обсудив его с кем-либо.
Автоматизированное соблюдение стандартов, как правило, менее эффективно.
Некоторые используют автоматизированные системы для проверки своего исходного
кода на соответствие стандартам или автоматически переформатируют код после
регистрации. Это может работать, если команда все согласовала, однако обычно это
заводит команды в ловушку чрезмерного принуждения.
И даже хуже, люди часто используют эти автоматические инструменты как ду-
бинку, чтобы навязать свое мнение. Возникает соблазн получить техническое реше-
ние межличностной проблемы, однако ничего не получится. Нужно сначала решить
межличностную проблему. Инструменты не знают нюансов. В лучшем случае эти
разногласия будут скрыты. Инструменты не решат проблему, а просто уберут ее из
виду, и она незаметно продолжит расти.
Вместо этого лучше начать, предпо-
Начните с предположения,
ложив, что человек имел добрые наме-
что имелись добрые намерения.
рения. Возможно, он неправильно понял
176 Часть II. Фокус на ценность
соглашение, или думает, что оно больше неприменимо, или по каким-то причинам
не может соблюдать это соглашение.
Если кто-то постоянно нарушает командные соглашения, то поговорите с ним
наедине, чтобы узнать, нет ли с его стороны принципиального несогласия. Займите
позицию коллективного решения проблем. Вместо того чтобы спросить: «Почему
ты не работаешь с нулевыми значениями, как мы договаривались?», задайте вопро-
сы: «Что ты думаешь о стандарте работы с нулями, о котором мы договорились?
Не нужно ли нам его изменить?» Примите к сведению все возражения, доведите их
до всей остальной команды и подумайте об изменении соглашения.
Если кто-то согласен с соглашением, но все же не соблюдает его, то, возможно,
оно применимо не в каждой ситуации. Спросите о конкретных случаях, замеченных
вами. И повторюсь: делайте это в манере сотрудничества, а не конфронтации. Скажи-
те нечто вроде: «Я согласен с тобой насчет того, как мы должны работать с нулями.
Можешь объяснить, что происходит в этом случае в данной функции? Я не понимаю,
почему этот код не проверяет на нули».
Во время такого обсуждения вы можете узнать, что человек не понимает сути
соглашения. К этому времени вы уже должны быть в ситуации, которая позволя-
ет обсудить соглашение и его значение. Если это младший член команды и ему
нужна помощь, то координируйте свои действия с остальной командой, чтобы
убедиться в том, что более опытные коллеги-наставники уделяют им достаточно
внимания.
Есть еще одна возможность для команд — новичков в Agile. Изменение рабо-
чих привычек действует разрушительно и может заставить людей думать, что
они потеряли контроль. Иногда они реагируют, отказываясь менять те или иные
мелочи. Упорное желание сохранить определенный стандарт или стиль общения,
независимо от желания остальной части команды, может быть симптомом такой
реакции.
В этом случае, возможно, лучшее решение — позволить нарушению просуще-
ствовать несколько месяцев. Со временем, привыкнув к изменениям в своей среде,
члены команды расслабятся и будут более склонны идти на компромисс.
Вопросы
Что, если мы не можем договориться относительно стандартов и рабочих согла-
шений?
Можно оказать давление на людей, чтобы они приняли соглашение, с которым
не согласны, но это плохая идея. Это несогласие просто будет все время проявляться
в других разговорах.
Вместо этого попытайтесь отпустить ситуацию. Неужели это рабочее соглашение
действительно настолько важно? Сфокусируйтесь на том, с чем вы все согласны.
В процессе работы ваши разногласия разрешатся.
Если это не то, что можно просто проигнорировать, то вашей команде нужна по-
мощь профессионального медиатора. Поговорите с вашим коучем или руководителем
о поиске того, кто может помочь. Такой человек может быть в штате вашего отдела
кадров. В худшем случае может оказаться, что ваша группа просто не подходит для
того, чтобы быть командой, и вам лучше собрать ее из других людей.
У нас есть предыдущая работа, которая не отвечает нашим стандартам. Надо ли
нам ее исправлять?
Тратить много времени на исправление того, что не является неисправностью,
дорого и рискованно, поэтому если ваша предыдущая работа в целом работает, то
оставьте ее и займитесь другими проектами. Приводите каждую часть в соответствие
со стандартом, когда понадобится внести изменения.
Некоторые стандарты, такие как форматирование кода, можно автоматизиро-
вать. Не тратьте на это слишком много времени, но если для вас это не трудно, то
лучше сделать. Не забудьте скоординироваться с другими командами в вопросе
автоматизированных изменений, чтобы не повлиять на их работу, и отделите авто-
матизированные изменения от обычных, чтобы вашу историю контроля изменений
было легко читать.
Предварительные требования
Члены команды должны хотеть работать как команда, прежде чем смогут создать
эффективные рабочие соглашения. Больше информации о командной поддержке
изменений можно найти в главе 5.
Показатели
Когда ваша команда имеет эффективные рабочие соглашения:
zz она использует рабочие соглашения для предотвращения и разрешения кон-
фликтов;
zz ваши стандарты повышают читабельность и удобство сопровождения вашего
кода и других артефактов;
zz ваши стандарты позволяют членам команды легче понимать незнакомые части
системы.
178 Часть II. Фокус на ценность
Альтернативы и эксперименты
Некоторые команды работают вместе настолько хорошо, что им не нужны четкие
соглашения. Их соглашения — подразумеваемые.
Однако прямое обсуждение соглашений поможет новым командам и даже боль-
шинству существующих избежать разрушительных споров в будущем. Точный
формат дискуссии не важен. Формат, представленный в книге, был выбран потому,
что является относительно быстрым и неконфликтным, но вы можете использовать
другой подход.
Придерживайтесь подхода, описанного в этой книге, пока не проведете несколько
успешных обсуждений. Согласование может быть спорным, особенно когда коман-
ды переходят к конкретным соглашениям, таким как стандарты, и именно поэтому
в книге подчеркивается необходимость отмены спорных соглашений.
Получив такой опыт, поэкспериментируйте с изменениями. Помогут ли обсужде-
ния в малых группах или интервью? Можно ли что-то подготовить заранее? Будут ли
другие упражнения более быстрыми или эффективными? Вы можете пробовать
разные варианты, не ограничивая себя.
Я люблю свою работу. Мне нравится решать проблемы, писать хороший код, на-
блюдать за прохождением тестов и особенно удалять код при рефакторинге.
Но если я в команде, которая имеет неясные цели, низкую коллективную ответ-
ственность и погружена во внутренние распри, я буду просыпаться в ужасе от пер-
спективы идти на работу. Я буду находиться в офисе, но не смогу удерживаться от
соблазна проводить утро за чтением своей электронной почты, а потом буду вяло
копаться в коде, одновременно просматривая мало относящиеся к делу сайты.
Мы все бывали в такой ситуации. Мы профессионалы, поэтому стремимся делать
свою работу качественно, даже если чувствуем себя деморализованными. Но все же
вспомните, когда вы были наиболее продуктивными. Вы замечаете, насколько велика
разница, когда вы просыпаетесь и чувствуете стремление начать работу? Не чувству-
ете ли вы себя более удовлетворенным, закончив работу вовремя в конце дня и зная,
что вы сделали нечто важное и нужное?
Практика «Энергичная работа» заключается
в том, что профессионалы могут хорошо выпол- Профессионалы работают
значительно качественнее
нять свою работу и в трудных обстоятельствах,
и продуктивнее, когда полны
однако работают качественнее и продуктивнее,
энергии и мотивированны.
когда полны энергии и мотивированны.
Глава 7. Командная работа 179
Иметь возможность питаться здоровой пищей на работе — еще один способ под-
держивать энергию и активность. Хороший выбор — фрукты и овощи. Пончики
и другая подобная нездоровая, но популярная еда способствуют спаду активности
во второй половине дня.
Природа работы также имеет значение.
Не каждая команда может накормить бедных См. также
или решить NP-полные задачи, но внятная
четкая цель может оказать большое влияние. Цель (глава 7)
Сформулировать и объявить цель команды
входит в обязанности членов команды, име-
ющих навыки менеджмента продукта. См. также
Для того чтобы быть внятной, цель должна
быть также достижимой. Ничто не разруша- Прогнозирование (глава 10)
ет мораль настолько быстро, как ответствен-
ность за недостижимую цель. Если команде необходимо отвечать за соблюдение
определенных сроков и объема работ, то убедитесь, что цели реалистичны и основаны
на прогнозах, сделанных командой.
У каждой организации есть политики, имеющие отношение к цели. В одних
случаях они приводят к здоровым переговорам и компромиссам. В других — могут
приводить к необоснованным требованиям и обвинениям. Члены команды, имеющие
навыки дипломатии, должны заниматься вопросами организационных политик,
информируя остальных о том, что важно, и ограждать от неважного.
Эти члены команды также могут помогать команде, оберегая ее от необязатель-
ных совещаний и конференц-звонков. Если предоставить информативное рабочее
пространство и соответствующие дорожные
карты, то необходимость в статус-митингах См. также
отпадает. При наличии множества внешних
помех рассмотрите возможность ежедневно Информативное рабочее про-
резервировать основные рабочие часы (может странство (глава 9)
быть, для начала всего час или два), в тече- Дорожные карты (глава 10)
ние которых все договорятся не беспокоить
команду.
В каждой организации есть стандартные процессы и технологии, которые коман-
да должна использовать. Когда эти стандарты препятствуют рабочему процессу, это
может разочаровывать и деморализовывать членов команды. Постарайтесь объяснять
«почему» вместе с «что», стоящими за каждым таким стандартом, и давать командам
возможность обсудить создание исключений. Руководители команды могут помогать
команде отстаивать эти изменения и преодолевать бюрократию.
Наконец, команды, находящиеся на уровне нормализации (см. пункт «Нормализа-
ция: мы — № 1» главы 11), обычно полны энергии. Им еще и очень весело. Вы можете
узнать такую команду по тому, насколько ее членам нравится проводить время вме-
сте. Они вместе ходят на обед, обмениваются
шутками и даже могут общаться в нерабочее См. также
время. Вы можете развиться в команде до
уровня нормализации, обращая внимание на Динамики команды (глава 11)
динамики команды.
Глава 7. Командная работа 181
Делайте перерывы
Если вы стали больше ошибаться, чем продвигаться в работе, то пора сделать
перерыв. Однако если вы похожи на меня, то в моменте как раз труднее всего
остановиться. Мне обычно кажется, что решение вот-вот обнаружится (даже если
это длится последние 45 минут), и я не хочу останавливаться, пока не найду его.
Поэтому полезно, чтобы кто-то другой напомнил мне, что надо остановиться.
Сделав перерыв или хорошенько выспавшись ночью, обычно я сразу нахожу
ошибку.
Иногда вполне достаточно перекусить или
немного прогуляться. Программистам может См. также
помочь предложение поменяться в своей паре
местами. Однако, если уже конец рабочего дня, Парное программирование
(глава 12)
лучше отправиться домой.
В физической командной комнате обычно Командная комната (глава 7)
заметно, когда кому-либо нужен перерыв.
Сердитая сосредоточенность, ругань с компьютером и резкие движения — это
знаки. Если кто-то ушел в себя, не общается — это тоже может значить, что
пора сделать перерыв. Когда я замечаю пару программистов, шепчущихся друг
с другом, я спрашиваю их, сколько времени у них прошло с последнего успешно
прошедшего теста. Часто я получаю робкий ответ и тогда напоминаю им, что пора
отдохнуть.
Предложение сделать перерыв требует определенной деликатности. Если вас
уважают как лидера, то вы можете просто сказать людям, чтобы перестали работать.
В противном случае отвлеките их от проблемы на минуту, чтобы они могли приве-
сти мысли в порядок. Попросите их немного помочь вам в чем-то или прогуляться
с вами, чтобы обсудить проблему, с которой вы столкнулись.
Вопросы
Я работаю в стартапе, и нормальной рабочей недели мне просто не хватает. Могу ли
я работать дольше?
Среда стартапа зачастую наполнена азартом и духом товарищества. Это приводит
к увеличению энергии и может значить, что вы можете работать больше, не теряя
способности к концентрации. В то же время стартапы иногда путают долгие рабочие
часы с преданностью делу. Будьте внимательны, не позволяйте преданности делу
перевесить здравую мысль о том, что вы слишком устали, чтобы вносить полезный
вклад.
У нас важный дедлайн, и нет никакой возможности все успеть, кроме как работать
круглосуточно, не поднимая головы. Нам нужно временно отказаться от обычного
режима работы?
Ничто не может сравниться с многочасовыми хакатонами, когда команда прино-
сит пиццу, все упорно работают не покладая рук и в последний момент все наконец
получается. Мощный марш-бросок перед финишной чертой может помочь команде
сплотиться, позволяя им чувствовать удовлетворение, стоя перед трудностями.
Однако…
182 Часть II. Фокус на ценность
Предварительные требования
Это контрпродуктивно, но в некоторых организациях судят о сотрудниках по коли-
честву часов переработок. В такой обстановке вам, возможно, лучше пожертвовать
энергичной и дополнительной работой. Это личный выбор, который можете сделать
только вы и ваша семья.
И наоборот, энергичная работа — не повод бездельничать. Создавайте атмосферу
доверия честным ежедневным трудом.
Показатели
Когда ваша команда энергична:
zz в ней присутствуют азарт и дух товарищества;
zz команда вовлечена в свою работу и стремится сделать ее как можно лучше;
zz команда демонстрирует постоянный еженедельный прогресс, и вы чувствуете,
что способны поддерживать его сколь угодно долго;
zz вы цените здоровье больше, чем краткосрочный прогресс, и чувствуете себя про-
дуктивными и успешными.
Альтернативы и эксперименты
Эта практика также называется «Устойчи-
вый темп», и альтернатива ей — хм… «не См. также
устойчивый». Но некоторые организации
делают энергичную работу еще более труд- Парное программирование (глава 12)
ной. Если это происходит в вашей органи- Групповое программирование
зации, то парное или групповое программи- (глава 12)
рование может помочь уставшим членам
команды оставаться сконцентрированными и находить ошибки друг друга. Как
ни странно, работа над вашим ПО займет больше времени (потребуется найти и ис-
Глава 7. Командная работа 183
1
ДеМарко Т. Человеческий фактор. Успешные проекты и команды.
2
Шеридан Р. Работа мечты. Как построить компанию, которую любят.
ГЛАВА 8
Планирование
Источники планирования
Agile всегда был адаптивным. Подзаголовок первой книги по экстремальному про-
граммированию звучал как «Примите перемены» (Embrace Change) [Beck2000a].
В предисловии к первой книге о Scrum подчеркивалось, что для снижения риска
необходимо как можно раньше вносить коррективы.
Адаптивность занимает настолько важное место в Agile, что трудно установить ее
конкретные источники. В практике «Адаптивное планирование» объединены идеи,
которые я видел и использовал многие годы; огромное влияние оказала книга
Software by Numbers [Denne2004]. Источники практик «Инкрементные требования»
Глава 8. Планирование 185
ИСТОРИИ
Мы планируем нашу работу небольшими
частями, ориентированными на интересы Аудитория
заказчика. Вся команда
К А Р ГО - К УЛ ЬТ
Мастерская писателей
«Нам нужен тренинг на тему, как лучше писать истории, — вздыхает
Рафаэла. — Я уже устала от того, что наша команда делает не то,
что нужно».
Вы не настолько уверены в этом. «Но разве истории не должны
быть просто напоминанием о необходимости поговорить? — спра-
шиваете вы. — Может, нам нужно почаще говорить с владельцем
продукта в процессе работы, задавать ему вопросы, показывать,
над чем мы работаем, — то есть получать обратную связь, чтобы
понимать, делаем ли мы правильный продукт?»
Рафаэла фыркает: «Да. Желаю удачи в этом. Нет, что нам нужно — это чтобы вла-
дельцы продукта Лучше. Писали. Истории. Все на это жалуются. Я позабочусь
о том, чтобы вытрясти на это бюджет. Уверена, я смогу найти инструктора, который
скажет владельцам продукта то, что они должны услышать».
ПРИМЕЧАНИЕ
Хороший способ сделать ваши истории ориентированными на заказчика — пред-
ложить, чтобы заказчики в команде писали их самостоятельно.
Крошечные истории
Чем больше вы разделяете историю, тем труднее может быть сохранять ее ориенти-
рованность на заказчика. Не сдавайтесь. Если не получается, то, по крайней мере,
опишите техническую задачу бизнес-терминами. Это позволит заказчикам в команде
понять суть и сохранить контроль над приоритетами. Вдобавок так вам будет легче
объяснять ваши планы и прогресс другим людям.
1
Кон М. Agile: оценка и планирование проектов.
190 Часть II. Фокус на ценность
Специальные истории
Большинство историй добавляет новые возможности в ваше ПО, но все, что требует
внимания команды и не является частью ее ежедневной работы, также нуждается
в истории.
Нефункциональные истории
Производительность, масштабирование и стабильность (нефункциональные требова-
ния) тоже должны быть запланированы с помощью историй. Как и всем историям, им
нужна конкретная цель, имеющая ценность для заказчика. Однако, в отличие от других
историй, вам понадобится помощь разработчиков, чтобы ее определить. Недостаточно
сказать: «ПО должно быть стабильным» или «ПО должно быть быстрым». Вы долж-
ны быть в состоянии описать, насколько стабильным или быстрым оно должно быть.
Создавая нефункциональные истории, подумайте о приемлемой производитель-
ности (минимально необходимой для удовлетворительных результатов) и наилучшей
возможной производительности — точке, за которой дальнейшая оптимизация мало-
полезна. Вам не нужно записывать эти цифры на карточке или сразу определяться
с ними, но часто бывает полезно это сделать.
Зачем две цифры? Нефункциональные требования, особенно оптимизация про-
изводительности, могут отнять бесконечное количество времени. Иногда вы рано
достигаете наилучшей цели: так вы узнае́те, когда пора остановиться. В других
случаях у вас могут быть сложности в достижении приемлемой цели: благодаря
этому вы понимаете, когда продолжать. Например, критерий производительности
для веб-страницы может быть таким: «Поддерживать 500–1000 запросов в минуту,
с задержкой 50–200 мс».
Как и истории для багов, нефункциональные истории может быть трудно изме-
рить. Для них вы также можете применять ограничения по времени.
Спайк-истории
Иногда разработчики не могут оценить раз-
мер истории, поскольку недостаточно знают Цель спайк-истории в том, чтобы
о технологии, необходимой для ее реализа- измерить другую историю.
ции. Когда это случается, создайте спайк-
историю (spike story) для исследования технологии. Цель такой истории в том,
чтобы измерить другую историю, а не выработать решение или исследовать все ее
уголки и закоулки. Например, «разобраться, нужно ли разделить историю “отправить
электронное письмо HTML” на более мелкие истории». Или более кратко: «спайк
“отправить электронное письмо HTML”».
Они называются спайк-историями, по- См. также
скольку часто используют спайк-решение
для исследовательской работы. Но это Спайк-решения (глава 13)
не обязательно.
Если вы все же делаете отдельную историю для очистки кода, говорите о ней в тер-
минах бизнес-выгоды, которую она дает. Часто эта выгода заключается в уменьшении
количества времени, необходимого на разработку. Плохой код подвержен ошибкам,
и, как правило, нужно много времени, чтобы безопасно его изменить. Так, например,
вместо того чтобы говорить, что нужен «рефакторинг сервиса аутентификации»,
скажите, что требуется «уменьшить вероятность ошибок аутентификации» или
«уменьшить время, необходимое для изменения параметров аутентификации».
Скорее всего, вы не сможете количественно оценить подобное улучшение, но
будьте готовы привести примеры, иллюстрирующие потенциальные преимущества.
Например, такие: «Вы знаете, что мы продолжаем сталкиваться с проблемами и за-
держками, когда меняем что-то связанное с входом в систему? Так вот, то, что мы
предлагаем, решит данную проблему».
Работая с историями для очистки, не имеющими
четкого момента, когда надо остановиться, используй- См. также
те временные рамки. Чтобы убедиться, что вы можете
остановиться, когда ваше время истекло, избегайте Рефлексивный дизайн
полного переписывания кода. Вместо этого делайте (глава 14)
его постепенный рефакторинг, поддерживая код в ра- Рефакторинг (глава 13)
бочем состоянии в любое время.
Вопросы
Наши заказчики разбираются в разработке. Нужно ли нам все же писать истории,
ориентированные на заказчика?
Писать истории, ориентированные на заказчика, гораздо труднее, чем истории,
ориентированные на разработчика. Поэтому сложно удержаться от соблазна избежать
этого под каким-нибудь предлогом. «Наши заказчики не возражают против историй,
ориентированных на разработчика» — один из таких предлогов.
194 Часть II. Фокус на ценность
Предварительные требования
Истории — не замена требованиям. Вам
нужен еще один способ углубиться в дета- См. также
ли — либо с помощью заказчиков в команде
и инкрементных требований (Agile-способ), Инкрементные требования (глава 8)
либо используя документ с требованиями
(традиционный способ).
Показатели
Когда вы правильно применяете истории:
zz заказчики в команде понимают работу, которую они утверждают и планируют;
zz вам легко объяснить стейкхолдерам, над чем работает команда и почему это
важно;
Глава 8. Планирование 195
Альтернативы и эксперименты
Основное различие между историями и составными элементами большинства планов
заключается в том, что истории ориентированы на заказчика. Если вы по какой-либо
причине не можете использовать такие истории, то заказчики не смогут эффектив-
но участвовать в планировании. Это сведет на нет одно из основных преимуществ
Agile — возможность создавать лучшие планы, объединяя знания и представления
заказчиков и разработчиков. Кроме того, вам будет трудно демонстрировать прогресс
стейкхолдерам. К сожалению, никакая другая практика здесь не поможет.
Истории — простая идея, но они связаны с вечной проблемой разработки ПО:
как принять решение, что именно создавать. Простая идея в сумме с серьезной про-
блемой приводят к тому, что у каждого участника имеется собственный взгляд на
истории. Вы можете найти онлайн любые шаблоны и советы по написанию историй.
Все они будут претендовать на то, что смогут решить эту проблему или что с ними
команда будет лучше писать ПО.
Все эти эксперименты, как правило, упускают суть. Истории — для разговора, а не
для бумаги. Любое изменение, которое направляет фокус на документирование, а не
на общение (шаблон, детализация, систематизация историй), движется в неверном
направлении.
Подобным же образом истории — не способ решать, что вы будете создавать. Они
служат лишь напоминанием. Есть много очень хороших способов понять потреб-
ности заказчиков и бизнеса и претворить это понимание в жизнь. (О некоторых из
них рассказывается в разделе «Визуальное планирование» далее в текущей главе.)
Не используйте истории для формирования понимания бизнеса.
Сначала сформируйте для себя понимание бизнеса, примите решение и исполь-
зуйте истории, чтобы напомнить себе об этих решениях и их обсуждениях.
Джефф Паттон говорит, что истории — как фотографии из отпуска: напоминают
вам, что происходило. Истории просто служат напоминанием, поэтому не должны
быть сложными. Когда будете экспериментировать с историями, подумайте о том,
чтобы придать большее значение разговорам и меньшее значение самой истории,
при этом сделав достаточно для того, чтобы напомнить людям предмет обсуждения
и принятое решение. Улучшайте отпуск, а не фотографии.
Наконец, еще одной распространенной альтернативой является отслеживание
историй в электронной таблице или инструменте отслеживания (трекинга) задач,
а не на индексных карточках. Это может облегчить чтение списков историй, но за-
трудняет визуализацию и взаимодействие. Это потеря, которую трудно оценить,
не имея определенного опыта. Поработайте с карточками по меньшей мере три месяца,
прежде чем пробовать альтернативы. Даже если у вас виртуальная команда, лучше
используйте виртуальные индексные карточки на виртуальной доске, а не таблицы
и системы трекинга.
196 Часть II. Фокус на ценность
АДАПТИВНОЕ ПЛАНИРОВАНИЕ
Мы рассчитываем на успех.
Аудитория
Представьте, что вас освободили от предва-
рительных планов. «Увеличьте рентабельность Продакт-менеджеры,
инвестиций, — сказал ваш босс. — Мы уже обсуж- заказчики
дали цели этой команды. Я рассчитываю, что вы
проработаете детали. Можете написать собственные планы и сами установить даты
релизов — просто сделайте так, чтобы мы получили действительно ценный продукт».
И что теперь?
Ценные инкременты
Создавайте ваши планы на основе ценных ин- Создавайте ваши планы на
крементов (valuable increments)1. У них есть три основе ценных инкрементов.
характеристики.
1. Пригодность для релиза. Заканчивая работу над инкрементом, вы можете его вы-
пустить и пожинать плоды своих усилий, даже если никогда больше не будете
над ним работать.
2. Ценность. Данный инкремент некоторым образом приносит ценность вашей
организации (см. врезку «Что ценно для организаций?» в главе 3).
3. Инкрементность. Инкремент не делает все сразу. Это только один шаг в нужном
направлении.
Не путайте ценные инкременты (valuable increments) с потенциально поставля-
емыми инкрементами (potentially shippable increments) — еще одним общим терми-
ном в сообществе Agile. Последние касаются наличия технической возможности
у команды делать релизы изменений. Ценные инкременты — это те изменения, ко-
торые действительно приносят ощутимую пользу вашему бизнесу.
Точно так же ценный инкремент может быть
выпущен только тогда, когда достигнута его цен-
ность. Команды, использующие непрерывное См. также
развертывание, могут разворачивать свое ПО не-
сколько раз в день, но оно не будет выпущено до Непрерывное развертывание
(глава 15)
тех пор, пока не будет переключена конфигурация
и данное улучшение продукта не станет доступно
его целевой аудитории.
Ценные инкременты обычно подпадают под следующие категории.
zz Прямая ценность. Вы создаете, меняете или ремонтируете что-либо имеющее
ценность. Оно становится выпущенным, когда ваша организация может пожинать
1
В первом издании этой книги вместо этапов улучшения продукта, или инкрементов (valuable
increments), я использовал термин «минимальная рыночная функция» (Minimum Marketable
Feature, MMF) из [Denne2004]. Инкременты представляют ту же идею, но я изменил название,
поскольку не все то, что ценно, является востребованным на рынке или функциональным.
Глава 8. Планирование 197
1
A/B-тестирование — это когда вы показываете разные элементы различным группам людей
и оцениваете, какой из элементов дает лучшие результаты.
198 Часть II. Фокус на ценность
Сценарий А Сценарий Б
Общие затраты 4,312 млн долларов 4,712 млн долларов
Выручка 5,600 млн долларов 7,800 млн долларов
Инвестиции 2,760 млн долларов 1,640 млн долларов
Возврат 1,288 млн долларов 3,088 млн долларов
Чистая приведенная стоимость @ 10 % 0,194 млн долларов 1,594 млн долларов
Внутренняя норма доходности 12,8 % 36,3 %
200 Часть II. Фокус на ценность
Разделите инкременты
Как показали примеры, чем меньше будут инкременты, на которые вы разделите
ваш продукт, тем более ценной будет работа вашей команды. Помимо этого, каждый
инкремент представляет собой возможность изменить направление, не понеся по-
терь. Если вы измените направление в середине работы над инкрементом, то она
будет выполнена частично и ее придется отложить на неопределенный срок или
выбросить. Когда же инкремент завершен, вы можете изменить направление работы,
ничего не теряя.
Чем меньше будут ваши инкременты, тем чаще
вы можете адаптировать ваши планы и тем боль- Чем меньше будут ваши
ше вы будете соответствовать философии Agile. инкременты, тем больше
В идеальном мире ваши инкременты должны вы будете соответствовать
быть разделены на самые мелкие базовые фраг- философии Agile.
менты, которые все еще могут иметь ценность,
оправдывающую их релиз.
В реальном мире трудно сделать эти инкременты настолько маленькими, осо-
бенно поначалу. Со временем вы, вероятно, научитесь видеть способы дальнейшего
разделения инкрементов. Можно начать с лучшего предположения и разделить их
позже. Agile — итеративный процесс. У вас будет множество возможностей для со-
вершенствования.
КЛЮЧЕВАЯ ИДЕЯ
ПРИМЕЧАНИЕ
Некоторые команды используют практику непрерывного развертывания для
развертывания своего кода несколько раз в день, но развертывание кода — это
не то же самое, что релиз инкремента. Релиз инкремента не выполнен до тех пор,
пока недоступен для использования. Для команд, использующих непрерывное
развертывание, в релиз обычно входит изменение параметров конфигурации.
ПРИМЕЧАНИЕ
Фреймворк SAFe определяет Agile Release Train как контейнер для команд, что
является неудачным переопределением термина1. Здесь я использую более
простое оригинальное определение. Поезд с релизами — это просто заплани-
рованное расписание релизов. Не придавайте ему дополнительного смысла.
К А Р ГО - К УЛ ЬТ
1
Термин «поезд с релизами» появился задолго до SAFe. Самые ранние известные мне упоми-
нания о нем есть в фреймворке разработки программного обеспечения 1993 года от компании
Sun, который определяет этот термин таким же образом, как и я в этой книге. Данный документ
отсутствует в публичном доступе, но [Rothman1998] ссылается на этот термин и использует
похожее определение. Большое спасибо Говарду Феару и Дэйву Хаунслоу за то, что нашли эти
ссылки.
Глава 8. Планирование 203
1
Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.
204 Часть II. Фокус на ценность
MVP — это не обязательно релиз или продукт в традиционном смысле. Это экс-
перимент, и он может быть у вас не один. По сути, настоящие MVP наиболее часто
используются командами оптимизации.
Является ли ваш первый инкремент минимально жизнеспособным продуктом
в понимании Эрика Риса или просто наименьшим инкрементом, который понравится
вашим покупателям и пользователям, зависит от вас.
Пример инкремента
В 2005 году маленькая команда запустила Writely, онлайн-приложение для об-
работки текстов. В те годы, как и сейчас, рынок текстовых процессоров был уже
достаточно развитым, поэтому создание минимального первого инкремента
такого продукта могло казаться невозможным. Нужно было приложить много
усилий, просто чтобы вступить в соревнование, не говоря уже о том, чтобы выдать
что-то новое и убедительное. В необходимый набор функций входили базовое
форматирование, проверка орфографии и грамматики, таблицы, рисунки, печать…
список мог быть бесконечным.
Вместо того чтобы вступить в соревнование, Writely сосредоточился на функцио
нальностях, которые могли выделить его среди остальных: совместная работа,
удаленное редактирование документов, надежное онлайн-хранилище и простота
использования. Команда создала минимум, достаточный для того, чтобы про-
верить свою концепцию. По словам венчурного предпринимателя Питера Рипа,
разработчики выпустили первую альфа-версию Writely через две недели после
того, как решили его создать1.
Конечно, вы могли никогда не слышать о Writely. Был ли их инкрементный подход
неуспешен? Совсем нет. Через восемь месяцев после запуска Writely компанию
купили. Сейчас она известна как Google Docs.
1
Источники: сайт Writely и блог Питера Рипа. Страниц больше нет в сети, но их можно найти
в интернет-архиве: домашняя страница Writely (https://oreil.ly/NWG6C), Writely is the seed of
a Big Idea (https://oreil.ly/L2qmo), Writely — The Back Story (https://oreil.ly/DRv5X).
Глава 8. Планирование 205
Думайте о вашем плане, что это и план изучения, и план создания. Сфокусируйтесь
на том, что вы не знаете. В чем вы не уверены? Что могло бы быть хорошей идеей?
Какие хорошие идеи вы можете проверить и подтвердить на практике? Не гадайте,
создавайте инкременты для изучения. Тестируйте каждую неясность, затем адап-
тируйте план.
Например, если бы вы создавали онлайновый текстовый процессор, то могли бы
не знать точно, насколько обширной должна была быть ваша поддержка импорта
документов Microsoft Word. Какая-то поддержка необходима, но какая? Реализа-
ция поддержки всех документов Word займет много времени. Добавление других,
возможно более ценных, функциональностей также потребует времени. В то же
время недостаточная поддержка может подорвать доверие к вам и привести к по-
тере клиентов.
Чтобы проверить эту неясность, вы можете добавить в ваше ПО элементарную
функцию импорта (ясно обозначив ее как экспериментальную), выпустить ее и со-
брать сообщения о типах документов, которые пользователи пытаются импортиро-
вать. Информация, которую вы соберете, поможет вам адаптировать план и повысить
ценность вашей команды.
ПРИМЕЧАНИЕ
Пользователи сетевого ПО привыкли к бета-версиям веб-приложений, так что
в этом случае выпуск экспериментальной, незавершенной функциональности
возможен. Чтобы выпустить продукт, предназначенный для более требователь-
ных пользователей, может понадобиться использовать программу пререлиза,
фокус-групп или какой-либо другой механизм получения обратной связи.
КЛЮЧЕВАЯ ИДЕЯ
1
Lean Construction Institute ввел термин «позднейший ответственный момент». [Poppendieck2003]
популяризировал его применительно к разработке ПО.
206 Часть II. Фокус на ценность
Как показывает рис. 8.3, для каждого уровня детализации нужны разные навыки.
Пример плана
Представьте, что ваша команда отвечает за сайт онлайн-магазина. Как в вашем
случае планировать методом набегающей волны? Ниже представлен упрощенный
пример, который показывает, как уровни детализации сочетаются друг с другом.
1. Цель. Общее ви́дение вашей команды — быть ведущим продавцом в вашей
рыночной нише. Ваша специальная миссия — улучшить коэффициент конвер-
сии: сделать так, чтобы больше людей посещало сайт с целью что-либо купить.
2. Возможные ценные инкременты. Чтобы выполнить эту миссию, вы думаете
о нескольких возможных ценных инкрементах. Одна из идей — улучшить работу
сайта на мобильных устройствах. Другая — улучшить страницу оформления
заказа. Третья — улучшить работу поиска. Четвертая — предоставлять кури
руемые обзоры товаров.
3. Наименьшие ценные инкременты. Обсудив идеи с различными стейкхолде-
рами, вы решаете, что улучшение страницы оформления заказа будет наи-
более выгодным. Многие покупатели уходят с сайта, дойдя до этой страницы.
Вы предлагаете идеи наименьших ценных инкрементов, какие только можете
придумать: поддержку подарочных карт, запоминание данных кредитных карт
покупателей, добавление поддержки купонов, поддержку PayPal и т. д.
4. Истории размером «в самый раз». Как показывает ваше исследование рынка,
покупателям из Европы менее комфортно использовать кредитные карты
Глава 8. Планирование 209
Вопросы
Нам нужно принять на себя обязательство делать релиз в определенные даты. Как
поступить?
Прочитайте раздел «Прогнозирование» главы 10. Если вы делаете прогнозы
по дате и объему работы, то вам могут понадобиться удлинение вашего горизонта
планирования и, как правило, свободное владение навыками на уровне поставки,
чтобы ваши прогнозы были полезны.
Если мы не планируем детально наши релизы, то что мы должны говорить о на-
ших планах стейкхолдерам?
Вы можете не планировать заранее все нюансы ваших релизов, однако все же
можете показать стейкхолдерам дорожную карту. Если им нужно много деталей,
то вам, возможно, понадобится удлинить ваш горизонт планирования (см. раздел
«Дорожные карты» главы 10).
Если мы используем короткие горизонты планирования, то как мы можем быть
уверены, что достигнем цели команды?
Если вы не уверены, что сможете достичь цели вашей команды, используйте ваш
план для того, чтобы понять, сможете ли вы это сделать. Вам может понадобиться
создать специальные инкременты для обучения, удлинить ваш горизонт планирова-
ния или сделать маленький релиз с ограниченной доступностью для тестирования
критически важных концепций. Детали будут зависеть от вашей ситуации, поэтому,
если вы не уверены, что делать, попросите совета у наставника.
Предварительные требования
Адаптивное планирование требует участия руководителя и стейкхолдеров (см. гла-
ву 5). Любая команда может планировать в рамках своих ценных инкрементов. Кроме
того, это зависит от имеющегося у вас объема поддержки.
Работа над одним инкрементом за раз — это разумный и легкий способ повысить
ценность вашей команды. Несмотря на его полезность, работа над одним элементом
за раз вызывает отвращение у некоторых стейкхолдеров. Действуйте осторожно.
Частые релизы требуют того, чтобы ваши заказчики и пользователи могли при-
нимать такие релизы. Для большинства сетевого ПО это не проблема, поскольку
пользователям не приходится ничего делать, чтобы получить обновление. Другие
виды ПО могут требовать болезненных процедур развертывания, а некоторые даже
дорогостоящих сертификационных тестов. Это может осложнить частые релизы.
Создание экспериментов, опций и MVP требует, чтобы ваша организация смирилась
с неопределенностью и верила, что у вашей команды достаточно знания рынка, чтобы
принимать правильные решения. Обычно это требует от вашей команды свободного
владения навыками на уровне оптимизации.
Глава 8. Планирование 213
Показатели
Когда вы создаете, поддерживаете хороший план и обмениваетесь им в коммуникациях:
zz он показывает, как команда достигнет своей цели или узнает, как ее достичь;
zz члены команды уверены, что план достижим;
zz вы выпускаете релизы ценного продукта регулярно и постоянно.
Когда вы хорошо адаптируете ваш план:
zz вы постоянно ищете возможности узнать что-то новое о вашем плане, продукте
и стейкхолдерах;
zz в процессе этого вы меняете план так, чтобы в нем использовались преимущества
новых данных.
Альтернативы и эксперименты
Адаптивное планирование повышает ценность благодаря гибкости в планировании
и стратегическому подходу к релизам. Ищите возможность снижать затраты времени
на планы, которые впоследствии отменяются, ускоряйте петлю обратной связи, чаще
совершенствуйте ваши планы и сокращайте время до получения готовой ценности.
Если у вас нет команды поставки, то могут возникнуть вопросы о том, как плани-
ровать техническую инфраструктуру. [Denne2004] предлагает сложную методологию
инкрементного финансирования (Incremental Funding Methodology, IFM), отвеча-
ющую на этот вопрос. Команды со свободным
владением навыками на уровне поставки из- См. также
бегают этой необходимости, поскольку исполь-
зуют эволюционный дизайн для инкрементно- Инкрементный дизайн (глава 14)
го построения технической инфраструктуры.
Команды, имеющие определенный продукт,
не всегда нуждаются в усложненном плане. Вместо того чтобы думать в терминах
инкрементов или релизов, эти команды отталкиваются от маленького списка историй
214 Часть II. Фокус на ценность
ВИЗУАЛЬНОЕ ПЛАНИРОВАНИЕ
У нас есть карта пути к достиже-
нию нашей цели. Аудитория
Продакт-менеджеры, заказчики
Ваш план — ключ к достижению цели
вашей команды. Вместо того чтобы го-
ворить «делайте это, потом вот это, а затем вот то», составьте план, позволяющий
визуализировать ваши варианты, и адаптируйте его в процессе работы. Визуальное
планирование позволяет сделать это.
Возможности для визуального планирования бесконечны. Здесь мы обсудим че-
тыре техники. Вы можете следовать одной из них буквально, как написано, соединять
несколько или создавать новые визуа-
лизации, полностью ваши собственные. Правильной является визуализация,
Правильной является визуализация, которая работает для вашей команды
которая работает для вашей команды и ваших стейкхолдеров.
и ваших стейкхолдеров.
Кто планирует?
Визуальное планирование проводится
членами команды, обладающими навы- См. также
ками управления созданием продук-
та, при помощи заказчиков в команде. Вся команда (глава 7)
Постарайтесь также привлечь ключе- Вовлечение реального заказчика (глава 8)
вых стейкхолдеров, по крайней мере,
Глава 8. Планирование 215
Картирование кластеров
Картирование кластеров (Cluster Mapping) (рис. 8.4) — самый простой и гибкий,
а также наиболее эффективный способ визуализировать ваши планы. Это моя лю-
бимая техника.
3. Организуйте инкременты
Сделайте шаг назад и подумайте об инкрементах в контексте цели вашей команды,
затем реорганизуйте их так, чтобы они лучше отражали ваше представление о том,
как эта цель будет достигнута. Некоторые инкременты окажутся не относящимися
к делу или относящимися к слишком далекому будущему. Их можно удалить или
отложить.
Некоторые инкременты будут отражать разные способы достижения одного
и того же результата. Если вы не уверены, что выбрать, то сохраните оба! Ваш план —
карта, а карты показывают разные пути к пункту назначения. Вы даже можете за-
хотеть добавить несколько инкрементов исследовательского типа, которые помогут
вам выбрать варианты.
У вас может оказаться несколько инкрементов, которые не имеют прямого от-
ношения к цели вашей команды, но все равно должны быть выполнены. Добавьте
их на доску.
Глава 8. Планирование 217
4. Проверьте и уточните
Когда вы это сделаете, вернитесь немного назад и посмотрите на карту еще раз.
Затем подправьте, если нужно, получившиеся кластеры и добавьте примечания,
чтобы карту было легче объяснить. Вам нужно иметь возможность использовать
карту в качестве визуальной подсказки, когда понадобится описать, как ваша коман-
да будет достигать своей цели.
В этой точке у вас есть краткий план,
показывающий возможные ценные ин- См. также
кременты, над которыми уже может ра-
Вовлечение реального заказчика (глава 8)
ботать ваша команда. Это подходящий
момент, чтобы сделать перерыв и за-
просить обратную связь от членов команды, реальных заказчиков и других стейк-
холдеров, которые не присутствовали при подготовке карты. Дальше вы можете
углубиться в детали.
2. Фильтруйте и повторите
Далее проанализируйте новые инкременты и удалите (или пока отложите) те, кото-
рые не относятся к делу или относятся к слишком далекому будущему. Оставшиеся
разделите на «высокий приоритет» и «невысокий приоритет».
Повторяйте шаги 1 и 2, пока у вас достаточно маленьких инкрементов с высо-
ким приоритетом, чтобы заполнить ваш горизонт планирования для «Наименьших
ценных инкрементов». Например, если вы используете горизонты планирования,
показанные на рис. 8.2 (см. выше), то остановитесь, когда наберете маленьких ин-
крементов на три месяца работы.
ПРИМЕЧАНИЕ
Просто используйте свое внутреннее ощущение размеров. Вы не делаете реаль-
ную оценку, просто решаете, когда остановить планирование, так что не стоит
останавливаться слишком рано. Самое важное — найти маленький инкремент,
над которым ваша команда будет работать в первую очередь. Вы всегда можете
разбить больше инкрементов чуть позже.
3. Расставьте приоритеты
Когда закончите, остановитесь и подумайте,
не приходят ли вам в голову какие-нибудь См. также
новые идеи. Затем решите, как вам приори-
Дорожные карты (глава 10)
тизировать маленькие инкременты с высо-
ким приоритетом. Как минимум отметьте Прогнозирование (глава 10)
один, чтобы выпустить его первым, и еще
один для предполагаемого второго релиза. Оставшиеся тоже можно приоритизиро-
вать или пока оставить в зависимости от того, что указано в вашей дорожной карте
и прогнозах.
Если вы используете физические индексные карточки, то запишите приоритет
на маленький стикер и приклейте его на карточку. Таким образом, когда ваши
приоритеты изменятся, вы сможете просто переклеить стикеры, не переписывая
карточки.
На этом уровень детализации «Маленькие инкременты» завершается. Это еще
один удобный момент сделать перерыв и запросить обратную связь.
Глава 8. Планирование 219
Карты влияния
Иногда вам нужно больше вариантов структуры, чем могут обеспечить карты класте-
ров. Карты влияния (impact maps), показанные на рис. 8.5, — отличный инструмент
для исследования доступных вам вариантов1.
Никогда не стремитесь реализовать всю карту. Лучше найдите на ней самый
короткий путь к цели! [Adzic2012] (с. 12–13).
Гойко Аджич
1
Большое спасибо Гойко Аджичу за его советы в этом подразделе.
220 Часть II. Фокус на ценность
Карта влияния — тип ментальных карт (mind maps). Если вы с ними не зна-
комы, то ментальные карты — это иерархическое дерево идей. Вы начинаете с ос-
новной идеи в центре карты. Идеи, относящиеся к ней, ветвятся из центра и соз-
дают собственные узлы. От каждой из этих идей ответвляются дополнительные
идеи. И т. д.
В данном случае на карте влияния «Почему» (цель) находится в центре, за
ней следует «Кто» (влияющие стейкхолдеры), «Как» (влияния) и «Что» (ин-
кременты).
Чтобы создать карту влияния, используйте вашу доску для визуального плани-
рования. В виртуальную доску может быть встроена функция карт влияния. Если
у вас физическая доска, то используйте для узлов индексные карточки разного
цвета. При необходимости их можно будет с легкостью передвигать. Как всегда,
лучше работайте все вместе, чтобы избежать образования узких мест в рабочем
процессе.
1. Начните с цели
Начните с вашей цели. Это «Почему» на карте
влияния, и она размещается в центре. Данная См. также
цель должна некоторым образом иметь отно-
шение к цели вашей команды. Это может быть Цель (глава 7)
сокращенная версия вашей миссии, следующих
тестов миссии или и то и другое. На карте влияния все зависит от цели. Это пункт
назначения, и карта покажет вам, как до него добраться. В примере команды «Снеж-
ный человек» (см. врезку «Пример цели» в главе 7) целью должно быть «100 команд-
покупателей».
4. Приоритизируйте влияния
До этого момента вы мыслили широко и генерировали варианты. Теперь настало
время сфокусировать ваше мышление. Какие влияния критичны для достижения
вашей цели? Какие представляют собой легкодоступные цели? Какие являются
предположениями, которые необходимо протестировать? Выберите влияния с самым
высоким приоритетом. При работе в группе вам может помочь точечное голосование
(см. пункт «Работайте одновременно» главы 7).
После того как вы приоритизировали влияния, подумайте над прикреплением кон-
кретных целей к максимальным влияниям. Например, влиянию «рекомендуйте нас
в социальных сетях» может соответствовать цель «100 рекомендаций в социальных
сетях в неделю». Это поможет вам понять ваш прогресс. Иногда вам будет удаваться
достичь цели раньше, чем вы ожидали, и тогда вы сможете изменить приоритеты.
В других случаях вы узнаете, что ваши усилия ничего не меняют, и вам понадобится
сделать больше, чтобы проверить ваши предположения.
Перспективный анализ
Перспективный анализ, изображенный на рис. 8.6, помогает вам генерировать идеи,
представляя будущие результаты. Он особенно хорошо работает в качестве инстру-
мента управления рисками. Кроме того, вы можете использовать перспективный
анализ в качестве самостоятельного инструмента планирования или как введение
в другой подход к планированию.
1. Создайте диаграмму
Чтобы создать диаграмму, нарисуйте большой график на вашей доске для ви-
зуального планирования или в ее виртуальном эквиваленте. Пронумеруйте
вертикальную ось от –3 до +3, что будет представлять собой результат от «очень
плохо» до «очень хорошо», и нарисуйте горизонтальную прерывистую линию на
уровне отметки «0». На горизонтальной оси отметьте диапазон от «Не произой-
дет» до «50/50» и далее до «Произойдет». Нарисуйте вертикальную прерывистую
линию на отметке «50/50».
3. Проверьте и уточните
После того как все карточки будут на доске, остановитесь, чтобы внимательно про-
смотреть их расположение и скорректировать его. Это можно сделать одновременно.
Результат будет похож на рис. 8.6 (см. выше).
1
Большое спасибо Джеффу Паттону за его советы в этом подразделе.
Глава 8. Планирование 225
2. Определите шаги
Создайте карту историй, буквально рассказывая, что происходит: сначала это, по-
том вот это, затем вот то. Она может охватывать несколько пользователей и систем:
«Я делаю это, затем Татьяна делает вот это, потом система бэкенда совершает вот
эти действия».
Записывайте каждый шаг (также называемый пользовательская задача (user
task)2) на индексной карточке, стикере или в виртуальном эквиваленте. Для примера
с онлайн-магазином вы можете расписать шаги «искать товар», «читать отзывы»,
«добавить в корзину», «нажать “оформить”» и т. д. Расставьте их по порядку от
первого до последнего.
Если вы создаете карту «сейчас», то добавьте примечание о том, как все работа-
ет на практике. Сделайте примечание о недостатках и о том, что работает хорошо.
Вы также можете написать, сколько времени занимает каждый шаг или как часто
они происходят, — все, что, по вашему мнению, может быть полезным позже, когда
вы будете думать об улучшениях.
ПРИМЕЧАНИЕ
Карты историй могут занимать много места. В физической командной комнате вы
можете использовать свободную большую стену и стикеры вместо белой доски
и индексных карточек. Используйте суперклейкие стикеры — вы же не хотите
вернуться после долгих выходных и найти свою карту на полу!
1
В личном общении.
2
Джефф Паттон использовал термин «пользовательские задачи» в [Patton2014], но позже пере-
ключился на «шаги». Это помогает избежать путаницы с задачами в разработке.
226 Часть II. Фокус на ценность
Расписав все шаги, осмотрите всю карту от начала до конца и заполните все про-
белы, какие найдете. Потом начните расширять свои представления об элементах
карты. Как другие люди делают что-то другим образом? Что происходит, когда
что-то идет не так? А что, если все идет отлично? Напишите новые стикеры для
таких вариаций и добавьте их столбиком под соответствующим им шагом. В конце
взгляните на изначальный список шагов и переместите те из них, которые кажутся
дополнительными, ниже соответствующих им шагов.
В процессе работы у вас будут появляться новые идеи, которые потребуют
реорганизации вашей карты. И это хорошо. Когда закончите, у вас будет горизон-
тальная линия шагов, рассказывающих историю о том, что делают пользователи,
и вертикальные линии вариаций, альтернатив и деталей, спускающиеся вниз от
горизонтальной линии. У вас должна быть возможность «пройти по карте» от на-
чала до конца, выбирая разные шаги из каждого столбца, чтобы рассказать разные
версии одной истории.
Иногда люди будут иметь разные мнения о том, в каком порядке расставить шаги.
Просто выберите наиболее типичный порядок. До тех пор, пока вы можете рассказать
историю, имеющую смысл, точный порядок шагов не важен.
Вопросы
Что, если мы вынуждены использовать корпоративный инструментарий, который
не позволяет нам сделать собственный визуальный план?
Не позволяйте корпоративным инструментам мешать вам создавать и адапти-
ровать ваш план. Если вам необходимо использовать такой инструмент, то рас-
сматривайте его как еще одну точку зрения на ваш реальный план, как описывается
в подразделе «Корпоративные системы отслеживания» главы 10. Делать двойную
работу, конечно, расточительно, но хороший визуальный план — настолько ценная
вещь, что оно того стоит.
Как нам сконвертировать визуальный план в такой формат, который хотят
видеть наша организация и стейкхолдеры?
Есть много вариантов в зависимости от того, какая степень детализации нужна
вашей организации. Прочитайте раздел «Дорожные карты» главы 10.
Предварительные требования
Для визуального планирования требует-
ся командная комната, приспособленная См. также
для совместной работы. Виртуальным
Командная комната (глава 7)
командам необходимо программное при-
ложение, представляющее собой вир-
туальную белую доску. В физическом помещении понадобятся большой стол,
магнитная белая доска и индексные карточки или стикеры.
Не используйте для вашего плана специальные инструменты для управления
жизненным циклом Agile и инструменты для трекинга открытых вопросов. Они
не имеют никакого отношения к Agile. Они сделаны для удовлетворения капризов
карго-культа крупных Agile-компаний и только повредят вашей гибкости. Вам
нужна возможность создавать и настраивать визуализацию произвольной формы,
не ограничиваясь этими инструментами. Белая доска или ее виртуальный эквива-
лент — лучшие способы сделать это.
Для команд, работающих в офисе, физическая доска будет гораздо более эф-
фективной, чем виртуальная. Тактильные ощущения, вызванные ее использова-
нием, резонируют с умственной работой человеческого мозга, что приносит такие
результаты, на которые экран просто не способен. Трудно понять, насколько это
эффективно, пока сами не испытаете это. Постарайтесь использовать физическую
доску и карточки.
Глава 8. Планирование 229
Показатели
Когда вы создаете и правильно доводите до участников визуальный план:
zz стейкхолдеры и члены команды понимают не только, что будет сделано, но и по-
чему это будет сделано;
zz взаимосвязи между частями вашего проекта хорошо видны;
zz стейкхолдеры и члены команды вносят новые идеи в результате более глубокого
понимания контекста.
Альтернативы и эксперименты
Вы можете сразу начать экспериментировать с этой практикой. Попробуйте каж-
дую из представленных здесь карт по отдельности, затем в разных комбинациях
и добавьте собственные идеи. Правильного ответа нет, так что экспериментируйте
с любыми идеями, какие только сможете найти или придумать. Не бойтесь что-то
менять; я меняю свои визуализации каждые несколько месяцев и каждый раз нахожу
новые идеи и ощущаю азарт от открывающихся возможностей.
Есть много способов визуализации планов. Один стартап, с которым я работал,
создал диаграмму бизнес-приоритетов в четырех категориях («развитие бизнеса»,
«контроль затрат», «снижение рисков», «расширение возможностей»). Каждая из
идей получила свой стикер в соответствии с приоритетом. Были сотни идей, и только
нескольким из них был присвоен высокий приоритет. Остальные постоянно пере-
мещались в разных направлениях, так как основатели стартапа выдвигали новые
идеи и пересматривали старые.
У другой команды было множество обязательств, привязанных к определенным
датам. Команда разработала календарь обязательств с колонкой для каждой недели.
Карточки, представлявшие собой обязательства на каждую неделю, приклеивались
к соответствующей колонке. Каждую неделю команда просматривала обязательства,
приближающиеся по срокам, и добавляла их в планирование задач этой недели.
Существует множество и других вариантов. Экспериментируйте свободно!
230 Часть II. Фокус на ценность
ИГРА В ПЛАНИРОВАНИЕ
В наших планах используются знания
и опыт как бизнеса, так и разработки. Аудитория
1
Паттон Дж. Пользовательские истории. Искусство гибкой разработки ПО.
2
Хоманн Л. Бизнес-игры: создание революционных продуктов с помощью клиентов.
3
Это определение игры пришло из Глоссария международной экономики (А. Дирдорффа) (https://
oreil.ly/IsTY2).
Глава 8. Планирование 231
К А Р ГО - К УЛ ЬТ
День планирования
Сегодня опять день планирования, и вы в ужасе от этого. Вы точно
знаете, что будет происходить. Сначала Захария и Мисси опоздают
минут на десять-пятнадцать. Потом Ладонна с помощью про-
ектора выведет ваш баг-трекер на стену. Она прочтет историю,
в том числе все детальные требования, критерии готовности
и все остальное. Все будут говорить об этом. Потом будет что-то
вроде оценочных шагов с помощью покера планирования. Джон
будет жаловаться, что оценка слишком велика. Клео скажет, что
историю надо разбивать на более мелкие. Филлис скажет, что она уже потратила
несколько часов на требования и менять истории — слишком большая работа.
Корнелл скажет всем, чтобы просто продолжали работать. В конце концов после
10 минут болезненных споров у вас будет оценка, Ладонна внесет ее в систему,
и вы перейдете к следующей.
И так снова и снова. Это так мучительно и занимает долгие часы. Наверняка есть
способы лучше.
Как играть
Цель игры в планирование — сфокусировать
команду на работе, которая обеспечит наи- Каждое решение сделать что-то
лучший возврат инвестиций. В конце кон- является также решением не делать
цов, каждое решение сделать что-то является что-то другое.
также решением не делать что-то другое.
Разработчики лучше всего информированы о затратах (они наиболее квалифи-
цированны, чтобы сказать, сколько работы потребуется для реализации истории),
поэтому задают размер историй.
Заказчики в команде больше всех знают о ценности продукта (они наиболее
квалифицированны, чтобы сказать, что именно важно), поэтому приоритизируют
истории.
Члены команды, у которых есть как опыт в разработке, так и знания о заказчике,
могут играть обе роли в игре в планирование, но лучше, если они будут придержи-
ваться какой-либо одной роли. Преимущества игры в планирование связаны с пре-
одолением естественных противоречий, возникающих между ценностью и затратами.
Легко обмануть себя, игнорируя эти противоречия, когда играешь обе роли.
историй (см. подраздел «Как создать план» ранее в данной главе). Например, если
вы используете горизонт планирования, показанный на рис. 8.2, вам понадобится
выбрать количество инкрементов, которого хватит примерно на месяц работы.
Начните игру в планирование с просмотра цели команды, затем опишите, как
выбранные вами инкременты вписываются в общий план и почему их важно сделать
в первую очередь. Объясните, что делает эти инкременты ценными и что должно про-
изойти, прежде чем их можно будет выпустить, и затем ответьте на все возможные
вопросы от команды.
ПРИМЕЧАНИЕ
Почему от четырех до десяти историй в неделю? Вы можете выбрать любой раз-
мер для понятия «в самый раз», но 4–10 — хорошая начальная точка. Если будет
больше, то вы можете прийти к тому, что будете тратить очень много времени
на создание, организацию, отслеживание историй. Если меньше — вам будет
трудно демонстрировать устойчивый прогресс.
Глава 8. Планирование 233
Вернемся к примеру с тостером. Вместо того чтобы объяснять выбор между оп-
тическим датчиком и таймером следующим образом:
«Мы думаем об использовании здесь оптического датчика Mark 4 Wizzle-Frobitz,
позволяющего оптимально определять момент выбрасывания. Другой вариант —
использовать 555-style IC. Оптический датчик лучше, но тогда нам понадобится
обучить индивидуальную пользовательскую модель ML. Что вы предпочитаете?»,
настает время снова провести игру в планирование. После этого проверьте еще раз,
нужно ли вытянуть инкременты в ваш визуальный план.
Стейкхолдеры тоже будут предлагать новые идеи и функциональности. Одни из
них не будут стоить того, чтобы их внедрять, и их можно будет выбросить (вежливо!).
Другие окажутся хорошими идеями для будущих инкрементов, и их можно будет до-
бавить к пока еще менее детализированной части вашего визуального плана. А идеям,
которые вы захотите реализовать скоро, понадобятся свои истории. Их нужно будет
обсудить с командой, чтобы задать размер и приоритет.
По мере приобретения опыта обсуждение, определение размера и приоритета
начинают занимать всего несколько минут. Соответственно, одни команды просма-
тривают новые истории в день их получения. Другие планируют большие сессии
игры в планирование каждую неделю или две. Я считаю, что короткие частые сессии
менее утомительны, чем долгие и более редкие, но оба подхода рабочие.
Иногда стейкхолдеры будут пытаться обойти процесс приоритизации, общаясь
с программистами напрямую. Правильной реакцией на это будет выслушать их за-
прос, записать его (на этот случай я всегда ношу с собой набор индексных карточек)
и сказать им, что запросу будет присвоен приоритет, когда команда в следующий раз
соберется на сессию планирования. Потом вы можете передать его своему локальному
заказчику для отслеживания.
Вопросы
Как можно побудить стейкхолдеров к использованию историй для запроса изменений?
Это не обязательно. Вместо этого члены команды, обладающие навыками в сфере
деятельности заказчика, должны интерпретировать идеи стейкхолдеров и преоб-
разовывать их в истории для команды.
Что делать с технической инфраструктурой?
В Agile планирование начинается с допущения, что
вы можете разбить свою работу на маленькие ориен- См. также
тированные на заказчика истории и создавать вашу
Инкрементный дизайн
техническую инфраструктуру в процессе работы. Как (глава 14)
это сделать, показывает эволюционный дизайн.
Предварительные требования
Игра в планирование основана на нескольких простых
предпосылках: См. также
zz есть члены команды, обладающие навыками в сфере Вся команда (глава 7)
деятельности заказчика, которые могут принимать
разумные решения о приоритетах;
zz есть члены команды с навыками разработки, которые могут надежно измерять
истории;
zz есть истории с минимальными зависимостями, ориентированные на заказчика.
Глава 8. Планирование 239
Показатели
Когда вы хорошо играете в игру в планирование:
zz заказчики и разработчики чувствуют, что они внесли свой вклад в план;
zz ощущения давления и стресса направлены скорее на ограничения плана и воз-
можные варианты, чем на отдельные лица или группы лиц;
zz разработчики рекомендуют способы, позволяющие уменьшить работу, при этом
выполняя цель команды;
zz заказчики расставляют строгие приоритеты историям, что наилучшим образом
служит достижению цели командой.
Альтернативы и эксперименты
Ключевая идея игры в планирование состоит в том, что заказчики и разработчики
собираются вместе, чтобы составить план, который будет лучше, чем тот, который
любой из них мог бы составить самостоятельно. Это командный, а не индивидуаль-
ный подход, и он сфокусирован на результатах, а не на задачах.
Я не видел ничего, что превзошло бы эту основную идею, но и тут есть простран-
ство для экспериментов. Например, некоторые команды предпочитают создавать
очень маленькие истории, которые можно завершить за час или два. (Однако не за-
бывайте, что они должны быть ориентированы на заказчика, иначе это просто задачи!)
Вы также можете экспериментировать с программой игры в планирование. Напри-
мер, можете попробовать создавать и измерять ваши истории асинхронно, включать
в процесс больше или меньше людей или планировать более или менее часто.
КЛЮЧЕВАЯ ИДЕЯ
Разработка платформ
В горизонтально масштабированных группах команд (см. подраздел «Горизонтальное
масштабирование» главы 6) некоторые команды могут делать ПО, предназначенное
только для использования другими командами. Реальные заказчики такого типа раз-
работки платформ — команды заказчика.
И слишком часто разработчики плат-
форм попадают в ловушку, делая инстру- Командам заказчика нужны гибкость,
менты и библиотеки, которые «просты автономия и полное владение своим
в использовании». Но это не то, что нужно продуктом, ничего волшебного.
командам вашего заказчика. Им нужны
гибкость, автономия и полное владение своим продуктом, ничего волшебного.
Им нужно, чтобы они могли делать свою работу, не завися от вас, если понадобятся
какие-то изменения. Как правило, это означает, что вам следует считать своими при-
оритетами простые программные интерфейсы с четкими зонами ответственности,
минимальными побочными эффектами и «аварийным люком», который позволит
команде погрузиться в нужные детали при необходимости.
ПРИМЕЧАНИЕ
Некоторые организации делят свои команды на старших разработчиков, которые
разрабатывают платформы, и младших разработчиков, которые адаптируют (ка-
стомизируют) эти платформы под разработку продуктов. Избегайте этого подхода.
Довольно часто он приводит к построению собственной «башни из слоновой
кости», пытающейся упростить кастомизацию, но на самом деле требующей от
неопытных разработчиков постоянной работы по латанию дыр. Результат — бес-
порядочное нагромождение решений, которое трудно поддерживать.
ПРИМЕЧАНИЕ
Вместо того чтобы приглашать заказчиков присоединиться к вашей команде,
может быть проще предложить вашей команде переехать поближе к заказчикам.
Аутсорсинг разработки
Аутсорсинг разработки (outsourced custom development) похож на внутреннюю раз-
работку на заказ (in-house custom development), но у вас может не быть таких связей,
которые есть у внутренних команд в организации. В результате у вас может не по-
лучиться привлечь реальных заказчиков к работе в качестве заказчиков в команде.
Но вы все же должны попытаться. Один из способов вовлечь в работу реальных
заказчиков — предложить вашей команде переехать в офис заказчика, а не наоборот.
Если вы не можете привести реальных заказчиков в вашу команду, то сделайте
попытку привлечь их другим способом. Встречайтесь лично с вашими заказчиками
Глава 8. Планирование 243
первую неделю-две работы над проектом, чтобы обсудить цель и контекст, визуаль-
ный план и познакомиться друг с другом. Если ваши офисы находятся неподалеку
друг от друга, то встречайтесь снова на каждой демосессии для стейкхолдеров и сес-
сиях планирования, а также время от времени на ретроспективах.
Если вы разделены территориально и ре-
гулярные визиты невозможны, то оставайтесь
См. также
на связи с помощью видео- и телефонных
конференций. Если у вас виртуальная коман- Цель (глава 7)
да, то рассмотрите возможность предоставить
заказчикам доступ в вашу виртуальную ко- Контекст (глава 7)
мандную комнату. Постарайтесь встречаться Визуальное планирование (глава 8)
по меньшей мере раз в месяц для обсуждения
Демо для стейкхолдеров (глава 10)
планов. Даже если ваша команда работает
в офисе, попробуйте использовать вирту- Игра в планирование (глава 8)
альную белую доску для визуального плана, Ретроспективы (глава 11)
чтобы было проще совместно просматривать
и обсуждать планы.
Вопросы
Мы создаем сайт для нашего отдела маркетинга. Какой это тип разработки?
На первый взгляд может показаться, что это разработка на заказ, но так как реаль-
ная аудитория сайта — внешний мир, речь скорее идет о разработке для вертикального
или горизонтального рынка в зависимости от вашей индустрии. Продакт-менеджер
должен быть из отдела маркетинга, если это возможно, но вам также понадобится
обратная связь от людей, которые будут посещать сайт.
Предварительные требования
Одна из опасностей вовлечения реального за-
казчика заключается в том, что он не обязательно См. также
будет отражать потребности всех ваших заказчи- Цель (глава 7)
ков. Будьте осторожны, чтобы он не подтолкнул
Глава 8. Планирование 245
вас к созданию ПО, полезного только для него. Используйте цель вашей команды
как ориентир. Пожелания заказчика задают цель и даже могут изменить ее, но
в конечном счете члены команды, обладающие навыками менеджмента продукта,
несут ответственность за направление работы команды.
Подобным образом пользователи часто думают об улучшении их существующих
методов работы, а не о поиске абсолютно новых методов работы. Это еще одна причина
того, почему конечные пользователи должны быть вовлечены, но не обладать контро-
лем. Если вашей команде важны иннова-
ции, то дайте прогрессивным мыслите- Конечные пользователи должны быть
лям (таким как дальновидный менеджер вовлечены, но не обладать контролем.
по продукции или UX-дизайнер) замет-
ные роли в вашей команде.
Показатели
Вовлекая реального заказчика и пользователей, вы:
zz улучшаете свои знания о том, как заказчики используют программное обеспе-
чение на практике;
zz лучше понимаете цели и опасения заказчика;
zz используете обратную связь от заказчиков, чтобы пересматривать свои планы
и программное обеспечение;
zz повышаете ваши шансы поставить действительно полезный и успешный продукт.
Альтернативы и эксперименты
Обратная связь — это необходимость, а непосредственное вовлечение реального за-
казчика — нет. Иногда лучшее ПО создают люди, которые имеют четкую концепцию
и энергично добиваются ее реализации. В результате ПО имеет тенденцию стано-
виться или полностью новым, или тщательно переосмысленным существующим
продуктом.
Кроме того, обратная связь от реальных заказчиков всегда информативна, даже
если вы решите игнорировать ее. Данная практика предназначена для получения
этой обратной связи из реального мира. Цель — создать ПО, которое реально отве-
чает потребностям заказчиков и пользователей, а не только представлениям вашей
команды и организации об их потребностях.
Пока вы будете думать о способах, позволяющих поэкспериментировать с этой
практикой, сфокусируйтесь на общении и обратной связи. Что поможет вам по-
лучить представление о том, как воспринимаются ваши программы в реальном
мире? Как вы можете уменьшить временной разрыв между идеей и получением
обратной связи? Как принимать лучшие решения, основываясь на обратной связи?
Чем больше у вас информации, тем более правильные решения сможет принимать
ваша команда.
246 Часть II. Фокус на ценность
ИНКРЕМЕНТНЫЕ ТРЕБОВАНИЯ
Мы выясняем детали требований непосредственно
перед тем, как они понадобятся. Аудитория
Работайте инкрементно
Заказчики работают над требованиями инкрементно, параллельно с остальной ра-
ботой команды, а не во время предварительной фазы подготовки требований. Это
облегчает работу и позволяет оставшейся части команды не ждать окончания ана-
лиза требований, чтобы начать свою работу.
Как и с горизонтами планирования адаптивного
плана, начинайте с общей картины без большого См. также
количества деталей и уточняйте их по мере необ-
ходимости. Заказчики в команде должны работать Адаптивное планирование
над этой задачей, как правило, вместе с продакт- (глава 8)
менеджером, внимание которого сконцентрировано
248 Часть II. Фокус на ценность
Цель (глава 7)
Игра в планирование
Визуальное планирование (глава 8)
Перед каждой сессией игры в планирование
посмотрите на свой визуальный план и ре- Игра в планирование (глава 8)
шите, какие инкременты будут предметом
внимания следующей игры. Все, кто разбирается в сфере деятельности заказчика,
должны иметь единое понимание о том, почему именно эти инкременты ценны
и что для них значит быть завершенными. Чтобы сберечь время разработчиков, как
вариант вы можете разбить эти инкременты на еще более мелкие истории перед на-
чалом игры в планирование, хотя вы должны быть готовы вносить изменения и по
ходу самой игры в планирование.
Во время игры в планирование разработчики будут задавать вопросы о ваших
ожиданиях от инкрементов и историй. Постарайтесь предугадать эти вопросы и под-
готовить ответы на них. (Со временем вы будете знать, какие вопросы могут зада-
вать разработчики.) Может помочь приблизительный набросок видимых аспектов
истории. Можете предварительно пообщаться с кем-либо из разработчиков, чтобы
подготовиться.
Отзывы заказчиков
Пока истории находятся в разработке, до того как они полностью сделаны, проверьте,
соответствуют ли они вашим ожиданиям. Вам не нужно полностью тестировать при-
ложение (вы должны полагаться на то, что разработчики тестируют свою работу),
но вы должны вместе с разработчиками проверить те области, где они могут думать
не так, как вы. В эти области входят терминология, макет экрана и взаимодействие
между его элементами.
Глава 8. Планирование 249
Документация
Хотя Agile-команды заменяют документацию личным общением, некоторые до-
кументы все же важны. Их планируют с помощью историй, как и любую другую
работу. В некоторых случаях обновление документации может стать просто ча-
стью более крупной истории, но вы также можете создать специальные истории
для документации, как обсуждалось в пункте «Истории для документации» ранее
в данной главе.
Постарайтесь не вводить документацию только ради документации. Как и во
всем, что делается командой, убедитесь, что вам понятно, кому принесет пользу до-
кументация и почему она имеет ценность.
Документация по продукту
Документация по продукту поставляется заказчику. Примеры такой документации —
руководства пользователя, справочные страницы и справочная документация по API.
Одна из команд, с которой я работал, собирала результаты тестов в формальный до-
кумент, который помогал заказчикам пройти процедуру одобрения у регулирующих
органов.
250 Часть II. Фокус на ценность
Эксплуатационная документация
Эксплуатационная документация, также называемая
runbooks, описывает стандартные практики и процедуры См. также
для разнообразных ситуаций, таких как развертывание
Сборка для эксплуа-
ПО, реагирование на оповещения и аварийные ситуации, тации (глава 15)
предоставление дополнительных ресурсов и т. д.
Руководящая документация
Ваша организация может требовать от вас создания определенных документов для
целей управления или аудита. Постарайтесь, чтобы такой документации было ми-
нимальное количество, или выполните требования, творчески перепрофилировав те
вещи, которые имеют большую ценность. Например, одна из команд использовала
автоматические приемочные тесты, отчеты о покрытии кода (code coverage) и исто-
рию управления исходным кодом (source control), чтобы удовлетворить требования
в части отслеживаемости.
Не думайте, что аудиты требуют специального процесса. Они часто требуют, чтобы
у вас просто имелся процесс (на ваш выбор) и чтобы вы могли продемонстрировать,
что вы ему следуете. Это может позволить вам уменьшить количество документации
по управлению куда больше, чем вы думаете. Например, вместо проведения формаль-
ных ревью кода команды использовали парное программирование и комментарии
при подтверждении изменений в код (commit comments), чтобы соответствовать
требованиям аудита в части экспертной проверки. Поговорите с аудиторскими груп-
пами заранее, чтобы сформировать атмосферу доброй воли и открыть возможности
для творческих решений.
Исполнительно-техническая документация
Agile-команды обладают глубоким пониманием, что они делают и почему. Но так
как они не используют документацию, это знание исчезает, когда команда расфор-
мировывается.
Когда ваша команда должна расфор-
мироваться или перейти к другой цели, Исполнительно-техническая
найдите время на то, чтобы задокументиро- документация (As-built
вать, что вы сделали. Это ваш финальный documentation) — это ваш
инкремент. Это как упаковывать одежду финальный инкремент создания ПО.
в коробки с нафталином: сейчас это вам
Глава 8. Планирование 251
не нужно, но тот, кто унаследует вашу работу, будет благодарен, что вы потратили на
это время. Ваша цель — предоставить информацию, которая позволит им сохранять
и поддерживать код.
Исполнительно-техническая документация может принимать форму письменных
документов или пошаговых видеоинструкций. Обычно в них представлены обзоры
важных концепций, таких как архитектура, дизайн и основные функциональности.
Код и его тесты документируют детали. Алистер Кокберн советует записывать
беседу с каким-нибудь красноречивым членом команды, в которой он с помощью
белой доски объясняет систему программисту, не знакомому с ней. Дополните видео
оглавлением, содержащим также временные метки для каждой части разговора.
Вопросы
Не рискованно ли уменьшать количество документации?
Может быть. Чтобы уменьшить количество документации, вам необходимо сна-
чала заменить ее другими формами общения. Именно поэтому Agile-команды имеют
заказчиков в команде — они заменяют документы с требованиями. Но вам все же
может понадобиться задокументировать то, что разработала ваша команда. Если вы
думаете, что это важно, то создайте для этого отдельную историю и приоритизируйте
ее или включите данный пункт в ваше определение понятия «сделано».
Наши заказчики не знают, что должна создать наша команда. Что нам делать?
Начните с четкой, убедительной цели.
Если ваши заказчики в команде не зна- См. также
ют, как ее достичь, значит, у вас в коман-
де не хватает важных навыков в сфере Цель (глава 7)
деятельности заказчика. В этом случае Вся команда (глава 7)
вы можете использовать традиционную
методику сбора требований, такую как Контекст (глава 7)
[Wiegers1999], но лучше все же найти
людей с соответствующими навыками. Если вы еще этого не сделали, попробуйте
определить контекст работы вашей команды и использовать его для лучшего по-
нимания и пропаганды необходимых вам навыков.
Что, если заказчики при проверках обнаруживают слишком много проблем, с ко-
торыми нам трудно справляться?
С большой вероятностью это может случаться с новой командой, до того как
разработчики и заказчики команды научатся работать вместе. В краткосрочной
перспективе вам нужно писать новые истории для изменений, которые необходимо
внести.
В долгосрочной перспективе можно
организовать работу так, чтобы заказчики См. также
проводили больше времени, разговари-
вая с разработчиками о своих ожиданиях Групповое программирование (глава 12)
и проверяя текущую работу. Групповое Парное программирование (глава 12)
программирование — наиболее яркое
252 Часть II. Фокус на ценность
Предварительные требования
Эта практика требует, чтобы в вашей ко-
манде были люди, имеющие время и навы- См. также
ки, которые позволяют тщательно прора-
батывать детали. Без них у вашей команды Вся команда (глава 7)
будут трудности из-за недостаточных и не- Без багов (глава 16)
ясных требований.
Визуальное планирование (глава 8)
Не рассматривайте проверки ваших за-
казчиков как сессии поиска багов. Разработ-
чики должны производить практически безошибочный код. Цель отзывов заказчиков
заключается в том, чтобы привести ожидания заказчиков и работу программистов
к единому знаменателю.
Некоторые организации настолько высоко ценят письменные документы, что вы
не сможете избежать документов с требованиями. Поговорите с вашим руководством
о том, почему эти документы так важны и не может ли их заменить непосредственное
общение. Возможно, исполнительно-техническая документация будет приемлемым
компромиссом. Если нет, то включите истории для необходимых документов в ваш
визуальный план.
Показатели
Когда заказчики разрабатывают требования инкрементно:
zz разработчики работают над готовыми историями, в то время как заказчики вы-
ясняют детали будущих историй;
zz у заказчиков наготове ответы на вопросы, касающиеся требований, что позволяет
планированию и разработке проходить быстро и плавно;
zz к моменту своей готовности история соответствует ожиданиям заказчиков.
Глава 8. Планирование 253
Альтернативы и эксперименты
Практика инкрементных требований, по сути, берет традиционную фазу предвари-
тельного сбора требований и распределяет ее вдоль всей протяженности процесса
разработки ПО. Долгий процесс, когда заказчики пишут документ с требованиями,
передают его разработчикам, а те его читают, заменяется прямым разговором за-
казчиков с разработчиками именно в тот момент, когда нужны детали.
Обычно люди экспериментируют с этой идеей, сглаживая ее. Чаще всего команды
не включают людей, имеющих опыт в сфере деятельности заказчиков, поэтому воз-
вращаются к фазовому подходу и передаче документов. Это снижает их соответствие
идеям Agile. Если вы ищете возможность для экспериментов, то попробуйте другое
направление: расширяйте коммуника-
цию, повышайте экспертность знаний
См. также
и уменьшайте передачу из рук в руки.
Групповое программирование — резуль- Групповое программирование (глава 12)
тат одного из таких экспериментов.
Agile-команды сами контролируют свою работу. Они сами для себя решают, что бу-
дут делать, как делить работу на задачи и кто в команде будет их выполнять. Все это
основано на фундаментальном принципе Agile: люди, которые реально выполняют
работу, лучше всех знают, что нужно делать. Их квалификация настолько велика,
что позволяет им принимать решения относительно деталей.
Однако такой подход подразумевает, что команда берет на себя не только контроль
над работой, но и ответственность за ее выполнение.
В этой главе содержатся практики, которые помогут вам взять на себя ответствен-
ность за работу и успешно ее выполнить.
zz Практика «Планирование задач» позволяет вашей команде разбивать истории
на задачи и решать, как они будут выполняться.
zz Практика «Потенциал» помогает вашей команде браться только за то, что она
в состоянии сделать.
zz С помощью практики «Резерв времени» ваша команда повысит потенциал и смо-
жет взять на себя надежные краткосрочные обязательства.
zz Практика «Стендап-митинги» помогает членам команды координировать свою
работу.
zz Используя практику «Информативное рабочее пространство», ваша команда
получит полезную информацию.
zz Практика «Примеры заказчика» помогает вашей команде сотрудничать с экс-
пертами.
zz С помощью практики «Сделано Сделано» ваша команда сфокусируется на соз-
дании ПО, готового к релизу.
Глава 9. Владение 255
Источники владения
Самоорганизация и коллективное владение всегда были в центре идеи Agile.
Способы, которыми команды планируют свои задачи, различаются. В XP и Scrum
использовались короткие циклы, называвшиеся итерациями и спринтами. Другие
методы, такие как язык шаблонов EPISODES Уорда Каннингема, использовали не-
прерывный поток работы [Cunningham1995]. В итоге XP и Scrum стали доминиро-
вать в мейнстриме, а непрерывный поток выпал из списка обычных практик Agile,
пока не был введен вновь в 2005 году в составе метода Kanban Дэвида Андерсона.
В практику «Планирование задач» входят и итерации, и непрерывный поток.
Подход к итерациям основывается на XP, а подход к непрерывному потоку — на
варианте Kanban Арло Бельши Naked Planning.
Практика «Потенциал» происходит из XP, где она изначально требовала вычисле-
ний, называвшихся фактором загрузки. Мартин Фаулер и Кент Бек упростили идею
до концепции «скорость» (velocity) в своей книге Planning Extreme Programming1
[Beck2000b]. Я переименовал ее в «потенциал» (capacity) во избежание некоторых
распространенных заблуждений.
Термин «резерв времени» (slack) был впервые представлен во втором издании
по XP: Extreme Programming Explained [Beck2004]. Я подозреваю здесь влияние
[DeMarco2002]. На меня повлияли оба этих источника, а также [Goldratt1992], хотя
мой пример довольно уникален.
Мой подход к стендап-митингам (stand-up meetings) прошел через фильтр мно-
жества источников. Его основу сформировал Daily Scrum. XP добавило «стояние»
(standing up) и в итоге сформировало Daily Stand-Up. Так я впервые узнал об этом.
А современный подход «прогулка по доске» (walk the board), похоже, возник из
речи Брайана Марика на конференции в 2007 году [Marick2007b].
«Информативное рабочее пространство» — комбинация понятий «большие
наглядные диаграммы» (big visible charts) из первого издания книги по XP, «ин-
формативное пространство» из второго издания книги по XP и «конвекционные
потоки информации» (convection currents of information) Алистера Кокберна
[Cockburn2006].
На практику «Примеры заказчика» в значительной степени повлияла работа
с Уордом Каннингемом над его фреймворком для интегрированного тестирова-
ния (Framework for Integrated Test, Fit), инструментом, позволяющим заказчикам
общаться через тесты. В первом издании этой книги данная практика называлась
«Тесты заказчиков». Позже она превратилась в «Примеры заказчика» как результат
моего опыта применения и преподавания Fit.
Идея «Сделано Сделано» является общей и не имеет определенного перво-
источника. Связанный с ней термин «критерии готовности» (Definition of Done)
обычно приписывается Биллу Уэйку, хотя он говорит, что не он это начал2. С тех
пор термин стал центральной частью Scrum.
1
Бек К., Фаулер М. Экстремальное программирование: планирование. — СПб.: Питер, 2002.
2
В личном общении.
256 Часть II. Фокус на ценность
ПЛАНИРОВАНИЕ ЗАДАЧ
У нас есть план на эту рабочую неделю. Аудитория
Если вы следуете практикам, описанным Вся команда
в главе 8, то в итоге придете к визуальному
плану с несколькими уровнями детализации:
ценные инкременты, которые возможно выполнить в долгосрочной перспективе, ма-
ленькие ценные инкременты, которые, вероятно, будут выполняться в среднесрочной
перспективе, и специальные истории, которые будут сделаны в ближайшее время.
План превращается в действие с помощью планирования задач: разделения
историй на задачи и отслеживания прогресса команды. Поскольку Agile-команды —
самоорганизующиеся (см. врезку «Самоорганизующиеся команды» в главе 7), соз-
дание задач, их распределение между членами команды и отслеживание полностью
выполняются командой, а не руководителями.
Планирование задач состоит из трех частей: рабочего ритма (cadence, используется
также термин «каденция»), создания задач и визуального отслеживания.
Рабочий ритм
Рабочий ритм (каденция, cadence) — это частота вашего планирования задач. В со-
обществе Agile существуют два общих подхода: итерации (также называемые сприн-
тами1) и непрерывный поток (также называемый Kanban).
Итерации — это периоды времени с фиксированной продолжительностью, длящиеся
неделю или две. В начале каждой итерации вы выбираете набор историй для реализации
и к концу периода ожидаете, что все они будут выполнены. Непрерывный поток, напро-
тив, представляет собой бесконечную вереницу
историй. Вы выбираете следующую историю, как
только предыдущая закончена. См. также
Команды — новички в Agile должны ис
Потенциал (глава 9)
пользовать итерации. Не потому, что они про-
ще (вообще-то они сложнее), а потому, что Резерв времени (глава 9)
четкий ритм итераций дает командам воз-
можность получать важную обратную связь, позволяющую понять, как ей со-
вершенствоваться. И что еще важнее, благодаря правильному использованию
вашего итерационного потенциала вы получаете резерв времени, позволяющий
совершенствоваться.
Непрерывный поток не имеет таких встроенных возможностей для совершен-
ствования, какие есть в итерациях. Здесь сложнее заметить, когда работа идет
1
Слово «спринт» вводит в заблуждение. Разработка ПО больше похожа на марафон, чем на серии
спринтов. Вам нужно работать в таком темпе, который вы можете поддерживать сколь угодно
долго.
Глава 9. Владение 257
Итерации
Программная разработка обычно замирает постепенно. Сначала все идет хорошо:
«Я закончу эту задачу, как только доделаю этот тест». Затем вы говорите: «Я закончу,
как только исправлю этот баг». Потом вздыхаете: «Я закончу, как только исследую
этот недостаток в API… на самом деле нет». Не успеете оглянуться, как потратите
два дня на выполнение задачи, которую планировали сделать за два часа.
Беда подкрадывается к команде постепенно. Каждая проблема отнимает всего
лишь пару часов или день, поэтому не ощущается большой проблемой, но они мно-
жатся вокруг сотен задач в релизе. Совокупный эффект застает команды и их стейк-
холдеров врасплох.
Итерации позволяют вам обнаруживать
проблемы на ранней стадии. Время итераций См. также
строго ограничено: когда время истекло, ите-
рация закончена. В начале итерации (а каждая Сделано Сделано (глава 9)
обычно длится неделю или две) вы прогнози-
руете свой потенциал и выбираете истории, которые ему соответствуют. В конце
итерации все истории должны быть «сделаны сделаны». Если это не так, то вы знаете,
что у вас проблема. Итерации не предотвращают проблемы, а обнаруживают их,
что позволяет вам исправлять лежащие в их основе причины.
Итерации выполняются в соответствии с постоянным графиком.
1. Продемонстрировать результаты преды-
дущей итерации стейкхолдерам (полчаса). См. также
2. Провести ретроспективу предыдущей ите- Демо для стейкхолдеров (глава 10)
рации (один час).
Ретроспективы (глава 11)
3. Запланировать задачи для итерации (пол-
часа). Непрерывное развертывание
(глава 15)
4. Разработать истории (остаток итерации).
5. Развернуть ПО, если не используется непрерывное развертывание (автомати-
зировано).
Многие команды начинают свои итерации в понедельник утром, но я предпочитаю
итерации, которые начинаются утром в среду или четверг. Это позволяет командам
уйти на длинные выходные, не пропуская важных событий. Вдобавок это снижает
желание работать по выходным.
Итерации могут иметь любую длительность, но большинство команд используют
недельные или двухнедельные. Командам — новичкам в Agile лучше всего подходят
итерации длительностью в одну неделю. Причина в том, что команды развивают
свое понимание Agile, основываясь на том, сколько итераций они выполнили, а не
258 Часть II. Фокус на ценность
сколько недель опыта они получили. Чем короче итерации, тем быстрее команды
будут совершенствоваться1.
Вместе с тем итерации длиной в неделю ока-
См. также
зывают большее давление на команду. Это за-
трудняет активную работу и может помешать Энергичная работа (глава 7)
выполнению рефакторинга. Кроме того, при
Рефакторинг (глава 13)
итерациях длиной в неделю труднее предсказы-
вать потенциал, поскольку различные переры- Потенциал (глава 9)
вы и праздники пропорционально больше, чем
прерывания. Таким образом, как только ваша команда научится надежно завершать
истории в течение каждой итерации, двигайтесь дальше и экспериментируйте с двух-
недельными итерациями.
Итерации длиной больше двух недель обычно являются ошибкой. Команды на-
чинают использовать более длинные итерации, когда чувствуют, что им нужно боль-
ше времени, чтобы закончить работу. Но это только прячет проблему. Более длинные
итерации не изменят количества имеющегося у вас времени; они изменят лишь перио
дичность, с которой вы проверяете ваш прогресс.
Если вам трудно закончить все к концу ите-
рации, то это не потому, что вам нужно боль- Если вам трудно закончить
ше времени; это потому, что вам нужно больше все к концу итерации,
то используйте более
практики инкрементной работы. Сократите
короткие итерации
длительность ваших итераций, уменьшите исто- и уменьшите истории.
рии и сконцентрируйтесь на решении проблем,
которые мешают вам заканчивать истории.
Непрерывный поток
Непрерывный поток является именно тем, чем кажется: непрерывным потоком
историй без определенного начала и конца. Вместо того чтобы прогнозировать,
что ваша команда может делать каждую неделю, установите лимит незавершенной
работы (work in progress) — то есть над каким количеством историй ваша команда
будет работать одновременно. Лучше всего от одной до трех. Чем меньше, тем лучше
(см. врезку «Минимизируйте объем незавершенной работы» в главе 8). Как только
этот лимит достигнут, больше новых историй начинать нельзя. Когда история «сде-
лана сделана» (done done), ее убирают, освобождая место для новой.
В теории непрерывный поток менее расточителен, чем итерации, поскольку вам
не нужно предсказывать потенциал или рассчитывать истории так, чтобы они поме-
щались во временные рамки итерации. На практике я не нашел этому подтверждения.
Строгие временные рамки итераций удерживают внимание команды на завершении
историй. Команды, использующие непрерывный поток, не имеют такой же срочной
1
Я преподавал в классе, где студенты разрабатывали реальное программное обеспечение с помо-
щью 90-минутных итераций. У них был такой же прогресс в совершенствовании, какой я видел
у команд, использовавших итерации длиной в неделю.
Глава 9. Владение 259
КЛЮЧЕВАЯ ИДЕЯ
Коллективное владение
Agile-команды разделяют ответственность за результаты. Вся команда работает
совместно, чтобы завершить истории, и каждый участник свободно выбирает
работу, которую знает лучше всего, помогает тем, кто нуждается в помощи,
и выясняет, как наилучшим образом внести вклад в работу, с которой пока
знаком не очень хорошо. Если что-то идет не так, то команда совместно ра-
ботает над решением проблемы; если все хорошо, то команда считает это
общей заслугой.
Некоторые команды назначают отдельных членов, чтобы они индивидуально
работали над историями, но лучшие команды Agile делают это совместно. Они
берутся за одну историю за раз или настолько близко к этому, насколько воз-
можно, координируясь и взаимодействуя так, чтобы все делалось одновременно.
Таким образом они избегают риска, когда один человек застревает на чем-либо
и тормозит весь прогресс, а остальная команда об этом не знает.
В командах поставки это общее владение распространяется также и на код.
В разделе «Коллективное владение кодом» главы 12 описывается, как это ра-
ботает.
Создание задач
Начните планирование задач с выбора
историй. Если вы используете итерации, См. также
то выбирайте истории, основываясь на
Потенциал (глава 9)
своем итерационном потенциале: напри-
мер, 6 историй или 12 пойнтов. Если вы Визуальное планирование (глава 8)
используете непрерывный поток, то вы- Игра в планирование (глава 8)
бирайте истории в соответствии с вашим
лимитом незавершенной работы, затем планируйте новую историю, когда эта за-
канчивается. В любом случае выбирайте только те истории, которые готовы к за-
вершению: то есть вопросы сторонней зависимости решены либо же третья сторона
готова участвовать.
260 Часть II. Фокус на ценность
Визуальное отслеживание
Agile-команды совместно управляют своей работой, как было сказано во врезке «Кол-
лективное владение» ранее в данной главе. Задания не назначаются конкретным людям.
Вместо этого, когда кто-то готов начать работу над задачей, он смотрит на доступные
задачи и выбирает из них такую, в которую может внести свой вклад, или ту, которая
позволит ему чему-то научиться. Отслеживание прогресса и оказание помощи там,
где нужно, — ответственность всей команды.
Легко зациклиться на собственных задачах
в ущерб общему прогрессу команды. Не забывай- См. также
те оставаться в курсе общей картины и ставить
успех команды выше завершения своих задач. Информативное рабочее про-
странство (глава 9)
Стендап-митинги помогут вам сделать шаг назад
и подумать об общей картине, но еще более важ-
ным инструментом является ваша доска для отслеживания задач. Это центральная
часть вашего информативного рабочего пространства.
Мой любимый инструмент для отслеживания задач — большая магнитная доска.
Мне нравится использовать шестидюймовую доску на колесиках. На одну сторону
я помещаю визуальный план, а на другую — план задач. Если у вас удаленно работа-
ющая команда, то используйте виртуальную доску. Скорее всего, вам будет удобнее
помещать план задач и визуальный план на одну и ту же доску.
Доска с задачами — нервный центр вашей командной комнаты, как физической, так
и виртуальной. Она делает ваш прогресс наглядным в любое время. Поддерживайте
доску в актуальном состоянии. Когда вы начинаете работу над задачей, отмечайте
на доске ваше имя или инициалы. Физические команды часто используют для этой
цели специальные магниты с забавными картинками. Виртуальные команды могут
загрузить любые собственные изображения.
262 Часть II. Фокус на ценность
ПРИМЕЧАНИЕ
Так называемые инструменты планирования Agile, такие как Jira, только вносят
разногласия. Agile-команды постоянно экспериментируют с улучшениями и но-
выми рабочими процессами. Инструмент для планирования будет вам только
мешать.
Сетка задач
Сетка задач становилась хитом во всех командах, в которых я ее внедрял. Она про-
стая и компактная. Чтобы ее создать, расположите истории вертикально, разместив
историю с наивысшим приоритетом сверху. Справа от каждой истории в горизон-
тальную линию поместите задачи, связанные с этой историей, — в любом порядке,
который кажется наиболее естественным. Их можно делать не по порядку.
Когда люди готовы начать работу над задачей, они выбирают любую карточку,
с которой готовы работать, начиная с верхнего левого угла. Как только задача за-
вершена, пометьте карточку одним из способов: обведите зеленым маркером, до-
бавьте зеленый магнит или измените цвет виртуальной карточки. (Лучше не делать
надписи на карточках. Иногда задачи приходится
пересматривать.) Когда все задачи из истории См. также
завершены, последней задачей будет взглянуть
на ваше определение понятия «сделано», внести Сделано Сделано (глава 9)
финальные изменения, если нужно, и отметить
карточку зеленым цветом.
Сетки задач особенно полезны командам, работающим итерациями. Пример
представлен на рис. 9.1.
Глава 9. Владение 263
Доска детективов
Помните, в криминальных драмах часто присутствует доска со всей имеющейся
информацией о преступлении? Фотографии подозреваемых, улики, стрелочки от
одного к другому? Это доска детективов, и именно так работает визуализация1.
Пример показан на рис. 9.2.
1
Арло Бельши познакомил меня с доской детективов как частью своего процесса обнаженного
планирования (Naked Planning).
264 Часть II. Фокус на ценность
Кросс-командные зависимости
Некоторые истории могут зависеть от людей вне команды. Так как истории малень-
кие (обычно примерно на день работы, если команда работает совместно), лучше
подождать, пока эти сторонние зависимости не будут урегулированы. Подобным же
образом, если для истории требуется, чтобы кто-то временно вступил в команду,
подождите, пока этот человек освободится. Иначе вы в итоге получите частично
сделанную работу (см. врезку «Минимизируйте объем незавершенной работы»
в главе 8).
Конкретнее: когда выбираете истории для планиро-
вания задач, не выбирайте истории с неурегулирован- Не выбирайте истории
ными зависимостями. Если вы используете итерации, с неурегулированными
то такие истории должны подождать до следующей зависимостями.
итерации. Если вы используете непрерывный поток,
то подождите, пока не откроется следующий слот.
Если вы начинаете работать над историей и обнаруживаете, что у нее есть внеш-
няя зависимость, то можно пока оставить ее в плане. Но ограничьте ее короткими
временными рамками, например день или два. Если зависимость не будет решена
за это время, то уберите ее из плана и замените. Я помечаю такие истории красным
цветом и добавляю дату окончания срока действия.
Некоторые истории может делать ваша команда, затем другая и затем снова ваша.
Разбивайте такие истории на две: первая — подготовка истории для другой команды,
вторая — история, которую вы начинаете после того, как другая команда завершила
свою часть работы. Помните, истории должны быть ориентированы на заказчика,
как было написано в подразделе «Ценность для заказчика» главы 8.
В целом Agile-команды должны быть в состоянии взять на себя полную ответствен-
ность за разрабатываемые ими истории. Если ваша команда сталкивается с частыми
задержками из-за кросс-командных взаимозависи-
мостей, то что-то идет не так. Возможно, у вас не вся См. также
команда или ваша организация выбрала неправильный
подход к масштабированию (см. главу 6). Попросите Вся команда (глава 7)
помощи у наставника.
Глава 9. Владение 265
Незаконченные истории
В конце итерации все истории должны быть
в статусе «Сделано Сделано». Частично сде- См. также
ланные истории должны быть редкостью. Это
означает, что они будут случаться иногда, в ос- Сделано Сделано (глава 9)
новном пока вы еще учитесь. Потенциал (глава 9)
Незавершенный код вредоносен. Если вы
не планируете завершить историю немедленно
в следующей итерации, то вырежьте ее код из кодовой базы и верните историю об-
ратно в ваш визуальный план. Если вы планируете завершить работу, то создайте
новую историю, представляющую оставшуюся работу. Если вы используете оценки,
то сделайте ее заново. Вам не нужно, чтобы частично сделанная работа была засчита-
на в ваш потенциал, поскольку тогда вы придете к тому, что опять возьмете на себя
слишком много работы.
Иногда, несмотря на все ваши усилия, вы будете обнаруживать, что ничего
полностью не выполнено. Некоторые команды объявляют потерянную итерацию,
когда это случается. Они откатывают код и начинают все сначала, как если бы ите-
рации не было. Звучит сурово, но это хорошая практика. Итерации короткие, по-
этому много кода вы не выбросите и у вас останется все, что вы узнали и чему научи-
лись, пока писали его в первый раз. В результате второй попытки получится
лучший код.
Компетентные команды редко имеют не-
законченные истории. Если у вас проблемы Если у вас проблемы
с завершением историй, то измените ваш под- с завершением историй,
ход. Снизьте ваш запланированный потенци- то измените ваш подход.
ал, разбивайте истории на еще более мелкие
и координируйте общие командные усилия, нацеливая их на завершение каждой
истории, прежде чем переходить к следующей. Если это не поможет, значит, что-то
организовано неправильно. Спросите совета у вашего наставника.
Срочные запросы
Это неизбежно: вы в середине работы над историей, все идет хорошо, а потом кто-
нибудь из стейкхолдеров говорит: «Нам в самом деле очень нужно взять в работу
вот эту историю». Что вы будете делать?
Глава 9. Владение 267
Вопросы
Как планирование задач может занимать менее 10–30 минут? У нас на это всегда
уходит гораздо больше времени.
Хитрость эффективного планирова-
ния задач в том, чтобы использовать его См. также
только для планирования задач. Мно-
жество команд используют свои сессии Игра в планирование (глава 8)
планирования для оценки и разделения
историй, но лучше это делать в рамках отдельной сессии игры в планирование. Пла-
нирование задач должно быть сфокусировано на задачах. Истории должны быть
готовы до того, как вы начнете.
Еще одна хитрость — работать одновременно, используя свободный подход вме-
сто инструментов для отслеживания задач (см. пункт «Работайте одновременно»
главы 7). Команды, использующие систему трекинга, как правило, сталкиваются
с проблемой узкого места процесса из-за того, что один человек управляет системой
и это все замедляет.
Используя эти две хитрости и немного попрактиковавшись, ваша команда
легко сможет запланировать задачи менее чем за 30 минут. Если же планирование
все еще идет медленно, то причиной может быть то, что людям трудно прийти
к согласию по поводу того, что предстоит делать. Помните, что лучше создавать
специальные задачи для открытых вопросов, чем пытаться решать их во время
встречи по планированию задач. Если и это не поможет, то попросите совета у на-
ставника.
270 Часть II. Фокус на ценность
Предварительные требования
И итерации, и непрерывный поток полагаются на небольшие истории — каждая
примерно на один день, если команда работает совместно. Более крупные истории
могут незаметно выполняться неправильно.
Каждая история, законченная командой, должна
вести к прогрессу, который могут признать и оценить См. также
заказчики в команде — если не в эксплуатационной
(production) среде, то хотя бы в промежуточной Истории (глава 8)
(staging). Для этого требуется, чтобы истории были Инкрементный дизайн
ориентированы на заказчика, а техническая инфра- (глава 14)
структура создавалась инкрементно. Потенциал (глава 9)
Последовательное выполнение обязательств
Резерв времени (глава 9)
в итерациях требует, чтобы ваши возможности ос-
новывались на измеренной реальности. Никогда
не завышайте искусственно потенциал вашей команды. Но даже в этом случае что-
то может пойти не так, поэтому ваша итерация должна содержать резерв времени,
чтобы покрыть эти проблемы.
Никогда не используйте обязательство как дубинку. Не заставляйте членов коман-
ды подписываться на план, с которым они не согласны. Не раскрывайте информацию
об обязательствах по итерациям вне команды, пока у вас не будет подтвержденного
списка успешных случаев выполнения таких обязательств.
Глава 9. Владение 271
Показатели
Когда вы хорошо планируете ваши задачи:
zz вся команда понимает, что нужно сделать, чтобы завершить истории;
zz команда совместно работает над выполнением своего плана;
zz команда понимает, когда все идет хорошо, а когда нет, и предпринимает действия,
необходимые для решения проблем.
Когда вы правильно применяете итерации:
zz ваша команда имеет стабильный, предсказуемый потенциал;
zz стейкхолдеры знают, чего ожидать от команды, и верят, что она выполнит свои
обязательства по итерации;
zz команда быстро обнаруживает ошибки и обычно может с ними разобраться,
не влияя на свои обязательства по итерации.
Альтернативы и эксперименты
Выдающееся отличие Agile-планирования задач от не-Agile — коллективное вла-
дение. Команды Agile не только отвечают за свое планирование, но и совместно
работают над выполнением плана. В не-Agile-командах обычно руководители
распределяют задачи среди сотрудников, и люди фокусируются на своих индиви-
дуальных задачах.
Еще одно различие заключается в итеративной и поэтапной природе Agile.
Маленькие истории приводят к стабильному инкрементному прогрессу. Команды
демонстрируют этот прогресс с помощью работающего ПО каждую неделю или две.
Они используют это ПО для получения обратной связи, которая, в свою очередь,
заставляет их итеративно повторять свои планы.
Когда вы задумаетесь о способах экспериментирования с планированием задач,
помните об этих различиях. Однако не стремитесь слишком сильно к эксперимен-
там: в планировании задач очень много тонкостей, особенно в итерациях, поэтому
сфокусируйтесь на том, чтобы достичь действительно хороших результатов в назна-
чении и выполнении обязательств по недельным итерациям, и только потом ищите
альтернативы. Отведите на это по меньшей мере несколько месяцев.
Когда будете готовы к экспериментам, самым очевидным вариантом будет по-
пробовать непрерывный поток вместо итераций. Кроме того, вы можете поэкспери-
ментировать с длиной итераций и размером историй. Некоторые команды предпо-
читают использовать очень маленькие истории, выполнение которых занимает всего
несколько часов. Для таких команд задачи не являются необходимостью. Истории
настолько малы, что сами по себе служат задачами.
Область, в которой вы можете сразу начать эксперименты, — это визуализация
вашей доски задач. Как наглядное представление процессов вашей команды, она
может и должна меняться в любое время, когда у вас появляются идеи по улучшению
ваших процессов.
Одна из общеизвестных визуализаций задач — создание вертикальных обзор-
ных полос (swim lanes), показывающих прохождение историй через разные фазы
272 Часть II. Фокус на ценность
ПОТЕНЦИАЛ
Мы знаем, за какой объем работы можем взяться.
Предполагается, что команды, использующие ите- Аудитория
рации, должны завершать каждую историю в каждой
Разработчики
итерации. Но как они узнают, за какое количество
историй они могут взяться? Здесь и появляется по-
нятие потенциала. Потенциал — это прогнозный показатель того, сколько работы
команда может гарантированно выполнить за одну итерацию.
Потенциал нужен только для того, чтобы спрогнозировать, что вы можете вклю-
чить в вашу следующую итерацию. Если же вам нужно рассчитать, когда будет
выпущен конкретный набор историй, то прочитайте раздел «Прогнозирование»
главы 10.
Если вы используете непрерывный поток вместо итераций, то вам не нужно бес-
покоиться о потенциале. Вы просто будете начинать новые истории, когда закончите
предыдущие.
ПРИМЕЧАНИЕ
Изначально потенциал (capacity) назывался скоростью (velocity). Но я больше
не использую этот термин, поскольку «скорость» предполагает такой уровень
контроля, которого на самом деле не существует. Представьте автомобиль:
его скорость легко увеличить; просто нажмите педаль газа. Но если вам нужно
повысить потенциал автомобиля, то потребуются более серьезные изменения.
Потенциал команды — то же самое. Его не так просто изменить.
1
Кон М. Agile: оценка и планирование проектов.
2
Бек К., Фаулер М. Экстремальное программирование: планирование. — СПб.: Питер, 2002.
3
Андерсон Д. Дж. Канбан. Альтернативный путь в Agile.
Глава 9. Владение 273
Вчерашняя погода
Потенциал может быть спорной темой. За-
казчики хотят, чтобы команда поставля- Когда на команды давят, чтобы они
ла больше каждую неделю. Разработчики подписались на большее, чем могут
сделать, проигрывают все.
не хотят, чтобы их торопили или давили на
них. Так как заказчики обычно пользуются
вниманием спонсора команды, то имеют тенденцию побеждать… в краткосрочной
перспективе. В долгосрочной перспективе, когда на команды давят, чтобы они под-
писались на большее, чем могут сделать, проигрывают все. Реальность побеждает,
и разработка в итоге занимает больше времени, чем ожидалось.
Чтобы избежать этих проблем, измеряйте свой потенциал. Не гадайте. Не надей
тесь. Просто измеряйте. Это просто: вероятно, на этой неделе вы сделаете столько же,
сколько сделали на прошлой. Это также известно как «вчерашняя погода», поскольку
вы можете прогнозировать сегодняшнюю погоду, говоря, что она, скорее всего, будет
такой же, как вчерашняя.
Если конкретнее, ваш потенциал — это количество историй, которые вы начали
делать и полностью закончили в предыдущей итерации. Частично сделанные исто-
рии не считаются. Например, если вы начали семь историй в прошлой итерации
и завершили шесть из них, то ваш потенциал — шесть, и в следующей итерации вы
можете взять в работу шесть историй.
ПРИМЕЧАНИЕ
Не усредняйте несколько итераций. Просто используйте предыдущую. В подраз-
деле «Стабилизация потенциала» далее в этой главе объясняется, как установить
стабильный потенциал без усреднения.
Подсчет историй работает, только если ваши истории примерно одного разме-
ра. Вы можете разделять и объединять истории, чтобы получить размер «в самый
раз», как описывалось в подразделе «Разделение и объединение историй» главы 8.
Со временем ваша команда научится делать истории одного размера.
Поначалу ваши истории, скорее всего, не будут иметь одинаковый размер. В этом
случае вы можете делать оценку историй, как я описываю в подразделе «Оценка
историй» далее в данной главе. Чтобы измерить ваш потенциал, используя оценки,
посмотрите на истории, которые вы начали и полностью завершили за последнюю
итерацию. Сложите их оценки. Это и будет ваш потенциал.
Например, если вы завершили шесть историй из тех, что начали в предыдущей
итерации, и их оценки были 1, 3, 2, 2, 1, 3, то ваш потенциал — 1 + 3 + 2 + 2 + 1 + 3 = 12.
Для следующей итерации вы можете выбрать любые понравившиеся вам истории
так, чтобы их общая оценка равнялась 12.
«Вчерашняя погода» — простой и при этом удивительно утонченный инструмент.
Это петля обратной связи, которая приводит к магическому эффекту: если ваша
команда недооценивает свою рабочую нагрузку и не может завершить все истории
к концу итерации, то ваш потенциал снижается и вы беретесь за меньшее количество
работы в следующий раз. Если вы переоцениваете свою нагрузку и заканчиваете
274 Часть II. Фокус на ценность
Стабилизация потенциала
Когда вашей команде не удается закончить все,
что она запланировала, ваш потенциал должен См. также
снизиться. Это даст вам больше времени, чтобы
закончить работу в следующей итерации, что Сделано Сделано (глава 9)
приведет к стабилизации вашего потенциала
на новом, пониженном уровне.
Глава 9. Владение 275
Оценка историй
«Вчерашняя погода» полагается на стабильность, но у вашей команды могут быть
трудности с созданием историй постоянного размера. Это нормально. Вы можете
использовать оценку.
Как обсуждалось во врезке в предыдущем подразделе, неважно, насколько точны
ваши оценки, пока они постоянны. Это хорошая новость, поскольку программисты,
как правило, оценивают очень плохо. Одна команда, с которой я работал, измеряла
реальное время, которое занимали ее истории. Мы делали это в течение 18 месяцев.
Оценки никогда не были точными: в среднем команда использовала около 60 %
фактически необходимого времени.
Но знаете что? Это было неважно, поскольку оценки, даваемые командой, были
стабильны, по крайней мере в совокупности. У той команды был стабильный по-
тенциал, и она постоянно завершала каждую историю в течение нескольких месяцев.
Таким образом, делайте оценку ваших историй и не беспокойтесь о точности.
Просто концентрируйтесь на стабильности. Вот как это нужно делать.
zz Оценивайте только ограничение. Один вид работы (как правило, программиро-
вание) будет узким местом всего рабочего процесса вашей команды. Оценивайте
все ваши истории только с точки зрения этого вида работы, поскольку именно
ваше ограничение будет определять ваш график работы. Иногда будут встречаться
исключения, но их компенсирует резерв времени в итерации.
zz Позвольте экспертам делать оценки. Сколько времени займет работа над
историей, по мнению членов команды, наиболее квалифицированных в этой
работе?
zz Делайте оценку в идеальных часах или днях. Сколько времени займет работа над
историей, если ее будет делать один из наиболее квалифицированных членов
вашей команды, его не будет никто отвлекать от работы, он сможет задавать во-
просы любому другому человеку в команде, не должен будет ждать никого вне
команды и все будет идти хорошо?
zz Думайте о задачах. Если вам трудно делать оценки, то мысленно разбейте исто-
рию до составляющих ее задач, затем сложите время, необходимое на выполнение
каждой из них.
zz Округляйте в три корзины. Все, что больше, должно быть разделено; все, что
меньше, — объединено. Чтобы выбрать свою корзину, разделите ваш потенциал
на 12, затем умножьте на 2 и 3. Настраивайте результаты по мере необходимости.
Например, если ваш потенциал находится между 9 и 14, то ваша корзина должна
быть размером 1, 2 и 3. Если потенциал между 3 и 8, то ваша корзина должна
быть размером 1/2, 1 и 11/2. Цель — иметь по меньшей мере четыре истории на
итерацию и шесть в среднем.
Этот подход даст вам оценку в идеальных часах или днях. Реальная работа займет
гораздо больше времени, но это неважно: вы стремитесь к постоянству, а не к точно-
сти. Чтобы люди ошибочно не принимали ваши оценки за обязательства, называйте
эти цифры пойнтами, а не часами или днями.
278 Часть II. Фокус на ценность
Разговорная оценка
При разговорной оценке команда оценивает одну историю за раз. Этот способ может
быть утомительным, но позволяет привести всех к единому пониманию того, что
должно быть сделано.
Заказчик в команде начинает каждую сессию оценки, выбирая историю и давая
краткое пояснение. Оценщики могут задавать вопросы, но только если ответ может
как-то изменить их оценку. Как только кто-то из оценщиков чувствует, что у него
достаточно информации, он предлагает свой вариант оценки. Пусть это происходит
естественно: тот, кому комфортнее всех, должен высказаться первым, так как обычно
это именно тот человек, который наиболее квалифицирован для оценки.
Если предложенный вариант оценки кажется неверным или если вы не понимаете,
из чего он следует, то попросите больше подробностей. В качестве альтернативы,
если вы один из оценщиков, то предложите собственный вариант оценки и объяс-
ните свой ход мыслей. Последующая дискуссия прояснит оценку. Когда оценщики
придут к согласию, запишите оценку на карточку истории.
280 Часть II. Фокус на ценность
Поначалу у разных членов команды будут разные идеи о том, сколько времени зай
мет что-либо. Это будет приводить к нестабильным оценкам. Проговорите это, и если
вы не сможете прийти к согласию, то используйте наименьшую оценку. (Помните,
вам нужно только постоянство, а не точность.) Со временем, когда команда будет
продолжать совместно делать оценки, ваши оценки будут синхронизироваться. Как
правило, это происходит в течение трех или четырех итераций.
Если участники понимают историю и лежащую в ее основе технологию, то смогут
оценить каждую историю менее чем за минуту. Если им необходимо обсудить тех-
нологию или задать вопросы заказчикам, то оценка может занять больше времени.
Я ищу способы завершить дискуссию, если процесс оценки начинает занимать больше
пяти минут. Если каждая история требует подробного обсуждения, то что-то идет
не так — см. подраздел «Когда оценить трудно» далее в текущей главе.
ПРИМЕЧАНИЕ
Некоторым нравится использовать для оценки покер планирования (planning
poker)1. В нем участники тайно выбирают карточку со своей оценкой, затем
одновременно раскрывают карты и обсуждают результаты. Это звучит забавно,
но приводит к множеству ненужных дискуссий. Данный метод полезен, если
людям трудно выражать свое мнение, но в других случаях обычно быстрее дать
высказаться первым тому, кто не испытывает с этим неудобств.
Оценка по сходству
Оценка по сходству (affinity estimating) — прекрасная техника быстрой оценки боль-
шого количества историй2. Она особенно полезна, когда у вас длинные горизонты
планирования.
Оценка по сходству — вариант молчаливого сопоставления (mute mapping)
(см. пункт «Работайте одновременно» главы 7). Заказчик в команде кладет стопку
карточек для оценки на стол или виртуальную доску. Один конец определяется как
наименьший, а другой — как наибольший. Затем оценщики распределяют карточки
вдоль этого спектра, группируя их в кластеры похожего размера. Карточки, которым
требуются дополнительные пояснения от заказчиков, помещаются в отдельный
кластер в стороне, как и карточки, которым требуется спайк-история (см. пункт
«Спайк-истории» главы 8).
Вся эта работа выполняется молча. Оценщики могут передвигать карточки, если
не согласны с тем, где те находятся, но не могут это обсуждать. Выполнение этой
работы в тишине помогает не отвлекаться, что обычно характерно для процесса об-
суждения оценок. В результате составление карты оценок происходит очень быстро.
1
Покер планирования (planning poker) был изобретен Джеймсом Греннингом в 2002 году
[Grenning2002] и позже популяризирован Майком Коном в [Cohn2005]. Компания Кона, Mountain
Goat Software, LLC, зарегистрировала этот термин как торговую марку.
2
Оценка по сходству (affinity estimating) была изобретена Ловеллом Линдстромом в ранние дни
экстремального программирования.
Глава 9. Владение 281
Защита оценки
Это почти закон природы: заказчики в команде и стейкхолдеры неизменно разоча-
рованы потенциалом своей команды. Иногда они выражают это в неуважительной
манере. Члены команды, обладающие хорошими социальными навыками, могут по-
мочь разрядить обстановку. Часто лучшим подходом будет игнорировать тон людей
и расценивать комментарии как простые запросы информации.
На самом деле некоторое количество обмена репликами даже полезно. Как
обсуждалось в подразделе «Как выиграть в игре в планирование» главы 8, во-
просы относительно оценок могут приводить к созданию лучших историй,
сфокусированных на таких аспектах идей заказчиков, как высокая ценность
и низкая стоимость.
Однако будьте осторожны: вопросы мо-
гут заставить оценщиков усомниться в сво- Вежливо и твердо откажитесь менять
их оценках. Разработчики, ваши оценки, вашу оценку, если на вас давят.
скорее всего, корректны или по меньшей
мере стабильны, что действительно важно. Меняйте свою оценку, только если узнали
что-то поистине новое. Не меняйте ее лишь потому, что чувствуете, что на вас давят.
Вы — те, кто будет реализовывать истории, и вы наиболее квалифицированны, чтобы
делать оценки. Будьте вежливы, но настойчивы:
Мне жаль, что вам не нравятся эти оценки. Мы уверены, что они корректны, но
если они слишком пессимистичны, то наш потенциал автоматически возрастет,
Глава 9. Владение 283
Поддерживать ограничение
Люди, которые не могут участвовать в работе над задачами, связанными с ограни-
чениями, будут иметь свободное время. Они должны сделать так, чтобы тем, кто
работает над ограничениями, никогда не приходилось их ждать, но не должны рабо-
тать на опережение. Это только создаст дополнительный объем незавершенной
работы (см. врезку «Минимизируйте объем незавершенной работы» в главе 8).
Вместо этого используйте дополнительное время для снижения нагрузки на актив-
ность, связанную с ограничением. Классический пример — тестирование. Некоторым
командам нужно так много ручного тестирования,
что последние дни каждой итерации у них полно- Используйте
стью посвящены тестированию ПО. Вместо того дополнительное время
чтобы переходить к разработке следующего набора для снижения нагрузки
функциональностей, программисты могут использо- на активность, связанную
вать это время для написания автоматизированных с ограничением.
тестов, что снизит нагрузку на тестирование.
286 Часть II. Фокус на ценность
времени, которое они тратят на ожидание других людей. Время, которое они тратят
на выполнение рутинных задач организации. Как часто они выбирают «короткий
путь», выполняя задачи. Объем их резерва времени.
Эти факторы различаются у каждой команды, поэтому вы не можете использо-
вать потенциал для сравнения двух команд. Если у одной команды вдвое больший
потенциал, чем у другой, это может означать, что у нее меньше затрат на рутину… но
более вероятно, что у нее просто другой подход к оценке.
Кроме того, у команд нет возможности контролировать большинство факторов,
которые влияют на потенциал. В краткосрочной перспективе они могут только
управлять количеством своих рабочих часов и количеством «коротких путей».
Таким образом, команда, о которой судят по ее потенциалу, может ответить на это
давление, только работая сверхурочно, делая работу небрежно или уменьшая свой
резерв времени. Это может вызвать краткосрочный скачок потенциала, но снизит
реальную способность команды поставлять продукт.
Не разглашайте значение потенциала команды за ее пределами. Если вы руко-
водитель, то не отслеживайте, не поощряйте и даже не обсуждайте потенциал, за
исключением вопросов содействия его стабилизации. И никогда не называйте его
производительностью.
Чтобы понять, что нужно делать вместо этого, прочтите раздел «Менеджмент»
главы 10.
К А Р ГО - К УЛ ЬТ
Нужно торопиться
«Вам нужно поторапливаться! — рявкает Бекки. Она руководитель
вашего руководителя. — У команды Сильвы потенциал вдвое
больше вашего. Это ненормально, что у вас вдвое меньшая про-
изводительность».
«Окей… — говорите вы, с трудом подавляя желание сделать
что-нибудь неблаговидное и наконец освободиться от всего
этого. — Во-первых, команда Сильвы занята совершенно другой
работой, поэтому значения потенциала несравнимы. Во-вторых, — вы пытаетесь
улыбнуться, — я бы очень хотел повысить наш потенциал. Самое большое препят-
ствие, которое нас сдерживает, — ограниченный доступ к Кристиане. Она не хочет,
чтобы мы сами общались со стейкхолдерами, но при этом не может участвовать
в наших сессиях планирования. Нам постоянно приходится переделывать работу».
«Ох, только не надо, — не соглашается Бекки. — Она занята. А вы же Agile. Это
значит — вы владельцы, и у вас ответственность, верно? Вот и разберитесь с этим».
Неблаговидные поступки — это, наверное, не так уж и плохо, правда? К счастью,
из-за угла выходит ваш руководитель, Даррел.
«Бекки! Как хорошо, что я тебя встретил. Я услышал, что ты говорила насчет
Кристианы, и у меня есть отличная идея. Ты права насчет владения и ответствен-
ности. Почему бы нам не забрать часть работы у Кристианы? Мы возьмем на
себя общение со стейкхолдерами, а у нее освободится время для того, чтобы
288 Часть II. Фокус на ценность
Вопросы
Как нам считать частично выполненные истории?
Частично выполненные истории не считаются. При наличии нескольких таких
историй в конце итерации создайте новую историю для оставшейся работы и заново
оцените ее, если используете оценки. (Больше информации вы найдете в подразделе
«Незаконченные истории» ранее в данной главе.) Та часть, которую вы сделали в этой
итерации, не засчитывается в ваш потенциал; это значит, ваш потенциал снизится.
Возможно, это звучит сурово, но если вы правильно используете итерации, по-
тенциал и резерв времени, то частично выполненные истории должны случаться
редко. Если они у вас есть, значит, что-то пошло не так. Снижение вашего потенциала
высвободит резерв времени, необходимый вашей команде для решения проблемы.
Как нам менять потенциал при добавлении или удалении людей из команды?
Если вы добавляете в команду или выводите из нее только одного человека, то
попробуйте оставить ваш потенциал без изменений и посмотрите, что получится.
Другой вариант — изменять ваш потенциал пропорционально. В любом случае ваш
потенциал примет правильное значение после следующей итерации.
Как мы можем иметь стабильный потенциал? Люди уходят в отпуска, болеют и т. д.
Резерв времени вашей итерации должен справиться с небольшими колебаниями
доступности людей. Если отсутствует больше людей, как, например, в праздники, то
ваш потенциал может снизиться на одну итерацию. Это нормально. Вы можете его
восстановить в следующей итерации.
Если у вас маленькая команда, то вы можете обнаружить, что даже одного дня
отсутствия достаточно для дестабилизации потенциала. В этом случае вы можете
попробовать использовать двухнедельные итерации. Возможные компромиссы
обсуждались в пункте «Итерации» ранее в данной главе.
Разве участие в совместной оценке историй не является лишней тратой времени
для каждого?
Людям требуется много времени на совместную оценку, но это время потрачено
не зря. Сессии оценки нужны не только для оценки — вдобавок к этому они являются
критически важным первым шагом в получении информации и прояснении того,
что нужно сделать. Разработчики задают вопросы и проясняют детали, что часто
порождает идеи, которые заказчики в команде даже не рассматривали. Иногда это
сотрудничество снижает общие затраты, как описывается в подразделе «Как выиграть
в игре в планирование» главы 8.
Все разработчики должны присутствовать, чтобы убедиться в том, что они пони-
мают, чем им предстоит заниматься. Их участие также улучшает стабильность оценок.
Глава 9. Владение 289
Предварительные требования
Потенциал предполагает использование
итераций и требует резерва времени, чтобы См. также
сгладить небольшие проблемы и несты-
ковки. Планирование задач (глава 9)
Оценка требует доверия: разработчики Резерв времени (глава 9)
должны верить, что они могут давать точные
Доверие стейкхолдеров (глава 10)
оценки, не опасаясь нападок, а заказчики
и стейкхолдеры должны верить, что разра-
ботчики дают честные оценки. Этого доверия поначалу часто может не быть, и тогда
вам нужно работать над тем, чтобы оно появилось.
Независимо от вашего подхода к оценкам и потенциалу никогда не используйте
значения потенциала или неверные оценки для нападок на разработчиков. Это бы-
стрый и легкий способ разрушить доверие.
290 Часть II. Фокус на ценность
Показатели
Когда вы правильно используете потенциал:
zz он последователен и предсказуем каждую итерацию;
zz вы берете на себя итерационные обязательства и стабильно их выполняете;
zz процесс оценки проходит быстро и легко или вообще не требуется;
zz вы можете измерить большинство историй за минуту или две.
Альтернативы и эксперименты
Идея в основе потенциала — это «Вчерашняя погода»: фокусироваться на стабиль-
ности и согласованности, а не точности; основывать свои прогнозы на прошлых
измерениях и использовать их для создания петли обратной связи, которая будет
автоматически сама себя корректировать.
Количество подходов к оцениванию и прогнози-
рованию бесконечно. Преимущество «Вчерашней См. также
погоды» — в простоте и надежности. Однако она не без-
упречна и полагается на резерв времени, чтобы компен- Резерв времени (глава 9)
сировать свои недостатки. Другие подходы много чего
усложняют в попытке достичь большей точности. Несмотря на эту дополнительную
сложность, я еще не видел, чтобы кто-то приблизился к тому, чтобы работать так, как
комбинация петли обратной связи «Вчерашняя погода» и резерва времени.
Вы можете поэкспериментировать в поисках лучших способов определения по-
тенциала, но не делайте это сразу. Сначала научитесь применять подход из данной
книги и надежно завершать итерации и поработайте с ним несколько месяцев. Смена
подхода к планированию потенциала имеет глубокий эффект, и его трудно увидеть,
не обладая достаточным опытом.
Одна из известных мне наиболее популярных альтернатив — основывать потен-
циал на среднем значении предыдущих итераций, а не на одной прошлой. Другой
подход — засчитывать истории, которые были начаты в одной итерации и закончены
в другой. Я думаю, что оба подхода ошибочны: они основываются на желании повы-
сить потенциал, но увеличивают только цифру, обозначающую потенциал, не увели-
чивая реальную способность команды поставлять продукт. Они лишь увеличивают
вероятность того, что командам будет сложно выполнять свои обязательства. Лучше
сделать над собой усилие, запланировать более низкий потенциал и использовать
имеющийся резерв времени, чтобы повысить фактическую, реальную возможность
команды поставлять продукт.
Другой популярный вариант — движение без оценок (#NoEstimates), которое
полностью отходит от них. Существуют два подхода без оценок, и я включил их
в эту книгу. Первый — считать истории, вместо того чтобы оценивать их, как опи-
сывается в данной практике. Некоторые команды используют очень маленькие
истории (больше дюжины на итерацию), чтобы это работало. Второй подход — во-
обще не использовать итерации, а вместо этого применять непрерывный поток, как
описывается в разделе «Планирование задач» ранее в данной главе. Обе идеи стоит
попробовать после того, как вы овладеете основами.
Глава 9. Владение 291
РЕЗЕРВ ВРЕМЕНИ
Мы выполняем наши обязательства по итерации. Аудитория
ПРИМЕЧАНИЕ
Помните, что команда сама решает, какие обязательства принимать на себя и де-
литься ли своими планами по этим обязательствам за пределами команды. Более
подробная информация представлена в подразделе «Принятие и выполнение
обязательств по итерации» ранее в данной главе.
Эти цифры приведены только для иллюстрации. Вместо того чтобы измерять
количество часов, которое вы тратите на решение проблем, воспользуйтесь петлей об-
ратной связи потенциала, описанной в подразделе «Стабилизация потенциала» ранее
в данной главе. Если ваш потенциал колеблется в большом диапазоне, то перестаньте
подписываться на большее количество историй, чем позволяет ваш потенциал. Это
приведет к тому, что он установится на более низком уровне, который будет содер-
жать резерв времени вашей команды. С другой стороны, если вы все завершаете рано,
включая время на очистку во всех частях кода, в которых что-то делали, то уменьшите
ваш резерв, взявшись за маленькую дополнительную историю в следующей итерации.
292 Часть II. Фокус на ценность
ПРИМЕЧАНИЕ
Всегда оставляйте ваш код и ваши системы в несколько улучшенном состоянии,
чем когда вы нашли их, неважно, сколько времени у вас есть. Вы не выбираете
между «неряшливый» и «чистый»; вы выбираете между «немного чище» и «зна-
чительно чище». Всегда находите время для того, чтобы делать работу хорошо.
Беспорядок отберет у вас больше времени, чем сбережет.
ПРИМЕЧАНИЕ
Если вы обеспокоены тем, чтобы люди не лентяйничали в это время, то пригласи-
те всех на обед на следующий день и в ходе неформального общения попросите
поделиться тем, что они узнали. В любом случае это может быть прекрасным
вариантом для «перекрестного опыления» идей.
Когда вы только внедряете практику времени исследования, вам может быть слож-
но решить, над чем работать. Подумайте, что вас озадачило недавно. Хотели бы вы
узнать больше о вашем UI-фреймворке или коде? Есть ли какой-то язык программи-
рования, который вы хотели попробовать, но в вашей организации он не использует-
ся? Возможно, вас всегда интересовали сети реального времени (real-time networking)?
В ходе вашего исследования созда-
вайте спайк-решения (маленькие отдель- См. также
ные программы), демонстрирующие, что
вы узнали. Если вы экспериментируете Спайк-решения (глава 13)
с кодом эксплуатационной среды, то соз-
дайте временную ветку. Не пытайтесь сделать что-то полезное в широком смысле;
это только уменьшит количество времени, отведенного на реализацию конкретных
идей. Сделайте только то, чего будет достаточно для проверки концепции, затем
переходите к следующей задаче.
Роль переработок
Переработки не являются результатом
работы петли обратной связи потенциала, См. также
но служат источником резерва времени.
Используйте их с осторожностью. Если вы Энергичная работа (глава 7)
добровольно хотите поработать дольше,
чтобы завершить какую-то историю или задачу, — это нормально. Однако не превра-
щайте это в привычку и не перерабатывайте больше чем на час или около того в любой
конкретный день. Вам нужно время на отдых и перезарядку, если вы хотите быть про-
дуктивными на следующий день. Уделяйте внимание своей энергии и никогда не ис-
пользуйте переработки как предлог для снижения рабочих стандартов вашей команды.
Вопросы
Если наши обязательства находятся под угрозой срыва, то должны ли мы временно
отменить парное программирование, рефакторинг, разработку через тестирование
и т. д.? Ведь исполнение обязательства — это самое важное?
С опытом эти практики должны начать ускорять вашу работу, а не замедлять, но
у них есть кривая обучения (или научения). Действительно, если вы их отложите,
то на раннем этапе сможете быстрее выполнить свои обязательства.
Но все же вы не должны использовать их в качестве источника резерва времени.
Эти практики поддерживают вашу способность поставлять высококачественный код.
Если вы не будете им следовать, то из-за снижения внутреннего качества ваша работа
сразу замедлится. Вы сможете выполнить
конкретные обязательства текущей итера- См. также
ции, но сделаете это за счет следующей.
Если вам не хватает резерва времени, Парное программирование (глава 12)
чтобы справиться с обязательством, то Групповое программирование (глава 12)
не понижайте свои стандарты. Лучше
296 Часть II. Фокус на ценность
Предварительные требования
Риск резерва времени заключается в том, что может вызвать у людей представление,
что такие активности, как повышение внутреннего качества и развитие навыков
в сфере деятельности заказчика, неважны. На самом деле они жизненно важны,
и команда, которая их игнорирует, со временем замедлит темпы работы. Они просто
не настолько срочные, как ваши обязательства по итерациям. Убедитесь, что ваш
резерв времени достаточно велик для того, чтобы вы могли стабильно совершен-
ствоваться. Если не получается, то немного понизьте свой потенциал, чтобы все же
это сделать.
Вдобавок никогда не делайте работу небрежно ради вашего резерва времени.
Если вы не можете выполнить обязательства по итерации, следуя выбранному вами
процессу, то лучше пересмотрите ваш план итераций.
Показатели
Когда ваша команда встраивает резерв времени в состав итераций:
zz команда стабильно исполняет свои обязательства по итерациям;
zz члены команды редко (а скорее никогда) нуждаются в переработках;
zz внутреннее качество стабильно улучшается, упрощая и ускоряя работу.
Глава 9. Владение 297
Альтернативы и эксперименты
На первый взгляд кажется, что резерв времени связан с исполнением обязательств
и что он — важная часть этого. Но реальная инновация использования данного резерва
в первую очередь заключается в решении проблем, которые вызвали необходимость
в нем самом. Вместе с потенциалом это формирует умную петлю обратной связи,
использующую слабости команды для того, чтобы сделать ее сильнее.
Многие организации настолько обеспокоены своей продуктивностью, что давят
на свои команды, чтобы те максимально повысили значение их потенциала. Команды
усиленно повышают свой потенциал на каждую итерацию и не могут ввести никакого
резерва. Парадоксальным образом это не дает им улучшить их реальный потенциал
и осложняет для них исполнение обязательств… что, в свою очередь, приводит к уси-
лению давления, не говоря уже об атмосфере неприятной и беспорядочной суеты,
окружающей весь рабочий процесс.
Экспериментируя с резервами, не забывайте об умной петле обратной связи.
Не просто ищите способы добавить скрытые резервы; ищите способы использовать
их так, чтобы улучшить потенциал вашей команды.
СТЕНДАП-МИТИНГИ
Мы координируемся для выполнения своей
работы. Аудитория
1
Голдратт Э. Цель. Процесс непрерывного улучшения.
2
Голдратт Э. Критическая цепь.
298 Часть II. Фокус на ценность
К А Р ГО - К УЛ ЬТ
Сидячий стендап
Сейчас 10:03 утра, и ваша команда опять собралась возле комнаты
для стендап-митингов, ожидая, пока из нее выйдет предыдущая
группа.
«Напомни мне, почему нам опять нужна эта комната?» — спраши-
вает Стив. «Все остальные были заняты, — отвечает Висенте. Он
ваш Scrum-мастер. — И нам нужен проектор. Смотри, они встают».
Пять минут спустя вы все уже удобно устроились, и Висенте с по-
мощью проектора направляет изображение из трекера задач на стену. «Окей, да-
вайте начнем наш стендап, — говорит Висенте, откидываясь в кресле. — Джастин?»
Джастин отрывает взгляд от своего телефона. «А, да. Ну-у… вчера я работала над
историей № 1106. Сегодня я все еще работаю над ней. Препятствий нет».
«Отлично, — отвечает Висенте. — Адриана?»
«Все еще работаю над № 1109. Препятствий нет».
Висенте продолжает опрашивать всех по кругу, внося обновления в трекер, пока
люди отвечают в том же духе.
«Окей, это все. Всем спасибо. Помните, что нужно обновить статус ваших историй,
чтобы нам не пришлось этого делать на встрече. Увидимся завтра».
Сейчас 10:20. Направляясь обратно к своему рабочему месту, вы размышляете
о стендапе. Во всяком случае, это быстро. Но так… бесполезно. За исключением
обновления в трекере, которое делает Висенте, все остальное выглядит пустой
тратой времени. Чего не хватает?
ПРИМЕЧАНИЕ
Стендапы прерывают работу команды. В этом отношении особенно пробле-
матичны утренние стендапы; так как члены команды знают, что встреча пре-
рвет их работу, они иногда просто теряют время, ожидая ее начала. Вы можете
сгладить проблему, перенеся стендап на более позднее время дня, например
перед обедом.
1. «Прогулка по доске»
Стендап начинается с того, что члены команды просматривают одну за другой истории
на доске, начиная с той, которая ближе всех к завершению. Люди, которые работали
над каждой из историй, описывают, что изменилось и что осталось сделать, а также
рассказывают любую другую новую информацию, которую команде нужно знать.
Например: «Мы с Дженной закончили эту задачу, — говорит Бобби, указывая на
доску. — Мы с На закончили вот ту задачу, так что эта история готова к финальной
экспертной проверке. Я поговорил с Родни, и он сказал, что хочет быть ее проверяю-
щим, но у него возникло какое-то срочное дело. Он должен вернуться в офис сегодня
во второй половине дня. Мы планируем сегодня отметить эту историю зеленым, если
не будет никаких сюрпризов».
Члены команды должны просить помощи и проводить спонтанные сессии со-
вместной работы по мере необходимости в течение дня, однако прогулка по до-
ске — подходящий момент для менее срочной координации. Ниже представлены
несколько примеров.
zz Кто-то, кто хочет помощи: «Меня смущает тестирование нашего фронтенда CSS.
Кто-нибудь может рассказать мне об этом после стендапа?»
zz Кто-то, обладающий новой информацией: «Я и Люсила попробовали новую
библиотеку TaskManager, и она работала очень хорошо. Посмотрите, когда в сле-
дующий раз будете работать с параллелизмом».
zz Кто-то, кому требуется сессия совместной работы: «У нас есть несколько историй,
которым нужно задать размер. Мы можем запланировать быструю сессию игры
в планирование после обеда?»
300 Часть II. Фокус на ценность
Вначале, пока люди еще только привыкают к стендапам, вам может понадобиться
кто-то для фасилитации встречи. Лучше передавать эту роль, чтобы команда могла
разделять лидерство. Фасилитатор должен следить за тем, чтобы не доминировать
на встрече; его роль только в том, чтобы указывать на каждую историю и побуждать
команду высказываться.
2. Фокус на завершении
После прогулки по доске сфокусируйте внимание команды на том, что им необходи-
мо для завершения работы, включая препятствия, которые не устранены. Команды,
использующие итерации, должны воспользоваться возможностью проверить свои
обязательства по итерациям, сказав примерно такие слова: «У нас осталось два
дня, и мы прошли итерацию на 60 %. Похоже, мы выполнили больше 60 % задач, но
только одна из наших историй отмечена как сделанная, поэтому сегодня мы должны
сконцентрироваться на закрытии историй».
3. Выбирайте задачи
Наконец, каждый решает, над чем будет работать дальше. Это разговор, а не одно-
стороннее решение: «С учетом того, что сказала На о завершении историй, похоже,
что эта задача должна иметь высокий приоритет в нашем списке. Кто-нибудь хочет
поработать над этим со мной?» (На выступает добровольцем и берет карточку с до-
ски.) «Кроме того, сегодня во второй половине дня я договорюсь с Родни насчет
экспертной проверки той, другой истории».
Таким же образом, если кто-то выбирает историю, по которой у вас есть информа-
ция, не забудьте упомянуть ее: «Когда начнете работать над этой задачей, поговорите
со мной или Сеймуром. Мы внесли несколько изменений в нашу обертку над Fetch1,
о которых вам нужно знать».
1
Название интерфейса. — Примеч. науч. ред.
Глава 9. Владение 301
Будьте краткими
Цель стендап-митингов — вкратце скоординировать всю команду. Они не предна-
значены для полного описания всего, что произошло. Главное достоинство стенда-
пов — краткость. Вот почему команды, работающие в офисе, проводят встречи стоя:
их уставшие ноги напомнят им, что встреча должна быть короткой.
Каждую историю обычно можно описать, используя всего несколько предложе-
ний. От 30 до 60 секунд вполне должно хватить. Вот несколько дополнительных
примеров.
zz Программист: «Для этой истории Дина и я закончили эту задачу (указывает на
доску). Мы столкнулись с проблемой с тестами, поэтому сделали рефакторинг
абстракции сервиса. Это также упростит вон ту задачу (показывает). Дайте ко-
му-нибудь из нас знать, если захотите, чтобы мы обсудили с вами изменения».
zz Продакт-менеджер: «Я только что вернулся с торговой выставки, где получил
отличные отзывы о UI и направлении развития нашего продукта. Это будет оз-
начать некоторые изменения в визуальном плане. Я поработаю над этим сегодня,
и любой, кто хочет знать больше, может присоединиться ко мне».
zz Эксперт в предметной области: «Синтия спрашивала меня вчера о финансовых
правилах для этой истории. После этого я обсудил это с Татум, и оказалось, что
там несколько больше работы, чем я думал. Я добавил эту задачу (показывает),
чтобы обновить примеры, и хотел бы поработать с программистом или тестиров-
щиком над этим, чтобы убедиться, что мы покрываем все базы».
Обычно стендап-митинги должны зани-
мать всего около пяти минут, максимум де- Стендап-митинги должны
сять. Если они постоянно занимают больше занимать всего около пяти минут,
десяти минут, что-то не так. Несколько общих максимум десять.
причин медленных стендапов таковы:
zz вместо карточек и доски или их виртуального эквивалента используются инстру-
менты трекинга задач;
zz доска задач обновляется во время стендапа, а не в течение всего дня;
zz разговоры ведутся во время стендапа, а не в течение всего дня;
zz подробные дискуссии ведутся во время стендапа, вместо того чтобы выносить
их за рамки встречи;
302 Часть II. Фокус на ценность
Вопросы
Могут ли люди, не являющиеся членами команды, участвовать в стендапах?
Да, но помните, что стендап организует команда и он проводится на благо коман-
ды. Если посторонние люди отвлекают от встречи или членам команды некомфортно
говорить в их присутствии, то посторонние
должны перестать участвовать. Члены коман- См. также
ды, имеющие навыки дипломатии, вероятно,
смогут им сообщить об этом наилучшим обра- Демо для стейкхолдеров (глава 10)
зом. Вы можете использовать демо для стейк- Дорожные карты (глава 10)
холдеров и дорожные карты, чтобы держать
этих людей в курсе происходящего.
Когда есть множество команд, иногда бывает полезно командам, плотно работаю-
щим друг с другом, отправлять своих людей на стендап-митинги друг к другу. В этом
случае решите совместно, как позволить людям посещать встречи и сотрудничать,
никому не мешая.
Что, если кто-то опоздал на встречу?
Начинайте без них. Стендапы длятся всего несколько минут, так что к моменту,
когда опоздавшие придут, вы уже можете закончить. Вы можете попросить кого-либо
заменить их, если необходимо. Если начинать всегда вовремя, это может способство-
вать установлению культуры пунктуальности.
Нам все еще нужны стендап-митинги, если мы используем групповое программи-
рование?
Команды, которые используют групповое
программирование, обычно постоянно коор- См. также
динируются, так что технически стендапы им
не нужны. Но все же полезно каждый день Групповое программирование
находить время, чтобы обсудить прогресс (глава 12)
и подумать о следующих шагах. У команд,
использующих групповое программирование, это может происходить естественным
образом. Если нет, то проведение запланированного стендапа должно помочь.
Предварительные требования
Не позволяйте ежедневным стендапам задушить общение. Некоторые члены команды
в какой-то момент обнаруживают, что ждут стендапа, вместо того чтобы разговаривать
с кем-то, кто им нужен. Если вы видите, что такое происходит, временная отмена
стендапов может на самом деле помочь улучшить общение.
Знайте, что есть лидеры, которые любят доминировать во время стенда-
пов. Будучи проверяющим, Джонатан Кларк метко выразился, что идеальный
Глава 9. Владение 303
Показатели
Когда вы хорошо проводите стендап-митинги:
zz команда координирует свою работу и демонстрирует устойчивый прогресс в вы-
полнении плана;
zz команда знает, когда задача или история застопорилась, и принимает меры, чтобы
ее разблокировать;
zz члены команды знают, над чем работают остальные и как это влияет на их работу.
Альтернативы и эксперименты
Координация, а не статус — основная идея стендап-митингов. Команды — новички
в Agile обычно испытывают с этим трудности; стендап кажется им более короткой
и частой версией статус-митинга, но такие представления упускают суть.
Во время стендапа избегайте излишней формальности. Люди часто эксперимен-
тируют, добавляя структуру (шаблоны, списки вопросов), но она может снижать
уровень взаимодействия, а не повышать его. Вместо этого ищите варианты повысить
способность команды нести коллективную ответственность за свою работу.
Одна команда, с которой я работал, стала настолько эффективной в технике
«прогулки по доске», что члены команды стали проводить очень короткие стенда-
пы несколько раз в день. Вместо того чтобы назначать время для встреч, участники
собирались сразу же, как только заканчивали свои задачи. Уже через 30–60 секунд
они договаривались о том, над чем работать дальше, и разбирали задачи с доски.
Тонкие сигналы
Суть информативного рабочего пространства —
информация. Пространство постоянно транслирует Информативное рабочее
информацию команде. Этот процесс принимает пространство постоянно
форму больших наглядных диаграмм, описанных транслирует информацию
далее, но может принимать форму тонких сигналов, команде.
что позволяет членам команды поддерживать их
осведомленность о ситуации.
Один из источников осведомленности о ситуации — видеть, что делают люди.
В физическом командном помещении, меняя визуальный план, человек, вероят-
но, думает о предстоящей работе. Если кто-то стоит возле доски задач, то, возмож-
но, может обсудить вопрос, над чем работать дальше. В середине итерации, если
половина карточек на доске не сделана, команда движется медленнее, чем ожи
далось.
Ощущение комнаты — еще один сигнал. Здоровая
команда энергична. В воздухе висит гул активности. См. также
Люди общаются, работают вместе, шутят время
от времени. Команда не спешит и не суетится, но Энергичная работа (глава 7)
определенно продуктивна. Когда человеку или паре
нужна помощь, другие это замечают, предлагают помощь, потом возвращаются
к своим задачам. Когда кто-то завершает задачу, все на минутку прерываются, чтобы
коротко отпраздновать это.
В нездоровой команде тихая и напряженная атмосфера. Члены команды не го-
ворят много или вовсе молчат. Есть ощущение чего-то серого и мрачного. Люди
живут по часам, отсчитывая время прихода и ухода или, еще хуже, наблюдая, кто
первый решится уйти.
В удаленных командах эти сигналы не видны.
Вместо этого приложите усилия, чтобы сообщать См. также
о текущем статусе и настроении. Установите рабочие
соглашения о том, как делиться информацией, напри- Согласование (глава 7)
мер, оставлять примечания в групповом чате, и пред-
ложите способы приветствовать друг друга.
Помимо собственно информации, рабочее пространство предоставляет людям
и способы общения. Для команд, работающих в офисе, это означает множество
Глава 9. Владение 305
Диаграммы улучшений
Один из типов большой наглядной диа-
граммы измеряет определенные параметры, См. также
которые команда хочет улучшить. Часто эти
Ретроспективы (глава 11)
параметры возникают во время ретроспек-
тив. В отличие от доски для планирования
или командного календаря, которые постоянно присутствуют в комнате, диаграммы
улучшений остаются там только на несколько недель.
Создавайте диаграммы улучшений как результат общего решения команды,
и пусть она за них отвечает. Когда вы согласитесь создать диаграмму, договоритесь
поддерживать ее в актуальном состоянии. Для некоторых диаграмм это означает,
что все уделяют несколько секунд на то, чтобы сделать отметку на доске, когда
меняется статус. Другие диаграммы подразумевают сбор некоторой информации
в конце дня. Для таких коллективно выберите кого-нибудь, кто будет отвечать за
обновление диаграммы.
Диаграммы улучшений настолько же разнообразны, как и проблемы, которые ис-
пытывают команды. Принцип, стоящий за всеми ними, один и тот же: они взывают
к нашему врожденному желанию совершенствоваться. Если вы демонстрируете про-
гресс в достижении общей цели, то люди обычно будут стараться улучшать свой статус.
Подумайте над проблемами, с которыми сталкиваетесь, и над тем, какой тип
диаграммы, если он есть, может помочь. В качестве примера команды Agile успешно
использовали диаграммы, чтобы улучшить:
zz использование парного программирования, отслеживая процентное соотношение
времени, проведенного в парном программировании, и сравнивая его с процент-
ным соотношением времени, ушедшего на работу в одиночку;
zz переключение пар, отслеживая, сколько возможных комбинаций пар фактически
работало парами во время каждой итерации (рис. 9.4, а);
zz производительность сборки, отслеживая количество тестов, выполненных за
секунду (см. рис. 9.4, б);
zz отзывчивость поддержки, отслеживая возраст самого старого запроса (более ран-
няя диаграмма, которая отслеживала количество нерешенных запросов, привела
к тому, что сложные запросы игнорировались);
zz ненужные перерывы, отслеживая количество часов, потраченное на работу не по
истории в каждой итерации.
Постарайтесь не впадать в крайности. Если вы публикуете слишком много диа-
грамм улучшений, то они потеряют свою эффективность. Я стараюсь удерживать
в пределах двух или трех за раз, не включая постоянные диаграммы, такие как доска
задач.
Но это не значит, что вашей единственной наглядностью должны быть несколько
диаграмм. Приветствуются и памятные для команды предметы, игрушки и элементы
текущей работы. Просто сделайте так, чтобы важные диаграммы выделялись.
Глава 9. Владение 307
Игры
Хотя слишком большое количество диаграмм улучшений может снизить их влия-
ние, более серьезная проблема возникает, когда команда чрезмерно заинтересована
в увеличении цифр в диаграмме. Люди часто начинают воспринимать процесс как
азартную игру. Игра начинается, когда люди фокусируются на цифрах за счет обще-
го процесса.
Обычный пример, который я встречаю, — программисты слишком фокусиру-
ются на улучшении количества имеющихся у них тестов или объема покрытия
кода вместо совершенствования качества своего подхода к тестированию. Они
выполняют тривиальные тесты, которые не несут никакой ценности, или сложны
для выполнения, или выполняются медленно. Иногда люди даже не осознают, что
делают это.
Чтобы уменьшить эту проблему, используйте диаграммы улучшений осторожно.
Обсуждайте новые диаграммы всей командой. Ясно обозначайте общие улучшения,
которые хотите увидеть. Каждую неделю проверяйте, работают ли диаграммы, и сни-
майте их в течение месяца. К этому времени диаграмма уже или выполнит свою задачу,
или окажется не в состоянии чем-то помочь.
Кроме того, никогда не используйте
диаграммы из вашего рабочего простран- Никогда не используйте диаграммы
ства для оценки производительности. Даже из вашего рабочего пространства
для оценки производительности.
не обсуждайте их за пределами команды.
Люди, которые чувствуют, что о них судят
по их производительности на диаграмме, с гораздо большей вероятностью вступят
в игру. В разделе «Менеджмент» главы 10 можно найти информацию о том, что
делать вместо этого.
308 Часть II. Фокус на ценность
Вопросы
Нам необходимо информировать о статусе людей, которые не могут или не хотят
приходить в наше рабочее пространство регулярно. Как нам это делать, не применяя
компьютеризированные диаграммы?
Первое и главное — информативное рабочее
пространство предназначено для команды. Что- См. также
бы делиться информацией о статусе с людьми,
Демо для стейкхолдеров
не входящими в команду, используйте демо для
(глава 10)
стейкхолдеров и дорожные карты.
Наши диаграммы постоянно устаревают. Как Дорожные карты (глава 10)
вдохновить членов команды на их обновление?
Первый вопрос, который нужно задать: «Действительно ли команда согласилась
с этой диаграммой?» Информативное рабочее пространство должно приносить поль-
зу команде, так что если члены команды не поддерживают диаграмму в актуальном
состоянии, то, возможно, считают, что она не имеет смысла. Может быть, члены
команды в пассивно-агрессивной форме игнорируют диаграмму, вместо того чтобы
просто сказать вам, что она им не нужна.
Могу сказать из собственного опыта: возможно, вы слишком сильно настаиваете
на диаграммах. Снижения моей вовлеченности в диаграммы часто бывает достаточно,
чтобы заинтересовать и привлечь команду. Иногда это означает, что нужно смириться
с неидеальными или небрежными картинками от руки, но это себя оправдывает.
Если ничего не помогает, то обсудите проблему во время ретроспективы или стендап-
митинга. Поделитесь своим разочарованием и попросите у команды помощи в решении
проблемы. Будьте готовы отказаться от части диаграмм, если команде они не нужны.
Предварительные требования
Если у вашей команды нет командного помещения,
физического или виртуального, то вы не сможете См. также
создать информативное рабочее пространство.
Такое пространство легче создать в физическом Командная комната (глава 7)
рабочем помещении. Просто повесьте диаграммы,
которые вам нужны. Если у вас виртуальное рабочее пространство, то вам понадобится
приложить дополнительные усилия, чтобы сделать информацию наглядной и создать
атмосферу ситуационной осведомленности.
Показатели
Когда у вашей команды есть информативное рабочее пространство:
zz вы своевременно узнаёте обо всех проблемах, с которыми сталкивается команда;
zz вы точно знаете, каков ваш прогресс по вашему текущему плану и сколько еще
предстоит сделать;
zz вы хорошо знаете, хорошо продвигается команда или столкнулась с трудностями;
zz вы знаете, насколько хорошо команда решает проблемы.
Глава 9. Владение 309
Альтернативы и эксперименты
Если у вас нет командного помещения, но ваша команда работает в смежных офисах
или кабинках с перегородками, то вы можете получить некоторые преимущества
информативного рабочего пространства, размещая информацию в холле или общих
помещениях.
В этом эксперименте вас ничто не ограничивает. Ключ к данной практике — ме-
тафора кабины пилотов: иметь постоянно на виду всю необходимую информацию,
чтобы автоматически замечать изменения и подсознательно понимать, когда что-то
не по плану. Имейте это в виду, когда будете экспериментировать с визуализациями
и плакатами. Вы можете начать экспериментировать сразу.
ПРИМЕРЫ ЗАКАЗЧИКА
Мы правильно реализуем сложные детали.
Некоторые программы довольно простые: Аудитория
просто еще один UI поверх еще одной базы
данных. Но часто наибольшую ценность пред- Заказчики, вся команда
ставляет ПО, требующее особых экспертных
знаний.
Эта экспертность, или знание предметной
области, наполнена деталями, в которых трудно См. также
разобраться и которые легко понять неправиль-
но. Для обсуждения этих деталей используют Единый язык (глава 12)
примеры заказчика: конкретные примеры, иллю- Вся команда (глава 7)
стрирующие правила предметной области. При- Вовлечение реального заказчи-
меры заказчика тесно связаны с единым языком, ка (глава 8)
который представляет собой способ объединить
язык, используемый программистами и экспер-
тами в предметной области, и сам код.
Для создания примеров заказчика вам понадобятся люди, обладающие эксперт-
ными знаниями в предметной области. Идеально, если они — часть команды. Если
нет, то вам нужно их найти.
В вашу команду могут входить люди, которые выработали «мирское» понимание
предметной области. В эту категорию часто входят программисты, тестировщики
и бизнес-аналитики. Они могут сами разрабатывать примеры заказчика. Но даже
310 Часть II. Фокус на ценность
в таком случае хорошей идеей будет проверить эти примеры вместе с реальными экс-
пертами в данной области, поскольку могут встретиться каверзные детали, которые
неспециалист поймет неверно.
Чтобы создать и использовать такие примеры, следуйте процессу Описать, Про-
демонстрировать, Разработать.
Описать
В процессе планирования задач посмотрите
на истории и решите, нет ли в них деталей, См. также
которые разработчики могли понять не-
правильно. Добавьте задачи по созданию Планирование задач (глава 9)
примеров таких деталей. Вам не нужны
примеры на все — только на каверзные. Примеры заказчика нужны для общения,
а не для подтверждения того, что ПО работает.
Например, если одна из ваших историй — «разрешить удаление счета», то вам
не нужен пример удаления счета. Разработчики уже понимают, что значит удалить
что-либо. Однако вам могут понадобиться примеры, показывающие, когда можно
удалить счет, особенно если есть сложные правила, обеспечивающие удаление счета
правильным образом.
Если вы не знаете, что именно разработчики могли понять неправильно, спросите
их! Но не совершайте ошибки, приводя слишком много примеров, по крайней мере
поначалу. Когда эксперты в предметной области и разработчики впервые собираются
вместе, чтобы создать примеры, обе группы часто бывают удивлены тем, насколько
велико неверное понимание.
Когда приходит время работать над примерами, соберите команду вокруг белой
доски или сделайте общий документ, если команда работает удаленно. Участвовать
может вся команда. Как минимум пригласите эксперта в предметной области, всех
программистов и тестировщиков. Они все должны понимать детали, чтобы кол-
лективно владеть продуктом (см. врезку «Коллективное владение» ранее в данной
главе).
Эксперты в предметной области начинают с краткого описания истории и соот-
ветствующих правил. Будьте лаконичны: это только краткий обзор. Сберегите детали
для примеров. Например, дискуссия об удалении счетов может пойти следующим
образом:
Эксперт: Одна из наших историй — добавление поддержки удаления счетов.
Вдобавок к макетам UI, которые мы вам дали, мы думаем, что будет хорошо до-
бавить несколько примеров заказчика. Удаление счетов — не настолько простая
операция, как кажется, поскольку мы должны вести аудиторский учет.
Этот вопрос связан с определенным набором правил. Обычно можно без про-
блем удалять счета, которые не были отправлены заказчикам, чтобы люди имели
возможность исправлять ошибки. Но как только счет был отправлен заказчику,
он может быть удален только менеджером. И даже тогда мы должны сохранять
копию для аудита.
Глава 9. Владение 311
Продемонстрировать
После того как эксперт в предметной об-
ласти сделал краткий обзор, постарайтесь Сделайте правило конкретным,
удержаться от искушения заставить его попросив привести пример.
продолжать описание правила. Вместо это-
го сделайте правило конкретным, попросив привести пример. Буквальный вопрос
«Можете привести пример?» поможет сразу перейти к делу.
Участники также могут начать, попросив привести пример, но предоставьте роль
лидера эксперту в предметной области. Маленькая хитрость — можно сделать пред-
намеренную ошибку и дать эксперту возможность вас поправить1.
Таблицы часто являются самым естественным способом предоставить примеры,
но вам не нужно беспокоиться о форматировании. Просто сформулируйте примеры
на доске или в общем документе. Дискуссия может быть продолжена следующим
образом:
Программист: То есть если счет не был отправлен, специалист по работе с за-
казчиком может удалить его, а если был отправлен, то не может? (Берет маркер
и пишет на доске.)
Эксперт: Верно.
Программист (намеренно понимая неверно): Но CSR может.
CSR Нет Да
CSR Да Да
1
Я научился этой хитрости у Уорда Каннингема. Один из ее вариантов был позже популяризиро-
ван Стивеном Макгиди как закон Каннингема: «Лучший способ найти ответ в Интернете — это
не задать вопрос, а опубликовать неверный ответ».
312 Часть II. Фокус на ценность
«Отправлен»
По электронной почте
Распечатан
Экспортирован в PDF
Экспортирован в URL
Разработать
Когда обсуждение закончено, запишите результаты для использования в дальнейшем.
Обычно достаточно фото и скриншота белой доски.
Примеры заказчика часто представляют наи-
более важные элементы логики вашего программ- См. также
ного приложения. Обязательно задокументируйте
их. Я предпочитаю разработать автоматические Разработка через тестирование
(глава 13)
тесты. Однако вместо того, чтобы слепо копиро-
вать каждый пример в соответствующий тест,
я использую примеры в качестве источника вдохновения для создания более точ-
ных и тщательно продуманных тестов, которые могут служить документацией для
других программистов. Для этого я распечатываю копию примеров и использую
разработку через тестирование, чтобы инкрементно создавать тесты и код. Когда
я пишу каждый тест и соответствующий ему код, то вычеркиваю примеры, которые
покрывает тест.
Проще всего, если у вас есть единый язык и модель предметной области. Напри
мер, в вашу модель могут входить класс Invoice и метод canDelete(). В этом случае
у нее могут быть такие тесты, как «позволять любому удалять счета, которые не были
отправлены» и «позволять только менеджерам удалять счета, которые были от-
правлены».
Пока разработчики будут работать над кодом, вероятно, выявятся некоторые
пограничные случаи, которые не обсуждались в первоначальной дискуссии. В этом
случае нормально вернуться к доске. Точно так же нормально задать вопрос, полу-
чить ответ и закодировать его. При любом варианте не забудьте обновить тесты
и документацию.
314 Часть II. Фокус на ценность
Вопросы
Мы должны создавать примеры до того, как
начнем разработку? См. также
В этом не должно быть необходимости.
Игра в планирование (глава 8)
Создание примеров обычно может быть пер-
вой задачей в вашей разработке. Если вам Инкрементные требования (глава 8)
нужно исследовать несколько примеров во
время игры в планирование, чтобы измерить историю, то вы можете создать примеры,
но в целом этого делать не нужно. Помните, что требования, в том числе примеры
заказчика, должны разрабатываться поэтапно вместе с остальным вашим ПО.
Предварительные требования
Многие истории настолько просты, что им не требуются примеры заказчика. Не ста-
райтесь насаждать их там, где в них нет необходимости.
Когда вам нужны примеры заказчика, вам также нужны и экспертные знания
в предметной области. Если в вашей команде нет экспертов, то вам нужно приложить
усилия, чтобы найти их и привлечь к работе.
Показатели
Когда ваша команда хорошо применяет примеры заказчика:
zz в вашем ПО немного багов в логике предметной области или они вовсе отсутствуют;
zz ваша команда обсуждает правила предметной области в конкретных, однознач-
ных терминах;
zz ваша команда часто обнаруживает и учитывает особые правила, которые никто
не принимал во внимание.
Альтернативы и эксперименты
Некоторые команды любят использовать средства автоматизации тестирования
на естественном языке, такие как Cucumber, для превращения примеров заказчика
в автоматизированные тесты. Когда-то я был одним из тех, кто это делал, — Fit Уорда
Каннингема был первым из таких инструментов в сообществе Agile, и я принимал
в нем активное участие.
Но со временем я понял, что ценность примеров была в обсуждении у доски,
а не в автоматизации. В теории заказчики должны помогать в написании Fit-тестов
и использовать результаты Fit, чтобы быть уверенными в прогрессе команды.
На практике это случалось редко и особой пользы не приносило. Обычная TDD
была более простым способом автоматизации и работала так же хорошо. То же самое
можно сказать и об инструментах наподобие Cucumber.
Cucumber вышел из сообщества разработок на основе поведения (Behavior-Driven
Development, BDD), основанного Дэниелом Терхорст-Нортом, который всегда
был решительным сторонником взаимодействия с заказчиком. Хотя я не думаю,
Глава 9. Владение 315
К А Р ГО - К УЛ ЬТ
Почти сделано
— Привет, Валентина! — Ширли просовывает голову в кабинет
Валентины. — Ты уже закончила ту новую функциональность?
Валентина кивает.
— Подожди секунду, — говорит она, продолжая что-то набирать. По-
ток щелчков клавиш нарастает в крещендо и наконец эффектно за-
канчивается. — Сделано! — Валентина триумфально поворачивается,
чтобы взглянуть на Ширли. — Мне тоже потребовалось всего полдня.
— Впечатляюще, — говорит Ширли. — Мы думали, это должно занять целый день,
а то и два. Я могу уже сейчас посмотреть на нее?
— Ну, не совсем, — говорит Валентина. — Я пока еще не интегрировала новый код.
— Окей, — говорит Ширли. — Но как только ты это сделаешь, я же смогу на нее
посмотреть, да? Мне не терпится показать ее нашим новым клиентам. Они нас
выбрали специально из-за этой функциональности. Я собираюсь развернуть новую
сборку на их испытательном стенде, чтобы они могли поэкспериментировать с ней.
316 Часть II. Фокус на ценность
1
Спасибо Биллу Уэйку за этот совет.
318 Часть II. Фокус на ценность
Находить время
Ваша команда должна завершать 4–10 историй
каждую неделю. То, что вам нужно доводить до Секрет состояния «Сделано
состояния «Сделано Сделано» так много исто- Сделано» — в создании
маленьких историй.
рий, может показаться невозможно большим
объемом работы. Хитрость частично состоит
в том, чтобы работать поэтапно, как только что описывалось, а не по фазам. Однако
настоящий секрет — в создании маленьких историй.
Множество команд — новичков в Agile создают истории, слишком большие, чтобы
стать «сделанными сделанными». Они завершают кодирование, но у них не хватает
времени, чтобы закончить все полностью. UI немного не в порядке, тесты не завер-
шены, и то и дело появляются баги.
Помните, вы — хозяева вашего расписания. Вы решаете, на сколько историй под-
писаться и какова их величина. Если ваши истории слишком большие, то уменьши-
те их! В подразделе «Разделение и объединение историй» главы 8 описывается, как
это сделать.
Создание слишком больших историй — есте-
ственная ошибка, но некоторые команды усугу- См. также
бляют проблему, думая: «Ну… мы действительно
закончили историю, за исключением одного Потенциал (глава 9)
небольшого бага». Они засчитывают ее в свой
потенциал, что только усугубляет проблему.
Истории, которые не «сделаны сделаны», не засчитываются в ваш потенциал.
Даже если в истории лишь несколько малозначимых багов в UI или вы закончили
все, кроме нескольких автоматизированных тестов, она засчитывается как ноль при
подсчете вашего потенциала. Это снижает ваш потенциал, давая вам больше времени,
чтобы вы смогли закончить все в следующий раз.
Вы можете посчитать, что это снижает ваш потенциал настолько, что вы можете
завершать всего одну или две истории в неделю. Это значит, что ваши истории были
слишком большими для начала. Разделите текущие истории и работайте над тем,
чтобы делать будущие истории меньшими по размеру.
Команды, использующие непрерывный поток, а не итерации, не отслеживают
потенциал, но к ним применима та же идея. Вы должны начинать и заканчивать
4–10 историй за неделю, и каждая должна быть «сделана сделана». Если это не так,
то уменьшите истории.
Организационные ограничения
У вашей команды может не быть возможности делать релиз историй самостоятель-
но1. Идеал Agile — кросс-функциональные команды, обладающие всеми навыками
и полномочиями, необходимыми для выполнения своей работы, как описано в главе 4,
однако это не всегда возможно.
1
Спасибо Басу Водде, Томасу Оуэнсу и Кену Пью за их вклад в этот подраздел.
320 Часть II. Фокус на ценность
Вопросы
Что, если история не «сделана сделана» в конце итерации?
Или попытайтесь еще раз позже, или создайте новую историю для того, что оста-
лось (см. подраздел «Незавершенные истории» ранее в данной главе).
Почему в вашем списке «Протестировано» идет раньше, чем «Код написан» и «Ди-
зайн готов»? Разве мы не должны сначала подготовить дизайн, затем написать код
и только потом тестировать?
Список «Сделано Сделано» — не перечень шагов или фаз, которые необходимо
выполнять последовательно; он служит для финальной проверки, помогающей убе-
диться, что вы ничего не забыли. Agile работает лучше всего, когда вы выполняете
фазы разработки инкрементно и одновременно, а не по одной за раз. В части III
описывается, как это работает.
Почему в вашем списке нет ручного тестирования?
Ручное тестирование заканчивается фазой «Протестировать и исправить» в конце
разработки, что осложняет надежное и гарантированное завершение работы. В части III
описывается, как заменить эту фазу инкрементным автоматизированным тестированием.
Помните, что мой список — это лишь пример. Если ваша команда использует
ручное тестирование, имеет дополнительные эксплуатационные требования или
должна делать что-то еще, чтобы завершить историю, то добавьте это в ваш список.
Глава 9. Владение 321
Предварительные требования
Приведение историй в состояние «Сделано
Сделано» требует участия всей команды — та- См. также
кой, в которую входят как минимум заказчики,
а также, возможно, тестировщики, специалисты Вся команда (глава 7)
по эксплуатации, технические писатели и т. д. Командная комната (глава 7)
У такой команды должна быть общая рабочая
комната, физическая или виртуальная. Иначе Разработка через тестирование
есть вероятность, что команда будет слишком (глава 13)
часто задерживать выполнение задач из-за их Инкрементный дизайн (глава 14)
передачи из рук в руки, что препятствует бы-
строму завершению историй.
Кроме того, вам, вероятно, понадобятся разработка через тестирование и эволю-
ционный дизайн, чтобы тестировать, создавать код и дизайн для каждой истории
в такие короткие сроки.
Показатели
Когда ваши истории в состоянии «Сделано Сделано»:
zz вы не сталкиваетесь с неожиданно возникающими объемами работы;
zz команды, использующие итерации, распределяют процессы завершения и окон-
чательной доводки работы по ходу всей итерации;
zz заказчики в команде и тестировщики имеют равномерную рабочую загрузку;
zz приемка работы заказчиком занимает всего несколько минут.
Альтернативы и эксперименты
Эта практика — краеугольный камень планирования в Agile. Если вы не достигли
статуса «Сделано Сделано» после каждой истории или итерации, то ваш потенциал
и прогнозирование будут ненадежными. Вы не сможете делать релизы по своему
усмотрению. Как следствие, ваши планы релизов будут срываться, что помешает
вам принимать и выполнять обязательства, а это, в свою очередь, будет подрывать
доверие стейкхолдеров. Такая ситуация, скорее всего, будет приводить к стрессу
и давлению на команду, снижать моральный дух команды и ее активность.
Альтернатива статусу «Сделано Сделано» — заполнить конец вашего расписания
косметической работой. В итоге вы получите неопределенный объем работы по ис-
правлению багов, доработке UI, миграции данных и т. д. Многие команды работают
таким образом, однако это вредит доверию и вашей способности поставлять продукт.
Я не рекомендую так делать.
ГЛАВА 10
Ответственность
Если Agile-команды сами управляют своей работой и своими планами, то как их ор-
ганизации узнают, что команды все делают правильно? Как они узнают, что команда
выполняет свою работу наилучшим из возможных способов с учетом имеющихся
у нее ресурсов, информации и людей?
Организации могут хотеть и даже стремиться к тому, чтобы команды следовали
подходу Agile, но это не значит, что у команд есть карт-бланш делать все, что они
захотят. Они все же подотчетны своей организации. Они должны демонстрировать,
что тратят время и деньги организации соответствующим образом.
В этой главе приводятся практики, которые помогут обеспечить подотчетность.
zz Практика «Доверие стейкхолдеров» позволяет команде эффективно работать со
стейкхолдерами.
zz С помощью практики «Демо для стейкхолдеров» вы сможете давать обратную
связь о том, как продвигается ваша команда.
zz Практика «Прогнозирование» предсказывает даты релизов ПО.
zz Используя практику «Дорожные карты», вы сможете рассказать о прогрессе
и планах команды.
zz Практика «Менеджмент» помогает командам совершенствоваться.
Источники ответственности
Подотчетность скорее подразумевается, чем явно указывается в литературе об
Agile. Во времена экстремального программирования в сообществе обсуждали
«Билль о правах заказчика», раннюю версию которого можно найти в предисло-
вии к первой книге об XP:
Заказчикам и руководителям XP обещает, что они получат максимум поль-
зы от каждой недели программирования. Каждые несколько недель они
смогут видеть конкретный прогресс в достижении важных для них целей.
У них будет возможность изменить направление проекта в середине раз-
работки, обойдясь без чрезмерных затрат [Beck2000a].
Extreme Programming Explained, первое издание
Вот точное заявление об ответственности: «Мы дадим вам максимально возмож-
ную ценность». Но XP не слишком много сказало о том, как продемонстрировать
Глава 10. Ответственность 323
ДОВЕРИЕ СТЕЙКХОЛДЕРОВ
Мы работаем со стейкхолдерами эффективно
Аудитория
и без опасений.
Продакт-менеджеры,
Я знаю человека, который работал в компании вся команда
с двумя командами разработки. Одна использовала
подход Agile, выполняла свои обязательства и ре-
гулярно поставляла ПО. Вторая все время боролась с трудностями: отставала от
графика и не могла показать никакого работающего ПО. Однако когда в компании
начались сокращения, расстались с Agile-командой, а не с другой!
Почему? Глядя на эту борющуюся с трудностями команду, руководители видели
стены, обвешанные формальными диаграммами, и программистов, просиживающих
долгие часы за работой. Когда же руководители смотрели на Agile-команду, они ви-
дели, что люди общаются, смеются и уходят домой в пять вечера, не сделав ничего,
кроме черновых набросков и диаграмм на доске.
Нравится это вам или нет, ваша команда живет не в вакууме. Agile поначалу
может казаться странным и отличающимся от привычного. «Они действительно
324 Часть II. Фокус на ценность
Проявите эмпатию
Команды разработчиков часто имеют напряженные отношения с ключевыми стейк-
холдерами — представителями бизнеса. С точки зрения разработчиков, это принимает
форму нечестных требований и бюрократии, особенно в виде навязывания сроков
и давления на график.
Вы можете удивиться, узнав, что для многих из этих стейкхолдеров разработчи-
ки — это люди, у которых все козыри. Стейкхолдеры находятся в довольно пугающей
ситуации, особенно в компаниях, не связанных с бизнесом продажи ПО. Задумайтесь
на минуту над тем, как это может выглядеть:
zz карьера спонсоров, продакт-менеджеров, стейкхолдеров часто находится на кону.
Карьера разработчиков — часто нет;
zz разработчики часто зарабатывают больше, чем стейкхолдеры, очевидно, не слиш-
ком утруждаясь и не соблюдая тех правил, которых стейкхолдеры должны при-
держиваться;
zz разработчики обычно приходят на работу значительно позже, чем представители
стейкхолдеров. Они и уходят позже, но стейкхолдеры этого не видят;
zz для посторонних наблюдателей разработчики часто не выглядят заинтересован-
ными в успехе. Кажется, что их больше привлекают изучение новых технологий,
подготовка своего следующего карьерного скачка, поиск баланса работы и отдыха
и офисные «плюшки», такие как игра в пинг-понг и бесплатные закуски;
zz опытные представители стейкхолдеров имеют множество примеров из своей
истории, когда разработчикам не удавалось поставить то, что было нужно, и тогда,
когда это было нужно;
zz стейкхолдеры привыкли, что разработчики отвечают на вопросы о прогрессе
в работе, оценках и обязательствах, используя все способы: от высокомерия до
многозначительного, но бесполезного технического жаргона;
zz многие стейкхолдеры видят, что крупные технические компании хорошо постав-
ляют ПО, что редко удается их компании, и они не знают почему.
Я не говорю, что разработчики плохие или что
это впечатление обязательно верно. Я предлагаю
Относится ли ваша команда
вам подумать, что означает успех для стейкхолде- к успеху ее стейкхолдеров
ров вашего проекта и относится ли ваша команда, с уважением, которого тот
с точки зрения внешнего наблюдателя, к успеху заслуживает?
ее стейкхолдеров с уважением, которого тот за-
служивает.
Выполняйте обязательства
Если ваши стейкхолдеры уже работали с командами разработки ПО, то, вероятно,
неоднократно терпели неудобства их-за сорванных графиков, неисправленных
дефектов и зря потраченных денег. Но в то же время, скорее всего, у них самих нет
навыков разработки ПО. Это ставит их в неудобное положение, когда они вынуждены
326 Часть II. Фокус на ценность
Управляйте проблемами
Я сказал: «Это все, что вам нужно»? Я сглупил. Все не так просто.
Во-первых, вам нужно создать хороший план и выполнять его (см. главы 8 и 9).
Во-вторых, как сказал поэт: «Лучшие планы мышей и людей / Часто идут вкривь
и вкось...»1.
1
«К полевой мыши», стихотворение известного шотландского поэта Роберта Бёрнса. Поэма на-
чинается так: «Маленький, хитрый, трусливый, пугливый зверь, / О, какая паника в твоей груди!»
Это напоминает мне мои ощущения, когда меня попросили интегрировать ветку, содержавшую
функциональность годичной давности.
Глава 10. Ответственность 327
Будьте честны
В своем энтузиазме демонстрировать прогресс будьте осторожны и не переступайте
черту. Пограничное поведение включает в себя замалчивание известных дефектов
в демо для стейкхолдеров, приписывание себе историй, которые еще не завершены
на 100 %, и продление срока итерации на несколько дней, чтобы завершить все, что
содержится в плане итерации.
Сокрытие правды подобным образом создает у стейкхолдеров впечатление, что вы
сделали больше, чем на самом деле. Они будут ожидать, что вы завершите остальные
истории так же быстро, хотя фактически вы еще не закончили предыдущие. В какой-
то момент вам придется все доделать, и получившаяся в результате задержка вызовет
непонимание, разочарование и даже гнев.
Даже кристально честные команды могут столкнуться с такой проблемой. Стре-
мясь хорошо выглядеть, команды иногда берутся за большее количество историй,
чем в состоянии хорошо реализовать. Они выполняют работу, но используют корот-
кие пути, уделяя дизайну и рефакторингу недостаточно внимания. В итоге дизайн
страдает, появляются дефекты, и команда вдруг обнаруживает, что замедлилась,
стараясь улучшить внутреннее качество.
Подобным образом не поддавайтесь искушению засчитать частично выполненные
истории в свой потенциал. Если история завершена не полностью, то считается за
ноль. Не приписывайте себе такие истории. Есть старая программистская шутка:
первые 90 % работы занимают 90 % времени… и последние 10 % работы занимают
90 % времени. До тех пор, пока история не сделана полностью, невозможно точно
сказать, какой процент был выполнен.
330 Часть II. Фокус на ценность
Вопросы
Почему строить доверие — это наша ответственность? Разве стейкхолдеры не долж-
ны внести свой вклад?
Вы отвечаете только за себя. В идеале стейкхолдеры тоже много работают над
взаимоотношениями, но это выходит за пределы вашего контроля.
Разве не важнее быть хорошими, чем казаться хорошими?
И то и другое важно. Выполняйте работу на отлично и делайте так, чтобы люди
знали об этом.
Вы говорите, что разработчикам лучше держать при себе шутки о сроках. Разве
это не то же самое, что сказать разработчикам: «Замолчите и выполняйте работу
в срок», как ни смешно?
Вовсе нет. Каждый в команде должен иметь возможность высказываться и гово-
рить правду, когда видит проблему. Однако есть большая разница между обсуждением
реальной проблемы и обыкновенной циничностью.
Помните, что карьера заказчиков часто стоит на кону. Они могут быть не в со-
стоянии увидеть разницу между реальной шуткой и жалобой, замаскированной под
шутку. Неуместная шутка может вызвать у них выброс адреналина так же легко, как
и реальная проблема.
Предварительные требования
Обязательства — это эффективный инструмент выстраивания доверия, но только
если вы их выполняете. Не берите на себя обязательств перед стейкхолдерами, пока
не докажете свою способность брать и выполнять обязательства внутри команды.
Более подробную информацию можно найти в подразделе «Принятие и выполнение
обязательств по итерации» главы 9.
Показатели
Когда ваша команда установит доверительные отношения с вашей организацией
и стейкхолдерами:
zz стейкхолдеры верят в способность команды удовлетворить их потребности;
zz вы признаете ошибки и проблемы вместо того, чтобы скрывать их до тех пор,
пока они не приведут к сбою;
zz все ищут решения, а не виноватых.
Альтернативы и эксперименты
Доверие стейкхолдеров жизненно необходимо. Альтернативы не существует.
Однако существует много способов завоевать доверие. У этой темы долгая исто-
рия, и единственная действительно новая идея, привнесенная Agile, — это способ-
ность, используя итерации, еженедельно брать на себя обязательства и выполнять их.
Помимо этого, вы можете свободно черпать вдохновение из множества существующих
источников по выстраиванию отношений и доверия.
Глава 10. Ответственность 331
1
Юри У. Гарвардская школа переговоров. Как говорить НЕТ и добиваться результатов.
332 Часть II. Фокус на ценность
установить контакт с ними и узнать о них больше информации, особенно если они
активные участники. Аналогично, если люди, которые, как вы считали, жизненно
заинтересованы в вашей работе, не присутствуют, то хорошей идеей будет узнать
причины.
Само демо — «момент истины» для команды. Оно дает вашей команде обратную
связь в отношении способности вашей команды закончить начатую работу. Будет
трудно обманывать себя, считая, что работа сделана, если вы не сможете продемон-
стрировать ее стейкхолдерам.
В конечном итоге демо также служит обратной
связью и для стейкхолдеров. Оно показывает им, что См. также
вы — ответственная команда: прислушиваетесь к их
Доверие стейкхолдеров
потребностям и демонстрируете стабильный прогресс. (глава 10)
Это крайне важно, поскольку помогает стейкхолдерам
поверить, что ваша команда действует в их интересах.
Частота демо
Начните с проведения демо еженедельно или каждую итерацию, если используете
итерации длиннее недели. Всегда проводите демо в одно и то же время и в одном
и том же месте. Это поможет установить ритм, облегчит людям планирование участия
и придаст сильный импульс с самого начала.
Если ваша работа не секретная, то приглашайте
всех в компании, кому это может быть интересно. Вся См. также
команда, ключевые стейкхолдеры и исполнительный
Вовлечение реального
спонсор должны присутствовать как можно чаще. По
заказчика (глава 8)
возможности пригласите реальных заказчиков. Вдоба-
вок можно позвать другие команды, работающие рядом,
и людей, интересующихся Agile.
Если вы используете итерации, то проводите демо незамедлительно по окончании
каждой из них. Я люблю проводить демо на следующий день, утром. Это поможет
вашей команде поддерживать дисциплину, поскольку вы не сможете затянуть работу
до следующей итерации.
Как правило, на демо планируют 30 минут. Может быть и дольше, но время ваших
самых важных стейкхолдеров очень ценное, поэтому лучше планировать короткие
встречи, чтобы они могли участвовать регулярно. Пусть ваше решение основывает-
ся на их заинтересованности и доступности. Помните, что вы также всегда можете
связаться с людьми после демо.
Вместе с презентацией демо предложите стейкхол-
дерам способ попробовать что-то самостоятельно. Для См. также
этого варианта можно задействовать промежуточный
Флаги функций (глава 15)
(staging) сервер или, если вы используете флаги функ-
ций (feature flags, фича-флаги), специальные разреше-
ния для учетных записей стейкхолдеров.
Глава 10. Ответственность 333
ПРИМЕЧАНИЕ
Если вы общаетесь с большим количеством людей, то вам может понадобиться
установить правила относительно вопросов и прерываний, чтобы демо не заняло
слишком много времени.
Так как встреча короткая, лучше начинать вовремя, даже если некоторые участ-
ники опаздывают. Это покажет, что вы цените время участников. И докладчик,
и демо должны оставаться доступными для дальнейшего обсуждения и изучения
после встречи.
Начните презентацию с краткого напоминания участникам о ценном инкремен-
те, над которым сейчас работает команда, и поясните, почему он является столь
важным, чтобы тратить на него время. Подготовьте почву и предоставьте контекст
334 Часть II. Фокус на ценность
тем людям, которые до этого не были полностью посвящены в детали. Затем кратко
опишите истории, над которыми команда работала с момента предыдущего демо.
Если вы внесли в свой план любые изменения, которые могут вызвать обеспокоен-
ность стейкхолдеров, то объясните, что случилось. Не приукрашивайте и не скрывайте
проблемы. Полная прозрачность повысит
доверие к вам. Ничего не упрощая и не пре- Спокойно опишите проблемы и то,
увеличивая, вы продемонстрируете способ- как вы с ними разобрались.
ность вашей команды профессионально
обращаться с проблемами. Например:
Как только демо завершено, объясните стейкхолдерам, как они могут запустить
ПО самостоятельно. Это хороший способ свернуть встречу, особенно если она
затягивается: объяснить аудитории, как они могут сами все попробовать, и затем
спросить, не хотел ли кто-либо продолжить общение в частном порядке, при наличии
дополнительных вопросов или отзывов.
Подготовьтесь
Перед началом демо убедитесь, что все истории,
планирующиеся для демонстрации, в состоянии См. также
«Сделано Сделано» и что у вас есть версия ПО,
включающая их. Убедитесь, что у участников Сделано Сделано (глава 9)
есть возможность попробовать демо самостоя-
тельно.
Вам не нужно создавать для демо безупречную презентацию с идеальной графи-
кой, но все же нужно быть подготовленными. Вы должны быть готовы презентовать
демо в течение 5–10 минут, а это значит, что вам следует знать свой материал и при
этом быть лаконичными.
336 Часть II. Фокус на ценность
что смогли бы вам показать. Теперь мы знаем больше и в следующий раз будем
более проактивными в отношении изменений планов.
Мы ожидаем похожих проблем с авиационными системами в будущем. Нам
пришлось добавить больше историй, чтобы учесть изменения, и использовать
почти весь наш буфер. Мы все еще укладываемся в сроки запуска маркетин-
говой кампании, но нам понадобится сократить функциональности, если мы
столкнемся с другими серьезными проблемами за это время.
Прошу прощения за плохие новости, и я готов ответить на ваши вопросы.
Я могу ответить на несколько вопросов сейчас, и после того как мы завер-
шим корректировку наших планов позже на этой неделе, у нас будет больше
информации.
Вопросы
Что нам делать, если стейкхолдеры продолжают прерывать и задавать вопросы во
время демо?
Вопросы и прерывания — это прекрасно! Значит, стейкхолдеры вовлечены и за-
интересованы.
Если вас так часто прерывают и задают вопросы, что вы не можете уложиться
в 30-минутный лимит времени, то, возможно, вам придется проводить демо чаще.
Или, если это только один особенно заинтересованный человек, вы можете попросить
его (или ее) отложить вопросы на более позднее время после встречи. Кроме того,
можно планировать встречи длительностью больше 30 минут, особенно в первые
месяц или два.
Что нам делать, если стейкхолдеры продолжают придираться к нашему выбору
решений?
Придирки — это тоже нормально, они служат признаком интереса, когда вы на-
чинаете проводить демо. Не принимайте их слишком близко к сердцу. Запишите
идеи на карточки, как любую другую историю, и приоритизируйте их после встречи.
Удерживайтесь от соблазна начать разбираться, приоритизировать или разрабатывать
решения во время встречи. Это не только ее затягивает, но и нарушает дисциплину
обычной практики планирования.
Если придирки продолжаются по истечении первых одного-двух месяцев, то это
может служить знаком, что заказчики в команде что-то упускают. Внимательно
изучите их претензии, чтобы понять, есть ли более глубокая проблема.
Стейкхолдерам очень нравится то, что они видят, и они хотят добавить набор
функциональностей. Это хорошая идея, но нам уже нужно заниматься другими ве-
щами. Что нам делать?
Не говорите «нет» во время демо. И не говорите «да». Просто поблагодарите
стейкхолдеров за их предложения и запишите их в качестве историй. По окончании
демо заказчики в команде должны будут более внимательно посмотреть предложения
и оценить их значимость относительно цели команды. Если они не вписываются
в график команды, то член команды с навыками менеджмента продукта может со-
общить это стейкхолдерам.
338 Часть II. Фокус на ценность
Предварительные требования
Никогда не фальсифицируйте демо для стейкхолдеров, скрывая баги или показывая
незавершенные истории. Вы просто навлечете на себя неприятности в будущем.
Если вы не можете демонстрировать прогресс, не прибегая к подделкам, — это
явный знак того, что у вашей команды проблемы. Замедлитесь и попытайтесь
разобраться, что идет не так. Если вы не используете итерации, то попробуйте их.
Если используете, то прочитайте подраздел
«Принятие и выполнение обязательств по
См. также
итерации» главы 9 и попросите помощи
у наставника. Проблема может заключаться Планирование задач (глава 9)
в том, что вы пытаетесь сделать слишком
много всего одновременно.
Показатели
Когда ваша команда хорошо проводит демо:
zz вы вызываете доверие у стейкхолдеров;
zz вы узнаёте, что стейкхолдеры увлечены больше всего;
zz команда уверена в своей способности поставлять продукт;
zz вы прямо говорите о проблемах, что позволяет вашей команде не давать им вы-
ходить из-под контроля.
Глава 10. Ответственность 339
Альтернативы и эксперименты
Демо для стейкхолдеров — четкий показатель вашей способности к поставке. Или
у вас есть завершенные истории для демонстрации, или нет. Или ваши стейкхол-
деры довольны вашей работой, или нет. Я не знаю альтернатив, которые могли бы
предоставить настолько ценную обратную связь.
Эта обратная связь — важная часть демо для стейкхолдеров. Обратная связь,
касающаяся способности вашей команды к поставке, обратная связь, говорящая об
удовлетворенности стейкхолдеров, а также обратная связь, которую вы получаете,
наблюдая их реакцию и слушая их вопросы и комментарии.
Когда вы экспериментируете с демо для стейкхолдеров, держите в голове эту об-
ратную связь. Демо — не только способ поделиться тем, чем вы сейчас заняты. Это еще
и способ узнать ваших стейкхолдеров. Некоторые команды упрощают проведение
демо, записывая краткое видео. Это разумная идея, и ее стоит попробовать. Но видео
не даст вам столько же обратной связи. Удостоверьтесь, что в любых экспериментах,
которые вы пробуете, есть вариант, который позволяет подтвердить вашу способность
выполнить работу и узнать у ваших стейкхолдеров интересующую вас информацию.
Некоторые команды выворачивают демонстрацию наизнанку: вместо того чтобы
показывать стейкхолдерам то, что они делают сейчас, они наблюдают за стейкхол-
дерами, которые сами тестируют их ПО. Это лучше всего работает в условиях непо-
средственного общения. Это также хорошо работает, если у вас множество команд,
работающих в офисе: вы можете пригласить их всех в одно большое помещение
и провести демо в стиле «базар» или «торговая выставка», когда стейкхолдеры могут
перемещаться от команды к команде и наблюдать их работу1.
ПРОГНОЗИРОВАНИЕ
Мы можем предсказать наши релизы.
Аудитория
«Когда вы закончите?» Программисты боятся
Продакт-менеджеры
этого вопроса. В разработке ПО столько нюансов, что
просто невозможно точно знать, что осталось сделать,
не говоря уже о том, сколько времени это займет. Тем не менее у стейкхолдеров есть
реальная потребность знать, сколько времени займет работа. Им нужно планировать
бюджет и координироваться с третьими сторонами. Чтобы сформировать доверие
и продемонстрировать свою ответственность, вы должны быть в состоянии пред-
сказать, когда будет релиз.
Составление этих прогнозов обычно называется оценкой (estimate), но это не-
верный термин. Оценка — просто одна из техник прогнозирования, и даже не самая
важная. Настоящий секрет хорошего прогнозирования — в понимании неопределен-
ности и риска. Именно поэтому я называю это прогнозированием.
1
Я узнал об этом подходе от Баса Водде. Подход «Базар» основан на технике «Ярмарка научных
достижений», обсуждаемой в [Schatz2004].
340 Часть II. Фокус на ценность
Неопределенность и риск
На первый взгляд, Agile предлагает отличное ре-
шение для прогнозирования: если вы используете См. также
итерации, то суммируйте ваши истории (или их
Потенциал (глава 9)
оценки), разделите на ваш потенциал — и вуаля!
Получите количество итераций, оставшихся до за- Резерв времени (глава 9)
вершения. В конце концов, потенциал и резерв вре-
мени дают вам возможность стабильно брать на себя итерационные обязательства
и выполнять их. Разве это не должно означать, что вы можете взять на себя обяза-
тельства и по релизам?
К сожалению, нет. Представьте, что вы в команде, которой нужно сделать 30 исто-
рий до релиза. Она стабильно делает шесть историй еженедельно, так что все займет
пять недель, верно? Сегодня 1 января, поэтому вы говорите вашим бизнес-стейк-
холдерам, что релиз будет через пять недель, 5 февраля. Они с энтузиазмом ждут
нового релиза и начинают рассказывать о нем заказчикам. «Подождите — и увидите,
что будет дальше. Ждите новостей 5 февраля!»
За следующую неделю вы заканчиваете шесть историй, как обычно. В процессе вы
обнаруживаете баг. Это небольшая проблема, но ее нужно решить до релиза. Вы добав-
ляете историю, чтобы исправить баг в следующей итерации. 8 января у вас остается
25 историй. Вы сообщаете стейкхолдерам, что, вероятно, релиз будет несколько позже,
чем 5 февраля. Они призывают вас немного ускориться. «Просто поднажмите, — го-
ворят они. — Наши заказчики рассчитывают на релиз 5 февраля!»
Пятнадцатого января во время демо ваши стейкхолдеры вдруг понимают, что одна
из функциональностей нуждается в дополнительных средствах аудита. Вы добавля-
ете четыре новые истории, чтобы удовлетворить эту потребность. С учетом шести
законченных историй остается 23 истории, а это означает, что вы точно не закончите
к 5 февраля. Вы предлагаете урезать функциональность, чтобы вернуть дату релиза
к начальным условиям, но стейкхолдеры сопротивляются. «Мы уже сказали заказ-
чикам, чего ожидать, — говорят они. — Мы просто скажем им, что будет задержка
на неделю».
На следующей неделе все идет гладко. Вы снова делаете шесть историй, и 22 ян-
варя остается 17 историй. Вы на пути к релизу 12 февраля.
Следующие несколько недель все идет не очень хорошо. Вы ждали, пока другая
команда поставит специальный UI-компонент. Они обещали передать его вам в на-
чале января, но продолжают сдвигать сроки. Теперь у вас закончились истории, над
которыми можно работать. Вы берете несколько дополнительных необязательных
историй наподобие «хорошо бы иметь», чтобы оставаться чем-то занятыми. Как
обычно, вы завершаете шесть историй, но большинство из них новые. 29 января
у вас все еще остается 15 историй.
Потом команда, работающая над UI, проясняет ситуацию: они столкнулись с не-
ожиданной технической проблемой. Компонент UI, на который вы рассчитывали,
не будет готов еще минимум месяц. Вы пересматриваете свой план, добавляете
истории, чтобы как-то обойти проблему отсутствующего компонента. 5 февраля, не-
смотря на завершение шести историй, у вас все еще 13 незаконченных историй. Ваши
Глава 10. Ответственность 341
Прогнозы осуществимости
Иногда вы просто хотите знать, стоит ли браться за идею, не прибегая к временны́ м
и финансовым затратам на подробное планирование. Любой подход, не подразуме-
вающий детального планирования, будет просто основан на внутренних ощущениях,
и это нормально. Люди с большим опытом могут принимать правильные решения
на основе своих внутренних ощущений.
Чтобы сделать прогноз осуществимости, соберите вместе спонсора команды,
опытного менеджера по продукту или проекту и одного-двух старших программи-
стов — предпочтительно участников команды. Выбирайте людей с большим опытом
работы в вашей компании.
Попросите спонсора описать цели разработки, дату начала работы, состав команды
и указать самую позднюю дату релиза, которая еще будет стоить затрат на нее. За-
тем спросите продакт-менеджера и программистов, считают ли они это возможным.
Обратите внимание: вы не спрашиваете, сколько времени это займет. Это более
трудный вопрос. Вам нужна первая, спонтанная реакция. Формулировка вопроса
в терминах твердых ожиданий делает эту реакцию более надежной.
Если ответ — безоговорочное «да», то имеет смысл инвестировать в месяц-другой
разработки, чтобы вы смогли подготовить реальный план и прогноз. Если эксперты
будут колебаться или скажут «нет», то существует риск. Стоит ли он инвестиций
в более тщательный прогноз — зависит от спонсора.
Глава 10. Ответственность 343
1
Большое спасибо Тодду Литтлу за обратную связь по этой технике.
2
Эти цифры риска являются обоснованным предположением. Цифры, представляющие «высокий
риск», основываются на [Little2006] и последующих обсуждениях с Тоддом Литтлом. Цифры,
представляющие «низкий риск», основываются на симуляторе RISKOLOGY ДеМарко и Листера
версии 4а, доступном по адресу https://systemsguild.eu/riskology. Я использовал стандартные
настройки, но выключил отклонение производительности, так как потенциал автоматически
подстраивается под этот риск.
344 Часть II. Фокус на ценность
Снижение риска
Командам с высоким уровнем риска трудно составлять полезные прогнозы. Три ме-
сяца историй дают прогноз с вероятностью 50–90 % на 6–12 месяцев. Стейкхолдерам
трудно принять такую высокую неопределенность.
346 Часть II. Фокус на ценность
чтобы получить соотношение «реальное / оценочное» для каждой пары. В табл. 10.2
представлен пример.
25,0 % 1,38
37,5 % 1,50
50,0 % 1,57
62,5 % 1,60
75,0 % 1,60
87,5 % 1,68
100,0 % 1,76
Чем больше данных о релизах вы используете, тем более точными будут по-
правки на риск. Для большей точности каждая команда должна отслеживать свои
данные независимо, но для начала вы можете комбинировать данные от нескольких
похожих команд.
348 Часть II. Фокус на ценность
Вопросы
Наша пропускная способность сильно меняется, поэтому прогнозы постоянно скачут.
Можем ли мы использовать среднее значение пропускной способности, чтобы они
были более стабильными?
Стабилизировать пропускную способность
лучше с помощью потенциала и резерва време- См. также
ни. Если этот вариант не подходит, то можете
взять среднее за последние три недели (или Потенциал (глава 9)
итерации), чтобы стабилизировать прогноз Резерв времени (глава 9)
или нарисовать график ваших прогнозов и до-
бавить линии тренда.
Наши прогнозы показывают, что мы делаем релизы слишком поздно. Что нам
делать?
Вам нужно сократить объем работы. Больше информации вы найдете в подразделе
«Когда дорожная карта недостаточно хороша» далее в текущей главе.
Наши эмпирические поправки на риск слишком велики. Можем ли мы использовать
меньшее соотношение?
Когда ваш прогноз не слишком оптимистичен, трудно удержаться от соблазна
поиграть цифрами, чтобы улучшить ситуацию. Как человек, который был в такой
ситуации и имеет подтверждающие данные, говорю вам, что это пустая трата времени.
Так вы не измените реальных сроков релиза вашего ПО. Если у вас есть исторические
данные, то можете составить пользовательскую таблицу поправок на риск, но если
данных нет, то лучший вариант для вас — встретить неприятные новости с высоко
поднятой головой и сократить объем работы.
Предварительные требования
Запланированные даты релизов и прогнозы осуществимости подходят любой ко-
манде.
Чтобы сделать прогноз даты и объема рабо-
ты, вам нужна команда, работающая над акту- См. также
альным ПО, для которого был сделан прогноз.
Вам нужно иметь историю, насчитывающую Игра в планирование (глава 8)
по меньшей мере четыре недели разработки,
и вы можете прогнозировать инкременты только с историями, размер которых был
заявлен как «в самый раз» при игре в планирование.
Что еще более важно, убедитесь, что вам действительно нужен прогноз. Слишком
многие компании просят прогнозы просто по привычке. Прогнозирование отнимает
время, которое ушло бы на разработку. Не только время, требующееся на составле-
ние прогноза, но и время, необходимое для того, чтобы справиться со множеством
эмоциональных реакций, которые прогнозы вызывают как у членов команды, так
и у стейкхолдеров. Все это также усложняет адаптацию ваших планов.
Как и во всем, что делает команда, имейте четкое представление о том, кому бу-
дут полезны прогнозы по датам и объемам работ, почему и в какой степени. Потом
Глава 10. Ответственность 349
Показатели
Когда ваша команда хорошо делает прогнозы:
zz вы можете координироваться с внешними мероприятиями, такими как марке-
тинговые кампании, имеющими длительные сроки;
zz вы можете координировать предстоящие даты поставок с бизнес-стейкхолдерами;
zz вы понимаете, когда затраты команды превышают ее ценность;
zz у вас есть данные, позволяющие противостоять нереалистичным ожиданиям
и срокам.
Альтернативы и эксперименты
Существует много подходов к прогнозированию даты и объема работы. Описанный
мною подход имеет преимущество одновременно в точности и простоте. Однако его
зависимость от историй размера «в самый раз» делает его довольно трудоемким для
прогнозов, предшествующих разработке. Другой недостаток — это объем историче-
ских данных, требующихся для использования в пользовательских поправках на
риск, хотя эмпирические правила часто довольно хороши.
Альтернатива — использовать симуляцию Монте-Карло для усиления небольших
объемов данных. Популярный пример — таблица Троя Мадженниса «Предсказатель
пропускной способности», доступная по адресу https://www.focusedobjective.com/
courses/using-the-monte-carlo-forecasting-spreadsheets.
Недостаток таблицы Мадженниса и подобных ей инструментов оценки заключа-
ется в том, что она просит вас оценивать источники неопределенности, а не исполь-
зовать исторические данные. Например, таблица Мадженниса просит пользователя
предположить диапазон оставшихся историй, как и диапазон количества историй,
которые надо добавить (или разделить, используя ее терминологию). Эти предпо-
ложения сильно влияют на прогноз, но являются всего лишь предположениями.
Таблица была бы более надежной, если бы вместо предположений использовала
реальные данные для расширения объема работы.
Прежде чем начать экспериментировать с альтернативными прогнозами даты
и объема работы, помните, что лучший способ сделать прогноз — выбрать заплани-
рованную дату релиза и строить свои планы так, чтобы успеть точно в срок.
ДОРОЖНЫЕ КАРТЫ
Аудитория
Наши стейкхолдеры знают, чего от нас ожидать.
Продакт-менеджеры
В конечном итоге быть ответственным за результат
означает делать так, чтобы инвестиции вашей организации приносили хороший до-
ход. В идеальном мире ваши бизнес-стейкхолдеры будут доверять вашей команде
делать это, избавив вас от пристального надзора. Это достижимо, но обычно сначала
требуются год или два надежных поставок.
Тем временем ваша организация хочет контролировать работу вашей команды.
Демо для стейкхолдеров помогают, но менеджеры часто хотят знать больше о том,
что вы делаете и чего ожидать. Вы подели-
тесь этой информацией в вашей дорожной
См. также
карте.
В Agile дорожные карты не должны вы- Доверие стейкхолдеров (глава 10)
глядеть как традиционные дорожные карты
программного обеспечения. Я использую Демо для стейкхолдеров (глава 10)
этот термин довольно свободно, чтобы охва-
тить все разнообразие способов, с помощью которых команды делятся информацией
о своем прогрессе и планах. Одни дорожные карты подробны и дают информацию
по существу, ими нужно делиться с руководителями, другие — краткие и приукра-
шенные — предназначены для заказчиков.
Agile-руководство
Тип вашей дорожной карты зависит от подхода к руководству, практикуемого в вашей
организации. Как ваша организация обеспечивает эффективную работу команд и их
движение в верном направлении?
Классический подход — руководство, основанное на проектах. Оно подразумевает
создание плана, оценку затрат и оценку стоимости. Проект подлежит финансирова-
нию, если общая стоимость значительно превышает общие затраты. После принятия
решения о финансировании проект тщательно контролируется, чтобы убедиться,
что он идет в соответствии с планом.
Этот предиктивный подход к руководству не в стиле Agile. Он подразумевает,
что планы должны быть определены заранее. Изменения строго контролируются,
и успех определяется как выполнение плана. Руководству нужны дорожные карты,
содержащие детальные планы, оценки затрат и прогресс выполнения работ.
Глава 10. Ответственность 351
К А Р ГО - К УЛ ЬТ
Дедлайн
Реальная история: у самой сложной команды, которую я когда-либо
тренировал, были жесткие дедлайны. (А у кого их нет?) Реальный
заказчик команды был критически важен: крупное ведомство,
приносящее бóльшую часть дохода организации. Если бы мы
не смогли удовлетворить его запросы, то рисковали бы лишиться
огромной части жизненно важного бизнеса. Объем работы и дата
готовности были фиксированными.
Зная, что было поставлено на карту, я сделал надежный прогноз нашим главным
приоритетом. Шесть недель спустя мы не только реализовали первый набор
историй объемом на шесть недель — у нас уже был измеренный потенциал,
полностью оцененный список оставшихся историй и прогноз относительно того,
когда все будет сделано.
Он показал, что мы опаздываем. Сильно опаздываем. Нам нужно было сделать
поставку через семь месяцев. Прогноз показал, что это займет тринадцать.
Я отнес прогноз директору. Все пошло прахом. Директор запретил нам делиться
этими новостями с заказчиком. Вместо этого он приказал нам любым возможным
способом сделать все в соответствии с первоначальным дедлайном.
Мы знали, что не можем выполнить работу в соответствии с этими сроками.
Мы не могли добавить людей; команда уже была полностью укомплектована,
и новым программистам понадобилось бы много времени, чтобы ознакомиться
с кодовой базой. Мы не могли сократить объем работы, поскольку не имели воз-
можности признать наличие проблемы перед заказчиком.
На кону стояли наши рабочие места, и мы старались, чтобы все получилось.
Мы игнорировали закон Брукса («Добавление человеческих ресурсов в программ-
ный проект, не укладывающийся в сроки, приводит к еще большей задержке»
[Brooks1995], с. 25), наняли группу программистов и сделали все, что смогли,
чтобы быстро ввести их в курс дела, не отвлекая продуктивных членов коман-
ды от их работы. Несмотря на все наши усилия, мы поставили ПО с дефектами
с шестимесячным опозданием — в пределах нескольких недель от даты нашего
прогноза. Мы лишились заказчика.
Я больше никогда не буду участвовать в сокрытии информации. Расписания
не умеют хранить секреты. Чудес не бывает. Настоящая дата релиза в конце
концов обязательно всплывет на поверхность.
Вместо этого я делаю все, что в моих силах, чтобы представить наиболее точную
картину происходящего. Если в данном релизе должен быть исправлен дефект, то
я планирую исправление перед следующей историей. Если наш потенциал ниже
того, что мне бы хотелось, я, тем не менее, делаю прогноз, основываясь на нашем
реальном потенциале. Это реальность, и только будучи честным по отношению
к ней, я могу эффективно управлять последствиями.
Глава 10. Ответственность 357
Вопросы
Как часто мы должны обновлять свою дорожную
карту? См. также
Обновляйте ее, когда появляется существен-
Демо для стейкхолдеров
ная новая информация. Сообщать об изменени- (глава 10)
ях дорожной карты можно во время проведения
демо для стейкхолдеров.
Что мы должны говорить стейкхолдерам о вероятности прогноза?
По моему опыту, стейкхолдерам трудно понять вероятность прогноза. Я даю диа-
пазон дат, но не вдаюсь в детали насчет вероятностей.
Если команда не отчитывается о детальных планах, то как руководители команд-
ного уровня понимают, что делают их команды?
Руководители командного уровня могут напрямую посмотреть на доски плани-
рования своих команд. Больше информации об управлении командами вы можете
найти в разделе «Менеджмент» далее в текущей главе.
Предварительные требования
Кто угодно может создавать дорожные карты, но создание эффективных простых
дорожных карт требует управления в соответствии с Agile и готовности позволить
командам отвечать за свою работу, как обсуждается в главе 4.
Показатели
Когда вы хорошо используете дорожные карты:
zz руководители и стейкхолдеры понимают, над чем работает команда и почему;
zz команде не мешают адаптировать ее планы.
Альтернативы и эксперименты
Есть много способов презентовать дорожные карты, и я не вдавался в детали на-
счет специфических стилей презентаций. Экспериментируйте! Самый известный
подход, который я видел, — наборы коротких слайдов, но некоторые также делают
видео (в частности, для дорожных карт типа «Только факты»), ведут Вики-страни-
цы и рассылают электронные письма с обновлениями статуса. Обсудите с вашими
стейкхолдерами, что для них лучше.
В ходе эксперимента ищите способы улучшить вашу способность адаптиро-
ваться и делать меньше прогнозов. Со временем стейкхолдеры начнут доверять
вашей команде, поэтому будьте готовы к тому, что их ожидания изменятся. Вы
можете обнаружить, что предыдущие требования, казавшиеся незыблемыми,
больше неважны.
358 Часть II. Фокус на ценность
МЕНЕДЖМЕНТ
Аудитория
Мы помогаем своим командам достичь успеха.
Руководители
Демо для стейкхолдеров и дорожные карты по-
зволяют руководителям видеть, что производят их
команды. Но руководителям нужно больше. Они хотят знать, работают ли команды
эффективно и как они могут помочь им добиться успеха.
В отличие от остальных практик данной книги, которые предназначены для
членов команды, эта практика — для руководителей. В первую очередь для руково-
дителей командного уровня, но идеи могут применять и руководители среднего
и старшего звеньев. В рабочей среде, в которой команды сами решают, как будет
сделана работа (см. врезку «Самоорганизующиеся команды» в главе 7), что делают
руководители и как они помогают своим командам достичь успеха?
Большинство организаций используют менед-
жмент на основе измерения: собирая показатели,
Менеджмент на основе
требуя отчеты и разрабатывая систему наград для
измерения не работает.
поощрения правильного поведения. Это проверенный
временем подход к управлению, возвращающий нас
во времена изобретения сборочного конвейера.
Есть лишь одна проблема — он не работает.
К А Р ГО - К УЛ ЬТ
Максимальное ускорение
— Согласно этой книге, — говорит вице-президент по инженерным
вопросам, держа в руках экземпляр Accelerate1, — высокопроиз-
водительные организации имеют автоматизированные тесты.
Начиная с этого момента любой регистрируемый вами код должен
не менее чем на 90 % покрываться тестами. Это обязательное
требование. Все, кто не согласен, могут искать другую работу.
Тишину нарушает чей-то кашель. Затяжной, подозрительно похожий на фразу:
«Корреляция — это не причинно-следственная связь». Вице-президент пристально
смотрит в вашем направлении.
1
Accelerate [Forsgren2018] — отличная книга. Я упоминаю увиденные мною случаи неправильного
ее применения, а не подвергаю критике ее саму.
Форсгрен Н., Хамбл Дж., Ким Дж. Ускоряйся! Наука DevOps: Как создавать и масштабировать
высокопроизводительные цифровые организации.
Глава 10. Ответственность 359
— Тебе обязательно нужно было делать это, стоя рядом со мной, Нелия? — жалобно
говорите вы позже. — Здесь довольно трудно получить повышение.
— Извини, — говорит она, совсем не выглядя виноватой. — Знаешь, я уже про-
ходила через это раньше. Я могу рассказать тебе, что будет дальше. Во-первых,
все будут в панике, поскольку на кон поставлена их работа. Во-вторых, руково-
дители скажут, что ни один из наших дедлайнов не меняется, так как их бонусы
зависят от соблюдения сроков релизов. В-третьих, у нас самый фиго… — Она
бросает взгляд на банку ругательств. В ней уже столько взносов Нелии, что
хватило профинансировать три из четырех последних «пончиковых» пятниц. —
Хм, самый сомнительный пакет тестирования в мире. Много-много медленных,
простеньких, ничего толком не проверяющих тестов. В итоге мы тратим все
свое время, ожидая, пока пройдет тест, и разбираясь с фальшивыми ошибками
тестов. И ничего не улучшается.
— Вот поэтому я ненавижу всю эту белиберду с Agile, — продолжает она. — Тонны
работы, ноль реальных результатов. Почему мы не можем просто писать код?
Теория X и теория Y
В 1950-х Дуглас Макгрегор определил два противоположных стиля управления:
теорию X и теорию Y. Каждый из них основывается на своей теории мотивации
работников.
Руководители, придерживающиеся теории X, уверены, что сотрудники не любят
работу и пытаются ее избежать. Их нужно принуждать и контролировать. Внешние
мотиваторы, такие как оплата, льготы и пособия, и другие формы поощрений — глав-
ный механизм, позволяющий заставить работников делать то, что нужно. Согласно
теории X, разработка и внедрение внешних схем мотивации с использованием таких
инструментов, как измерение и поощрение, — центральный элемент правильного
менеджмента.
Руководители, выбравшие теорию Y, верят, что сотрудникам нравится работать
и они способны к самоуправлению. Они ищут ответственность и получают удо-
вольствие, решая проблемы. Внутренние мотиваторы, такие как чувство удовле
творенности хорошо выполненной работой, вклад в общее дело группы или решение
сложных проблем, — основные движущие силы поведения работника. Согласно
теории Y, центральный элемент правильного менеджмента — обеспечение контекста
и вдохновения, что позволяет людям работать вне строгого контроля.
Менеджмент, основанный на измерениях, — это подход теории X. Он основан на
использовании внешних мотиваторов для стимулирования правильного поведения.
Agile, напротив, — подход теории Y. Ожидается, что члены Agile-команд должны
быть внутренне мотивированы на то, чтобы решать проблемы и достигать цели ор-
ганизации. Они должны быть способны сами решать, над чем им работать, а также
кто и как будет выполнять работу.
360 Часть II. Фокус на ценность
1
Спасибо Диане Ларсен за ее вклад в подготовку этого списка.
Глава 10. Ответственность 361
zz делают так, чтобы команда понимала, насколько хорошо она соблюдает устав и как
ее работу воспринимают заинтересованные стороны, в частности руководители
и бизнес-стейкхолдеры;
zz находятся в курсе отношений команды и стейкхолдеров и помогают ей понять,
когда и почему эти отношения не работают должным образом;
zz отстаивают интересы команды среди остальной части организации и координи-
руются с коллегами-руководителями для защиты команд друг друга. Помогают
командам справляться с организационной бюрократией и устранять препятствия
на пути к успеху;
zz обеспечивают достижение ожидаемых организацией результатов в таких вопро-
сах, как бюджет, управление, отчетность. Аккуратно подталкивают к ослаблению
этих требований, когда это может помочь команде.
Дисфункция измерений
Есть один пункт, который вы не увидите
в этом списке, — показатели. Это потому, что Менеджмент, основанный
менеджмент, основанный на измерениях, ис- на измерениях, искажает поведение
кажает поведение и вызывает дисфункцию. и вызывает дисфункцию.
Приведу несколько примеров.
Покрытие кода
Один из топ-менеджеров поручил сделать так, чтобы весь новый код проходил
тестирование. Целью было 85%-ное покрытие кода. «Весь новый код нуждается
в тестировании», — сказал топ-менеджер.
Хорошие тесты — маленькие, быстрые и целенаправленные, что требует вни-
мательного и обдуманного подхода. Вместо этого команды данного топ-менеджера
работали над выполнением показателей, используя самый простой и быстрый способ.
Они писали тесты, которые покрывали большое количество кода, но были медлен-
ными и нестабильными, случайным образом сбоили и зачастую не проверяли ничего
важного. Качество кода продолжало ухудшаться, производительность снизилась,
затраты на техническое обслуживание выросли.
362 Часть II. Фокус на ценность
Строки кода
В попытках повысить производительность одна компания награждала людей за
добавленное, измененное или удаленное количество строк кода за день. (Похожий
показатель — количество коммитов в день.) Члены команды стали меньше времени
посвящать дизайну и больше — удалению и вставке кода. Качество кода снизилось,
затраты на техническое обслуживание выросли, и члены команды боролись с де-
фектами, которые продолжали появляться после того, как люди думали, что все
исправлено.
Подсчет дефектов
Что проще: снизить количество дефектов, допускаемых командой, или изменить
определение понятия «дефект»? Одна организация, которая отслеживала количе-
ство дефектов, тратила время впустую на споры о том, что считать дефектом. Когда
определение было слишком узким, команда тратила много времени на исправление
незначительных дефектов. Когда оно было слишком широким, команда отправляла
заказчикам баги, что снижало удовлетворенность этих людей.
Все знают, что показатели могут вызывать проблемы. Но это лишь потому, что
руководители выбирают плохие показатели, не так ли? Умный менеджер может
предотвратить проблемы, умело балансируя показателями… Верно?
К сожалению, нет. Роберт Остин объясняет, почему нет, в своей основополагающей
книге Measuring and Managing Performance in Organizations:
«Основной посыл этой книги состоит в том, что организационные измерения
сложны. Организационный ландшафт усеян искореженными обломками из-
мерительных систем, разработанных людьми, которые считали, что измере-
ния — это просто. Если вы ловите себя на мыслях типа “Установить успешную
измерительную программу легко, если вы просто выберете правильные кри-
терии” — остерегайтесь! История показывает обратное» [Austin1996] (гл. 19).
Делегируемое управление
Даже если бы эффективная система измерения была возможна, измерения упу-
скают главное. Agile требует менеджмента, основанного на теории Y, а не на тео-
рии Х, а он строится на внутренней мотивации, а не на измерениях и системах
поощрений.
Вместо того чтобы думать об измерениях
и поощрениях, сфокусируйтесь на том, что Что члены вашей команды любят
внутренне мотивирует членов команды. Что в своей работе?
они любят в своей работе? Создание чего-то
безумно грандиозного, что полюбят заказчики? Расширение границ технических воз-
можностей? Быть частью высокофункциональной, слаженной команды? Затеряться
в потоке продуктивной работы?
Какой бы ни была мотивация, вдохновляйте вашу команду, показывая, как их
работа будет отвечать их потребностям. Обеспечьте их необходимыми ресурсами
и информацией. И сделайте шаг назад, чтобы они взяли на себя ответственность
и совершенствовались.
Идите в гемба
Если руководители не получают данных о своих подчиненных, то как они узнают,
насколько продуктивно работают люди? Они идут в гемба (gemba).
Фраза «пойти в гемба» пришла из подхода «Бережливое производство» (Lean
Manufacturing). Она означает «пойти и увидеть своими глазами»1. Идея в том, что
1
Gemba — японское слово, означающее «реальное место [где что-то произошло]», поэтому «пойти
в гемба» буквально значит «пойти в реальное место».
Глава 10. Ответственность 365
руководители узнают больше о том, что нужно, увидев реальную работу, а не глядя
на цифры.
Руководители, чтобы лучше узнать свои команды, пойдите и посмотрите своими
глазами. Загляните в код. Просмотрите макеты UI. Посидите на интервью со стейк-
холдерами. Посетите совещание по планированию.
Затем подумайте, как бы вы хотели улучшить команду. Спросите себя: «Почему
они уже не делают это сами?» Предположите добрые намерения: в большинстве
случаев это не проблема с мотивацией; это вопрос возможности, организацион-
ных препятствий, или (не сбрасывайте это со счетов) идея уже рассматривалась
и была отложена по веским причинам, которых вы просто не знаете. Crucial
Accountability1 [Patterson2013] — отличная книга, в которой обсуждается, что де-
лать дальше.
Будьте осторожны, не используйте «пойти в гемба» как оправдание для микро-
менеджмента. Это способ улучшить ваше понимание, а не механизм контроля.
Спросите команду
Компетентные Agile-команды знают о ежедневных деталях своей работы куда больше,
чем кто-либо еще. Вместо того чтобы запрашивать измерения, руководители могут
задать своим командам простой вопрос: «Что я могу сделать, чтобы помочь вашей
команде стать более эффективной?» Выслушайте. Потом действуйте.
1
Паттерсон К., Гренни Дж., Максфилд Д. и др. Серьезный разговор об ответственности. Что делать
с обманутыми ожиданиями, нарушенными обещаниями и некорректным поведением.
366 Часть II. Фокус на ценность
Вопросы
А что насчет «если вы не можете это измерить, то не сможете этим управлять»?
Фразу «Если вы не можете это измерить, то не сможете этим управлять» часто
приписывают Уильяму Эдвардсу Демингу, статистику, инженеру и консультанту
в области управления, чьи работы оказали влияние на бережливое производство,
бережливую разработку ПО и Agile.
Деминг был очень влиятелен, неудивительно, что его цитата так широко известна.
Есть только одна проблема: он этого не говорил. Он сказал обратное.
Неверно предполагать, что если вы не можете измерить что-либо, то вы не мо-
жете этим управлять, — дорогостоящий миф1.
Предварительные требования
Делегируемый стиль управления — организационная культура, которая понимает
дисфункцию измерений. Несмотря на то что ей десятки лет (Деминг подчеркивал
необходимость избавиться от менеджмента, основанного на измерениях, по меньшей
мере в 1982-м2), она все еще недостаточно широко понята и принята.
1
Эта цитата объяснена и помещена в контекст институтом Уильяма Эдвардса Деминга (https://
oreil.ly/FNeRb).
2
Принцип 12 из 14 принципов менеджмента Деминга: «А. Устраните барьеры, которые лишают по-
часового работника его права гордиться своим мастерством. Ответственность контролеров должна
быть изменена с сухих цифр на качество. Б. Устраните барьеры, которые лишают менеджеров
и инженеров их права гордиться своим мастерством. Это означает среди прочего упразднение
ежегодной оценки или рейтинга заслуг и системы менеджмента на основе поставленных целей».
368 Часть II. Фокус на ценность
Показатели
Когда вы правильно используете делегируемый стиль управления:
zz команды чувствуют, что настроены на успех;
zz они несут ответственность за свою работу и принимают правильные решения без
активного участия руководства;
zz члены команды чувствуют уверенность, делая то, что ведет к лучшим результатам,
а не к высшим баллам;
zz члены команды и руководители не склонны снимать с себя вину и обвинять
других;
zz руководители хорошо понимают, что делают их команды и как они могут им
помочь.
Альтернативы и эксперименты
Основной посыл в этой практике (менеджмент, основанный на измерениях, ведет
к дисфункции) — горькая пилюля для большинства организаций. Вас могут со-
блазнить альтернативы, которые обещают решить проблему дисфункции измерений
с помощью сложных схем балансировки.
Прежде чем сделать это, вспомните, что Agile — это подход к разработке, относя-
щийся к теории Y. Правильный способ управлять Agile-командой — использовать
делегируемый стиль управления, а не менеджмент на основе измерений.
Если вы рассматриваете идеи с альтернативными показателями, то будьте вни-
мательны. Дисфункция измерений не сразу становится очевидной. До этого могут
пройти годы, так что идея может выглядеть великолепно на бумаге и поначалу даже
казаться работающей. Вы не обнаружите ошибку до последнего момента, и даже
когда обнаружите, будет слишком легко свалить вину в проявившейся проблеме на
что-то другое.
Другими словами, скептически относитесь к любому подходу к показателям,
который не является хотя бы таким же тщательным, как подход [Austin1996].
Он основан на тезисах отмеченной наградами докторской диссертации по эконо-
мике Остина.
Тем не менее есть и хорошие, продуманные подходы к Agile-менеджменту. Когда
будете искать возможности для экспериментов, ищите варианты с подходом, де-
лающим упор на сотрудничество и делегирование теории Y. Хорошей начальной
точкой могут послужить ресурсы, перечисленные в подразделе «Литература для
дополнительного чтения».
Глава 10. Ответственность 369
Источники совершенствования
Хотя ретроспективы сейчас являются обычной практикой в Agile, в изначальных
книгах об XP и Scrum1 их не было — или, собственно говоря, никаких явных практик
улучшения. Непрерывное совершенствование явно занимало умы ранних при-
верженцев Agile, судя по его присутствию в Манифесте Agile, но ретроспективы
до последнего времени не были формально обозначены в качестве практики.
Первый известный мне метод Agile, включавший ретроспективы, был Industrial
XP (IXP) Джошуа Кериевски в начале 2000-х.
Ретроспективы в IXP были основаны на Project Retrospectives Норма Керта
[Kerth2001]. Позже Диана Ларсен, которая тесно сотрудничала с Нормом Кертом,
1
В частности, я имею в виду первое издание Extreme Programming Explained [Beck2000a] и Agile
Software Development with Scrum [Schwaber2002].
Глава 11. Совершенствование 371
РЕТРОСПЕКТИВЫ Аудитория
КЛЮЧЕВАЯ ИДЕЯ
Непрерывное совершенствование
Все Agile-команды — разные. Члены команды — разные, стейкхолдеры — разные,
и то, что командам нужно делать, тоже различается. Это значит, что процессы
каждой команды также должны различаться.
Хотя обычно лучше начать изучать Agile со стандартного процесса, такого как
тот, что представлен в данной книге, — это лишь начало, а не конец. Всегда есть
способы заставить процессы команды работать лучше, и когда ваша ситуация
улучшится, процесс должен измениться вместе с ней.
Agile-команды постоянно ищут возможности совершенствовать свои процессы,
рабочие привычки, отношения и окружающую среду. Все, что может улучшить
работу, открыто для рассмотрения.
Организации могут постоянно устанавливать ограничения вокруг процессов
команды, но никогда не должны ожидать, что у каждой команды будет абсолютно
один и тот же процесс. Чем больше команды могут адаптировать процесс к своим
конкретным потребностям, тем более эффективными будут.
Виды ретроспектив
Самая обычная ретроспектива — пульсирующая (heartbeat), происходит с регуляр-
ной частотой. (Она также известна как итерационная ретроспектива.) Команды,
использующие итерации, проводят ее в конце каждой итерации. Команды, исполь-
зующие непрерывный поток, проводят ее в определенное время каждую неделю
или две.
В дополнение к пульсирующим ретроспек-
тивам вы можете проводить более длительные, См. также
более интенсивные ретроспективы, достигая
наиболее важных этапов. Такие поэтапные Анализ инцидентов (глава 16)
ретроспективы дают вам шанс более глубоко
осмыслить свой опыт и обобщить ключевые уроки, чтобы поделиться ими с осталь-
ной организацией. Один из примеров — анализ инцидентов, о котором я расскажу
далее в этой книге.
Другие виды поэтапных ретроспектив выходят за рамки данной книги. Лучше
всего они работают, когда проводятся нейтральными третьими сторонами, поэто-
му рассмотрите возможность пригласить опытного фасилитатора ретроспектив.
Крупные организации могут иметь таких фасилитаторов в своем штате (для начала
спросите отдел кадров), или можете привлечь внешнего консультанта. Если вы за-
хотите провести эти ретроспективы самостоятельно, то прочитайте [Derby2006]
и [Kerth2001] — это отличные источники информации.
необходимо сначала решить, чтобы люди смогли говорить честно и открыто, как
того требует ретроспектива. Если вы не знаете, в чем проблема, то попросите по-
мощи у наставника.
Просьба об устном согласии некоторым участникам может показаться странной,
но она служит важной цели. Во-первых, если кто-то искренне против, то, вероятнее
всего, скажет об этом, если нужно будет выразить согласие вслух. Во-вторых, тот,
кто уже однажды высказался во время ретроспективы, скорее всего, заговорит снова.
Устное согласие поощряет дальнейшее участие.
ПРИМЕЧАНИЕ
Разочарованы, что ваша любимая категория проиграла? Подождите несколько
месяцев. Если она важная, то в конце концов выйдет в победители.
Глава 11. Совершенствование 375
Вопросы
Несмотря на все мои усилия в качестве фасилитатора, наши ретроспективы всегда
опускаются до обвинений и споров. Что я могу сделать?
Приостановите ретроспективы и сосредо-
точьтесь на динамиках команды и установлении
психологической безопасности. Если это не сра- См. также
ботает, то вам может понадобиться помощь извне.
Динамики команды (глава 11)
Рассмотрите возможность прибегнуть к помощи
специалиста по организационному развитию. Безопасность (глава 7)
Им может быть кто-то из сотрудников вашего
отдела кадров.
Мы придумываем хорошие цели ретроспектив, но потом ничего не происходит.
Что мы делаем неправильно?
Ваши идеи могут быть слишком масштабными. Помните: у вас только одна не-
деля, может быть, две, и у вас есть еще и другая работа. Попробуйте строить менее
Глава 11. Совершенствование 377
Однако обычно это не тот случай. Более вероятно то, что ретроспектива просто
устарела. Попробуйте ее изменить. Поменяйте фасилитаторов и попробуйте новые
виды активности или сконцентрируйтесь на других темах.
Предварительные требования
Самая большая опасность в ретроспективе
заключается в том, что она может стать аре- См. также
ной для нападок, а не для конструктивного
решения проблем. Постарайтесь создать Безопасность (глава 7)
среду, в которой люди смогут делиться сво-
ими истинными мнениями. Не проводите ретроспективы, если у вас есть члены
команды, которые склонны срываться на окружающих, набрасываться на других
и обвинять их.
Показатели
Когда ваша команда хорошо проводит ретроспективы:
zz ваша способность разрабатывать и поставлять ПО стабильно совершенствуется;
zz команда сближается и становится более сплоченной;
zz каждый специалист команды относится с уважением к проблемам, с которыми
сталкиваются другие специалисты;
zz члены команды честны и открыты в отношении успехов и неудач;
zz команда спокойно относится к изменениям.
Альтернативы и эксперименты
Любой формат ретроспектив устаревает со временем. Меняйте его! Формат, пред-
ставленный в этой книге, — хорошая начальная точка, но как только вы его освоите,
начните экспериментировать с другими идеями. [Derby2006] — хороший источник
информации, который поможет изучить нюансы проведения ретроспектив; кроме
того, в нем также описываются разнообразные виды активности, которые вы можете
попробовать. Опробовав эти идеи, посетите https://www.tastycupcakes.org, чтобы узнать
еще больше информации.
Некоторые считают, что час — это слишком мало для хорошей ретроспективы,
и предпочитают 90 минут или даже два часа. Вы можете экспериментировать и с более
долгими, и с более короткими вариантами. Некоторым видам активности, в частности,
нужно больше времени. В ходе экспериментов проведите короткую «ретроспективу
ретроспективы», чтобы оценить, какой эксперимент нужно повторить, а какой — нет.
В главе 8 книги [Derby2006], Activities to Close the Retrospective, есть несколько идей.
Помимо апробации новых видов активностей, вы можете экспериментировать
с абсолютно другим подходом к улучшению процессов. Арло Бельши пробовал
непрерывный подход, когда люди в течение недели записывали свои наблюдения
и складывали записки в банку, а затем в конце недели просматривали их. У Вуди
Зуилла есть упражнение, которое он называет «выявить хорошее» (turn up the good):
Глава 11. Совершенствование 379
1
Керт Н. Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться
вперед.
380 Часть II. Фокус на ценность
Развитие команды
В 1965-м Брюс Такман создал широко известную модель группового развития
[Tuckman1965]. В ней он описал четыре (позднее — пять) стадии группового раз-
вития: стадия формирования, штормовая (она же штормление, бурление, конфликт-
ная, конфронтация), стадия нормализации, стадия функционирования (исполнения)
и стадия расставания (Forming, Storming, Norming, Performing and Adjourning).
Эта модель показывает, как меняются степени товарищества и взаимодействия
с течением времени.
Идеальной модели не существует. Не вос-
принимайте модель Такмана как неизбежную, Не воспринимайте модель Такмана
чисто линейную прогрессию. Команды могут как неизбежную, чисто линейную
демонстрировать поведение любой из четырех прогрессию.
первых стадий. Изменения в составе, такие как
приход новых членов или потеря ценных товарищей по команде, могут привести
к тому, что команда вернется на более раннюю стадию. При изменениях в окружающей
обстановке, например переходе от работы в общем пространстве на удаленную работу
или наоборот, команда может регрессировать с более поздних стадий на более ранние.
Тем не менее модель Такмана дает полезные подсказки. Она позволяет вам понять
модели поведения ваших товарищей по команде, а также вы можете использовать ее
как основу для дискуссий о том, как наилучшим образом поддерживать друг друга.
В процессе формирования команда может делать совсем мало работы, если вообще
будет делать что-то относящееся к ее целям и задачам. Это нормально. Хорошая но-
вость в том, что при поддержке большинство команд быстро проходят эту стадию.
Командам на стадии формирования могут быть полезны мудрость и опыт старших
членов команды, приобретенные в предыдущих командах, а также тех участников
команды, которые тяготеют к действиям по сплочению группы или коучингу в об-
ласти командного взаимодействия.
Поддержите ваших товарищей по команде
с помощью лидерства и четкого руководства. См. также
(Больше информации о лидерских ролях в ко-
манде будет дано позднее.) Начните с поиска Цель (глава 7)
способов, которые позволят членам команды Контекст (глава 7)
познакомиться с работой и друг с другом. Сфор-
Согласование (глава 7)
мируйте общее чувство единения сильных сторон
и личностей в команде. Подготовить устав ко-
манды, содержащий цель, контекст и согласование, — отличный способ сделать это.
Вам могут пригодиться и другие упражнения, помогающие узнать друг друга, такие
как «Упражнение на построение взаимоотношений в команде» (см. одноименную
врезку в главе 7).
Наряду с подготовкой устава найдите время и для того, чтобы обсудить и разра-
ботать план команды. Сфокусируйтесь на том, что может быть сделано; выполнение
каких-либо задач создаст ощущение первых успехов. (В подразделе «Ваша первая
неделя» главы 9 описывается, как начать работу.) Найдите и сообщите о ресурсах,
доступных команде, таких как информация, обучение и поддержка.
Признайтесь в ощущениях новизны, неопределенности, растерянности и раз-
дражения. Они естественны на этой стадии. Сессии подготовки устава должны
были помочь команде разобраться с зонами ответственности, однако проясните
любые оставшиеся вопросы, касающиеся рабочих ожиданий, границ полномочий
и ответственности, а также рабочих соглашений. Убедитесь, что люди знают, как их
команда сотрудничает с другими командами, работающими над тем же продуктом.
Командам, работающим в офисе, объясните, над чем работают соседние команды,
даже если это не имеет отношения к командной работе.
В течение стадии формирования членам команды нужны следующие навыки:
zz одноуровневая коммуникация и обратная связь;
zz групповое решение проблем;
zz управление межличностными конфликтами.
Убедитесь, что членам команды доступны коучинг, наставничество или обучение
этим навыкам по мере необходимости.
Стадия нормализации: мы — № 1
Члены команды объединились в сплоченную группу. Они нашли комфортный ра-
бочий темп и наслаждаются сотрудничеством. Они идентифицируют себя как часть
команды. Фактически они могут идентифицировать себя настолько близкими и на-
столько наслаждаться совместной работой, что в рабочем пространстве появляются
символы принадлежности. Вы можете замечать одинаковые или очень похожие
футболки, чашки с названием команды или одинаковые наклейки на компьютерах.
Виртуальные команды могут завести традицию дней «все в кепках» или дней «га-
вайских рубашек».
Команды на стадии нормализации согласовали структуру и рабочие отношения.
Взаимодействие позволяет развивать неформальные, неявные нормы поведения, до-
полняющие командные рабочие соглашения. Люди вне команды могут заметить ее
«командность» и говорить об этом. Некоторые могут завидовать этому — особенно
если члены команды начинают хвастаться своими успехами или объявлять свою
команду «лучшей».
Их гордость оправданна. Команды, находящиеся на стадии нормализации, успеш-
но и стабильно двигаются в направлении к своей цели. Члены команды сталкиваются
с рисками и успешно сотрудничают. Вы увидите следующее поведение:
zz новая возможность конструктивного выражения критики;
zz принятие и положительная оценка различий среди членов команды;
zz чувство облегчения от того, что все это может хорошо работать;
zz большее дружелюбие;
zz люди чаще делятся личными историями и откровениями;
zz открытое обсуждение динамик команды;
zz желание обновлять рабочие соглашения и пересматривать вопросы границ с дру-
гими командами.
Как вам воодушевлять вашу команду на стадии нормализации? Выходите за
пределы границ команды и расширяйте кругозор участников. Способствуйте кон-
тактам с заказчиками и поставщиками. (Выезды за пределы офиса!) Если работа
команды связана с работой других команд, то просите провести обучение в кросс-
командных группах.
384 Часть II. Фокус на ценность
1
Кейнер С. Руководство фасилитатора. Как привести группу к принятию совместного решения.
Глава 11. Совершенствование 385
Совместное лидерство
Мэри Паркер Фоллетт, эксперт в менеджменте, также известная как «мать современ-
ного менеджмента», была пионером в области организационной теории и поведения.
Рассуждая о роли лидерства, она писала:
«Мне кажется, несмотря на то что власть обычно означает власть “над” (власть
одного человека или группы над другим человеком или группой), можно развить
концепцию власти “с”: совместно развиваемой власти, действующей совместно,
а не принудительно… И лидер, и его последователи следуют за незримым лиде-
ром — общей целью» [Graham1995] (с. 103, 172).
Мэри Паркер Фоллетт
Ориентированный Ориентированный
на выполнение задач на сотрудничество
1
За исключением дипломатов, эти роли были разработаны Дианой Ларсен и Эстер Дерби, осно-
вываясь на [Benne1948].
390 Часть II. Фокус на ценность
Токсичное поведение
Токсичное поведение — это любое поведение, которое создает нездоровую и небез-
опасную атмосферу, снижает динамики команды или нарушает способность команды
достичь ее цели.
Если член команды демонстрирует токсичное поведение, то начните с напоми-
нания Первой директивы ретроспективы: «Независимо от того, что мы обнаружим,
мы должны понимать и искренне верить, что каждый делал свою работу наилучшим
образом, в соответствии с тем, что было известно на тот момент, его или ее навыками
и возможностями, доступными ресурсами и сложившейся ситуацией» [Kerth2001]
(гл. 1). Предполагайте, что человек делает все наилучшим из возможных для него
способов.
Сначала ищите проблемы, связанные с давлением окружающей среды. Например,
кто-то из членов команды не высыпается, поскольку у него родился ребенок. Или но-
вый член команды может один отвечать за жизненно важную систему, с которой еще
не очень хорошо знаком. Все вместе члены команды могут внести коррективы, кото-
рые помогут людям улучшить свое поведение. Например, договорившись перенести
утренние стендапы, чтобы молодой родитель мог приходить попозже, или разделив
ответственность за функционирование важной системы с кем-то еще.
Следующий шаг — давать обратную связь данному человеку. Используйте про-
цесс, описанный в пункте «Научитесь давать и получать обратную связь» главы 7,
чтобы описать последствия такого поведения и попросить изменить его. Очень часто
этого оказывается достаточно. Люди просто не осознавали, как их поведение влияет
на команду, и будут вести себя иначе.
392 Часть II. Фокус на ценность
Вопросы
Разве не важно команде иметь одного лидера? Как это работает с командами лидеров?
Наличие единственного лидера позволяет упростить комплексную проблему, но
этот способ не так уж и удобен для самого человека в этой роли. Это также противо-
речит Agile-идеалу коллективного владения (см. врезку «Коллективное владение»
в главе 9). Вся команда несет ответственность. Нет козла отпущения, который
возьмет на себя ответственность, если все пойдет не так, или того, кто получит все
награды, если все будет хорошо, поскольку успех и провал — результат сложного
взаимодействия множества участников и факторов. Вклад каждого члена команды
критически важен.
Глава 11. Совершенствование 393
Предварительные требования
Чтобы эти идеи стали реальностью, ваша команда
и ваша организация должны быть к этому готовы.
Члены команды должны быть полны энергии См. также
и мотивированы работать вместе. Ничего не по-
Энергичная работа (глава 7)
лучится, если людям будет интересно только
смотреть на стрелки часов и ждать, когда им Вся команда (глава 7)
скажут, что делать. Кроме того, ваша организация Командная комната (глава 7)
должна инвестировать в командную работу. Сюда
Менеджмент (глава 10)
входит создание команды, командного помеще-
ния и подхода к менеджменту, соответствующего
принципам Agile.
Показатели
Когда у вашей команды здоровые динамики:
zz члены команды с удовольствием приходят на работу;
zz они говорят, что могут положиться на своих товарищей по команде при выпол-
нении своих обязательств, а если нет, то могут сказать об этом;
zz члены команды верят, что каждый в команде стремится к достижению ее цели;
zz они знают сильные стороны коллег и относятся с пониманием к ограничениям
в возможностях друг друга;
zz члены команды успешно работают вместе и празднуют прогресс и успехи.
Альтернативы и эксперименты
Материалы этой практики содержат лишь крошечную часть имеющихся ценных зна-
ний о командах, их динамиках, управлении конфликтами, лидерстве и многих других
вопросах, влияющих на эффективность команд. Больше информации можно найти
в источниках, указанных в ссылках и в подразделе «Литература для дополнительного
394 Часть II. Фокус на ценность
чтения». И даже это — капля в море. Спросите у наставника, что он может пореко-
мендовать. Продолжайте учиться и экспериментировать. Это дорога длиною в жизнь.
Выявление препятствий
Чтобы устранить препятствия, вы должны сначала их выявить. Задайте следующие
вопросы:
zz Что нас замедляет?
zz Что нам нужно из того, чего у нас еще нет?
zz Где бы мы могли продемонстрировать больший прогресс, если бы не ...?
zz Что нас останавливает или удерживает от ...?
zz Что постоянно способствует появлению дефектов?
zz Какие навыки нам нужны, которых у нас еще нет?
Если ваша команда не может добиться прогресса, но, кажется, на ее пути нет
никаких препятствий, то положитесь на список Уильяма Ларсена под названием
TRIPE (Tools, Resources, Interactions, Processes and Environment): инструменты,
ресурсы, взаимодействия, процессы и среда [Larsen2021]. Добавьте каждую из ка-
тегорий в предыдущий список: какие инструменты нас замедляют? Какие ресурсы
нас замедляют? Какие взаимодействия нас замедляют? И т. д.
Круги и суп
Что вам делать с препятствиями? Подумайте о них в терминах кругов и супа. Каждую
команду окружает сравнительно небольшой круг вещей, которые она может контро-
лировать, и более широкий круг вещей, на которые она только влияет. За границами
этих кругов находится суп: неизменные факты существования вашей команды. Суп
нельзя изменить, и на него нельзя оказать какого-либо влияния. Все, что вы можете
сделать, — это изменить реакцию на него вашей команды.
Следующий вид активности, основанный на [Larsen2010], использует эту идею,
чтобы помочь команде решить, как реагировать на препятствия.
Шаг 1. Используйте одновременный мозговой штурм (см. пункт «Работайте одно-
временно» главы 7) для выявления действий, которые улучшат способность вашей
команды выполнять свою работу. Запишите каждый пункт на отдельный стикер,
физический или виртуальный.
Шаг 2. Нарисуйте три концентрических круга на доске (рис. 11.2). Оставьте место
для стикеров в каждом круге.
396 Часть II. Фокус на ценность
1
Диаграмма обязательств стейкхолдеров взята и адаптирована из [Beckhard1992].
398 Часть II. Фокус на ценность
Вопросы
Что, если член команды говорит, что нет никаких препятствий, но при этом мы
не видим прогресса?
Если кажется, что у кого-то из команды
застопорилась работа, но он постоянно со- См. также
общает, что препятствий нет, то вмешайтесь.
Возможно, в его личной жизни происходят Безопасность (глава 7)
какие-то события, которые отвлекают от рабо- Парное программирование
ты, и он может чувствовать себя слишком уяз- (глава 12)
вимым и не в безопасности, чтобы признать
Групповое программирование
это. Или он может действительно застрять на (глава 12)
чем-то, но слишком привязан к своей задаче,
чтобы просить помощи, желая разобраться
самостоятельно.
Запланируйте время, чтобы поговорить. Проявите сочувствие. Скажите о поведе-
нии, которое побуждает вас вмешаться. Это единственный способ, которым вы можете
обнаружить препятствия, мешающие устранению препятствий. Обратите внимание
члена команды на расхождение между его отчетами и результатами. Убедите его
рассказать о проблеме. Подчеркните, что команда коллективно отвечает за работу
(см. врезку «Коллективное владение» в главе 9) и просить помощи или передать
задачу кому-то еще — совершенно нормально. Предотвратить эту проблему может
помочь парное или групповое программирование.
Что, если все наши препятствия возникают из-за других людей или команд?
Всегда есть соблазн обвинить кого-то в своих проблемах, но поиски виноватых
мешают вашей команде выбирать действия, помогающие контролировать пробле-
му. Подумайте о том, как поведение вашей команды вносит свой вклад в проблему.
Есть ли способы сделать что-то по-другому? Найдите часть динамики, которая может
быть в вашей власти.
Запланируйте межкомандный диалог с другими, чтобы изучить препятствие.
(Вы можете попросить нейтральную сторону выступить посредником.) Объясните
влияние на команду и ищите решение, удовлетворяющее обе стороны.
Предварительные требования
Каждая команда встречает препятствия на своем пути, но не каждое из них может
быть устранено. Некоторые находятся за пределами досягаемости вашей команды
независимо от того, насколько сильно они влияют на вас.
Помните о необходимости взглянуть на проблему шире. Слишком узкий фокус
на локальных препятствиях команды приводит к решениям, вызывающим новые
проблемы, или перекладывает препятствия на кого-то другого. Вырабатывая подход
к препятствиям, постарайтесь сохранять системный взгляд.
Остерегайтесь использовать препятствия как оправдание медленного прогресса.
Легко превратить их в козлов отпущения.
400 Часть II. Фокус на ценность
Показатели
Когда вы хорошо устраняете препятствия:
zz команда учится получать удовольствие от решения задачи путем очистки своего
пути;
zz она устраняет препятствия по мере их возникновения;
zz команда тратит меньше времени на устранение препятствий. Вместо этого она
укрепляет те практики и факторы окружающей среды, которые помогают работе.
Альтернативы и эксперименты
Устранять препятствия в конечном счете нужно для того, чтобы помочь вашей ко-
манде стать более быстрой и эффективной. Не бойтесь экспериментировать.
Например, концепция позитивного исследования (Appreciative Inquiry) меняет
ситуацию. Вместо того чтобы фокусироваться на проблемах команды, ищите то, что
наполняет ее энергией, и делайте это чаще. Отследите практики или события, благо-
даря которым команда прогрессирует. Анализируйте аспекты, в которых все идет
хорошо, и изучайте, как команда может создать еще больше похожих преимуществ.
Побочный эффект фокусировки на расширении сильных сторон команды — частое
уменьшение количества проблем.
Ката бережливого совершенствования (Lean Improvement kata) — еще один под-
ход, фокусирующийся на долгосрочных препятствиях. Книга Джеспера Боэга Level Up
Agile with Toyota Kata [Boeg2019] — руководство по этому подходу, ориентированное
на программное обеспечение. Она особенно хорошо подходит для устранения пре-
пятствий, мешающих производству высококачественных продуктов.
Опять октябрь. Последний год (см. часть II) ваша команда много работала над раз-
витием свободного владения навыками на уровне поставки и теперь являет собой
слаженный механизм. Никогда вы не получали больше удовольствия от работы, чем
сейчас: все мелкие раздражители и шероховатости, относящиеся к профессиональ-
ной разработке ПО (поврежденные сборки, утомительный поиск багов, тщательный
анализ изменений), ушли в прошлое. Теперь вы можете начать задачу и уже через
несколько часов увидеть ее в эксплуатационной среде.
Вы жалеете только о том, что ваша команда свободно не владела навыками на
уровне поставки с самого начала. Оглядываясь назад, можно сказать, что все было бы
быстрее и проще, но люди хотели, чтобы все было медленно. Что ж, хорошо. Теперь
вы знаете.
Входя в командную комнату, вы видите Валери и Бо, работающих вместе за пар-
ной рабочей станцией. Они оба любят приходить пораньше, чтобы успеть до начала
часа пик. Валери видит, что вы снимаете свой рюкзак, и привлекает ваше внимание.
— Сможешь поработать в паре сегодня утром? — спрашивает она. Она всегда
немногословна. — Мы с Бо работаем над обновлениями в реальном времени, и он
сказал, что у тебя могут быть идеи, как тестировать сетевой код.
Вы киваете:
— Мы с Дунканом вчера включили это в спайк и нашли кое-что многообещающее.
Хочешь поработать в паре или можем втроем организовать мини-группу?
— Можешь поработать в паре с Валери, — Бо встает и потягивается. — Мне нуж-
но сделать перерыв после сетевого кода. — Он притворно вздрагивает. — Даже CSS
лучше, чем это.
Валери закатывает глаза и качает головой.
— Устраивайся, — говорит она вам. — Я пока налью себе еще кофе.
Через полчаса вы с Валери уже достигли неплохого прогресса с сетевым кодом.
Каждый раз, когда вы сохраняете изменения, дежурный скрипт запускает ваши
402 Часть III. Надежная поставка
тесты, а затем, секунду спустя, позвякивает, сообщая, как прошел тест: успешно
или нет.
Вы вошли в устойчивый ритм. В данный момент вы — водитель, а Валери — штур-
ман. «Хорошо, теперь давай сделаем так, чтобы выдавалась ошибка, если сообщение
пустое», — говорит она. Вы добавляете тест. Донг! Тест не прошел. Не останавливаясь,
вы переключаетесь на промышленный код, добавляете оператор if и сохраняете
изменение. Дзинь! Тест проходит. «А теперь, когда сообщение повреждено, — гово-
рит Валери, — вы добавляете строку к тесту». Донг! Еще один оператор if. Дзинь!
«Окей, у меня есть несколько заметок и о других пограничных случаях, — говорит
Валери. — Но я думаю, сначала нам нужно вычистить эти if. Исключение метода
validateMessage() должно помочь». Вы киваете, выделяете код и нажимаете клавишу
Extract Method. Дзинь! Никаких проблем!
Эти звуки — результат эксперимента, проведенного несколько месяцев назад.
Несмотря на шутки о «программистах Павлова», они стали хитом. Ваша команда
работает такими маленькими шагами, что бо́льшую часть времени код делает именно
то, что вы от него ожидаете. Тесты ваших инкрементов занимают меньше секунды,
так что звуки служат мгновенной обратной связью. Вам всего лишь нужно взглянуть
на исполнителя тестов (test runner), когда что-то идет не так. Остальное время вы
остаетесь в области работы, переключаясь между тестами, кодом и рефакторингом,
а перезвон подтверждает, что все в порядке и под контролем.
Еще через полчаса сетевые изменения сделаны. Вы потягиваетесь, пока Валери
извлекает последний код из интеграционной ветки и запускает полный набор тестов.
Через минуту он проходит, и она запускает скрипт развертывания. «Готово! — говорит
она. — Пора выпить еще кофе, последишь за развертыванием?»
Вы снова устраиваетесь в кресле и наблюдаете, как выполняется скрипт разверты-
вания. Он тестирует ваш код на отдельной машине, затем сливает его в общую инте-
грационную ветку. Все в команде сливают свой код из нее и в нее каждые несколько
часов. Это позволяет поддерживать синхронизацию команды и разрешать конфликты
при слиянии на раннем этапе, до того как это превратится в проблему. Затем скрипт
развертывает код на канареечном производственном сервере. Через несколько минут
развертывание подтверждено, и скрипт помечает ваш репозиторий как успешный.
Вы неспешно идете к доске задач и отмечаете сетевую задачу зеленым. «Все сде-
лано, Бо! — зовете вы. — Готов заняться CSS?»
1
Эти списки получены из [Shore2018b].
Часть III. Надежная поставка 403
Источники сотрудничества
Как это обычно бывает на уровне поставки, большинство практик в этой главе
ведут свою родословную от XP1. Практики «Коллективное владение кодом»
и «Парное программирование» пришли напрямую из XP.
Групповое программирование — разновидность парного программирования.
Вуди Зуилл формализовал его в качестве практики, основываясь на собственном
опыте его применения с одной из команд в Hunter Industries. Первоначально
Вуди называл эту практику «Программирование всей командой» (Whole Team
programming), но он использовал название «Групповое программирование» для
похожей активности (из [Hohman2002]), и это название прижилось. Групповое
программирование также известно как программирование в ансамбле (ensemble
programming).
1
Влияние экстремального программирования простирается, конечно, еще дальше. Один из наиболее
заслуживающих внимания предшественников — язык шаблонов Уорда Каннингема EPISODES
[Cunningham1995], включающий множество идей, в том числе парное программирование, которые
позже перешли в XP.
Глава 12. Сотрудничество 407
Коллективное владение имеет большой смысл для организации. Оно снижает риск,
улучшает временной цикл и повышает качество благодаря привлечению к коду боль-
шего количества людей. Но имеет ли оно смысл для программистов? Не осложнит ли
оно еще больше признание вашего вклада?
Если честно, то может… Как обсуждается в подразделе «Измените вредные
кадровые политики» главы 4, Agile требует, чтобы ваша организация признавала
и ценила командный вклад больше, чем индивидуальный героизм. Если в вашей
организации это не так, то коллективное владение кодом может вам не подойти.
Даже если ваша организация ценит командную работу, перестать работать над
большим куском кода нелегко. Может быть трудно справиться с желанием взять на
себя почетную ответственность за особенно умное или элегантное решение.
Но все же это хорошо для вас как для программиста. Почему? Вся кодовая база
в вашем распоряжении — не только для изменений, но и для поддержки и совер-
шенствования. Вы можете расширить ваши технические навыки. Вы узнаете новые
техники дизайна и написания кода, работая с другими членами команды. Обучая
других людей знаниям из вашей экспертной области, вы также можете практиковать
свои навыки наставничества.
Вы также не должны нести бремя технического обслуживания каждого куска
кода, который напишете. Вся команда прикрывает вас. Со временем они будут знать
ваш код так же хорошо, как и вы сами, и вы сможете уйти в отпуск, не ожидая по-
стоянных звонков с вопросами и экстренных ситуаций.
Поначалу немного страшновато приходить на работу и не знать точно, над какой
частью системы вы будете работать сегодня, но это также и освобождает. У вас больше
нет долгих подпроектов, растягивающихся на ночь или на выходные. Вы получаете
разнообразие, вызов и изменения. Попробуйте — вам понравится.
412 Часть III. Надежная поставка
Вопросы
У нас есть действительно хороший фронтенд-разработчик/программист баз данных/
гуру масштабирования. Почему не использовать их навыки?
Пожалуйста, так и делайте! Коллективное владение кодом означает, что каждый
вносит вклад в каждую часть системы, но вам все же понадобятся эксперты, которые
будут задавать тон.
Как может каждый узнать всю кодовую базу целиком?
Людей естественным образом притягивает та или иная часть системы. Они ста-
новятся экспертами в определенных областях. Каждый получает общее понимание
кодовой базы в целом, но все не могут знать всех деталей.
Несколько практик поддерживают
этот подход к работе. Простой дизайн См. также
и его фокус на ясности кода облегча-
ет понимание незнакомого кода. Тесты Простой дизайн (глава 14)
работают как подстраховка и источник Разработка через тестирование (глава 13)
документации. Парное и групповое про-
Парное программирование (глава 12)
граммирование позволяет вам работать
с людьми, разбирающимися в деталях, Групповое программирование (глава 12)
которые не понимаете вы.
Разные программисты в нашей команде отвечают за разные продукты. Должна ли
команда коллективно владеть всеми этими продуктами?
Если вы объединили программистов в одну команду, то да, вся команда должна взять
на себя ответственность за весь свой код. Если у вас несколько команд, то они могут
делить ответственность между командами или не делить в зависимости от вашего под-
хода к масштабированию. В главе 6 можно найти больше информации по данной теме.
Предварительные требования
Коллективно владеть кодом трудно с со-
циальной точки зрения. Некоторым орга- См. также
низациям сложно отказаться от практики
индивидуальных поощрений и ответ- Согласование (глава 7)
ственности. Некоторым программистам Безопасность (глава 7)
трудно избавиться от привычки брать
Командная комната (глава 7)
на себя индивидуальную ответствен-
ность или отказаться от использования Планирование задач (глава 9)
определенного языка программирования. Стендап-митинги (глава 9)
По этим причинам важно поговорить с ру-
ководителями и членами команды о кол- Групповое программирование (глава 12)
лективном владении кодом, прежде чем Парное программирование (глава 12)
пробовать его. Все эти опасения должны
Непрерывная интеграция (глава 13)
стать частью ваших изначальных дискус-
сий о том, пробовать или нет Agile в целом Простой дизайн (глава 14)
(см. главу 5), а потом их следует поднять Разработка через тестирование (глава 13)
снова во время сессии согласования.
Глава 12. Сотрудничество 413
Показатели
Когда ваша команда хорошо практикует коллективное владение кодом:
zz каждый в команде постоянно вносит небольшие усовершенствования во все
части кода;
zz никто не жалуется на то, что члены команды меняют код, не спрашивая разре-
шения перед этим;
414 Часть III. Надежная поставка
Альтернативы и эксперименты
Главные альтернативы коллективному владению кодом — слабое и сильное владение
кодом. Если вы работаете с кодом со слабым владением, то можете изменять любую
часть кода, но хорошим тоном будет согласовать изменения с разработчиками, от-
ветственными за его качество. В случае кода с сильным владением все изменения
делаются только через его владельцев.
Оба эти подхода умаляют присущую Agile сосредоточенность на командной
работе, хотя слабое владение кодом не так плохо, как сильное. Оно может быть по-
лезно командам, которые не используют парное или групповое программирование
или у которых не получается оставлять код в лучшем состоянии, чем они его нашли.
Но если вы можете, то попробуйте применить коллективное владение кодом. Это
одна из тех идей Agile, которую часто упускают из виду, хотя на самом деле она является
одной из главных. Она не всегда означает коллективное владение кодом, но, я думаю,
это важная составляющая равенства. Хотя, вероятно, и можно быть компетентной
командой поставки без коллективного владения кодом, я такого еще не видел. Ис-
пользуйте эту практику, пока не наберетесь опыта как компетентная команда поставки.
ПАРНОЕ ПРОГРАММИРОВАНИЕ
Мы помогаем друг другу добиваться успеха.
Аудитория
Вы бы хотели, чтобы кто-то весь день загля- Разработчики, вся команда
дывал вам через плечо? Вы бы хотели тратить
половину своего времени, сидя в скучной тиши-
не и глядя на чей-то чужой код?
Конечно, нет! К счастью, парное программирование работает не так.
Парное программирование подразумевает работу двух человек за одним компью-
тером в одно и то же время над одним и тем же. Это одна из наиболее противоречи-
вых идей Agile. Два человека работают за одним компьютером? Это странно. И это
также чрезвычайно эффективно и, когда вы привыкаете, доставляет огромное удо-
вольствие. Большинство знакомых мне программистов, которые практиковали
парное программирование в течение месяца, обнаружили, что предпочитают его
программированию в одиночестве.
Что гораздо важнее, парное программирова-
ние — один из наиболее эффективных способов См. также
достижения коллективного владения и под-
Коллективное владение кодом
линного взаимодействия команды в работе над (глава 12)
кодом.
Глава 12. Сотрудничество 415
Почему парное?
Парное программирование — нечто большее, чем обмен знаниями. Помимо этого, оно
улучшает качество ваших результатов. Это потому, что парное программирование
удваивает ваш интеллектуальный потенциал.
Когда вы работаете в паре, один человек является водителем. Он (или она) пишет
код. Второй человек — штурман. Его (или ее) работа — думать. Будучи штурманом,
иногда вы думаете о том, что набирает водитель. (Однако не спешите указывать ему
на пропущенные точки с запятой, это раздражает.) Иногда вы думаете о том, что будет
дальше. А иногда — о том, как ваша работа вписывается в общий дизайн.
Такой порядок позволяет водителю свободно работать над тактическими задачами
по созданию строгого, синтаксически правильного кода, не беспокоясь об общей карти-
не, а штурману дает возможность рассматривать стратегические вопросы, не отвлекаясь
на детали кодирования. Работая вместе, водитель и штурман выполняют работу более
качественно и быстро, чем если бы это делал каждый из них по отдельности1.
Кроме того, парное программирование закрепляет хорошие навыки программи-
рования. Практики поставки требуют много самодисциплины. В процессе парного
программирования вы будете испытывать позитивное давление коллег, побуждающее
вас делать то, что необходимо. Вы также будете распространять знания и рекомен-
дации по кодированию в команде.
Как ни удивительно, вы также будете проводить больше времени в потоке — этом
высокопродуктивном состоянии, в котором вы полностью сосредоточены на коде. Это
другой вид потока, по сравнению с тем, когда вы работаете в одиночку, но он гораздо
более устойчив к прерываниям. Для начала вы обнаружите, что ваши офисные кол-
леги с гораздо меньшей вероятностью отвлекают вас, когда вы работаете с кем-либо.
А когда они это делают, один член пары может заняться тем вопросом, по которому
вас прервали, в то время как другой продолжит работу. Далее вы обнаружите, что
фоновый шум отвлекает меньше: ваши разговоры с вашим партнером по паре будут
удерживать вас в фокусе.
Если этих резонов недостаточно, то могу сказать, что программирование в паре —
это действительно очень весело. Дополнительная умственная энергия поможет вам
легче обойти препятствия. Бо́льшую часть времени вы будете взаимодействовать
с умными людьми, вашими единомышленниками. Вдобавок если у вас устанут
пальцы, то вы сможете передать клавиатуру вашему партнеру и при этом продолжать
быть продуктивным.
1
Одно из исследований обнаружило, что парная работа требует приблизительно на 15 % больше
усилий, чем индивидуальная, но дает результат гораздо быстрее, при этом количество дефектов
уменьшается на 15 % [Cockburn2001]. Все команды разные, так что лучше относиться к этим
результатам с недоверием.
416 Часть III. Надежная поставка
могли сидеть рядом. Обычные офисные кабинки, где монитор расположен в углу,
не подойдут. Они неудобны и требуют, чтобы один человек сидел за спиной у другого,
что добавляет психологические и физические барьеры на пути к тому, что должно
быть сотрудничеством с коллегами.
Вам не нужна роскошная мебель для того, чтобы сделать хорошую парную рабочую
станцию. Подойдет простой стол. Он должен быть шесть футов шириной (примерно
180 см), чтобы два человека могли комфортно разместиться бок о бок. На каждый
стол нужен мощный компьютер. Подключите две клавиатуры и мышь, чтобы у каж-
дого человека был свой комплект. Если у людей есть любимые клавиатура и мышь,
то они могут принести их с собой. На такой случай предоставьте свободный доступ
к USB-портам.
Купите большие мониторы, чтобы обоим участникам пары было все хорошо видно.
Учтите возможную разницу зрения людей, особенно в отношении размеров шрифтов
и цвета. Некоторые команды устанавливают три монитора, при этом два внешних
монитора зеркальны, чтобы каждый человек мог видеть код на мониторе напротив
себя, используя центральный монитор для вспомогательных материалов. Если вы
так делаете, то попробуйте установить утилиту, позволяющую мыши переходить
за границы рабочего стола. Это позволит обоим программистам легко добраться до
центрального экрана.
Если ваша команда работает удаленно, то вам понадобятся совместный редактор
кода и видеоконференция. Предоставьте несколько экранов, чтобы вы могли одно-
временно видеть друг друга и писать код.
Существует множество IDE-надстроек и автономных инструментов для со-
вместного редактирования, таких как CodeTogether, Tuple, Floobits и Visual Studio’s
Live Share. Кроме того, можно совместно использовать экран в программе для
видеоконференций, но инструмент для совместного редактирования позволит вам
переключать водителей гораздо быстрее. Если вам нужно совместно использовать
экран, то вы можете передавать контроль, выкладывая код во временную ветвь
с текущей работой (work-in-progress). Напишите небольшой скрипт для автома-
тизации процесса.
У Джеффа Лангра в [Langr2020] есть хороший обзор вариантов взаимодействия
при удаленном написании кода.
Эффективная навигация
Пребывая в роли штурмана, вы можете испытывать желание вмешаться и за-
брать клавиатуру у вашего партнера. Будьте терпеливы. Ваш водитель часто бу-
дет высказывать свои идеи как словами, так и с помощью кода. Он будет делать
опечатки и небольшие ошибки — дайте ему время исправить их самостоятельно.
Используйте свое свободное время, чтобы подумать об общей картине. Какие еще
тесты вам необходимо написать? Как этот код вписывается в остальную систему?
Есть ли дублирование, которое вы хотите удалить? Может ли код быть более по-
нятным? Может ли общий дизайн быть лучше? Есть ли шероховатости, которые
надо устранить?
Кроме того, уделите внимание потребностям вашего водителя. Людям, которые
не знакомы с IDE или кодовой базой, могут понадобиться конкретные рекомен-
дации. Но постарайтесь удержаться от микроменеджмента. Дайте людям свободу
разобраться самостоятельно, если они этого хотят.
Когда вы — штурман, ваша роль — помогать водителю быть более произво-
дительным. Думайте о том, что будет дальше, и будьте готовы дать рекомендации.
Когда я штурман, мне нравится держать перед собой индексную карточку. Вместо
того чтобы прерывать водителя, когда мне приходит что-то в голову, я записываю
идею на индексную карточку и жду перерыва в работе, чтобы вынести ее на об-
суждение. В конце сессии парного программирования я рву карточку и выбра-
сываю.
Подобным образом, когда возникает какой-то
вопрос, уделите время поиску ответов, прежде См. также
чем водитель продолжит работу. Некоторые
команды держат для этой цели отдельные но- Спайк-решения (глава 13)
утбуки. Если вам нужно больше, чем несколько
минут, то сделайте паузу в кодировании и поищите решение вместе. Иногда лучший
способ это сделать — разделиться, провести исследования, двигаясь параллельными
путями, и затем снова собраться вместе, чтобы поделиться тем, что удалось узнать.
Особенно эффективный подход — спайк-решения.
Хотя у штурмана обычно больше времени на раздумья, чем у водителя, это
не значит, что водитель — бездумный автомат. У него тоже могут быть идеи по ча-
сти дизайна. Поощряйте вашего водителя делиться своими мыслями, и когда у него
Глава 12. Сотрудничество 419
будут идеи на будущее, предложите записывать их. Кроме того, если вы столкнетесь
со сложным вопросом по дизайну, то будет разумным остановить написание кода,
взять доску и потратить немного времени на то, чтобы вместе проработать идеи.
Трудности
Работа в паре поначалу может показаться неудобной или неприятной. Это естествен-
ное чувство, и обычно оно проходит через месяц или два. Ниже описаны несколько
обычных трудностей и способы их преодоления.
420 Часть III. Надежная поставка
Удобство
Стоит повторить: парное программирование перестает быть удовольствием, если
вам неудобно. Когда вы садитесь за работу в паре, займите удобную позу, настройте
и оборудование, чтобы вам было комфортно. Уберите мусор со стола и обеспечьте
достаточно места для ног. Договоритесь с партнером о размере шрифта и располо-
жении монитора. Если вы работаете в паре в удаленном режиме, то перед началом
работы уделите время тому, чтобы убедиться, что весь инструментарий настроен
и работает безупречно.
Некоторым людям (вроде меня) нужно много личного пространства. Другим
нравится расположиться ближе. Когда вы начинаете работать в паре, обсудите ваши
потребности в личном пространстве с партнером и спросите о его запросах.
Стиль коммуникации
Новым водителям иногда бывает трудно вовлекать своих партнеров: они берут под
свой контроль клавиатуру и полностью закрываются от общения. Чтобы попрак-
тиковаться в коммуникации и переключении ролей в парном программировании,
рассмотрите парную работу в стиле пинг-понг. В этом упражнении один человек
пишет тест. Другой выполняет его и пишет новый. Тогда первый человек выполняет
его и пишет новый тест, таким образом повторяя всю процедуру.
Еще один подход — попробовать работу в паре в сильном стиле. В этом подходе,
который изобрел Левелин Фалько, все идеи должны проходить через руки другого
человека [Falco2014]. Поэтому, когда у вас возникает идея, вы должны передать кла-
виатуру другому человеку и объяснить ему, как ее реализовать. Потом, когда у другого
Глава 12. Сотрудничество 421
человека возникает идея, он передает клавиатуру вам и объясняет, что делать. Даже
если вы не хотите делать так постоянно, это отличный способ попрактиковаться
в общении с вашим партнером.
Обратная сторона недостаточного общения — слишком много общения или,
скорее, слишком грубое общение. Откровенная критика кода или дизайна полезна,
но ее может быть трудно оценить поначалу. У разных людей разные пороги чувстви-
тельности, поэтому обратите внимание на то, как ваш партнер воспринимает ваши
комментарии. Попробуйте трансформировать заявления (такие как «Этот метод
слишком длинный») в вопросы или предложения («Не могли бы мы сделать этот
метод короче?»). Примите на вооружение подход совместного решения проблем.
Больше идей вы найдете в пункте «Научитесь принимать и давать обратную связь»
главы 7.
Вопросы
Разве это не расточительно, когда два человека выполняют работу одного?
На самом деле в парном программировании два человека не делают работу одного.
В каждый момент времени используется только одна клавиатура, однако програм-
мирование — это больше чем набор кода. Один человек программирует, а другой
думает наперед, предвидит проблемы и разрабатывает стратегию.
Как мне убедить мою команду или организацию попробовать парное программи-
рование?
Попросите разрешения попробовать это в качестве эксперимента. Запланируйте
месяц, в течение которого все будут работать в парах над рабочим кодом. Сделайте
так, чтобы эксперимент обязательно продолжался целый месяц, поскольку парное
программирование может быть некомфортным первые несколько недель.
Не только попросите разрешения руководства; заручитесь также согласием ваших
коллег по команде. Необязательно, чтобы они полюбили эту идею, пусть хотя бы
не будут против нее.
422 Часть III. Надежная поставка
Предварительные требования
Работа в паре требует комфортной рабочей среды. Большинство офисов просто
не подготовлены к этому. Прежде чем пробовать парное программирование на полный
рабочий день, подготовьте свое физическое пространство. Если у вас виртуальная
команда, то подготовьте соответствующий инструментарий.
Убедитесь, что каждый хочет участвовать, прежде чем начнете эксперимент
с работой в парах. Она вносит большие изменения в рабочие стили программистов,
и вы можете встретить сопротивление. Я обычно стараюсь обойти эту проблему,
попросив людей попробовать месяц или два и потом решить. Если это не срабаты-
вает, то можно попробовать работать парами часть рабочего времени или только
с людьми, которые заинтересованы в этом. Однако я считаю, что парное програм-
мирование работает наилучшим образом, когда вся команда использует его полный
рабочий день.
Групповое программирование, как пра-
вило, менее пугающее, чем парное. Если См. также
люди не хотят пробовать работу в парах, то
Групповое программирование
проверьте, не понравится ли им идея попро- (глава 12)
бовать групповое программирование.
Показатели
Когда ваша команда хорошо работает в парах:
zz вы сфокусированы и вовлечены в работу весь день;
zz вы наслаждаетесь духом товарищества, работая с вашими коллегами по команде;
zz в конце дня вы чувствуете усталость и удовлетворенность;
zz в случаях коротких прерываний один человек разбирается с проблемой, в то
время как другой продолжает работу. Затем они сразу же возвращаются в ра-
бочий режим;
zz улучшается внутреннее качество;
zz знания и советы по написанию кода быстро распространяются среди членов
команды, повышая уровень компетенции каждого;
zz новые члены команды интегрируются в команду быстро и легко.
424 Часть III. Надежная поставка
Альтернативы и эксперименты
Парное программирование — очень эффективный инструмент. За исключением
группового программирования, я не знаю другой техники, которая была бы столь же
эффективна. Сначала освойте парное (или групповое) программирование, прежде
чем экспериментировать с альтернативами.
Когда будете рассматривать альтернативы, не делайте ошибку, думая, что парное
программирование — всего лишь модный способ ревью кода. Чтобы действительно
заменить парное программирование, вам нужно заменить все преимущества, пере-
численные ниже.
Качество кода. Парное программирование привно-
сит в код много разнообразных точек зрения и приво- См. также
дит к множеству разговоров о коде, поэтому снижает
количество дефектов и улучшает качество дизайна. Коллективное владение
Частое переключение пар помогает распространению кодом (глава 12)
знаний среди членов команды, что укрепляет кол-
лективное владение кодом. Совместная работа помогает людям сфокусироваться,
поддерживает самодисциплину и уменьшает отвлекающие факторы. Всего этого
удается добиться, не принося в жертву производительность.
Формальные ревью кода также могут снизить дефекты, повысить качество и под-
держивать самодисциплину. В каком-то смысле парное программирование — это
непрерывное ревью кода. Однако при ревью нельзя делиться знаниями так же под-
робно, как при парной работе, поэтому если вы используете коллективное владение
кодом, то вам, вероятно, понадобится дополнить ревью кода обсуждениями дизайна.
Поток. Парное программирование дает потоку более тонкие преимущества.
Поскольку два человека сосредоточиваются на одной и той же проблеме, при объ-
единении в пару как будто появляется запасной мозг. Если один человек отвлекся,
то другой может «перезагрузить» его внимание и легко вернуть его назад, в нужное
русло. Кроме того, легче игнорировать вездесущие отвлекающие факторы, такие
как смартфоны, электронная почта, мессенджеры и прочие претенденты на ваше
внимание. Там, где не используется парная работа, вам понадобится другой способ
помочь людям оставаться сосредоточенными.
Взаимодействие. Устойчивость парного программирования к прерываниям
упрощает внутрикомандное взаимодействие. В идеале, когда один член команды
застревает на каком-то вопросе, на который может ответить другой член команды,
предпочтительнее, чтобы он обратился за помощью, а не «варился в собственном
соку». Если вы работаете в паре, то ответить на вопрос почти ничего не стоит, по-
скольку ваш партнер продолжает работу. Имеет смысл просить помощи каждый раз,
когда она вам нужна.
Если вы не работаете в паре, то прерывания обходятся гораздо дороже. Тут вы
должны принять решение, стоит ли время, сэкономленное благодаря ответу на во-
прос, прерывания чужого процесса. На практике в команде, не работающей в парном
программировании, гораздо меньше взаимодействия.
Меньше шума и осведомленность о происходящем. У парного программирования
есть еще одно преимущество, менее очевидное. В физической командной комнате при
парной работе возникает негромкий фоновый гул разговоров. Можно ожидать, что
Глава 12. Сотрудничество 425
это отвлекает, но на самом деле этот гул отступает на задний план, так как ваш мозг
фокусируется на взаимодействии с вашим партнером. Но фоновые разговоры все же
повышают вашу осведомленность о ситуации. Это эффект коктейльной вечеринки:
когда кто-то говорит что-то важное для вас, ваше подсознание выхватывает это из
фонового шума и выводит на уровень сознания.
Участников команд, не работающих в паре, сторонние разговоры отвлекают
и мешают концентрации. В этой ситуации отдельные офисы или перегородки-кубики
или наушники могут быть более подходящим вариантом. Но при этом вы не будете
осведомлены о ситуации.
Другими словами, парное программирование имеет множество неочевидных
преимуществ, подкрепляющих другие практики Agile. Оно определенно странное
и может вызывать много вопросов, однако точно стоит того, чтобы приложить уси-
лия и попробовать. Не сбрасывайте его со счетов. Если парное программирование
не подойдет, то попробуйте групповое программирование.
ГРУППОВОЕ ПРОГРАММИРОВАНИЕ
Аудитория
Мы используем идеи всей команды.
Вся команда
В ранние годы экстремального программирования, когда
парное программирование только набирало популярность,
люди подшучивали над ним. «Если работать в паре хорошо, то почему бы и не попро-
бовать втроем! — смеялись они. — Или просто посадить всю команду перед одним
компьютером!»
Они пытались принизить ХР, но Agile — это путь экспериментов, обучения и со-
вершенствования. Вместо того чтобы предполагать, что что-то не будет работать, мы
просто ставим эксперимент. Некоторые эксперименты работают, некоторые — нет.
Так или иначе, мы делимся тем, что узнали.
Именно это и произошло с групповым программированием. У Вуди Зуилла была
групповая обучающая техника, которую он использовал для кодирования додзё. Его
команда в компании Hunter Industries оказалась в затруднительном положении. Они
решили попробовать групповую технику Вуди в реальной работе и посадили всю
команду перед одним компьютером.
426 Часть III. Надежная поставка
Это сработало, и весьма хорошо. Вуди и команда поделились с другими тем, чему
научились. И теперь групповое программирование используется по всему миру.
ПРИМЕЧАНИЕ
В некоторых странах термин «групповое программирование» (mob programming)
имеет неприятный подтекст, поэтому люди называют эту практику «програм-
мирование в ансамбле» (ensemble programming). Оригинальное название, дан-
ное ей Вуди Зуиллом, было «программирование всей командой» (Whole Team
programming). Но он сказал: «Я всегда говорил: мне все равно, как это называется.
Хорошей командной работе стоит учиться, и я предлагаю людям называть это
так, как они хотят»1.
1
Цитата из разговора с Вуди Зуиллом в Twitter (https://oreil.ly/RERXS).
2
Еще один отрывок из разговора с Вуди Зуиллом в Twitter (https://oreil.ly/UWIEK).
Глава 12. Сотрудничество 427
работу точно с того места, где остановился предыдущий водитель. Передавайте работу
таким образом по кругу через всех, кто интересуется программированием.
Динамики команды
Обратите внимание на взаимодействие членов
команды и сделайте так, чтобы голос каждого
был услышан. Установите рабочие соглашения, См. также
сделайте так, чтобы выражать несогласие и обес
покоенность было безопасно для людей, и об- Согласование (глава 7)
ратите внимание на динамики команды. Если Безопасность (глава 7)
кто-то склонен доминировать, то напомните
Динамики команды (глава 11)
ему, что нужно давать высказаться другим; если
кому-то трудно высказываться, то спрашивайте
мнение таких людей.
Когда вы только начинаете использовать групповое программирование, стоит
потратить несколько минут в конце каждого дня на очень короткую ретроспективу.
Сфокусируйтесь на том, что хорошо работало и как делать этого больше. Вуди Зуилл
называет это «включить хорошее».
Энергичная работа
Групповое программирование не должно вас из-
матывать, но быть постоянно окруженным всей См. также
командой может быть несколько утомительным.
Энергичная работа (глава 7)
Позаботьтесь о себе. Вам не нужно быть вклю-
ченным в каждый момент времени.
Одно из преимуществ группового программирования заключается в том, что его
процесс не зависит от каждого. Люди могут выпадать из процесса и возвращаться по
необходимости. Если вам нужен перерыв на кофе или вы хотите просто развеяться,
то сделайте это. Точно так же, если вам нужно проверить свою почту или позвонить
по телефону, вы можете это сделать. Работа будет продолжаться без вас. Кроме того,
вам не нужно согласовывать свои рабочие часы.
Исследование
Все изменения в рабочем коде проходят через
водителя, но когда вы не в этой роли, вы тоже
можете использовать свой компьютер. Если вам См. также
нужно найти какой-либо запрос API, или по-
Спайк-решения (глава 13)
участвовать в параллельном обсуждении идеи
дизайна у доски, или создать спайк-решение, то
вы можете это сделать.
может передаваться по кругу, как и роль водителя. (Мне нравится, когда водитель
становится следующим штурманом.) Его работа состоит в том, чтобы сконцентриро-
вать идеи всех, преобразовав их в конкретное направление для штурмана. Водитель
должен слушать только штурмана, а не всю группу.
Непрограммисты
Каждый в группе может быть водителем, даже люди, не умеющие программировать.
Для непрограммистов возможность развить новые навыки может стать увлекательной
перспективой. Возможно, они не станут экспертами, но узнают достаточно, чтобы
внести свой вклад в общее дело, а обучение роли водителя может улучшить их спо-
собность сотрудничать с программистами.
Помните о необходимости направлять вашего водителя на том уровне, которому
он способен следовать. Непрограммистам поначалу может потребоваться задавать
направление на уровне конкретных комбинаций клавиш, пунктов меню или кликов
мышью.
При этом никто не обязан быть водителем. Некоторые люди в команде могут
считать, что им лучше потратить свое время на какой-либо другой способ помочь
группе. Тестировщик и эксперт в предметной области могут вести сопутствующее
обсуждение примеров заказчика, относящихся к текущей истории. Продакт-менеджер
может отвлечься, чтобы провести интервью с важным стейкхолдером. Интерактивный
дизайнер может работать над персонами пользователей.
Как и во всем остальном, экспериментируйте, меняя уровень вовлеченности лю-
дей, чтобы понять, что лучше всего подходит вашей команде. Но лучше начинайте
с большей вовлеченности, а не с меньшей. Люди часто недооценивают всю силу ко-
мандной работы. Разговор о примерах заказчика, интервью со стейкхолдером или
работа над персоной пользователя может быть чем-то, чему группа учится благодаря
совместной работе.
Вопросы
Групповое программирование действительно эффективнее, чем работа поодиночке
или в парах?
Для новых команд почти наверняка. Эффективность команд зависит от того, на-
сколько хорошо участники знают код и друг друга, а групповое программирование
превосходит все остальные способы приобретения этого знания. Поэтому я реко-
мендую командам начинать с группового программирования (см. подраздел «Ваша
первая неделя» главы 9).
Для уже состоявшихся команд, по моему опыту, парное программирование более
эффективно, чем одиночная работа. Будет ли групповое программирование еще
более эффективно, чем парная работа? Для команд с хорошим командным помеще-
нием и отлично налаженным взаимодействием, возможно, нет. Для других команд,
вероятно, да. Здесь слишком много переменных, чтобы сказать наверняка, поэтому
попробуйте — и узнаете.
Нам бывает трудно помнить о необходимости менять водителей. Что нам
делать?
Если люди забывают о таймере, то попробуйте использовать инструменты типа
Mobster (доступен на http://mobster.cc). Когда время выходит, он гасит экран и во-
дитель вынужден остановиться.
Предварительные требования
Групповое программирование требует разрешения команды и руководства. Помимо
этого, единственным требованием являются комфортная рабочая среда и подходящая
организация групповой работы.
Показатели
Когда ваша команда хорошо работает с практикой группового программирования:
zz вся команда направляет все свои усилия на одну историю за раз, завершая работу
с минимальными задержками и временем ожидания;
zz команда хорошо взаимодействует и работает друг с другом с удовольствием;
zz внутреннее качество улучшается;
zz когда возникает серьезная проблема, команда решает ее, в то время как водитель
продолжает двигаться вперед;
zz решения принимаются быстро и эффективно.
Альтернативы и эксперименты
«Все блестящие умы в одном и том же месте в одно и то же время работают над од-
ним и тем же». Это центральная идея группового программирования. Сверх того,
все детали — на ваше усмотрение. Начните с базовой структуры, описанной здесь,
и ежедневно думайте над тем, что можно улучшить.
Глава 12. Сотрудничество 431
ЕДИНЫЙ ЯЗЫК
Аудитория
Все в нашей команде понимают друг друга.
Программисты
Попытайтесь объяснить бизнес-логику вашей теку-
щей системы экспертам в предметной области. Сможете
объяснить это в понятных им терминах? Сможете избежать программистских жар-
гонизмов, таких как названия структур дизайна, фреймворков, стилей кодирования?
Ваш эксперт в предметной области в состоянии определить потенциальные проблемы
в вашей бизнес-логике?
Если нет, то вам нужен единый язык. Это способ унификации терминов, которые ваша
команда использует в разговоре и коде, чтобы все могли эффективно взаимодействовать.
Результат этого разговора — нечто гораздо большее, чем просто набросок на дос
ке. Он также может стать основой модели предметной области [Fowler2002] (гл. 9)
в вашем коде. Она нужна не для каждой программы, но если ПО вашей команды
подразумевает сложные правила предметной области, то данная модель — эффек-
тивный инструмент разработки.
1
Вот здесь есть пример нот для оркестра: https://oreil.ly/HP5Zp.
434 Часть III. Надежная поставка
Вопросы
Должны ли мы все вместе избегать использования технических терминов? В нашей
предметной области бизнеса не упоминается ничего о GUI-виджетах или базе данных.
Нормально использовать технический язык в тех областях, которые не имеют
отношения к предметной области. Например, возможно, имеет смысл называть под-
ключение к базе данных подключением, кнопку UI — кнопкой.
Как нам документировать наш единый язык?
В идеале вы кодируете свой единый язык в реальном дизайне вашего ПО с по-
мощью модели предметной области. Если это не подходит, то вы можете задокумен-
тировать вашу модель на доске (можно на виртуальной), в общем документе или на
Вики-странице. Однако будьте осторожны: поддержание этого типа документации
в актуальном состоянии требует большого внимания.
Преимущество использования кода для документа-
ции заключается в том, что код не может не отражать См. также
то, что ваше ПО делает на самом деле. С некоторой
долей осторожности вы можете разработать свой код Простой дизайн (глава 14)
так, чтобы он был самодокументированным.
Мы программируем на английском, но это не наш родной язык, и наши эксперты
в предметной области его не используют. Нужно ли нам переводить их термины на
английский, чтобы единообразить с остальным нашим кодом?
На ваше усмотрение. С одной стороны, слова не всегда переводятся напрямую,
поэтому использование языка вашего эксперта в предметной области, вероятно, будет
приводить к меньшему количеству ошибок, особенно если эксперты могут слушать
и участвовать в разговорах программистов. С другой стороны, единообразие может
облегчить другим работу с вашим кодом в будущем.
Если вы решите переводить термины вашего эксперта на английский (или другой
язык), то создайте словарь перевода для слов, которые используете, особенно для
тех, перевод которых затруднен.
Предварительные требования
Если в вашей команде нет ни одного эксперта в пред-
метной области, то вам может быть трудно понять
эту область настолько глубоко, чтобы создать единый См. также
язык. Однако попытки это сделать в данной ситуации
Вся команда (глава 7)
даже еще важнее. Когда у вас есть возможность гово-
рить с экспертом, единый язык поможет вам быстрее
обнаружить недопонимание.
В то же время некоторые проблемы настолько технические, что не касаются знаний
в области, отличной от программирования. Компиляторы и веб-серверы — примеры
из этой категории. Если вы разрабатываете этот вид ПО, то языком программиро-
вания является язык предметной области.
У некоторых команд нет опыта в создании моделей предметной области
и предметно-ориентированных дизайнов. Если это ваш случай, то будьте осто-
рожны. Предметно-ориентированные дизайны требуют изменения мышления,
436 Часть III. Надежная поставка
что может быть непросто. Для начала изучите подраздел «Литература для допол-
нительного чтения» и подумайте о том, чтобы нанять коуча, который поможет вам
в обучении.
Показатели
Когда ваша команда имеет работающий единый язык:
zz вы уменьшаете недопонимание между клиентами и программистами;
zz вы производите код, который легко понимать, обсуждать и изменять;
zz при личном общении с командой в офисе эксперты слышат обсуждения между
представителями предметной области и отдела реализации. Они присоединяются,
чтобы решить вопросы и выявить скрытые допущения.
Альтернативы и эксперименты
Говорить на языке экспертов предметной области — это всегда хорошая идея, но
предметно-ориентированное проектирование — не всегда хороший выбор. Иногда
ориентированное на технологию проектирование более простое. Это чаще всего так,
когда ваши правила предметной области не очень сложные. Однако будьте осторожны:
правила этой области могут быть более сложными, чем кажется на первый взгляд,
и в этом случае ориентированное на технологию проектирование, как правило, имеет
дефекты и высокие затраты на техническое обслуживание. Дальнейшее обсуждение
этого компромисса см. в [Fowler2002].
Другой способ сформировать общее понимание предметной области — исполь-
зовать метод штурма событий (event storming) Альберто Брандолини, который на-
чинается с событий, случающихся в предметной области, а не с имен и отношений
в ее модели. На момент написания этой книги каноническая книга Event Storming
все еще писалась, но на странице https://www.eventstorming.com есть указатели на до-
полнительные ресурсы.
1
Эванс Э. Предметно-ориентированное проектирование (DDD). Структуризация сложных про-
граммных систем.
2
Фаулер М. Шаблоны корпоративных приложений.
ГЛАВА 13
Разработка
Источники разработки
Впервые я столкнулся с практиками, описанными в этой главе, в экстремальном
программировании. Некоторые из них отсутствуют в оригинальных книгах об
XP; вместо этого они упоминались в обсуждениях XP на Вики-страницах Уорда
Каннингема на c2.com.
Практика «Нулевое трение» — это современная версия «Десятиминутной сборки»
в XP.
Практика «Непрерывная интеграция» также пришла из XP. Ее обычно понимают
не совсем верно, поэтому придумывают для нее новые названия (особенно по-
пулярны «магистральная разработка» (trunk-based development) и «непрерывная
поставка» (continuous delivery)), но непрерывная интеграция в том виде, в котором
ее определяет XP, охватывает оба варианта [Beck2004] (гл. 7).
438 Часть III. Надежная поставка
1
Выдержка из спайк-решений на странице https://oreil.ly/QUTY6.
Глава 13. Разработка 439
одной или двух строчек кода, а это значит, вы всегда знаете, где у вас ошибки. Отладка
становится чем-то из прошлого.
Если обратная связь занимает меньше секунды, то она функционально мгновен-
на. Вы вносите изменение, смотрите на отклик и продолжаете работу. Если на это
уходит от одной до пяти секунд, то процесс, по ощущениям, не будет мгновенным,
но все еще приемлемым. Если на все уходит от пяти до десяти секунд, то процесс
будет ощущаться как медленный. Вы начнете испытывать соблазн сгруппировать
изменения. А если обратная связь будет занимать больше десяти секунд, то вы
не сможете продвигаться маленькими шагами, и это будет вас замедлять.
Чтобы достичь секундной обратной свя-
зи, установите скрипт watch, который будет
автоматически проверять ваш код, когда См. также
вы внесете изменение. Внутри скрипта ис-
пользуйте компилятор или линтер, кото- Разработка через тестирование
(глава 13)
рый будет сообщать вам о синтаксических
ошибках, и тесты, которые будут сообщать
о семантических ошибках.
В качестве альтернативы вы можете настроить вашу IDE на проверку синтаксиса
и запуск тестов, а не на написание скрипта. Это может быть простым способом на-
чать работу, хотя в конечном итоге вам придется перейти на скрипт. Если вы начнете
с подхода на основе IDE, то убедитесь, что его конфигурацию можно передать в ваш
репозиторий и использовать всеми в команде. Вам понадобится возможность легко
делиться усовершенствованиями.
Когда вы сохраняете изменения, скрипт (или IDE) должен давать вам немедлен-
ную и недвусмысленную обратную связь. Если все работает, то он должен выдать
сообщение ÎÊ. Если что-то не так, то он должен выдать сообщение FAILED и предо-
ставить информацию, которая поможет вам решить проблему. Большинство людей
настраивает свои инструменты так, чтобы они показывали зеленую полосу в случае
успеха и красную — в случае неудачи. Вдобавок к этому я программирую свои ин-
струменты так, чтобы они издавали какие-либо звуки (один звук для ошибок ком-
пилятора/линтера, другой — для ошибок в тесте и третий — для успешного завер-
шения), но так делаю только я.
По мере расширения вашей кодовой
базы добиться секундной обратной связи См. также
станет труднее. Обычно первый виновник —
скорость тестирования. Сконцентрируйтесь Быстрые надежные тесты (глава 13)
на написании быстрых надежных тестов.
По мере продолжения роста вашей системы скорость сборки (компиляция или
линтинг) станет проблемой. Решение будет зависеть от вашего языка. Поиск в сети
по фразе «ускорить сборку <язык>» поможет вам начать. Обычно это будет под-
разумевать поэтапные (инкрементальные) сборки: кеширование части сборки так,
чтобы перестраивался только код, в который внесли изменения. Чем больше будет
становиться ваша система, тем более креативными вам нужно быть.
В конце концов вам, вероятно, понадобится сконфигурировать две сборки: одну
для быстрой обратной связи и другую для развертывания в эксплуатационную среду.
Глава 13. Разработка 441
Воспроизводимые сборки
Что происходит, когда вы проверяете произвольный коммит из вашего репози-
тория? Скажем, годичной давности. (Попробуйте!) Он все еще работает? А тесты
проходят? Или он требует какой-то эзотерической комбинации из инструментов
и внешних сервисов, которые уже канули в Лету?
442 Часть III. Надежная поставка
Управление зависимостями
Зависимости (dependencies) — это библиотеки и программные инструменты,
которые нужны вашему коду для работы. Сюда входят компилятор или интер-
претатор, среда времени выполнения, пакеты, скачанные из вашего репозитория
пакетов языков, код, написанный другими командами в вашей организации, и т. д.
Чтобы ваша сборка была воспроизводимой, каждому нужно иметь одни и те же
зависимости.
Программируйте вашу сборку так, чтобы обеспечить корректную версию каждой
зависимости. Она может или выдавать ошибку, когда установлена некорректная вер-
сия, или (что предпочтительнее) автоматически устанавливать правильную версию.
Среди инструментов, которые это делают, — Nix, Bazel и Docker. Проверьте также
версию вашего инструмента управления зависимостями.
Простой способ сделать так, чтобы ваше ПО имело корректные зависимости, —
поместить их в ваш репозиторий. Это называется вендорингом (vendoring). Вы можете
смешать два подхода: например, команда с кодовой базой Node.js сделала вендоринг
для своего каталога node_modules, но не сделала Node исполнимым. Вместо этого
они запрограммировали свою сборку так, чтобы она давала сбой, если работала не-
правильная версия Node.
Локальные сборки
Управление зависимостями обеспечивает одинаковую работу вашего кода на любой
машине, но не делает того же для ваших тестов. Ваши тесты должны запускаться
полностью локально, не связываясь через сеть. Иначе у вас, вероятно, будут противо-
речивые результаты, когда два человека делают тесты одновременно, и вы не сможете
тестировать старые версии. Сервисы и данные, от которых они зависят, изменятся,
и тесты, которые раньше проходили, станут сбоить.
То же самое верно для случаев, когда вы запускаете код вручную. Чтобы получать
непротиворечивые результаты и иметь возможность запускать старые версии, все,
от чего зависит код, должно быть инсталлировано локально.
Могут быть какие-то зависимости, которые невозможно запустить локально.
В таком случае вам нужно запрограммировать свои тесты, чтобы они работали неза-
висимо от этих зависимостей, или у вас может не быть возможности воспроизвести
результаты своих тестов в будущем. В подразделе «Моделирование нелокальных
зависимостей» далее в текущей главе описывается, как это сделать.
Глава 13. Разработка 443
Пятиминутная интеграция
Если вы используете непрерывную интеграцию, то будете интегрировать несколько
раз в день. Данный процесс должен быть сверхнадежным и быстрым. Это значит, для
него нужен скрипт. Ваш скрипт должен выдавать успешный или неуспешный результат
в течение пяти минут — максимум десяти.
Пятиминутные результаты на удивле-
ние важны. Пяти минут достаточно для не- См. также
большого перерыва и новой чашки кофе,
пока вы следите за результатами. Десять Непрерывная интеграция (глава 13)
минут — терпимо, но начинает наскучивать.
Больше — и люди начнут работать над другими задачами, пока дожидаются полу-
чения результатов. Далее, если интеграция неуспешна, код останется в подвешенном
состоянии, пока кто-нибудь к нему не вернется. На практике это ведет к системной
интеграции и проблемам сборки.
Не нужно, чтобы скрипт буквально завершался за пять минут, хотя это и жела-
тельно. Вместо этого он должен проверять код и выдавать успешный или неуспеш-
ный результат, прежде чем переходить к более длительным проверкам. В подразделе
«Многоступенчатые интеграционные сборки» далее в текущей главе объясняется,
как это работает.
Большинство команд не могут исполь-
См. также
зовать пятиминутную интеграцию именно
из-за скорости набора тестов. Решение — ис- Быстрые надежные тесты (глава 13)
пользовать быстрые надежные тесты.
КЛЮЧЕВАЯ ИДЕЯ
Контролировать сложность
Часто упускаемый из виду источник трения команд
разработки — сложность их среды разработки. См. также
Стремясь сделать работу быстро, команды вы-
бирают популярные инструменты, библиотеки Простой дизайн (глава 14)
и фреймворки, чтобы решать общие проблемы
разработки.
По отдельности в этих инструментах нет ничего плохого. Но любой длительный
процесс программной разработки должен иметь специализированные инструменты,
и именно здесь быстрый и простой подход начинает подводить. Все эти инструмен-
ты, библиотеки и фреймворки создают огромную когнитивную нагрузку, особенно
когда вам нужно погрузиться в их внутреннее устройство, чтобы заставить слаженно
работать вместе. В конечном итоге все это добавляет трения.
Гораздо важнее оптимизировать затраты на сопровождение, чем на изначальную
разработку, как объяснялось во врезке «Оптимизировать для сопровождения» ранее
в данной главе. Будьте внимательны к сторонним зависимостям, которые вы ис-
пользуете. Выбирая одну из них, думайте не только о проблеме, которую она решает;
думайте о нагрузке на сопровождение, которую добавит эта зависимость, и о том,
насколько хорошо она будет встраиваться в существующие системы. Простой ин-
струмент или библиотека, которые могут вызывать ваши скрипты, будут отличным
вариантом. Сложный «черный ящик» — вероятно, нет.
В большинстве случаев лучше всего обернуть сторонний инструмент или библио
теку в код, который вы контролируете. Задача вашего кода — скрыть базовую
сложность и представить простой интерфейс, адаптированный под ваши потреб-
ности. В подразделе «Сторонние компоненты» главы 14 можно найти дальнейшие
пояснения.
Автоматизировать все
Автоматизируйте любое действие, которое команда выполняет неоднократно. Это
не только снизит трение, но и уменьшит вероятность ошибок. Для начала это озна-
чает пять скриптов:
zz build — использовать компилятор и/или линтер, запускать тесты и сообщать об
успехе или неудаче;
zz watch — автоматически запускать build при изменении файла;
zz integrate — запускать build в среде, идентичной эксплуатационной, и интегри-
ровать свой код;
zz deploy — запускать integrate, затем разворачивать интеграционную ветку;
zz rundev — запускать ПО локально для оценки и тестирования вручную.
Конечно, вы можете использовать любые имена, какие захотите.
Используйте реальный язык программирования для ваших скриптов. Они могут
обращаться к инструментам, часть которых может иметь собственные конфигу-
рационные языки, но организуйте их все с помощью реального кода, которым вы
Глава 13. Разработка 445
Автоматизируйте инкрементно
Совершенствуйте вашу автоматизацию непрерывно и инкрементно (инкрементами),
начиная с самой первой истории. В абсолютно новой кодовой базе это означает, что
вашей первой задачей разработки станет настройка скриптов.
Придерживайтесь простой автоматизации. Поначалу вам не нужны сложные
инкрементные сборки или анализ графов зависимостей. Прежде чем вы напишете
любой код, начните с написания скрипта build, который будет просто отвечать
build OK. И ничего больше! Это как hello world для вашей сборки. Потом напиши-
те скрипт watch, который не делает ничего, кроме запуска build при изменении
файлов.
Когда заработают build и watch, создайте подобным образом пустой скрипт
integrate. Поначалу ему нужно будет только запустить build в первозданной среде
и интегрировать ваш код. В подразделе «Танец непрерывной интеграции» далее
в текущей главе описывается, как это работает.
Когда заработает скрипт integrate, вы готовы конкретизировать build. Напиши-
те ничего не выполняющий код входной точки для вашего приложения. Он может
просто говорить Hello world. Запустите build, чтобы скомпилировать сборку или
выполнить линтинг, потом добавьте управление зависимостями для компилятора или
линтера. Для начала оно может проверять номер версии относительно какой-либо
константы, или вы можете инсталлировать программный инструмент для управле-
ния зависимостями. В качестве альтернативы вы можете использовать вендоринг
для ваших зависимостей.
Далее добавьте инструмент модульного тестирования и неуспешный тест. Не за-
будьте также добавить управление зависимостями для инструмента тестирования.
Пусть скрипт build запустит тест, тот должным образом пройдет неуспешно и выдаст
код ошибки. Далее проверьте, что скрипты watch и integrate корректно обрабатывают
ошибки, и затем дайте тесту пройти успешно.
Теперь вы можете добавить скрипт rundev. Скомпилируйте его, если необходимо,
и запустите ваше ничего не делающее приложение. Сделайте так, чтобы оно автомати-
чески перезапускалось при изменении исходных файлов. Сделайте рефакторинг так,
446 Часть III. Надежная поставка
чтобы скрипты build, watch и rundev не содержали дубликатов кода для наблюдения
за файлами или компиляции.
В конце создайте скрипт deploy. Дайте ему запустить integrate (не забудьте об-
работку сбоев) и затем разверните интеграционную ветку. Начните с развертывания
на промежуточный сервер. Каким будет правильный способ — зависит от вашей си-
стемной архитектуры, но у вас есть только один рабочий файл, так что вам не нужно
ничего сложного. Просто разверните этот один файл и его среду выполнения на одном
сервере. Это так же просто сделать, как использовать scp или rsync.
Для всего более сложного (обработки сбоев, мониторинга, конфигурирования
(provisioning)) нужна история. (Например, «Сайт продолжает работать после ава-
рии».) По мере роста вашей системы автоматизация тоже будет увеличиваться.
ПРИМЕЧАНИЕ
Если вы не выполняете развертывание на сервер, а вместо этого распространяете
инсталляционные пакеты, то создайте с помощью deploy простой дистрибутив-
ный пакет. Начните с пустого пакета, например ZIP-файла, просто содержащего
ваш один рабочий файл и его среду выполнения. Более красивую и удобную
для пользователя установку можно запланировать позже с помощью пользо-
вательских историй.
Вопросы
Как нам найти время на автоматизацию?
Так же, как вы находите время на напи-
сание кода и тестирование: это просто часть См. также
работы, которую нужно делать. Во время игры
Игра в планирование (глава 8)
в планирование, когда вы думаете о размере
каждой истории, добавляйте любые изменения Резерв времени (глава 9)
автоматизации, необходимые для истории.
448 Часть III. Надежная поставка
Предварительные требования
Каждая команда может работать над уменьшением трения. В некоторых языках бы-
страя обратная связь затруднена, но обычно вы получаете значимую обратную связь
о конкретной части системы, над которой работаете в данный момент, даже если это
означает запуск небольшой подгруппы ваших тестов. Быстрая обратная связь очень
ценна, она стоит того, чтобы потратить время и разобраться в ней.
Ваша способность запускать ПО локально может зависеть от приоритетов вашей
компании. В среде, где работает много команд, легко случайно создать систему, ко-
торую нельзя будет запустить локально. Если это ваш случай, то вы все же можете
запрограммировать ваши тесты на локальный запуск, но способ локального запуска
всей системы может быть вне вашего контроля.
Показатели
Когда ваша команда работает с нулевым трением:
zz вы проводите время, занимаясь разработкой, а не программными инструментами,
чек-листами и документацией о зависимостях;
zz вы можете работать очень маленькими шагами, что позволяет вам обнаруживать
ошибки на раннем этапе и тратить меньше времени на отладку;
Глава 13. Разработка 449
zz настройка новой рабочей станции для разработки — всего лишь вопрос клони-
рования репозитория и запуска скрипта;
zz вы можете выполнять интеграцию и развертывание несколько раз в день.
Альтернативы и эксперименты
Разработка с нулевым трением — идеал, к которому должна стремиться каждая ко-
манда. Лучший способ сделать это зависит от вашей ситуации, поэтому не бойтесь
экспериментировать.
Некоторые команды полагаются на свою IDE, а не на скрипты, чтобы обеспе-
чить необходимую автоматизацию. Другие используют большие «доморощенные»
инструментарии со сложными языками конфигурации. Я считаю, что эти подходы
перестают работать, когда потребности команды возрастают. Такие подходы могут
быть удобными вначале, но когда вы продолжаете работу, переключение может стать
болезненным, и будет трудно делать это инкрементно. Будьте скептичны при оценке
сложных инструментов, обещающих покрыть все ваши потребности в автоматизации.
НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ
Мы держим наш последний код готовым
к выпуску. Аудитория
Развертывание vs релиз
В чем разница между развертыванием и релизом? Выполнить развертывание
означает запустить ПО, написанное командой, в работу (обычно скопировав его
на рабочие серверы), но не обязательно активировав его новые функционально-
сти и возможности. Выпустить релиз означает сделать новые функциональности
доступными для использования заказчиком. Для многих команд каждое развер-
тывание одновременно является и релизом, но можно использовать техники,
такие как флаги функций, чтобы сделать развертывание без релиза.
неудачно. Теперь вы должны прервать свою работу, чтобы пойти исправлять ошибку.
Во всяком случае, в теории. Чаще она просто откладывается на потом. В итоге вы
получаете огромный объем просроченной на часы или даже дни работы, имеющий
гораздо более высокую вероятность конфликтов при объединении.
Особенно часто эта проблема касается плохо сконфигурированных CI-серверов.
Ваш CI-сервер должен объединять код в интеграционной ветке только после того,
как сборка выполняется успешно, чтобы интеграционная ветка была заведомо ис-
правной, однако некоторые CI-серверы по определению сначала объединяют код,
а потом запускают сборку. Если код повреждает сборку, то все, кто загружал его из
ветки интеграции, блокируются.
В сочетании с асинхронной интеграцией вы получите ситуацию, когда люди
невольно загружают поврежденный код, а затем не исправляют его, думая, что это
кто-то другой повредил сборку. Ситуация усугубляется, когда ошибки наслаиваются
одна на другую. Мне попадались команды, в которых сборки оставались поврежден-
ными целыми днями.
Лучше сделать конструктивно невозможным повреждение сборки, введя правило
сначала тестировать сборку. И все же лучше использовать синхронную интеграцию.
Когда вы интегрируете, дождитесь успешного завершения интеграции. Если она
неуспешна, сразу исправьте ошибку.
К А Р ГО - К УЛ ЬТ
Инструмент
«Непрерывная интеграция? Что вы имеете в виду, говоря, что
непрерывная интеграция может помочь? У нас уже есть инстру-
мент CI».
Ваш босс разговаривает по телефону с Agile-коучем. Это должен
был быть телефонный отбор кандидатов, но сейчас не очень по-
нятно, кто кого интервьюирует.
458 Часть III. Надежная поставка
Вопросы
Вы говорите, мы должны делать очистку в конце дня, а что, если у меня осталась
незавершенная работа и я не могу сделать интеграцию?
Если вы используете флаги функций и практикуете разработку через тестирова-
ние, то можете делать интеграцию в любой момент по мере прохождения тестов,
которое должно происходить каждые несколько минут. Вы вообще не должны ока-
зываться в ситуации, когда не можете делать интеграцию.
Если работа встала, то хорошей иде-
ей может быть удаление незавершенного
См. также
кода. Если вы часто делаете интеграцию, то
его не должно быть много. Вы справитесь Флаги функций (глава 15)
с работой лучше, если начнете все сначала
Разработка через тестирование
утром, на свежую голову. (глава 13)
Разве синхронная интеграция — это
не потеря времени?
Нет, если ваша сборка такая быстрая, какой должна быть. Это хорошая воз-
можность сделать перерыв и подумать о дизайне, возможностях рефакторинга или
следующих шагах. На практике проблемы, вызванные асинхронной интеграцией,
отнимают больше времени.
Кажется, мы всегда сталкиваемся с конфликтами объединения, когда выполняем
интеграцию. Что мы делаем не так?
Глава 13. Разработка 459
Предварительные требования
Непрерывная интеграция наиболее эф-
фективна в сочетании с синхронной ин- См. также
теграцией, что требует сборки с нулевой
пробуксовкой, для завершения которой Нулевое трение (глава 13)
нужно не более 10 минут. Иначе вам Парное программирование (глава 12)
придется использовать асинхронную Групповое программирование (глава 12)
или многоступенчатую интеграцию.
Разработка через тестирование (глава 13)
Асинхронная и многоступенчатая
интеграции требуют использования CI- Быстрые надежные тесты (глава 13)
сервера, и он должен быть сконфигури-
рован так, чтобы проверять сборку до того, как она объединяет изменения с интегра-
ционной веткой. Иначе, вероятно, в конечном итоге вы получите наслаивающиеся
друг на друга ошибки сборки.
Запросы на слияние кодов не очень хорошо работают в сочетании с непрерывной
интеграцией, поэтому к ревью кода нужен другой подход. Лучше всего подходит
парное или групповое программирование.
Непрерывная интеграция полагается на сборку и набор тестов, которые будут
тщательно тестировать ваш код, желательно с помощью быстрых надежных те-
стов. Разработка на основе тестирования, использующая узкие коммуникативные
(sociable) тесты, — лучший способ достичь этого.
460 Часть III. Надежная поставка
Показатели
Когда вы выполняете интеграцию непрерывно:
zz развертывание и релиз происходят безболезненно;
zz ваша команда имеет мало конфликтов интеграции и запутанных багов интеграции;
zz члены команды могут легко синхронизировать свою работу;
zz ваша команда может делать релиз нажатием кнопки в любой момент, когда за-
казчики в команде готовы.
Альтернативы и эксперименты
Непрерывная интеграция — базовая необходи-
мость для команд, использующих коллективное См. также
владение кодом и эволюционный дизайн. Без нее
Коллективное владение кодом
существенный рефакторинг становится нецелесо- (глава 12)
образным, поскольку вызывает слишком много
конфликтов объединения. Это мешает команде Рефлексивный дизайн (глава 14)
непрерывно совершенствовать дизайн, что необ- Рефакторинг (глава 13)
ходимо для успеха в долгосрочной перспективе. Флаги функций (глава 15)
Самая часто встречающаяся альтернатива
непрерывной интеграции — это ветки функцио-
нальностей, которые регулярно сливаются из интеграционной ветки и интегриру-
ются в нее только тогда, когда каждая функциональность готова.
Хотя ветки функциональностей позволяют вам держать интеграционную
ветку в состоянии готовности к релизу, они обычно не очень хорошо работают
с коллективным владением кодом и эволюционным дизайном, поскольку слияния
в интеграционную ветку слишком редки. Ис-
пользовать флаги функций — лучший способ См. также
держать интеграционную ветку в состоянии
готовности к релизу. Непрерывное развертывание
Эксперименты с непрерывной интеграцией, (глава 15)
которые я видел, предполагают доведение ее
до крайности. Некоторые команды делают интеграцию по мере каждого коммита
(каждые несколько минут) или даже каждый раз, когда проходит тест. Наиболее по-
пулярный эксперимент — непрерывное развертывание, которое попало в мейнстрим
и будет обсуждаться дальше в этой книге.
КЛЮЧЕВАЯ ИДЕЯ
Шаг 1. Подумать
TDD основана на тестировании, поскольку вы начинаете с теста и потом пишете
ровно столько кода, сколько необходимо для его прохождения. Есть поговорка:
«Не пишите никакой рабочий код, если у вас нет неуспешного теста».
Таким образом, вашим первым шагом будет начать несколько странный мысли-
тельный процесс. Вообразите поведение, которое ваш код должен демонстрировать,
а затем подумайте о самой первой части, которая позволит это реализовать. Она
должна быть маленькой. Очень маленькой. Меньше пяти строк кода.
Далее подумайте о тесте (также всего несколько строк кода), который будет
неуспешным, пока не появится именно такое поведение. Подумайте о том, что про-
веряет поведение кода, не реализацию. Пока
интерфейс не меняется, вы должны иметь См. также
возможность изменить реализацию в любой
момент, не меняя тест. Парное программирование
Это самая трудная часть TDD, поскольку (глава 12)
она требует, чтобы вы думали на два шага Групповое программирование
вперед: первый — что вы хотите сделать; (глава 12)
второй — какой тест потребует, чтобы вы Спайк-решения (глава 13)
это сделали. Поможет парное и групповое
464 Часть III. Надежная поставка
программирование. Пока водитель работает над тем, чтобы текущий тест прошел,
штурман думает на опережение, выясняя, какой инкремент и тест должны стать
следующими.
Иногда думать на опережение трудно. Когда это случается, используйте спайк-
решение, чтобы найти подход к проблеме, а затем перестройте его с помощью TDD.
Шаг 5. Повторить
Когда будете готовы добавить новое поведение,
начните цикл сначала. Ключ к успешной TDD —
Если все идет гладко и каждая гипотеза маленькие инкременты и быстрая
совпадает с реальностью, то вы можете «повы- обратная связь.
сить передачу» и делать более крупные шаги.
466 Часть III. Надежная поставка
(Но, как правило, не больше пяти строк кода за раз.) Если столкнетесь с проблемами,
то «понизьте передачу» и двигайтесь меньшими шагами.
Ключ к успешной TDD — маленькие инкременты и быстрая обратная связь.
Каждую минуту или две вы должны получать подтверждение, что двигаетесь в вер-
ном направлении и ваши изменения делают то, чего вы от них ожидаете. Обычно вы
пройдете через несколько циклов очень быстро, затем потратите больше времени на
обдумывание и рефакторинг для новых циклов, потом снова ускоритесь.
К А Р ГО - К УЛ ЬТ
работает на практике. Это удобно? Имеет смысл? Чтобы тест прошел, вы можете
просто жестко закодировать ответ.
2. Вычисления и ветки. Вашего жестко закодированного ответа недостаточно. Какие
вычисления и логика лежат в основе вашего нового кода? Начните их добавлять,
одна ветка и одно вычисление за раз. Сосредоточьтесь на удачном случае: как
будет использоваться код, когда все будет правильно работать.
3. Циклы и обобщение. Ваш код будет часто предусматривать циклы или альтер-
нативные способы использования. Как только вы реализуете основную логику,
добавьте поддержку этих альтернатив, по одной за раз. Скорее всего, вам понадо-
бится сделать рефакторинг логики, которую вы встроили в более общую форму,
чтобы код сохранял чистоту.
4. Особые случаи и обработка ошибок. После того как вы обработаете все успешные
случаи, подумайте обо всем, что может пойти не так. Вызываете ли вы какой-либо
код, который может сгенерировать исключение? Делаете ли вы какие-то предпо-
ложения, которые требуют проверки? Напишите тест для каждого.
5. Утверждения времени выполнения (runtime assertions). В процессе работы вы мо-
жете определить ситуации, которые могут возникнуть только в результате ошибки
программирования, такой как индекс массива, выходящий за его пределы, или
переменная, которая никогда не должна равняться нулю. Добавьте утверждения
времени выполнения для этих случаев, чтобы они быстро вызывали аварийное за-
вершение (см. подраздел «Быстрое завершение с ошибкой» главы 14). Их не нужно
тестировать, так как они являются просто дополнительной страховочной сеткой.
Может оказаться полезной мнемоника ZOMBIES Джеймса Греннинга: про-
тестируйте ноль (Zero), затем один (One), потом много (Many). Пока тестируете,
обратите внимание на границы (Boundaries), интерфейсы (Interfaces) и исключения
(Exceptions), при этом сохраняя код простым (Simple) [Grenning2016].
Пример TDD
Проще всего понять TDD, если смотреть, как кто-либо работает с ней. У меня есть
несколько серий онлайн-видео, демонстрирующих реальную TDD. На момент на-
писания этого текста самая последняя — серия TDD Lunch & Learn. Она состоит из
21 эпизода, охватывающего все: от основ TDD до тяжелых проблем, таких как сетевое
окружение и тайм-ауты [Shore2020b].
Первый из этих примеров использует TDD для создания функции кодирования
ROT-13. (ROT-13 — простой шифр Цезаря, в котором abc становится nop, и на-
оборот.) Это очень простая проблема, но при этом хороший пример того, как даже
небольшие задачи можно разбивать на очень маленькие шаги.
В этом примере обратите внимание на техники, которые я использую в работе
с небольшими инкрементами. Инкременты могут даже казаться смехотворно ма-
ленькими, но это облегчает поиск ошибок и помогает мне быстрее двигаться вперед.
Как я сказал, чем больше у вас опыта в TDD, тем более маленькие шаги вы можете
делать и тем быстрее это позволяет вам идти вперед.
468 Часть III. Надежная поставка
Вычисления и ветви
Подумать. Теперь мне нужно было закодировать основную логику преобразования
ROT-13. В конечном итоге я знал, что хочу перебирать строку в цикле и преобра-
зовывать по одному символу за раз, но это был слишком большой шаг. Мне нужно
было придумать более маленький шаг.
Более маленький шаг — «сконвертировать один символ», но даже это слишком
велико. Помните, чем меньше шаги, тем быстрее вы можете продвигаться вперед.
Глава 13. Разработка 469
Мне нужно было разбить их на еще более маленькие. В итоге я решил просто преоб-
разовать одну прописную букву в соответствующую ей, находящуюся на 13 символов
впереди. Заглавные буквы и цикл после z отложим на потом.
Красная полоса. С помощью таких маленьких шагов было легко написать тест.
it("transforms lower-case letters", function() {
assert.equals(rot13.transform("a"), "n");
});
Моя гипотеза заключалась в том, что тест провалится, ожидая "n", но получив "",
и именно это и случилось.
Зеленая полоса. Сделать так, чтобы тест прошел, было легко:
export function transform(input) {
if (input === "") return "";
Хотя это был маленький шаг, он вынудил меня проработать важный вопрос
конвертации букв в коды символов и обратно, ответ на который мне понадобилось
искать. Небольшие шаги позволили мне решить эту проблему изолированно, что
упростило задачу определить момент, когда я понял правильно.
Сделать рефакторинг. Я не видел никаких возможностей для рефакторинга, по-
этому пришло время снова вернуться в начало цикла.
Повторить. Я продолжил таким же образом, двигаясь маленькими шажками до
тех пор, пока главный алгоритм преобразования букв не был завершен.
1. Строчная буква вперед: a → n (как я только что показал).
2. Строчная буква назад: n → a.
3. Первый символ перед a не сдвигается: ` → `.
4. Первый символ после z не сдвигается: { → {.
5. Заглавные буквы вперед: A → N.
6. Заглавные буквы назад: N → A.
7. Еще пограничные случаи: @ → @ and [ → [.
После каждого шага я просматривал код и при необходимости делал рефак-
торинг. Итоговые тесты показаны ниже. Цифра соответствует шагу. Обратите
внимание, как некоторые шаги привели к новым тестам, а другие расширили
существующий тест:
it("does nothing when input is empty", function() {
assert.equal(rot13.transform(""), "");
});
Рабочий код показан ниже. Проследить соответствие каждого шага коду труднее,
поскольку было выполнено много рефакторинга (больше информации см. в эпизоде 1
в [Shore2020b]), но вы можете видеть, что TDD — итеративный процесс, постепенно
заставляющий код разрастаться.
export function transform() {
if (input === "") return "";
function codeFor(letter) {
return letter.charCodeAt(0);
}
Шаг 7 (тесты остальных пограничных случаев) не привел в результате к ново-
му рабочему коду, но я добавил его, только чтобы удостовериться, что не допустил
ошибок.
Циклы и обобщение
Подумать. До сих пор код обрабатывал только строки, состоящие из одной буквы.
Теперь настало время обобщить его таким образом, чтобы он поддерживал полные
строки.
Сделать рефакторинг. Я понял, что это было бы легче реализовать, если бы
я выделил основную логику, поэтому я вернулся назад на шаг рефакторинга, чтобы
сделать следующее:
export function transform(input) {
if (input === "") return "";
Глава 13. Разработка 471
function transformLetter(charCode) {
if (isBetween(charCode, "a", "m") || isBetween(charCode, "A", "M")) {
charCode += 13;
}
if (isBetween(charCode, "n", "z") || isBetween(charCode, "N", "Z")) {
charCode -= 13;
}
return String.fromCharCode(charCode);
}
function isBetween...
function codeFor...
Я ожидал, что тест провалится, ожидая "nop", а вместо этого получив "n", по-
скольку он смотрел только на первую букву, и именно это и произошло.
Зеленая полоса. Я изменил рабочий код, добавив цикл:
export function transform(input) {
let result = "";
for (let i = 0; i < input.length; i++) {
let charCode = input.charCodeAt(i);
result += transformLetter(charCode);
}
return result;
}
function transformLetter...
function isBetween...
function codeFor...
function transformLetter(charCode) {
if (isBetween(charCode, "a", "m") || isBetween(charCode, "A", "M")) {
charCode += 13;
} else if (isBetween(charCode, "n", "z") || isBetween(charCode, "N", "Z")) {
charCode -= 13;
}
return String.fromCharCode(charCode);
}
function codeFor(letter) {
return letter.charCodeAt(letter);
}
На данном этапе код сделал все, что должен был. Однако читатели, знакомые
с JavaScript, заметят, что код можно подвергнуть дальнейшему рефакторингу и со-
вершенствованию. Я продолжу этот пример в подразделе «Рефакторинг в действии»
далее в текущей главе.
Вопросы
Разве TDD не расточительна?
С ее помощью я работаю быстрее, чем без нее. Я думаю, получив достаточно опыта,
вы тоже будете работать быстрее.
TDD быстрее, поскольку программирование — это не только набор на клавиа-
туре. Помимо этого, в него входят отладка, запуск кода вручную, проверка того, что
изменения работают, и т. д. Майкл GeePaw Хилл называет все эти действия GAK —
Geek At Keyboard. Используя TDD, вы проводите значительно меньше времени за
этими действиями и больше времени занимаетесь интересной работой, связанной
с программированием. Кроме того, вы тратите меньше времени на изучение кода,
поскольку тесты работают как документация и сообщают вам, когда вы делаете
ошибки. Написание тестов требует времени, однако в результате у вас больше вре-
мени на разработку, а не меньше. Видео Хиллса TDD & The Lump of Coding Fallacy
[Hill2018] — отличное и в то же время забавное объяснение этого феномена.
Что мне нужно тестировать при использовании TDD?
Поговорка гласит: «Тестируйте все, что может сломаться». Чтобы определить,
может ли что-то сломаться, я думаю: «Есть ли у меня уверенность, что я делаю это
правильно и что никто в будущем случайно не повредит код?»
На горьком опыте я узнал, что могу сломать практически все, поэтому тестирую
практически все. Единственное исключение — код без какой-либо логики, такой как
простые геттеры и сеттеры, или функция, которая вызывает только другую функцию.
Вам не нужно тестировать сторонний код, если только у вас нет причины не до-
верять ему. Но хорошей идеей будет обернуть этот код в код, который вы можете
контролировать, и проверять тестами, что обертка работает так, как вы хотите, чтобы
она работала. В подразделе «Сторонние компоненты» главы 14 содержится больше
информации об обертке стороннего кода.
Как мне тестировать частные (private) методы?
Начните с тестирования открытых (public) методов. В процессе рефакторинга
часть этого кода перейдет в частные методы, но все еще будет покрываться суще-
ствующими тестами.
Если ваш код настолько сложен, что вам нужно тестировать непосредственно
частный метод, то это хороший признак того, что вам необходим рефакторинг. Вы
можете перенести частную функцию в отдельный модуль или метод объекта, где она
будет открытой, и тестировать ее напрямую.
Как я могу использовать TDD, разрабатывая UI?
TDD особенно трудно применять с пользовательскими интерфейсами, поскольку
дизайн большинства фреймворков UI не учитывает пригодности к тестированию.
Глава 13. Разработка 475
Предварительные требования
TDD — очень ценный инструмент, однако имеет двух- или трехмесячную кривую об-
учения. Его легко применять к игрушечным проблемам, таким как показанная в при-
мере с ROT-13, но перенос этого опыта на более крупные системы требует времени.
Особенно сложно освоить устаревший код, надлежащую изоляцию теста и узкие
интеграционные тесты. В то же время чем раньше вы начнете использовать TDD, тем
раньше разберетесь с ней, поэтому не позволяйте этим трудностям вас остановить.
Так как TDD имеет кривую обучения, будьте осторожны и не беритесь исполь-
зовать ее без разрешения. Ваша организация может увидеть начальное замедление
и отказаться от TDD, не уделив ей достаточно внимания. Точно так же остерегайтесь
становиться единственным пользователем TDD в вашей команде. Лучше всего, если
все согласятся использовать ее коллективно, иначе в итоге вы придете к тому, что
другие члены команды непреднамеренно будут портить ваши тесты и писать не-
дружественный к тестированию код.
476 Часть III. Надежная поставка
Показатели
Когда вы правильно используете TDD:
zz вы тратите совсем немного времени на отладку;
zz вы продолжаете допускать ошибки в программировании, но находите их за минуту
и можете легко исправить;
zz вы полностью уверены, что вся кодовая база выполняет именно то, что от нее
хотели программисты;
zz вы решительно выполняете рефакторинг при любой возможности и уверены, что
тесты найдут любую ошибку.
Альтернативы и эксперименты
TDD занимает центральное место среди практик поставки. Без нее будет трудно
или даже невозможно достичь свободного владения навыками на этом уровне. Наи-
более часто встречающаяся неверная интерпретация TDD, как показывает врезка
«Разгром, основанный на тестах» ранее в данной главе, — сначала спроектировать
код, написать все тесты, а потом написать рабочий код. Этот подход раздражающий
и медленный, и он не дает вам учиться на ходу.
Еще один подход — писать тесты после написания рабочего кода. Это очень трудно
сделать хорошо: код должен быть спроектирован тестируемым, а это сложно сделать,
если вы сначала не напишете тесты. Вдобавок это скучное занятие, вызывающее
стойкое искушение заняться чем-то другим. На практике мне еще не приходилось
видеть, чтобы постфактум-тесты хоть как-то приближались к детализации и качеству
тестов, созданных с TDD.
Даже если эти подходы годятся для вас, TDD — не только тестирование. На са-
мом деле речь идет об использовании очень маленьких, непрерывно проверяемых
гипотез для подтверждения того, что вы на правильном пути и производите вы-
сококачественный код. За исключением TCR Кента Бека, о котором я расскажу
Глава 13. Разработка 477
позже, я не знаю никаких альтернатив TDD, которые позволили бы вам сделать это,
одновременно предоставляя документацию и обеспечивая безопасность, присущие
хорошему набору тестов.
Вместе с тем TDD предоставляет очень много возможностей для экспериментов.
TDD — это один из тех навыков, которым «учишься моментально, а осваиваешь
всю жизнь». Ищите способы, позволяющие применять TDD ко все большему
и большему количеству технологий, и экспериментируйте, уменьшая свои петли
обратной связи.
Кент Бек экспериментирует с идеей, которую он называет TCR: test && commit ||
revert [Beck2018]. Она относится к небольшому скрипту, который автоматически
подтверждает ваш код, если тесты проходят, и возвращает все обратно, если не про-
ходят. Он дает ту же серию проверенных гипотез, что и TDD, и, пожалуй, делает их
еще меньше и более частыми. Это одна из самых сложных и наиболее важных вещей,
которую вы можете узнать о TDD. TCR стоит попробовать в качестве упражнения,
но не более того.
1
Бек К. Экстремальное программирование. Разработка через тестирование. — СПб.: Питер, 2017.
478 Часть III. Надежная поставка
Быстрые надежные тесты полностью все меняют. Они требуют практики и хо-
рошего дизайна, но как только вы узна́ете их секреты, вам будет проще и быстрее
написать именно их, а не медленные нестабильные тесты. Вот как это делается.
Моделирование нелокальных
зависимостей
Некоторые зависимости слишком сложны или дороги, чтобы запускать их на вашей
рабочей машине разработки. Однако вы все же должны иметь возможность запускать
тесты локально для целей как воспроизводимости, так и скорости.
Чтобы решить эту проблему, начните с создания инфраструктурной обертки
для зависимости, как обычно. Затем напишите узкий интеграционный тест скорее
для моделирования зависимости, чем для того, чтобы инфраструктурная оболочка
вызывала его по-настоящему. Например, если ваш код использует биллинговый сер-
вис с REST API, то вы можете написать небольшой HTTP-сервер, чтобы заменить
биллинговый сервис в ваших тестах. Больше подробностей вы найдете в шаблоне
«шпионский сервер» в [Shore2018b], а в эпизодах Microservice Clients Without Mocks
в [Shore2020b] есть пример.
В связи с этим возникает вопрос: если вы не тестируете свое ПО на его реальные
зависимости, то как узнаете, что оно работает? Поскольку внешние системы могут
измениться или сломаться в любое время, реальный ответ — использовать мониторинг
(см. подраздел «Параноидальная телеметрия» главы 15). Но некоторые команды
также используют контрактные тесты (contract tests) [Fowler2011], чтобы обнару-
живать изменения в сервисах провайдера. Лучше всего, когда провайдер обязуется
делать тесты самостоятельно.
480 Часть III. Надежная поставка
1
Термины «коммуникабельные» и «одиночные» ввел Джей Филдс [Fields2015].
Глава 13. Разработка 481
Одиночные тесты позволяют вам проверять, что ваш тестируемый код запрашива-
ет свои зависимости, но не дают возможность проверять, что зависимости работают
так, как ожидает ваш код. На самом деле тест не запускает зависимости; он запускает
тестовый дубль. Так что если вы когда-нибудь внесете изменение в зависимость, ко-
торое нарушит ожидания любого кода, который ее использует, то ваши тесты будут
продолжать проходить и вы случайно внесете баг.
Чтобы предотвратить эту проблему, люди, которые пишут одиночные тесты, вдо-
бавок пишут широкие тесты, чтобы убедиться, что все вместе работает корректно.
Это двойная работа, и эти широкие тесты часто медленные и нестабильные.
На мой взгляд (сообщество разделилось в своих мнениях по этому вопросу),
гораздо лучше использовать коммуникативные тесты вместо одиночных. Комму-
никативный тест запускает тестируемый код, не заменяя его зависимостей. Код ис-
пользует реальные зависимости во время своей работы; это значит, тесты не пройдут,
если зависимости работают не так, как от них ожидает тестируемый код. На рис. 13.2
показана разница.
шага. Упрощайте и совершенствуйте код до тех пор, пока одна часть его не станет
пригодной для тестов, затем добавьте в ней узкие тесты. Вам может понадобиться
сначала добавить одиночные тесты, а не коммуникативные.
Продолжайте улучшать, совершенствовать и тестировать до тех пор, пока весь
код, над которым вы работаете, не будет покрываться высококачественными узкими
тестами. Как только это произойдет, вы можете удалить диагностические и любые
другие тесты этого кода.
Предварительные требования
Если вы пишете тесты, то можете писать бы-
стрые надежные тесты. Однако добавление те- См. также
стов к существующему коду может занимать
Резерв времени (глава 9)
некоторое время. Поможет внедрение практики
резерва времени.
Показатели
Когда вы пишете быстрые надежные тесты:
zz вы не «исправляете» нестабильные тесты, запуская набор тестов снова;
zz ваши узкие интеграционные тесты пропорциональны количеству внешних сер-
висов и компонентов, которые использует ваш код;
zz у вас есть только небольшое количество широких тестов;
zz ваш набор тестов в среднем — 100 тестов в секунду.
Альтернативы и эксперименты
В сообществе Agile есть две точки зрения о том, как создавать хорошие тесты: клас-
сический подход и мок-подход. В этой книге я отметил классический, но мок-подход,
возглавляемый Стивом Фрименом и Натом Прайсом, тоже заслуживает изучения.
Прочитать их книгу, Growing Object-Oriented Software, Guided by Tests, — лучший
способ познакомиться с этим подходом [Freeman2010].
Представители другой точки зрения полностью отказываются от узких тестов
и используют только широкие. Поначалу это быстро и просто, но по мере роста ва-
шего ПО происходят сбои. В итоге вы придете к тому, что будете тратить на тесты
времени больше, чем сбережете.
РЕФАКТОРИНГ
Мы улучшаем дизайн существующего кода.
Аудитория
Код портится. Это все говорят: энтропия не-
Программисты
избежна, и хаос в конце концов превращает ваш
прекрасно задуманный, хорошо спроектирован-
ный код в большой ком спагетти.
Я тоже так думал раньше, до того как научился рефакторингу. Теперь у меня есть
рабочая кодовая база десятилетней давности, которая сегодня лучше, чем была в момент
создания. Я бы не хотел возвращаться в прошлое: с каждым годом база становится
значительно лучше, чем была год назад.
Рефакторинг делает это возможным. Это
процесс изменения дизайна вашего кода без Рефакторинг — это
изменения его поведения. То, что делает код, не переписывание кода.
остается тем же самым, но как он это делает —
меняется. Несмотря на распространенное неверное использование термина, ре-
факторинг — это не переписывание кода. И это не произвольное изменение.
Рефакторинг — это осторожный пошаговый подход к инкрементному улучшению
дизайна вашего кода.
Вдобавок рефакторинги обратимы: правильного ответа нет, поэтому иногда вы
будете делать рефакторинг в одном направлении, а иногда — в другом. Точно так
же, как вы можете изменить выражение x2–1 на (x+1)(x–1) и обратно, вы сможете
изменить дизайн вашего кода — и когда вам это удастся, вы сможете держать энтро-
пию под контролем.
1
Физерс М. Эффективная работа с унаследованным кодом.
486 Часть III. Надежная поставка
Рефакторинг в действии
Чтобы проиллюстрировать этот момент, я продолжу пример, начатый в подразделе
«Пример TDD» ранее в данной главе. Этот пример невелик по причине экономии
места, но он показывает, как большие изменения можно разбить на индивидуальные
рефакторинги. Каждый рефакторинг занимает несколько секунд.
ПРИМЕЧАНИЕ
Чтобы следовать этому примеру, клонируйте git-репозиторий, находящийся по
адресу https://github.com/jamesshore/livestream, проверьте тег 2020-05-05-end
и измените файл src/rot-13.js. Инструкции о том, как запустить сборку, находятся
в файле в README.md.
В конце примера TDD у меня был модуль JavaScript, который выполнял шиф-
рование ROT-13:
export function transform(input) {
if (input === undefined || typeof input !== "string") {
throw new Error("Expected string parameter");
}
result += transformLetter(charCode);
}
return result;
}
function transformLetter(charCode) {
if (isBetween(charCode, "a", "m") || isBetween(charCode, "A", "M")) {
charCode += 13;
} else if (isBetween(charCode, "n", "z") || isBetween(charCode, "N", "Z")) {
charCode -= 13;
}
return String.fromCharCode(charCode);
}
function codeFor(letter) {
return letter.charCodeAt(0);
}
Это изменение можно внести сразу, однако при внесении больших изменений
в реально работающее ПО образуются баги и вы можете попасть в положение, из
которого трудно выбраться. (Такое со мной случалось. При публичной демонстрации
рефакторинга. Ой…) Как в примере TDD, чем лучше вы знаете, как делать рефакто-
ринг, тем меньшие шаги вы сможете делать и тем быстрее будете продвигаться вперед.
Поэтому я продемонстрирую рефакторинг шаг за шагом, безопасным способом.
Начнем с того, что isBetween() принимает значение charCode, не letter. Мне
потребовалось изменить вызывающий его transformLetter(), чтобы он передавал
символьное значение letter . Но в transformLetter() отсутствует символьная
переменная letter. Даже transform() не содержит символьной переменной letter.
Поэтому первое, что понадобилось ввести, — это следующий код:
export function transform(input) {
if (input === undefined || typeof input !== "string") {
throw new Error("Expected string parameter");
}
result += transformLetter(charCode);
}
return result;
}
Тесты снова прошли. Теперь, когда у меня была letter в transformLetter(), я мог
передать ее в isBetween():
function transformLetter(letter, charCode) {
if (isBetween(letter, charCode, "a", "m") ||
isBetween(letter, charCode, "A", "M")) {
charCode += 13;
} else if (isBetween(letter, charCode, "n", "z") ||
isBetween(letter, charCode, "N", "Z")) {
charCode -= 13;
}
Глава 13. Разработка 489
return String.fromCharCode(charCode);
}
function transformLetter(letter) {
let charCode = letter.charCodeAt(0);
if (letter >= "a" && letter <= "m" || letter >= "A" && letter <= "M") {
charCode += 13;
} else if (letter >= "n" && letter <= "z" || letter >= "N" && letter <= "Z") {
charCode -= 13;
}
return String.fromCharCode(charCode);
}
Тесты не прошли! Я забыл, что в ASCII заглавная Z идет перед строчной a. Мне
нужно было сначала нормализовать символ:
function transformLetter(letter) {
let charCode = letter.charCodeAt(0);
if (letter <= "m" || letter >= "A" && letter.toUpperCase() <= "M") {
charCode += 13;
} else if (letter >= "n" && letter <= "z" || letter >= "N" && letter <= "Z") {
charCode -= 13;
}
return String.fromCharCode(charCode);
}
492 Часть III. Надежная поставка
Код был исправлен. Теперь я чувствовал, что будет безопасно удалить вторую
часть оператора if:
function transformLetter(letter) {
let charCode = letter.charCodeAt(0);
if (letter.toUpperCase() <= "M") {
charCode += 13;
} else if (letter >= "n" && letter <= "z" || letter >= "N" && letter <= "Z") {
charCode -= 13;
}
return String.fromCharCode(charCode);
}
(Тест прошел). Тогда я использовал этот код вместо того, чтобы изменять charCode:
function transformLetter(letter) {
let charCode = letter.charCodeAt(0);
let rotation;
if (letter.toUpperCase() <= "M") {
charCode += 13;
rotation = 13;
} else {
charCode -= 13;
rotation = -13;
}
return String.fromCharCode(charCode + rotation);
}
} else {
rotation = -13;
}
return String.fromCharCode(letter.charCodeAt(0) + rotation);
}
function transformLetter(letter) {
const rotation = letter.toUpperCase() <= "M" ? 13 : -13;
return String.fromCharCode(letter.charCodeAt(0) + rotation);
}
ПРИМЕЧАНИЕ
Чтобы увидеть пример последовательного рефакторинга в применении к более
крупной задаче, посмотрите превосходную сессию Эмили Бач по ката Gilded
Rose [Bache2018].
одну часть дизайна в один день, а другую часть — в другой. Это необходимая часть
использования вашего резерва времени для внесения больших изменений и ключ
к успешному дизайну Agile.
Вопросы
Как часто мы должны делать рефакторинг?
Постоянно. Выполняйте небольшие ре- См. также
факторинги в процессе TDD и более серьез-
Разработка через тестирование
ные — в свободное время, за счет резерва (глава 13)
времени. Каждую неделю ваш дизайн дол-
жен становиться лучше, чем за неделю до Резерв времени (глава 9)
этого.
Разве рефакторинг — это не переделка? Разве мы не должны проектировать наш
код правильно с самого начала?
Если бы было можно делать дизайн вашего кода великолепно с самого начала, то
рефакторинг был бы переделкой. Однако, как знает каждый, кто работал с большими
системами, ошибки закрадываются всегда. Даже если нет, потребности вашего ПО
со временем меняются, и ваш дизайн должен быть обновлен соответственно. Рефак-
торинг дает вам возможность постоянного совершенствования.
А что насчет нашей базы данных? Вот она действительно нуждается в улуч-
шении.
Вы можете делать рефакторинг и баз данных. Как и в случае с обычным рефак-
торингом, хитрость заключается в том, чтобы действовать маленькими, сохраня-
ющими поведение шагами. В книге Refactoring Databases: Evolutionary Database
Design [Ambler2006] объясняется, как это делать. Миграция данных занимает много
времени, что требует особых условий развертывания, как описывается в подразделе
«Миграция данных» главы 15.
Как мы можем вносить большие изменения, не конфликтуя с остальными членами
команды?
Регулярно общайтесь и используйте не-
прерывную интеграцию. Прежде чем пред- См. также
принять рефакторинг, который затронет
значительную часть кода, интегрируйте ваш Непрерывная интеграция (глава 13)
существующий код и сообщите людям, что
вы собираетесь делать, затем сразу же повторите интеграцию. Они могут снизить
вероятность конфликтов, копируя ваши изменения, как только вы выполните ин-
теграцию.
Я не могу делать рефакторинг, не повредив множество тестов! Что я делаю
не так?
Ваши тесты должны проверять поведение вашего кода, а не реализацию, а рефак-
торинг должен изменять реализацию, а не поведение. Так что если вы все делаете
правильно, то тесты не должны выходить из строя из-за рефакторинга.
Некоторые рефакторинги меняют сигнатуры функции или метода, но эти из-
менения касаются только интерфейса, а не лежащего в основе поведения. Рефак-
Глава 13. Разработка 495
торинг интерфейса требует изменения всех вызывающих его объектов, в том числе
ваших тестов, но ваши тесты не должны требовать каких-то особых изменений.
Если ваши тесты всегда повреждаются
при рефакторинге или затрудняют изме-
нения интерфейса, это может быть связано См. также
с неправильным использованием тестовых
Быстрые надежные тесты (глава 13)
дублей (таких как объекты-имитации).
Ищите способы улучшить дизайн вашего
теста.
Предварительные требования
Рефакторинг требует хороших тестов и сборки с нулевой пробуксовкой. Без тестов
рефакторинг рискован, поскольку вы не можете с легкостью сказать, не повредили ли
ваши изменения случайно что-нибудь. (Не-
которые IDE предоставляют несколько га-
См. также
рантированно безопасных рефакторингов,
но другие рефакторинги все же требуют Разработка через тестирование
тестов.) Без сборки с нулевой пробуксовкой (глава 13)
обратная связь слишком медленная, чтобы
Нулевое трение (глава 13)
позволять действовать маленькими шагами.
Технически возможно сделать рефакторинг,
но это будет медленно и мучительно.
Кроме того, рефакторинг требует кол- См. также
лективного владения кодом. Любые зна-
Коллективное владение кодом
чительные изменения дизайна потребу- (глава 12)
ют от вас изменения многих частей кода.
Непрерывная интеграция (глава 13)
Коллективное владение кодом дает вам
необходимое разрешение на это. Таким же
образом рефакторинг требует непрерывной интеграции. Без нее слияние кода будет
кошмаром, состоящим из конфликтующих изменений.
Рефакторинг опубликованных интерфейсов (интерфейсов, используемых
кодом за пределами контроля вашей команды) требует осторожного управления.
Вам нужно будет координировать свои действия с каждым, кто использует такие
интерфейсы. По этой причине часто лучше избегать рефакторинга опубликован-
ных интерфейсов.
Некоторые среды программирования, особенно среды с «малым кодом» или «без
кода», могут затруднить рефакторинг. То же самое можно сказать и о высокодина-
мичных стилях программирования, таких как обезьяний патч (monkey-patching)
(код, который переопределяет существующие интерфейсы) или отражение на основе
строк. В таких ситуациях рефакторинг может не стоить затраченных средств, но обя-
зательно учитывайте возросшие затраты на изменения и снижение долговечности,
связанные с отказом от рефакторинга.
Можно, хотя и не часто, тратить слишком много времени на рефакторинг. Вам
не нужно делать рефакторинг кода, который не имеет отношения к вашей текущей
496 Часть III. Надежная поставка
Показатели
Когда вы используете рефакторинг как ежедневную часть вашего инструмента
рия:
zz код постоянно улучшается;
zz вы делаете значительные изменения дизайна уверенно и безопасно;
zz каждую неделю код в чуть лучшем состоянии, чем он был неделю назад.
Альтернативы и эксперименты
Реальных альтернатив рефакторингу не существует. Независимо от того, насколько
тщательно вы проектируете ваш код, в конечном итоге он не будет соответствовать
потребностям вашего приложения. Без рефакторинга эта несогласованность при-
ведет к тому, что вам придется выбирать между необходимостью переписать ПО
ценой огромных затрат и риска или полностью отказаться от него.
Однако всегда есть возможности научиться делать рефакторинг лучше. Обычно
это подразумевает выяснение того, как делать маленькие, безопасные, более надеж-
ные шаги. Продолжайте практиковаться. Я занимаюсь этим 20 лет и все еще учусь
новым трюкам.
1
Фаулер М. Рефакторинг: улучшение проекта существующего кода.
2
Кериевски Дж. Рефакторинг с использованием шаблонов.
3
Эмблер С. В., Садаладж Прамодкумар Дж. Рефакторинг баз данных: эволюционное проектиро-
вание.
Глава 13. Разработка 497
СПАЙК-РЕШЕНИЯ
Мы ставим маленькие изолированные экспери- Аудитория
менты, чтобы обосновать наши решения.
Программисты
Вы, вероятно, заметили, что команды Agile ценят
конкретные данные куда больше, чем домыслы. Столкнувшись с вопросом, не вы-
думывайте ответ — проведите эксперимент! Выясните, как вы можете использовать
данные, чтобы добиться прогресса.
Именно для этого нужны спайк-решения. Спайк-решение, или спайк — это тех-
ническое исследование. Это маленький эксперимент в виде кода, позволяющий
провести исследование и найти решение проблемы. Обычно это занимает меньше
одного дня. Когда у вас есть ответ, спайк удаляется.
ПРИМЕЧАНИЕ
Люди часто путают спайк-решения с «ходячими скелетами»: голым кодом, ко-
торый демонстрирует идею от начала до конца. Это начало производственной
реализации. Спайк же, напротив, сосредоточен лишь на конкретной технической
проблеме и впоследствии удаляется.
Простые вопросы
Если у вас есть вопросы о языке, библиотеках или инструментах, то напишите одну-
две строки кода. Если в вашем языке программирования есть REPL (интерактивное
программирование), то часто это самый быстрый способ получить ответ. Например,
чтобы узнать, может ли JavaScript использовать операторы сравнения для строк, вы
можете открыть консоль браузера:
> "a" < "b"
true
> "a" > "b"
false
> "a" === "a"
True
Сторонние зависимости
Чтобы узнать, как использовать сторонние зависимости, такие как библиотека,
фреймворк или сервис, напишите небольшую автономную программу, которая по-
зволит исследовать, как работает эта зависимость. Не утруждайте себя написанием
промышленного кода — сфокусируйтесь на демонстрации основной идеи. Запустите
из командной строки, жестко закодируйте значения и не используйте ввод данных
от пользователей. Создайте минимально достаточный дизайн и абстракцию, только
чтобы не запутаться.
Что касается сложных зависимостей, таких как фреймворки, то я часто начинаю
с их руководства. Однако в них, как правило, делается акцент на быстром запуске
и работе, а не на том, чтобы помочь вам понять, как работает фреймворк. В них часто
содержится много волшебного инструментария, из-за чего фреймворк сложнее по-
нять, а не проще. Поэтому сделайте собственный пример. Уберите магию, вызывайте
все API вручную и упростите ненужную сложность. Думайте о своих вариантах
использования и демонстрируйте, как они будут работать.
Когда закончите, можете разместить спайк в своем кодовом репозитории, чтобы
он выступал в качестве справочника, пока вы готовите реальную реализацию. (Я ис-
пользую каталог /spikes.) Создав производственную реализацию, вы можете или
удалить спайк, или сохранить на будущее в зависимости от его полезности.
Дизайн-эксперименты
Если у вас есть идея для улучшения дизайна,
но вы не знаете точно, как она сработает, то вы См. также
можете сделать спайк дизайна. Я применяю
Рефлексивный дизайн (глава 14)
этот подход, когда не уверен, что мои идеи
дизайна будут работать так, как я думаю.
Чтобы сделать спайк дизайна, создайте временную одноразовую ветку в вашем
репозитории. В ней вы можете экспериментировать, не беспокоясь о безопасности
рефакторингов или успешности прохождения тестов. Вам даже не нужно, чтобы код
работал правильно. Цель спайка — только поэкспериментировать с идеей дизайна
и посмотреть, как она работает на практике.
Если ваша идея дизайна не работает, то просто удалите ветку. Если она работает,
то вы можете сохранить ее временно, но не объединяйте ее с вашим рабочим кодом.
Переделайте изменение заново, на этот раз позаботившись о рефакторингах и об-
новлении тестов, если это необходимо. Когда закончите, удалите ветку.
Глава 13. Разработка 499
Вопросы
В чем разница между прототипом и спайком?
Понятие «прототип» не имеет строгого определения, но обычно относится к не-
полному или нефункционирующему ПО, которое сделано для имитации конечного
продукта. Прототип часто используют для демонстрации UI или для обучения,
создавая одноразовую версию приложения.
Спайки гораздо более целенаправленны. Они создаются для того, чтобы ответить
на узкий технический вопрос, а не для имитации конечного продукта.
Мы должны работать над спайками в режиме парного или группового програм-
мирования?
На ваш выбор. Спайки не нужно поддерживать в будущем, поэтому даже командам
со строгими правилами парного программирования не требуется писать спайки в парах.
Очень эффективный способ парного или группового программирования при ра-
боте над спайками — когда один человек исследует технологию, а в это время другой
пишет код. Еще один вариант — люди работают отдельно над разными подходами,
500 Часть III. Надежная поставка
Предварительные требования
Избегайте соблазна создать полезные или универсальные программы из своих спай-
ков. Сосредоточьтесь на ответе на конкретный технический вопрос и прекратите
работать над спайком, как только он ответит на этот вопрос. Таким же образом нет
необходимости создавать спайк, когда вы уже хорошо поняли технологию.
Не используйте спайки как предлог увер-
нуться от дисциплинарной разработки на См. также
основе тестирования и рефакторинга. Ни-
когда не копируйте код спайка в рабочий Разработка через тестирование
код. Даже если спайк делает точно то, что (глава 13)
вам нужно, перепишите его, используя TDD, Рефакторинг (глава 13)
чтобы он отвечал вашим стандартам рабо-
чего кода.
Показатели
Когда вы проясняете технические вопросы с помощью хорошо управляемых изо-
лированных экспериментов:
zz вместо того чтобы строить предположения о том, как будет работать ваша про-
грамма, вы проводите эксперимент, который показывает это;
zz сложность вашего рабочего кода не мешает вашим экспериментам.
Альтернативы и эксперименты
Спайк-решения — это техника обучения, основанная на выполнении маленьких
конкретных экспериментов. Некоторые выполняют эти эксперименты в своем рабо-
чем коде, что увеличивает количество возможных ошибок. Если что-то не работает
так, как ожидалось, то не потому ли, что вы неправильно понимаете технологию?
Глава 13. Разработка 501
1
Наиболее часто цитируемый источник — Барри Боэм, у которого есть диаграмма, показывающая
экспоненциальный рост затрат, но она демонстрирует затраты на исправление дефектов по фа-
зам, а не затраты на внесение изменений с течением времени. И, как оказывается, эта диаграмма
неточно отражает лежащие в ее основе данные. Отличную работу по поиску данных проделал
Лорент Боссавит в [Bossavit2013] (гл. 10 и приложение Б).
Глава 14. Дизайн 503
1
Скринкасты доступны по адресу https://www.letscodejavascript.com. Пример с сетевым взаимо-
действием можно найти в эпизодах 370–498 канала.
504 Часть III. Надежная поставка
Это совпадает с моим опытом. В реальном мире каждый новый дизайн повторяет
кривую, показанную на рисунке, вследствие чего внешний вид стоимости изменений
становится похож на «зуб пилы». Общая тенденция, однако, нисходящая. Благодаря
эволюционному дизайну ваш дизайн стабильно улучшается со временем, все больше
и больше упрощая изменения вашего ПО. Улучшения тоже смешиваются: например,
финальным сетевым изменениям пошли на пользу предыдущие изменения дизайна,
которые я внес в код обработки событий фронтенда.
Традиционный дизайн начинается быстро, когда все делается с чистого листа.
Эволюционный дизайн — наоборот: вначале вы все еще нащупываете путь, улучшая
дизайн по мере появления у вашей команды новых идей. Но потом традиционный
дизайн замедляется, а эволюционный ускоряется. Спустя примерно 4–6 недель
в моем случае кривые пересеклись: с кодом, написанным с помощью эволюционно-
го дизайна, проще и быстрее работать, чем с традиционным кодом такого же возрас-
та. И он продолжает улучшаться.
Успешность Agile в долгосрочной перспек-
тиве зависит в первую очередь от эволюцион- Успешность Agile в долгосрочной
перспективе зависит в первую
ного дизайна. Он революционный. И об этом
очередь от эволюционного
мало кто знает. дизайна.
В этой главе содержатся три практики эво-
люционного дизайна.
zz С помощью практики «Инкрементный дизайн» члены команды могут создавать
дизайн одновременно с процессом поставки продукта.
zz Благодаря практике «Простой дизайн» можно создавать дизайны, которые легко
модифицировать и поддерживать.
zz Практика «Рефлексивный дизайн» позволяет непрерывно улучшать существу-
ющие дизайны.
Источники дизайна
Практики в этой главе основаны на подходе экстремального программирова-
ния к дизайну. В дискуссиях, посвященных XP, это называлось эволюционным
дизайном, и это обобщающее понятие я использую здесь. Кент Бек называл
это простым дизайном в первом издании книги по XP [Beck2000a] и поэтапным
дизайном — во втором [Beck2004]. Я использовал оба термина Бека для практик
в этой главе (каждый из них фокусируется на своем аспекте эволюционного
дизайна) и добавил рефлексивный дизайн, который в ранние годы XP назывался
безжалостным рефакторингом.
Детали, которые я обсуждаю в каждой из практик, почерпнуты из множества ис-
точников, как и мой собственный опыт в эволюционном дизайне. Значительное
влияние оказали Мартин Фаулер и «три товарища» XP — Кент Бек, Рон Джеффрис
и Уорд Каннингем.
Глава 14. Дизайн 505
ИНКРЕМЕНТНЫЙ ДИЗАЙН
Аудитория
Мы создаем дизайн в процессе поставки.
Программисты
Команды Agile предъявляют жесткие требования
к своим программистам: каждые неделю или две от
команды ожидают завершения 4–10 историй, ориентированных на заказчика. Каждые
неделю или две заказчики могут пересмотреть текущий план и внести абсолютно
новые истории, не предупреждая заранее. Такой режим устанавливается с самой
первой недели.
Для программистов это означает, что вы должны быть в состоянии реализовы-
вать истории с нуля за одну неделю. Так как план может быть изменен буквально
в любой момент, вы не можете выделить несколько недель на создание проектной
инфраструктуры — эти усилия могут оказаться потраченными впустую, когда план
изменится. От вас ожидается, что вместо этого вы сфокусируетесь на поставке цен-
ных с точки зрения заказчика историй.
Это звучит как рецепт катастрофы. К счастью, инкрементный дизайн позволяет
вам создавать ваш дизайн с помощью инкрементов, маленьких фрагментов, пока вы
выполняете поставку историй.
Обсуждения дизайна не должны быть запрещены ни для кого из тех, с кем вы сей-
час работаете. Обсуждайте в более многочисленных группах так часто, как считаете
необходимым, и используйте любые техники моделирования, которые, по вашему
мнению, будут полезны. (См. пункт «Легко входите в дискуссии и выходите из них»
главы 7.) Поддерживайте неформальный и совместный стиль обсуждения. Хорошо
помогают в этом простые наброски на белой доске.
sendPointerLocation(x, y) {
this._socket.emit(
ClientPointerEvent.EVENT_NAME,
new ClientPointerEvent(x, y).toSerializableObject()
);
}
Уровни дизайна
Инкрементный дизайн происходит на всех уровнях дизайна — как внутри класса
или модуля, так и между классами и модулями, и даже на уровне архитектуры при-
ложения.
На каждом уровне качество имеет склонность улучшаться рывками. Как правило,
вы развиваете дизайн инкрементно, в течение нескольких циклов, по ходу внося
мелкие изменения. Затем что-то подает вам идею нового подхода к дизайну, для
поддержки которого потребуется серия более существенных рефакторингов. Эрик
Эванс называет это прорывом (breakthrough) [Evans2003] (гл. 8).
сначала абсолютно конкретен, зачастую до той степени, когда ответ жестко закодиро-
ван, но затем он постепенно обобщается по мере добавления дополнительных тестов.
Внутри класса или модуля рефакторинги происходят каждые несколько минут, на
шаге «Рефакторинг» цикла TDD. Прорывы могут происходить несколько раз в час,
и их завершение занимает считаные минуты. Например, прорыв случился в конце
подраздела «Рефакторинг в действии» главы 13, когда я понял, что регулярное вы-
ражение позволило мне упростить функцию transformLetter(). Заметьте, что до
этого момента рефакторинги приводили к небольшим стабильным улучшениям.
После прорыва transformLetter() стала кардинально проще.
ПРИМЕЧАНИЕ
Не позволяйте обсуждениям дизайна вылиться в затяжные споры и разногласия.
Следуйте правилу десяти минут: если вы не договорились о направлении раз-
вития дизайна за это время, то попробуйте какой-либо из вариантов и посмотри-
те, как он работает. Если разногласия совершенно непримиримые, то разделитесь
и попробуйте оба варианта в качестве спайк-решений. Ничто не проясняет ва-
риант решения в дизайне так, как работающий код.
для себя. Это нормально. Вы делаете достаточно, пока ваш дизайн в конце недели
оказывается в лучшем состоянии, чем был в начале.
Например, работая над небольшим движком для управления контентом, я начал
с реализации единичного класса Server, который обслуживал статические файлы.
Добавляя поддержку трансляции шаблонов Jade в HTML, я начал с того, что ввел
код, который делал это в Server, поскольку это был самый простой подход. Код стал
выглядеть некрасиво после того, как я добавил поддержку динамических конечных
точек, поэтому я включил области ответственности шаблонов в модуль JadeProcessor.
Это привело к прорыву в том, что статические файлы и динамические конеч-
ные точки могли таким же образом быть добавлены в модули StaticProcessor
и JavaScriptProcessor, и в том, что они все могли зависеть от одного и того же ба-
зового класса SiteFile. Это четко разделило сетевую часть, генерацию HTML и код
для управления файлами.
Архитектура приложения
«Архитектура» — слишком перегруженное слово. В данном случае я говорю о по-
вторяющихся паттернах в коде вашей команды. Не формальные паттерны в смысле
Design Patterns1 [Gamma1995], а повторяющиеся условности, проходящие сквозь всю
вашу кодовую базу. Например, веб-приложения часто реализуются таким образом, что
каждая конечная точка имеет определение маршрута и класс контроллера, а каждый
контроллер часто реализован со скриптом транзакции (Transaction Script)2.
Эти повторяющиеся паттерны воплощают вашу архитектуру приложения. Они
ведут к стабильному и согласованному коду, но при этом являются формой дубли-
рования, что усложняет внесение изменений в архитектуру. Например, изменение
подхода в веб-приложении с помощью скриптов транзакций на использование модели
предметной области требует обновления каждого контроллера конечных точек.
ПРИМЕЧАНИЕ
Здесь я сосредоточусь на архитектуре приложения, что конкретно подразуме-
вает код, которым управляет ваша команда. Есть также системная архитектура,
которая подразумевает все компоненты вашего развернутого ПО, такие как
сторонние сервисы, сетевые шлюзы, маршрутизаторы и т. д. Чтобы понять, как
применить идеи эволюционного дизайна к системной архитектуре, см. подраз-
дел «Эволюционная системная архитектура» главы 15.
1
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Паттерны объектно-ориентированного проектиро-
вания. — СПб.: Питер, 2021.
2
Узнать о сценарии транзакции и архитектуре модели предметной области можно из [Fowler2002]
(гл. 9).
510 Часть III. Надежная поставка
Вопросы
Разве инкрементный дизайн не дороже, чем предварительный?
По моему опыту, как раз наоборот. На это есть две причины. Во-первых, инкре-
ментный дизайн реализует только код, достаточный для выполнения вашей текущей
истории, так что инкрементный дизайн позволяет вам начинать поставку гораздо
быстрее. Во-вторых, когда будущая история меняется, вы ничего не пишете для ее
поддержки, так что не тратите усилия напрасно.
Даже если бы требования никогда не менялись, инкрементный дизайн все же
был бы эффективнее, поскольку он ведет к регулярным прорывам в дизайне. Каж-
дый прорыв позволяет вам увидеть новые возможности, которые в конечном итоге
приводят к новым прорывам. Это продолжающаяся серия прорывов существенно
улучшает ваш дизайн.
Разве прорывы не оказываются напрасными усилиями, когда вам приходится воз-
вращаться назад?
В реальности вы не возвращаетесь назад. Иногда прорыв будет приводить вас
к радикально более простому дизайну, который может ощущаться как возврат,
но на самом деле это не так. Если бы вы могли подумать о более простом подходе
раньше, то сделали бы это. Простота трудно дается, и вам понадобится выполнять
свой дизайн итерациями, чтобы ее добиться. Природа прорывов, особенно на уровне
класса и архитектурном уровне, состоит в том, что обычно вы их не видите, пока
не поработаете немного со своим текущим дизайном.
Наша организация (или заказчик) требует проектную документацию. Как нам
выполнить это требование?
Если вы можете убедить вашу организацию подождать, то сможете предоставить ей
исполнительно-техническую документацию (см. пункт «Исполнительно-техническая
документация» главы 8). Ее проще создать и она более точная, чем предварительная
документация. И так как она создается после того, как вы сделали релиз, то вы можете
сделать релиз раньше. Дешевле, лучше и быстрее? Это может быть убедительно.
Если нет, то единственный способ предоставить предварительную документа-
цию — это заняться предварительным дизайном, а также, вероятно, предваритель-
ным анализом требований. Однако вам не нужно включать в дизайн абсолютно
все. Вашим стейкхолдерам, возможно, нужно, только чтобы вы подтвердили опре-
деленную часть документации дизайна с целью координации с другой группой или
в целях управления. Поработайте с ними над определением минимума, для которого
необходим предварительный дизайн, а потом используйте инкрементный дизайн
для всего остального.
514 Часть III. Надежная поставка
Предварительные требования
Инкрементный дизайн требует самодис-
циплины, готовности к постоянному еже- См. также
дневному совершенствованию и стремления
к высококачественному коду. И, конечно, Парное программирование (глава 12)
навыка применять все это в нужное время. Групповое программирование
Эти качества присущи не всем. (глава 12)
К счастью, вам и не нужно, чтобы они Коллективное владение кодом
были присущи всем. По моему опыту, ко- (глава 12)
манды хорошо справляются, даже если все- Энергичная работа (глава 7)
го один человек обучает остальную ее часть
использованию инкрементного дизайна. Резерв времени (глава 9)
Однако вам понадобятся практики парного
или группового программирования, коллективного владения кодом, активной ра-
боты и резерва времени в качестве механизмов поддержки. Они помогают с само-
дисциплиной и позволяют людям, которые страстно увлечены качеством кода,
влиять на весь код.
Инкрементный дизайн зависит от про-
стого и рефлексивного дизайна. Важна и раз- См. также
работка через тестирование. Четкие шаги
рефакторинга, повторяемые каждые несколь- Простой дизайн (глава 14)
ко минут, позволяют людям постоянно оста- Рефлексивный дизайн (глава 14)
навливаться и вносить улучшение в дизайн. Разработка через тестирование
Парное и групповое программирование также (глава 13)
помогает в этом, гарантируя, что по меньшей Командная комната (глава 7)
мере половина программистов команды,
будучи в роли штурманов, всегда имеет воз- Согласование (глава 7)
можность думать об улучшениях дизайна.
Убедитесь, что ваша команда может свободно общаться, находясь в общей ко-
мандной комнате, физической или виртуальной, если вы используете инкрементный
дизайн. Без постоянного обсуждения межмодульных, межклассовых и архитектурных
рефакторингов ваш дизайн будет фрагментироваться и разваливаться. Договоритесь
о стандартах кодирования при изначальном процессе согласования, чтобы все сле-
довали одним и тем же паттернам.
Все, что затрудняет постоянное совершенствование, затрудняет и инкрементный
дизайн. Один из примеров — опубликованные интерфейсы; так как их трудно изме-
нить после опубликования, поэтапный дизайн обычно непригоден для интерфейсов,
используемых третьими сторонами, если только вы не имеете возможности изменять
сторонний код. (Но вы можете использовать инкрементный дизайн для внедрения
этих интерфейсов.) Точно так же любой язык или платформа, которые осложняют
рефакторинг, не позволят вам использовать поэтапный дизайн.
И наконец, некоторые организации ограничивают возможности команд исполь-
зовать инкрементный дизайн. Это организации, требующие предварительную про-
ектную документацию или имеющие жестко контролируемую схему базы данных.
В этих ситуациях инкрементный дизайн может быть непригоден.
Глава 14. Дизайн 515
Показатели
Когда вы правильно применяете поэтапный дизайн:
zz с каждой неделей возможности ПО и дизайн улучшаются в равной мере;
zz вам не нужно пропускать истории в течение недели или больше, чтобы сфокуси-
роваться на рефакторинге или дизайне;
zz каждую неделю качество ПО становится лучше, чем было неделю назад;
zz со временем поддерживать и расширять ПО становится все проще и проще.
Альтернативы и эксперименты
Если вам не нравится идея инкрементного дизайна, то вы можете застраховать свои
ставки, скомбинировав его с предварительным. Начните с фазы предварительного
дизайна, затем полностью перейдите на инкрементный. Хотя это отложит начало
вашей первой истории и может потребовать некоторой работы над предварительными
требованиями, у данного подхода есть преимущество. Он обеспечивает страховочную
сетку, не подвергая слишком большому риску.
Это не говорит о том, что инкрементный дизайн не работает, — он работает!
Но если вам с ним некомфортно, то вы можете застраховать свои ставки, начав с пред-
варительного дизайна. Именно так я научился доверять инкрементному дизайну.
Другие альтернативы инкрементному дизайну менее успешны. Широко извест-
ный подход — рассматривать Agile как серию мини-водопадов, выполняя неболь-
шой объем предварительного дизайна в начале каждой итерации. К сожалению,
эти сессии дизайна слишком короткие и маленькие, чтобы самостоятельно создать
целостный дизайн. Качество кода будет постепенно деградировать. Лучше освоить
инкрементный дизайн.
Другая альтернатива — использовать предварительный дизайн, не применяя инкре-
ментный. Это хорошо работает только в том случае, если ваши планы не меняются,
что противоречит обычному стилю работы Agile-команд.
Сначала освойте инкрементный дизайн, прежде чем экспериментировать. Как
только это произойдет, посмотрите, насколько далеко вы можете продвинуться благо-
даря ему. Не просто уменьшайте долю своего предварительного дизайна; уменьшите
также количество предположений в дизайне, которые вы мысленно делаете. Каково
минимальное количество предположений о дизайне, которым вы можете обойтись?
Найдите предельные возможности инкрементного дизайна.
КЛЮЧЕВАЯ ИДЕЯ
Простота
Простота — искусство минимизации лишней работы — крайне необходима.
Манифест Agile для разработки
программного обеспечения
Agile — это результат стремления к простоте. Это касается не только дизайна ПО,
но и всех аспектов вашей работы. Как можно упростить большие тяжеловесные
процессы? Что мы можем убрать из того, что люди воспринимают как должное?
Глава 14. Дизайн 517
toNumber() {
return this._amount;
}
equals(currency) {
return this._amount === currency._amount;
}
}
Поначалу это кажется расточительством. Это всего лишь простая обертка поверх
базового типа данных, но теперь еще и с дополнительными накладными расходами.
И не только это. Кажется, что она повышает сложность, добавляя еще один класс.
Но подобные простые типы данных оказываются чрезвычайно эффективными
в реализации принципа «однажды и только однажды». Теперь любой код, имеющий
отношение к валюте, имеет очевидное место пребывания: внутри класса Currency.
Если кто-то захочет добавить новый код, то сначала заглянет туда, чтобы проверить,
не существует ли он уже. И когда что-то в концепции (например, конвертацию ино-
странной валюты) нужно изменить, есть одно очевидное место, где это следует делать.
Альтернатива не очень привлекательная. Что происходило с тем интернет-мага-
зином? Как оказалось, математика с плавающей запятой была не очень хорошим
выбором. Программисты попали в ситуацию, в которой при возврате позиции, вклю-
чающей конвертацию валюты, они не могли сгенерировать возмещение, совпадающее
1
Спасибо Эндрю Блэку за эту идею.
Глава 14. Дизайн 519
с изначальным счетом. (Упс.) Им пришлось много месяцев искать все, что имело
отношение к валюте, и изменять его таким образом, чтобы использовать математику
с фиксированной запятой. Реальная история.
Держу пари, они хотели бы, чтобы Currency был выражен один раз. (И только
один.) Они могли бы изменить реализацию своего класса Currency, и на этом все.
Когда (а не если) вам понадобится изменить какое-либо решение в дизайне, на-
сколько трудно это будет?
Связанность и сплоченность
Связанность и сплоченность (Coupling and cohesion) — древние идеи дизайна ПО,
восходящие к Structured Design: Fundamentals of a Discipline of Computer Program and
Systems Design [Yourdon1975] (гл. 6–7). Они не стали ничуть менее влиятельными,
несмотря на свой возраст. Оба термина относятся к взаимоотношениям между кон-
цепциями в вашем коде1.
Части вашего кода связаны (coupled), когда изменение в одной части делает не-
обходимым изменение в другой. Если продолжить пример с классом Currency, то
функция преобразования валюты в строку связана с типом данных, используемых
для валюты.
Ваш код сплоченный (cohesive), когда физически находится близко друг к другу
в исходных файлах. Например, если бы функция преобразования валюты в строку
находилась в классе Currency вместе с основным типом данных, то они были бы вы-
сокосплоченными. Если бы функция была в модуле утилиты в совершенно другом
каталоге, то они бы имели низкую сплоченность.
Хороший код имеет низкую связанность. Другими словами, изменение кода для
одной концепции не требует, чтобы вы изменили код для любой другой концепции:
изменение типа данных Currency не требует изменения кода аутентификации или
логики процесса возмещения средств. В то же время, когда две части кода связаны,
лучше всего, если они высокосплоченные: если вы меняете тип данных Currency, то
все остальное, что вам нужно изменить, находится в том же самом файле или, по
крайней мере, в том же самом каталоге.
Когда вы принимаете решение по дизайну, отступите на миг от паттернов дизай-
на и архитектурных принципов и языковых парадигм. Задайте себе вопрос: когда
(а не если) кто-то изменит этот код, будут ли очевидны другие вещи, которые нужно
изменить? Ответ сводится к связанности и сплоченности.
Сторонние компоненты
Сторонние компоненты (библиотеки, фреймворки и сервисы) — общая причина про-
блем с дизайном. Они распространяются по всему вашему коду. Когда (не если) вам
понадобится заменить или обновить компонент, изменения могут быть сложными
и чреваты последствиями.
Чтобы предотвратить эту проблему, изолируйте сторонние компоненты за интер-
фейсом, который находится под вашим контролем. Вместо того чтобы использовать
1
Я слегка обновил определения. Оригинальное определение обсуждало модули, а не концепции.
520 Часть III. Надежная поставка
компонент напрямую, ваш код будет использовать интерфейс. Это называется шлюз,
но я употребляю более общий термин обертка.
Обертка делает ваш код устойчивым к изменениям в сторонних компонентах
и, помимо этого, может также представлять интерфейс, адаптированный под ваши
потребности, а не имитировать сторонний. При необходимости вы также можете
расширить его с помощью дополнительных функциональностей.
Например, когда я писал обертку для биллингового сервиса Recurly, я не по-
казал метод для конечной точки subscriptions Recurly. Вместо этого я написал
isSubscribed(). Он обращался к конечной точке, разбирал ее XML, делал цикл по
подпискам и конвертировал множество возможных флагов статусов подписок в про-
стой результат булевой логики.
Создавайте вашу обертку инкрементно. Вместо того чтобы поддерживать каждую
функциональность компонента, который вы обертываете, поддерживайте только то, что
вам нужно сегодня, фокусируясь на предоставлении интерфейса, который соответствует
потребностям вашего кода. Это удешевит создание обертки и облегчит изменение, когда
(не если) вам понадобится заменить основной компонент в будущем.
Некоторые компоненты (особенно фреймворки) хотят «владеть миром», и их
трудно спрятать за оберткой. По этой причине я предпочитаю создавать свой код,
используя простые библиотеки с узко определенными интерфейсами вместо одно-
го большого делающего все фреймворка. Однако в некоторых случаях фреймворк
все же будет лучшим вариантом.
Можно обертывать и фреймворк, но при таком варианте обычно больше проблем,
чем пользы. Обычно вы в итоге приходите к необходимости обертывать целый на-
бор разных классов. В некоторых случаях вам придется обертывать базовые классы
фреймворка, что вы можете сделать, написав собственные базовые классы, расши-
ряющие базовые классы фреймворка.
В качестве альтернативы вы можете решить не использовать обертку для сторонне-
го компонента. Это имеет смысл, когда компонент широко распространен и стабилен,
такой как фреймворки основного языка. Вы можете принимать решение в каждом
конкретном случае: например, я буду использовать класс .NET String напрямую,
без обертки, но буду использовать обертку, чтобы изолировать криптографические
библиотеки .NET, — не потому, что думаю, что они будут меняться, а потому, что они
сложные, а обертка позволит мне спрятать и централизовать эту сложность.
fast). Оно позволяет вам писать более простой код: вместо того чтобы обрабатывать
все возможные случаи, вы пишете свой код так, чтобы он обрабатывал только те слу-
чаи, которые нужно. В любом другом случае работа быстро завершится с ошибкой.
Например, ваш метод рендеринга валюты может быстро завершиться с ошибкой,
когда его запросят отобразить валюту, отличную от американской.
Чтобы быстро завершать работу с ошибкой, напишите утверждение времени
выполнения. Это строка кода, которая проверяет условие и выбрасывает исключе-
ние (обычно это зависит от языка), когда условие не выполняется. Оно похоже на
тестовое утверждение, но является частью вашего рабочего кода. Например, версия
метода рендеринга валюты JavaScript может иметь такое утверждение:
if (currency !== Currency.USD) {
throw new Error("Currency rendering not yet implemented for " + currency);
}
Самодокументируемый код
Простота в глазах смотрящего. Не так важно, чтобы вы думали, что дизайн простой.
Если остальная часть вашей команды (или те, кто в будущем будет поддерживать
ваше ПО) сочтет его слишком сложным, значит, это так и есть.
Чтобы этого не случилось, используйте общие для вашего языка и команды
идиомы и паттерны. Можно вносить новые идеи, но сначала обсудите их с другими
членами команды.
Имена — один из ваших наиболее эффективных инструментов написания
самодокументированного кода. Постарайтесь использовать имена, которые ясно
отражают смысл переменных, функций и т. д. Когда функция содержит много из-
меняющихся частей, применяйте рефакторинг «Извлечение функции» (Extract
Function refactoring) [Fowler2018] для наименования каждой части. Когда условное
522 Часть III. Надежная поставка
Опубликованные интерфейсы
Опубликованные интерфейсы снижают ваши возможности вносить изменения. Как
только интерфейс опубликован для людей, не входящих в вашу команду, изменение
этого интерфейса, как правило, требует больших затрат и усилий. Вам нужно быть
осторожными, чтобы не повредить то, на что полагаются эти люди.
Некоторые команды подходят к дизайну таким образом, что каждый публичный
метод также является опубликованным интерфейсом. Этот подход подразумевает, что
публичный метод, определенный однажды, не должен меняться никогда. Откровенно
говоря, это плохая идея: она мешает вам улучшать ваш дизайн со временем. Лучший
подход — менять неопубликованные интерфейсы при необходимости, обновляя со-
ответствующим образом то, что к ним обращается.
Если ваш код используется кем-то за пределами вашей команды, то вам нужны
опубликованные интерфейсы. Каждый из них представляет собой обязательство
на принятие в дизайне решения, которое вы можете захотеть поменять в будущем,
поэтому минимизируйте количество интерфейсов, которые вы опубликовываете.
Для каждого из них решите, стоит ли польза понесенных затрат. Иногда это будет
стоить того, но это решение, которое нужно принимать осторожно. Откладывайте
решение как можно дольше, чтобы дать дизайну усовершенствоваться и устояться.
В некоторых случаях, как с командами, создающими библиотеку для использо-
вания третьими сторонами, вся цель продукта — предоставление опубликованного
интерфейса. В этом случае проектируйте ваш интерфейс осторожно, заранее, а не
Глава 14. Дизайн 523
Оптимизация производительности
Современные компьютеры сложны. Даже чтение единичной строки файла с диска
требует координации процессора, множества уровней кеша процессора, ядра опера-
ционной системы, виртуальной файловой системы, системной шины, контроллера
жесткого диска, кеша жесткого диска, буферов операционной системы, системных
буферов и вычислительного конвейера. Каждый компонент существует, чтобы решать
проблему, и у каждого есть определенные хитрости, позволяющие повысить произ-
водительность. Данные в кеше? В каком кеше? Как согласована память? Вы читае-
те асинхронно или блокируете?
Другими словами, ваше предположение
о производительности почти всегда будет Ваше предположение
ошибочным. Приемы оптимизации на базе о производительности почти всегда
двадцатистрочных тестов производительно- будет ошибочным.
сти не помогут. Единственный способ опти-
мизировать современные системы — использовать комплексный подход. Вы должны
измерить реальную производительность кода, найти критические места и начать с них.
Не гадайте. Не делайте предположений. Просто профилируйте код.
Конкатенация строк, вызовы функций и упаковка/распаковка (то, что восприни-
мается как нечто затратное) — обычно не проблема. Большую часть времени на вашу
производительность будут влиять сеть, база данных или файловая система. Если
нет, то, скорее всего, это будет квадратичный алгоритм. В редких случаях это будет
конфликт потоков или непоследовательный доступ к памяти внутри замкнутого
цикла. Но единственный способ убедиться — измерить реальную производитель-
ность. Не гадайте. Профилируйте, профилируйте, профилируйте.
А пока не обращайте внимания на то, что вы услышите о приемах оптимизации.
Когда (не если) вам понадобится изменить ваш код (по любой причине), будет про-
ще это сделать, если он простой и понятный.
Вопросы
Что, если мы знаем, что нам понадобится одна из историй? Разве мы не должны
встроить хук для нее в дизайн?
Ваши планы могут измениться в любой момент. Если история не является частью
вашей работы на текущую неделю, то не встраивайте хук. История может исчезнуть
из плана, оставив вас разбираться с ненужной сложностью.
524 Часть III. Надежная поставка
Что еще более важно, эволюционный дизайн на самом деле снижает стоимость
изменений со временем, так что чем дольше вы подождете, чтобы сделать изменение,
тем дешевле оно обойдется.
Что, если игнорирование истории усложнит ее реализацию в будущем?
Если игнорирование потенциальной истории может ее усложнить, то ищите спо-
собы устранить этот риск, обойдясь без кодирования поддержки для этой истории.
Больше информации вы найдете в подразделе «Архитектура на основе риска» ранее
в текущей главе.
Предварительные требования
Простой дизайн требует непрерывного со-
вершенствования с помощью рефакторинга, См. также
рефлексивного и инкрементного дизайна.
Без них ваш дизайн не сможет развиваться Рефакторинг (глава 13)
вместе с вашими требованиями. Рефлексивный дизайн (глава 14)
Не используйте простой дизайн в каче- Инкрементный дизайн (глава 14)
стве предлога для плохого дизайна. Про-
стота требует тщательного обдумывания.
Не делайте вид, что «простой» означает код, См. также
который проще или быстрее реализовать.
Коллективное владение кодом и парное Коллективное владение кодом
или групповое программирование, хотя и не (глава 12)
строго обязательны для простого дизайна, Парное программирование (глава 12)
помогут вашей команде выделить интеллек-
Групповое программирование
туальные ресурсы, необходимые для созда- (глава 12)
ния действительно простых дизайнов.
Показатели
Когда вы создаете простые дизайны:
zz ваша команда не пишет код в ожидании будущих историй;
zz ваша команда завершает работу быстрее, поскольку не создает то, что не нужно
на сегодняшний день;
zz ваш дизайн с легкостью поддерживает произвольные изменения;
zz хотя новые функциональности могут требовать много нового кода, изменения
в существующем коде локализованы и понятны.
Альтернативы и эксперименты
Классический подход к дизайну — ожидать бу-
дущие изменения и формировать дизайн так, См. также
чтобы превентивно их поддерживать. Я назы-
ваю это предиктивным дизайном в отличие Рефлексивный дизайн (глава 14)
от рефлексивного, который мы обсудим далее.
Глава 14. Дизайн 525
1
Хант Э, Томас Д. Программист-прагматик. — СПб.: Питер, 2006.
2
Бек К. Шаблоны реализации корпоративных приложений.
526 Часть III. Надежная поставка
Далее мне было нужно определить изъяны в дизайне. Их было множество. Это
был один из самых первых кодов, написанных мною для сайта примерно четыре года
назад, и я с тех пор многому научился.
zz Я не отделил логику от инфраструктуры. Наоборот, SubscriberAccount (логика)
напрямую зависела от RecurlyClient (инфраструктура).
528 Часть III. Надежная поставка
Реверс-инжиниринг дизайна
Первый шаг в рефлексивном дизайне — проанализировать свой существующий код,
и если вы его уже не понимаете, то сделать реверс-инжиниринг его дизайна.
Лучше всего будет попросить кого-нибудь в команде объяснить вам дизайн.
Обсуждение наброска на доске, реальное или виртуальное, — быстрый и эффектив-
ный способ обучения, и он часто приводит к взаимодействию в области возможных
улучшений.
Может случиться так, что никто из команды не понимает дизайн или вы можете
захотеть сами понять код. Когда это происходит, начните с обдумывания задач, за
которые отвечают исходные файлы. Выберите файл, зона ответственности которого
наиболее тесно связана с вашей текущей задачей. Если ничего больше не находится,
то, скорее всего, вы можете начать с пользовательского интерфейса и отслеживать
зависимости от него. Например, анализируя код аутентификации, я начал с конечной
точки, относящейся к кнопке входа в систему.
Когда вы найдете стартовую точку, откройте файл и просмотрите имена методов
и функций. Используйте их, чтобы подтвердить или пересмотреть верность вашего
предположения о задачах, выполняемых файлом. Если нужны еще подсказки, то про-
смотрите названия тестов в файле тестов. Затем обратите внимание на зависимости
файла (как правило, его импорты). Проанализируйте и эти файлы и повторяйте до
тех пор, пока встречающиеся зависимости не перестанут иметь отношение к вы-
полняемым вами изменениям.
Теперь, когда у вас есть хорошее представление о задействованных файлах и зонах
ответственности каждого из них, вернитесь назад и посмотрите, как они связаны
друг с другом. Если это сложно, то нарисуйте диаграмму. Вы можете использовать
формальную технику моделирования, например UML, но подойдет и простой набро-
сок. Я обычно начинаю с того, что рисую квадраты для каждого модуля или класса
и линии с надписями, чтобы показать, как они взаимосвязаны. Когда код особенно
сложный, я рисую диаграмму последовательностей, в которой есть колонка для
530 Часть III. Надежная поставка
ПРИМЕЧАНИЕ
Некоторые инструменты автоматически создают диаграммы UML на основе
вашего исходного кода. Я предпочитаю создавать диаграммы вручную, само-
стоятельно изучая код. Создание их вручную заставляет меня изучать код более
глубоко. Это занимает больше времени, но в итоге приводит к гораздо лучшему
пониманию того, как работает код.
Это не должно занять много времени. Если все же занимает, то помните, что
лучший способ понять дизайн — попросить кого-либо в команде объяснить его вам.
Если ваша команда не работает с большими объемами кода, который не она созда-
вала, то у вас вряд ли возникнут проблемы с поиском того, кто понимает дизайн
существующего кода. В конце концов, это же ваша команда его написала. Быстрого
просмотра должно быть достаточно, чтобы освежить ваше понимание.
Определение улучшений
В основе любого кода лежит своя красота. Это наиболее важно помнить, когда вы
будете искать улучшения дизайна. Легко смотреть на существующий код и думать:
«Он ужасен». И он действительно может быть ужасным, хотя лучше стараться
не считать дизайн таким только потому, что вы не сразу разобрались в коде. Чтобы
понять код, нужно время, неважно, насколько хорошо он спроектирован.
Но даже если код действительно ужасен, он, скорее всего, создавался на основе
какого-то дизайна. Тот со временем мог перестать работать, но где-то внутри него
есть зачатки хорошей идеи.
Ваша работа — найти и оценить эту глубоко спря-
танную красоту. Вам не обязательно поддерживать Ваша работа — найти
изначальный дизайн, если он больше непригоден, и оценить эту глубоко
но вам нужно его понимать. Довольно часто изна- спрятанную красоту.
чальный дизайн все еще имеет смысл. Он нуждается
в настройках, а не в полной переделке.
Возвращаясь к примеру с аутентификацией, конечная точка входа в систему за-
висела от класса PersonaClient, который зависел от класса HttpsRestClient. Весь код
был не тестопригодным, что приводило к несколько уродливому, нетестируемому
коду входа в систему. Но основная идея создания инфраструктурных оберток была
разумной. Вместо того чтобы отказаться от нее, я усилил ее, сделав инфраструктур-
ные обертки допускающими значение null, что позднее позволило мне использовать
принципы разработки через тестирование, чтобы создать новую, более понятную
конечную точку входа в систему в Auth0.
Это не значит, что существующий дизайн будет совершенным. Всегда есть что-то,
что можно улучшить. Но когда вы думаете об улучшениях, не ищите способ удалить
все и начать сначала. Лучше ищите проблемы, уменьшающие глубоко спрятанную
красоту. Восстанавливайте и улучшайте дизайн. Не изобретайте его заново.
Глава 14. Дизайн 531
Проблемный код
Термин «проблемный код» (code smells) — «сжатые крупицы мудрости» в сфере про-
блем дизайна. Он представляет собой отличный способ замечать возможности для
улучшения вашего кода.
Если вы заметили проблемный код, это не обязательно означает, что есть про-
блемы с дизайном. Это как странный запах на кухне: он может сигнализировать,
что пора вынести мусор, а может означать, что кто-то всего лишь готовит блюдо
с очень пикантным сыром. В любом случае, если вы чувствуете странный запах, то
присмотритесь внимательнее.
Мартин Фаулера и Кент Бек ведут отличную дискуссию о проблемном коде
в главе 3 книги Refactoring [Fowler2018]. Ее стоит прочесть. В следующих разделах
приводятся несколько наиболее важных, по моему мнению, «запахов», в том числе
таких, о которых Фаулер и Бек не упоминали1.
1
Класс кода (Code Class), отброшенные ошибки (Squashed Errors), нянчиться с Nulls (Coddled
Nulls), зависимость от времени (Time Dependency) и полусырые объекты (Half-Baked Objects) —
мои изобретения.
532 Часть III. Надежная поставка
до этого. Вы можете выбрать функцию или метод, модуль или класс либо целую
подсистему. Не тратьте слишком много времени на выбор; если вам трудно это
сделать, то выберите наугад.
Сделайте реверс-инжиниринг дизайна кода, прочитав его. Смоделируйте дизайн
с помощью диаграммы последовательности, диаграммы классов, CRC-карт или
любой другой техники на ваш выбор. Специализированные модели тоже по-
дойдут. Определите изъяны в коде и его дизайне и обсудите, как их исправить.
Создайте новую модель, показывающую, как будет выглядеть дизайн после
внесения исправлений.
Шаг 3. (Ограничьте этот шаг 15 минутами.) Выберите три пары, каждая из которых
проведет трехминутное обсуждение своих выводов.
Повторяйте до тех пор, пока все участники не научатся производить высоко
качественные результаты через 30 минут, не чувствуя спешки.
Вопросы
Чем рефлексивный дизайн отличается от рефакторинга?
Рефлексивный дизайн решает, куда вести машину. Рефакторинг нажимает педали
и крутит руль.
Как нам найти время на рефлексивный дизайн?
Это нормальная, необсуждаемая часть вашей работы. Предполагается, что вы бу-
дете оставлять свой код в немного лучшем состоянии, чем было, поэтому, приступая
к работе над задачей, начните с рефлексивного дизайна, чтобы определить, что вы
собираетесь улучшить. Иногда эти улучшения даже уменьшают общее количество
времени, необходимое для выполнения задачи. Но даже если сейчас это не ускоряет
выполнение вашей задачи, то ускорит выполнение будущих задач. Поддерживать
чистоту дизайна — выгодно.
С другой стороны, вам нужно всего лишь оставить код в немного лучшем состоя
нии, чем он был. Не исправляйте все. Лучше используйте резерв времени, чтобы
выделить время для дополнительных возможностей совершенствования, как описано
в пункте «Повышать внутреннее качество» главы 9.
Предварительные требования
Кто угодно может использовать рефлексивный ди-
зайн для определения возможностей улучшений. Это См. также
еще один инструмент в наборе, и ничто не мешает
использовать его вместе с предиктивным дизайном Рефакторинг (глава 13)
или специализированным подходом к дизайну. Разработка через тестиро-
На самом деле выполнение улучшений требует вание (глава 13)
рефакторинга, а это обычно зависит от хорошего
набора тестов.
Глава 14. Дизайн 535
Показатели
Когда вы правильно используете рефлексивный дизайн:
zz ваша команда постоянно улучшает дизайн существующего кода;
zz работая над задачей, программисты часто выполняют рефакторинг, чтобы упро-
стить задачу;
zz рефакторинги выполняются там, где могут принести больше пользы;
zz код стабильно становится проще и более удобным для работы.
Альтернативы и эксперименты
Команды, которые не знают, как использовать рефлексивный дизайн, часто вместо
этого выступают за переписывание кода или тратят много времени на рефакторин-
ги. Это работает, но в сравнении оказывается довольно неуклюжим решением. Это
нельзя делать инкрементно, инкрементами, что приводит к конфликтам между про-
граммистами и стейкхолдерами по поводу распределения времени команды.
Рефлексивный дизайн на самом деле заключается в инкрементном улучшении
дизайна. Это та же самая работа инкрементами, которая проходит сквозь все прак-
тики области поставки. Описанный здесь подход вам не обязательно использовать
в точности, поэтому не бойтесь экспериментировать. В процессе экспериментов
фокусируйтесь на методах, которые позволяют вам определять возможности для
улучшений и вносить изменения постепенно, не вынуждая при этом никого ждать,
пока вы закончите.
ПРИМЕЧАНИЕ
Как и во многом в экосистеме Agile, термин DevOps был искажен людьми с доб
рыми намерениями, которые делали неверные предположения… и компаниями
с менее добрыми намерениями, пытающимися быстро заработать. Здесь я ис-
пользую его в оригинальном смысле этого слова: тесное сотрудничество отделов
разработки, эксплуатации и безопасности.
Источники DevOps
Термин DevOps был популяризирован Патриком Дюбуа — организатором пер-
вой конференции DevOpsDays в 2009 году. Идея разрушить барьеры между от-
делами разработки и эксплуатации появилась раньше самого термина, не имея
какого-либо явного источника происхождения. Однако одним из самых ранних
примеров является создание Бенджамином Трейнором Слоссом подхода к обес
печению надежности информационных систем (Site Reliability Engineering, SRE)
в Google в 2003 году. В [Beyer2016] Слосс пишет: «Можно рассматривать DevOps
как обобщение нескольких основных принципов SRE… или эквивалентно рас-
сматривать SRE как особую реализацию DevOps с некоторыми уникальными
расширениями». Эта основная идея совместной работы отражена в практике
«Сборка для эксплуатации».
Флаги функций также известны как переключатели функций. Как и DevOps, они
представляют собой довольно естественное продолжение идей Agile (в этом слу-
чае — непрерывной интеграции), не имея определенного источника происхождения.
Непрерывное развертывание также является естественным продолжением
непрерывной интеграции. Кент Бек включил похожую практику «Ежедневное
развертывание» (Daily Deployment) во второе издание книги по XP [Beck2004].
Впервые термин был использован, насколько мне известно, в книге Поля Дюваля
Continuous Integration1 [Duvall2006].
В практике «Эволюционная системная архитектура» отражено применение идей
эволюционного дизайна XP к системной архитектуре.
1
Гловер Э., Дюваль Поль М., Матиас С. DevOps. Непрерывная интеграция. Улучшение качества
программного обеспечения и снижение риска.
538 Часть III. Надежная поставка
Моделирование угроз
Сборка для эксплуатации подразумевает сдвиг влево: думать о потребностях отделов
безопасности и эксплуатации с самого начала разработки, а не в конце. Один из
способов понять эти потребности — моделирование угроз. Это техника из сферы
безопасности, но ее анализ также полезен и для области эксплуатации.
Моделирование угроз — это процесс пони-
мания вашей программной системы и того,
как она может быть скомпрометирована. См. также
В своей книге Threat Modeling: Designing
Визуальное планирование (глава 8)
for Security [Shostack2014] Адам Шостак
описывает это как процесс поиска ответов Обнаружение слепых зон (глава 16)
на четыре вопроса. Это хорошая командная
работа.
1. Что вы создаете? Нарисуйте диаграмму вашей системной архитектуры: компо-
ненты вашего развернутого ПО, потоки данных между ними и границы доверия
или полномочий между ними.
2. Что может пойти не так? Примените одновременный мозговой штурм (см. пункт
«Работайте одновременно» главы 7), чтобы обдумать возможные способы, с по-
мощью которых каждый компонент и поток данных могут быть атакованы, затем
проведите точечное голосование, чтобы сузить список основных угроз.
3. Что вам делать с тем, что может пойти не так? Найдите способы проверки
или решения проблем из списка основных угроз с помощью мозгового штурма,
проведите точечное голосование и создайте для этих работ карты историй.
Глава 15. DevOps 539
Конфигурация
Согласно The Twelve-Factor App [Wiggins2017], развернутое ПО — это комбинация
кода и конфигурации. Конфигурация в этом случае означает часть вашего ПО, которая
различается для каждой среды: строки подключения к базе данных, URL и секреты
(secrets) для сторонних продуктов и т. д.
Когда вы выполняете развертывание, вы развертываете один и тот же код в каж-
дую среду, неважно, тестовая это среда или эксплуатационная. Но ваши настройки
изменятся: например, ваша тестовая среда будет настроена для использования
тестовой базы данных, а эксплуатационная — для использования вашей эксплуата-
ционной базы данных.
В определение «конфигурация» входит только то, что меняется от среды к среде.
Команды часто делают настраиваемыми другие вещи, такие как дата авторского права
в нижней части сайта, но эти типы конфигурации должны быть явно отделены от
конфигурации среды. Они являются частью поведения вашего ПО, и с ними нужно
обращаться как с кодом, включая контроль их версий вместе с кодом. Я часто ис-
пользую реальный код для этих целей, такой как константы или геттеры в модуле
Configuration. (Как правило, я программирую этот модуль также и на конфигурацию
абстрактной среды.)
Конфигурация среды, с другой стороны, должна быть отделена от кода. Она часто
хранится в отдельном репозитории. Если вы включите ее в ваш кодовый репозито-
рий, что имеет смысл, когда ваша команда отвечает за развертывания, то четко от-
делите ее: например, исходный код в каталоге source, а конфигурация среды в ката-
логе environments . Потом, при развертывании, введите конфигурацию в среду
развертывания, выставив переменные среды, скопировав файлы и т. д. Конкретика
будет зависеть от вашего механизма развертывания.
Избегайте делать ваше ПО бесконечно кон-
фигурируемым. Сложная конфигурация в итоге
становится формой кода — кода, написанного осо- См. также
бенно скверным языком программирования, без
Флаги функций (глава 15)
абстракций или тестов. Если вам нужны сложные
настройки, то лучше используйте флаги функций,
540 Часть III. Надежная поставка
чтобы выборочно включать и выключать какие-либо виды поведения. Если вам нужно
комплексное, контролируемое заказчиком поведение, то рассмотрите возможность
использования архитектуры плагинов. Оба подхода позволят вам кодировать детали,
используя реальный язык программирования.
Секреты
Секреты (secrets) (пароли, ключи API и т. д.) —
особый вид конфигурации. Особенно важно, Члены команды не должны иметь
чтобы они не были частью вашего исходного доступ к секретам.
кода. Фактически большинство членов коман-
ды вообще не должны иметь доступ к секретам. Вместо этого определите безопасную
процедуру генерирования, хранения, обращения и аудита секретов. В комплексных
системах эта процедура часто подразумевает использование инструмента или сервиса
управления секретами.
Если вы храните конфигурацию среды в отдельном репозитории, то можете
контролировать доступ к секретам, строго ограничив доступ к этому репозиторию.
Если вы храните конфигурацию среды в вашем кодовом репозитории, то должны
шифровать свои секреты в «состоянии покоя», что означает шифрование всех
файлов, которые содержат секреты. Запрограммируйте свои скрипты разверты-
вания, чтобы они выполняли дешифрование секретов перед вводом их в среду
развертывания.
Что касается развертывания, уделяйте особое внимание тому, как секреты управ-
ляются вашей автоматизацией сборки и развертывания. Конечно, удобно жестко
закодировать секреты в скрипт развертывания или конфигурацию CI-сервера, но
это удобство не стоит риска. Вашей автоматизации нужны те же самые процедуры
безопасности, что и остальному коду.
Никогда не записывайте секреты в ваши журналы. Это легко сделать случайно,
поэтому подумайте над тем, чтобы написать для вашей обертки записи в журнал про-
цедуру поиска данных, похожих на секреты (например, поля с именами password или
secret), и их редактирования. Когда такие данные будут обнаруживаться, команда
должна получать оповещение о том, что необходимо исправить ошибку.
Параноидальная телеметрия
Независимо от того, насколько аккуратно вы пишете ваш код, он все же будет сбоить
при эксплуатации. Даже самый совершенный код зависит от несовершенного мира.
Внешние сервисы возвращают непредвиденные данные или (что еще хуже) отвеча-
ют очень медленно. Заканчивается свободное пространство в файловых системах.
Системы обработки отказов… отказывают.
Всякий раз, когда ваш код взаимодействует с внешним миром, запрограммируйте
его так, чтобы он предполагал, что мир стремится вам навредить. Проверяйте код
каждой ошибки. Подтверждайте каждый ответ. Вводите тайм-аут для неотвечающих
Глава 15. DevOps 541
"correlationId": "b7398565-3b2b-4d80-b8e3-4f41fdb21a98",
"code": "L16",
"message": "ExampleService API has been deprecated.",
"endpoint": "/v2/accounts/:account_id",
"headers": {
⋮
"x-api-version": "2.22",
"x-deprecated": true,
"x-sunset-date": "Wed November 10 2021 00:00:00 GMT"
}
}
Зачастую эти сведения будут частью вашего ранбука (runbook) — сборника процедур
и процессов для конкретной части ПО. Например:
Мониторинг и оповещения
Система мониторинга распознает, когда ваши журналы и показатели требуют внима-
ния. Когда это происходит, инструмент мониторинга посылает оповещение (электрон-
ное письмо, уведомление в чате или даже текстовое сообщение либо телефонный
звонок), чтобы кто-то мог об этом позаботиться. В некоторых случаях оповещения
выполняет отдельный сервис.
Решение, о чем нужно отправлять оповещение, а о чем — нет, может быть доволь-
но сложным, поэтому может понадобиться настроить ваш инструмент мониторинга
с помощью подходящего языка программирования. Отнеситесь к этой настройке
с таким же вниманием, как и к реальной программе. Храните ее в контроле версий,
уделяйте внимание дизайну и пишите тесты по возможности.
Виды оповещений, которые отправляет ваш инструмент мониторинга, зависят от
вашей организации, но, как правило, они попадают в четыре категории:
zz «Авария» — что-то очень срочное или вот-вот станет срочным, и человек должен
проснуться и исправить это немедленно;
zz «Событие» — что-то важное, требует внимания, но это недостаточно срочно,
чтобы кого-либо будить;
zz «Наблюдение» — что-то необычное, человек должен еще раз на это взглянуть
(используйте умеренно);
zz «Информация» — не требует чьего-либо внимания, но полезно для наблюдения.
Настройте ваш инструмент мониторинга так, чтобы он отправлял некоторые
оповещения на основе записей в вашем журнале. Проще всего запрограммировать
журнал на использование приведенных выше терминов, но большинство библио-
тек журналов используют вместо этого такие: FATAL, ERROR, WARN, INFO и DEBUG. Хотя
технически они имеют другие значения, вы можете напрямую наложить их на пре-
дыдущие уровни: FATAL — для категории «Авария», ERROR — для «События», WARN —
для «Наблюдения» и INFO — для… «Информации». Лучше совсем не используйте
DEBUG — он только добавляет шум.
Глава 15. DevOps 545
ПРИМЕЧАНИЕ
Можно использовать записи журнала DEBUG во время разработки, но не реги-
стрируйте их. Некоторые команды программируют свой скрипт непрерывной
интеграции так, чтобы он вызывал автоматический сбой сборки, если обнару-
живает записи DEBUG.
ПРИМЕЧАНИЕ
Некоторые организации имеют специально назначенные команды эксплуатации,
которые управляют системами и несут дежурство на телефоне. Это работает лучше
всего, когда команда разработки первой управляет собственными системами. Пре-
жде чем передавать свои обязанности, они должны продемонстрировать опреде-
ленный уровень стабильности. Больше информации вы найдете в [Kim2016] (гл. 15).
Напишите тесты для своих журналов и оповещений. Они так же важны для
успеха вашего ПО, как и пользовательские функции. Эти тесты может быть трудно
написать, поскольку они часто вовлекают глобальное состояние, но это решаемая
проблема дизайна, как обсуждается в разделе «Контроль глобального состояния»
главы 13. Эпизоды 11–15 в [Shore2020b] показывают, как это сделать.
К А Р ГО - К УЛ ЬТ
Команда DevOps
Идет ваша первая рабочая неделя, когда вы заглядываете в офис
вашего босса. «Привет, Уолдо, есть минутка? У меня небольшой
вопрос». Он доброжелательно кивает и движением приглашает
вас присесть.
Вы устраиваетесь поудобнее.
— Кто из людей DevOps есть у нас в команде? У меня проблема,
которую мне надо обсудить с кем-то, но я не смог разобраться,
как у нас работает DevOps.
— В команде? — Уолдо поднимает бровь. — Нет, конечно, у нас отдельная команда
DevOps. ProdOps и DataOps тоже. DevOps занимается тестовой средой и инстру-
ментарием CI, ProdOps управляет эксплуатационной средой, и DataOps отвечает
за базы данных и схемы. Разве ты не должен это знать? Твоя предыдущая компа-
ния, наверное, была довольно маленькая, если в ней все это было объединено.
— Нет, мы… — вы трясете головой. — Долгая история. Это был другой тип DevOps.
В любом случае я же могу поговорить с людьми из ProdOps? Возможно, API, ко-
торый я использую, выдает исключение Disk Full, и я хотел бы скоординировать
с ними соответствующую реакцию на это.
Уолдо втягивает воздух через зубы.
— О-о-ох, я бы лучше этого не делал. Они довольны резкие и ужасно занятые.
Все должно проходить через их систему заявок, и они терпеть не могут, когда мы
понапрасну тратим их время. В любом случае, когда еще случится этот Disk Full?
Просто запиши это исключение в журнал и верни null. Здесь мы делаем именно
так. Нам нужно соблюдать сроки.
Вы набираете воздух в легкие, чтобы возразить, но Уолдо поднимает руку:
— Слушай, я знаю, что это отличается от того, к чему ты привык, но у нас большая
компания. Ты не можешь просто ходить и отвлекать людей всякими мелочами.
Надо все делать правильно.
Глава 15. DevOps 547
Вопросы
Как нам найти время на все это?
Как сказала Сара Хоран Ван Трис, у вас нет времени, чтобы этого не делать.
«По моему опыту, команды, работающие над ПО, которое не “создано для эксплуа-
тации”, как правило, тратят много времени на то, чего можно было бы избежать или,
по крайней мере, что можно было бы диагностировать и исправить за минуты, будь
они более пригодными для наблюдения». Позаботьтесь об этом сейчас, или будете
тратить больше времени на авралы потом.
Потребности отделов эксплуатации и безопас-
ности можно запланировать как истории, как и все См. также
остальное. Чтобы убедиться, что этим историям
присвоен должный приоритет, привлеките людей Визуальное планирование
с навыками эксплуатации и безопасности к сессиям (глава 8)
планирования. Без багов (глава 16)
Обращайтесь с оповещениями, как с багами: они
Резерв времени (глава 9)
должны быть неожиданными, и их следует воспри-
нимать всерьез, когда они случаются. Каждым опо-
вещением нужно заниматься немедленно. Это применимо и к ложным оповещениям
о событиях: когда вам приходит сообщение о чем-то, что не является проблемой,
отрегулируйте это оповещение так, чтобы оно не поднимало ложную тревогу.
Улучшения, влияющие на качество жизни, такие как доводка чувствительности
оповещений или усовершенствование сообщений в журнале, можно выполнять за
счет резерва времени вашей команды.
Что, если у нас в команде нет никого с навыками эксплуатации или безопасности?
Найдите время, чтобы связаться с вашим отделом эксплуатации на ранней стадии
разработки. Сообщите им, что вы хотели бы узнать их мнение по части операционных
требований и требований к аварийным оповещениям, и спросите, как организовать
регулярные встречи, на которых можно получать от них обратную связь. Я замечал,
что люди из отдела эксплуатации бывают приятно удивлены, когда команды раз-
работки приглашают их принять участие до того, как случается аврал. Они обычно
стремятся помочь.
У меня меньше опыта по части привлечения сотрудников отдела безопасности,
отчасти потому, что их меньше, чем людей из отдела эксплуатации, но в целом под-
ход должен быть тот же: свяжитесь с ними на ранней стадии разработки и обсудите,
как вы можете сразу встроить безопасность в ваш продукт, вместо того чтобы при-
страивать ее задним числом.
Предварительные требования
Делать сборку для эксплуатации может любая ко- См. также
манда. Чтобы получить лучшие результаты, вам
понадобится команда, в которой есть люди с навы- Вся команда (глава 7)
ками эксплуатации и безопасности, или хорошие
отношения с людьми, обладающими этими навыками, а также культура управления,
которая ценит долгосрочное планирование.
548 Часть III. Надежная поставка
Показатели
Когда вы делаете сборку для эксплуатации:
zz ваша команда рассмотрела и учла потенциальные угрозы безопасности;
zz оповещения адресные и актуальные;
zz когда возникает проблема в отделе эксплуатации, ваша организация готова на
нее реагировать;
zz ваше ПО жизнеспособно и устойчиво.
Альтернативы и эксперименты
Эта практика в конечном счете касается подтверждения того, что работающее ПО
подразумевает его запуск в эксплуатационной среде, а не просто написание кода и со-
знательное создание вашего ПО таким образом, чтобы оно соответствовало потреб-
ностям эксплуатации. Лучший способ это сделать, который я знаю, — привлекать
экспертов по эксплуатации и безопасности к работе в вашей команде.
Вы можете экспериментировать с другими подходами. Отделы эксплуатации и без-
опасности в компаниях часто бывают малочисленными, так что может быть сложно
включить людей с этими навыками в каждую команду. В таких случаях в качестве
замены обычно используются чек-листы и автоматические инструменты. По моему
опыту, это лишь бледная копия. Лучше всего дать членам команды возможность
обучиться, чтобы развить соответствующие навыки.
Прежде чем начать экспериментировать, попробуйте поработать хотя бы с одной
командой, применяющей подлинный подход DevOps, в составе которой есть ква-
лифицированные специалисты. Таким образом, вы будете знать, с чем сравнивать
ваши эксперименты.
1
https://12factor.net/ru/.
2
Ким Дж. и др. Руководство по DevOps. Как добиться гибкости, надежности и безопасности миро-
вого уровня в технологических компаниях.
3
Ким Дж., Спаффорд Дж., Бер К. Проект «Феникс». Как DevOps устраняет хаос и ускоряет раз-
витие компании.
Глава 15. DevOps 549
Замковый камень
Строго говоря, самый простой тип флага функций — вообще не флаг функций. Кент
Бек называет это замко́вым камнем (keystone) [Beck2004] (гл. 9). Все просто: рабо-
тая над чем-либо новым, подключайте UI последним. Это замковый камень. До тех
пор, пока замковый камень не будет установлен (до тех пор, пока UI не будет под-
ключен), никто не будет знать, что есть новый код, поскольку ни у кого не будет
никаких способов доступа к нему.
Например, когда я переводил сайт на использование другого сервиса аутенти-
фикации, я начал с введения инфраструктурной обертки для нового сервиса. Мне
удалось выполнить большую часть этой работы, не подключая к ней кнопку входа
в систему. До того как я это сделал, пользователи
ничего не знали об изменениях, поскольку кнопка См. также
все еще использовала старую инфраструктуру
аутентификации. Разработка через тестирова-
Это поднимает следующий вопрос: если вы ние (глава 13)
не можете увидеть ваши изменения, то как вы их Быстрые надежные тесты
протестируете? Ответ: используя разработку че- (глава 13)
рез тестирование и узкие тесты. Разработка через
550 Часть III. Надежная поставка
тестирование позволяет вам проверить вашу работу, не видя, как она выполняется.
Узкие тесты сосредоточиваются на конкретных функциях, не требуя, чтобы те были
подключены к остальной части вашего приложения.
В конечном счете вы, конечно, захотите увидеть работу вашего кода, чтобы или
сделать тонкую настройку UI (его тест-драйв может быть трудно сделать) с целью
получить отзывов от заказчиков, или просто проверить еще раз свою работу. В конце
концов, TDD тоже неидеальна.
Проектируйте ваш новый код так, чтобы его можно было «включить» буквально
одной строчкой. Когда вы захотите увидеть его работу, добавьте эту строку. Если
вам нужно сделать интеграцию перед тем, как вы будете готовы к релизу, заком-
ментируйте эту строку. Когда вы готовы к релизу, напишите соответствующий тест
и раскомментируйте строку окончательно.
Замковый камень не обязательно должен включать пользовательский интерфейс.
В качестве камня может быть использовано все, что скрывает вашу работу от за-
казчиков. Например, одна команда использовала непрерывное развертывание для
того, чтобы переписать свой сайт. Она развернула новый сайт на реальном рабочем
сервере, но тот не получал никакого рабочего трафика. Никто за пределами компа-
нии не видел нового сайта, пока команда не переключила трафик со старого сервера
на новый.
Замковые камни — мой любимый способ
маскировки незавершенной работы. Они Замковые камни — мой любимый
простые, понятные и не требуют никакой способ маскировки незавершенной
работы.
специальной работы по техническому об-
служиванию или дизайну.
Флаги функций
Флаги функций похожи на замковые камни, за исключением того, что для управления
видимостью используют код, а не комментарий. Обычно это простой оператор if.
Продолжая пример с аутентификацией, напомню, что я запрограммировал свою
новую инфраструктуру аутентификации, не подключая ее к кнопке входа в систему.
Прежде чем я смог бы ее подключить, мне нужно было протестировать ее в эксплуа
тационной среде, поскольку там были сложные взаимодействия между сторонним
сервисом и моими системами. Но я не хотел, чтобы мои пользователи использовали
новый вход в систему до того, как я его протестирую.
Я решил эту дилемму с помощью флага функциональности. Мои пользователи
видели старый вход в систему; я видел новый. Код работал таким образом: (Node.js):
if (siteContext.useAuth0ForAuthentication()) {
// новый Auth0 HTML
}
else {
// старый Persona HTML
}
Глава 15. DevOps 551
Я должен был сделать новую страницу проверки электронной почты как часть
изменений. Это не показывалось внешним пользователям, но люди все же могли
вручную набрать URL, поэтому я использовал флаг функций, чтобы перенаправлять
их наружу:
httpGet(siteContext) {
if (!siteContext.useAuth0ForAuthentication()) return redirectToAccountPage();
⋮
}
Не забывайте удалять флаги функций после того, как они становятся больше
не нужны. Об этом легко забыть, и это одна из причин, почему я предпочитаю ис-
пользовать замковые камни, а не флаги функций. Чтобы помочь себе это запомнить,
вы можете добавить напоминание в календарь команды или историю «удалить флаг»
в план команды. Некоторые команды программируют код своего флага так, чтобы
он записывал сообщение в журнал или вызывал сбой тестов после того, как срок
годности флага истек.
Как ваш код узнает, когда флаг включен? Другими словами, куда вы встроите
свой эквивалент useAuth0ForAuthentication()? У вас есть несколько вариантов.
Конфигурация приложения
Конфигурация приложения — самый простой способ управлять вашими флагами
функций. Ваш код конфигурации может получать состояние флага из константы,
переменной среды, базы данных или откуда вам нравится. Константа — самый про-
стой вариант, поэтому я выбираю его первым, но переменная среды или база данных
позволят вам включать или выключать флаг на отдельных машинах, что даст воз-
можность выполнять поэтапные релизы.
Пользовательская конфигурация
Если вы хотите включать ваш флаг в зависимости от того, кто авторизован в систе-
ме, то сделайте это привилегией, привязанной к вашей абстракции пользователя
или учетной записи. Например, user.privileges.logsInWithAuth0(). Вы можете
использовать это для выполнения поэтапных релизов, основанных на подгруппе
пользователей, и выборочно выпускать функциональности, чтобы тестировать
разные идеи.
552 Часть III. Надежная поставка
ПРИМЕЧАНИЕ
Флаги функций легко внедрить, но ими может быть сложно управлять. Как только
вы начнете заниматься инкрементными релизами и сегментацией пользовате-
лей, стоит изучить имеющееся множество инструментов и сервисов, которые
позволяют управлять ими.
Секреты
В некоторых случаях вам может понадобиться включать флаг от случая к случаю,
но вы не сможете привязать эту привилегию к пользователю. Например, во время
моей работы по переводу аутентификации мне было необходимо включить новую
кнопку входа в систему, прежде чем я фактически авторизовался в ней.
В таких случаях вы можете включать флаг с помощью секрета. В клиентских при-
ложениях секрет может принимать форму специального файла в файловой системе.
Для серверных приложений подойдет куки или другой заголовок запроса. Именно это
я делал для своего флага аутентификации. Я написал код, который искал куки секрета,
который можно было установить, только авторизовавшись как администратор.
Флаги на основе секрета более рискованны, чем на основе конфигурации. Если
секрет станет известен, то кто угодно сможет включить функциональность. Их так-
же труднее установить и контролировать. Я их использую только в самом крайнем
случае.
Предварительные требования
Замковые камни может использовать кто угодно. Флаги функций могут выйти из-
под контроля, поэтому ваша команда должна уделять внимание их дизайну и удале-
нию, особенно когда их количество растет. Помогут коллективное владение кодом
и рефлексивный дизайн.
Глава 15. DevOps 553
Показатели
Когда вы правильно используете замковые камни и флаги функций:
zz ваша команда может развертывать ПО, в котором есть незавершенный код;
zz релиз — это бизнес-решение, а не техническое;
zz код, относящийся к флагу, понятен, хорошо спроектирован и протестирован;
zz флаги и их код удаляются после релиза соответствующей функциональности.
Альтернативы и эксперименты
Широко известная альтернатива замко-
вым камням и флагам функций — ветви См. также
функций. Когда кто-то начинает работать
Рефакторинг (глава 13)
над новой функцией, он создает ветвь и не
объединяет ее с остальным кодом до тех пор, Рефлексивный дизайн (глава 14)
пока функция не будет готова. Это эффек-
тивно, когда заказчики не должны иметь доступ к незавершенным изменениям, но
важные рефакторинги имеют тенденцию вызывать конфликты объединения ветвей.
Поэтому ветви функций не подходят для команд поставки, которые стремятся ис-
пользовать рефакторинг и рефлексивный дизайн для снижения затрат.
Замковые камни настолько просты, что не предоставляют места для эксперимен-
тов. Флаги функций, напротив, можно исследовать. Ищите способы поддерживать
порядок в ваших флагах функций и сохранять чистый дизайн. Подумайте, каким
образом ваши флаги могут предоставлять новые возможности для бизнеса. Напри-
мер, флаги функций часто используются при A/B-тестировании, что подразумевает
показ разных версий ПО различным пользователям, а затем принятие решения
в зависимости от результатов.
В процессе экспериментов помните: чем проще, тем лучше. Замковые камни мо-
гут показаться дешевым трюком, но очень эффективны и сохраняют чистоту кода.
Флаги функций легко могут выйти из-под контроля. По возможности выбирайте
простые решения.
НЕПРЕРЫВНОЕ РАЗВЕРТЫВАНИЕ
Аудитория
Наш новейший код уже в эксплуатации.
Если вы используете непрерывную интеграцию, Программисты,
значит, ваша команда ликвидировала большинство отдел эксплуатации
рисков релиза. Если все сделано правильно, то не-
прерывная интеграция означает, что ваша команда готова к релизу в любой момент
времени. Вы протестировали свой код и применили скрипты развертывания.
Остается один источник риска. Если вы делаете
развертывание не на реальные эксплуатационные См. также
серверы, то может оказаться, что ваше ПО на самом
деле не будет работать в эксплуатационной среде. Непрерывная интеграция
Разница в среде, трафике и использовании может при- (глава 13)
вести к отказам даже хорошо протестированного ПО.
Непрерывное развертывание помогает справиться с этим риском. Оно следует
тому же принципу, что и непрерывная интеграция: часто развертывая небольшие фраг-
менты, вы снижаете риск возникновения проблем, вызванных крупным изменением,
и облегчаете себе задачу поиска и решения проблемы, когда они все же возникают.
Непрерывное развертывание — ценная практика для команд, обладающих навы-
ками на уровне поставки, но при этом необязательна. Если ваша команда все еще
развивает эти навыки, то сфокусируйтесь сначала на других практиках. Полный
переход на использование непрерывной интеграции, включая автоматизированные
развертывания в тестовую среду (что некоторые называют непрерывной поставкой),
принесет вам почти такую же пользу.
Остановите линию
Когда развертывание не удалось, остановите линию: все перестают работать и со-
средоточиваются на проблеме в эксплуатационной среде. Это предотвращает
наслаивание ошибок.
Вот краткий список шагов, составляющих процесс исправления неудачного раз-
вертывания.
1. Остановите линию.
2. Откатите эксплуатационную среду.
3. Отмените развернутые изменения в репозитории кода. Сделайте интеграцию
и развертывание.
4. Всей командой создайте задачи для исправления ошибочного кода.
5. Перезапустите линию.
6. После развертывания исправления запланируйте сессию анализа инцидента.
Откатить развертывание
Начните с восстановления системы до ее предыдущего рабочего состояния. Как
правило, это подразумевает откат (rollback), который восстанавливает код пре-
дыдущего развертывания и конфигурацию. Чтобы это сделать, вы можете хранить
каждое развертывание в системе контроля версий или сохранять только копию
самого последнего развертывания.
Один из простейших способов сделать откат возможным — использовать
сине-зеленое развертывание (blue/green deployment). Для этого создайте две
копии вашей эксплуатационной среды, произвольно помеченные как «синяя»
и «зеленая», и настройте вашу систему на маршрутизацию трафика на одну из
двух сред. При каждом развертывании происходит переключение между двумя
средами, позволяя вам выполнить откат с помощью маршрутизации трафика на
предыдущую среду.
Например, если активна «синяя» среда, то развертывайте на «зеленую». Когда
развертывание завершено, прекратите маршрутизировать трафик на «синюю» и пере-
направьте его на «зеленую». Если развертывание неуспешно, то откат представляет
собой просто маршрутизацию трафика обратно на «синюю» среду.
Иногда откат тоже бывает неуспешным. Это может говорить о повреждении
данных или проблеме в конфигурации. В любом случае все члены команды прила-
гают усилия до тех пор, пока проблема не будет решена. В главах 12–14 книги Site
Reliability Engineering1 [Beyer2016] содержатся практические рекомендации о том,
как реагировать на такие инциденты.
1
Бейер Б. и др. Site Reliability Engineering. Надежность и безотказность как в Google. — СПб.:
Питер, 2019.
Глава 15. DevOps 557
Исправить развертывание
Откат плохой версии на предыдущую обычно решает непосредственную текущую
проблему в эксплуатационной среде, но на этом работа вашей команды не закан-
чивается. Вы должны исправить корневую проблему. Первый шаг — вернуть вашу
интеграционную ветвь назад в заведомо исправное состояние. Вы пока не пытаетесь
исправить проблему, вы лишь пытаетесь вернуть ваш код и эксплуатационную среду
обратно в состояние синхронизации.
Начните с возврата изменений в кодовом репозитории, чтобы содержимое вашей
интеграционной ветви совпадало с тем, что реально находится в эксплуатационной
среде. Если вы используете коммиты объединения (merge commits) в git, то можете
просто сделать git revert на интеграционном коммите. Затем используйте обычный
процесс непрерывной интеграции для интеграции и развертывания восстановлен-
ного кода.
Развертывание восстановленного кода должно пройти без ошибок, поскольку вы
развертываете тот же самый код, который уже работает. Важно все равно это сделать,
так как это позволяет вашему следующему развертыванию начинать с заведомо ис-
правного состояния. Кроме того, если это второе развертывание тоже будет иметь
проблемы, то проблемная область сузится до проблемы развертывания, а не про-
блемы в коде.
Вернувшись в заведомо исправное состоя
ние, вы сможете исправить корневую ошиб- См. также
ку. Создайте задачи для отладки проблемы
(обычно ее исправляют люди, которые ее Анализ инцидентов (глава 16)
развертывали), и все смогут вернуться к нор-
мальной работе. После того как проблема будет решена, запланируйте сессию анализа
инцидента, чтобы решить, как предотвратить подобные сбои развертывания в будущем.
Инкрементные релизы
В случае больших и рискованных изменений запускайте код в эксплуатационной
среде до того, как дадите пользователям доступ к нему. Это похоже на флаги функ-
ций, за исключением того, что вы на самом деле используете новый код. (Флаги
558 Часть III. Надежная поставка
Миграция данных
Изменения в базе данных откатить нельзя (по крайней мере, без риска потери дан-
ных), поэтому миграция данных требует особого внимания. Это похоже на выпол-
нение инкрементного релиза: сначала вы делаете развертывание, затем миграцию.
Выполните три шага.
1. Развертывайте код, который понимает и старую, и новую схему. В это же время
развертывайте код миграции данных.
2. После успешного развертывания запускайте код миграции данных. Его можно
запустить вручную или автоматически как часть вашего скрипта развертывания.
3. Когда миграция завершена, удалите вручную код, понимающий старую схему,
затем снова сделайте развертывание.
Разделение миграции данных и развертывания позволяет каждому разверты-
ванию, если оно будет неуспешным, пережить откат без потерь данных. Миграция
происходит только после того, как будет проверено, что новый код стабилен в экс-
плуатационной среде. Это несколько сложнее, чем миграция данных в процессе
развертывания, но более безопасно и позволяет делать развертывание с нулевым
временем простоя.
Миграции больших объемов данных требуют особого внимания, поскольку ра-
бочая система должна оставаться доступной, пока идет миграция. Для этого типа
миграций напишите ваш код так, чтобы он работал инкрементно (возможно, с огра-
ничителем скорости, из соображений производительности) и использовал обе схемы
одновременно. Например, если вы переносите данные из одной таблицы в другую,
то ваш код может просматривать обе таблицы, читая и обновляя данные, но вставлять
данные только в новую таблицу.
После того как миграция закончена, поста-
райтесь сделать так, чтобы ваш код оставался См. также
чистым, удалив устаревший код. Если для ми-
грации требуется больше, чем несколько минут, Планирование задач (глава 9)
то добавьте напоминание в план задач вашей Визуальное планирование
команды. В случае очень длительных миграций (глава 8)
вы можете добавить напоминание в календарь
Глава 15. DevOps 559
Предварительные требования
Чтобы использовать непрерывное развер-
тывание, вашей команде нужен строгий См. также
подход к непрерывной интеграции. Вам
нужно выполнять интеграцию несколько Непрерывная интеграция (глава 13)
раз в день и каждый раз создавать заведомо Флаги функций (глава 15)
исправную, готовую к развертыванию сбор- Без багов (глава 16)
ку. «Готовая к развертыванию» в этом случае
Нулевое трение (глава 13)
означает, что незавершенные функциональ-
ности скрыты от пользователей и ваш код Сборка для эксплуатации (глава 15)
не нуждается в ручном тестировании. В ре-
зультате ваш процесс развертывания должен быть полностью автоматизирован, и вам
нужен способ автоматического обнаружения сбоев развертывания.
Непрерывное развертывание имеет смысл только тогда, когда развертывания
не видны пользователям. На практике имеются в виду, как правило, системы бэкенда
и веб-фронтенды. Настольные и мобильные фронтенды, встроенные системы и т. д.
обычно не подходят для непрерывного развертывания.
Показатели
Когда ваша команда выполняет непрерывное развертывание:
zz развертывание в эксплуатационную среду не вызывает стресса и не является
экстраординарным событием;
zz когда случаются проблемы с развертыванием, они легко решаются;
zz развертывания редко вызывают ошибки в эксплуатационной среде, а если это
случается, то их обычно быстро исправляют.
Альтернативы и эксперименты
Стандартной альтернативой непрерывному развертыванию является развертыва-
ние, ориентированное на релиз: развертывание только тогда, когда у вас есть что-то
готовое к релизу. В действительности непрерывное развертывание является более
безопасным и надежным, когда соблюдены предварительные условия, хотя поначалу
это звучит пугающе.
560 Часть III. Надежная поставка
ПРИМЕЧАНИЕ
Я провожу различие между системной архитектурой и архитектурой приложения.
Архитектура приложения представляет собой дизайн вашего кода, содержащий
решения о том, как вызывать другие компоненты в вашей системе. Мы говори-
ли об этом в пункте «Архитектура приложения» ранее в текущей главе. В этой
практике обсуждается системная архитектура: решения о том, какие компоненты
создать и использовать, и высокоуровневые отношения между ними.
1
Stack Overflow публикует свою системную архитектуру и статистику производительности (https://
stackexchange.com/performance), и у Ника Крейвера в [Craver2016] есть подробные истории, в которых
обсуждается их архитектура. Доступ к процитированным данным осуществлялся 4 мая 2021 года.
562 Часть III. Надежная поставка
Нацеленность на простоту
Я не говорю, что вы должны слепо копировать архитектуру Stack Overflow. Никого
не следует слепо копировать! Лучше взгляните на проблемы, которые вам нужно
решать. («Более впечатляющее резюме» не в счет.) Какая самая простая архитектура
может их решить?
Один из вариантов подхода к этому вопросу — начать с идеализированного взгляда
на мир. Вы можете использовать этот мысленный эксперимент как для существу
ющих архитектур, так и для новых.
1
Рейтинг трафика Stack Overflow взят с alexa.com 6 мая 2021 года.
Глава 15. DevOps 563
3. Ограничьте ресурсы
Далее уберите предположение о неограниченных ресурсах. Вам могут понадобиться
несколько узлов для управления нагрузкой, а также компоненты для балансировки
нагрузки. Вам может понадобиться разбить операцию, интенсивно нагружающую
процессор, на ее компоненты и ввести очередь. Вам могут понадобиться общий кэш
и способ его заполнения.
Но будьте осторожны: вы рассуждаете
о будущей нагрузке или решаете реальные Вы рассуждаете о будущей нагрузке
задачи, основываясь на реальной эксплуа- или решаете реальные задачи?
тации и трендах? Можете ли вы упростить
архитектуру, используя более мощное аппаратное обеспечение или подождав с ре-
шениями для будущих нагрузок?
Контроль сложности
Некоторая архитектурная сложность необходима. Ваша система могла быть проще,
если бы вам не приходилось беспокоиться о балансировке нагрузки или сбое ком-
понентов, однако вам нужно беспокоиться о таких вещах. Как сказал Фред Брукс
в своей знаменитой статье No Silver Bullet: Essence and Accident in Software Engineering1
в [Brooks1995], некоторая сложность обязательна. Ее нельзя исключить.
Но есть еще одна сложность — случайная. Иногда вы разбиваете большой ком-
понент на несколько мелких, только чтобы упростить работу человека, а не потому,
что это важная часть проблемы, которую вы решаете. Случайную сложность можно
удалить или, по меньшей мере, снизить.
Эволюционный дизайн
Одна из наиболее часто встречающихся мне причин разделения компонентов — это
предотвратить большие комки грязи. Маленькие компоненты просты, и их легче
поддерживать.
1
https://ru.wikipedia.org/wiki/Серебряной_пули_нет.
564 Часть III. Надежная поставка
Самодисциплина
Еще одна причина того, почему команды разделяют свои компоненты, — это обеспе-
чение изоляции. Когда компонент отвечает за множество типов данных, появляется
соблазн перемешать данные, что усложняет дальнейший рефакторинг.
Конечно, нет никакой внутренней причины, по которой данные должны быть
перемешаны. Это просто решение по дизайну, и если вы можете спроектировать
изолированные компоненты, то можете спроектировать и изолированные модули
внутри одного компонента. Вы даже можете сделать так, чтобы каждый модуль ис-
пользовал отдельную базу данных. Не похоже, чтобы сетевые вызовы волшебным
образом создавали хороший дизайн!
Но сетевые вызовы обеспечивают
изоляцию. Если вы не используете сеть, См. также
чтобы обеспечивать изоляцию, то вза-
мен вам понадобится команда с хоро- Коллективное владение кодом (глава 12)
шей самодисциплиной. Коллективное Парное программирование (глава 12)
владение кодом, парное или групповое Групповое программирование (глава 12)
программирование и энергичная рабо-
та — все это помогает, а рефлексивный Энергичная работа (глава 7)
дизайн позволяет вам исправлять лю- Рефлексивный дизайн (глава 14)
бые возникающие ошибки.
Быстрое развертывание
См. также
Большие компоненты часто трудно
развертывать. По моему опыту, трудно Нулевое трение (глава 13)
не само развертывание, а сборка и те-
Разработка через тестирование (глава 13)
сты, которые должны пройти перед раз-
вертыванием компонента. Это вдвойне Непрерывная интеграция (глава 13)
верно, если компонент нужно тестиро- Быстрые надежные тесты (глава 13)
вать вручную.
Глава 15. DevOps 565
Вертикальное масштабирование
Перефразируя закон Конвея, организации, как правило, масштабируют свои органи-
зационные схемы. Многие организации по умолчанию используют горизонтальное
масштабирование (см. главу 6), что приводит к множеству маленьких изолированных
команд. Им нужны соответствующие маленькие компоненты.
Вертикальное масштабирование позволяет вашим командам работать вместе над
одним и тем же компонентом. Это дает вам возможность проектировать вашу архи-
тектуру так, чтобы она соответствовала проблеме, которую вы решаете, вместо того
чтобы проектировать вашу архитектуру так, чтобы она соответствовала структуре
ваших команд.
Компоненты → микролиты
Если ваша команда владеет множеством компонентов, вы можете объединить их
в один, оставив базовую архитектуру в том же состоянии. Изолируйте их в дере-
вьях отдельного каталога и используйте файл интерфейса верхнего уровня, а не
сервер для преобразования между вашей сериализированной полезной нагрузкой
и структурами данных компонента. Замените сетевые вызовы между компонента-
ми вызовом функции, но сохраняйте ту же самую архитектуру во всех остальных
отношениях, включая использование примитивных типов данных, а не объектных
или пользовательских типов.
Я называю эти внутрипроцессные компоненты микролитами1. Вы можете увидеть
пример такого рефакторинга в эпизоде 21 [Shore2020b]. Они обеспечивают изоляцию
компонента, не усложняя операции.
ПРИМЕЧАНИЕ
Мои микролит-рефакторинги абсолютно умозрительные. Я их испытывал только
на игрушечных проблемах. Я добавил их в эту книгу, поскольку они выступают
в роли промежуточного шага между компонентами и модулями.
Микролиты → модули
Микролиты строго изолированы. Они, по сути, являются компонентами, работающи-
ми в одном процессе. Это чревато определенными сложностями и дополнительными
издержками.
Если вам не нужна такая строгая изоляция, то вы можете удалить файл интерфейса
верхнего уровня и сериализацию/десериализацию. Просто вызывайте код микролита
как обычно. Результат — это модуль. (Не путать с файлом исходного кода, который
тоже может называться модулем.)
Компонент, составленный из модулей, как правило, называется модульным моно-
литом, но модули нужны не только для монолитов. Вы можете использовать их
в любом компоненте, неважно, насколько он большой или маленький.
1
Я называю их микролитами, поскольку изначально представлял их себе как комбинацию лучших
частей монолитов и микросервисов. Кроме того, «микролит» — понятие из реального мира, от-
носящееся к крошечному каменному инструменту, отколотому от большого камня, что выглядит
почти как метафора.
Глава 15. DevOps 567
Модули → микролиты
Если вам нужна строгая изоляция или вы думаете, что вам может понадобиться раз-
делить большой компонент на много маленьких, то можете конвертировать модуль
в микролит. Для этого введите файл интерфейса высокого уровня и сериализируйте
параметры комплексной функции.
Обращайтесь с микролитом, как если бы он был отдельным компонентом. Вызовы
к нему должны идти только через файл интерфейса высокого уровня, и их следует
абстрагировать за инфраструктурной оберткой, как описывается в подразделе «Сто-
ронние компоненты» главы 14. Код микролита должен быть изолирован похожим
образом; кроме общих типов и утилит, которые может использовать компонент, он
должен ссылаться только на другие компоненты и микролиты и только через их ин-
терфейсы высокого уровня. Сначала вам может понадобиться сделать рефакторинг
вашего модуля, чтобы он стал более похожим на компонент.
Сетевые вызовы гораздо медленнее и менее надежны, чем вызовы функций
и методов. Конвертация модуля в микролит не гарантирует, что ваш микролит будет
хорошо работать как сетевой компонент. Теоретически вы можете подтвердить, что
ваш микролит будет работать как полноценный сетевой компонент, введя задержку
1–2 мс в ваш высокоуровневый API или даже в случайные сбои. На практике это
звучит несколько смешно, и я еще не пробовал сделать это.
Микролиты → компоненты
Если микролит пригоден для использования в качестве сетевого компонента, то
конвертировать его в компонент довольно просто. Это вопрос конвертации файла
высокоуровневого API в сервер и преобразования вызывающих его элементов для
использования сетевых вызовов. Это сделать проще всего, если вы не забыли изо-
лировать их вызовы за инфраструктурной оберткой.
568 Часть III. Надежная поставка
Конвертация микролита в компонент наверняка потребует, чтобы те, кто будет его
вызывать, ввели обработку ошибок, тайм-ауты, повторные попытки, экспоненциаль-
ную задержку и противодавление вдобавок к операционным и инфраструктурным
изменениям, которых требуют новые компоненты. Это большой объем работы, но
такова цена сетевого взаимодействия.
Модули → компоненты
Вместо того чтобы использовать микролиты, вы можете перейти с модуля на ком-
понент. Это можно сделать с помощью извлечения кода, однако я часто вижу, как
люди вместо этого переписывают модули. Это обычная стратегия при выполнении
рефакторинга большого комка грязи, поскольку код модуля часто не заслуживает
того, чтобы его сохранять. В [Todkar2018] демонстрируется данный подход.
Составные рефакторинги
Скорее всего, вы будете связывать эти рефакторинги системного уровня в единую
цепочку. Например, самый общий подход, который я вижу, — очищать устаревший
код, используя схемы «Большой комок грязи → модули» и «Модули → компоненты».
Или более компактно: большой комок грязи → модули → компоненты.
Объединение компонентов — похожая операция в обратном направлении: компо-
ненты мультирепозитория → компоненты монорепозитория → микролиты → модули.
Если у вас есть набор компонентов с запутанными обязанностями, то, возможно,
вы сможете сделать рефакторинг для создания новых обязанностей вместо того,
чтобы переписывать: компоненты → микролиты → модули → новые модули →
микролиты → компоненты.
Предварительные требования
Вероятно, вы сможете использовать идеи,
изложенные в этой практике, только с ком- См. также
понентами, которыми владеет ваша команда.
Архитектурные стандарты и компоненты, Устранение препятствий (глава 11)
которыми владеют другие команды, скорее
всего, не будут находиться под вашим непосредственным контролем, но вы сможете
попытаться повлиять на людей, чтобы внести нужные вам изменения.
Изменения в системной архитектуре зависят от отношений между отделами раз-
работчиков и эксплуатации. Вам придется сотрудничать, чтобы определить простую
архитектуру для текущих потребностей системы, включая пиковые нагрузки и про-
гнозируемый рост, и вам придется продолжать координировать ваши совместные
действия при изменении потребностей.
Глава 15. DevOps 569
Показатели
Когда вы хорошо развиваете вашу системную архитектуру:
zz маленькие системы имеют маленькие архитектуры; большие — имеют управля-
емые архитектуры;
zz системную архитектуру легко объяснить и понять;
zz случайная сложность сохраняется на минимуме.
Альтернативы и эксперименты
Многое из того, о чем люди думают как об
эволюционной системной архитектуре, — на См. также
самом деле просто обычный эволюцион-
ный дизайн. Например, переход компо- Простой дизайн (глава 14)
нента с использования одной базы данных Инкрементный дизайн (глава 14)
на использование другой — это проблема
эволюционного дизайна, поскольку речь Рефлексивный дизайн (глава 14)
в основном идет о дизайне одного ком-
понента. То же самое можно сказать, когда компонент переходит с использования
одного стороннего сервиса на использование другого. Такие виды изменений можно
внести с помощью практик эволюционного дизайна: простого дизайна, инкремент-
ного и рефлексивного.
Развитие системной архитектуры означает необходимость намеренно начать
с самой простой из возможных систем и расти по мере изменения ваших потребно-
стей. Это идея, которую еще предстоит изучить. Выберите те части этой практики,
которые работают для вашей ситуации, затем посмотрите, какого прогресса сможете
достичь. Основная цель — снизить пробуксовки между отделами разработки и экс-
плуатации и упростить поиск неисправностей, не принося в жертву надежность
и ремонтопригодность.
1
Форд Н., Куа П., Парсонс Р. Эволюционная архитектура. Поддержка непрерывных изменений. —
СПб.: Питер, 2018.
2
Ньюман С. Создание микросервисов. — 2-е изд. — СПб.: Питер, 2022.
ГЛАВА 16
Качество
Источники качества
Идеи, представленные в разделе «Без багов», пришли из экстремального про-
граммирования.
Раздел «Обнаружение слепых зон» — сборник нескольких техник: «Подтвержден-
ное знание» (Validated Learning), пришедшее из бережливого стартапа, подхода
Эрика Риса; «Исследовательское тестирование» (Exploratory Testing), подход, воз-
главляемый Джемом Канером, хотя мое описание основано на работе Элизабет
Хендриксон [Hendrickson2013]; «Хаос-инжиниринг» (Chaos Engineering), который
возник благодаря Грегу Орзеллу и его коллегам из Netflix1; и «Тестирование
на проникновение и оценка уязвимостей» (Penetration Testing and Vulnerability
Assessment) — хорошо зарекомендовавшие себя техники обеспечения безопас-
ности.
1
Мне не удалось найти четко определенный источник техники «Хаос-инжиниринг». Его формали-
зовала «команда Хаоса» Кейси Розенталь в Netflix в 2015 году, но основные идеи опередили эту
команду на несколько лет. Изначальным инструментом был Chaos Monkey, который [Dumiak2021]
приписывает «Орзеллу и его коллегам из Netflix». В американском патенте US20120072571A1,
заявка на регистрацию которого была подана в 2010 году, в качестве изобретателей перечислены
Грег Орзелл и Юрий Израилевский.
Глава 16. Качество 571
БЕЗ БАГОВ
Мы смело выполняем релизы.
Аудитория
Если вы в команде, ведущей счет багов на сотни
или даже тысячи, то идея «без багов» звучит для вас Вся команда
смешно. Признаю: без багов — это идеал, к которому
надо стремиться, а не то, чего ваша команда непременно достигнет в полной мере.
Какие-то баги будут всегда. (Или дефекты; я использую «баг» и «дефект» как взаи
мозаменяемые термины.)
Но вы можете приблизиться к идеалу «без багов» гораздо больше, чем вам кажет-
ся. Рассмотрим опыт Нэнси ван Шондерворт с экстремальным программированием.
Она вела команду новичков, работавших над встроенной системой для сельскохо-
зяйственных комбайнов, действующей в режиме реального времени: параллельной
системой, написанной на С, с некоторой сборкой. Если это не рецепт разведения
багов, то не знаю, что еще может им быть. Согласно ее анализу данных по Каперсу
Джонсу, средняя команда разработчиков этого ПО произвела бы 1035 дефектов
и 207 поставила бы заказчику.
Вот что произошло на самом деле.
Команда GMS поставила этот продукт после трех лет разработки, столкнувшись
за это время всего с 51 дефектом. Открытый список багов никогда не содержал
больше двух единиц одновременно. Измерения продуктивности демонстри-
ровали результат, почти втрое превышавший уровни команд, работающих над
сопоставимым встраиваемым ПО. Первые модули для полевых тестов были
поставлены примерно через шесть месяцев разработки. После этого команда
разработки поддерживала другие дисциплины инжиниринга, продолжая улуч-
шения ПО [VanSchooenderwoert2006].
КЛЮЧЕВАЯ ИДЕЯ
Встроенное качество
«Дешево, быстро или хорошо, — гласит поговорка. — Выберите два».
Десятилетиями люди думали о качестве как о чем-то стоящем дополнительных де-
нег. Чем больше времени и денег вы тратите, тем выше качество можете получить.
И в какой-то степени это правда. Если ваш подход к качеству — протестировать
работу после завершения, то чем больше времени вы тратите на тестирование
и исправление, тем больше багов устраняете.
Но это не единственный путь к качеству. Встраивая качество с самого начала, вы
получаете более высокое качество за меньшие деньги и время. Конечно, встраи
вание качества отнимает время, но оно также ликвидирует затраты времени на
поиск и устранение багов постфактум. Вы получаете чистую выгоду.
«Дешево, быстро или хорошо». Вы можете заполучить все три.
Однако для ваших целей даже это отличие не имеет значения. Если что-то требует
работы, то получает карточку истории. Вот и все, что нужно.
Роль тестировщика
Так как команды, обладающие навыками на уровне поставки, скорее встраивают
качество, чем тестируют на ошибки, люди с навыками тестировщиков делают сдвиг
влево. Вместо того чтобы направлять свои навыки на завершенный продукт, они со-
средоточиваются на том, чтобы помогать команде создавать качественный продукт
с самого начала.
По моему опыту, некоторые тестировщики ориентированы на бизнес: они очень
заинтересованы в том, чтобы правильно понимать бизнес-требования. Они работают
с заказчиками в команде, чтобы выявить все мельчайшие подробности, которые в про-
тивном случае заказчик бы упустил. В ходе обсуждения требований такие специалисты
часто подсказывают людям, что нужно подумать о граничных случаях.
Другие тестировщики больше ориентированы на технические аспекты. Они
заинтересованы в автоматизации тестирования и нефункциональных требовани-
ях. Эти тестировщики служат техническими исследователями команды. Они
создают испытательные стенды, которые изучают такие задачи, как масштабиру-
емость, надежность и производительность. Они просматривают журналы событий,
чтобы понять, как система ПО работает в эксплуатационной среде. Таким образом
эти тестировщики помогают команде понять поведение их ПО и решить, когда
уделить больше внимания эксплуатации, безопасности или нефункциональным
историям.
Тестировщики также помогают команде
обнаруживать слепые зоны. В целом исполь- См. также
зовать техники обнаружения таких зон может
кто угодно в команде, однако люди с навы- Обнаружение слепых зон (глава 16)
ками тестирования, как правило, особенно
хороши в этом.
Правильное мироощущение
Я поощряю особое мироощущение в своих
командах — немного элитарности, даже сно- Баги — это для других.
бизма. Его можно кратко описать следующим
образом: «Баги — это для других».
Если вы делаете все, что я описал, то баги должны быть редкостью. Ваш следу-
ющий шаг — относиться к ним именно так. Вместо того чтобы пожимать плечами,
когда возникает баг («Ах, да, еще один баг, в программах это бывает»), вы должны
быть потрясены и обескуражены. Баги — это не то, что нужно терпеть; это признак
наличия фундаментальных проблем, которые нужно решить.
578 Часть III. Надежная поставка
Вопросы
Как нам предотвращать дефекты безопасности и другие сложные баги?
Моделирование угроз (см. подраздел «Моделирование угроз» ранее в текущей
главе) может помочь вам подумать об изъянах в системе безопасности заранее. О про-
блемах, требующих решения, вам могут напоминать чек-лист «сделано сделано»
и установленные вами стандарты кодирования. Однако таким образом вы сможете
предотвращать только те баги, кото-
рые думали предотвратить. Безопас- См. также
ность, параллелизм и другие сложные
проблемные области могут порождать Сделано Сделано (глава 9)
дефекты, о которых вы никогда даже Согласование (глава 7)
не подозревали. Вот почему так важно
Обнаружение слепых зон (глава 16)
обнаруживать слепые зоны.
Как нам отслеживать наши баги?
Для новых багов вам вряд ли понадобится база данных багов или трекер проблем,
при условии, что ваша команда не генерирует множество багов. (Если генерирует, то
сначала сконцентрируйтесь на решении той проблемы.) Если баг слишком велик,
чтобы исправить его сразу, то превратите его в историю и отслеживайте детали та-
ким же образом, каким обрабатываете детали других требований.
Как долго мы должны работать над багом, прежде чем превратить его в историю?
Это зависит от того, какой резерв
времени у вас в наличии. В начале ите-
рации, когда такого резерва много, я мог См. также
потратить полдня на дефект, прежде
чем превратить его в историю. Позже, Резерв времени (глава 9)
когда резерва оставалось меньше, я мог
потратить на него только 10 минут.
Глава 16. Качество 579
У нас много устаревшего кода. Как нам освоить политику «без багов» и при этом
не сойти с ума?
Это потребует времени. Начните с изучения вашей базы данных багов и опреде-
лите те, которые вы хотите исправить в текущем релизе. Запланируйте по крайней
мере одно исправление каждую неделю, стараясь исправить их как можно раньше,
а не позже.
Каждую неделю или две произвольно
выбирайте какой-либо недавний баг, чтобы См. также
провести анализ инцидентов хотя бы нефор-
мально. Это позволит вам постепенно улуч- Анализ инцидентов (глава 16)
шать вашу систему разработки и предот
вращать баги в будущем.
Предварительные требования
«Без багов» — культура совершенства. Она может существовать только внутри ко-
манды. Руководители, не просите ваши команды отчитываться о количестве дефек-
тов и не награждайте и не наказывайте их на основе количества имеющихся у них
дефектов. Это приведет к тому, что дефекты будут скрыты и качество ухудшится,
а не улучшится. Я буду говорить об этом дальше в подразделе «Ответственность за
инциденты» главы 16.
Достижение идеала «без багов» зависит от огромного количества практик Agile —
по сути, от каждой практики фокусировки и поставки, описанной в этой книге. До тех
пор, пока ваша команда не достигнет компетентности в этих практиках, не ждите
значительного снижения дефектов.
В то же время если вы используете практики фокусировки и поставки, то по-
явление новых багов в количестве, большем, чем несколько штук в месяц, может
говорить о проблеме с вашим подходом. Конечно, вам понадобится время, чтобы
научиться этим практикам и усовершенствовать свой процесс, но вы должны
увидеть улучшение, касающееся количества ваших багов, в течение нескольких
месяцев. Если не увидите, то сверьтесь с врезкой «Руководство по устранению
неполадок» в главе 4.
Показатели
Когда в вашей команде есть культура «без багов»:
zz ваша команда уверена в качестве своего ПО;
zz вам комфортно делать релизы в эксплуатационную среду без фазы ручного те-
стирования;
zz стейкхолдеры, заказчики и пользователи редко встречаются с неприятными
сюрпризами;
zz ваша команда тратит свое время на производство отличного ПО, а не на борьбу
с авралами.
580 Часть III. Надежная поставка
Альтернативы и эксперименты
Одна из революционных идей Agile подразумевает, что ПО с низким количеством
дефектов может быть дешевле производить, чем ПО с большим количеством дефек-
тов. Это становится возможным с помощью встраивания качества. Чтобы поэкспери-
ментировать еще больше, посмотрите на те части вашего процесса, в конце которых
проверяется качество, и поищите способ, как встроить это качество в самом начале.
Вы также можете снизить количество багов, используя еще больше высоко
качественного тестирования для поиска и исправления все большего процента ба-
гов. Однако это работает не так хорошо, как встраивание качества с самого начала.
К тому же это вас замедлит и затруднит релизы.
Некоторые компании, пытаясь улучшить качество, инвестируют в отдельные
команды по контролю качества. Случайное независимое тестирование может быть
полезно для обнаружения слепых зон, однако отдельная команда, контролирующая
качество, — не очень хорошая идея. Парадоксально, но это ведет к снижению каче-
ства, поскольку команда разработки сама тратит меньше усилий на качество. Этот
феномен исследует Элизабет Хендриксон в отличной статье Better Testing, Worse
Quality? [Hendrickson2000].
Подтвержденное знание
Думая о багах, люди часто представляют себе ошибки логики, ошибки UI или кри-
тические сбои в эксплуатационной среде. Но та слепая зона, которую я вижу чаще
всего, более фундаментальная и более трудноуловимая.
Чаще всего команды создают не то, что надо. Используя терминологию береж-
ливого стартапа, им не хватает соответствия продукта рынку. Я думаю, это проис-
Глава 16. Качество 581
ходит потому, что многие команды думают о своей работе как о создании продукта,
который им приказали создать. Они действуют как послушные исполнители при-
казов: фабрика программного обеспечения, спроектированная поглощать истории на
входе и выпускать готовое ПО на выходе.
Не считайте, что ваша команда должна
создавать то, что ей приказали создать. Луч- Никто на самом деле не знает, что
ше предположите обратное: никто на самом вы должны создать, даже люди,
деле не знает, что вы должны создать, даже которые просят об этом.
люди, которые просят об этом. Работа вашей
команды состоит в том, чтобы взять идеи, протестировать их и узнать, что вам на
самом деле нужно сделать. Перефразируя The Lean Startup1 [Ries2011], фундаменталь-
ная деятельность любой команды Agile — превращать идеи в продукты, наблюдать
за реакцией заказчиков и пользователей и затем решать, что делать дальше: разво-
рачиваться или продолжать двигаться в этом направлении. Это называется под-
твержденным знанием.
Многие команды первый раз тестируют
свои идеи в тот момент, когда выполняют См. также
релиз своего ПО. Это довольно рискованно.
Цель (глава 7)
Лучше использовать цикл Риса «создать —
измерить — изучить» (Build-Measure-Learn). Визуальное планирование (глава 8)
1. Создать. Посмотрите на цель и план ва- Вовлечение реального заказчика
шей команды. Каковы ваши базовые пред- (глава 8)
положения о вашем продукте, заказчике
и пользователях? Выберите для тестирования одно из них, а потом подумайте:
«Какой самый маленький элемент мы можем продемонстрировать реальным за-
казчикам и пользователям?» Это не обязательно должен быть реальный продукт
(в некоторых случаях вполне подойдут макет или бумажный прототип), и вам
не обязательно вовлекать каждого пользователя, но нужно вовлечь людей, которые
на самом деле будут покупать и использовать ваш продукт.
2. Измерить. Прежде чем показывать людям, что вы создали, решите, какие данные
вам нужно увидеть, чтобы сказать, подтвердились ваши предположения или нет.
Данные могут быть субъективными, но измерения должны быть объективными.
Например, «70 % наших заказчиков говорят, что нас любят» — объективное из-
мерение субъективных данных.
3. Изучить. Ваши измерения будут либо подтверждать вашу гипотезу, либо опро-
вергать ее. Если вы подтвердили гипотезу, то переходите к следующей. Если
опровергли, измените свои планы соответствующим образом.
Например, целью одной команды было улучшить результаты хирургического лече-
ния позвоночника. Команда планировала сделать это, создав инструмент, который по-
зволит руководству клиник смотреть на хирургические данные с разных точек зрения.
Одним из базовых предположений этой команды было то, что клиники будут доверять
исходным данным, представленным этим инструментом. Но данные могли оказаться
скудными, и руководители клиник, как правило, относились к ним скептически.
1
Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.
582 Часть III. Надежная поставка
Исследовательское тестирование
Разработка через тестирование гарантиру-
ет, что код, написанный программистами, См. также
будет делать то, что они от него хотят. Но
что, если намерения программистов невер- Разработка через тестирование
(глава 13)
ны? Например, программист может думать,
что правильный способ определить длину
строки в JavaScript — это использовать string.length, но это может привести к тому,
что в слове naïve будет насчитано шесть букв1.
«Исследовательское тестирование» — это техника для поиска подобных слепых
зон. Это скрупулезный подход к тестированию, подразумевающий «планирование
и выполнение быстрой последовательности крошечных экспериментов, где резуль-
таты предыдущего эксперимента используются в качестве вводной информации
для следующего» [Hendrickson2013] (гл. 1). Эта техника состоит из следующих шагов.
1. Устав. Начните с решения, что вы собираетесь исследовать и почему. Новую тех-
нологию, недавно освоенную командой? Недавно выпущенный пользовательский
интерфейс? Критический фрагмент инфраструктуры безопасности? Ваш устав
должен быть достаточно общим, чтобы обеспечить вас работой на час или два,
и достаточно конкретным, чтобы помочь вам сфокусироваться.
2. Наблюдение. Используйте ПО. Чаще всего вы будете делать это через UI, но также
можете использовать инструменты, чтобы исследовать API и сетевой трафик;
1
Подсчет может быть ошибочным, поскольку string.length считает количество кодовых точек (что-
то вроде того), а не количество графем (того, что люди обычно считают символами), а Unicode
может хранить графему как две кодовые точки: обычное i плюс комбинированный диэрезис
(умлаут). Обработка строки имеет аналогичные проблемы. Инвертирование строки, содержащей
испанский флаг, превратит Испанию в Швецию , что наверняка удивит любителей
пляжного отдыха.
Глава 16. Качество 583
Хаос-инжиниринг
В большой сетевой системе сбои — ежедневное явление. Ваш код должен быть за-
программирован на устойчивость к ним, а это требует особого внимания к обработке
ошибок и отказоустойчивости. К сожалению, обработка ошибок — общая слепая зона
для не очень опытных программистов и команд, и даже опытные команды не могут
прогнозировать каждый случай отказа сложной системы.
Хаос-инжиниринг можно считать особой формой исследовательского тестирова-
ния, которое фокусируется на системной архитектуре1. В него входит умышленное
внесение сбоев в работающие системы (зачастую живые эксплуатационные системы)
с целью узнать, как они реагируют на сбой. Хотя такие действия кажутся рискованны-
ми, их можно выполнять контролируемо. Это позволяет вам обнаружить проблемы,
появляющиеся только в результате сложных взаимодействий.
Хаос-инжиниринг похож на исследовательское тестирование тем, что включает
в себя поиск возможностей, позволяющих изменить нормальное поведение. Однако
вместо того, чтобы думать в терминах непредвиденных данных, введенных пользо-
вателем, или вызовов по API, вы думаете в терминах непредвиденного поведения
1
Некоторые люди из сообщества хаос-инжиниринга возражают против использования слова «те-
стирование» в отношении хаос-инжиниринга. Они предпочитают термин «эксперимент». Я думаю,
это возражение возникло из-за неправильного понимания природы тестирования. Как пишет
Элизабет Хендриксон в Explore It!: «Суть тестирования вот в чем: проектировать эксперимент
для сбора эмпирических свидетельств, чтобы ответить на вопрос о риске» [Hendrickson2013]
(гл. 1). Это именно то, чем является и хаос-инжиниринг.
584 Часть III. Надежная поставка
Вопросы
Эти техники должны выполняться индивидуально, в парах или группах?
Это зависит от вашей команды. Эти техники вполне можно выполнять индиви-
дуально. В то же время парное и групповое программирование позволяют получать
и распространять новые идеи и могут помочь
сломать барьеры, которые часто образуются См. также
между тестировщиками и другими членами
команды. Поэкспериментируйте, чтобы уви- Парное программирование (глава 12)
деть, какой подход лучше всего работает для
Групповое программирование
вашей команды. Он может варьироваться (глава 12)
в зависимости от техники.
586 Часть III. Надежная поставка
Предварительные требования
Любая команда может использовать эти техники. Но помните, что они нужны для
обнаружения слепых зон, а не для проверки, что ПО работает. Не позволяйте им стать
узким местом. Вам не нужно делать проверки перед релизом, и вам не нужно про-
верять все. Вы ищете изъяны в вашей системе разработки, а не в системе вашего ПО.
С другой стороны, релиз без дополнительных
проверок требует от вашей команды способности
См. также
производить код практически с нулевым уровнем
багов. Если вы пока еще не дошли до этого или Без багов (глава 16)
просто не готовы, то вполне можете отложить
релиз до тех пор, пока не проверите наличие слепых зон. Просто удостоверьтесь,
что не используете практику обнаружения слепых зон как костыль. Исправляйте
свою систему разработки так, чтобы вы могли делать релиз, не прибегая к ручному
тестированию.
Показатели
Когда вы хорошо используете практику обнаружения слепых зон:
zz команда доверяет качеству своего ПО;
zz команда не использует практику обнаружения слепых пятен как форму тести-
рования перед релизом;
zz количество дефектов, обнаруженных в эксплуатационной среде и с помощью
техники слепых зон, со временем снижается;
zz количество времени, необходимое для обнаружения слепых пятен, со временем
снижается.
Альтернативы и эксперименты
Эта практика основана на предположении, что
разработчики вполне могут создавать системы См. также
практически без багов, дефекты — это результат
исправимых слепых зон, а не недостатка ручного Без багов (глава 16)
тестирования. Таким образом, техники направ- Разработка через тестирова-
лены на обнаружение сюрпризов и проверку ние (глава 13)
гипотез.
Глава 16. Качество 587
АНАЛИЗ ИНЦИДЕНТОВ
Аудитория
Мы учимся на ошибках.
Вся команда
Несмотря на все ваши усилия, ПО иногда будет
отказываться работать так, как должно. Некоторые
сбои будут мелкими, вроде опечатки на веб-странице. Другие — более значительными,
такими как код, который повреждает данные заказчика, или сбой, препятствующий
доступу заказчиков.
Одни сбои называют багами или дефектами, другие — инцидентами. Различие
не особенно важно. В любом случае, как только страсти улягутся и все снова будет
идти гладко, вам нужно будет выяснить, что случилось и как вы можете это испра-
вить. Это и есть анализ инцидентов.
ПРИМЕЧАНИЕ
Подробности того, как реагировать во время инцидента, выходят за рамки этой
книги. Отличное практическое руководство по реагированию на инциденты — Site
Reliability Engineering: How Google Runs Production Systems [Beyer2016], особенно
главы 12–14.
КЛЮЧЕВАЯ ИДЕЯ
Примите сбой
Команды Agile понимают, что сбои неизбежны. Люди делают ошибки; возникают
недопонимания; идеи не срабатывают.
Вместо того чтобы вовлекаться в идеалистический квест в надежде избежать
сбоя, команды Agile принимают его возможность. Если он неизбежен, то самое
важное — обнаружить его как можно быстрее; получить ошибку на раннем этапе,
пока еще есть время на восстановление, противостоять сбою, чтобы последствия
были минимальными; и учиться на ошибке, а не искать виноватого.
588 Часть III. Надежная поставка
Природа сбоя
Всегда есть соблазн думать о сбое как о ре-
зультате простой причинно-следственной Сбой — следствие специфики всей
связи. А сделал нечто, приведшее к Б, а это, вашей системы разработки.
в свою очередь, привело к В — однако на
самом деле все происходит не так1. В реальности сбой — следствие специфики всей
вашей системы разработки, в которой выполняется работа. (Ваша система разра-
ботки — это все аспекты того, как вы создаете ПО, начиная с инструментария и за-
канчивая организационной структурой. Система разработки отличается от вашей
системы ПО, которую вы создаете.) Каждый сбой, каким бы незначительным ни был,
содержит подсказку о характере и слабых местах этой системы разработки.
Сбой — результат множества взаимодействующих событий. Мелкие проблемы
происходят постоянно, но система имеет стандарты, которые удерживают их в преде-
лах безопасных границ. Программист делает ошибку смещения на единицу, но его
напарник предлагает тест, который ее находит. Локальный заказчик плохо объясняет
историю, но позже во время обсуждения с заказчиками замечает недопонимание.
Член команды случайно стирает файл, но непрерывная интеграция отклоняет под-
тверждение (коммит).
Сбой возникает не из-за одной причины, а потому что много всего одновременно
пошло не так. Программист делает ошибку смещения на единицу, и его напарник
засиделся допоздна с новорожденным и не заметил ошибку, и команда эксперимен-
тирует с менее частыми переключениями пар, и оповещения канареечных серверов
случайно были отключены. Сбои возникают не из-за проблем, а потому что система
разработки (люди, процессы и бизнес-среда) позволяют проблемам объединиться.
Более того, системы демонстрируют тенденцию к отказу. Как ни странно, для
команд, имеющих опыт противостояния отказам, угрозу представляют не ошиб-
ки, а успех. Со временем при отсутствии отказов стандарты команды меняются.
Например, команда может сделать работу в парах необязательной, чтобы дать
людям больше возможностей выбора рабочего стиля. Их безопасные границы
1
Мое обсуждение природы неудач основано на [Woods2010] и [Dekker2014].
Глава 16. Качество 589
сужаются. В конечном итоге условия отказа (которые существовали все это время!)
соединяются таким образом, что преодоление этих границ становится возможным,
и возникает отказ.
Тенденцию к отказу трудно заметить. Каждое изменение — маленькое и в каком-
то другом измерении является улучшением, как, например, скорость, стоимость,
удобство или удовлетворенность заказчика. Чтобы предотвратить эту тенденцию,
вы должны сохранять бдительность. Успехи в прошлом не гарантируют успеха в бу-
дущем.
Вы можете ожидать, что крупные сбои
являются результатом больших ошибок, Маленькие сбои — нечто вроде
но это не так. Единственной причины нет, «генеральной репетиции»
как нет и пропорциональности. Крупные для больших.
сбои — результат тех же системных проблем,
свойственных маленьким сбоям. Это хорошая новость, поскольку это значит, что
маленькие сбои — нечто вроде «генеральной репетиции» для больших. Вы можете
научиться у них тому же, чему и у больших.
Таким образом, рассматривайте каждый сбой как возможность учиться и совер-
шенствоваться. Опечатка — это сбой. Проблема, обнаруженная перед релизом, — тоже
сбой. Неважно, большая она или маленькая. Если ваша команда думает, будто что-то
«сделано» и это что-то позже нуждается в исправлении, то ситуация заслуживает
анализа.
Но все еще глубже. Сбой — следствие устройства вашей системы разработки, как
я уже сказал, но и успехи тоже. Вы можете проанализировать и их.
Проведение анализа
Анализ инцидентов — вид ретроспективы.
Это ваш совместный взгляд назад на вашу См. также
систему разработки с целью изучения и со-
вершенствования. Учебник. Соответственно, Ретроспективы (глава 11)
эффективный анализ подразумевает пять
стадий ретроспективы [Derby2006].
1. Подготовить условия.
2. Собрать данные.
3. Генерировать идеи.
4. Решить, что делать.
5. Завершить ретроспективу.
Пригласите для участия в сессии анализа всю вашу команду, а также всех, кто уча-
ствует в реагировании на инцидент. Избегайте присутствия руководителей и любых
других представителей руководства; вам нужно, чтобы участники могли высказаться
и открыто признать ошибки, а это требует ограниченного круга участников, в кото-
рый входят только те, кто необходим. Если анализ вызовет большой интерес, то вы
можете создать отчет об инциденте; я расскажу подробности чуть позже.
Время, необходимое для сессии анализа, зависит от количества событий, которые
привели к инциденту. Сложные критические сбои могут иметь десятки событий
и занимать несколько часов. Однако простой дефект может состоять всего из не-
скольких событий и занять 30–60 минут. По мере накопления опыта вы будете
делать все быстрее.
В самом начале и в случаях рассмотрения деликатных инцидентов сессию должен
ввести нейтральный фасилитатор. Чем деликатнее инцидент, тем более опытным
должен быть фасилитатор.
ПРИМЕЧАНИЕ
Эта практика, как и все в данной книге, ориентирована на инциденты командного
уровня — те, которые команда может анализировать самостоятельно. Вы также
можете использовать ее для анализа участия вашей команды в более крупном
инциденте.
1. Подготовить условия
Анализ инцидентов подразумевает критиче-
ский взгляд на успехи и неудачи. Поэтому См. также
каждому участнику жизненно необходимо
чувствовать себя в безопасности, чтобы вне- Безопасность (глава 7)
сти свой вклад, включая откровенные обсуж-
дения принятых решений. Начните сессию, напомнив каждому, что ее цель состоит
в том, чтобы с помощью инцидента лучше понять, как вы создаете ПО — вашу си-
стему разработки, состоящую из людей, процессов, ожиданий, окружающей среды
Глава 16. Качество 591
Вдобавок подумайте о том, чтобы установить правило Вегаса: все, что сказано на
сессии анализа, остается на сессии анализа. Не записывайте ее и попросите участ-
ников согласиться на нераспространение никаких личных подробностей, которыми
люди будут делиться во время сессии.
Если в сессии участвуют люди, не состоящие в вашей команде, или если ваша
команда только начинает работать вместе, то вы также можете заключить рабочие
соглашения на время сессии. (См. пункт «Создайте рабочие соглашения» главы 7.)
2. Собрать данные
Как только условия будут подготовлены, ваш следующий шаг — понять, что случи-
лось. Вы делаете это с помощью создания визуальной хронологии событий с ком-
ментариями.
На данной стадии люди будут испы-
тывать соблазн начать интерпретировать Сосредоточьтесь на фактах,
данные, но важно, чтобы все оставались а не на интерпретациях.
сконцентрированы «только на фактах».
Возможно, понадобится множество раз напомнить об этом по мере продвижения по
данной стадии. Очень легко увлечься и начать задним числом критиковать действия
людей, но это не поможет. Успешный анализ фокусируется на понимании того, что
люди действительно сделали и какой вклад в их действия внесла ваша система раз-
работки, а не на том, что они могли бы сделать по-другому.
Чтобы создать временну́ю шкалу, начните с организации длинного горизонталь-
ного пространства на вашей виртуальной доске. Если вы проводите очную сессию,
то наклеивайте голубую клейкую ленту на большой участок стены. Разделите шкалу
на столбцы, представляющие разные периоды времени. Столбцы не обязательно
должны быть равномерными; недели или месяцы часто больше подходят для начала
шкалы, а для моментов, предшествующих инциденту, возможно, лучше использовать
часы или дни.
Предложите участникам провести одновременный мозговой штурм, чтобы по-
думать о событиях, имеющих отношение к инциденту. (См. пункт «Работайте одно-
временно» главы 7.) События — это фактические безоценочные заявления о чем-то,
что произошло, например: «Скрипт развертывания останавливает все экземпляры
ServiceGamma», «ServiceBeta возвращает код ответа 418», «ServiceAlpha не распоз-
нает код ответа 418 и дает сбой», «Дежурный инженер получает сообщение о сбое
системы» и «Дежурный инженер вручную перезапускает экземпляры ServiceGamma».
592 Часть III. Надежная поставка
(Вы можете использовать имена участвовавших людей, но только если они при этом
присутствуют и согласны.) Постарайтесь также охватить события, которые прошли
хорошо, а не только те, которые прошли плохо.
Программные журналы, записи реагирования на инциденты и история контроля
версий могут быть для вас источниками вдохновения. Запишите каждое событие
на отдельном стикере и прикрепите его на доску. Для всех событий используйте
стикеры одного цвета.
После этого предложите всем сделать шаг назад и взглянуть на картину в целом.
Каких событий не хватает? Работая одновременно, посмотрите на каждое событие
и спросите: «Что было перед этим? Что было после?» Каждое дополнительное со-
бытие добавляйте в виде еще одного стикера. Вы можете посчитать полезным по-
казать взаимоотношения «до/после» с помощью стрелок.
Не забудьте включить события с участием
людей, а не только ПО. Решения людей — важней-
ший фактор в вашей системе разработки. Найдите Как использовалась
автоматизация? Настроена?
каждое событие, в котором задействована авто-
Запрограммирована?
матизация, контролируемая или используемая
вашей командой, затем добавьте предыдущие
события, показывающие, какой вклад в то событие внесли люди. Как использовалась
автоматизация? Настроена? Запрограммирована? Не забудьте излагать события
нейтральным тоном, без обвинений. Не гадайте, что люди должны были сделать;
записывайте только то, что они на самом деле сделали.
Например, событию «Скрипт развертывания останавливает все экземпляры
ServiceGamma» могло предшествовать «Оператор сделал опечатку в параметре
командной строки --tagre вместо --target» и «Инженер ошибочно изменяет скрипт
развертывания, чтобы остановить все экземпляры, когда параметр --target не обнару-
жен», которому, в свою очередь, предшествовало событие «Команда решает очистить
обработку командной строки скрипта развертывания».
Событиям могут предшествовать несколько других, связанных с одним и тем же
событием. Каждое предшествующее событие может произойти в разных точках
временной шкалы. Например, событию «ServiceAlpha не распознает код ответа 418
и дает сбой» могли предшествовать три: «ServiceBeta возвращает код ответа 418»
(непосредственно перед); «Инженер ошибочно отключает обработчик исключений
верхнего уровня ServiceAlpha» (несколькими месяцами ранее); и «Инженер про-
граммирует ServiceAlpha для выдачи исключения при получении неожиданного
кода ответа» (год назад).
Когда события добавлены, предложите участникам поделиться своими воспо-
минаниями и эмоциями на тот момент. Не просите людей оправдать свои действия;
вы здесь не для того, чтобы найти виноватых. Попросите их объяснить, каково это
было, находиться там, в тот момент, когда событие произошло. Это поможет вашей
команде понять социальные и организационные аспекты вашей системы разработ-
ки — не только какие решения были приняты, но и почему.
Попросите участников добавить дополнительные стикеры, другого цвета, для
этих мыслей. Например, если Джарретт сказал: «Я беспокоился о качестве кода, но
чувствовал, что нужно спешить, чтобы уложиться в срок», — то мог бы написать два
стикера: «Джарретт обеспокоен качеством кода» и «Джарретт чувствует, что нужно
Глава 16. Качество 593
спешить, чтобы уложиться в срок». Не угадывайте мысли тех людей, кто не присут-
ствует, но вы можете записать то, что они говорили в тот момент, например: «Лейла
говорит, что ей трудно запомнить параметры скрипта развертывания».
Сосредоточьтесь на том, что люди чувствовали и думали в тот момент. Ваша
цель — понять систему такой, какой она была на самом деле, а не критиковать людей
задним числом.
В конце попросите участников выделить в хронологии важные события — те,
которые кажутся наиболее относящимися к инциденту. Еще раз удостоверьтесь, что
люди запечатлели все свои воспоминания о тех событиях.
3. Генерировать идеи
Теперь пришло время превратить факты в идеи. На этой стадии вы будете изучать
временную шкалу на предмет подсказок о своей системе разработки. Прежде чем
начать, дайте людям немного времени на изучение доски. В этот момент можно
сделать перерыв.
Начните с напоминания участникам
о природе сбоев. Проблемы возникают все События не причина неудачи;
гда, но обычно не соединяются таким об- они являются симптомом того, как
разом, чтобы приводить к серьезному сбою. функционирует ваша система.
События в вашей хронологии не причина
неудачи, они являются симптомом того, как функционирует ваша система разработки.
Это именно та, более глубокая система, которую вы хотите анализировать.
Взгляните на события, которые вы определили как важные во время стадии сбора
данных. В каких из них фигурируют люди? Продолжая предыдущий пример, вы бы
выбрали события «Оператор сделал опечатку в параметре командной строки --tagre
вместо --target» и «Инженер ошибочно изменяет скрипт развертывания, чтобы
остановить все экземпляры, когда параметр --target не обнаружен», а не «Скрипт
развертывания останавливает все экземпляры ServiceGamma», поскольку это со-
бытие случилось автоматически.
Работая одновременно, присвойте каждому из событий с участием людей одну или
несколько следующих категорий1. Запишите каждую категорию на стикер третьего
цвета и добавьте его на доску.
zz В категорию «Модели знаний и ментальные модели» входит информация и реше-
ния внутри команды, вовлеченной в событие. Например, уверенность в том, что
сервис, поддерживаемый командой, никогда не возвратит ответ 418.
zz В категорию «Коммуникация и обратная связь» входит информация и решения
снаружи команды, вовлеченной в событие. Например, уверенность в том, что
сторонний сервис никогда не возвратит ответ 418.
zz Категория «Внимание» включает в себя возможность сосредоточиться на актуаль-
ной информации. Например, игнорирование аварийного оповещения из-за того,
что в тот же самый момент пришли несколько других оповещений, или неверное
понимание важности оповещения вследствие усталости.
1
Идеи категорий событий почерпнуты из [Woods2010] и [Dekker2014].
594 Часть III. Надежная поставка
1
Спасибо Саре Хоран Ван Трис, предложившей большинство из этих вопросов.
596 Часть III. Надежная поставка
командной строки всех скриптов команды». Одни из этих идей лучше, чем другие,
но на этой стадии вы генерируете идеи, а не фильтруете их.
Как только у вас будет набор параметров, сгруппируйте их в круги «контроль»,
«влияние» и «суп» в зависимости от способности вашей команды влиять на их по-
явление, как описано в подразделе «Круги и суп» главы 11. Вкратце обсудите все за
и против каждого параметра. Затем решите, каким параметрам ваша команда будет
следовать, используя точечное голосование, затем единогласное голосование (см.
пункты «Работайте одновременно» и «Стремитесь к согласию» главы 7). Вы можете
выбрать несколько параметров.
Когда будете думать, что выбрать, помните, что вы не должны исправлять все.
Иногда изменение более рискованно или затратно, чем те недостатки, которые оно
исправляет. Кроме того, хотя каждое событие — это информация о поведении вашей
системы разработки, не всякое событие является чем-то плохим. Например, одно из
событий в примере было «Инженер программирует ServiceAlpha на выдачу исклю-
чения при получении неожиданного кода ответа». Хотя это событие напрямую вело
к аварии, оно ускорило и упростило диагностику сбоя. Без него что-то все равно бы
могло пойти не так, а на решение проблемы ушло бы больше времени.
Предотвращение сбоя
Если вы раздумываете о вариантах того, что ваша команда может сделать, то по-
думайте о способах изменить ваш код или дизайн таким образом, чтобы сделать
ошибки невозможными. Например, представьте, что вы обнаружили потерю
данных в текстовом поле. Люди могли ввести 500 символов, но только первые
250 сохранялись в базе данных. Отчасти причина была в том, что фронтенд был
случайно настроен на неверную длину. Вы могли сделать эту ошибку невозмож-
ной, автоматически подтягивая длину из метаданных бэкенда.
Когда вы не можете сделать ошибку невозможной, попробуйте обнаруживать
их автоматически, обычно усовершенствовав вашу сборку или набор тестов.
Например, вы можете написать тест, просматривающий все шаблоны фронтенда
и проверяющий и сравнивающий длины полей с базой данных.
Не останавливайтесь непосредственно на данной ошибке. Подумайте о том, что
она говорит о системе разработки вашей команды. Например, еще одна причина
потери данных была в том, что бэкенд не проверял длины полей. Не значит ли
это, что есть проблема с проверкой полей в целом? Некоторые из ваших вари-
антов могут подразумевать дальнейшее изучение, например исследовательское
тестирование, предназначенное для углубленной проверки данных.
5. Завершить ретроспективу
Анализ инцидента может быть напряженным. Завершая ретроспективу, дайте людям
возможность сделать вдох и плавно вернуться к своей повседневной работе. Этот
вдох может быть метафорическим, или вы можете буквально предложить, чтобы
люди встали и сделали глубокий вдох.
Глава 16. Качество 597
Начните с решения о том, что оставить. Снимок экрана или фото временной
шкалы с комментариями и другие артефакты, вероятно, пригодятся вам в будущем.
Сначала пригласите участников взглянуть на шкалу, чтобы выяснить, нет ли там
чего-либо, что они не хотели бы выносить за пределы сессии. Уберите эти стикеры,
прежде чем делать фото.
Далее решите, кто и как будет отслеживать принятые решения. Если ваша команда
будет готовить отчет, то решите, кто будет участвовать в его написании.
В конце завершите сессию, выразив признательность друг другу за трудную
работу1. Объясните упражнение и приведите пример: «(Имя), я признателен тебе
за (причина)». Сядьте и подождите. Другие тоже должны высказаться. Говорить
необязательно, но оставьте в конце ретроспективы достаточно времени (минуту
или около того тишины), поскольку людям может потребоваться некоторое время,
чтобы высказаться.
Некоторые считают упражнение «Признательность» некомфортным для себя.
В качестве альтернативы каждый участник может по очереди сказать несколько слов
о том, что он или она чувствуют теперь, когда анализ завершен. Это можно пропустить.
В завершение поблагодарите каждого за участие. Напомните им о правиле Вегаса
(не делиться личными подробностями без разрешения) и закончите на этом.
Обучение организации
Организации часто требуют отчет о выводах, сделанных в ходе анализа инцидентов.
Он обычно называется постмортем-отчетом, но я предпочитаю более нейтральный
термин «отчет об инциденте».
В теории отчасти цель этого отчета об инциденте — дать другим командам воз-
можность использовать то, чему вы научились, для совершенствования их системы
разработки. К сожалению, люди склонны игнорировать уроки, полученные другими
командами. Это называется дистанцированием через дифференцирование (distancing
through differencing) [Woods2010] (гл. 14). «Эти идеи не применимы к нам, поскольку
мы — команда, ориентированная на внутренние задачи, а не на внешние», или «У нас
микросервисы, а не монолит», или «Мы работаем удаленно, а не в офисе». Поверх-
ностные различия легко использовать как причину, позволяющую уклониться от
изменений.
Предотвращение этого дистанцирования — вопрос организационной культуры,
что выходит за рамки этой книги. Однако, если говорить коротко, люди больше всего
жаждут учиться и меняться после крупного сбоя. Кроме этого, я добивался макси-
мального успеха, сделав уроки персональными. Покажите, как эти уроки влияют на
то, что беспокоит вашу аудиторию.
Это легче сделать в форме разговора, чем письменного документа. На практике,
я подозреваю (но наверняка не знаю!), наиболее эффективный способ заставить
людей прочитать уроки из отчета об инциденте и применить их — рассказать захва-
тывающую, но короткую историю. Разъясните с самого начала, что поставлено на
карту. Опишите, что случилось, и позвольте интриге раскрыться. Опишите, что вы
1
Упражнение «Признательность» основано на [Derby2006] (гл. 8).
598 Часть III. Надежная поставка
узнали о своей системе, и объясните, как это влияет на другие команды. Опишите
потенциальные ставки для других команд и кратко изложите, что они могут сделать,
чтобы защитить себя.
Ответственность за инциденты
Еще одна причина, почему организации хотят получить отчет об инциденте, — «при-
влечь людей к ответственности». Это в лучшем случае ошибочно.
Я не говорю, что команды не должны быть ответственными за свою работу. Долж-
ны! Анализируя инцидент и работая над улучшением своей системы разработки,
в том числе взаимодействуя с остальной частью организации в целях внедрения
изменений, они и демонстрируют свою ответственность.
Поиск виноватого (single, wringable neck в неверно понимаемой терминологии
Scrum) только поощряет уклонение от ответственности и перекладывание ее на дру-
гих. Количество зарегистрированных инцидентов может снизиться, но только потому,
что люди будут скрывать проблемы. Серьезные проблемы будут лишь ухудшаться.
«Когда количество инцидентов снижается,
уровень смертности возрастает», сообщается
Поиски виноватого только
в The Field Guide to Understanding ‘Human Error’,
ухудшат серьезные инциденты.
когда речь заходит о строительстве и авиации.
«Это поддерживает важность… извлечения уро-
ков из почти аварийных ситуаций. Отказ от таких возможностей обучения на любом
уровне и любыми средствами не просто плохая идея. Это опасно» [Dekker2014] (гл. 7).
Если ваша организация понимает эту динамику и действительно хочет, чтобы
команда показала свою ответственность, то вы можете поделиться результатами,
выявленными при анализе инцидента и имеющими отношение к вашей системе раз-
работки. (Другими словами, последними стикерами стадии «Генерировать идеи».)
Вы также можете поделиться тем, что решили сделать, чтобы улучшить надежность
вашей системы разработки.
Часто организации имеют готовый шаблон отчета, который вам нужно будет ис-
пользовать. Сделайте все возможное, чтобы избежать упрощенного, причинно-след-
ственного изображения ситуации, и будьте осторожны, постарайтесь показать, как
система, а не отдельные лица позволила проблемам превратиться в критический сбой.
Вопросы
Что, если у нас нет времени, чтобы делать полный анализ каждого бага и инцидента?
Анализ инцидента необязательно должен быть формальной ретроспективой.
Вы можете использовать простую структуру, чтобы исследовать возможности нефор-
мально, с участием всего нескольких людей или даже уделив всего несколько минут
в своих мыслях. Есть основной момент, который надо запомнить: события — это
симптомы функционирования вашей базовой системы разработки. Они являются
подсказками, которые покажут вам, как работает эта система. Начните с фактов,
обсудите, как они меняют ваше понимание системы разработки, и только тогда по-
думайте, что поменять.
Глава 16. Качество 599
Предварительные требования
Успех анализа инцидентов зависит от психологи-
ческой безопасности. Если участники не чувствуют См. также
себя в безопасности настолько, чтобы поделиться
своим взглядом на случившееся как есть, без при- Безопасность (глава 7)
крас, то вам будет трудно достичь углубленного
понимания вашей системы разработки.
Более широкий организационный подход к инцидентам оказывает большое
влияние на безопасность участников. Даже компаниям, которые на словах под-
держивают «постмортем-обсуждения без обвинений», трудно перейти с упро-
щенного причинно-следственного мировоззрения на системное. Они склонны
думать, что «без обвинений» — это «не говорить, кто виноват», но чтобы быть
действительно организацией «без обвинений», они должны понимать, что никто
не виноват. Неудачи и успехи — следствия работы сложной системы, а не действий
отдельных лиц.
Вы можете проводить успешный анализ инцидентов в организациях, которые
не понимают этого, но вам понадобится быть вдвойне осторожными, устанавливая
базовые правила в части психологической безопасности, и предстоит сделать так,
чтобы в анализе не участвовали люди, имеющие мировоззрение, ориентированное
на обвинения. Вам нужно позаботиться и о том, чтобы отчет об инциденте, если он
будет, был написан с системной точки зрения, а не причинно-следственной.
Показатели
Когда вы хорошо проводите анализ инцидентов:
zz инциденты признаются, и анализируются даже те инциденты, которые не имеют
заметных последствий;
zz члены команды видят, что инциденты — это способ учиться и совершенствоваться,
и даже рассчитывают на них;
zz надежность и устойчивость вашей системы со временем улучшаются, приводя
в результате к меньшему количеству скрытых дефектов и сбоев в эксплуатаци-
онной среде;
zz никого не обвиняют, не судят и не наказывают за инциденты.
Альтернативы и эксперименты
Многие организации смотрят на анализ инцидентов сквозь линзы шаблона стандарт-
ного отчета. Это может приводить к поверхностным «заплаткам», а не к системному
взгляду, поскольку люди фокусируются на том, что хотят включить в отчет, а не на
исследовании самого инцидента. Формат, который я описал, поможет людям рас-
ширить свою точку зрения, прежде чем приходить к каким-либо заключениям. Про-
ведение его как ретроспективы также гарантирует, что каждый голос будет услышан
и вся команда согласится с выводами.
600 Часть III. Надежная поставка
Снова октябрь. В прошлом году ваша команда достигла свободного владения навы-
ками на уровне поставки (см. часть III). В то время некоторые члены команды также
хотели достичь навыков на уровне оптимизации, но руководство отнеслось к этому
скептически. Вы не смогли получить нужной вам поддержки.
Однако с тех пор как вы достигли навыков на уровне поставки, ваша команда ра-
ботает на полную мощность. Производительность значительно выросла, количество
дефектов сократилось. Ханне, вашему продакт-менеджеру, было трудно успевать за
всем. Она делегировала все больше и больше обязанностей команде, которая отлично
со всем справлялась.
Это заметили. Ханна расхваливала вас директору по маркетингу, а ваш босс го-
ворил о вас с техническим директором. Настал подходящий момент для еще одной
попытки достичь навыков на уровне оптимизации. На сей раз это сработало. Ханна
была назначена в вашу команду на полный день. И это не все: она получила разре-
шение на «эксперимент c Agile».
«Эксперимент c Agile» — это то, как они называют способ, с помощью которого
Ханна работает с вашей командой. Вместо того чтобы заниматься ежегодным плани-
рованием, как остальные специалисты отдела маркетинга, она получила разрешение
распоряжаться финансами вашей команды. Она регулярно встречается со своим
боссом, чтобы поделиться статистикой, такой как выручка и удержание заказчиков,
и постоянно пробует новые идеи и эксперименты. (Ее коллеги ревнуют. Они все
еще должны каждый год проходить через шестинедельный ад постановки целей
и планирования бюджета.)
И Ханна не одна. Активно участвует вся команда. Ханна первая среди равных,
но когда дело доходит до экспертных знаний в области маркетинга продукта, другие
602 Часть IV. Оптимизация результатов
1
Эти перечни взяты из [Shore2018b].
604 Часть IV. Оптимизация результатов
ДОСТИЖЕНИЕ НАВЫКОВ
НА УРОВНЕ ОПТИМИЗАЦИИ
Инвестиции, позволяющие достичь навыков на уровне оптимизации, испытывают на
прочность предрассудки и установленный порядок большинства компаний. Требуется
отказаться от значительной части контроля и больше доверять команде. Некоторый
надзор остается, но все равно это может пугать.
В результате вам обычно приходится в течение нескольких лет демонстрировать
успех в навыках на уровнях фокусировки и поставки, прежде чем ваша компания
предоставит вам полномочия и автономность, которые позволяют достичь навыков
на уровне оптимизации. Стартапы на раннем этапе, как правило, являются исклю-
чением, но всем остальным понадобится поработать над выстраиванием доверия.
К моменту, когда вы будете готовы к оптимизации, ваша команда, вероятно,
овладеет остальными практиками, представленными в этой книге. Вам больше не по-
надобится руководство в стиле «как это делать». Вы уже овладеете мастерством.
Поэтому главы в данной части короткие и легкие. Они помогут вам начать работу
и подскажут, что делать дальше. Ваша задача — взять то, что вы узнали о разработке
Agile, объединить с этими идеями и самостоятельно создать что-то великое.
Эти главы помогут вам начать работу:
zz в главе 17 обсуждается сущность автономных команд;
zz в главе 18 описаны способы, которые позволяют вашей команде учиться;
zz в главе 19 книга завершается рассказом о том, что будет дальше.
ГЛАВА 17
Автономность
БИЗНЕС-РЕШЕНИЯ
Одна из самых потрясающих черт команд оптимизации — отсутствие акцента на
пользовательских историях. Конечно, у них есть истории как механизм планирова-
ния, но они не являются темой разговоров со стейкхолдерами. Вместо этого коман-
ды сосредоточиваются на бизнес-результатах и ценности. Они не пытаются поставить
набор историй; это детали. Они пытаются добиться значимых изменений в своей
организации.
Особенно ярко это проявляется в отно-
шениях команд оптимизации с руковод- См. также
ством. Они пользуются доверием своей ор-
ганизации. Руководство высшего уровня Доверие стейкхолдеров (глава 10)
и непосредственные руководители знают,
что могут дать команде финансирование и миссию и далее не вмешиваться в ее ра-
боту. Команда самостоятельно решит, как выполнить миссию. Команда проинфор-
мирует руководство о том, как тратятся финансы, какие результаты достигаются
и какая поддержка ей нужна, чтобы быть более успешной.
Одним из последствий данного подхода
является то, что команды оптимизации ред- См. также
ко следуют предварительно составленному
плану. Как правило, их ценные инкременты Адаптивное планирование (глава 8)
маленькие, их планы в высшей степени адап-
тивны, и их горизонты планирования короткие. Вместо того чтобы работать в со-
ответствии с большим статичным планом, команды постоянно тестируют идеи
и демонстрируют инкрементный прогресс. (По крайней мере, с точки зрения вну-
тренних стейкхолдеров. При этом они все еще могут откладывать работу на потом,
до выхода большого релиза.)
В результате команды оптимизации, как
правило, не имеют традиционных дедлай- См. также
нов или дорожных карт. Они сами выби-
Прогнозирование (глава 10)
рают, когда устанавливать дедлайн. Они
делают это потому, что есть убедительная
бизнес-причина, например координация с работой отдела маркетинга, а не для того,
чтобы удовлетворить бюрократические требования. Если команды осознают, что
не могут уложиться в установленный срок, то сами решают, как и когда изменить
свои планы.
Глава 17. Автономность 607
ОТВЕТСТВЕННОСТЬ И НАДЗОР
Команды оптимизации не лишены надзора. Они могут контролировать свой бюджет
и планы, но это не значит, что им можно делать все, что захочется. Они все еще долж-
ны показывать свою работу и обосновывать свои масштабные решения. Им просто
не нужно получать предварительное одобрение своих решений, пока те соответству-
ют цели команды и не требуют дополнительных ресурсов от организации.
Организация использует командную цель, чтобы направить работу команды в нуж-
ное русло. Цель команды определяет общее направление движения (концепцию),
текущую краткосрочную цель (миссию) и вехи, которые ведут к успеху (показатели).
Руководство определяет общее направление, и команда разрабатывает детали, взаимо-
действуя с ним и другими стейкхолдерами.
Когда команда видит возможность изменить См. также
свою цель так, чтобы она принесла больше
ценности, члены команды обсуждают это Цель (глава 7)
с руководством.
Команда демонстрирует свою ответственность не тем, что показывает поставлен-
ные ею истории, а фокусируясь на бизнес-целях: как уже достигнутых на данный
момент, так и тех, которых она надеется достичь в будущем. Эти результаты могут
быть простыми, например цифры полученной выручки, или более изощренными,
как, например, рейтинг удовлетворенности сотрудников. В любом случае акцент
делается на результатах, а не просто на поставленном продукте и датах.
Однако команды оптимизации не только пытаются достичь краткосрочных
результатов. Они также постоянно изучают, как лучше обслуживать своих заказ-
чиков и рынок. Поэтому они обсуждают то,
что узнали, что хотят узнать дальше и как См. также
планируют это сделать. Они делятся этой
информацией с помощью внутренних демо, Демо для стейкхолдеров (глава 10)
внутренних дорожных карт и непосред- Дорожные карты (глава 10)
ственного общения с руководством.
ФИНАНСИРОВАНИЕ
Финансирование команды — еще один механизм организационного надзора. Коман-
ды оптимизации, как правило, финансируются на основе текущей деятельности
(см. подраздел «Agile-управление» главы 10). Организация выделяет эти средства,
основываясь на результатах, ожидаемых от команды. Команда также может получить
единовременное финансирование и ресурсы, обратившись к руководству и обосно-
вав потребность в них.
Если члены команды не думают, что
могут достичь своей цели с помощью име См. также
ющихся у них финансов и других ресурсов,
Контекст (глава 7)
то могут попросить спонсора о большем.
608 Часть IV. Оптимизация результатов
Если он не согласен, то команда вместе с ним ищет баланс, которого можно достичь,
или переключается на другую, более значимую цель. Как правило, это обсуждение
проводится в рамках разработки контекста для устава.
В ходе работы команды прогнозы организации о ценности сбываются… или нет.
Здесь возникает возможность скорректировать цель команды. Если команда произ-
водит больше ценности, чем ожидалось, то финансирование может быть увеличено
и команда может удвоить свои успехи. Если производит меньше, то финансирова-
ние может быть уменьшено или команда может переключиться на более ценную
и значимую цель.
ЭКСПЕРИМЕНТЫ И ЛИТЕРАТУРА
ДЛЯ ДОПОЛНИТЕЛЬНОГО ЧТЕНИЯ
Как я уже упоминал, организациям и руководителям может быть сложно перейти
к автономности и владению. The Agile Culture: Leading through Trust and Ownership
[Pixton2014] может помочь руководителям узнать, как сделать этот шаг. Другой вари-
ант — Turn the Ship Around! A True Story of Turning Followers Into Leaders [Marquet2013].
Это тоже отличная книга.
Что касается экспериментов, то одна из наиболее интересных книг — Beyond
Budgeting1 Джереми Хоупа и Робина Фрейзера [Hope2003]. Авторы делают акцент
на распространении практики принятия решений среди команд, ориентированных
на заказчика, подобно тому, что я описал здесь, но гораздо более подробно рассма-
тривают вопросы менеджмента.
Сообщество Agile наполнено другими интересными идеями и экспериментами
по улучшению автономности. Многие из этих экспериментов затрагивают уровень
навыков «Укрепление». Поговорим о них в главе 19.
1
Хоуп Дж., Фрейзер Р. Бюджетирование, каким мы его не знаем. Управление за рамками бюджетов.
ГЛАВА 18
Открытия
1
Бланк С. Четыре шага к озарению. Стратегии создания успешных стартапов.
610 Часть IV. Оптимизация результатов
ПОДТВЕРЖДЕННОЕ ЗНАНИЕ
Бесчисленное количество раз у меня была хорошая идея, я предлагал ее реальным
заказчикам или пользователям и обнаруживал, что она не сработала. Конечно, они
мне говорили, что им нравится идея, когда я им о ней рассказывал. Иногда они это
говорили даже после того, как попробовали прототип! И только когда я предлагал
людям понести реальные расходы (времени, денег или политического капитала),
я узнавал, что моя «хорошая идея» была недостаточно хороша.
Идеи по продукту подобны вечному двигателю: если вы достаточно сильно в них
верите и придали им достаточно инерции, то они выглядят так, словно будут работать
вечно. Но подайте на них реальную нагрузку, и они замирают.
«Подтвержденное знание» — один из ваших луч-
ших инструментов для тестирования идей. Я расска-
зывал о нем в подразделе «Подтвержденное знание» См. также
главы 16, однако напомню: подтвержденное знание
Обнаружение слепых зон
подразумевает постановку гипотезы о вашем рынке, (глава 16)
создание чего-либо, что вы можете вывести на него,
Вовлечение реального за-
и измерение того, что происходит. Используйте
казчика (глава 8)
полученное знание для коррекции своих планов,
затем повторите. Этот процесс часто упоминается
как цикл «Создать — измерить — узнать».
Чтобы действительно подтвердить верность того, что вы узнали, вам нужны
реальные заказчики (или пользователи) и реальные затраты. Если вы показываете
ваше творение людям, не принадлежащим к вашему целевому рынку, то получите
обратную связь, но она может не иметь отношения к вашей реальной ситуации.
И если вы не просите их принять на себя какие-либо обязательства в ответ, то больше
узнаете о желании людей не задеть ваши чувства, чем о реальной ценности вашей
идеи. Все будут хвалить вашу идею роскошного отпуска… пока вы не попросите их
внести первый взнос1.
СПОСОБНОСТЬ К АДАПТАЦИИ
Всякий раз, проходя цикл «Создать — измерить —
узнать», вы узнаете что-то новое. Чтобы восполь- См. также
зоваться тем, что вы узнали, вам понадобится
изменить свои планы. В результате команды оп- Адаптивное планирование
(глава 8)
тимизации склонны иметь короткие горизонты
планирования и планы, пригодные для адаптации.
Они работают с помощью маленьких инкрементов, чтобы иметь возможность без-
болезненно изменить направление.
1
И тогда начинается все вот это: «Ой, у меня нет времени», «Я не могу оставить в одиночестве
своего чихуахуа Пушистика» и «Ненавижу тропический песок. Он грубый, раздражает и про-
никает везде».
Глава 18. Открытия 611
ЭКСПЕРИМЕНТЫ И ЛИТЕРАТУРА
ДЛЯ ДОПОЛНИТЕЛЬНОГО ЧТЕНИЯ
Определение направления развития продукта имеет гораздо больше нюансов, чем
я могу рассказать в этой книге. Источников для дальнейшего изучения множество;
изучите категорию менеджмента продукта. Можно начать с трех книг: Inspired: How
to Create Tech Products Customers Love1 Марти Кагана [Cagan2017]; Innovation Games:
Creating Breakthrough Products through Collaborative Play Люка Хоффмана; и Testing
Business Ideas2 Дэвида Блэнда и Александра Остервальдера [Bland2019].
Следует помнить, что, помимо обычного менеджмента продукта, команды опти-
мизации взаимодействуют со своими заказчиками, чтобы понять их рынок и про-
верить свои идеи. Они существуют для того, чтобы учиться, равно как и для того,
чтобы создавать, и гибкость их планов отражает эту направленность. В движении
«Бережливый стартап» это называется открытием заказчика и проверкой заказчика.
Гораздо больше подробной информации об этих идеях вы можете найти в The
Startup Owner’s Manual3 [Blank2020b]. Это обновленная версия книги Стива Бланка
The Four Steps to the Epiphany [Blank2020a]. Идеи Бланка в сочетании с экстремальным
программированием сформировали основу для движения «Бережливый стартап»
Эрика Риса [Ries2011].
Как вы можете догадаться, авторы The Startup Owner’s Manual сосредоточиваются
на стартапах, поэтому советы, представленные в книге, нужно адаптировать к вашей
ситуации, но команды оптимизации во многом сходны со стартапами. Успешная
команда оптимизации не только поддерживает установившийся статус-кво. Если бы
она это делала, то навыков на уровнях фокусировки и поставки было бы достаточно.
Помимо этого, команда ищет способы лидировать на своем рынке и создавать новые
рынки. Идеи бережливого стартапа, в том числе базовые идеи открытия заказчика
и проверки заказчика, — ключ к тому, как это сделать.
1
Каган М. Вдохновленные. Все, что нужно знать продакт-менеджеру.
2
Блэнд Д., Остервальдер А. Тестирование бизнес-идей.
3
Бланк С., Дорф Б. Стартап. Настольная книга основателя.
ГЛАВА 19
Взгляд в будущее
1
Семлер Р. Маверик. История успеха самой необычной компании в мире.
614 Часть IV. Оптимизация результатов
Это увлекательный рассказ о том, как автор обновлял подход к менеджменту в своей
компании.
С учетом сказанного, модель Agile Fluency никогда не была моделью зрелости.
Вам не нужно проходить все уровни по порядку или добиваться владения навыками
в каждом из них. Хотя индивидуальные практики, такие как самоотбор команды,
имеют место быть, я подозреваю, что полное владение навыками на уровне укрепле-
ния неприемлемо для большинства компаний. Но если вы хотите жить на передовой
и вступить в ряды новаторов, которые сделали Agile тем, чем он сейчас является, то
область укрепления — одна из стартовых точек. Кроме того… кто знает? Есть и другие
области, которые ждут, когда их откроют.
Однако в конечном итоге Agile не имеет значения. На самом деле! Что имеет
значение, так это успех членов вашей команды, организации и стейкхолдеров, как бы
они его себе не представляли. Практики Agile, принципы и идеи — всего лишь про-
водники на этом пути. Начните со строгого следования этим практикам. Научитесь
применять принципы и ключевые идеи. Нарушайте правила, экспериментируйте,
смотрите, что работает, и узнавайте еще больше. Делитесь своими идеями и увле-
ченностью и узнавайте еще больше.
Со временем, по мере становления дисциплины и накопления опыта, практики
и принципы станут менее важными. Когда навык действовать правильно становится
инстинктивным, а интуиция вырабатывается на опыте, приходит время оставить
правила и принципы позади. Неважно, как вы это назовете. Когда ваша интуиция
приведет вас к отличному ПО, которое будет служить важной цели, а ваша мудрость
будет вдохновлять следующее поколение команд, вы овладеете мастерством раз-
работки Agile.
Библиография
[Adzic2011] Adzic G. Specification by Example. New York: Manning Publications, 2011. https://
learning.oreilly.com/library/view/specification-by-example/9781617290084.
[Adzic2012] Adzic G. Impact Mapping. Victoria, BC: Leanpub, 2012.
[Ambler2006] Ambler S., Sadalage P. Refactoring Databases: Evolutionary Database Design. Boston:
Addison-Wesley Professional, 2006.
[Anderson2010] Anderson D. Kanban. Blue Hole Press Inc., 2013.
[Austin1996] Austin R. D. Measuring and Managing Performance in Organizations. New York:
Dorset House Publishing Co., 1996.
[Bache2018] Bache E. “Introducing the Gilded Rose kata and writing test cases using
Approval Tests.” 2018. YouTube. Video series. Eficode Praqma. https://www.youtube.com/
watch?v=zyM2Ep28ED8; https://www.youtube.com/watch?v=OJmg9aMxPDI; https://
www.youtube.com/watch?v=NADVhSjeyJA.
[Beck2000a] Beck K. Extreme Programming Explained: Embrace Change. 1st ed. Boston: Addison-
Wesley, 2000.
[Beck2000b] Beck K. Fowler M. Planning Extreme Programming. Boston: Addison-Wesley
Professional, 2000.
[Beck2001] Beck K. et al. “Manifesto for Agile Software Development.” 2001. http://
agilemanifesto.org.
[Beck2002] Beck K. Test-Driven Development: By Example. Boston: Addison-Wesley Professional,
2002.
[Beck2004] Beck K. Extreme Programming Explained. 2nd ed. Boston: Addison-Wesley Professional,
2004.
[Beck2007] Beck K. Implementation Patterns. Boston: Addison-Wesley Professional, 2007. https://
learning.oreilly.com/library/view/implementation-patterns/9780321413093.
[Beck2018] Beck K. “test && commit || revert.” Medium. September 28, 2018. https://medium.com/
@kentbeck_7670/test-commit-revert-870bbd756864.
[Beckhard1992] Beckhard R., Pritchard W. Changing the Essence: The Art of Creating and Leading
Fundamental Change in Organizations. San Francisco: Jossey-Bass, 1992.
[Belshee2005] Belshee A. “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience.”
Proceedings of the Agile Development Conference, July 24–29, 2005, 125–131. Washington,
DC: IEEE Computer Society. http://dx.doi.org/10.1109/ADC.2005.37.
[Belshee2016a] Belshee A. “WET: When DRY Doesn’t Apply.” Arlo Being Bloody Stupid (blog).
April 7, 2016. https://arlobelshee.com/wet-when-dry-doesnt-apply.
[Belshee2016b] Belshee A. “The Core 6 Refactorings.” Arlo Being Bloody Stupid (blog). May 2,
2016. https://arlobelshee.com/the-core-6-refactorings.
[Belshee2019] Belshee A. “Naming as a Process” (article series). Deep Roots (blog). October 10–17,
2019. https://www.digdeeproots.com/articles/on/naming-process.
[Benne1948] Benne K. D., Sheats P. “Functional roles of group members.” Journal of Social Issues,
1948: 4 (2), 41–49. https://doi.org/10.1111/j.1540-4560.1948.tb01783.x.
616 Библиография
[Bernhardt2012] Bernhardt G. “Functional Core, Imperative Shell.” Destroy All Software (blog).
July 12, 2012. https://www.destroyallsoftware.com/screencasts/catalog/functional-core-
imperative-shell.
[Beyer2016] Beyer B., Jones C., Petoff J., Murphy N. R. Site Reliabililty Engineering: How Google
Runs Production Systems. 1st ed. Sebastopol, CA: O’Reilly, 2016.
[Bland2019] Bland D. J., Osterwalder A. Testing Business Ideas. Hoboken, NJ: Wiley, 2019. https://
learning.oreilly.com/library/view/testing-business-ideas/9781119551447.
[Blank2020a] Blank. The Four Steps to the Epiphany. 3rd ed. Palo Alto, CA: K&S Ranch, 2013.
[Blank2020b] Blank S., Dorf B. The Startup Owner’s Manual: The Step-By-Step Guide for Building
a Great Company. Hoboken, NJ: Wiley, 2020.
[Bockeler2020] Böckeler B., Siessegger N. “On Pair Programming.” martinFowler.com (website).
January 15, 2020. https://martinfowler.com/articles/on-pair-programming.html.
[Boeg2019] Boeg J. Level Up Agile with Toyota Kata: Beyond Method Wars, Establishing Core
Lean/Agile Capabilities Through Systematic Improvement, 2019. (self-pub.)
[Boehm1987] Boehm B. “Industrial Software Metrics Top 10 List.” IEEE Software, 1987, 4 (9): 84–85.
[Bossavit2013] Bossavit L. The Leprechuans of Software Engineering: How Folklore Turns Into
Fact and What To Do About It. Victoria, BC: Leanpub, 2013.
[Brooks1995] Brooks F. P. The Mythical Man-Month: Essays on Software Engineering.
20th Anniversary Edition. Boston: Addison-Wesley Professional, 1995.
[Cagan2017] Cagan M. Inspired: How to Create Tech Products Customers Love. Hoboken, NJ:
Wiley, 2017. https://learning.oreilly.com/library/view/inspired-2nd-edition/9781119387503.
[Clacey2020] Clacey K., Morris J.-A. The Remote Facilitator’s Pocket Guide. San Francisco:
Berrett-Koehler Publishers, 2020. https://learning.oreilly.com/library/view/the-remote-
facilitators/9781523089123.
[Cockburn2001] Cockburn A., Williams L. “The Costs and Benefits of Pair Programming.” Extreme
Programming Examined, edited by G. Succi and M. Marchesi, 223–247. Boston: Addison-
Wesley, 2001. https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF.
[Cockburn2006] Cockburn A. Agile Software Development: The Cooperative Game. Boston:
Addison-Wesley Professional, 2006.
[Cockburn2008] Cockburn A. “Hexagonal Architecture.” 2008. https://alistair.cockburn.us/
hexagonalarchitecture.
[Cohn2005] Cohn M. Agile Estimating and Planning. Upper Saddle River, NJ: Prentice Hall, 2005.
[Craver2016] Craver N. “Stack Overflow: A Technical Deconstruction.” Nick Craver (blog).
February 3, 2016. https://nickcraver.com/blog/2016/02/03/stack-overflow-a-technical-
deconstruction.
[Cunningham1995] Cunningham W. “EPISODES: A Pattern Language of Competitive
Development, Part I.” Paper submitted to the Second International Conference on Pattern
Languages of Programs. Monticello, Illinois, September 6–8, 1995. http://c2.com/ppr/
episodes.html.
[Dekker2014] Dekker S. The Field Guide to Understanding ‘Human Error’. 3rd ed. Boca Raton,
FL: CRC Press, 2014.
[DeMarco2002] DeMarco T. Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency.
New York: Broadway Books, 2002.
[DeMarco2003] DeMarco T, Lister T. Waltzing With Bears: Managing Risk on Software Projects.
New York: Dorset House Publishing Co., 2003.
[DeMarco2013] DeMarco T, Lister T. Peopleware: Productive Projects and Teams. 3rd ed. Boston:
Addison-Wesley Professional, 2013.
Библиография 617
[Fowler2020b] Fowler M. “Patterns for Managing Source Code Branches.” Martin Fowler.com. May
28, 2020. https://martinfowler.com/articles/branching-patterns.html.
[Freeman2010] Freeman S., Pryce N. Growing Object-Oriented Software, Guided by Tests. Boston:
Pearson Education, 2010.
[Gamma1995] Gamma E., Helm R., Johnson R., Vlissides J. [Gang of Four]. Design Patterns: Elements
of Reusable Object-Oriented Software. Boston: Addison-Wesley, 1995.
[Goldratt1992] Goldratt E. M. The Goal: A Process of Ongoing Improvement. Great Barrington,
MA: North River Press, 1992.
[Goldratt1997] Goldratt E. M. Critical Chain: A Business Novel. Great Barrington, MA: North
River Press, 1997.
[Google2021] Google. “Guide: Understand Team Effectiveness.” Accessed May 11, 2021. https://
rework.withgoogle.com/print/guides/5721312655835136.
[Graham1995] Graham P. Mary Parker Follett: Prophet of Management: A Celebration of Writings
from the 1920’s. Fairless Hills, PA: Beard Books, 1995.
[Grenning2002] Grenning J. “Planning Poker or How to Avoid Analysis Paralysis While Release
Planning.” 2002. https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf.
[Grenning2016] Grenning J. “TDD Guided by ZOMBIES.” James Grenning’s Blog, October 31,
2016. https://blog.wingman-sw.com/tdd-guided-by-zombies.
[Gumbley2020] Gumbley J. “A Guide to Threat Modelling for Developers.” Martin Fowler.com.
May 28, 2020. https://martinfowler.com/articles/agile-threat-modelling.html.
[Hammant2020] Hammant P. Trunk-Based Development and Branch By Abstraction. Victoria,
BC: Leanpub, 2020. https://leanpub.com/trunk-based-development.
[Heaton2015] Heaton R. “Migrating bajillions of database records at Stripe.” Robert Heaton.com.
August 31, 2015. https://robertheaton.com/2015/08/31/migrating-bajillions-of-database-
records-at-stripe.
[Hendrickson2000] Hendrickson E. “Better Testing, Worse Quality?” Quality Tree, December
2000. https://www.stickyminds.com/sites/default/files/article/file/2012/XDD2479file
listfilename1_0.pdf.
[Hendrickson2013] Hendrickson E. Explore It! Reduce Risk and Increase Confidence with
Exploratory Testing. Raleigh, NC: Pragmatic Bookshelf, 2013.
[Highsmith2001] Highsmith J. “History: The Agile Manifesto.” 2001. https://agilemanifesto.org/
history.html.
[Highsmith2002] Highsmith J. Agile Software Development Ecosystems. Boston: Addison-Wesley
Professional, 2002.
[Hill2018] Hill M. “GeePaw.” “TDD & The Lump of Coding Fallacy.” Video, 9:04. GeePaw-Hill.org.
April 14, 2018. https://www.geepawhill.org/2018/04/14/tdd-the-lump-of-coding-fallacy.
[Hodgson2017] Hodgson P. “Feature Flags.” Martin Fowler.com. October 9, 2017. https://
martinfowler.com/articles/feature-toggles.html#ImplementationTechniques.
[Hohman2002] Hohman M., Slocum A. C. “Mob Programming and the Transition to XP.” ResearchGate,
2002. https://www.researchgate.net/publication/2522276_Mob_Programming_and_the_
Transition_to_XP/link/55de4a1b08ae7983897d11ad/download.
[Hohmann2006] Hohmann L. Innovation Games: Creating Breakthrough Products Through
Collaborative Play. Boston: Addison-Wesley Professional, 2006. https://learning.oreilly.com/
library/view/innovation-gamescreating/0321437292.
[Hope2003] Hope J., Fraser R. Beyond Budgeting. Cambridge, MA: Harvard Business School
Publishing, 2003.
Библиография 619
[Humble2010] Humble J., Farley D. Continuous Delivery: Reliable Software Releases through Build,
Test and Deployment Automation. Boston: Addison-Wesley Professional, 2010.
[Hunt2019] Hunt A., Thomas D. The Pragmatic Programmer: Your Journey to Mastery,
20th Anniversary Edition. 2nd ed. Boston: Addison-Wesley Professional, 2019.
[Janis1982] Janis I. L. Groupthink: Psychological Studies of Policy Decisions and Fiascoes. Boston:
Houghton Mifflin, 1982.
[Kahn1990] Kahn W. A. “Psychological Conditions of Personal Engagement and Disengagement at
Work.” Academy of Management Journal, 1990, 33 (4): 692–724. https://doi.org/10.5465/256287.
[Kaner1998] Kaner S. Facilitator’s Guide to Participatory Decision-Making. San Francisco: Jossey-
Bass, 1998.
[Katzenback2015] Katzenbach J. R., Smith D. K. The Wisdom of Teams: Creating the High-
Performance Organization. Boston: Harvard Business Review Press, 2015.
[Kerievsky2004] Kerievsky J. Refactoring to Patterns. Boston: Addison-Wesley Professional, 2004.
[Kerievsky2005] Kerievsky J. “Industrial XP: Making XP Work in Large Organizations.” 2005. Agile
Project Management Advisory Service Executive Report 6, no 2. https://citeseerx.ist.psu.edu/
viewdoc/download?doi=10.1.1.694.2506&rep=rep1&type=pdf.
[Kerth2001] Kerth N. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset
House Publishing Co., 2001.
[Kim2013] Kim G. Behr K., Spafford G. The Phoenix Project. Portland, OR: IT Revolution Press, 2013.
[Kim2016] Kim G., Humble J., Debois P., Willis J. The DevOps Handbook: How to Create World-Class
Agility, Reliability, and Security in Technology Organizations. Portland, OR: IT Revolution
Press, 2016.
[Kline2015] Kline N. Time to Think: Listening to Ignite the Human Mind. London: Cassell, 2015.
[Kohn1999] Kohn A. Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A’s,
Praise and Other Bribes. Boston: Mariner Books, 1999.
[Lacey2006] Lacey M. “Adventures in Promiscuous Pairing: Seeking Beginner’s Mind.” Proceedings
of the Conference on AGILE 2006, July 23–28, 263–269. Washington, DC: IEEE Computer
Society. http://dx.doi.org/10.1109/AGILE.2006.7.
[Langr2020] Langr J. “Remote Collaborative Coding: 6 Ways to Go.” Langr Software Solutions.
June 2, 2020. https://langrsoft.com/2020/06/02/git-handover.
[Larman2015] Larman C., Vodde B. Large-Scale Scrum: More with LeSS. Boston: Addison-Wesley
Professional, 2015.
[Larsen2010] Larsen D. “Circles and Soup.” Partnerships and Possibilities (blog), July 26, 2010.
https://www.futureworksconsulting.com/blog/2010/07/26/circles-and-soup.
[Larsen2016] Larsen D., Nies A. Liftoff: Start and Sustain Successful Agile Teams. Raleigh, NC and
Dallas, TX: Pragmatic Bookshelf, 2016. https://pragprog.com/titles/liftoff/liftoff-second-
edition.
[Larsen2021] Larsen W. “Supercharge Your Retrospectives with TRIPE.” Industrial Logic, January
31, 2021. https://www.industriallogic.com/blog/supercharge-your-retrospectives-with-tripe.
[Little2006] Little T. “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty,”
IEEE Software 23, 2006, no. 3: 48–54. https://doi.org/10.1109/MS.2006.82.
[Mah2006] Mah M. “Agile Productivity Metrics.” Keynote Address, Better Software Conference &
EXPO, Las Vegas, June 2006. https://www.stickyminds.com/sites/default/files/presentation/
file/2013/06BSOFR_WK2.pdf.
[Mah2018] Mah M. “Taking the SAFe 4.0 Road to Hyper Speed and Quality.” Keynote Address,
Pacific Northwest Software Quality Conference, Portland, October 2018. https://www.
youtube.com/watch?v=OldRc6lp3CU.
620 Библиография
[Mamoli2015] Mamoli S., Mole D. Creating Great Teams: How Self-Selection Lets People Lead.
Raleigh, NC and Dallas, TX: Pragmatic Bookshelf, 2015.
[Manns2015] Manns M. L., Rising L. More Fearless Change: Strategies for Making Your Ideas
Happen. Boston: Addison-Wesley Professional, 2015. https://learning.oreilly.com/library/
view/more-fearlesschange/9780133966534.
[Marick2007a] Marick B. “Six years later: What the Agile Manifesto left out.” Exploration Through
Example (blog). May 16, 2007. http://www.exampler.com/blog/2007/05/16/six-years-later-
what-the-agilemanifesto-left-out.
[Marick2007b] Marick B. “Latour 3: Anthrax and standups.” Exploration Through Example (blog).
November 6, 2007. http://exampler.com/blog/2007/11/06/latour-3-anthrax-and-standups/
trackback/index.html.
[Marquet2013] Marquet L. D. Turn the Ship Around! A True Story of Turning Followers into
Leaders. New York: Penguin Group, 2013.
[McConnell2006] McConnell S. Software Estimation: Demystifying the Black Art. Redmond, WA:
Microsoft Press, 2006.
[Montagna1996] Montagna F C. “The Effective Postfire Critique.” Fire Engineering Maga
zine, July 1, 1996. https://www.fireengineering.com/firefighting/the-effective-postfire-
critque/#gref.
[Nelson2006] Nelson R. R. “Applied Insight — Tracks in the Snow.” CIO Magazine, Sep 1, 2006.
https://www.cio.com/article/2444800/applied-insight---tracks-in-the-snow.html.
[Newman2021] Newman S. Building Microservices, 2nd Edition. Sebastopol, CA: O’Reilly, 2021.
https://learning.oreilly.com/library/view/building-microservices-2nd/9781492034018.
[Nierenberg2009] Nierenberg R. Maestro: A Surprising Story About Leading by Listening. New
York: Portfolio, 2009.
[Nygard2011] Nygard M. “Documenting Architecture Decisions.” Cognitect (blog). November 15,
2011. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions.
[Patterson2013] Patterson K. Crucial Accountability: Tools for Resolving Violated Expectations,
Broken Commitments, and Bad Behavior. New York: McGraw-Hill Education, 2013.
[Patton2014] Patton J. User Story Mapping. Sebastopol, CA: O’Reilly, 2014.
[Pearce2002] Pearce C. L., Conger J. A. Shared Leadership: Reframing the Hows and Whys of
Leadership. Thousand Oaks, CA: Sage Publications, 2002.
[Perry2016] Perry T. L. The Little Book of Impediments. Victoria, BC: Leanpub, 2016. https://
leanpub.com/ImpedimentsBook.
[Pixton2014] Pixton P., Gibson P., Nickolaisen N. The Agile Culture: Leading through Trust and
Ownership. Boston: Addison-Wesley Professional, 2014. https://learning.oreilly.com/library/
view/the-agileculture/9780133463187.
[Poppendieck2003] Poppendieck M., Poppendieck T. Lean Software Development: An Agile Toolkit
for Software Development Managers. Boston: Addison-Wesley Professional, 2003.
[Pugh2005] Pugh K. Prefactoring. Sebastopol, CA: O’Reilly, 2005.
[Reina2015] Reina D. Trust and Betrayal in the Workplace: Building Effective Relationships in
Your Organization. 3rd ed. San Francisco: Berrett-Koehler Publishers, 2015.
[Reinertson2009] Reinertson D. G. The Principles of Product Development FLow: Second Generation
Lean Product Development. 1st ed. Redondo Beach, CA: Celeritas Publishing, 2009.
[Ries2011] Ries E. The Lean Startup. New York: Crown Business, 2011.
[Rosenthal2020] Rosenthal C., Jones N. Chaos Engineering: System Resiliency in Practice. Sebastopol,
CA: O’Reilly, 2020.
Библиография 621
[Rooney2006] Rooney D. “The Disengaged Customer.” The Agile Artisan blog, January 20, 2006.
http://agileartisan.blogspot.com/2006/01/disengaged-customer-introduction.html.
[Rothman1998] Rothman J. “A Problem-Based Approach to Software Process Improvement: A Case
Study.” In Proceedings of the 16th Annual Pacific Northwest Software Quality Conference Joint
with ASQ Software Division’s 8th International Conference on Software Quality, October 13–14,
1998, 310–316. http://uploads.pnsqc.org/proceedings/pnsqc1998.pdf.
[Rothman2005] Rothman J. Behind Closed Doors: Secrets of Great Management. Raleigh, NC:
Pragmatic Bookshelf, 2005. https://learning.oreilly.com/library/view/behind-closed-
doors/9781680500332.
[Sawyer2017] Sawyer K. Group Genius: The Creative Power of Collaboration. New York: Basic
Books, 2017.
[Schwaber2002] Schwaber K., Beedle M. Agile Software Development with Scrum. Boston: Pearson
Education, 2002.
[Schatz2004] Schatz B., Schwaber K., Martin R. “Primavera Success Story.” Best Practices in Scrum
Project Management and XP Agile Software Development White Paper. Object Mentor,
Inc. and Advanced Development Methods, 2004. https://www.academia.edu/25855389/
Primavera_Success_Story.
[Schein1965] Schein E., Bennis W. Personal and Organizational Change Through Group Methods:
The Laboratory Approach. New York: John Wiley & Sons, 1965.
[Seashore2013] Seashore C. N., Seashore E. W., Weinburg G. M. What Did You Say? The Art of Giving
and Receiving Feedback. Columbia, MD: Bingham House Books, 2013.
[Semler1995] Semler R. Maverick: The Success Story Behind the World’s Most Unusual Workplace.
New York: Warner Books, 1995.
[Sheridan2013] Sheridan R. Joy, Inc.: How We Built a Workplace People Love. New York: Portfolio,
2013.
[Shore2004a] Shore J. “Continuous Design.” IEEE Software, 2004, 21 (1): 20–22. http://www.mar
tinfowler.com/ieeeSoftware/continuousDesign.pdf.
[Shore2004b] Shore J. “Fail Fast.” IEEE Software, 2004, 21 (5): 21–25. http://www.martinfowler.
com/ieeeSoftware/failFast.pdf.
[Shore2006] Shore J. “Change Your Organization: A Diary.” The Art of Agile (blog), 2006. http://
www.jamesshore.com/v2/projects/change-diary.
[Shore2018a] Shore J. “Testing Without Mocks: A Pattern Language.” The Art of Agile (blog). April
27, 2018. https://www.jamesshore.com/v2/blog/2018/testing-without-mocks.
[Shore2018b] Shore J., Larsen D. “The Agile Fluency Model: A Brief Guide to Success with Agile.”
Martin Fowler.com. March 6, 2018. https://martinfowler.com/articles/agileFluency.html.
[Shore2019] Shore J. “Bjorn Freeman-Benson: Three Challenges of Distributed Teams.” The Art of
Agile (blog). February 19, 2019. https://www.jamesshore.com/v2/blog/2019/three-challenges-
of-distributedteams.
[Shore2020a] Shore J. “Evolutionary Design Animated.” The Art of Agile (blog). February 20,
2020. https://www.jamesshore.com/v2/presentations/2020/evolutionary-design-animated.
[Shore2020b] Shore J. “TDD Lunch & Learn.” The Art of Agile (blog). May–September 2020.
https://www.jamesshore.com/v2/projects/lunch-and-learn.
[Shore2021] Shore J. “Fireside Chat with Ron Quartel on FAST.” The Art of Agile (blog). April 15, 2021.
https://www.jamesshore.com/v2/presentations/2021/fireside-chat-with-ron-quartel-on-fast.
[Shostack2014] Shostack A. Threat Modeling: Designing for Security. Indianapolis: John Wiley &
Sons, 2014.
622 Библиография
[Sierra2015] Sierra K. Badass: Making Users Awesome. Sebastopol, CA: O’Reilly, 2015. https://
learning.oreilly.com/library/view/badass-making-users/9781491919057.
[Skelton2019] Skelton M., Pais M. Team Topologies. Portland, OR: IT Revolution Press, 2019.
[Smith2012] Smith M. “The Failure Bow.” 2012. YouTube. Video, 12:12. TEDxTalks. https://www.
youtube.com/watch?v=cXuD2zHVeB0.
[Squirrel2020] Squirrel D., Fredrick J. Agile Conversations: Transform Your Conversations, Transform
Your Culture. Portland, OR: IT Revolution Press, 2020.
[Standish1994] Standish Group. “The CHAOS Report.” The Standish Group International, Inc.,
1994. https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf.
[Teasley2002] Teasley S., Covi L., Krishnan M. S., Olson J. “Rapid Software Development Through
Team Collocation.” IEEE Trans. Softw. Eng, 2002, 28 (7): 671–683. http://dx.doi.org/10.1109/
TSE.2002.1019481.
[Todkar2018] Todkar P. 2018. “How To Extract Data-Rich Service from a Monolith.” MartinFowler.
com. August 30, 2018. https://martinfowler.com/articles/extract-data-rich-service.html#Re
spectx201catomicStepOfArchitectureEvolutionx201dPrinciple.
[Tuckman1965] Tuckman B. W. “Developmental sequences in small groups.” Psychological Bulletin,
1965, 63: 384–399. http://dennislearningcenter.osu.edu/references/GROUP%20DEV%
20ARTICLE.doc.
[Ury2007] Ury W. The Power of a Positive No: How to Say No and Still Get to Yes. New York:
Bantam Books, 2007.
[VanSchooenderwoert2006] Schooenderwoert N. van. “Embedded Agile Project by the Numbers with
Newbies.” The Conference on AGILE 2006 (July 23–28). Washington, DC: IEEE Computer
Society, 2006, 351–366. http://dx.doi.org/10.1109/AGILE.2006.24.
[Venners2002] Venners B. “Design Principles and Code Ownership: A Conversation with Martin
Fowler, Part II.” Artima. November 11, 2002. https://www.artima.com/articles/design-
principles-and-codeownership.
[Venners2005] Venners B. “Erich Gamma on Flexibility and Reuse: A Conversation with Erich
Gamma, Part II.” Artima. May 30, 2005. https://www.artima.com/articles/erich-gamma-on-
flexibility-and-reuse.
[Wiegers1999] Wiegers K. E. Software Requirements. Redmond, WA: Microsoft Press, 1999.
[Wiggins2017] Wiggins A. “The Twelve-Factor App.” 2017. https://12factor.net.
[Williams2002] Williams L. Pair Programming Illuminated. Boston: Addison-Wesley Professional,
2002.
[Woods2010] Woods D., Decker S., Cook R., Johannesen L., Sarter N. Behind Human Error. Boca
Raton, FL: CRC Press, 2010.
[Wynne2015] Wynne M. “Introducing Example Mapping.” Cucumber. December 8, 2015. https://
cucumber.io/blog/bdd/example-mapping-introduction.
[Yip2016] Yip J. “It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings.” Martin Fowler.
com. February 21, 2016. http://www.martinfowler.com/articles/itsNotJustStandingUp.html.
[Yourdon1975] Yourdon E., Constantine L. L. Structured Design: Fundamentals of a Discipline of
Computer Program and Systems Design. Upper Saddle River, NJ: Prentice Hall, 1975.
[Zuill2021] Zuill W., Meadows K. Mob Programming: A Whole Team Approach. Victoria, BC:
Leanpub, 2021.
Об авторе