Искусство Agile-разработки

Искусство Agile-разработки
ВТОРОЕ ИЗДАНИЕ
Джеймс Шор
Диана Ларсен, Гитте Клитгаард, Шэйн Уорден
2024
ББК 32.973-018
УДК 004.4:005.8
Ш79
Шор Джеймс, Уорден Шэйн

Ш79 Искусство Agile-разработки. Теория и практика гибкой разработки ПО. — СПб.: Пи-
тер, 2024. — 624 с.: ил. — (Серия «Бестселлеры O’Reilly»).
ISBN 978-5-4461-2386-5
Большинство компаний, разрабатывающих ПО, якобы используют Agile, но на самом деле не пони-
мают, что это такое. Хотите повысить гибкость своей команды? В книге вы найдете четкие, конкретные
и подробные рекомендации о том, что, как и почему следует делать, а когда стоит пойти на компромиссы.
Джеймс Шор предлагает реальные решения по освоению, планированию, разработке и управлению,
основанные на более чем двадцатилетнем опыте Agile. Он объединяет актуальные идеи экстремального
программирования, Scrum, Lean, DevOps и многих других в единое целое. Узнайте, как успешно внедрить
гибкую разработку в вашей команде и организации, или разберитесь, почему Agile вам не подходит.
16+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.)
ББК 32.973-018
УДК 004.4:005.8
Права на издание получены по соглашению с 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
ЧАСТЬ I. УЛУЧШАЯ ГИБКОСТЬ

Глава 1. Что есть Agile..........................................................................................................................................34
Происхождение Agile.....................................................................................................................................34
Рожденный из кризиса..................................................................................................................................35
Манифест Agile..................................................................................................................................................35
Суть Agile..............................................................................................................................................................37
Адаптивность вместо предиктивности..........................................................................................37
Ориентированность на людей, а не на процессы.....................................................................38
Почему Agile победил....................................................................................................................................39
Почему Agile работает...................................................................................................................................40
Почему Agile терпит неудачу......................................................................................................................42
Глава 2. Как быть Agile.........................................................................................................................................44

Практика Agile...................................................................................................................................................44
Как достичь мастерства................................................................................................................................45
С чего начать?....................................................................................................................................................46
Присоединение к действующей команде Agile..........................................................................46
Введение Agile............................................................................................................................................46
Совершенствование действующих Agile-команд......................................................................47
Применение отдельных практик Agile............................................................................................48
6 Оглавление
Глава 3. Выберите свою гибкость...................................................................................................................49

Модель Agile Fluency......................................................................................................................................49
Уровень фокусировки (Focusing).......................................................................................................51
Уровень поставки (Delivering).............................................................................................................52
Уровень оптимизации (Optimizing)..................................................................................................53
Уровень укрепления (Strengthening)..............................................................................................53
Выберите свои уровни..................................................................................................................................54
Глава 4. Инвестируйте в гибкость...................................................................................................................56

Найдите время на обучение.......................................................................................................................58
Если нет времени на обучение…......................................................................................................60
Если нет средств на финансовую помощь…................................................................................60
Отберите или создайте Agile-команды..................................................................................................60
Если вы не можете закрепить людей за определенной командой…...............................62
Если члены команды не ладят друг с другом…..........................................................................62
Если вы не можете создать долгосрочную команду…............................................................62
Если вы не можете получить необходимых экспертов со знанием бизнеса,
клиентов или пользователей….........................................................................................................62
Если вы не можете получить необходимые вам навыки разработчиков…..................62
Выберите Agile-коучей..................................................................................................................................63
Если вы не можете нанять на работу нужных вам коучей…................................................63
Делегируйте полномочия и ответственность команде..................................................................63
Если работу нужно поручить отдельным людям…...................................................................64
Если корпоративные инструменты не поддерживают командную работу…...............64
Если команды должны использовать корпоративный инструмент
отслеживания…........................................................................................................................................65
Если у команды нет доступа к стейкхолдерам….......................................................................65
Если команда поставки не управляет своим процессом релиза…...................................65
Если команда оптимизации не управляет своими планами создания продукта
и расходами…............................................................................................................................................65
Измените стиль управления командой.................................................................................................66
Если менеджеры не могут отпустить ситуацию….....................................................................66
Организуйте рабочие помещения...........................................................................................................66
Если команда удаленная…...................................................................................................................67
Если вы не можете организовать физическое помещение
для офисной команды….......................................................................................................................67
Выберите команде подходящую для обучения задачу..................................................................67
Если есть важный дедлайн…..............................................................................................................68
Если нет значимой работы с нуля….................................................................................................68
Смените водопадные подходы в управлении....................................................................................68
Если требуется водопадная модель управления…..................................................................68
Измените вредные HR-политики .............................................................................................................69
Если HR-политики не подлежат изменению…............................................................................70
Оглавление 7
Решите проблемы, связанные с безопасностью...............................................................................70

Если требования безопасности не допускают гибкости…...................................................71
Если вам требуется дополнительный этап ревью кода…......................................................71
Глава 5. Инвестируйте в изменения..............................................................................................................75

Осознание изменений...................................................................................................................................75
Масштабные изменения...............................................................................................................................77
Процессы изменений.....................................................................................................................................78
Заручитесь поддержкой руководства....................................................................................................79
1. Начните с разговора...........................................................................................................................79
2. Получите одобрение экономичного покупателя..................................................................80
3. Сделайте официальное предложение.......................................................................................81
Если это выглядит слишком трудозатратным….........................................................................82
Если руководство считает, что они уже Agile…..........................................................................83
Если руководство не поддерживает…...........................................................................................83
Заинтересуйте команду................................................................................................................................85
Если команда настроена скептически…........................................................................................86
Если несколько членов команды против…..................................................................................86
Если большинство членов команды против…...........................................................................86
Если люди обманывают насчет своего согласия…...................................................................87
Заручитесь поддержкой стейкхолдеров..............................................................................................87
Если нужны конкретные обязательства…....................................................................................88
Если стейкхолдеры не спешат поддержать….............................................................................88
Литература для дополнительного чтения............................................................................................89
Глава 6. Масштабирование гибкости............................................................................................................90

Масштабирование свободного владения навыками......................................................................90
Организационный потенциал.............................................................................................................90
Коучинговый потенциал........................................................................................................................91
Потенциал команды.................................................................................................................................92
Масштабирование продуктов и портфелей........................................................................................93
Вертикальное масштабирование......................................................................................................93
Горизонтальное масштабирование..................................................................................................98
Вертикальное и горизонтальное масштабирование............................................................ 100
Моя рекомендация............................................................................................................................... 101
ЧАСТЬ II. ФОКУС НА ЦЕННОСТЬ

Добро пожаловать на уровень фокусировки.................................................................................. 105
Достижение свободного владения навыками на уровне фокусировки.............................. 107
Глава 7. Командная работа............................................................................................................................. 108

Вся команда..................................................................................................................................................... 109
Навыки в сфере деятельности заказчика................................................................................... 111
Навыки разработки............................................................................................................................... 114
Навыки коучинга.................................................................................................................................... 115

Специалисты широкого профиля.................................................................................................. 117
Комплектование команды................................................................................................................. 118
Размер команды..................................................................................................................................... 120
Команда единомышленников.......................................................................................................... 122
Еще раз о провальной команде...................................................................................................... 123
Вопросы..................................................................................................................................................... 124
Предварительные требования........................................................................................................ 124
Показатели................................................................................................................................................ 125
Альтернативы и эксперименты....................................................................................................... 125
Литература для дополнительного чтения.................................................................................. 125
Командная комната...................................................................................................................................... 126
Секреты сотрудничества.................................................................................................................... 128
Физические командные комнаты................................................................................................... 132
Виртуальные командные комнаты................................................................................................ 138
Вопросы..................................................................................................................................................... 141
Показатели................................................................................................................................................ 142
Безопасность.................................................................................................................................................. 143
Понятие психологической безопасности................................................................................... 144
Как создать атмосферу безопасности.......................................................................................... 144
Роль лидера.............................................................................................................................................. 148
Вопросы..................................................................................................................................................... 150
Показатели................................................................................................................................................ 151
Цель..................................................................................................................................................................... 152
Начните с ви́дения................................................................................................................................. 153
Идентифицируйте цель....................................................................................................................... 153
Задокументируйте цель...................................................................................................................... 155
Внесите цель в свой устав.................................................................................................................. 157
Продвигайте цель.................................................................................................................................. 160
Обновляйте цель.................................................................................................................................... 161
Вопросы..................................................................................................................................................... 161
Показатели................................................................................................................................................ 162
Контекст............................................................................................................................................................. 163
Запишите контекст в устав................................................................................................................. 163
Обновляйте контекст........................................................................................................................... 168
Вопросы..................................................................................................................................................... 168
Показатели................................................................................................................................................ 168
Согласование.................................................................................................................................................. 169
Запишите договоренности в устав................................................................................................ 170
Обновляйте соглашения..................................................................................................................... 174
Придерживайтесь договоренностей............................................................................................ 175
Вопросы..................................................................................................................................................... 177
Показатели................................................................................................................................................ 177
Энергичная работа....................................................................................................................................... 178
Как быть энергичным........................................................................................................................... 179
Поддерживайте энергичную работу............................................................................................. 179
Делайте перерывы................................................................................................................................ 181
Вопросы..................................................................................................................................................... 181
Показатели................................................................................................................................................ 182
Глава 8. Планирование..................................................................................................................................... 184

Истории............................................................................................................................................................. 185
Как написать историю......................................................................................................................... 186
Ценность для заказчика...................................................................................................................... 187
Разделение и объединение историй............................................................................................ 188
Специальные истории......................................................................................................................... 190
Вопросы..................................................................................................................................................... 193
Показатели................................................................................................................................................ 194
Адаптивное планирование...................................................................................................................... 196
Ценные инкременты............................................................................................................................. 196
Фокус на один инкремент за раз.................................................................................................... 198
Разделите инкременты........................................................................................................................ 200
Делайте частые релизы и как можно раньше.......................................................................... 201
Ваш первый инкремент....................................................................................................................... 203
Адаптируйте свои планы.................................................................................................................... 204
Как создать план..................................................................................................................................... 206

Баланс адаптивности и предсказуемости.................................................................................. 209
Адаптивное планирование и организационная культура.................................................. 211
Вопросы..................................................................................................................................................... 212
Показатели................................................................................................................................................ 213
Визуальное планирование....................................................................................................................... 214
Кто планирует?........................................................................................................................................ 214
Картирование кластеров................................................................................................................... 215
Дальнейшая разбивка инкрементов............................................................................................ 217
Карты влияния........................................................................................................................................ 219
Перспективный анализ....................................................................................................................... 222
Составление карты историй............................................................................................................. 224
Обновление визуального плана..................................................................................................... 227
Вопросы..................................................................................................................................................... 228
Показатели................................................................................................................................................ 229
Игра в планирование.................................................................................................................................. 230
Как играть.................................................................................................................................................. 231
Держите открытым окно возможностей..................................................................................... 234
Как выиграть в игре в планирование........................................................................................... 235
Приоритизация решений по разработке................................................................................... 236
Лицом к лицу с реальностью............................................................................................................ 237
Повторение игры в планирование................................................................................................ 237
Вопросы..................................................................................................................................................... 238
Показатели................................................................................................................................................ 239
Вовлечение реального заказчика......................................................................................................... 239
Разработка для собственных нужд................................................................................................ 240
Разработка платформ.......................................................................................................................... 241
Внутренняя разработка на заказ.................................................................................................... 241
Аутсорсинг разработки....................................................................................................................... 242
Программное обеспечение для вертикального рынка....................................................... 243
Программное обеспечение для горизонтального рынка.................................................. 244
Вопросы..................................................................................................................................................... 244
Показатели................................................................................................................................................ 245
Инкрементные требования...................................................................................................................... 246
Изменяемый документ с требованиями..................................................................................... 246
Когда эксперты не являются частью команды......................................................................... 247
Работайте инкрементно...................................................................................................................... 247
Документация.......................................................................................................................................... 249
Вопросы..................................................................................................................................................... 251
Показатели................................................................................................................................................ 252
Глава 9. Владение................................................................................................................................................ 254

Планирование задач................................................................................................................................... 256
Рабочий ритм .......................................................................................................................................... 256
Создание задач....................................................................................................................................... 259
Визуальное отслеживание................................................................................................................. 261
Кросс-командные зависимости...................................................................................................... 264
Принятие и выполнение обязательств по итерации............................................................ 265
Незаконченные истории.................................................................................................................... 266
Срочные запросы.................................................................................................................................. 266
Ваша первая неделя............................................................................................................................. 267
Вопросы..................................................................................................................................................... 269
Показатели................................................................................................................................................ 271
Потенциал......................................................................................................................................................... 272
Вчерашняя погода................................................................................................................................. 273
Потенциал и временные рамки итерации................................................................................. 274
Стабилизация потенциала................................................................................................................. 274
Оценка историй...................................................................................................................................... 277
Когда оценить трудно.......................................................................................................................... 281
Защита оценки........................................................................................................................................ 282
Ваш начальный потенциал................................................................................................................ 284
Как улучшить потенциал.................................................................................................................... 284
Потенциал — это не производительность................................................................................ 286
Вопросы..................................................................................................................................................... 288
Показатели................................................................................................................................................ 290
Резерв времени............................................................................................................................................. 291

Сколько резерва нужно...................................................................................................................... 291
Как использовать резерв................................................................................................................... 292
Вопросы..................................................................................................................................................... 295
Показатели................................................................................................................................................ 296
Стендап-митинги........................................................................................................................................... 297
Как проводить ежедневные стендапы......................................................................................... 298
Будьте краткими..................................................................................................................................... 301
Вопросы..................................................................................................................................................... 302
Показатели................................................................................................................................................ 303
Информативное рабочее пространство............................................................................................ 303
Тонкие сигналы....................................................................................................................................... 304
Большие наглядные диаграммы..................................................................................................... 305
Диаграммы улучшений....................................................................................................................... 306
Игры............................................................................................................................................................. 307
Вопросы..................................................................................................................................................... 308
Показатели................................................................................................................................................ 308
Примеры заказчика..................................................................................................................................... 309
Описать....................................................................................................................................................... 310
Продемонстрировать.......................................................................................................................... 311
Разработать.............................................................................................................................................. 313
Вопросы..................................................................................................................................................... 314
Показатели................................................................................................................................................ 314
Сделано Сделано.......................................................................................................................................... 315
Как быть в статусе «Сделано Сделано»........................................................................................ 317
Находить время...................................................................................................................................... 319
Организационные ограничения..................................................................................................... 319
Вопросы..................................................................................................................................................... 320
Показатели................................................................................................................................................ 321
Глава 10. Ответственность.............................................................................................................................. 322

Доверие стейкхолдеров............................................................................................................................ 323
Добавьте немного суеты..................................................................................................................... 324
Проявите эмпатию................................................................................................................................. 325
Выполняйте обязательства............................................................................................................... 325
Управляйте проблемами.................................................................................................................... 326
Уважайте цели заказчика................................................................................................................... 328
Сделайте так, чтобы стейкхолдеры выглядели хорошо...................................................... 329
Будьте честны.......................................................................................................................................... 329
Вопросы..................................................................................................................................................... 330
Показатели................................................................................................................................................ 330
Демо для стейкхолдеров........................................................................................................................... 331
Петли обратной связи.......................................................................................................................... 331
Частота демо............................................................................................................................................ 332
Как проводить демо для стейкхолдеров.................................................................................... 333
Подготовьтесь......................................................................................................................................... 335
Когда дела идут плохо......................................................................................................................... 336
Вопросы..................................................................................................................................................... 337
Показатели................................................................................................................................................ 338
Прогнозирование......................................................................................................................................... 339
Неопределенность и риск................................................................................................................. 340
Запланированные даты релизов.................................................................................................... 341
Прогнозы осуществимости............................................................................................................... 342
Прогнозы сроков и объема работы.............................................................................................. 343
Вопросы..................................................................................................................................................... 348
Показатели................................................................................................................................................ 349
Дорожные карты........................................................................................................................................... 350
Agile-руководство................................................................................................................................. 350
Вариант 1. Только факты .................................................................................................................... 351
Вариант 2. Общее направление...................................................................................................... 352
Вариант 3. Дата и примерный объем работы........................................................................... 352
Вариант 4. Детальные планы и прогнозы................................................................................... 353
Корпоративные системы отслеживания..................................................................................... 354
Когда дорожная карта недостаточно хороша ......................................................................... 355
Вопросы..................................................................................................................................................... 357

Показатели................................................................................................................................................ 357
Менеджмент.................................................................................................................................................... 358
Теория X и теория Y.............................................................................................................................. 359
Роль руководителя в Agile................................................................................................................. 360
Дисфункция измерений...................................................................................................................... 361
Почему дисфункция измерений неизбежна............................................................................. 362
Делегируемое управление................................................................................................................ 364
Когда показатели необходимы........................................................................................................ 366
Вопросы..................................................................................................................................................... 367
Показатели................................................................................................................................................ 368
Глава 11. Совершенствование...................................................................................................................... 370

Ретроспективы............................................................................................................................................... 371
Виды ретроспектив............................................................................................................................... 372
Как проводить пульсирующие ретроспективы....................................................................... 372
Шаг 1. Первая директива (5 минут)................................................................................................ 373
Шаг 2. Мозговой штурм (20 минут)................................................................................................ 374
Шаг 3. Безмолвное сопоставление (15 минут).......................................................................... 374
Шаг 4. Генерация идей (инсайтов) (10–30 минут).................................................................... 375
Шаг 5. Цель ретроспективы (10–20 минут)................................................................................. 375
Довести дело до конца........................................................................................................................ 376
Вопросы..................................................................................................................................................... 376
Показатели................................................................................................................................................ 378
Динамики команды...................................................................................................................................... 379
Что формирует команду..................................................................................................................... 379
Развитие команды................................................................................................................................. 380
Коммуникация, сотрудничество и взаимодействие.............................................................. 386
Совместное лидерство ....................................................................................................................... 388
Токсичное поведение.......................................................................................................................... 391
Вопросы..................................................................................................................................................... 392
Показатели................................................................................................................................................ 393
Устранение препятствий........................................................................................................................... 394

Выявление препятствий..................................................................................................................... 395
Круги и суп................................................................................................................................................ 395
Вопросы..................................................................................................................................................... 399
Показатели................................................................................................................................................ 400
ЧАСТЬ III. НАДЕЖНАЯ ПОСТАВКА

Добро пожаловать на уровень поставки........................................................................................... 402
Достижение свободного владения навыками на уровне поставки...................................... 404
Глава 12. Сотрудничество .............................................................................................................................. 406

Коллективное владение кодом.............................................................................................................. 407
Как заставить коллективное владение работать.................................................................... 407
Программирование без эго.............................................................................................................. 408
Сотрудничество без конфликтов.................................................................................................... 409
Работа с незнакомым кодом ............................................................................................................ 410
Преимущества для программистов.............................................................................................. 411
Вопросы..................................................................................................................................................... 412
Показатели................................................................................................................................................ 413
Парное программирование..................................................................................................................... 414
Почему парное? ..................................................................................................................................... 415
Рабочие станции для парного программирования .............................................................. 415
Как работать в паре.............................................................................................................................. 416
Эффективная навигация..................................................................................................................... 418
Обучение при работе в паре............................................................................................................ 419
Трудности.................................................................................................................................................. 419
Вопросы..................................................................................................................................................... 421
Показатели................................................................................................................................................ 423
Групповое программирование............................................................................................................... 425
Как работать в групповом программировании....................................................................... 426
Почему групповое программирование работает.................................................................. 427
Рабочая станция для группового программирования......................................................... 427
Как заставить режим группового программирования работать..................................... 427
Вопросы..................................................................................................................................................... 430
Показатели................................................................................................................................................ 430
Единый язык.................................................................................................................................................... 431
Дилемма экспертных знаний в предметной области........................................................... 431
Говорить на одном языке................................................................................................................... 432
Как создать единый язык................................................................................................................... 432
Вопросы..................................................................................................................................................... 435
Показатели................................................................................................................................................ 436
Глава 13. Разработка.......................................................................................................................................... 437

Нулевое трение.............................................................................................................................................. 438
Обратная связь за секунду................................................................................................................ 439
Знайте свой редактор ......................................................................................................................... 441
Воспроизводимые сборки................................................................................................................. 441
Пятиминутная интеграция................................................................................................................. 443
Контролировать сложность.............................................................................................................. 444
Автоматизировать все......................................................................................................................... 444
Автоматизируйте инкрементно...................................................................................................... 445
Автоматизация устаревшего кода................................................................................................. 446
Вопросы..................................................................................................................................................... 447
Показатели................................................................................................................................................ 448
Непрерывная интеграция......................................................................................................................... 449
Непрерывная интеграция — это практика, а не инструмент............................................ 450
Множество разновидностей непрерывной интеграции..................................................... 452
Танец непрерывной интеграции.................................................................................................... 453
Непрерывная интеграция без CI-сервера.................................................................................. 454
Синхронная или асинхронная интеграция................................................................................ 455
Многоступенчатые интеграционные сборки........................................................................... 456
Запросы на слияние кодов (пул-реквесты) и ревью кода................................................... 457
Вопросы..................................................................................................................................................... 458
Показатели................................................................................................................................................ 460
Разработка через тестирование............................................................................................................ 461
Почему TDD работает........................................................................................................................... 461
Как использовать TDD......................................................................................................................... 463
Ешьте луковицу с середины.............................................................................................................. 466

Пример TDD.............................................................................................................................................. 467
Вопросы..................................................................................................................................................... 474
Показатели................................................................................................................................................ 476
Быстрые надежные тесты.......................................................................................................................... 477
Использование узких модульных тестов.................................................................................... 478
Тестирование внешних взаимодействий с помощью узких
интеграционных тестов...................................................................................................................... 479
Моделирование нелокальных зависимостей.......................................................................... 479
Контроль глобального состояния.................................................................................................. 480
Написание коммуникативных тестов........................................................................................... 480
Разделение инфраструктуры и логики........................................................................................ 482
Применение широких тестов только в качестве страховочной сетки ........................ 482
Добавление тестов к существующему коду............................................................................... 483
Показатели................................................................................................................................................ 484
Рефакторинг ................................................................................................................................................... 485
Как делать рефакторинг..................................................................................................................... 485
Рефакторинг в действии..................................................................................................................... 486
Вопросы .................................................................................................................................................... 494
Показатели................................................................................................................................................ 496
Спайк-решения ............................................................................................................................................. 497
Простые вопросы.................................................................................................................................. 497
Сторонние зависимости..................................................................................................................... 498
Дизайн-эксперименты......................................................................................................................... 498
Найдите время для спайков.............................................................................................................. 499
Вопросы..................................................................................................................................................... 499
Показатели................................................................................................................................................ 500
Глава 14. Дизайн.................................................................................................................................................. 502

Инкрементный дизайн............................................................................................................................... 505
Никогда не останавливайте работу над дизайном................................................................ 505
Как работает инкрементный дизайн............................................................................................ 506
Уровни дизайна...................................................................................................................................... 507

Архитектура на основе рисков........................................................................................................ 511
Вопросы..................................................................................................................................................... 513
Показатели................................................................................................................................................ 515
Простой дизайн............................................................................................................................................. 516
Вам это не понадобится (YAGNI: You Aren’t Gonna Need It)................................................. 517
Однажды и только однажды............................................................................................................. 517
Связанность и сплоченность........................................................................................................... 519
Сторонние компоненты...................................................................................................................... 519
Быстрое завершение с ошибкой.................................................................................................... 520
Самодокументируемый код.............................................................................................................. 521
Опубликованные интерфейсы ........................................................................................................ 522
Оптимизация производительности ............................................................................................. 523
Вопросы..................................................................................................................................................... 523
Показатели................................................................................................................................................ 524
Рефлексивный дизайн................................................................................................................................ 525
Как работает рефлексивный дизайн............................................................................................. 526
Рефлексивный дизайн на практике............................................................................................... 526
Реверс-инжиниринг дизайна........................................................................................................... 529
Определение улучшений................................................................................................................... 530
Проблемный код.................................................................................................................................... 531
Выполняйте рефакторинг инкрементно..................................................................................... 533
Вопросы..................................................................................................................................................... 534
Показатели................................................................................................................................................ 535
Глава 15. DevOps.................................................................................................................................................. 536

Сборка для эксплуатации.......................................................................................................................... 537
Моделирование угроз......................................................................................................................... 538
Конфигурация......................................................................................................................................... 539
Секреты...................................................................................................................................................... 540
Параноидальная телеметрия........................................................................................................... 540
Ведение журнала событий ............................................................................................................... 541
Показатели и пригодность к наблюдению................................................................................. 543
Мониторинг и оповещения............................................................................................................... 544
Вопросы..................................................................................................................................................... 547
Показатели................................................................................................................................................ 548
Флаги функций............................................................................................................................................... 549
Замковый камень .................................................................................................................................. 549
Флаги функций........................................................................................................................................ 550
Показатели................................................................................................................................................ 553
Непрерывное развертывание................................................................................................................ 554
Как использовать непрерывное развертывание.................................................................... 554
Обнаружение сбоев развертывания............................................................................................ 555
Устранение сбоев развертывания................................................................................................. 555
Инкрементные релизы........................................................................................................................ 557
Миграция данных ................................................................................................................................. 558
Показатели................................................................................................................................................ 559
Эволюционная системная архитектура.............................................................................................. 560
Вам действительно это понадобится? ......................................................................................... 561
Нацеленность на простоту................................................................................................................ 562
Контроль сложности ........................................................................................................................... 563
Рефакторинг системной архитектуры ........................................................................................ 565
Показатели................................................................................................................................................ 569
Глава 16. Качество.............................................................................................................................................. 570

Без багов........................................................................................................................................................... 571
Не ищите виноватого в багах........................................................................................................... 572
Как встроить качество......................................................................................................................... 573
Исправляйте баги незамедлительно............................................................................................ 576
Роль тестировщика............................................................................................................................... 577
Правильное мироощущение............................................................................................................ 577
Вопросы..................................................................................................................................................... 578
Показатели................................................................................................................................................ 579
Обнаружение слепых зон......................................................................................................................... 580

Подтвержденное знание.................................................................................................................... 580
Исследовательское тестирование................................................................................................. 582
Хаос-инжиниринг.................................................................................................................................. 583
Тестирование на проникновение и оценка уязвимостей................................................... 584
Вопросы..................................................................................................................................................... 585
Показатели................................................................................................................................................ 586
Анализ инцидентов...................................................................................................................................... 587
Природа сбоя.......................................................................................................................................... 588
Проведение анализа............................................................................................................................ 590
Обучение организации....................................................................................................................... 597
Ответственность за инциденты....................................................................................................... 598
Вопросы..................................................................................................................................................... 598
Показатели................................................................................................................................................ 599
ЧАСТЬ IV. ОПТИМИЗАЦИЯ РЕЗУЛЬТАТОВ

Добро пожаловать в область оптимизации..................................................................................... 602
Достижение навыков на уровне оптимизации............................................................................... 604
Глава 17. Автономность................................................................................................................................... 605

Экспертные знания в области заказчика........................................................................................... 605
Бизнес-решения............................................................................................................................................ 606
Ответственность и надзор ....................................................................................................................... 607
Финансирование........................................................................................................................................... 607
Эксперименты и литература для дополнительного чтения...................................................... 608
Глава 18. Открытия............................................................................................................................................. 609

Подтвержденное знание........................................................................................................................... 610
Способность к адаптации.......................................................................................................................... 610
Эксперименты и литература для дополнительного чтения...................................................... 612
Глава 19. Взгляд в будущее ............................................................................................................................ 613
Библиография........................................................................................................................................................ 615
Об авторе................................................................................................................................................................. 623
Отзывы
Автор «Искусства Agile-разработки» смог совершить, казалось бы, невозможное,

собрав все материалы по обширнейшей теме разработки современного программ-
ного обеспечения в понятную и увлекательную книгу. Новички, лишь начинающие
изучать итеративные процессы, найдут в ней отличный обзор популярных практик.
Людям, заблудившимся в дебрях мудреных процессов «масштабизации Agile», она
предлагает хорошие идеи выхода из этого ада. Первое издание оказало огромное вли-
яние на мою карьеру два десятилетия назад, и, уверен, второе издание аналогичным
образом поможет миллионам разработчиков улучшить свои методы поставки ПО.
Гойко Аджич, автор книг Running Serverless,
Impact Mapping и Specification by Example
В этой книге есть все: от кода до поставки готового продукта. Заработанные деся-
тилетиями тяжелого труда знания превратились в легкочитаемый и доступный для
восприятия материал — обязательный к прочтению для всех, кто работает с командой
разработчиков программного обеспечения или в ней.
Ави Кесснер, инженер, Forter
Эта книга получит свое постоянное место на моей книжной полке.

Кришна Кумар, основатель и CEO,
Exathink Research
Первое издание этой книги заворожило меня до такой степени, что до сих пор стоит
на моей книжной полке в качестве справочника. Второе издание сохраняет шарм
своего предшественника и содержит еще больше знаний, накопленных за последнее
десятилетие.
Бенджамин Мускалла,
старший инженер-программист, GitHub
Одна из самых полных книг по Agile-разработке программного обеспечения, которые

я когда-либо читала. Очень прагматичная, с яркими примерами, легко применимыми
к любому проекту разработки ПО независимо от технологического стека, размера
команды или предметной области отрасли. Определенно жемчужина, стоящая того,
чтобы держать ее под рукой.
Луиза Нуньес, менеджер программ,
Thoughtworks
22 Отзывы
Это моя любимая книга об Agile. Она охватывает технические и управленческие

темы. Я использую ее на своих занятиях и всегда рекомендую своим клиентам.
Николас Паес, инженер-программист
и преподаватель, Университет Буэнос-Айреса
Джеймс подробнейшим образом описывает собственный опыт в Agile-разработке ПО.

Простыми словами, связывая теорию с практикой.
Кен Пью, главный консультант, автор книги
Prefactoring: Extreme Abstraction, Extreme Separation,
Extreme Readability
Тысячи книг об Agile. Какую из них прочитать? Я советую вам эту. Джеймс рабо-
тает с Agile с первых дней его появления и знает свое дело. Книга разбирает весь
бессмысленный мусор в нашей отрасли, окружающий это понятие, и предлагает
тщательно выверенный, целостный подход. Этот подход не будет быстрым и лег-
ким, но он того стоит. Мне понравилась книга «Искусство Agile-разработки». Это
книга с характером!
Бас Водде, соавтор LeSS
Джеймс Шор полностью обновил «Искусство Agile-разработки», дополнив книгу

новыми инструментами, методами и уроками прошедшего десятилетия. Эта жем-
чужина среди книг поможет вам превратить ваш стиль работы в действительно
эффективный Agile-подход.
Билл Уэйк, XP123, LLC
Моей семье
Предисловие
Когда мы писали Манифест Agile для разработки программного обеспечения, наши-

ми сторонниками было незначительное меньшинство людей, пытавшихся изменить
отрасль. Сейчас, 20 лет спустя, «agile» — это мейнстрим. Я пишу «agile» в кавычках
намеренно: множество людей говорят, что они занимаются разработкой программно-
го обеспечения по Agile, в самом деле искренне в это веря, однако их действия мало
напоминают то ви́дение, которым мы поделились со всеми два десятилетия назад.
Правда в том, что для работы по Agile требуется целая сеть взаимосвязанных
практик, охватывающая как управление, так и техническую работу по созданию ПО.
Многие из этих практик, особенно технические, далеко не всем хорошо понятны или
не изучаются широко. Следовательно, слишком многие люди имеют искаженное
представление о том, что могло бы быть очень эффективным способом создания
программных продуктов.
Джеймс Шор был одним из пионеров, вставших на тропу экстремального про-
граммирования (Extreme Programming, XP), центрального элемента движения Agile.
Первое издание этой книги было отличным руководством для команд, показывавшим
им, что нужно знать для правильного выполнения Agile-процессов. Позже Джеймс
вместе с Дианой Ларсен продолжили работу над созданием модели Agile Fluency™,
которая объединила в себе их опыт развития навыков в использовании подходов
Agile. Модель показывает, что простое применение техник проектного управления,
часто именуемых базовым подходом Scrum, дает некую ценность, фокусируя внима-
ние на потребностях клиентов, но не учитывает технических навыков, необходимых
для того, чтобы полностью раскрыть преимущества высокой производительности
и надежности, которых добиваются многие команды.
Эта позиция непосредственно определяет структуру книги, значительная часть
которой посвящена тому, как сфокусироваться на создании реальной ценности
и как надежно поставить ее потребителю продукта. «Сфокусироваться на ценности»
означает понимать потенциал командной работы, развивать навыки адаптивного
планирования и тесно сотрудничать с заказчиками и конечными пользователями
готового ПО. В понятие «надежно поставить ценность» входят основные технические
практики тестирования, рефакторинга, дизайна и коллективной разработки. Оно
также учитывает парадоксальное наблюдение, что создание программного обеспече-
ния, обладающего высоким внутренним качеством, снижает затраты и увеличивает
скорость поставки продукта. Сочетание культуры DevOps и непрерывной поставки
(continuous delivery) дает возможность быстро вводить в эксплуатацию множество
функций, а это, в свою очередь, позволяет командам понять, что является ценным
в программном обеспечении, наблюдая, как оно используется на практике.
Предисловие 25
Двадцать лет назад мне повезло найти свое место в компании Thoughtworks,
где наши команды используют такие навыки, чтобы создавать для наших клиентов
новые программные продукты и заменять ими устаревшие. Как и Джеймс, мы обна-
ружили, что техники экстремального программирования служили надежной основой
для нашей работы, и мы весьма успешно применяли их в течение последних двух
десятилетий. Поэтому я очень рад, что Джеймс переписал свою книгу, добавив в нее
опыт еще одного десятилетия своей работы в роли коуча. В результате получился
прочный фундамент для изучения тех навыков, которые нам так помогли. Как и все
действительно стоящее, обучение займет время, и на вашем пути будут разочаро-
вания. Но этот путеводитель может вам помочь — избавив от безрезультативных
церемоний и приведя к источнику силы, которую мы с Джеймсом почувствовали,
впервые применив эти методы много лет назад.
Мартин Фаулер, Chief Scientist, Thoughtworks
Введение
Вопрос: Что нужно делать, чтобы выступить в Карнеги-холле?

Ответ: Практиковаться, практиковаться и еще раз практиковаться.
Я хочу помочь вам овладеть мастерством Agile-разработки.
Agile, как и любой командный подход к разработке программного обеспече-
ния, — в своей основе человеческое искусство, зависящее от капризов людей и их
взаимодействия. Чтобы мастерски овладеть Agile-разработкой, вам нужно научиться
ежеминутно оценивать множество возможностей и интуитивно выбирать лучшее
направление действий.
Как можно научиться такому сложному искусству? Практикуясь!
Во-первых, эта книга — руководство. Она содержит подробное описание одного
из способов практического применения Agile. Книга основана на экстремальном
программировании, но также берет идеи и практики из Scrum, Kanban, DevOps,
Lean Software Development, Lean Startup и др. В конечном счете это практическое
пособие, которое позволит вам успешно внедрить Agile-разработку в вашу команду
и организацию или поможет обнаружить, что Agile не подходит в вашей ситуации.
Во-вторых, эта книга призвана помочь вам овладеть мастерством Agile-разработки.
Освоить Agile означает выйти за рамки книги рецептов. Разработка программного
обеспечения — слишком чувствительный к контексту процесс, чтобы какой-то один
подход подошел вам полностью, и слишком богатый нюансами, чтобы какая-то кни-
га могла научить вас, как его освоить. Мастерство приходит изнутри — благодаря
опыту и интуитивному пониманию природы волн, вызванных брошенным в воду
камнем вашего выбора.
Я не могу спрогнозировать, какую волну поднимет ваш выбор в вашей органи-
зации. Я и не пытаюсь. Вы должны сами определить нюансы и достичь понимания.
Это единственный способ овладеть искусством. Следуйте практикам. Смотрите, что
происходит. Думайте, почему они сработали… или не сработали. Потом повторяйте.
Что было таким же? Что получилось по-другому? Почему? Потом делайте это снова.
И снова.
Поначалу вам может быть трудно понять, как использовать каждую из практик.
Они могут выглядеть простыми на бумаге, но сложными в реальном применении.
Продолжайте практиковаться, пока не станет легче.
По мере того как применять Agile станет проще, вы обнаружите, что некоторые
мои советы для вас не работают. Поначалу вы не сможете различить, в чем пробле-
ма: в инструкциях, которые я дал, или в том, как вы их выполняете. Продолжайте
практиковаться, пока не почувствуете уверенность. Как только это произойдет, на-
рушьте правила. Измените мои инструкции так, чтобы они работали лучше в вашей
Введение 27
конкретной ситуации. В каждой практике есть подраздел «Альтернативы и экспе-

рименты», содержащий идеи для исследований.
Однажды правила перестанут вас интересовать. В конце концов, Agile не о том,
чтобы следовать правилам. Тогда вы подумаете: «Речь о простоте и обратной связи,
общении и доверии. О поставке ценности и смелости делать правильные вещи в нуж-
ное время». Вы станете мгновенно оценивать множество возможностей и интуитивно
выбирать лучшее направление действий.
Когда этот момент настанет, отдайте книгу (пусть и с загнутыми уголками страниц
и, возможно, слегка потрепанную) кому-нибудь еще, чтобы эти люди тоже смогли
овладеть искусством разработки Agile.
ДЛЯ ПРАГМАТИКОВ
А что, если вы не хотите овладевать так называемым «искусством»? Что, если вы
хотите просто разрабатывать хорошее ПО?
Не волнуйтесь. Эта книга и для вас тоже. На основе моего многолетнего опыта
Agile-разработки я создал единый, четко определенный, комплексный подход.
Это позволяет мне использовать простой язык. Я даю много практических сове-
тов. Я честно пишу, когда мой подход не будет работать и какие альтернативы можно
рассмотреть в таком случае. Глава 2 поможет вам начать.
Есть и обратная сторона обсуждения только одного подхода: ни один под-
ход не применим ко всем случаям. Мой совет может быть непригоден для вашей
команды или организации. Прочтите главы 4 и 5, чтобы понять, на каких общих
условиях возможен успех, и изучите подраздел «Предварительные требования»
каждой практики.
Не стоит сразу думать, что какая-либо конкретная практика вам не подходит.
Некоторые практики, описанные в этой книге, противоречат здравому смыслу или
просто не кажутся интересными. Большинство из них лучше всего работают в со-
четании с другими. Если можете, то попробуйте применять практики, как написано,
в течение нескольких месяцев, получите реальный опыт их работы в ваших условиях
и потом измените их.
Я применяю эти идеи в реальной работе уже более 20 лет. В правильной среде
они действительно работают. Agile оказывается более увлекательным и успешным,
чем любой другой подход к разработке программного обеспечения, который я про-
бовал. Присоединяйтесь.
ЧТО НОВОГО ВО ВТОРОМ ИЗДАНИИ

Первое издание было полностью переработано. Во втором издании сохранен призем-
ленный, практический подход, свойственный первому изданию, как и большинство
приводившихся в нем практик. Но почти все они были переписаны с учетом 14 лет
прогресса Agile, не говоря уже о моем собственном 14-летнем опыте.
28 Введение
Я полностью переработал книгу, чтобы она позволяла обеспечить постепенное

внедрение Agile и лучше отражала реальное использование командами. Принципы
и настройки, обсуждавшиеся в части III первого издания, были распределены между
практиками, чтобы сделать их более заметными и понятными, и я внес в каждую
практику предложения по экспериментам.
Среди наиболее заметных дополнений:
zz подробное руководство по внедрению Agile и адаптации этого внедрения к по-
требностям вашей компании, основанное на модели Agile FluencyТМ1, которую
я создал вместе с Дианой Ларсен;
zz новая глава о масштабировании Agile, основанная на моем опыте помощи боль-
шим и маленьким компаниям;
zz новая глава о DevOps, содержащая новый материал о работе в сфере эксплуатации
и безопасности, а также вдохновленные темой DevOps обновления по остальной
части книги;
zz руководство по внедрению Agile для работы с удаленными командами; много
новых практик, историй и идей; а также слишком много других улучшений и из-
менений, чтобы упомянуть их все.
ДЛЯ КОГО ПРЕДНАЗНАЧЕНА КНИГА

Эта книга для каждого, кто уже работает с командой Agile или надеется работать в бу-
дущем. Сюда входят, конечно же, программисты, а также менеджеры, руководители
высшего звена, эксперты в предметных областях, тестировщики, продакт-менеджеры,
руководители проектов, архитекторы, сотрудники отделов эксплуатации и отделов
безопасности, дизайнеры и бизнес-аналитики. Команды Agile кросс-функциональны;
книга отражает этот факт.
Книга представляет собой краткий справочник, но ее также можно читать
и подряд, от корки до корки. Каждая практика в частях II–IV предназначена для
самостоятельного чтения. Блоки «См. также» и ссылки на источники помогут вам
сопоставить информацию. Вдобавок печатное издание можно открыть в любом ме-
сте и быстро просмотреть интересующую информацию. Можете пролистать книгу
и остановиться, чтобы прочитать какую-то врезку более внимательно, если она
привлечет ваше внимание.
Если вы менеджер или руководитель высшего звена, который хочет понять, как
Agile может или должен работать в вашей компании, то прочитайте часть I. Если вы
руководитель командного уровня, то прочтите еще и раздел «Менеджмент» главы 10
и, возможно, другие практики, рассматриваемые в той же главе.
Если вы член команды или менеджер, заинтересованный в том, чтобы внедрить
Agile в свою компанию или улучшить уже работающую в ней практику Agile, то
прочитайте всю книгу целиком. Часть I поможет вам понять, как представить идеи
1
Agile Fluency — зарегистрированный товарный знак Agile Fluency Project LLC.
Введение 29
Agile коллегам. Остальной материал книги поможет разобраться, как воплотить

Agile в жизнь.
Если вы часть Agile-команды и просто хотите получить знания, которые позво-
лят выполнять вашу работу, то можете сосредоточиться на практиках, изложенных
в частях II и III. Начните с главы 1, чтобы получить общую картину, затем перейдите
к тем практикам, которые использует ваша команда.
Если вы не являетесь частью Agile-команды, но работаете с одной из них, то
посоветуйтесь с ними, что почитать. Продакт-менеджеры, владельцы продукта,
дизайнеры могут начать с главы 8 и раздела «Цель» главы 7. Сотрудникам отделов
безопасности и отделов эксплуатации рекомендую разделы «Сборка для эксплуа
тации» главы 15, «Обнаружение слепых зон» и «Анализ инцидентов» главы 16.
Тестировщики, ознакомьтесь с главой 16.
Если вам просто любопытно узнать об Agile, то начните с главы 1. После этого
ознакомьтесь с частями II–IV. Начните с наиболее интересных для вас практик.
Можете читать их в любом порядке.
О ПРИГЛАШЕННЫХ АВТОРАХ
Эта книга создана в соавторстве с несколькими выдающимися людьми. Гитте
Клитгаард написала раздел «Безопасность» главы 7, профессионально осветив
тему психологической безопасности. Диана Ларсен написала разделы «Динамики
команды» и «Устранение препятствий» главы 11, поделившись своим многолетним
опытом организационного и командного развития. Шейн Уорден, мой соавтор
первого издания, не смог написать новый материал для второго, но остался на-
дежным и ценным советчиком, и наша работа над первым изданием легла в основу
этой книги.
Гитте Клитгаард
Гитте Клитгаард — Agile-коуч, инструктор и наставник, специализирующаяся на
помощи организациям в формировании психологической безопасности и ответ-
ственности. Гитте сразу переходит к сути дела и помогает людям стать самими собой
и таким образом достичь успеха.
Ее вклад в сообщество включает организацию встреч для тренеров и выступления
на конференциях, где она поднимает темы психического здоровья и психологической
безопасности и делает их доступными для общего понимания. Гитте создает без-
опасную и уважительную атмосферу на работе и за ее пределами. Она умеет слушать
и вовлекать в обсуждение более тихие голоса и малые сообщества.
В свободное время Гитте собирает LEGO, коллекционирует фигурки Йоды
и поддерживает связь с друзьями со всего земного шара, многих из которых она
считает своей второй семьей.
Гитте является владельцем Native Wired и руководила преобразованиями в таких
компаниях, как LEGO, Spotify и Mentimeter.
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
ИСПОЛЬЗОВАНИЕ ПРИМЕРОВ КОДА

Дополнительные материалы доступны для скачивания по ссылке https://www.james
shore.com/v2/books/aoad2.
Пожалуйста, напишите по адресу электронной почты bookquestions@oreilly.com,
если у вас технический вопрос или проблема с использованием материалов.
Эта книга призвана помочь в решении ваших задач. В общем случае все приме-
ры кода из книги вы можете использовать в своих программах и в документации.
Вам не нужно обращаться в издательство за разрешением, если вы не собираетесь
воспроизводить существенные части кода, или если вы разрабатываете программу
и используете в ней несколько фрагментов кода из книги, или если будете цитировать
эту книгу либо примеры из нее, отвечая на вопросы. Вам потребуется разрешение
от издательства O’Reilly, если вы хотите продавать или распространять примеры из
книги либо хотите включить существенные объемы программного кода из книги
в документацию вашего продукта.
Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при ци-
тировании. Под ссылкой на первоисточник мы подразумеваем указание авторов,
издательства и ISBN.
Получить разрешение на использование значительных объемов программного
кода примеров из этой книги можно по адресу permissions@oreilly.com.
БЛАГОДАРНОСТИ
Эта книга вдохновлена бессчетным количеством источников. На протяжении всей
книги я поблагодарил скольких мог, но наверняка забыл кого-то. (Пожалуйста, при-
мите мои извинения.) Я хочу выразить особую признательность Кенту Беку, Рону
Джеффрису и Уорду Каннингему за то, что они создали экстремальное программиро-
вание, с которого я начал мое Agile-путешествие. Алистер Коберн и его круглый стол
по программному обеспечению, как и бурные споры и обсуждения Вики-страниц C2
Уорда Каннингема, помогли определить направление в начале этого пути. Благодарю
также Диану Ларсен, с которой я работаю много лет — ее точка зрения так хорошо
уравновешивает мою. И конечно, Мартина Фаулера, чей вдумчивый стиль письма
много лет вдохновляет меня.
Поддержка этого издания со стороны O’Reilly была просто исключительной. Я вы-
ражаю огромную благодарность Гэри О’Брайену, моему редактору, обеспечивавшему
постоянную обратную связь и поддержку. Благодарю также Мелиссу Даффилд, кото-
рая помогла сделать так, чтобы книга пользовалась успехом; Райана Шоу, убедившего
меня в том, что пришло время для второго издания; Дебору Бейкер, подготовившую
издание ранних выпусков книги; Сюзанну Хьюстон, которая позаботилась о том,
чтобы люди узнали о книге; Ника Адамса и команду Tools издательства O’Reilly,
которые выстроили производственный процесс и успешно разобрались с моими за-
путанными и придирчивыми требованиями к оформлению; Кристофера Фоучера,
который руководил превращением «сырой рукописи» в «законченную книгу»; Тонью
Трибулу и Стефани Инглиш, исправивших мои грамматические чудачества; Кейт
Дулли, превратившую мои наброски от руки в понятные рисунки.
32 Введение
Что касается обратной связи, особую признательность выражаю моим рецен-

зентам. Рецензирование было открытым, и мы получили более 700 электронных
писем от десятков людей. Практически каждое было содержательным и полезным
и в результате улучшило книгу. Кроме того, благодарю тех людей, которые ответи-
ли на мои прямые запросы на рецензию. Спасибо всем: Адриану Саттону, Энтони
Уильямсу, Ави Кесснер, Басу Водде, Бенджамину Мускалла, Биллу Уэйку, Брэду
Эпплтону, Си Кейту Рэйю, Си Джею Джеймсону, Кристиану Дювану, Дэйвиду Пулу,
Диане Ларсен, Диего Фонтдевиле, Эмили Бач, Эрику Петерсону, «Эвану M.», Фран-
цу Амадору, Джорджу Динвидди, Гойко Аджичу, Джейсону Йипу, Джеффу Григгу,
Джеффу Паттону, Джеффри Палермо, Йохану Алуддену, Кену Пью, Кришне Кумару,
Лиз Кеог, Луизе Нуньес, Марсело Лопесу, Маркусу Гертнеру, Мартину Фаулеру,
Михалу Свободе, Николасу Паесу, Полу Стивенсону, Петеру Гравесу, Реувену Ягелю,
Рикардо Майерхоферу, Рону Джеффрису, Рону Квартелу, Саре Хоран Ван Треесе,
Стиву Бементу, Томасу Джей Оуэнсу, Тодду Литтлу и Уорду Каннингему.
Особая благодарность тем рецензентам, которые пошли еще дальше, прочитав
и прокомментировав почти каждую из частей книги: Басу Водде, Биллу Уэйку, Кену
Пью, Мартину Фаулеру и Томасу Джей Оуэнсу.
Процесс открытого рецензирования пошел на пользу и первому изданию, и все
его преимущества, в свою очередь, отразились и на этой книге. Спасибо Адриану Хо-
варду, Адриану Саттону, Энн Баркомб, Энди Лестеру, Энтони Уильямсу, Басу Водде,
Биллу Капуто, Бобу Коррику, Брэду Эпплтону, Крису Уилеру, Кларку Чингу, Дади
Ингольфссону, Диане Ларсен, Эрику Петерсену, Джорджу Динвидди, Илье Прейсу,
Джейсону Йипу, Джеффу Олферту, Джеффри Палермо, Джонатану Кларке, Кейт Рэй,
Кевину Рутерфорду, Ким Грэсман, Лизе Криспин, Марку Уайтэ, Николасу Эвансу,
Филиппе Антрасу, Рэнди Коулмэн, Роберту Шмитту, Рону Джеффрису, Шейну Доуну,
Тиму Хоутону и Тони Бирну за их множественные комментарии и Брайану Марику,
Кену Пью и Марку Стрейбеку за их замечания по готовому черновику.
И наконец, еще раз спасибо моей жене Ниру. В этот раз ты знала, на что шла,
и все же без колебаний поддерживала меня. Без тебя я бы не смог это сделать.
ОТ ИЗДАТЕЛЬСТВА
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com
(издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На сайте издательства www.piter.com вы найдете подробную информацию о на-
ших книгах.
I
УЛУЧШАЯ ГИБКОСТЬ
ГЛАВА 1
Что есть Agile
Agile везде. И, как ни парадоксально, нигде.

Двадцать лет назад локомотив Agile с ревом ворвался в сознание разработчиков
программного обеспечения. За это время количество компаний, называющих себя
Agile, возросло на порядки. А сколько команд действительно применяет Agile-подход
в своей работе? Не так много. Agile, легко повторяемое название, пользуется огром-
ным успехом. А как насчет идей, стоящих за названием? Вообще-то большинство
из них игнорируется.
Исправим это.
ПРОИСХОЖДЕНИЕ AGILE
В 1990-е считалось, что разработка ПО находится в кризисе. Это явление так и на-
зывалось: «Кризис программного обеспечения». Проекты разработки выходили за
рамки бюджетов, задерживались, не отвечали требованиям, и (согласно часто ци-
тируемому и зловеще именуемому «Отчету о Хаосе» (CHAOS Report)) почти треть
их была полностью отменена [Standish1994].
Agile не был ответом на этот кризис. Отнюдь нет. Agile стал ответным подходом.
Чтобы взять под контроль разработку ПО, большие организации придумали
высокодетализированный процесс, точно определявший, как ПО должно создаваться.
Все жестко контролировалось, чтобы исключить возможность ошибки. (Во всяком
случае, в теории.)
Сначала бизнес-аналитики должны были опрашивать стейкхолдеров (stakeholders,
заинтересованные стороны) и документировать системные требования. Далее ар-
хитекторы программного обеспечения должны были изучить документы с требо-
ваниями и создать подробную проектную документацию, определяющую каждый
компонент системы и их взаимосвязь друг с другом. Затем программисты должны
были конвертировать проектную документацию в код. В некоторых организациях
такое выполнение механического перевода считалось низкоквалифицированной
работой.
Тем временем руководители тестирования должны были создавать планы тестиро-
вания, используя те же документы, и когда кодирование завершалось, бесчисленные
специалисты по обеспечению качества должны были вручную выполнять эти планы,
фиксируя отклонения как дефекты. По завершении каждой фазы все должно было
быть задокументировано, проверено и подписано.
Глава 1. Что есть Agile 35
Подход, основанный на фазах, получил название водопадной (waterfall develop

ment) или каскадной разработки (phase-gate development)1. Если вам это кажется
похожим на нелепое пугало — считайте, что вам повезло. Не все команды применяли
в 1990-х перегруженный документацией каскадный процесс, но он широко призна-
вался как логичный и разумный метод работы. Конечно, нужно было определить
требования, разработать проект, затем выполнить реализацию и следом — тестиро-
вание. Конечно, нужно было документировать каждую фазу. Это была дисциплина.
Это была инженерия. Как еще можно было добиться успеха?
РОЖДЕННЫЙ ИЗ КРИЗИСА
Крупные компании расписывали свои процессы в мельчайших деталях. Роли, от-
ветственности, шаблоны документов, языки моделирования, советы по контролю
за изменениями… каждый аспект разработки строго регламентировался и контро-
лировался. Если проект заканчивался провалом (а согласно CHAOS Report, менее
одной шестой доли проектов были успешны), причиной считалась недостаточная
детализация процесса: нужно больше документов, больше согласований. Это по-
рождало огромное количество документации. Мартин Фаулер описывал это в своей
статье The Almighty Thud [Fowler1997].
Этот стиль работы был далеко не лучшим. Он был бюрократическим и бесчело-
вечным. Казалось, знания и навыки не так важны, как соблюдение процессов. Про-
граммисты чувствовали себя легко заменимыми винтиками бездушной машины.
И даже она работала не очень хорошо.
И тогда несколько человек создали более простые, изящные и менее директивные
методы разработки программного обеспечения. Они назывались легковесными в от-
личие от тяжеловесных, использовавшихся большими компаниями. Эти методы носи-
ли такие названия, как адаптивная разработка программного обеспечения (Adaptive
Software Development), Crystal, разработка на основе функциональности (Feature-
Driven Development, FDD), метод разработки динамических систем (Dynamic Systems
Development Method, DSDM), экстремальное программирование (ХР) и Scrum.
К концу 1990-х эти методы стали привлекать серьезное внимание. Экстремальное
программирование, в частности, вызвало вспышку массового интереса среди про-
граммистов. В 2001 году 17 сторонников легковесной методологии встретились на
горнолыжном курорте в штате Юта, чтобы обсудить объединение усилий.
МАНИФЕСТ AGILE
«Лично я не ожидал, что эта конкретная группа [людей] сможет договориться о чем-
либо по существу», — позже говорил Алистер Кокберн.
И действительно, за два дня они смогли договориться только о двух вещах: назва-
нии Agile и заявлении о четырех ценностях новой методологии (рис. 1.1). В течение
1
Источником появления подхода Waterfall часто ошибочно считают статью Уинстона Ройса,
написанную в 1970 году. Однако применение фазового подхода восходит еще к 1950-м, а статья
Ройса не пользовалась широкой известностью до конца 1980-х, когда к ней стали прибегать для
описания того, что люди уже давно делали [Bossavit2013, chapt. 7].
36 Часть I. Улучшая гибкость
следующих нескольких месяцев, переписываясь по электронной почте, эти люди

сформулировали 12 сопутствующих принципов (рис. 1.2) [Beck2001].
Рис. 1.1. Ценности Agile
Рис. 1.2. Принципы Agile

Это стало Манифестом Agile, который изменил мир. «Таким образом, — продол-
жил Алистер, — они в конце концов все же смогли договориться о чем-то по
существу»1.
Однако единого метода Agile не было. Его
никогда не было и никогда не будет. Agile Если ваши команды воплощают
подразумевает три составляющие: название, философию Agile, то вы — Agile.
ценности и принципы. И все. Это не что-то, Если не воплощают — то нет.
что можно делать. Это философия. Это спо-
соб мышления, посвященный разработке программного обеспечения. Невозможно
«использовать» Agile или «делать» Agile… вы только можете быть Agile. Или не быть.
Если ваши команды воплощают философию Agile, то вы — Agile. Если не воплоща-
ют — то нет.
СУТЬ AGILE
Мартин Фаулер сделал карьеру, превращая сложные вопросы о программировании
в тщательно продуманные, беспристрастно точные объяснения. Его определение
«Суть разработки программного обеспечения по Agile» — одно из лучших:
Agile-разработка является скорее адаптивной, чем предиктивной; ориентиро-

ванной скорее на людей, чем на процессы2.
Мартин Фаулер
Адаптивность вместо предиктивности

Помните, в CHAOS Report утверждалось, что всего одна шестая часть проектов в об-
ласти программного обеспечения успешна? В отчете успешность определена очень
специфическим образом:
zz успешный — проект выполнен вовремя и в рамках бюджета, все характеристики
и функциональности соответствуют изначально запланированным;
zz сомнительный — проект завершен, результаты переданы в эксплуатацию, но
количество характеристик и функциональностей меньше, чем было заявлено
изначально. Запланированные бюджет и сроки проекта превышены;
zz неуспешный — проект отменен в какой-либо момент в течение цикла разработки.
1
Алистер Кокберн, цитата Джима Хайсмита в [Highsmith2001]. Полная цитата: «Лично я не ожи-
дал… что эта конкретная группа приверженцев различных гибких методик сможет договориться
о чем-либо по существу… Что касается меня, я в восторге от окончательной формулировки [Мани-
феста]. Я был удивлен, что и другие оказались так же довольны окончательной формулировкой.
Таким образом, мы все же смогли договориться о чем-то по существу».
2
Фаулер выражал эту идею множество раз в течение нескольких лет. Оригинальную версию можно
найти в статье [Fowler2000].
Эти определения прекрасно иллюстрируют предиктивный тип мышления. Они

все говорят о соответствии запланированному. Если вы сделали то, что собирались
сделать, то вы успешны. А если нет, то неуспешны! Все просто.
На первый взгляд, это разумно. Но посмотрим повнимательнее. Тут чего-то
не хватает. Райан Нельсон писал в журнале CIO Magazine [Nelson2006]:
Как обнаружилось, проекты, отвечающие всем традиционным критериям

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

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

В случае тяжеловесных процессов люди пытались избежать ошибок, тщательно
определяя каждый аспект разработки ПО. При добавлении в процессы регламента
индивидуальные навыки становились менее важными. В теории вы могли применять
один и тот же процесс снова и снова с разными людьми и получать одни и те же
результаты. (Если вдуматься, то они и получали. Просто не те результаты, которые
хотели.)
Agile заявляет, что люди — главный фак-
тор успеха в разработке программного обес Agile заявляет, что люди — главный
печения. Не только их знания и навыки, но фактор успеха в разработке
и все аспекты человеческой природы. На- программного обеспечения.
сколько хорошо сработались члены команды.
Насколько часто они отвлекаются. Насколько комфортно и безопасно для них вы-
сказывать свое мнение. Насколько они увлечены своей работой.
У Agile-команд тоже есть процессы (у любой команды они есть, пусть и неявные),
но они находятся на службе у человека, а не наоборот. И Agile-команды сами от-
вечают за свои процессы. Желая улучшить методы работы, люди меняют процессы.
Посмотрите на Манифест еще раз (см. рис. 1.1 и 1.2). Какие ценности и принципы
имеют отношение к концепции «люди на первом месте»?
ПОЧЕМУ AGILE ПОБЕДИЛ

В течение первых десяти лет после появления Манифеста Agile столкнулся с не-
бывалой критикой. Его называли «недисциплинированным». Говорили, что он
никогда не будет работать. Следующие десять лет критики молчали. Agile был уже
везде, по крайней мере это название. Тяжеловесные водопадные методы практи-
чески умерли. Молодые программисты вообще не верили в то, что кто-то когда-то
мог работать таким образом.
Не то чтобы основанные на фазах процессы неполноценны по сути. У них, безус
ловно, есть свои недостатки, но если ограничивать их объем, при этом действуя
в хорошо изученной предметной области, то методы водопадного стиля тоже могут
работать. Проблема была в самом тяжеловесном процессе, который применяли
крупные компании. Словно по иронии судьбы, процессы, предназначенные для того,
чтобы избегать проблем, на самом деле сами вызывали большинство проблем, с ко-
торыми сталкивались компании.
Трудно представить, как будет работать
программа, до того, как вы начнете ее ис- Получение информации и реакция
пользовать на практике, и еще тяжелее про- на изменения лежат в основе всего
думать абсолютно все, что она должна будет того, что называется Agile.
делать. И это вдвойне сложнее для людей,
которые не вовлечены в разработку программного обеспечения. В результате кри-
тически важно как можно скорее предоставить людям работающую программу. Вам
просто необходимо получить от них обратную связь о том, что не работает и чего
не хватает, и затем скорректировать ваши планы в зависимости от полученной ин-
формации. Как говорится в Манифесте, «работающее программное обеспечение —
основной показатель прогресса». Получение информации и реакция на изменения
лежат в основе всего того, что называется Agile.
В случае тяжеловесных процессов придавалось настолько большое значение
контролю над процессами и согласованию документации, что порождались зна-
чительные задержки и расходы. На то, чтобы получить работающее ПО, уходили
годы, и заказчику не показывали ничего конкретного почти до самого конца проекта.
Вместо того чтобы приветствовать изменения, в этих процессах делалось все, чтобы
их избежать. Была даже отдельная составная часть процессов «Совет по контролю
за изменениями» (Change Control Board), чьей основной задачей было сказать «нет»
запросам на изменения. (Точнее, «да, но за это понадобится доплатить».)
Все это наслаивалось друг на друга в проектах, где люди годами вели разработку,
прежде чем могли что-то показать клиенту. И когда они это делали, было уже слиш-
ком поздно и дорого что-то менять. В конечном итоге они выдавали программное
обеспечение, которое не делало то, чего хотел заказчик.
Типичный провал тяжеловесного процесса

Третьего февраля 2005 года Роберт С. Мюллер III, директор Федерального бюро
расследований, предстал перед подкомитетом Сената США, чтобы объяснить,
как ФБР умудрилось потратить впустую 104,5 миллиона долларов1.
Это явно было не комфортно для компании. В июне 2001-го ФБР запустило про-
ект VCF с целью заменить программное обеспечение для управления делами.
Через четыре года он был отменен. Общие затраты составили 170 миллионов
долларов; 104,5 миллиона из них были полностью невозвратными.
Сроки и последовательность событий проекта могут рассказать нам хорошо
знакомую историю. Проект начался в июне 2001 года. Через 17 месяцев, в ноя-
бре 2002-го, были определены «четкие требования». Программное обеспечение
было поставлено год спустя, в декабре 2003-го, но «ФБР сразу обнаружило не-
которое количество недостатков в VCF, которые делали его непригодным для
использования». Подрядчик, разрабатывавший программу, согласился исправить
недостатки, но только за дополнительную плату в размере 56 миллионов дол-
ларов и в срок один год. В конце концов ФБР отказалось от идеи исправлять
недочеты, фактически перечеркнув годы работы.
Несмотря на существование большого раз-

нообразия подходов к Agile (и некоторые из них Agile-команды демонстрируют
больше используют популярное название, чем прогресс, используя работающие
действительно следуют философии), у них есть программы, а не документы.
кое-что общее. Они фокусируются на том, чтобы
делать прогресс в работе видимым, позволяя всем стейкхолдерам проекта корректи-
ровать его на ходу. Казалось бы, это мелочь, но она невероятно эффективна. Именно
благодаря ей мы больше не слышим о кризисе ПО. Сроки разработки программ все
еще задерживаются. Бюджеты все еще перерасходуются. Но Agile-команды демон-
стрируют прогресс, используя работающие программы, а не документы. С самого
начала. И это огромное достижение.
Agile имеет и другие преимущества, помимо наглядности процесса. Но даже
одного этого оказалось достаточно, чтобы все захотели стать Agile.
ПОЧЕМУ AGILE РАБОТАЕТ

Первым прорывным успехом Agile стало экстремальное программирование, метод
со слоганом «Примите изменения». В нем смешались здоровая доза философских
размышлений о разработке программ и прагматичное стремление изменить ситуацию
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).
к лучшему. В предисловии к первой книге по экстремальному программированию

было сказано:
«Если коротко, то экстремальное программирование обещает снизить риски
проекта, улучшить отклик на потребности бизнеса и повысить продуктивность
в течение всего срока жизни системы, сделать приятным создание ПО в коман-
де — и все это одновременно. Это правда. Прекратите смеяться» [Beck2000a].
Extreme Programming Explained, первое издание
Одни действительно смеялись. А другие попробовали и обнаружили, что (во-

преки всеобщему мнению о том, как должна вестись разработка ПО) экстремальное
программирование реально выполняло все, что обещало. Так, несмотря на смех, оно
пользовалось спросом, а вместе с ним Agile.
Экстремальное программирование было живым примером Agile, заложившим
основу идей и терминологии, которые используются до сих пор. Однако сила сообще-
ства Agile в том, что оно всегда было широкой коалицией. Agile не ограничивается
каким-то одним методом. Он постоянно расширяется, включая в себя новых людей
и свежие идеи. «Бережливая разработка программного обеспечения» (Lean software
development), Scrum, Kanban, «Бережливый стартап» (Lean Startup), DevOps и мно-
гие-многие другие подходы внесли свой вклад в то, что сейчас известно под общим
названием Agile.
Если взять все эти идеи и сгруппировать по категориям, то получится пять цен-
тральных концепций.
zz Полагайтесь на людей. Создавайте процессы, которые понятны и могут работать
с учетом человеческой природы. Отдайте право принимать решения в руки тех,
кто наиболее квалифицирован в этой области. Выстраивайте здоровые рабочие
взаимоотношения, основанные на сотрудничестве.
zz Поставляйте полезный продукт. Запрашивайте обратную связь, эксперимен-
тируйте и подстраивайте свои планы. Считайте частично выполненную работу
затратами, а не прибылью. Концентрируйтесь на создании ценных результатов.
Поставляйте продукт часто.
zz Исключите напрасную трату времени и усилий. Выполняйте работу маленьки-
ми обратимыми шагами. Примите возможность неудачи и стройте ваши планы
с учетом вероятности их быстрого провала. Максимизируйте невыполненную
работу. Стремитесь к производительности, а не эффективности.
zz Стремитесь к техническому совершенству. Обеспечивайте гибкость с помощью
технического качества. Закладывайте в проект то, что известно, а не то, что
предполагаете. Начинайте с простого и добавляйте сложное, только если это
будет реально необходимо. Создавайте системы, которые легко развивать, даже
(и особенно) в непредвиденных направлениях.
zz Совершенствуйте ваши процессы. Экспериментируйте с новыми идеями. Настра-
ивайте и адаптируйте то, что работает. Никогда не считайте, что отлаженный,
популярный способ будет самым лучшим и для вас.
Agile определяется Манифестом, но сам Ма-

нифест — лишь начальная точка. Agile работает Agile работает потому, что
потому, что люди заставляют его работать. Они люди заставляют его работать.
берут идеи Agile, адаптируют их к своим ситуа-
циям и не перестают совершенствоваться.
ПОЧЕМУ AGILE ТЕРПИТ НЕУДАЧУ

Agile начинался как общественное движение. Первоначально он был успешным
в значительной степени благодаря программистам, стремящимся к лучшим резуль-
татам и лучшему качеству жизни. По мере роста этого успеха акцент сместился
с основополагающих идей в сторону ажиотажа. Вместо того чтобы сказать: «Давайте
добьемся лучших результатов, адаптируя наши планы и ставя интересы людей пре-
выше всего», — лидеры компаний стали говорить: «Все обсуждают Agile. Дайте мне
этот Agile».
Дело в том, что нет такого Agile, который можно было бы где-то взять. Это просто
набор идей. Существуют специфические подходы Agile, такие как экстремальное
программирование и Scrum, которые могут вам объяснить, как быть Agile, но вам
все же придется принять лежащую в его основе философию.
А для многих организаций эта основополагающая философия (адаптировать
планы и ставить интересы людей превыше всего) на самом деле реально чуждая.
Карго-культы
Корни этой истории уходят в 1940-е1, когда американские войска высадились
на далеком острове. Местные жители никогда не встречались с современной
цивилизацией, и люди и материалы, привезенные союзными войсками, изумили
аборигенов. Они наблюдали, как солдаты строили взлетно-посадочную полосу
и башню управления воздушным трафиком, надевали наушники и вызывали
с небес на землю больших металлических птиц, нагруженных ценным грузом
(карго). Когда птицы приземлялись, часть груза распределялась между всеми
островитянами, благодаря чему те жили в благополучии и комфорте.
Однажды войска покинули остров, и большие металлические птицы перестали
прилетать. Успевшие привыкнуть к комфорту островитяне сплели из бамбука
собственную взлетно-посадочную полосу. Они построили высокую платформу,
посадили на нее своего вождя и надели ему на голову кокосы, которым придали
форму наушников. Но как бы ни старались островитяне, большие металлические
птицы так больше никогда и не вернулись.
1
Впервые я прочел эту историю в трудах Ричарда Фейнмана, где в числе прочего была пред-
ставлена его речь на церемонии вручения дипломов в Калтехе в 1974 году [Feynman1974].
История основана на реальных ритуалах, практиковавшихся в Меланезии после Второй
мировой войны.
Трагедия карго-культа — в его приверженности к поверхностным, внешним про-

явлениям какой-либо идеи в сочетании с полным непониманием того, как эта идея
работает на самом деле. В той истории островитяне воссоздали все элементы по от-
дельности: взлетно-посадочную полосу, башню, наушники, — но не знали обо всей
инфраструктуре, благодаря которой прибывали самолеты.
Такая же трагедия случается с Agile. Люди хотят Agile-карго: лучшие результаты,
больше наглядности происходящего процесса, меньше неудач бизнеса. Но они не по-
нимают лежащую в основе всего этого философию и зачастую не согласились бы
с ней, даже если бы поняли. Они хотят купить Agile, но идею нельзя купить.
Что можно купить, так это внешние символы Agile. Стендап-митинги! Исто-
рии! Инструменты! Сертификации! Есть множество вещей с маркировкой Agile
и достаточно людей, жаждущих вам их продать. Их часто продают как элементы
«корпоративного уровня», что является способом сказать: «Не беспокойтесь, вам
не придется ничего менять». Неудобные идеи, вроде «адаптивного планирования»
или «ориентированности на людей», игнорируются.
Так и получается карго-культ. Много действий, ноль результата. Относящаяся
к Agile составляющая отсутствует.
«В моей предыдущей компании огромное количество человеко-часов тратилось
на совещания».
«Из-за этого [Agile] целая команда (30+ человек) лишилась работы, поскольку
они не произвели почти ничего в результате почти года работы».
«Все это [Agile] означает, что разработчиков просто обманули, когда проект
изменился... за день до поставки».
Реальные комментарии об Agile из сети
Слово Agile — повсюду. Идеи Agile — нет. Это вечный самообман

для многих: единственный Agile, который они знают, — это карго-
культ Agile.
Настало время это исправить. В этой книге я расскажу вам, как
применять идеи Agile по-настоящему. Будьте начеку, чтобы не под-
даться поборникам карго-культа Agile, которых вы встретите в книге.
Они покажут вам, как делать не надо.
Готовы? Поехали.
ГЛАВА 2
Как быть Agile
Как перейти от нагромождения Agile-идей к реальным, действующим Agile-

командам?
Нужна практика. Очень много практики.
ПРАКТИКА AGILE
У каждой команды есть свой подход к работе — процессы, или методы, которым
она следует, зачастую формально не задокументированы. Эти методы отра
жают лежащую в их основе философию разработки программного обеспечения,
хотя она не всегда бывает четко сформулирована и не обязательно последова-
тельна.
Чтобы быть Agile, вам нужно изменить
свои методы так, чтобы они стали отражать Чтобы быть Agile, вам нужно
философию Agile. Это одновременно и про- изменить свои методы так, чтобы они
ще, и сложнее, чем кажется. Это просто, по- стали отражать философию Agile.
скольку в большинстве случаев вы можете
начать с одного из готовых Agile-методов, например, представленного в этой книге.
И это сложно, так как вам понадобится перестроить свой стиль работы, а это под-
разумевает изменение многих привычек.
Сообщество Agile называет эти привычки практиками. Им посвящена значитель-
ная часть данной книги. Под практиками подразумеваются сессии планирования,
автоматизированные сборки и демо для стейкхолдеров. Большинство этих практик
существует десятилетиями. В методах Agile они скомбинированы уникальным обра-
зом — выделяются компоненты, поддерживающие философию Agile, отбрасываются
остальные и добавляется ряд новых идей. В результате получается экономичный,
эффективный, взаимоусиливающий комплект.
Практики Agile часто имеют двойное и тройное назначение, решая одновременно
множество проблем и поддерживая друг друга разумными и неожиданными спосо-
бами. Вам не удастся по-настоящему понять, как работает метод Agile, до тех пор,
пока вы некоторое время не понаблюдаете за ним в действии.
Таким образом, несмотря на соблазн сразу настроить метод Agile под себя, лучше
все же начать со стандартного, «книжного» подхода. Идея удалить наименее знакомые
Глава 2. Как быть Agile 45
практики выглядит заманчиво, но именно они и будут вам нужны больше всего, если
вы действительно собираетесь перейти на Agile. Именно с этими практиками связаны
главные изменения в философии.
КАК ДОСТИЧЬ МАСТЕРСТВА

Овладение искусством разработки по Agile требует реального опыта использования
конкретного, четко определенного метода Agile. Начните со стандартного, «книжного»
подхода. Примените его на практике — полностью — и потратьте несколько месяцев,
совершенствуя практику и досконально разбираясь, почему она работает. Потом
настройте под себя. Выберите один из нюансов, разберитесь с последовавшими
переменами и повторите.
Данная книга посвящена этой цели. В ней представлен тщательно подготовлен-
ный набор практик Agile, проверенных в реальном мире. Чтобы совершенствоваться
в искусстве Agile или просто достичь бо́льшего успеха с помощью практик Agile,
выполняйте следующие шаги.
1. Выберите для освоения подгруппу идей Agile. Глава 3 поможет вам опреде-
литься.
2. Применяйте как можно больше соответствующих практик. Они описаны в ча-
стях II–IV. Практики Agile усиливают друг друга, поэтому работают наилучшим
образом, если использовать их все вместе.
3. Применяйте практики строго и последовательно. Если практика не работает,
то попробуйте следовать методу еще точнее. Команды-новички в Agile часто
недостаточно тщательно следуют практикам. Будьте готовы к тому, что вам по-
требуются два-три месяца на то, чтобы почувствовать себя комфортно, работая
с новыми практиками, и еще от двух до шести месяцев на то, чтобы довести их
использование до автоматизма.
4. По мере того как вы почувствуете уверенность в том, что применяете практики
правильно (повторимся, отведите на это несколько месяцев), начните эксперимен-
тировать, внося изменения. Описание каждой из практик в этой книге дополнено
рассуждениями о том, почему она работает и что в ней можно изменить. Каждый
раз, меняя что-либо, наблюдайте за результатами и затем вносите дальнейшие
улучшения.
5. Последнего шага нет. Разработка программного обеспечения по Agile — это непре-
рывный процесс обучения и совершенствования. Не прекращайте практиковаться,
экспериментировать и развиваться.
На рис. 2.1 показан этот процесс. Сначала следуйте правилам, потом нарушайте
их и в конце концов будьте выше правил1.
1
Эта последовательность действий следует из рассуждений Алистера Кокберна о сюхари
(Shu-Ha-Ri).
Рис. 2.1. Как достичь мастерства
С ЧЕГО НАЧАТЬ?
Ваши первые шаги зависят от того, чего вы хотите. Вы присоединяетесь к действу-
ющей команде Agile, внедряете Agile в работу одной или нескольких команд или
стремитесь улучшить свою команду Agile?
Присоединение к действующей команде Agile

Если вы планируете присоединиться к действующей Agile-команде или просто хоти-
те дополнить свои знания о том, как Agile работает на практике, то можете перейти
к частям II–IV. Каждая часть начинается с истории в стиле «один день из жизни»,
описывающей, как может выглядеть Agile. Команды, работающие по Agile, отлича-
ются друг от друга, поэтому и ваша не будет абсолютно такой же. Но эти истории
дадут вам представление, чего можно ожидать.
Прочитав истории, переходите к интересующим вас практикам. Каждая написана
как отдельный справочный материал.
Введение Agile
Если вы помогаете своей организации сформировать Agile-команды или только хо-
тите убедить ее сделать это, то оставшиеся главы части I помогут вам начать. Чтобы
структурировать процесс, используйте чек-лист, представленный ниже.
Глава 2. Как быть Agile 47
Сначала убедитесь, что Agile подходит вашей компании:

zz выберите подход Agile, который ваша организация сможет поддерживать (см. гла-
ву 3);
zz определите, что ей нужно сделать, чтобы успешно внедрить Agile (см. главу 4);
zz получите согласие на эксперимент с Agile (см. главу 5);
zz если у вас несколько команд, то решите, как вы будете их масштабировать
(см. главу 6).
За несколько недель до начала:
zz определитесь, кто будет коучем (или коучами) команды, и выберите по меньшей
мере одного человека, который будет продакт-менеджером (см. раздел «Вся
команда» главы 7);
zz организуйте встречу продакт-менеджера с исполнительным спонсором команды
и ключевыми стейкхолдерами, чтобы разработать замысел проекта (см. раздел
«Цель» главы 7);
zz обеспечьте команде физическое или виртуальное помещение (см. раздел «Команд-
ная комната» главы 7);
zz запланируйте и проведите сессию подготовки устава команды (см. врезку «Пла-
нирование сессии подготовки устава» в главе 7);
zz попросите команду ознакомиться с новым методом. Раздайте людям копии этой
книги, чтобы они могли ее изучить самостоятельно, предложите применить не-
которые практики в их текущей работе и рассмотрите возможность проведения
тренинга по тем практикам, которые вызывают трудности (практики представ-
лены в частях II–IV).
Когда команда будет готова начать, сделайте глубокий вдох и:
zz поручите членам команды спланировать первую рабочую неделю (см. подраздел
«Ваша первая неделя» главы 9).
Совершенствование
действующих Agile-команд
Если у вас уже есть действующие Agile-команды и вы хотите улучшить их работу, то
ваш подход будет зависеть от того, какие именно улучшения вам нужны.
Если вы заинтересованы в небольшой регулировке уже работающих процессов
вашей команды, то перейдите к частям II–IV и прочитайте об интересующих вас
практиках. Если вы хотите более масштабных улучшений, то процесс будет таким же,
как и при внедрении Agile в команду, за исключением того, что вам понадобится со-
средочиться на конкретных элементах, требующих изменений.
В качестве руководства используйте чек-листы из предыдущего подраздела
«Внедрение Agile» данной главы.
Если Agile не срабатывает в вашей организации, то ознакомьтесь с врезкой «Ру-
ководство по устранению неполадок» в главе 4.
Применение отдельных практик Agile

Agile работает наилучшим образом, когда вы идете ва-банк, но если это не ваш вари-
ант, то вы можете добавить немного Agile в действующие процессы. Вот подходящие
практики, c которых можно начать.
zz Ежедневное планирование. Если вы боретесь с частыми прерываниями (inter
ruptions), то попробуйте использовать однодневные итерации (см. раздел «Пла-
нирование задач» главы 9). Возьмите за основу игру в планирование (см. раздел
«Игра в планирование» главы 8) и измеряемый потенциал (capacity) по работе
вашей команды на спринте (см. раздел «Потенциал» главы 9) и проводите со-
вместные сессии планирования в начале каждого дня, откладывая все прерывания
на сессию планирования следующего дня. Обеспечьте условия, чтобы люди сами
оценивали свои задачи.
zz Итерации. Если частые прерывания для вас не проблема, но вы все же хотели бы
улучшить свое планирование, то попробуйте использовать недельные итерации
(см. раздел «Планирование задач» главы 9). В этом случае вы также можете прак-
тиковать ежедневные рабочие стендап-митинги (см. раздел «Стендап-митинги»
главы 9) и регулярные демо для стейкхолдеров (см. раздел «Демо для стейкхолде-
ров» главы 10). Со временем рассмотрите возможность использования индексных
карточек для планирования и больших диаграмм, показывающих предстоящую
работу, как описано в разделе «Визуальное планирование» главы 8.
zz Ретроспективы. Частое проведение ретроспектив (см. раздел «Ретроспективы»
главы 11) — отличный способ адаптировать и улучшить рабочие процессы коман-
ды. Могут быть полезны и другие практики, перечисленные в главе 11.
zz Быстрая обратная связь. Быстрая автоматизированная сборка значительно улуч-
шит вашу жизнь, а также откроет возможности для других усовершенствований
(см. раздел «Нулевое трение» главы 13).
zz Непрерывная интеграция. Непрерывная интеграция (практика, а не инструмент)
не только уменьшает проблемы интеграции, но и способствует повышению каче-
ства сборок и тестов. Более подробную информацию см. в разделе «Непрерывная
интеграция» главы 13.
zz Разработка через тестирование. Хотя эту практику не так легко принять, как
другие, она весьма эффективна. Разработка через тестирование (см. соответ-
ствующий раздел главы 13) позволяет снизить частоту появления программных
ошибок (багов), повысить скорость разработки, улучшить вашу способность
к переработке кода (рефакторингу) и сократить технический долг. На ее освоение
может уйти некоторое время, так что запаситесь терпением.
Другие практики, описанные в частях II–IV, также могут оказаться полезными.
Agile-практики объединены множеством зависимостей друг от друга, поэтому обя-
зательно обратите внимание на блоки «См. также» и подраздел «Предварительные
требования» каждой практики.
Не расстраивайтесь, если возникнут проблемы с применением отдельных прак-
тик. Быстрее и проще выбрать соответствующую группу практик и применить ее
полностью, от начала и до конца. Это мы и рассмотрим далее.
ГЛАВА 3
Выберите свою гибкость
Нет смысла использовать Agile ради него самого. Задайте себе два вопроса.
1. Поможет ли нам Agile стать более успешными?
2. Чего нам будет стоить достижение этого успеха?
Ответив на эти вопросы, вы поймете, нужен ли вам Agile.
Что ценно для организаций?

Успех определяется не только доходами. Вот только несколько составляющих
успеха:
zz улучшение финансовых результатов — прибыль, рост выручки, биржевая стои
мость акций, снижение затрат;
zz достижение целей организации — стратегические цели, оригинальные иссле-
дования, благотворительные цели;
zz укрепление позиций на рынке — продвижение бренда, конкурентные различия,
лояльность существующих клиентов, привлечение новых;
zz обретение популярности — стратегическая информация, аналитика, отзывы
клиентов;
zz снижение риска — безопасность, требования законодательства, аудит;
zz увеличение потенциала — наем и удержание персонала, моральный климат
и развитие навыков, автоматизация.
МОДЕЛЬ AGILE FLUENCY

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

показан на рис. 3.1 [Shore2018b].
Рис. 3.1. Упрощенная модель Agile Fluency™
Каждый уровень связан с набором преимуществ. Чтобы обрести их, команде не-
обходимо свободно (уверенно) владеть навыками, относящимися к этому уровню.
Считается, что команда свободно владеет навыками, если способна применять все
навыки этого уровня, не прикладывая сознательных усилий.
ПРИМЕЧАНИЕ
Несмотря на то что на рис. 3.1 представлен прямой путь от одного уровня к друго-
му, в реальности все более беспорядочно. Команды могут достигать уверенного
владения навыками на любом уровне, в любом порядке, хотя продвижение,
показанное на рис. 3.1, типично.
Навыки, необходимые для свободного применения, перечислены в предисловиях

к частям II–IV. Но уверенное владение навыками не достигается само по себе. Ваша
организация тоже должна инвестировать в эти навыки своих команд. Это гораздо
больше, чем поддерживать идеи Agile на словах. Организация должна произвести
реальные, значительные изменения, которые занимают время, стоят денег и требуют
вложения политического капитала.
Результат, который вы получаете от команд, зависит от того, насколько ваша
организация вкладывается в идеи Agile. Компании не удается добиться результатов,
которых она хочет от Agile, обычно потому, что она не сделала необходимые инве-
стиции. Часто организации даже не осознают, что это было нужно.
Глава 3. Выберите свою гибкость 51
Инвестирование в Agile должно стать осознанным

выбором. Тщательно изучите каждый из уровней. Каж- Инвестирование
дый требует затрат, и каждый имеет свои преимущества. в Agile должно стать
Выберите те уровни, которые имеют наилучшее соот- осознанным выбором.
ношение затрат и выгоды для вашей ситуации.
Вероятнее всего, вам не удастся убедить вашу компанию инвестировать в каждый
уровень. Это нормально. В отличие от моделей зрелости (maturity models), таких
как интегрированная модель зрелости возможностей компании при разработке ПО
(Capability Maturity Model Integration, CMMI), модель Agile Fluency™ не показывает
продвижения от слабых навыков к сильным. Вместо этого она демонстрирует мно-
жество вариантов соотношения инвестиций/выгоды. Хотя диаграмма показывает
наиболее распространенный вариант продвижения, каждый уровень можно выбрать
независимо. Каждый имеет ценность сам по себе.
Уровень владения навыками и степени зрелости

Свободное владение навыками — это свойство, присущее команде, а не одному
индивидууму. Свободное владение навыками не означает, что каждый член ко-
манды обладает каждым навыком, связанным с данным уровнем. Вместо этого
им нужна способность, будучи командой, привлекать к работе правильных людей
в правильное время.
Каждый уровень имеет несколько степеней зрелости.
1. Обучение — команда изучает нужные навыки.
2. Профессионализм — команда может продемонстрировать нужные навыки,
когда она концентрируется на них.
3. Свободное владение — команда демонстрирует нужные навыки автоматически,
не прикладывая осознанных усилий, при условии, что в команде есть коуч.
4. Самостоятельное свободное владение — команда демонстрирует нужные на-
выки автоматически, не нуждаясь в присутствии в команде коуча.
Уровень фокусировки (Focusing)

Уровень фокусировки — это самые основы Agile: сфокусированность на бизнес-
результатах; командная работа; принятие на себя ответственности. Команды, которые
свободно владеют навыками на этом уровне, фокусируют процесс разработки на
основной цели команды, сначала выпускают наиболее ценные функциональности
и меняют направление в ответ на меняющиеся потребности бизнеса. Они постоянно
фокусируются на наиболее значимых приоритетах своей организации.
В большинстве команд и организаций для этого требуется изменить образ мышле-
ния о командах. Организации, находящиеся в состоянии «до Agile», составляют планы
заранее, запрашивают смету у команды и требуют отчетов о соответствии хода работ
этой смете. Команды зоны фокусировки часто корректируют свои планы (по меньшей
мере ежемесячно) и демонстрируют прогресс, показывая выполненную работу.
Организации в состоянии «до Agile» разбивают свои планы на задачи, назначают

членов команды ответственными за них и оценивают людей, основываясь на том,
насколько хорошо те выполняют свои задачи. Команды уровня фокусировки самостоя
тельно делают разбивку задач, сами решают, кто над чем будет работать, и ожидают,
что их будут оценивать по их способности создавать ценный продукт как команда.
Чтобы команды вашей организации достигали успеха, понадобится поддерживать
перемены конкретными инвестициями в форме изменения командной структуры,
системы управления и рабочей среды. (Я подробно расскажу об этом в следующей
главе.) Это ситуация в стиле «хорошие новости и плохие новости»: плохие новости
в том, что когда доходит до дела, у многих организаций пропадает желание инвести-
ровать. А хорошие новости таковы: если они отказываются, то вы понимаете сразу, на
начальном этапе, что на самом деле они не готовы к погружению в философию Agile.
Вы просто избавили себя от долгих лет разочарований и душевной боли, которые
пришлось бы испытать, следуя за карго-культом Agile.
Если же вам удастся получить поддержку, то владение навыками на уровне фо-
кусировки может быть достигнуто каждой командой примерно за 2–6 месяцев целе-
направленных усилий. При должной поддержке они превзойдут свой предыдущий
уровень производительности даже в течение 1–4 месяцев1. В части II приведены
практики, которые могут им понадобиться.
Уровень поставки (Delivering)

Agile-команды могут менять свои планы в любое время. Для большинства команд
это несколько снижает качество их кода. Они постепенно теряют свою способность
вносить изменения, эффективные с точки зрения затрат. В итоге команды могут
сказать, что нужно выбросить ПО и переписать его заново, а это дорогое и невы-
годное решение.
Команды уровня поставки предотвращают эту проблему через свое техническое
превосходство. Они сразу закладывают в дизайн своих программ готовность к частым
изменениям. Команды поддерживают высокое качество кода, поэтому не тратят время
на поиски багов. Они совершенствуют цикл своего производства так, чтобы релизы
ПО становились безболезненными, а эксплуатация — управляемой. Они способны
поставить надежное программное обеспечение с низким уровнем дефектов в любой
момент, когда это наиболее целесообразно для бизнеса.
Достижение таких результатов требует существенных инвестиций в навыки
членов команды по разработке, а также структурных изменений, которые позволят
интегрировать людей, компетентных в тестировании и эксплуатации, в каждую
команду.
Если ваша компания сделает эти инвестиции, то на достижение владения навы-
ками на уровне поставки у ваших команд уйдет от 3 до 24 месяцев, и повышение
производительности вы сможете увидеть в течение 2–6 месяцев. Точное количество
времени, которое понадобится каждой команде, зависит от текущего качества ее кода
и от того, сколько у нее будет коучей. Часть III содержит нужные практики.
1
Временные рамки, приведенные в этой главе, приблизительны и основаны на моем опыте. Ваш
опыт может быть другим.
Уровень оптимизации (Optimizing)

Большинство компаний были бы довольны лишь уровнями фокусировки и поставки.
Но Agile способен на большее. Agile во всем своем великолепии — это мир, в котором
команды рады изменениям рыночных условий. Они экспериментируют и учатся,
развивают новые рынки, обыгрывают конкурентов.
Команды уровня оптимизации достигают этой степени гибкости. Они понимают,
чего хочет рынок, каковы требования бизнеса и как можно соединить одно с другим.
Или, как в обстановке стартапа, они понимают, чему им надо научиться и как к этому
приступить. Они постоянно оптимизируют свои планы создания продукта, чтобы
те достигли максимально возможного уровня.
Здесь необходимы изменения в организационной структуре. Создание оптималь-
ных планов требует постоянного внимания людей, обладающих глубокими знаниями
в области бизнеса и продуктов, и, следовательно, эксперты по рынку и по продукту
должны постоянно взаимодействовать с командой разработки. Это также означает,
что на эти команды будет возложена полная ответственность за их планы создания
продукта и бюджеты.
Такие структурные изменения требуют одобрения на высоком уровне, которое
может быть трудно получить. Команды обычно тратят по меньшей мере год на
укрепление доверия с помощью уверенного владения навыками на уровне поставки,
прежде чем получают разрешение на такие инвестиции. Как только это происходит,
свободное владение навыками в оптимизации занимает следующие 3–9 месяцев,
хотя увидеть некоторые улучшения можно уже в течение 1–3 месяцев. Но даже
в этом случае оптимизация остается бесконечным процессом экспериментирования,
обучения и открытий. В части IV мы поговорим о том, как начать.
Уровень укрепления (Strengthening)

Есть еще один последний уровень в модели Agile Fluency™. Он во многом теоре-
тичен: это возможное будущее Agile. Кроме того, он подходит только для органи-
заций, находящихся на переднем крае теории и практики управления. Это обстоя
тельство выводит данный уровень за рамки темы этой книги. Вкратце, уровень
укрепления предполагает переработку коллективных идей команд и направление
их в организационные улучшения. Если вы хотите узнать об этом больше, то про-
чтите главу 19.
Уровни свободного владения навыками Agile, резюме

Фокусировка
zz Основные преимущества: фокус на бизнес-приоритеты, наглядность работы
команды, способность менять направление.
zz Инвестиции: структура команд, управление, рабочая среда.
zz Примерные сроки: падение производительности на 1–4 месяца, достижение
владения наыками в течение 2–6 месяцев.
Поставка
zz Основные преимущества: мало дефектов и высокая производительность,
техническая долговечность.
zz Инвестиции: навыки разработки, слияние тестирования и эксплуатации.
zz Примерные сроки: падение производительности на 2–6 месяцев, достижение
владения навыками в течение 3–24 месяцев.
Оптимизация
zz Основные преимущества: повышение уровня ценности релизов и улучшенные
продуктовые решения.
zz Инвестиции: встроенное управление продуктом, команда несет ответствен-
ность за бюджет и планы.
zz Примерные сроки: падение производительности на 1–3 месяца, достижение
владения навыками в течение 3–9 месяцев.
ВЫБЕРИТЕ СВОИ УРОВНИ

К каким уровням свободного владения навыками должна стремиться ваша коман-
да? Это зависит от того, на каких из них вас может поддержать ваша организация.
В идеале все вместе: фокусировка, поставка и оптимизация — наилучший вариант.
Комбинация трех уровней обеспечивает наилучшие результаты и чистейшую реа-
лизацию идей Agile.
Но выбор всех трех уровней одновременно требует и максимальных инвестиций.
Если вы не можете обосновать их, то у вас наверняка будут сложности с получением
необходимой поддержки. А при недостаточных инвестициях вашим командам будет
тяжело достичь уверенного владения навыками. Вы понесете расходы на обучение
и не получите преимуществ. Вы даже можете увидеть худшие результаты по срав-
нению с тем, что есть сейчас.
Другими словами, выбирайте те уровни, которые нужны вашей компании и за
которые она хочет платить.
Какие же уровни вам все-таки выбрать?
zz Каждая команда нуждается в свободном владении навыками на уровне фокуси-
ровки. Это базовое свойство. Если ваша компания не может инвестировать по
меньшей мере в навыки в фокусировке, то, вероятно, Agile вам не подходит, хотя,
возможно, у вас получится постепенно продвигаться в этом направлении, если
вы начнете со свободного владения навыками на уровне поставки.
zz Свободное владение навыками на уровне поставки снижает затраты и повышает
скорость разработки. Без нее ваш код в конечном итоге скатится к техническому
долгу. Это делает уровень поставки очевидной целью для большинства команд.
Тем не менее многие организации не готовы к большим инвестициям в обучение
и качество кода, требующимся для уровня поставки. Тогда имеет смысл начать
со свободного владения навыками на уровне фокусировки, продемонстрировать
успех и использовать его как положительный пример для обоснования дальней-

ших инвестиций.
zz Свободное владение навыками на уровне оптимизации — это то, где Agile про-
являет себя наиболее ярко. Но хотеть этого сразу, возможно, чересчур. Для
большинства организаций лучше сначала выстроить доверительные отношения,
продемонстрировав навыки на уровнях фокусировки и поставки, а затем посте-
пенно брать на себя больше ответственности. Но если в вашей организации уже
принято делегировать полномочия по принятию решений кросс-функциональным
командам, как это часто бывает в стартапах, то благодаря свободному владению
навыками на уровне оптимизации вы получите великолепные результаты.
Больше информации о каждом уровне и его преимуществах вы можете найти
в предисловиях к частям II–IV. Подробная информация о необходимых инвести-
циях представлена во врезке «Список необходимых инвестиций» в главе 4. Если
вы не можете определиться, какой из уровней выбрать, то начните с фокусировки
и поставки.
Какие бы уровни вы ни выбрали, инвестируйте в изучение всех относящихся
к ним практик одновременно. Практики из более поздних уровней улучшают
работу более ранних, поэтому вам лучше осваивать их все вместе, а не по отдель-
ности. Но если вы не можете инвестировать в каждый из желаемых уровней, то это
нормально. Процесс будет длиться дольше, но со временем вы сможете добраться
и до других уровней.
Определившись с желаемыми уровнями, переходите к более подробному рас-
смотрению инвестиций, требуемых от вашей организации. Мы будем изучать их
в следующей главе.
ГЛАВА 4
Инвестируйте в гибкость
Как мы видим из предыдущей главы, для того чтобы команды получили все пре-
имущества Agile, ваша организация должна приобщиться к его основополагающей
философии. Не просто тратить деньги (это сравнительно легко), а выполнять реаль-
ные, осмысленные изменения в организационных структурах, системах и рабочих
привычках...
Если это выглядит как очень трудозатратное дело… что ж, так и есть. Неужели
эти инвестиции действительно настолько важны?
Да, действительно настолько.
Инвестировать в Agile важно, поскольку
вы инвестируете в изменение границ, ко- По большей части команды
торые вас сдерживают. По большей части сдерживают не процессы, которым
команды сдерживают не процессы, которым они следуют, а ограничения,
они следуют, а ограничения, в которых они в которых они находятся.
находятся. Попробуйте делать эти инвести-
ции и не следовать практикам, и ваши команды, вероятно, все же покажут улучшение
результатов. А если, наоборот, следовать практикам и игнорировать инвестиции?
Тогда командам придется тяжело.
Как сказал Мартин Фаулер1, «я вижу поразительную параллель между ДХХ
(Давид Хейнемейер Ханссон, создатель Ruby on Rails) и Кентом Беком (создатель
экстремального программирования). Любой из них, получив в подарок ограничен-
ный мир, посмотрит на его ограничения, которые мы принимаем как должное, со-
чтет их несущественными и создаст новый мир без них… они просто подложат под
них заряд интеллектуального динамита и двинутся дальше. Именно поэтому они
могут создавать такие вещи, как экстремальное программирование и Rails, которые
встряхивают всю индустрию».
Делайте инвестиции — в них секрет успеха Agile.
В следующих разделах рассказывается об инвестициях, которые нужны вашим
командам от вашей организации. Возможно, вы не сможете получить их все, поэтому
я предлагаю вам альтернативы. При этом альтернативы возможны ценой снижения
эффективности, поэтому лучше приложите все усилия, чтобы добиться как можно
больше инвестиций. Я включил в список только те, которые важны.
1
Отрывок из статьи Мартина Фаулера Enterprise Rails (http://martinfowler.com/bliki/Enter
priseRails.html).
Глава 4. Инвестируйте в гибкость 57
Список необходимых инвестиций

Все команды Agile
zz Получите поддержку руководства, команд и ключевых стейкхолдеров, как
описано в главе 5.
zz Создайте долговечные кросс-функциональные команды и все время на-
значайте людей только в эти команды (см. раздел «Выберите или создайте
Agile-команды» текущей главы).
zz Предоставьте каждой команде коуча, который поможет ей научиться быть
эффективной слаженной командой (см. раздел «Выберите Agile-коучей»
текущей главы).
zz Поручайте работу командам, а не отдельным людям. Ожидайте от команд
самостоятельного выбора подхода к ежедневному планированию и рас-
пределению задач (см. раздел «Делегируйте полномочия и ответственность
команде» текущей главы).
zz Направьте усилия руководителей командного уровня на управление общей
системой работы вместо управления отдельными людьми и задачами (см. раз-
дел «Измените стиль управления командой» текущей главы).
zz Организуйте физические или виртуальные рабочие помещения для каждой
команды (см. раздел «Организуйте рабочие помещения» текущей главы).
zz Для получения первого опыта работы в Agile выберите командам значимую,
но несрочную задачу (см. раздел «Выберите команде подходящую для обуче
ния задачу» текущей главы).
zz Замените водопадные политики управления на политики управления Agile
(см. раздел «Смените водопадные подходы в управлении» текущей главы).
zz Удалите, пересмотрите или научитесь обходить политики отдела кадров, пре-
пятствующие эффективной командной работе (см. раздел « Измените вредные
кадровые политики» текущей главы).
Команды фокусировки
zz Рассчитывайте на 1–4 месяца пониженной производительности каждой коман
ды (см. раздел «Найдите время на обучение» текущей главы).
zz Включите в команду людей, имеющих навыки в сфере деятельности поль-
зователей и заказчиков (см. раздел «Выберите или создайте Agile-команды»
zz Убедитесь, что в каждой команде есть тот, кто принимает решение, над чем
команда будет работать, или команда имеет к нему свободный доступ (см. раз-
дел «Выберите или создайте Agile-команды» текущей главы).
zz Предоставьте каждой команде коуча, который сможет научить ее практикам
фокусировки (см. раздел «Выберите Agile-коучей» текущей главы).
zz Обеспечьте каждой команде доступ к стейкхолдерам или их представителям
(см. раздел «Делегируйте полномочия и ответственность команде» текущей
главы).
Команды поставки
zz Рассчитывайте на 2–6 месяцев пониженной производительности каждой коман
zz Объедините в каждой команде все нужные навыки разработки, такие как тести-
рование и эксплуатация (см. раздел «Выберите или создайте Agile-команды»
поставки (см. раздел «Выберите Agile-коучей» текущей главы).
zz Доверьте каждой команде контроль над ее процессами разработки, сборки,
тестирования и релиза (см. раздел «Делегируйте полномочия и ответствен-
ность команде» текущей главы).
zz Для получения первого опыта работы в Agile выберите задачу, предполага-
ющую написание кода с нуля (green-field codebase), если коуч не сочтет, что
в этом нет необходимости (см. раздел «Выберите команде подходящую для
обучения задачу» текущей главы).
zz Разберитесь с вопросами безопасности, которые мешают коллективной раз-
работке (см. раздел «Решите проблемы, связанные с безопасностью» текущей
главы).
Команды оптимизации
zz Рассчитывайте на 1–3 месяца пониженной производительности каждой коман
zz Включите в команду экспертов в области бизнеса, рынка и продукта (см. раз-
дел «Выберите или создайте Agile-команды» текущей главы).
оптимизации (см. раздел «Выберите Agile-коучей» текущей главы).
zz Передайте каждой команде ответственность за ее бюджет, планы и результаты
(см. раздел «Делегируйте полномочия и ответственность команде» текущей
главы).
НАЙДИТЕ ВРЕМЯ НА ОБУЧЕНИЕ

Изменения даются непросто, и нужно время, чтобы научиться чему-то новому. Освоение
Agile поначалу замедлит работу ваших команд.
Насколько они замедлятся? Объективных критериев продуктивности в раз-
работке программного обеспечения нет [Fowler2003], но, исходя из моего опыта,
я бы предположил снижение на 10–20 % на первых порах. По мере освоения знаний
и навыков Agile производительность команд будет расти. Она будет увеличиваться,
пока команды не достигнут уверенного владения навыками, и тогда рост постепенно
начнет выравниваться (рис. 4.1). Это называется J-кривой, и она характерна для всех
значительных изменений. В главе 5 мы более подробно рассмотрим эти изменения.
Временны́ е затраты обычно окупаются уже в первый год. Длительность изначаль-
ного спада зависит от уровней свободного владения навыками, которые осваивает
каждая команда, как объяснялось в предыдущей главе. Напомню:
zz фокусировка — 1–4 месяца;
zz поставка — 2–6 месяцев;
zz оптимизация — 1–3 месяца.
Рис. 4.1. Изменение производительности в Agile с течением времени
Эти периоды пересекаются, поэтому команда, обучающаяся навыкам фокуси-

ровки и поставки одновременно, будет менее продуктивна в течение 2–6 месяцев.
Для сравнения: команда, которая сначала изучает фокусировку и позже переходит
к обучению поставке, продемонстрирует два спада: 1–4 месяца — при обучении
фокусировке и затем 2–6 месяцев — при обучении поставке.
Производительность команд Agile меняется и с других сторон. Команды Agile
фокусируются на том, чтобы полностью завершить разработку одной функциональ-
ности, прежде чем переходить к следующей. Это особенно верно в отношении команд
поставки, которые предпочитают создавать качественный продукт с самого начала,
а не исправлять баги в конце. Это улучшает продуктивность и производительность,
но (как ни странно) выглядит как замедление работы для людей, которые привыкли
видеть одновременно несколько функциональностей в разработке.
В результате стейкхолдеры могут быть разочарованы темпом Agile-разработки,
особенно в течение первого года, когда им приходится справляться сразу с тремя
ударами: с реальными задержками из-за обучения команд, с ощущением задержки,
вызванной необходимостью последовательно фокусироваться на завершении задач,
и с затратами на завершение работ, которые велись до эксперимента с Agile и были
объявлены «выполненными», на самом деле не являясь таковыми.
Это может приводить к тому, что команды будут отвлекаться от изучения Agile
и фокусироваться только на поставке программного обеспечения, не закончив обуче
ние. Такая ситуация контрпродуктивна для всех: команды будут измучены и рас-
строены, а организация потеряет свои инвестиции. Перед тем как команды начнут
внедрять Agile, убедитесь, что руководители и все стейкхолдеры отдают себе отчет
в том, что в первый год производительность снизится.
У вашей организации есть возможность купить время за деньги, наняв людей,
которые помогут командам. Это не устранит полностью спад производительности,
но сделает его менее значительным. Варианты такой помощи весьма разнообразны:
периодическое наставничество, тренинги, помощь в разработке и имплементации
процессов, каждодневный коучинг. Эффективнее всего нанять опытных специали-

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

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

С помощью этой книги, множества бесплатных онлайн-ресурсов и при наличии
стремления к новым знаниям ваши команды могут самостоятельно научиться всему,
что им нужно знать. Помощь извне, конечно, полезна, но не обязательна.
ОТБЕРИТЕ ИЛИ СОЗДАЙТЕ AGILE-КОМАНДЫ

Невозможно преувеличить важность команды в Agile-организации. Большинство
организаций рассматривают людей как основной производственный ресурс. В Agile
ресурсом являются команды.
Вашей организации нужно инвестировать в команды, которые будут:
zz кросс-функциональными — члены команды в совокупности обладают всеми зна-
ниями, которые нужны ей для достижения цели;
zz полностью вовлеченными — внешние специалисты могут время от времени при-
ходить в команду, чтобы помочь, но основные члены команды должны посвящать
все свое время только своей команде;
zz сплоченными — отношения между членами команды дружеские, конструктивные,

позволяющие сотрудничать;
zz долгосрочными — у команд могут уходить месяцы на то, чтобы понять, как наи-
более эффективно работать вместе, поэтому сохраняйте состав команд как можно
дольше.
Размер и состав каждой команды зависят от того, какие уровни свободного вла-
дения навыками вы выбрали. В разделе «Вся команда» главы 7 представлены все
подробности. Краткое описание команд выглядит следующим образом.
zz Команды фокусировки концентрируются на достижении бизнес-результатов.
Им нужны люди, способные поставить себя на место пользователей и заказчиков,
чтобы точно понять, что должно делать программное обеспечение. Если команда
работает над задачей, ориентированной на пользователя, необходимы специали-
сты, имеющие навыки UI/UX (UI — User Interface — «пользовательский интер-
фейс», UX — User Experience — «опыт пользователя»). Команды также должны
иметь способ определять, чем заниматься дальше. Лучше всего, если в команде
есть люди с навыками и полномочиями, позволяющими делать это самостоятельно,
однако члены команды могут работать и с кем-то извне.
zz Команды поставки берут на себя ответственность за полный цикл поставки своего
программного обеспечения. Им требуются все навыки, необходимые для сборки
и развертывания программного продукта. Команда поставки должна брать на
себя те виды ответственности, которые раньше передавались другим командам.
Сюда входят управление сборкой, архитектура и администрирование данных,
тестирование и эксплуатация.
zz Команды оптимизации ответственны за успех своего продукта в бизнесе в широ-
ком смысле. Они также берут на себя ответственность за координацию со стейк-
холдерами и принимают решения о продуктовых приоритетах. Им нужны экс-
перты в сфере бизнеса, рынка и продукта.
Возможно, у вас уже есть команды, которые отвечают всем требованиям. Если
вы собираете новые Agile-команды, то можете выполнить шаги, описанные ниже.
В любом случае вам понадобится вовлечь команду в процесс, как описано в разделе
«Заинтересуйте команду» главы 5.
1. Определите цель каждой команды (см. раздел «Цель» главы 7).
2. Решите, сколько человек будет в каждой команде, основываясь на значимости
цели команды и в зависимости от ограничений, описанных в разделе «Вся ко-
манда» главы 7.
3. Определите, какие навыки нужны в каждой команде.
4. Выберите людей с соответствующими навыками, которые наверняка смогут со-
трудничать и хотят попробовать работу в Agile.
Если вы создаете или реорганизуете множество команд, то позвольте командам
провести самостоятельный отбор. Этот способ удивительно эффективен в созда-
нии высокопродуктивных команд, которые будут в восторге от совместной работы.
В книге Creating Great Teams: How Self-Selection Lets People Excel [Mamoli2015] рас-
сказывается, как это работает.
Если вы не можете закрепить людей

за определенной командой…
Успех Agile зависит от тесного сотрудничества, и он плохо работает, если нужные
люди недоступны. Внешние ресурсы, приходящие время от времени, — это неплохо,
но если вы не сможете заполучить людей, которые будут посвящать все свое время
команде, есть вероятность, что Agile не будет работать.
Если члены команды не ладят друг с другом…

Для новой команды нормально проходить через трудный период, когда люди учатся
работать друг с другом, поэтому не волнуйтесь, если первое время в команде проис-
ходит борьба. Коуч и менеджер команды могут помочь в урегулировании конфлик-
тов. В разделе «Динамики команды» главы 11 эта тема разбирается более подробно.
Если вы не можете создать долгосрочную команду…

Разбивать отлично работающую команду — расточительно, но это не помешает
вашим командам быть Agile.
Если вы не можете получить необходимых экспертов

со знанием бизнеса, клиентов или пользователей…
Командам оптимизации необходим по меньшей мере один человек с навыками про-
дакт-менеджера, но это не обязательно должен быть традиционный продакт-менед-
жер. Иногда разработчики, давно работающие в компании, знают продукт и рынок
лучше, чем кто-либо еще. Если это ваш случай, то у вас есть все, чтобы приступить
к работе.
Если ваши команды развивают навыки не на уровне оптимизации, то вам не ну-
жен продакт-менеджер непосредственно в команде. Но вам все же понадобится
некто с такой квалификацией, чтобы он работал в тесном контакте с командой,
и вам нужны члены команды, которые могут представлять интересы клиентов
и пользователей.
Вовлеченность бизнеса играет огромную роль в успехе команды. Это одно из тех
свойств, которые отличают Agile от его предшественников. Приложите максимальные
усилия, чтобы интересы бизнеса, клиентов и конечных пользователей были пред-
ставлены в вашей команде. Если этого не сделать, то поставленное программное
обеспечение, скорее всего, разочарует.
Если вы не можете получить необходимые вам навыки

разработчиков…
Скорее всего, вы не сможете достичь навыков в поставке, но практики поставки вам
все же стоит изучать и использовать в работе.
ВЫБЕРИТЕ AGILE-КОУЧЕЙ
Каждой команде нужен коуч, который поможет ей научиться быть эффективной
Agile-командой. В подразделе «Навыки коучинга» главы 7 содержатся подробности.
Краткое описание коуча представлено ниже.
zz Каждой команде необходим тот, кто может помочь ей научиться быть эффектив-
ной и сплоченной.
zz Командам фокусировки нужен тот, кто может научить практикам планирования,
описанным в части II.
zz Командам поставки нужен тот, кто может научить техническим практикам, из-
ложенным в части III.
zz Командам оптимизации нужен тот, кто сможет научить практикам развития
бизнеса, описанным в части IV.
Некоторые коучи могут охватить сразу несколько категорий. Каждый коуч может
работать с одной или двумя командами.
Если вы не можете нанять на работу нужных вам коучей…

Вы можете воспитать собственных. Выберите старших специалистов-практиков,
пользующихся уважением и доверием команды (если сразу не очевидно, кто они,
то спросите членов команды, кого они могут рекомендовать), и предложите им по-
пробовать себя в роли коучей. В этой книге есть все, что поможет им начать. Такие
коучи, закрепленные за одной командой, — идеальный вариант.
ДЕЛЕГИРУЙТЕ ПОЛНОМОЧИЯ
И ОТВЕТСТВЕННОСТЬ КОМАНДЕ
Уважение к человеческим способностям
лежит в центре философии Agile, и нигде Уважение к человеческим способностям
это не очевидно настолько, как в подходе лежит в центре философии Agile.
Agile к полномочиям и ответственности.
Секрет первоклассного выполнения работы заключается в правильном понима-
нии деталей, а никто не понимает их лучше, чем непосредственные исполнители
этой работы… Имея необходимую квалификацию и направляемые лидером, они
будут принимать наилучшие технические решения и воплощать их лучше, чем
кто-либо другой смог бы сделать за них [Poppendieck2003].
Мэри и Toм Поппендик
С точки зрения организационных инвестиций это означает следующее.

zz Работа поручается командам, а не отдельным людям. Команды сами решают,
как разбить весь объем работы на задачи и кто в команде будет их выполнять.
Возможно, вам понадобится изменить процесс распределения задач и другие
рабочие процессы в соответствии с этим подходом. Это приводит к определенным

последствиям в системе оценки эффективности, о чем мы подробнее поговорим
в разделе «Измените вредные кадровые политики» текущей главы.
zz Команды сами разрабатывают свои рабочие процессы. В частности, команды
должны иметь возможность свободно использовать простой, безынструменталь-
ный подход к планированию вместо того, чтобы привязываться к корпоративным
инструментам. Руководство может ограничивать процессы команды, но причины
каждого из этих ограничений должны быть четко сформулированы.
zz Команды фокусировки работают со стейкхолдерами, чтобы понимать потреб-
ности и приоритеты бизнеса. Организация должна обеспечить команде доступ
к заинтересованным сторонам или их представителям.
zz Команды поставки контролируют процессы разработки, сборки, тестирования
и релиза. Опять же, руководство может устанавливать ограничения на процес-
сы команд, например, предписывать им следовать корпоративному конвейеру
релизов, но нужно дать командам возможность разрабатывать и выпускать код
в своем темпе, не дожидаясь других команд.
zz Команды оптимизации управляют своим бюджетом и планами продукта. Менедж
мент определяет цель каждой команды, общую стратегию и устанавливает бюджет.
Кроме того, он осуществляет надзор в виде анализа бизнес-показателей. В рамках
этой модели организация должна позволить командам самостоятельно решать,
как достигать их целей и расходовать бюджет.
Если работу нужно поручить отдельным людям…

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

не поддерживают командную работу…
Если в вашей компании используется система распределения задач, которую невоз-
можно заменить, то одним из вариантов краткосрочного решения проблемы может
стать создание для каждой команды «фантомного» человека, чтобы он принимал
командные задачи. Другой вариант — члены команды могут рассматривать полу-
чаемые индивидуальные задания как командные.
В долгосрочной перспективе лучше все же исправить корпоративную про-
грамму.
Если команды должны использовать

корпоративный инструмент отслеживания…
Одна из главных причин эффективности Agile-команд — способность улучшать и упо-
рядочивать свои рабочие процессы. Корпоративные системы отслеживания, включая
так называемые инструменты управления жизненным циклом Agile (Agile Lifecycle
Management), ограничивают возможности команд. Как и множество продуктов, бо-
рющихся за место в вагоне локомотива Agile, эти инструменты имеют тенденцию
настолько упускать смысл самого подхода, что начинают снижать гибкость команд.
Принуждение Agile-команд к исполь-
зованию корпоративных инструментов от- Принуждение Agile-команд
слеживания в их повседневной деятельно- к использованию корпоративных
сти снижает их производительность. Если инструментов отслеживания в их
у вас нет выбора в этом вопросе, то можно повседневной деятельности снижает
применять две отдельные системы отсле- их производительность.
живания: одну для легковесного подхода
Agile и основную корпоративную систему. Более подробная информация доступна
в подразделе «Корпоративные системы отслеживания» главы 10.
Если у команды нет доступа к стейкхолдерам…

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

процессом релиза…
Вы не сможете увидеть всех преимуществ владения навыками команд поставки,
пока они не получат контроль над своим процессом релиза. Тем не менее практики
поставки достаточно ценны, чтобы стремиться к мастерству в этой области. Вы смо-
жете со временем избавиться от этой проблемы.
Если команда оптимизации не управляет

своими планами создания продукта и расходами…
Командам оптимизации необходимо иметь возможность экспериментировать и адап-
тировать свои планы, а для этого им нужен контроль над планами и расходами. Без
этого они не смогут достичь свободного владения навыками на уровне оптимизации.
ИЗМЕНИТЕ СТИЛЬ УПРАВЛЕНИЯ КОМАНДОЙ

Когда команды сами определяют свои процессы, назначают себе задачи и коорди-
нируют работу со стейкхолдерами, менеджеры командного уровня могут подумать,
что им нет места в Agile. Но это далеко не так. Работа руководителя группы в Agile
различается, но она не менее важна, чем в команде периода «до Agile». Больше ин-
формации об этом можно найти в разделе «Менеджмент» главы 10.
Поговорите с менеджерами об их новой роли и предложите им тренинг, если не-
обходимо. Убедитесь, что их ожидания тоже соответственно изменились.
Если менеджеры не могут отпустить ситуацию…

Микроменеджмент раздражает, но в краткосрочной перспективе он не будет кам-
нем преткновения. Однако он препятствует обучению, отбирая у команд возмож-
ность самостоятельно принимать решения. Микроменеджеры удлиняют сроки
и повышают затраты, необходимые для достижения уровня свободного владения
навыками1.
Руководители часто занимаются микроменеджментом, когда не знают, чем еще
им заниматься, или когда боятся, что им не найдется места в среде Agile. Заверьте
их, что у них есть роль, показав, как она выглядит. Тренинг или хороший Agile-коуч
могут в этом помочь.
ОРГАНИЗУЙТЕ РАБОЧИЕ ПОМЕЩЕНИЯ

Команды Agile активно сотрудничают и постоянно общаются друг с другом. Чтобы
это общение было эффективным, потребуется помещение, приспособленное под по-
требности команды. Оно может быть как физическим, так и виртуальным. В разделе
«Командная комната» главы 7 содержится более подробная информация.
Для команд, работающих в режиме личного общения, организация физического
помещения может стать вашей самой дорогостоящей инвестицией. Вдобавок она
является и наиболее ценной. Как обсуждается в разделе «Командная комната» гла-
вы 7, физические командные комнаты играют роль мультипликаторов производи-
тельности.
Однако, когда ваша команда только на-
чинает работу, вы можете не знать, какого Команды-новички в Agile обычно
рода помещение ей нужно и даже прижи- недооценивают то, насколько им
вется ли вообще Agile на долгий срок. Ваши понравится совместная работа.
команды, вероятно, тоже этого не знают.
Команды-новички в Agile обычно недооценивают то, насколько им понравится со-
вместная работа, и переоценивают свою тягу к приватности.
1
Спасибо Джорджу Динвидди за это замечание.
Так что это нормально — застраховать свои ставки на физическое рабочее про-
странство. Заложите на это средства в бюджете (в конце концов вам понадобится
хорошее помещение для команды, если вы сработаетесь с Agile), но в краткосрочной
перспективе вы можете реквизировать для каждой команды одну из больших комнат
для собраний или часть открытого пространства офиса.
Что бы вы ни решили, начните работать над этим как можно раньше. Организация
физического помещения занимает много времени.
Если команда удаленная…

Вы можете создать виртуальную командную комнату. В подразделе «Виртуальные
командные помещения» главы 7 рассказывается, как это сделать.
Если вы не можете организовать

физическое помещение для офисной команды…
Команды, работающие в режиме личного общения, также могут использовать вирту-
альные комнаты, но я очень не рекомендую это делать. В таком случае им придется
столкнуться с худшими сторонами обоих вариантов: отсутствие гибкого подхода
и регулярные поездки на работу, присущие офисной работе, в сочетании с трудно-
стями общения, возникающими при удаленной работе.
ВЫБЕРИТЕ КОМАНДЕ ПОДХОДЯЩУЮ

ДЛЯ ОБУЧЕНИЯ ЗАДАЧУ
У любой команды есть цель: ее место в общей стратегии организации. (См. раздел
«Цель» главы 7.) Когда команда только начинает учиться Agile, важно выбрать цель,
которая поможет в учебе. В практическом смысле это означает три вещи.
zz Цель, имеющая ценность, но не срочная. Если команда будет сильно ограничена
во времени, то ей будет трудно учиться. Члены команды по умолчанию вернутся
к тому, что у них хорошо получалось в прошлом, чем будут тратить время на во-
площение новых идей.
zz Автономная цель. Чем сильнее команда зависит от других, тем с бо́льшими слож-
ностями координации она, скорее всего, столкнется. Некоторых таких сложностей
следует ожидать, но их переизбыток будет отвлекать команду от обучения.
zz Совершенно новая кодовая база (green-field codebase). Команды, изучающие прак-
тики поставки, должны многому научиться, и это проще делать с нуля. В конце
концов им придется научиться работать с существующим кодом. Команды, у ко-
торых есть опытный коуч в области поставки, могут игнорировать это требование,
если тот согласится. Таким же образом могут поступить и те команды, которые
изучают уровни, отличные от поставки.
Если есть важный дедлайн…

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

Для команд важнее делать ценную работу, чем иметь кодовую базу с нуля. Однако,
не имея опытного коуча, команды, только начинающие учиться практикам поставки,
вероятно, будут испытывать сложности с уже существующим кодом. Будьте готовы
к тому, что спад производительности продлится дольше, достижение навыков займет
больше времени, а программисты команды будут более разочарованы.
СМЕНИТЕ ВОДОПАДНЫЕ ПОДХОДЫ

В УПРАВЛЕНИИ
Руководство (Governance) — это процесс
того, как работа согласовывается, отслежи- Чтобы Agile заработал, необходимо
вается и управляется на высоком уровне. изменить водопадные политики
В большинстве организаций политики та- руководства.
кого руководства предполагают водопадный
подход в разработке. Часто это требует подготовки предварительной документации
или четких переходов от фазы к фазе (phase gates). Все это означает предиктивный
подход к планированию.
Для достижения лучших результатов нужно изменить политики руководства так,
чтобы они стали соответствовать подходу Agile. Это значит удалить точки фазовых
переходов и использовать адаптивный подход к планированию. Подробная инфор-
мация доступна в подразделе «Agile-руководство» главы 10.
Если требуется водопадная модель управления…

Это расточительно и лишит команды части их гибкости, но при необходимости вы
можете соблюдать водопадные политики руководства. Это возможно для нескольких
пилотных команд, но будет лучше переключиться на Agile-руководство, прежде чем
распространять Agile дальше.
Чаще всего руководство требует составления четких предварительных планов
и бюджета. Простейший способ удовлетворить это требование — использовать
сначала любой доступный вам подход, а затем, после того как вы пройдете через
согласование проекта, начать Agile-часть процесса. В качестве альтернативы для
команд, свободно владеющих навыками на уровне как фокусировки, так и постав-
ки, вы можете заложить 4–8 недель на планирование, начать нормально работать
и создать качественную дорожную карту (Roadmap). (См. раздел «Дорожные
карты» главы 10.)
Как добиться успеха, используя водопадную модель

Agile подходит далеко не для каждой компании. И это нормально! Можно до-
биться успеха, используя водопадную модель. Если вы в компании, которой нужны
предварительные планы или культура которой — «командуй и контролируй», то
водопадная модель может быть более уместной.
Наиболее безопасно использовать итеративный водопад. Вместо того чтобы реа-
лизовывать один большой водопадный проект, что довольно рискованно, начните
серию небольших водопадных проектов. Каждый должен длиться не больше
3–6 месяцев и завершаться работающим программным обеспечением, дей-
ствительно пригодным для выхода на рынок. Каждый проект должен содержать
стандартные фазы водопада: анализ требований, архитектура и дизайн, реализа-
ция, тестирование — или тот вариант фаз, который предпочитает ваша компания.
Водопадная модель работает наилучшим образом в хорошо изученных пред-
метных областях при наличии небольшой неопределенности. Постарайтесь взять
на работу людей, весьма опытных в создании именно того типа программного
обеспечения, который вы собираетесь реализовывать.
Другую предварительную документацию, такую как анализ требований или про-

ектная документция, также можно подготовить с помощью действующих подходов
до начала выполнения Agile-части вашей работы. Оставшуюся часть работы, которую
необходимо выполнять для того, чтобы ваш рабочий процесс соответствовал водо-
падному подходу, можно распределить параллельно Agile-работе вместе с пользова-
тельскими историями (см. раздел «Истории» главы 8), как и любые другие запросы.
Водопадный стиль управления несовместим со свободным владением навыками
на уровне оптимизации, который основан на адаптивном планировании. Если от вас
требуется соответствие водопадным политикам управления, ограничьтесь уровнями
фокусировки и поставки.
ИЗМЕНИТЕ ВРЕДНЫЕ HR-ПОЛИТИКИ

Agile — это командный спорт, и несмотря на то, что на словах командная работа под-
держивается, многие компании имеют политики, непреднамеренно сдерживающие
ее. Любая политика, поощряющая людей конкурировать друг с другом, затруднит
работу по Agile. Особенно деструктивный пример — таблицы ранжирования, где
члены команды оцениваются методом сравнения друг с другом. Люди, оказываю-
щиеся на верхушке таблицы, получают повышение, а тех, кто «на дне», увольняют
независимо от их реальной производительности.
Похожий случай — руководители, которые ценят только материальный результат.
В Agile-команде есть много способов внести свой вклад в успех. Примером может
служить человек, который непосредственно не пишет код, но проводит много време-
ни, воспроизводя баги, или человек, который работает «за сценой» над улучшением
коммуникации.
Во многих организациях также развита культура вины, при которой на ошибки

реагируют путем наказания виновных. В мировоззрении Agile, напротив, ошибки
рассматриваются как возможность обучения. Например, не-Agile-организация может
уволить программиста за непреднамеренное удаление критически важной оператив-
ной базы данных. Agile-организация вместо этого спросит: «Какие методы сдержек
и противовесов мы можем внедрить, чтобы предотвратить случайное удаление баз
данных, и как мы можем упростить восстановление после подобных ошибок?»
Такие особенности корпоративной культуры часто отражены в HR-политиках
(Human Resources, HR) в части продвижения и поощрения. Если карьера людей зави-
сит от внешней причины, независимо от их реального влияния на производительность
команды, то у ваших команд, вероятно, будут трудности в совместной работе по Agile.
Вам не удастся изменить культуру вашей организации за одну ночь, но вы можете
начать работать над изменением HR-политик, а руководители могут изменить способ
своего обращения с командами. Это занимает много времени, так что начните как
можно раньше. Вам наверняка понадобится поддержка высшего руководства.
Часто лучше найти креативные способы применения существующих политик, чем
отменить все политики сразу, что вдобавок может оказаться значительно сложнее.
Кроме того, помните, что иногда руководство может применять какие-то практики
по собственному усмотрению, поэтому если вы слышите, что что-либо «невозможно
сделать», то это может быть из-за менеджера, которого вы уговариваете, а не из-за
отдела кадров.
Если HR-политики не подлежат изменению…

Если изменить плохие HR-политики невозможно, то руководителям придется
ограждать от них свои команды. Сделайте так, чтобы они и освоили Agile, и могли
хорошо ориентироваться в корпоративной бюрократии.
Если у вас много команд, то ограничьте пилотный Agile командами, имеющими
опытных руководителей. Используйте их опыт, чтобы запустить необходимые вам
изменения политик.
РЕШИТЕ ПРОБЛЕМЫ, СВЯЗАННЫЕ

С БЕЗОПАСНОСТЬЮ
Эти инвестиции обычно не проблема, но если они вдруг становятся проблемой, то
могут затормозить вас намертво. Так что уделите им внимание, особенно если вы
работаете в индустрии, имеющей повышенную чувствительность к безопасности.
Проблема в том, что работающие очно команды, которые используют такие
практики, как парное программирование и групповое програмирование (моб-
программирование) (см. соответствующие разделы главы 12), работают вместе за
одним компьютером. Это может беспокоить с точки зрения безопасности, поскольку
человек, который вошел в систему, не всегда тот же, кто сейчас сидит за клавиатурой.
Фактически человек, который авторизовался в системе, может ненадолго отойти,
чтобы поговорить с кем-то или посетить уборную. Набирая код, люди часто меняются
(буквально каждые несколько минут), поэтому выходить из системы каждый раз,

когда вводить код должен другой человек, и затем снова входить нереально.
Если ваши команды будут использовать эти практики, то привлеките людей из
службы безопасности вашей компании и поработайте с ними над решением беспоко-
ящих их вопросов. Обычно можно найти креативный способ поддерживать работу по
Agile и одновременно соблюдать правила безопасности. Один общий подход — соз-
дать закрытую общую учетную запись для отдела разработки. Некоторые компании
совмещают ее с отдельными рабочими станциями, выделенными специально отделу
разработки, или виртуальными машинами на базе общих серверов. Использовать
электронную почту и выполнять другие индивидуальные задачи можно на других
ноутбуках, выданных индивидуально.
С этим связана проблема возможности отслеживания. Некоторые компании
требуют, чтобы каждое внесенное изменение (commit) можно было отследить до его
автора. Это требование можно выполнить, добавив инициалы или адрес электронной
почты в коммит-комментарий команды. У Git есть соглашение о том, чтобы добавлять
строку Co-authored-by в конце каждого коммит-сообщения1.
Некоторые компании требуют, чтобы весь код перед релизом просмотрел еще один
человек, помимо автора. В парном и групповом программировании это требование
выполняется, но, скорее всего, вам понадобится модифицировать свой инструмен-
тарий, чтобы он позволил осуществить релиз кода, минуя дополнительную фазу
проверки. Если полная отмена этого требования — не подходящий вариант, то вам,
возможно, понадобится модифицировать инструменты так, чтобы пропускать про-
верку изменений, выполненных в соавторстве.
Если требования безопасности не допускают гибкости…

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

Код, написанный в результате парного или группового программирования, уже может
считаться прошедшим дополнительное ревью, поэтому команды могут начать не глядя
штамповать отзывы об этом коде. Однако это тоже вызывает сложности, так что луч-
ше убрать данное требование до того, как начинать широкое распространение Agile.
1
Спасибо Джею Базузи за то, что обратил мое внимание на эти соглашения о commit-сообщениях
(https://oreil.ly/7vSmz).
Руководство по устранению неполадок

Если Agile не работает для ваших команд и особенно если вы замечаете одни
и те же проблемы в нескольких командах, то причина, вероятно, в недостаточных
инвестициях. Ваши команды в большинстве случаев могут сами вам сказать, что
им мешает, но если нет, то сверьтесь со списком часто встречающихся проблем,
который приводится ниже.
Члены команды не пытаются применять новые практики
Команда не заинтересовалась Agile (см. «Заинтересуйте команду» гла-
вы 5); или
В команде нет коуча, который может научить ее практикам (см. раздел
«Выберите Agile-коучей» текущей главы); или
На команду слишком давят, чтобы она давала результат (см. раздел «Вы-
берите команде подходящую для обучения задачу» текущей главы).
Внутри команды слишком много конфликтов
Команды слишком часто переформируются (см. раздел «Выберите или
создайте Agile-команды» текущей главы); или
Команда испытывает слишком большое давление (см. раздел «Выберите
команде подходящую для обучения задачу» текущей главы); или
Менеджеру команды приходится постоянно помогать улаживать конфлик-
ты (см. раздел «Измените стиль управления командой» текущей главы); или
Политики отдела кадров поощряют конкуренцию (см. раздел «Измените
вредные кадровые политики» текущей главы).
Члены команды не сотрудничают друг с другом
Команда не заинтересовалась Agile (см. раздел «Заинтересуйте команду»
главы 5); или
Члены команды не имеют возможности посвятить все свое время команде
или не ладят друг с другом (см. раздел «Выберите или создайте Agile-
команды» текущей главы); или
В команде нет коуча, который может научить ее сотрудничеству (см. раз-
дел «Выберите Agile-коучей» текущей главы); или
Распределение или отслеживание задач требует индивидуальной рабо-
ты (см. раздел «Делегируйте полномочия и ответственность команде»
текущей главы); или
Рабочее пространство не подходит команде (см. раздел «Организуйте
рабочие помещения» текущей главы); или
Команда испытывает слишком большое давление (см. раздел «Выберите
команде подходящую для обучения задачу» текущей главы); или
Менеджер команды раздает индивидуальные задания (см. раздел «Из-
мените стиль управления командой» текущей главы); или
HR-политики поощряют индивидуальную работу (см. раздел «Измените
вредные кадровые политики» текущей главы).
Команда тратит слишком много времени на предварительную оценку, планиро-

вание и отслеживание работ
Команда вынуждена использовать корпоративную систему отслеживания
задач (см. раздел «Делегируйте полномочия и ответственность команде»
От команды требуют составления предварительных планов и детальных
прогнозов (см. раздел «Смените водопадные подходы в управлении»
Команде нужно развивать свободное владение навыками на уровне фо-
кусировки (см. часть II).
Программное обеспечение, созданное командой, не делает то, что нужно стейк-
холдерам
У команды нет доступа к нужному представителю бизнеса, или ей нужны
люди с большим опытом в сфере деятельности заказчика и пользо-
вателей (см. раздел «Выберите или создайте Agile-команды» текущей
главы); или
В команде нет коуча, который может научить ее работе со стейкхолдерами
(см. раздел «Выберите Agile-коучей» текущей главы); или
У команды нет доступа к стейкхолдерам (см. раздел «Делегируйте полно-
мочия и ответственность команде» текущей главы).
Команде тяжело привлекать внимание стейкхолдеров
Стейкхолдеры не поддержали инициативу с Agile (см. раздел «Заручитесь
поддержкой стейкхолдеров» главы 5); или
У команды отсутствуют необходимые навыки в сфере деятельности за-
казчика (см. раздел «Выберите или создайте Agile-команды» текущей
главы); или
Стейкхолдеры не считают работу команды актуальной или значимой
(см. раздел «Выберите команде подходящую для обучения задачу» теку-
щей главы).
Программное обеспечение, созданное командой, делает то, что хотят заказчики
и пользователи, но не имеет коммерческого успеха
У команды нет доступа к нужному представителю бизнеса или опыта
в бизнесе (см. раздел «Выберите или создайте Agile-команды» текущей
главы); или
Команде нужна более подходящая цель (см. раздел «Выберите команде
подходящую для обучения задачу» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне оп-
тимизации (см. часть IV); или
Команда свободно владеет навыками в оптимизации, но не может кон-
тролировать свои планы и расходы (см. раздел «Делегируйте полномочия
и ответственность команде» текущей главы).
Программное обеспечение, разрабатываемое командой, имеет очень долгие

циклы выпуска версий, много багов или эксплуатационные проблемы
В команде нет людей, уверенно владеющих навыками на уровне поставки
(см. раздел «Выберите или создайте Agile-команды» текущей главы); или
В команде нет коуча, который может научить ее практикам поставки
(см. раздел «Выберите Agile-коучей» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне по-
ставки (см. часть III); или
Команда свободно владеет навыками на уровне поставки, но не может
полностью контролировать свою разработку, выпуск версий и эксплуата-
цию (см. раздел «Делегируйте полномочия и ответственность команде»
Команда учится работать с существующим кодом (см. раздел «Выберите
команде подходящую для обучения задачу» текущей главы).
Разработка идет медленнее, чем ожидалось
Команда завершает предыдущие задачи, которые были до Agile, или все
еще учится (см. раздел «Найдите время на обучение» текущей главы); или
Команде нужно больше коучинга (см. раздел «Выберите Agile-коучей»
Рабочее пространство не подходит командам (см. раздел «Организуйте
рабочие помещения» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне по-
ставки (см. часть III); или
Команда не может полностью контролировать свой процесс разработки
(см. раздел «Делегируйте полномочия и ответственность команде» теку-
щей главы); или
Команда работает с существующим кодом (см. раздел «Выберите команде
подходящую для обучения задачу» текущей главы); или
Команда ограничена требованиями руководства, отданными на высоком
уровне (см. раздел «Смените водопадные подходы в управлении» текущей
главы); или
Команда ограничена требованиями безопасности (см. раздел «Решите
проблемы, связанные с безопасностью» текущей главы).
ГЛАВА 5
Инвестируйте в изменения
Вы решили, что Agile сделает вашу команду более успешной. Вы знаете, какие уровни
предлагают наилучший компромисс между затратами и выгодой. Вы определились
с инвестициями, которые должна сделать ваша компания. Теперь осталось понять,
как все это сделать на практике.
ОСОЗНАНИЕ ИЗМЕНЕНИЙ
Изменения разрушительны, и внедрение Agile —
не исключение. Степень разрушительности зависит Изменения разрушительны,
от того, скольких команд они коснулись и насколь- и внедрение Agile —
ко успешно вы управляете этими изменениями. не исключение.
Если у вас одна команда, жаждущая попробовать
Agile при полной поддержке со стороны организации, то это не должно быть боль-
шой проблемой. Если вы пытаетесь изменить 50 команд в организации, не знакомой
с идеями Agile… что ж, это очень большая проблема.
Понять, как люди реагируют на изменения, можно с помощью модели изменений
Вирджинии Сатир (рис. 5.1)1. Согласно рисунку, существует пять ступеней перемен.
Они применимы к Agile следующим образом.
1. Имеющийся статус-кво. Это стиль работы, который был до Agile. Он удобен
и всем хорошо знаком. Все знают, чего от них ждут и как делать свою работу.
Некоторые, тем не менее, не очень довольны и считают, что Agile должен помочь.
Они хотят перемен.
2. Сопротивление. Люди, желающие перемен, начинают получать поддержку,
и какие-то изменения в направлении Agile становятся возможными. Это назы-
вается внешним элементом изменения. Люди начинают по-разному реагировать
на возможность перемен. Многие противостоят им. Они говорят, что в Agile нет
необходимости, что вряд ли его внедрение будет успешным или что это пустая
трата времени. Некоторые злятся. Чем больше людей касаются изменения, тем
больше сопротивления вы встречаете.
3. Хаос. Проект изменений одобрен, и команды начинают использовать практики
Agile. Старые методы работы и привычные ожидания больше не действуют.
1
У Стивена Смита есть хорошая статья об этой модели (https://oreil.ly/1KQ38), включающая
советы о том, как помочь команде на каждом этапе.
Люди растеряны, находятся в замешательстве, и настроения в коллективе пере-

менчивы. В какие-то дни все хорошо, в другие — все плохо. Люди периодически
демонстрируют ребяческое поведение. Производительность и моральный климат
ухудшаются.
4. Интеграция. С течением временем, практикуясь, люди начинают осваивать
новые методы работы. Они открывают для себя тот аспект Agile (его называют
трансформирующей идеей), который особенно убедителен для них (для каждого
человека он свой). Люди начинают осознавать возможности, которые дает им
Agile, и прикладывают реальные усилия, чтобы Agile заработал. Ощущение хаоса
снижается, моральный климат улучшается, производительность растет.
5. Новый статус-кво. Коллектив прошел через изменения. Новые методы работы по
Agile уже комфортны и знакомы, и люди достаточно уверены в себе, чтобы продол-
жать добавлять небольшие изменения. Производительность стабилизировалась
на более высоком уровне, чем была до перемен, и продолжает постепенно расти
по мере того, как люди экспериментируют с внедрением небольших новшеств.
Рис. 5.1. Модель изменений Вирджинии Сатир (The Satir Change Model)
Такие реакции на изменения неизбежны. По-

пытки ускорить процесс только ухудшают ситуа Попытки ускорить процесс
цию. Вот почему организациям следует отвести только ухудшат ситуацию.
время на обучение (см. раздел «Найдите время на
обучение» главы 4). Обратите внимание на параллели между моделью Сатир, пред-
ставленной на рис. 5.1, и J-кривой, показанной на рис. 4.1 (см. выше).
Каждый участник проходит через эти ступени в своем темпе. Длительность перио-
да изменений и глубина хаоса зависят от того, в какой степени затронута повседневная
жизнь человека. Участник, действующий на периферии процесса, реагирует легче, чем
тот, кто непосредственно является частью новой Agile-команды. Индивидуальные
Глава 5. Инвестируйте в изменения 77
особенности личности также имеют значение; одним людям нравится пробовать все
новое, в то время как другие хотят стабильности и предсказуемости.
Вы можете снизить (но не полностью устранить!) хаос, применив технику, ко-
торой я научился у Дианы Ларсен: поддержка, информация и структура (Support,
Information, Structure — SIS)1.
zz Поддержка. Помогите людям разобраться, как выполнять работу в изменившейся
окружающей среде. Организуйте обучение, коучинг или найдите любые другие
способы оказать помощь людям, не внушая им мысль, что их оценивают. Сде-
лайте необходимые инвестиции, описанные в главе 4. Убедитесь, что у каждого
есть кто-то, с кем он может поговорить на работе или в частной жизни, когда
чувствует себя перегруженным.
zz Информация. Обеспечьте прозрачность информации в отношении того, что про-
исходит, что известно и с чем еще предстоит определиться. Не оставляйте без
внимания озабоченность людей карьерными вопросами. Если вы можете сделать
это честно, то дайте твердое обещание, что никто не будет уволен в результате
изменений. Сообщайте даже больше, чем считаете нужным2.
zz Структура. Людям нужна твердая почва под ногами, поэтому предоставьте им
дорожную карту грядущих изменений. Если вы используете эту книгу в качестве
основы для ваших изменений, то раздайте всем ее копии и расскажите, какие части
в данный момент используете. Когда что-то неясно, объясните, что нужно сделать,
чтобы внести определенность, и когда, по вашим ожиданиям, это произойдет.
Если нужен промежуточный шаг, например временные команды, то дайте ясно
понять, что это временно, и объясните, что будет дальше.
МАСШТАБНЫЕ ИЗМЕНЕНИЯ
Изменения, затрагивающие множество людей, гораздо более разрушительны, чем те,
которые касаются лишь нескольких команд. Это разрушение имеет тенденцию уси-
ливаться. Появляются слухи, люди начинают беспокоиться о своих рабочих местах,
и грядущие перемены становятся предметом ежедневного обсуждения.
Большие перемены (непосредственно затрагивающие 30–70 и более человек)
требуют профессионального управления изменениями. В зависимости от размеров
вашей организации ваш отдел кадров может иметь в своем составе специалистов по
изменениям, которые могут вам помочь. Если вы нанимаете внешних консультантов
Agile на этот проект, то поинтересуйтесь их опытом и подходом в области управле-
ния изменениями.
Руководители организаций часто недо-
оценивают важность управления измене Не стоит недооценивать важность
ниями. Это большая ошибка! Используя тер- управления изменениями.
минологию модели Сатир, к тому времени,
1
Спасибо Диане Ларсен за помощь в составлении этого списка.
2
Диана говорит: «Коммуницируйте, пока вас не затошнит. И даже потом продолжайте».
как вся остальная организация узнает об изменениях, руководство организации уже

восприняло «трансформирующую идею», которая избавила их от ощущений неприя
тия и хаоса. Для руководства изменения уже кажутся очевидными и необходимыми.
Так почему кто-то может быть не согласен?
И тогда они запускают процесс изменений и сталкиваются с огромным сопро-
тивлением и противодействием со стороны людей, которые только начали проходить
сквозь собственные ступени неприятия и хаоса. И это способно загубить на корню
весь проект изменений.
Правильный процесс управления изменениями не может предотвратить все раз-
рушения, но может их минимизировать. Не скупитесь. Если вы не готовы потра-
титься на экспертную помощь, то ограничьте масштабы вашего проекта изменений
в направлении Agile всего несколькими командами за раз.
ПРОЦЕССЫ ИЗМЕНЕНИЙ
Кайдзен — общий термин в сообществе Agile. Это японское слово, означающее «со-
вершенствование». В Agile-сообществе этот термин означает непрерывное постепенное
совершенствование1.
Непрерывное совершенствование — неотъемлемая часть Agile, так не нужен ли
кайдзен в первую очередь для того, чтобы направить ваши усилия к Agile? Пара-
доксально… но, наверное, нет. Кайдзен предназначен для улучшения существующих
методов работы. Если в вашей компании особое значение имеют документы, то
кайдзен поможет вам рационализировать документооборот. Если культура вашей
организации основана на обвинениях, то кайдзен поможет вам точнее устанавливать
вину. Но он не поможет вам перейти с любой культуры на Agile.
Чтобы перейти с одного стиля работы на другой, вам понадобится другое япон-
ское слово — кайкаку. Оно означает «трансформационное изменение». Вместо того
чтобы постепенно улучшать существующие процессы работы, как это делает кайдзен,
кайкаку фундаментально меняет основополагающий подход.
Все лучшие команды Agile, которые я знаю, начинали с кайкаку. Они разобра-
лись, что им нужно от Agile, как они собираются инвестировать в достижение этого
результата, и пошли ва-банк.
Я вижу команды Agile, которые работают посредственно, значительно чаще, чем
те, которые функционируют прекрасно. Первых объединяет то, что их компании
в свое время не пошли ва-банк. Они пытались проложить свой путь к Agile через
кайдзен. Поначалу кажется, что это работает, но потом все неизбежно останавливается.
Люди выгорают из-за несовпадения идей Agile и ценностей компании. Они устают
впитывать новые идеи. Изменения вызывают переутомление, прогресс начинает
тормозиться и после многолетних усилий полностью останавливается. По иронии
1
Термин «кайдзен» был импортирован в Agile из концепции бережливого производства (lean
manufacturing), которая, в свою очередь, основывается на революционной производственной
системе компании Toyota, — отсюда и японский термин. Рифмуется с английским I win — «я вы-
игрываю».
судьбы, разрушения при таком способе продвижения к Agile значительно более

длительные, чем при кайкаку.
Если ваша компания — новичок в идеях Agile (даже если вы уже используете это
слово), то вам нужен кайкаку. Определите зоны применения, выделите необходи-
мые средства, и пусть каждая команда начнет использовать все соответствующие
практики сразу. Возможно, это звучит пугающе, однако на самом деле это быстрее
и безопаснее, чем осваивать практики постепенно.
Если у вас много команд, то, вероятно, безопаснее действовать постепенно, но
даже тогда кайкаку — лучший вариант для вас. Вместо того чтобы в соответствии
с кайдзен постепенно внедрять Agile во многих командах, примените кайкаку, чтобы
полностью внедрить Agile в подгруппе команд. Если нужно двигаться еще более мел-
кими шагами, то начните всего с одной команды и, возможно, только с одного уровня
фокусировки. Затем добавьте уровень поставки. Далее добавьте еще одну команду,
возможно, вместе с уровнями фокусировки и поставки. По мере накопления опыта
увеличьте размер шага изменений.
Команды, уже работающие по Agile, могут использовать кайдзен для достижения
лучших результатов в рамках их нынешних областей компетентности. Более под-
робная информация доступна в главе 11. Чтобы добавить новые области (например,
если команда компетентна на уровне фокусировки и хочет стать таковой на уровнях
поставки и оптимизации), лучше всего выбрать кайкаку. Новые уровни требуют
новых инвестиций и серьезных изменений, и лучше делать все сразу.
Успешный кайкаку требует дисциплины и заботы. Рассмотрим, с чего все на-
чинается.
ЗАРУЧИТЕСЬ ПОДДЕРЖКОЙ РУКОВОДСТВА

Agile требует поддержки руководства. Без нее несоответствие между Agile-практиками
вашей команды и никак не связанной с Agile культурой вашей организации будет
вызывать постоянные трения. Если вы сами руководитель, постарайтесь сделать так,
чтобы ваш непосредственный руководитель был на вашей стороне, и будет совсем
хорошо, если коллеги тоже вас поддержат.
1. Начните с разговора
Все начинается с разговора. Часто проще всего разговаривать один на один, вы
получите наилучший результат, если будете общаться лично или, по крайней мере,
по видеосвязи. Начните с одного из влиятельных руководителей, которому вы до-
веряете, и завербуйте его в свои союзники. Он поможет разобраться, с кем еще вам
нужно поговорить и как найти к ним подход.
В этих разговорах, начиная с того самого первого руководителя, говорите о про-
блемах в разработке ПО, с которыми сталкивается ваша организация. Возьмите за
основу преимущества, описанные в предисловиях к частям II–IV, и расскажите о том,
насколько, по вашему мнению, разработка программного обеспечения могла бы
вестись лучше в вашей компании. Не монополизируйте разговор; вовлеките в него
вашу аудиторию. Вкратце обрисуйте преимущества свободного владения навыками

на каждом соответствующем уровне и поинтересуйтесь, какие уровни важны по мне-
нию собеседников. Спросите почему. Слушайте больше, чем говорите. Прежде всего
фокусируйтесь больше на том, что они могут получить и к каким потерям может
привести бездействие, чем на продвижении Agile ради него самого. На самом деле,
учитывая степень всеобщего недопонимания, что такое Agile, вам может быть лучше
вообще не упоминать этот термин.
2. Получите одобрение экономичного покупателя

Ваша конечная цель — поговорить с человеком, обладающим полномочиями рас-
поряжаться инвестициями, которые понадобятся вашей команде. В продажах этот
человек называется экономичным покупателем (economic buyer).
Экономичные покупатели часто бывают окружены своего рода привратниками,
работа которых — беречь время экономичного покупателя. Они предложат вам
передать всю информацию им, чтобы они могли презентовать ее покупателю. Они
не пытаются украсть вашу идею; они пытаются помочь экономичному покупателю
сберечь его время. Иногда они пытаются убедить вас, что покупатель на самом
деле — это они, даже если у них в действительности нет необходимых полномочий.
Не дайте себя обмануть. Заручиться поддержкой привратников полезно и часто
даже необходимо, однако этого недостаточно. Они не смогут одобрить нужные вам
инвестиции. Вам нужно разговаривать с реальным экономичным покупателем.
До этого разговора фокусируйте ваше общение на выгодах Agile: что на кону.
Вопрос инвестиций, скорее всего, будет отвлекать или даже вызывать беспокой-
ство, поскольку люди, с которыми вы будете разговаривать, не имеют полномочий
управлять инвестициями.
Когда разговор с экономичным покупателем наконец состоится, вашей целью
будет получить его принципиальное согласие инвестировать в Agile. Вероятнее все-
го, ваше время будет ограниченным, так что удерживайте фокус на общей картине.
Кроме того, часто лучше провести эту встречу в формате диалога, а не презентации
со слайдами, хотя в вашей конкретной ситуации, скорее всего, ваши союзники смогут
предложить вам наилучший подход.
Во время встречи с экономичными покупателями говорите о том, чего они хотят
от их организации и как Agile может в этом помочь. Это может сработать еще лучше,
если кто-то из руководителей, кому они доверяют, будет говорить от вашего имени.
Заполучив в команду союзников экономичного
покупателя, начните говорить об инвестициях.
Если вы предложите
Не перегружайте собеседников излишними под-
несколько вариантов, это
робностями; кратко перечислите несколько клю- понизит шансы отказа.
чевых инвестиций, необходимых каждому уровню
(врезка «Список необходимых инвестиций» в гла-
ве 4 поможет вам подготовиться), а также то, как эти уровни соотносятся с пожела-
ниями покупателя. Спросите его, какой компромисс между размером инвестиций
и выгодой он считает приемлемым. Если вы предложите несколько вариантов, а не
потребуете ответа «да или нет», это понизит шансы категорического отказа.
При условии, что экономичный покупатель в принципе согласился инвестировать

в Agile или по крайней мере считает возможным дальнейшее рассмотрение этого во-
проса, попросите разрешения подготовить конкретное предложение. Спросите, что
он хотел бы увидеть в нем в целом, чтобы его одобрить. Попросите рекомендовать
конкретное контактное лицо, спонсора, с которым вы будете работать, сообщите дату,
когда предложение будет готово (лучше сделать его в течение одного-двух дней, по-
этому хорошо иметь готовый черновик документа), и спросите, когда ожидать ответа.
В конце разговора попросите разрешения напомнить. Вероятнее всего, с вами
не свяжутся в оговоренный день, поэтому хорошо иметь возможность сказать что-то
вроде: «Напоминаю, как вы и просили».
3. Сделайте официальное предложение

Если вы добрались до этого этапа, то поздравляю! Вы преодолели самое важное пре-
пятствие. Сейчас вам нужно пройти через официальное предложение.
Степень формальности предложения зависит от вашей организации. Ваш спонсор
и ваши союзники помогут вам разобраться, как лучше оформить предложение, помо-
гут доработать его, правильно преподнести экономичному покупателю. Действуйте
оперативно, вежливо и настойчиво.
В вашем предложении опишите преимущества, которые может получить ваша
организация, и инвестиции, которые ей необходимо сделать. Будьте конкретны.
В главе 3 описываются преимущества в целом, а в предисловиях к частям II–IV дана
более подробная информация. Перенесите эти преимущества на вашу конкретную
ситуацию, на инвестиции, которые экономичный покупатель готов сделать, и объ-
ясните, что в реальности это означает для вашей организации.
При подготовке инвестиционного аспекта вашего предложения прочитайте гла-
ву 4 и переведите каждый шаг в конкретный запрос. В каких-то инвестициях вам,
вероятно, придется пойти на компромисс. В главе объясняется, как это сделать.
Но постарайтесь избежать слишком больших компромиссов. В конечном счете
именно инвестиции делают возможными преимущества Agile.
Выход на экономичного покупателя

Приведу пример того, как вовлеченность руководства работает в сложной си-
туации; он взят из моего собственного опыта в роли консультанта. Это не было
обычным проектом по переходу организации к Agile, поэтому у вас все будет
иначе, но этапы обсуждения в организации наверняка будут похожими.
Изначально ко мне обратился менеджер по проектированию компании, насчи-
тывающей несколько сотен инженеров и порядка 45 команд разработчиков про-
граммного обеспечения. Этот руководитель искал кого-нибудь, кто возглавил бы
маленькую команду. Мы поговорили, и я узнал, что у них были сложности с взаи
модействием команд. Я предложил свою помощь в решении этой проблемы.
Этот руководитель нашел мои идеи касательно масштабирования довольно со-
держательными и представил меня своему вице-президенту по проектированию.
Мы поговорили спустя две недели. Ему понравилось то, что я сказал, и еще через
полторы недели мы обедали с его боссом — директором по продукту. Он и был
экономичным покупателем.
Во время того обеда директор по продукту высказал ряд опасений, касающихся
его организации. Мы обсудили несколько способов, как я могу помочь, и в ка-
честве продолжения запланировали встречу между мной и их директором по
управлению продуктами, который также присутствовал на том обеде.
Я встретился с директором через неделю. Он не являлся покупателем, поэтому
моей целью было не убедить его, а узнать больше информации о компании. Я также
хотел убедиться, что мы правильно понимаем друг друга, поскольку нам предстоя
ло тесно сотрудничать. К счастью, мы были на одной волне, и мой собеседник
запланировал еще одну встречу с участием нас двоих и директора по продукту.
Эта встреча состоялась на следующей неделе. Наша предыдущая встреча за
обедом была нашим шансом познакомиться друг с другом, тогда как эта встреча
была моим шансом заручиться поддержкой директора по продукту.
Я не пытался развернуть рекламную кампанию. Я никогда не считал полезным
говорить людям, что они должны хотеть. Вместо этого я задавал вопросы. У меня
была реальная цель: я хотел понять потребности директора по продукту и про-
информировать его о тех моментах, которые чреваты трудностями или даже
проблемами. Я спросил его, как он представляет себе успех, как он поймет, что
успех достигнут, и как, по его ожиданиям, в итоге это повлияет на бизнес.
К концу встречи, которая заняла час, я узнал достаточно, чтобы обрисовать при-
мерный подход и ценовой диапазон. Я спросил, правильно ли я все понял, и мой
собеседник ответил утвердительно. Мы ударили по рукам, и я обещал к концу
следующего рабочего дня представить детальное предложение, что и сделал.
Его рассмотрели в течение недели (директор держал меня в курсе того, что проис-
ходило в компании) и одобрили на следующей неделе, внеся небольшие поправки.
Окончательное одобрение заняло еще некоторое время, которое ушло на то,
чтобы пробиться сквозь корпоративную бюрократию, однако на тот момент это
был уже решенный вопрос. От первой встречи до первого одобрения прошло
пять встреч и семь недель. Это довольно быстрый результат для организации та-
кого размера, но они были очень мотивированы. У них была серьезная проблема,
которая блокировала прогресс, и они верили, что я могу помочь им решить ее.
Вот те ингредиенты, которые понадобятся и вам: мотивирующая проблема и вера
в то, что вы можете ее решить.
Если это выглядит слишком трудозатратным…

Этот осторожный процесс привлечения сторонников предназначен для случаев, когда
поддержка под вопросом: если вы работаете со множеством команд, запрашиваете
большие инвестиции или работаете в бюрократической организации, для которой
идеи Agile не комфортны (даже если люди активно используют это название).
Но иногда все это не так сложно. Иногда вы просто помогаете одной маленькой
команде стать более Agile. Если вы и ваш руководитель уже имеете все полномочия,
чтобы выделить необходимые вам инвестиции, то просто сделайте это!
Если руководство считает, что они уже Agile…

Некоторые организации (а в наши дни таких много) думают, что они уже Agile. Одна
организация говорила мне: «Мы пост-Agile!» Или вы можете услышать: «Мы agile
с маленькой буквы “а”, а не Agile с большой буквы “A”!» Но сравнив философию,
описанную в главе 1, с тем, как действует организация, вы поймете, что это далеко
не так.
Спорить о терминологии бесполезно. Если
организация хочет сказать, что она Agile, или Фокусируйтесь на текущей
пост-Agile, или экстра-супер-пупер-Agile, то ситуации: проблемах,
пусть говорит. Вместо того чтобы спорить, фо- преимуществах, инвестициях.
кусируйтесь на текущей ситуации: проблемах,
с которыми сталкиваются ваши команды, преимуществах, которые организация
может получить, и на том, какие инвестиции потребуются для этого.
Если руководство не поддерживает…

Если поначалу вы не можете найти понимание и поддержку у руководства, то не от-
чаивайтесь. Попробуйте поставить себя на их место. Как Agile может помочь им
получить то, что им нужно? Если ответ «не может», то, вероятно, он им и не нужен.
Выберите другой подход к разработке программного обеспечения, такой, который
лучше впишется в культуру вашей организации. Один из вариантов можно найти во
врезке «Как добиться успеха, используя водопадную модель» в главе 4.
Если у вас есть руководитель, которому вы доверяете, то обратитесь к нему за по-
мощью и советом. Если его нет, то попробуйте провести информационное интервью:
поговорите с руководителем из другой компании, проходившей через это недавно. (Они
могут попытаться нанять вас на работу. Взаимовыгодный вариант, win/win!) Во врезке
«Смените организацию» далее в этой главе рассматривается ряд идей на этот случай.
На заре развития Agile, когда это было еще стихийным общественным движением,
множество команд приняли экстремальное программирование самостоятельно, при
слабой поддержке или согласии руководства, а то и вообще без них. Вы тоже могли бы
попробовать это сделать. Но я не рекомендую. Опыт команд, которые попытались
это сделать, показал, что кому-то (чаще всего руководителю проекта) в конце концов
приходилось все время преодолевать разрыв между корпоративной культурой и фило-
софией Agile. Это неблагодарная работа, которая привела к выгоранию команды.
Некоторые используют метод Kanban, чтобы мотивировать организационные из-
менения1. Kanban представляет существующие методы работы таким образом, чтобы
подчеркнуть узкие места в исполняемой работе и показать стоимость задержек. Его
достаточно легко внедрить, и он может мотивировать переход организации к Agile.
Kanban является кайдзен-подходом к изменениям, он медленный и работает толь-
ко до определенного предела, но очень эффективен и может привести к появлению
разрешения на кайкаку. Более подробную информацию вы можете найти в книге
[Anderson2010].
1
Обратите внимание, что метод Kanban — это значительно более широкое понятие, чем доска
Kanban, применяемая некоторыми командами для визуализации планирования.
Если ничего из того, что вы делаете, не меняет ситуацию, то задумайтесь, а что

нужно вам. Представьте, что статус-кво не изменится, поскольку этого, вероятно,
и не случится. И тогда или вас это устраивает, или (а часто это как раз такой случай)
пришло время перейти в другую, более подходящую вам компанию.
Изменить организацию
Вы можете изменить свою организацию или сменить ее.
Мартин Фаулер
Изменить организацию изнутри непросто, но возможно. Это отнимает много сил
и времени, и не всегда оказывается, что оно того стоило. Поэтому более простой
способ изменить организацию — сменив работу — может оказаться более разумным
выбором. Для тех, кто все же хотел бы попытаться, ниже приведены 13 советов,
почерпнутых из моего собственного опыта изменения организации изнутри.
1. Задумывайтесь о своих мотивах. Отвечает ли Agile в наивысшей степени ин-
тересам организации или он нужен вам по личным причинам? Есть ли у вас
время, энергия и энтузиазм, чтобы проповедовать эти изменения? Есть ли у вас
стратегия поиска выхода из проблем, которые могут возникнуть вследствие
ваших усилий? Если ответ на любой из этих вопросов — «нет», то смена работы
может оказаться лучшим выходом.
2. Организуйте надежную сеть поддержки. Изменения в направлении снизу
вверх — неблагодарная работа, часто ведущая к разочарованию. Полагайтесь
на семью и друзей, уходите домой вовремя и не живите рабочими проблемами
в нерабочее время.
3. Находите для себя маленькие удовольствия. Без поддержки сверху органи-
зационные изменения в значительной мере находятся вне вашего контроля.
Находите небольшие ежедневные рабочие задачи, благодаря выполнению
которых вы будете чувствовать удовлетворение.
4. Не сдавайтесь. Небольшие изменения накапливаются. Поначалу эффект от
ваших усилий будет незаметным, но они будут постепенно менять стиль
мышления людей в сфере решения проблем. В конце концов, по достижении
некоего порога все внезапно начнет меняться.
5. Уважение — ваша валюта. Чем больше люди уважают вас, тем больше ваш
авторитет. Завоевывайте авторитет своими действиями и уважительно от-
носитесь к другим, даже в мыслях.
6. Оставайтесь внутри сферы своего влияния. Изменения снизу требуют по-
стоянного повторения. Пытайтесь вносить изменения только в тех отделах
организации, с которыми вы находитесь в постоянном контакте.
7. Пополняйте ряды сторонников. Найдите хотя бы одного человека, который
уважает вас и ваши идеи и имеет большее влияние, чем вы. Привлеките его
к распространению ваших идей.
8. Находите пробелы. Люди должны хотеть изменений, но они будут их хотеть,
только если это дает им что-то, что они не могут получить другим способом,
или если это убережет их от потери чего-то ценного для них. Фокусируйтесь
на этих моментах.
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 в течение трех месяцев. После этого мы оценим, что работает, что нет,
и попробуем что-то улучшить1. Спустя шесть месяцев у вас будет возможность при-
нять решение — продолжаем мы работать с Agile или остаемся с тем, что есть сейчас».
Затем я даю всем возможность задать вопросы. У команд обычно множество
вопросов касательно процесса, но один вопрос возникает всегда: «Что будет, если
мы скажем “нет”?» Мой ответ всегда один и тот же: «Ничего не произойдет». Это
важно! Должна быть реальная возможность наложить вето. Если вы не дадите людям
возможность сказать «нет», то их «да» ничего не будет значить. Давая людям шанс
отказаться сейчас и конкретную возможность передумать позже, вы позволяете им
в безопасном режиме попробовать что-то новое.
Выделите достаточно времени на то, чтобы ответить на все вопросы. Встреча
обычно занимает около часа, но иногда может затянуться. Ответив на все вопросы,
напомните, что не будет никаких последствий для проголосовавших против. Еще
раз подчеркните это. И затем приступите к голосованию.
Если команда настроена скептически…

Скептический настрой — нормальное явление, его следует ожидать. Будьте честны
с вашим коллективом: изменения разрушительны, но результаты себя оправдывают.
Поясните практики, которые, по вашему мнению, люди поначалу могут счесть стран-
ными или даже раздражающими, например парное программирование. Это поможет
снизить градус скептицизма и в будущем облегчит процесс внедрения этих практик.
Может быть полезно подчеркнуть, что это эксперимент и за командой будет по-
следнее слово в вопросе, придерживаться Agile или нет.
Если несколько членов команды против…

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

Если команда не согласна, то вам придется выбрать другую. В моей практике это
случалось редко, но так бывает. В одном из случаев это было потому, что коллек-
тив не верил, что их организация даст им достаточно времени на обучение. Теперь,
оглядываясь назад, я понимаю, что они были правы, и хорошо, что мы тогда не при-
ступили к изменениям.
1
Это не совсем правда. Agile подразумевает постоянное совершенствование, поэтому мы оценим,
что работает, а что нет, уже в течение нескольких недель. Но по истечении трех месяцев мы делаем
паузу, чтобы дать более значительную оценку.
Если люди обманывают насчет своего согласия…

Иногда люди голосуют за Agile, при этом внутренне выступая против. С этим вы
ничего не можете сделать, кроме как приложить все усилия, чтобы люди не чувство-
вали себя принуждаемыми. Пытаться угадывать чужие мысли непродуктивно.
Даже если никто не обманывает сейчас, при-
рода изменений такова, что время от времени всех
будут посещать сомнения. Вам придется работать Природа изменений такова,
что время от времени всех
с этими сомнениями по мере их появления. И будет
будут посещать сомнения.
полезно иметь возможность напомнить людям, что
они согласились принять участие в эксперименте
длиной в шесть месяцев, что есть точная дата его окончания и если все не заработает
к этой дате, то они смогут отказаться. Отнеситесь к ним с сочувствием и уважени-
ем; изменение привычек требует времени, и люди могут чувствовать, что устои, на
которые они привыкли опираться, полностью утрачены.
По моему опыту, к окончанию шестимесячного периода изначальный хаос из-
менений будет уже в прошлом и люди будут вполне довольны своим новым стилем
работы по Agile. Так было с каждой командой, с которой я работал.
ЗАРУЧИТЕСЬ ПОДДЕРЖКОЙ СТЕЙКХОЛДЕРОВ

Стейкхолдерами вашей команды являются все, кого касается ваша работа или кто
может влиять на нее. Применительно к вашим усилиям по Agile-улучшениям к стейк-
холдерам также нужно отнести всех тех, кто влияет на эти изменения.
Мы уже разбирались с вопросом поддержки со стороны членов команды и ру-
ководителя. Вам не нужно, чтобы все остальные стейкхолдеры поддерживали ваш
замысел, но вам точно нужно заручиться поддержкой тех, кто имеет значительное
политическое влияние. В противном случае они могут тихо саботировать ваши уси-
лия или каким-нибудь неожиданным образом выбить почву у вас из-под ног через
полгода-год, если (особенно если) внедрение Agile будет успешным1.
С наибольшей вероятностью вы встретите сопротивление со стороны бизнес-
партнеров вашей команды: менеджеров по продукту, маркетингу и продажам. Agile
ведет к серьезным сдвигам в системе взаимодействия с этими группами. Они при-
выкли к прогнозируемому подходу, ориентированному на строгие обязательства
и сроки. Взаимодействие этих людей с командой разработки, как правило, основано
на документации, отчетах о проделанной работе и согласованиях.
Команды, работающие по Agile, фокусируются на обратной связи, частой постав-
ке ценного продукта и постоянной адаптации своих планов. Они регулярно просят
у стейкхолдеров обратную связь, а затем корректируют свои планы в соответствии
с полученной информацией. Так как планы Agile-команд постоянно меняются,
они не берут на себя четких обязательств по срокам релизов. Некоторые команды
1
Алистер Кокберн называет этот феномен организационными антителами. Чем более успешна
инициатива по изменениям, тем больше люди беспокоятся о ее влиянии на них и тем сильнее
сопротивляются изменениям.
могут давать какие-то прогнозы, но они не являются обязательствами и тоже часто

меняются.
Одним стейкхолдерам это нравится. Наконец-то они знают, что происходит на
самом деле, и имеют возможность влиять на результат. Другие же, особенно те, кто
уже когда-то пострадал из-за срывов сроков или обязательств, видят в Agile поли-
тический маневр: изощренный способ не давать обещаний. Они сражаются с Agile
изо всех сил.
Поговорите с ключевыми стейкхолдерами вашей команды об Agile. Чаще всего
это лучше делать один на один. Тема может быть политически чувствительной, по-
этому спланируйте стратегию вместе с вашими союзниками в руководстве. Кроме
того, возможно, будет лучше, если этот разговор проведете не вы, а руководитель
или человек, которому доверяет данное заинтересованное лицо.
Во время таких разговоров относитесь
к вашим стейкхолдерам как к доверенным
партнерам. Вы хотите, чтобы они достигли Относитесь к вашим стейкхолдерам
как к доверенным партнерам.
успеха. Вам необходимо соблюдать баланс
Вы хотите, чтобы они достигли успеха.
множества интересов, и вы обеспечиваете
прозрачность и контроль, а не предсказу-
емость. Но помогать им — существенная часть вашей работы. Вы будете делать все
от вас зависящее, чтобы облегчить их работу и привести к успеху.
Если нужны конкретные обязательства…

В Agile используется адаптивное планирование, которое подразумевает динамичное
изменение планов в целях достижения наилучших результатов. Вы можете установить
конкретную дату и придерживаться ее, как описано в подразделе «Запланированные
даты релизов» главы 10, но не сможете точно предсказать, какие функции будут
готовы к этой дате.
Если этого недостаточно, то можно применить подход, описанный в подразделе
«Если требуется водопадная модель управления…» главы 4, то есть подготовить
планы с фиксированными сроками и объемом работ. Нет гарантии, что эти планы
будут правильными, но это лучшее, что вы можете предложить на данный момент.
Если и этого недостаточно, то, видимо, Agile вам не подходит.
Если стейкхолдеры не спешат поддержать…

Иногда у команд разработчиков складываются непростые отношения с некоторы-
ми стейкхолдерами, особенно с продакт-менеджерами или отделом продаж. Эти
отношения могут быть довольно напряженными. В некоторых случаях неприязнь
и отсутствие доверия даже могут привести к тому, что эти люди будут категорически
против Agile. Они могут также возражать против замедления работы, вызванного
необходимостью обучения Agile в начале процесса внедрения (см. раздел «Найдите
время на обучение» главы 4).
Если возражают всего несколько человек, то попробуйте выбрать команды, в ра-
боте которых они не участвуют. Если среди стейкхолдеров много возражающих или
против даже их руководство высокого уровня, то, возможно, хорошим решением будет
убедить их попробовать сделать пилотный проект, ограничивающийся только одной
командой. В этом случае выберите команду, стейкхолдеры которой одновременно
влиятельны и стремятся пробовать новые идеи. Это может занять какое-то время
(даже год или два), но им понравятся прозрачность и контроль, свойственные Agile,
и они убедят своих коллег дать новому подходу шанс.
Иногда организации, разрабатывающие программное обеспечение, пытаются
навязать Agile своим стейкхолдерам. Это даже может получаться, если эти органи-
зации обладают достаточной политической властью. Но в долгосрочной перспективе
это может привести к негативным последствиям. И если вы столкнулись с широ-
комасштабным сопротивлением, активным до такой степени, что даже пробный
пилотный проект не является приемлемым решением, — значит, Agile не подходит
вашей организации.
ЛИТЕРАТУРА ДЛЯ ДОПОЛНИТЕЛЬНОГО ЧТЕНИЯ

Книгу 7 Rules for Positive, Productive Change1 [Derby2019] должен прочитать каждый,
кто занимается организационными изменениями.
Если хотите понять, как повлиять на изменения в вашей организации, то начни-
те с прекрасной книги More Fearless Change: Strategies for Making Your Ideas Happen
[Manns2015].
1
Дерби Э. Психология управления изменениями. Семь главных правил.
ГЛАВА 6
Масштабирование гибкости
В идеальном мире каждая Agile-команда была бы полностью независима и едино-

лично владела бы своим продуктом или портфелем продуктов. Но в реальном мире
необходимость координации взаимодействия множества команд является источником
задержек и разнообразных ошибок. Если бы каждая команда работала изолированно,
то этих проблем просто не было бы.
Но это совершенно нереалистично. Типичная Agile-команда состоит из 4–10 чело
век. Как правило, этого недостаточно.
Как же вам тогда расширяться? Эта книга посвящена в основном индивиду-
альным Agile-командам, однако этот вопрос достаточно важен, чтобы заслуживать
отдельной главы.
МАСШТАБИРОВАНИЕ СВОБОДНОГО
ВЛАДЕНИЯ НАВЫКАМИ
Организации довольно часто пытаются мас-
штабировать Agile, при этом не ставя на первое Организации довольно часто
место способность быть Agile. Они инвести- пытаются масштабировать Agile,
при этом не инвестируя
руют много времени и денег в некое грандиоз-
ни в команды, ни в потенциал
ное «фирменное блюдо» под названием Agile, самой организации.
не инвестируя ни в свободное владение коман-
дами навыками, ни в потенциал самой органи-
зации. И это никогда не работает.
Чтобы масштабировать Agile, вам понадобится масштабировать и способность
вашей организации быть Agile. В эту задачу входят работы по трем направлениям:
организацонному потенциалу, коучинговому потенциалу и потенциалу команд.
Организационный потенциал
Одна из самых больших ошибок, которую совершают организации при попытке
внедрить Agile, — отказ от инвестиций, описанных в главе 4. Но даже если ваша
организация серьезно относится к этим инвестициям, могут обнаружиться другие
скрытые проблемные места.
Глава 6. Масштабирование гибкости 91
Прежде чем потратить значительные средства на масштабирование Agile, вам

нужно определить организационный потенциал. Если вы работаете с советником-
экспертом, то он наверняка сможет дать вам рекомендации, применимые именно
в вашей ситуации. Если вы работаете в одиночку, то начните с одной пилотной
команды или небольшой группы — не больше пяти команд.
В процессе развития навыков ваши пилотные команды обнаружат организаци-
онные проблемы, мешающие их свободному усвоению. Отметьте для себя эти про-
блемы. Скорее всего, они будут постоянно повторяться. Вам не нужно решать их
в масштабах организации, но необходимо решить их для каждой команды, в которой
вы хотели бы внедрить Agile.
Вы будете готовы масштабироваться дальше только тогда, когда наладите под-
держку команд, владеющих навыками, в вашей организации. До этого момента, ка-
ким бы ни был соблазн агрессивно продвигать Agile, лучше придерживаться вашего
текущего подхода для всех команд, кроме пилотных.
Коучинговый потенциал
Вам понадобится коуч или коучи, которые помогут разобраться с общей картиной
масштабирования Agile: кросс-командной координацией, потенциальными возмож-
ностями организации, управлением продуктом/портфолио и управлением измене-
ниями. С помощью книг и тренингов вы можете сами взрастить этих коучей внутри
организации, однако лучше все же нанять кого-то со стороны.
Вам также понадобятся опытные коучи командного уровня, и это, вероятно, будет
главным ограничением при масштабировании. Это люди, которые помогают команде
достичь уровня уверенного владения навыками, и они ей жизненно необходимы.
Каждой команде понадобится по меньшей мере один коуч, как обсуждается в под-
разделе «Навыки коучинга» главы 7.
Кроме того, вы можете как нанять опытных коучей командного уровня, так и вос-
питать собственных внутри организации. Если вы выбираете второй вариант, то
учтите, что каждому будущему коучу понадобятся обучающие ресурсы, такие как,
например, эта книга.
Вы можете расширяться быстрее, поощряя опытных коучей командного уровня
переходить в другую команду, как только их текущая команда начнет приближать-
ся к уровню свободного владения навыками. (Чек-листы в начале частей II–IV
помогут вам оценить прогресс.) К этому моменту некоторые члены команды,
возможно, уже сами будут обладать квалификацией, достаточной для того, чтобы
выступать в качестве коучей командного уровня, и смогут развивать свои новые
навыки в более опытных командах. Убедитесь, что такие горизонтальные пере-
мещения улучшают карьеру ваших коучей, а не вредят ей, иначе их поток может
иссякнуть1.
1
Спасибо Эндрю Стельману за то, что в Twitter-посте указал на опасность горизонтального
перемещения (https://oreil.ly/E0EaB).
Навыки коучинга отличаются от навыков разработки. Даже лучшим членам

вашей команды может быть трудно стать хорошими коучами. Быстрее расширить
возможности коучинга командного уровня можно, наняв коучей для обучения
коучей.
Опытные коучи командного уровня могут работать с двумя командами одно-
временно, хотя это и не всегда хорошая идея для команд, добивающихся свободного
владения навыками на уровне поставки. Менее опытные коучи должны быть при-
креплены только к одной команде.
Потенциал команды
Коучи помогут вашим командам достичь свободного владения навыками. Чем
больше опыта у коучей, тем быстрее пойдут дела, но все же это займет некоторое
время. В разделе «Найдите время на обучение» главы 4 представлены примерные
цифры.
Вы можете форсировать события, наняв крупную консалтинговую компанию,
чтобы укомплектовать ваши команды опытными Agile-разработчиками в соотно-
шении 50 % и более. Достаточно высокое соотношение позволяет достичь уровня
компетентности почти мгновенно при условии, что вы уже приложили достаточно
усилий для мобилизации потенциала вашей организации.
Однако применяйте этот подход с осторожностью. Стратегия разумная, хотя
и дорогостоящая, но ее реализация имеет тенденцию давать сбои. Люди, которыми
вы дополняете ваши команды, оказывают огромное влияние на успех этого подхо-
да, и есть вполне реальный риск нанять неправильную фирму. Все говорят, что их
сотрудники имеют Agile-навыки, но даже в случае компаний с широко известными
именами тут больше бравады, чем реальных возможностей. За несколькими исклю-
чениями, если добавленный персонал и имеет какие-то знания в Agile, то обычно они
ограничиваются уровнем фокусировки.
Еще один риск усиления штата с помощью внешнего персонала связан с навыками
коучинга. Даже если добавленные сотрудники и будут иметь навыки, необходимые
для мгновенного перехода на уровень свободного владения навыками (в чем дале-
ко не всегда можно быть уверенным), маловероятно, что они также будут владеть
и навыками коучинга. Изменения в направлении Agile могут не состояться, если
консалтинг не даст результата.
Подход с добавлением внешнего персонала может сработать, если вы наймете
подходящую фирму. Выбрав этот вариант, постарайтесь воспитывать при этом
собственных коучей. Не ждите, что компания, добавляющая вам персонал, сделает
это за вас; тут нужен совершенно другой набор навыков. Обратитесь в небольшие
фирмы и к независимым консультантам, которые специализируются на Agile-
трансформациях и услугах обучения коучей. Люди, которых вы нанимаете, имеют
большее значение, чем вендор, особенно в случае этих конкретных навыков, и ма-
ленькие консалтинговые компании делают эту работу лучше.
Синдром второго ребенка

Я заметил удивительный тренд среди компаний, внедряющих Agile: пилотные
команды часто очень успешны и вдохновляют организацию на дальнейшее рас-
пространение Agile, но вторая волна команд начинает испытывать трудности.
Я называю это синдромом второго ребенка. Моя теория заключается в том, что
пилотные команды получают всю необходимую поддержку: целеустремленных
участников, терпеливую организацию, помощь извне и задачи, хорошо подхо-
дящие для обучения.
А затем, думая, что все ее сотрудники уже хорошо знакомы с Agile, организация
оказывает второй волне команд гораздо меньшую поддержку. Agile навязывается
людям, которые его совсем не хотят; кроме того, руководители не предоставля-
ют помощь извне и оказывают большее давление по срокам выполнения задач.
Чтобы избежать синдрома второго ребенка, помните, что успех одной команды
не гарантирует автоматически успех другой. Каждой команде требуются пони-
мание и поддержка, когда она впервые пытается быть Agile-командой.
МАСШТАБИРОВАНИЕ ПРОДУКТОВ
И ПОРТФЕЛЕЙ
Свободное владение навыками — основа
успешного масштабирования Agile, но само- Успешное масштабирование Agile —
го по себе этого недостаточно. Вам понадо- это вопрос правильного управления
взаимозависимостями.
бится способ координации работы команд,
если только они не работают совершенно
независимо. Это труднее, чем кажется, поскольку команды обычно зависят друг от
друга, что вызывает появление узких мест в рабочем процессе, задержек, проблем
и ошибок коммуникации. Успешное масштабирование Agile — это вопрос правиль-
ного управления взаимозависимостями.
Есть две базовые стратегии масштабирования Agile: вертикальное, нацеленное
на увеличение количества команд, способных работать друг с другом, не образуя
узких мест, и горизонтальное, которое пытается ликвидировать узкие места путем
изоляции зон ответственности команд. Обе стратегии можно использовать вместе.
Вертикальное масштабирование
Вертикальное масштабирование означает увеличение количества команд, которые
могут совместно владеть продуктом или портфелем. Под «совместным владением»
я имею в виду, что у них нет четко определенной области работы. Каждая команда
может работать над любой частью продукта и участвовать в написании любого кода.
Я рассмотрю два подхода к тому, как это сделать: 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.
Внедрение 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.
историями. FAST использует непрерывный поток работы и формирует новые ко-

манды каждые несколько дней. В FAST отсутствует владение на командном уровне.
FAST-группа называется трайбом (tribe — «племя»). Каждый трайб состоит из раз-
работчиков и одного или нескольких продакт-менеджеров (которых FAST называет
директорами по продукту), ответственных за определение направления. В теории
трайб может насчитывать до 150 человек, но такое количество не тестировалось на
момент написания этой книги.
Каждые два дня (этот срок может меняться) трайб собирается на FAST-митинг,
на котором решает, над чем работать. Это короткая и быстрая встреча. Продакт-ме-
неджеры объясняют свои приоритеты, и затем люди вызываются добровольцами,
чтобы вести работу команды над какой-либо задачей. Таких людей называют стю-
ардами команды. Любой может вызваться добровольцем в стюарды. Это временная
роль, которая длится только до следующего FAST-митинга.
Приоритеты продакт-менеджеров — это скорее ориентир, а не директива. Стюарды
команды могут выбрать для работы задачу, которая им нравится, хотя и ожидается,
что они будут действовать добросовестно. Иногда это может подразумевать работу
над чем-то, что продакт-менеджеры не просили напрямую, например исправлением
некорректного кода или уменьшением трудностей, возникающих при разработке.
Как только добровольцы-стюарды найдены и они объявили, над чем будет работать
их команда, оставшаяся часть трайба самостоятельно распределяется по командам
в зависимости от того, кто с кем и над чем хочет работать.
Вместо того чтобы разбивать истории на детализированные списки задач, команды
FAST создают дерево открытий (discovery tree) для каждого ценного инкремента1.
(Ценный инкремент представляет собой то, что может быть выпущено само по себе
(см. подраздел «Ценные инкременты» главы 8).)
Дерево открытий — это иерархическая текущая декомпозиция работы, необходи-
мой для релиза такого инкремента. Его изображают с помощью бумажных стикеров,
наклеенных на стене, или виртуальных стикеров на виртуальной доске.
Команды работают в течение двух дней или в том темпе, который выбрал трайб.
От них не ожидают, что они выпустят что-либо определенное за этот период вре-
мени. Вместо этого они просто делают столько, сколько могут. Деревья открытий
нужны, чтобы обеспечить непрерывность процесса и помочь людям увидеть прогресс.
Кто-то также может выступить добровольцем в роли «стюарда функциональности»
определенного дерева открытий, если это необходимо для усиления поддержки не-
прерывности процесса. Вся остальная кросс-командная координация происходит
спонтанно при необходимости и напрямую между задействованными участниками,
так же как и в LeSS.
По завершении двух дней трайб собирается на следующий FAST-митинг. Команда
быстро оценивает свой прогресс, и весь цикл повторяется. Это быстрый, подвижный
и неформальный процесс.
1
Буквально «приращение», «добавка». Часть (или версия) создаваемого продукта, потенциально
готовая к использованию и увеличивающая ценность для конечных пользователей/потребителей.
Инкремент необходимо показывать конечным потребителям для получения от них обратной
связи (отзывов, замечаний и предложений).
Внедрение FAST
FAST не настолько точно совпадает с техниками, представленными в этой книге, как
LeSS. Например, многие практики из уровня фокусировки не будут применимы.
В частности:
zz все места в книге, где упоминается термин
«команда», относятся к FAST-трайбу в целом; См. также
zz у вас будут дополнительные требования к ко-
Командная комната (глава 7)
мандной комнате, хотя настоящее руковод-
ство остается в силе, особенно для удаленных Согласование (глава 7)
команд; Ретроспективы (глава 11)
zz согласование и ретроспективы должны быть Визуальное планирование
настроены для работы с более крупными груп- (глава 8)
пами людей, и им, вероятно, понадобится более Игра в планирование (глава 8)
опытный фасилитатор, особенно для удален-
Планирование задач (глава 9)
ных команд;
Потенциал (глава 9)
zz визуальное планирование применимо в том
виде, в котором описывается здесь, но в него Резерв времени (глава 9)
больше не включается ничего мельче, чем один Стендап-митинги (глава 9)
ценный инкремент (Valuable Increment);
Прогнозирование (глава 10)
zz игра в планирование, планирование задач и по-
тенциал больше не нужны; Динамики команды (глава 11)
zz резерв времени должен внедряться по-другому;

zz стендап-митинги заменяются FAST-митингами;
zz прогнозирование — совершенно другое (и значительно проще, хотя его точность
не оценивалась);
zz динамики команд осложнены, поскольку отсутствуют постоянные составы команд.
В то же время одинаково хорошо соответствуют FAST практики уровней постав-

ки и оптимизации. Как и в LeSS, вам нужно быть более требовательным к скорости
непрерывной интеграции.
Хотя FAST и не проверялся до такой степени подробно, как LeSS, я считаю его
очень перспективным. Если у вас есть опыт в Agile и вам ничего не мешает проте-
стировать его с пилотной командой, состоящей из 10–30 человек, то рекомендую
вам сделать это.
Для тестирования FAST вам нужны опытные коучи. В теории FAST требует
свободного владения навыками только на уровне фокусировки. Однако Рон Куартел
включил в свой пилотный проект с FAST коучей, имеющих опыт в экстремальном
программировании, и я подозреваю, что отчасти именно их знание практик уровней
поставки и фокусировки заставило FAST работать. Если вы решитесь попробовать
его, то я советую вам сделать то же самое.
Вы можете найти больше информации о FAST на сайте fastagile.io. Поищите там
раздел FAST Guide. Руководство короткое и легко читается. У меня на сайте также
есть интервью с Роном Куартелом о FAST [Shore2021].
Проблемы и преимущества вертикального масштабирования

Ахиллесова пята вертикального масштабирова-
ния также является и его сильной стороной: это См. также
совместное владение. Вертикально масштаби-
рованная группа команд совместно отвечает за Коллективное владение кодом
(глава 12)
всю базу кодов. Для этого нужно, чтобы люди
были знакомы с большим разнообразием кодов.
На практике, по крайней мере в LeSS и FAST, люди обычно имеют специализацию
и стремятся работать в тех областях, которые уже знают, но при этом еще могут со-
вершенствоваться.
Однако это не самая большая проблема. Настоящая сложность в том, что кол-
лективное владение кодом может легко превратиться в отсутствие владения. Как
вы понимаете, коллективное владение не только дает возможность изменять код,
но и налагает на вас ответственность улучшать код, когда вы видите такую воз-
можность. В больших группах легко предполагать, что это сделает кто-то другой.
В маленьких командах это тоже может быть проблемой, но в больших группах эф-
фект возрастает. Людям потребуется больше коучинга, чтобы помочь им свыкнуться
с этой ответственностью.
Вместе с тем вертикальное масштабирование решает одну из главных проблем
масштабирования Agile: создание кросс-функциональных команд. Agile-командам
нужны люди со специальными навыками, такими как UX-дизайн, эксплуатация
и безопасность. Если в каждой из ваших команд только шесть или семь человек,
то вам будет трудно оправдать включение людей с этими навыками в каждую
команду. Но если этого не сделать, то вы столкнетесь с трудностями при распре-
делении задач. Как убедиться в том, что у команды есть все, кто ей необходим,
в нужное время?
А для вертикально масштабированных групп это не проблема. Если у вас 30 че-
ловек и достаточно работы только для двух UX-специалистов, это не проблема:
вы можете взять всего двух UX-специалистов. В FAST они сами включат себя в те
команды, в которых нужны их навыки. В LeSS они присоединятся к определенной
команде или двум, и эти команды вызовутся добровольцами на задачу, требующую
квалификации в UX.
Горизонтальное масштабирование
Применительно к крупномасштабному Agile я предпочитаю вертикальное масшта-
бирование. Но многие организации вместо этого обращаются к горизонтальному.
В нем основное внимание уделяется тому, чтобы позволить командам работать
изолированно. Вместо того чтобы коллективно владеть продуктом или портфелем,
как это происходит в вертикальном масштабировании, горизонтальное разделяет
продукт или портфель на индивидуальные зоны ответственности, которыми владеют
отдельные команды.
Задача горизонтального масштабирования состоит в определении зон ответствен-
ности команды таким образом, чтобы они оставались максимально изолированными.
Это очень трудно сделать правильно и затрудняет адаптацию к изменениям в при-

оритетах продукта.
В теории каждая команда должна владеть долей продукта, полностью ориенти-
рованного на заказчика, от начала до конца. На практике горизонтально масштаби-
рованные команды настолько малы, что им сложно владеть целой долей. В итоге вы
приходите к тому, что двум командам необходим доступ к одному и тому же коду.
Но в горизонтально масштабированной модели команды не должны делиться кодом
с другими командами.
В результате, хотя в идеале каждая команда владела бы долей продукта, вам поч-
ти всегда придется вводить в работу и менее идеальные типы команд. В книге Team
Topologies [Skelton2019] они разделены на четыре категории.
zz Поточно-ориентированные команды. Это идеальный вариант. Они сфокусиро-
ваны на определенном продукте, его доле, обращенной к заказчику или группе
заказчиков.
zz Команды сложных подсистем. Фокусируются на построении части системы, тре-
бующей определенных специальных знаний, например компоненты машинного
обучения в составе облачного решения. Эти команды следует создавать очень
взвешенно и только тогда, когда требуемые знания являются действительно
специфическими.
zz Вспомогательные или помогающие команды. Фокусируются на предоставлении
специализированных экспертных знаний другим командам, например UX, экс-
плуатации или безопасности. Вместо того чтобы выполнять работу за другие
команды, что сделало бы их узким местом, они помогают командам учиться
делать эту работу самостоятельно. Иногда это подразумевает предоставление
ресурсов, помогающих в решении комплексных проблем, например чек-листов
по безопасности или рекомендаций по UX-дизайну.
zz Команды платформ. Похожи на вспомогательные команды, за исключением того,
что предлагают скорее инструментарий, чем прямую помощь. Равно как и вспо-
могательные команды, не решают проблемы за другие команды; вместо этого их
инструменты помогают командам самостоятельно справляться со своими про-
блемами. Например, команды платформ могут предоставлять инструментарий
для развертывания программного обеспечения.
Секрет успеха горизонтального планирования — в правильном распределении
ответственности среди команд. Чем меньше перекрестных зависимостей между
командами, тем лучше. Это фундаментальный вопрос архитектуры, поскольку зоны
ответственности ваших команд должны имитировать желаемую системную архитек-
туру. (Это также называется обратным маневром Конвея (Inverse Conway Maneuver).)
Горизонтальное масштабирование работает наилучшим образом, когда у вас
всего несколько команд. Когда их количество невелико, легко понять, как все они
сочетаются друг с другом, и координировать их работу. Если есть проблема, то пред-
ставители команд могут собраться вместе и все урегулировать.
Такой принцип координации по необходимости (ad-hoc coordination) перестает
работать при наличии примерно 5–10 команд. Начинают формироваться узкие места,
одни команды почти останавливают работу, а другие оказываются перегружены ею.

Чтобы сохранять команды как можно более независимыми друг от друга, вам нужно
уделять особое внимание их структуре. Каждая команда, особенно те, которые не от-
носятся к типу поточно-ориентированных команд, должна рассматривать автономию
тех, кто от нее зависит, как свой высочайший приоритет. А продакт-менеджеры
должны тщательно координировать действия всех участников, обеспечивая общую
согласованность работы.
Когда вы достигаете уровня 30–100 команд, даже этот подход начинает сбоить.
Чаще происходят различные изменения, и зоны ответственности команд нужно
корректировать, чтобы не отставать от изменений в бизнес-приоритетах. Вам уже
требуется многоуровневая система координации и управления. Люди перестают
понимать, как работает система в целом.
Хотя горизонтальное масштабирование может продолжаться до бесконечности,
на практике по мере роста количества команд управлять им становится все труднее.
Вертикальное масштабирование является более гибким, но не может масштабиро-
ваться до такой степени. К счастью, можно получать преимущества обоих вариантов,
комбинируя два подхода.
Вертикальное и горизонтальное масштабирование

Я работал со стартапом, в котором участниками команд стали 300 человек и который
застопорился на этом. (Вся организация насчитывала более 1000 человек, а в коман
дах разработки продукта состояло около 300 человек.) Все команды работали над
разными аспектами одного и того же продукта, и кросс-командные зависимости
просто блокировали их деятельность.
Я подошел к задаче со стороны горизонтального масштабирования и помог им
реструктурировать зоны ответственности команд так, чтобы минимизировать зависи-
мости и максимизировать изоляцию. В итоге они достигли уровня 40 команд (почти
то же, что и раньше), но были гораздо более независимыми. Это разблокировало их
попытки развития, и они продолжили рост. Они выросли до 80 команд, прежде чем
столкнулись с новым препятствием.
Все были довольны результатом. Однако если бы я мог сделать это еще раз, то
внедрил бы и вертикальное масштабирование. Вместо 40 команд они могли бы сфор-
мировать шесть групп по 50 человек в каждой. Координировать шесть вертикально
масштабированных групп значительно легче, чем 40 маленьких команд, и у них
не было бы проблем при дальнейшем масштабировании. Даже когда они бы начали
сталкиваться с проблемами координации, техники горизонтального масштабирования
помогли бы им вырасти на порядок.
Так как вертикально масштабированные группы большие, еще лучше было бы,
будь все они согласованными по потоку. Созданная нами структура содержала
вспомогательные команды и команды платформ, и некоторые из них изо всех сил
пытались понять свою роль. Поточно-ориентированные команды гораздо проще.
Используя вертикально масштабированные группы, они получали бы все, что им
было нужно, кроме операционной платформы.
Отчасти причина того, что в работе начались сбои, когда этот стартап разросся
до 80 команд, — в том, что организация не поддерживала в актуальном состоя-
нии зоны ответственности команд. Мы спроектировали механизм пересмотра
и обновления обязанностей команд (это была работа команды архитекторов), но,
как это часто случается, о нем забыли на фоне выполнения других обязанностей.
А вертикально масштабированные группы не нуждаются в таком же объеме со-
провождения. Они могут намного легче адаптироваться к меняющимся условиям
бизнеса.
Другими словами, вы можете комбинировать вертикальное и горизонтальное
масштабирование, представляя себе свои вертикально масштабированные группы
как одну «команду» с точки зрения горизонтального масштабирования. При этом
почти каждая может быть поточно-ориентированной, возможно, за исключением
группы, занятой вашей операционной платформой.
Моя рекомендация
Резюмируем: как вам масштабировать вашу Agile-организацию?
Начните с формирования компетентной команды. Наиболее частая ошибка,
которую допускают организации, — это начать широко распространять Agile, не до-
бившись свободного владения навыками
у команд. В большинстве случаев хоро- Начните с формирования у команды
шее масштабирование потребует от ваших свободного владения навыками.
команд развития компетентности на уров-
нях фокусировки и поставки.
Делайте вертикальное масштабирование прежде, чем горизонтальное. В боль-
шинстве случаев лучшим выбором является LeSS. Если у вас есть опыт и вы хотите
экспериментировать, то попробуйте FAST.
Если вы достигли пределов вертикального масштабирования (вероятно, около
60–70 человек, хотя FAST, возможно, способен и на дальнейшее масштабиро-
вание), то разделитесь на множество вертикально масштабированных групп.
Каждая должна быть поточно-ориентированной. Вам вряд ли понадобится ко-
манда сложных подсистем или вспомогательная команда, поскольку ваши группы
будут достаточно велики, чтобы иметь все необходимые знания. В некоторых
случаях вы можете захотеть сформировать отдельную группу платформ, чтобы
заботиться об общей инфраструктуре — обычно о платформе эксплуатации или
развертывания.
Если вы используете LeSS, то LeSS Huge описывает этот тип разделения при
горизонтальном масштабировании, хотя и с небольшими различиями. Он сохраняет
присущий LeSS акцент на коллективном владении кодом, даже двумя группами (ко-
торые LeSS называет «областями»). Однако в действительности группы склоняются
к специализации.
Но помните: успех масштабирования зависит от свободного владения навыками
команд. Этому посвящена вся оставшаяся часть книги. Мы начнем со свободного
владения навыками на уровне фокусировки.
Несколько слов о SAFe

SAFe (Scaled Agile Framework), масштабированный гибкий фреймворк, представ-
ляет собой популярный подход к Agile-масштабированию. К сожалению, я пока
еще не видел его хорошо работающим. Как правило, компании принимают его
с большой помпой, но через несколько лет тихо избавляются от него.
Я не знаю точно, почему это так. Критики SAFe заявляют, что это не совсем Agile
и что ему свойствен характерный оттенок преобладания «процессов над людьми»
и «предиктивности над адаптивностью».
Я подозреваю, что настоящих причин неудач SAFe две. Во-первых, SAFe подчерки-
вает, что «он дружествен для предприятий», что в организациях, которые я видел,
приводит к недостаточным инвестициям в идеи Agile. Организации склонны при-
держиваться привычного предиктивного мышления в стиле управления сверху
вниз и «командуй-и-контролируй».
Во-вторых, SAFe мало что предлагает для координации команд — самой сложной
и критически важной проблемы масштабирования. До SAFe 5 он предлагал делить
команды по функциональностям (то же, что и LeSS), но это было крайне невы-
годно и не включало элементы, с помощью которых LeSS обеспечивает работу
команд1. SAFe 5, появившийся в феврале 2021 года, заменил функциональные
команды дискуссией о топологиях команд, которая хотя бы содержит больше
деталей. Но это подход горизонтального масштабирования, что является шагом
назад. Он требует обращать пристальное внимание на структуру обязанностей
команд, которую SAFe опять-таки даже не упоминает, не говоря о том, чтобы по-
мочь с этим разобраться.
Небольшим вкладом SAFe в координацию команд может считаться сессия пла-
нирования инкремента программы (Program Increment (PI) Planning) каждые не-
сколько месяцев, также известная как «планирование в большой комнате». Эта
сессия предиктивная, не адаптивная; чрезвычайно трудоемкая и изнурительная;
плохо работающая с удаленными командами. Хотя некоторые команды и ценят
ее за возможность привести команды к общему пониманию, по моему опыту, это
первое, от чего избавляются компании. К сожалению, в SAFe больше нет ничего
особенного, и как только из него исчезает PI Planning, вы остаетесь с группой
команд и ограниченными возможностями их координации.
В общем и целом SAFe на словах поддерживает идеи Agile, однако не понимает
их по-настоящему. Я его не рекомендую.
1
См. https://www.scaledagileframework.com/features-and-components по состоянию на 30 июня
2021 года.
II
ФОКУС НА ЦЕННОСТЬ
Вы приходите на работу прохладным октябрьским утром. Ваша предыдущая команда

работала полностью удаленно, но нынешняя предпочитает работать в офисе. Стили
общения — абсолютно разные, размышляете вы, но Agile — тот же самый.
Ваша команда свободно владееет навыками на уровне фокусировки. Как команда,
вы очень хорошо понимаете потребности заказчика, выступаете с хорошими идеями
и фокусируете свою работу на наиболее ценном из того, что можете сделать. Вам есть
что улучшить, в частности, в сфере дефектов и развертывания, и люди говорят об
инвестировании в свободное владение навыками и на уровне поставки, что позволит
решить эти проблемы, но в целом руководство очень довольно вашей работой.
Некоторые выступают с идеей, чтобы ваша команда взяла на себя полную от-
ветственность как команда оптимизации, но в данный момент ваши приоритеты
определяет Ханна, продакт-менеджер из отдела маркетинга. Она очень занята, и ее
босс не хочет назначать ее в вашу команду на полный рабочий день.
Кстати, о направлении развития продукта. Сегодня демодень. Каждую неделю
ваша команда выпускает новую версию своего ПО, затем составляет план на следу-
ющую неделю разработки. Раз в месяц вы встречаетесь с вашими основными стейк-
холдерами, показываете, что сделали, и получаете от них обратную связь. Раньше
вы делали это чаще, но представителей стейкхолдеров нельзя беспокоить слишком
частыми встречами. Так что ваши демо стали реже и короче, и обычно все участники
встреч предвкушают что-то новое. Когда нужна более быстрая обратная связь, вы
проводите частные демонстрации для отдельных заинтересованных лиц.
Как обычно, демо ведет Ханна. Сначала она хотела, чтобы его вели члены команды,
но вы обнаружили, что Ханна уделяет больше внимания тому, что вы создаете, если
сама отвечает за демо. Это улучшает результаты и обратную связь от заказчиков.
Вдобавок она лучше умеет находить общий язык со стейкхолдерами.
104 Часть II. Фокус на ценность
Стейкхолдеры, кажется, довольны вашим прогрессом за этот месяц. Большой

интерес вызвала функциональность для немарочного продукта (whitelabel), над
которой вы сейчас работаете, и, как обычно, поступило несколько предложений.
Ханна принимает их к сведению.
После демо приходит время вашей еженедельной командной ретроспективы.
Она позволяет вашей команде обсудить практики, динамику и имеющиеся органи-
зационные препятствия на пути к экспериментам, а также возможные улучшения.
Периодичность ваших демо — как раз результат одного из таких экспериментов.
Каждую неделю вы меняете ведущего ретроспективы. На этой неделе очередь
Шайны. Вы ждете с нетерпением. Шайна всегда придумывает творческие занятия,
чтобы оживить ретроспективу, и ей очень хорошо удается увлечь команду разными
экспериментами.
У вашей команды перерыв после ретроспективы, затем Ханна начинает еже-
недельную сессию планирования. Она достает доску для визуального планиро-
вания. Это большая белая доска с пачкой индексных карточек, прилепленных
к ней магнитами. Карточки образуют кластеры, и у каждого из них есть название,
например, «реселлеры», «актуарии», «бухгалтеры». Кластеры представляют собой
группы ваших заказчиков. Есть и другая большая группа карточек, помеченная
словом whitelabel.
«У нас были хорошие идеи во время демо, — говорит Ханна, — но я хочу, чтобы
мы продолжили фокусироваться на функциональности для немарочного продукта
для реселлеров». Все кивают. Вы работаете над этим уже несколько недель, так что
это для вас не является сюрпризом. «Мы близки к завершению самой сути нема-
рочного продукта, поэтому следующий этап — экраны администратора. Перед этим
я хотела бы организовать пробный прогон с одним из наших главных реселлеров.
Я пришлю подробную информацию по электронной почте».
Ханна делает знак Колтону, UX-дизайнеру команды, и он вступает в разговор. «Мы
с Ханной собираемся заняться пробным прогоном и администрированием whitelabel
чуть позже сегодня. Приглашаем всех поучаствовать. После этого я хотел бы составить
карту историй и провести игру в планирование, чтобы конкретизировать истории.
Это не должно быть слишком сложным. Я сообщу вам, когда мы это запланируем».
Ханна берет несколько голубых карточек с историями из раздела доски, подпи-
санного whitelabel. «У нас еще достаточно историй на эту неделю. Наш потенциал
все еще составляет 12 пойнтов (point), верно?» Все кивают. «Отлично. Вот 3… 6… 8,
11, 12. Это должно приблизить нас к пробному прогону с реальными заказчиками».
Она поднимает первую карточку, на которой написано «цветовая схема whitelabel».
«Окей, для этого нам нужна возможность изменить цветовую схему сайта, чтобы она
соответствовала фирменным цветам каждого реселлера». Вдобавок Ханна кратко
поясняет содержимое остальных карточек. Ей задают несколько уточняющих во-
просов, но вообще-то вы все уже видели это раньше, поэтому процесс идет быстро.
«Вот такой план! — заканчивает Ханна. — Колтон сможет ответить на любые во-
просы, касающиеся деталей. Сейчас мне нужно заняться электронными письмами,
но я буду здесь, — она показывает на угол, — до тех пор, пока вы не закончите пла-
нирование. Дайте знать, если от меня понадобятся какие-либо пояснения».
Часть II. Фокус на ценность 105
Ханна садится, и Шайна берет инициативу в свои руки. Некоторое время назад вы
решили (это был другой эксперимент с ретроспективами), что тот, кто ведет ретроспек-
тиву, будет фасилитировать все собрания команды в течение недели. Вы не слышали,
чтобы какие-либо другие команды работали подобным образом, но наличие заранее
назначенного фасилитатора помогает вам придерживаться выбранного направления,
тем более сейчас, когда ваш коуч перешел в другую команду.
Шайна переворачивает планировочную доску. На обратной стороне ваш план
на неделю. «Окей, вы знаете упражнение, — говорит она, указывая на пять карточек
с историями, выбранными Ханной. — Разложите их, и начнем мозговой штурм.
Нужно выписать задачи на желтые карточки. Я приготовлю доску».
Члены команды собираются вокруг стола и начинают записывать задачи на жел-
тых карточках. В процессе этого они высказывают свои соображения, что, в свою
очередь, вдохновляет всех на дополнительные идеи. «Обновить схему DB так, чтобы
она содержала цветовую схему». «Вынести переменные CSS». «Сделать для каждого
реселлера отдельный файл CSS». «Добавить CSS-файл реселлера к шаблону верх-
него уровня». Вскоре появляется упорядоченная сеть карточек, показывающая все,
что команде нужно сделать за эту неделю. Шайна помогает перенести все на белую
доску. Вы слышали, что другие команды визуализируют свои планы по-другому, но
вам нравится именно этот подход.
«Давайте соберемся на стендап», — говорит Шайна. Вы собираетесь вокруг белой
доски и сначала кратко обсуждаете, над чем будете работать, а затем каждый участ-
ник снимает с доски карточку с задачей. На каждую задачу уходит всего несколько
часов, поэтому, как только она завершена, вы помечаете ее как выполненную и берете
с белой доски новую. Каждый день вы проводите новый стендап-митинг вокруг
доски, чтобы оценить ваш прогресс и убедиться, что неделя идет должным образом.
«Думаю, на этом все», — говорит Шайна. Стендап занял всего несколько минут,
а вся сессия планирования продолжалась менее часа. Учитывая ретроспективу и демо,
время приближается к полудню. «Кто на обед?»
ДОБРО ПОЖАЛОВАТЬ НА УРОВЕНЬ ФОКУСИРОВКИ

Свободное владение навыками на уровне
фокусировки — для тех команд, которые Область фокусировки —
хотят сконцентрироваться на том, что их для тех команд, которые хотят
компания ценит больше всего. Они тесно со- сконцентрироваться на том, что их
трудничают со своими бизнес-партнерами, компания ценит больше всего.
чтобы понимать приоритеты, обеспечивать
наглядность и реагировать на обратную связь. В частности, команды, которые сво-
бодно владеют навыками на уровне фокусировки1:
zz планируют свою работу с точки зрения бизнес-ценности, а не технических задач
и согласовывают работу с бизнес-приоритетами компании;
1
Эти списки взяты из [Shore2018b].
zz демонстрируют прогресс по меньшей мере ежемесячно и делают это с точки

зрения бизнес-ценности, а не технических задач;
zz меняют свое направление, чтобы следовать за изменениями в приоритетах
бизнеса;
zz обеспечивают наглядность своего прогресса, чтобы руководство могло вме-
шаться, когда команда создает не то, что нужно, или в ее работе отсутствует
прогресс;
zz регулярно улучшают свои рабочие привычки, снижая затраты и повышая эф-
фективность;
zz поддерживают сотрудничество внутри команды, уменьшая недопонимание и за-
держки в процессах внутри команды.
Чтобы добиться всех этих преимуществ, командам необходимо развить соответ-
ствующие навыки. Это требует инвестиций, описанных в главе 4.
Команда отвечает на потребности бизнеса:
zz работает с представителем бизнеса, который обеспечивает ее организационными
перспективами и ожиданиями;
zz стейкхолдеры от бизнеса могут быть уверены, что команда будет работать
над тем, что ее бизнес-представитель называет своим самым важным при-
оритетом;
zz команда планирует свою работу и демонстрирует прогресс поэтапно, чтобы ее
бизнес-представитель мог его понять и оценить;
zz бизнес-представитель команды видит и может изменить направление работы
команды по меньшей мере раз в месяц;
zz руководство дает полномочия команде работать в темпе, позволяющем ей реаги-
ровать на потребности бизнеса сколь угодно долго.
Команда эффективно работает как команда:
zz составляет свои ежедневные задачи и план, основываясь на приоритетах ее биз-
нес-представителя;
zz участники считают план командной работой, а не индивидуальной;
zz члены команды разделяют ответственность за выполнение плана;
zz руководство считает план командной работой, а не назначает ответственными
отдельных исполнителей.
Команда стремится к командным достижениям:
zz принимает и постоянно улучшает общий подход к своей работе;
zz понимает, как внутрикомандные отношения влияют на ее способность достигать
успеха, и своевременно пытается их улучшить;
zz понимает, как рабочая атмосфера влияет на способность команды выполнять
работу, и своевременно пытается ее улучшить.
Часть II. Фокус на ценность 107
ДОСТИЖЕНИЕ СВОБОДНОГО ВЛАДЕНИЯ

НАВЫКАМИ НА УРОВНЕ ФОКУСИРОВКИ
Главы этой части помогут вашей команде достичь свободного владения навыками
на уровне фокусировки. Здесь содержатся практики, которые научат вас работать
как команда, планировать ценные релизы, управлять своей работой и нести за нее
ответственность, а также неуклонно совершенствоваться.
zz В главе 7 рассматривается эффективная работа в команде.
zz В главе 8 описывается, как планировать и приоритизировать работу в соответ-
ствии с бизнес-ценностью.
zz В главе 9 рассказывается о том, как взять на себя ответственность за повседнев-
ный процесс и планы.
zz В главе 10 описывается, как обеспечить наглядность рабочего процесса и заво-
евать доверие стейкхолдеров.
zz В главе 11 представлена информация о том, как улучшать рабочие привычки,
отношения и атмосферу в команде.
ГЛАВА 7
Командная работа
Лучшие требования, архитектурные и технические

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

Agile-организации. Но кто должен быть частью Agile-команды? Как они узнают, над
чем работать? Что помогает им продуктивно работать вместе?
В этой главе содержатся практики, позволяющие создать отличную команду
Agile.
zz С помощью практики «Вся команда» вы можете создать кросс-функциональную
команду, имеющую все необходимые навыки.
zz Практика «Командная комната» позволит создать пространство, физическое или
виртуальное, в котором команда может эффективно сотрудничать.
zz С помощью практики «Безопасность» вы можете создать рабочую среду, в которой
члены команды могут делиться опытом и знаниями.
zz Практика «Цель» помогает командам понять, как их работа поддерживает гло-
бальные планы компании.
zz В практике «Контекст» рассматриваются вопросы о стейкхолдерах команды
и выделенных ресурсах.
zz Практика «Согласование» дает возможность устанавливать нормы и правила,
позволяющие членам команды эффективно сотрудничать.
zz В практике «Энергичная работа» рассказывается о том, как работать таким спо-
собом, который ваша команда может поддерживать неограниченно долго.
Глава 7. Командная работа 109
Источники командной работы

Идея кросс-функциональных самоорганизующихся команд была частью Agile
с самого начала. В экстремальном программировании эта идея называется «вся
команда», данный термин я использую в этой книге. В Scrum это явление называ-
ется Scrum-командой. Командная комната — тоже устоявшийся термин, в экстре-
мальном программировании это называется «сидеть вместе», а в оригинальной
книге о Scrum [Schwaber2002] говорилось о важности рабочей среды для команды.
Безопасность также была частью обсуждения в Agile в течение многих лет.
[Beck2004] рассуждает об этом в своей дискуссии о команде. Джошуа Кериевски
называет принцип «безопасность — предварительное условие» руководящим прин-
ципом современного Agile. Обсуждение этой темы было включено в данную книгу
благодаря приглашенному автору Гитте Клитгаард, которая имеет огромный опыт
помощи командам и организациям в создании психологической безопасности.
Практики «Цель», «Контекст» и «Согласование» основаны на великолепной
книге Дианы Ларсен и Эйнсли Нис Liftoff: Start and Sustain Successful Agile Teams
[Larsen2016]. Вместе они являют собой пример подготовки устава (chartering), ко-
торый я впервые увидел, в контексте Agile, в методе Джошуа Кериевски Industrial
XP (IXP) [Kerievsky2005]. Подготовку устава внес в IXP неподражаемый III1, который
также оказал большое влияние на работу Нис и Ларсен.
Практика «Энергичная работа» — еще одна давняя идея Agile. Термин пришел
из XP: в первом издании книги по XP эта концепция носила название «40-часовая
неделя», но оно было пересмотрено, превратившись во втором издании в на-
звание «Энергичная работа», менее ориентированное на США.
ВСЯ КОМАНДА
У нас есть все навыки, необходимые для достижения
отличных результатов. Аудитория
Коучи
Современная разработка ПО требует множества на-
выков. Речь идет не только о навыках программирования,
но и о навыках общения с людьми. Художественных навыках. Технических навыках.
И когда команда не имеет этих навыков, производительность падает. Вместо того
чтобы сконцентрироваться на функциональности и завершить ее, члены команды
должны жонглировать множеством задач, отправляя электронные письма, ожидая
ответы и улаживая недоразумения.
Чтобы избегать подобных проблем, Agile-команды
создаются как кросс-функциональные команды. Они со- См. также
стоят из людей, имеющих разные навыки и опыт, кол-
лективно обладающих всеми данными, позволяющими Цель (глава 7)
людям выполнять свое предназначение. В широком
1
III — его полное имя. Произносится как «три».
смысле эти навыки могут быть сгруппированы в навыки в сфере деятельности за-
казчика, навыки разработки и навыки коучинга.
Обратите внимание, что Agile-командам нужны
навыки, а не роли. Иногда из старших программистов, Agile-командам нужны
давно работающих в компании, получаются лучшие навыки, а не роли.
продакт-менеджеры. Иногда руководители проектов
обладают великолепными навыками в тестировании. И вдобавок Agile-команды
учатся и растут. Каждый работает над расширением своих навыков, особенно в от-
ношении сферы деятельности заказчика.
В тексте этой книги, когда я пишу «продакт-менеджер» или «разработчик»,
я имею в виду кого-то в команде, кто имеет такие навыки, а не того, чья должность
в команде носит буквально такое название. Agile-команды работают наилучшим
образом, когда люди вносят вклад в соответствии с их навыками и опытом, а не по-
зицией в организационной структуре.
К А Р ГО - К УЛ ЬТ
Провальная команда
«Окей, теперь вы Agile», — говорит ваш руководитель и немедленно
исчезает за дверью офиса.
Вы вчетвером нервно смотрите друг на друга. Вы — команда фрон-
тенд-программистов и не совсем понимаете, что вам делать. До вас
доходили слухи о новой инициативе и о том, что ваша команда будет
участвовать в ней… как?
На следующий день вбегает Клодин. «Привет! Я ваш Scrum-мастер, — говорит
она. — Извините, вчера меня не было. У меня еще четыре команды, и я только
что узнала, что буду работать еще и с вами. Рамонита будет вашим владельцем
продукта, но она сегодня не сможет присутствовать. Я назначила встречу через
неделю».
Клодин вводит вас в курс дела касательно продукта, над которым вы будете
работать. Ваша команда создает пользовательский интерфейс, а несколько
других команд делают микросервисы бэкенда. Тестирование будет проводиться
отделом контроля качества, как обычно, и когда вы будете готовы к разверты-
ванию, то отправите заявку в отдел эксплуатации, который будет отвечать за
мониторинг и бесперебойную работу. «Вот макет интерфейса, подготовленный
отделом дизайна, — говорит Клодин, — и Рамонита добавит в трекер задач
истории со всеми требованиями. Я буду встречаться с вами каждый день на
стендап-митинге. Просто сообщайте мне, что вы сделали, и я буду обновлять
трекер задач».
Клодин выбегает, и ее голос, затихая, доносится из глубины коридора. «Дайте
мне знать, если вам что-то понадобится!» Вы смотрите друг на друга, пожима-
ете плечами и открываете трекер задач. Истории не совсем понятные, поэтому
вы отправляете несколько электронных писем с вопросами. И начинаете раз-
работку.
Проходит месяц. Все идет не очень хорошо. Вы встречаетесь с Рамонитой каждые

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

Люди, представляющие интересы заказ-
чика, пользователей или бизнеса, назы- См. также
ваются локальными заказчиками команды,
или просто заказчиками. Они отвечают Вовлечение реального заказчика (глава 8)
за понимание, что создавать. В зависимо-
сти от вида ПО, которое вы создаете, ваши заказчики в команде могут являться реаль-
ными заказчиками или могут быть людьми, представляющими реальных заказчиков.
Один из наиболее трудных моментов
при создании Agile-команды — найти Чтобы использоваться по-настоящему
людей с навыками в сфере деятельно- успешно, ваше ПО должно также
сти заказчика. Не пренебрегайте этими приносить пользу реальному заказчику,
навыками. Они необходимы для повы- пользователям и вашей организации.
шения ценности продукта, который вы
поставляете. Отличная команда может создавать технически совершенное программ-
ное обеспечение и без локального заказчика, но чтобы использоваться по-настоящему
успешно, ваше ПО должно также приносить пользу реальному заказчику, пользова-
телям и вашей организации. А это требует навыков в сфере деятельности заказчика.
Они бывают нескольких категорий.
Управление продуктом (оно же владение продуктом — ownership)

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

на полный рабочий день. См. также
Продакт-менеджеры должны иметь полно-
мочия принимать сложные компромиссные Цель (глава 7)
решения о том, что войдет в продукт, а что Контекст (глава 7)
останется за рамками. Этим людям требуются
Адаптивное планирование (глава 8)
навыки дипломатии, которые позволят согла-
совывать разнообразные интересы множества Визуальное планирование (глава 8)
стейкхолдеров, консолидировать их, превра- Демо для стейкхолдеров (глава 10)
щая в цель команды, а также эффективно от- Доверие стейкхолдеров (глава 10)
вечать «нет» на запросы, которые невозможно
выполнить.
Люди, имеющие навыки и влияние такого масштаба, обычно очень востре-
бованы и заняты. Вам может быть трудно привлечь их внимание. Настаивайте.
Продакт-менеджер — один из важнейших членов команды. От его участия зависит,
чем закончится проект: успехом или провалом. Если ваше ПО недостаточно цен-
но, чтобы отнимать время такого специалиста, то, возможно, не стоит и начинать
разработку.
Во многих компаниях довольно мало продакт-менеджеров. Для команд, рабо-
тающих медленно и имеющих предсказуемые задачи, это, возможно, не проблема.
Но чаще всего это приводит к тому, что команды тратят время впустую, создавая
не то, что требуется. [Rooney2006] столкнулся с этой проблемой, приведшей к пе-
чальным результатам:
Мы не знали, какие у нас приоритеты. Мы не были полностью уверены, над
чем работать дальше. Мы вытаскивали истории из общего списка, а заказчик
[продакт-менеджер] давал очень мало информации о том, над чем нам работать.
Так продолжалось несколько месяцев.
Потом мы обнаружили, что золотой владелец [исполнительный спонсор] был
очень рассержен — просто в бешенстве. По его мнению, мы работали совсем
не над тем, над чем должны были.
Не совершайте ошибку, экономя на ме-

неджменте продукта. Но помните: командам Не совершайте ошибку, экономя
нужны люди, имеющие навыки менеджмента на менеджменте продукта.
продукта, а не должность «менеджер по про-
дукту». Ведущий разработчик, пройдя тренинг, может стать отличным продакт-
менеджером, особенно если давно работает в этой компании и с этим продуктом.
В компании Toyota, например, главный инженер модели автомобиля несет полную
ответственность за все, от концепции до экономических результатов.
Экспертные знания в предметной области

(Domain expertise, Subject Matter Expertise)
Чаще всего программное обеспечение работает в определенной индустрии, например
финансовой, имеющей собственные правила ведения бизнеса. Чтобы успешно ис-
пользоваться в этой индустрии, ПО должно добросовестно реализовывать эти пра-

вила. Они называются правилами предметной области, а знание этих правил под-
разумевает знание самой предметной области.
В команде нужны эксперты, разбирающиеся в предметной области, которые будут
отвечать за выяснение всех деталей, разрешение противоречий и давать немедлен-
ные ответы на любые вопросы. Это должны быть люди с огромным опытом. Одна
Agile-команда, с которой я работал, разрабатывала ПО для химического анализа,
и в ней был химик-аналитик со степенью магистра. Другая создавала программу для
управления межбанковским залоговым обеспечением, и в ней были два финансовых
эксперта. Третья создавала ПО для страхования жизни, и ее эксперт в предметной
области был актуарием.
Даже если в вашем ПО нет сложных правил
предметной области, вам все равно понадобятся См. также
люди, которые смогут детально разобраться
в том, что именно оно должно делать. В неко- Поэтапные требования (глава 8)
торых командах таким человеком может быть Примеры заказчика (глава 9)
продакт-менеджер, дизайнер пользовательско- Единый язык (глава 12)
го интерфейса (User Experience; UX-дизайнер)
или бизнес-аналитик.
В отличие от продакт-менеджера, который должен много времени общаться со
стейкхолдерами, эксперт в предметной области проводит основное время с командой.
Бо́льшая часть этого времени уходит на прояснение деталей предстоящей работы,
создание примеров сложных правил и ответы на различные вопросы по данной
предметной области.
Дизайн пользовательского интерфейса (UX-дизайн)

(он же дизайн взаимодействий)
Пользовательский интерфейс вашего ПО — лицо вашего продукта. Для многих
пользователей интерфейс и есть продукт. Они судят о продукте, основываясь только
на том, какое впечатление у них вызвал его пользовательский интерфейс.
Люди, имеющие UX-навыки, определяют пользовательский интерфейс. Эти
навыки заключаются в понимании пользователей, их потребностей и того, как они
взаимодействуют с продуктом. В их работу входит проведение интервью и обсужде-
ние прототипов с пользователями, создание пользовательских образов, наблюдение
за использованием реального ПО и объединение этой информации в подробные
макеты и изображения.
Быстрая, итеративная и ориентированная на обратную связь природа Agile-
разработки приводит к формированию среды, отличной от той, к которой, возможно,
привыкли UX-дизайнеры. Вместо того чтобы включать UX-дизайн в предваритель-
ные исследования пользователей, его выполняют итеративно, одновременно с та-
кой же итеративной доработкой самого ПО. Agile-команды выпускают ПО каждую
неделю или две, что дает дизайнерам возможность дать его реальным пользователям,
понаблюдать за паттернами его использования и руководить дальнейшими планами
команды, основываясь на полученной обратной связи.
Навыки разработки
Великая цель требует надежной реализации. Если навыки в сфере деятельности за-
казчика позволяют разобраться, что нужно делать, то навыки разработки нужны для
того, чтобы понять, как это сделать. Люди, имеющие навыки разработки, отвечают
за то, чтобы найти наиболее эффективный способ поставки ПО.
Некоторые называют навыки разработки техническими навыками, что мне кажет-
ся не совсем верным. В конце концов химики-аналитики или актуарии не являются
техническими специалистами. Поэтому за неимением лучшего термина я буду
описывать людей, которые пишут, тестируют и выпускают ПО, как имеющих на-
выки разработки.
Программирование, дизайн и архитектура

Любой команде, разрабатывающей ПО,
конечно, необходим навык программи- См. также
рования. Кроме того, в команде поставки
Разработка через тестирование
каждый, кто пишет код, также делает
(глава 13)
дизайн и архитектуру, и наоборот. Такая
команда использует метод разработки Простой дизайн (глава 14)
через тестирование, чтобы объединить Инкрементный дизайн (глава 14)
архитектуру, дизайн, тесты и кодирова- Рефлексивный дизайн (глава 14)
ние в непрерывную деятельность.
Эволюционная системная архитектура
Но все же эксперты в дизайне и архи- (глава 15)
тектуре необходимы. Их роль — возглав-
лять работы по дизайну и архитектуре, Игра в планирование (глава 8)
помогая членам команды найти способы Без багов (глава 16)
упрощения сложного дизайна. Эксперты Сборка для эксплуатации (глава 15)
действуют на равных, скорее направляя,
чем командуя.
Навыки программирования позволяют осуществлять планирование, предотвра-
щать дефекты и упрощать развертывание ПО и управление им в производственной
среде.
Тестирование
Люди, имеющие навыки тестирования,
помогают команде поставки создавать См. также
качественные результаты с самого начала.
Поэтапные требования (глава 8)
Благодаря их критическому мышлению
заказчики при представлении будущего Примеры заказчика (глава 9)
продукта могут рассматривать все воз- Обнаружение слепых зон (глава 16)
можности. Эти люди также выступают
Без багов (глава 16)
в роли технических экспертов команды,
помогая ей обнаруживать слабые места и давая информацию о нефункциональных

характеристиках, таких как производительность и безопасность.
В отличие от большинства других команд, в процесс тестирования в команде по-
ставки не входит всестороннее тестирование на баги. Вместо этого ожидается, что
остальная часть команды будет выдавать почти безошибочный код. Когда какой-
либо баг все же появляется, команда меняет свои привычки, чтобы предотвратить
его появление в будущем.
Эксплуатация (Operations)
В командах поставки нужны люди, имеющие
навыки эксплуатации ПО. Они помогают раз- См. также
вертывать, контролировать, управлять ПО
и обеспечивать его безопасность в производ- Непрерывное развертывание
стве. В небольших организациях эти люди так- (глава 15)
же могут отвечать за обеспечение и управление Сборка для эксплуатации
аппаратными средствами (hardware). В более (глава 15)
крупных организациях они могут быть заняты Анализ инцидентов (глава 16)
координацией с центральной эксплуатацион-
ной группой.
В навыки эксплуатации также входит помощь команде в поддержании рабочих
реалий: планирование потребностей отдела эксплуатации, таких как безопасность,
производительность, масштабирование, контроль и управление; справедливое
распределение смен дежурств на линии поддержки (при необходимости); помощь
в анализе и предотвращении инцидентов.
Навыки коучинга
Командам — новичкам в Agile надо научиться многому: им нужно понять, как при-
менять практики Agile, вдобавок им следует научиться работать всем вместе как
эффективные самоорганизующиеся команды.
Их организациям также надо научиться способам поддержки своих команд.
Большую часть этой поддержки они дают в виде инвестиций, описанных в главе 4,
но всегда необходимы дополнительные изменения. И хотя лучше, если организации
делают нужные командам инвестиции заранее, командам часто приходится доби-
ваться необходимых инвестиций уже после того, как работа началась.
Люди, имеющие навыки коучинга, помогают командам учиться быть эффектив-
ными Agile-командами. Они обучают практикам, помогают в дискуссиях, направля-
ют самоорганизацию и развитие и показывают, как работать с руководителями
и другими бизнес-стейкхолдерами, чтобы получить нужные инвестиции.
Команды — новички в Agile обычно имеют в своем
составе одного, иногда двух человек, однозначно опре- Работа коуча —
деляемых как коучи команды. Работа этих людей — помогать команде
помогать команде стать независимо компетентной, стать независимо
чтобы все ее члены могли выполнять свои задачи компетентной.
без участия коуча. Это не значит, что коуч уходит из
команды, но это значит, что он мог бы, и если остается, то постепенно становится
постоянным членом команды.
Даже после того как команда станет независимо владеть навыками, будет по-
лезно присоединять к ней опытного коуча (скажем, раз в год или около того),
чтобы помочь ей вспомнить забытые практики и попробовать новые.
Командам нужен коучинг в четырех категориях в зависимости от того, какие

уровни свободного владения навыками их интересуют.
zz Развитие команды, самоорганизация и посредничество (все команды).
zz Практики планирования и командной работы на уровне фокусировки.
zz Практики разработки на уровне поставки.
zz Практики развития бизнеса на уровне оптимизации.
Для этого может потребоваться несколько коучей.
Часть работы коуча — научить команду
быть самодостаточной. Ее участники долж- См. также
ны быть способны сами помогать себе вести
дискуссии, улучшать динамику и практики Ретроспективы (глава 11)
своих команд, понимать, какие инвестиции Динамики команды (глава 11)
сделают их более эффективными, и работать
со стейкхолдерами так, чтобы получить эти Устранение препятствий (глава 11)
инвестиции. Как и со всеми командными на-
выками, нет необходимости, чтобы это мог делать каждый в команде, но чем больше
участников могут, тем более устойчивой она будет.
Некоторые коучи попадают в своеобразную ловушку и начинают делать все это
за команду, вместо того чтобы научить ее, как делать это самостоятельно. Убедитесь,
что это не ваш случай.
Коучи-практики
Для меня наиболее предпочтительный тип коуча в Agile — это коуч-практик: че-
ловек, который имеет реальный опыт применения практик Agile и может подавать
пример. Его основные усилия направлены на помощь команде и организацию обуче
ния, а не на поставку продукта, но у него есть навыки и опыт, чтобы показывать,
а не рассказывать, а это часто подразумевает помощь членам команды в их работе.
Опытный коуч-практик может работать с одной-двумя командами одновременно
или руководить работой коучей-игроков в нескольких командах.
Коучи-игроки
Один из вариантов коуча-практика — это коуч-игрок (играющий тренер, player-
coach), который имеет опыт в практиках Agile и некие навыки коучинга, но больше
сфокусирован на поставке, чем на помощи командам в обучении. В эту категорию
часто попадают «доморощенные» коучи (их должность может называться а-ля «тех-
нический руководитель» или «ведущий инженер»), как и большинство опытных
Agile-разработчиков.
Коучи-игроки могут быть очень эффективными, помогая командам в применении
практик Agile, вплоть до уровня свободного владения навыками. Но они могут быть
менее успешными там, где командам нужно стать самостоятельно владеющими на-
выками. Этим коучам также может быть трудно понять, как и когда нужно влиять на
организационные изменения. Они должны быть приписаны только к одной команде.
Коучи-фасилитаторы
Один из наиболее часто встречающихся типов коучей — коуч-фасилитатор, также
называемый Scrum-мастером1, который поддерживает коллег как бы со стороны,
помогая в общении и разбираясь с организационными препятствиями. Такие коу-
чи обычно обучают практикам на уровне фокусировки и помогают командам стать
самодостаточными. Они могут выступать в защиту нужных инвестиций, поэтому
полезны и командам, которые в своей работе сталкиваются со множеством препят-
ствий. Коуч-игрок и коуч-фасилитатор могут быть хорошей командой, поскольку
их сильные и слабые стороны взаимодополняемы.
Опытный коуч-фасилитатор может работать с одной или двумя командами
одновременно. Один из недостатков роли коуча-фасилитатора заключается в том,
что он не вносит вклад в ежедневную разработку. Из-за этого организации часто
считают таких коучей недостаточно занятыми и назначают им в работу одновремен-
но слишком большое количество команд. Но тогда коучи лишаются возможности
полноценно присутствовать в жизни команды и понимать проблемы, с которыми
она сталкивается. В этой ситуации многие коучи в конце концов просто постоянно
занимаются организацией собраний, что является не очень хорошей областью при-
менения их талантов.
Специалисты широкого профиля

Команды Agile работают наилучшим образом, когда состоят из специалистов
широкого профиля, также называемых людьми с профилем компетенций T, или
T-людьми (T-shaped people). Специалист широкого профиля обладает глубокими
знаниями и опытом сразу в нескольких областях, что символизирует вертикальная
линия буквы Т, но полезен и в некоторых других областях, необходимых команде.
Это символизирует горизонтальная черта. (Иногда используют термин «М-люди»
(M-shaped people), чтобы подчеркнуть, что такие специалисты могут развить у себя
экспертные навыки во многих областях.)
Agile-командам нужны такие специалисты, чтобы предотвращать образование
узких мест в рабочем процессе. Организации, не использующие Agile, следуют
1
Название Scrum-мастер пришло из популярного метода Scrum. Оно вводит в заблуждение:
предполагает кого-то, кто достиг мастерства в понимании Scrum, а не того, кто имеет власть или
контроль над командой.
сложным процедурам формирования ресурсов, чтобы обеспечить каждую команду

необходимыми специалистами в нужное время. Эти процедуры никогда толком
не работают, поскольку работа по созданию ПО не может быть предсказана настолько
точно, насколько они требуют. Поэтому командам в итоге приходится ждать нужных
людей, задерживающихся на других проектах, или торопливо находить какие-то за-
дачи для тех специалистов, которые освободились раньше, чем вся команда готова
к началу работы. Получается, что люди страдают из-за множества краткосрочных
разрозненных назначений, в то время как руководители борются за то, чтобы вы-
ровнять назначение в команде. Это ведет к разнообразным потерям.
В Agile-организации ресурс — это команды, а не индивидуумы, поэтому процесс
формирования ресурсов значительно более простой: все или ничего. Команда или
берется за разработку функциональности, или нет. Или нужного человека назначают
в команду, или она не приступает к работе.
Но вы можете столкнуться с узкими местами и внутри команды. Представьте
команду с двумя фронтенд- и двумя бэкенд-разработчиками. Иногда бывает больше
работы по фронтенду, и тогда разработчики бэкенда бездельничают. (Или они рабо-
тают на опережение, что в конечном итоге приводит к постоянным дорогостоящим
переделкам, что мы будем обсуждать во врезке «Минимизируйте объем незавер-
шенной работы» в главе 8.) В другое время ситуация в такой команде может быть
противоположной.
Команды, в составе которых есть специалисты широкого профиля, избегают
этого. Когда много работы по фронтенду, соответствующие специалисты берут ини-
циативу в свои руки, а бэкенд-разработчики им помогают. Когда много работы по
бэкенду, все наоборот. И речь идет не только о программировании. Какие бы узкие
места ни встретились команде, ее члены должны хотеть и быть способны вмешаться
и помочь решить проблему.
Вам не нужно, чтобы члены команды были специалистами широкого профиля,
когда вы впервые ее формируете. Это больше про их отношение к данному вопро-
су, чем возможности. Любой специалист при желании может научиться работать
в областях, близких к его основной специализации. При подборе людей в команду
убедитесь, что у них есть такое желание.
Комплектование команды
Точные названия должностей и ролей в вашей команде неважны, пока в ней пред-
ставлены все необходимые навыки. Должности больше имеют отношение к традициям
в вашей компании, чем к чему-либо еще.
В недавно сформированных Agile-командах полезно четко обозначить продакт-
менеджера и коуча. Для опытных команд четкие роли могут только мешать,
но новичкам в Agile будет полезно точно знать, к кому обращаться в случае
вопросов.
У вас может не получиться найти в команду

человека, имеющего навыки продакт-менед- Внештатные владельцы продукта
жера или экспертные знания в предметной не могут поддерживать команду
области. Во многих компаниях такого человека в долгосрочной перспективе.
назначают на неполный рабочий день коорди-
нировать команду в качестве владельца продукта. Рассматривайте это как знак того,
что члены команды должны сами развить у себя навыки менеджмента продукта и экс-
пертные знания в предметной области. Такой внештатный владелец продукта может
помочь им начать, однако не сможет поддерживать их в долгосрочной перспективе.
Лучшие Agile-команды прекрасно разбираются в сфере деятельности заказчиков.
Это хорошо сформулировал Бас Водде1:
Я вижу, что большинство команд, с которыми работаю, находятся на пути транс-
формации от «программистов» к «разработчикам продукта». Это означает, что
команда (вся команда!) глубоко понимает заказчика и его предметную область,
а не зависит от кого-то, кто выяснит все для них и передаст им результаты.
Да, мне нравится, когда в команде есть люди, которые хорошо знают заказчика,
но в основном имеют цель помочь всей команде совершенствоваться.
Даже в случае высокопрофессиональной команды некоторые решения будут при-

ниматься людьми, не входящими в вашу команду. Например, если она работает над
компонентом большого продукта, решения о системной архитектуре могут оказаться
вне вашей компетенции. Хорошо, если эти решения — только часть каких-то процессов,
происходящих на заднем плане. Но если вы постоянно ждете, пока люди, не входящие
в вашу команду, примут решение или сделают что-то для вас, — значит, ваша команда
неполная. Члены вашей команды должны иметь требуемые навыки и ответственность,
или же данный компонент продукта нужно отдать куда-то вне команды. Больше ин-
формации о кросс-командной координации доступно в главе 6.
Постоянные члены команды

Каждый постоянный член команды должен быть полностью приписан только к одной
команде. Дробные назначения (когда человек назначается одновременно в несколько
команд) дают ужасные результаты. Частично занятые работники не связаны со своей
командой, часто не присутствуют при обсуждениях и не слышат ответы на вопросы,
к тому же должны постоянно переключаться между задачами, что влечет за собой
множество скрытых потерь. «Минимальные потери — 15 процентов. Работники
с частичной занятостью могут выглядеть загруженными, но их загруженность — по
большей части бестолковая суета» [DeMarco2002] (гл. 3).
Скорее всего, некоторые навыки нужны вашей команде лишь изредка. Вы можете
приглашать людей, имеющих эти навыки, временно присоединиться к вашей команде.
Например, если она создает сложный продукт на серверной стороне, имеющий очень
маленький пользовательский интерфейс, то вы можете пригласить UX-дизайнера
присоединиться к вашей команде лишь на те несколько недель, в течение которых
вы работаете над интерфейсом.
1
В личном общении.
Даже если кто-то временно является частью вашей команды, договоритесь, чтобы
эти люди были полностью приписаны к вам на этот период. Лучше иметь кого-то,
назначенного в команду на полный рабочий день на одну неделю, а потом — к дру-
гой команде на другую неделю, чем того же человека, назначенного в обе команды
одновременно на две недели.
Стабильные команды
Команде может потребоваться несколько ме-
сяцев на то, чтобы научиться эффективно См. также
работать вместе. В некоторых организациях
команды создаются и расформировываются Динамики команды (глава 11)
для каждого нового проекта. Однако сохра-
нять состав команды — менее расточительный вариант. Даже если цель команды
достигнута или жизненный цикл продукта завершен, не распускайте команду. Вместо
этого дайте ей новую цель или продукт.
То же самое применимо и к изменению состава. Если вы добавляете человека
в существующую команду, то он встраивается в ее культуру и нормы. А если вы до-
бавляете нескольких, то команда практически начинает все с нуля. Мое правило —
добавлять или удалять не больше одного человека в месяц.
Размер команды
Рекомендации в этой книге предназначены для команд численностью 3–20 человек.
Для новых команд хорошей отправной точкой будет численность 4–8 человек. Пре-
высив количество в 12 человек, вы начнете замечать проблемы в общении, так что
будьте осторожны при создании больших команд. И наоборот, если у вас очень
маленькие команды, то подумайте о том, чтобы объединить их. Это уменьшит рас-
ходы, и вы будете менее чувствительны к текучести персонала.
Для большинства команд программирова-
ние поначалу будет узким местом. Поэтому,
См. также
планируя размер команды, начните с того,
чтобы подумать, сколько времени уходит Парное программирование
на программирование. Для удобства я буду (глава 12)
называть человека, на 100 % занятого про-
Групповое программирование
граммированием, «один программист», но это (глава 12)
не значит, что в вашей команде должны быть
строго обозначенные роли.
zz Команды, которые не используют парное или групповое программирование,
должны состоять из 3–5 программистов. По мере увеличения команды у них
начинаются проблемы с координацией.
zz Команды с парным программированием должны состоять из 4–10 программистов.
Оптимальное количество — шесть. Команды — новички в практиках поставки
не должны насчитывать больше 6–7 программистов, пока не приобретут доста-
точного опыта.
zz Команды с групповым программированием должны состоять из 3–5 програм-

мистов. Можно работать и с более многочисленными группами (это хорошая
обучающая техника), но в какой-то момент вы достигнете точки падения эф-
фективности.
Обычно оставшуюся часть команды комплектуют пропорционально объемам вы-
полняемого программирования. Соотношение должно быть примерно эквивалентно
количеству работы, которую надо сделать так, чтобы не образовывались узкие места,
а наличие специалистов широкого профиля должно позволять справляться с не-
равномерностью загрузки. В целом нужно планировать:
zz навыки в сфере деятельности заказчика — один-два локальных заказчика на каж-
дые три программиста. От четверти до половины их времени будет уходить на
менеджмент продукта. Оставшееся будет тратиться на сочетание экспертных зна-
ний в предметной области и UX- и UI-дизайна в зависимости от вида вашего ПО;
zz навыки тестирования — один тестировщик на каждые 2–4 программиста, если
команда не имеет свободного владения навыками на уровне поставки, или один
тестировщик на каждые 4–8 программистов, если имеет;
zz навыки эксплуатации — от нуля до двух специалистов эксплуатации в зависи-
мости от типа продукта;
zz навыки коучинга — один или два коуча, которые могут делить свое время с дру-
гими командами.
Повторюсь: речь идет не о наличии четких ролей в команде. Например, вы можете
иметь команду из шести программистов, включая коуча-игрока, которая затрачивает
примерно половину своего времени на программирование, одну шестую — на работу
с заказчиком, одну шестую — на тестирование и еще одну шестую — на эксплуатацию.
Почему так много заказчиков

Два заказчика на каждых трех программистов — это очень много, не правда ли?
Я начинал с гораздо меньшего соотношения, но часто видел, что заказчики дер-
жатся наравне с программистами. В итоге я пришел к соотношению «два к трем»
после экспериментов с разными соотношениями в различных успешных командах.
Все эти команды свободно владели навыками на уровне поставки, что подразуме-
вало наличие в команде менеджмента продукта. Большинство работали в сложных
предметных областях. Если у вас простое ПО и вы не стремитесь к свободному
владению навыками на уровне поставки или у вас в команде отсутствует менедж
мент продукта, то, вероятно, сможете обойтись меньшим количеством заказчиков.
Но имейте в виду, что у заказчиков очень много работы. Им необходимо понять,
что представляет наибольшую ценность, установить правильные приоритеты
в работе, определить все детали, о которых будут спрашивать разработчики,
и вовремя реагировать на отзывы и примеры от клиента. Заказчики должны все
это делать, на один шаг опережая программистов, которые (особенно в командах
поставки) неумолимо следуют за ними, словно товарный поезд, который невоз-
можно остановить. Это очень большая работа. Не стоит ее недооценивать.
Команда единомышленников
Никто в команде не отвечает за других. Далеко не каждое решение подлежит об-
суждению; но люди имеют решающий голос в своей экспертной области. Например,
программисты не могут не учитывать мнение заказчиков о приоритетах продукта,
а заказчики не могут не принимать во внимание мнение программистов о техниче-
ских необходимостях. Вдобавок у вас есть старшие члены команды, которые берут на
себя принятие важных решений. Но внутри нее нет иерархии подчиненности. Даже
люди с впечатляющими должностями, наподобие «продакт-менеджер», не управ-
ляют командой.
Это понимание важно для самоорганизующейся команды. Она сама решает, кто
возьмет на себя инициативу в любой задаче. И это нельзя считать трудным решением;
в командах, которые хорошо знают друг друга, это обычно происходит автоматически.
Таким человеком будет тот, кто лучше всех знаком с задачей, или тот, кто больше
всех заинтересовался получением дополнительной информации, или следующий
в очереди, или кто-нибудь еще.
При этом трудно передать, насколько весело и с удовольствием проводят время
высокопродуктивные Agile-команды. Брайан Марик, один из авторов Манифеста
Agile, говорил, что радостный настрой (Joy) — еще одна ценность Agile1. И он прав.
Отличные Agile-команды ее ощущают. Они оптимисты, энтузиасты своего дела
и получают истинное удовольствие от совместной работы. Есть чувство превосход-
ства, но они не воспринимают его слишком серьезно. Например, когда есть задача,
за которую никто не хочет браться, разговор о том, кто ее будет делать, может вестись
в игривой и веселой манере. И он протекает быстро. Эффективные Agile-команды
легко принимают решения.
Такая эффективность требует значитель-
См. также
ного времени и работы над собой. В прак-
тике «Динамики команды» показано, как Динамики команды (глава 11)
это сделать.
КЛЮЧЕВАЯ ИДЕЯ
Самоорганизующиеся команды
Agile-команды самостоятельно решают, над чем работать, кто будет это делать
и как. Это основная идея Agile: люди, которые выполняют работу, достаточно ква-
лифицированны, чтобы решать, как ее делать. Поэтому в данной книге так много
практик в областях планирования, взаимодействия и работы со стейкхолдерами.
За все это отвечают команды, а не менеджеры. От команд ожидается, что они
коллективно возьмут на себя ответственность и будут совместно работать для
достижения своей цели.
Это не значит, что руководителям нечем заняться. Фактически, делегируя де-
тали своим командам, руководители освобождают свое время, чтобы иметь
1
Марик определял четыре ценности, которые он видел в ранних Agile-командах: навык,
[само]дисциплина, легкость, радостный настрой [Marick2007a].
возможность сконцентрироваться на более значимой деятельности. Их работа —

настраивать команды на успех, управляя более широкой системой, в которую
встроены их команды. Более подробная информация представлена в разделе
«Менеджмент» главы 10.
Еще раз о провальной команде

Давайте еще раз взглянем на историю провальной команды (см. врезку «Провальная
команда» ранее в текущей главе). Что пошло не так?
zz Руководитель удивил команду и сразу ее покинул, вместо того чтобы настроить
ее на успех.
zz Коуч Клодин не помогала команде учиться.
zz У Рамониты, продакт-менеджера, совсем не было времени на команду.
zz В команде не было никого, кто разбирался бы в сфере деятельности заказчика.
zz У команды не было возможности самостоятельно выпускать продукт. Им требо-
валось координироваться с внешними командами: отделом контроля качества,
эксплуатации и бэкенда.
А вот как все это должно было произойти.
«Окей, сегодня день Agile», — говорит ваш руководитель. Вы согласились на этот
эксперимент несколько недель назад, так что никто не удивлен. «Как мы обсуждали,
мы формируем новую команду для работы над этим продуктом. Почему бы вам всем
не представиться и не рассказать о себе заново?»
Все присутствующие поочередно представляются. У вас три фронтенд-про-
граммиста (один имеет опыт работы с полным стеком (full stack experience)), один
бэкенд-программист, тестировщик и один UX-дизайнер. Вы уже познакомились со
своим коучем Клодин. Она представляет вам Рамониту, вашего продакт-менеджера.
Входит Клодин. «Я знаю, что вам всем не терпится узнать, как работает Agile,
поэтому сразу перейду к делу. Мы начнем с активности, называемой подготовкой
устава. Рамонита работает со стейкхолдерами нашего проекта, чтобы понять, что
мы будем создавать, почему и как это на всех повлияет. Мы тоже с ними встретимся
через пару минут. Кроме того, мы уделим некоторое время тому, чтобы понять, как
нам взаимодействовать наилучшим образом».
В течение следующих нескольких дней вы думаете, как выполнить эту работу,
и начинаете подбирать для нее технологии, имеющиеся в вашем распоряжении.
Рамонита не входит в состав команды, но Микки, ваш UX-дизайнер, будет плотно
работать с ней, чтобы конкретизировать ваши планы.
Проходят недели. Рамонита появляется часто, и Микки учится заменять ее,
когда она отсутствует. Благодаря тому, что ответственные за фронтенд, бэкенд, те-
стирование и эксплуатацию становятся одной командой, вам удается продвигаться
быстро. Через неделю вы проводите первое демо для стейкхолдеров, и их реакция
заряжает вас новой энергией. Вы — хорошая команда. И вам не терпится увидеть,
что будет дальше.
Вопросы
А что, если не хватает людей, чтобы обеспечить каждую команду всеми необходимыми
ей навыками, или определенный навык нужен команде не постоянно?
Для начала проверьте, не нанимает ли ваша компания слишком много програм-
мистов по сравнению с остальными экспертами, нужными командам разработки
ПО. Это распространенная ошибка. Если это так, то попробуйте изменить при-
оритеты найма.
Если у вас несколько команд, работающих над одним продуктом, то рассмотрите
возможность использования вертикального масштабирования, что позволит разумно
объединить их усилия, как описано в подразделе «Вертикальное масштабирование»
главы 6.
Если эти варианты не сработают, то ваша компания может сформировать вспомо-
гательную команду, ответственную за инструкции, стандарты и тренинг для других
команд, как описано в подразделе «Горизонтальное масштабирование» главы 6.
Например, какая-либо UX-команда может создать руководство по стилям и научить
людей, как его использовать применительно к программному обеспечению, разраба-
тываемому их командами. Это позволяет командам решать собственные проблемы,
не нуждаясь в полноценном опыте.
Когда требуется больше навыков, вы можете запросить, чтобы соответствующего
специалиста назначили в вашу команду временно. За этот период он сможет обучить
членов команды. Отложите любую работу, требующую определенных навыков, до
тех пор пока они не появятся. Таким образом вы не останетесь с наполовину выпол-
ненной работой, что ведет к потерям, как обсуждается во врезке «Минимизируйте
объем незавершенной работы» в главе 8.
Младшие члены команды наравне с остальными?
Члены команды необязательно наравне (у всех разная квалификация и опыт),
но они коллеги. Для младших членов команды будет разумным обращаться за со-
ветом и наставничеством к более опытным коллегам. А для тех, в свою очередь, раз-
умным будет обращаться ко всем с уважением, создавать товарищеские отношения
и помогать младшим коллегам расти, иногда делая шаг назад и позволяя им взять
инициативу в свои руки.
Как члены команды могут развить определенные навыки, не работая в команде,
специализирующейся на этом навыке?
Многие Agile-организации формируют сообщества практик вокруг функцио-
нальных специализаций. Их может вести руководитель, централизованная команда
поддержки или просто те, кому это интересно. Обычно эти люди проводят множество
тренингов, встреч и предлагают другие возможности для развития навыков.
Предварительные требования
Создание кросс-функциональной команды требует вовлеченности и поддержки от
руководства, а также согласия команды работать вместе как Agile-команда. В главе 5
можно найти больше подробностей о формировании такой вовлеченности.
Показатели
Когда ваша команда кросс-функциональна:
zz она способна решать проблемы и выполнять свою задачу, не дожидаясь внешних
специалистов;
zz люди в команде работают, выходя за рамки своей специализации, чтобы предот-
вратить появление узких мест и замедление работы;
zz команда способна принимать решения легко и эффективно;
zz люди в команде плавно перенимают роли лидерства от задачи к задаче.
Альтернативы и эксперименты
Теория, лежащая в основе этой практики, очень простая. Чтобы избежать задержек
и проблем в общении, следует:
1) найти всех, кто нужен для достижения ваших целей;
2) собрать их всех в одну команду;
3) организовать согласованную работу команды так, чтобы она достигла этих
целей.
Это основная идея Agile, и на самом деле нет никаких альтернатив, соответ
ствующих философии Agile. Но есть много возможностей для оптимизации де
талей. Накопив опыт использования этой практики, несколько месяцев применяя
ее буквально, как написано в этой книге, попробуйте немного поэксперименти-
ровать.
Например, как ваша команда может экспериментировать с изменением способов
принятия решений? Улучшается ли процесс, если назначить специального человека
для фасилитации дискуссий? Или пусть дискуссии текут свободно? Следует ли воз-
лагать некоторые решения на конкретных людей? Или ответственность руководства
должна быть более гибкой?
Простых ответов на эти вопросы не существует. Сделайте предположение.
Проверьте его, посмотрите, как все работает, и сделайте другое предположение.
Проверьте и его. Никогда не переставайте экспериментировать. Только так можно
достичь мастерства.
Литература для дополнительного чтения

The Wisdom of Teams: Creating the High Performance Organization1 [Katzenback2015] —
классическое издание о высокоэффективных командах.
Agile Conversations [Squirrel2020] — отличный ресурс для коучей, которые по-
могают командам и организациям развить культуру Agile.
1
Катценбах Дж., Смит Д. Командный подход: Создание высокоэффективной организации.
КОМАНДНАЯ КОМНАТА Аудитория

Мы взаимодействуем быстро и эффективно. Вся команда, коучи
Окончание истории
Вы — программист, работающий в команде над какой-то историей,
и вам нужны пояснения по одному из требований. Вы отправляете
электронное письмо вашему эксперту в предметной области,
Линн, и делаете перерыв, чтобы размять ноги и выпить кофе.
Когда вы возвращаетесь, ответа от Линн все еще нет, поэтому вы
заглядываете в пару блогов по теме разработки, которые соби-
рались почитать. Через полчаса вы получаете ответ Линн.
Эх, кажется, она не поняла ваше сообщение и ответила не на тот вопрос. Вы от-
правляете другое письмо, но дальше ждать уже не можете. Вы предполагаете,
каким мог бы быть ее ответ, и возвращаетесь к работе.
Днем позже, обменявшись еще несколькими письмами, вы вместе с Линн нащупы-
ваете правильный ответ. Он не совсем такой, как вы предполагали, но довольно
близок к этому. Вы возвращаетесь к тому месту в коде и корректируете его. В этот
момент вы вдруг понимаете, что есть еще один связанный случай, которым еще
никто не занимался.
Конечно, вы можете еще раз спросить Линн, но это очень странный случай. Скорее
всего, в реальной жизни он никогда не произойдет. Кроме того, Линн очень за-
нята, а вы обещали закончить с этой историей еще вчера. (Фактически все и было
готово вчера, кроме этих мелких придирок.) Вы снова делаете предположение
и продолжаете работу, не зная, что ваше предположение было неверным.
Когда люди не могут общаться напрямую, эффективность общения падает, как

обсуждается во врезке «Личное общение» далее в текущей главе. Возникают недо-
понимание и задержки. Люди начинают строить догадки, чтобы избежать долгого
ожидания ответов. Случаются ошибки. Начинает формироваться подход, в котором
есть противостояние группировок «мы» и «они».
Чтобы справиться с этой проблемой, многие команды пытаются снизить необхо-
димость прямого общения. Это спорный способ. Если вопросы порождают задерж-
ки и ошибки, снизьте необходимость задавать вопросы! Люди тратят больше време-
ни на предварительное выяснение требований и документирование каждой
потребности. Согласно этой теории, впоследствии программистам не нужно будет
общаться с экспертами; они могут просто посмотреть ответы в документе.
Звучит разумно, но на практике не рабо-
тает. Трудно заранее предсказать каждый То, что написано, очень легко понять
вопрос, и то, что написано, очень легко неправильно.
понять неправильно. К тому же это удлиняет процесс разработки: прежде чем при-
ступить к работе, людям нужно потратить много времени на написание, передачу
и чтение документов.
Поэтому Agile-команды используют общую команд-
ную комнату, чтобы разговаривать напрямую. Это место, См. также
физическое или виртуальное, в котором команда рабо-
тает и взаимодействует друг с другом. Вместо того Вся команда (глава 7)
чтобы назначать кого-то для общения с экспертами
в предметной области и готовить документы, которые потом будут читать програм-
мисты, Agile-команды включают в свой состав экспертов в предметной области
и других локальных заказчиков. Когда программистам надо понять, что делать, они
разговаривают с локальными заказчиками напрямую.
Совместная работа в одной комнате дает огромные
преимущества. В полевых исследованиях шести со- См. также
вмещенных рабочих команд [Teasley2002] было об-
Поэтапные требования
наружено, что работа в одном помещении удваивала
(глава 8)
продуктивность и ускоряла выход на рынок почти до
трети от базового расчетного уровня компании.
Это сто́ит того, чтобы повторить еще раз: команды поставляли ПО за треть
обычного времени. После пилотного исследования еще 11 команд достигли того же
результата.
Личное общение
Непосредственное общение является наиболее практичным и эффектив-
ным способом обмена информацией как с самой командой, так и внутри
нее.
Несмотря на успехи технологий, непосредственное, личное общение остается
самым эффективным способом общения. Перефразируя [Cockburn2006] (гл. 3),
существует несколько осей эффективности общения. Удаление каждой из них
делает его менее эффективным.
zz Сотрудничество лучше, чем разговоры. Под сотрудничеством я понимаю со-
вместную работу над общим ви́дением или другим артефактом. Это делает
идеи реальными, выявляя предположения и разницу в смыслах, которые
скрываются за словами.
zz Лично лучше, чем виртуально. В личном общении участники видят все нюансы
и сигналы, такие как малейшие движения глаз и едва различимые знаки языка
тела. Люди двигаются, общаясь с помощью поз, прикосновений (например,
кладя руку на плечо) и неосознанной синхронизации. Эти нюансы (неосознан-
но) помогают участникам лучше понимать друг друга.
zz Видео лучше, чем только аудио. Аудио лучше, чем текст. В аудио люди исполь-
зуют интонации и паузы, чтобы дать место юмору, выразить беспокойство,
передать важные оттенки. В видео участники дополнительно общаются с по-

мощью выражения лица и жестов.
zz В реальном времени лучше, чем асинхронно. В разговоре, происходящем
в реальном времени, собеседники прерывают друг друга, уточняют и управ-
ляют вектором беседы.
zz Интерактивное общение лучше, чем одностороннее. В интерактивном обще-
нии участники задают вопросы, чтобы прояснить непонятные моменты.
Уберите все это — и получите написанный документ. Нет нюансов, интерактив-
ности, но есть максимум возможностей для неверного понимания.
Секреты сотрудничества
Чтобы ваша командная комната была максималь-
но полезной, ваша команда должна быть единой См. также
и полной. Вы не получите всех преимуществ кросс-
функционального сотрудничества, если люди, с кото- Вся команда (глава 7)
рыми вам надо общаться, не являются членами вашей
команды. Убедитесь, что кто-то из членов команды может заменить тех, кого работа
часто заставляет покидать командную комнату (обычно в эту категорию попадают
продакт-менеджеры).
Даже если ваша команда пока неполная, тем не менее совместная работа в одной
комнате позволит придать новый импульс вашему сотрудничеству. Ниже я описал
несколько моих любимых техник.
Всегда просите помощи, всегда помогайте

Если вы зациклились на проблеме, а кто-то в команде знает ответ, попросите его
помочь. Нет смысла биться головой о стену. Многие команды заключают рабочее
соглашение: «Мы всегда помогаем, когда член команды просит помощи».
Некоторые, услышав это правило, беспокоятся,
что не будут продуктивными. И в некоторой степени
Agile фокусируется
они правы. Если вы будете проводить много времени, на продуктивности
отвечая на вопросы, то вы, возможно, будете не столь команды, а не отдельных
продуктивны. Но Agile — это команда. Даже если вам лиц.
в конечном итоге придется тратить больше времени,
команда в целом будет более продуктивной.
А как насчет программирования и другой работы, требующей глубокой со-
средоточенности? Согласно [DeMarco2013], у программиста уходит 15 минут
и больше на то, чтобы погрузиться в работу после прерывания. Не может ли
культура, в которой все время просят о помощи, повредить общей продуктивности
программирования?
Может. Но в то же время быстрое решение проблем программирования с помощью
просьб о помощи — одна из прекрасных возможностей улучшить продуктивность
команды в целом. Поэтому вместо того, чтобы избегать прерываний, ищите способы,
как сделать так, чтобы они не отвлекали.
Лучший способ избежать длительного от-
влечения в случае прерываний — использовать См. также
парное или групповое программирование. В слу-
чае парного программирования, пока один че- Парное программирование
(глава 12)
ловек отвечает на вопросы, второй может про-
должать размышлять над текущей задачей. Групповое программирование
По завершении прерывания вопрос «На чем мы (глава 12)
остановились?» вернет процесс в прежнее русло.
В случае группового программирования прерывание становится еще меньшей про-
блемой; как правило, оно имеет тенденцию вовсе не происходить, поскольку все
работают вместе. А когда происходит, тот, кого отвлекли, просто отходит в сторону,
а остальные продолжают работать.
Если парное и групповое программирование
для вас не вариант, то вашей команде понадобит- См. также
ся заключить рабочие соглашения относительно
прерываний работы, требующей глубокой со- Согласование (глава 7)
средоточенности. Один из вариантов — выбрать
какой-либо показатель (например, наушники при личном общении или специаль-
ный статус в программе при виртуальном), который будет означать «пожалуйста,
не отвлекайте». Но все же не забывайте, цель — повысить продуктивность команды,
а не отдельных лиц.
Легко входите в дискуссии и выходите из них

Общая командная комната позволяет вам тратить меньше времени на встречи. Когда
вам нужно обсудить проблему с другими людьми в команде, не организуйте собрание,
просто скажите на всю комнату, что вы хотите обсудить. Или встаньте и скажите что-
либо (если все находятся в одной комнате), или отправьте сообщение в групповой
чат (при виртуальном общении). Затем просто начните разговаривать друг с другом.
В каждое обсуждение должны вовлекаться только те, кого непосредственно касается
этот вопрос, и его надо завершать сразу, когда проблема решена. Если оказывается,
что в обсуждении нужен кто-то еще из команды, то попросите его присоединиться.
Когда кто-то начинает разговор, вам не обязательно сразу в нем участвовать.
Подслушайте, о чем речь, и решите, нужно ли что-либо от вас. Так, если оказывается,
что дискуссия не имеет к вам отношения, то не нужно в ней участвовать. Вы можете
вернуться к работе. Это называется «закон мобильности», или «закон двух ног» (Law
of Mobility, или Law of Two Feet): «В любой момент времени, если вы не учитесь
чему-то важному и не вносите какой-либо вклад в общее дело, переместитесь в то
место, где вы будете это делать»1. И наоборот! Если оказывается, что обсуждение
имеет к вам отношение, то присоединитесь к нему.
1
Закон мобильности, или закон двух ног, пришел из «Технологий открытого пространства»
Харрисона Оуэна — прекрасного подхода к организации продуктивных дискуссий в больших
группах.
В физическом помещении вежливость предписывает общаться в стороне от того

места, где работают люди, которым нужна концентрация. Большинство командных
комнат имеют специально отведенную отдельную зону для общения. Она находится
достаточно близко к остальной команде, чтобы люди могли слышать разговор и при
желании вступить в него, и при этом достаточно отделена, чтобы шум не отвлекал
других участников.
Виртуальные команды имеют противоположную проблему: трудно услышать
разговоры других людей. Как только разговор начинается, обычно более эффек-
тивно вывести его из группового чата в формат видеоконференции. Но тогда никто
не сможет услышать, о чем разговор. Поэтому рассмотрите возможность время от
времени размещать обновления по текущему обсуждению в групповом чате, чтобы
люди могли решить, нужно ли им вступить в него.
Создавайте визуализации
В момент общения каждый его участник держит в голове собственную модель
окружающего мира. И если ментальные модели слишком сильно различаются, про-
исходит недопонимание.
Чтобы это предотвратить, превратите вашу внутреннюю модель во внешнюю. Соз-
дайте визуализацию, которую каждый сможет увидеть, сравнить с собственной моделью
и изменить. Подойдут рисунки на белой доске, но еще лучше — модели, которые
способствуют сотрудничеству. Отлично работают индексные карточки и стикеры или
их виртуальные эквиваленты. Записывайте ваши идеи на карточках и передвигайте
их, чтобы наглядно представить взаимосвязи.
Вы будете встречать примеры таких визуализа-
ций в этой книге, например визуальное планирова- См. также
ние или практики планирования задач. Не ограничи-
Визуальное планирование
вайтесь визуализациями, описанными здесь. Всякий (глава 8)
раз, когда у вас возникает дискуссия, особенно если
Планирование задач
люди никак не могут понять друг друга или прийти
(глава 9)
к согласию, создавайте модель, которой участники
смогут управлять.
Работайте одновременно
При совместной работе не позволяйте процессу
проходить через узкое место, которым может стать, Не позволяйте процессу
например, единственный специалист. Убедитесь, что проходить через узкое
все могут вносить свой вклад одновременно. Напри- место, которым может стать
мер, при планировании избегайте того, чтобы один единственный специалист.
человек сидел за компьютером и вносил все данные
в электронную систему планирования. Вместо этого визуализируйте план с помощью
индексных карточек или их виртуального эквивалента. Таким образом множество
людей могут писать новые карточки одновременно, менять план (и обсуждать из-
менения), передвигая карточки и указывая на них.
Этот вид одновременной совместной работы невероятно эффективен. Все, что

нужно, — это чтобы человек, который обычно сидит за клавиатурой, отпустил кон-
троль. И как только это происходит, обсуждения значительно ускоряются. В коман-
дах, находящихся в одном помещении, люди естественным образом разделятся на
маленькие группы, чтобы обсуждать темы по интересам. Вы сделаете в два-три раза
больше работы за то же время. Виртуальные группы не увидят столько же преиму-
ществ, поскольку для них сложнее организовать обсуждение в маленьких группах.
Но они все же будут эффективными.
Один из моих любимых способов одновременной работы — одновременный моз-
говой штурм (brainstorming). Кто-то предлагает группе высказывать идеи по обсуж-
даемой теме, совсем как при обычном мозговом штурме. Когда кому-то приходит
на ум идея, он говорит ее вслух, записывает на индексную карточку и помещает ее
туда, где каждый сможет ее видеть. (Одна идея на одной карточке, чтобы облегчить
последующую сортировку.) Высказывание вслух вдохновляет остальных участни-
ков на идеи, а самостоятельная запись идеи на карточку предотвращает задержки,
которые неминуемы, если все записывает один человек.
Помните, что критиковать идеи во время мозгового штурма не нужно. И он
лучше всего работает, когда состоит из двух частей: первая — генерация идей
в свободной форме, где годится все; вторая — уточнение и фильтрация идей.
Иногда я провожу одновременный мозговой штурм, используя сопоставление, или

картирование сходства (affinity mapping). Чтобы сделать карту сходства, возьмите
все карточки, заполненные командой во время мозгового штурма, и разложите их
произвольно на столе или белой доске. Затем переместите их так, чтобы наиболее
похожие идеи оказались рядом друг с другом, а наименее похожие — в отдалении.
Все участники работают одновременно, передвигая карточки, как только видят
нужное направление. В конце концов карточки должны сформировать кластеры,
которым можно дать названия.
Вариантом картирования сходства является молчаливое сопоставление (mute
mapping), которое представляет собой тот же процесс, но никому не разрешается
разговаривать, пока перемещаются карточки. Это помогает предотвратить споры
о том, куда поместить ту или иную карточку, а также приводит к забавным мимиче-
ским взаимодействиям.
Еще один способ фильтрации ваших идей после мозгового штурма — точечное
голосование (dot voting). Каждый имеет определенное количество голосов. (Я ум-
ножаю количество вариантов на три, а затем делю на количество участников.) Все
голосуют одновременно, ставя точку на вариант, который они предпочитают. Можно
голосовать за один вариант несколько раз. Например, если у вас четыре голоса, то
вы можете поставить по одной точке на четыре разных варианта, четыре точки на
один вариант или сделать что-то среднее. Побеждают варианты, получившие наи-
большее количество голосов.
Стремитесь к согласию
Как вы поступаете, когда люди не согласны? Единоличные решения заставляют
людей отстраняться. Правило большинства приводит к разочарованию тех, кто
в меньшинстве. А поиск консенсуса очень долог и может зайти в тупик.
Вместо всего этого используйте голосование согласием (consent vote). При таком
способе голосования кто-то высказывает предложение, и затем все голосуют одним
из следующих способов: «Я согласен» (большой палец вверх при личном общении,
«+1» — в групповом чате), «Я вместе с группой» (большой палец в сторону или «+0»)
или «Я не согласен и хочу объяснить почему» (большой палец вниз или «–1»). Чтобы
избежать случайного давления друг на друга, вы можете договориться, что каждый
раскрывает свой вариант голосования на счет три.
Если никто не выбирает вариант «Я согласен», предложение не принимается из-
за отсутствия интереса. И наоборот, если отсутствуют несогласные, оно проходит.
Если все же кто-то не согласен, то объясняет свои возражения, и группа корректирует
предложение, чтобы устранить их. Предложение не проходит, пока не устранены
все возражения.
Голосование согласием работает по двум причинам. Во-первых, оно дает людям
возможность воздержаться от поддержки, не блокируя предложение полностью.
Во-вторых, если кто-то чувствует себя достаточно сильным, чтобы наложить вето
на предложение, то должен объяснить причины, что позволяет группе разрешить
их сомнения.
Соглашайтесь на эксперимент
Некоторые решения не имеют очевидного ответа или имеют множество одинаково
допустимых вариантов. Обсуждения этих решений легко могут перейти в бесконечные
рассуждения о том, что может пойти не так.
Когда вы замечаете, что дискуссия пере-
ходит в домыслы, предложите конкретный Когда вы замечаете, что дискуссия
эксперимент. Например, в экстремальном переходит в домыслы, предложите
программировании есть правило десяти ми- конкретный эксперимент.
нут: если двое спорят о направлении дизайна
более десяти минут, то они разделяются. Каждый пишет временный код, иллюстри-
рующий идею дизайна, а потом оба сравнивают результаты.
Физические командные комнаты

Командные комнаты могут быть физическими или виртуальными. Если есть такая
возможность, то организуйте физическую комнату. Она обойдется дороже, чем
виртуальная, но, несмотря на успехи технологий, личное общение все же остается
наиболее эффективным способом взаимодействия команд.
Бьорн Фриман-Бенсон, технологический лидер, имеющий многолетний опыт
управления распределенными группами, сказал: «Наши виртуальные команды были
гораздо менее креативными. Нам приходилось комплектовать команды с большей
численностью персонала, чтобы получать тот же уровень креативности… Ключевой
момент любого бизнеса, в котором я был, — это творческий потенциал, в удаленных

командах его меньше из-за разногласий. Вы можете даже получить больше единиц
работы, но тикеты Jira не оплачивают счета» [Shore2019].
Эффект коктейльной вечеринки

Отчасти причина того, что физические командные комнаты более эффективны, за-
ключается в эффекте коктейльной вечеринки, который [Cockburn2006] называет ос-
мотической коммуникацией. Случалось ли вам разговаривать с кем-либо, стоя посреди
переполненной людьми комнаты, и внезапно услышать свое имя? Даже если вы были
сконцентрированы на вашей беседе, ваш мозг прислушивался ко всем остальным раз-
говорам. Услышав ваше имя, он воспроизвел эти звуки в вашем сознании. Вы слышите
не только ваше имя, но и отрывок обсуждения, в котором оно прозвучало.
Представьте себе команду поставки, которая сидит вместе. Члены команды ра-
ботают в парах и ведут тихие разговоры. Потом один из программистов упоминает
что-то насчет управления соединением с базой данных, и другой оживляется: «О, мы
с Кейли на прошлой неделе сделали рефакторинг соединений с базой данных. Больше
не нужно управлять соединениями вручную». Когда членам команды удобно раз-
говаривать таким образом, то это происходит часто (по меньшей мере раз в день)
и всякий раз экономит время и деньги.
Дизайн вашей командной комнаты

Сделайте такой дизайн комнаты для вашей команды, который будет способствовать
взаимодействию. Поставьте прямые столы, позволяющие двум членам команды сидеть
рядом и вместе работать, вместо угловых столов в форме буквы L с монитором в углу.
Поставьте много белых досок и сделайте так, чтобы на стенах можно было рисовать
наброски идей и размещать плакаты с диаграммами. Организуйте зону для общения
с большим столом, который команда сможет использовать для раскладывания кар-
точек и построения визуализаций, и добавьте проектор или большой монитор, если
возможно, для групповых дискуссий, в которых требуется компьютер.
Группируйте людей в соответствии с темами, к обсуждению которых им будет
нужно прислушиваться. Обычно разработчики (программисты, тестировщики,
эксплуатация и т. д.) должны сидеть рядом. Заказчикам в команде не обязательно
находиться рядом, но они должны быть поблизости, чтобы при необходимости от-
вечать на вопросы.
Кроме того, организуйте ваше рабочее пространство таким образом, чтобы ми-
нимизировать отвлекающий шум. Зона общения команды должна быть удалена от
рабочих столов. Рассмотрите возможность организовать отдельную закрытую ком-
нату, предназначенную для телефонных разговоров, особенно если в команде есть
люди, которые много общаются по телефону или на видеоконференциях.
И наконец, уделите внимание человеческому фактору.
Людям комфортнее, когда их рабочее место освещается Уделите внимание
естественным образом, там есть растения и цвета. Оставьте человеческому
пространство для индивидуальности. Если у людей нет фактору.
своих постоянных мест, как это обычно бывает при парном
и групповом программировании, предоставьте им место для хранения личных вещей.

Добавьте книги (например, эту), чтобы их можно было просто полистать или сверить
какую-либо информацию.
Сделайте так, чтобы всю мебель можно было передвинуть, вместо того чтобы
прикручивать ее к полу. Тогда члены команды смогут настроить свое рабочее место
под свои потребности.
Множество команд
Из комнат, где сидят Agile-команды, обычно доносится ровный гул голосов, перио
дически перекрываемый возгласами торжества. Это вряд ли будет мешать членам
вашей команды, но может беспокоить ваших соседей. Убедитесь, что командная
комната хорошо шумоизолирована.
Если командам необходимо часто сотрудничать, то разместите их рядом и дайте
возможность слышать друг друга. Команды, которым взаимодействие не требуется,
можно разделить, используя расстояние или шумозащитные экраны.
Личное оборудование и принадлежности

Оснастите физические помещения ваших команд оборудованием и принадлежностя-
ми, описанными ниже. Многое из этого можно заменить электронными аналогами,
однако лучше потратьтесь на физическое оборудование. Это обойдется не очень до-
рого, но позволит вашим командам использовать преимущества непосредственного
личного взаимодействия. Итак, вам понадобятся:
zz две большие магнитные белые доски для планирования. Мне нравится использо-
вать одну двухстороннюю магнитную доску шесть футов шириной, поставленную
на колесики. Это позволяет командам перемещать свои планы в комнаты для со-
браний. Доска должна быть магнитной, чтобы можно было прикрепить карточки;
zz много дополнительных белых досок, предпочтительно магнитных, для обсужде-
ний и диаграмм;
zz большой пластиковый вечный календарь (на три месяца и больше), чтобы по-
мечать важные даты;
zz звукопоглощающие перегородки, чтобы отделить командное пространство и не
допустить шумовых помех, или дополнительная закрытая командная комната;
zz стулья или что-то иное, на чем кто-либо может временно посидеть;
zz блокноты или портативные белые доски, позволяющие сидя зарисовать набросок
идеи;
zz разнообразные игрушки или другие предметы, вдохновляющие на дискуссии
и взаимодействие в команде;
zz бумага для флипчарта, один-два мольберта для флипчарта и что-нибудь, что позво-
лит прикреплять листы из флипчарта на стену (клейкая лента, кнопки, булавки);
zz разноцветные индексные карточки (не менее 2000 штук каждого цвета). Убедитесь,
что каждый в команде различает цвета1;
1
Один из восьми человек имеет ту или иную форму дальтонизма.
zz стикеры разного цвета, размера и формы;

zz карандаши, ручки и маркеры на водной основе для рисования на карточках
и стикерах. Избегайте перманентных маркеров; они сильно пахнут, и к тому же
кто-нибудь неизбежно испачкает ими белую доску1;
zz маркеры сухого стирания для белой доски, маркеры на водной основе для флип-
чарта и маркеры влажного стирания для полуперманентных надписей на белой
доске, а также вечный календарь. Избегайте сильно пахнущих маркеров;
zz магнитные кнопки для прикрепления карточек и документов к доске;
zz экземпляр этой книги и другие полезные справочные материалы.
Командам, работающим в парном программировании в режиме личного общения,
также понадобятся специальные рабочие станции (см. раздел «Парное программи-
рование» главы 12):
zz широкие столы, подходящие для работы бок о бок. Некоторые команды пред-
почитают иметь или оба варианта столов (столы для работы сидя и стоя), или
столы с изменяемой высотой;
zz один компьютер уровня разработки для каждой рабочей станции;
zz две клавиатуры и мыши на каждой станции. Некоторые предпочитают исполь-
зовать свои клавиатуры и мыши; в этом случае удостоверьтесь, что USB-порты
легкодоступны, поскольку каждый компьютер будут перемещать между станциями
несколько раз в день;
zz не менее двух мониторов на каждой станции.
Командам, работающим в групповом программировании в режиме личного
общения, тоже понадобятся специальные рабочие станции (см. раздел «Групповое
программирование» главы 12):
zz столы, за которыми поместятся каждый член команды и несколько гостей, и про-
странство, достаточное для того, чтобы люди могли меняться местами;
zz кресло «водителя» — с удобным доступом, мышью, клавиатурой и компьютером
уровня разработки;
zz кресло «штурмана» — за тем же столом, что и кресло «водителя», или достаточно
близко, чтобы «водитель» и «штурман» могли беспрепятственно общаться;
zz не менее одного монитора, обычно с диагональю от 60 дюймов, достаточно боль-
шого, чтобы его было видно со всех мест. Телевизоры с разрешением 4K тоже
вполне пригодны для этой цели. Убедитесь, что всех все устраивает с учетом
разницы в зрении.
Не покупайте программное обеспечение для
управления жизненным циклом Agile или другие Не покупайте программное
системы отслеживания, если команда не про- обеспечение для управления
сит именно его, и даже если просит, подождите, жизненным циклом Agile.
пока члены команды сначала наберутся опыта,
1
Профессиональный совет: следы от перманентного маркера на белой доске можно удалять, рисуя
поверх него маркером для белой доски и немедленно стирая.
несколько месяцев работая с практиками планирования, представленными в этой

книге. Больше информации можно найти в подразделе «Корпоративные системы
отслеживания» главы 10.
Примеры командных помещений

Схема рабочего пространства, представленная на рис. 7.1, основана на командных
помещениях, которые я видел в штаб-квартире Spotify в 2015 году. Каждое помещение
имело рабочую зону со множеством белых досок, зону для общения и комнату для част-
ных разговоров, вмещающую от трех до пяти человек. За пределами помещения был
широкий коридор с уютными диванами и креслами и вешалка для верхней одежды.
Рис. 7.1. План командного помещения, вдохновленный Spotify
Командные помещения Spotify были лучшими из тех, что я видел, но, по словам
людей, с которыми я разговаривал, и они имели ряд недостатков. Перегородка
между рабочими комнатами команды и коридором изначально должна была быть
стеклянной, но вместо этого ее сделали своего рода сетью (видимо, вследствие
требований пожарной безопасности), из-за чего шум разговоров в коридоре мешал
команде. Кроме того, планировке комнат не хватало гибкости: Spotify имел комнаты
разного размера для команд разной численности, но людям не нравилось переезжать
из комнаты в комнату, когда команды увеличивались или, наоборот, уменьшались.
Рабочее пространство на рис. 7.2 основывается на комнате, созданной одним пер-
спективным стартапом, когда они переехали в новый офис. У них не было средств
на шикарное рабочее пространство, поэтому им пришлось обходиться тем, что име-
лось. Они поставили пять рабочих станций для парного программирования вдоль
длинной стены с окнами. Два стола были высокими для работы стоя, а оставшиеся
три были переделаны из сегментов круглого стола для переговоров. Второй круглый
стол для переговоров использовался для группового общения. Пространство было
разграничено перегородками с белыми досками. В распоряжении членов команды
была небольшая группа кабин в стороне, и вдобавок неподалеку имелись комнаты

для переговоров, которые можно было использовать для частных бесед.
Рис. 7.2. План бюджетного командного помещения
Это было отличное пространство с одним серьезным недостатком: перегородкой

между программистами и продакт-менеджером. (На рисунке я ее удалил.) В резуль-
тате продакт-менеджер сидел снаружи комнаты и не мог слышать членов команды
и участвовать в общих дискуссиях. Команда не получала своевременных ответов на
вопросы и часто имела проблемы с требованиями по продукту.
Адаптация к физической командной комнате

Многие люди могут сопротивляться переезду в общую командную комнату. Они
обычно опасаются потерять индивидуальность и приватность, предполагаемого
понижения статуса из-за потери собственного кабинета и того, что руководители
не будут замечать индивидуального вклада.
По моему опыту, большинство людей начинает получать удовольствие от пре-
имуществ, которые дает совместная работа в одном помещении, однако на это может
уйти несколько месяцев. Некоторые команды, с которыми я работал, зарезервиро-
вали для себя много индивидуального свободного места в командных комнатах,
но, в конце концов, так его и не использовали. Тематическое исследование Тизли
продемонстрировало похожие результаты: члены команды сначала предпочитали
офисы-кабинки с перегородками, но в конце эксперимента им уже больше нравилось
открытое рабочее пространство.
Однако заставлять людей сидеть вместе в надежде, что им это когда-нибудь
понравится, — плохая идея. Вместо этого поговорите с командой об их опасениях
и компромиссах переезда в общее помещение. Обсудите, как работа членов команды
будет оцениваться в среде Agile (это должно улучшить вклад команды, см. врезку
«Коллективное владение» в главе 9) и как обеспечить приватность.
Один менеджер, с которым я разговаривал, организовал командную комнату,

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

Если ваша команда работает удаленно, то вы можете организовать виртуальную
комнату с помощью онлайн-инструментов. Это возможно и в случае гибридных
и частично удаленных команд1, но будьте осторожны: люди, работающие удаленно,
не смогут принять участие в личном общении.
Тем, кто работает в офисе, тоже нужна виртуальная командная комната, чтобы
взаимодействовать с коллегами, работающими удаленно. Решение использовать
виртуальное рабочее пространство эквивалентно решению действовать так, будто
все работают удаленно.
Оборудование и инструменты для удаленной работы

Удаленным командам нужна электронная версия командного рабочего простран-
ства:
zz ПО для видеоконференций, такое как Zoom, для общения в реальном времени;
zz ПО для обмена сообщениями (мессенджер), например Slack;
zz виртуальная белая доска, например Miro или Mural, для простого взаимодействия
в свободной форме;
zz инструменты для конкретных задач, где это возможно, в версиях для совместного
использования, такие как Figma для UX- и UI-дизайна;
zz хранилище для документации, например DropBox, Google Drive или Вики;
zz недорогие планшеты для использования в качестве доски, на которой можно со-
вместно рисовать наброски;
zz дополнительный монитор или планшет для видеоконференций, чтобы люди могли
видеть друг друга и одновременно работать;
zz для команд поставки инструменты для совместного программирования, напри-
мер Tuple или Visual Studio Live Share, с поддержкой парного или группового
программирования (более подробную информацию см. в разделах «Парное про-
граммирование» и «Групповое программирование» главы 12).
Как и в случае офисного рабочего пространства, не покупайте ПО для управления
жизненным циклом Agile или другие системы отслеживания.
1
Гибридно-удаленная команда в одни дни работает в режиме личного общения, а в другие —
в удаленном режиме. В частично удаленной команде часть людей работает в офисе, а часть —
удаленно.
Организация удаленного взаимодействия

Взаимодействие не вызывает трудностей, когда
люди сидят все вместе. Достижение такого же См. также
уровня взаимодействия при удаленной работе
требует тщательной проработки. Когда ваша ко- Согласование (глава 7)
манда устанавливает свои рабочие соглашения
в ходе начального согласования, обязательно обсудите, как вы будете сотрудничать.
Помните, что цель — максимизировать продуктивность команды, а не отдельного
человека. В процессе работы не забывайте чаще оценивать и совершенствовать ваши
методы общения.
Я просил людей, имеющих опыт работы с офисными и удаленными командами,
поделиться приемами удаленного взаимодействия1. Вот несколько отличных советов.
zz Находите время для личных контактов. Команды, общающиеся лично, формируют
дружеские связи и взаимное уважение, и это позволяет им принимать решения
быстро и эффективно. Виртуальным командам будет полезно выделять время на
общение и интересоваться жизнью друг друга. Примеры — виртуальные перерывы
на кофе, которые помогают снизить напряженность в общении; отдельные чаты
и каналы для приветствий по приходе и выходе из офиса и личных сообщений;
а также 30-минутные ежедневные звонки для неформального общения или игр.
Одна из команд выработала привычку выделять первые 5–10 минут каждой встре-
чи на неформальное общение; люди могли либо приходить пораньше и общаться,
либо приходить позже, непосредственно к деловой части встречи, по настроению.
Другая команда специально выделяла время для празднования успехов.
zz Обеспечьте безопасность. В командах, общающихся лично, люди могут шутить
и быть самими собой, не опасаясь, что кто-то когда-либо припомнит им это.
В виртуальной среде все может быть записано. Установите четкие рекомендации
о том, когда можно записывать разговор и распространять запись. Еще один способ
создать атмосферу безопасности — открыть приватный канал в вашем групповом
чате, доступный только команде.
zz Сделайте неявное явным. При личном общении многие социальные сигналы
подаются с помощью малозаметных изменений выражения лица и языка тела.
При виртуальном общении эти сигналы обычно не видны. Поэтому сделайте их
явными. Например, один человек сделал индексные карточки, которые он держал
во время видеозвонков. На них было написано «+1», «Обеспокоен», «+1 000 000»
и «Да-а-а-а! Сделаем это!» (Пусть это будет весело!) Кроме того, демонстрируйте,
что вы доступны для общения. Ставьте в групповом чате статус, оповещающий
о том, где вы, что делаете и открыты ли для разговора.
zz Обновите вашу среду общения. Низкоскоростная связь (например, текстовый чат)
пригодна для коротких обменов информацией, но может приводить к длинным
и долгим перепискам, когда надо обсудить значимые вопросы. Если вы заметили,
1
Спасибо Дэйву Пулу, Габриель Хокнесс, Александру Берду, Крису Фентону, Брайану Шефу
и Дэйву Руни за то, что поделились своими приемами в Twitter (https://oreil.ly/vwWli). Кроме
того, спасибо Бренту Миллеру, Дэннису Макмиллану, Сету Маккарти, Джеффу Олферту, Матту
Плавкану за их советы.
что это происходит, переключитесь на более скоростные варианты связи. Напри-

мер, одна команда установила стандарт, предусматривающий переход на видео,
если тему в групповом чате команды обсуждали больше двух человек.
zz Используйте функции одновременного общения в параллельных группах. Когда
группы одновременно работают над визуализацией, они часто разделяются на
дискуссионные группы численностью два-три человека. Придумайте, как орга-
низовать нечто подобное с помощью ваших программных инструментов. В ПО
для видеоконференций можно открывать комнаты отдыха, а приложения для
групповых чатов поддерживают создание отдельных каналов и чатов.
zz Создайте «стену». В офисе информация, которую необходимо узнать или пом-
нить, вывешивается на стене. Для виртуальных команд можно создать небольшое
количество общих документов, в которых будет храниться та же информация.
zz Купите планшеты. Стоят они не очень дорого, а рисовать диаграммы на планшете
гораздо удобнее, чем с помощью мыши или сенсорной панели. Раздайте планшеты
всем членам вашей команды и держите их подключенными к вашей виртуальной
белой доске. Когда вам понадобится зарисовать что-то во время обсуждения,
планшеты будут наготове.
zz Учитывайте разницу в доступе к Интернету. Он у всех разный. Расстояние всего
в 10 миль может означать переход от широкополосного городского доступа к не-
равномерному сельскому покрытию, не говоря уже о разнице между странами.
Обсудите потребности людей и выберите коммуникационные стратегии, под-
ходящие каждому.
Младшие члены команды

Бьерн Фриман-Бенсон описывает проблему младших членов команды (джуниоров)
как один из трех вызовов распределенных команд:
У начинающих разработчиков очень много вопросов. Они не знают, как делать
свою работу. И в то же время они находятся на низшей ступени иерархии. Они
не решаются перебивать и не хотят выглядеть обузой.
В InVision [где Бьерн был техническим директором], все команды которой
были полностью удаленными, джуниор-разработчики не могли видеть, что
делают все остальные. Они боялись прервать других. «Они замирали и тянули
время, — говорил Бьерн, — до самого последнего момента, пока их напрямую
не спрашивали, чем они заняты» [Shore2019].
Бьерн Фриман-Бенсон.
Три проблемы распределенных команд
Организуйте способы, которые по-

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

наставничества или других способов, которые не дадут обделить младших членов
команды вниманием.
Вопросы
В физической комнате моей команды слишком шумно, я не могу сосредоточиться.
Что мне делать?
Иногда команда становится чрезмерно шумной
и непоседливой. И это нормально — попросить вести См. также
себя потише. Когда вы обсуждаете рабочие соглаше-
ния при начальном согласовании, поговорите о том, Согласование (глава 7)
как удовлетворить пожелания каждого. Если этого Ретроспективы (глава 11)
будет недостаточно, поднимайте этот вопрос также
во время ретроспектив.
Помните, что парное программирование — отличный способ отвлечь ваше вни-
мание от фонового шума. Вы просто не заметите этот шум, разговаривая с вашим
партнером. Точно так же эта проблема не свойственна и групповому программиро-
ванию за счет фокусировки общего внимания на одной общей теме.
Когда начинается разговор, вся команда перестает делать то, что делала,
и начинает слушать. Что мы можем сделать, чтобы люди перестали так легко
отвлекаться?
Возможно, всей команде действительно нужно слышать эти разговоры, особенно
в самом начале. Это помогает установить контакт и привести всех к общему по-
ниманию. Со временем команды разберутся, какие разговоры можно с легкостью
игнорировать.
Если проблема продолжается, особенно в физической рабочей комнате, то попро-
буйте отходить немного подальше от остальных коллег, когда начинается разговор.
Заинтересованные члены команды сами присоединятся к обсуждению, в то время
как остальная команда продолжит работу.
Членам команды приходится проводить вместе несколько основных часов, чтобы
эффективно сотрудничать, даже если они работают удаленно. Если они настолько
широко разбросаны по часовым поясам, что общее время невозможно подобрать,
то у вас на самом деле несколько команд и вам нужно спланировать работу соот-
ветствующим образом. (В главе 6 представлена более подробная информация о том,
как масштабироваться до нескольких Agile-команд.)
Самое сложное — организовать пространство физической командной комнаты.
Обычно требуются согласование с административно-хозяйственным отделом и под-
держка руководства. На это могут потребоваться недели, а то и месяцы, поэтому
начинайте организацию рабочего пространства как можно раньше.
Вдобавок к получению поддержки руководства и административно-хозяйствен-
ного отдела убедитесь как можно раньше, что члены команды согласны работать
в общей комнате. Многие люди могут тяжело воспринимать изменение рабочего

пространства. Если их вынуждают перейти на новый порядок против их воли, то
они, вероятно, найдут способ уйти из команды, даже если это равнозначно уходу из
компании. Больше информации о том,
как заручиться поддержкой, доступно
в главе 5. См. также
Если ваша команда не использует
Парное программирование (глава 12)
парное или групповое программирова-
ние, то уделите внимание организации Групповое программирование (глава 12)
рабочего пространства и рабочих со- Согласование (глава 7)
глашений, чтобы минимизировать шум
и отвлекающие факторы.
Когда у вас хорошая командная комната:
zz члены команды взаимодействуют быстро и эффективно;
zz вы знаете, когда люди работают над проблемами, в решение которых вы можете
внести свой вклад, и они будут рады, если вы присоединитесь к дискуссии;
zz вам не нужно угадывать ответ. Если кто-либо в команде его знает, вы можете
спросить у него и получить быстрый ответ;
zz члены команды самостоятельно формируют кросс-функциональные группы для
решения проблем;
zz в команде царит атмосфера товарищества и взаимного уважения.
Эта практика предназначена для беспрепятственного общения, и неважно, есть у вас
буквально командная комната или нет. Но если у вас нет опыта непринужденного
взаимодействия в пространстве такой комнаты (особенно физической), то попро-
буйте подобное общение в течение нескольких месяцев, прежде чем перейти к экс-
периментам с альтернативами. Трудно оценить, насколько это эффективно, пока
не увидишь своими глазами.
Группповое программирование еще
больше расширяет возможности сотруд- См. также
ничества, поскольку все члены команды
работают за одним компьютером. Воз- Групповое программирование (глава 12)
можно, это звучит странно, но в некото-
ром смысле это «простой режим» совместной работы. Он особенно эффективен для
команд, работающих удаленно, которым иначе пришлось бы очень постараться, прежде
чем они добились бы той же эффективности, что и команды, работающие в офисе.
Пожалуй, помимо группового программирования, больше ничто не приближа-
ется по эффективности к центральной идее общего рабочего пространства. Экспе-
риментировать можно с деталями. Как вы можете улучшить общение? Можно ли
трансформировать регулярные плановые собрания в непрерывное взаимодействие

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

В книге Agile Software Development [Cockburn2006] есть отличная глава, посвящен-
ная общению. В главе 3 Communicating, Cooperating Teams обсуждаются источники
информации, качество коммуникации и множество других концепций, связанных
с использованием общих командных комнат.
The Remote Facilitator’s Pocket Guide [Clacey2020] содержит краткий и полезный
материал о фасилитации. Книга в большей степени ориентирована на удаленные
сессии, но советы, представленные в ней, будут ценны и для людей, работающих
в формате личного общения.
БЕЗОПАСНОСТЬ Аудитория
Гитте Клитгаард Вся команда
Мы без страха делимся противоречивыми точ-
ками зрения.
В 2012 году Google запустил проект «Аристотель» — внутреннее исследование,

призванное определить, почему одни команды достигали успеха, а другие нет. Google
учитывал несколько факторов: состав команды, общение вне работы, образование,
являются ли члены команды экстравертами или интровертами, работают в офисе или
удаленно, трудовой стаж, численность команды, индивидуальная продуктивность
и др. Ничто из перечисленного не оказывало значительного влияния на эффектив-
ность, даже стаж и индивидуальная продуктивность.
А что имело значение? Психологическая безопасность.
Из пяти ключевых показателей динамики эффективных команд, обнаруженных
исследователями, психологическая безопасность была, безусловно, самой важ-
ной. Исследователи Google обнаружили, что люди в команде, имеющей более
высокую психологическую безопасность, с меньшей вероятностью уходили из
компании, с большей вероятностью использовали потенциал разнообразных
идей своих коллег, приносили больший доход и оценивались как эффективные
высшим руководством в два раза чаще [Google2021].
Понятие командной эффективности
Выводы Google сделали психологическую безопасность центром внимания, од-

нако это не новая идея. Она была введена в 1965 году Эдгаром Шейном и Уорреном
Беннисом в контексте проведения личных и организационных изменений. «Для

того чтобы дискомфорт приводил к усилению желания учиться вместо усиления
беспокойства… должна быть создана среда с максимальной психологической без-
опасностью» [Schein 1965, р. 44].
Понятие психологической безопасности

Психологическая безопасность (часто сокращается до слова «безопасность», посколь-
ку вопрос физической безопасности в современных офисах в целом решен) пред-
ставляет собой возможность быть собой, не опасаясь негативных последствий для
своей карьеры, статуса или имиджа. Это возможность выдвигать идеи, задавать
вопросы, выражать озабоченность и даже совершать ошибки, не подвергаясь за это
наказанию или унижению1.
Безопасность не означает, что в вашей
команде отсутствуют конфликты. Она озна Безопасность означает, что члены
чает как раз обратное: каждый в команде команды могут не соглашаться друг
имеет возможность высказать свое мнение, с другом и это для них безопасно.
не боясь возмездия или унижения. Люди
чувствуют, что могут не соглашаться друг с другом и это для них безопасно. И они
это делают. Это может быть некомфортно, но все же это безопасно.
Такая творческая напряженность позволяет рассматривать все идеи, многие
из которых при других обстоятельствах могли бы быть забыты. Люди принимают
во внимание возражения, от которых иначе просто бы отмахнулись. В результате
каждый высказывает свою точку зрения, и это помогает достигать лучших резуль-
татов.
Как создать атмосферу безопасности

Чувство безопасности очень индивидуально. Оно нематериально и зависит от кон-
текста. Обмен информацией, безопасный для одних участников, может казаться не-
безопасным для других. Например, вы начинаете разговор с легкой светской беседы
наподобие: «Чем вы занимались в выходные?» Один человек уверенно отвечает:
«Я ходил в горы с женой». Другому не очень хочется отвечать. Он провел выходные
со своим бойфрендом и беспокоится, что если поднимет эту тему, то пойдут непри-
ятные разговоры о его сексуальной ориентации.
Прежний опыт — тоже важный фактор. Я (Гитте) работала с 60-летним человеком,
который всегда избегал упоминания пола своего мужа. Он говорил «мой партнер»
вместо «мой муж» и никогда не использовал местоимения. Разумом этот человек
понимал, что тема его отношений не вызывает у меня дискомфорта, и я никогда
не обращалась с ним плохо, но он вырос в то время, когда быть геем было наказуемо,
и инстинктивно старался себя защитить.
1
Первая половина этого определения психологической безопасности («возможность быть со-
бой») основывается на [Kahn1990]. Вторая половина («возможность выдвигать идеи») — на
[Edmonson2014].
Человеческие личности, нейроразнообразие в команде и другие различия в образе

мышления людей тоже играют свою роль. Означает ли это, что безопасность невоз-
можна? Вовсе нет! Но это значит, что волшебного решения не существует. Вы можете
все делать правильно, но люди все равно не будут чувствовать себя в безопасности.
Вы не можете заставить их испытывать это чувство. Вы можете только создать об-
становку, где безопасность возможна, и обсудить эту тему, чтобы разобраться, что
безопасность означает для членов вашей команды.
Техники, представленные в этой главе, помогут вам создать атмосферу безопасности.
Дать возможность высказаться всем

Одно из больших преимуществ безопасности — то, что она дает возможность вы-
сказаться каждому. Чувствуя себя в безопасности, члены команды озвучивают свое
мнение, не соглашаются, предлагают новые идеи, поднимают проблемы и в целом от-
крывают возможности. Это не значит, что все идеи претворяются в жизнь. Это значит,
что ваша команда рассмотрела больше вариантов, прежде чем приняла решение, —
вариантов, которые вы иначе бы не увидели.
Даже если люди чувствуют себя настолько безопасно, чтобы высказаться, неко-
торые от природы застенчивы, испытывают социальную тревожность или им просто
некомфортно высказываться в группе. Вы можете облегчить им задачу, приняв эти
особенности во внимание.
Один из способов — начинать каждое собрание с краткого вступления. Оно мо-
жет быть совсем небольшим, например: «Выразите одним словом ваше настроение
сегодня» или «Расскажите, какая погода сегодня за вашим окном». Когда человек
один раз уже сказал что-либо на собрании, ему легче заговорить еще раз позже.
Кроме того, дайте возможность пропустить участие. Это покажет всем, что не вы-
сказываться тоже безопасно.
Еще один способ — разделить большую дискуссию по маленьким группам
в 2–4 человека. Один человек из каждой группы может поделиться выводами, сде-
ланными группой, с остальными. Это даст возможность учесть мнения тех, кому
некомфортно высказываться в условиях большой группы.
Открыто говорите об ошибках

Когда мы совершаем ошибку, легко начать себя защищать, особенно если мы до-
пустили оплошность. Сопротивляйтесь желанию проигнорировать или прикрыть
свои ошибки. Вместо этого признайте их. Вы покажете остальным, что для них тоже
безопасно признавать свои ошибки.
У Мэтта Смита есть техника, называющаяся «Поклон неудачи» (the failure bow)
[Smith2012]. Лучше всего она работает, когда становится общей нормой в команде.
Когда вы сделаете ошибку, встаньте, вытяните руки высоко вверх. «Я ошибся!» —
скажите это, широко улыбаясь. Остальные тоже начнут улыбаться и, может быть,
даже аплодировать. Превратите ошибку во что-то смешное. Это ее обезвредит.
Некоторым трудно признавать ошибки. Человек может винить себя в ошибке,
думать, что команда будет его ненавидеть и его уволят. Я и сама так думала, когда
исцелялась от перфекционизма.
Другими словами, вы можете создать среду, в которой безопасно говорить

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

В эффективной команде разногласия и противоречивые мнения — это не только
нормально, но и ожидаемо. Именно так возникают лучшие идеи. Сделайте раз-
ногласия безопасными, сосредоточившись на предметах и идеях, а не на людях, их
предлагающих. Используйте старый прием импровизации: каждый раз говорите «да,
и…», чтобы развить чужую идею.
Например, если кто-то предлагает поправки в коде, но не учел вопрос обработки
ошибок, не говорите: «Ты забыл добавить обработку ошибок». Это перемещает фо-
кус на человека и на то, что он забыл сделать. Вместо этого сфокусируйтесь на идее
и развивайте ее: «Куда мы добавим обработку ошибок?» Или: «Давайте добавим
сюда обработку ошибок».
Некоторые разногласия могут носить личный характер. Например, кто-то может
неудачно и довольно бесчувственно пошутить. Диана Ларсен предлагает следующий
процесс обратной связи по межличностным вопросам.
1. Создайте открытость. Попросите разрешения дать обратную связь: «Жоржетта,
могу я поговорить с тобой о том, что ты сказала сегодня во время стендап-
митинга?»
2. Опишите поведение. Будьте конкретны насчет того, что случилось: «Сегодня во
время стендап-митинга ты пошутила, что люди низкого роста не ходят на свида-
ния. Это была твоя третья шутка на эту тему на текущей неделе».
3. Заявите о последствиях. Опишите, как это повлияло на вас: «Тема моего роста
для меня чувствительна, и, хотя я и посмеялся, у меня все утро было плохое на-
строение».
4. Сформулируйте запрос. Объясните, что бы вы хотели изменить, поощрить или
предотвратить: «Я бы хотел, чтобы ты перестала шутить на эту тему».
5. Выслушайте ответ. Другой человек ответит. Выслушайте, чтобы понять, и дайте

ему закончить мысль.
6. Обсудите следующие шаги. Сосредоточьтесь на том, что вы оба можете сделать,
с учетом выстраивания отношений в дальнейшем. «Мне нравится твое чувство
юмора, и я надеюсь, ты будешь продолжать шутить на другие темы. Я работаю над
тем, чтобы быть менее чувствительным к этому вопросу, но это непросто. Я ценю
то, что ты согласна сделать это для меня».
Давайте обратную связь, чтобы поощрить поведение, которое вы хотите видеть,
а также чтобы исправить поведение, которое вы хотите изменить.
Людям может понадобиться несколько дней, чтобы переварить обратную связь,
особенно если это что-то серьезное. Не ждите ответа сразу. Многим также трудно
получать положительную обратную связь. Мне самой понадобилось несколько лет
сознательных тренировок, прежде чем я научилась с благодарностью принимать
положительную обратную связь, и у меня до сих пор бывают с этим проблемы
в плохие дни.
Получать личную обратную связь может быть особенно некомфортно, если вы
сделали что-то, что задело чувства другого человека. Когда такое случается, не за-
нимайте оборонительную позицию и не преуменьшайте опасения другого человека.
Не извиняйтесь в манере: «Мне жаль, что ты почувствовал себя обиженным». Вместо
этого признайте свою ошибку и попытайтесь загладить вину: «Я не хотел обидеть
тебя своими шутками, но обидел. Я прошу прощения. Впредь я буду избегать по-
добных шуток. Пожалуйста, напомни мне, если я снова сделаю так».
Подумайте над заключением рабочего соглашения о том, как давать и получать
личную обратную связь. Некоторые советы можно найти в пункте «Разумные кон-
фликты с обратной связью» главы 11.
Используйте эмпатию
Люди подвержены фундаментальной ошибке атрибуции: мы склонны думать, что
люди делают что-то из-за своих личных качеств, а не из-за ситуации, в которой
оказались. Например, если мы подрезали кого-то на шоссе, это потому, что мы чуть
не проскочили свой поворот. Если нас подрезал кто-то другой, это потому, что он
плохой водитель и не уважает других.
Когда вы не согласны с кем-то, поставьте
себя на его место. Вместо того чтобы подо- Когда вы не согласны с кем-то,
зревать злонамеренность или некомпетент- предположите, что у него добрые
ность, предположите добрые намерения: намерения.
человек такой же умный и имеет благие
намерения, как и вы, просто пришел к другому выводу. Попробуйте понять его по-
зицию и причины, по которым его вывод отличается от вашего.
Вы можете развить в себе эмпатию, разыгрывая разногласие по ролям постфак-
тум. Попросите кого-нибудь послушать, как вы будете объяснять это разногласие.
Объясните с вашей точки зрения, а потом с точки зрения оппонента. Приведите
лучший, наиболее разумный аргумент для его позиции.
Agile Conversations [Squirrel2020] — отличный ресурс, который позволит начать
понимать последствия разговоров и научиться быть более эффективными.
Позвольте себе быть уязвимым

Делитесь личным и позволяйте людям видеть ваши уязвимости. Можно начать
с малого: хобби, любимая игрушка в детстве или домашнее животное. Это укрепля-
ет отношения и доверие. Со временем, когда вы дорастете до того, чтобы доверять
вашим товарищам по команде, вы можете открыться еще больше.
Люди приходят на работу вместе со всей своей индивидуальностью. Другими сло-
вами, то, что происходит дома, влияет на нас и на работе, так же как и все остальное,
что делает нас такими, какие мы есть. Проводя вместе и хорошие, и плохие дни, люди
начинают понимать настроение друг друга, что создает безопасность. Например, если
вы не выспались, то можете быть ворчливым. Если вы поделитесь с окружающими
этой информацией, то поможете им понять, что это не они вас раздражают… вы про-
сто сегодня ворчливы.
В 2007 году я проходила обследование на рак матки. Я паниковала и плакала
и рассказала об этом в своей команде. Это было очень некомфортно, но безопасно.
Когда пришло время идти к врачу на обследование, трое из моей команды позвони-
ли мне, чтобы убедиться, что меня есть кому проводить на прием. Они знали, что
я живу одна, и поддерживали меня. Это было чудесное ощущение. (В конечном счете
пришли отрицательные результаты анализа — рака не было.)
Организационная безопасность
Мой опыт помощи компаниям в построении безопасности во всей организации
заключается в том, что если безопасность отсутствует с самого начала, то нужно
начинать с малого. Чувство безопасности — внутреннее, оно может быть чем-то,
что человек испытывает только с одним-двумя людьми. Кроме того, нормально
чувствовать себя в безопасности только в своей команде. Если организация
озаботится безопасностью, то может совершить прорыв и люди начнут испы-
тывать чувство безопасности сначала в своем отделе, а затем, наконец, во всей
компании.
Роль лидера
Люди, находящиеся у власти, оказывают огромное влияние на безопасность. Это
могут быть как традиционные источники власти, например начальник отдела или
менеджер, так и неформальные, когда, например, старший разработчик общается
с младшим.
Если вы у власти, то ваши слова и поступки весьма значимы. Относитесь к этому
серьезно. Это значит, что вы не можете высказываться небрежно, как вам, возможно,
хотелось бы, по крайней мере поначалу. Научитесь считывать состояние людей: об-
ратите внимание на то, как ваши слова и поступки действуют на других.
Техники, представленные ниже, помогут вам создать атмосферу безопасности
в ваших командах.
Моделирование поведения, которое вы хотели бы видеть

Демонстрируйте поведение, которое хотели бы видеть у остальных членов вашей
команды. Поощряйте высказывание мнений, будьте открытыми касательно ваших
ошибок, любознательными, давайте обратную связь, проявляйте эмпатию и позво-
ляйте себе быть уязвимым. Недостаточно говорить людям, что они в безопасности,
или считать так. Демонстрируйте это.
При обсуждении ошибок старайтесь не винить других и не брать вину на себя.
Не говорите что-то наподобие: «Ах, я совершил ошибку, я такой глупый». Такое вы-
сказывание формирует мысль, что ошибки — это глупость. Вместо этого придайте
своему сообщению такую форму, что работа — это процесс обучения, где ошибки
ожидаемы, и обучение — часть результата: «Я ошибся, и вот чему меня это научило».
Будьте конкретны касательно своих ожиданий

Agile-команды сами организуют свою работу и управляют ею, но это не значит, что
от них ничего не ждут и не направляют их действия. Четко информируйте, чего вы
ожидаете от своих коллег и что можете сделать, чтобы им помочь. Начинайте встречи
и другие виды активности, например ретроспективы, с четкого обозначения того,
чего вы ждете от данной сессии.
Не уклоняйтесь от конфликта
Безопасность не означает, что люди всегда полу-
чают то, чего хотят. Она подразумевает, что все Безопасность не означает,
мнения принимаются во внимание. что люди всегда получают то,
Пытаясь создать ощущение безопасности, не- чего хотят.
которые команды вместо этого создают ложную
гармонию. Они начинают избегать конфликтов и подавлять инакомыслие. Это может
казаться безопасным, но конфликт никуда не уйдет и будет лишь подспудно расти.
Некоторые лидеры совершают ошибку, поощряя позитивность в своих коман-
дах. Они говорят что-то вроде «не будь таким негативным» или «будь командным
игроком» — подразумевая «иди вместе со всей командой». Таким образом, люди
понимают, что высказывать свое мнение небезопасно.
Вместо этого, если вы заметили, что люди подавляют свое мнение, попросите их
поделиться. Если кажется, что люди потакают ложной гармонии, то спросите их,
какие негативные стороны они видят в какой-либо идее. Если вы видите проблему,
которую никто другой не упомянул, то вынесите ее на обсуждение, но в доброже-
лательной манере.
В то же время будьте готовы ошибаться. Концентрируйтесь не на том, чтобы быть
всегда правым, а на том, чтобы вынести все мнения на открытое обсуждение, в ходе
которого можно их обдумать, оспорить и улучшить.
Ложная гармония и групповое мышление —
обычные проблемы команд, находящихся на См. также
стадии развития, называемой нормализацией.
Больше информации об этом вы найдете в пункте Динамики команды (глава 11)
«Стадия нормализации: мы — № 1» главы 11.
Упражнение на построение взаимоотношений в команде

Это забавное упражнение вы можете использовать для налаживания взаимопони-
мания в вашей команде. Оно хорошо работает как самостоятельное упражнение,
а также может быть частью вашей начальной сессии согласования при разработке
устава проекта (см. раздел «Согласование» далее в этой главе).
Цель этого упражнения — показать членам команды, что у них гораздо больше
общего, чем им кажется. Если вы работаете в общем помещении, то найдите
в офисе большое открытое пространство, в котором можно свободно передви-
гаться. Если команда работает удаленно, то попросите каждого загрузить свое
фото на общую виртуальную белую доску. (Готовьтесь, это будет весело!) Затем,
когда будете готовы, повторяйте шаги, указанные ниже.
1. Один человек делает заявление о себе: «Я люблю собак».
2. Каждый, кто согласен с этим заявлением, подходит и становится рядом с этим
человеком. Удаленные команды передвигают свое фото.
3. Следующий человек делает свое заявление: «Мой любимый язык програм-
мирования — Perl». И т. д.
Продолжайте, пока время не истечет. Люди могут поделиться всем, чем захотят,
многим или немногим.
Вопросы
Что бы я ни делал, один из членов команды не хочет высказываться. Как я могу ему помочь?
Как и со многими командными вопросами, лучшее, что можно сделать для нача-
ла, — это слушать. Поговорите с этим человеком, почему он не хочет высказываться.
Подчеркните, что это не проблема, которую должен решить он. Это проблема команды.
Вы хотите, чтобы ему стало легче вносить свой вклад в общее дело.
Когда будете обсуждать возможности, имейте в виду, что хотя вы и хотите, что-
бы его голос был услышан, это вовсе не обязательно должен быть именно голос.
Некоторым людям удобнее излагать свои мысли в письменном виде, чем делиться
ими спонтанно.
Еще один вариант для такого человека — проговорить свои идеи с приятелем
в команде. Это позволит заранее отрепетировать то, что он хочет сказать, или он
может попросить приятеля представить его точку зрения.
Я видел кое-что и знаю, что это повлияло на одного человека. Но меня беспокоит,
что он не чувствует себя в достаточной безопасности, чтобы рассказать об этом.
Что мне делать?
Это зависит от сложности ситуации и от того, чувствуете ли вы себя в достаточной
безопасности, чтобы действовать самостоятельно.
В большинстве случаев можно начать с разговора с пострадавшим. Спросите,
все ли у него нормально и не хочет ли он обсудить это. Если можете, то предложите
поднять этот вопрос от его имени. Даже если вы не сможете это сделать, ваше пред-
ложение поможет человеку понять, что его замечают и кому-то не все равно.
Если я чувствую, что какое-то событие выходит за рамки, то выскажусь на месте.

Например, представьте, что Вон что-то сказал на собрании, но его проигнорировали.
Обычно я обсудила бы это с Вон после встречи. Но позже на другом собрании Макс
повторил то, что сказал Вон, и на этот раз все услышали. Здесь я вмешаюсь. У меня
есть стандартная фраза для таких ситуаций: «Макс, мне понравилось, как ты пере-
фразировал то, что до этого сказал Вон».
Разве мы не проведем время с большей пользой, занимаясь своей работой, а не
обсуждая свои чувства?
Простые повторяющиеся задачи могут не требовать безопасности, но разработка
ПО требует творчества, обучения и мыслительного процесса. Чтобы достичь наи-
лучших результатов, вашей команде нужны все умы и мнения. Атмосфера небезопас-
ности приведет к тому, что вы потеряете часть идей, люди будут неохотно указывать
на ошибки, а возможности будут упускаться из-за предполагаемого риска.
Вспомните выводы проекта «Аристотель». Безопасность была показателем номер
один производительности команд Google. И даже если это не так, работа — огромная
часть нашей жизни. Разве вы не хотите, чтобы она проходила в обстановке, в которой
вы и ваши коллеги могут выражать себя без страха?
Практически каждая команда может достичь психологической безопасности. В неко
торых компаниях принято подавлять разногласия или искать виноватых, и это может
затруднить обеспечение безопасности. Но вы все же можете организовать островок
безопасности внутри своей команды.
Если у вас удаленная команда, то будьте осторожны при записи разговоров. Если
в команде безопасно и люди могут свободно самовыражаться, то вы же не хотите,
чтобы организация в будущем смогла использовать это против членов команды?
По возможности настройте ваш чат на удаление старых записей и не записывайте
видеозвонки, если на это нет особых причин.
Когда в вашей команде царит атмосфера психологической безопасности:
zz члены команды говорят о своих ошибках и чему они их научили;
zz они конструктивно выражают несогласие;
zz они выносят на общее обсуждение идеи и проблемы;
zz команда создает лучшие продукты, содержащие больше идей;
zz легче нанимать и удерживать людей с разнообразным опытом.
Психологическая безопасность позволяет учиться, делиться знаниями, не соглашать-
ся и высказывать свое мнение. Эта практика помогает найти и упростить способы
изменения вашей окружающей среды.
Альтернатива является попыткой изменить людей, а не окружающую среду. Теоре-

тически вы можете поработать над развитием их смелости, чтобы им было комфортно
высказываться, даже если они не чувствуют себя в безопасности. Но я не рекомендую
этот подход. Люди могут измениться только сами, вы не можете сделать это за них.
Даже если они найдут в себе смелость высказаться, не чувствуя себя в безопасности,
страх будет снижать их креативность.
В то же время эксперимент — отличный способ повысить безопасность. Будьте
конкретны насчет экспериментов, которые проводите: даже планирование экспери-
мента с четкой датой окончания может создать ощущение безопасности, поскольку
люди будут знать, что изменения можно отменить, если результат будет нерабочим.
Создайте культуру проверки новых идей как в отношении безопасности, так и в це-
лом внутри своей команды.
Один из способов начать — проводить ретро-
спективы на тему безопасности. Обсудите, что См. также
вы заметили в отношении безопасности в своей
команде и в других, и выберите несколько экс- Ретроспективы (глава 11)
периментов, которые можно провети.

The Fearless Organization: Creating Psychological Safety in the Workplace for Learning,
Innovation and Growth1 [Edmonson2018] — новая книга Эми Эдмонсон, профессора
Гарвардской школы бизнеса. Это хорошая книга о многих аспектах психологической
безопасности, которую исследовала автор.
Building a Psychologically Safe Workplace [Edmonson2014] — выступление Эми
Эдмонсон на TEDx; легкое, быстрое погружение в тему.
Time to Think: Listening to Ignite the Human Mind [Kline2015] посвящена тому, как
создать пространство и время для размышлений на работе. Книга содержит прак-
тические советы, которые я использую на большинстве встреч.
ЦЕЛЬ
Аудитория
Мы понимаем, ради чего работаем.
Продакт-менеджеры, коучи
У каждой команды есть цель: причина суще-
ствования команды и ожидания от результатов ее работы. Но слишком часто команде
эту цель не озвучивают. Вместо этого членам команды сообщают много подробностей
о том, что им нужно делать… но не почему им надо это делать или как это поможет
компании достичь ее целей.
1
Эдмонсон Э. Работа без страха. Как создать в компании психологически безопасную среду для
максимальной командной эффективности.
В практике «Цель» объясняется, как сделать так, чтобы каждый понимал общую
картину, а не только детали.
Начните с ви́дения
Прежде чем у продукта появляется команда, у кого-то в компании рождается идея.
Предположим, это некто в компании Wizzle-Frobitz (выдуманное название).
«Эй! — восклицает он (или она), в порыве воодушевления смахивая свой кофе со
стола. — Мы могли бы frobitz наши wizzle намного лучше, если бы у нас было ПО,
которое сначала сортировало бы wizzle!»
Как правило, обычно это происходит не так драматично. Основная мысль в том,
что цель команды начинается как идея, ориентированная на результат. Продавать
больше «железа», комплектуя его лучшим ПО. Привлекать более крупных заказ-
чиков, более эффективно масштабируя. Продавать больше облачных сервисов,
предоставляя технологию машинного обучения. Это все реальные примеры команд,
с которыми я работал.
Где-то в процессе перехода от идеи к команде часто теряется важная часть — ви́де
ние лучшего будущего. Его загораживают детали. Вам нужно укомплектовать коман-
ду программистами, экспертами в предметной области и UX-дизайнерами. Вам
нужно определиться с функциональностью, запланировать релизы и отчитываться
о прогрессе. Быстрее, народ, поторапливайтесь!
И это позор, поскольку нет ничего важнее, чем
предоставить ви́дение. Если цель — продать боль- Нет ничего важнее, чем
ше облачных сервисов с помощью машинного обу- предоставить ви́дение.
чения, то даже самый лучший продукт машинного
обучения недостаточно хорош, если он не является частью облачной платформы.
Если вы производите масштабирование с целью привлечь более крупного заказчика,
то вам нужно убедиться, что выбранный вами способ масштабирования подходит
для его потребностей. И наоборот, если вы ищете способ привлечь заказчиков,
для которых вряд ли вообще требуется масштабирование, то какая разница, как
вы его сделали?
Идентифицируйте цель
Деньги для вашей команды приходят из чьего-то бюджета. Этих людей обычно на-
зывают исполнительными спонсорами команды. Технически у спонсора решающее
слово в отношении цели команды, однако на самом деле все не так просто. На спон-
соров влияет множество людей, называемых ключевыми стейкхолдерами, поддержка
которых позволит вашей команде быть успешной.
Кто-то должен объединить все идеи в одну цель. Нужно убедиться, что исполни-
тельный спонсор относится к цели с энтузиазмом, команда понимает ее, ключевые
стейкхолдеры согласны с ней и другие стейкхолдеры принимают ее. Как обсуждается
в практике «Вся команда» главы 7, нужные

для этого навыки называются менеджментом См. также
продукта, и как минимум один человек с та-
Вся команда (глава 7)
кими навыками должен быть частью вашей
команды.
Если есть один визионер, то будет лучше, если он станет менеджером по про-
дукту. Пока ви́дение ценно и достижимо, ежедневная вовлеченность его создателя
в качестве менеджера значительно увеличит шансы команды поставить впечатляю-
щий продукт.
Если визионер не может участвовать по-
стоянно, как это часто бывает, то продакт- См. также
менеджером должен выступать кто-то еще.
Постарайтесь заполучить кого-то, кто макси- Вовлечение реального заказчика
(глава 8)
мально близок к ключевым стейкхолдерам.
Как в детской игре в испорченный телефон,
каждый дополнительный шаг между продакт-менеджером и ключевыми стейк
холдерами снижает способность этих людей поддерживать и продвигать цель
команды.
В некоторых случаях у команды может быть несколько целей. Если концепции
ключевых стейкхолдеров сильно различаются и их все нужно воплотить, то вы мо-
жете создать цель для каждого стейкхолдера. Работайте над одной из них в каждый
момент времени, периодически переключаясь между ними.
Разработка несколькими командами

Если ваша команда — часть горизонтально масштабированной группы команд
(см. главу 6), то цель вашей команды будет отличаться от общей цели продукта
или портфеля продуктов. Она будет связана с общей целью, но сосредоточена
на специфической роли вашей команды.
Например, ваша компания создает продукт для анализа информации о рейсах
авиакомпании. Ваша команда отвечает за получение полетной информации от
авиакомпании. Другая команда отвечает за карты аэропортов и направления.
Третья — за уведомления о вылетах и прилетах.
В этом случае общая концепция продукта может выглядеть как «мы предоставля-
ем достоверную статистику с точностью до минут и информацию для авиапуте-
шествий по всему миру». Но у вас как у команды, отвечающей за прием данных,
вашей концепцией будет «мы предоставляем другим командам нашей компании
данные, с помощью которых они могут своевременно и точно обслуживать своих
заказчиков».
Для вертикально масштабированных команд в этом нет необходимости. Они
работают все вместе над общей целью.
Задокументируйте цель
Продакт-менеджеры в процессе обсуж-
дений с ключевыми стейкхолдерами Задача обсуждений — согласовать
и спонсором уточняют идеи и собирают работу команды.
их в проект документа о цели. Задача об-
суждений — согласовать, над чем команда должна работать, почему она работает над
этим и как выглядит успех. Это общее понимание отражается в вашем документе
о цели. Вы будете его регулярно пересматривать и обновлять.
Проект документа о цели — первый примерный набросок в документировании
этого обсуждения. Он используется для того, чтобы развивать дискуссию. Формат
документа зависит от стандартов вашей компании. Некоторые компании любят
использовать ключевые показатели эффективности (Key Performance Indicators,
KPIs) или подход OKR (Objectives and Key Results — цели и основные результаты).
Каким бы ни был формат, вам в конечном итоге нужно ответить на три вопроса.
1. Ви́дение. Почему работа команды ценная? Опишите, как мир (или, по крайней
мере, его маленькая часть) изменится, когда команда добьется успеха. Поясните,
почему это важно для компании и ее заказчиков. Думайте о долгосрочной пер-
спективе и сосредоточьтесь на ценности.
2. Миссия. Как команда может реализовать концепцию в следующие 3–6 месяцев?
Опишите, что, по ожиданиям, команда должна выполнить и что лежит за преде-
лами объема работ, но на высоком уровне. Оставьте больше пространства команде
для проработки деталей. Сосредоточьтесь на итогах и ценности до результатов.
Может быть полезным сначала подумать о конкретных результатах, но двигаться
в обратном направлении, то есть начать с «почему», а не «что».
3. Показатели. Как члены команды узнают, что они на верном пути? Опишите до
пяти кратких показателей успеха. Будьте конкретны и недвусмысленны. Избегай-
те разговоров о конкретных функциональностях (например, «поставить функцио
нальность Х к дате Y»). Вместо этого пишите о коммерческих результатах, кото-
рых ожидают стейкхолдеры. Объясните, как понять по показателю, что ценность
миссии была достигнута. Если это трудно сделать, то, вполне возможно, ваша
миссия не сфокусирована на ценности.
Документ о цели — это ориентир, а не
набор четких и жестких правил. Это способ Документ о цели описывает
помочь людям понять, чего команда пыта- механизм сотрудничества,
ется достичь. Таким образом, он отражает а не является контрактом.
понимание ситуации на сегодняшний день.
Если показатели не достигнуты, это не означает, что команду надо наказать. Если
достигнуты, это не значит, что все перестают работать.
Вспомните Манифест Agile: «Сотрудничество с заказчиком важнее согласова-
ния условий контракта». Документ о цели описывает механизм сотрудничества,
а не является контрактом. В процессе работы и по мере накопления командой знаний
о рынке цели будут меняться.
Пример цели
Ви́дение: команда «Снежный человек» помогает другим командам взаимодей-
ствовать на дальних расстояниях. Наши заказчики добиваются того же высокого
уровня взаимодействия в случаях, когда команды сидят в одном рабочем по-
мещении. Используя обычные инструменты для демонстрации экрана, человек
становится узким местом для всего обсуждения. Наши инструменты позволяют
участвовать каждому. Это превращает взаимодействие на расстоянии в эффек-
тивное и приятное занятие, в то же время давая нам возможность зарабатывать
на оплате подписки лояльными клиентами.
(Обратите внимание, ви́дение фокусируется на ценности в долгосрочной пер-
спективе.)
Миссия: наша первая миссия — создание инфоповода. Наша цель на данный мо-
мент — не в создании постоянного дохода, а в том, чтобы доказать жизнеспособ-
ность идеи и привлечь внимание к нашему уникальному взгляду на удаленное
сотрудничество.
Мы будем это делать, создавая инструмент для одновременной работы, повто-
ряющей принцип работы с индексными карточками на столе. Это не инструмент
продакт-менеджмента, не инструмент для отслеживания или проведения ретро-
спектив. Это «песочница» свободной формы, способная выполнять любую из этих
задач. Она сфокусирована на взаимодействии и простоте. Она выделяется своим
качеством. Она не предоставляет возможности для чата или видеоконференции,
но по-прежнему сфокусирована на базовой функции «песочницы» для одновре-
менного сотрудничества.
(Обратите внимание, что миссия начинается с ценности, затем переходит к де-
талям конечного продукта.)
1. Мы представим первый макет и план для как минимум 20 потенциальных
заказчиков. Мы будем считать, что достигли успеха, если 70 % из них скажут,
что это решает их проблемы с взаимодействием. Так мы узнаем, является ли
наш подход жизнеспособным.
2. Мы проведем демонстрацию ранней версии на стенде во время отраслевого
мероприятия. Мы будем считать, что достигли успеха, если минимум 100 чело
век остановятся и проявят интерес и по меньшей мере 50 подпишутся на
бета-версию. Это будет означать, что люди заинтересованы в продукте.
3. Выпустив открытую бета-версию, мы будем считать, что достигли успеха, если
минимум 500 команд подпишутся на нее за первый месяц. Это будет означать,
что люди заинтересованы в продукте.
4. Через четыре месяца после запуска бета-версии продукта мы будем считать,
что достигли успеха, если минимум 100 команд будут оплачивать продукт
и пользоваться им регулярно, что будет определяться как минимум одной
авторизацией и изменением в течение каждых двух недель. Это будет означать,
что продукт полезен в реальной жизни.
(Обратите внимание, что каждый показатель описывает, как он соотносится с це-
лью. Существует множество способов, позволяющих команде оценивать свой
прогресс уже на раннем этапе.)
Внесите цель в свой устав

Создав проект документа c предварительным описанием цели и утвердив его с ва-
шими ключевыми стейкхолдерами, вы готовы обсудить его с остальными членами
команды. Обычно это происходит во время сессии подготовки устава1, также на-
зываемой взлет, после одноименной книги [Larsen2016]. Подробная информация
о том, как спланировать эту сессию, представлена во врезке «Планирование сессии
подготовки устава» далее в текущей главе.
Сессия подготовки устава обычно олицетворяет собой старт вашей новой инициа
тивы, но при этом полезна для любой команды, которая хочет лучше понять общую
картину, даже если уже работает в течение многих лет. Кроме того, допустимо про-
водить эту сессию за несколько недель до реального начала работ.
Проверьте черновик цели

Сессия подготовки устава начинается с обсуждения цели команды2. Начните
с презентации черновика ви́дения. Будет лучше, если его презентует тот, кто ру-
ководил подготовкой черновика. Обычно это делает продакт-менеджер, входящий
в команду.
Когда вы презентуете цель, не просто читайте ее, а объясняйте мысли, стоящие
за словами. Предыдущие обсуждения. Компромиссы, которые были достигнуты
и которые еще необходимо достичь. Эта предыстория позже поможет всем понять
«почему» цели.
Получите общее согласие с ви́дением

Ознакомившись с целью, проведите голосование по поводу согласия с ви́дением
(см. пункт «Стремитесь к согласию» ранее в данной главе). Ви́дение принадлежит
спонсору, так что цель вряд ли можно будет изменить, но проведение голосования
выявит любые серьезные возражения. Если нужны изменения, то спонсор должен их
одобрить. Если спонсор недоступен, то человек, руководивший созданием черновика
цели, может быть его временным уполномоченным.
Совершенствуйте миссию
За ви́дение отвечает спонсор, а за миссию — коман-
да. Именно она отвечает за претворение миссии За ви́дение отвечает спонсор,
а за миссию — команда.
в жизнь, поэтому должна взять на себя и ответ-
ственность за нее.
Чтобы помочь с формированием этой ответственности, запросите у команды
обратную связь о миссии. (Пока не о показателях. Только о самой миссии.) Попро-
сите дать реакции и комментарии, затем разделите команду на небольшие группы:
кросс-функциональный коллектив, состоящий из членов команды и стейкхолдеров.
1
На сессии не всегда готовится устав как документ, скорее это сессия, устанавливающая или
стартующая проект. Далее оставим вариант «сессия подготовки устава». — Примеч. науч. ред.
2
Данная программа основана на [Larsen2016] (гл. 6), с небольшими изменениями.
Пусть каждая группа внесет в миссию улучшения: как небольшие поправки в фор-
мулировки, так и более значительные изменения.
По истечении отведенного времени каждая группа представляет свои поправки
и их обоснование, а остальная часть группы дает обратную связь. Фасилитатор по-
могает всем объединить их идеи в общую миссию. Для этого может потребоваться
еще один раунд обсуждения в небольших группах. Иногда полезно перемешать
состав групп.
Как только команда скорректирует миссию, проведите еще один раунд голосова-
ния за согласие. Соответствует ли скорректированная миссия ви́дению? Удовлетво-
рены ли стейкхолдеры тем, что миссия будет отвечать их потребностям? Готова ли
команда взять на себя ответственность за достижение миссии? Когда вы будете вести
это голосование, подчеркните, что миссия не обязательно должна быть идеальной.
Она будет меняться со временем. Она должна быть просто достаточно хорошей на
текущий момент.
Пересмотрите показатели
И наконец, время пересмотреть показатели. Эта часть может быть самой спорной,
поскольку они должны быть максимально конкретными. Хорошие показатели долж-
ны быть недвусмысленными. И это может пугать.
Напомните всем, что показатели не являются
контрактом. Они служат ориентиром. Это способ Показатели — это ориентир,
проверить, находится ли команда на верном пути. а не контракт.
Если ваша команда не достигает показателей, это
значит, что вам нужна помощь или следует понизить ожидания. Если вы превы-
шаете показатели, это значит, что вы готовы поднять планку и повысить ожидания.
Показатели будут пересматриваться, как и все остальное, и они — не единственная
бизнес-метрика, которой следует уделить внимание.
Чтобы пересмотреть показатели, снова разделитесь на маленькие кросс-функ
циональные группы. Поделите показатели между группами. Убедитесь, что с помощью
каждого показателя можно проверять прогресс по достижению миссии, что для него
возможен ясный ответ «да» или «нет» и команда способна достичь этого показателя.
Проверьте изменения в большой группе, удостоверьтесь в общем согласии и продол-
жайте проверку, пока все возражения не будут благополучно разрешены.
Пока группа работает над каждой частью, вы можете обнаружить новые детали,
которые заставят вас вернуться и пересмотреть предыдущие части цели. Это нор-
мально и ожидаемо. Это итеративный процесс.
Стремитесь к цели
Когда закончите, проведите заключительное голосование о согласии с целью. Соглас-
ны ли все присутствующие, что цель ясна, имеет ценность и достижима? Если да,
то пора начать стремиться к ней. Попросите каждого из присутствующих зафикси-
ровать обязательства с помощью физической подписи (если у вас личная встреча)
или электронной (если виртуальная).
После того как цель будет утверждена, пригласите вашего спонсора, если он
(она) еще не с вами. Вместе просмотрите изменения в цели, попросите поддержки
и получите подпись спонсора.
Если во время вашей сессии подготовки устава вы обсуждаете и цель, и контекст
(см. раздел «Контекст» далее в этой главе), то можете обсудить контекст и только
потом пригласить спонсора.
Планирование сессии подготовки устава

Сессии подготовки устава (chartering session) начинаются с обсуждения цели, но,
помимо этого, обычно обсуждаются контекст и согласование (см. разделы «Кон-
текст» и «Согласование» далее в этой главе). Если вы планируете обсудить все
три элемента, то выделите на сессию два полных дня. Вы же не хотите спешить,
а если закончите раньше, то никто не будет в обиде. Чего нельзя будет сказать,
если процесс затянется.
Удаленным командам нужно столько же времени, сколько и командам, работа-
ющим в режиме личного общения, — около 15 часов или, возможно, больше; но
их сессия должна быть разбита на меньшие периоды, как правило, не превы-
шающие четырех часов в день. Длительные собрания очень утомительны, если
проводятся в виртуальном формате, поэтому разделите их. Убедитесь, что все
могут полностью погрузиться в дискуссию, и проводите сессию с включенным
видео, если это возможно (см. врезку «Личное общение» выше в текущей главе).
Как вариант (особенно для новых команд), с помощью сессии подготовки устава
бюджет, заложенный на поездки, можно использовать для построения взаимоот-
ношений. Проведите сессию в приятном месте за пределами офиса и отведите
дополнительный день на развлечения, которые позволят лучше узнать друг друга,
и, возможно, даже на совместный осмотр каких-либо достопримечательностей.
В сессии должны принимать участие ваш исполнительный спонсор, ключевые
стейкхолдеры, члены команды и продакт-менеджер (если он/она уже не является
частью команды). Спонсор открывает встречу, поприветствовав и поблагодарив
участников, кратко описав бизнес-преимущества командной работы и заявив
поддержку инициативы. Затем спонсор может уйти, если не желает участвовать
в дискуссии.
Будет лучше, если кто-то, имеющий навыки фасилитации, будет вести сессию,
особенно при наличии шансов, что она перерастет в спор. Этим кем-то может
быть коуч команды, но часто лучше привлечь представителя нейтральной третьей
стороны. Вы можете попросить помочь коуча другой команды или нанять внеш-
него фасилитатора. В крупных организациях отдел кадров может иметь в своем
штате профессионального фасилитатора.
Когда обсуждение цели и контекста закончено, исполнительный спонсор воз-
вращается, чтобы подтвердить свою поддержку. На этом участие стейкхолде-
ров завершается. Члены команды выражают им свою благодарность за участие
и дальше продолжают обсуждение одни. (Люди, близко работающие с командой,

например продакт-менеджер, тоже могут участвовать.)
Закончите вашу сессию подготовки устава празднованием, особенно если она
продолжалась несколько дней. Как минимум поблагодарите друг друга за про-
деланную трудную работу. Если есть возможность, то пойдите куда-нибудь вместе
развлечься. Помните, что сначала нужно сделать перерыв, чтобы интроверты
в вашей команде смогли перезарядиться.
После всего этого разместите результаты сессии где-нибудь в заметном месте
вашей командной комнаты. Возможно, вам понадобится переписать их, чтобы
сделать более понятными.
zz Концепция, миссия и показатели (из раздела «Цель»).
zz Контекстная диаграмма (из раздела «Контекст»).
zz Рабочие соглашения и стандарты (из раздела «Согласование»).
Остальные составляющие сессии подготовки устава обнародовать не обязатель-
но, но нужно сохранить копию инвентарного списка навыков и подтвержденных
ресурсов (из части «Контекст»), чтобы использовать в дальнейшем. Другие со-
ставляющие также могут пригодиться.
Продвигайте цель
Как только цель утверждена, сделайте ее
краеугольным камнем проекта. Ссылай- См. также
тесь на нее в отчетах о работе команды,
предназначенных для стейкхолдеров, Информативное рабочее пространство
и в разговорах о ваших планах и при- (глава 9)
оритетах. Вывесите постер с целью на Визуальное планирование (глава 8)
видном месте в командной комнате и об- Демо для стейкхолдеров (глава 10)
ращайтесь к ней во время сессий плани-
рования.
Не забывайте вовлекать в процесс работы вашего спонсора и других ключевых
стейкхолдеров. Приглашайте их на визуальные сессии планирования. Убедитесь,
что эти люди видят демо, даже если это происходит на сессиях с ограниченным
доступом. Запрашивайте у них обратную связь относительно прогресса и просите
помощи в улучшении ваших планов.
Вовлекать стейкхолдеров может быть непросто, но вы все же пытайтесь. Энтузи-
азм и воодушевление этих людей могут говорить гораздо больше, чем любой документ.
Если члены команды часто общаются со своими ключевыми стейкхолдерами, то
будут лучше понимать свою цель и выдвигать больше идей, которые позволят повы-
сить ценность продукта и снизить затраты.
Ели гора не идет к команде, значит, коман-
да должна идти к горе. Другими словами, если Попытайтесь вовлечь
стейкхолдеры не хотят приходить на сессии пла- ключевых стейкхолдеров.
нирования, то командные продакт-менеджеры
должны наладить взаимодействие. Информировать о планах, получать обратную

связь и проводить показы демо менее эффективно, чем вовлекать стейкхолдеров
непосредственно в планирование, и вам нужно убедиться, что продакт-менеджеры
способны донести до команды точку зрения стейкхолдеров. Если у вас нет никого,
кто может это делать, то обсудите с исполнительным спонсором риски создания
неправильного продукта. Возможно, вашей команде лучше заняться чем-то другим
до тех пор, пока стейкхолдеры не будут доступны.
Обновляйте цель
Цель команды будет меняться со временем. Показатели будут устаревать, и команда
будет узнавать что-то новое о своих стейкхолдерах, заказчиках и рынке. В результате
вам понадобится обновлять цель. Это изменяемый документ.
Установите конкретное время для пересмотра и корректировки цели. Например,
каждые 3–6 месяцев. Подготовьте новый черновик и соберите всех на новую сессию
подготовки устава. Скорее всего, она пройдет значительно быстрее, чем в первый раз.
Обычно концепция сильно не меняется, миссию потребуется слегка скорректировать,
а показатели нужно будет обновить или заменить.
Вопросы
Может ли вся команда участвовать в обсуждении проекта цели?
Конечно! Это прекрасный способ для команды узнать поближе своих стейкхолде-
ров. Обычно одни члены команды больше заинтересованы, чем другие. Обсудите, как
разделить работу внутри команды, возлагая ее на тех участников, кто имеет больше
опыта работы со стейкхолдерами.
Обсуждение цели привело нас к спорам, и согласия не предвидится. Должны ли мы
продолжать в любом случае?
С целью команды должен быть согласен не каждый стейкхолдер, а лишь ключе-
вые стейкхолдеры. Даже если обсуждение цели команды привело к ожесточенным
спорам, вам все же необходимо стремиться к общему ви́дению и цели. Иначе вы
выпустите ПО, которое будет фрагментированным и никого не удовлетворит.
Вероятно, вы сможете разбить цель на множество этапов, которые команда сможет
выполнять последовательно. Если это не сработает, то попробуйте привлечь про-
фессионального фасилитатора, который может выступать посредником в дискуссии.
Наш спонсор постоянно меняет свое мнение. Как можно заставить его выбрать
одно направление и придерживаться его?
Как правило, быстро меняют цели спонсоры с предпринимательским мышлением.
Это происходит не из-за отсутствия ви́дения или последовательности; просто они
видят множество возможностей и меняют направление, чтобы использовать их все.
Постоянное изменение цели может служить зна-
ком, что то, что вы принимаете за цель команды, — на
См. также
самом деле временная стратегия в более крупной
общей цели. Адаптивное планирование
Если вам удастся идентифицировать эту более (глава 8)
крупную цель, то адаптивное планирование сможет
помочь вам двигаться наравне с вашим спонсором. Здесь также может пригодиться
свободное владение навыками на уровне оптимизации. Его акцент на обучение и ис-
пользование всех возможностей будет прекрасно сочетаться с предпринимательской
натурой вашего спонсора.
Ваш спонсор может продолжать менять направления быстрее, чем вы будете
воплощать в жизнь его идеи. В этом случае продакт-менеджер может выступать по-
средником, защищая команду от быстрых изменений и объясняя спонсору, какой
объем работы команда может выполнить в данный момент.
Любой команде нужна цель. Она не обязательно должна быть выражена в представ-
ленном здесь формате, но каждой команде необходимо знать, чего от нее ожидают
и почему. Правильно определить цель может быть непросто. Для этого потребуется
вовлечь стейкхолдеров и людей, имеющих достаточные навыки в области менедж
мента продукта.
Если у вас нет человека с необходимыми навыками, то ваша компания рискует
потратить много денег на неверные результаты. Прежде чем продолжить, попросите
вашего исполнительного спонсора помочь устранить этот риск.
Когда у вашей команды есть понятная и убедительная цель, которую разделяет вся
команда и стейкхолдеры:
zz легко приоритизировать функциональности;
zz продакт-менеджеры без труда обосновывают перед стейкхолдерами свои решения
по приоритизации;
zz разработчики вносят свой вклад в принятие решений при планировании, пред-
лагая способы того, как повысить ценность, одновременно снизив затраты;
zz ключевые стейкхолдеры уверены, что команда разрабатывает именно то, что им
нужно;
zz организация поддерживает усилия команды.
В конечном итоге эта практика нужна для того, чтобы убедиться, что все одинаково
понимают, что и почему в работе команды. Точный способ достижения этого пони-
мания не так важен. Вы можете использовать сессию подготовки устава и документ
о цели, как я описывал здесь, а можете попробовать и другие подходы.
Один стартап, с которым я работал, начинал с нормального документа о цели,
но потом люди обнаружили, что их бизнес меняется слишком быстро, чтобы этот
документ оставался полезным. Вместо него они стали вести доску со стикерами, на
которых были записаны бизнес-приоритеты. Стикеры распределялись по категори-
ям («Развитие бизнеса», «Контроль затрат», «Производительность» и «Снижение
рисков»), и один или два из самых приоритетных закреплялись за каждой командой.
При еженедельных пересмотрах стратегии основатели стартапа уделяли этой доске

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

Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen2016] — ком-
плексное руководство по планированию устава в Agile. Оно легло в основу практик
в разделах «Цель», «Контекст» и «Согласование» этой книги. Особенно полезны
рекомендации по подготовке и фасилитации сессий подготовки устава.
Impact Mapping1 [Adzic2012] содержит милую дискуссию о том, как определить
цели и создать хорошие показатели (автор называет их «измерители»), в главе
Creating an Impact Map.
КОНТЕКСТ
Мы знаем, с кем и с чем мы должны работать.
Аудитория
Какие навыки доступны для вашей команды?
Продакт-менеджеры, коучи
Какие ресурсы у вас есть? Кто ваши стейкхол
деры?
Все это — часть контекста вашей команды:
более широкой системы, в которую она встрое-
на. Понимание контекста важно для снижения Если вы не понимаете
риска. Если вы не понимаете контекст, то люди контекст, то люди и ожидания
или ожидания, о существовании которых вы даже могут застать вас врасплох.
не подозревали. легко могут застать вас врасплох.
Запишите контекст в устав

Сессия подготовки устава вашей команды, ко-
торую мы обсуждали во врезке «Планирование См. также
сессии подготовки устава» ранее в данной гла-
ве, — подходящий момент, чтобы обсудить ваш Цель (глава 7)
контекст. Вы также можете обсудить контекст
и во время отдельной сессии, если это удобнее, но будет лучше, если вы сначала
определите цель вашей команды. Это поможет каждому понять, что именно команда
намеревается делать.
1
Аджич Г. Impact mapping: Как повысить эффективность программных продуктов и проектов по
их разработке.
В процессе обсуждения контекста вам будет нужно работать с ключевыми

стейкхолдерами, чтобы определить три аспекта контекста вашей команды: доступ-
ные навыки, границы и взаимодействие команды, а также ресурсы, выделенные
ей. В дальнейшем вы посмотрите результаты с вашим исполнительным спонсором
и попросите его подтвердить готовность предоставить то, чего не хватает1.
Доступные навыки
Начните с просмотра навыков, доступных вашей команде. Попросите каждого члена
команды представиться и описать навыки и опыт, которыми они владеют. Эти люди
также могут рассказать о любых своих связях или разрешениях, имеющих отношение
к делу. Пока человек будет говорить, фасилитатор может записывать ответы на флип-
чарт. Для удаленных команд можно выделить пространство на вашей виртуальной
белой доске и использовать его в качестве виртуального флипчарта. Назовите этот
список «Перечень навыков».
В «Разрешения» входят электронные разрешения (допуски), такие как «я имею
возможность просматривать базу данных в эксплуатационной среде»; юридиче-
ские разрешения, такие как «у меня есть корпоративная кредитная карта и право
подписи при покупке оборудования»; социальные разрешения, такие как «мне
разрешается разговаривать с тем расстроенным заказчиком».
Некто, имеющий опыт в эксплуатации, может сказать: «Я — Ха Лам, и я работаю

в эксплуатации пять лет, два из которых — в этой компании. Моя специализация —
инфраструктура как код (IaC), и у меня есть опыт в кибернетике. У меня хорошие
связи с командой платформ и есть допуск к развертыванию в эксплуатационной
среде».
После того как все члены команды представились, создайте отдельный список
людей, которые помогают вам, но не приписаны к команде на полный рабочий день.
В список, вероятно, будут входить продакт-менеджер и коуч. Если они присутствуют
на встрече, то также могут рассказать о себе; если нет — тот, кто знает их лучше всех,
может рассказать об их навыках, опыте и т. д., включая время, когда они бывают до-
ступны, и наиболее удобные способы общения с ними.
Обсудив навыки всех участников, обратите общее
внимание на цель команды. (Вы можете записать ее См. также
на флипчарте или в общедоступном документе; кроме
того, можно раздать всем копии.) Прочтите несколь- Цель (глава 7)
ко пунктов, а затем попросите участников свериться
с перечнем навыков. Не пропущены ли какие-либо навыки или разрешения, которые
могут понадобиться команде? Предложите команде одновременный мозговой штурм
1
Этот план основан на [Larsen2016] (гл. 7), с некоторыми изменениями. Я добавил перечень
навыков, частично вдохновленный активностью «Основная группа», и удалил их активность
«Перспективный анализ», чтобы сохранить ее в разделе «Визуальное планирование» главы 8.
(см. пункт «Работайте одновременно» выше в данной главе), чтобы подготовить

стикеры или их виртуальный эквивалент, по одному на каждый навык.
Пока участники заняты этим, подготовьте еще два флипчарта. Назовите один
«Необходимые навыки», а другой — «Необходимые разрешения». Попросите всех
наклеить на них свои стикеры. Повторяющиеся можно скомбинировать или убрать.
Когда закончите, посмотрите на результаты, затем отставьте флипчарты в сторону
на время.
Границы и взаимодействия
Далее вы создадите контекстную диаграмму, выявляющую все разнообразие групп
людей, с которыми придется работать вашей команде. Начните с подготовки большой
поверхности для диаграммы. (Лучше приготовить ее заранее.) Она должна быть боль-
шой, поэтому скрепите вместе несколько флипчартов на стене или столе либо исполь-
зуйте большую белую доску. Удаленные команды будут использовать виртуальную
доску, как обычно. Нарисуйте в центре круг, представляющий вашу команду.
Когда будете готовы, предложите участникам мозговой штурм, чтобы записать
каждую группу стейкхолдеров, с которой команде необходимо взаимодействовать,
на отдельный стикер. Мыслите очень широко: важен каждый, кто влияет или под-
вергается влиянию работы команды как в позитивном, так и в негативном ключе.
Сюда входят команды разработчиков ПО, с которыми взаимодействует ваша команда,
включая команды — владельцы систем, с которыми будет коммуницировать ваше
ПО; другие группы в компании, отвечающие за маркетинг, продажи и эксплуатацию;
группы вне компании, такие как ваши заказчики, конкуренты и поставщики; и даже
еще более отдаленные группы, например государственные регулирующие органы.
Когда идеи закончатся, пусть люди разместят стикеры вокруг центрального круга,
представляющего вашу команду. Одинаковые стикеры можно объединить. Например,
вы можете сгруппировать вендоров программ в один стикер под названием «Вендоры
ПО», но оставьте отдельный стикер для вашего провайдера облачной инфраструкту-
ры. Похожим образом стикеры с указанием групп, имеющих минимальное влияние
на вашу команду (и наоборот), можно выбросить.
После того как все стикеры окажутся на доске, попросите участников подумать над
тем, что они дают каждой группе стейкхолдеров и что получают от каждой группы.
Пусть они обозначат все эти взаимодействия стрелками и добавят краткое описание.
Если вы рисуете вашу диаграмму на бумаге, то начните с чего-нибудь временного,
типа карандаша или другого стикера, чтобы было легко вносить изменения.
Пока участники работают над диаграммой контекста, подготовьте еще несколько
флипчартов. Озаглавьте их «Необходимые ресурсы» и «Коммуникации, которые не-
обходимо обеспечить» и прикрепите рядом с флипчартами «Необходимые навыки»
и «Необходимые разрешения».
Agile-команды избегают называть людей ресурсами. Это обезличивает. Под
ресурсами я имею в виду такие понятия, как время, деньги, товары и сервисы.
Как только диаграмма контекста будет готова, вам нужно ее проанализировать.

Разделите команду на небольшие кросс-функциональные группы и распределите
между ними группы стейкхолдеров с диаграммы. Обсудите, как команда будет
взаимодействовать с каждой группой заинтересованных лиц, и с помощью моз-
гового штурма определите необходимые команде навыки, разрешения и ресурсы.
Таким же образом подумайте, с помощью каких коммуникационных способов эта
группа будет взаимодействовать с командой. Запишите каждую идею на стикер
и прикрепите на соответствующем флипчарте: «Необходимые навыки», «Необ-
ходимые разрешения», «Необходимые ресурсы» или «Коммуникации, которые
необходимо обеспечить».
И наконец, дайте всей команде подумать над диаграммой «Коммуникации, ко-
торые необходимо обеспечить» и решите, как упростить и скомбинировать ваши
способы коммуникаций. Некоторые их виды могут подойти для нескольких групп.
Например, вы можете информировать людей о прогрессе работы и дорожных картах
с помощью рассылки по электронной почте. На данный момент вам нужно просто
создать примерный план; команда будет его пересматривать в течение следующих
недель.
Выберите ответственного за каждый тип коммуникации, а также кого-то, кто бу-
дет регулярно всем напоминать выполнять запланированные действия. Когда ваша
команда установит рабочий ритм, эти обязанности могут стать более гибкими, но
в самом начале что-то может выпадать из поля зрения. Поэтому лучше будет пока
иметь четко определенные обязанности.
Если принятие решения о том, как продолжить коммуникации, занимает больше,
чем несколько минут, то отложите его до конца встречи. (Только не забудьте по-
том!) Не нужно тратить время остальных участников понапрасну.
Выделенные ресурсы
По завершении двух предыдущих упражнений у вас должно быть три диаграммы,
описывающие, что нужно вашей команде: «Необходимые навыки», «Необходимые
разрешения», «Необходимые ресурсы». Теперь пусть участники одновременно по-
работают над сортировкой стикеров из каждой диаграммы, сгруппировав их в четыре
категории: «строго необходимо», «необходимо», «желательно», «не нужно»1. В про-
цессе сортировки люди могут добавить новые пункты.
Проверьте результаты вместе со всеми присутствующими и убедитесь, что ко-
манды и стейкхолдеры достигли согласия в вопросе о необходимых пунктах и их
категоризации. Небольшие разногласия — это нормально, так что не стремитесь
к совершенству.
1
Это называется приоритизация MoSCoW (must have, should have, could have and won’t have).
Последняя категория обычно называется «не будет» (won’t have), но я называл ее «не нужно»
(don’t need), чтобы отличать от того, что вы хотели бы, но не можете получить.
Когда закончите с этим, стикеры с надписью «не нужно» можно выбросить.

Добавьте на оставшихся стикерах примечания.
1. Кто может предоставить каждый элемент.
2. Насколько они готовы его предоставить.
3. Как его получить, если это неочевидно.
Группа может работать над несколькими стикерами одновременно.
В конце предложите всем сделать шаг назад и осмотреть все, что необходимо.
Есть ли что-то важное, что необходимо команде, но получить это будет непросто?
Если да, то выделите эти пункты. Вам понадобится обратиться к спонсору с просьбой
предоставить это. Подготовьте несколько возможностей на рассмотрение спонсору.
Например, если вам нужны навыки настройки баз данных, то вы можете предложить
найти консультанта, пройти тренинг или нанять кого-то.
Обязательства спонсора
Завершите обсуждение контекста, снова пригласив
спонсора в комнату, если он не присутствовал при об- См. также
суждении. Если вы также обсуждали изменения в уставе,
имеющие отношение к цели, то сейчас подходящее время Цель (глава 7)
для того, чтобы спонсор утвердил эти поправки. Затем
обратите внимание на потребности команды.
Просмотрите навыки, разрешения и ресурсы, которые ваша команда не мо-
жет получить самостоятельно, и попросите спонсора взять на себя обязательство
обеспечить их. Если он сделает это, то задача выполнена. Решите, кто в коман-
де будет ответственным за напоминания по этим обязательствам и кто еще бу-
дет дополнительно напоминать о них, как было описано в предыдущем подраз-
деле.
Если ваш спонсор не может предоставить
все необходимое, то внимательно изучите воз- Если ваш спонсор не может
можные компромиссы. Как нехватка каждого предоставить все необходимое,
из ресурсов, навыков или разрешений влияет то откровенно поговорите с ним
на способность команды достичь цели? От- о компромиссах.
кровенно поговорите со спонсором о том, чем
он рискует и чего хочет от команды.
В ходе разговора помните, что спонсор должен сделать нелегкий выбор. Обычно
эти люди оказываются перед выбором одной из двух плохих возможностей. Да, спон-
соры владеют бюджетом команды, но их ресурсы не безграничны. Иногда спонсоры
должны сделать трудный выбор между тем, чтобы дать команде все, о чем она просит,
или надеяться на то, что она найдет достаточно ресурсов, позволяющих добиться
результатов и без спонсорской поддержки.
Некоторые элементы все же будут существенными, и без них команда не сможет
достичь своей цели. Если вы не можете получить какие-либо важные ресурсы, то
вам нужно будет проработать со спонсором возможности изменить или отменить
цель либо отложить ее достижение.
Обновляйте контекст
Когда сессия подготовки устава будет окончена, сохра-
ните копию перечня навыков, контекстную диаграмму См. также
и подтвержденные ресурсы в месте, легкодоступном для
вашей команды. Вы будете обращаться к ним и обнов- Командная комната
(глава 7)
лять их по мере необходимости. Вывесите контекстную
диаграмму на видном месте командной комнаты.
Помните, что вам нужно выделить время на то, чтобы просмотреть планы комму-
никации, которые вы создали, определяя границы и взаимодействия. Обязательно
проконсультируйтесь с вашим спонсором по поводу выделенных ресурсов.
Первые несколько раз, после каждого контакта с группами ваших стейкхолдеров,
уделите некоторое время оценке и корректировке плана коммуникации. Со временем
ваше общение станет комфортным для всех.
Необходимо пересматривать контекст время от времени (примерно каждые шесть
месяцев), чтобы освежить его в памяти каждого участника, обновить информацию
и пересмотреть план коммуникации. Вам не обязательно проводить полномасштаб-
ную встречу с участием стейкхолдеров; будет достаточно провести быстрый пере-
смотр в вашей командной комнате. Пригласите продакт-менеджера, если он еще
не является постоянным членом команды.
Вопросы
Что, если у нас отсутствуют необходимые ресурсы, но спонсор не хочет слушать?
Это трудная ситуация. Если вы знакомы с кем-то имеющим навыки дипломатии
(например, продакт-менеджером, менеджером проекта или коучем), попросите их
помочь донести это сообщение до спонсора. Тем временем работайте с тем, что есть,
и продолжайте напоминать спонсору и бизнес-стейкхолдерам, что от вас ожидают,
что вы сделаете X, Y и Z, но вы можете сделать только X и Z из-за ограниченности
в ресурсах.
Описанный здесь сбор информации о контексте требует участия людей, знаю-
щих, как работает ваша организация. Постарайтесь подключить таких людей
к проекту.
Когда ваша команда понимает свой контекст и обладает необходимыми подтверж-
денными ресурсами:
zz она имеет доступ ко всему, что ей требуется для выполнения задачи;
zz ее не застать врасплох внезапно появившейся и неизвестной ранее группе стейк-
холдеров или требованию;
zz общение с группами стейкхолдеров ровное и стабильное.
Работа над контекстом для устава позволяет вам получить много информации о си-
туации, в которой находится команда, но особенно важны следующие три результата.
1. Знание того, кто ваши группы стейкхолдеров и что вам нужно друг от друга.
2. Определение способов, с помощью которых вы будете общаться друг с другом.
3. Корректировка вашей цели и ожиданий стейкхолдеров в соответствии с навы-
ками, разрешениями и ресурсами, доступными команде.
Программа сессии подготовки устава, представленная здесь, — это только один из
способов, позволяющих достичь этих результатов. Вы можете применить любой подход.
Некоторые организации, вместо того чтобы проводить сессии подготовки уста-
ва, поручают руководителям проектов или бизнес-аналитикам провести интервью
со стейкхолдерами и, исходя из результатов, создать набор документов. Это рабо-
чий способ, но все же не стоит недооценивать значимость коллективной работы
команды и заинтересованных сторон над тем, чтобы узнать точки зрения друг друга.
Проведение сессии в сотрудничестве с ключевыми стейкхолдерами — прекрасная
возможность создать взаимосвязи и обоюдную эмпатию. Это нечто гораздо более
интуитивное и запоминающееся, чем пачка документов, на чтение которых некоторые
люди так и не найдут времени.
Вы все еще сможете проводить эксперименты, даже если будете придерживаться
базовой идеи сессии подготовки устава. Начните с практики, описанной здесь, пред-
почтительно задействовав опытного фасилитатора, просто чтобы получить некоторые
представления о том, как это должно работать. Затем начните экспериментировать.
Например, долгая двухдневная встреча может быть очень изнуряющим мероприя
тием. А что, если разделить ее на несколько более коротких? А как насчет специ-
альных видов деятельности? Можете подумать о способах, позволяющих улучшить
или заменить эти виды чем-то другим. Что, если сделать больше подготовительной
работы заранее или пригласить других людей?
Если ваша организация большая, то предложите провести такие сессии для
других команд. Они ценны для любых команд, не только Agile, и даже не только
команд разработки ПО. Эти сессии проводятся не только тогда, когда команда лишь
создается; если она раньше не согласовывала устав, то ей наверняка будет полезна
такая сессия независимо от того, насколько долго люди работают вместе. У вас будет
много возможностей для эксперимента, и есть множество вещей, которые вы можете
попробовать. Подумайте, чему вы можете научиться.
СОГЛАСОВАНИЕ
Мы договорились о том, как будем работать
вместе. Аудитория
Что такое «команда»? Это не просто груп- Продакт-менеджеры,

па людей, сидящих в одной комнате. Это даже коучи
не группа людей, которой поручили работать над
одной и той же задачей.
Команда — это группа людей, которые полагаются

друг на друга, стремясь достичь общей цели. Эта взаи Взаимозависимость —
мозависимость — отличительный признак команды. отличительный признак
команды.
Это то, что делает команды такими успешными… и то,
что все усложняет.
Вероятно, вы помните работу над групповыми заданиями в школе. В лучшем слу-
чае вы их терпели. Мы все слышали ужасные истории о человеке, который в конечном
итоге начал один делать всю работу, пока остальные выпрашивали оценки.
Но мы слышали и истории об удивительных командах. Возможно, у вас тоже
был такой опыт: быть частью прекрасной спортивной команды, музыкальной или
волонтерской группы. Работая, команды заряжают энергией все вокруг.
В чем разница между хорошими и плохими командами? В согласованности. Люди
в команде, достигшей согласия, не только полагаются друг на друга, чтобы достичь
общей цели, но и договорились о том, как будут работать вместе.
Запишите договоренности в устав

Во время сессии подготовки устава вы можете согла-
совать договоренности (см. врезку «Планирование
сессии подготовки устава» выше в данной главе). См. также
В отличие от других этапов сессии (обсуждение цели
Цель (глава 7)
и контекста), стейкхолдеры не присутствуют при об-
суждении договоренностей. В нем участвуют только Контекст (глава 7)
члены команды и те, кто близко работает с командой,
например продакт-менеджер.
Как и в случае с другими дискуссиями об уставе, тема согласования может под-
нять некоторые деликатные вопросы. Будет лучше, если вы привлечете нейтрального
фасилитатора. Хороший фасилитатор поможет уладить конфликты и сделать так,
чтобы мнение каждого участника было услышано.
В процессе согласования вы узнаете больше о людях в команде, создадите рабо-
чие договоренности, которые будут направлять поведение команды, и установите
стандарты1.
Узнайте друг друга

Начните ваше обсуждение с того, что поможет лучше узнать друг друга. Врезка
«Упражнение на построение взаимоотношений в команде» выше в этой главе — хо-
роший способ положить начало общению. Затем проведите групповое обсуждение
следующих вопросов.
1. Кто я? (Расскажите немного о себе, поделитесь своими положительными лич-
ными качествами, например, «внимательность к деталям», «терпеливость» или
«дружелюбие».)
2. Что люди сразу узнают обо мне, как только знакомятся? (Это может быть хобби,
любимые места для поездки в отпуск или любимое домашнее животное.)
1
Эта программа основана на [Larsen2016] (гл. 6), с некоторыми изменениями.
3. Почему я думаю, что эта группа хорошо подходит для достижения цели команды?
4. Каков самый важный факт из того, что другие должны знать обо мне, чтобы эф-
фективно работать со мной?
5. Что все это для меня значит? Что я хочу получить от участия в работе команды
и достижении ее цели?
Сделайте круг по комнате, задавайте один вопрос за раз, дайте ответить каждому.
Люди могут пропустить свою очередь, если им надо время подумать. Вернитесь к ним
позже, прежде чем переходить к следующему вопросу.
Этот разговор поможет членам команды увидеть друг друга как людей в целом,
а не только имена, лица и названия должностей. Если у вас удаленная команда, то
постарайтесь провести этот разговор с включенным видео.
Заключите рабочие соглашения

Рабочие соглашения определяют поведение вашей команды, описывая то, чего вы
ждете друг от друга. Со временем они будут меняться. Когда команда достигает
зрелости, многие из рабочих соглашений становятся привычными, и их можно будет
удалить из списка. Другие, наоборот, можно будет добавить, чтобы воспользоваться
новыми идеями.
Чтобы создать рабочие соглашения вашей команды, начните с того, что поделитесь
историями о других командах, с которыми вы работали. Опишите, как они работали
вместе, хорошо или плохо. Можете делать это по кругу или в произвольном порядке
в зависимости от того, кто хочет говорить следующим.
1. Вспоминая ваш прошлый опыт работы в команде (любого типа, включая спор-
тивные команды, церковные или музыкальные группы либо хоры), подумайте,
когда вы были наиболее эффективны как член команды. Расскажите коротко об
этом времени. Какие рабочие условия привели к эффективной работе?
2. Поразмышляйте о том времени и тех ситуациях в вашей жизни, когда вы сотруд-
ничали с командой. Что вы заметили в отношении себя, своего вклада, что вам
кажется ценным? Что вы больше всего цените в тех группах?
3. Что, по вашему мнению, является основным фактором, который создает, вос-
питывает и поддерживает эффективную командную работу? Что отличает ее
от других?
4. Какие три желания вы бы загадали, чтобы ваш опыт в этой команде стал наи-
более ценным?
Пока люди делятся своими воспоминаниями, сделайте паузу, чтобы записать идеи
потенциальных рабочих соглашений. Они могут относиться к чему угодно: стан-
дарты поведения, например, «мы не прерываем говорящего»; особенные практики,
например, «мы используем парное программирование для всего промышленного
кода»; рабочие привычки, например, «меняя задачи, мы пишем сообщение об этом
в групповой чат» и т. д. Запишите все, что может помочь команде лучше работать
вместе. Пока не критикуйте предложения; просто собирайте их.
После того как вы поделились своими историями, проверьте, рассмотрели ли вы
категории, приведенные ниже в перечне. Если нет, то предложите рабочие соглашения
и относительно них. Вам не обязательно будет их выбирать, просто убедитесь, что

вы их приняли во внимание.
zz Практики, которые будет использовать ваша команда. Я рекомендую начать
с каждой практики на уровнях, выбранных вашей командой.
zz Для виртуальных команд — как вы будете общаться (см. пункт «Организация
удаленного взаимодействия» выше в данной главе).
zz Как вы будете принимать решения.
zz Для физических команд — как вы будете решать проблему отвлекающего фоно-
вого шума.
zz Для команд, которые не используют парное или групповое программирование, —
как вы будете просить помощи, не отвлекая коллег (см. пункт «Всегда просите
помощи, всегда помогайте» выше в данной главе).
zz Обязательные рабочие часы, в течение которых вы можете ожидать, что все чле-
ны команды будут доступны.
После генерации идей сократите их спи-
сок до пяти самых важных, используя то- Выберите рабочие соглашения,
чечное голосование (см. пункт «Работайте которые требуют особого внимания,
одновременно» выше в данной главе). Идей а не те, которые выполняются
может быть несколько больше или меньше. автоматически.
Предложите людям проголосовать за те
предложения, на которые, как они считают, команде нужно обратить особое вни-
мание, а не на те, которые выполняются автоматически.
Убедитесь, что все согласны с окончательным списком, проведя голосование
о согласии (см. пункт «Стремитесь к согласию» выше в данной главе). Если не полу-
чается достичь согласия по определенному пункту рабочего соглашения, то просто
пока исключите его из списка. Вы сможете вернуться к нему позже.
В завершение сформулируйте все рабочие соглашения и внесите их в оконча-
тельный список. Каждое должно заканчиваться предложением «Мы работаем вместе
лучше, когда…» Опишите то, что надо делать, а не то, что не надо делать. Другими
словами, вместо «мы не прерываем друг
друга» запишите «мы даем людям закончить
См. также
мысль и только потом выражаем свою».
Прикрепите список где-нибудь на видном Командная комната (глава 7)
месте в вашей командной комнате. Вы мо-
жете сразу начать им пользоваться.
Задайте стандарты
Стандарты — это особые рабочие соглашения, применяемые к определенным типам
задач. Примерами могут служить стандарты кодирования, рекомендации по UI-
дизайну и эксплуатационные стандарты.
Стандарты могут становиться источниками конфликтов, если к ним не обра-
щаются, поэтому будет лучше сразу дать им определение. Их содержание не очень
важно. Вы будете их расширять и корректировать с течением времени. Помните,
что в Agile мало решений, которые нельзя изменить. Уорд Каннингем сказал об этом
так (https://oreil.ly/IcikH):
«Переломный момент в моей программистской карьере наступил, когда я осоз-
нал, что мне не нужно побеждать в каждом споре. Допустим, я разговаривал
с кем-то о коде и говорил: “Я думаю, что лучший способ это сделать — это А”.
А они отвечали: “Мы думаем, что лучший способ это сделать — это Б”. Я гово-
рил: “Нет же. Это точно А”. Они отвечали: “А мы хотим это сделать с помощью
способа Б”. Поворотный момент настал, когда я смог сказать: “Хорошо. Делайте
с помощью способа Б. Если я ошибаюсь, это не причинит нам особого вреда.
Даже если я прав, а вы делаете Б — нам и это не слишком повредит, поскольку мы
можем исправить ошибки. Так что давайте узнаем, является ли это ошибкой”».
Исходя из этого, используйте следующие две рекомендации для создания своих

стандартов.
1. Создайте минимальный набор стандартов, который позволит выполнять работу.
2. Предпочтите последовательность и согласованность, а не совершенство.
В качестве первого стандарта решите,
что подразумевать под сделанной работой. См. также
Начните обсуждение, попросив участников
предложить промышленный стандарт в ка- Сделано Сделано (глава 9)
честве основы. (Для определения понятия
«сделано» можете использовать чек-лист «Сделано Сделано» (Done Done) из гла-
вы 9.) Если в вашей компании уже есть стандарты, то начните с них.
Если предложений для базового стандарта несколько, то обсудите варианты и вы-
берите один, с которым согласны все. Ограничьте дискуссию несколькими минутами.
Если вы не можете уложиться в это время, то начните без базового стандарта.
Далее, используя одновременный мозговой штурм, подумайте о дополнениях или
изменениях. Сгруппируйте идеи, используя диаграмму сходства (см. пункт «Рабо-
тайте одновременно» выше в данной главе), а затем проведите точечное голосование,
чтобы выбрать наиболее важные категории.
Начиная с категории, получившей максимальное количество голосов, попросите
кого-нибудь предложить подходящий стандарт. Проведите голосование за согласие,
устраните возражения и перейдите к следующему предложению.
Ограничьте обсуждение каждого варианта пятью минутами. Если не удалось до-
говориться за это время, то пока просто пропустите это предложение. Повторюсь:
у вас будет возможность пересмотреть свои стандарты позже. Отведите на все об-
суждение 45 минут.
После того как сформулируете определение понятия «сделано», повторите процесс
с любыми другими нужными вам стандартами. Можно это сделать параллельно, раз-
бившись на специализации, такие как программирование, UX-дизайн и эксплуатация.
Резюмируем.
1. Начните с согласования по поводу базового стандарта. (Ограничьтесь пятью
минутами.)
2. Внесите дополнения или поправки с помощью мозгового штурма. Сгруппируйте
их по категориям. Проведите точечное голосование.
3. Для каждой категории заключите соглашение об определенном стандарте. (Огра-

ничьтесь пятью минутами.)
4. Отведите на все обсуждение 45 минут.
Независимо от того, какие стандарты выберет ваша группа, у некоторых людей
они поначалу будут вызывать раздражение или недовольство. Но со временем вы
приспособитесь к ним. Во многом стандарты — это вопрос эстетики. Один из при-
знаков профессионализма — это готовность отказаться от личных эстетических
предпочтений в пользу командных.
Помимо форматирования
Однажды я вел команду из четырех программистов, имевших очень сильно
различающиеся подходы к форматированию. Когда мы обсуждали стандарты
кодирования, я перечислил три разных подхода к скобкам и табуляции. У каж-
дого был свой ярый сторонник. Я не хотел, чтобы мы погрязли в спорах, поэтому
сказал, что все участники команды могут использовать тот стиль скобок, который
они предпочитают.
Результат был предсказуем: у нас было три разных подхода к форматированию
нашего кода. Я даже увидел три разных варианта отступа в пределах одного
короткого метода.
Знаете, что меня удивило? Это было не так уж плохо. Конечно, текст программы
выглядел скверно, и я бы предпочел что-то более последовательное, но все же
код был читаемым. В конце концов, остальные наши стандарты кодирования
имели большее значение, чем форматирование.
Мы договорились, что важно именовать переменные и короткие методы понятным
образом. Мы договорились использовать утверждения (assertions), чтобы быстро
обнаруживать неправильно работающий код, не оптимизировать без измерений
и никогда не передавать пустые ссылки (ссылки, которые не ссылаются ни на какой
объект, null references) между объектами. Мы договорились о том, как надо и не надо
обрабатывать исключения (exceptions), что делать с отладочным кодом (debugging
code), когда и куда регистрировать события (events). Эти стандарты помогли нам
гораздо больше, чем это мог бы сделать единый стиль форматирования. Каждый
стандарт приносил конкретную пользу. Вероятно, именно поэтому мы смогли до-
говориться о них, когда не смогли договориться о форматировании.
Не поймите меня неправильно: иметь единое форматирование было бы лучше!
Но, собирая в единое целое ваши стандарты программирования, не загоняйте
себя в ловушку бесконечных споров о форматировании.
Обновляйте соглашения
Ваш список рабочих соглашений, не включая стандарты, позволит сформировать
привычки, над созданием которых вы активно работаете. Лучше будет ограничить
этот список пятью пунктами. Когда привычка станет автоматической, удалите ее из
списка, чтобы освободить место для нового соглашения.
Стандартам нужно какое-то время, чтобы устояться. Запланируйте встречу, на

которой вы сможете обсудить ваши стандарты, через несколько дней после начала
вашей совместной работы, и еще одну — еще через несколько недель. Одного часа
должно быть достаточно. Это поможет вам применять ваши стандарты на практике.
Если после этого возникнут разногласия по поводу стандарта, то договоритесь по-
экспериментировать с одним подходом, потом с другим и затем вернитесь к этому
вопросу.
Вы можете изменить ваши рабочие соглашения
и стандарты в любой момент. Просто объявите о своем См. также
намерении команде, получите согласие и замените
флипчарт или его виртуальный эквивалент. Кроме Ретроспективы (глава 11)
того, удобно изменять рабочие соглашения во время
ретроспектив.
Придерживайтесь договоренностей
Люди совершают ошибки. Предположим, ваши коллеги профессиональны и имеют
добрые намерения. Если кто-то не выполняет соглашения, то допустим, что у него
есть причина, несмотря на свидетельства обратного. Ваша задача — найти эту при-
чину и разобраться с ней. Такой подход продемонстрирует уважение к другим и по-
высит их уважение по отношению к вам.
Используя парное и групповое програм-
мирование, а также коллективное владение См. также
кодом, команда может находить ошибки
и поддерживать самодисциплину. Кроме Парное программирование (глава 12)
того, эти практики позволяют обсуждать Групповое программирование
вопросы, не касающиеся ваших командных (глава 12)
соглашений. Вдобавок они дают прекрасную Коллективное владение кодом
возможность улучшить ваши стандарты; на- (глава 12)
много легче предлагать улучшение, сначала
обсудив его с кем-либо.
Автоматизированное соблюдение стандартов, как правило, менее эффективно.
Некоторые используют автоматизированные системы для проверки своего исходного
кода на соответствие стандартам или автоматически переформатируют код после
регистрации. Это может работать, если команда все согласовала, однако обычно это
заводит команды в ловушку чрезмерного принуждения.
И даже хуже, люди часто используют эти автоматические инструменты как ду-
бинку, чтобы навязать свое мнение. Возникает соблазн получить техническое реше-
ние межличностной проблемы, однако ничего не получится. Нужно сначала решить
межличностную проблему. Инструменты не знают нюансов. В лучшем случае эти
разногласия будут скрыты. Инструменты не решат проблему, а просто уберут ее из
виду, и она незаметно продолжит расти.
Вместо этого лучше начать, предпо-
Начните с предположения,
ложив, что человек имел добрые наме-
что имелись добрые намерения.
рения. Возможно, он неправильно понял
соглашение, или думает, что оно больше неприменимо, или по каким-то причинам
не может соблюдать это соглашение.
Если кто-то постоянно нарушает командные соглашения, то поговорите с ним
наедине, чтобы узнать, нет ли с его стороны принципиального несогласия. Займите
позицию коллективного решения проблем. Вместо того чтобы спросить: «Почему
ты не работаешь с нулевыми значениями, как мы договаривались?», задайте вопро-
сы: «Что ты думаешь о стандарте работы с нулями, о котором мы договорились?
Не нужно ли нам его изменить?» Примите к сведению все возражения, доведите их
до всей остальной команды и подумайте об изменении соглашения.
Если кто-то согласен с соглашением, но все же не соблюдает его, то, возможно,
оно применимо не в каждой ситуации. Спросите о конкретных случаях, замеченных
вами. И повторюсь: делайте это в манере сотрудничества, а не конфронтации. Скажи-
те нечто вроде: «Я согласен с тобой насчет того, как мы должны работать с нулями.
Можешь объяснить, что происходит в этом случае в данной функции? Я не понимаю,
почему этот код не проверяет на нули».
Во время такого обсуждения вы можете узнать, что человек не понимает сути
соглашения. К этому времени вы уже должны быть в ситуации, которая позволя-
ет обсудить соглашение и его значение. Если это младший член команды и ему
нужна помощь, то координируйте свои действия с остальной командой, чтобы
убедиться в том, что более опытные коллеги-наставники уделяют им достаточно
внимания.
Есть еще одна возможность для команд — новичков в Agile. Изменение рабо-
чих привычек действует разрушительно и может заставить людей думать, что
они потеряли контроль. Иногда они реагируют, отказываясь менять те или иные
мелочи. Упорное желание сохранить определенный стандарт или стиль общения,
независимо от желания остальной части команды, может быть симптомом такой
реакции.
В этом случае, возможно, лучшее решение — позволить нарушению просуще-
ствовать несколько месяцев. Со временем, привыкнув к изменениям в своей среде,
члены команды расслабятся и будут более склонны идти на компромисс.
Рабочие соглашения и коучинг

Рабочие соглашения могут служить полезным инструментом для коучинга. Неко-
торые практики поначалу могут вызывать у людей дискомфорт. Как коуч, я считаю
полезным говорить о том, что люди договорились сделать, вместо того, чтобы
говорить им, что они не делают того, чего я от них хочу.
Например, я тренирую команду, которая согласилась попробовать парное про-
граммирование, но не делает этого. Я не буду говорить: «Вы должны работать
с парным программированием». Вместо этого я скажу: «Я заметил, что люди
не соблюдают соглашение о парном программировании. Как вы думаете, в чем
причина?» Затем я могу снова вернуться к этой теме, спрашивая, применимо ли
все еще соглашение или, возможно, его необходимо изменить.
Вопросы
Что, если мы не можем договориться относительно стандартов и рабочих согла-
шений?
Можно оказать давление на людей, чтобы они приняли соглашение, с которым
не согласны, но это плохая идея. Это несогласие просто будет все время проявляться
в других разговорах.
Вместо этого попытайтесь отпустить ситуацию. Неужели это рабочее соглашение
действительно настолько важно? Сфокусируйтесь на том, с чем вы все согласны.
В процессе работы ваши разногласия разрешатся.
Если это не то, что можно просто проигнорировать, то вашей команде нужна по-
мощь профессионального медиатора. Поговорите с вашим коучем или руководителем
о поиске того, кто может помочь. Такой человек может быть в штате вашего отдела
кадров. В худшем случае может оказаться, что ваша группа просто не подходит для
того, чтобы быть командой, и вам лучше собрать ее из других людей.
У нас есть предыдущая работа, которая не отвечает нашим стандартам. Надо ли
нам ее исправлять?
Тратить много времени на исправление того, что не является неисправностью,
дорого и рискованно, поэтому если ваша предыдущая работа в целом работает, то
оставьте ее и займитесь другими проектами. Приводите каждую часть в соответствие
со стандартом, когда понадобится внести изменения.
Некоторые стандарты, такие как форматирование кода, можно автоматизиро-
вать. Не тратьте на это слишком много времени, но если для вас это не трудно, то
лучше сделать. Не забудьте скоординироваться с другими командами в вопросе
автоматизированных изменений, чтобы не повлиять на их работу, и отделите авто-
матизированные изменения от обычных, чтобы вашу историю контроля изменений
было легко читать.
Члены команды должны хотеть работать как команда, прежде чем смогут создать
эффективные рабочие соглашения. Больше информации о командной поддержке
изменений можно найти в главе 5.
Когда ваша команда имеет эффективные рабочие соглашения:
zz она использует рабочие соглашения для предотвращения и разрешения кон-
фликтов;
zz ваши стандарты повышают читабельность и удобство сопровождения вашего
кода и других артефактов;
zz ваши стандарты позволяют членам команды легче понимать незнакомые части
системы.
Некоторые команды работают вместе настолько хорошо, что им не нужны четкие
соглашения. Их соглашения — подразумеваемые.
Однако прямое обсуждение соглашений поможет новым командам и даже боль-
шинству существующих избежать разрушительных споров в будущем. Точный
формат дискуссии не важен. Формат, представленный в книге, был выбран потому,
что является относительно быстрым и неконфликтным, но вы можете использовать
другой подход.
Придерживайтесь подхода, описанного в этой книге, пока не проведете несколько
успешных обсуждений. Согласование может быть спорным, особенно когда коман-
ды переходят к конкретным соглашениям, таким как стандарты, и именно поэтому
в книге подчеркивается необходимость отмены спорных соглашений.
Получив такой опыт, поэкспериментируйте с изменениями. Помогут ли обсужде-
ния в малых группах или интервью? Можно ли что-то подготовить заранее? Будут ли
другие упражнения более быстрыми или эффективными? Вы можете пробовать
разные варианты, не ограничивая себя.
ЭНЕРГИЧНАЯ РАБОТА Аудитория

Мы работаем в таком темпе, который по- Коучи, вся команда
зволяет нам делать нашу работу наилучшим,
наиболее продуктивным образом сколь угодно
долго.
Я люблю свою работу. Мне нравится решать проблемы, писать хороший код, на-
блюдать за прохождением тестов и особенно удалять код при рефакторинге.
Но если я в команде, которая имеет неясные цели, низкую коллективную ответ-
ственность и погружена во внутренние распри, я буду просыпаться в ужасе от пер-
спективы идти на работу. Я буду находиться в офисе, но не смогу удерживаться от
соблазна проводить утро за чтением своей электронной почты, а потом буду вяло
копаться в коде, одновременно просматривая мало относящиеся к делу сайты.
Мы все бывали в такой ситуации. Мы профессионалы, поэтому стремимся делать
свою работу качественно, даже если чувствуем себя деморализованными. Но все же
вспомните, когда вы были наиболее продуктивными. Вы замечаете, насколько велика
разница, когда вы просыпаетесь и чувствуете стремление начать работу? Не чувству-
ете ли вы себя более удовлетворенным, закончив работу вовремя в конце дня и зная,
что вы сделали нечто важное и нужное?
Практика «Энергичная работа» заключается
в том, что профессионалы могут хорошо выпол- Профессионалы работают
значительно качественнее
нять свою работу и в трудных обстоятельствах,
и продуктивнее, когда полны
однако работают качественнее и продуктивнее,
энергии и мотивированны.
когда полны энергии и мотивированны.
Как быть энергичным

Один из самых простых способов быть энергичным — это заботиться о себе. Уходить
домой вовремя каждый день. Отключаться от работы и проводить свободное время
с семьей и друзьями. Питаться здоровой пищей, заниматься спортом и высыпаться.
Когда вы заняты другими делами, ваш мозг переваривает события дня. Часто бывает,
что утром вы по-новому посмотрите на вещи.
Если качественная жизнь вне работы — это «инь» активной работы, то скон-
центрированность — это «ян». Когда вы на работе, уделяйте ей все ваше внимание.
Отключитесь от всего, что вас отвлекает, например от электронной почты и мессен-
джеров, если они не являются частью вашего виртуального рабочего пространства.
Поставьте телефоны на беззвучный режим. Попросите вашего руководителя оградить
вас от ненужных совещаний и организационной политики.
Когда «инь» и «ян» сбалансируются, вы будете просыпаться по утрам хорошо
отдохнувшим и готовым начать новый день. А в конце дня вы будете уставшим (но
не истощенным) и удовлетворенным выполненной работой.
Это нелегко. Энергичная работа требует поддержки со стороны как рабочего про-
странства, так и домашней среды. Это еще и личный выбор. Невозможно заставить
кого-то быть энергичным. Но вы можете убрать препятствия.
Поддерживайте энергичную работу

Одна из моих любимых техник как коуча — напоминать людям уходить домой во-
время. Уставшие люди совершают ошибки и выбирают неверные решения. Возни-
кающие в результате ошибки в конечном итоге обходятся дороже, чем сама работа.
Это особенно относится к тем, кто приходит на работу больным; помимо того что
эти люди плохо выполняют свою работу, так еще и могут заразить других.
Парное программирование — еще один
способ стимулировать энергичную рабо-
См. также
ту. Оно способствует концентрации, как
никакая другая известная мне практика. Парное программирование (глава 12)
Проведя полный рабочий день за парным
программированием, вы будете уставшим (глава 12)
и удовлетворенным. Это особенно полезно
в те моменты, когда вы не в лучшей форме. Согласование (глава 7)
Работа в паре с кем-то бодрым и бдитель-
ным может помочь сконцентрироваться и вам. Групповое программирование не так
эффективно в удержании концентрации (ее легко потерять), но помогает избежать
ошибок, которые может допускать уставший человек.
Agile-команды основаны на плотном взаимодействии и постоянном общении.
Это может выглядеть как кошмар интроверта, но (я говорю это как интроверт) все
не так плохо, как кажется. Взаимодействие направлено на идеи и результаты, а не на
болтовню. Но даже в этом случае относитесь с пониманием к тому, что интровертам
нужно восполнять энергию, и старайтесь создавать рабочие соглашения, которые
будут помогать вам оставаться энергичными.
Иметь возможность питаться здоровой пищей на работе — еще один способ под-
держивать энергию и активность. Хороший выбор — фрукты и овощи. Пончики
и другая подобная нездоровая, но популярная еда способствуют спаду активности
во второй половине дня.
Природа работы также имеет значение.
Не каждая команда может накормить бедных См. также
или решить NP-полные задачи, но внятная
четкая цель может оказать большое влияние. Цель (глава 7)
Сформулировать и объявить цель команды
входит в обязанности членов команды, име-
ющих навыки менеджмента продукта. См. также
Для того чтобы быть внятной, цель должна
быть также достижимой. Ничто не разруша- Прогнозирование (глава 10)
ет мораль настолько быстро, как ответствен-
ность за недостижимую цель. Если команде необходимо отвечать за соблюдение
определенных сроков и объема работ, то убедитесь, что цели реалистичны и основаны
на прогнозах, сделанных командой.
У каждой организации есть политики, имеющие отношение к цели. В одних
случаях они приводят к здоровым переговорам и компромиссам. В других — могут
приводить к необоснованным требованиям и обвинениям. Члены команды, имеющие
навыки дипломатии, должны заниматься вопросами организационных политик,
информируя остальных о том, что важно, и ограждать от неважного.
Эти члены команды также могут помогать команде, оберегая ее от необязатель-
ных совещаний и конференц-звонков. Если предоставить информативное рабочее
пространство и соответствующие дорожные
карты, то необходимость в статус-митингах См. также
отпадает. При наличии множества внешних
помех рассмотрите возможность ежедневно Информативное рабочее про-
резервировать основные рабочие часы (может странство (глава 9)
быть, для начала всего час или два), в тече- Дорожные карты (глава 10)
ние которых все договорятся не беспокоить
команду.
В каждой организации есть стандартные процессы и технологии, которые коман-
да должна использовать. Когда эти стандарты препятствуют рабочему процессу, это
может разочаровывать и деморализовывать членов команды. Постарайтесь объяснять
«почему» вместе с «что», стоящими за каждым таким стандартом, и давать командам
возможность обсудить создание исключений. Руководители команды могут помогать
команде отстаивать эти изменения и преодолевать бюрократию.
Наконец, команды, находящиеся на уровне нормализации (см. пункт «Нормализа-
ция: мы — № 1» главы 11), обычно полны энергии. Им еще и очень весело. Вы можете
узнать такую команду по тому, насколько ее членам нравится проводить время вме-
сте. Они вместе ходят на обед, обмениваются
шутками и даже могут общаться в нерабочее См. также
время. Вы можете развиться в команде до
уровня нормализации, обращая внимание на Динамики команды (глава 11)
динамики команды.
Делайте перерывы
Если вы стали больше ошибаться, чем продвигаться в работе, то пора сделать
перерыв. Однако если вы похожи на меня, то в моменте как раз труднее всего
остановиться. Мне обычно кажется, что решение вот-вот обнаружится (даже если
это длится последние 45 минут), и я не хочу останавливаться, пока не найду его.
Поэтому полезно, чтобы кто-то другой напомнил мне, что надо остановиться.
Сделав перерыв или хорошенько выспавшись ночью, обычно я сразу нахожу
ошибку.
Иногда вполне достаточно перекусить или
немного прогуляться. Программистам может См. также
помочь предложение поменяться в своей паре
местами. Однако, если уже конец рабочего дня, Парное программирование
(глава 12)
лучше отправиться домой.
В физической командной комнате обычно Командная комната (глава 7)
заметно, когда кому-либо нужен перерыв.
Сердитая сосредоточенность, ругань с компьютером и резкие движения — это
знаки. Если кто-то ушел в себя, не общается — это тоже может значить, что
пора сделать перерыв. Когда я замечаю пару программистов, шепчущихся друг
с другом, я спрашиваю их, сколько времени у них прошло с последнего успешно
прошедшего теста. Часто я получаю робкий ответ и тогда напоминаю им, что пора
отдохнуть.
Предложение сделать перерыв требует определенной деликатности. Если вас
уважают как лидера, то вы можете просто сказать людям, чтобы перестали работать.
В противном случае отвлеките их от проблемы на минуту, чтобы они могли приве-
сти мысли в порядок. Попросите их немного помочь вам в чем-то или прогуляться
с вами, чтобы обсудить проблему, с которой вы столкнулись.
Вопросы
Я работаю в стартапе, и нормальной рабочей недели мне просто не хватает. Могу ли
я работать дольше?
Среда стартапа зачастую наполнена азартом и духом товарищества. Это приводит
к увеличению энергии и может значить, что вы можете работать больше, не теряя
способности к концентрации. В то же время стартапы иногда путают долгие рабочие
часы с преданностью делу. Будьте внимательны, не позволяйте преданности делу
перевесить здравую мысль о том, что вы слишком устали, чтобы вносить полезный
вклад.
У нас важный дедлайн, и нет никакой возможности все успеть, кроме как работать
круглосуточно, не поднимая головы. Нам нужно временно отказаться от обычного
режима работы?
Ничто не может сравниться с многочасовыми хакатонами, когда команда прино-
сит пиццу, все упорно работают не покладая рук и в последний момент все наконец
получается. Мощный марш-бросок перед финишной чертой может помочь команде
сплотиться, позволяя им чувствовать удовлетворение, стоя перед трудностями.
Однако…
Бросок к финишной черте — это одно,

а постоянный спринт на многие киломе- Длительные переработки
тры — другое. Длительные переработки не смогут решить ваших проблем
не смогут решить ваших проблем с плани- с планированием.
рованием, к тому же чреваты серьезными
негативными последствиями. Том ДеМарко называет такие переработки «важной
техникой снижения продуктивности», приводящей к снижению качества, личному
выгоранию, повышенной текучке персонала и неэффективному использованию
времени в течение рабочих часов [DeMarco2002] (гл. 9).
Если вы переработали на этой неделе, то не повторяйте этого на следующей. Если
я вижу команду, работающую таким образом каждый квартал или каждый релиз, то
ищу более глубокие проблемы.
Это контрпродуктивно, но в некоторых организациях судят о сотрудниках по коли-
честву часов переработок. В такой обстановке вам, возможно, лучше пожертвовать
энергичной и дополнительной работой. Это личный выбор, который можете сделать
только вы и ваша семья.
И наоборот, энергичная работа — не повод бездельничать. Создавайте атмосферу
доверия честным ежедневным трудом.
Когда ваша команда энергична:
zz в ней присутствуют азарт и дух товарищества;
zz команда вовлечена в свою работу и стремится сделать ее как можно лучше;
zz команда демонстрирует постоянный еженедельный прогресс, и вы чувствуете,
что способны поддерживать его сколь угодно долго;
zz вы цените здоровье больше, чем краткосрочный прогресс, и чувствуете себя про-
дуктивными и успешными.
Эта практика также называется «Устойчи-
вый темп», и альтернатива ей — хм… «не См. также
устойчивый». Но некоторые организации
делают энергичную работу еще более труд- Парное программирование (глава 12)
ной. Если это происходит в вашей органи- Групповое программирование
зации, то парное или групповое программи- (глава 12)
рование может помочь уставшим членам
команды оставаться сконцентрированными и находить ошибки друг друга. Как
ни странно, работа над вашим ПО займет больше времени (потребуется найти и ис-
править ошибки, допущенные уставшими членами команды), поэтому скорректи-

руйте ваши планы соответствующим образом.
Некоторые организации требуют, чтобы их
сотрудники работали сверхурочно неделю за Одна общая характеристика
неделей. К сожалению, эти гонки на выживание, проектов в стиле гонки
также называемые режимами кризиса, случаются на выживание — низкая
не из-за необходимости получения огромной ожидаемая ценность.
ценности; как раз наоборот. Том ДеМарко и Ти-
моти Листер объясняют:
«Из нашего опыта, общая характеристика проектов в стиле гонок на выжива-
ние — низкая ожидаемая ценность. Это проекты, направленные на выпуск про-
дуктов, имеющих монументальную незначительность. Единственное реальное
оправдание гонки на выживание — это то, что ее ценность настолько мизерная,
что создание проекта по нормальной стоимости явно приведет к тому, что за-
траты превысят выгоду… Если проект настолько необходим, то почему компания
не может выделить время и деньги на то, чтобы сделать его должным образом?»
[DeMarco2003] (гл. 21).
Ваши лучшие эксперименты по взаимодействию с организацией такого типа

будут включать рассылку резюме.

Peopleware: Productive Projects and Teams1 [DeMarco2013] — классическая работа
о мотивации и продуктивности программистов. Она должна быть первой в списке
для чтения у каждого руководителя разработки программного обеспечения.
В книге Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency
[DeMarco2002] рассматриваются последствия длительной сверхурочной работы
и перегрузки.
В книге Joy, Inc.2 [Sheridan2013] описывается, как Menlo Innovations применяет
свой вариант экстремального программирования для создания «энергичного» рабо-
чего места. Это увлекательное произведение написано с точки зрения CEO.
1
ДеМарко Т. Человеческий фактор. Успешные проекты и команды.
2
Шеридан Р. Работа мечты. Как построить компанию, которую любят.
ГЛАВА 8
Планирование
Agile — адаптивный, а не предиктивный подход. В этом его отличие от других (уже

название говорит само за себя!) и одна из причин культурного шока для организа-
ций — новичков в Agile. И ни в чем это не проявляется больше, чем в том, как Agile-
команды планируют свою работу.
В данной главе описаны практики, необходимые для эффективной подготовки
и адаптации ваших планов. Поскольку организациям может потребоваться время
на то, чтобы принять метод адаптивного планирования, здесь также обсуждается,
как Agile-команде следует создавать предиктивные планы.
zz Практика «Истории» поможет вашей команде планировать работу небольшими
частями, ориентированными на интересы заказчика.
zz Практика «Адаптивное планирование» позволит найти баланс между адаптив-
ностью и предиктивностью, фокусируя планы команды на создание ценности.
zz С помощью практики «Визуальное планирование» вы можете создавать планы,
которые отражают контекст и варианты реализации.
zz Практика «Игра в планирование» поможет создать подробный план, направля-
ющий дальнейшие действия вашей команды.
zz Благодаря практике «Вовлечение реального заказчика» команда научится вклю-
чать в свои планы точку зрения заказчика.
zz Используя практику «Инкрементные требования», вы научитесь выяснять детали
требований к продукту непосредственно перед тем, как они понадобятся.
Источники планирования
Agile всегда был адаптивным. Подзаголовок первой книги по экстремальному про-
граммированию звучал как «Примите перемены» (Embrace Change) [Beck2000a].
В предисловии к первой книге о Scrum подчеркивалось, что для снижения риска
необходимо как можно раньше вносить коррективы.
Адаптивность занимает настолько важное место в Agile, что трудно установить ее
конкретные источники. В практике «Адаптивное планирование» объединены идеи,
которые я видел и использовал многие годы; огромное влияние оказала книга
Software by Numbers [Denne2004]. Источники практик «Инкрементные требования»
Глава 8. Планирование 185
и «Вовлечение реального заказчика» также трудно установить, однако название

последней я позаимствовал из второго издания книги по экстремальному про-
граммированию [Beck2004].
Практика «Визуальное планирование» основана на реальных рабочих практиках
многих Agile-команд. Источниками вдохновения послужили карты историй Джеф-
фа Паттона и карты влияний Гойко Аджича, и я добавил обе.
«Истории» — одна из наиболее известных практик Agile. Она зародилась в XP под
названием «Пользовательские истории», а потом упростилась до «Истории» во
втором издании «Экстремального программирования». Практика «Игра в плани-
рование» также пришла из XP.
ИСТОРИИ
Мы планируем нашу работу небольшими
частями, ориентированными на интересы Аудитория
заказчика. Вся команда
Истории (Stories) — вероятно, самая неверно

понимаемая идея всего Agile. Истории — это
не требования и не варианты использования (use
cases). И даже не нарративы. Они гораздо проще, Каждая история —
напоминание о необходимости
чем все перечисленное. поговорить.
Истории нужны для планирования. Это сво-
его рода игральные карты игры в планирование.
И все! Алистер Кокберн называет их долговыми обязательствами для будущей дис-
куссии. Каждая история напоминает о необходимости поговорить о чем-то, что
команде нужно сделать. Их пишут на индексных карточках или их виртуальном
эквиваленте так, чтобы можно было их взять, передвинуть с места на место и пого-
ворить об их месте в ваших планах.
Так как истории просто напоминают о необходимости поговорить, они не должны
быть подробными. Фактически подробные истории — знак того, что люди непра-
вильно их понимают. Предполагается, что у вас должна быть команда, помещение
для нее и вы должны регулярно общаться друг с другом. История — напоминание.
Способ начать обсуждение подробностей.
Хотя истории должны быть краткими, при
необходимости их можно дополнять примеча- См. также
ниями. Если есть что-то важное, что вы хотите
запомнить, или техническая деталь, которую
нужно отслеживать, то запишите это. Но не чув- Командная комната (глава 7)
ствуйте себя обязанными добавить больше дета-
лей. Карточка с историей не должна быть документом с требованиями. Это только
напоминание.
Мастерская писателей
«Нам нужен тренинг на тему, как лучше писать истории, — вздыхает
Рафаэла. — Я уже устала от того, что наша команда делает не то,
что нужно».
Вы не настолько уверены в этом. «Но разве истории не должны
быть просто напоминанием о необходимости поговорить? — спра-
шиваете вы. — Может, нам нужно почаще говорить с владельцем
продукта в процессе работы, задавать ему вопросы, показывать,
над чем мы работаем, — то есть получать обратную связь, чтобы
понимать, делаем ли мы правильный продукт?»
Рафаэла фыркает: «Да. Желаю удачи в этом. Нет, что нам нужно — это чтобы вла-
дельцы продукта Лучше. Писали. Истории. Все на это жалуются. Я позабочусь
о том, чтобы вытрясти на это бюджет. Уверена, я смогу найти инструктора, который
скажет владельцам продукта то, что они должны услышать».
Как написать историю

Все, что нужно сделать вашей команде, кроме
обычной административной работы, требует См. также
своей истории. Именно так работа получает
приоритет. Когда вы узнаете о чем-то, что нуж- Игра в планирование (глава 8)
но сделать вашей команде независимо от вашей
роли в этом, запишите это на карточку и поставьте в очередь, чтобы обсудить на сле-
дующей игре в планирование. Вам всего лишь надо написать минимум, достаточный
для того, чтобы начать обсуждение, и напомнить об этом в дальнейшем. Например:
zz «Отчет о складских запасах»;
zz «Полноэкранная демоверсия для ярмарки вакансий»;
zz «Настраиваемый брендинг на экране входа в систему».
Некоторым нравится использовать ша-
блоны Connextra, чтобы писать истории сле- Вам не обязательно использовать
дующего вида: «Как (роль) я хочу (что-либо), шаблоны историй.
чтобы (результат)». Вы можете использовать
данный формат, если хотите, но это не обязательно. Компания Connextra создала этот
шаблон в порядке эксперимента, чтобы напоминать самим себе, как обслуживать
своих пользователей. Вы можете попробовать провести собственный эксперимент
или просто набросать пару слов.
Хотя истории и короткие, у них все же есть две важные характеристики.
1. Истории представляют собой ценность для заказчика и описываются в его тер-
минах. Они описывают ту работу, которая понятна и имеет ценность для заказ-
чика, а не детали ее технической реализации в вашем будущем ПО. Это позволит
вашему локальному заказчику принимать обоснованные решения о компромиссах

в приоритетах.
2. Истории имеют четкие критерии выполнения. Они не обязательно должны быть
записаны на карточке, но заказчики в команде должны понимать, что значит для
истории быть сделанной, и должны уметь описать это, когда их спрашивают.
Следующие примеры не являются хорошими историями.
zz «Автоматизировать интеграцию сборки» не отражает ценность для заказчика.
zz «Развертывание на промежуточном сервере за пределами файрвола» описывает
скорее детали реализации ПО, чем конечный результат. Не использует терми-
нологию заказчика, и локальным заказчикам, вероятно, будет трудно расставить
приоритеты. Лучше написать «Сделать демо для заказчиков».
Ценность для заказчика

Истории должны быть ориентированы на заказчика (клиентоцентричными). Пишите
их с точки зрения заказчика, таким образом, чтобы они предоставляли нечто полезное
для самого заказчика, пользователей и стейкхолдеров — представителей бизнеса.
За их приоритеты отвечают заказчики в команде; решив, что история не имеет цен-
ности, они не добавят ее в план.
Ориентированные на заказчика истории не обязательно одновременно имеют
ценность и для конечного пользователя, но всегда должны быть ценными с точки
зрения заказчиков в команде. Например, упомянутая история про создание демо
никак не помогает конечным пользователям, но поможет вашему бизнесу продавать
продукт.
Подобным образом некоторые истории могут быть слишком мелкими для ре-
альных заказчиков, чтобы о них беспокоиться. Например, если вы разрабатываете
систему расчетов по кредитным картам, то одна из ваших историй может звучать так:
«Специальная обработка для кода 54, означающего отказ торговой точки». Но за-
казчики в команде должны знать место каждой истории в общей картине и должны
быть в состоянии принимать компромиссные решения о приоритетах. («Мы можем
пока отложить вопрос о коде 54, но просто обязаны обрабатывать код 41, поскольку
это сообщение о мошенничестве».)
Хороший способ сделать ваши истории ориентированными на заказчика — пред-
ложить, чтобы заказчики в команде писали их самостоятельно.
Одно из практических проявлений ориентированности историй на заказчика —

отсутствие историй для технических проблем. Не должно быть истории наподобие
«Дизайн уровня предметной области» — заказчики не будут знать, как расставить
приоритеты. Конечно, разработчики могут рассказать заказчикам, как приоритизи-
ровать технические истории, но это будет отвлекать внимание команды от ценности
продукта и вызывать у заказчиков в команде ощущение собственной бесправности.
Будет лучше распределить технические детали

по всем историям. Например, вместо одной истории См. также
«Дизайн уровня предметной области» инкрементно
изменяйте дизайн вашей предметной области в каж- Инкрементный дизайн
(глава 14)
дой истории. Будет проще, если использовать эво-
люционный дизайн, который мы обсудим в главе 14.
У разработчиков часто бывают трудности с созда-
нием историй, ориентированных на заказчика. Нужно Строгая расстановка
продолжать практиковаться! Без этого заказчикам приоритетов — секрет
в команде трудно принимать взвешенные решения по быстрых релизов ПО.
приоритизации, а строгая расстановка приоритетов —
секрет быстрых релизов вашего ПО.
Чтобы сделать истории ориентированными на заказчика, разработчикам нужно
проговаривать их со своими заказчиками в команде. Объяснить им, какого результата
они хотят добиться, и попросить описать это своими словами. Если нужно, можно
добавить к истории примечание, напоминающее о технологии, с которой связана
эта история.
Например, если вы считаете, что команде нужно перейти на использование дру-
гой технологии базы данных, то можете объяснить это таким образом: «Нам нужно
перенести наши статьи в базу данных, которая лучше обрабатывает полнотекстовый
поиск. Поиск уже занимает более полсекунды, и по мере добавления новых статей
ситуация будет ухудшаться». Заказчик может описать это так: «Остановить снижение
производительности при поиске статей». А вы можете добавить: «(база данных для
полнотекстового поиска)».
Разделение и объединение историй

Истории могут иметь любой размер. Когда у вас впервые возникает какая-либо идея,
ваши истории могут быть большими и пространными: например, онлайн-магазин
мог бы иметь историю «страница оформления заказа».
Однако чтобы обеспечить наглядность и кон-
троль, команде нужно каждую неделю выполнять См. также
несколько историй. Вы можете разделить большие
истории на более мелкие и объединить маленькие Игра в планирование (глава 8)
истории в большие в процессе игры в планирование.
Объединять истории легко. Возьмите несколько взаимосвязанных историй,
скрепите их вместе и напишите новую оценку на лицевой стороне, если используе-
те оценки. В виртуальной среде вырежьте описания историй и вставьте их на одну
виртуальную карточку.
Разделять истории немного сложнее, так как нужно следить, чтобы они оставались
ориентированными на заказчика. Хитрость состоит в том, чтобы найти суть истории,
а не отдельные шаги, которые она подразумевает. Какую фундаментальную цен-
ность предлагает история, а что является ее приукрашиванием сверх этой ценности?
Запишите эту фундаментальную суть как историю, а каждое приукрашивание — как

дополнительную историю.
Если вам трудно это представить, то в книге Майка Кона Agile Estimating and
Planning1 [Cohn2005] есть отличная глава о том, как разделять истории. Он пред-
лагает следующие варианты. (Примеры мои собственные.)
zz Разделять в соответствии с приоритетами. Например, история «Страница оформ-
ления заказа» может быть разделена на истории «Оформление заказа» (высокий
приоритет), «Купоны» (средне-высокий приоритет), «Подарочные чеки» (средне-
низкий приоритет) и «Подарочная упаковка» (низкий приоритет).
zz Разделять по границам данных, поддерживаемых историей. Например, история о сбо-
ре платежной информации может быть разбита на «Сбор информации о кредитной
карте», «Сбор информации о подарочной карте» и «Сбор информации о PayPal».
zz Разделять на основе операций, которые выполняются в рамках истории. Напри-
мер, история об обработке платежей кредитными картами может быть разделена
на «Сбор информации о кредитной карте», «Подтверждение данных кредитной
карты», «Оплата по кредитной карте».
zz Разделять на отдельные CRUD-операции (Create, Read, Update, Delete — создать,
прочитать, обновить, удалить). Например, историю об управлении данными
клиентов можно разделить на «Добавить клиента», «Просмотреть данные кли-
ента», «Редактировать данные клиента» и «Удалить клиента», а также «Список
клиентов» и «Сортировка клиентов».
zz Разделять по межсекторальным задачам (таким как безопасность, ведение журна-
ла операций и обработка ошибок), сделав множественные версии вашей истории.
Например, историю об оплате кредитной картой можно разделить на «Оплата по
кредитной карте», «Регистрация оплаты по кредитной карте в журнале» и «Об-
работка отказа в оплате по кредитной карте».
zz Разделять по нефункциональным задачам (таким как производительность,
стабильность, масштабируемость и т. д.). Например, историю об оплате кредит-
ной картой можно разделить на «Оплата по кредитной карте» и «Поддержка
100–200 транзакций по кредитным картам в минуту».
Лучшие варианты разделения — те, которые позволяют вам приоритизировать
истории по отдельности и в любом порядке. Это требует практики и не всегда воз-
можно, поэтому не волнуйтесь, если вы столкнетесь с трудностями.
Крошечные истории
Чем больше вы разделяете историю, тем труднее может быть сохранять ее ориенти-
рованность на заказчика. Не сдавайтесь. Если не получается, то, по крайней мере,
опишите техническую задачу бизнес-терминами. Это позволит заказчикам в команде
понять суть и сохранить контроль над приоритетами. Вдобавок так вам будет легче
объяснять ваши планы и прогресс другим людям.
1
Кон М. Agile: оценка и планирование проектов.
Например, ваша история «Отправить электронное письмо, когда банковский пере-

вод завершится», с точки зрения программистов, подразумевает следующие задачи.
1. Отправить обратный вызов в банковский сервис.
2. Зарегистрировать в журнале вызов веб-хука (webhook).
3. Захватить веб-хук.
4. Выполнить разбор данных транзакций веб-хука и базы данных запросов.
5. Отправить POST сервису электронной почты.
Превратите их в истории, переформулировав их в бизнес-терминах.
1. Попросить банк уведомить вас о завершении банковского перевода.
2. Записать в журнал уведомления о банковских переводах.
3. Предотвратить поддельные уведомления о банковских переводах.
4. Найти клиента, связанного с уведомлением о банковском переводе.
5. Отправить электронное письмо клиенту, когда получено уведомление о банков-
ском переводе.
Повторю еще раз: лучше иметь независимые друг от друга истории, но и этот
вариант может пригодиться как запасной, если не можете придумать ничего другого.
Специальные истории
Большинство историй добавляет новые возможности в ваше ПО, но все, что требует
внимания команды и не является частью ее ежедневной работы, также нуждается
в истории.
Истории для документации

Чтобы делать свою работу, Agile-командам
нужно совсем немного документации, по- См. также
скольку они используют инкрементные тре-
Инкрементные требования (глава 8)
бования и эволюционный дизайн. Но иногда
команде может понадобиться документация Инкрементный дизайн (глава 14)
по другим причинам. Как правило, такая до-
кументация является частью работы над какой-либо другой, более крупной историей,
но бывают и истории, специально предназначенные для написания документации.
Истории для создания документации такие же, как и все остальные: сделайте их
ориентированными на заказчика и определите специальные критерии их выпол-
нения. Пример истории для документации: «Инструкция по настройке биллинга».
В подразделе «Документация» далее в текущей главе можно найти дополнительную
информацию по этой теме.
Истории для багов

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

дактирования». Запланируйте эти истории как мож- См. также
но раньше, чтобы код оставался чистым и потреб-
ность в ПО для трекинга багов была минимальной.
Истории для багов трудно измерить. Часто Сделано Сделано (глава 9)
больше всего времени при отладке уходит на вы-
яснение того, в чем ошибка, и обычно вы не узнаете, как много времени это займет,
пока не сделаете это. Вместо этого установите временные рамки, например: «У нас
уйдет максимум один день на исследование этого бага. Если мы не починим его за
это время, то обсудим проблему всей командой и запланируем еще одну историю».
На карточке напишите: «Временной отрезок — 1 день».
Нефункциональные истории
Производительность, масштабирование и стабильность (нефункциональные требова-
ния) тоже должны быть запланированы с помощью историй. Как и всем историям, им
нужна конкретная цель, имеющая ценность для заказчика. Однако, в отличие от других
историй, вам понадобится помощь разработчиков, чтобы ее определить. Недостаточно
сказать: «ПО должно быть стабильным» или «ПО должно быть быстрым». Вы долж-
ны быть в состоянии описать, насколько стабильным или быстрым оно должно быть.
Создавая нефункциональные истории, подумайте о приемлемой производитель-
ности (минимально необходимой для удовлетворительных результатов) и наилучшей
возможной производительности — точке, за которой дальнейшая оптимизация мало-
полезна. Вам не нужно записывать эти цифры на карточке или сразу определяться
с ними, но часто бывает полезно это сделать.
Зачем две цифры? Нефункциональные требования, особенно оптимизация про-
изводительности, могут отнять бесконечное количество времени. Иногда вы рано
достигаете наилучшей цели: так вы узнае́те, когда пора остановиться. В других
случаях у вас могут быть сложности в достижении приемлемой цели: благодаря
этому вы понимаете, когда продолжать. Например, критерий производительности
для веб-страницы может быть таким: «Поддерживать 500–1000 запросов в минуту,
с задержкой 50–200 мс».
Как и истории для багов, нефункциональные истории может быть трудно изме-
рить. Для них вы также можете применять ограничения по времени.
Истории для эксплуатации и безопасности

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

историй, обсудите их в терминах той ценности, которую они обеспечивают, а не той
технической работы, которая должна быть проделана.
Часто ценность проявляется в виде снижения риска. Например, история о добав-
лении распределенной трассировки может звучать так: «Облегчить поиск источника
проблем с производительностью во время сбоев производительности (распределенная
трассировка)».
Спайк-истории
Иногда разработчики не могут оценить раз-
мер истории, поскольку недостаточно знают Цель спайк-истории в том, чтобы
о технологии, необходимой для ее реализа- измерить другую историю.
ции. Когда это случается, создайте спайк-
историю (spike story) для исследования технологии. Цель такой истории в том,
чтобы измерить другую историю, а не выработать решение или исследовать все ее
уголки и закоулки. Например, «разобраться, нужно ли разделить историю “отправить
электронное письмо HTML” на более мелкие истории». Или более кратко: «спайк
“отправить электронное письмо HTML”».
Они называются спайк-историями, по- См. также
скольку часто используют спайк-решение
для исследовательской работы. Но это Спайк-решения (глава 13)
не обязательно.
Истории для очистки (clean-up stories)

Ожидается, что Agile-команды будут рабо-
тать таким способом, который позволяет им См. также
работать бесконечно долго. Это возможно
Резерв времени (глава 9)
благодаря наличию достаточного количества
свободного времени в их графике, позволя-
ющего постоянно совершенствовать свою кодовую базу. Если вы правильно органи-
зуете этот резерв, то вам не нужно специально планировать время на очистку. Части
кода, над которыми вы работаете чаще всего, со временем автоматически становятся
чище. Тем не менее иногда вы наследуете плохой код, и тогда стоит потратить до-
полнительное время на его очистку.
Как и все другие истории, истории для
очистки должны быть ориентированы на Вам не нужны обязательные истории
заказчика. И они должны быть полностью для очистки, чтобы поддерживать
необязательными. Вам не нужны обяза- чистоту вашего кода.
тельные истории для очистки, чтобы под-
держивать чистоту вашего кода. Никто не захочет оказаться в ситуации, когда раз-
работчики должны просить у заказчиков разрешения выполнить необходимую им
работу или заказчики вынуждены просить разрешения у разработчиков пропустить
какую-либо историю.
Если вы все же делаете отдельную историю для очистки кода, говорите о ней в тер-
минах бизнес-выгоды, которую она дает. Часто эта выгода заключается в уменьшении
количества времени, необходимого на разработку. Плохой код подвержен ошибкам,
и, как правило, нужно много времени, чтобы безопасно его изменить. Так, например,
вместо того чтобы говорить, что нужен «рефакторинг сервиса аутентификации»,
скажите, что требуется «уменьшить вероятность ошибок аутентификации» или
«уменьшить время, необходимое для изменения параметров аутентификации».
Скорее всего, вы не сможете количественно оценить подобное улучшение, но
будьте готовы привести примеры, иллюстрирующие потенциальные преимущества.
Например, такие: «Вы знаете, что мы продолжаем сталкиваться с проблемами и за-
держками, когда меняем что-то связанное с входом в систему? Так вот, то, что мы
предлагаем, решит данную проблему».
Работая с историями для очистки, не имеющими
четкого момента, когда надо остановиться, используй- См. также
те временные рамки. Чтобы убедиться, что вы можете
остановиться, когда ваше время истекло, избегайте Рефлексивный дизайн
полного переписывания кода. Вместо этого делайте (глава 14)
его постепенный рефакторинг, поддерживая код в ра- Рефакторинг (глава 13)
бочем состоянии в любое время.
Совещания и другие организационные мероприятия

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

Не создавайте отдельные истории для технических
деталей. Решение технических вопросов разработ- См. также
ки входит в затраты на реализацию самой истории.
Используйте эволюционный дизайн и архитектуру, Рефлексивный дизайн
(глава 14)
чтобы разбить большие предварительные технические
требования на маленькие фрагменты, которые вы Рефакторинг (глава 13)
сможете реализовывать инкрементно.
Вопросы
Наши заказчики разбираются в разработке. Нужно ли нам все же писать истории,
ориентированные на заказчика?
Писать истории, ориентированные на заказчика, гораздо труднее, чем истории,
ориентированные на разработчика. Поэтому сложно удержаться от соблазна избежать
этого под каким-нибудь предлогом. «Наши заказчики не возражают против историй,
ориентированных на разработчика» — один из таких предлогов.
Даже если заказчик понимает истории, ори-

ентированные на разработчика, все же истории, Ваш план должен отражать
ориентированные на заказчика, ведут к форми- ценность, и то же самое верно
рованию более качественных планов. Ваш план для историй.
должен отражать ценность, и то же самое верно
для историй.
Если ваши заказчики сами являются разработчиками (если вы разрабатываете ПО
для разработчиков, например библиотеку или фреймворк), то ваши истории могут
использовать ориентированный на разработчиков язык. Но даже в этом случае они
должны отражать точку зрения вашего заказчика. Создавайте истории о потребностях
вашего заказчика, а не о деталях реализации.
Разве разработчики не должны делать программное обеспечение быстрым по
умолчанию? Зачем нам нужны истории о производительности?
В разработке ПО ничего не бывает бесплатно. Вы не обязаны создавать истории
о производительности, но вам нужно знать, что означает «быстрый» в вашей ситуа-
ции, а разработчикам понадобится потратить время, чтобы это реализовать. Разбивка
нефункциональных требований на отдельные истории не меняет количества необ-
ходимого на это времени; она просто позволяет вам лучше понимать, как тратится
данное время, и контролировать этот процесс.
Как нам найти время на техническую инфраструктуру и обширный рефакторинг,
например, на замену тестового фреймворка?
Выполняйте работу подобного рода ин-
крементно, используя эволюционный ди- См. также
зайн и резерв времени в графике вашей
Инкрементный дизайн (глава 14)
команды. Обширный рефакторинг вы мо-
жете выполнять с помощью историй для Рефлексивный дизайн (глава 14)
очистки, но все же обычно лучше подходит Резерв времени (глава 9)
инкрементная работа.
Истории — не замена требованиям. Вам
нужен еще один способ углубиться в дета- См. также
ли — либо с помощью заказчиков в команде
и инкрементных требований (Agile-способ), Инкрементные требования (глава 8)
либо используя документ с требованиями
(традиционный способ).
Когда вы правильно применяете истории:
zz заказчики в команде понимают работу, которую они утверждают и планируют;
zz вам легко объяснить стейкхолдерам, над чем работает команда и почему это
важно;
zz ваша команда работает над небольшими, легко управляемыми фрагментами и до-

бивается ценного для заказчика прогресса несколько раз в неделю;
zz истории дешевы в создании и легко выбрасываются.
Основное различие между историями и составными элементами большинства планов
заключается в том, что истории ориентированы на заказчика. Если вы по какой-либо
причине не можете использовать такие истории, то заказчики не смогут эффектив-
но участвовать в планировании. Это сведет на нет одно из основных преимуществ
Agile — возможность создавать лучшие планы, объединяя знания и представления
заказчиков и разработчиков. Кроме того, вам будет трудно демонстрировать прогресс
стейкхолдерам. К сожалению, никакая другая практика здесь не поможет.
Истории — простая идея, но они связаны с вечной проблемой разработки ПО:
как принять решение, что именно создавать. Простая идея в сумме с серьезной про-
блемой приводят к тому, что у каждого участника имеется собственный взгляд на
истории. Вы можете найти онлайн любые шаблоны и советы по написанию историй.
Все они будут претендовать на то, что смогут решить эту проблему или что с ними
команда будет лучше писать ПО.
Все эти эксперименты, как правило, упускают суть. Истории — для разговора, а не
для бумаги. Любое изменение, которое направляет фокус на документирование, а не
на общение (шаблон, детализация, систематизация историй), движется в неверном
направлении.
Подобным же образом истории — не способ решать, что вы будете создавать. Они
служат лишь напоминанием. Есть много очень хороших способов понять потреб-
ности заказчиков и бизнеса и претворить это понимание в жизнь. (О некоторых из
них рассказывается в разделе «Визуальное планирование» далее в текущей главе.)
Не используйте истории для формирования понимания бизнеса.
Сначала сформируйте для себя понимание бизнеса, примите решение и исполь-
зуйте истории, чтобы напомнить себе об этих решениях и их обсуждениях.
Джефф Паттон говорит, что истории — как фотографии из отпуска: напоминают
вам, что происходило. Истории просто служат напоминанием, поэтому не должны
быть сложными. Когда будете экспериментировать с историями, подумайте о том,
чтобы придать большее значение разговорам и меньшее значение самой истории,
при этом сделав достаточно для того, чтобы напомнить людям предмет обсуждения
и принятое решение. Улучшайте отпуск, а не фотографии.
Наконец, еще одной распространенной альтернативой является отслеживание
историй в электронной таблице или инструменте отслеживания (трекинга) задач,
а не на индексных карточках. Это может облегчить чтение списков историй, но за-
трудняет визуализацию и взаимодействие. Это потеря, которую трудно оценить,
не имея определенного опыта. Поработайте с карточками по меньшей мере три месяца,
прежде чем пробовать альтернативы. Даже если у вас виртуальная команда, лучше
используйте виртуальные индексные карточки на виртуальной доске, а не таблицы
и системы трекинга.
АДАПТИВНОЕ ПЛАНИРОВАНИЕ
Мы рассчитываем на успех.
Аудитория
Представьте, что вас освободили от предва-
рительных планов. «Увеличьте рентабельность Продакт-менеджеры,
инвестиций, — сказал ваш босс. — Мы уже обсуж- заказчики
дали цели этой команды. Я рассчитываю, что вы
проработаете детали. Можете написать собственные планы и сами установить даты
релизов — просто сделайте так, чтобы мы получили действительно ценный продукт».
И что теперь?
Ценные инкременты
Создавайте ваши планы на основе ценных ин- Создавайте ваши планы на
крементов (valuable increments)1. У них есть три основе ценных инкрементов.
характеристики.
1. Пригодность для релиза. Заканчивая работу над инкрементом, вы можете его вы-
пустить и пожинать плоды своих усилий, даже если никогда больше не будете
над ним работать.
2. Ценность. Данный инкремент некоторым образом приносит ценность вашей
организации (см. врезку «Что ценно для организаций?» в главе 3).
3. Инкрементность. Инкремент не делает все сразу. Это только один шаг в нужном
Не путайте ценные инкременты (valuable increments) с потенциально поставля-
емыми инкрементами (potentially shippable increments) — еще одним общим терми-
ном в сообществе Agile. Последние касаются наличия технической возможности
у команды делать релизы изменений. Ценные инкременты — это те изменения, ко-
торые действительно приносят ощутимую пользу вашему бизнесу.
Точно так же ценный инкремент может быть
выпущен только тогда, когда достигнута его цен-
ность. Команды, использующие непрерывное См. также
развертывание, могут разворачивать свое ПО не-
сколько раз в день, но оно не будет выпущено до Непрерывное развертывание
(глава 15)
тех пор, пока не будет переключена конфигурация
и данное улучшение продукта не станет доступно
его целевой аудитории.
Ценные инкременты обычно подпадают под следующие категории.
zz Прямая ценность. Вы создаете, меняете или ремонтируете что-либо имеющее
ценность. Оно становится выпущенным, когда ваша организация может пожинать
1
В первом издании этой книги вместо этапов улучшения продукта, или инкрементов (valuable
increments), я использовал термин «минимальная рыночная функция» (Minimum Marketable
Feature, MMF) из [Denne2004]. Инкременты представляют ту же идею, но я изменил название,
поскольку не все то, что ценно, является востребованным на рынке или функциональным.
плоды этих усилий. Например, если вы хотите улучшить удержание заказчиков,

добавив новый отчет, то сможете считать, что сделали релиз этого отчета, когда
его смогут использовать реальные заказчики.
zz Исследовательская ценность. Вы проводите эксперимент, который должен
дать вам представление о том, как повысить ценность. Можно считать ваш экс-
перимент выпущенным, когда он готов к запуску, включая решение о том, как
интерпретировать результат. Например, если вы предполагаете, что можно уве-
личить количество регистраций клиентов, изменив процедуру регистрации, но
не уверены, какая процедура лучше, то можете использовать A/B-тестирование1.
Релиз этого эксперимента считается сделанным, когда A/B-тест активен, мо-
мент оценки данных определен, как и критерий для сохранения или отказа от
новой процедуры.
zz Ценность функций. Вы создаете возможность отложить или изменить решение,
чтобы можно было воспользоваться преимуществом какой-либо ценной пер-
спективы в будущем. Она считается выпущенной, когда вы можете без проблем
отложить или изменить свое решение. Например, если вы думаете, что ваш по-
ставщик пытается создать благоприятные для себя условия, чтобы поднять свои
цены, то можете изменить свое ПО таким образом, чтобы оно поддерживало вто-
рого поставщика. Эта функция будет считаться выпущенной, когда вы сможете
переключаться между поставщиками по своему желанию.
Инкрементам, имеющим исследовательскую ценность и ценность функций, тре-
буется, чтобы люди чувствовали себя комфортно в условиях неопределенности и не-
однозначности. Поэтому, хотя эти инкременты может применять любая команда, чаще
они используются командами оптимизации.
Вы будете отслеживать ценные инкременты
с помощью историй в вашем визуальном плане. См. также
Например, в предыдущем примере может быть
записано «TPS-отчет», «A/B-тест процедуры ре- Истории (глава 8)
гистрации» и «аутентификация, независимая от Визуальное планирование
поставщика». При желании вы можете добавить (глава 8)
более подробные пояснения, но для большинства Цель (глава 7)
продакт-менеджеров, которых я встречал, корот-
Инкрементные требования
кой фразы было достаточно для напоминания. (глава 8)
Вы должны уметь сформулировать три вещи:
1) почему этот инкремент ценен;
2) как его ценность соотносится с целью команды;
3) что означает «выпущен, сделан релиз» для этого инкремента на высоком уровне.
Детали определяются позже (см. подраздел «Как создать план» далее в данной
главе).
1
A/B-тестирование — это когда вы показываете разные элементы различным группам людей
и оцениваете, какой из элементов дает лучшие результаты.
Фокус на один инкремент за раз

Стейкхолдеры любят, когда команды
работают одновременно над множе- Фокус на выполнении одного
ством идей. Чувствуется, что делается инкремента за раз улучшит скорость
много работы и вся она имеет макси- поставки и повысит ценность.
мальный приоритет! Все так просто.
И очень-очень расточительно. Фокус на выполнении одного инкремента за раз
улучшит скорость поставки и повысит ценность.
Рассмотрим команду, работающую над тремя инкрементами (рис. 8.1). В этом
упрощенном примере все инкременты имеют одинаковую ценность: по завершении
каждый из них будет приносить 4 доллара ежемесячно. Выполнение каждого за-
нимает два месяца.
Рис. 8.1. Результат фокусирования внимания на ценности

В сценарии A команда работает над всеми тремя инкрементами одновременно.

Завершение всех трех занимает шесть месяцев. Закончив, команда начинает полу-
чать 12 долларов ежемесячно.
В сценарии Б команда фокусируется на выполнении одного инкремента за раз.
Она делает релиз своего первого инкремента через два месяца — одну треть времени
сценария А. Он начинает зарабатывать деньги, пока команда работает над следующим
инкрементом. К концу седьмого месяца она заработала 36 долларов за то время, ко-
торое понадобилось сценарию А, чтобы заработать 12 долларов. И это без учета затрат
на переключение между задачами и преимуществ более раннего выхода на рынок.
Это легко полученные деньги.
Чем чаще вы делаете релиз, тем больше по-
лучаете, как показывает сценарий В. Он такой Чем чаще вы делаете релиз,
же, как сценарий Б, за исключением того, что тем больше получаете.
команда научилась делить каждый из своих
инкрементов пополам. Вместо того чтобы делать релиз инкремента стоимостью
4 доллара через два месяца, она делает релиз инкремента стоимостью 2 доллара через
месяц. Через семь месяцев команда заработает 42 доллара.
Конечно, некоторые идеи более ценны, чем другие. Сценарий Г показывает, что
произойдет, если вы отделите наиболее ценные части и будете работать над ними
в первую очередь. Этот сценарий такой же, как сценарий В, но инкременты имеют
разную ценность. Изменение порядка таким образом, чтобы сначала делать релизы
наиболее ценных инкрементов, позволяет сценарию Г заработать 50 долларов. Это
три месяца легких денег по сравнению со сценарием А.
В этом суть свободного владения навыками на уровне фокусировки. Фокус на не-
больших ценных инкрементах. Фокус на выпуске одного инкремента за раз. Фокус
на релизе наиболее ценных идей в первую очередь. После каждого релиза исполь-
зуйте любую новую информацию, которую вы получили, адаптируйте ваши планы
и сфокусируйтесь на наиболее ценном из оставшихся.
Сценарии на рис. 8.1 упрощенные. В книге Software By Numbers [Denne2004]
(гл. 2) приводится более сложный пример (табл. 8.1), основанный на реальном про-
дукте. В своем примере авторы конвертируют пятилетний проект с двумя релизами
в конце проекта (сценарий А) в пять ежегодных релизов, упорядоченных по ценности
(сценарий Б). Производительность команды одинаковая в каждом сценарии.
Таблица 8.1. Реалистичный пример фокусировки на ценности
Сценарий А Сценарий Б
Общие затраты 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 %
Сценарий А — маржинальные инвестиции с доходностью 12,8 %. Этот сценарий

требует инвестиций 2,8 млн долларов и принесет прибыль 1,3 млн долларов. Учиты-
вая риск разработки ПО, инвесторы могут с большей выгодой вложить эти деньги
в другой проект.
Сценарий Б (тот же самый продукт с более частыми релизами) — отличная
инвестиция с доходностью 36,3 %. Хотя затраты при сценарии Б больше из-за про-
ведения большего количества релизов, эти релизы дают продукту возможность
быть самофинансируемым. В результате ему потребуется меньше инвестиций
(1,6 млн долларов) и он принесет прибыль 3,1 млн долларов. Этот сценарий заслу-
живает финансирования.
Взгляните еще раз на эти примеры. Каждый показывает впечатляющие приросты
в ценности. При этом ничего не меняется, кроме способа релизов ПО командами.
Разделите инкременты
Как показали примеры, чем меньше будут инкременты, на которые вы разделите
ваш продукт, тем более ценной будет работа вашей команды. Помимо этого, каждый
инкремент представляет собой возможность изменить направление, не понеся по-
терь. Если вы измените направление в середине работы над инкрементом, то она
будет выполнена частично и ее придется отложить на неопределенный срок или
выбросить. Когда же инкремент завершен, вы можете изменить направление работы,
ничего не теряя.
Чем меньше будут ваши инкременты, тем чаще
вы можете адаптировать ваши планы и тем боль- Чем меньше будут ваши
ше вы будете соответствовать философии Agile. инкременты, тем больше
В идеальном мире ваши инкременты должны вы будете соответствовать
быть разделены на самые мелкие базовые фраг- философии Agile.
менты, которые все еще могут иметь ценность,
оправдывающую их релиз.
В реальном мире трудно сделать эти инкременты настолько маленькими, осо-
бенно поначалу. Со временем вы, вероятно, научитесь видеть способы дальнейшего
разделения инкрементов. Можно начать с лучшего предположения и разделить их
позже. Agile — итеративный процесс. У вас будет множество возможностей для со-
вершенствования.
Минимизируйте объем незавершенной работы

Незавершенная работа (Work in progress, WIP) — это работа, которая была начата,
но пока не завершена релизом. Agile-команды стараются минимизировать ее по
нескольким причинам. Во-первых, это инвестиция, которая ожидает возврата.
Как показано на рис. 8.1 (см. выше), чем чаще вы делаете релиз (чем меньше
у вас незавершенной работы), тем выше окупаемость инвестиций, вложенных
в вашу работу.
Во-вторых, WIP делает изменения более затратными. Когда вы меняете ваши

планы, любую недоделанную работу нужно отложить. Со временем решения,
которые вошли в эту работу, устаревают и должны быть переделаны. Код для
незавершенных инкрементов особенно затратный: он либо увеличивает размер
и стоимость поддержки вашей рабочей кодовой базы в эксплуатационной среде,
либо должен храниться в отдельной ветви, которую становится все более сложно
слить с эксплуатационной средой.
Метафорически можно сказать, что незавершенная работа ржавеет. Ее нужно
или обслуживать, или переделывать, или выбросить. А это затратно. Сведите ее
к минимуму.
Делайте частые релизы и как можно раньше

Вы можете выпускать новые версии ва-
ших инкрементов сразу, как только каж- См. также
дый из них готов, или можете дожидаться
и собирать вместе несколько таких инкре- Непрерывное развертывание (глава 15)
ментов, чтобы выпустить их одновремен-
но в одном релизе. Хотя немедленный выпуск более ценен, иногда может быть эф-
фективнее вывести на рынок несколько улучшений одновременно, чем выкладывать
их по очереди. И похожим образом, если имеются изменения в пользовательском
интерфейсе или другие расходы, связанные с релизом, то может быть проще покрыть
эти расходы разом, чем постоянно делать небольшие изменения.
Некоторые команды используют практику непрерывного развертывания для
развертывания своего кода несколько раз в день, но развертывание кода — это
не то же самое, что релиз инкремента. Релиз инкремента не выполнен до тех пор,
пока недоступен для использования. Для команд, использующих непрерывное
развертывание, в релиз обычно входит изменение параметров конфигурации.
Иногда команды объединяют инкременты, поскольку технические ограничения

делают частые релизы слишком затратными. Так делать можно, если вам это необходи
мо, но будьте честны с собой насчет причин этого. Вдобавок к высоким затратам на рели
зы вы несете дополнительные расходы, связанные с увеличением количества незавершен
ной работы. Вы можете устранить оба вида затрат путем инвестирования в свободное
владение навыками на уровне поставки.
Некоторые команды планируют ре-
лизы с помощью процесса релизов по рас- Поезд всегда должен отбывать вовремя,
писанию, поезда с релизами (release train). по расписанию.
Он представляет собой запланированную
серию релизов, например, первый понедельник каждого месяца. Завершенные
инкременты «садятся в поезд» и добавляются в данный релиз. Остальные ждут
следующего поезда. Неважно, насколько они близки к завершению, поезд всегда

должен отбывать вовремя, по расписанию.
Фреймворк SAFe определяет Agile Release Train как контейнер для команд, что
является неудачным переопределением термина1. Здесь я использую более
простое оригинальное определение. Поезд с релизами — это просто заплани-
рованное расписание релизов. Не придавайте ему дополнительного смысла.
Поезда с релизами имеют множество преимуществ. Они дают маркетологам повод

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

Ваш релиз-менеджер, Иезекиль, созвал на встречу всех владель-
цев продукта: «Следующий поезд с релизами отправляется через
три месяца! Что вы обязуетесь поставить?»
Вы быстро обмениваетесь взглядами с Лавоной, одной из владе-
лиц продукта, и она изображает взмах кнутом. Вы сдерживаете
ухмылку и спешно надеваете маску «командного игрока», как
только Иезекиль обращает на вас внимание.
На прошлой неделе вы заставили свою команду сделать оценки и взять на себя
обязательства, но с каждым кварталом ребята становятся все более угрюмыми.
«Хештег — без оценок!» — сказала потом Роза, ваш лучший разработчик, прежде
чем подать уведомление об увольнении. Вы информируете Иезекиль о принятом
1
Термин «поезд с релизами» появился задолго до SAFe. Самые ранние известные мне упоми-
нания о нем есть в фреймворке разработки программного обеспечения 1993 года от компании
Sun, который определяет этот термин таким же образом, как и я в этой книге. Данный документ
отсутствует в публичном доступе, но [Rothman1998] ссылается на этот термин и использует
похожее определение. Большое спасибо Говарду Феару и Дэйву Хаунслоу за то, что нашли эти
ссылки.
обязательстве, но уже переживаете о том, на что будут похожи следующие три

месяца.
Когда вы медленно бредете со встречи, Лавона идет рядом, издавая тихое мыча-
ние: «Му-у-у-у-у. Ты же знаешь, что коровы в поезде едут на бойню, да?» — говорит
она. Вы киваете и вздыхаете. «Я знаю, кто возьмет на себя ответственность, если
мы не справимся с этой поставкой».
Лавона останавливается и смотрит вам в глаза. «Я тут проводила небольшое
исследование. Agile не должен быть таким. Мы не должны подстегивать наши
команды, а потом принимать вину на себя, когда что-то не получается».
«Конечно, — соглашаетесь вы. — Роза говорит, что мы работаем по итеративному
“водопаду”, а не по Agile, но что мы можем сделать?»
Лавона улыбается: «Здесь? Не очень много. Но у меня есть предложение о работе,
и они хотят, чтобы я привела с собой еще одного хорошего продакт-менеджера.
Ты участвуешь?»
Она рассказывает подробности, и ваше настроение улучшается. Пришло время
сойти с этого поезда.
Ваш первый инкремент

Ваш первый инкремент может быть непростым. Ему нужно быть достаточно со-
держательным, чтобы быть интересным, но не настолько, чтобы вы ради него за-
держивали релиз.
Один из способов думать о вашем первом инкременте — использовать термин
минимально жизнеспособный продукт (Minimum Viable Product, MVP). Вопреки
обычному пониманию этого термина, MVP — это не самый маленький продукт,
пригодный для успешного релиза. Это скорее способ подтверждения ваших идей
продукта. Эрик Рис определяет этот термин в своей очень авторитетной книге The
Lean Startup1 следующим образом:
Минимально жизнеспособный продукт (MVP) помогает предпринимателям как
можно скорее начать процесс обучения. Однако это не обязательно минимальный
продукт, который только можно себе представить; это просто самый быстрый
способ пройти через цикл обратной связи «Создать — измерить — узнать»
(Build — Measure — Learn), приложив минимум усилий.
В отличие от традиционной разработки, которая обычно подразумевает длитель-
ный инкубационный период и стремится к совершенствованию продукта, MVP
ставит целью начать процесс обучения, а не закончить его. В отличие от испыта-
ний прототипов или тестов концепции, MVP предназначен не только для того,
чтобы ответить на вопросы о дизайне продукта или его технической реализации.
Его цель — проверить фундаментальные бизнес-гипотезы [Ries2011] (гл. 6).
Эрик Рис
1
Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.
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).
Думайте о вашем плане, что это и план изучения, и план создания. Сфокусируйтесь
на том, что вы не знаете. В чем вы не уверены? Что могло бы быть хорошей идеей?
Какие хорошие идеи вы можете проверить и подтвердить на практике? Не гадайте,
создавайте инкременты для изучения. Тестируйте каждую неясность, затем адап-
тируйте план.
Например, если бы вы создавали онлайновый текстовый процессор, то могли бы
не знать точно, насколько обширной должна была быть ваша поддержка импорта
документов Microsoft Word. Какая-то поддержка необходима, но какая? Реализа-
ция поддержки всех документов Word займет много времени. Добавление других,
возможно более ценных, функциональностей также потребует времени. В то же
время недостаточная поддержка может подорвать доверие к вам и привести к по-
тере клиентов.
Чтобы проверить эту неясность, вы можете добавить в ваше ПО элементарную
функцию импорта (ясно обозначив ее как экспериментальную), выпустить ее и со-
брать сообщения о типах документов, которые пользователи пытаются импортиро-
вать. Информация, которую вы соберете, поможет вам адаптировать план и повысить
ценность вашей команды.
Пользователи сетевого ПО привыкли к бета-версиям веб-приложений, так что
в этом случае выпуск экспериментальной, незавершенной функциональности
возможен. Чтобы выпустить продукт, предназначенный для более требователь-
ных пользователей, может понадобиться использовать программу пререлиза,
фокус-групп или какой-либо другой механизм получения обратной связи.
Последний ответственный момент

Agile-команды откладывают принятие необратимых решений до позднейшего от-
ветственного момента1. Принятие решений в позднейший ответственный момент
снижает ваши затраты и повышает вашу приверженность идеям Agile.
Представьте, что вы злой деспот, действующий в условиях жесткого графика.
Вы пообещали вашему императору, что вернете проект строительства его новой
игрушки для уничтожения планет обратно в рамки графика. А теперь все засто-
порилось. Были кое-какие сложности, которые вы не могли предвидеть. Чтобы
сохранить лицо, вы говорите императору, что его новая боевая машина полностью
вооружена и в рабочем состоянии, хотя это не совсем так. А дальше, как вы знаете,
отважная группа фотогеничной молодежи уничтожает вашу Звезду Смерти. Опять.
Чем раньше вы принимаете решение, тем больше вероятность, что вы упу-
скаете что-то важное. И если это так, то вы должны либо переделать работу,
либо смириться с плохим решением. Это расточительно. Ожидая позднейшего
1
Lean Construction Institute ввел термин «позднейший ответственный момент». [Poppendieck2003]
популяризировал его применительно к разработке ПО.
ответственного момента, вы повышаете свою информированность, что дает вам

возможность выбирать лучшие решения, которые, в свою очередь, приведут
к меньшим потерям. При этом будет проще вносить изменения, поскольку у вас
будет меньше работы, которую придется отменить или переделать.
Обратите внимание, что используется выражение «позднейший ответственный
момент», а не «позднейший возможный момент». Как говорит [Poppendieck2003],
принимайте критическое решение «в тот момент, когда непринятое решение
приведет к потере важной альтернативы. Если обязательство откладывается на
период после позднейшего ответственного момента, то принимается решение по
умолчанию, что в принципе не является хорошим подходом к принятию решений».
Как создать план

Инкременты являются строительными блоками вашего плана, но не имеют никаких
деталей. Проработка деталей требует много времени и труда. Хуже того, когда воз-
никает необходимость адаптировать планы, часть этого труда может отправиться
в мусор.
Чтобы снизить потери и облегчить про-
цесс планирования, применяйте метод на- См. также
бегающей волны, предполагающий планиро-
вание в позднейший ответственный момент. Цель (глава 7)
При использовании этого метода детали до- Визуальное планирование (глава 8)
бавляются постепенно, точно перед тем, как
Игра в планирование (глава 8)
в них возникает необходимость. Период, на
который каждый уровень детализации смо- Планирование задач (глава 9)
трит в будущее, называется горизонтом пла- Инкрементные требования (глава 8)
нирования. Планы в Agile имеют несколько
горизонтов планирования (рис. 8.2).
1. Начните с цели команды, в которую будет входить ее миссия.
2. Используйте визуальное планирование для создания карты возможных ценных
инкрементов, необходимых для выполнения миссии.
3. Продолжайте использовать визуальное планирование, чтобы разбить первые не-
сколько инкрементов на наименьшие ценные инкременты, которые вы сможете
придумать.
4. Используйте игру в планирование, чтобы еще больше разбить первые мелкие
инкременты, в истории размером «в самый раз».
5. Применяйте планирование задач, чтобы разбить первые несколько историй на
задачи разработки.
6. Непосредственно перед началом разработки истории используйте инкрементные
требования, чтобы определить детали требований.
Рис. 8.2. Горизонты планирования
В подразделе «Ваша первая неделя» главы 9 рассказывается, как начать работу.

Как только план будет готов, вы начнете использовать систему вытягивания для его
выполнения. В такой системе вместо того, чтобы делать работу запланированными
интервалами, вы делаете ее по требованию. В этом случае «вытягивание» происходит
вследствие завершения задач.
1. Когда ваша команда завершает выполнение своих задач, ей нужны следующие.
Вы планируете задачи, вытягивая истории из визуального плана на вашу команд-
ную рабочую доску, где разбиваете их на задачи.
2. В процессе вам может понадобиться больше историй. Когда это происходит, вам
нужно запланировать сессию игры в планирование и вытянуть истории из вашего
следующего маленького ценного инкремента.
3. Когда вы закончите один инкремент, вам нужно использовать визуальное плани-
рование, чтобы вытянуть следующий маленький инкремент из ваших возможных
инкрементов.
4. А когда вам понадобится больше идей для возможных инкрементов, вы вытянете
их из ваших цели и миссии.
5. И наконец, приблизившись к завершению вашей миссии, вы пойдете к своему
спонсору и вытянете новую миссию из концепции и цели вашей команды.
Как показывает рис. 8.3, для каждого уровня детализации нужны разные навыки.
Рис. 8.3. Навыки планирования
Пример плана
Представьте, что ваша команда отвечает за сайт онлайн-магазина. Как в вашем
случае планировать методом набегающей волны? Ниже представлен упрощенный
пример, который показывает, как уровни детализации сочетаются друг с другом.
1. Цель. Общее ви́дение вашей команды — быть ведущим продавцом в вашей
рыночной нише. Ваша специальная миссия — улучшить коэффициент конвер-
сии: сделать так, чтобы больше людей посещало сайт с целью что-либо купить.
2. Возможные ценные инкременты. Чтобы выполнить эту миссию, вы думаете
о нескольких возможных ценных инкрементах. Одна из идей — улучшить работу
сайта на мобильных устройствах. Другая — улучшить страницу оформления
заказа. Третья — улучшить работу поиска. Четвертая — предоставлять кури
руемые обзоры товаров.
3. Наименьшие ценные инкременты. Обсудив идеи с различными стейкхолде-
рами, вы решаете, что улучшение страницы оформления заказа будет наи-
более выгодным. Многие покупатели уходят с сайта, дойдя до этой страницы.
Вы предлагаете идеи наименьших ценных инкрементов, какие только можете
придумать: поддержку подарочных карт, запоминание данных кредитных карт
покупателей, добавление поддержки купонов, поддержку PayPal и т. д.
4. Истории размером «в самый раз». Как показывает ваше исследование рынка,
покупателям из Европы менее комфортно использовать кредитные карты
онлайн, и ваша статистика говорит о том, что максимальное количество

прерванных попыток заказа совершают именно европейцы. Вы решаете, что
вашим следующим инкрементом будет поддержка PayPal. Вы собираете всю
команду, чтобы разбить инкремент на более мелкие составляющие. Вместе
вы разрабатываете более подробные истории, в том числе: «Встроить Pay-
Pal в страницу оформления заказа», «Разрешить использование PayPal для
подписок», «Обработка ошибок PayPal», «Обработка сбоев PayPal», «Возврат
платежей через PayPal», «Интерфейс поддержки покупателей для оплаты
через PayPal».
5. Задачи. Во время планирования задач вы выбираете несколько историй,
над которыми команда будет работать в первую очередь, и разработчики
разбивают их на задачи. «Интерфейс поддержки покупателей для оплаты
через PayPal» получает такие задачи, как «Перенести CS UI в текущую версию
фреймворка фронтенда», «Добавить PayPal к фронтенду CS» и «Добавить
PayPal к бэкенду CS».
6. Детали. Пока разработчики закладывают основы, UX-дизайнер команды
создает макет, показывающий потенциальные изменения в поддержке поль-
зовательского интерфейса, и просматривает его с представителями отдела
клиентской поддержки. После этого разработчики используют макет в качестве
руководства для изменений, потом просматривают окончательный результат
с другими локальными заказчиками и отделом клиентской поддержки.
Баланс адаптивности и предсказуемости

Каждый уровень детализации в вашем плане имеет соответствующий горизонт
планирования. Например, рис. 8.2 показывает, что задачи планируются на следующую
неделю, истории — на следующий месяц; маленькие инкременты планируются на
следующие три месяца, а возможные — на следующие шесть месяцев.
Эти горизонты планирования — только пример. Вы должны выбрать собственные,
основываясь на том, как будете соблюдать баланс адаптивности и предсказуемости.
Например, если ваши планы меняются значительно, то можете готовить истории
размером «в самый раз» только за две недели и маленькие инкременты всего за один
месяц до непосредственной даты начала
работ. Вместе с тем если вашим стейкхол-
Выбирайте ваши горизонты
дерам нужно больше определенности, то вы планирования, основываясь на
можете создавать истории размером «в са- том, как будете соблюдать баланс
мый раз» за три месяца и маленькие инкре- адаптивности и предсказуемости.
менты — за шесть месяцев до даты начала
работ.
Чем длиннее ваши горизонты планиро-
вания, тем больший объем работы окажется См. также
напрасным в случае изменения ваших пла-
нов и тем больше людей будут сопротив- Дорожные карты (глава 10)
ляться изменениям. С другой стороны, бо- Прогнозирование (глава 10)
лее длинные горизонты планирования часто
необходимы для хороших дорожных карт, а горизонт планирования ваших историй

определяет, насколько далеко в будущее могут заглядывать ваши прогнозы релизов.
В конечном итоге выбор горизонтов планирования — компромисс между мень-
шим количеством потерь и большей гибкостью, присущей Agile (более короткие
горизонты планирования), и большей определенностью и предсказуемостью (более
длинные горизонты планирования). Неправильного ответа тут нет; только выбор
между компромиссами. Если вы не знаете, что выбрать, начните с горизонтов, по-
казанных на рис. 8.2.
Адаптивное планирование в действии

Через несколько лет после свадьбы мы с женой провели двухмесячный отпуск
в Европе. Это была самая сложная поездка, которую мы когда-либо совершали.
Мы знали, что не могли полностью спланировать ее заранее, поэтому выбрали
адаптивный подход.
Мы начали с нашего ви́дения этой поездки: договорились побывать во многих
городах, вместо того чтобы оставаться на одном месте. Мы обсудили, какие
страны хотели увидеть, но не приняли никаких решений, которые обязывали бы
нас посетить конкретную группу стран.
Мы определили позднейший ответственный момент для различных решений по
нашей поездке. Авиабилеты обычно дорожают со временем, поэтому мы забро-
нировали перелеты в Лондон и обратно за месяц и запланировали побыть там
с родственниками в начале и в конце поездки. Гостиницы, однако, нужно было
уведомить за несколько дней до приезда.
Мы также предприняли шаги, которые дали бы нам больше возможностей.
Мы нашли хороший путеводитель по Европе. Мы купили проездной EuroRail,
позволявший использовать прекрасную европейскую систему железных дорог
для путешествий по всему континенту. Мы заплатили несколько дороже за про-
ездной, но он давал нам возможность посетить больше стран.
Приняв эти общие решения, мы оставили детали на позднейший ответственный
момент. Во время поездки, за несколько дней до выезда в направлении следу-
ющего места, мы принимали решение, какие именно страну и город посетим.
Мы останавливались около железнодорожных станций, смотрели расписание
отбытия поездов и при необходимости резервировали билеты. Мы смотрели ин-
формацию об отелях в нашем путеводителе, отправляли электронные письма трем
наиболее понравившимся и продолжали наслаждаться прогулками по городу.
На следующий день мы подтверждали одну из броней отеля. В последний день
мы бездельничали и выбирали из расписания поездов время для выезда. Затем,
через 4–5 часов, мы приезжали в следующий город, оставляли вещи в гостинице
и отправлялись смотреть город.
Такой подход не только давал нам свободу действий, но был еще и простым
и расслабляющим. Поскольку мы бронировали номер за день или два до приезда,
ни один отель никогда не терял и не путал наши бронирования. Если город нам
нравился, то мы оставались в нем подольше. Если не нравился — уезжали раньше.
В наш медовый месяц мы были рабами своих заранее подготовленных планов
и все время беспокоились о деталях поездки. В этой же поездке, гораздо более
длительной и сложной, нам было нужно думать только о планах на следующие

несколько дней.
Кроме того, такая гибкость позволила нам испытать то, что иначе мы бы не испыта-
ли. В Италии мы поняли, что наше намерение посетить Турцию приведет к потере
массы времени на дорогу. Вместо этого мы воспользовались проездным EuroRail
и поехали в Северную Европу. В результате мы получили одни из самых запо-
минающихся впечатлений в тех городах, посетить которые никогда не ожидали.
Набросав примерный план заранее, оставляя открытыми варианты и принимая
окончательные решения в последний ответственный момент, мы организовали
себе гораздо лучший отпуск, чем могли бы в любом другом случае. Таким же
образом, когда вы используете адаптивное планирование в разработке ПО,
перед вами возникают непредсказуемые возможности, что позволяет повысить
ценность вашего ПО.
Адаптивное планирование и организационная культура

Идея провести два месяца, путешествуя по чужой стране без определенного плана,
выглядит пугающе? На практике все было просто и расслабляюще, но когда я рас-
сказывал историю нашей адаптивно спланированной поездки в Европу (см. врезку
«Адаптивное планирование в действии» чуть выше), люди заметно беспокоились.
Организации часто похожим образом реагируют на адаптивное планирование.
Адаптивный план работает на достижение цели команды. Однако точно так же, как
мы в нашей поездке достигли своей цели («получить удовольствие от посещения
множества европейских городов»), не выбирая заранее конкретные города, адаптив-
ная команда достигнет своей цели, даже если не сможет точно сказать, что именно
она будет поставлять.
Никакой другой аспект Agile не бросает
больший вызов организационной культуре, Никакой другой аспект Agile
чем адаптивное планирование. Оно требует не бросает больший вызов
изменений не только в команде разработки, организационной культуре, чем
но и в системах отчетности, оценки и управ- адаптивное планирование.
ления. Последствия выбора адаптивного
планирования удивительным образом распространяются на разные подгруппы
вашего сообщества стейкхолдеров, и люди часто испытывают шок и демонстрируют
эмоциональные реакции в ответ на эту идею.
В результате вы, возможно, не сможете повлиять на процесс изменений, движу-
щийся в сторону адаптивного планирования. Если у вас нет поддержки со стороны
высшего руководства, то любые изменения будут медленными и постепенными.
Даже с поддержкой руководства эти изменения займут много времени.
Чтобы вводить адаптивное планиро-
вание постепенно, попробуйте работать См. также
в рамках вашей организационной культуры.
Используйте планирование методом набега- Прогнозирование (глава 10)
ющей волны, но установите ваши горизонты
планирования так, чтобы они совпадали с ожиданиями вашей организации. Кроме

того, вам, возможно, понадобится делать прогнозы, что, как правило, требует сво-
бодного владения навыками на уровне поставки. Когда ваши стейкхолдеры проник-
нутся доверием к вашей способности предоставить результат, сократите горизонты
планирования и переходите к более адаптивному плану.
Вопросы
Нам нужно принять на себя обязательство делать релиз в определенные даты. Как
поступить?
Прочитайте раздел «Прогнозирование» главы 10. Если вы делаете прогнозы
по дате и объему работы, то вам могут понадобиться удлинение вашего горизонта
планирования и, как правило, свободное владение навыками на уровне поставки,
чтобы ваши прогнозы были полезны.
Если мы не планируем детально наши релизы, то что мы должны говорить о на-
ших планах стейкхолдерам?
Вы можете не планировать заранее все нюансы ваших релизов, однако все же
можете показать стейкхолдерам дорожную карту. Если им нужно много деталей,
то вам, возможно, понадобится удлинить ваш горизонт планирования (см. раздел
«Дорожные карты» главы 10).
Если мы используем короткие горизонты планирования, то как мы можем быть
уверены, что достигнем цели команды?
Если вы не уверены, что сможете достичь цели вашей команды, используйте ваш
план для того, чтобы понять, сможете ли вы это сделать. Вам может понадобиться
создать специальные инкременты для обучения, удлинить ваш горизонт планирова-
ния или сделать маленький релиз с ограниченной доступностью для тестирования
критически важных концепций. Детали будут зависеть от вашей ситуации, поэтому,
если вы не уверены, что делать, попросите совета у наставника.
Адаптивное планирование требует участия руководителя и стейкхолдеров (см. гла-
ву 5). Любая команда может планировать в рамках своих ценных инкрементов. Кроме
того, это зависит от имеющегося у вас объема поддержки.
Работа над одним инкрементом за раз — это разумный и легкий способ повысить
ценность вашей команды. Несмотря на его полезность, работа над одним элементом
за раз вызывает отвращение у некоторых стейкхолдеров. Действуйте осторожно.
Частые релизы требуют того, чтобы ваши заказчики и пользователи могли при-
нимать такие релизы. Для большинства сетевого ПО это не проблема, поскольку
пользователям не приходится ничего делать, чтобы получить обновление. Другие
виды ПО могут требовать болезненных процедур развертывания, а некоторые даже
дорогостоящих сертификационных тестов. Это может осложнить частые релизы.
Создание экспериментов, опций и MVP требует, чтобы ваша организация смирилась
с неопределенностью и верила, что у вашей команды достаточно знания рынка, чтобы
принимать правильные решения. Обычно это требует от вашей команды свободного
владения навыками на уровне оптимизации.
Планирование методом набегающей волны требует четкой цели и регулярных

обновлений плана. Используйте его, если уверены, что можете пересматривать
план по меньшей мере раз в неделю. Включите в команду людей, имеющих навыки
обновления и пересмотра плана.
Адаптация планов требует того, чтобы ваша организация думала об успехе в тер-
минах ценности, а не в стиле «поставлено вовремя, в рамках бюджета и в соответствии
со спецификацией». Некоторым организациям бывает трудно принять такую идею.
Возможно, вы сможете смягчить страхи, связанные с адаптацией планов, обязавшись
делать релиз в определенную дату, но при этом оставив подробности этого релиза
неопределенными.
Наконец, будьте осторожны, составляя планы, не предусматривающие релиза
в ближайшие три месяца. Хотя эти цели по выпуску не должны рассматриваться
как обязательства, легко сбиться с курса без какой-либо контрольной точки и сроч-
ности ближайшей цели.
Когда вы создаете, поддерживаете хороший план и обмениваетесь им в коммуникациях:
zz он показывает, как команда достигнет своей цели или узнает, как ее достичь;
zz члены команды уверены, что план достижим;
zz вы выпускаете релизы ценного продукта регулярно и постоянно.
Когда вы хорошо адаптируете ваш план:
zz вы постоянно ищете возможности узнать что-то новое о вашем плане, продукте
и стейкхолдерах;
zz в процессе этого вы меняете план так, чтобы в нем использовались преимущества
новых данных.
Адаптивное планирование повышает ценность благодаря гибкости в планировании
и стратегическому подходу к релизам. Ищите возможность снижать затраты времени
на планы, которые впоследствии отменяются, ускоряйте петлю обратной связи, чаще
совершенствуйте ваши планы и сокращайте время до получения готовой ценности.
Если у вас нет команды поставки, то могут возникнуть вопросы о том, как плани-
ровать техническую инфраструктуру. [Denne2004] предлагает сложную методологию
инкрементного финансирования (Incremental Funding Methodology, IFM), отвеча-
ющую на этот вопрос. Команды со свободным
владением навыками на уровне поставки из- См. также
бегают этой необходимости, поскольку исполь-
зуют эволюционный дизайн для инкрементно- Инкрементный дизайн (глава 14)
го построения технической инфраструктуры.
Команды, имеющие определенный продукт,
не всегда нуждаются в усложненном плане. Вместо того чтобы думать в терминах
инкрементов или релизов, эти команды отталкиваются от маленького списка историй
и постоянно выпускают небольшие изменения. Вы можете рассматривать это как

адаптивный план с очень короткими горизонтами планирования.
И наконец, адаптивное планирование часто рассматривается как альтернатива
предиктивному, но, как показывает подраздел «Баланс адаптивности и предсказу-
емости» данной главы, скорее является комплексом различных горизонтов плани-
рования. Если вы работаете в среде, где требуется предиктивное планирование, то
подумайте, сколько адаптивных идей вы можете использовать вместе с длинными
горизонтами планирования.

Software By Numbers [Denne2004] предоставляет убедительные и подробные аргу-
менты в пользу проведения частых релизов.
В главе 3 книги Lean Software Development [Poppendieck2003] обсуждаются преи
мущества отсрочки принятия решений и долгого сохранения вариантов открытыми.
В книге The Principles of Product Development Flow [Reinertson2009] автор глубоко
погружается в принципы, лежащие в основе адаптивного планирования. Книга ориен-
тирована скорее на физические продукты, чем на ПО, однако ее все же стоит прочитать.
ВИЗУАЛЬНОЕ ПЛАНИРОВАНИЕ
У нас есть карта пути к достиже-
нию нашей цели. Аудитория
Продакт-менеджеры, заказчики
Ваш план — ключ к достижению цели
вашей команды. Вместо того чтобы го-
ворить «делайте это, потом вот это, а затем вот то», составьте план, позволяющий
визуализировать ваши варианты, и адаптируйте его в процессе работы. Визуальное
планирование позволяет сделать это.
Возможности для визуального планирования бесконечны. Здесь мы обсудим че-
тыре техники. Вы можете следовать одной из них буквально, как написано, соединять
несколько или создавать новые визуа-
лизации, полностью ваши собственные. Правильной является визуализация,
Правильной является визуализация, которая работает для вашей команды
которая работает для вашей команды и ваших стейкхолдеров.
и ваших стейкхолдеров.
Кто планирует?
Визуальное планирование проводится
членами команды, обладающими навы- См. также
ками управления созданием продук-
та, при помощи заказчиков в команде. Вся команда (глава 7)
Постарайтесь также привлечь ключе- Вовлечение реального заказчика (глава 8)
вых стейкхолдеров, по крайней мере,
к составлению краткого плана, и ищите возможность привлечь реальных заказчиков.

Если будут учитываться их точки зрения, то качество ваших планов улучшится.
Разработчики могут активно участвовать или нет по усмотрению вашей команды.
Многие разработчики предпочитают не посещать некоторые собрания — и, по прав-
де говоря, им действительно лучше тратить свое время на что-то другое. В то же
время разработчикам пойдет на пользу углубленное понимание плана, и их точка
зрения часто улучшает планы. Я склонен оставлять это решение на усмотрение
каждого разработчика.
Даже если разработчики не участвуют, они
все же должны понимать план и давать обрат- См. также
ную связь. Зарезервируйте время на обсуждение
плана с разработчиками. Подходящим момен- Игра в планирование (глава 8)
том для этого может быть игра в планирование.
Картирование кластеров
Картирование кластеров (Cluster Mapping) (рис. 8.4) — самый простой и гибкий,
а также наиболее эффективный способ визуализировать ваши планы. Это моя лю-
бимая техника.
Рис. 8.4. Карта кластера

1. Подготовьте истории с помощью мозгового штурма

Чтобы создать карту кластера, сначала взгляните
снова на цель вашей команды, затем примените См. также
одновременный мозговой штурм (см. пункт «Рабо-
тайте одновременно» главы 7), чтобы сгенерировать Цель (глава 7)
истории, соответствующие этой цели. Вы можете Истории (глава 8)
записывать любые истории, которые вам нравятся, Адаптивное планирование
но помните, что они должны быть краткими, и не (глава 8)
слишком вдавайтесь в детали. Вы начинаете с обще-
го плана в долгосрочной перспективе.
Например, если ваша цель — улучшить коэффициент конверсии для вашего он-
лайн-магазина, то вы можете написать истории наподобие «улучшенная поддержка
мобильных устройств», «собственное мобильное приложение», «курируемые обзоры
товаров», «улучшенная страница оформления покупки» и т. д.
2. Сгруппируйте истории в инкременты

После мозгового штурма сгруппируйте истории (см. пункт «Работайте одновремен-
но» главы 7), используя картирование сходства, затем поделите кластеры на ценные
инкременты (см. подраздел «Ценные инкременты» ранее в данной главе). Одни
истории станут самостоятельными инкрементами, другие сформируют инкремент,
когда будут собраны вместе. Для последних создайте новую историю, целиком пред-
ставляющую ценный инкремент.
Отметьте каждую историю, которая представляет собой ценный инкремент.
Для физических карточек мне нравится использовать забавный стикер, например,
звезду или лицо с улыбкой. Работая с виртуальными эквивалентами, я меняю цвет
карточки. Оставшиеся истории можно сохранить или выбросить в зависимости от
того, насколько они ценны, по вашему мнению.
3. Организуйте инкременты
Сделайте шаг назад и подумайте об инкрементах в контексте цели вашей команды,
затем реорганизуйте их так, чтобы они лучше отражали ваше представление о том,
как эта цель будет достигнута. Некоторые инкременты окажутся не относящимися
к делу или относящимися к слишком далекому будущему. Их можно удалить или
отложить.
Некоторые инкременты будут отражать разные способы достижения одного
и того же результата. Если вы не уверены, что выбрать, то сохраните оба! Ваш план —
карта, а карты показывают разные пути к пункту назначения. Вы даже можете за-
хотеть добавить несколько инкрементов исследовательского типа, которые помогут
вам выбрать варианты.
У вас может оказаться несколько инкрементов, которые не имеют прямого от-
ношения к цели вашей команды, но все равно должны быть выполнены. Добавьте
их на доску.
4. Проверьте и уточните
Когда вы это сделаете, вернитесь немного назад и посмотрите на карту еще раз.
Затем подправьте, если нужно, получившиеся кластеры и добавьте примечания,
чтобы карту было легче объяснить. Вам нужно иметь возможность использовать
карту в качестве визуальной подсказки, когда понадобится описать, как ваша коман-
да будет достигать своей цели.
В этой точке у вас есть краткий план,
показывающий возможные ценные ин- См. также
кременты, над которыми уже может ра-
Вовлечение реального заказчика (глава 8)
ботать ваша команда. Это подходящий
момент, чтобы сделать перерыв и за-
просить обратную связь от членов команды, реальных заказчиков и других стейк-
холдеров, которые не присутствовали при подготовке карты. Дальше вы можете
углубиться в детали.
Дальнейшая разбивка инкрементов

Как описывалось в разделе «Как создать
план» ранее в данной главе, общий план См. также
будет состоять из множества уровней
детализации.
1. Цель.
2. Возможные ценные инкременты.
3. Наименьшие ценные инкременты.
4. Истории размером «в самый раз».
Вы начали с цели вашей команды и использовали ее для того, чтобы создать
возможные инкременты. Теперь вам нужно разбивать их на еще более мелкие
элементы.
1. Проведите мозговой штурм для разработки историй

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

страница оформления заказа», то вы можете разбить его на следующие меньшие
инкременты: «Запоминать данные кредитных карт», «Оформление платежа через
PayPal», «Подарочная упаковка», «Купоны» и т. д.
2. Фильтруйте и повторите
Далее проанализируйте новые инкременты и удалите (или пока отложите) те, кото-
рые не относятся к делу или относятся к слишком далекому будущему. Оставшиеся
разделите на «высокий приоритет» и «невысокий приоритет».
Повторяйте шаги 1 и 2, пока у вас достаточно маленьких инкрементов с высо-
ким приоритетом, чтобы заполнить ваш горизонт планирования для «Наименьших
ценных инкрементов». Например, если вы используете горизонты планирования,
показанные на рис. 8.2 (см. выше), то остановитесь, когда наберете маленьких ин-
крементов на три месяца работы.
Просто используйте свое внутреннее ощущение размеров. Вы не делаете реаль-
ную оценку, просто решаете, когда остановить планирование, так что не стоит
останавливаться слишком рано. Самое важное — найти маленький инкремент,
над которым ваша команда будет работать в первую очередь. Вы всегда можете
разбить больше инкрементов чуть позже.
И наконец, посмотрите на инкременты, которые вы еще не разбили. Могут какие-

либо из них содержать маленькие инкременты с приоритетом, более высоким, чем
у тех, которые у вас уже есть? Если это так, то разбивайте и их.
3. Расставьте приоритеты
Когда закончите, остановитесь и подумайте,
не приходят ли вам в голову какие-нибудь См. также
новые идеи. Затем решите, как вам приори-
Дорожные карты (глава 10)
тизировать маленькие инкременты с высо-
ким приоритетом. Как минимум отметьте Прогнозирование (глава 10)
один, чтобы выпустить его первым, и еще
один для предполагаемого второго релиза. Оставшиеся тоже можно приоритизиро-
вать или пока оставить в зависимости от того, что указано в вашей дорожной карте
и прогнозах.
Если вы используете физические индексные карточки, то запишите приоритет
на маленький стикер и приклейте его на карточку. Таким образом, когда ваши
приоритеты изменятся, вы сможете просто переклеить стикеры, не переписывая
карточки.
На этом уровень детализации «Маленькие инкременты» завершается. Это еще
один удобный момент сделать перерыв и запросить обратную связь.
4. Сыграйте в игру в планирование

Финальный уровень детализации вашего
визуального плана — разбивка ваших ма- См. также
леньких инкрементов на истории размером
«в самый раз». Для этого используйте игру
в планирование. Когда закончите, у вас бу-
дет набор историй для каждого из ваших самых высокоприоритетных инкрементов.
Разместите каждый набор на доске рядом с соответствующим инкрементом.
Если вы прогнозируете релизы, то можете добавить их даты на доску. Оконча-
тельный результат будет выглядеть примерно как на рис. 8.4 (см. выше).
Карты влияния
Иногда вам нужно больше вариантов структуры, чем могут обеспечить карты класте-
ров. Карты влияния (impact maps), показанные на рис. 8.5, — отличный инструмент
для исследования доступных вам вариантов1.
Никогда не стремитесь реализовать всю карту. Лучше найдите на ней самый
короткий путь к цели! [Adzic2012] (с. 12–13).
Гойко Аджич
Рис. 8.5. Карта влияния
1
Большое спасибо Гойко Аджичу за его советы в этом подразделе.
Карта влияния — тип ментальных карт (mind maps). Если вы с ними не зна-
комы, то ментальные карты — это иерархическое дерево идей. Вы начинаете с ос-
новной идеи в центре карты. Идеи, относящиеся к ней, ветвятся из центра и соз-
дают собственные узлы. От каждой из этих идей ответвляются дополнительные
идеи. И т. д.
В данном случае на карте влияния «Почему» (цель) находится в центре, за
ней следует «Кто» (влияющие стейкхолдеры), «Как» (влияния) и «Что» (ин-
кременты).
Чтобы создать карту влияния, используйте вашу доску для визуального плани-
рования. В виртуальную доску может быть встроена функция карт влияния. Если
у вас физическая доска, то используйте для узлов индексные карточки разного
цвета. При необходимости их можно будет с легкостью передвигать. Как всегда,
лучше работайте все вместе, чтобы избежать образования узких мест в рабочем
процессе.
1. Начните с цели
Начните с вашей цели. Это «Почему» на карте
влияния, и она размещается в центре. Данная См. также
цель должна некоторым образом иметь отно-
шение к цели вашей команды. Это может быть Цель (глава 7)
сокращенная версия вашей миссии, следующих
тестов миссии или и то и другое. На карте влияния все зависит от цели. Это пункт
назначения, и карта покажет вам, как до него добраться. В примере команды «Снеж-
ный человек» (см. врезку «Пример цели» в главе 7) целью должно быть «100 команд-
покупателей».
2. Определите влияния с помощью мозгового штурма

Следующий уровень карты влияния — «влияю-
щие стейкхолдеры», но, как правило, далее лучше См. также
использовать мозговой штурм для определения
влияний. Это «Как» карты влияния. Как могут Контекст (глава 7)
люди, находящиеся за пределами команды, по-
мочь вам достичь вашей цели? Как они могут помешать этому? Каких изменений
вы бы хотели в их поведении? Если вы создали диаграмму контекста (см. пункт
«Границы и взаимодействия» главы 7), то группы стейкхолдеров, перечисленные
на этой диаграмме, могут подать вам новые идеи.
Например, существующие заказчики «могут порекомендовать нас в социальных
сетях» или отраслевые журналы могут «публиковать положительные отзывы». Поста-
райтесь включить и негативные влияния, например регуляторы, которые «повышают
требования к аудиту», или конкуренты, которые «меняют модель ценообразования».
Поговорите о том, как их поведение отличается от сегодняшнего: если регулятор
уже требует аудит, то правильной формулировкой влияния будет не «требование
аудита», а «повышение требований по аудиту».
3. Определите влияющих стейкхолдеров

Скорее всего, вы в итоге получите широкий выбор возможных влияний. Удалите те,
которые не заслуживают внимания или находятся в слишком далеком будущем. Для
остальных определите влияющих стейкхолдеров (группы, внешние по отношению
к вашей команде, включая другие группы в вашей компании), которые создают
влияния. Поместите их на карту на уровень «Кто», между целью и их влиянием.
Сделайте шаг назад и осмотрите всю доску. Не хватает каких-нибудь важных
участников? Подумайте об их влиянии и добавьте их на доску. Затем посмотрите на
нее еще раз. Ищите недостающие влияния и удаляйте не относящиеся к делу.
4. Приоритизируйте влияния
До этого момента вы мыслили широко и генерировали варианты. Теперь настало
время сфокусировать ваше мышление. Какие влияния критичны для достижения
вашей цели? Какие представляют собой легкодоступные цели? Какие являются
предположениями, которые необходимо протестировать? Выберите влияния с самым
высоким приоритетом. При работе в группе вам может помочь точечное голосование
(см. пункт «Работайте одновременно» главы 7).
После того как вы приоритизировали влияния, подумайте над прикреплением кон-
кретных целей к максимальным влияниям. Например, влиянию «рекомендуйте нас
в социальных сетях» может соответствовать цель «100 рекомендаций в социальных
сетях в неделю». Это поможет вам понять ваш прогресс. Иногда вам будет удаваться
достичь цели раньше, чем вы ожидали, и тогда вы сможете изменить приоритеты.
В других случаях вы узнаете, что ваши усилия ничего не меняют, и вам понадобится
сделать больше, чтобы проверить ваши предположения.
5. Определите инкременты с помощью мозгового штурма

Теперь вы готовы к «Что» карты влияний.
Это ваши возможные инкременты. Заман- Цель карты влияний —
чиво думать о них как о наиболее важной сфокусировать ваше внимание
части карты, но это не так! Цель карты влия на вашей цели и влияниях.
ний — сфокусировать ваше внимание на
вашей цели и влияниях, которых вы хотите добиться (или, наоборот, уменьшить).
Для этого, конечно, вы используете инкременты, но считать их самым главным — это
словно говорить, что машина — самая важная часть дорожного атласа. Для поездки
она необходима, да. Для карты — нет.
Подумайте о способах, с помощью которых ваша команда может поддержать
каждое положительное влияние, уменьшить каждое негативное или узнать больше
о предположениях, которые требуют проверки. Формулируйте ваши идеи в общих
чертах. Например, касательно поддержки заказчиков, рекомендующих вас в со-
циальных сетях, вы можете добавить «Автоматически публиковать скриншоты»
и «Публиковать отзывы».
Один из возможных подходов к работе с инкрементами — подумать о том, как можно
упростить рабочий процесс или вызвать изменения в поведении людей. «Автоматически
публиковать скриншоты» выполняет обе задачи: вызывает изменение в поведении

людей (за счет увеличения взаимодействия в социальных сетях) путем упрощения
процесса (обычно это требует совершения множества действий: сделать скриншот,
отформатировать его, открыть приложение социальной сети и вставить его туда).
На данный момент у вас есть общий краткий план. Это подходящий момент для
того, чтобы сделать перерыв и запросить обратную связь. На следующем шаге вы
будете разбивать возможные инкременты на наименьшие ценные инкременты.
6. Разбейте инкременты на более мелкие составляющие

Начните с поиска возможностей разделения влияющих стейкхолдеров и влияния, а не
инкрементов. Например, влияние «Рекомендуйте нас в социальных сетях» можно по-
делить на «Рекомендуйте нас в Twitter» и «Рекомендуйте нас в Facebook». Влияющих
стейкхолдеров можно поделить на «новых заказчиков» и «существующих заказчиков».
Закончите так, как было описано в подразделе «Дальнейшая разбивка инкре-
ментов» выше в данной главе. Окончательный результат будет выглядеть так, как
показано на рис. 8.5 (см. выше).
Перспективный анализ
Перспективный анализ, изображенный на рис. 8.6, помогает вам генерировать идеи,
представляя будущие результаты. Он особенно хорошо работает в качестве инстру-
мента управления рисками. Кроме того, вы можете использовать перспективный
анализ в качестве самостоятельного инструмента планирования или как введение
в другой подход к планированию.
Рис. 8.6. Перспективный анализ

Один из видов перспективного анализа — диаграмма влияния и вероятности

(Impact and Probability chart), описанная в книге Дианы Ларсен и Эйнсли Нис
Liftoff: Start and Sustain Successful Teams [Larsen2016]. Диаграмма довольно проста
и эффективна.
1. Создайте диаграмму
Чтобы создать диаграмму, нарисуйте большой график на вашей доске для ви-
зуального планирования или в ее виртуальном эквиваленте. Пронумеруйте
вертикальную ось от –3 до +3, что будет представлять собой результат от «очень
плохо» до «очень хорошо», и нарисуйте горизонтальную прерывистую линию на
уровне отметки «0». На горизонтальной оси отметьте диапазон от «Не произой-
дет» до «50/50» и далее до «Произойдет». Нарисуйте вертикальную прерывистую
линию на отметке «50/50».
2. Определите вероятные результаты

с помощью мозгового штурма
Теперь примените технику одновременного мозгового штурма, чтобы предполо-
жить, что может произойти в будущем вашей команды: с командой, стейкхолдерами
и вашим ПО. Запишите каждый вариант на индексную карточку. Подумайте как
о позитивных, так и о негативных результатах.
Участники могут прикреплять свои карточки на диаграмму сразу или дожидаться
окончания сессии мозгового штурма. Добавляя карточки, участники должны раз-
мещать их в соответствии с вероятностью записанного на карточке события (го-
ризонтальная ось) и того влияния, которое будет им оказано, если данное событие
случится (вертикальная ось).
3. Проверьте и уточните
После того как все карточки будут на доске, остановитесь, чтобы внимательно про-
смотреть их расположение и скорректировать его. Это можно сделать одновременно.
Результат будет похож на рис. 8.6 (см. выше).
4. Определите приоритетность результатов

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

Карты историй (Story maps), представленные на рис. 8.7, особенно полезны, когда
нужно сфокусироваться на том, как используется ваше ПО1. Они могут использо-
ваться сами по себе, или вы можете с их помощью конкретизировать инкремент,
созданный путем применения другого подхода.
Рис. 8.7. Карта историй
Карты историй описывают реальную ак-

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

Начните создание карты историй с просмотра вашей цели и контекста. Кто пользо-
ватели вашего ПО? Кто покупатели, которые будут за него платить? Какие другие
программные системы будут с ним взаимодействовать? Какие преимущества полу-
1
Большое спасибо Джеффу Паттону за его советы в этом подразделе.
чит каждый? Как это соотносится с целью вашей

команды и ценностью, которую ожидает ваша орга- См. также
низация?
На основе этого решите, какую тему или темы Цель (глава 7)
будет охватывать ваша карта историй. Вам не нужно Контекст (глава 7)
накладывать на эту карту абсолютно все. Как говорит
Джефф Паттон, «создать карту — это просто рас-
сказать историю»1. Выберите начало и конец вашей Создать карту — это просто
истории. В нашем примере с онлайн-магазином вы рассказать историю.
можете рассказать историю о том, что происходит,
когда кто-либо покупает какой-либо товар.
Дальше вам нужно решить, хотите ли вы создать карту «сейчас» или карту
«потом». Карта «сейчас» описывает, что люди делают сегодня. Она помогает вам
поставить себя на их место. Обычно вам лучше начинать с карты «сейчас», если вы
не слишком хорошо понимаете, как будет использоваться ваше ПО.
Карта «потом» описывает, что люди делают после того, как у них появилось
новое ПО. Обычно вы конвертируете карту «сейчас» в «потом», представляя, как
ваше ПО улучшит ситуацию. Но вы можете создать карту «потом» и напрямую.
2. Определите шаги
Создайте карту историй, буквально рассказывая, что происходит: сначала это, по-
том вот это, затем вот то. Она может охватывать несколько пользователей и систем:
«Я делаю это, затем Татьяна делает вот это, потом система бэкенда совершает вот
эти действия».
Записывайте каждый шаг (также называемый пользовательская задача (user
task)2) на индексной карточке, стикере или в виртуальном эквиваленте. Для примера
с онлайн-магазином вы можете расписать шаги «искать товар», «читать отзывы»,
«добавить в корзину», «нажать “оформить”» и т. д. Расставьте их по порядку от
первого до последнего.
Если вы создаете карту «сейчас», то добавьте примечание о том, как все работа-
ет на практике. Сделайте примечание о недостатках и о том, что работает хорошо.
Вы также можете написать, сколько времени занимает каждый шаг или как часто
они происходят, — все, что, по вашему мнению, может быть полезным позже, когда
вы будете думать об улучшениях.
Карты историй могут занимать много места. В физической командной комнате вы
можете использовать свободную большую стену и стикеры вместо белой доски
и индексных карточек. Используйте суперклейкие стикеры — вы же не хотите
вернуться после долгих выходных и найти свою карту на полу!
1
2
Джефф Паттон использовал термин «пользовательские задачи» в [Patton2014], но позже пере-
ключился на «шаги». Это помогает избежать путаницы с задачами в разработке.
Расписав все шаги, осмотрите всю карту от начала до конца и заполните все про-
белы, какие найдете. Потом начните расширять свои представления об элементах
карты. Как другие люди делают что-то другим образом? Что происходит, когда
что-то идет не так? А что, если все идет отлично? Напишите новые стикеры для
таких вариаций и добавьте их столбиком под соответствующим им шагом. В конце
взгляните на изначальный список шагов и переместите те из них, которые кажутся
дополнительными, ниже соответствующих им шагов.
В процессе работы у вас будут появляться новые идеи, которые потребуют
реорганизации вашей карты. И это хорошо. Когда закончите, у вас будет горизон-
тальная линия шагов, рассказывающих историю о том, что делают пользователи,
и вертикальные линии вариаций, альтернатив и деталей, спускающиеся вниз от
горизонтальной линии. У вас должна быть возможность «пройти по карте» от на-
чала до конца, выбирая разные шаги из каждого столбца, чтобы рассказать разные
версии одной истории.
Иногда люди будут иметь разные мнения о том, в каком порядке расставить шаги.
Просто выберите наиболее типичный порядок. До тех пор, пока вы можете рассказать
историю, имеющую смысл, точный порядок шагов не важен.
3. Выделите активности пользователя

Теперь преобразуйте карту в активности пользователя — набор шагов, которые вы-
полняются вместе. Например, вы можете сгруппировать «Ввести адрес для выставле-
ния счета», «Ввести адрес доставки» и «Ввести данные кредитной карты» в единую
активность «Оформление покупки». Пометьте каждую активность пользователя
цветным стикером, разместив его над первым шагом в этой активности. Некоторые
активности могут иметь только один шаг.
4. Идентифицируйте результаты и цели

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

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

лучше — наилучший». Для каждого изменения спрашивайте: «Какой способ сделать
это достаточно хорош для пользователей?», «Какой способ лучше?», «А какой способ
наилучший?» Каждая идея получает собственный стикер. Так образуется коллекция
компромиссов, из которых вы сможете выбирать, когда будете принимать решения
об инкрементах и адаптировать свои планы.
Когда закончите, сделайте перерыв и запросите обратную связь от членов команды,
пользователей и других стейкхолдеров, которые не присутствовали при обсуждении.
6. Разделите карту на инкременты

Теперь, когда ваша карта историй готова, вы можете подумать о том, как разбить ее
на ценные инкременты. Для начала взгляните на активности пользователей (верхний
ряд). Можете разделить их так, чтобы сформировать множество ценных инкрементов?
Это не всегда будет возможно, но если можете, то сгруппируйте активности в ин-
кременты, нарисовав вертикальные линии. Проверьте, что каждый из них является
ценным сам по себе и его можно выпустить отдельно.
Например, если активности в вашей карте онлайн-магазина были «Найти товар»,
«Оформить покупку» и «Отследить доставку», то вы можете создать два инкремента:
«Найти товар + Оформить покупку» и «Отследить доставку».
Далее взгляните на результаты (горизонтальные полосы). Какие из них могут
быть выпущены отдельно? Иногда каждый результат представляет собой ценный
инкремент. Возможно, вы даже сможете разделить шаги, принадлежащие какому-
либо из результатов, на множество инкрементов. В других случаях вам может пона-
добиться сгруппировать множество результатов, чтобы сформировать инкремент.
Нарисуйте квадратные рамки вокруг инкрементов. Получится что-то похожее на
рис. 8.7 (см. выше). Снова сделайте перерыв и получите обратную связь.
7. Сыграйте в игру в планирование

Получившиеся в результате квадраты —
это ваши наименее ценные инкременты. См. также
Дальше вам нужно доработать их с по-
мощью игры в планирование. Шаги «по- Игра в планирование (глава 8)
том», детали и вариации (отклонения)
в каждом квадрате — это истории, которые вы возьмете с собой в игру в плани-
рование. Когда это будет сделано, отправьте получившиеся истории обратно на
вашу карту историй.
Обновление визуального плана

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

большие поправки.
Как минимум проверяйте свой план каждую неделю. Как только команда за-
канчивает работу над историями и инкрементами, проверяйте свои горизонты пла-
нирования и вытягивайте больше деталей, как написано в подразделе «Как создать
план» выше в данной главе
Вопросы
Что, если мы вынуждены использовать корпоративный инструментарий, который
не позволяет нам сделать собственный визуальный план?
Не позволяйте корпоративным инструментам мешать вам создавать и адапти-
ровать ваш план. Если вам необходимо использовать такой инструмент, то рас-
сматривайте его как еще одну точку зрения на ваш реальный план, как описывается
в подразделе «Корпоративные системы отслеживания» главы 10. Делать двойную
работу, конечно, расточительно, но хороший визуальный план — настолько ценная
вещь, что оно того стоит.
Как нам сконвертировать визуальный план в такой формат, который хотят
видеть наша организация и стейкхолдеры?
Есть много вариантов в зависимости от того, какая степень детализации нужна
вашей организации. Прочитайте раздел «Дорожные карты» главы 10.
Для визуального планирования требует-
ся командная комната, приспособленная См. также
для совместной работы. Виртуальным
командам необходимо программное при-
ложение, представляющее собой вир-
туальную белую доску. В физическом помещении понадобятся большой стол,
магнитная белая доска и индексные карточки или стикеры.
Не используйте для вашего плана специальные инструменты для управления
жизненным циклом Agile и инструменты для трекинга открытых вопросов. Они
не имеют никакого отношения к Agile. Они сделаны для удовлетворения капризов
карго-культа крупных Agile-компаний и только повредят вашей гибкости. Вам
нужна возможность создавать и настраивать визуализацию произвольной формы,
не ограничиваясь этими инструментами. Белая доска или ее виртуальный эквива-
лент — лучшие способы сделать это.
Для команд, работающих в офисе, физическая доска будет гораздо более эф-
фективной, чем виртуальная. Тактильные ощущения, вызванные ее использова-
нием, резонируют с умственной работой человеческого мозга, что приносит такие
результаты, на которые экран просто не способен. Трудно понять, насколько это
эффективно, пока сами не испытаете это. Постарайтесь использовать физическую
доску и карточки.
Визуальное планирование также требует

руководства людьми, обладающими навыками См. также
менеджмента продукта и разбирающимися в сфе-
ре деятельности заказчика. Без их участия вы, Вся команда (глава 7)
конечно, сможете создать визуальный план, но Цель (глава 7)
он не будет хорошим. Имеет большое значение
и ясная цель.
Результат будет еще лучше, если вы пригласите ключевых стейкхолдеров и ре-
альных заказчиков на ваши сессии планирования или, по крайней мере, запросите
их обратную связь по черновым версиям вашего плана. Без обратной связи вы под-
вергаетесь риску туннельного видения. Вы можете построить что-то, что вам будет
казаться правильным, но на самом деле не будет выполнять требования людей.
Когда вы создаете и правильно доводите до участников визуальный план:
zz стейкхолдеры и члены команды понимают не только, что будет сделано, но и по-
чему это будет сделано;
zz взаимосвязи между частями вашего проекта хорошо видны;
zz стейкхолдеры и члены команды вносят новые идеи в результате более глубокого
понимания контекста.
Вы можете сразу начать экспериментировать с этой практикой. Попробуйте каж-
дую из представленных здесь карт по отдельности, затем в разных комбинациях
и добавьте собственные идеи. Правильного ответа нет, так что экспериментируйте
с любыми идеями, какие только сможете найти или придумать. Не бойтесь что-то
менять; я меняю свои визуализации каждые несколько месяцев и каждый раз нахожу
новые идеи и ощущаю азарт от открывающихся возможностей.
Есть много способов визуализации планов. Один стартап, с которым я работал,
создал диаграмму бизнес-приоритетов в четырех категориях («развитие бизнеса»,
«контроль затрат», «снижение рисков», «расширение возможностей»). Каждая из
идей получила свой стикер в соответствии с приоритетом. Были сотни идей, и только
нескольким из них был присвоен высокий приоритет. Остальные постоянно пере-
мещались в разных направлениях, так как основатели стартапа выдвигали новые
идеи и пересматривали старые.
У другой команды было множество обязательств, привязанных к определенным
датам. Команда разработала календарь обязательств с колонкой для каждой недели.
Карточки, представлявшие собой обязательства на каждую неделю, приклеивались
к соответствующей колонке. Каждую неделю команда просматривала обязательства,
приближающиеся по срокам, и добавляла их в планирование задач этой недели.
Существует множество и других вариантов. Экспериментируйте свободно!

Impact Mapping [Adzic2012] — исчерпывающее руководство по картам влияния. Оно
короткое, легкое для чтения, содержит много полезных советов. Если вы применяете
карты влияния в своей практике, то его стоит приобрести.
User Story Mapping1 [Patton2014] — исчерпывающий справочный материал по
созданию карт историй. Это захватывающая книга, содержащая много полезного
об историях и планировании в целом.
Innovation Games2 [Hohmann2006] содержит огромное количество упражнений,
которые помогут вам визуализировать и создавать ваши планы. Обратитесь к ней,
когда будете готовы адаптировать визуализации, представленные в этой книге, под
свои потребности.
ИГРА В ПЛАНИРОВАНИЕ
В наших планах используются знания
и опыт как бизнеса, так и разработки. Аудитория
Вы можете точно знать, что вы хотите сде- Вся команда

лать, но как вам составить пошаговый план?
Здесь вам поможет игра в планирование.
Несмотря на название, игра в планирование — не просто развлечение. В эконо-
мике понятие «игра» относится к ситуации, где «игроки выбирают действия и вы-
игрыш зависит от действий всех игроков»3. Вот что такое игра в планирование.
Это кооперативная игра, предназначенная для того, чтобы создавать наилучший
выигрыш из возможных.
Игра в планирование примечательна тем, как максимизирует количество инфор-
мации, вложенной в ваш план. Она поразительно эффективна. У игры в планирование
есть ограничения, однако если вы работаете внутри них, то я не знаю лучшего способа
выяснить все детали вашего плана.
Игра в планирование — всего лишь часть
вашего общего процесса планирования. Это См. также
способ разбить ценные инкременты, пригод-
ные для отдельного релиза, на истории мень- Истории (глава 8)
шего размера. В конце игры в планирование Цель (глава 7)
у вас будет набор историй размера «в самый Визуальное планирование (глава 8)
раз» для разработки. Напомню:
1) цель представляет собой общую цель и текущее направление;
2) визуальное планирование определяет варианты для ценных инкрементов;
3) игра в планирование обеспечивает пошаговый план, который вы будете использо
вать для разработки каждого инкремента.
1
Паттон Дж. Пользовательские истории. Искусство гибкой разработки ПО.
2
Хоманн Л. Бизнес-игры: создание революционных продуктов с помощью клиентов.
3
Это определение игры пришло из Глоссария международной экономики (А. Дирдорффа) (https://
oreil.ly/IsTY2).
День планирования
Сегодня опять день планирования, и вы в ужасе от этого. Вы точно
знаете, что будет происходить. Сначала Захария и Мисси опоздают
минут на десять-пятнадцать. Потом Ладонна с помощью про-
ектора выведет ваш баг-трекер на стену. Она прочтет историю,
в том числе все детальные требования, критерии готовности
и все остальное. Все будут говорить об этом. Потом будет что-то
вроде оценочных шагов с помощью покера планирования. Джон
будет жаловаться, что оценка слишком велика. Клео скажет, что
историю надо разбивать на более мелкие. Филлис скажет, что она уже потратила
несколько часов на требования и менять истории — слишком большая работа.
Корнелл скажет всем, чтобы просто продолжали работать. В конце концов после
10 минут болезненных споров у вас будет оценка, Ладонна внесет ее в систему,
и вы перейдете к следующей.
И так снова и снова. Это так мучительно и занимает долгие часы. Наверняка есть
способы лучше.
Как играть
Цель игры в планирование — сфокусировать
команду на работе, которая обеспечит наи- Каждое решение сделать что-то
лучший возврат инвестиций. В конце кон- является также решением не делать
цов, каждое решение сделать что-то является что-то другое.
также решением не делать что-то другое.
Разработчики лучше всего информированы о затратах (они наиболее квалифи-
цированны, чтобы сказать, сколько работы потребуется для реализации истории),
поэтому задают размер историй.
Заказчики в команде больше всех знают о ценности продукта (они наиболее
квалифицированны, чтобы сказать, что именно важно), поэтому приоритизируют
истории.
Члены команды, у которых есть как опыт в разработке, так и знания о заказчике,
могут играть обе роли в игре в планирование, но лучше, если они будут придержи-
ваться какой-либо одной роли. Преимущества игры в планирование связаны с пре-
одолением естественных противоречий, возникающих между ценностью и затратами.
Легко обмануть себя, игнорируя эти противоречия, когда играешь обе роли.
1. Заказчики определяют объем плана

Менеджеры продукта, вам нужно готовиться
к игре в планирование, выбирая из визуаль- См. также
ного плана инкременты с наивысшим при-
оритетом. Выбирайте ровно столько, что- Визуальное планирование (глава 8)
бы заполнить свой горизонт планирования
историй (см. подраздел «Как создать план» ранее в данной главе). Например, если
вы используете горизонт планирования, показанный на рис. 8.2, вам понадобится
выбрать количество инкрементов, которого хватит примерно на месяц работы.
Начните игру в планирование с просмотра цели команды, затем опишите, как
выбранные вами инкременты вписываются в общий план и почему их важно сделать
в первую очередь. Объясните, что делает эти инкременты ценными и что должно про-
изойти, прежде чем их можно будет выпустить, и затем ответьте на все возможные
вопросы от команды.
2. Вся команда определяет истории

с помощью мозгового штурма
Используйте одновременный мозговой штурм
(см. пункт «Работайте одновременно» главы 7), См. также
чтобы придумать истории, необходимые для ре-
лиза каждого инкремента. Запишите каждую Истории (глава 8)
на своей индексной карточке или виртуальном
эквиваленте.
Вы можете иметь некоторые предстоящие обязательства, запросы или активности,
которые не соответствуют вашим самым приоритетным инкрементам, но все равно
должны быть сделаны. Подготовьте истории и для них. Для всего, что требует каких-
либо действий от команды, кроме рутинной работы компании, нужна своя история.
3. Разработчики определяют размер историй

Разработчикам нужно пересмотреть карточки историй и рассортировать их в не-
сколько групп:
zz истории размера «в самый раз»;
zz слишком большие истории;
zz слишком маленькие истории;
zz истории, размер которых невозможно определить, поскольку вы их не понимаете;
zz истории, размер которых невозможно определить из-за технических неясностей.
Истории имеют размер «в самый раз», когда вся команда может завершить от
четырех до десяти (в среднем шесть) таких историй за неделю. Со временем у вас
появится интуитивное ощущение истории размером «в самый раз». Однако для на-
чала вы можете воспользоваться одной из оценочных техник, описанных в подразделе
«Оценка историй» главы 9.
Почему от четырех до десяти историй в неделю? Вы можете выбрать любой раз-
мер для понятия «в самый раз», но 4–10 — хорошая начальная точка. Если будет
больше, то вы можете прийти к тому, что будете тратить очень много времени
на создание, организацию, отслеживание историй. Если меньше — вам будет
трудно демонстрировать устойчивый прогресс.
Если истории слишком большие, то вместе со своими заказчиками разделите их

на более мелкие. В подразделе «Разделение и объединение историй» данной главы
описывалось, как это сделать. Если истории слишком малы, то комбинируйте их
с другими историями. Если вы работаете с физическими индексными карточками,
то можете буквально скрепить их друг с другом.
Если вы не понимаете историю, то попросите ваших заказчиков в команде по-
яснить. Иногда им может понадобиться больше времени, чтобы разобраться. Пока
они это делают, продолжайте заниматься оставшимися историями.
Для историй, в которых есть технические неясности, создайте спайк-истории
(см. пункт «Спайк-истории» ранее в данной главе). Сделайте отметку на первона-
чальной истории, что ее размер неизвестен. Я обычно пишу в углу «спайк».
4. Заказчики определяют приоритеты историй

Заказчики, как только разработчики одобрят
размер истории «в самый раз», добавляют их См. также
в ваш визуальный план примерно в порядке при-
оритета. Визуальное планирование
(глава 8)
Для историй, у которых нет соответствующего
инкремента, добавьте их там, где это наиболее
целесообразно для вашей команды. Размещение их среди других историй в соот-
ветствии с приоритетом поможет гарантировать, что вы о них не забудете.
Некоторые истории не стоят того, чтобы их добавлять. Они или неважны, или
находятся слишком далеко в будущем. Продолжайте, выбросив их, — они устареют
к тому времени, когда вы до них доберетесь. Если вы терпеть не можете выбрасывать
свои истории, то сохраните их в каком-нибудь архиве.
Заказчики, убедитесь, что вы понимаете каждую историю, которую добавляете.
Вам нужно принимать правильные решения о том, что входит, а что нет в каждый
релиз, а также решать, в каком порядке будут выстраиваться истории. Это значит, что
истории должны соответствовать вашей точке зрения. Не позволяйте разработчикам
заставить вас добавить историю, которую вы не понимаете.
Разработчики, за вами последнее слово в вопросе историй, которые «в самый
раз» и готовы к приоритизации. Не позволяйте заказчикам заставить вас принять
историю, которая должна быть разделена на более мелкие или нуждается в спайк-
истории.
5. Повторяйте, пока план не будет завершен

Продолжайте создавать, оценивать и размещать истории, пока не заполните свой
горизонт планирования историй. Добавляйте дополнительные инкременты, если
необходимо. Например, если вы нацелены на шесть историй в неделю и ваш гори-
зонт планирования историй — четыре недели, то продолжайте, пока у вас не будет
по меньшей мере 24 истории. Затем сделайте шаг назад и еще раз проверьте план
с помощью вопросов, указанных ниже.
zz Каждая история имеет размер «в самый раз», согласно мнению членов команды
с навыками разработки?
zz Каждая история, размер которой невозможно определить, имеет спайк-историю,

приоритизированную для выполнения перед ней?
zz Истории приоритизированы правильно, согласно мнению членов команды, име-
ющих навыки в сфере деятельности заказчика?
zz В целом имеет ли ваш план смысл и ведет ли команду к достижению ее цели?
Попросите членов команды дать согласие на работу по вашему плану (см. пункт
«Стремитесь к согласию» главы 7). Как только они подтвердят свое согласие, вы
закончите данный этап работы.
Держите открытым окно возможностей

Старайтесь создавать план, который позволит вам сделать релиз в любое время. Вам
не нужно на самом деле делать релизы все время, но вы хотите иметь такую возмож-
ность даже в середине работы над любым инкрементом.
Зачем это делать? Это позволяет вам держать открытым окно возможностей.
Обычно, если появляется интересная новая возможность, пока вы находитесь в се-
редине работы над инкрементом, то вам нужно ждать его завершения и потом или
выбрасывать наполовину выполненную работу, или откладывать ее на неопреде-
ленное время в сторону, где она будет, метафорически говоря, ржаветь (см. врезку
«Минимизируйте объем незавершенной работы» ранее в данной главе). Но если вы
планируете свою работу так, что можете сделать релиз в любой момент, то можете
принять решение, что половина ценности инкремента лучше, чем ничего, выпустить
то, что есть, и сразу начать работать над новой возможностью.
Чтобы держать открытым окно возможностей, создайте такой план, чтобы можно
было делать релиз после каждой истории. Истории могут основываться на преды-
дущих историях, но не должны зависеть от последующих.
Например, предположим, что вы создаете страницу оформления покупки, на
которой взимается плата с кредитной карты пользователя. Вы могли бы сначала
создать историю для каждого уровня вашей архитектуры: «Получить платежную
информацию», «Сохранить платежную информацию» и «Отправить платежную
информацию в систему обработки платежей». Иногда это называют горизонтальны-
ми полосами. Это простой способ создания историй, но он не позволит вам сделать
релиз вашего ПО, пока вы не закончите все три истории. Они формируют выбор
«все или ничего».
Лучше создавать истории, которые содержат все три горизонтальных уровня, но
обеспечивают более узкую самостоятельную утилитарность. Например, вы можете
создать истории «Обработать платеж», «Запомнить одну карту» и «Запомнить
и управлять несколькими картами». Это вертикальные полосы (рис. 8.8). Каждая
строится на предыдущей, но вы можете сделать релиз после любой из них.
Не волнуйтесь, если у вас пока не получается сделать так, чтобы ваши истории
опирались друг на друга подобным образом. Для этого нужна практика. Возмож-
ность релиза после каждой истории позволяет вам быть более гибкими, но и немного
«скомканных» историй в вашем плане не нанесут большого вреда. Со временем вы

научитесь делать ваши планы более ровными.
Рис. 8.8. Горизонтальные и вертикальные полосы
Как выиграть в игре в планирование

Когда разработчики и заказчики в команде собираются, чтобы сыграть в игру в пла-
нирование, происходит нечто удивительное. Я называю это чудом сотрудничества.
Это чудо, поскольку время появляется из ниоткуда.
Как вы можете вообразить, этого чуда достичь непросто. Когда разработчики
говорят, что история должна быть разделена на более мелкие, заказчики обычно
задают вопрос, который вызывает у разработчиков зубной скрежет: «Почему это
так дорого стоит?»
Инстинктивно этот вопрос вызывает защитную реакцию: «Это стоит так дорого,
поскольку разработка ПО — трудная работа! Почему вы меня допрашиваете?!»
Разработчики могут реагировать иначе, лучше. Мысленно перефразируйте во-
прос: «Помогите понять, какие у меня есть варианты». В ответ расскажите о том,
что легко и что сложно.
Например, вообразите, что вы создаете тостер и у вашего продакт-менеджера есть
история для разработки функциональности автоматического выскакивания тоста
по его готовности. Разработчики говорят, что историю нужно разделить, и когда
продакт-менеджер спрашивает почему, разработчики спокойно отвечают: «Ну, вы-

скакивание тоста — это легко, надо просто отрубить электричество от электромагнита.
Но определение готовности тоста — это что-то новое. Нам понадобятся датчик изобра-
жения и система машинного обучения для того, чтобы точно определить изменения
в степени потемнения тоста для разных видов хлеба. С мраморным ржаным… будет
сложно, не говоря уже о тостерной выпечке!»
Это дает продакт-менеджеру возможность спросить: «А как насчет всех других
тостеров вокруг? Как они определяют, что тост готов?»
Разработчики строят красноречивую гримасу: «О, это полная ерунда. Они вообще
не определяют готовность тоста. Они просто используют таймер».
Теперь продакт-менеджер может ответить: «Так это отлично! Нашим заказ-
чикам не нужен супертостер. Они хотят обычный. Используйте таймер, как все
остальные».
«А, ну окей. Тогда это совсем не сложно. Нам не нужно делить эту историю».
Как правило, заказчики не знают, что просто, и придумывают истории, которые
трудно реализовать. Точно так же разработчики могут не знать, что считают важным
заказчики, и придумывают истории, в которых отсутствует ценность для заказчиков.
При открытом и честном общении эти противоречивые тенденции можно при-
мирить. Когда заказчики просят чего-то неважного, но сложного, разработчики
указывают на затраты и предлагают более простые альтернативы. И заказчики
меняют направление. Так время появляется словно ниоткуда. Это и есть чудо со-
трудничества.
Приоритизация решений по разработке

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

ческими возможностями. Вместо этого объясните технологию и опишите варианты
в терминах влияния на бизнес.
Вернемся к примеру с тостером. Вместо того чтобы объяснять выбор между оп-
тическим датчиком и таймером следующим образом:
«Мы думаем об использовании здесь оптического датчика Mark 4 Wizzle-Frobitz,
позволяющего оптимально определять момент выбрасывания. Другой вариант —
использовать 555-style IC. Оптический датчик лучше, но тогда нам понадобится
обучить индивидуальную пользовательскую модель ML. Что вы предпочитаете?»,
попробуйте объяснить так:

«У нас есть два способа определения готовности тоста. Мы можем использовать
камеру или таймер. Камера позволит зажаривать тост в точном соответствии
с предпочтениями пользователя, но реализация потребует нескольких дополни-
тельных историй. Таймер не добавит дополнительной работы. Но пользователь,
скорее всего, будет получать недожаренный или, наоборот, подгоревший тост.
Что вы предпочитаете?»
Лицом к лицу с реальностью

Заказчики, во время игры в планирование вы почти наверняка узна́ете информацию,
которая вас расстроит. Даже если ваша команда не делает прогнозов, игра в плани-
рование даст вам примерное понимание того, какое количество работы предстоит
сделать. И почти всегда ее будет значительно больше, чем вы надеялись.
Вы можете почувствовать искушение обвинить информирующего и прекратить
игру в планирование. Или можете надавить на разработчиков, чтобы они не дели-
ли истории на части. Это будет ошибкой. Игнорирование неприятной реальности
не уменьшит количества времени, затраченного на работу; задержки, возникшие из-за
этого, просто заведут вас в тупик. Перефразируя Дэвида Шмальтца: каждый релиз
содержит определенное количество свя-
занных с ним разочарований. Вы можете Игнорирование неприятной
или использовать игру в планирование, реальности не уменьшит количества
чтобы раздавать его в умеренных дозах… времени, затраченного на работу.
или нести его с собой целиком до самого
конца.
Ваш план может и так быть больше, чем вам хотелось бы, однако если разра-
ботчики просят еще разделить истории, то это, скорее всего, потому, что они хотят
установить реалистичные ожидания. На практике я обнаружил, что на первых порах
разработчики скорее недостаточно делят истории, чем наоборот. Но если они все же
планируют слишком мелкие истории, это значит, что они просто выполнят больше
историй, а вы сможете скомпенсировать все на следующей игре в планирование.
Повторение игры в планирование

Когда ваша команда заканчивает истории,
удаляйте их из плана. Когда план сжимается См. также
и становится меньше вашего горизонта пла-
Визуальное планирование (глава 8)
нирования (например, меньше 24 историй),
настает время снова провести игру в планирование. После этого проверьте еще раз,
нужно ли вытянуть инкременты в ваш визуальный план.
Стейкхолдеры тоже будут предлагать новые идеи и функциональности. Одни из
них не будут стоить того, чтобы их внедрять, и их можно будет выбросить (вежливо!).
Другие окажутся хорошими идеями для будущих инкрементов, и их можно будет до-
бавить к пока еще менее детализированной части вашего визуального плана. А идеям,
которые вы захотите реализовать скоро, понадобятся свои истории. Их нужно будет
обсудить с командой, чтобы задать размер и приоритет.
По мере приобретения опыта обсуждение, определение размера и приоритета
начинают занимать всего несколько минут. Соответственно, одни команды просма-
тривают новые истории в день их получения. Другие планируют большие сессии
игры в планирование каждую неделю или две. Я считаю, что короткие частые сессии
менее утомительны, чем долгие и более редкие, но оба подхода рабочие.
Иногда стейкхолдеры будут пытаться обойти процесс приоритизации, общаясь
с программистами напрямую. Правильной реакцией на это будет выслушать их за-
прос, записать его (на этот случай я всегда ношу с собой набор индексных карточек)
и сказать им, что запросу будет присвоен приоритет, когда команда в следующий раз
соберется на сессию планирования. Потом вы можете передать его своему локальному
заказчику для отслеживания.
Вопросы
Как можно побудить стейкхолдеров к использованию историй для запроса изменений?
Это не обязательно. Вместо этого члены команды, обладающие навыками в сфере
деятельности заказчика, должны интерпретировать идеи стейкхолдеров и преоб-
разовывать их в истории для команды.
Что делать с технической инфраструктурой?
В Agile планирование начинается с допущения, что
вы можете разбить свою работу на маленькие ориен- См. также
тированные на заказчика истории и создавать вашу
Инкрементный дизайн
техническую инфраструктуру в процессе работы. Как (глава 14)
это сделать, показывает эволюционный дизайн.
Игра в планирование основана на нескольких простых
предпосылках: См. также
zz есть члены команды, обладающие навыками в сфере Вся команда (глава 7)
деятельности заказчика, которые могут принимать
разумные решения о приоритетах;
zz есть члены команды с навыками разработки, которые могут надежно измерять
истории;
zz есть истории с минимальными зависимостями, ориентированные на заказчика.
Последний пункт требует, чтобы техническая инфраструктура создавалась ин-

крементно. Если у вас с этим трудности, то вам понадобится свободное владение
навыками на уровне поставки или, по меньшей мере, эволюционный дизайн.
Вам также понадобится хранить истории в таком формате, который позволит ва-
шим командам работать одновременно. Обычно это означает, что лучше записывать
истории на индексные карточки или их виртуальный эквивалент, чем использовать
инструменты трекинга задач.
Когда вы хорошо играете в игру в планирование:
zz заказчики и разработчики чувствуют, что они внесли свой вклад в план;
zz ощущения давления и стресса направлены скорее на ограничения плана и воз-
можные варианты, чем на отдельные лица или группы лиц;
zz разработчики рекомендуют способы, позволяющие уменьшить работу, при этом
выполняя цель команды;
zz заказчики расставляют строгие приоритеты историям, что наилучшим образом
служит достижению цели командой.
Ключевая идея игры в планирование состоит в том, что заказчики и разработчики
собираются вместе, чтобы составить план, который будет лучше, чем тот, который
любой из них мог бы составить самостоятельно. Это командный, а не индивидуаль-
ный подход, и он сфокусирован на результатах, а не на задачах.
Я не видел ничего, что превзошло бы эту основную идею, но и тут есть простран-
ство для экспериментов. Например, некоторые команды предпочитают создавать
очень маленькие истории, которые можно завершить за час или два. (Однако не за-
бывайте, что они должны быть ориентированы на заказчика, иначе это просто задачи!)
Вы также можете экспериментировать с программой игры в планирование. Напри-
мер, можете попробовать создавать и измерять ваши истории асинхронно, включать
в процесс больше или меньше людей или планировать более или менее часто.
ВОВЛЕЧЕНИЕ РЕАЛЬНОГО ЗАКАЗЧИКА

Мы понимаем цели и опасения наших заказчиков
и пользователей. Аудитория
Однажды я работал с командой, которая делала Заказчики

ПО для анализа данных масс-спектрометра. Команд-
ный эксперт в предметной области была химиком и на своей предыдущей работе
использовала старое ПО компании. Она была бесценным источником информации
о том, что работало, а что нет в предыдущей программе. Нам повезло, что она была
членом нашей команды. Благодаря ей мы смогли создать действительно более цен-

ный продукт.
В Agile-команде заказчики (члены коман
ды, обладающие нужными навыками, что- См. также
бы представлять заказчика, пользователей
и интересы бизнеса) отвечают за выбор Вся команда (глава 7)
и приоритеты историй. В их руках ценность
работы, выполненной командой. Это большая ответственность. Будучи заказчиком
в команде, как вы узнаете, что выбрать?
Часть этих знаний вы получили исходя из вашего предыдущего опыта и квалифи-
кации. Но вы не можете думать обо всем. Вас может настолько захватить ежедневная
рутина, что вы потеряете из виду интересы вашего реального заказчика.
Чтобы расширить свою перспективу, вам нужно привлечь реальных клиентов
и пользователей. Наилучший подход к этому зависит от того, для кого вы делаете ПО.
Обратная связь и итерации

Сосредоточенность Agile на обратной связи — одна из основных причин его
успеха.
Невероятно трудно предсказать, как будет принято ваше программное обеспече-
ние. Трудно даже представить, как оно будет работать на практике. В результате
команды часто обнаруживают, что первая версия их ПО содержит неожиданные
недостатки. Не совсем баги, а скорее некоторые заблуждения в части того, что
именно нужно было сделать.
До появления Agile на релиз первой версии ПО у команды могли уйти годы. Когда
неизбежные недостатки обнаруживались, оказывалось, что уже слишком поздно
и слишком дорого что-то менять. Революционность идеи Agile была в том, чтобы
выпускать ПО уже в первый месяц работы и так же часто и далее, что позволяло
обнаруживать и устранять ошибки на ранней стадии.
Предотвращайте ошибки, запрашивая как можно больше обратной связи.
Подключайте к планированию заказчиков, пользователей и стейкхолдеров от
бизнеса. Показывайте им макеты. Просите комментарии по текущей работе.
Выпускайте версии ПО инкрементно и наблюдайте, как люди используют его
в реальности.
И затем действуйте, основываясь на обратной связи. Меняйте планы, вносите
улучшения и повторяйте все снова.
Разработка для собственных нужд

В разработке для собственных нужд, которую я добавил в эту книгу в основном
для полноты картины, команда разработчиков является сама себе заказчиком. Она
разрабатывает ПО для собственного использования. Нет необходимости вовлекать
в процесс кого-то еще; команда и есть реальный заказчик.
Разработка платформ
В горизонтально масштабированных группах команд (см. подраздел «Горизонтальное
масштабирование» главы 6) некоторые команды могут делать ПО, предназначенное
только для использования другими командами. Реальные заказчики такого типа раз-
работки платформ — команды заказчика.
И слишком часто разработчики плат-
форм попадают в ловушку, делая инстру- Командам заказчика нужны гибкость,
менты и библиотеки, которые «просты автономия и полное владение своим
в использовании». Но это не то, что нужно продуктом, ничего волшебного.
командам вашего заказчика. Им нужны
гибкость, автономия и полное владение своим продуктом, ничего волшебного.
Им нужно, чтобы они могли делать свою работу, не завися от вас, если понадобятся
какие-то изменения. Как правило, это означает, что вам следует считать своими при-
оритетами простые программные интерфейсы с четкими зонами ответственности,
минимальными побочными эффектами и «аварийным люком», который позволит
команде погрузиться в нужные детали при необходимости.
Некоторые организации делят свои команды на старших разработчиков, которые
разрабатывают платформы, и младших разработчиков, которые адаптируют (ка-
стомизируют) эти платформы под разработку продуктов. Избегайте этого подхода.
Довольно часто он приводит к построению собственной «башни из слоновой
кости», пытающейся упростить кастомизацию, но на самом деле требующей от
неопытных разработчиков постоянной работы по латанию дыр. Результат — бес-
порядочное нагромождение решений, которое трудно поддерживать.
Старайтесь работать в тесном сотрудничестве с представителями команд заказ-

чика, когда делаете дизайн API (Application Programming Interfaces — «прикладные
программные интерфейсы») и принимаете решения о технических возможностях.
Сфокусируйтесь на том, чтобы дать возможность вашим заказчикам решать про-
блемы самостоятельно, так, чтобы вы не стали узким местом их рабочего процесса.
Один из способов улучшить взаимопонимание — проводить «программы обмена»,
в которых один из ваших разработчиков на несколько недель меняется местами
с разработчиком из команды заказчика.
Если ваша команда делает вспомогательное ПО для других разработчиков в целом,
а не для поддержки определенных команд, то вам лучше прочитать подраздел «Про-
граммное обеспечение для вертикального рынка» далее в текущей главе.
Внутренняя разработка на заказ

Внутренняя разработка на заказ (in-house custom development) происходит, если
ваша команда разрабатывает что-либо для собственного использования вашей ком-
панией. Это классическая разработка в ИТ. В нее может входить разработка ПО для
оптимизации операционной деятельности, автоматизация заводов вашей компании
или составление отчетов для бухгалтерии.
В таких условиях команда работает сразу

на нескольких заказчиков: исполнительного Превратите ваших реальных
спонсора, который платит за ПО, и конеч- заказчиков в заказчиков в команде.
ных пользователей, которые его используют.
Их цели могут не совпадать. В худшем случае вам будет необходимо удовлетворить
запросы целого комитета спонсоров и множества групп пользователей.
Несмотря на эти трудности, внутренняя разработка на заказ облегчает вовлече-
ние реальных заказчиков, поскольку они легкодоступны. Лучшим вариантом будет
принять заказчиков в вашу команду — превратить реальных заказчиков в заказчиков
в команде.
Вместо того чтобы приглашать заказчиков присоединиться к вашей команде,
может быть проще предложить вашей команде переехать поближе к заказчикам.
Чтобы этого добиться, попросите вашего исполнительного спонсора или одного

из его доверенных помощников стать вашим продакт-менеджером. Он будет при-
нимать решения по приоритетам, отражая стремление исполнительного спонсора
создать ПО, представляющее ценность для организации.
Кроме того, привлеките несколько конечных пользователей ПО в качестве экс-
пертов в предметной области. Как в вышеупомянутом случае с химиком, они будут
давать ценную информацию об использовании вашего ПО реальными людьми. Экс-
перты будут отражать стремление конечных пользователей использовать ПО, улуч-
шающее их жизнь.
Во избежание эффекта туннельного зрения
продакт-менеджер и заказчики в команде должны См. также
запрашивать обратную связь у своих коллег, про-
водя демо для стейкхолдеров и обсуждая с ними Демо для стейкхолдеров
(глава 10)
дорожные карты.
Если вам трудно уговорить исполнительного Дорожные карты (глава 10)
спонсора и пользователей присоединиться к ко-
манде, то прочтите информацию об аутсорсинге разработки (см. следующий подраз-
дел). Если у вас множество спонсоров и групп пользователей, то прочитайте подраз-
дел «Программное обеспечение для вертикального рынка» далее в текущей главе.
Аутсорсинг разработки
Аутсорсинг разработки (outsourced custom development) похож на внутреннюю раз-
работку на заказ (in-house custom development), но у вас может не быть таких связей,
которые есть у внутренних команд в организации. В результате у вас может не по-
лучиться привлечь реальных заказчиков к работе в качестве заказчиков в команде.
Но вы все же должны попытаться. Один из способов вовлечь в работу реальных
заказчиков — предложить вашей команде переехать в офис заказчика, а не наоборот.
Если вы не можете привести реальных заказчиков в вашу команду, то сделайте
попытку привлечь их другим способом. Встречайтесь лично с вашими заказчиками
первую неделю-две работы над проектом, чтобы обсудить цель и контекст, визуаль-
ный план и познакомиться друг с другом. Если ваши офисы находятся неподалеку
друг от друга, то встречайтесь снова на каждой демосессии для стейкхолдеров и сес-
сиях планирования, а также время от времени на ретроспективах.
Если вы разделены территориально и ре-
гулярные визиты невозможны, то оставайтесь
См. также
на связи с помощью видео- и телефонных
конференций. Если у вас виртуальная коман- Цель (глава 7)
да, то рассмотрите возможность предоставить
заказчикам доступ в вашу виртуальную ко- Контекст (глава 7)
мандную комнату. Постарайтесь встречаться Визуальное планирование (глава 8)
по меньшей мере раз в месяц для обсуждения
Демо для стейкхолдеров (глава 10)
планов. Даже если ваша команда работает
в офисе, попробуйте использовать вирту- Игра в планирование (глава 8)
альную белую доску для визуального плана, Ретроспективы (глава 11)
чтобы было проще совместно просматривать
и обсуждать планы.
Программное обеспечение для вертикального рынка

В отличие от разработки на заказ (custom development), ПО для вертикального рынка
разрабатывается для множества организаций. Однако, как и разработка на заказ, оно
делается для определенной индустрии и часто адаптируется для каждого покупателя.
Большинство продуктов «программное обеспечение как услуга» (software as a service,
SaaS) попадает в эту категорию.
Так как ПО для вертикального рынка имеет много заказчиков и у каждого свои
потребности, вы должны быть осторожны, предоставляя реальным заказчикам слиш-
ком много контроля над направлением развития продукта. Вы можете прийти к тому,
что ваш продукт будет идеально соответствовать потребностям вашего заказчика
в команде, но оттолкнет всех остальных.
Вместо этого в вашей команде должен
быть продакт-менеджер, который безоши- См. также
бочно понимает потребности ваших реаль-
ных заказчиков. Его работа (а она трудная) — Цель (глава 7)
принимать во внимание требования ваших
реальных заказчиков и комбинировать их в единую четкую цель. Это подразумевает
балансирование пожеланий людей, которые покупают продукт, с потребностями
людей, которые используют продукт. В случае ПО для вертикального рынка их цели
часто различаются и даже могут вступать в конфликт.
Вместо того чтобы вовлекать реальных за-
казчиков в качестве членов команды, создайте
Создайте возможности
возможности для получения от них обратной для получения обратной
связи. Некоторые компании формируют совет связи от реальных
заказчиков, в который входят их наиболее важ- заказчиков.
ные заказчики. Организации таким образом
делятся с заказчиками своими планами релизов ПО и предоставляют им демо

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

ПО для горизонтального рынка — заметная верхушка айсберга разработки ПО: это про-
граммы, которые предназначены для использования в широком спектре индустрий.
В данную категорию попадают потребительские сайты, а также игры, множество
мобильных приложений, офисное ПО и т. д.
Как и в случае с ПО для вертикального рынка, лучше не предоставлять реаль-
ным заказчикам слишком большой контроль над направлением развития ПО для
горизонтального рынка. Оно должно подходить широкой аудитории, а реальные
заказчики вряд ли владеют такой перспективой. В процессе разработки ПО для
горизонтального рынка особенно важную роль играет продакт-менеджер, который
создает убедительную цель и стратегию выхода на рынок, основываясь на потреб-
ностях всех заказчиков.
Организации горизонтального рынка могут не иметь таких тесных связей с заказ-
чиками, какие имеют организации вертикального рынка. Поэтому вариант с советом
заказчиков здесь может не подойти. Найдите другие способы вовлечения заказчи-
ков: фокус-группы, UX-тестирование, предварительные просмотры в сообществах,
ранний доступ и бета-версии и т. д.
Вопросы
Мы создаем сайт для нашего отдела маркетинга. Какой это тип разработки?
На первый взгляд может показаться, что это разработка на заказ, но так как реаль-
ная аудитория сайта — внешний мир, речь скорее идет о разработке для вертикального
или горизонтального рынка в зависимости от вашей индустрии. Продакт-менеджер
должен быть из отдела маркетинга, если это возможно, но вам также понадобится
обратная связь от людей, которые будут посещать сайт.
Одна из опасностей вовлечения реального за-
казчика заключается в том, что он не обязательно См. также
будет отражать потребности всех ваших заказчи- Цель (глава 7)
ков. Будьте осторожны, чтобы он не подтолкнул
вас к созданию ПО, полезного только для него. Используйте цель вашей команды
как ориентир. Пожелания заказчика задают цель и даже могут изменить ее, но
в конечном счете члены команды, обладающие навыками менеджмента продукта,
несут ответственность за направление работы команды.
Подобным образом пользователи часто думают об улучшении их существующих
методов работы, а не о поиске абсолютно новых методов работы. Это еще одна причина
того, почему конечные пользователи должны быть вовлечены, но не обладать контро-
лем. Если вашей команде важны иннова-
ции, то дайте прогрессивным мыслите- Конечные пользователи должны быть
лям (таким как дальновидный менеджер вовлечены, но не обладать контролем.
по продукции или UX-дизайнер) замет-
ные роли в вашей команде.
Вовлекая реального заказчика и пользователей, вы:
zz улучшаете свои знания о том, как заказчики используют программное обеспе-
чение на практике;
zz лучше понимаете цели и опасения заказчика;
zz используете обратную связь от заказчиков, чтобы пересматривать свои планы
и программное обеспечение;
zz повышаете ваши шансы поставить действительно полезный и успешный продукт.
Обратная связь — это необходимость, а непосредственное вовлечение реального за-
казчика — нет. Иногда лучшее ПО создают люди, которые имеют четкую концепцию
и энергично добиваются ее реализации. В результате ПО имеет тенденцию стано-
виться или полностью новым, или тщательно переосмысленным существующим
продуктом.
Кроме того, обратная связь от реальных заказчиков всегда информативна, даже
если вы решите игнорировать ее. Данная практика предназначена для получения
этой обратной связи из реального мира. Цель — создать ПО, которое реально отве-
чает потребностям заказчиков и пользователей, а не только представлениям вашей
команды и организации об их потребностях.
Пока вы будете думать о способах, позволяющих поэкспериментировать с этой
практикой, сфокусируйтесь на общении и обратной связи. Что поможет вам по-
лучить представление о том, как воспринимаются ваши программы в реальном
мире? Как вы можете уменьшить временной разрыв между идеей и получением
обратной связи? Как принимать лучшие решения, основываясь на обратной связи?
Чем больше у вас информации, тем более правильные решения сможет принимать
ваша команда.
ИНКРЕМЕНТНЫЕ ТРЕБОВАНИЯ
Мы выясняем детали требований непосредственно
перед тем, как они понадобятся. Аудитория
В традиционном процессе разработки создается доку- Заказчики

мент с требованиями, которые (в теории) точно описывают,
как должно работать ПО. Документ готовят бизнес-аналитики в ходе предвари-
тельной фазы сбора требований.
Но Agile-команды не используют фазы, а карты историй не являются миниа-
тюрными документами с требованиями. Как тогда команды узнаю́т, что им разра-
батывать?
Изменяемый документ с требованиями

Agile-команды предпочитают общаться лицом
к лицу, как рассказывается во врезке «Личное См. также
общение» в главе 7. Заказчики в команде
(члены команды, обладающие навыками, Вся команда (глава 7)
позволяющими представлять интересы по- Командная комната (глава 7)
купателей, пользователей и бизнес-стейкхол-
Вовлечение реального заказчика
деров) должны отвечать на вопросы команды
(глава 8)
о требованиях. Они выступают в качестве
«изменяемого документа с требованиями».
Они общаются с остальными членами команды с помощью разговоров, примеров
и рисунков на доске. Это более быстрый и менее подверженный ошибкам способ,
чем поддержание документа в актуальном состоянии, особенно для сложных тем.
Когда разработчикам нужно понять требование, они просто спрашивают.
От заказчиков в команде ожидают, что они разберутся с требованиями до того,
как их будут спрашивать о них. Ключ к успеху здесь — их экспертные знания. В за-
висимости от потребностей вашего ПО в вашу команду должен входить кто-то
с навыками управления продуктом, определяющий, что и как разрабатывать; кто-то
с экспертными знаниями в предметной области, понимающий тонкости профессии,
которую поддерживает ваше ПО; кто-то с навыками в области UX-дизайна, изуча-
ющий поведение пользователей и создающий продуктивный пользовательский ин-
терфейс; и, может быть, даже реальные заказчики, которые предоставляют контекст
о том, что значит использовать ПО в реальной работе.
Например, когда я работал над актуарным продуктом, наш менеджер по продук-
ту был актуарием, а спонсоры — старшими актуариями фирмы. У продукта для
химического анализа продакт-менеджер имел докторскую степень по химии, у нас
был специальный UX-дизайнер, и эксперт в предметной области был химиком-ана-
литиком.
Даже эксперты должны учитывать все
Не только представляйте себе, как
разнообразие вариантов и проводить иссле-
будет принято ваше программное
дование, прежде чем принимать решение. обеспечение: идите и узнавайте это.
Заказчики, вы можете и должны разговари-
вать с покупателями, пользователями и другими стейкхолдерами (см. врезку «Об-

ратная связь и итерации» ранее в данной главе). Не только представляйте себе, как
будет принято ваше программное обеспечение: идите и узнавайте это. Задавайте
вопросы, проводите эксперименты и демонстрируйте работающее ПО.
Вы также можете вовлекать других членов команды. Например, если вы UX-
дизайнер, обдумывающий возможности пользовательского интерфейса, то об-
суждение его с программистами команды может помочь добиться баланса между
впечатляющим UI и низкой стоимостью его реализации.
Заказчики сами решают, как запоминать все, что они узнали и решили. Что бы
вы ни использовали, рассматривайте это как временные заметки. Главное, чтобы за-
казчики в команде могли взаимодействовать друг с другом. Если вы придете к необ-
ходимости иметь постоянные заметки или формальную документацию, то это можно
сделать позже, как описывается в подразделе «Документация» далее в текущей главе.
Когда эксперты не являются частью команды

Agile-команды должны быть кросс-функциональными и иметь в своем составе людей
с настоящими экспертными знаниями в сфере заказчика, однако многие организации
испытывают трудности с укомплектованием своих команд таким образом. Вместо
этого они предпочитают, чтобы люди действовали как посредники между разра-
ботчиками и экспертами. Например, бизнес-аналитик может быть назначен вместо
эксперта в предметной области, а кто-либо не имеющий полномочий на принятие
решений может быть выбран в качестве продакт-менеджера.
В этой ситуации люди становятся привратниками ворот, выступая посредниками
и интерпретируя заявления экспертов. Не совершайте эту ошибку. Если ваши за-
казчики в команде не являются экспертами, то должны способствовать общению
между командой и экспертами так, чтобы каждый в команде получал информацию
непосредственно из ее источника. Затем команда работает совместно, постепенно
конкретизируя требования, как я объясню чуть позже.
Иногда команда полностью состоит из разработчиков. Ситуация похожая: не-
которые члены команды выступают медиаторами (посредниками) в общении с экс-
пертами, и вся команда совместно работает над требованиями.
Работайте инкрементно
Заказчики работают над требованиями инкрементно, параллельно с остальной ра-
ботой команды, а не во время предварительной фазы подготовки требований. Это
облегчает работу и позволяет оставшейся части команды не ждать окончания ана-
лиза требований, чтобы начать свою работу.
Как и с горизонтами планирования адаптивного
плана, начинайте с общей картины без большого См. также
количества деталей и уточняйте их по мере необ-
ходимости. Заказчики в команде должны работать Адаптивное планирование
над этой задачей, как правило, вместе с продакт- (глава 8)
менеджером, внимание которого сконцентрировано
на общей картине, и локальными заказчиками, фокусирующимися на деталях, как

было показано на рис. 8.3 (см. выше).
Цель и визуальный план

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

Выясните детали каждой истории, прежде
чем разработчики начнут работать над ней. См. также
Вы должны быть в состоянии пояснить их,
Примеры заказчика (глава 9)
глядя на визуальный план. UX-дизайнеры,
вам нужно подготовить макеты (мокапы), Сделано Сделано (глава 9)
которые продемонстрируют, как, по вашим
ожиданиям, будет выглядеть выполненная работа. Эксперты в предметной области,
убедитесь, что вы готовы предоставить примеры сложных концепций данной области.
Решите совместно, что для каждой истории будет значить быть сделанной.
Отзывы заказчиков
Пока истории находятся в разработке, до того как они полностью сделаны, проверьте,
соответствуют ли они вашим ожиданиям. Вам не нужно полностью тестировать при-
ложение (вы должны полагаться на то, что разработчики тестируют свою работу),
но вы должны вместе с разработчиками проверить те области, где они могут думать
не так, как вы. В эти области входят терминология, макет экрана и взаимодействие
между его элементами.
Прежде чем вы увидите программу в ра-

боте, все разговоры будут теоретическими. Только работающее ПО покажет вам,
Вы можете обсуждать варианты и затраты что вы получите на самом деле.
с разработчиками, но пока у вас нет рабо-
тающего ПО, каждый может только представлять себе, как все будет выглядеть на
практике. Только работающее ПО покажет вам, что вы получите на самом деле.
Иногда разработчики будут давать вам именно то, о чем вы просили, но на прак-
тике оно не будет работать так, как вы надеялись. В другие моменты у вас будут
проблемы с общением и взаимопониманием. В любом случае решение одно и то же:
поговорите с разработчиками о внесении изменений. Вы даже можете объединиться
в пары с разработчиками, пока они работают над исправлениями.
Большинство изменений будут незначительными, и разработчики обычно в со-
стоянии исправить их, используя резерв времени в графике команды. Однако если
понадобятся более серьезные изменения, то они могут оказаться слишком большими,
чтобы их можно было сделать в рамках текущей истории. Это может произойти даже
тогда, когда изменение кажется небольшим
с вашей точки зрения как заказчика. Создай-
См. также
те вместе с разработчиками новые истории
для этих изменений. Прежде чем внести эти Резерв времени (глава 9)
истории в ваш визуальный план, подумайте,
стоит ли это изменение затрат на него.
В процессе вашего взаимодействия разработчики будут узнавать о ваших ожи-
даниях от ПО. Ожидайте также, что некоторое количество предложенных вами
изменений со временем будет отменяться.
Документация
Хотя Agile-команды заменяют документацию личным общением, некоторые до-
кументы все же важны. Их планируют с помощью историй, как и любую другую
работу. В некоторых случаях обновление документации может стать просто ча-
стью более крупной истории, но вы также можете создать специальные истории
для документации, как обсуждалось в пункте «Истории для документации» ранее
в данной главе.
Постарайтесь не вводить документацию только ради документации. Как и во
всем, что делается командой, убедитесь, что вам понятно, кому принесет пользу до-
кументация и почему она имеет ценность.
Документация по продукту
Документация по продукту поставляется заказчику. Примеры такой документации —
руководства пользователя, справочные страницы и справочная документация по API.
Одна из команд, с которой я работал, собирала результаты тестов в формальный до-
кумент, который помогал заказчикам пройти процедуру одобрения у регулирующих
органов.
Если у вашего ПО нет никакой документации по

продукту, то вы можете сами задокументировать, что См. также
оно делает, — чтобы команда могла использовать эту
информацию в дальнейшем. Лучше всего это делать Сделано Сделано
сразу, пока воспоминания людей еще свежи, в рамках (глава 9)
каждой истории, как часть командного определения
понятия «сделано».
Эксплуатационная документация
Эксплуатационная документация, также называемая
runbooks, описывает стандартные практики и процедуры См. также
для разнообразных ситуаций, таких как развертывание
Сборка для эксплуа-
ПО, реагирование на оповещения и аварийные ситуации, тации (глава 15)
предоставление дополнительных ресурсов и т. д.
Руководящая документация
Ваша организация может требовать от вас создания определенных документов для
целей управления или аудита. Постарайтесь, чтобы такой документации было ми-
нимальное количество, или выполните требования, творчески перепрофилировав те
вещи, которые имеют большую ценность. Например, одна из команд использовала
автоматические приемочные тесты, отчеты о покрытии кода (code coverage) и исто-
рию управления исходным кодом (source control), чтобы удовлетворить требования
в части отслеживаемости.
Не думайте, что аудиты требуют специального процесса. Они часто требуют, чтобы
у вас просто имелся процесс (на ваш выбор) и чтобы вы могли продемонстрировать,
что вы ему следуете. Это может позволить вам уменьшить количество документации
по управлению куда больше, чем вы думаете. Например, вместо проведения формаль-
ных ревью кода команды использовали парное программирование и комментарии
при подтверждении изменений в код (commit comments), чтобы соответствовать
требованиям аудита в части экспертной проверки. Поговорите с аудиторскими груп-
пами заранее, чтобы сформировать атмосферу доброй воли и открыть возможности
для творческих решений.
Исполнительно-техническая документация
Agile-команды обладают глубоким пониманием, что они делают и почему. Но так
как они не используют документацию, это знание исчезает, когда команда расфор-
мировывается.
Когда ваша команда должна расфор-
мироваться или перейти к другой цели, Исполнительно-техническая
найдите время на то, чтобы задокументиро- документация (As-built
вать, что вы сделали. Это ваш финальный documentation) — это ваш
инкремент. Это как упаковывать одежду финальный инкремент создания ПО.
в коробки с нафталином: сейчас это вам
не нужно, но тот, кто унаследует вашу работу, будет благодарен, что вы потратили на
это время. Ваша цель — предоставить информацию, которая позволит им сохранять
и поддерживать код.
Исполнительно-техническая документация может принимать форму письменных
документов или пошаговых видеоинструкций. Обычно в них представлены обзоры
важных концепций, таких как архитектура, дизайн и основные функциональности.
Код и его тесты документируют детали. Алистер Кокберн советует записывать
беседу с каким-нибудь красноречивым членом команды, в которой он с помощью
белой доски объясняет систему программисту, не знакомому с ней. Дополните видео
оглавлением, содержащим также временные метки для каждой части разговора.
Вопросы
Не рискованно ли уменьшать количество документации?
Может быть. Чтобы уменьшить количество документации, вам необходимо сна-
чала заменить ее другими формами общения. Именно поэтому Agile-команды имеют
заказчиков в команде — они заменяют документы с требованиями. Но вам все же
может понадобиться задокументировать то, что разработала ваша команда. Если вы
думаете, что это важно, то создайте для этого отдельную историю и приоритизируйте
ее или включите данный пункт в ваше определение понятия «сделано».
Наши заказчики не знают, что должна создать наша команда. Что нам делать?
Начните с четкой, убедительной цели.
Если ваши заказчики в команде не зна- См. также
ют, как ее достичь, значит, у вас в коман-
де не хватает важных навыков в сфере Цель (глава 7)
деятельности заказчика. В этом случае Вся команда (глава 7)
вы можете использовать традиционную
методику сбора требований, такую как Контекст (глава 7)
[Wiegers1999], но лучше все же найти
людей с соответствующими навыками. Если вы еще этого не сделали, попробуйте
определить контекст работы вашей команды и использовать его для лучшего по-
нимания и пропаганды необходимых вам навыков.
Что, если заказчики при проверках обнаруживают слишком много проблем, с ко-
торыми нам трудно справляться?
С большой вероятностью это может случаться с новой командой, до того как
разработчики и заказчики команды научатся работать вместе. В краткосрочной
перспективе вам нужно писать новые истории для изменений, которые необходимо
внести.
В долгосрочной перспективе можно
организовать работу так, чтобы заказчики См. также
проводили больше времени, разговари-
вая с разработчиками о своих ожиданиях Групповое программирование (глава 12)
и проверяя текущую работу. Групповое Парное программирование (глава 12)
программирование — наиболее яркое
выражение этой идеи. Другой вариант — работа заказчика и программиста в паре.

Практикуясь, вы научитесь предвидеть запросы друг друга.
Как программиста меня обижают некоторые вещи, которые заказчики указывают
в своих отзывах. Они слишком придирчивы.
Многие вещи, кажущиеся программистам придирками (например, цвет фона
экрана или несколько пикселей выравнивания в пользовательском интерфейсе),
являются для заказчиков свидетельством дополнительной полировки и профессио
нализма. Это работает в обе стороны: некоторые вещи, важные для программистов,
такие как качество кода и рефакторинга, часто кажутся заказчикам ненужным пер-
фекционизмом.
Вместо того чтобы расстраиваться из-за разницы во взглядах, попробуйте понять,
что заботит заказчиков и почему. Узнав это, вы будете лучше предугадывать их по-
требности, что сократит необходимость в изменениях.
Эта практика требует, чтобы в вашей ко-
манде были люди, имеющие время и навы- См. также
ки, которые позволяют тщательно прора-
батывать детали. Без них у вашей команды Вся команда (глава 7)
будут трудности из-за недостаточных и не- Без багов (глава 16)
ясных требований.
Не рассматривайте проверки ваших за-
казчиков как сессии поиска багов. Разработ-
чики должны производить практически безошибочный код. Цель отзывов заказчиков
заключается в том, чтобы привести ожидания заказчиков и работу программистов
к единому знаменателю.
Некоторые организации настолько высоко ценят письменные документы, что вы
не сможете избежать документов с требованиями. Поговорите с вашим руководством
о том, почему эти документы так важны и не может ли их заменить непосредственное
общение. Возможно, исполнительно-техническая документация будет приемлемым
компромиссом. Если нет, то включите истории для необходимых документов в ваш
визуальный план.
Когда заказчики разрабатывают требования инкрементно:
zz разработчики работают над готовыми историями, в то время как заказчики вы-
ясняют детали будущих историй;
zz у заказчиков наготове ответы на вопросы, касающиеся требований, что позволяет
планированию и разработке проходить быстро и плавно;
zz к моменту своей готовности история соответствует ожиданиям заказчиков.
Практика инкрементных требований, по сути, берет традиционную фазу предвари-
тельного сбора требований и распределяет ее вдоль всей протяженности процесса
разработки ПО. Долгий процесс, когда заказчики пишут документ с требованиями,
передают его разработчикам, а те его читают, заменяется прямым разговором за-
казчиков с разработчиками именно в тот момент, когда нужны детали.
Обычно люди экспериментируют с этой идеей, сглаживая ее. Чаще всего команды
не включают людей, имеющих опыт в сфере деятельности заказчиков, поэтому воз-
вращаются к фазовому подходу и передаче документов. Это снижает их соответствие
идеям Agile. Если вы ищете возможность для экспериментов, то попробуйте другое
направление: расширяйте коммуника-
цию, повышайте экспертность знаний
См. также
и уменьшайте передачу из рук в руки.
Групповое программирование — резуль- Групповое программирование (глава 12)
тат одного из таких экспериментов.

Badass: Making Users Awesome [Sierra2015] — великолепная книга о том, как делать
продукты, которые понравятся людям.
ГЛАВА 9
Владение
Секрет первоклассного выполнения работы заклю-

чается в правильном понимании деталей, а никто
не понимает их лучше, чем непосредственные ис-
полнители этой работы [Poppendieck2003].
Lean Software Development: An Agile Toolkit
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
ПЛАНИРОВАНИЕ ЗАДАЧ
У нас есть план на эту рабочую неделю. Аудитория
Если вы следуете практикам, описанным Вся команда
в главе 8, то в итоге придете к визуальному
плану с несколькими уровнями детализации:
ценные инкременты, которые возможно выполнить в долгосрочной перспективе, ма-
ленькие ценные инкременты, которые, вероятно, будут выполняться в среднесрочной
перспективе, и специальные истории, которые будут сделаны в ближайшее время.
План превращается в действие с помощью планирования задач: разделения
историй на задачи и отслеживания прогресса команды. Поскольку Agile-команды —
самоорганизующиеся (см. врезку «Самоорганизующиеся команды» в главе 7), соз-
дание задач, их распределение между членами команды и отслеживание полностью
выполняются командой, а не руководителями.
Планирование задач состоит из трех частей: рабочего ритма (cadence, используется
также термин «каденция»), создания задач и визуального отслеживания.
Рабочий ритм
Рабочий ритм (каденция, cadence) — это частота вашего планирования задач. В со-
обществе Agile существуют два общих подхода: итерации (также называемые сприн-
тами1) и непрерывный поток (также называемый Kanban).
Итерации — это периоды времени с фиксированной продолжительностью, длящиеся
неделю или две. В начале каждой итерации вы выбираете набор историй для реализации
и к концу периода ожидаете, что все они будут выполнены. Непрерывный поток, напро-
тив, представляет собой бесконечную вереницу
историй. Вы выбираете следующую историю, как
только предыдущая закончена. См. также
Команды — новички в Agile должны ис
пользовать итерации. Не потому, что они про-
ще (вообще-то они сложнее), а потому, что Резерв времени (глава 9)
четкий ритм итераций дает командам воз-
можность получать важную обратную связь, позволяющую понять, как ей со-
вершенствоваться. И что еще важнее, благодаря правильному использованию
вашего итерационного потенциала вы получаете резерв времени, позволяющий
совершенствоваться.
Непрерывный поток не имеет таких встроенных возможностей для совершен-
ствования, какие есть в итерациях. Здесь сложнее заметить, когда работа идет
1
Слово «спринт» вводит в заблуждение. Разработка ПО больше похожа на марафон, чем на серии
спринтов. Вам нужно работать в таком темпе, который вы можете поддерживать сколь угодно
долго.
вкривь и вкось, и труднее оправдать затраты времени на улучшения. Тем не менее

непрерывный поток — менее стрессовый метод, и многие команды предпочитают
использовать его.
Итерации
Программная разработка обычно замирает постепенно. Сначала все идет хорошо:
«Я закончу эту задачу, как только доделаю этот тест». Затем вы говорите: «Я закончу,
как только исправлю этот баг». Потом вздыхаете: «Я закончу, как только исследую
этот недостаток в API… на самом деле нет». Не успеете оглянуться, как потратите
два дня на выполнение задачи, которую планировали сделать за два часа.
Беда подкрадывается к команде постепенно. Каждая проблема отнимает всего
лишь пару часов или день, поэтому не ощущается большой проблемой, но они мно-
жатся вокруг сотен задач в релизе. Совокупный эффект застает команды и их стейк-
холдеров врасплох.
Итерации позволяют вам обнаруживать
проблемы на ранней стадии. Время итераций См. также
строго ограничено: когда время истекло, ите-
рация закончена. В начале итерации (а каждая Сделано Сделано (глава 9)
обычно длится неделю или две) вы прогнози-
руете свой потенциал и выбираете истории, которые ему соответствуют. В конце
итерации все истории должны быть «сделаны сделаны». Если это не так, то вы знаете,
что у вас проблема. Итерации не предотвращают проблемы, а обнаруживают их,
что позволяет вам исправлять лежащие в их основе причины.
Итерации выполняются в соответствии с постоянным графиком.
1. Продемонстрировать результаты преды-
дущей итерации стейкхолдерам (полчаса). См. также
2. Провести ретроспективу предыдущей ите- Демо для стейкхолдеров (глава 10)
рации (один час).
Ретроспективы (глава 11)
3. Запланировать задачи для итерации (пол-
часа). Непрерывное развертывание
(глава 15)
4. Разработать истории (остаток итерации).
5. Развернуть ПО, если не используется непрерывное развертывание (автомати-
зировано).
Многие команды начинают свои итерации в понедельник утром, но я предпочитаю
итерации, которые начинаются утром в среду или четверг. Это позволяет командам
уйти на длинные выходные, не пропуская важных событий. Вдобавок это снижает
желание работать по выходным.
Итерации могут иметь любую длительность, но большинство команд используют
недельные или двухнедельные. Командам — новичкам в Agile лучше всего подходят
итерации длительностью в одну неделю. Причина в том, что команды развивают
свое понимание Agile, основываясь на том, сколько итераций они выполнили, а не
сколько недель опыта они получили. Чем короче итерации, тем быстрее команды
будут совершенствоваться1.
Вместе с тем итерации длиной в неделю ока-
См. также
зывают большее давление на команду. Это за-
трудняет активную работу и может помешать Энергичная работа (глава 7)
выполнению рефакторинга. Кроме того, при
Рефакторинг (глава 13)
итерациях длиной в неделю труднее предсказы-
вать потенциал, поскольку различные переры- Потенциал (глава 9)
вы и праздники пропорционально больше, чем
прерывания. Таким образом, как только ваша команда научится надежно завершать
истории в течение каждой итерации, двигайтесь дальше и экспериментируйте с двух-
недельными итерациями.
Итерации длиной больше двух недель обычно являются ошибкой. Команды на-
чинают использовать более длинные итерации, когда чувствуют, что им нужно боль-
ше времени, чтобы закончить работу. Но это только прячет проблему. Более длинные
итерации не изменят количества имеющегося у вас времени; они изменят лишь перио
дичность, с которой вы проверяете ваш прогресс.
Если вам трудно закончить все к концу ите-
рации, то это не потому, что вам нужно боль- Если вам трудно закончить
ше времени; это потому, что вам нужно больше все к концу итерации,
то используйте более
практики инкрементной работы. Сократите
короткие итерации
длительность ваших итераций, уменьшите исто- и уменьшите истории.
рии и сконцентрируйтесь на решении проблем,
которые мешают вам заканчивать истории.
Непрерывный поток
Непрерывный поток является именно тем, чем кажется: непрерывным потоком
историй без определенного начала и конца. Вместо того чтобы прогнозировать,
что ваша команда может делать каждую неделю, установите лимит незавершенной
работы (work in progress) — то есть над каким количеством историй ваша команда
будет работать одновременно. Лучше всего от одной до трех. Чем меньше, тем лучше
(см. врезку «Минимизируйте объем незавершенной работы» в главе 8). Как только
этот лимит достигнут, больше новых историй начинать нельзя. Когда история «сде-
лана сделана» (done done), ее убирают, освобождая место для новой.
В теории непрерывный поток менее расточителен, чем итерации, поскольку вам
не нужно предсказывать потенциал или рассчитывать истории так, чтобы они поме-
щались во временные рамки итерации. На практике я не нашел этому подтверждения.
Строгие временные рамки итераций удерживают внимание команды на завершении
историй. Команды, использующие непрерывный поток, не имеют такой же срочной
1
Я преподавал в классе, где студенты разрабатывали реальное программное обеспечение с помо-
щью 90-минутных итераций. У них был такой же прогресс в совершенствовании, какой я видел
у команд, использовавших итерации длиной в неделю.
необходимости решать проблемы и урезать запланированный объем работы. Я реко-

мендую командам — новичкам в Agile сначала освоить итерации, а затем пробовать
непрерывный поток.
Тем не менее непрерывный поток хорошо подойдет командам, работающим
с большим количеством маленьких непредсказуемых историй, например командам,
занятым техническим обслуживанием и исправлением багов. Если ваши планы
меняются настолько часто, что даже недельные итерации для вас слишком длинны,
то ваш выбор — непрерывный поток.
Коллективное владение
Agile-команды разделяют ответственность за результаты. Вся команда работает
совместно, чтобы завершить истории, и каждый участник свободно выбирает
работу, которую знает лучше всего, помогает тем, кто нуждается в помощи,
и выясняет, как наилучшим образом внести вклад в работу, с которой пока
знаком не очень хорошо. Если что-то идет не так, то команда совместно ра-
ботает над решением проблемы; если все хорошо, то команда считает это
общей заслугой.
Некоторые команды назначают отдельных членов, чтобы они индивидуально
работали над историями, но лучшие команды Agile делают это совместно. Они
берутся за одну историю за раз или настолько близко к этому, насколько воз-
можно, координируясь и взаимодействуя так, чтобы все делалось одновременно.
Таким образом они избегают риска, когда один человек застревает на чем-либо
и тормозит весь прогресс, а остальная команда об этом не знает.
В командах поставки это общее владение распространяется также и на код.
В разделе «Коллективное владение кодом» главы 12 описывается, как это ра-
ботает.
Создание задач
Начните планирование задач с выбора
историй. Если вы используете итерации, См. также
то выбирайте истории, основываясь на
своем итерационном потенциале: напри-
мер, 6 историй или 12 пойнтов. Если вы Визуальное планирование (глава 8)
используете непрерывный поток, то вы- Игра в планирование (глава 8)
бирайте истории в соответствии с вашим
лимитом незавершенной работы, затем планируйте новую историю, когда эта за-
канчивается. В любом случае выбирайте только те истории, которые готовы к за-
вершению: то есть вопросы сторонней зависимости решены либо же третья сторона
готова участвовать.
Заказчики в команде выбирают истории, подбирая приоритетные из визуального

плана. Они раскладывают их на столе или виртуальной доске и объясняют их осталь-
ным членам команды. Это должно происходить буквально мгновенно: команда уже
видела истории во время игры в планирование.
Далее используйте одновременный мозговой штурм (см. пункт «Работайте одно-
временно» главы 7), чтобы сформировать задачи, необходимые для завершения
каждой истории. Делайте их маленькими: каждая задача на несколько часов работы.
Запишите каждую задачу на карточку или ее виртуальный эквивалент и разместите
рядом с историей, к которой она относится.
Задачи могут быть любыми, на ваш вкус. Следует включить все, что нужно, что-
бы закончить историю. Примеры: «обновить скрипт сборки», «добавить класс за-
казчика» и «макет платежной формы». Большинство задач будут создавать разра-
ботчики, но участвовать могут все.
Планирование задач — активность, относящая
ся к дизайну. Это способ, позволяющий добиться Планирование задач —
общего понимания в команде. Если у всех одина- активность, относящаяся
ковые идеи, как разрабатывать ПО, это должно к дизайну.
проходить быстро. Если нет — это отличная воз-
можность обсудить все до начала разработки.
Вам не нужно слишком сильно вдаваться в детали каждой отдельной задачи.
Планирование задач нужно для того, чтобы все получили одинаковую картину проис-
ходящего, а не для того, чтобы окончательно решить, что делать. Оставьте людям воз-
можность проработать детали, когда они непосредственно приступят к выполнению
работы. Например, если одна из ваших задач — «добавить класс заказчика», то вам
не нужно говорить, какие методы в него входят, если все программисты понимают
место данного класса в общем плане.
В процессе работы у разработчиков могут появляться вопросы о деталях каждой
истории. Нужно, чтобы члены команды, имеющие навыки в сфере деятельности за-
казчика, могли отвечать на эти вопросы.
На подготовку плана задач у вас должно уходить меньше 10–30 минут. Если
она занимает больше, то вы, вероятно, слишком вдаетесь в детали. Если вы завязли
в каком-то вопросе, то не решайте его во время совещания. Лучше добавьте его как
отдельную самостоятельную задачу, относящуюся к дизайну. Например, если людям
нужно решить, какую библиотеку аутентификации использовать, то можно добавить
задачу «выбрать библиотеку аутентификации».
Помните, что в работе должна принимать участие вся команда. Если вы создаете
задачи в области дизайна, то убедитесь, что все члены команды, к которым это от-
носится, имеют право голоса при принятии этих решений. Эти люди могут вместе
работать над задачей. В качестве альтернативы команда может делегировать задачу
подгруппе людей, которые выработают варианты, а затем отчитаются о результате
большой группе. В любом случае это то, что следует сделать после первой встречи,
посвященной планированию задач.
Результатом встречи по планированию задач становится ваш первоначальный
набор задач. В процессе работы вы можете обнаружить новые задачи. Это особенно
вероятно, когда у вас задача, относящаяся к дизайну. Например, задача «выбрать

библиотеку аутентификации» может привести к новым, таким как «создать конеч-
ную точку обратного вызова аутентификации», «написать копию электронного
письма о сбросе пароля» и «добавить письмо о сбросе пароля в скрипт разверты-
вания».
Когда все задачи будут готовы, еще раз проверьте, содержит ли план все, что
нужно вашей команде для завершения своих историй. Спросите команду, выпол-
ним ли этот план. Обычно это так, но если нет, удаляйте или заменяйте истории,
пока не добьетесь выполнимости.
В конце проведите единогласное голосование
(см. пункт «Стремитесь к согласию» главы 7). См. также
Когда команда согласует план, вы готовы начать
работу. Настройте свою доску для отслеживания Стендап-митинги (глава 9)
задач, проведите короткий стендап, чтобы решить,
с чего начать, и приступайте к работе.
Визуальное отслеживание
Agile-команды совместно управляют своей работой, как было сказано во врезке «Кол-
лективное владение» ранее в данной главе. Задания не назначаются конкретным людям.
Вместо этого, когда кто-то готов начать работу над задачей, он смотрит на доступные
задачи и выбирает из них такую, в которую может внести свой вклад, или ту, которая
позволит ему чему-то научиться. Отслеживание прогресса и оказание помощи там,
где нужно, — ответственность всей команды.
Легко зациклиться на собственных задачах
в ущерб общему прогрессу команды. Не забывай- См. также
те оставаться в курсе общей картины и ставить
успех команды выше завершения своих задач. Информативное рабочее про-
странство (глава 9)
Стендап-митинги помогут вам сделать шаг назад
и подумать об общей картине, но еще более важ-
ным инструментом является ваша доска для отслеживания задач. Это центральная
часть вашего информативного рабочего пространства.
Мой любимый инструмент для отслеживания задач — большая магнитная доска.
Мне нравится использовать шестидюймовую доску на колесиках. На одну сторону
я помещаю визуальный план, а на другую — план задач. Если у вас удаленно работа-
ющая команда, то используйте виртуальную доску. Скорее всего, вам будет удобнее
помещать план задач и визуальный план на одну и ту же доску.
Доска с задачами — нервный центр вашей командной комнаты, как физической, так
и виртуальной. Она делает ваш прогресс наглядным в любое время. Поддерживайте
доску в актуальном состоянии. Когда вы начинаете работу над задачей, отмечайте
на доске ваше имя или инициалы. Физические команды часто используют для этой
цели специальные магниты с забавными картинками. Виртуальные команды могут
загрузить любые собственные изображения.
В физической командной комнате приносите карточки с задачами на свой рабочий

стол. Физическое действие в виде похода к доске и снятия с нее карточки будет по-
могать остальным членам команды быть в курсе ситуации. Даже простое наблюдение
за передвижением людей вокруг себя позволяет понимать статус команды.
В виртуальной команде вы можете так же повлиять на информированность ко-
манды о ситуации, раздав участникам планшеты, предназначенные для использова-
ния в качестве виртуальных досок. (Это хорошая идея в любом случае. Планшеты
стоят недорого и упрощают рисование набросков.) Оставляйте планшет включенным
и авторизованным в системе доски задач, чтобы вы могли видеть изменения. Его
всегда можно выключить, если будет отвлекать.
Лучший способ визуализации вашего плана
задач — тот, который хорошо работает именно для Следите, чтобы ваш
вашей команды. Здесь я представляю два варианта. подход к планированию
Вы можете поэкспериментировать с остальными. задач оставался простым
Однако следите, чтобы ваш подход оставался про- и наглядным.
стым и наглядным, когда используете доску или ее
виртуальный эквивалент.
Так называемые инструменты планирования Agile, такие как Jira, только вносят
разногласия. Agile-команды постоянно экспериментируют с улучшениями и но-
выми рабочими процессами. Инструмент для планирования будет вам только
мешать.
Сетка задач
Сетка задач становилась хитом во всех командах, в которых я ее внедрял. Она про-
стая и компактная. Чтобы ее создать, расположите истории вертикально, разместив
историю с наивысшим приоритетом сверху. Справа от каждой истории в горизон-
тальную линию поместите задачи, связанные с этой историей, — в любом порядке,
который кажется наиболее естественным. Их можно делать не по порядку.
Когда люди готовы начать работу над задачей, они выбирают любую карточку,
с которой готовы работать, начиная с верхнего левого угла. Как только задача за-
вершена, пометьте карточку одним из способов: обведите зеленым маркером, до-
бавьте зеленый магнит или измените цвет виртуальной карточки. (Лучше не делать
надписи на карточках. Иногда задачи приходится
пересматривать.) Когда все задачи из истории См. также
завершены, последней задачей будет взглянуть
на ваше определение понятия «сделано», внести Сделано Сделано (глава 9)
финальные изменения, если нужно, и отметить
карточку зеленым цветом.
Сетки задач особенно полезны командам, работающим итерациями. Пример
представлен на рис. 9.1.
Рис. 9.1. Сетка задач
Доска детективов
Помните, в криминальных драмах часто присутствует доска со всей имеющейся
информацией о преступлении? Фотографии подозреваемых, улики, стрелочки от
одного к другому? Это доска детективов, и именно так работает визуализация1.
Пример показан на рис. 9.2.
Рис. 9.2. Детективная доска
1
Арло Бельши познакомил меня с доской детективов как частью своего процесса обнаженного
планирования (Naked Planning).
Каждая история получает собственную доску или ее часть, куда помещается

все, что имеет отношение к этой истории. Задачи, макеты, документы… вообще все.
Элементы группируются так, как команда считает нужным.
Когда задача или какая-то часть информации обработана или больше не акту-
альна, команда удаляет ее с доски. Когда члены команды понимают, что что-то еще
может быть полезным, они это добавляют. История сделана, когда доска пустая.
Детективные доски особенно хорошо работают для команд, использующих непре-
рывный поток.
Кросс-командные зависимости
Некоторые истории могут зависеть от людей вне команды. Так как истории малень-
кие (обычно примерно на день работы, если команда работает совместно), лучше
подождать, пока эти сторонние зависимости не будут урегулированы. Подобным же
образом, если для истории требуется, чтобы кто-то временно вступил в команду,
подождите, пока этот человек освободится. Иначе вы в итоге получите частично
сделанную работу (см. врезку «Минимизируйте объем незавершенной работы»
в главе 8).
Конкретнее: когда выбираете истории для планиро-
вания задач, не выбирайте истории с неурегулирован- Не выбирайте истории
ными зависимостями. Если вы используете итерации, с неурегулированными
то такие истории должны подождать до следующей зависимостями.
итерации. Если вы используете непрерывный поток,
то подождите, пока не откроется следующий слот.
Если вы начинаете работать над историей и обнаруживаете, что у нее есть внеш-
няя зависимость, то можно пока оставить ее в плане. Но ограничьте ее короткими
временными рамками, например день или два. Если зависимость не будет решена
за это время, то уберите ее из плана и замените. Я помечаю такие истории красным
цветом и добавляю дату окончания срока действия.
Некоторые истории может делать ваша команда, затем другая и затем снова ваша.
Разбивайте такие истории на две: первая — подготовка истории для другой команды,
вторая — история, которую вы начинаете после того, как другая команда завершила
свою часть работы. Помните, истории должны быть ориентированы на заказчика,
как было написано в подразделе «Ценность для заказчика» главы 8.
В целом Agile-команды должны быть в состоянии взять на себя полную ответствен-
ность за разрабатываемые ими истории. Если ваша команда сталкивается с частыми
задержками из-за кросс-командных взаимозависи-
мостей, то что-то идет не так. Возможно, у вас не вся См. также
команда или ваша организация выбрала неправильный
подход к масштабированию (см. главу 6). Попросите Вся команда (глава 7)
помощи у наставника.
Принятие и выполнение обязательств по итерации

Итерации — эффективный инструмент для улуч-
шения способности вашей команды надежно по- См. также
ставлять ПО. Чтобы полностью воспользоваться
всеми его преимуществами, рассматривайте ваш Доверие стейкхолдеров
план итераций как обязательство: нечто такое, ради (глава 10)
исполнения которого вы готовы приложить макси-
мальные усилия.
Поначалу у вас будут трудности с выполнением ваших планов итераций, поэтому
берите на себя обязательства негласно, внутри команды. Обязуйтесь сами перед со-
бой, не перед стейкхолдерами. Однако, практикуясь, вы станете достаточно последо-
вательными, чтобы начать информировать о своих обязательствах и стейкхолдеров —
и это потрясающий способ выстроить доверие.
Однако, как бы то ни было, обязательства — соб-
ственный выбор команды. Agile-команды отвечают Обязательства —
за свою работу. Руководители, никогда не застав- собственный выбор команды.
ляйте ваши команды брать на себя обязательства.
Это плохо заканчивается.
Конечно, быть хозяевами своих обязательств не означает, что вы будете всегда
завершать все, что запланировали. Что-то может пойти не так. Да, обязательство
заключается в том, чтобы делать все, что необходимо (в пределах разумного) для
завершения историй, входящих в данную итерацию вовремя. Но сюда входит и по-
иск решений для проблем, и честное, ясное информирование о тех проблемах, кото-
рые вы не можете решить.
Чтобы выполнять свои обязательства, вы долж-
ны знать о проблемах до того, как будет слишком См. также
поздно. Проверяйте прогресс команды во время
Стендап-митинги (глава 9)
ваших ежедневных стендап-митингов. Есть неза-
вершенная задача, о которой говорили на преды- Сделано Сделано (глава 9)
дущем стендапе? Это может быть проблемой. Если Резерв времени (глава 9)
вы в середине итерации, то проверьте, отмечена ли
зеленым примерно половина карточек задач. Если нет, то велика вероятность, что
вы не закончите все вовремя. Отмечена ли также зеленым половина историй? Если
задачи сделаны, а истории — нет, то вам в последний день придется внезапно делать
много работы, чтобы перевести истории в статус «Сделано Сделано».
Обнаружив проблему, угрожающую исполнению ваших обязательств, проверьте,
нет ли способа изменить план так, чтобы соответствовать обязательствам. Может ли
помочь использование вашего резерва времени? Нет ли задачи, которую можно упро-
стить или отложить? Обсудите ваши варианты в команде и пересмотрите план.
Иногда проблема слишком серьезна, чтобы с ней можно было справиться так
просто. В этом случае обычно вам нужно уменьшить объем работы в итерации.
Как правило, это подразумевает разделение какой-либо истории и откладывание

части работы или полное удаление истории.
Всегда держите итерацию под контролем, даже если для этого вам понадобится
удалить из нее историю. Любая итерация, которая поставляет все истории текущего
плана (даже если план меньше изначального), — это уже успех. Но ни при каких
обстоятельствах не отодвигайте предельный срок итерации. Всегда завершайте
итерацию вовремя. Это убережет вас от самообмана.
Незаконченные истории
В конце итерации все истории должны быть
в статусе «Сделано Сделано». Частично сде- См. также
ланные истории должны быть редкостью. Это
означает, что они будут случаться иногда, в ос- Сделано Сделано (глава 9)
новном пока вы еще учитесь. Потенциал (глава 9)
Незавершенный код вредоносен. Если вы
не планируете завершить историю немедленно
в следующей итерации, то вырежьте ее код из кодовой базы и верните историю об-
ратно в ваш визуальный план. Если вы планируете завершить работу, то создайте
новую историю, представляющую оставшуюся работу. Если вы используете оценки,
то сделайте ее заново. Вам не нужно, чтобы частично сделанная работа была засчита-
на в ваш потенциал, поскольку тогда вы придете к тому, что опять возьмете на себя
слишком много работы.
Иногда, несмотря на все ваши усилия, вы будете обнаруживать, что ничего
полностью не выполнено. Некоторые команды объявляют потерянную итерацию,
когда это случается. Они откатывают код и начинают все сначала, как если бы ите-
рации не было. Звучит сурово, но это хорошая практика. Итерации короткие, по-
этому много кода вы не выбросите и у вас останется все, что вы узнали и чему научи-
лись, пока писали его в первый раз. В результате второй попытки получится
лучший код.
Компетентные команды редко имеют не-
законченные истории. Если у вас проблемы Если у вас проблемы
с завершением историй, то измените ваш под- с завершением историй,
ход. Снизьте ваш запланированный потенци- то измените ваш подход.
ал, разбивайте истории на еще более мелкие
и координируйте общие командные усилия, нацеливая их на завершение каждой
истории, прежде чем переходить к следующей. Если это не поможет, значит, что-то
организовано неправильно. Спросите совета у вашего наставника.
Срочные запросы
Это неизбежно: вы в середине работы над историей, все идет хорошо, а потом кто-
нибудь из стейкхолдеров говорит: «Нам в самом деле очень нужно взять в работу
вот эту историю». Что вы будете делать?
Сначала решите всей командой, является ли эта история действительно срочной.

Ваша следующая встреча по планированию задач будет всего через несколько дней.
Может быть, эту историю можно отложить до следующей возможности, вместо того
чтобы вносить хаос в работу команды. Принимать решение должны члены команды,
имеющие наиболее глубокие знания в предметной области заказчиков и навыки
дипломатии.
Если вы решите приоритизировать эту срочную историю, то ваш подход будет
зависеть от того, что вы используете: итерации или непрерывный поток.
В случае итераций вы можете удалить любую еще не начатую историю и заменить
ее историей такого же размера. (Удаленная история возвращается обратно в визуаль-
ный план.) Если все ваши истории уже начаты, то вы все же можете удалить истории,
но вам придется угадать, сколько нужно удалить, а также понадобится удалить их
код. Таким образом, неполный код не будет тормозить вашу работу.
Команды, использующие непрерывный поток, часто создают отдельный лимит
незавершенной работы, специально для срочных историй. Сделайте этот лимит не-
большим: одного аварийного слота будет вполне достаточно. Если появится вторая
срочная история и она не сможет ждать, то вы сможете удалить существующую
историю, а также ее код.
Если у вас постоянный приток небольших экстренных случаев, то вы можете
рассматривать их скорее как рутинную работу, а не как истории. Помещайте их
на вашу доску задач, но не учитывайте в вашем потенциале. Ваш потенциал будет
автоматически подстраиваться, чтобы дать вам достаточно времени для обработки
срочных вопросов, за счет меньшего времени для работы над историями.
Если у вас много срочных запросов или вам необходима другая поддержка по
ходу работы, то вы можете зарезервировать одного (или нескольких) разработчика
для обработки этих запросов. В промежутках между ними люди могут работать над
чем-то, что не очень чувствительно прерывать, — а это обычно исключает работу
над историями. На данную роль лучше назначать нового человека каждый день или
неделю, чтобы предотвратить выгорание.
Ваша первая неделя

Когда ваша команда впервые работает с Agile, планируйте, что первые месяц или
два будут довольно хаотичными. В течение первого месяца заказчики в команде
будут разбираться с визуальным планом, разработчики будут устанавливать тех-
ническую инфраструктуру, и все будут учиться, как работать вместе, используя
практики Agile.
Некоторые считают, что лучший способ побороть этот хаос — взять неделю или
две заранее для работы над планированием и технической инфраструктурой. (Это
часто называют нулевым спринтом.) У этой идеи есть некоторые достоинства, од-
нако Agile-команды работают над планированием и технической инфраструктурой
итеративно и непрерывно в течение всего периода жизни команды. Начало реальной
работы в первый день помогает установить хорошие привычки и поддерживать работу
сфокусированной на том, что действительно необходимо.
Начните с использования недельных ите-

раций, а свой первый день — с планирования См. также
вашей первой итерации. Обычно сюда вхо-
дит выбор историй из визуального плана, Адаптивное планирование (глава 8)
но у вас на тот момент еще не будет плана. Визуальное планирование (глава 8)
Вместо этого подумайте над одним ценным
инкрементом, который точно войдет в ваш Игра в планирование (глава 8)
первый релиз, и проведите миниатюрную
сессию игры в планирование для этого инкремента. Придумайте 10–20 историй
размера «в самый раз», хорошо понятных для всех.
Эти несколько историй должны изобразить «вертикальную полосу» вашего ПО,
также известную как «ходячий скелет». Они должны собрать крошечную часть
каждой технологии, необходимой для вашего первого инкремента, так, чтобы вы
увидели, что программа работает по-настоящему. Если инкремент подразумевает
взаимодействие с пользователем, то создайте историю для отображения начального
экрана или веб-страницы. Если в него входит база данных, то создайте историю для
запроса небольшого количества данных. Если в инкремент входит отчетность, то
создайте историю для примитивного отчета.
Не ожидайте слишком многого от своих первых историй. Разработчикам пона-
добится установить техническую инфраструктуру. Поэтому истории должны быть
очень маленькими. На начальном экране может не быть ничего, кроме вашего лого.
Запрос в базу данных может иметь жестко заданные параметры. Отчет может выво-
дить заголовки и нижние колонтитулы без информационных элементов.
Как только у вас появятся начальные истории, вы
готовы к планированию задач. Вы можете еще не знать См. также
ваш потенциал, поэтому начните с создания задач для
всего одной-двух историй. Ваши первые задачи будут Потенциал (глава 9)
предназначены для установки технической инфра-
Нулевое трение (глава 13)
структуры: контроль версий, автоматическая сбор-
ка и т. д. Сделайте пока минимум, как описано в под- Сделано Сделано (глава 9)
разделе «Автоматизируйте инкрементно» главы 13.
В ходе итерации продолжайте фокусироваться на одной или двух историях за раз,
заканчивая одну полностью, прежде чем добавить следующую, и так до самого конца
итерации. Выполненные истории определят ваш потенциал на следующую итерацию,
как описано в подразделе «Ваш начальный потенциал» далее в этой главе. Невыпол-
ненные истории можно откатить или превратить в новые, как описывалось в подраз-
деле «Незаконченные истории» ранее в текущей главе.
Будет хорошей идеей, если программисты и отдел
эксплуатации будут работать над первыми несколь- См. также
кими историями вместе, как группа, даже если вы
не планируете использовать групповое программиро- Групповое программиро-
вание в долгосрочной перспективе. Установите проек- вание (глава 12)
тор или общий экран, чтобы каждый мог участвовать,
пока люди по очереди управляют клавиатурой. Вам не обязательно использовать
формальный подход группового программирования, но он может быть полезен.
Групповая работа над вашими первыми историями помогает снизить ощущение

хаоса, возникающее, когда люди только начинают работать вместе. Это поможет вам
совместно установить первоначальные соглашения, такие как структура каталогов,
имена файлов и пространства имен, базовые варианты дизайна и инфраструктурные
решения. Некоторые разработчики или пары разработчиков могут отделиться от
группы, чтобы заняться решением необходимых вопросов, например настройкой
контроля версий или рабочих станций программистов, но бо́льшую часть времени
вы должны работать вместе, командой.
Пока разработчики и люди из отдела
эксплуатации работают вместе, заказчи- См. также
ки в команде и тестировщики должны
заняться визуальным планом. Если у вас
еще нет проекта цели, то начните с него. Визуальное планирование (глава 8)
Другие члены команды могут работать Цель (глава 7)
с заказчиками или разработчиками, по
своему усмотрению.
Каждая следующая неделя будет идти более гладко. Разработчики будут учить-
ся, как делить истории, а заказчики — готовить визуальный план для вытягивания
историй. Потенциал команды стабилизируется. Ощущение хаоса пройдет, и команда
начнет работать в стабильном предсказуемом ритме.
Вопросы
Как планирование задач может занимать менее 10–30 минут? У нас на это всегда
уходит гораздо больше времени.
Хитрость эффективного планирова-
ния задач в том, чтобы использовать его См. также
только для планирования задач. Мно-
жество команд используют свои сессии Игра в планирование (глава 8)
планирования для оценки и разделения
историй, но лучше это делать в рамках отдельной сессии игры в планирование. Пла-
нирование задач должно быть сфокусировано на задачах. Истории должны быть
готовы до того, как вы начнете.
Еще одна хитрость — работать одновременно, используя свободный подход вме-
сто инструментов для отслеживания задач (см. пункт «Работайте одновременно»
главы 7). Команды, использующие систему трекинга, как правило, сталкиваются
с проблемой узкого места процесса из-за того, что один человек управляет системой
и это все замедляет.
Используя эти две хитрости и немного попрактиковавшись, ваша команда
легко сможет запланировать задачи менее чем за 30 минут. Если же планирование
все еще идет медленно, то причиной может быть то, что людям трудно прийти
к согласию по поводу того, что предстоит делать. Помните, что лучше создавать
специальные задачи для открытых вопросов, чем пытаться решать их во время
встречи по планированию задач. Если и это не поможет, то попросите совета у на-
ставника.
Как нам запланировать время на исправление

багов? См. также
Каждый раз, когда вы находите баг, даже если
он не связан с историями в вашем плане, заказчики Без багов (глава 16)
в команде должны принять решение, исправлять его
или нет. Если он должен быть исправлен, то добавьте соответствующие задачи в свой
план независимо от того, имеют ли они отношение к вашим текущим историям. Эти
задачи по исправлению багов — часть ваших рутинных процессов, и они не включа-
ются в расчет вашего потенциала.
Некоторые баги будут слишком большими, чтобы войти в вашу текущую итера-
цию. Создайте для них карточки историй и запланируйте их на следующую итерацию.
Незамедлительное устранение поможет вам снизить количество багов, с которыми
вы сталкиваетесь.
Если у вас старая кодовая база с большим количеством багов, то пройдитесь по
вашей базе данных багов и по каждому примите решение, исправлять их или нет
в следующем релизе. Закройте или отложите баги, помеченные «не исправлять»,
а остальные превратите в истории.
Все задачи в нашем плане зависят от кода, над которым все еще работают другие
люди. Что нам делать?
Вы можете писать код, зависящий от незавершенного кода. Поговорите с людьми,
которые работают над тем кодом, и договоритесь об именах модулей, классов и мето-
дов. Затем сделайте заготовку той части, над которой они работают. В разделе «Кол-
лективное владение кодом» главы 12 содержится больше информации по этой теме.
И итерации, и непрерывный поток полагаются на небольшие истории — каждая
примерно на один день, если команда работает совместно. Более крупные истории
могут незаметно выполняться неправильно.
Каждая история, законченная командой, должна
вести к прогрессу, который могут признать и оценить См. также
заказчики в команде — если не в эксплуатационной
(production) среде, то хотя бы в промежуточной Истории (глава 8)
(staging). Для этого требуется, чтобы истории были Инкрементный дизайн
ориентированы на заказчика, а техническая инфра- (глава 14)
структура создавалась инкрементно. Потенциал (глава 9)
Последовательное выполнение обязательств
в итерациях требует, чтобы ваши возможности ос-
новывались на измеренной реальности. Никогда
не завышайте искусственно потенциал вашей команды. Но даже в этом случае что-
то может пойти не так, поэтому ваша итерация должна содержать резерв времени,
чтобы покрыть эти проблемы.
Никогда не используйте обязательство как дубинку. Не заставляйте членов коман-
ды подписываться на план, с которым они не согласны. Не раскрывайте информацию
об обязательствах по итерациям вне команды, пока у вас не будет подтвержденного
списка успешных случаев выполнения таких обязательств.
Когда вы хорошо планируете ваши задачи:
zz вся команда понимает, что нужно сделать, чтобы завершить истории;
zz команда совместно работает над выполнением своего плана;
zz команда понимает, когда все идет хорошо, а когда нет, и предпринимает действия,
необходимые для решения проблем.
Когда вы правильно применяете итерации:
zz ваша команда имеет стабильный, предсказуемый потенциал;
zz стейкхолдеры знают, чего ожидать от команды, и верят, что она выполнит свои
обязательства по итерации;
zz команда быстро обнаруживает ошибки и обычно может с ними разобраться,
не влияя на свои обязательства по итерации.
Выдающееся отличие Agile-планирования задач от не-Agile — коллективное вла-
дение. Команды Agile не только отвечают за свое планирование, но и совместно
работают над выполнением плана. В не-Agile-командах обычно руководители
распределяют задачи среди сотрудников, и люди фокусируются на своих индиви-
дуальных задачах.
Еще одно различие заключается в итеративной и поэтапной природе Agile.
Маленькие истории приводят к стабильному инкрементному прогрессу. Команды
демонстрируют этот прогресс с помощью работающего ПО каждую неделю или две.
Они используют это ПО для получения обратной связи, которая, в свою очередь,
заставляет их итеративно повторять свои планы.
Когда вы задумаетесь о способах экспериментирования с планированием задач,
помните об этих различиях. Однако не стремитесь слишком сильно к эксперимен-
там: в планировании задач очень много тонкостей, особенно в итерациях, поэтому
сфокусируйтесь на том, чтобы достичь действительно хороших результатов в назна-
чении и выполнении обязательств по недельным итерациям, и только потом ищите
альтернативы. Отведите на это по меньшей мере несколько месяцев.
Когда будете готовы к экспериментам, самым очевидным вариантом будет по-
пробовать непрерывный поток вместо итераций. Кроме того, вы можете поэкспери-
ментировать с длиной итераций и размером историй. Некоторые команды предпо-
читают использовать очень маленькие истории, выполнение которых занимает всего
несколько часов. Для таких команд задачи не являются необходимостью. Истории
настолько малы, что сами по себе служат задачами.
Область, в которой вы можете сразу начать эксперименты, — это визуализация
вашей доски задач. Как наглядное представление процессов вашей команды, она
может и должна меняться в любое время, когда у вас появляются идеи по улучшению
ваших процессов.
Одна из общеизвестных визуализаций задач — создание вертикальных обзор-
ных полос (swim lanes), показывающих прохождение историй через разные фазы
разработки. Я избегаю этого подхода, поскольку Agile проявляет себя наилучшим

образом, когда вы работаете над всеми фазами одновременно, — но, безусловно, это
зависит от практик поставки. Командам, которые не стремятся к компетентности
в области поставки, диаграмма обзорных полос может быть полезна.

Agile Estimating and Planning1 [Cohn2005] и Planning Extreme Programming2 [Beck2000b].
Каждая из этих книг предлагает альтернативные способы подхода к планированию
итераций.
Непрерывный поток часто называют Kanban. Однако Kanban — нечто гораздо
большее, чем просто непрерывный поток. Kanban3 [Anderson2010] — хороший ис-
точник дополнительной информации по этой теме.
ПОТЕНЦИАЛ
Мы знаем, за какой объем работы можем взяться.
Предполагается, что команды, использующие ите- Аудитория
рации, должны завершать каждую историю в каждой
Разработчики
итерации. Но как они узнают, за какое количество
историй они могут взяться? Здесь и появляется по-
нятие потенциала. Потенциал — это прогнозный показатель того, сколько работы
команда может гарантированно выполнить за одну итерацию.
Потенциал нужен только для того, чтобы спрогнозировать, что вы можете вклю-
чить в вашу следующую итерацию. Если же вам нужно рассчитать, когда будет
выпущен конкретный набор историй, то прочитайте раздел «Прогнозирование»
главы 10.
Если вы используете непрерывный поток вместо итераций, то вам не нужно бес-
покоиться о потенциале. Вы просто будете начинать новые истории, когда закончите
предыдущие.
Изначально потенциал (capacity) назывался скоростью (velocity). Но я больше
не использую этот термин, поскольку «скорость» предполагает такой уровень
контроля, которого на самом деле не существует. Представьте автомобиль:
его скорость легко увеличить; просто нажмите педаль газа. Но если вам нужно
повысить потенциал автомобиля, то потребуются более серьезные изменения.
Потенциал команды — то же самое. Его не так просто изменить.
1
Кон М. Agile: оценка и планирование проектов.
2
Бек К., Фаулер М. Экстремальное программирование: планирование. — СПб.: Питер, 2002.
3
Андерсон Д. Дж. Канбан. Альтернативный путь в Agile.
Вчерашняя погода
Потенциал может быть спорной темой. За-
казчики хотят, чтобы команда поставля- Когда на команды давят, чтобы они
ла больше каждую неделю. Разработчики подписались на большее, чем могут
сделать, проигрывают все.
не хотят, чтобы их торопили или давили на
них. Так как заказчики обычно пользуются
вниманием спонсора команды, то имеют тенденцию побеждать… в краткосрочной
перспективе. В долгосрочной перспективе, когда на команды давят, чтобы они под-
писались на большее, чем могут сделать, проигрывают все. Реальность побеждает,
и разработка в итоге занимает больше времени, чем ожидалось.
Чтобы избежать этих проблем, измеряйте свой потенциал. Не гадайте. Не надей
тесь. Просто измеряйте. Это просто: вероятно, на этой неделе вы сделаете столько же,
сколько сделали на прошлой. Это также известно как «вчерашняя погода», поскольку
вы можете прогнозировать сегодняшнюю погоду, говоря, что она, скорее всего, будет
такой же, как вчерашняя.
Если конкретнее, ваш потенциал — это количество историй, которые вы начали
делать и полностью закончили в предыдущей итерации. Частично сделанные исто-
рии не считаются. Например, если вы начали семь историй в прошлой итерации
и завершили шесть из них, то ваш потенциал — шесть, и в следующей итерации вы
можете взять в работу шесть историй.
Не усредняйте несколько итераций. Просто используйте предыдущую. В подраз-
деле «Стабилизация потенциала» далее в этой главе объясняется, как установить
стабильный потенциал без усреднения.
Подсчет историй работает, только если ваши истории примерно одного разме-
ра. Вы можете разделять и объединять истории, чтобы получить размер «в самый
раз», как описывалось в подразделе «Разделение и объединение историй» главы 8.
Со временем ваша команда научится делать истории одного размера.
Поначалу ваши истории, скорее всего, не будут иметь одинаковый размер. В этом
случае вы можете делать оценку историй, как я описываю в подразделе «Оценка
историй» далее в данной главе. Чтобы измерить ваш потенциал, используя оценки,
посмотрите на истории, которые вы начали и полностью завершили за последнюю
итерацию. Сложите их оценки. Это и будет ваш потенциал.
Например, если вы завершили шесть историй из тех, что начали в предыдущей
итерации, и их оценки были 1, 3, 2, 2, 1, 3, то ваш потенциал — 1 + 3 + 2 + 2 + 1 + 3 = 12.
Для следующей итерации вы можете выбрать любые понравившиеся вам истории
так, чтобы их общая оценка равнялась 12.
«Вчерашняя погода» — простой и при этом удивительно утонченный инструмент.
Это петля обратной связи, которая приводит к магическому эффекту: если ваша
команда недооценивает свою рабочую нагрузку и не может завершить все истории
к концу итерации, то ваш потенциал снижается и вы беретесь за меньшее количество
работы в следующий раз. Если вы переоцениваете свою нагрузку и заканчиваете
раньше, то ваша команда берет больше историй, ее потенциал возрастает и вы бере-

тесь за большее количество работы.
Это невероятно эффективный способ ба-
лансировки нагрузки. В сочетании с резервом См. также
времени потенциал позволяет вам достоверно
прогнозировать, сколько работы вы можете Резерв времени (глава 9)
сделать за итерацию.
Потенциал и временные рамки итерации

«Вчерашняя погода» опирается на строгие временные рамки итерации. Чтобы по-
тенциал работал, никогда не засчитывайте истории, которые не получили статус
«Сделано Сделано» в конце итерации. Никогда не сдвигайте, даже на несколько
часов, предельный срок итерации.
У вас может появиться соблазн немного об-
мануть и отодвинуть предельный срок оконча- Искусственное увеличение
ния итерации или засчитать историю, которая цифры вашего потенциала только
почти сделана. Не делайте этого! Конечно, это усложнит выполнение ваших
увеличит цифру вашего потенциала, но нару- обязательств.
шит петлю обратной связи. Вы возьметесь за
больший объем работы, чем сможете выполнить, усилив проблему в следующий раз
и еще больше усложнив выполнение ваших обязательств.
Один руководитель проекта, с которым я сотрудничал, хотел добавить несколько
дней перед началом итерации, чтобы его команда могла немедленно приступить
к работе, а он смог бы получить более впечатляющую цифру потенциала и гордо
продемонстрировать ее своему руководителю. Сделав это, он обрек свою команду на
провал: она не смогла поддерживать взятый темп в следующей итерации. Помните,
что потенциал нужен для прогнозирования того, сколько вы можете уместить в ите-
рацию. Это не показатель продуктивности.
Потенциал не стабилен, когда команды только формируются и учатся работать
по Agile. Для стабилизации потребуются три-четыре итерации. После этого у вас
должен быть один и тот же потенциал на каждой итерации, если она не попадает на
праздничные дни. Используйте ваш резерв времени в итерации, чтобы убедиться,
что стабильно заканчиваете каждую историю. Если потенциал команды меняется
больше чем один-два раза в квартал, то ищите более глубокие проблемы и задумай-
тесь о том, чтобы попросить помощи у наставника.
Стабилизация потенциала
Когда вашей команде не удается закончить все,
что она запланировала, ваш потенциал должен См. также
снизиться. Это даст вам больше времени, чтобы
закончить работу в следующей итерации, что Сделано Сделано (глава 9)
приведет к стабилизации вашего потенциала
на новом, пониженном уровне.
Но как ваш потенциал вернется на прежний уровень? Парадоксально, но вам

нужно быстро снижать потенциал и медленно повышать. Повышайте его лишь тогда,
когда вы не только завершили все запланированные истории, но и имели достаточ-
но времени на уборку по окончании: вы вычистили плохие участки в коде, который
был задействован в итерации, улучшили автоматизацию и инфраструктуру и поза-
ботились о других важных, хотя и не срочных задачах, имеющих отношение к исто-
рии, над которой вы работали.
Если вам хватило времени на уборку, то можете
взять дополнительную историю. Если вы завер- Повышайте потенциал,
шите ее до окончания итерации, то ваш потенциал только когда вам хватает
повысится. времени на уборку
Я работаю со многими командами и вижу одну по окончании работы.
общую проблему — чрезмерное давление на гра-
фик. Оно повсеместно снижает производительность команд, заставляет их торо-
питься, сокращать сроки и совершать ошибки. Эти сокращенные сроки и ошибки
вредят их внутреннему качеству (качеству кода, автоматизации и инфраструктуры),
а плохое качество приводит к тому, что все идет медленнее, из-за чего, как ни стран-
но, им остается меньше времени на работу. Это порочный круг, который и дальше
усиливает нагрузку на график и снижает производительность.
Наиболее эффективный способ улучшить производительность команд в этой
ситуации — снизить давление на график. Потенциал сделает это автоматически, если
вы ему позволите. На рис. 9.3 показана стабилизация потенциала.
Рис. 9.3. Стабилизация потенциала
Тонкая ломаная линия показывает потенциал команды под высоким давлением.

Это потенциал, если члены команды максимально торопятся. Вы можете увидеть, что
он сильно переменчив. Несколько недель все идет гладко. В другие недели команда
сталкивается с багами и проблемами качества.
Толстая плавная линия показывает потенциал команды под низким давлением.
Это результат следования правилу «быстро снижать и медленно повышать». Вы мо-
жете увидеть, что когда команде не удалось сделать все запланированное, ее члены
понизили потенциал и не повышали его какое-то время.
Затененные пики представляют команд-

ный резерв времени: разница между потен- См. также
циалом команды под низким давлением и ко-
личеством времени, которое ей понадобилось Резерв времени (глава 9)
для завершения своих историй. В течение
нескольких недель команда имела очень большой резерв. В другое время — очень
маленький. Когда у команды был большой резерв времени, участники использовали
его для повышения внутреннего качества и решения тормозящих их проблем.
Со временем это дополнительное усилие оправдывает себя. Так как члены ко-
манды не спешат изо всех сил, они постепенно повышают внутреннее качество
и решают проблемы. В результате люди расслаблены, контролируют ситуацию
и имеют больше времени, чем необходимо для уборки. Вот тогда они увеличивают
свой потенциал. Результат — улучшение потенциала и работа, приносящая больше
удовольствия, чем у команд, спешащих изо всех сил.
Этот график иллюстрирует мой реальный
опыт, а не какую-то абстрактную теорию. Резерв времени — лучший из ваших
Я видел множество вариаций на эту тему вариантов реального улучшения
в реальных командах. Может быть трудно количества работы, которую может
выполнить ваша команда.
стабилизировать потенциал, когда ваша ко-
манда находится под высоким давлением, но
оно того стоит. Резерв времени — лучший из ваших вариантов реального улучшения
количества работы, которую может выполнить ваша команда.
Почему точность оценки не имеет значения

Потенциал автоматически подстраивается, если оценки неточные. Вот как это
работает.
Предположим, у вас есть 30 человеко-дней на одну итерацию. Для упрощения
примера пусть все истории команды оцениваются в три дня работы каждая. Если
оценки идеально точны, то команда должна быть в состоянии сделать 10 историй
за итерацию (30 человеко-дней на одну итерацию ÷ 3 дня на историю).
Но оказывается, что их оценки не идеально точны! Фактически они даже не рядом.
На самом деле от команды требуются шесть человеко-дней на завершение каж-
дой истории, а не три. В конце итерации команда закончила только пять историй
(30 человеко-дней на одну итерацию ÷ 6 дней на историю).
Измеренный потенциал команды — 15: члены команды закончили пять историй,
оцениваемых в три дня каждая. Таким образом, в следующей итерации они могут
взяться только за пять историй (потенциал 15 ÷ 3 дня на историю). И хотя их оценки
совершенно неверны, они завершат все истории до единой (30 человеко-дней
÷ 6 дней = 5 историй).
Эти расчеты приведены только для того, чтобы вы понимали петлю обратной
связи. В реальном мире вам не нужно производить никаких расчетов. Сочетание
потенциала и резерва времени необыкновенно простое и устойчивое. Просто
стабилизируйте ваш потенциал, как я описал, и все получится.
Оценка историй
«Вчерашняя погода» полагается на стабильность, но у вашей команды могут быть
трудности с созданием историй постоянного размера. Это нормально. Вы можете
использовать оценку.
Как обсуждалось во врезке в предыдущем подразделе, неважно, насколько точны
ваши оценки, пока они постоянны. Это хорошая новость, поскольку программисты,
как правило, оценивают очень плохо. Одна команда, с которой я работал, измеряла
реальное время, которое занимали ее истории. Мы делали это в течение 18 месяцев.
Оценки никогда не были точными: в среднем команда использовала около 60 %
фактически необходимого времени.
Но знаете что? Это было неважно, поскольку оценки, даваемые командой, были
стабильны, по крайней мере в совокупности. У той команды был стабильный по-
тенциал, и она постоянно завершала каждую историю в течение нескольких месяцев.
Таким образом, делайте оценку ваших историй и не беспокойтесь о точности.
Просто концентрируйтесь на стабильности. Вот как это нужно делать.
zz Оценивайте только ограничение. Один вид работы (как правило, программиро-
вание) будет узким местом всего рабочего процесса вашей команды. Оценивайте
все ваши истории только с точки зрения этого вида работы, поскольку именно
ваше ограничение будет определять ваш график работы. Иногда будут встречаться
исключения, но их компенсирует резерв времени в итерации.
zz Позвольте экспертам делать оценки. Сколько времени займет работа над
историей, по мнению членов команды, наиболее квалифицированных в этой
работе?
zz Делайте оценку в идеальных часах или днях. Сколько времени займет работа над
историей, если ее будет делать один из наиболее квалифицированных членов
вашей команды, его не будет никто отвлекать от работы, он сможет задавать во-
просы любому другому человеку в команде, не должен будет ждать никого вне
команды и все будет идти хорошо?
zz Думайте о задачах. Если вам трудно делать оценки, то мысленно разбейте исто-
рию до составляющих ее задач, затем сложите время, необходимое на выполнение
каждой из них.
zz Округляйте в три корзины. Все, что больше, должно быть разделено; все, что
меньше, — объединено. Чтобы выбрать свою корзину, разделите ваш потенциал
на 12, затем умножьте на 2 и 3. Настраивайте результаты по мере необходимости.
Например, если ваш потенциал находится между 9 и 14, то ваша корзина должна
быть размером 1, 2 и 3. Если потенциал между 3 и 8, то ваша корзина должна
быть размером 1/2, 1 и 11/2. Цель — иметь по меньшей мере четыре истории на
итерацию и шесть в среднем.
Этот подход даст вам оценку в идеальных часах или днях. Реальная работа займет
гораздо больше времени, но это неважно: вы стремитесь к постоянству, а не к точно-
сти. Чтобы люди ошибочно не принимали ваши оценки за обязательства, называйте
эти цифры пойнтами, а не часами или днями.
Когда вы наберетесь опыта, эти техники будут работать еще лучше.

zz Ищите совпадения с другими историями. Что вы говорили о других историях,
похожих на эту? Используйте те же оценки.
zz Сравнивайте с другими историями. Эта история потребует в два раза больше
работы или в два раза меньше, чем другая? Соответственно увеличьте или умень-
шите оценку вдвое.
zz Прислушайтесь к своему чутью. Используйте те цифры, которые вам кажутся
правильными.
У меня есть два вида оценочных сессий, которые вы можете использовать: раз-
говорные оценки и оценки по сходству. В любом случае привлеките всех, кто имеет
квалификацию, позволяющую выполнять эту работу (оценщики), и по меньшей мере
одного заказчика в команде. Другие члены команды тоже могут присоединиться (для
них обсуждения могут быть информативны), но это не обязательно.
Пример оценочной сессии: разговорная оценка

Команда собралась для оценки историй. Элисса, одна из заказчиков в команде,
начинает дискуссию. Кенна, Инга и Остин — программисты.
Элисса: Вот наша следующая история. (Она читает историю вслух, потом кладет
ее на стол.) «Отчет о запасах запчастей на складе».
Кенна: Это часть усилий по устранению расхождений в складских данных, да?
(Элисса кивает.) Мы уже сделали столько отчетов на сегодняшний день, что еще
один не должен вызвать трудностей. Они обычно состоят из одного пункта. Мы уже
отслеживаем складские запасы, так что нам не понадобится управлять какими-
либо новыми данными. Есть что-то необычное в этом отчете?
Элисса: Не думаю. Мы соберем макет. (Она вытаскивает распечатку и передает
ее Кенне.)
Кенна: Выглядит довольно понятно. (Она кладет бумагу на стол. Другие програм-
мисты смотрят ее.)
Инга: Элисса, что это за колонка «возраст»? Не думала, что возраст имеет отно-
шение к расхождениям на складе.
Элисса: Верно, не имеет. Это количество рабочих дней с того момента, как зап-
часть поступила на склад. Мы подумали, что это будет полезно на будущее.
Инга: Нужны рабочие дни, не календарные?
Элисса: Совершенно верно.
Инга: Как насчет праздников?
Элисса: Мы хотим считать только те дни, в которые работаем. Без выходных,
праздников и плановых остановок.
Остин: Инга, я вижу, к чему ты клонишь. Элисса, у нас есть дата, когда зап-
часть поступила на склад, но мы сейчас не отслеживаем плановые остановки.
Нам понадобится новый UI или поток данных, чтобы получить эту информацию.
Это может усложнить экраны администраторов, а ты и Брэдфорд говорили, что
простота администрирования важна для вас. Можем ли мы делать этот отчет

в календарных днях?
Элисса: Хм. Точное число неважно, но люди обычно мыслят в терминах рабочих
дней, и если мы собираемся предоставлять эту информацию, то я бы хотела, чтобы
она была точной. Что насчет праздников? Вы сможете это сделать?
Инга: Мы можем считать, что праздники будут одни и те же каждый год?
Элисса: Не обязательно. Но они не будут меняться слишком часто.
Инга: Хорошо. Тогда мы можем пока поместить их в конфигурационный файл,
вместо того чтобы создавать для них UI. Это обойдется дешевле.
Элисса: Знаешь, я хочу отложить это на потом. Это поле — не самый главный наш
приоритет, и я не думаю, что оно достойно дополнительных затрат. Давайте пока
это оставим. Я сделаю для этого отдельную историю. (Она берет карточку и за-
писывает: «Добавить колонку “возраст” к отчету о запасах запчастей».)
Остин: Звучит неплохо. Этот отчет будет довольно простым. Для него нужен UI?
Элисса: Все, что нам нужно сделать, — это добавить его в список на экране отчетов.
Инга: Думаю, я готова сделать оценку. (Смотрит на других программистов.) Мне
кажется, это довольно стандартный отчет. Это еще одна специализация для
уровня отчетов с несколькими небольшими изменениями в логике. Я согласна
с Кенной. Это один пункт.
(Остин кивает.)
Кенна: Один пункт. (Она записывает «1» на карточке истории.) Элисса, я думаю,
мы не сможем оценить историю «возраст», пока ты не будешь знать, какой UI
хочешь для этого.
Элисса: Справедливо. (Добавляет стикер «Раб. дней? UI?» на карточку «возраст»
и откладывает ее в сторону.) Наша следующая история...
Разговорная оценка
При разговорной оценке команда оценивает одну историю за раз. Этот способ может
быть утомительным, но позволяет привести всех к единому пониманию того, что
должно быть сделано.
Заказчик в команде начинает каждую сессию оценки, выбирая историю и давая
краткое пояснение. Оценщики могут задавать вопросы, но только если ответ может
как-то изменить их оценку. Как только кто-то из оценщиков чувствует, что у него
достаточно информации, он предлагает свой вариант оценки. Пусть это происходит
естественно: тот, кому комфортнее всех, должен высказаться первым, так как обычно
это именно тот человек, который наиболее квалифицирован для оценки.
Если предложенный вариант оценки кажется неверным или если вы не понимаете,
из чего он следует, то попросите больше подробностей. В качестве альтернативы,
если вы один из оценщиков, то предложите собственный вариант оценки и объяс-
ните свой ход мыслей. Последующая дискуссия прояснит оценку. Когда оценщики
придут к согласию, запишите оценку на карточку истории.
Поначалу у разных членов команды будут разные идеи о том, сколько времени зай
мет что-либо. Это будет приводить к нестабильным оценкам. Проговорите это, и если
вы не сможете прийти к согласию, то используйте наименьшую оценку. (Помните,
вам нужно только постоянство, а не точность.) Со временем, когда команда будет
продолжать совместно делать оценки, ваши оценки будут синхронизироваться. Как
правило, это происходит в течение трех или четырех итераций.
Если участники понимают историю и лежащую в ее основе технологию, то смогут
оценить каждую историю менее чем за минуту. Если им необходимо обсудить тех-
нологию или задать вопросы заказчикам, то оценка может занять больше времени.
Я ищу способы завершить дискуссию, если процесс оценки начинает занимать больше
пяти минут. Если каждая история требует подробного обсуждения, то что-то идет
не так — см. подраздел «Когда оценить трудно» далее в текущей главе.
Некоторым нравится использовать для оценки покер планирования (planning
poker)1. В нем участники тайно выбирают карточку со своей оценкой, затем
одновременно раскрывают карты и обсуждают результаты. Это звучит забавно,
но приводит к множеству ненужных дискуссий. Данный метод полезен, если
людям трудно выражать свое мнение, но в других случаях обычно быстрее дать
высказаться первым тому, кто не испытывает с этим неудобств.
Оценка по сходству
Оценка по сходству (affinity estimating) — прекрасная техника быстрой оценки боль-
шого количества историй2. Она особенно полезна, когда у вас длинные горизонты
планирования.
Оценка по сходству — вариант молчаливого сопоставления (mute mapping)
(см. пункт «Работайте одновременно» главы 7). Заказчик в команде кладет стопку
карточек для оценки на стол или виртуальную доску. Один конец определяется как
наименьший, а другой — как наибольший. Затем оценщики распределяют карточки
вдоль этого спектра, группируя их в кластеры похожего размера. Карточки, которым
требуются дополнительные пояснения от заказчиков, помещаются в отдельный
кластер в стороне, как и карточки, которым требуется спайк-история (см. пункт
«Спайк-истории» главы 8).
Вся эта работа выполняется молча. Оценщики могут передвигать карточки, если
не согласны с тем, где те находятся, но не могут это обсуждать. Выполнение этой
работы в тишине помогает не отвлекаться, что обычно характерно для процесса об-
суждения оценок. В результате составление карты оценок происходит очень быстро.
1
Покер планирования (planning poker) был изобретен Джеймсом Греннингом в 2002 году
[Grenning2002] и позже популяризирован Майком Коном в [Cohn2005]. Компания Кона, Mountain
Goat Software, LLC, зарегистрировала этот термин как торговую марку.
2
Оценка по сходству (affinity estimating) была изобретена Ловеллом Линдстромом в ранние дни
экстремального программирования.
Один человек рассказывал мне, что их команда оценила 60 историй за 45 минут

в первый же раз, когда они пробовали этот метод.
После того как все истории сгруппированы, команда отмечает каждый кластер
цифрой оценки. Цифры на самом деле неважны, если верны относительные раз-
меры. Другими словами, история в кластере, отмеченном цифрой 2, должна за-
нимать в два раза больше времени, чем история в кластере, отмеченном цифрой 1.
Однако для согласованности с разговорными оценками может иметь смысл делать
оценки в идеальных часах или днях. Оценка кластеров должна занимать всего
минуту или две.
В конце выберите три кластера, совпадающих с вашими оценочными корзинами
(описанными ранее). Например, если ваш потенциал равен 15, вы выберете кластеры,
оцененные в 1, 2 и 3. Истории в более крупных кластерах должны быть разделены,
а в более мелких — объединены.
Карточки в ваших трех финальных корзинах готовы к работе. Запишите на каждой
их оценки. Оставшиеся карточки нужно разделить, объединить, обсудить или исследо-
вать с помощью спайк-историй в зависимости от того, в каком кластере они оказались.
Это можно делать одновременно, а затем провести следующую сессию сопоставления
оценок или последовательно, по одной за раз, с помощью разговорной оценки.
Когда оценить трудно

Когда ваша команда только формируется, процесс оценивания будет довольно мед-
ленным и болезненным. По мере применения он будет улучшаться.
Одна общая причина медленного оценивания — недостаточная подготовка со
стороны заказчиков в команде. Поначалу оценщики задают вопросы, которые заказ-
чики не принимали во внимание. В некоторых случаях заказчики могут иметь между
собой разногласия насчет правильного ответа и должны разобраться с этим.
Совещание заказчиков (customer huddle) (на котором заказчики вкратце обсуж-
дают какой-либо вопрос, приходят к решению и возвращаются к оценке) — один из
способов, позволяющих с этим справиться. Пока заказчики совещаются, оценщики
продолжают оценку историй, с которыми им все понятно.
Другой вариант — записать вопрос на стикер и приклеить его на карточку.
Заказчики берут карточку и прорабатывают детали в своем темпе, затем приносят
ее обратно на оценку к следующей сессии.
Неопытность разработчиков также может быть причиной медленного процесса
оценивания. Если оценщики не очень хорошо понимают истории, то должны будут
задать множество вопросов, прежде чем смогут сделать оценку. Однако если они
не понимают технологию, то нужно просто создать спайк-историю (см. пункт «Спайк-
истории» главы 8) и идти дальше.
Некоторые оценщики стараются разобраться со всеми деталями истории до того,
как делать оценку. Помните, что единственные детали, которые имеют значение во
время оценки, — это те, из-за которых историю могут поместить в другую корзину.
Сосредоточьтесь на деталях, которые могут изменить оценку, и отложите остальное
на потом.
Такое чрезмерное внимание к деталям иногда является следствием того, что

оценщик неохотно делает оценку. Это свойственно программистам, которые сталки-
вались в прошлом с использованием своих оценок против себя. Они будут пытаться
делать максимально точные оценки, вместо того чтобы стремиться к «достаточно
хорошему» постоянству.
Сопротивление оценщиков может быть признаком организационных сложно-
стей или чрезмерного давления на график либо может быть сопряжено с прошлым
опытом, никак не связанным с нынешней командой. В последнем случае оценщики
обычно со временем начинают доверять команде.
Чтобы помочь с решением этих проблем во время сессии оценки, вы можете за-
давать наводящие вопросы. Например:
zz проблемы у заказчиков — требуется ли совещание заказчиков по этому вопросу?
Не нужно ли сделать историю для этого вопроса и вернуться к нему позже?
zz оценщики не уверены насчет технологии — не нужно ли нам создать спайк-историю
для этого?
zz оценщики задают очень много вопросов — у нас достаточно информации, чтобы
оценить эту историю? Ответ на этот вопрос повлияет на оценку истории?
zz история занимает больше пяти минут — может, вернемся к этой истории
позже?
Защита оценки
Это почти закон природы: заказчики в команде и стейкхолдеры неизменно разоча-
рованы потенциалом своей команды. Иногда они выражают это в неуважительной
манере. Члены команды, обладающие хорошими социальными навыками, могут по-
мочь разрядить обстановку. Часто лучшим подходом будет игнорировать тон людей
и расценивать комментарии как простые запросы информации.
На самом деле некоторое количество обмена репликами даже полезно. Как
обсуждалось в подразделе «Как выиграть в игре в планирование» главы 8, во-
просы относительно оценок могут приводить к созданию лучших историй,
сфокусированных на таких аспектах идей заказчиков, как высокая ценность
и низкая стоимость.
Однако будьте осторожны: вопросы мо-
гут заставить оценщиков усомниться в сво- Вежливо и твердо откажитесь менять
их оценках. Разработчики, ваши оценки, вашу оценку, если на вас давят.
скорее всего, корректны или по меньшей
мере стабильны, что действительно важно. Меняйте свою оценку, только если узнали
что-то поистине новое. Не меняйте ее лишь потому, что чувствуете, что на вас давят.
Вы — те, кто будет реализовывать истории, и вы наиболее квалифицированны, чтобы
делать оценки. Будьте вежливы, но настойчивы:
Мне жаль, что вам не нравятся эти оценки. Мы уверены, что они корректны, но
если они слишком пессимистичны, то наш потенциал автоматически возрастет,
чтобы компенсировать это. У нас есть профессиональные обязательства перед

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

не осознавать, насколько невежливо себя ведет. Иногда может помочь, если вы про-
сто объясните ему, как выглядит его поведение:
У меня складывается впечатление, что вы не уважаете и не доверяете нашему

профессионализму. Вы действительно имеете это в виду?
Стейкхолдеров также может смутить идея оценки

в пойнтах. По этой причине я стараюсь избегать делить- См. также
ся информацией о потенциале и оценках с кем-либо
за пределами команды. Вместо этого я отчитываюсь Дорожные карты
об историях и инкрементах, над которыми мы сейчас (глава 10)
работаем. Но если все же нужны объяснения, то я на-
чинаю с простого.
Пoйнт (point) — метод оценки, ориентированный на единообразие. Он позволяет

делать краткосрочные прогнозы, основываясь на результатах измерений. Наш
потенциал по результатам измерений — 12 пойнтов, это означает, что мы закон-
чили 12 пойнтов работы за прошлую неделю. Следовательно, мы прогнозируем,
что сможем завершить 12 пойнтов работы на этой неделе.
Иногда люди возражают против измерения потенциала. «Если в вашей команде

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

человеко-дни. Если хотите, то мы можем провести детальный аудит нашей ра-
боты на следующей неделе и точно сказать вам, куда уходит время. Это может
помочь?
Обычно собеседник на этом отступает, но если скажет «да», то детально отсле-

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

Когда вы планируете вашу первую итерацию, у вас еще нет никакой истории, поэто-
му у вас не будет ни потенциала, ни оценочных корзин.
Начните с использования недельных итераций и корзин размером 1/2 дня, 1 день
или 1,5 дня. Работайте над одной или двумя историями за раз, как обсуждалось
в подразделе «Ваша первая неделя» ранее в данной главе. В конце первой итерации
у вас будет потенциал, который вы сможете использовать для следующей итерации.
Помните, что не нужно засчитывать незавершенные истории. Выбросьте их и соз-
дайте новые истории с новыми оценками,
представляющими количество оставшей- Частично сделанная работа никогда
ся работы. (Да, это означает, что вы не за- не засчитывается.
считаете частично сделанную работу. Она
никогда не засчитывается.)
Если у вас сделано меньше четырех историй, то разделите оценочные корзины
на две (используйте двух-, четырех- и шестичасовые корзины) для вашей сле-
дующей итерации. Если сделано 12 историй, то увеличьте корзину вдвое (один,
два и три дня). Продолжайте таким образом, пока ваш потенциал не стабилизи-
руется.
Ваш потенциал должен стабилизироваться после примерно четырех итераций.
По мере приобретения опыта вы, в конце концов, сможете задавать размер историй
так, чтобы завершать одно и то же их количество за каждую итерацию. Когда это
станет привычным, вы можете совсем перестать делать оценки и просто считать
истории. Но чтобы быть уверенными в правильности размера историй, вам все еще
будет необходимо обсуждать их с заказчиками.
Как улучшить потенциал

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

Наиболее распространенная проблема с потенциалом — низкое внутреннее качество:
плохой код, медленные и ненадежные тесты, плохая автоматизация и ненадежная
инфраструктура. Это также называется техническим долгом.
Внутреннее качество влияет на команду гораздо сильнее, чем любой другой
фактор. Сделайте внутреннее качество вашим приоритетом, и оно значительно
улучшится. Однако это не быстрый процесс. Командам, имеющим проблемы низ-
кого внутреннего качества, часто предстоят месяцы или даже годы работы по очист-
ке от проблем.
Вместо того чтобы останавливать всю
работу, чтобы разобраться с проблемами, См. также
улучшайте качество инкрементно, исполь-
зуя резерв времени, как описывалось в под- Резерв времени (глава 9)
разделе «Стабилизация потенциала» ранее
в данной главе. Выработайте привычку непрерывно улучшать все, к чему прикасае-

тесь. Будьте терпеливы: вы должны почувствовать моральный подъем почти сразу,
но можете не увидеть никаких улучшений потенциала в течение нескольких месяцев.
Улучшить навыки в сфере деятельности заказчика

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

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

Члены команды, которые могут работать над ограничениями (часто это программи-
сты), должны передавать работу, которую могут выполнить другие. Найдите способы
оградить их от ненужных совещаний, прерываний, и пусть кто-то другой занимается
организационной бюрократией, такой как учет рабочего времени и отчеты о расходах.
Вы можете даже найти ассистента для команды.
Поддерживать ограничение
Люди, которые не могут участвовать в работе над задачами, связанными с ограни-
чениями, будут иметь свободное время. Они должны сделать так, чтобы тем, кто
работает над ограничениями, никогда не приходилось их ждать, но не должны рабо-
тать на опережение. Это только создаст дополнительный объем незавершенной
работы (см. врезку «Минимизируйте объем незавершенной работы» в главе 8).
Вместо этого используйте дополнительное время для снижения нагрузки на актив-
ность, связанную с ограничением. Классический пример — тестирование. Некоторым
командам нужно так много ручного тестирования,
что последние дни каждой итерации у них полно- Используйте
стью посвящены тестированию ПО. Вместо того дополнительное время
чтобы переходить к разработке следующего набора для снижения нагрузки
функциональностей, программисты могут использо- на активность, связанную
вать это время для написания автоматизированных с ограничением.
тестов, что снизит нагрузку на тестирование.
Обеспечивать необходимые ресурсы

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

Потенциал связан с количеством людей, которые
могут работать в условиях ограничений вашей См. также
команды. Но если ваша команда не испыты-
вает крайней нехватки персонала и опытные Парное программирование
(глава 12)
сотрудники легкодоступны, то ее пополнение
не окажет немедленного эффекта. Как сказал Групповое программирование
[Brooks1995], «добавление людей в отстающий (глава 12)
проект делает его еще более отстающим». Ожи- Коллективное владение кодом
дайте, что новым членам команды понадобится (глава 12)
месяц или два, чтобы стать продуктивными. Командная комната (глава 7)
Сократить этот срок может помочь плотное
взаимодействие.
Аналогично пополнение больших команд может вызвать трудности с общением
и снижение продуктивности. Я предпочитаю, чтобы в команде, использующей парное
программирование, было шесть программистов, и всегда готов добавить хороших
программистов, чтобы достичь этого предела. После него я уже осторожен в плане
добавления новых людей и крайне редко увеличиваю команду, если она достигла
размера восьми человек. Другие навыки добавляются пропорционально, как рас-
сказывается в разделе «Вся команда» главы 7.
Потенциал — это не производительность

Одна из наиболее распространенных ошибок, со-
вершаемых организациями, заключается в сме- Потенциал — инструмент
шивании понятий «потенциал» и «производи- прогнозирования, а не мера
тельность». Позвольте мне пояснить: потенциал производительности.
не является мерой производительности. Это
инструмент прогнозирования. Конечно, на потенциал влияют изменения произво-
дительности, но он их не измеряет, и эта взаимосвязь не очень прочная. В частности,
нельзя сравнивать между собой потенциалы разных команд.
Потенциал представляет собой совокупность многих факторов: количество людей,
работающих в условиях ограничений. Количество их рабочих часов. Отношение их
оценок к реально затраченному времени. Внутреннее качество их ПО. Количество
времени, которое они тратят на ожидание других людей. Время, которое они тратят
на выполнение рутинных задач организации. Как часто они выбирают «короткий
путь», выполняя задачи. Объем их резерва времени.
Эти факторы различаются у каждой команды, поэтому вы не можете использо-
вать потенциал для сравнения двух команд. Если у одной команды вдвое больший
потенциал, чем у другой, это может означать, что у нее меньше затрат на рутину… но
более вероятно, что у нее просто другой подход к оценке.
Кроме того, у команд нет возможности контролировать большинство факторов,
которые влияют на потенциал. В краткосрочной перспективе они могут только
управлять количеством своих рабочих часов и количеством «коротких путей».
Таким образом, команда, о которой судят по ее потенциалу, может ответить на это
давление, только работая сверхурочно, делая работу небрежно или уменьшая свой
резерв времени. Это может вызвать краткосрочный скачок потенциала, но снизит
реальную способность команды поставлять продукт.
Не разглашайте значение потенциала команды за ее пределами. Если вы руко-
водитель, то не отслеживайте, не поощряйте и даже не обсуждайте потенциал, за
исключением вопросов содействия его стабилизации. И никогда не называйте его
производительностью.
Чтобы понять, что нужно делать вместо этого, прочтите раздел «Менеджмент»
главы 10.
Нужно торопиться
«Вам нужно поторапливаться! — рявкает Бекки. Она руководитель
вашего руководителя. — У команды Сильвы потенциал вдвое
больше вашего. Это ненормально, что у вас вдвое меньшая про-
изводительность».
«Окей… — говорите вы, с трудом подавляя желание сделать
что-нибудь неблаговидное и наконец освободиться от всего
этого. — Во-первых, команда Сильвы занята совершенно другой
работой, поэтому значения потенциала несравнимы. Во-вторых, — вы пытаетесь
улыбнуться, — я бы очень хотел повысить наш потенциал. Самое большое препят-
ствие, которое нас сдерживает, — ограниченный доступ к Кристиане. Она не хочет,
чтобы мы сами общались со стейкхолдерами, но при этом не может участвовать
в наших сессиях планирования. Нам постоянно приходится переделывать работу».
«Ох, только не надо, — не соглашается Бекки. — Она занята. А вы же Agile. Это
значит — вы владельцы, и у вас ответственность, верно? Вот и разберитесь с этим».
Неблаговидные поступки — это, наверное, не так уж и плохо, правда? К счастью,
из-за угла выходит ваш руководитель, Даррел.
«Бекки! Как хорошо, что я тебя встретил. Я услышал, что ты говорила насчет
Кристианы, и у меня есть отличная идея. Ты права насчет владения и ответствен-
ности. Почему бы нам не забрать часть работы у Кристианы? Мы возьмем на
себя общение со стейкхолдерами, а у нее освободится время для того, чтобы
сфокусироваться на...» — Даррел уходит, увлекая за собой Бекки, и вы облегченно

вздыхаете. Хорошо, что у вас есть Даррел, который может справиться с требо-
ваниями Бекки.
Или вы можете просто сфальсифицировать более высокий потенциал. Умножение
всех ваших оценок на три должно сделать свое дело.
Вопросы
Как нам считать частично выполненные истории?
Частично выполненные истории не считаются. При наличии нескольких таких
историй в конце итерации создайте новую историю для оставшейся работы и заново
оцените ее, если используете оценки. (Больше информации вы найдете в подразделе
«Незаконченные истории» ранее в данной главе.) Та часть, которую вы сделали в этой
итерации, не засчитывается в ваш потенциал; это значит, ваш потенциал снизится.
Возможно, это звучит сурово, но если вы правильно используете итерации, по-
тенциал и резерв времени, то частично выполненные истории должны случаться
редко. Если они у вас есть, значит, что-то пошло не так. Снижение вашего потенциала
высвободит резерв времени, необходимый вашей команде для решения проблемы.
Как нам менять потенциал при добавлении или удалении людей из команды?
Если вы добавляете в команду или выводите из нее только одного человека, то
попробуйте оставить ваш потенциал без изменений и посмотрите, что получится.
Другой вариант — изменять ваш потенциал пропорционально. В любом случае ваш
потенциал примет правильное значение после следующей итерации.
Как мы можем иметь стабильный потенциал? Люди уходят в отпуска, болеют и т. д.
Резерв времени вашей итерации должен справиться с небольшими колебаниями
доступности людей. Если отсутствует больше людей, как, например, в праздники, то
ваш потенциал может снизиться на одну итерацию. Это нормально. Вы можете его
восстановить в следующей итерации.
Если у вас маленькая команда, то вы можете обнаружить, что даже одного дня
отсутствия достаточно для дестабилизации потенциала. В этом случае вы можете
попробовать использовать двухнедельные итерации. Возможные компромиссы
обсуждались в пункте «Итерации» ранее в данной главе.
Разве участие в совместной оценке историй не является лишней тратой времени
для каждого?
Людям требуется много времени на совместную оценку, но это время потрачено
не зря. Сессии оценки нужны не только для оценки — вдобавок к этому они являются
критически важным первым шагом в получении информации и прояснении того,
что нужно сделать. Разработчики задают вопросы и проясняют детали, что часто
порождает идеи, которые заказчики в команде даже не рассматривали. Иногда это
сотрудничество снижает общие затраты, как описывается в подразделе «Как выиграть
в игре в планирование» главы 8.
Все разработчики должны присутствовать, чтобы убедиться в том, что они пони-
мают, чем им предстоит заниматься. Их участие также улучшает стабильность оценок.
Не рискованно ли делать оценки на основе самого квалифицированного члена

команды? Может, нам лучше использовать среднего члена команды или наименее
квалифицированного для большей безопасности?
Петля обратной связи «Вчерашняя погода» избавляет от необходимости точной
оценки, как описывается во врезке «Почему точность оценки не имеет значения»
ранее в данной главе. Поэтому все варианты одинаково безопасны. Что действи-
тельно важно, так это стабильность оценок, а думать в терминах идеального времени
и наиболее квалифицированного члена команды — самый легкий способ прийти
к стабильности.
Когда нам переоценивать наши истории?
Поскольку оценки историй должны быть согласованными друг с другом, вам
не нужно переоценивать истории, если только не меняется объем работы. И даже
тогда не делайте переоценку истории после того, как начали над ней работать, по-
скольку вы будете знать уже слишком много деталей реализации, чтобы согласовать
оценку с предыдущими.
Вместе с тем если ваши ограничения меняются и оценки начинают делать разные
люди, то и ваши оценки, и ваш потенциал должны начаться с нуля.
Чтобы выполнить оценку, мы сделали несколько предположений, касающихся
технического дизайна. А что, если он изменится?
В Agile предполагается, что вы создаете ваш дизайн инкрементно и со временем
полностью улучшаете его. В результате ваши оценки обычно будут оставаться ста-
бильно согласованными друг с другом.
Как нам работать с техническими взаимозависимостями в наших историях?
При условии правильного инкрементно-
го дизайна технические взаимозависимости
См. также
будут редкими, хотя и могут случаться. Как
правило, я делаю отметку вместе с оцен- Инкрементный дизайн (глава 14)
кой: «6 (4, если история Foo будет сделана
первой)».
Потенциал предполагает использование
итераций и требует резерва времени, чтобы См. также
сгладить небольшие проблемы и несты-
ковки. Планирование задач (глава 9)
Оценка требует доверия: разработчики Резерв времени (глава 9)
должны верить, что они могут давать точные
Доверие стейкхолдеров (глава 10)
оценки, не опасаясь нападок, а заказчики
и стейкхолдеры должны верить, что разра-
ботчики дают честные оценки. Этого доверия поначалу часто может не быть, и тогда
вам нужно работать над тем, чтобы оно появилось.
Независимо от вашего подхода к оценкам и потенциалу никогда не используйте
значения потенциала или неверные оценки для нападок на разработчиков. Это бы-
стрый и легкий способ разрушить доверие.
Когда вы правильно используете потенциал:
zz он последователен и предсказуем каждую итерацию;
zz вы берете на себя итерационные обязательства и стабильно их выполняете;
zz процесс оценки проходит быстро и легко или вообще не требуется;
zz вы можете измерить большинство историй за минуту или две.
Идея в основе потенциала — это «Вчерашняя погода»: фокусироваться на стабиль-
ности и согласованности, а не точности; основывать свои прогнозы на прошлых
измерениях и использовать их для создания петли обратной связи, которая будет
автоматически сама себя корректировать.
Количество подходов к оцениванию и прогнози-
рованию бесконечно. Преимущество «Вчерашней См. также
погоды» — в простоте и надежности. Однако она не без-
упречна и полагается на резерв времени, чтобы компен- Резерв времени (глава 9)
сировать свои недостатки. Другие подходы много чего
усложняют в попытке достичь большей точности. Несмотря на эту дополнительную
сложность, я еще не видел, чтобы кто-то приблизился к тому, чтобы работать так, как
комбинация петли обратной связи «Вчерашняя погода» и резерва времени.
Вы можете поэкспериментировать в поисках лучших способов определения по-
тенциала, но не делайте это сразу. Сначала научитесь применять подход из данной
книги и надежно завершать итерации и поработайте с ним несколько месяцев. Смена
подхода к планированию потенциала имеет глубокий эффект, и его трудно увидеть,
не обладая достаточным опытом.
Одна из известных мне наиболее популярных альтернатив — основывать потен-
циал на среднем значении предыдущих итераций, а не на одной прошлой. Другой
подход — засчитывать истории, которые были начаты в одной итерации и закончены
в другой. Я думаю, что оба подхода ошибочны: они основываются на желании повы-
сить потенциал, но увеличивают только цифру, обозначающую потенциал, не увели-
чивая реальную способность команды поставлять продукт. Они лишь увеличивают
вероятность того, что командам будет сложно выполнять свои обязательства. Лучше
сделать над собой усилие, запланировать более низкий потенциал и использовать
имеющийся резерв времени, чтобы повысить фактическую, реальную возможность
команды поставлять продукт.
Другой популярный вариант — движение без оценок (#NoEstimates), которое
полностью отходит от них. Существуют два подхода без оценок, и я включил их
в эту книгу. Первый — считать истории, вместо того чтобы оценивать их, как опи-
сывается в данной практике. Некоторые команды используют очень маленькие
истории (больше дюжины на итерацию), чтобы это работало. Второй подход — во-
обще не использовать итерации, а вместо этого применять непрерывный поток, как
описывается в разделе «Планирование задач» ранее в данной главе. Обе идеи стоит
попробовать после того, как вы овладеете основами.
РЕЗЕРВ ВРЕМЕНИ
Мы выполняем наши обязательства по итерации. Аудитория
Представьте, что кабель электропитания вашей Разработчики

рабочей станции имеет строго определенную длину
и едва дотягивается до розетки. Вы можете вставить
вилку в розетку, туго натянув кабель, но малейшая вибрация приведет к тому, что
он вывалится из розетки и электропитание компьютера отключится. Вы лишитесь
всего, над чем работали.
Я не могу позволить, чтобы электропитание моего компьютера пропадало по
малейшему поводу. Моя работа слишком важна. В этой ситуации я бы передвинул
компьютер поближе к розетке, чтобы кабель мог выдержать некоторые небольшие
воздействия. (Потом я бы прикрепил кабель к полу, чтобы об него никто не мог
споткнуться, поставил бы источник бесперебойного питания (uninterruptable power
supply, UPS) и вложился бы в решение, позволяющее выполнять непрерывное ре-
зервное копирование (continuous backup solution).)
Ваши планы на итерацию тоже слишком важны, чтобы быть разрушенными
малейшим воздействием. Как и кабелю электропитания, им нужен резерв времени.
Сколько резерва нужно

Количество резерва, которое вам нужно, не зависит
от количества проблем, с которыми вы сталкиваетесь. См. также
Оно зависит от степени хаотичности этих проблем.
Если вы всегда испытываете проблем точно на 20 ча- Потенциал (глава 9)
сов в каждой итерации, то ваш потенциал автоматиче-
ски их компенсирует. Однако если у вас будет между 20 и 30 часами проблем, то ваш
потенциал будет колебаться то вверх, то вниз. Вам нужно 10 часов резерва, чтобы
стабилизировать потенциал и выполнить свои обязательства.
Помните, что команда сама решает, какие обязательства принимать на себя и де-
литься ли своими планами по этим обязательствам за пределами команды. Более
подробная информация представлена в подразделе «Принятие и выполнение
обязательств по итерации» ранее в данной главе.
Эти цифры приведены только для иллюстрации. Вместо того чтобы измерять
количество часов, которое вы тратите на решение проблем, воспользуйтесь петлей об-
ратной связи потенциала, описанной в подразделе «Стабилизация потенциала» ранее
в данной главе. Если ваш потенциал колеблется в большом диапазоне, то перестаньте
подписываться на большее количество историй, чем позволяет ваш потенциал. Это
приведет к тому, что он установится на более низком уровне, который будет содер-
жать резерв времени вашей команды. С другой стороны, если вы все завершаете рано,
включая время на очистку во всех частях кода, в которых что-то делали, то уменьшите
ваш резерв, взявшись за маленькую дополнительную историю в следующей итерации.
Как использовать резерв

При правильном использовании петля обратной связи потенциала автоматически
даст вашей команде то количество резерва, которое ей необходимо, чтобы завершать
каждую историю в каждой итерации. Но как вам использовать этот резерв?
Для начала резерв времени нужен только в случае ограничений, в которых
работает команда. Всегда найдется какой-то вид работы (как правило, программи-
рование), который будет узким местом вашей команды. Резерв времени команды
будет направлен на смягчение этого ограничения.
Один из способов это сделать — зарезервировать последнюю часть вашей итерации
в качестве резерва и просто уйти домой пораньше, когда истории будут завершены.
Конечно, это расточительно. Другой вариант — брать в работу еще одну историю,
когда все закончено, но это возвращает вас к отсутствию резерва и выполнению мак-
симально возможного количества работы.
Нет, лучше всего использовать резерв времени
для повышения ваших возможностей в поставке Лучше всего использовать
продукта. Правильный способ будет зависеть резерв времени для повышения
от ваших ограничений. Ниже представлены три ваших возможностей
хороших варианта. Повышение внутреннего ка- в поставке продукта.
чества, в частности, является обязательным для
каждой команды.
Повышать внутреннее качество

Производительность команды напрямую связана с качеством ее кода, тестами, авто-
матизацией и инфраструктурой. Все вместе это составляет внутреннее качество ПО.
Даже лучшие команды невольно накапливают проблемы внутреннего качества.
Хотя вы должны всегда делать ваше ПО настолько чистым, насколько возможно,
даже хорошая работа в конце концов перестает соответствовать вашим потреб
ностям.
Если ваше ограничение связано с програм-
мированием, то повышение внутреннего каче- См. также
ства — верный путь к повышению потенциала.
Каждую итерацию, вместо того чтобы делать Рефлексивный дизайн (глава 14)
минимум, необходимый для создания чистого
кода, ищите возможности также улучшить существующий код. Делайте это частью
вашей повседневной работы. Если вы обнаруживаете, что ломаете голову над име-
нем переменной или метода, то измените его. Если вы видите код, который больше
не используется, то удалите его.
Вдобавок к этим небольшим улучшениям ищите возможности для более масштаб-
ных усовершенствований. Возможно, у модуля слишком много задач, тест случайным
образом не проходит или сборка идет медленно. Когда эти проблемы влияют на вашу
работу, вносите усовершенствования инкрементно.
Не смешивайте все улучшения в одно. Вносите усовершенствования ежедневно,
по ходу всей итерации: час инкапсулирования структуры здесь, два часа корректи
ровки скрипта развертывания там. Каждое улучше-

ние должно решать одну относительно маленькую Вносите
проблему. Иногда вы сможете решить только часть усовершенствования
более крупной проблемы — это нормально, если код ежедневно, по ходу
улучшается. Вы сможете улучшить эту часть систе- итерации.
мы позже, когда будете работать над ней в следу
ющий раз.
Прежде чем начать, взгляните на доску задач
и сравните ее с количеством времени, оставшимся См. также
в итерации. Много ли задач выполнено, по сравнению
с количеством прошедшего времени? Если да, то ко- Планирование задач
(глава 9)
манда опережает график, так что вы можете заняться
очисткой. Или наоборот, похоже, что команда отстает?
Тогда сфокусируйтесь на ваших обязательствах по текущей итерации. У вас будут
еще возможности в следующей итерации. Меняя количество времени, потраченное
вами на внутреннее качество, вы можете удостовериться, что итерации проходят
именно так, как планировалось.
Всегда оставляйте ваш код и ваши системы в несколько улучшенном состоянии,
чем когда вы нашли их, неважно, сколько времени у вас есть. Вы не выбираете
между «неряшливый» и «чистый»; вы выбираете между «немного чище» и «зна-
чительно чище». Всегда находите время для того, чтобы делать работу хорошо.
Беспорядок отберет у вас больше времени, чем сбережет.
Сфокусируйте ваши усилия по улучшению на коде, тестах и других системах, над

которыми вы реально работаете. Если вы это сделаете, то элементы, с которыми вы
чаще всего работаете, претерпят наибольшие изменения. Эта простая петля обратной
связи волшебным образом направляет ваши усилия по совершенствованию точно
туда, где от них будет больше всего пользы.
Развивать навыки в сфере деятельности заказчика

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

Разработчики обычно склонны быть любознательными и должны непрерывно со-
вершенствовать свои навыки. Удовлетворяя свое любопытство, они часто получают
знания, которые улучшают их работу в команде.
Время, посвященное исследованиям и экспериментам, также называется време-
нем исследования (research time). Это отличный способ поощрить обучение, одно-
временно добавляя резерв времени в вашу итерацию. В отличие от других техник,
этот блок активностей займет полдня в конце итерации. Если вы запаздываете с вы-
полнением задач, то можете использовать небольшую часть времени исследования,
чтобы выполнить свои обязательства.
Если вы используете время исследова-
ния, то посчитайте ваш потенциал, осно- Время исследования дает вам
вываясь на историях, которые закончены, буфер, но не нужно слишком
когда запланировано начало времени иссле- на него полагаться.
дования, а не когда итерация должна закан-
чиваться по плану. Таким образом, если вы вклинитесь в ваше время исследования,
то ваш потенциал автоматически снизится, так что вам не понадобится делать это
в следующей итерации. Время исследования дает вам буфер, но не нужно слишком
на него полагаться.
Каждый член команды использует блок времени исследования для того, чтобы
провести самостоятельное исследование темы по своему выбору. Это может быть
исследование новой технологии, изучение неясной секции кода, тестирование новой
практики, проверка идеи нового продукта или что-то еще интересное сотруднику.
Есть только одно правило на это время: не работать ни над одной историей и не под-
тверждать код в эксплуатационной среде.
Если вы обеспокоены тем, чтобы люди не лентяйничали в это время, то пригласи-
те всех на обед на следующий день и в ходе неформального общения попросите
поделиться тем, что они узнали. В любом случае это может быть прекрасным
вариантом для «перекрестного опыления» идей.
Я внедрил практику времени исследования в нескольких командах, и она

каждый раз приносила свои плоды. В одной организации спустя две недели после
внедрения продакт-менеджер сказал мне, что период исследования был самым по-
лезным временем, проведенным командой, и предложил, чтобы мы его увеличили
вдвое.
Члены команды, для того чтобы время исследования было эффективным, вы
должны быть сконцентрированы и расценивать его как реальную работу. Полдня
может пройти очень быстро. Не считайте, что время исследования — это все, что
нужно для отложенного совещания. Строго избегайте прерываний. Не проверяйте
электронную почту, выключите текстовые сообщения, заблокируйте этот период
времени в своем календаре и ограничьте использование Интернета только материа
лами, имеющими отношение к вашему исследованию.
Когда вы только внедряете практику времени исследования, вам может быть слож-
но решить, над чем работать. Подумайте, что вас озадачило недавно. Хотели бы вы
узнать больше о вашем UI-фреймворке или коде? Есть ли какой-то язык программи-
рования, который вы хотели попробовать, но в вашей организации он не использует-
ся? Возможно, вас всегда интересовали сети реального времени (real-time networking)?
В ходе вашего исследования созда-
вайте спайк-решения (маленькие отдель- См. также
ные программы), демонстрирующие, что
вы узнали. Если вы экспериментируете Спайк-решения (глава 13)
с кодом эксплуатационной среды, то соз-
дайте временную ветку. Не пытайтесь сделать что-то полезное в широком смысле;
это только уменьшит количество времени, отведенного на реализацию конкретных
идей. Сделайте только то, чего будет достаточно для проверки концепции, затем
переходите к следующей задаче.
Роль переработок
Переработки не являются результатом
работы петли обратной связи потенциала, См. также
но служат источником резерва времени.
Используйте их с осторожностью. Если вы Энергичная работа (глава 7)
добровольно хотите поработать дольше,
чтобы завершить какую-то историю или задачу, — это нормально. Однако не превра-
щайте это в привычку и не перерабатывайте больше чем на час или около того в любой
конкретный день. Вам нужно время на отдых и перезарядку, если вы хотите быть про-
дуктивными на следующий день. Уделяйте внимание своей энергии и никогда не ис-
пользуйте переработки как предлог для снижения рабочих стандартов вашей команды.
Вопросы
Если наши обязательства находятся под угрозой срыва, то должны ли мы временно
отменить парное программирование, рефакторинг, разработку через тестирование
и т. д.? Ведь исполнение обязательства — это самое важное?
С опытом эти практики должны начать ускорять вашу работу, а не замедлять, но
у них есть кривая обучения (или научения). Действительно, если вы их отложите,
то на раннем этапе сможете быстрее выполнить свои обязательства.
Но все же вы не должны использовать их в качестве источника резерва времени.
Эти практики поддерживают вашу способность поставлять высококачественный код.
Если вы не будете им следовать, то из-за снижения внутреннего качества ваша работа
сразу замедлится. Вы сможете выполнить
конкретные обязательства текущей итера- См. также
ции, но сделаете это за счет следующей.
Если вам не хватает резерва времени, Парное программирование (глава 12)
чтобы справиться с обязательством, то Групповое программирование (глава 12)
не понижайте свои стандарты. Лучше
измените свои планы, как обсуждается в подразделе «Принятие и выполнение обя-

зательств по итерации» ранее в данной главе.
Должны ли мы использовать парное или групповое программирование в течение
времени исследования?
Групповое программирование — это, как правило, лишнее. Парное программи-
рование может пригодиться, если вы планируете взаимодействовать с коллегами по
какому-либо вопросу, но необходимости в нем нет.
Как резерв времени связан с историями для очистки?
Истории для очистки — это специальные истории, предназначенные только для
повышения внутреннего качества (см. пункт «Истории для очистки (clean-up stories)»
главы 8). Честно говоря, они скорее являются ошибкой. Команда должна исполь-
зовать свой резерв времени для того, чтобы постоянно улучшать свой код и другие
системы. В историях для очистки вообще не должно быть необходимости.
Но иногда вы наследуете ПО, которое можно значительно ускорить с помо-
щью дополнительной чистки. В этих случаях заказчики в команде могут решить,
что в список приоритетов нужно включить историю для очистки. Но это никогда
не должно быть обязательным. Решение всегда принимают заказчики в команде,
которым нужно соблюдать компромисс между пользой от дополнительной очистки
ПО и пользой от другой работы, на которую команда могла бы потратить это время.
В этом отличие от процедуры очистки, выполняемой с помощью командного резерва
времени, которая остается на усмотрение разработчиков.
Риск резерва времени заключается в том, что может вызвать у людей представление,
что такие активности, как повышение внутреннего качества и развитие навыков
в сфере деятельности заказчика, неважны. На самом деле они жизненно важны,
и команда, которая их игнорирует, со временем замедлит темпы работы. Они просто
не настолько срочные, как ваши обязательства по итерациям. Убедитесь, что ваш
резерв времени достаточно велик для того, чтобы вы могли стабильно совершен-
ствоваться. Если не получается, то немного понизьте свой потенциал, чтобы все же
Вдобавок никогда не делайте работу небрежно ради вашего резерва времени.
Если вы не можете выполнить обязательства по итерации, следуя выбранному вами
процессу, то лучше пересмотрите ваш план итераций.
Когда ваша команда встраивает резерв времени в состав итераций:
zz команда стабильно исполняет свои обязательства по итерациям;
zz члены команды редко (а скорее никогда) нуждаются в переработках;
zz внутреннее качество стабильно улучшается, упрощая и ускоряя работу.
На первый взгляд кажется, что резерв времени связан с исполнением обязательств
и что он — важная часть этого. Но реальная инновация использования данного резерва
в первую очередь заключается в решении проблем, которые вызвали необходимость
в нем самом. Вместе с потенциалом это формирует умную петлю обратной связи,
использующую слабости команды для того, чтобы сделать ее сильнее.
Многие организации настолько обеспокоены своей продуктивностью, что давят
на свои команды, чтобы те максимально повысили значение их потенциала. Команды
усиленно повышают свой потенциал на каждую итерацию и не могут ввести никакого
резерва. Парадоксальным образом это не дает им улучшить их реальный потенциал
и осложняет для них исполнение обязательств… что, в свою очередь, приводит к уси-
лению давления, не говоря уже об атмосфере неприятной и беспорядочной суеты,
окружающей весь рабочий процесс.
Экспериментируя с резервами, не забывайте об умной петле обратной связи.
Не просто ищите способы добавить скрытые резервы; ищите способы использовать
их так, чтобы улучшить потенциал вашей команды.

В книге Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
[DeMarco2002] приводятся убедительные аргументы в пользу применения резерва
времени во всей организации.
The Goal1 [Goldratt1992] и Critical Chain2 [Goldratt1997] — два бизнес-романа,
в которых обосновывается, почему для защиты обязательств и повышения пропуск-
ной способности команды нужно использовать резерв времени (или «буферы»), а не
дополнять предварительные оценки.
СТЕНДАП-МИТИНГИ
Мы координируемся для выполнения своей
работы. Аудитория
Я испытываю особую неприязнь к статус- Вся команда

митингам. Вы наверняка знаете этот вид встреч:
руководитель зачитывает список задач и спрашивает о каждой всех по очереди.
Кажется, что встречи длятся вечно, хотя моя часть обычно занимает всего пять
минут. Я узнаю что-то новое примерно за 10 минут. Остальные 45 минут — совер-
шенно бесполезная трата времени.
1
Голдратт Э. Цель. Процесс непрерывного улучшения.
2
Голдратт Э. Критическая цепь.
У организаций есть веские причины проводить

такие встречи. Люди должны знать, что происхо- См. также
дит. Но у Agile-команд есть более эффективные
Информативное рабочее
механизмы: информативное рабочее пространство
пространство (глава 9)
позволяет узнавать статус, а ежедневные стендап-
митинги служат для координации работ.
Сидячий стендап
Сейчас 10:03 утра, и ваша команда опять собралась возле комнаты
для стендап-митингов, ожидая, пока из нее выйдет предыдущая
группа.
«Напомни мне, почему нам опять нужна эта комната?» — спраши-
вает Стив. «Все остальные были заняты, — отвечает Висенте. Он
ваш Scrum-мастер. — И нам нужен проектор. Смотри, они встают».
Пять минут спустя вы все уже удобно устроились, и Висенте с по-
мощью проектора направляет изображение из трекера задач на стену. «Окей, да-
вайте начнем наш стендап, — говорит Висенте, откидываясь в кресле. — Джастин?»
Джастин отрывает взгляд от своего телефона. «А, да. Ну-у… вчера я работала над
историей № 1106. Сегодня я все еще работаю над ней. Препятствий нет».
«Отлично, — отвечает Висенте. — Адриана?»
«Все еще работаю над № 1109. Препятствий нет».
Висенте продолжает опрашивать всех по кругу, внося обновления в трекер, пока
люди отвечают в том же духе.
«Окей, это все. Всем спасибо. Помните, что нужно обновить статус ваших историй,
чтобы нам не пришлось этого делать на встрече. Увидимся завтра».
Сейчас 10:20. Направляясь обратно к своему рабочему месту, вы размышляете
о стендапе. Во всяком случае, это быстро. Но так… бесполезно. За исключением
обновления в трекере, которое делает Висенте, все остальное выглядит пустой
тратой времени. Чего не хватает?
Как проводить ежедневные стендапы

Провести ежедневный стендап-митинг очень
просто. Каждый день в определенное время вся См. также
команда собирается на короткую, 5–10-минутную,
встречу. Команды, работающие в офисе, соби- Планирование задач (глава 9)
раются вокруг своей доски для трекинга задач.
Виртуальные команды общаются по видеосвязи и также подключаются к вирту-
альной доске задач. Заведите привычку всегда начинать вовремя, даже если кто-то
опаздывает.
Стендапы предназначены для координации,

а не для обновления статуса. Если вам нужен Стендапы предназначены
текущий статус, просто посмотрите на доску для координации,
для планирования задач. Но так как команда а не для обновления статуса.
совместно владеет историями, несет за них от-
ветственность и работает над их выполнением (см. врезку «Коллективное владение»
ранее в данной главе), членам команды нужен способ координировать свою работу.
Именно для этого и нужны стендап-митинги. Они позволяют членам команды син-
хронизироваться, чтобы те могли продолжать координировать свои действия по
необходимости в течение дня.
Стендапы прерывают работу команды. В этом отношении особенно пробле-
матичны утренние стендапы; так как члены команды знают, что встреча пре-
рвет их работу, они иногда просто теряют время, ожидая ее начала. Вы можете
сгладить проблему, перенеся стендап на более позднее время дня, например
перед обедом.
Наиболее эффективный подход для стендапов из тех, что я видел, называется

«Прогулка по доске». Он состоит из четырех частей.
1. «Прогулка по доске»
Стендап начинается с того, что члены команды просматривают одну за другой истории
на доске, начиная с той, которая ближе всех к завершению. Люди, которые работали
над каждой из историй, описывают, что изменилось и что осталось сделать, а также
рассказывают любую другую новую информацию, которую команде нужно знать.
Например: «Мы с Дженной закончили эту задачу, — говорит Бобби, указывая на
доску. — Мы с На закончили вот ту задачу, так что эта история готова к финальной
экспертной проверке. Я поговорил с Родни, и он сказал, что хочет быть ее проверяю-
щим, но у него возникло какое-то срочное дело. Он должен вернуться в офис сегодня
во второй половине дня. Мы планируем сегодня отметить эту историю зеленым, если
не будет никаких сюрпризов».
Члены команды должны просить помощи и проводить спонтанные сессии со-
вместной работы по мере необходимости в течение дня, однако прогулка по до-
ске — подходящий момент для менее срочной координации. Ниже представлены
несколько примеров.
zz Кто-то, кто хочет помощи: «Меня смущает тестирование нашего фронтенда CSS.
Кто-нибудь может рассказать мне об этом после стендапа?»
zz Кто-то, обладающий новой информацией: «Я и Люсила попробовали новую
библиотеку TaskManager, и она работала очень хорошо. Посмотрите, когда в сле-
дующий раз будете работать с параллелизмом».
zz Кто-то, кому требуется сессия совместной работы: «У нас есть несколько историй,
которым нужно задать размер. Мы можем запланировать быструю сессию игры
в планирование после обеда?»
Вначале, пока люди еще только привыкают к стендапам, вам может понадобиться
кто-то для фасилитации встречи. Лучше передавать эту роль, чтобы команда могла
разделять лидерство. Фасилитатор должен следить за тем, чтобы не доминировать
на встрече; его роль только в том, чтобы указывать на каждую историю и побуждать
команду высказываться.
2. Фокус на завершении
После прогулки по доске сфокусируйте внимание команды на том, что им необходи-
мо для завершения работы, включая препятствия, которые не устранены. Команды,
использующие итерации, должны воспользоваться возможностью проверить свои
обязательства по итерациям, сказав примерно такие слова: «У нас осталось два
дня, и мы прошли итерацию на 60 %. Похоже, мы выполнили больше 60 % задач, но
только одна из наших историй отмечена как сделанная, поэтому сегодня мы должны
сконцентрироваться на закрытии историй».
3. Выбирайте задачи
Наконец, каждый решает, над чем будет работать дальше. Это разговор, а не одно-
стороннее решение: «С учетом того, что сказала На о завершении историй, похоже,
что эта задача должна иметь высокий приоритет в нашем списке. Кто-нибудь хочет
поработать над этим со мной?» (На выступает добровольцем и берет карточку с до-
ски.) «Кроме того, сегодня во второй половине дня я договорюсь с Родни насчет
экспертной проверки той, другой истории».
Таким же образом, если кто-то выбирает историю, по которой у вас есть информа-
ция, не забудьте упомянуть ее: «Когда начнете работать над этой задачей, поговорите
со мной или Сеймуром. Мы внесли несколько изменений в нашу обертку над Fetch1,
о которых вам нужно знать».
4. Подробные обсуждения выносите за рамки встречи

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

Вместо того чтобы во время стендапа сосредоточиваться на историях, некоторые
команды фокусируются на людях. Все по очереди вкратце описывают новую ин-
формацию, которую команде нужно знать. Часто это принимает форму ответов
на три вопроса.
1
Название интерфейса. — Примеч. науч. ред.
1. Что я делал вчера?

2. Что я буду делать сегодня?
3. Что мне мешает?
Такие встречи обычно превращаются в статус-митинги, а не в координационные,
поэтому я предпочитаю «прогулку по доске». Кроме того, они, как правило, за-
нимают больше времени или превращаются в бессодержательную перекличку.
Будьте краткими
Цель стендап-митингов — вкратце скоординировать всю команду. Они не предна-
значены для полного описания всего, что произошло. Главное достоинство стенда-
пов — краткость. Вот почему команды, работающие в офисе, проводят встречи стоя:
их уставшие ноги напомнят им, что встреча должна быть короткой.
Каждую историю обычно можно описать, используя всего несколько предложе-
ний. От 30 до 60 секунд вполне должно хватить. Вот несколько дополнительных
примеров.
zz Программист: «Для этой истории Дина и я закончили эту задачу (указывает на
доску). Мы столкнулись с проблемой с тестами, поэтому сделали рефакторинг
абстракции сервиса. Это также упростит вон ту задачу (показывает). Дайте ко-
му-нибудь из нас знать, если захотите, чтобы мы обсудили с вами изменения».
zz Продакт-менеджер: «Я только что вернулся с торговой выставки, где получил
отличные отзывы о UI и направлении развития нашего продукта. Это будет оз-
начать некоторые изменения в визуальном плане. Я поработаю над этим сегодня,
и любой, кто хочет знать больше, может присоединиться ко мне».
zz Эксперт в предметной области: «Синтия спрашивала меня вчера о финансовых
правилах для этой истории. После этого я обсудил это с Татум, и оказалось, что
там несколько больше работы, чем я думал. Я добавил эту задачу (показывает),
чтобы обновить примеры, и хотел бы поработать с программистом или тестиров-
щиком над этим, чтобы убедиться, что мы покрываем все базы».
Обычно стендап-митинги должны зани-
мать всего около пяти минут, максимум де- Стендап-митинги должны
сять. Если они постоянно занимают больше занимать всего около пяти минут,
десяти минут, что-то не так. Несколько общих максимум десять.
причин медленных стендапов таковы:
zz вместо карточек и доски или их виртуального эквивалента используются инстру-
менты трекинга задач;
zz доска задач обновляется во время стендапа, а не в течение всего дня;
zz разговоры ведутся во время стендапа, а не в течение всего дня;
zz подробные дискуссии ведутся во время стендапа, вместо того чтобы выносить
их за рамки встречи;
zz стендап проводится в комнате для совещаний, а не в рабочей комнате вашей команды;

zz участники встречи ждут, когда все соберутся, вместо того чтобы начинать всегда
вовремя.
Если ничто из перечисленного не похоже на ваш случай, то обратитесь за по-
мощью к наставнику.
Вопросы
Могут ли люди, не являющиеся членами команды, участвовать в стендапах?
Да, но помните, что стендап организует команда и он проводится на благо коман-
ды. Если посторонние люди отвлекают от встречи или членам команды некомфортно
говорить в их присутствии, то посторонние
должны перестать участвовать. Члены коман- См. также
ды, имеющие навыки дипломатии, вероятно,
смогут им сообщить об этом наилучшим обра- Демо для стейкхолдеров (глава 10)
зом. Вы можете использовать демо для стейк- Дорожные карты (глава 10)
холдеров и дорожные карты, чтобы держать
этих людей в курсе происходящего.
Когда есть множество команд, иногда бывает полезно командам, плотно работаю-
щим друг с другом, отправлять своих людей на стендап-митинги друг к другу. В этом
случае решите совместно, как позволить людям посещать встречи и сотрудничать,
никому не мешая.
Что, если кто-то опоздал на встречу?
Начинайте без них. Стендапы длятся всего несколько минут, так что к моменту,
когда опоздавшие придут, вы уже можете закончить. Вы можете попросить кого-либо
заменить их, если необходимо. Если начинать всегда вовремя, это может способство-
вать установлению культуры пунктуальности.
Нам все еще нужны стендап-митинги, если мы используем групповое программи-
рование?
Команды, которые используют групповое
программирование, обычно постоянно коор- См. также
динируются, так что технически стендапы им
не нужны. Но все же полезно каждый день Групповое программирование
находить время, чтобы обсудить прогресс (глава 12)
и подумать о следующих шагах. У команд,
использующих групповое программирование, это может происходить естественным
образом. Если нет, то проведение запланированного стендапа должно помочь.
Не позволяйте ежедневным стендапам задушить общение. Некоторые члены команды
в какой-то момент обнаруживают, что ждут стендапа, вместо того чтобы разговаривать
с кем-то, кто им нужен. Если вы видите, что такое происходит, временная отмена
стендапов может на самом деле помочь улучшить общение.
Знайте, что есть лидеры, которые любят доминировать во время стенда-
пов. Будучи проверяющим, Джонатан Кларк метко выразился, что идеальный
фасилитатор — это «харизматичный, но нетерпеливый коллега, который торопит

и прерывает говорящих». Команда (и стендап ) — это собрание равных. Никто
не должен доминировать.
Когда вы хорошо проводите стендап-митинги:
zz команда координирует свою работу и демонстрирует устойчивый прогресс в вы-
полнении плана;
zz команда знает, когда задача или история застопорилась, и принимает меры, чтобы
ее разблокировать;
zz члены команды знают, над чем работают остальные и как это влияет на их работу.
Координация, а не статус — основная идея стендап-митингов. Команды — новички
в Agile обычно испытывают с этим трудности; стендап кажется им более короткой
и частой версией статус-митинга, но такие представления упускают суть.
Во время стендапа избегайте излишней формальности. Люди часто эксперимен-
тируют, добавляя структуру (шаблоны, списки вопросов), но она может снижать
уровень взаимодействия, а не повышать его. Вместо этого ищите варианты повысить
способность команды нести коллективную ответственность за свою работу.
Одна команда, с которой я работал, стала настолько эффективной в технике
«прогулки по доске», что члены команды стали проводить очень короткие стенда-
пы несколько раз в день. Вместо того чтобы назначать время для встреч, участники
собирались сразу же, как только заканчивали свои задачи. Уже через 30–60 секунд
они договаривались о том, над чем работать дальше, и разбирали задачи с доски.

It’s Not Just Standing Up: Patterns for Daily Standup Meetings [Yip2016] — хороший ис-
точник идей для экспериментов со стендап-митингами.
ИНФОРМАТИВНОЕ РАБОЧЕЕ ПРОСТРАНСТВО

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

ход из привычной зоны может приводить к внезапным открытиям.
Виртуальным командам труднее добиться такого же эффекта «постоянно на
виду», но тут работают те же принципы. Создавайте людям возможности получать
информацию, не прибегая к сознательным ее поискам.
Информативное рабочее пространство также позволяет ощутить прогресс
команды, просто войдя в комнату — или авторизовавшись в общей сети в случае
виртуального командного помещения. Оно передает информацию о состоянии дел,
не отвлекая членов команды, и помогает повышать доверие стейкхолдеров.
Тонкие сигналы
Суть информативного рабочего пространства —
информация. Пространство постоянно транслирует Информативное рабочее
информацию команде. Этот процесс принимает пространство постоянно
форму больших наглядных диаграмм, описанных транслирует информацию
далее, но может принимать форму тонких сигналов, команде.
что позволяет членам команды поддерживать их
осведомленность о ситуации.
Один из источников осведомленности о ситуации — видеть, что делают люди.
В физическом командном помещении, меняя визуальный план, человек, вероят-
но, думает о предстоящей работе. Если кто-то стоит возле доски задач, то, возмож-
но, может обсудить вопрос, над чем работать дальше. В середине итерации, если
половина карточек на доске не сделана, команда движется медленнее, чем ожи
далось.
Ощущение комнаты — еще один сигнал. Здоровая
команда энергична. В воздухе висит гул активности. См. также
Люди общаются, работают вместе, шутят время
от времени. Команда не спешит и не суетится, но Энергичная работа (глава 7)
определенно продуктивна. Когда человеку или паре
нужна помощь, другие это замечают, предлагают помощь, потом возвращаются
к своим задачам. Когда кто-то завершает задачу, все на минутку прерываются, чтобы
коротко отпраздновать это.
В нездоровой команде тихая и напряженная атмосфера. Члены команды не го-
ворят много или вовсе молчат. Есть ощущение чего-то серого и мрачного. Люди
живут по часам, отсчитывая время прихода и ухода или, еще хуже, наблюдая, кто
первый решится уйти.
В удаленных командах эти сигналы не видны.
Вместо этого приложите усилия, чтобы сообщать См. также
о текущем статусе и настроении. Установите рабочие
соглашения о том, как делиться информацией, напри- Согласование (глава 7)
мер, оставлять примечания в групповом чате, и пред-
ложите способы приветствовать друг друга.
Помимо собственно информации, рабочее пространство предоставляет людям
и способы общения. Для команд, работающих в офисе, это означает множество
белых досок на всех стенах и стопки индексных карточек. Совместно нарисованный

на доске эскиз дизайна может объяснить идею гораздо быстрее и эффективнее, чем
получасовая презентация. Индексные карточки отлично подходят для ретроспектив,
планирования и создания визуализаций.
Для команд, работающих удаленно, общая виртуальная доска служит тем же
целям. Некоторые команды также создают один или два общедоступных документа
в качестве командной «стены» для полезной информации. Кроме того, вы можете
улучшить вашу осведомленность о ситуации, если будете держать виртуальную
доску планирования всегда на виду на отдельном мониторе или планшете, чтобы
замечать, когда люди что-то меняют.
Большие наглядные диаграммы

Существенный аспект информативного рабочего пространства — большая наглядная
диаграмма, или «излучатель информации». Цель такой диаграммы — отобразить
информацию настолько просто и недвусмысленно, чтобы она проецировалась на
все пространство.Удаленно работающие команды могут достичь похожего эффекта,
используя одну виртуальную доску, представляющую их «комнату».
Доска планирования задач (как на рис. 9.1) и доска для планирования задач (как
на рис. 8.4) — примеры повсеместно используемых больших наглядных диаграмм.
Вы встретите варианты таких досок у каждой Agile-команды, хотя многие совершают
ошибку, пряча их в трекер проблем.
Еще одна полезная диаграмма — командный календарь, который показывает
важные даты, итерации и дни, когда члены команды будут отсутствовать в офисе
(а также контактную информацию, если это необходимо). Для команд, работающих
в офисе, подойдет большой пластиковый вечный календарь.
Мне нравится также держать на видном месте цель команды — ви́дение, миссию
и тесты миссии. Эта информация имеет тенденцию отходить на второй план через
несколько недель, но все же хорошо иметь возможность указать на нее при необхо-
димости.
Избегайте рефлекторного побуждения
компьютеризировать ваше информативное Не позволяйте электронным
рабочее пространство. Ваша команда долж- инструментам ограничивать то, что
на быть в состоянии менять свой процесс вы можете сделать.
в любой момент, как только у кого-либо
возникает хорошая идея. Благодаря бумаге для флипчарта, ленте и маркерам время,
прошедшее от идеи до готовой диаграммы на стене, составит всего две или три ми-
нуты. В физическом командном помещении нет ничего более гибкого или удобного.
Электронные инструменты работают дольше и ограничены запрограммированными
функциями. Не позволяйте им ограничивать то, что вы можете сделать.
Командам, работающим удаленно, конечно, приходится использовать электронные
инструменты, но участники также должны отдавать предпочтение инструментам,
которые упрощают быстрые изменения и обновления, а не пытаются автоматизи-
ровать. Обычных карточек, стикеров и инструментов для рисования, имеющихся
в вашей виртуальной доске, должно быть достаточно.
Диаграммы улучшений
Один из типов большой наглядной диа-
граммы измеряет определенные параметры, См. также
которые команда хочет улучшить. Часто эти
параметры возникают во время ретроспек-
тив. В отличие от доски для планирования
или командного календаря, которые постоянно присутствуют в комнате, диаграммы
улучшений остаются там только на несколько недель.
Создавайте диаграммы улучшений как результат общего решения команды,
и пусть она за них отвечает. Когда вы согласитесь создать диаграмму, договоритесь
поддерживать ее в актуальном состоянии. Для некоторых диаграмм это означает,
что все уделяют несколько секунд на то, чтобы сделать отметку на доске, когда
меняется статус. Другие диаграммы подразумевают сбор некоторой информации
в конце дня. Для таких коллективно выберите кого-нибудь, кто будет отвечать за
обновление диаграммы.
Диаграммы улучшений настолько же разнообразны, как и проблемы, которые ис-
пытывают команды. Принцип, стоящий за всеми ними, один и тот же: они взывают
к нашему врожденному желанию совершенствоваться. Если вы демонстрируете про-
гресс в достижении общей цели, то люди обычно будут стараться улучшать свой статус.
Подумайте над проблемами, с которыми сталкиваетесь, и над тем, какой тип
диаграммы, если он есть, может помочь. В качестве примера команды Agile успешно
использовали диаграммы, чтобы улучшить:
zz использование парного программирования, отслеживая процентное соотношение
времени, проведенного в парном программировании, и сравнивая его с процент-
ным соотношением времени, ушедшего на работу в одиночку;
zz переключение пар, отслеживая, сколько возможных комбинаций пар фактически
работало парами во время каждой итерации (рис. 9.4, а);
zz производительность сборки, отслеживая количество тестов, выполненных за
секунду (см. рис. 9.4, б);
zz отзывчивость поддержки, отслеживая возраст самого старого запроса (более ран-
няя диаграмма, которая отслеживала количество нерешенных запросов, привела
к тому, что сложные запросы игнорировались);
zz ненужные перерывы, отслеживая количество часов, потраченное на работу не по
истории в каждой итерации.
Постарайтесь не впадать в крайности. Если вы публикуете слишком много диа-
грамм улучшений, то они потеряют свою эффективность. Я стараюсь удерживать
в пределах двух или трех за раз, не включая постоянные диаграммы, такие как доска
задач.
Но это не значит, что вашей единственной наглядностью должны быть несколько
диаграмм. Приветствуются и памятные для команды предметы, игрушки и элементы
текущей работы. Просто сделайте так, чтобы важные диаграммы выделялись.
Рис. 9.4. Примеры диаграмм улучшений
Игры
Хотя слишком большое количество диаграмм улучшений может снизить их влия-
ние, более серьезная проблема возникает, когда команда чрезмерно заинтересована
в увеличении цифр в диаграмме. Люди часто начинают воспринимать процесс как
азартную игру. Игра начинается, когда люди фокусируются на цифрах за счет обще-
го процесса.
Обычный пример, который я встречаю, — программисты слишком фокусиру-
ются на улучшении количества имеющихся у них тестов или объема покрытия
кода вместо совершенствования качества своего подхода к тестированию. Они
выполняют тривиальные тесты, которые не несут никакой ценности, или сложны
для выполнения, или выполняются медленно. Иногда люди даже не осознают, что
делают это.
Чтобы уменьшить эту проблему, используйте диаграммы улучшений осторожно.
Обсуждайте новые диаграммы всей командой. Ясно обозначайте общие улучшения,
которые хотите увидеть. Каждую неделю проверяйте, работают ли диаграммы, и сни-
майте их в течение месяца. К этому времени диаграмма уже или выполнит свою задачу,
или окажется не в состоянии чем-то помочь.
Кроме того, никогда не используйте
диаграммы из вашего рабочего простран- Никогда не используйте диаграммы
ства для оценки производительности. Даже из вашего рабочего пространства
для оценки производительности.
не обсуждайте их за пределами команды.
Люди, которые чувствуют, что о них судят
по их производительности на диаграмме, с гораздо большей вероятностью вступят
в игру. В разделе «Менеджмент» главы 10 можно найти информацию о том, что
делать вместо этого.
Вопросы
Нам необходимо информировать о статусе людей, которые не могут или не хотят
приходить в наше рабочее пространство регулярно. Как нам это делать, не применяя
компьютеризированные диаграммы?
Первое и главное — информативное рабочее
пространство предназначено для команды. Что- См. также
бы делиться информацией о статусе с людьми,
Демо для стейкхолдеров
не входящими в команду, используйте демо для
(глава 10)
стейкхолдеров и дорожные карты.
Наши диаграммы постоянно устаревают. Как Дорожные карты (глава 10)
вдохновить членов команды на их обновление?
Первый вопрос, который нужно задать: «Действительно ли команда согласилась
с этой диаграммой?» Информативное рабочее пространство должно приносить поль-
зу команде, так что если члены команды не поддерживают диаграмму в актуальном
состоянии, то, возможно, считают, что она не имеет смысла. Может быть, члены
команды в пассивно-агрессивной форме игнорируют диаграмму, вместо того чтобы
просто сказать вам, что она им не нужна.
Могу сказать из собственного опыта: возможно, вы слишком сильно настаиваете
на диаграммах. Снижения моей вовлеченности в диаграммы часто бывает достаточно,
чтобы заинтересовать и привлечь команду. Иногда это означает, что нужно смириться
с неидеальными или небрежными картинками от руки, но это себя оправдывает.
Если ничего не помогает, то обсудите проблему во время ретроспективы или стендап-
митинга. Поделитесь своим разочарованием и попросите у команды помощи в решении
проблемы. Будьте готовы отказаться от части диаграмм, если команде они не нужны.
Если у вашей команды нет командного помещения,
физического или виртуального, то вы не сможете См. также
создать информативное рабочее пространство.
Такое пространство легче создать в физическом Командная комната (глава 7)
рабочем помещении. Просто повесьте диаграммы,
которые вам нужны. Если у вас виртуальное рабочее пространство, то вам понадобится
приложить дополнительные усилия, чтобы сделать информацию наглядной и создать
атмосферу ситуационной осведомленности.
Когда у вашей команды есть информативное рабочее пространство:
zz вы своевременно узнаёте обо всех проблемах, с которыми сталкивается команда;
zz вы точно знаете, каков ваш прогресс по вашему текущему плану и сколько еще
предстоит сделать;
zz вы хорошо знаете, хорошо продвигается команда или столкнулась с трудностями;
zz вы знаете, насколько хорошо команда решает проблемы.
Если у вас нет командного помещения, но ваша команда работает в смежных офисах
или кабинках с перегородками, то вы можете получить некоторые преимущества
информативного рабочего пространства, размещая информацию в холле или общих
помещениях.
В этом эксперименте вас ничто не ограничивает. Ключ к данной практике — ме-
тафора кабины пилотов: иметь постоянно на виду всю необходимую информацию,
чтобы автоматически замечать изменения и подсознательно понимать, когда что-то
не по плану. Имейте это в виду, когда будете экспериментировать с визуализациями
и плакатами. Вы можете начать экспериментировать сразу.

Agile Software Development [Cockburn2006] содержит интересную дискуссию в главе 3
Communicating, Cooperating Teams, в которой информация описывается как жар,
а отвлекающие факторы — как сквозняки. Это источник метафоры «излучатель
информации».
ПРИМЕРЫ ЗАКАЗЧИКА
Мы правильно реализуем сложные детали.
Некоторые программы довольно простые: Аудитория
просто еще один UI поверх еще одной базы
данных. Но часто наибольшую ценность пред- Заказчики, вся команда
ставляет ПО, требующее особых экспертных
знаний.
Эта экспертность, или знание предметной
области, наполнена деталями, в которых трудно См. также
разобраться и которые легко понять неправиль-
но. Для обсуждения этих деталей используют Единый язык (глава 12)
примеры заказчика: конкретные примеры, иллю- Вся команда (глава 7)
стрирующие правила предметной области. При- Вовлечение реального заказчи-
меры заказчика тесно связаны с единым языком, ка (глава 8)
который представляет собой способ объединить
язык, используемый программистами и экспер-
тами в предметной области, и сам код.
Для создания примеров заказчика вам понадобятся люди, обладающие эксперт-
ными знаниями в предметной области. Идеально, если они — часть команды. Если
нет, то вам нужно их найти.
В вашу команду могут входить люди, которые выработали «мирское» понимание
предметной области. В эту категорию часто входят программисты, тестировщики
и бизнес-аналитики. Они могут сами разрабатывать примеры заказчика. Но даже
в таком случае хорошей идеей будет проверить эти примеры вместе с реальными экс-
пертами в данной области, поскольку могут встретиться каверзные детали, которые
неспециалист поймет неверно.
Чтобы создать и использовать такие примеры, следуйте процессу Описать, Про-
демонстрировать, Разработать.
Описать
В процессе планирования задач посмотрите
на истории и решите, нет ли в них деталей, См. также
которые разработчики могли понять не-
правильно. Добавьте задачи по созданию Планирование задач (глава 9)
примеров таких деталей. Вам не нужны
примеры на все — только на каверзные. Примеры заказчика нужны для общения,
а не для подтверждения того, что ПО работает.
Например, если одна из ваших историй — «разрешить удаление счета», то вам
не нужен пример удаления счета. Разработчики уже понимают, что значит удалить
что-либо. Однако вам могут понадобиться примеры, показывающие, когда можно
удалить счет, особенно если есть сложные правила, обеспечивающие удаление счета
правильным образом.
Если вы не знаете, что именно разработчики могли понять неправильно, спросите
их! Но не совершайте ошибки, приводя слишком много примеров, по крайней мере
поначалу. Когда эксперты в предметной области и разработчики впервые собираются
вместе, чтобы создать примеры, обе группы часто бывают удивлены тем, насколько
велико неверное понимание.
Когда приходит время работать над примерами, соберите команду вокруг белой
доски или сделайте общий документ, если команда работает удаленно. Участвовать
может вся команда. Как минимум пригласите эксперта в предметной области, всех
программистов и тестировщиков. Они все должны понимать детали, чтобы кол-
лективно владеть продуктом (см. врезку «Коллективное владение» ранее в данной
главе).
Эксперты в предметной области начинают с краткого описания истории и соот-
ветствующих правил. Будьте лаконичны: это только краткий обзор. Сберегите детали
для примеров. Например, дискуссия об удалении счетов может пойти следующим
образом:
Эксперт: Одна из наших историй — добавление поддержки удаления счетов.
Вдобавок к макетам UI, которые мы вам дали, мы думаем, что будет хорошо до-
бавить несколько примеров заказчика. Удаление счетов — не настолько простая
операция, как кажется, поскольку мы должны вести аудиторский учет.
Этот вопрос связан с определенным набором правил. Обычно можно без про-
блем удалять счета, которые не были отправлены заказчикам, чтобы люди имели
возможность исправлять ошибки. Но как только счет был отправлен заказчику,
он может быть удален только менеджером. И даже тогда мы должны сохранять
копию для аудита.
Если команда только начинает узнавать

о предметной области, то могут понадобить- См. также
ся более детальные обсуждения. В этом слу-
Единый язык (глава 12)
чае постарайтесь выработать единый язык.
Продемонстрировать
После того как эксперт в предметной об-
ласти сделал краткий обзор, постарайтесь Сделайте правило конкретным,
удержаться от искушения заставить его попросив привести пример.
продолжать описание правила. Вместо это-
го сделайте правило конкретным, попросив привести пример. Буквальный вопрос
«Можете привести пример?» поможет сразу перейти к делу.
Участники также могут начать, попросив привести пример, но предоставьте роль
лидера эксперту в предметной области. Маленькая хитрость — можно сделать пред-
намеренную ошибку и дать эксперту возможность вас поправить1.
Таблицы часто являются самым естественным способом предоставить примеры,
но вам не нужно беспокоиться о форматировании. Просто сформулируйте примеры
на доске или в общем документе. Дискуссия может быть продолжена следующим
образом:
Программист: То есть если счет не был отправлен, специалист по работе с за-
казчиком может удалить его, а если был отправлен, то не может? (Берет маркер
и пишет на доске.)
Пользователь Отправлен Можно удалить?

Специалист по работе с заказчиком Нет Да
Специалист по работе с заказчиком Да Нет
Эксперт: Верно.
Программист (намеренно понимая неверно): Но CSR может.

CSR Нет Да
CSR Да Да
1
Я научился этой хитрости у Уорда Каннингема. Один из ее вариантов был позже популяризиро-
ван Стивеном Макгиди как закон Каннингема: «Лучший способ найти ответ в Интернете — это
не задать вопрос, а опубликовать неверный ответ».
Эксперт: Нет. CSR не может. Может менеджер. (Программист передает маркер

эксперту.)

CSR Нет Да
CSR Да Да
Менеджер Да Да, но с копией
для аудита
Тестировщик: А что насчет руководителя CSR? Или администратора?

Эксперт: Руководители CSR не считаются менеджерами, а администраторы —
да. Но даже администраторы должны оставлять копию для аудита.

CSR Нет Да
CSR Да Нет
Менеджер Да Да, но с копией
для аудита
Руководитель CSR Да Нет
Администратор Да Да, но с копией
для аудита
Эксперт: Добавлю еще одно замечание. «Отправлен» вообще-то означает что-

либо, что могло привести к тому, что заказчик увидел счет, независимо от того,
увидел ли он его на самом деле.
«Отправлен»
По электронной почте
Распечатан
Экспортирован в PDF
Экспортирован в URL
Тестировщик: А что насчет предпросмотра?

Эксперт: Никто никогда не спрашивал меня об этом. Ну… очевидно… хм… окей,
я вам отвечу позже.
Этот разговор продолжается, программисты и тестировщики задают вопросы, за-

полняя пробелы, пока не будут проработаны все детали. Ожидайте обнаружить здесь
вопросы, которые заказчики раньше не принимали во внимание. Если вы используете
единый язык, то набросайте эскиз соответствующей модели и корректируйте его по
ходу работы.
Когда будете вникать в детали, обязательно продолжайте создавать соответ-
ствующие примеры. Всегда есть соблазн говорить обобщенно, например: «Кто
угодно может удалять счета, которые не были отправлены», но лучше создавать
конкретные примеры, такие как «Специалист по работе с заказчиком может уда-
лить счет, который не был отправлен». Это поможет выявить пробелы в мышлении
людей.
Вы можете обнаружить, что у вас больше вопросов для обсуждения, чем вы ду-
мали. Процесс создания конкретных примеров часто выявляет сценарии, которые
заказчикам раньше не приходили в голову. Особенно хорошо обнаруживают такие
пробелы тестировщики. Если вам многое нужно обсудить, то рассмотрите возмож-
ность разделиться, чтобы программисты начали реализацию, пока заказчики и те-
стировщики будут искать дополнительные примеры.
Разработать
Когда обсуждение закончено, запишите результаты для использования в дальнейшем.
Обычно достаточно фото и скриншота белой доски.
Примеры заказчика часто представляют наи-
более важные элементы логики вашего программ- См. также
ного приложения. Обязательно задокументируйте
их. Я предпочитаю разработать автоматические Разработка через тестирование
(глава 13)
тесты. Однако вместо того, чтобы слепо копиро-
вать каждый пример в соответствующий тест,
я использую примеры в качестве источника вдохновения для создания более точ-
ных и тщательно продуманных тестов, которые могут служить документацией для
других программистов. Для этого я распечатываю копию примеров и использую
разработку через тестирование, чтобы инкрементно создавать тесты и код. Когда
я пишу каждый тест и соответствующий ему код, то вычеркиваю примеры, которые
покрывает тест.
Проще всего, если у вас есть единый язык и модель предметной области. Напри
мер, в вашу модель могут входить класс Invoice и метод canDelete(). В этом случае
у нее могут быть такие тесты, как «позволять любому удалять счета, которые не были
отправлены» и «позволять только менеджерам удалять счета, которые были от-
правлены».
Пока разработчики будут работать над кодом, вероятно, выявятся некоторые
пограничные случаи, которые не обсуждались в первоначальной дискуссии. В этом
случае нормально вернуться к доске. Точно так же нормально задать вопрос, полу-
чить ответ и закодировать его. При любом варианте не забудьте обновить тесты
и документацию.
Вопросы
Мы должны создавать примеры до того, как
начнем разработку? См. также
В этом не должно быть необходимости.
Создание примеров обычно может быть пер-
вой задачей в вашей разработке. Если вам Инкрементные требования (глава 8)
нужно исследовать несколько примеров во
время игры в планирование, чтобы измерить историю, то вы можете создать примеры,
но в целом этого делать не нужно. Помните, что требования, в том числе примеры
заказчика, должны разрабатываться поэтапно вместе с остальным вашим ПО.
Многие истории настолько просты, что им не требуются примеры заказчика. Не ста-
райтесь насаждать их там, где в них нет необходимости.
Когда вам нужны примеры заказчика, вам также нужны и экспертные знания
в предметной области. Если в вашей команде нет экспертов, то вам нужно приложить
усилия, чтобы найти их и привлечь к работе.
Когда ваша команда хорошо применяет примеры заказчика:
zz в вашем ПО немного багов в логике предметной области или они вовсе отсутствуют;
zz ваша команда обсуждает правила предметной области в конкретных, однознач-
ных терминах;
zz ваша команда часто обнаруживает и учитывает особые правила, которые никто
не принимал во внимание.
Некоторые команды любят использовать средства автоматизации тестирования
на естественном языке, такие как Cucumber, для превращения примеров заказчика
в автоматизированные тесты. Когда-то я был одним из тех, кто это делал, — Fit Уорда
Каннингема был первым из таких инструментов в сообществе Agile, и я принимал
в нем активное участие.
Но со временем я понял, что ценность примеров была в обсуждении у доски,
а не в автоматизации. В теории заказчики должны помогать в написании Fit-тестов
и использовать результаты Fit, чтобы быть уверенными в прогрессе команды.
На практике это случалось редко и особой пользы не приносило. Обычная TDD
была более простым способом автоматизации и работала так же хорошо. То же самое
можно сказать и об инструментах наподобие Cucumber.
Cucumber вышел из сообщества разработок на основе поведения (Behavior-Driven
Development, BDD), основанного Дэниелом Терхорст-Нортом, который всегда
был решительным сторонником взаимодействия с заказчиком. Хотя я не думаю,
что инструменты наподобие Cucumber необходимы, сообщество BDD может быть

хорошим источником идей для экспериментов. Одна из таких идей — составление
карты примеров (example mapping), способ подборки примеров с помощью индекс-
ных карточек [Wynne2015].
Вы можете исследовать и другие варианты создания примеров заказчика. Многие
считают инструменты наподобие Cucumber полезными для структурирования ком-
муникации, и некоторые команды использовали их для упрощения аудитов и прочих
сторонних проверок. Сначала несколько раз попробуйте простой подход, основанный
на взаимодействии и использовании белой доски, чтобы у вас сформировалась база
для сравнения. Когда будете экспериментировать с другими вариантами, помните,
что примеры заказчика — средство для взаимодействия и получения обратной связи,
а не для автоматизации или тестирования. Убедитесь, что ваши эксперименты рас-
ширяют и дополняют этот основной принцип, а не отвлекают от него.

В главе 7 книги Specification by Example [Adzic2011] содержится великолепный на-
бор советов для запросов примеров заказчиков, и вообще сама она достойна того,
чтобы ее прочесть.
СДЕЛАНО СДЕЛАНО Аудитория

Мы закончили, когда готовы к эксплуатации Вся команда
(production-ready).
Почти сделано
— Привет, Валентина! — Ширли просовывает голову в кабинет
Валентины. — Ты уже закончила ту новую функциональность?
Валентина кивает.
— Подожди секунду, — говорит она, продолжая что-то набирать. По-
ток щелчков клавиш нарастает в крещендо и наконец эффектно за-
канчивается. — Сделано! — Валентина триумфально поворачивается,
чтобы взглянуть на Ширли. — Мне тоже потребовалось всего полдня.
— Впечатляюще, — говорит Ширли. — Мы думали, это должно занять целый день,
а то и два. Я могу уже сейчас посмотреть на нее?
— Ну, не совсем, — говорит Валентина. — Я пока еще не интегрировала новый код.
— Окей, — говорит Ширли. — Но как только ты это сделаешь, я же смогу на нее
посмотреть, да? Мне не терпится показать ее нашим новым клиентам. Они нас
выбрали специально из-за этой функциональности. Я собираюсь развернуть новую
сборку на их испытательном стенде, чтобы они могли поэкспериментировать с ней.
Валентина хмурится. «Ну, я бы пока ее никому не показывала. Я ее еще не проте-

стировала. И ты не сможешь ее нигде развернуть — я еще не обновила ни скрипт
развертывания, ни инструмент миграции».
— Я не понимаю, — ворчит Ширли. — Я думала, ты сказала, что сделала.
— Сделала, — настаивает Валентина. — Я закончила писать код в тот момент, когда
ты зашла. Смотри, я тебе покажу.
— Нет, мне не нужно смотреть код, — отвечает Ширли. — Мне нужно показать что-
то нашим заказчикам. Мне нужно, чтобы это было завершено. На самом деле
завершено.
— Тогда почему ты это не сказала? — говорит Валентина. — Эта функциональность сде-
лана — весь код написан. Просто не сделано сделано. Дай мне еще несколько дней.
Разве не было бы удобно, однажды закончив историю, больше к ней никогда

не возвращаться? Как раз в этом заключается идея, стоящая за понятием «сделано
сделано». Завершенная история — это не свалка неинтегрированного и непротести-
рованного кода. Она готова к работе. Когда другие истории, запланированные для
вашего текущего релиза, будут готовы, вы сможете сделать его, не выполняя никаких
дополнительных действий.
Частично сделанные истории увеличивают ваш объем незавершенной работы,
и это повышает ваши затраты, как описано во врезке «Минимизируйте объем
незавершенной работы» главы 8. Вместо того чтобы нажать кнопку и сделать
релиз, вы должны закончить непредсказуемое количество работы. Это дестаби-
лизирует ваши планы релизов и мешает вам принимать и выполнять свои обяза-
тельства.
Чтобы избежать этой проблемы, убедитесь,
что ваши истории «сделаны сделаны». Если вы См. также
используете планирование задач, основанное на
итерациях, все истории в итерации должны быть Планирование задач (глава 9)
сделаны в конце каждой итерации. Если вы ис-
пользуете непрерывный поток, истории должны быть сделаны до того, как вы сни-
мете их с доски. У вас должна быть техническая возможность делать релиз каждой
завершенной истории, даже если вы на самом деле его не делаете.
Что нужно, чтобы история была «сделана сделана»? Это зависит от вашей ор-
ганизации. Создайте определение понятия «сделано», демонстрирующее критерии
завершенности историй для вашей команды. Я пишу свое определение на доске для
планирования задач. Вот пример.
zz Протестировано (все автоматизированные тесты написаны и проходят).
zz Код написан (весь код написан).
zz Дизайн готов (выполнен рефакторинг кода, удовлетворяющий команду).
zz Проинтегрирован (история работает от начала до конца (обычно от UI до базы
данных) и совместима с остальным ПО).
zz Сборка (скрипт сборки работает со сделанным изменением).

zz Развертывание (скрипт развертывания развертывает сделанное изменение).
zz Мигрирует (скрипт развертывания обновляет схему базы данных и переносит
данные при необходимости).
zz Проверен на месте (заказчики подтвердили, что обновленное ПО соответствует
их ожиданиям).
zz Исправлен (все известные баги исправлены или запланированы к исправлению
в рамках собственных историй).
zz Приняты на месте (заказчики согласны, что история завершена).
Некоторые команды добавляют к этому списку пункт «Задокументировано»,
означающий, что у истории есть документация, справочный текст и она соответ-
ствует другим стандартам документации (см. подраздел «Документация» главы 8).
Другие команды добавляют нефункциональные критерии, такие как ожидаемая
производительность или масштабируемость. Это может приводить к преждевремен-
ной оптимизации или к трудностям завершения историй, поэтому я предпочитаю
планировать этот вид нефункциональных требований со специальными отдельными
историями. Компромисс — проверять ожидания в рамках чек-листа «Сделано Сде-
лано», но не обязательно предпринимать какие-либо действия в соответствии с ними1.
Например: «Проверить время отклика. Если оно > 500 мс, то оптимизировать или
создать историю производительности».
Со временем вы узнаете много нового о том,
что нужно для вашего ПО, и усовершенствуете См. также
ваш подход к разработке. Например, можете
начать с пункта «Протестировано вручную» Ретроспективы (глава 11)
в вашем определении понятия «сделано». В про-
цессе улучшения вашего подхода вы можете добавить «Автоматизированные тесты
написаны и проходят» и в итоге удалить запись «Протестировано вручную». Хорошо
рассматривать изменения в вашем определении понятия «сделано» во время ретро-
спектив.
Как быть в статусе «Сделано Сделано»

Agile работает наилучшим образом, когда вы
ежедневно добиваетесь небольшого прогресса Добивайтесь ежедневно
в каждом аспекте вашей работы, вместо того небольшого прогресса в каждом
чтобы работать по фазам или резервировать не- аспекте вашей работы.
сколько последних дней вашей итерации, имея
целью привести ваши истории к статусу «Сделано Сделано». Этот способ работы
окажется более простым, как только вы к нему привыкнете, и снижает риск полу-
чения незавершенной работы в конце итерации. Однако он полагается на некоторые
практики из уровня поставки.
1
Спасибо Биллу Уэйку за этот совет.
Программисты, используйте разра

ботку через тестирование, чтобы со- См. также
вмещать тестирование, написание кода Разработка через тестирование (глава 13)
и дизайн. В процессе работы интегри-
Непрерывная интеграция (глава 13)
руйтесь с остальной работой команды,
используя непрерывную интеграцию. Нулевое трение (глава 13)
Поэтапно улучшайте автоматизацию
сборки и развертывания для каждой задачи, которая в этом нуждается. Создайте
задачи для миграции базы данных, когда возможно, и работайте над ними в рамках
каждой истории.
Не менее важно вовлекать ваших заказчиков в команде. Когда вы будете работать
над задачами в области UI, показывайте ваш прогресс заказчикам в команде, даже
если интерфейс пока еще не работает. Заказчики часто хотят попробовать UI, когда
видят его впервые. Это может приводить к удивительному количеству работы, ко-
торую приходится делать в последний момент.
Таким же образом, когда вы завершаете задачи и интегрируете в единое целое
различные части истории, запустите код, чтобы убедиться, что все работает вместе.
Хотя это и не должно быть заменой автоматизированному тестированию, хорошо
сделать проверку работоспособности, чтобы не было сюрпризов.
В течение всего процесса вы можете найти опечатки, ошибки или явные баги. Если
найдете, то исправьте их сразу — затем улучшите ваши рабочие привычки, чтобы
избежать появления таких ошибок.
В некоторых случаях вы можете об-
наружить баг или какой-нибудь другой См. также
сюрприз, значительно увеличивающий
размер истории. В этом случае вы мо-
жете поработать с вашим заказчиком Анализ инцидентов (глава 16)
в команде и запланировать дополни-
тельную работу в отдельной истории (или историях). Если баг — результат ошибки
дизайна или кодирования, то запланируйте его незамедлительно в следующую
итерацию или историю, поскольку ошибки этого вида, как правило, увеличивают
ваши затраты на разработку и их исправление со временем становится все более
дорогостоящим.
Однако не успокаивайтесь на этом: такой вид историй должен быть редким.
Появление их чаще, чем несколько раз в квартал, говорит о неких проблемах.
Если сюрпризы относятся к недостающим или неверно понятым требованиям,
то сфокусируйтесь на улучшении вовлеченности заказчика. Если они имеют от-
ношение к ошибкам кодирования, то улучшите свободное владение навыками на
уровне поставки. Если ни один из этих вариантов не работает, то попросите по-
мощи у наставника.
Когда вы уверены, что история «сделана сделана», покажите ее вашему за
казчику в команде для финальной проверки и приемки. Так как вы проверяли
вместе с ним ваш прогресс по ходу разработки, это должно занять всего несколько
минут.
Находить время
Ваша команда должна завершать 4–10 историй
каждую неделю. То, что вам нужно доводить до Секрет состояния «Сделано
состояния «Сделано Сделано» так много исто- Сделано» — в создании
маленьких историй.
рий, может показаться невозможно большим
объемом работы. Хитрость частично состоит
в том, чтобы работать поэтапно, как только что описывалось, а не по фазам. Однако
настоящий секрет — в создании маленьких историй.
Множество команд — новичков в Agile создают истории, слишком большие, чтобы
стать «сделанными сделанными». Они завершают кодирование, но у них не хватает
времени, чтобы закончить все полностью. UI немного не в порядке, тесты не завер-
шены, и то и дело появляются баги.
Помните, вы — хозяева вашего расписания. Вы решаете, на сколько историй под-
писаться и какова их величина. Если ваши истории слишком большие, то уменьши-
те их! В подразделе «Разделение и объединение историй» главы 8 описывается, как
Создание слишком больших историй — есте-
ственная ошибка, но некоторые команды усугу- См. также
бляют проблему, думая: «Ну… мы действительно
закончили историю, за исключением одного Потенциал (глава 9)
небольшого бага». Они засчитывают ее в свой
потенциал, что только усугубляет проблему.
Истории, которые не «сделаны сделаны», не засчитываются в ваш потенциал.
Даже если в истории лишь несколько малозначимых багов в UI или вы закончили
все, кроме нескольких автоматизированных тестов, она засчитывается как ноль при
подсчете вашего потенциала. Это снижает ваш потенциал, давая вам больше времени,
чтобы вы смогли закончить все в следующий раз.
Вы можете посчитать, что это снижает ваш потенциал настолько, что вы можете
завершать всего одну или две истории в неделю. Это значит, что ваши истории были
слишком большими для начала. Разделите текущие истории и работайте над тем,
чтобы делать будущие истории меньшими по размеру.
Команды, использующие непрерывный поток, а не итерации, не отслеживают
потенциал, но к ним применима та же идея. Вы должны начинать и заканчивать
4–10 историй за неделю, и каждая должна быть «сделана сделана». Если это не так,
то уменьшите истории.
Организационные ограничения
У вашей команды может не быть возможности делать релиз историй самостоятель-
но1. Идеал Agile — кросс-функциональные команды, обладающие всеми навыками
и полномочиями, необходимыми для выполнения своей работы, как описано в главе 4,
однако это не всегда возможно.
1
Спасибо Басу Водде, Томасу Оуэнсу и Кену Пью за их вклад в этот подраздел.
Например, вашему юридическому отделу может потребоваться проверить текст

истории перед ее релизом. Ваш отдел эксплуатации может не позволить вам делать
собственные развертывания. Вам может понадобиться проводить сторонние проверки
безопасности или проходить пользовательские приемочные испытания.
Постарайтесь разобраться с максимально возможным количеством зависимостей
до начала работы над историей, как описывалось в подразделе «Кросс-командные
зависимости» ранее в данной главе. Например, если ваш юридический отдел должен
одобрить текст, то напишите его и получите одобрение до начала работы над той
историей, для которой он нужен.
Для предрелизных зависимостей, таких
как поверка безопасности или пользователь- См. также
ские приемочные испытания, вы можете
определить «сделано» как передачу ПО Без багов (глава 16)
на проверку и релиз, а не реальный релиз. Примеры заказчика (глава 9)
В ваше определение понятия «сделано»
Устранение препятствий (глава 11)
должны входить только те части, которые
находятся под вашим контролем. Однако,
насколько это возможно, рассматривайте эти финальные шаги как защитную сетку.
Если они обнаружат проблемы, то рассматривайте их с той же серьезностью, что
и дефекты, найденные в эксплуатационной среде.
Со временем работайте над снижением количества времени, затрачиваемого на
сторонние зависимости. Например, некоторые команды используют автоматизи-
рованные примеры заказчика, чтобы упростить стороннюю проверку. Заручитесь
помощью вашего менеджера, чтобы изменить организационные требования и при-
внести в команду необходимые навыки.
Вопросы
Что, если история не «сделана сделана» в конце итерации?
Или попытайтесь еще раз позже, или создайте новую историю для того, что оста-
лось (см. подраздел «Незавершенные истории» ранее в данной главе).
Почему в вашем списке «Протестировано» идет раньше, чем «Код написан» и «Ди-
зайн готов»? Разве мы не должны сначала подготовить дизайн, затем написать код
и только потом тестировать?
Список «Сделано Сделано» — не перечень шагов или фаз, которые необходимо
выполнять последовательно; он служит для финальной проверки, помогающей убе-
диться, что вы ничего не забыли. Agile работает лучше всего, когда вы выполняете
фазы разработки инкрементно и одновременно, а не по одной за раз. В части III
описывается, как это работает.
Почему в вашем списке нет ручного тестирования?
Ручное тестирование заканчивается фазой «Протестировать и исправить» в конце
разработки, что осложняет надежное и гарантированное завершение работы. В части III
описывается, как заменить эту фазу инкрементным автоматизированным тестированием.
Помните, что мой список — это лишь пример. Если ваша команда использует
ручное тестирование, имеет дополнительные эксплуатационные требования или
должна делать что-то еще, чтобы завершить историю, то добавьте это в ваш список.
Приведение историй в состояние «Сделано
Сделано» требует участия всей команды — та- См. также
кой, в которую входят как минимум заказчики,
а также, возможно, тестировщики, специалисты Вся команда (глава 7)
по эксплуатации, технические писатели и т. д. Командная комната (глава 7)
У такой команды должна быть общая рабочая
комната, физическая или виртуальная. Иначе Разработка через тестирование
есть вероятность, что команда будет слишком (глава 13)
часто задерживать выполнение задач из-за их Инкрементный дизайн (глава 14)
передачи из рук в руки, что препятствует бы-
строму завершению историй.
Кроме того, вам, вероятно, понадобятся разработка через тестирование и эволю-
ционный дизайн, чтобы тестировать, создавать код и дизайн для каждой истории
в такие короткие сроки.
Когда ваши истории в состоянии «Сделано Сделано»:
zz вы не сталкиваетесь с неожиданно возникающими объемами работы;
zz команды, использующие итерации, распределяют процессы завершения и окон-
чательной доводки работы по ходу всей итерации;
zz заказчики в команде и тестировщики имеют равномерную рабочую загрузку;
zz приемка работы заказчиком занимает всего несколько минут.
Эта практика — краеугольный камень планирования в Agile. Если вы не достигли
статуса «Сделано Сделано» после каждой истории или итерации, то ваш потенциал
и прогнозирование будут ненадежными. Вы не сможете делать релизы по своему
усмотрению. Как следствие, ваши планы релизов будут срываться, что помешает
вам принимать и выполнять обязательства, а это, в свою очередь, будет подрывать
доверие стейкхолдеров. Такая ситуация, скорее всего, будет приводить к стрессу
и давлению на команду, снижать моральный дух команды и ее активность.
Альтернатива статусу «Сделано Сделано» — заполнить конец вашего расписания
косметической работой. В итоге вы получите неопределенный объем работы по ис-
правлению багов, доработке UI, миграции данных и т. д. Многие команды работают
таким образом, однако это вредит доверию и вашей способности поставлять продукт.
Я не рекомендую так делать.
ГЛАВА 10
Ответственность
Если Agile-команды сами управляют своей работой и своими планами, то как их ор-
ганизации узнают, что команды все делают правильно? Как они узнают, что команда
выполняет свою работу наилучшим из возможных способов с учетом имеющихся
у нее ресурсов, информации и людей?
Организации могут хотеть и даже стремиться к тому, чтобы команды следовали
подходу Agile, но это не значит, что у команд есть карт-бланш делать все, что они
захотят. Они все же подотчетны своей организации. Они должны демонстрировать,
что тратят время и деньги организации соответствующим образом.
В этой главе приводятся практики, которые помогут обеспечить подотчетность.
zz Практика «Доверие стейкхолдеров» позволяет команде эффективно работать со
стейкхолдерами.
zz С помощью практики «Демо для стейкхолдеров» вы сможете давать обратную
связь о том, как продвигается ваша команда.
zz Практика «Прогнозирование» предсказывает даты релизов ПО.
zz Используя практику «Дорожные карты», вы сможете рассказать о прогрессе
и планах команды.
zz Практика «Менеджмент» помогает командам совершенствоваться.
Источники ответственности
Подотчетность скорее подразумевается, чем явно указывается в литературе об
Agile. Во времена экстремального программирования в сообществе обсуждали
«Билль о правах заказчика», раннюю версию которого можно найти в предисло-
вии к первой книге об XP:
Заказчикам и руководителям XP обещает, что они получат максимум поль-
зы от каждой недели программирования. Каждые несколько недель они
смогут видеть конкретный прогресс в достижении важных для них целей.
У них будет возможность изменить направление проекта в середине раз-
работки, обойдясь без чрезмерных затрат [Beck2000a].
Вот точное заявление об ответственности: «Мы дадим вам максимально возмож-
ную ценность». Но XP не слишком много сказало о том, как продемонстрировать
Глава 10. Ответственность 323
ответственность. Предполагалось, что вместо этого ПО, разработанное командой,

будет говорить само за себя. Практика «Демо для стейкхолдеров» — пример такого
типа ответственности. Он основан на обзорах спринтов в Scrum.
Но руководители и организации хотят от своих команд больше, чем только ПО; они
также хотят знать, что команды работают эффективно. Это привело меня к мысли
о необходимости однозначно определить практики, которые Agile-процессы
обычно обходят молчанием.
Первая практика в этой главе — «Доверие стейкхолдеров». За ней стоит поистине
фундаментальная идея — настолько фундаментальная, что я не могу сказать, откуда
пришли мои конкретные практики. Они основываются на применении разных
идей, о которых я слышал в течение многих лет, отмечая работавшие наилучшим
образом. Дискуссия о практике «Дорожные карты» формировалась аналогично;
я перепробовал множество идей и поделился теми, которые работают.
«Прогнозирование» — еще одна идея, которая существовала с самых первых дней
ПО, хотя обычно ее называют оценкой (estimating). Я впитал идеи из слишком
большого количества источников, чтобы помнить их все. Мой любимый источник
представляет вообще-то не совсем подход к прогнозированию. Это [Little2006],
статья Тодда Литтла, которая сравнивает сотни прогнозов с реальными датами
релизов. Автор приходит к четким заключениям о неопределенности и пред-
сказуемости. Статья оказала сильное влияние на мои представления о прогно-
зировании и легла в основу дискуссии в этой книге.
Дискуссия о практике «Менеджмент» в основном вдохновлена книгой Роберта Ости-
на Measuring and Managing Performance in Organizations [Austin1996], а также идеями,
накопленными в процессе работы с Дианой Ларсен в течение многих лет.
ДОВЕРИЕ СТЕЙКХОЛДЕРОВ
Мы работаем со стейкхолдерами эффективно
Аудитория
и без опасений.
Продакт-менеджеры,
Я знаю человека, который работал в компании вся команда
с двумя командами разработки. Одна использовала
подход Agile, выполняла свои обязательства и ре-
гулярно поставляла ПО. Вторая все время боролась с трудностями: отставала от
графика и не могла показать никакого работающего ПО. Однако когда в компании
начались сокращения, расстались с Agile-командой, а не с другой!
Почему? Глядя на эту борющуюся с трудностями команду, руководители видели
стены, обвешанные формальными диаграммами, и программистов, просиживающих
долгие часы за работой. Когда же руководители смотрели на Agile-команду, они ви-
дели, что люди общаются, смеются и уходят домой в пять вечера, не сделав ничего,
кроме черновых набросков и диаграмм на доске.
Нравится это вам или нет, ваша команда живет не в вакууме. Agile поначалу
может казаться странным и отличающимся от привычного. «Они действительно
работают? — интересуются посторонние. — Как-то шумно и запутанно. Я не хочу

так работать. Если это будет иметь успех, то и меня заставят это делать?»
По иронии судьбы чем более успешен Agile, тем больше растут опасения. Алистер
Кокберн называет их организационными антителами. (Он приписывает этот термин
Рону Холидею.) Если оставить их без внимания, то организационные антитела
одолеют и разрушат даже в целом успешную Agile-команду.
Неважно, насколько вы эффективны в поставке
ПО; у вас будут проблемы, если вы не добились Неважно, насколько
расположения ваших стейкхолдеров и спонсора. вы эффективны;
Да, поставка ПО и выполнение технических обя- если вы не добились
зательств помогают, но навыки межличностных расположения ваших
отношений, которые демонстрирует ваша команда, стейкхолдеров и спонсора,
могут быть не менее важными и помогут завоевать то у вас будут проблемы.
доверие к ней.
Это звучит нечестно и нелогично? Конечно, ваша способность поставлять высо-
кокачественное ПО — единственное, что имеет значение!
Это нечестно. Это нелогично. И именно так мыслят люди. Если ваши стейкхол-
деры не доверяют вам, то не будут сотрудничать с командой, и это повредит вашей
способности поставлять ПО. Они даже могут выступить против вас.
Не ждите, пока стейкхолдеры осознают, как ваша работа может им помочь.
Покажите им это.
Добавьте немного суеты

Много лет назад я нанял небольшую местную транспортную компанию, чтобы
перевезти мои вещи из одной квартиры в другую. Когда грузчики прибыли, я был
впечатлен, увидев, что они суетятся — передвигаются максимально быстро от авто
фургона до квартиры и обратно. Это было особенно неожиданно, так как оплата была
почасовой. Им было невыгодно работать так быстро.
Эти грузчики произвели на меня впечатление. Я чувствовал, что они были на-
строены удовлетворить мои запросы и при этом относились с уважением к моему
бумажнику. Если бы я все еще жил в том городе и собирался еще раз переезжать, то,
скорее всего, нанял бы их. Они завоевали мое расположение — и мое доверие.
В случае команды, разрабатывающей ПО, суета — это активная, продуктивная
работа. Это ощущение, что команда честно выполняет дневную работу за честную
дневную оплату. Энергичная работа, ин-
формативное рабочее пространство, демо
См. также
для стейкхолдеров и соответствующие до-
рожные карты — все это способствует пере- Энергичная работа (глава 7)
даче ощущения продуктивности. Однако,
возможно, самое важное — это отношение: Информативное рабочее простран-
ство (глава 9)
в рабочие часы относитесь к работе как
к приоритетному занятию, заслуживаю- Демо для стейкхолдеров (глава 10)
щему вашего полного внимания, а не как Дорожные карты (глава 10)
к бремени, которого хочется избежать.
Проявите эмпатию
Команды разработчиков часто имеют напряженные отношения с ключевыми стейк-
холдерами — представителями бизнеса. С точки зрения разработчиков, это принимает
форму нечестных требований и бюрократии, особенно в виде навязывания сроков
и давления на график.
Вы можете удивиться, узнав, что для многих из этих стейкхолдеров разработчи-
ки — это люди, у которых все козыри. Стейкхолдеры находятся в довольно пугающей
ситуации, особенно в компаниях, не связанных с бизнесом продажи ПО. Задумайтесь
на минуту над тем, как это может выглядеть:
zz карьера спонсоров, продакт-менеджеров, стейкхолдеров часто находится на кону.
Карьера разработчиков — часто нет;
zz разработчики часто зарабатывают больше, чем стейкхолдеры, очевидно, не слиш-
ком утруждаясь и не соблюдая тех правил, которых стейкхолдеры должны при-
держиваться;
zz разработчики обычно приходят на работу значительно позже, чем представители
стейкхолдеров. Они и уходят позже, но стейкхолдеры этого не видят;
zz для посторонних наблюдателей разработчики часто не выглядят заинтересован-
ными в успехе. Кажется, что их больше привлекают изучение новых технологий,
подготовка своего следующего карьерного скачка, поиск баланса работы и отдыха
и офисные «плюшки», такие как игра в пинг-понг и бесплатные закуски;
zz опытные представители стейкхолдеров имеют множество примеров из своей
истории, когда разработчикам не удавалось поставить то, что было нужно, и тогда,
когда это было нужно;
zz стейкхолдеры привыкли, что разработчики отвечают на вопросы о прогрессе
в работе, оценках и обязательствах, используя все способы: от высокомерия до
многозначительного, но бесполезного технического жаргона;
zz многие стейкхолдеры видят, что крупные технические компании хорошо постав-
ляют ПО, что редко удается их компании, и они не знают почему.
Я не говорю, что разработчики плохие или что
это впечатление обязательно верно. Я предлагаю
Относится ли ваша команда
вам подумать, что означает успех для стейкхолде- к успеху ее стейкхолдеров
ров вашего проекта и относится ли ваша команда, с уважением, которого тот
с точки зрения внешнего наблюдателя, к успеху заслуживает?
ее стейкхолдеров с уважением, которого тот за-
служивает.
Выполняйте обязательства
Если ваши стейкхолдеры уже работали с командами разработки ПО, то, вероятно,
неоднократно терпели неудобства их-за сорванных графиков, неисправленных
дефектов и зря потраченных денег. Но в то же время, скорее всего, у них самих нет
навыков разработки ПО. Это ставит их в неудобное положение, когда они вынуждены
полагаться на вашу работу, имея в прошлом неудачный опыт и не имея возможности

понять, будет ли ваша работа чем-то лучше.
Тем временем ваша команда ежемесячно потребляет десятки тысяч долларов на
зарплаты и поддержку. Как стейкхолдеры могут понять, что вы разумно используете
их деньги? Как они могут знать, что команда вообще компетентна?
Стейкхолдеры могут не знать, как оценивать ваш рабочий процесс, но могут
оценить результаты. Особенно информативны два вида результатов: работающее
ПО и исполнение обязательств. Для некоторых именно это и означает ответствен-
ность и подотчетность: вы сделали именно то, что обещали сделать.
Далее, ваши обязательства дают вашим стейкхолдерам возможность, в свою оче-
редь, брать на себя обязательства в отношении их стейкхолдеров. Послужной список,
подтверждающий вашу надежность, позво-
лит снизить их обеспокоенность. В то же См. также
время, если вы не выполняете обязательства
и не предупреждаете об этом заранее, стейк- Планирование задач (глава 9)
холдеры легко могут предположить, что вы Демо для стейкхолдеров (глава 10)
намеренно оставили их в неведении.
К счастью, Agile-команды могут быть Прогнозирование (глава 10)
надежны в плане обязательств. Вы можете
использовать планирование задач, основанное на итерациях, чтобы брать на себя
обязательства на еженедельной основе, и можете демонстрировать, что исполня-
ете свои обязательства ровно через неделю, с помощью демо для стейкхолдеров.
Вы также можете использовать поезда с релизами для создания подобного темпа
релизов и управлять вашими планами так, чтобы всегда выполнять релизы точно
вовремя, как описано в подразделе «Запланированные даты релизов» далее в те-
кущей главе.
Такая упорядоченная поставка ПО с обя-
зательством, взятым на одной неделе, и его Упорядоченная поставка ПО
выполнением на следующей способствует с обязательством, взятым на
формированию доверия стейкхолдеров, как одной неделе, и его выполнением
ничто другое. Это очень эффективное сред- на следующей способствует
формированию доверия
ство. Все, что вам нужно, — это создать план,
стейкхолдеров, как ничто другое.
который вы можете выполнить… и выпол-
нить его. И делать так снова и снова.
Управляйте проблемами
Я сказал: «Это все, что вам нужно»? Я сглупил. Все не так просто.
Во-первых, вам нужно создать хороший план и выполнять его (см. главы 8 и 9).
Во-вторых, как сказал поэт: «Лучшие планы мышей и людей / Часто идут вкривь
и вкось...»1.
1
«К полевой мыши», стихотворение известного шотландского поэта Роберта Бёрнса. Поэма на-
чинается так: «Маленький, хитрый, трусливый, пугливый зверь, / О, какая паника в твоей груди!»
Это напоминает мне мои ощущения, когда меня попросили интегрировать ветку, содержавшую
функциональность годичной давности.
Другими словами, некоторым релизам не удается прибыть в пункт поставки

в последний день. Что вы предпринимаете, когда ваши планы, подготовленные наи-
лучшим образом, идут вкривь и вкось?
Вообще-то это ваш шанс проявить себя. Кто угодно может хорошо выглядеть,
когда все в жизни идет так, как запланировано. Ваш истинный характер проявляется
в том, как вы решаете неожиданно возникшие проблемы.
Первое, что вам нужно сделать, — снизить предрасположенность к проблемам.
Работайте над самыми сложными и самыми непонятными историями на максималь-
но раннем этапе релиза. Вы обнаружите проблемы раньше и будете иметь больше
времени на их решение.
Столкнувшись с проблемой, начните с того,
что расскажите о ней всей команде. Подними- См. также
те этот вопрос самое позднее на следующем
Стендап-митинги (глава 9)
стендапе. Это даст всей команде шанс помочь
в решении проблемы. Планирование задач (глава 9)
Кроме того, хорошим способом заметить, Резерв времени (глава 9)
что что-то идет не по плану, являются итера-
ции. Проверяйте ваш прогресс на каждом стендапе. Если проблема относительно
небольшая, то вы, вероятно, сможете компенсировать ее, используя ваш резерв вре-
мени. Иначе вам придется скорректировать ваши планы, как описано в подразделе
«Принятие и выполнение обязательств по итерации» главы 9.
Обнаружив проблему, которую не можете решить, расскажите о ней вашим стейк-
холдерам. Они оценят ваш профессионализм, даже если она им не понравится.
Обычно я жду дня проведения демо, чтобы рассказать стейкхолдерам о проблемах,
которые мы уже решили самостоятельно, но немедленно довожу до их сведения
информацию о более серьезных проблемах. Члены команды, имеющие дипломати-
ческие навыки, должны решить, с кем и когда лучше поговорить.
Чем раньше вы раскроете информацию о проблеме, тем больше времени у вас
будет на ее решение. Вдобавок это снизит градус паники: на раннем этапе люди
меньше переживают о сроках и имеют больше умственной энергии для решения
проблемы. Похожим образом чем раньше ваши
стейкхолдеры узнают о проблеме (поверьте
Стейкхолдеров расстраивает
мне, они в конце концов все равно о ней уз- не само наличие проблем,
нают), тем больше у них будет времени на ее а то, что их ошарашивают
решение. Стейкхолдеров расстраивает не само проблемами.
наличие проблем, а то, что их ошарашивают
проблемами.
Когда вы рассказываете заказчику о проблеме, расскажите и о вариантах смягчения
ее последствий, если можете. Это хорошо, когда вы можете объяснить суть проблемы,
но еще лучше, когда вы можете объяснить, что вы собираетесь с ней делать. Начало
этого разговора может потребовать немалой смелости — но успешное решение про-
блемы может сотворить чудо в деле формирования доверия.
Не тяните с информированием заказчика о проблеме только потому, что у вас
пока нет решения. Наоборот, объясните ее, расскажите, что вы делаете для поиска
решения и когда он сможет услышать от вас больше информации.
Остерегайтесь соблазна работать сверхурочно или использовать резерв времени,

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

Когда Agile-команды только формируются, у от-
дельных членов команды обычно уходит какое-то См. также
время на то, чтобы начать думать о себе как о части
Динамики команды (глава 11)
команды. В самом начале разработчики и заказчики
часто видят себя представителями разных групп.
Новые заказчики в команде, как правило, особенно пугливы. Быть частью коман-
ды разработчиков — странное чувство; они бы предпочли работать в своем обычном
офисе с коллегами. И к тому же, если заказчики в команде недовольны, эти самые
коллеги (которые обычно имеют прямой доступ к ключевым стейкхолдерам команды)
будут первыми, кто об этом услышит.
Формируя новую команду Agile, приложите усилия, чтобы расположить к себе
заказчиков в команде. Один из особенно эффективных способов сделать это — отно-
ситься к целям заказчиков с уважением. Это может даже подразумевать временный
запрет на циничные шутки разработчиков о графиках и костюмах.
(Конечно, уважение должно быть обоюдным, и заказчики тоже должны подавлять
свои естественные склонности жаловаться на сроки и спорить с оценками. Я под-
черкиваю здесь потребности заказчиков, поскольку они играют очень важную роль
в восприятии стейкхолдеров.)
Еще один способ для разработчиков принимать всерьез цели заказчиков — вы-
двигать креативные альтернативы, направленные на достижение этих целей. Если
заказчик хочет что-то, что может занять много времени, или вносит значительные
технические риски, то посоветуйте альтернативный подход, позволяющий достичь
той же основной цели, но меньшей ценой. Таким же образом при наличии более
впечатляющего способа достичь цели, который заказчики не приняли во внимание,
вынесите его на обсуждение, особенно если он не очень сложный.
По мере таких обсуждений в команде барьеры будут разрушены и доверие начнет
развиваться. Когда стейкхолдеры увидят это, их доверие к команде также возрастет.
Вы можете также построить доверительные отношения непосредственно со
стейкхолдерами. Подумайте: в следующий раз, когда стейкхолдер обратится к вам
с просьбой, что случится, если вы незамедлительно и доброжелательно выслушаете
его, запишете как историю на индексную карточку и затем расскажете о ней про-
дакт-менеджеру, чтобы тот внес ее в план или инициировал дальнейшее обсуждение?
Вас это может отвлечь всего на 10 минут, но представьте, что почувствует стейк-
холдер. Вы откликнулись на его озабоченность, помогли выразить ее и предприняли
немедленные шаги для того, чтобы внести ее в план. Для стейкхолдеров это гораздо
важнее, чем отправлять электронные письма в черную дыру вашей системы трекинга
требований.
Сделайте так, чтобы стейкхолдеры

выглядели хорошо
Даже если ваши непосредственные стейкхолдеры любят вас, им необходимо убе-
дить своих боссов, чтобы те тоже вас полюбили. Что нужно вашим стейкхолдерам?
Подумайте о ситуации, в которой они находятся, как их оценивают и что вы можете
сделать, чтобы, в свою очередь, поддержать их.
Один из вариантов — создать книгу ценностей, которую бизнес-стейкхолдеры
смогут показывать своим боссам. Это регулярно обновляемый документ, в который
вы записываете ценность, транслируемую стейкхолдерам. Он поможет напомнить
стейкхолдерам, что вы для них сделали, и позволит им оправдать вашу работу перед
остальной организацией. Например: «Релиз Х обработал 20 000 событий за первые
два месяца, снизив частоту ошибок на 8 %».
Хотя это и может выглядеть как маркетинговый ход (а это он и есть), данный
способ позволяет командам оставаться сфокусированными на ценности. Обновление
книги ценностей заставляет членов команды размышлять над тем, что они сделали
для стейкхолдеров и заказчиков. Это помогает не допустить того, чтобы команда
считала себя просто фабрикой для поставки историй.
Будьте честны
В своем энтузиазме демонстрировать прогресс будьте осторожны и не переступайте
черту. Пограничное поведение включает в себя замалчивание известных дефектов
в демо для стейкхолдеров, приписывание себе историй, которые еще не завершены
на 100 %, и продление срока итерации на несколько дней, чтобы завершить все, что
содержится в плане итерации.
Сокрытие правды подобным образом создает у стейкхолдеров впечатление, что вы
сделали больше, чем на самом деле. Они будут ожидать, что вы завершите остальные
истории так же быстро, хотя фактически вы еще не закончили предыдущие. В какой-
то момент вам придется все доделать, и получившаяся в результате задержка вызовет
непонимание, разочарование и даже гнев.
Даже кристально честные команды могут столкнуться с такой проблемой. Стре-
мясь хорошо выглядеть, команды иногда берутся за большее количество историй,
чем в состоянии хорошо реализовать. Они выполняют работу, но используют корот-
кие пути, уделяя дизайну и рефакторингу недостаточно внимания. В итоге дизайн
страдает, появляются дефекты, и команда вдруг обнаруживает, что замедлилась,
стараясь улучшить внутреннее качество.
Подобным образом не поддавайтесь искушению засчитать частично выполненные
истории в свой потенциал. Если история завершена не полностью, то считается за
ноль. Не приписывайте себе такие истории. Есть старая программистская шутка:
первые 90 % работы занимают 90 % времени… и последние 10 % работы занимают
90 % времени. До тех пор, пока история не сделана полностью, невозможно точно
сказать, какой процент был выполнен.
Вопросы
Почему строить доверие — это наша ответственность? Разве стейкхолдеры не долж-
ны внести свой вклад?
Вы отвечаете только за себя. В идеале стейкхолдеры тоже много работают над
взаимоотношениями, но это выходит за пределы вашего контроля.
Разве не важнее быть хорошими, чем казаться хорошими?
И то и другое важно. Выполняйте работу на отлично и делайте так, чтобы люди
знали об этом.
Вы говорите, что разработчикам лучше держать при себе шутки о сроках. Разве
это не то же самое, что сказать разработчикам: «Замолчите и выполняйте работу
в срок», как ни смешно?
Вовсе нет. Каждый в команде должен иметь возможность высказываться и гово-
рить правду, когда видит проблему. Однако есть большая разница между обсуждением
реальной проблемы и обыкновенной циничностью.
Помните, что карьера заказчиков часто стоит на кону. Они могут быть не в со-
стоянии увидеть разницу между реальной шуткой и жалобой, замаскированной под
шутку. Неуместная шутка может вызвать у них выброс адреналина так же легко, как
и реальная проблема.
Обязательства — это эффективный инструмент выстраивания доверия, но только
если вы их выполняете. Не берите на себя обязательств перед стейкхолдерами, пока
не докажете свою способность брать и выполнять обязательства внутри команды.
Более подробную информацию можно найти в подразделе «Принятие и выполнение
обязательств по итерации» главы 9.
Когда ваша команда установит доверительные отношения с вашей организацией
и стейкхолдерами:
zz стейкхолдеры верят в способность команды удовлетворить их потребности;
zz вы признаете ошибки и проблемы вместо того, чтобы скрывать их до тех пор,
пока они не приведут к сбою;
zz все ищут решения, а не виноватых.
Доверие стейкхолдеров жизненно необходимо. Альтернативы не существует.
Однако существует много способов завоевать доверие. У этой темы долгая исто-
рия, и единственная действительно новая идея, привнесенная Agile, — это способ-
ность, используя итерации, еженедельно брать на себя обязательства и выполнять их.
Помимо этого, вы можете свободно черпать вдохновение из множества существующих
источников по выстраиванию отношений и доверия.

В книге Trust and Betrayal in the Workplace [Reina2015] представлен тщательный
анализ того, как установить атмосферу доверия и что делать, когда оно разрушено.
В книге The Power of a Positive No: How to Say No and Still Get to Yes1 [Ury2007]
рассказывается, как сказать «нет», при этом сохранив важные для вас отношения.
Диана Ларсен описывает эту способность как «вероятно, более важную в построении
доверия, чем навык ведения переговоров любого масштаба».
ДЕМО ДЛЯ СТЕЙКХОЛДЕРОВ

У нас всё по-настоящему.
Аудитория
Agile-команды могут производить работающее
Продакт-менеджеры,
ПО каждую неделю, начиная с самой первой. Может
вся команда
показаться, что это невозможно, но нет; просто это
сложно. И ключ к умению делать это правильно —
обратная связь.
Демо для стейкхолдеров — эффективный способ предоставить вашей команде
необходимую ей обратную связь. Демо — именно то, чем кажется на первый взгляд:
демонстрация ключевым стейкхолдерам того, что ваша команда недавно сделала,
а также возможность для них самостоятельно попробовать новое ПО.
Петли обратной связи

Демо для стейкхолдеров обеспечивают обрат-
ную связь несколькими способами. Первый, См. также
очевидный: стейкхолдеры скажут вам, что они
думают о вашем ПО. Инкрементные требования (глава 8)
Хотя эта обратная связь тоже важна, она — Вовлечение реального заказчика
не самое ценное из того, что вы получаете (глава 8)
благодаря демо для стейкхолдеров. Ведь за-
казчики в команде работают со стейкхолдерами в ходе всего процесса разработки,
так что должны знать, чего стейкхолдеры хотят и ожидают от ПО.
Поэтому реальная обратная связь, выражающаяся комментариями стейкхолдеров,
заключается не в ней самой, а в том, насколько она вас удивляет. Если вы удивлены,
значит, вам нужно больше поработать над тем, чтобы понимать ваших заказчиков.
Еще один вид обратной связи — реакции вовлеченных в проект людей. Если члены
команды гордятся своей работой, а стейкхолдеры рады это видеть — это хороший
знак. Если члены команды не гордятся или выглядят выгоревшими либо стейкхол-
деры недовольны — что-то идет не так.
Сами участники встречи — еще одна форма обратной связи. Если присутству-
ют люди, которых вы не считали стейкхолдерами, то подумайте над тем, чтобы
1
Юри У. Гарвардская школа переговоров. Как говорить НЕТ и добиваться результатов.
установить контакт с ними и узнать о них больше информации, особенно если они
активные участники. Аналогично, если люди, которые, как вы считали, жизненно
заинтересованы в вашей работе, не присутствуют, то хорошей идеей будет узнать
причины.
Само демо — «момент истины» для команды. Оно дает вашей команде обратную
связь в отношении способности вашей команды закончить начатую работу. Будет
трудно обманывать себя, считая, что работа сделана, если вы не сможете продемон-
стрировать ее стейкхолдерам.
В конечном итоге демо также служит обратной
связью и для стейкхолдеров. Оно показывает им, что См. также
вы — ответственная команда: прислушиваетесь к их
Доверие стейкхолдеров
потребностям и демонстрируете стабильный прогресс. (глава 10)
Это крайне важно, поскольку помогает стейкхолдерам
поверить, что ваша команда действует в их интересах.
Частота демо
Начните с проведения демо еженедельно или каждую итерацию, если используете
итерации длиннее недели. Всегда проводите демо в одно и то же время и в одном
и том же месте. Это поможет установить ритм, облегчит людям планирование участия
и придаст сильный импульс с самого начала.
Если ваша работа не секретная, то приглашайте
всех в компании, кому это может быть интересно. Вся См. также
команда, ключевые стейкхолдеры и исполнительный
Вовлечение реального
спонсор должны присутствовать как можно чаще. По
заказчика (глава 8)
возможности пригласите реальных заказчиков. Вдоба-
вок можно позвать другие команды, работающие рядом,
и людей, интересующихся Agile.
Если вы используете итерации, то проводите демо незамедлительно по окончании
каждой из них. Я люблю проводить демо на следующий день, утром. Это поможет
вашей команде поддерживать дисциплину, поскольку вы не сможете затянуть работу
до следующей итерации.
Как правило, на демо планируют 30 минут. Может быть и дольше, но время ваших
самых важных стейкхолдеров очень ценное, поэтому лучше планировать короткие
встречи, чтобы они могли участвовать регулярно. Пусть ваше решение основывает-
ся на их заинтересованности и доступности. Помните, что вы также всегда можете
связаться с людьми после демо.
Вместе с презентацией демо предложите стейкхол-
дерам способ попробовать что-то самостоятельно. Для См. также
этого варианта можно задействовать промежуточный
Флаги функций (глава 15)
(staging) сервер или, если вы используете флаги функ-
ций (feature flags, фича-флаги), специальные разреше-
ния для учетных записей стейкхолдеров.
После того как вы проведете несколько демо и воодушевление от новой работы

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

Вести демо может кто угодно в команде. Лучший вариант — тот, кто наиболее тесно
сотрудничает со стейкхолдерами. Как правило, это продакт-менеджер. Он (или она)
может говорить с ними на одном языке и лучше всех понимает их точку зрения. Кроме
того, такое взаимодействие подчеркнет, что потребности стейкхолдеров управляют
работой команды.
Продакт-менеджеры обычно просят разработчиков проводить демо вместо них.
Я часто вижу такое, когда продакт-менеджер не видит себя частью команды или
не чувствует, что достаточно хорошо знает ПО. Отклоняйте такие просьбы. Разра-
ботчики создают ПО не для продакт-менеджеров; вся команда, включая менеджера,
создает ПО для стейкхолдеров. Продакт-менеджер — лицо этой деятельности, по-
этому он (или она) должен сам вести демо. Чтобы продакт-менеджеры были более
вовлеченными и ориентировались в продукте, помогайте им, вместе просматривая
истории в процессе разработки.
Подготовленная часть демонстрации должна занимать менее 10 минут. Вам
не нужно показывать все детали. В процессе презентации разрешите задавать вам
вопросы и давать обратную связь, но следите за тем, чтобы закончить вовремя.
Если вам нужно больше времени из-за большого количества обратной связи, то это
знак, что нужно проводить демо чаще. С другой стороны, если вам трудно привлечь
участников или они кажутся незаинтересованными, то проведение демо реже может
дать вам больше материала для обсуждения.
Если вы общаетесь с большим количеством людей, то вам может понадобиться
установить правила относительно вопросов и прерываний, чтобы демо не заняло
слишком много времени.
Так как встреча короткая, лучше начинать вовремя, даже если некоторые участ-
ники опаздывают. Это покажет, что вы цените время участников. И докладчик,
и демо должны оставаться доступными для дальнейшего обсуждения и изучения
после встречи.
Начните презентацию с краткого напоминания участникам о ценном инкремен-
те, над которым сейчас работает команда, и поясните, почему он является столь
важным, чтобы тратить на него время. Подготовьте почву и предоставьте контекст
тем людям, которые до этого не были полностью посвящены в детали. Затем кратко
опишите истории, над которыми команда работала с момента предыдущего демо.
Если вы внесли в свой план любые изменения, которые могут вызвать обеспокоен-
ность стейкхолдеров, то объясните, что случилось. Не приукрашивайте и не скрывайте
проблемы. Полная прозрачность повысит
доверие к вам. Ничего не упрощая и не пре- Спокойно опишите проблемы и то,
увеличивая, вы продемонстрируете способ- как вы с ними разобрались.
ность вашей команды профессионально
обращаться с проблемами. Например:
Докладчик: Последние две недели мы были сфокусированы на совершенство-

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

Вместо того чтобы буквально читать каждую историю, перефразируйте их так,
чтобы они представляли контекст. Можно комбинировать истории или опускать
детали, которые могут быть неинтересны стейкхолдерам. Потом продемонстрируйте
результат в ПО. Истории без пользовательского интерфейса можно опустить или
просто описать на словах.
Докладчик: Наши первые две истории касались автоматического заполнения

платежной информации пользователя при авторизации в системе. Итак, я зай
ду как наш тестовый пользователь… нажму «бронирования»… и там вы можете
увидеть, что платежная информация заполняется автоматически.
Один из слушателей: А что, если они изменят свою платежную информацию?
Докладчик: Тогда мы спросим их, хотят ли они сохранить изменения. (Демон-
стрирует.)
Стейкхолдерам часто есть что сказать в качестве обратной связи. В основном

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

устарела?
Докладчик: В данный момент нет, но это хорошая идея. (Делает пометку.) Я по-
смотрю и вернусь к этому вопросу позже.
Если вы столкнулись с историей, которая не заработала, как планировалось, то

дайте простое объяснение. Не защищайтесь; просто объясните, что произошло.
Докладчик: Наша следующая история касается визуализации маршрутов. Как
я уже упомянул, нам для этого понадобилось изменить планы. Возможно, вы
помните, что наш изначальный план был показывать этапы полета с помощью
анимированного 3D-сюжета. Программисты были несколько обеспокоены про-
изводительностью, поэтому сделали тест, и оказалось, что рендеринг анимации
нанесет серьезный удар по нашим затратам на облачные сервисы.
Слушатель: Почему это так дорого? (Докладчик поворачивается к програм-
мисту.)
Программист: Некоторые мобильные устройства не имеют возможности делать
3D-анимацию в браузере или не могут делать это плавно. Поэтому нам при-
шлось бы делать это в облаке. А время работы облачного графического процес-
сора стоит очень дорого. Мы могли бы построить облачную версию и версию
на клиентской стороне и, может быть, кешировать некоторые из анимаций, но
нам бы понадобилось подробнее изучить статистику использования, прежде
чем мы смогли бы сказать, насколько это помогло.
Докладчик: Это всегда было скорее приятным дополнением, и повышенные
облачные затраты того не стоили. Мы также не хотели тратить на это дополни-
тельное время разработки, поэтому вернулись к обычной 2D-карте. Ни у кого
из наших конкурентов вообще нет карты этапов полета. У нас не оставалось
времени на анимацию карты, но, увидев результат (показывает), мы решили,
что она выглядит достойно. Мы предпочли бы пойти дальше вместо того, чтобы
тратить на это еще больше времени.
Как только демо завершено, объясните стейкхолдерам, как они могут запустить
ПО самостоятельно. Это хороший способ свернуть встречу, особенно если она
затягивается: объяснить аудитории, как они могут сами все попробовать, и затем
спросить, не хотел ли кто-либо продолжить общение в частном порядке, при наличии
дополнительных вопросов или отзывов.
Подготовьтесь
Перед началом демо убедитесь, что все истории,
планирующиеся для демонстрации, в состоянии См. также
«Сделано Сделано» и что у вас есть версия ПО,
включающая их. Убедитесь, что у участников Сделано Сделано (глава 9)
есть возможность попробовать демо самостоя-
тельно.
Вам не нужно создавать для демо безупречную презентацию с идеальной графи-
кой, но все же нужно быть подготовленными. Вы должны быть готовы презентовать
демо в течение 5–10 минут, а это значит, что вам следует знать свой материал и при
этом быть лаконичными.
Чтобы подготовиться, просмотрите исто-

рии, которые были закончены с предыдущего См. также
демо, и выстройте их в порядке повествования.
Решите, какие истории можно объединить,
чтобы лучше объяснить суть. Посмотрите Визуальное планирование (глава 8)
на цель и визуальный план вашей команды
и решите, как каждый набор историй связан с вашим текущим инкрементом, вашим
ближайшим релизом и с миссией и концепцией в целом. Составьте план того, что
вы хотите сказать.
Наконец, проведите несколько репетиций. Сценарий вам не нужен (спонтанная
речь звучит более натурально), но вы точно захотите потренироваться. Пройдитесь
по тем элементам, которые хотите продемонстрировать, чтобы убедиться, что все
работает в соответствии с вашими ожиданиями и данные для всех примеров при-
сутствуют. Затем порепетируйте свое выступление. Сделайте это несколько раз, пока
не будете спокойны и уверенны.
Каждое следующее демо будет требовать все меньше и меньше подготовки и ре-
петиций. В конце концов подготовка войдет в привычку и будет занимать всего
несколько минут.
Когда дела идут плохо

Иногда ничего не получается. Вам нечего показать стейкхолдерам, или то, что есть,
их наверняка разочарует.
В этой ситуации очень заманчиво сфальсифицировать демо. У вас может появиться
соблазн показать UI, в котором нет никакой логики, или намеренно избежать демон-
страции тех действий, в которых есть дефект.
Это трудно, но вы должны быть честными
в отношении того, что происходит. Четко ука- Четко укажите на ограничения
жите на ограничения вашего ПО и на то, что вашего ПО и на то, что вы
вы намерены делать с ними. Фальсификация намерены делать с ними.
прогресса заставит ваших стейкхолдеров по-
верить, что потенциал команды больше, чем на самом деле. Они будут ожидать от
вас продолжения в том же завышенном темпе, а вы постоянно будете отставать.
Вместо этого возьмите на себя ответственность как команда (а не обвиняйте от-
дельных лиц или другие группы), старайтесь не занимать оборонительную позицию
и проинформируйте стейкхолдеров о том, что вы делаете, чтобы предотвратить по-
вторение подобных ситуаций. Например:
Боюсь, на этой неделе нам нечего показать. Мы планировали показать вам от-
слеживание рейсов в реальном времени, но недооценили сложность взаимодей-
ствия интерфейса с бэкендом авиационных систем. Мы ожидали, что данные
будут более чистыми, чем оказалось на самом деле, и не поняли сразу, что нам
нужно будет создать собственную тестовую среду.
Мы рано обнаружили эти проблемы и думали, что сможем их как-то обойти.
Мы это сделали, но недостаточно вовремя, чтобы закончить что-то конкретное,
что смогли бы вам показать. Теперь мы знаем больше и в следующий раз будем
более проактивными в отношении изменений планов.
Мы ожидаем похожих проблем с авиационными системами в будущем. Нам
пришлось добавить больше историй, чтобы учесть изменения, и использовать
почти весь наш буфер. Мы все еще укладываемся в сроки запуска маркетин-
говой кампании, но нам понадобится сократить функциональности, если мы
столкнемся с другими серьезными проблемами за это время.
Прошу прощения за плохие новости, и я готов ответить на ваши вопросы.
Я могу ответить на несколько вопросов сейчас, и после того как мы завер-
шим корректировку наших планов позже на этой неделе, у нас будет больше
информации.
Вопросы
Что нам делать, если стейкхолдеры продолжают прерывать и задавать вопросы во
время демо?
Вопросы и прерывания — это прекрасно! Значит, стейкхолдеры вовлечены и за-
интересованы.
Если вас так часто прерывают и задают вопросы, что вы не можете уложиться
в 30-минутный лимит времени, то, возможно, вам придется проводить демо чаще.
Или, если это только один особенно заинтересованный человек, вы можете попросить
его (или ее) отложить вопросы на более позднее время после встречи. Кроме того,
можно планировать встречи длительностью больше 30 минут, особенно в первые
месяц или два.
Что нам делать, если стейкхолдеры продолжают придираться к нашему выбору
решений?
Придирки — это тоже нормально, они служат признаком интереса, когда вы на-
чинаете проводить демо. Не принимайте их слишком близко к сердцу. Запишите
идеи на карточки, как любую другую историю, и приоритизируйте их после встречи.
Удерживайтесь от соблазна начать разбираться, приоритизировать или разрабатывать
решения во время встречи. Это не только ее затягивает, но и нарушает дисциплину
обычной практики планирования.
Если придирки продолжаются по истечении первых одного-двух месяцев, то это
может служить знаком, что заказчики в команде что-то упускают. Внимательно
изучите их претензии, чтобы понять, есть ли более глубокая проблема.
Стейкхолдерам очень нравится то, что они видят, и они хотят добавить набор
функциональностей. Это хорошая идея, но нам уже нужно заниматься другими ве-
щами. Что нам делать?
Не говорите «нет» во время демо. И не говорите «да». Просто поблагодарите
стейкхолдеров за их предложения и запишите их в качестве историй. По окончании
демо заказчики в команде должны будут более внимательно посмотреть предложения
и оценить их значимость относительно цели команды. Если они не вписываются
в график команды, то член команды с навыками менеджмента продукта может со-
общить это стейкхолдерам.
Что, если люди не приходят на демо или не вовлечены?

Возможно, вы проводите демо слишком часто или они слишком длинные. Попро-
буйте проводить их реже и потренируйтесь говорить кратко. Кроме того, есть веро-
ятность, что люди не понимают, какое отношение имеет к ним ваше ПО. Спросите
ключевых стейкхолдеров, что вы можете сделать, чтобы демо стали более полезными
и актуальными.
Что, если у нас несколько команд, работающих над одним и тем же ПО?
Возможно, имеет смысл объединить работу команд в одно демо. В этом случае
выберите одного человека, который представит работу всех. Это потребует кросс-
командной координации, и данная тема выходит за рамки этой книги, но такая ко-
ординация у вас уже должна быть налажена как часть подхода к масштабированию.
Прочитайте главу 6, чтобы получить больше информации.
Если объединение работы всех команд в одно демо по какой-либо причине
не имеет смысла, то вы можете продолжать проводить отдельные демо. Некоторые
организации предпочитают планировать их проведение во время одной большой
встречи, но это плохо масштабируется. Вместо этого лучше организуйте множество
комбинированных демо (например, одно — для команд, работающих непосредственно
с заказчиком, другое — для внутренней администрации, третье — для поддержки
разработки и т. д.) и спланируйте их так, чтобы люди могли сами выбрать, в каком
демо поучаствовать.
Никогда не фальсифицируйте демо для стейкхолдеров, скрывая баги или показывая
незавершенные истории. Вы просто навлечете на себя неприятности в будущем.
Если вы не можете демонстрировать прогресс, не прибегая к подделкам, — это
явный знак того, что у вашей команды проблемы. Замедлитесь и попытайтесь
разобраться, что идет не так. Если вы не используете итерации, то попробуйте их.
Если используете, то прочитайте подраздел
«Принятие и выполнение обязательств по
См. также
итерации» главы 9 и попросите помощи
у наставника. Проблема может заключаться Планирование задач (глава 9)
в том, что вы пытаетесь сделать слишком
много всего одновременно.
Когда ваша команда хорошо проводит демо:
zz вы вызываете доверие у стейкхолдеров;
zz вы узнаёте, что стейкхолдеры увлечены больше всего;
zz команда уверена в своей способности поставлять продукт;
zz вы прямо говорите о проблемах, что позволяет вашей команде не давать им вы-
ходить из-под контроля.
Демо для стейкхолдеров — четкий показатель вашей способности к поставке. Или
у вас есть завершенные истории для демонстрации, или нет. Или ваши стейкхол-
деры довольны вашей работой, или нет. Я не знаю альтернатив, которые могли бы
предоставить настолько ценную обратную связь.
Эта обратная связь — важная часть демо для стейкхолдеров. Обратная связь,
касающаяся способности вашей команды к поставке, обратная связь, говорящая об
удовлетворенности стейкхолдеров, а также обратная связь, которую вы получаете,
наблюдая их реакцию и слушая их вопросы и комментарии.
Когда вы экспериментируете с демо для стейкхолдеров, держите в голове эту об-
ратную связь. Демо — не только способ поделиться тем, чем вы сейчас заняты. Это еще
и способ узнать ваших стейкхолдеров. Некоторые команды упрощают проведение
демо, записывая краткое видео. Это разумная идея, и ее стоит попробовать. Но видео
не даст вам столько же обратной связи. Удостоверьтесь, что в любых экспериментах,
которые вы пробуете, есть вариант, который позволяет подтвердить вашу способность
выполнить работу и узнать у ваших стейкхолдеров интересующую вас информацию.
Некоторые команды выворачивают демонстрацию наизнанку: вместо того чтобы
показывать стейкхолдерам то, что они делают сейчас, они наблюдают за стейкхол-
дерами, которые сами тестируют их ПО. Это лучше всего работает в условиях непо-
средственного общения. Это также хорошо работает, если у вас множество команд,
работающих в офисе: вы можете пригласить их всех в одно большое помещение
и провести демо в стиле «базар» или «торговая выставка», когда стейкхолдеры могут
перемещаться от команды к команде и наблюдать их работу1.
ПРОГНОЗИРОВАНИЕ
Мы можем предсказать наши релизы.
Аудитория
«Когда вы закончите?» Программисты боятся
Продакт-менеджеры
этого вопроса. В разработке ПО столько нюансов, что
просто невозможно точно знать, что осталось сделать,
не говоря уже о том, сколько времени это займет. Тем не менее у стейкхолдеров есть
реальная потребность знать, сколько времени займет работа. Им нужно планировать
бюджет и координироваться с третьими сторонами. Чтобы сформировать доверие
и продемонстрировать свою ответственность, вы должны быть в состоянии пред-
сказать, когда будет релиз.
Составление этих прогнозов обычно называется оценкой (estimate), но это не-
верный термин. Оценка — просто одна из техник прогнозирования, и даже не самая
важная. Настоящий секрет хорошего прогнозирования — в понимании неопределен-
ности и риска. Именно поэтому я называю это прогнозированием.
1
Я узнал об этом подходе от Баса Водде. Подход «Базар» основан на технике «Ярмарка научных
достижений», обсуждаемой в [Schatz2004].
Неопределенность и риск
На первый взгляд, Agile предлагает отличное ре-
шение для прогнозирования: если вы используете См. также
итерации, то суммируйте ваши истории (или их
оценки), разделите на ваш потенциал — и вуаля!
Получите количество итераций, оставшихся до за- Резерв времени (глава 9)
вершения. В конце концов, потенциал и резерв вре-
мени дают вам возможность стабильно брать на себя итерационные обязательства
и выполнять их. Разве это не должно означать, что вы можете взять на себя обяза-
тельства и по релизам?
К сожалению, нет. Представьте, что вы в команде, которой нужно сделать 30 исто-
рий до релиза. Она стабильно делает шесть историй еженедельно, так что все займет
пять недель, верно? Сегодня 1 января, поэтому вы говорите вашим бизнес-стейк-
холдерам, что релиз будет через пять недель, 5 февраля. Они с энтузиазмом ждут
нового релиза и начинают рассказывать о нем заказчикам. «Подождите — и увидите,
что будет дальше. Ждите новостей 5 февраля!»
За следующую неделю вы заканчиваете шесть историй, как обычно. В процессе вы
обнаруживаете баг. Это небольшая проблема, но ее нужно решить до релиза. Вы добав-
ляете историю, чтобы исправить баг в следующей итерации. 8 января у вас остается
25 историй. Вы сообщаете стейкхолдерам, что, вероятно, релиз будет несколько позже,
чем 5 февраля. Они призывают вас немного ускориться. «Просто поднажмите, — го-
ворят они. — Наши заказчики рассчитывают на релиз 5 февраля!»
Пятнадцатого января во время демо ваши стейкхолдеры вдруг понимают, что одна
из функциональностей нуждается в дополнительных средствах аудита. Вы добавля-
ете четыре новые истории, чтобы удовлетворить эту потребность. С учетом шести
законченных историй остается 23 истории, а это означает, что вы точно не закончите
к 5 февраля. Вы предлагаете урезать функциональность, чтобы вернуть дату релиза
к начальным условиям, но стейкхолдеры сопротивляются. «Мы уже сказали заказ-
чикам, чего ожидать, — говорят они. — Мы просто скажем им, что будет задержка
на неделю».
На следующей неделе все идет гладко. Вы снова делаете шесть историй, и 22 ян-
варя остается 17 историй. Вы на пути к релизу 12 февраля.
Следующие несколько недель все идет не очень хорошо. Вы ждали, пока другая
команда поставит специальный UI-компонент. Они обещали передать его вам в на-
чале января, но продолжают сдвигать сроки. Теперь у вас закончились истории, над
которыми можно работать. Вы берете несколько дополнительных необязательных
историй наподобие «хорошо бы иметь», чтобы оставаться чем-то занятыми. Как
обычно, вы завершаете шесть историй, но большинство из них новые. 29 января
у вас все еще остается 15 историй.
Потом команда, работающая над UI, проясняет ситуацию: они столкнулись с не-
ожиданной технической проблемой. Компонент UI, на который вы рассчитывали,
не будет готов еще минимум месяц. Вы пересматриваете свой план, добавляете
истории, чтобы как-то обойти проблему отсутствующего компонента. 5 февраля, не-
смотря на завершение шести историй, у вас все еще 13 незаконченных историй. Ваши
стейкхолдеры начинают расстраиваться. «Мы отложим релиз еще на одну неделю, до

19 февраля, — говорят они. — Вам просто нужно впихнуть все в последнюю историю.
И мы не можем продолжать сдвигать дату! Нас съедят заживо в Twitter».
Следующие две недели дела идут совсем не весело. Вы продолжаете искать новые
истории, чтобы заменить отсутствующий компонент UI. Все работают сверхуроч-
но, стараясь успеть к дате релиза, и вы сокращаете тестирование и резерв времени.
Вы игнорируете своей потенциал и беретесь за большее количество историй, исходя
из того, что дополнительное время сработает.
Оно не срабатывает. На первый взгляд все выглядит хорошо. К 12 февраля вы
завершаете девять историй! Однако на следующей неделе узнаёте, что четыре из них
нужно переделать из-за багов и неучтенных исходных предположений. Если учесть
все новые UI-истории, то оказывается, что работы слишком много. Когда прибли-
жается 19 февраля, у вас все еще остается четыре истории.
В итоге на следующей неделе вы делаете релиз. 26 февраля. Вы ни разу не делали
менее шести историй в неделю. Но каким-то образом релиз 30 историй изначаль-
ного плана у вас занял восемь недель. Этот вид задержек называется рисками срыва
графика.
Запланированные даты релизов

Риски срыва графика непредсказуемы.
Если бы вы могли их предсказать, то они Лучший способ прогнозировать
не были бы рисками — а были бы частью риски срыва графика — определить,
вашего плана. И они неизбежны. Поэтому когда вы будете делать релиз, но
лучший способ прогнозировать их — опре- не что вы будете включать в него.
делить, когда вы будете делать релиз, но
не что вы будете включать в него. Таким образом вы сможете скорректировать ваши
планы в случае какого-либо сюрприза. В предыдущем примере если бы стейкхолдеры
не сказали заказчикам, чего именно ожидать, то команда могла бы сократить пакет
функциональностей и сделать релиз вовремя.
Кроме того, информирование людей о том, что и когда вы будете выпускать,
снижает ваше соответствие принципам Agile. Оно подразумевает поиск новой ин-
формации и ответное изменение планов. Если вы будете точно сообщать людям, что
собираетесь делать, то вам придется менять ваш прогноз каждый раз, когда вы бу-
дете менять план. В лучшем случае это будет означать, что время и усилия, потра-
ченные на предыдущий прогноз, были потрачены зря. Зачастую люди воспринима-
ют ваши прогнозы как обязательства и расстраиваются, когда вы их меняете.
Вместо этого прогнозируйте только дату релиза. Управляйте вашими планами
так, чтобы быть готовыми выпустить в эту дату ваши самые ценные инкременты.
Таким образом вы сможете сделать релиз вовремя независимо от того, что закон-
чили. Обычный вариант этой идеи — поезд
с релизами, который представляет собой См. также
запланированную серию дат релизов (см.
подраздел «Делайте частые релизы и как Адаптивное планирование (глава 8)
можно раньше» главы 8).
Как управлять своими планами

Чтобы все успеть к запланированной дате релиза, нужно разделить работу на мини-
мально возможные ценные инкременты. Сосредоточьтесь на том, чтобы как можно
быстрее оказаться в состоянии, когда релиз возможен. Для этого отложите в сторону
все истории, которые не обязательно выпускать.
Этот простой минимум и будет вашим первым инкрементом. Как только вы его
идентифицировали, посмотрите на истории, которые вы отложили, и решите, какие
могут быть сделаны сами по себе, как дополнительные инкременты. Некоторые из них
могут быть совсем маленькими, на одну историю — фактически это идеал. В идеальном
мире вы бы хотели, чтобы каждая история была чем-то, что можно выпустить само по
себе, не ожидая каких-либо дополнительных историй. Это позволит вам быть макси-
мально гибкими и управлять своими планами. В подразделе «Держите открытым окно
возможностей» главы 8 содержится больше информации по данной теме.
Как минимум инкременты должны быть достаточно маленькими, чтобы вы могли
легко закончить хотя бы один до даты вашего релиза. Заканчивая работу, следите
за тем, сколько времени осталось, и используйте эту информацию, чтобы решить,
что делать дальше. Если у вас много времени, то вы можете сформировать большой
новый инкремент, ведущий ПО в новом направлении. Если времени остается не так
много, то сфокусируйтесь на более мелких дополнительных инкрементах.
Вы можете судить о размерах инкремента на основе внутреннего чутья. Если вам
нужно больше точности, то используйте вре́менные прогнозы даты и объема работы
(поговорим о них чуть позже), чтобы посмотреть, что подойдет, но не разглашайте
их. Это даст вашей команде возможность поменять планы позже.
Прогнозы осуществимости
Иногда вы просто хотите знать, стоит ли браться за идею, не прибегая к временны́ м
и финансовым затратам на подробное планирование. Любой подход, не подразуме-
вающий детального планирования, будет просто основан на внутренних ощущениях,
и это нормально. Люди с большим опытом могут принимать правильные решения
на основе своих внутренних ощущений.
Чтобы сделать прогноз осуществимости, соберите вместе спонсора команды,
опытного менеджера по продукту или проекту и одного-двух старших программи-
стов — предпочтительно участников команды. Выбирайте людей с большим опытом
работы в вашей компании.
Попросите спонсора описать цели разработки, дату начала работы, состав команды
и указать самую позднюю дату релиза, которая еще будет стоить затрат на нее. За-
тем спросите продакт-менеджера и программистов, считают ли они это возможным.
Обратите внимание: вы не спрашиваете, сколько времени это займет. Это более
трудный вопрос. Вам нужна первая, спонтанная реакция. Формулировка вопроса
в терминах твердых ожиданий делает эту реакцию более надежной.
Если ответ — безоговорочное «да», то имеет смысл инвестировать в месяц-другой
разработки, чтобы вы смогли подготовить реальный план и прогноз. Если эксперты
будут колебаться или скажут «нет», то существует риск. Стоит ли он инвестиций
в более тщательный прогноз — зависит от спонсора.
Прогнозы сроков и объема работы

Лучше всего прогнозировать, когда, а не что вы будете выпускать, однако иногда
вам все же необходимо прогнозировать и то и другое. Чтобы сделать это точно,
нужно учитывать риски срыва графика. По сути, вы добавите некоторые дополне-
ния, называющиеся поправкой на риск, чтобы компенсировать проблему. Формула
выглядит так1:
Количество оставшихся недель = количество оставшихся историй
(или общая примерная оценка) ÷ еженедельная пропускная
способность × поправка на риск
Вы также можете спрогнозировать, сколько историй будет сделано к запланиро-
ванной дате релиза:
Количество выполненных историй (или общая примерная
оценка) = количество оставшихся недель × еженедельная пропускная
способность ÷ поправка на риск
Вот что означает каждый из этих терминов:
zz количество оставшихся недель — количество времени от настоящего момента до
даты вашего релиза;
zz количество историй (или общая примерная оценка) — количество историй раз-
мером «в самый раз», которые должны быть завершены до релиза или будут
сделаны к дате релиза. Если вы используете оценки, то это сумма оценок этих
историй;
zz еженедельная пропускная способность — если вы используете итерации, то это
количество историй, законченных в последнюю итерацию (или сумма их оценок),
поделенное на количество недель в итерации. Если вы используете непрерывный
поток, то это количество историй, завершенных за последнюю неделю (или сумма
их оценок). Не усредняйте несколько итераций или недель; здесь поможет по-
правка на риск;
zz поправка на риск — табл. 10.12. Используйте столбец «Команда с высоким риском»,
если ваша команда не владеет свободно навыками на уровнях и фокусировки,
и поставки. Выберите строку, соответствующую вашей желаемой вероятности
успеть к запланированной дате или даже раньше. Например, прогнозы, сделан-
ные с использованием строки «90 %», сбудутся к планируемой дате или раньше
в девяти из десяти случаев.
1
Большое спасибо Тодду Литтлу за обратную связь по этой технике.
2
Эти цифры риска являются обоснованным предположением. Цифры, представляющие «высокий
риск», основываются на [Little2006] и последующих обсуждениях с Тоддом Литтлом. Цифры,
представляющие «низкий риск», основываются на симуляторе RISKOLOGY ДеМарко и Листера
версии 4а, доступном по адресу https://systemsguild.eu/riskology. Я использовал стандартные
настройки, но выключил отклонение производительности, так как потенциал автоматически
подстраивается под этот риск.
Таблица 10.1. Эмпирические правила поправки на риск
Вероятность Команда с низким риском Команда с высоким риском

10 % (почти невозможно) 1 1
50 % (дело случая) 1,4 2
90 % (очень вероятно) 1,8 4
Прогноз сроков и объема работы зависит

от историй, размер которых был определен См. также
как «в самый раз» при игре в планирование.
Если вы не разбили все истории в вашем ре- Игра в планирование (глава 8)
лизе до такого уровня детализации, то не смо-
жете прогнозировать релиз. Вам понадобится использовать игру в планирование,
чтобы сначала задать размер всех ваших историй.
Таким же образом, если в релиз входят какие-либо спайк-истории, то вам пона-
добится завершить их все до того, как вы сможете сделать прогноз. Именно поэтому
спайк-истории стоя́т отдельно в вашем плане; иногда ценно запланировать их заранее,
чтобы вы смогли устранять риски и делать прогнозы.
Обновляйте ваш прогноз в конце каждой итерации или раз в неделю, если ис-
пользуете непрерывный поток. При приближении даты релиза прогноз «сузится» до
фактической даты релиза. Со временем составление графиков изменения прогнози-
руемых сроков релиза поможет вам видеть тренды, особенно если ваша пропускная
способность нестабильна.
Пример сроков и объема работы

Вернемся к примеру, приведенному выше. Чтобы сосчитать количество оставшихся
недель, начните с количества оставшихся историй и пропускной способности коман-
ды. Как и раньше, у команды остается 30 историй, и она завершает шесть историй
в неделю.
Далее определите поправку на риск. Я обычно прогнозирую диапазон дат, имею-
щих вероятность 50–90 %. Это дает относительно узкий диапазон, который я могу
преодолеть примерно за половину времени. Если я думаю, что моя аудитория не при-
мет прогноз на основе диапазона, то использую только цифру 90 %.
Конкретная поправка на риск зависит от того, к какой группе риска относится
команда: высокого или низкого, что зависит от ее владения навыками. В этом
случае предположим, что команда владеет навыками одновременно на уровнях
фокусировки и поставки, поэтому относится к группе низкого риска. Это дает
поправку на риск 1,4 и 1,8 для 50 и 90 % вероятности и позволяет получить сле-
дующие прогнозы:
zz 50 % вероятности — 30 историй ÷ 6 историй в неделю × 1,4 поправка на риск =
= 7,0 недель;
zz 90 % вероятности — 30 историй ÷ 6 историй в неделю × 1,8 поправка на риск =
= 9,0 недель.
На рис. 10.1 показан прогноз в виде графика.
Рис. 10.1. Пример итерационного прогноза
Если команда составляет свой прогноз 1 января, то ее участники говорят стейк-

холдерам, что сделают релиз «между 19 февраля и 5 марта». Каждую неделю команда
предоставляет обновленный прогноз следующего вида:
zz 1 января — остается 30 историй; прогноз: 19 февраля — 5 марта (7,0–9,0 недель);
zz 8 января — остается 25 историй; прогноз: 19 февраля — 5 марта (5,8–7,5 недели;
я всегда округляю);
zz 15 января — остается 23 истории; прогноз: 26 февраля — 5 марта (5,4–6,9 недели);
zz 22 января — остается 17 историй; прогноз: 19 февраля — 5 марта (4,0–5,1 недели);
zz 29 января — остается 15 историй; прогноз: 26 февраля — 5 марта (3,5–4,5 недели);
zz 5 февраля — остается 13 историй; прогноз: 26 февраля — 5 марта (3,0–3,9 недели);
zz 12 февраля — остается 9 историй; прогноз: 5 марта (2,1–2,7 недели);
zz 19 февраля — остается 4 истории; прогноз: 26 февраля — 5 марта (1,0–1,4 недели);
zz реальный релиз — 26 февраля.
Команда, упомянутая в примере, столкнулась со множеством проблем, но по-
правка на риск позволила ей сделать релиз вовремя.
Снижение риска
Командам с высоким уровнем риска трудно составлять полезные прогнозы. Три ме-
сяца историй дают прогноз с вероятностью 50–90 % на 6–12 месяцев. Стейкхолдерам
трудно принять такую высокую неопределенность.
Самый простой способ снизить риск — уменьшить размер инкрементов. Вместо

того чтобы делать релизы историй объемом три месяца, делайте релизы историй объ-
емом два месяца. Это даст прогноз на 4–8 недель с 50–90 % вероятности. Не так плохо.
Более трудный, но и более эффективный способ — усовершенствовать ваши прак-
тики разработки. Вам не обязательно иметь отличное владение навыками на уровнях
фокусировки и поставки, чтобы использовать колонку «Низкий риск» в таблице
поправок на риск. Вам просто нужно быть в состоянии ответить утвердительно на
каждый из следующих вопросов:
zz Была ли у вас одинаковая пропускная способность в течение каждой из четырех
последних итераций? (Или если вы используете непрерывный поток, то заверша-
ли ли вы одинаковое количество историй в каждую из четырех последних недель?)
zz Если вы используете итерации, то были ли все ваши истории в четырех последних
итерациях «сделаны сделаны»?
zz Вы не добавили ни одной новой истории для исправления багов в течение четырех
последних итераций (или недель)?
zz В вашем самом последнем релизе, когда истории были закончены, смогли ли вы
сразу сделать релиз в эксплуатационную среду, без дополнительной работы,
ожидания контроля качества или других задержек?
Разберитесь с первыми двумя вопро-
сами, введя практику резерва времени, как См. также
описано в подразделе «Стабилизация потен-
циала» главы 9. Чтобы решить проблемы, Резерв времени (глава 9)
обозначенные в двух последних вопросах, Разработка через тестирование
введите практики уровня поставки, начиная (глава 13)
с разработки через тестирование и непре- Непрерывная интеграция (глава 13)
рывной интеграции.
Пользовательские поправки на риск

Поправки на риск, показанные в табл. 10.1, — это просто обоснованные предположе-
ния. Если вы хотите быть более точными (и возможно, менее пессимистичными), то
можете создать собственную таблицу. Однако для нее требуется очень много данных,
и она не всегда стоит затраченных усилий.
Чтобы создать собственную таблицу поправок на риск, вам понадобятся историче-
ские данные об оценках релизов. Каждую неделю (или итерацию) составляйте базовую
оценку релиза. Базовая оценка релиза — это количество оставшихся недель = остав
шиеся истории (или общая оценка) ÷ недельная пропускная способность.
Затем, когда релиз действительно состоится, сосчитайте, сколько времени в не-
делях он занял на самом деле с момента каждой из оценок. Если на вас оказывали
давление, чтобы вы сделали его быстрее, или у вас было множество багов или ис-
правлений, то используйте ту дату релиза, которая представляет реальный релиз
(когда ПО на самом деле готово), — так ваши прогнозы будут представлять время,
которое действительно нужно вашей команде для создания ценного релиза.
В итоге вы должны прийти к нескольким парам цифр: оценочное (в неделях) и ре-
ально требующееся время (тоже в неделях). Разделите реальное время на оценочное,
чтобы получить соотношение «реальное / оценочное» для каждой пары. В табл. 10.2
представлен пример.
Таблица 10.2. Исторические данные оценок релизов
Дата Базовая оценка Реальная Реальное/оценочное
1 января 5,00 недель 8 недель 1,60
8 января 4,17 недели 7 недель 1,68
29 января 2,50 недели 4 недели 1,60
5 февраля 2,17 недели 3 недели 1,38
12 февраля 1,50 недели 2 недели 1,33
19 февраля 0,67 недели 1 неделя 1,50
В конце отсортируйте соотношения от самого маленького к самому большому.

Добавьте еще одну колонку с позицией каждой строки в процентах. Другими словами,
если у вас восемь строк, то значение соотношения в процентах для первой строки
будет 1 ÷ 8 = 12,5 %. Это ваша пользовательская таблица поправок на риск. Процен-
ты — это вероятность риска, и соотношение «Реальное / оценочное» — поправка на
риск. Продолжение примера — в табл. 10.3.
Таблица 10.3. Пример пользовательской таблицы поправок на риск
Вероятность Поправка на риск

12,5 % 1,33
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
Чем больше данных о релизах вы используете, тем более точными будут по-
правки на риск. Для большей точности каждая команда должна отслеживать свои
данные независимо, но для начала вы можете комбинировать данные от нескольких
похожих команд.
Вопросы
Наша пропускная способность сильно меняется, поэтому прогнозы постоянно скачут.
Можем ли мы использовать среднее значение пропускной способности, чтобы они
были более стабильными?
Стабилизировать пропускную способность
лучше с помощью потенциала и резерва време- См. также
ни. Если этот вариант не подходит, то можете
взять среднее за последние три недели (или Потенциал (глава 9)
итерации), чтобы стабилизировать прогноз Резерв времени (глава 9)
или нарисовать график ваших прогнозов и до-
бавить линии тренда.
Наши прогнозы показывают, что мы делаем релизы слишком поздно. Что нам
делать?
Вам нужно сократить объем работы. Больше информации вы найдете в подразделе
«Когда дорожная карта недостаточно хороша» далее в текущей главе.
Наши эмпирические поправки на риск слишком велики. Можем ли мы использовать
меньшее соотношение?
Когда ваш прогноз не слишком оптимистичен, трудно удержаться от соблазна
поиграть цифрами, чтобы улучшить ситуацию. Как человек, который был в такой
ситуации и имеет подтверждающие данные, говорю вам, что это пустая трата времени.
Так вы не измените реальных сроков релиза вашего ПО. Если у вас есть исторические
данные, то можете составить пользовательскую таблицу поправок на риск, но если
данных нет, то лучший вариант для вас — встретить неприятные новости с высоко
поднятой головой и сократить объем работы.
Запланированные даты релизов и прогнозы осуществимости подходят любой ко-
манде.
Чтобы сделать прогноз даты и объема рабо-
ты, вам нужна команда, работающая над акту- См. также
альным ПО, для которого был сделан прогноз.
Вам нужно иметь историю, насчитывающую Игра в планирование (глава 8)
по меньшей мере четыре недели разработки,
и вы можете прогнозировать инкременты только с историями, размер которых был
заявлен как «в самый раз» при игре в планирование.
Что еще более важно, убедитесь, что вам действительно нужен прогноз. Слишком
многие компании просят прогнозы просто по привычке. Прогнозирование отнимает
время, которое ушло бы на разработку. Не только время, требующееся на составле-
ние прогноза, но и время, необходимое для того, чтобы справиться со множеством
эмоциональных реакций, которые прогнозы вызывают как у членов команды, так
и у стейкхолдеров. Все это также усложняет адаптацию ваших планов.
Как и во всем, что делает команда, имейте четкое представление о том, кому бу-
дут полезны прогнозы по датам и объемам работ, почему и в какой степени. Потом
сравните значение с другими способами, на которые ваша команда может потратить

свое время. Запланированные даты релизов часто являются лучшим вариантом.
Когда ваша команда хорошо делает прогнозы:
zz вы можете координироваться с внешними мероприятиями, такими как марке-
тинговые кампании, имеющими длительные сроки;
zz вы можете координировать предстоящие даты поставок с бизнес-стейкхолдерами;
zz вы понимаете, когда затраты команды превышают ее ценность;
zz у вас есть данные, позволяющие противостоять нереалистичным ожиданиям
и срокам.
Существует много подходов к прогнозированию даты и объема работы. Описанный
мною подход имеет преимущество одновременно в точности и простоте. Однако его
зависимость от историй размера «в самый раз» делает его довольно трудоемким для
прогнозов, предшествующих разработке. Другой недостаток — это объем историче-
ских данных, требующихся для использования в пользовательских поправках на
риск, хотя эмпирические правила часто довольно хороши.
Альтернатива — использовать симуляцию Монте-Карло для усиления небольших
объемов данных. Популярный пример — таблица Троя Мадженниса «Предсказатель
пропускной способности», доступная по адресу https://www.focusedobjective.com/
courses/using-the-monte-carlo-forecasting-spreadsheets.
Недостаток таблицы Мадженниса и подобных ей инструментов оценки заключа-
ется в том, что она просит вас оценивать источники неопределенности, а не исполь-
зовать исторические данные. Например, таблица Мадженниса просит пользователя
предположить диапазон оставшихся историй, как и диапазон количества историй,
которые надо добавить (или разделить, используя ее терминологию). Эти предпо-
ложения сильно влияют на прогноз, но являются всего лишь предположениями.
Таблица была бы более надежной, если бы вместо предположений использовала
реальные данные для расширения объема работы.
Прежде чем начать экспериментировать с альтернативными прогнозами даты
и объема работы, помните, что лучший способ сделать прогноз — выбрать заплани-
рованную дату релиза и строить свои планы так, чтобы успеть точно в срок.

В книге Software Estimation: Demystifying the Black Art [McConnell2006] представлен все-
сторонний анализ традиционных подходов к прогнозированию даты и объема работы.
В статье Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty
[Little2006] автор использует эмпирические данные, чтобы бросить тень сомне-
ния на конус неопределенности (cone of uncertainty), одну из центральных идей
традиционного прогнозирования, обсуждаемого в книге Макконелла. (Данное из-

дание также послужило основой подхода к прогнозированию даты и объема работы,
описанного в этой книге.)
В главе 2 книги The Leprechauns of Software Engineering: How Folklore Turns Into Fact
and What to Do About It [Bossavit2013] автор отслеживает источники идеи конуса
неопределенности и обнаруживает, что у нее нет эмпирической основы.
ДОРОЖНЫЕ КАРТЫ
Аудитория
Наши стейкхолдеры знают, чего от нас ожидать.
Продакт-менеджеры
В конечном итоге быть ответственным за результат
означает делать так, чтобы инвестиции вашей организации приносили хороший до-
ход. В идеальном мире ваши бизнес-стейкхолдеры будут доверять вашей команде
делать это, избавив вас от пристального надзора. Это достижимо, но обычно сначала
требуются год или два надежных поставок.
Тем временем ваша организация хочет контролировать работу вашей команды.
Демо для стейкхолдеров помогают, но менеджеры часто хотят знать больше о том,
что вы делаете и чего ожидать. Вы подели-
тесь этой информацией в вашей дорожной
См. также
карте.
В Agile дорожные карты не должны вы- Доверие стейкхолдеров (глава 10)
глядеть как традиционные дорожные карты
программного обеспечения. Я использую Демо для стейкхолдеров (глава 10)
этот термин довольно свободно, чтобы охва-
тить все разнообразие способов, с помощью которых команды делятся информацией
о своем прогрессе и планах. Одни дорожные карты подробны и дают информацию
по существу, ими нужно делиться с руководителями, другие — краткие и приукра-
шенные — предназначены для заказчиков.
Agile-руководство
Тип вашей дорожной карты зависит от подхода к руководству, практикуемого в вашей
организации. Как ваша организация обеспечивает эффективную работу команд и их
движение в верном направлении?
Классический подход — руководство, основанное на проектах. Оно подразумевает
создание плана, оценку затрат и оценку стоимости. Проект подлежит финансирова-
нию, если общая стоимость значительно превышает общие затраты. После принятия
решения о финансировании проект тщательно контролируется, чтобы убедиться,
что он идет в соответствии с планом.
Этот предиктивный подход к руководству не в стиле Agile. Он подразумевает,
что планы должны быть определены заранее. Изменения строго контролируются,
и успех определяется как выполнение плана. Руководству нужны дорожные карты,
содержащие детальные планы, оценки затрат и прогресс выполнения работ.
Подход Agile — это руководство, основанное на

продукте. Оно подразумевает выделение бюджета Подход Agile — это
на текущую деятельность и оценку стоимости руководство, основанное
того, что команда будет производить с течением на продукте.
времени. Продукт финансируется, если текущая
стоимость в достаточной степени превышает текущие затраты. С момента финан-
сирования стоимость и затраты на продукт тщательно контролируются, чтобы обе-
спечить достижение желаемой окупаемости инвестиций независимо от фактических
характеристик продукта. Когда стоимость отличается от расчетной, затраты и планы
корректируются соответствующим образом.
Это адаптивный подход к руководству. Он предполагает, что команда будет ис-
кать информацию и новые возможности, потом менять свои планы так, чтобы вос-
пользоваться преимуществами того, что она узнала. Успех определяется в терминах
коммерческих результатов, таких как коэффициент рентабельности инвестиций
(ROI). Руководству нужны дорожные карты, содержащие расходы, показатели
стоимости, такие как выручка, и бизнес-модель.
Хотя Agile адаптивный, а не предиктивный, многие Agile-команды подвержены
проектному стилю руководства. Ваши дорожные карты должны учитывать эту
реальность. Я предоставил четыре варианта — от максимально адаптивного до
максимально предиктивного. Выберите вариант с наименьшим из номеров, с ко-
торым сможете работать. В некоторых случаях у вас будет несколько дорожных
карт, например одна — для надзора со стороны руководства, а вторая — для продаж
и маркетинга.
Вы можете презентовать дорожную карту вашей команды в любом подходящем
вам формате и с любой степенью детализации. Для внутренних дорожных карт обычно
выбирают небольшую подборку слайдов, электронное письмо или Вики-страницу.
Для дорожных карт, предназначенных для внешнего использования, подойдут глян-
цевая, менее детализированная веб-страница или маркетинговое видео.
Вариант 1. Только факты

Дорожная карта «Только факты» — это совсем не дорожная карта в традиционном
смысле этого слова. Это описание того, что ваша команда сделала на данный момент,
без каких-либо предположений на будущее.
С точки зрения ответственности и обязательств
это самый безопасный вид дорожной карты, по- См. также
скольку вы делитесь только теми вещами, которые
уже произошли. Ее также проще всего адаптиро- Цель (глава 7)
вать, так как вы не даете никаких обещаний насчет
будущих планов. В ней содержатся:
zz цель вашей команды;
zz что закончено и готово к следующему релизу;
zz дата следующего релиза, если вы используете запланированные даты релизов
(см. подраздел «Запланированные даты релизов» ранее в данной главе).
Кроме того, в дорожные карты, предназначенные для руководства, команды

оптимизации вносят:
zz текущие показатели коммерческой стоимости (выручка, удовлетворенность за-
казчика и т. д.);
zz текущие затраты;
zz бизнес-модель.
Даже если руководству требуется более предиктивная дорожная карта, вариант
«Только факты» может хорошо подойти для отдела продаж и маркетинга. Преиму-
щество подхода «Только факты» заключается в том, что никто никогда не будет рас-
строен, если ваши планы изменятся, поскольку никто не знает, что планы изменились.
В сочетании с поездами с релизами (см. подраздел «Делайте частые релизы и как
можно раньше» главы 8) это может приводить к регулярным объявлениям о захва-
тывающих новых функциональностях, которые люди могут получить прямо сейчас.
Широко известный пример такого подхода — компания Apple, которая имеет тен-
денцию объявлять о новых продуктах, только когда они готовы к покупке. Он также
характерен для видеоигр, использующих регулярные обновления вместе с марке-
тинговыми видео «Что нового», чтобы возобновить интерес и вовлеченность людей.
Вариант 2. Общее направление

Стейкхолдеры часто хотят большего, чем просто факты. Они также хотят знать, что
будет. План «Общее направление» обеспечивает хороший баланс. Предположения
сведены к минимуму, так что ваша команда все еще может адаптировать свои планы,
но в то же время и стейкхолдеры не остаются в полном неведении насчет будущего.
В этой дорожной карте содержится все, что есть в варианте «Только факты», плюс:
zz ценный инкремент, над которым команда работает в данный момент, и объяснение,
почему он является наивысшим приоритетом;
zz ценный инкремент (или инкременты), над которым команда, скорее всего, будет
работать дальше.
Инкременты представлены без привязки к датам. Команды оптимизации могут
также добавлять гипотезы о коммерческих результатах предстоящих релизов.
Вариант 3. Дата и примерный объем работы

В дорожной карте «Дата и примерный объем
работы» прогнозируемые даты релизов до- См. также
бавляются к варианту «Общее направление».
Это снижает соответствие принципам Agile Прогнозирование (глава 10)
и повышает риск, поскольку люди имеют
склонность воспринимать такие дорожные карты как обязательства независимо от
того, насколько часто вы предостерегаете от этого.
Это ставит команды перед неудобным компромиссом: или вы используете
консервативный прогноз, например, с вероятностью успеха 90 % и указываете
пессимистичную дату релиза; или используете более оптимистичный прогноз, на-

пример, с вероятностью успеха 50 % и риском не успеть к заявленной дате. Более
того, работа имеет тенденцию расти в объемах и заполнять все имеющееся время,
так что более консервативные прогнозы, вероятно, приведут к меньшему количеству
сделанной работы.
Но так как дорожная карта не содержит деталей каждого инкремента, команда
все еще может управлять своими планами, как описывалось в подразделе «Запла-
нированные даты релизов» ранее в данной главе. Вместо того чтобы прогнозировать
готовность каждой истории, сделайте консервативный прогноз для обязательных
историй в вашем плане и рассматривайте его как запланированную дату релиза.
Так вы получите прогноз, который сможете выполнить, не заглядывая слишком
далеко в будущее. Тогда, если у вас остается дополнительное время (а если прогноз
был действительно консервативным, то оно остается), вы можете использовать его
для доработки и добавления других необязательных историй, которые «неплохо
было бы иметь».
Команды оптимизации обычно не используют этот вид дорожных карт. Бизнес-
затраты не стоят получаемой выгоды. Однако эти карты могут быть полезными,
когда нужно координировать работу с третьими сторонами, например с торговыми
выставками или другими маркетинговыми мероприятиями.
Вариант 4. Детальные планы и прогнозы

Этот вариант менее всего близок к стилю Agile и наиболее рискован. Это дорожная
карта «Дата и примерный объем работы», в которой также содержится каждая исто-
рия, имеющаяся в плане команды. В результате команда не может управлять своими
планами, не обосновывая внесенные изменения. Это приводит к более консерва-
тивным прогнозам (что означает бо́льшую вероятность потери времени впустую)
и меньшему желанию вносить изменения.
Хотя это наиболее рискованный тип дорожной карты, организации часто склон-
ны предпочитать именно его. Он кажется более безопасным, несмотря на то что
в действительности является наименее безопасным. Неопределенность вызывает
у людей дискомфорт, а эта дорожная карта позволяет им говорить уверенно.
Однако эта уверенность — всего лишь иллю-
зия. Разработка ПО неопределенна по своей сути. Искусственная определенность
Искусственная определенность только осложняет только осложняет
адаптацию к изменяющимся обстоятельствам. адаптацию к изменяющимся
Иногда вам все же придется предоставлять обстоятельствам.
эту дорожную карту. Для этого делайте прогнозы,
содержащие каждую историю, а не только обязательные. Как и с вариантом 3, вам
понадобится сделать выбор между консервативными прогнозами, которые надежны,
но потенциально ведут к потерям, и более оптимистичными, которые вы можете
не выполнить.
Команды, не обладающие свободным владением навыками на уровне фокуси-
ровки или поставки, обычно несут в себе много рисков, а это значит, правильный
консервативный прогноз покажет дату релиза где-то в будущем, слишком далеком,

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

Компании часто ставят задачу своим коман-
дам использовать так называемые инстру- Отслеживать команды
менты управления жизненным циклом Agile с помощью инструментов
или другие инструменты планирования, планирования — это ошибка.
чтобы можно было отслеживать работу ко-
манд и создавать отчеты автоматически. Это ошибка. Это не только вредит команде
(которой нужна визуализация в свободной форме, которую она может легко менять
и повторять), но и укрепляет и без того не соответствующий Agile подход к управ-
лению.
Agile-менеджмент представляет собой
создание систем, в которых команды при- См. также
нимают эффективные решения самостоя-
тельно. Работа руководителя — обеспечить Менеджмент (глава 10)
командам доступ к информации, контексту Цель (глава 7)
и необходимой им поддержке. «Инструмен-
Демо для стейкхолдеров (глава 10)
ты планирования Agile» имеют отношение
ко всему что угодно, только не к Agile: они
созданы для слежки и контроля за командами, а не для помощи им. В лучшем случае
это дорогостоящее развлечение. Не используйте эти инструменты. Они повредят
вашему стремлению быть Agile.
Это не значит, что командами никто не управляет. Руководству все же надо дер-
жать руку на пульсе. Но это достигается с помощью периодического повторения цели
команды, обеспечения наблюдения и обратной связи во время демо для стейкхолде-
ров и использования наиболее адаптивных дорожных карт из возможного (вдобавок
к эффективному и активно вовлеченному менеджменту) командного уровня.
Если от вашей команды требуют использования корпоративного инструмента от-
слеживания, то вносите в него только ту информацию, которую требует руководство.
Для ежедневной работы используйте другие практики планирования, описанные
в этой книге, копируя информацию в корпоративную систему по необходимости.
Если в вашей дорожной карте только ценные инкременты, а не истории, это будет
не слишком обременительно.
Если вы должны вносить истории в вашу дорожную карту (чего я не рекомен-
дую), то подумайте, нет ли легкого способа делать это. Возможно, вы сможете делать
фотографию вашего визуального плана, вместо того чтобы переписывать карточки
в систему. Возможно, руководителям следует более активно вовлекаться в сессии
планирования, или, может быть, они просят

о чем-то, что на самом деле им не нужно. См. также
Однако если они настаивают, то вы може-
те переписывать истории в корпоративную Визуальное планирование (глава 8)
систему планирования. Делайте это раз в не-
делю (или ежедневно, если у вас нет другого выхода) и помните: каждая история
должна представлять собой короткую фразу, а не миниатюрный документ с требо-
ваниями.
Если руководители хотят, чтобы вы хранили больше деталей в системе, или
настаивают на отслеживании индивидуальных задач, то что-то идет не так. Руко-
водство может испытывать сложности с тем, чтобы отпустить ситуацию, или ваша
организация может быть неподходящей для Agile. Попросите помощи у наставника.
Когда дорожная карта недостаточно хороша

В конечном итоге кто-нибудь попросит у вас дорожную карту с прогнозом
даты, а потом скажет, что дата слишком далекая и вам нужно сделать поставку
быстрее.
Есть только один реалистичный способ
ускорить поставку — сократить объем рабо- Сократить объем работы —
единственный способ
ты. Вы должны удалить истории из вашего
ускорить поставку.
плана. Все остальное — это выдавать жела-
емое за действительное.
Вы можете попытаться улучшить ваш потенциал (см. подраздел «Как улучшить
потенциал» главы 9) или продолжать развивать навыки, но начать следует с сокраще-
ния объема. Все другие усилия требуют времени, и их влияние трудно предсказать.
Если они окупятся, то вы сможете вернуть удаленные истории обратно.
Иногда вам могут не позволить сократить объем работы. В этом случае вам
предстоит трудный выбор. С реальностью не поспоришь, так что вам остаются
дипломатические варианты решения. Вы можете или защищать свои позиции, от-
казываться менять прогноз и рисковать быть уволенными, или использовать менее
консервативный прогноз, предложить более привлекательную дату и рисковать
опоздать с релизом.
Прежде чем принять решение, посмотрите на другие команды в вашей компа-
нии. Что происходит, когда они не успевают вовремя? Во многих компаниях даты
релизов используются как дубинка (способ давить на людей, чтобы они работали
больше и интенсивнее), но реальных последствий не несут. В других компаниях даты
релизов — священные обязательства.
Если вы попали в ситуацию, когда ваша дорожная карта недостаточно хороша
и у вас нет возможности сократить объем работы, то попросите помощи. Положитесь
на членов команды, которые понимают политику вашей организации, обсудите ваши
варианты с руководителем, которому доверяете, или попросите совета у наставника.
Помните: лучший подход к прогнозированию — если это возможно, выбрать за-
планированные даты релизов и управлять своими планами так, чтобы успеть точно
в срок.
Дедлайн
Реальная история: у самой сложной команды, которую я когда-либо
тренировал, были жесткие дедлайны. (А у кого их нет?) Реальный
заказчик команды был критически важен: крупное ведомство,
приносящее бóльшую часть дохода организации. Если бы мы
не смогли удовлетворить его запросы, то рисковали бы лишиться
огромной части жизненно важного бизнеса. Объем работы и дата
готовности были фиксированными.
Зная, что было поставлено на карту, я сделал надежный прогноз нашим главным
приоритетом. Шесть недель спустя мы не только реализовали первый набор
историй объемом на шесть недель — у нас уже был измеренный потенциал,
полностью оцененный список оставшихся историй и прогноз относительно того,
когда все будет сделано.
Он показал, что мы опаздываем. Сильно опаздываем. Нам нужно было сделать
поставку через семь месяцев. Прогноз показал, что это займет тринадцать.
Я отнес прогноз директору. Все пошло прахом. Директор запретил нам делиться
этими новостями с заказчиком. Вместо этого он приказал нам любым возможным
способом сделать все в соответствии с первоначальным дедлайном.
Мы знали, что не можем выполнить работу в соответствии с этими сроками.
Мы не могли добавить людей; команда уже была полностью укомплектована,
и новым программистам понадобилось бы много времени, чтобы ознакомиться
с кодовой базой. Мы не могли сократить объем работы, поскольку не имели воз-
можности признать наличие проблемы перед заказчиком.
На кону стояли наши рабочие места, и мы старались, чтобы все получилось.
Мы игнорировали закон Брукса («Добавление человеческих ресурсов в программ-
ный проект, не укладывающийся в сроки, приводит к еще большей задержке»
[Brooks1995], с. 25), наняли группу программистов и сделали все, что смогли,
чтобы быстро ввести их в курс дела, не отвлекая продуктивных членов коман-
ды от их работы. Несмотря на все наши усилия, мы поставили ПО с дефектами
с шестимесячным опозданием — в пределах нескольких недель от даты нашего
прогноза. Мы лишились заказчика.
Я больше никогда не буду участвовать в сокрытии информации. Расписания
не умеют хранить секреты. Чудес не бывает. Настоящая дата релиза в конце
концов обязательно всплывет на поверхность.
Вместо этого я делаю все, что в моих силах, чтобы представить наиболее точную
картину происходящего. Если в данном релизе должен быть исправлен дефект, то
я планирую исправление перед следующей историей. Если наш потенциал ниже
того, что мне бы хотелось, я, тем не менее, делаю прогноз, основываясь на нашем
реальном потенциале. Это реальность, и только будучи честным по отношению
к ней, я могу эффективно управлять последствиями.
Вопросы
Как часто мы должны обновлять свою дорожную
карту? См. также
Обновляйте ее, когда появляется существен-
Демо для стейкхолдеров
ная новая информация. Сообщать об изменени- (глава 10)
ях дорожной карты можно во время проведения
демо для стейкхолдеров.
Что мы должны говорить стейкхолдерам о вероятности прогноза?
По моему опыту, стейкхолдерам трудно понять вероятность прогноза. Я даю диа-
пазон дат, но не вдаюсь в детали насчет вероятностей.
Если команда не отчитывается о детальных планах, то как руководители команд-
ного уровня понимают, что делают их команды?
Руководители командного уровня могут напрямую посмотреть на доски плани-
рования своих команд. Больше информации об управлении командами вы можете
найти в разделе «Менеджмент» далее в текущей главе.
Кто угодно может создавать дорожные карты, но создание эффективных простых
дорожных карт требует управления в соответствии с Agile и готовности позволить
командам отвечать за свою работу, как обсуждается в главе 4.
Когда вы хорошо используете дорожные карты:
zz руководители и стейкхолдеры понимают, над чем работает команда и почему;
zz команде не мешают адаптировать ее планы.
Есть много способов презентовать дорожные карты, и я не вдавался в детали на-
счет специфических стилей презентаций. Экспериментируйте! Самый известный
подход, который я видел, — наборы коротких слайдов, но некоторые также делают
видео (в частности, для дорожных карт типа «Только факты»), ведут Вики-страни-
цы и рассылают электронные письма с обновлениями статуса. Обсудите с вашими
стейкхолдерами, что для них лучше.
В ходе эксперимента ищите способы улучшить вашу способность адаптиро-
ваться и делать меньше прогнозов. Со временем стейкхолдеры начнут доверять
вашей команде, поэтому будьте готовы к тому, что их ожидания изменятся. Вы
можете обнаружить, что предыдущие требования, казавшиеся незыблемыми,
больше неважны.

Джоанна Ротман ведет отличную дискуссию об управлении ожиданиями в главе 7
книги Behind Closed Doors: Secrets of Great Management [Rothman2005].
МЕНЕДЖМЕНТ
Аудитория
Мы помогаем своим командам достичь успеха.
Руководители
Демо для стейкхолдеров и дорожные карты по-
зволяют руководителям видеть, что производят их
команды. Но руководителям нужно больше. Они хотят знать, работают ли команды
эффективно и как они могут помочь им добиться успеха.
В отличие от остальных практик данной книги, которые предназначены для
членов команды, эта практика — для руководителей. В первую очередь для руково-
дителей командного уровня, но идеи могут применять и руководители среднего
и старшего звеньев. В рабочей среде, в которой команды сами решают, как будет
сделана работа (см. врезку «Самоорганизующиеся команды» в главе 7), что делают
руководители и как они помогают своим командам достичь успеха?
Большинство организаций используют менед-
жмент на основе измерения: собирая показатели,
Менеджмент на основе
требуя отчеты и разрабатывая систему наград для
измерения не работает.
поощрения правильного поведения. Это проверенный
временем подход к управлению, возвращающий нас
во времена изобретения сборочного конвейера.
Есть лишь одна проблема — он не работает.
Максимальное ускорение
— Согласно этой книге, — говорит вице-президент по инженерным
вопросам, держа в руках экземпляр Accelerate1, — высокопроиз-
водительные организации имеют автоматизированные тесты.
Начиная с этого момента любой регистрируемый вами код должен
не менее чем на 90 % покрываться тестами. Это обязательное
требование. Все, кто не согласен, могут искать другую работу.
Тишину нарушает чей-то кашель. Затяжной, подозрительно похожий на фразу:
«Корреляция — это не причинно-следственная связь». Вице-президент пристально
смотрит в вашем направлении.
1
Accelerate [Forsgren2018] — отличная книга. Я упоминаю увиденные мною случаи неправильного
ее применения, а не подвергаю критике ее саму.
Форсгрен Н., Хамбл Дж., Ким Дж. Ускоряйся! Наука DevOps: Как создавать и масштабировать
высокопроизводительные цифровые организации.
— Тебе обязательно нужно было делать это, стоя рядом со мной, Нелия? — жалобно
говорите вы позже. — Здесь довольно трудно получить повышение.
— Извини, — говорит она, совсем не выглядя виноватой. — Знаешь, я уже про-
ходила через это раньше. Я могу рассказать тебе, что будет дальше. Во-первых,
все будут в панике, поскольку на кон поставлена их работа. Во-вторых, руково-
дители скажут, что ни один из наших дедлайнов не меняется, так как их бонусы
зависят от соблюдения сроков релизов. В-третьих, у нас самый фиго… — Она
бросает взгляд на банку ругательств. В ней уже столько взносов Нелии, что
хватило профинансировать три из четырех последних «пончиковых» пятниц. —
Хм, самый сомнительный пакет тестирования в мире. Много-много медленных,
простеньких, ничего толком не проверяющих тестов. В итоге мы тратим все
свое время, ожидая, пока пройдет тест, и разбираясь с фальшивыми ошибками
тестов. И ничего не улучшается.
— Вот поэтому я ненавижу всю эту белиберду с Agile, — продолжает она. — Тонны
работы, ноль реальных результатов. Почему мы не можем просто писать код?
Теория X и теория Y
В 1950-х Дуглас Макгрегор определил два противоположных стиля управления:
теорию X и теорию Y. Каждый из них основывается на своей теории мотивации
работников.
Руководители, придерживающиеся теории X, уверены, что сотрудники не любят
работу и пытаются ее избежать. Их нужно принуждать и контролировать. Внешние
мотиваторы, такие как оплата, льготы и пособия, и другие формы поощрений — глав-
ный механизм, позволяющий заставить работников делать то, что нужно. Согласно
теории X, разработка и внедрение внешних схем мотивации с использованием таких
инструментов, как измерение и поощрение, — центральный элемент правильного
менеджмента.
Руководители, выбравшие теорию Y, верят, что сотрудникам нравится работать
и они способны к самоуправлению. Они ищут ответственность и получают удо-
вольствие, решая проблемы. Внутренние мотиваторы, такие как чувство удовле
творенности хорошо выполненной работой, вклад в общее дело группы или решение
сложных проблем, — основные движущие силы поведения работника. Согласно
теории Y, центральный элемент правильного менеджмента — обеспечение контекста
и вдохновения, что позволяет людям работать вне строгого контроля.
Менеджмент, основанный на измерениях, — это подход теории X. Он основан на
использовании внешних мотиваторов для стимулирования правильного поведения.
Agile, напротив, — подход теории Y. Ожидается, что члены Agile-команд должны
быть внутренне мотивированы на то, чтобы решать проблемы и достигать цели ор-
ганизации. Они должны быть способны сами решать, над чем им работать, а также
кто и как будет выполнять работу.
Эти предположения встроены в основы

Agile. Успешным этот подход делает ме- Agile требует менеджмента,
неджмент, основанный на теории Y. А вот основанного на теории Y.
менеджмент, основанный на теории X, рабо-
тать не будет. То, что он полагается на измерения и поощрения, искажает поведение
и вызывает дисфункцию. Я объясню это чуть позже.
Роль руководителя в Agile

Некоторые руководители беспокоятся, что в среде Agile для них нет места. Нет ни-
чего более далекого от истины, чем это утверждение. Роль руководителя меняется,
но не становится менее важной. Фактически, делегируя детали своим командам,
руководители освобождают свое время, чтобы сфокусироваться на более значимой
деятельности.
Руководители в Agile управляют скорее общей системой работы, чем работой
отдельных людей. Они настраивают свои команды на успех. Их работа заключается
в том, чтобы направлять свои команды так, чтобы каждая делала правильный выбор,
обходясь без непосредственного вовлечения руководства. На практике это означает,
что руководители команд1:
zz обеспечивают наличие в команде нужных людей, чтобы она имела или могла
получить все необходимые для ее работы навыки. Сюда входят координация
найма и продвижение сотрудников по службе;
zz обеспечивают наличие коучей, в которых нуждается команда;
zz выступают посредниками в межличностных конфликтах, помогают членам коман
ды проходить через хаос изменений и формироваться как команда;
zz помогают членам команды строить и развивать свою карьеру. Выступают настав-
никами для сотрудников — будущих руководителей и воодушевляют на развитие
разных навыков, чтобы команда сохраняла устойчивость в случае потери любого
из ее членов;
zz следят за прогрессом команды в развитии свободного владения навыками (см. чек-
листы во введениях к частям II–IV) и координируются с коучами команды, чтобы
обеспечить обучение и другие ресурсы, необходимые команде для достижения
владения навыками;
zz обеспечивают инструменты, оборудование и другие ресурсы, необходимые ко-
манде для того, чтобы быть продуктивной;
zz делают так, чтобы команда понимала, как ее работа вписывается в общую кар-
тину организации, и чтобы у нее был устав (см. врезку «Планирование сессии
подготовки устава» в главе 7), который регулярно обновляется;
1
Спасибо Диане Ларсен за ее вклад в подготовку этого списка.
zz делают так, чтобы команда понимала, насколько хорошо она соблюдает устав и как
ее работу воспринимают заинтересованные стороны, в частности руководители
и бизнес-стейкхолдеры;
zz находятся в курсе отношений команды и стейкхолдеров и помогают ей понять,
когда и почему эти отношения не работают должным образом;
zz отстаивают интересы команды среди остальной части организации и координи-
руются с коллегами-руководителями для защиты команд друг друга. Помогают
командам справляться с организационной бюрократией и устранять препятствия
на пути к успеху;
zz обеспечивают достижение ожидаемых организацией результатов в таких вопро-
сах, как бюджет, управление, отчетность. Аккуратно подталкивают к ослаблению
этих требований, когда это может помочь команде.
Дисфункция измерений
Есть один пункт, который вы не увидите
в этом списке, — показатели. Это потому, что Менеджмент, основанный
менеджмент, основанный на измерениях, ис- на измерениях, искажает поведение
кажает поведение и вызывает дисфункцию. и вызывает дисфункцию.
Приведу несколько примеров.
Истории и пункты историй

Руководитель команды хотел знать, была ли его команда продуктивной, поэтому
отслеживал количество историй, которое команда завершала в каждой итерации.
Команда сократила тестирование, рефакторинг и разработку дизайна, чтобы делать
больше историй. Результатом стали понижение внутреннего качества, увеличение
количества дефектов и снижение производительности. (Отслеживание потенциала
приводит к такому же результату. Больше информации об этой общей ошибке вы
найдете в подразделе «Потенциал — это не производительность» главы 10.)
Покрытие кода
Один из топ-менеджеров поручил сделать так, чтобы весь новый код проходил
тестирование. Целью было 85%-ное покрытие кода. «Весь новый код нуждается
в тестировании», — сказал топ-менеджер.
Хорошие тесты — маленькие, быстрые и целенаправленные, что требует вни-
мательного и обдуманного подхода. Вместо этого команды данного топ-менеджера
работали над выполнением показателей, используя самый простой и быстрый способ.
Они писали тесты, которые покрывали большое количество кода, но были медлен-
ными и нестабильными, случайным образом сбоили и зачастую не проверяли ничего
важного. Качество кода продолжало ухудшаться, производительность снизилась,
затраты на техническое обслуживание выросли.
Строки кода
В попытках повысить производительность одна компания награждала людей за
добавленное, измененное или удаленное количество строк кода за день. (Похожий
показатель — количество коммитов в день.) Члены команды стали меньше времени
посвящать дизайну и больше — удалению и вставке кода. Качество кода снизилось,
затраты на техническое обслуживание выросли, и члены команды боролись с де-
фектами, которые продолжали появляться после того, как люди думали, что все
исправлено.
Соотношение заявленного к сделанному

Выполнение обязательств важно для выстраивания доверия, однако это нельзя
считать хорошим показателем. Тем не менее одна компания сделала выполнение
обязательств своей ключевой ценностью. «Ответственность здесь очень важна, —
сказали они. — Если вы говорите, что собираетесь сделать что-то к определенной
дате, то должны это сделать. Никаких отговорок».
Их команды стали очень консервативными в своих обязательствах. Объемы
работы росли и заполняли все отведенное время, снижая пропускную способность.
Руководители начали отказываться от чрезмерно долгих временных графиков.
Это подорвало моральный дух и создало напряженность в отношениях между
руководителями и их командами. Команды делали работу торопливо и часто вы-
бирали не лучший способ, что в итоге привело к снижению внутреннего качества,
большему количеству дефектов, повышению затрат на техническое обслуживание
и недовольству заказчиков.
Подсчет дефектов
Что проще: снизить количество дефектов, допускаемых командой, или изменить
определение понятия «дефект»? Одна организация, которая отслеживала количе-
ство дефектов, тратила время впустую на споры о том, что считать дефектом. Когда
определение было слишком узким, команда тратила много времени на исправление
незначительных дефектов. Когда оно было слишком широким, команда отправляла
заказчикам баги, что снижало удовлетворенность этих людей.
Почему дисфункция измерений неизбежна

Когда люди уверены, что об их произво-
дительности будут судить на основании из- Вместо того чтобы делать работу,
мерений, они меняют свое поведение, чтобы которая принесет наилучший
получить лучший балл в этом измерении. результат, люди делают работу,
Но время людей ограниченно. Делая больше которая получит наивысший балл.
для измерения, они должны делать меньше
для чего-то другого. Вместо того чтобы делать работу, которая принесет наилучший
результат, они делают работу, которая получит наивысший балл.
Все знают, что показатели могут вызывать проблемы. Но это лишь потому, что
руководители выбирают плохие показатели, не так ли? Умный менеджер может
предотвратить проблемы, умело балансируя показателями… Верно?
К сожалению, нет. Роберт Остин объясняет, почему нет, в своей основополагающей
книге Measuring and Managing Performance in Organizations:
«Основной посыл этой книги состоит в том, что организационные измерения
сложны. Организационный ландшафт усеян искореженными обломками из-
мерительных систем, разработанных людьми, которые считали, что измере-
ния — это просто. Если вы ловите себя на мыслях типа “Установить успешную
измерительную программу легко, если вы просто выберете правильные кри-
терии” — остерегайтесь! История показывает обратное» [Austin1996] (гл. 19).
Ситуация была бы другой, если бы в программной разработке можно было из-

мерять все, что имеет значение. Но это невозможно. Есть слишком много важных
вещей, которые (хотя и можно измерить каким-либо способом) не могут быть из-
мерены хорошо. Внутреннее качество. Затраты на техническое обслуживание. Про-
изводительность разработки. Удовлетворенность заказчика. Устные рекомендации.
Снова обратимся к Роберту Остину:
«Как профессиональная активность, имеющая значительное ментальное со-

держание и не очень пригодная для ротации, программная разработка, похоже,
особенно плохо подходит для менеджмента, основанного на измерениях… Есть
свидетельства, что дисфункция измерения наносит вред программной разра-
ботке» [Austin1996] (гл. 12).
Люди (особенно в разработке ПО) ненавидят это сообщение. Мы любим фанта-

зии о прекрасном рациональном и измеримом мире. Конечно, это просто вопрос
правильного выбора измерений!
Красивая история, но это ловушка. Нет способа
измерить все, что имеет значение в разработке ПО. Нет способа измерить
Результатом будет бесконечный цикл программ все, что имеет значение
показателей, приводящих к дисфункциям, которые в разработке ПО.
приводят к новым показателям, приводящим к но-
вым дисфункциям.
«Даже когда дисфункция обнаружена и выясняется, что [измерение] полно-
стью не было достигнуто, [руководитель] может все еще сопротивляться вы-
воду, что [измерение] не может быть достигнуто полностью. Вместо этого она
может сделать вывод, что просто что-то неправильно поняла, когда пыталась
изменить дизайн последней работы. Может начаться бесконечная последо-
вательность попыток изменить дизайн работы, пока [руководитель] честно
пытается понять правильно… В результате дизайнеры систем разработки ПО
вечно переделывают дизайн, заменяя старые режимы контроля и выставляя
новые, но структурно похожие режимы, предсказуемо не имеющие успеха»
[Austin1996] (гл. 14).
Делегируемое управление
Даже если бы эффективная система измерения была возможна, измерения упу-
скают главное. Agile требует менеджмента, основанного на теории Y, а не на тео-
рии Х, а он строится на внутренней мотивации, а не на измерениях и системах
поощрений.
Вместо того чтобы думать об измерениях
и поощрениях, сфокусируйтесь на том, что Что члены вашей команды любят
внутренне мотивирует членов команды. Что в своей работе?
они любят в своей работе? Создание чего-то
безумно грандиозного, что полюбят заказчики? Расширение границ технических воз-
можностей? Быть частью высокофункциональной, слаженной команды? Затеряться
в потоке продуктивной работы?
Какой бы ни была мотивация, вдохновляйте вашу команду, показывая, как их
работа будет отвечать их потребностям. Обеспечьте их необходимыми ресурсами
и информацией. И сделайте шаг назад, чтобы они взяли на себя ответственность
и совершенствовались.
Сделайте измерения несущественными

Не то чтобы измерения и показатели не были полезны. Они полезны! Проблемы
возникают, когда люди думают, что измерения будут использоваться для оценки их
продуктивности. К сожалению, люди (особенно разработчики ПО) склонны цинично
относиться к таким вещам. Важно не то, что говорят руководители; дисфункцию
вызывает то, что думают люди.
Чтобы избежать дисфункции, вы должны сделать неправильное использование
этих данных структурно невозможным.
Простейший способ сделать это — сохранять информацию приватно, внутри ко-
манды. Команда собирает данные, анализирует их и уничтожает. В качестве отчета
команда выдает выводы и решения, а не данные, лежащие в их основе. Если никто
их не видит, то нет и риска искажения.
Если это невозможно, то агрегируйте данные так, чтобы их нельзя было связать
с конкретными людьми. Вместо того чтобы использовать данные для оценки под-
чиненных, используйте их для оценки себя. Это применимо ко всем уровням орга-
низации. Руководители команды видят измерения команды, а не отдельных лиц.
Директора видят измерения департамента, а не команды и т. д.
Идите в гемба
Если руководители не получают данных о своих подчиненных, то как они узнают,
насколько продуктивно работают люди? Они идут в гемба (gemba).
Фраза «пойти в гемба» пришла из подхода «Бережливое производство» (Lean
Manufacturing). Она означает «пойти и увидеть своими глазами»1. Идея в том, что
1
Gemba — японское слово, означающее «реальное место [где что-то произошло]», поэтому «пойти
в гемба» буквально значит «пойти в реальное место».
руководители узнают больше о том, что нужно, увидев реальную работу, а не глядя
на цифры.
Руководители, чтобы лучше узнать свои команды, пойдите и посмотрите своими
глазами. Загляните в код. Просмотрите макеты UI. Посидите на интервью со стейк-
холдерами. Посетите совещание по планированию.
Затем подумайте, как бы вы хотели улучшить команду. Спросите себя: «Почему
они уже не делают это сами?» Предположите добрые намерения: в большинстве
случаев это не проблема с мотивацией; это вопрос возможности, организацион-
ных препятствий, или (не сбрасывайте это со счетов) идея уже рассматривалась
и была отложена по веским причинам, которых вы просто не знаете. Crucial
Accountability1 [Patterson2013] — отличная книга, в которой обсуждается, что де-
лать дальше.
Будьте осторожны, не используйте «пойти в гемба» как оправдание для микро-
менеджмента. Это способ улучшить ваше понимание, а не механизм контроля.
Спросите команду
Компетентные Agile-команды знают о ежедневных деталях своей работы куда больше,
чем кто-либо еще. Вместо того чтобы запрашивать измерения, руководители могут
задать своим командам простой вопрос: «Что я могу сделать, чтобы помочь вашей
команде стать более эффективной?» Выслушайте. Потом действуйте.
Определите цели и ограничения

Хотя команда и управляет процессом своей работы, цели этой работы определяют-
ся руководством. Установить требования и границы — это нормально. Например,
одному директору было нужно знать, что его команда эффективно обрабатывает
поток входящих данных. Он собрал свою команду руководителей, сказал им, что
ему нужно, и попросил создать такое измерение, чтобы команды могли отслеживать
сами себя, не боясь осуждения. Директору не нужно было видеть это измерение; ему
нужно было знать, что команды в состоянии держать все под контролем, а если нет,
то он хотел знать, что им для этого нужно.
Пример: покрытие кода

Организации часто реагируют на проблемы с качеством введением обязатель-
ных показателей покрытия кода. Обычно это приводит к дисфункциональным
практикам тестирования, как уже описывалось ранее. Как должен выглядеть
недисфункциональный подход?
Для начала поймите основную мотивацию покрытия кода. Что действительно
нужно команде? Пойдите в гемба: посмотрите код, послушайте стейкхолдеров,
почитайте отзывы заказчиков, поговорите с членами команды и спросите их, что
1
Паттерсон К., Гренни Дж., Максфилд Д. и др. Серьезный разговор об ответственности. Что делать
с обманутыми ожиданиями, нарушенными обещаниями и некорректным поведением.
они рекомендуют. Если они не знают, то попросите совета у наставников. Вот

несколько вариантов, к которым может стремиться команда.
zz Есть ли у команды рискованные пробелы в тестах? Сделайте внутри команды
анализ покрытия кода, отчет о пробелах, а не о первичных «сырых» данных
покрытия кода, и выделите время для добавления тестов там, где они при-
несут наибольшую пользу.
zz Нужно ли команде усовершенствовать свою дисциплину написания тестов?
Обеспечьте коучинг и применяйте практики, улучшающие дисциплину, такие
как парное и групповое программирование.
zz У команды много непротестированного старого унаследованного кода?
Вырабатывайте привычку добавлять тесты как часть работы над любым кодом.
Очень скоро 20 % кода, над которым команда работает наиболее часто, будут
иметь тесты. Остальные 80 % могут подождать.
Любое из этих действий будет иметь более широкое и более непосредственное
влияние, чем показатели покрытия. И даже еще лучше: так как сама команда
принимает решение, а не получает его в качестве приказа сверху, она будет бо-
лее мотивирована следовать ему. Роль руководителя в том, чтобы сделать так,
чтобы обсуждение состоялось и члены команды вышли из своей зоны комфорта,
а также предоставить необходимые команде ресурсы. Этот продуманный подход
с делегированием можно использовать вместо любых показателей.
Когда показатели необходимы

Довольно часто у руководителей в крупных организационных системах связаны
руки. Возвращаясь к Роберту Остину:
«Важный факт, который необходимо осознать, — это что в иерархической
организации каждый руководитель [тоже измеряется]… о ее собственной
производительности судят в основном по тому, насколько хорошо ее орга-
низация (то есть ее [работники]) работает в соответствии с той самой систе-
мой измерения, которую устанавливает [руководитель]. У [руководителя]
тогда есть интерес установить простую в эксплуатации систему измерения.
[Руководитель] и [работник] тайно вступают в сговор для взаимной выгоды»
[Austin1996] (гл. 15).
Если вам необходимо о чем-то отчитываться, то предоставьте описание и каче-

ственную информацию, а не количественные данные, которыми можно злоупотребить.
Расскажите о том, что ваша команда сделала и чему она научилась.
Этого может оказаться недостаточно. От вас может потребоваться отчитывать-
ся в сухих цифрах. Сопротивляйтесь, если можете, но очень часто это вне вашего
контроля.
Если вы можете контролировать используемые измерения, то измеряйте резуль-
таты, максимально близкие к реальным. Одна из таких возможностей — скорость
роста ценности (value velocity). Это мера производительности. Она измеряет
производительность команды с течением времени. Чтобы ее сосчитать, измерьте

два значения для каждого инкремента, выпускаемого командой: эффект, такой
как доход; и время выполнения, которое представляет собой количество недель
(или дней) от начала разработки до момента релиза инкремента. Затем разделите:
эффект ÷ время = скорость роста ценности.
Во многих случаях эффект не так просто измерить. Тогда вы можете оценить эф-
фект каждого инкремента. Это должен сделать спонсор или ключевые стейкхолдеры
вне команды. Все оценки должны быть выполнены одним и тем же человеком или
сплоченной командой, чтобы они были совместимы друг с другом.
Однако помните, что скорость роста ценности вызывает искажения в поведении,
как и любой другой показатель. Какой бы показатель вы ни собирали, сделайте все
возможное, чтобы защитить вашу команду от дисфункции. Большинство показателей
вредят внутреннему качеству, затратам на техническое обслуживание, производи-
тельности, удовлетворенности заказчика и долгосрочной ценности, поскольку их
трудно измерить и всегда есть соблазн подделать. Обратите внимание ваших команд
на важность этих атрибутов и (если реально можете) обещайте им, что не будете
использовать показатели в оценке эффективности.
Вопросы
А что насчет «если вы не можете это измерить, то не сможете этим управлять»?
Фразу «Если вы не можете это измерить, то не сможете этим управлять» часто
приписывают Уильяму Эдвардсу Демингу, статистику, инженеру и консультанту
в области управления, чьи работы оказали влияние на бережливое производство,
бережливую разработку ПО и Agile.
Деминг был очень влиятелен, неудивительно, что его цитата так широко известна.
Есть только одна проблема: он этого не говорил. Он сказал обратное.
Неверно предполагать, что если вы не можете измерить что-либо, то вы не мо-
жете этим управлять, — дорогостоящий миф1.
Делегируемый стиль управления — организационная культура, которая понимает
дисфункцию измерений. Несмотря на то что ей десятки лет (Деминг подчеркивал
необходимость избавиться от менеджмента, основанного на измерениях, по меньшей
мере в 1982-м2), она все еще недостаточно широко понята и принята.
1
Эта цитата объяснена и помещена в контекст институтом Уильяма Эдвардса Деминга (https://
oreil.ly/FNeRb).
2
Принцип 12 из 14 принципов менеджмента Деминга: «А. Устраните барьеры, которые лишают по-
часового работника его права гордиться своим мастерством. Ответственность контролеров должна
быть изменена с сухих цифр на качество. Б. Устраните барьеры, которые лишают менеджеров
и инженеров их права гордиться своим мастерством. Это означает среди прочего упразднение
ежегодной оценки или рейтинга заслуг и системы менеджмента на основе поставленных целей».
Agile все же может работать в среде, базирующейся на измерениях, но цель этой

книги не в том, чтобы сказать вам, что просто работает; цель в том, чтобы сказать
вам, что является лучшим. Делегируемый стиль управления — лучший вариант, если
вы можете его использовать.
Когда вы правильно используете делегируемый стиль управления:
zz команды чувствуют, что настроены на успех;
zz они несут ответственность за свою работу и принимают правильные решения без
активного участия руководства;
zz члены команды чувствуют уверенность, делая то, что ведет к лучшим результатам,
а не к высшим баллам;
zz члены команды и руководители не склонны снимать с себя вину и обвинять
других;
zz руководители хорошо понимают, что делают их команды и как они могут им
помочь.
Основной посыл в этой практике (менеджмент, основанный на измерениях, ведет
к дисфункции) — горькая пилюля для большинства организаций. Вас могут со-
блазнить альтернативы, которые обещают решить проблему дисфункции измерений
с помощью сложных схем балансировки.
Прежде чем сделать это, вспомните, что Agile — это подход к разработке, относя-
щийся к теории Y. Правильный способ управлять Agile-командой — использовать
делегируемый стиль управления, а не менеджмент на основе измерений.
Если вы рассматриваете идеи с альтернативными показателями, то будьте вни-
мательны. Дисфункция измерений не сразу становится очевидной. До этого могут
пройти годы, так что идея может выглядеть великолепно на бумаге и поначалу даже
казаться работающей. Вы не обнаружите ошибку до последнего момента, и даже
когда обнаружите, будет слишком легко свалить вину в проявившейся проблеме на
что-то другое.
Другими словами, скептически относитесь к любому подходу к показателям,
который не является хотя бы таким же тщательным, как подход [Austin1996].
Он основан на тезисах отмеченной наградами докторской диссертации по эконо-
мике Остина.
Тем не менее есть и хорошие, продуманные подходы к Agile-менеджменту. Когда
будете искать возможности для экспериментов, ищите варианты с подходом, де-
лающим упор на сотрудничество и делегирование теории Y. Хорошей начальной
точкой могут послужить ресурсы, перечисленные в подразделе «Литература для
дополнительного чтения».

Turn the Ship Around! A True Story of Turning Followers into Leaders [Marquet2013] —
захватывающая книга и отличный способ узнать больше о делегируемом стиле
управления. Автор описывает, как он, будучи капитаном американской атомной
подводной лодки, учился применять делегирование в своей команде.
Measuring and Managing Performance in Organizations [Austin1996] послужила ис-
точником вдохновения для многих тем в этой практике. Книга представляет строгую
экономическую модель, оставаясь интересной и доступной.
Crucial Accountability: Tools for Resolving Violated Expectations, Broken Commitments,
and Bad Behavior [Patterson2013] — хороший ресурс для руководителей, которым
нужно вмешаться, чтобы помочь своим сотрудникам.
ГЛАВА 11
Совершенствование
Команда должна систематически анализировать

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

в отношении самого подхода команды к Agile. Хотя вы можете начать со стандартного
метода Agile, каждая команда должна сама настроить свой метод.
Как и все остальное в Agile, эта настройка происходит с помощью итераций,
размышлений и обратной связи. Подчеркивайте то, что работает. Улучшайте то, что
не работает. В этом вам помогут следующие практики:
zz с помощью практики «Ретроспективы» команда может непрерывно совершен-
ствоваться;
zz благодаря практике «Динамики команды» повышается способность команды
работать совместно;
zz практика «Устранение препятствий» позволит команде сосредоточить усилия по
совершенствованию там, где они могут иметь наибольшее значение.
Источники совершенствования
Хотя ретроспективы сейчас являются обычной практикой в 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

Retrospectives: Making Good Teams Great [Derby2006]. С этого момента ретроспек-
тивы перешли в Scrum и распространились по всему Agile-сообществу.
Мой подход к практике «Ретроспективы» формировался в течение нескольких
десятилетий экспериментов и опыта. Проводя первые эксперименты с непрерыв-
ным совершенствованием, я вдохновлялся постмортемами проектов — техникой,
которая предшествовала Agile. Позже я позаимствовал идеи из [Kerth2001], затем
работал с Джошуа Кериевски в IXP-команде и еще позже прочитал и добавил
[Derby2006]. Конечный результат совместим с подходом Ларсен к ретроспекти-
вам, хотя и имеет небольшие различия.
Диана Ларсен — не только гуру ретроспектив, но и эксперт в области динамик
организаций и команд. Нам повезло, что она стала приглашенным автором в этой
главе. Она написала разделы «Динамики команд» и «Устранение препятствий».
Эти практики основаны на огромном опыте Дианы в области динамик организа-
ций и команд, обе они предшествовали Agile.
РЕТРОСПЕКТИВЫ Аудитория
Мы постоянно совершенствуем наши рабочие Вся команда

привычки.
Непрерывное совершенствование
Все Agile-команды — разные. Члены команды — разные, стейкхолдеры — разные,
и то, что командам нужно делать, тоже различается. Это значит, что процессы
каждой команды также должны различаться.
Хотя обычно лучше начать изучать Agile со стандартного процесса, такого как
тот, что представлен в данной книге, — это лишь начало, а не конец. Всегда есть
способы заставить процессы команды работать лучше, и когда ваша ситуация
улучшится, процесс должен измениться вместе с ней.
Agile-команды постоянно ищут возможности совершенствовать свои процессы,
рабочие привычки, отношения и окружающую среду. Все, что может улучшить
работу, открыто для рассмотрения.
Организации могут постоянно устанавливать ограничения вокруг процессов
команды, но никогда не должны ожидать, что у каждой команды будет абсолютно
один и тот же процесс. Чем больше команды могут адаптировать процесс к своим
конкретным потребностям, тем более эффективными будут.
Ваша команда должна постоянно обновлять и улучшать свои процессы разработки.

Использовать ретроспективы — отличный способ сделать это.
Виды ретроспектив
Самая обычная ретроспектива — пульсирующая (heartbeat), происходит с регуляр-
ной частотой. (Она также известна как итерационная ретроспектива.) Команды,
использующие итерации, проводят ее в конце каждой итерации. Команды, исполь-
зующие непрерывный поток, проводят ее в определенное время каждую неделю
или две.
В дополнение к пульсирующим ретроспек-
тивам вы можете проводить более длительные, См. также
более интенсивные ретроспективы, достигая
наиболее важных этапов. Такие поэтапные Анализ инцидентов (глава 16)
ретроспективы дают вам шанс более глубоко
осмыслить свой опыт и обобщить ключевые уроки, чтобы поделиться ими с осталь-
ной организацией. Один из примеров — анализ инцидентов, о котором я расскажу
далее в этой книге.
Другие виды поэтапных ретроспектив выходят за рамки данной книги. Лучше
всего они работают, когда проводятся нейтральными третьими сторонами, поэто-
му рассмотрите возможность пригласить опытного фасилитатора ретроспектив.
Крупные организации могут иметь таких фасилитаторов в своем штате (для начала
спросите отдел кадров), или можете привлечь внешнего консультанта. Если вы за-
хотите провести эти ретроспективы самостоятельно, то прочитайте [Derby2006]
и [Kerth2001] — это отличные источники информации.
Как проводить пульсирующие ретроспективы

В каждой ретроспективе должна участвовать вся команда вместе с другими людь-
ми, работающими с ней в тесном контакте, такими как продакт-менеджер. Больше
никто не должен участвовать. Это даст возможность участникам более свободно
высказывать свое мнение.
Фасилитатором может быть кто угодно в команде. Фактически фасилитаторов
лучше часто менять. Это помогает поддерживать интерес к встречам. Начните с людей,
имеющих опыт фасилитации. Когда процесс ретроспективы наладится, дайте шанс
другим членам команды побыть в этой роли.
Фасилитатор никаким другим образом
не участвует в ретроспективе. Его (или ее) роль Фасилитатор никаким
заключается в поддержке общего направления другим образом не участвует
в ретроспективе.
ретроспективы и обеспечении того, чтобы голос
каждого был услышан. Если членам команды
трудно оставаться нейтральными, то команды могут обмениваться фасилитаторами,
чтобы у каждой был нейтральный внешний фасилитатор.
Я выделяю на свои ретроспективы 60–90 минут. Ваши первые несколько ретро-
спектив, вероятно, могут занять все 90 минут. Отведите на это побольше времени,
но не стесняйтесь вежливо свернуть обсуждение и перейти к следующему шагу. Вся
команда будет совершенствоваться, практикуясь, а следующая ретроспектива будет
всего через неделю или две.
Как описывается в [Derby2006], ретроспектива состоит из пяти частей: подго-

товить почву; собрать данные; сгенерировать идеи; решить, что делать; закончить
ретроспективу. В следующих подразделах я опишу простой и эффективный подход.
Не пытайтесь в точности повторить временной режим; позвольте событиям идти
в естественном темпе.
Привыкнув к этому формату, измените его. Ретроспектива прекрасно подходит
для апробации новых идей. Рекомендации представлены в подразделе «Альтерна-
тивы и эксперименты» далее в данной главе.
Небольшое предостережение: ретроспек-
тивы могут навредить, если члены команды См. также
используют их для нападок друг на друга. Если
у вашей команды проблемы с уважительным Безопасность (глава 7)
отношением друг к другу, то в первую очередь Динамики команды (глава 11)
сосредоточьтесь на безопасности и динамиках
команды.
Шаг 1. Первая директива (5 минут)

В статье The Effective Postfire Critique глава Городской пожарной охраны Нью-Йорка
Фрэнк Монтанья пишет:
«Пожарные, как и все люди, ошибаются. Однако когда пожарные ошибаются
в своей работе, это может угрожать их жизни, жизни их коллег и общества,
которому они служат. Тем не менее пожарные будут продолжать делать ошиб-
ки и иногда повторять их» [Montagna1996].
Все ошибаются, даже если на кон постав-

лена жизнь. Ретроспектива позволяет учиться Никогда не используйте
и совершенствоваться, и каждому нужно иметь ретроспективы для обвинений
возможность безопасно делиться опытом и мне- или нападок на отдельных
нием. Команда никогда не должна использовать людей.
ретроспективы для обвинений и нападок на
отдельных людей.
Роль фасилитатора состоит в том, чтобы пресечь деструктивное поведение
в зародыше. Чтобы помочь людям вспомнить о необходимости психологической
безопасности, я начинаю каждую ретроспективу с повторения Первой директивы
Норма Керта:
«Независимо от того, что мы обнаружим, мы должны понимать и искренне
верить, что каждый делал свою работу наилучшим образом, в соответствии
с тем, что было известно на тот момент, его или ее навыками и возможностями,
доступными ресурсами и сложившейся ситуацией» [Kerth2001] (гл. 1).
Спросите каждого участника по очереди, согласны ли они с Первой директивой,

и ожидайте устного «да». Если они не согласны, то спросите, могут ли они отложить
свой скептицизм хотя бы на время этой встречи. Если они все еще не согласны,
то отложите ретроспективу. Возможно, есть межличностная проблема, которую
необходимо сначала решить, чтобы люди смогли говорить честно и открыто, как
того требует ретроспектива. Если вы не знаете, в чем проблема, то попросите по-
мощи у наставника.
Просьба об устном согласии некоторым участникам может показаться странной,
но она служит важной цели. Во-первых, если кто-то искренне против, то, вероятнее
всего, скажет об этом, если нужно будет выразить согласие вслух. Во-вторых, тот,
кто уже однажды высказался во время ретроспективы, скорее всего, заговорит снова.
Устное согласие поощряет дальнейшее участие.
Шаг 2. Мозговой штурм (20 минут)

Если все согласны с Первой директивой, то запишите на доске следующие категории:
увлекательное, разочаровывающее, озадачивающее, продолжать, больше, меньше.
Попросите членов команды поразмышлять о событиях с момента последней ре-
троспективы и используйте одновременный мозговой штурм (см. пункт «Работайте
одновременно» главы 7), чтобы записать их реакции (то, что они считают увлека-
тельным, разочаровывающим, озадачивающим) и предпочтения (то, что они хотят
продолжать, делать больше или меньше).
Если участникам трудно начать, то коротко напомните, что произошло с момен-
та последней ретроспективы («Утром в среду у нас была сессия планирования…»).
Делайте паузу после каждого пункта, чтобы дать людям шанс записать идеи. Другие
участники тоже могут поделиться своими воспоминаниями.
Когда идеи начнут заканчиваться, посмотрите на время. Если у вас оно осталось,
то немного побудьте в тишине. Часто бывает так, что кто-нибудь скажет что-то, о чем
умолчали, и это может вызвать новый раунд идей. Если времени у вас не осталось,
то можете перейти к следующему шагу.
Шаг 3. Безмолвное сопоставление (15 минут)

Далее используйте молчаливое сопоставление (mute mapping), чтобы рассортировать
карточки по кластерам. Закончив, с помощью точечного голосования выберите
один кластер, который предстоит совершенствовать. (О том, что такое молчаливое
сопоставление и точечное голосование, рассказывается в пункте «Работайте одно-
временно» главы 7.) Если кластер-победитель не определился, то не тратьте времени
на его выбор. Подбросьте монету или сделайте что-то подобное.
Выбросьте карточки из других кластеров. Если кто-то хочет взять карточку
для индивидуальной работы, это хорошо, но не необходимо. Помните: вы будете
проводить следующую ретроспективу через неделю или две. Важные вопросы воз-
никнут снова.
Разочарованы, что ваша любимая категория проиграла? Подождите несколько
месяцев. Если она важная, то в конце концов выйдет в победители.
Шаг 4. Генерация идей (инсайтов) (10–30 минут)

Предыдущие части этой активности были предназначены для сбора реакций
и ощущений. Теперь пришло время анализа. Его можно проводить в виде расслаб
ленной беседы в свободной форме. Записывайте ключевые идеи, спрашивайте
у людей, которые молчат, что они думают. Постарайтесь записать, что считают
ключевыми идеями участники, вместо того чтобы предлагать вашу собственную
интерпретацию.
Чтобы начать разговор, задавайте вопросы «почему». Почему выбранный кла-
стер наиболее важно улучшить? Почему текущая ситуация недостаточно хороша?
Почему что-то делается именно таким образом? С этого момента позвольте беседе
развиваться естественным образом. Сохраняйте расслабленный темп и фокусируй-
тесь на исследовании идей, не переходя к поиску решений.
Шаг 5. Цель ретроспективы (10–20 минут)

Настало время предложить варианты совершенствования. Попросите команду по-
думать над идеями улучшений в выбранной категории. Можно высказывать любые
идеи, какие только придут в голову: выполнить какое-либо действие, изменить
процесс, поведение или сделать что-то совершенно иное. Не пытайтесь высказывать
идеальные или окончательные решения; просто предлагайте эксперименты, которые
могли бы что-то улучшить. Это может помочь думать в терминах кругов и супа: чем
команда управляет и на что может повлиять (см. подраздел «Круги и суп» далее
в текущей главе).
Не вдавайтесь слишком глубоко в детали. Достаточно общего направления. Напри-
мер, если была выбрана категория «формирование пар», то идеи «чаще переключать
пары» и «переключать пары по расписанию» вполне подойдут.
Все это можно организовать как одновременный мозговой штурм или беседу
в свободной форме. Однако если людям нужен перерыв в разговоре, то попробуйте
применить технику, называемую «1 — 2 — 4 — Все». В этой технике люди начинают
обдумывать варианты молча, про себя. Они записывают по одному варианту на
стикер (или индексную карточку) и ограничиваются тремя самыми важными. Дайте
им на это три минуты.
Далее сгруппируйтесь по парам. Каждая должна выбрать из своих шести идей три
самые приоритетные. Дайте им еще три минуты, дальше сгруппируйте пары в груп-
пы по четыре и предложите им уменьшить количество своих идей до двух лучших
для четверки. Дайте им четыре минуты, затем каждая четверка должна поделиться
своими результатами со всей командой.
Группа может объединиться вокруг единственной хорошей идеи. В других случаях
может образоваться несколько конкурирующих предложений. Если это происходит,
то проведите еще одно точечное голосование, чтобы выбрать одно из предложений.
Это ваша цель ретроспективы: усовершенствование, над которым вся команда будет
работать до следующей ретроспективы. Ограничьтесь одним, чтобы команда могла
сфокусироваться на нем.
Определив цель ретроспективы, попросите кого-нибудь выступить доброволь-

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

Очень легко выйти с ретроспективы и подумать:
«Ну вот, все сделано, до следующей недели». Если ничего не меняется,
Убедитесь, что вы действительно выполняете то ретроспектива не сработала.
цель ретроспективы. Если ничего не меняется,
значит, ретроспектива не сработала.
Чтобы помочь команде с дальнейшими дей-
ствиями, сделайте цель ретроспективы види- См. также
мой. Если вы решили что-то сделать, то добавьте
Информативное рабочее про-
эти задачи к вашему плану. Если меняете свой
странство (глава 9)
процесс, то обновите вашу доску планирования,
чтобы визуализировать изменения. Если вы хо- Стендап-митинги (глава 9)
тите, чтобы люди изменили свое поведение, то
отслеживайте это с помощью большой наглядной диаграммы. Если меняете рабочее
соглашение, то обновите ваш плакат с рабочими соглашениями.
Сверяйтесь с целью ретроспективы ежедневно. Это можно делать во время стен-
дап-митингов, напоминая членам команды о необходимости довести дело до конца.
Вопросы
Несмотря на все мои усилия в качестве фасилитатора, наши ретроспективы всегда
опускаются до обвинений и споров. Что я могу сделать?
Приостановите ретроспективы и сосредо-
точьтесь на динамиках команды и установлении
психологической безопасности. Если это не сра- См. также
ботает, то вам может понадобиться помощь извне.
Рассмотрите возможность прибегнуть к помощи
специалиста по организационному развитию. Безопасность (глава 7)
Им может быть кто-то из сотрудников вашего
отдела кадров.
Мы придумываем хорошие цели ретроспектив, но потом ничего не происходит.
Что мы делаем неправильно?
Ваши идеи могут быть слишком масштабными. Помните: у вас только одна не-
деля, может быть, две, и у вас есть еще и другая работа. Попробуйте строить менее
грандиозные планы (возможно, на несколько часов работы) и работать над ними

ежедневно.
Другая возможная причина — в вашем
графике недостаточно резерва времени. При См. также
полной рабочей загрузке второстепенные
задачи, такие как совершенствование ваших
рабочих привычек, будут оставаться невы-
полненными. (Грустная ирония заключается в том, что усовершенствование ваших
рабочих привычек даст вам больше времени.)
И последнее: возможно, члены команды не чувствуют, что действительно имеют
право голоса в ретроспективе. Взгляните честно на то, как вы ее проводите. Возмож-
но, вы обманываете команду, вместо того чтобы способствовать ходу обсуждения?
Попробуйте предложить кому-нибудь другому побыть фасилитатором на следующей
ретроспективе.
Некоторые люди не высказываются на ретроспективе. Как я могу воодушевить
их на участие?
Возможно, они просто застенчивы. Никто не обязан участвовать постоянно.
Попробуйте начать следующую ретроспективу с какой-нибудь разминки и посмо-
трите, не поможет ли это.
Вместе с тем, возможно, им есть что сказать, но они не чувствуют себя в безопас-
ности. В этом случае сфокусируйтесь на создании безопасной атмосферы в команде.
Одна группа людей (например, тестировщики) оказывается в меньшинстве на
ретроспективах. Как мы можем удовлетворить и их потребности?
Со временем каждая большая проблема получает свою долю внимания. Прово-
дите ретроспективы несколько месяцев, прежде чем решить, какая группа оказалась
бесправной. В одной команде, с которой я работал, было несколько тестировщиков,
которые чувствовали, что их приоритеты игнорируются. Месяц спустя, после того
как команда разобралась с другой проблемой, проблема тестировщиков заняла первое
место в списках приоритетов каждого члена команды.
Если время не помогает, то вы можете провести взвешенное точечное голосова-
ние. Дайте людям, чьи специализации недостаточно представлены, больше голосов.
Наши ретроспективы всегда занимают очень много времени. Как нам их ускорить?
Фасилитатор вполне может решительно свернуть обсуждение и двигаться дальше.
Всегда можно оставить что-то на следующий раз. Если мозговой штурм или безмолв-
ное сопоставление длятся очень долго, то вы можете сказать примерно такие слова:
«Окей, у нас заканчивается время. У вас есть две минуты, чтобы записать финальные
идеи (или внести окончательные изменения), и потом мы двинемся дальше».
Тем не менее я предпочитаю поначалу позволять ретроспективам идти их есте-
ственным темпом, даже если они затягиваются. Это дает людям возможность при-
выкнуть к ходу ретроспективы, не переживая о времени.
Ретроспектива мало что нам дает. Можем ли мы проводить ее реже?
Если ваша команда компетентна в выбранной ею области и все идет гладко, то,
возможно, осталось не так много аспектов, которые можно улучшать. В этом случае
вы можете попытаться проводить ретроспективы реже, но все же продолжайте про-
водить их хотя бы ежемесячно.
Однако обычно это не тот случай. Более вероятно то, что ретроспектива просто
устарела. Попробуйте ее изменить. Поменяйте фасилитаторов и попробуйте новые
виды активности или сконцентрируйтесь на других темах.
Самая большая опасность в ретроспективе
заключается в том, что она может стать аре- См. также
ной для нападок, а не для конструктивного
решения проблем. Постарайтесь создать Безопасность (глава 7)
среду, в которой люди смогут делиться сво-
ими истинными мнениями. Не проводите ретроспективы, если у вас есть члены
команды, которые склонны срываться на окружающих, набрасываться на других
и обвинять их.
Когда ваша команда хорошо проводит ретроспективы:
zz ваша способность разрабатывать и поставлять ПО стабильно совершенствуется;
zz команда сближается и становится более сплоченной;
zz каждый специалист команды относится с уважением к проблемам, с которыми
сталкиваются другие специалисты;
zz члены команды честны и открыты в отношении успехов и неудач;
zz команда спокойно относится к изменениям.
Любой формат ретроспектив устаревает со временем. Меняйте его! Формат, пред-
ставленный в этой книге, — хорошая начальная точка, но как только вы его освоите,
начните экспериментировать с другими идеями. [Derby2006] — хороший источник
информации, который поможет изучить нюансы проведения ретроспектив; кроме
того, в нем также описываются разнообразные виды активности, которые вы можете
попробовать. Опробовав эти идеи, посетите https://www.tastycupcakes.org, чтобы узнать
еще больше информации.
Некоторые считают, что час — это слишком мало для хорошей ретроспективы,
и предпочитают 90 минут или даже два часа. Вы можете экспериментировать и с более
долгими, и с более короткими вариантами. Некоторым видам активности, в частности,
нужно больше времени. В ходе экспериментов проведите короткую «ретроспективу
ретроспективы», чтобы оценить, какой эксперимент нужно повторить, а какой — нет.
В главе 8 книги [Derby2006], Activities to Close the Retrospective, есть несколько идей.
Помимо апробации новых видов активностей, вы можете экспериментировать
с абсолютно другим подходом к улучшению процессов. Арло Бельши пробовал
непрерывный подход, когда люди в течение недели записывали свои наблюдения
и складывали записки в банку, а затем в конце недели просматривали их. У Вуди
Зуилла есть упражнение, которое он называет «выявить хорошее» (turn up the good):
в конце каждого дня проводить пятиминутную ретроспективу, выбирать что-то, что

прошло хорошо, и решать, как сделать так, чтобы этого было больше. Однако снача-
ла ознакомьтесь с обычными пульсирующими ретроспективами, чтобы вы смогли
сказать, улучшат ваши эксперименты что-то или нет.

Книга Project Retrospectives1 [Kerth2001] — это основной ресурс для ретроспективных
мероприятий, посвященных важным событиям.
В книге Agile Retrospectives: Making Good Teams Great [Derby2006] авторы про-
должают тему, начиная с того места, где остановился Керт, и обсуждают техники
проведения всех видов Agile-ретроспектив.
В статье The Effective Postfire Critique [Montagna1996] представлен интересный
взгляд на подход к ретроспективе в профессии, связанной с жизнью и смертью.
ДИНАМИКИ КОМАНДЫ Аудитория

Диана Ларсен Вся команда
Мы стабильно совершенствуем нашу способ-
ность работать вместе.
Способность вашей команды работать вместе формирует основу ее способности
разрабатывать и поставлять ПО. Вам нужны навыки взаимодействия, способность
делиться лидерскими ролями и понимание того, как команды эволюционируют со
временем. Все вместе эти навыки определяют динамики вашей команды.
Динамики команды — невидимые подводные течения, определяющие культуру
команды. С их помощью люди взаимодействуют и объединяются. Здоровые ди-
намики ведут к культуре достижений и благополучия. Нездоровые — к культуре
разочарований и дисфункции.
Каждый участник может по-своему влиять на эти динамики. Используйте идеи,
изложенные в этой практике, чтобы предложить способы, которые позволят членам
вашей команды улучшить способность сотрудничать.
Что формирует команду

Команда — не просто группа людей. В своей классической книге The Wisdom of Teams
Джон Катценбах и Дуглас Смит описывают шесть характеристик, отличающих
команды от других групп:
[Реальная команда] — это небольшое количество людей с взаимодополняющими
навыками, приверженных общей цели, целям производительности и подходу, за
которые они считают себя взаимно ответственными [Katzenback2015, chapt. 5]
(курсив мой).
The Wisdom of Teams
1
Керт Н. Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться
вперед.
Арло Бельши предлагает другую характеристику: совместная история. Группа

людей обретает ощущение себя как команды, проводя время за совместной работой.
Если вы следовали практикам, представленным в этой книге, то у вас есть все
предпосылки, необходимые для формирования отличной команды. Теперь вам нужно
развить в себе способность сотрудничать.
Развитие команды
В 1965-м Брюс Такман создал широко известную модель группового развития
[Tuckman1965]. В ней он описал четыре (позднее — пять) стадии группового раз-
вития: стадия формирования, штормовая (она же штормление, бурление, конфликт-
ная, конфронтация), стадия нормализации, стадия функционирования (исполнения)
и стадия расставания (Forming, Storming, Norming, Performing and Adjourning).
Эта модель показывает, как меняются степени товарищества и взаимодействия
с течением времени.
Идеальной модели не существует. Не вос-
принимайте модель Такмана как неизбежную, Не воспринимайте модель Такмана
чисто линейную прогрессию. Команды могут как неизбежную, чисто линейную
демонстрировать поведение любой из четырех прогрессию.
первых стадий. Изменения в составе, такие как
приход новых членов или потеря ценных товарищей по команде, могут привести
к тому, что команда вернется на более раннюю стадию. При изменениях в окружающей
обстановке, например переходе от работы в общем пространстве на удаленную работу
или наоборот, команда может регрессировать с более поздних стадий на более ранние.
Тем не менее модель Такмана дает полезные подсказки. Она позволяет вам понять
модели поведения ваших товарищей по команде, а также вы можете использовать ее
как основу для дискуссий о том, как наилучшим образом поддерживать друг друга.
Стадия формирования: новенький в классе

Команда формируется и начинает работать вместе. Отдельные участники могут
иметь ощущение, не сильно отличающееся от того, что испытывает новичок в классе:
они не стремятся к тому, чтобы работать с другими, но хотят чувствовать себя при-
нятыми (или, скорее, не исключенными) остальной частью группы. Члены команды
заняты сбором информации, которая позволит им ориентироваться на своей новой
территории и чувствовать себя в безопасности.
Вероятно, вы будете видеть реакции, такие как:
zz воодушевление, ожидания и оптимизм;
zz гордость за индивидуальные навыки;
zz обеспокоенность по поводу синдрома самозванца (страх показать себя недоста-
точно квалифицированным);
zz начальная, осторожная привязанность к команде;
zz подозрительность и беспокойство по поводу ожидаемой командной работы.
В процессе формирования команда может делать совсем мало работы, если вообще
будет делать что-то относящееся к ее целям и задачам. Это нормально. Хорошая но-
вость в том, что при поддержке большинство команд быстро проходят эту стадию.
Командам на стадии формирования могут быть полезны мудрость и опыт старших
членов команды, приобретенные в предыдущих командах, а также тех участников
команды, которые тяготеют к действиям по сплочению группы или коучингу в об-
ласти командного взаимодействия.
Поддержите ваших товарищей по команде
с помощью лидерства и четкого руководства. См. также
(Больше информации о лидерских ролях в ко-
манде будет дано позднее.) Начните с поиска Цель (глава 7)
способов, которые позволят членам команды Контекст (глава 7)
познакомиться с работой и друг с другом. Сфор-
Согласование (глава 7)
мируйте общее чувство единения сильных сторон
и личностей в команде. Подготовить устав ко-
манды, содержащий цель, контекст и согласование, — отличный способ сделать это.
Вам могут пригодиться и другие упражнения, помогающие узнать друг друга, такие
как «Упражнение на построение взаимоотношений в команде» (см. одноименную
врезку в главе 7).
Наряду с подготовкой устава найдите время и для того, чтобы обсудить и разра-
ботать план команды. Сфокусируйтесь на том, что может быть сделано; выполнение
каких-либо задач создаст ощущение первых успехов. (В подразделе «Ваша первая
неделя» главы 9 описывается, как начать работу.) Найдите и сообщите о ресурсах,
доступных команде, таких как информация, обучение и поддержка.
Признайтесь в ощущениях новизны, неопределенности, растерянности и раз-
дражения. Они естественны на этой стадии. Сессии подготовки устава должны
были помочь команде разобраться с зонами ответственности, однако проясните
любые оставшиеся вопросы, касающиеся рабочих ожиданий, границ полномочий
и ответственности, а также рабочих соглашений. Убедитесь, что люди знают, как их
команда сотрудничает с другими командами, работающими над тем же продуктом.
Командам, работающим в офисе, объясните, над чем работают соседние команды,
даже если это не имеет отношения к командной работе.
В течение стадии формирования членам команды нужны следующие навыки:
zz одноуровневая коммуникация и обратная связь;
zz групповое решение проблем;
zz управление межличностными конфликтами.
Убедитесь, что членам команды доступны коучинг, наставничество или обучение
этим навыкам по мере необходимости.
Штормовая стадия: подростковый возраст группы

Команда начинает трансформироваться из группы индивидуумов в единое целое.
Участники пока еще не вполне эффективны, однако начинают проявлять признаки
взаимопонимания.
На данной стадии команда сталкивается со спорными вопросами. Это время

турбулентности, совместного выбора направления, совместного принятия решений.
Вот почему Такман и другие назвали эту стадию штормовой.
Члены команды достигли определенной степени комфорта — достаточной,
чтобы начать оспаривать идеи друг друга. Они понимают друг друга достаточно
хорошо, чтобы знать, где возникают разногласия, и с готовностью выносят на об-
суждение расхождения во мнениях. Такая динамика может приводить к творческой
напряженности или деструктивным конфликтам в зависимости от того, как с ней
обращаться.
Ожидайте следующего поведения:
zz нежелание справляться с задачами или множество разных подходов к тому, как
это делать;
zz настороженное отношение к подходам с непрерывным совершенствованием;
zz резкие колебания отношения к команде и ее шансам на успех;
zz недовольство недостаточным прогрессом или другими членами команды;
zz споры между членами команды, даже когда они согласны по основному вопросу;
zz сомнения в мудрости людей, которые выбрали структуру команды;
zz подозрительное отношение к мотивам людей, которые назначили других членов
команды (эти подозрения могут быть конкретными или обобщенными и зачастую
больше базируются на предыдущем опыте, чем на текущей ситуации).
Поддерживайте вашу конфликтующую команду, отслеживая подрывные дей-
ствия, такие как оборонительное поведение, конкуренция между членами команды,
формирование группировок или выбор сторон и ревность. Ожидайте повышенной
напряженности и стресса.
Заметив такое поведение, будьте готовы
вмешаться и описать примеры, которые См. также
видите. Например: «Я заметил, что вокруг
подхода к дизайну было много конфликтов Безопасность (глава 7)
и люди начинают формировать группиров-
ки. Есть ли способ вернуться к более коллегиальному обсуждению?» Поддерживайте
прозрачность, откровенность и обратную связь и выявляйте типичные конфликтные
ситуации. Открыто обсуждайте роль конфликта и давления в творческом решении
проблем, включая взаимосвязь между психологической безопасностью и здоровым
конфликтом. Празднуйте маленькие достижения команды.
Когда вы заметите, что в команде участились случаи конфликтного поведения
(а это обычно бывает через несколько недель после ее формирования), соберите
команду для обсуждения темы доверия.
1. Подумайте о вашем прошлом опыте работы в команде любого типа. Когда вы
больше всего доверяли своим коллегам по команде? Расскажите историю об этом
времени. Какие условия способствовали формированию доверия?
2. Поразмышляйте о времени и ситуациях в вашей жизни, когда вы больше всего
заслуживали доверия. Что вы замечаете в себе такого, что является ценным для
вас? Как вы строили доверие с другими?
3. По вашему мнению, какой основной фактор создает и поддерживает доверие

в организациях? Какой основной фактор создает, питает и поддерживает дове-
рие среди членов команды?
4. Какие три желания вы бы загадали, чтобы сделать общение в вашей команде более
доверительным и здоровым?
Это трудная стадия, но она поможет членам команды набраться мудрости и за-
ложит фундамент для следующей стадии. Ожидайте появления ощущения растущей
сплоченности команды. По мере роста сплоченности продолжайте давать возмож-
ность всем членам команды выражать разнообразные мнения, вместо того чтобы
заставлять их молчать ради фальшивой гармонии (см. пункт «Не уклоняйтесь от
конфликта» главы 7).
Стадия нормализации: мы — № 1
Члены команды объединились в сплоченную группу. Они нашли комфортный ра-
бочий темп и наслаждаются сотрудничеством. Они идентифицируют себя как часть
команды. Фактически они могут идентифицировать себя настолько близкими и на-
столько наслаждаться совместной работой, что в рабочем пространстве появляются
символы принадлежности. Вы можете замечать одинаковые или очень похожие
футболки, чашки с названием команды или одинаковые наклейки на компьютерах.
Виртуальные команды могут завести традицию дней «все в кепках» или дней «га-
вайских рубашек».
Команды на стадии нормализации согласовали структуру и рабочие отношения.
Взаимодействие позволяет развивать неформальные, неявные нормы поведения, до-
полняющие командные рабочие соглашения. Люди вне команды могут заметить ее
«командность» и говорить об этом. Некоторые могут завидовать этому — особенно
если члены команды начинают хвастаться своими успехами или объявлять свою
команду «лучшей».
Их гордость оправданна. Команды, находящиеся на стадии нормализации, успеш-
но и стабильно двигаются в направлении к своей цели. Члены команды сталкиваются
с рисками и успешно сотрудничают. Вы увидите следующее поведение:
zz новая возможность конструктивного выражения критики;
zz принятие и положительная оценка различий среди членов команды;
zz чувство облегчения от того, что все это может хорошо работать;
zz большее дружелюбие;
zz люди чаще делятся личными историями и откровениями;
zz открытое обсуждение динамик команды;
zz желание обновлять рабочие соглашения и пересматривать вопросы границ с дру-
гими командами.
Как вам воодушевлять вашу команду на стадии нормализации? Выходите за
пределы границ команды и расширяйте кругозор участников. Способствуйте кон-
тактам с заказчиками и поставщиками. (Выезды за пределы офиса!) Если работа
команды связана с работой других команд, то просите провести обучение в кросс-
командных группах.
Кроме того, повышайте сплоченность команды и расширяйте свои горизонты.

Ищите возможности для членов команды делиться опытом, например, совместно
участвовать в волонтерских проектах или презентациях для остальной части орга-
низации. Убедитесь, что эти возможности подходят всем членам команды, чтобы
ваши добрые намерения не создали группировки «своих» и «чужих».
В навыки, необходимые нормализующимся командам, входят:
zz обратная связь и умение слушать;
zz процессы группового принятия решений;
zz понимание точки зрения организации на работу команды.
Книги, такие как What Did You Say? The Art of Giving and Receiving Feedback
[Seashore2013] и Facilitators’ Guide to Participatory Decision-Making1 [Kaner1998], по-
могут команде обрести первые два навыка, а привлечение всей команды к общению
с руководителями организации позволит наработать третий.
Остерегайтесь попыток сохранить гармонию, избегая конфликтов. Не желая
возвращаться на штормовую стадию, члены команды могут демонстрировать груп-
повое мышление: форму ложной гармонии, когда члены команды избегают проявлять
несогласие друг с другом, даже если оно
оправданно. Groupthink: Psychological Studies
Остерегайтесь попыток сохранить
of Policy Decisions and Fiascoes [Janis1982] — гармонию, избегая конфликтов.
классическая книга, исследующая этот фе-
номен.
Обсудите подходы к принятию команд-
ных решений, когда увидите симптомы См. также
группового мышления. Одним из призна-
ков является то, что члены команды удер- Безопасность (глава 7)
живаются от критических замечаний ради
сохранения мира, особенно если они высказывают критику позже, когда уже слишком
поздно менять направление. Попросите членов команды критиковать и сделайте так,
чтобы они чувствовали, что не соглашаться — безопасно.
Один из способов избежать группового мышления — начинать дискуссии с опре-
деления желаемого результата. Работайте в направлении результата, вместо того
чтобы отворачиваться от проблемы. Экспериментируйте со следующими базовыми
правилами для командных решений:
zz договоритесь, что каждый член команды будет действовать как ключевой оцен-
щик;
zz поощряйте открытые вопросы, а не просто заявления позиции;
zz примите процесс принятия решений, который содержит определение хотя бы
трех жизнеспособных вариантов, прежде чем выбор будет сделан;
zz назначайте оппонента для поиска контраргументов;
zz разбейте команды на маленькие группы для независимых дискуссий;
zz запланируйте встречу «второго шанса», на которой можно пересмотреть решение.
1
Кейнер С. Руководство фасилитатора. Как привести группу к принятию совместного решения.
Стадия функционирования (исполнения): синергия команды

Фокус команды переключился на выполнение работы. Эффективность и произво-
дительность входят в распорядок дня. Члены команды связаны своей частью работы
с остальной организацией. Они следуют знакомым, установленным процедурам при-
нятия решений, устранения проблем и поддержания атмосферы совместной работы.
Сейчас команда выполняет много работы.
Команды на стадии функционирования превосходят ожидания. Они демон-
стрируют бо́льшую автономность, достигают более высоких результатов и развили
способность принимать быстрые и высококачественные решения. Члены команды
совместно добиваются бо́льших результатов, чем можно было бы ожидать при про-
стом суммировании их отдельных усилий. Члены команды продолжают демонстри-
ровать лояльность и взаимоподдержку, выражая при этом меньше эмоций по поводу
сотрудничества и задач, чем на более ранних стадиях.
Вы увидите следующее поведение:
zz глубокое понимание личных и командных процессов;
zz снижение потребности в фасилитативном коучинге. Такие коучи тратят больше
времени на поддержание связей и урегулирование вопросов с остальной частью
организации, чем на внутренние потребности команды;
zz сотрудничество с учетом понимания сильных и слабых сторон членов команды;
zz замечания наподобие «Мне не терпится поработать с этой командой», «Не могу
дождаться, пока вернусь на работу», «Это моя самая лучшая работа» и «Как мы
можем добиться еще большего успеха?»;
zz уверенность друг в друге и вера в то, что каждый член команды вносит свой вклад
в достижение целей команды;
zz предотвращение или проработка проблем и деструктивных конфликтов.
Люди, работавшие в командах, находящихся на стадии функционирования, на-
всегда запоминают этот свой опыт. У них есть истории об ощущении тесной связи
со своими коллегами. Если команда проводит много времени на стадии функциони-
рования, то члены команды могут очень эмоционально относиться к потенциальной
возможности расформирования или реорганизации команды.
Команды на стадии функционирования находятся на пике командного развития,
однако им все еще необходимо учиться успешно работать с людьми, не входящими
в команду. Вдобавок они не застрахованы от возвращения на предыдущие стадии.
Изменения в составе команды могут нарушить равновесие, равно как и значитель-
ные организационные изменения и нарушения установленных рабочих привычек.
И всегда есть возможности для дальнейшего совершенствования. Продолжайте
учиться, расти и развиваться.
Стадия расставания: разделение и движение дальше

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

свершениям.
Коммуникация, сотрудничество и взаимодействие

Коммуникация, сотрудничество и взаимодействие членов команды формируют
сплоченность команды. Этот обмен влияет на способность команды работать эф-
фективно или нет.
Рассмотрите мою модель командной коммуникации, показывающую, как эффек-
тивное командное общение требует развития взаимосвязанных и взаимозависимых
серий коммуникативных навыков (рис. 11.1).
Рис. 11.1. Модель командной коммуникации Ларсен
Модель начинается с развития доверия, которое позволит начать. Каждый но-

вый навык продвигает команду вперед, одновременно укрепляя следующие за ним
вспомогательные навыки.
Начните с твердой основы доверия

Когда вы формируете свою команду, сконцентри-
руйтесь на том, чтобы помочь ее членам обрести См. также
доверие друг к другу. Не нужно глубокого дове-
рия, достаточно просто согласиться работать вместе Согласование (глава 7)
и посвятить себя работе. Помогут договоренности, Безопасность (глава 7)
зафиксированные в уставе, и акцент на психологи-
ческую безопасность.
Поддержите растущее доверие

с помощью тройного обязательства
Основываясь на доверии, ваша команда начнет
исследовать тройную природу командного обяза- См. также
тельства:
zz приверженность цели команды;
zz приверженность благополучию друг друга;
zz приверженность благополучию команды в целом.
Занесение в устав цели и соглашений поможет в построении этих обязательств.
По мере укрепления приверженности доверие будет продолжать расти. Вместе с ним
будет расти и чувство психологической безопасности.
Когда приверженность и доверие начнут улучшать психологическую безопас-
ность, наступает подходящее время для изучения движущих сил в команде. Какой бы
равноправной ни была ваша команда, расстановка сил всегда существует. Это часть
человеческой природы. Если не обращать на нее внимания или не решать, то рас-
становка сил может стать разрушительной. Лучше держать ее на виду, чтобы команда
могла попытаться ее выровнять.
Источники расстановки сил — в индивидуальном восприятии влияния друг на
друга, способности добиваться результата и предпочтений в отношениях. Вынесите
все это на открытое обсуждение, обсудив расстановку сил, имеющуюся в команде, и ее
влияние на сотрудничество. Обсудите, как силы команды и отдельных ее участников
могут быть использованы на благо всей команды.
Разумные конфликты с обратной связью

Чем больше членов команды ощущают поддержку друг друга, тем больше адаптиру-
ются к конфликтам. Вместо позиции «ты против меня» люди начинают подходить
к конфликтам с позиции «мы против проблемы». Сфокусируйтесь на развитии
способности членов команды давать и получать обратную связь, как описано в пун-
кте «Научитесь давать и получать обратную связь» главы 7. Подходите к обратной
связи, преследуя такие цели:
zz обратная связь, которую мы даем и получаем, — конструктивная и полезная;
zz наша обратная связь — бережная и уважительная;
zz обратная связь — неотъемлемая часть нашей работы;
zz никто не удивляется обратной связи; мы ждем четко выраженного согласия, пре-
жде чем давать обратную связь;
zz мы даем обратную связь, чтобы поощрить какое-либо поведение, а также чтобы
предотвратить или изменить поведение.
Обратная связь между членами команды, находящимися на одном уровне, по-
могает справляться с межличностными конфликтами, пока они еще малы. Неудов-
летворенное скрытое недовольство может перерасти в огромное недоверие. Навыки,
которые члены команды развивают для обратной связи внутри команды, помогут
им и в более крупных конфликтах с внешними силами.
Искра креативности и инновационности

Что такое инновация команды, если не столкновение идей, порождающее новый
потенциал? Поддержание здоровых рабочих отношений в момент яростных споров —
это командный навык. Он возникает из способности вступать в конфликты и пере-
направлять их в сторону желаемого результата. Он стимулирует увеличение инно-
вационности и креативности. Способность команды решать проблемы резко
возрастает.
Развивайте креативность команды, пред-
лагая обучающие задачи и игровой подход. См. также
Встройте их в ежедневную рутину команды.
Используйте резерв времени для изучения Ретроспективы (глава 11)
новых технологий, как описано в пункте «По-
свящать время исследованиям и экспериментам» главы 9. Экспериментируйте
с новыми идеями во время ретроспектив. Создайте условия для бесполезных причуд
и проявления изобретательности (научите друг друга жонглированию!).
Поддержание высокой производительности

Когда навыки сотрудничества и коммуникации встречаются с навыками, ориенти-
рованными на решение конкретных задач, высокая производительность становится
чем-то обычным. Ваша задача — поддерживать эту производительность. Избегайте
самодовольства. Как команда, продолжайте оттачивать ваши навыки, которые
позволяют строить доверие, быть преданным работе и друг другу, предоставлять
обратную связь и побуждать к креативности. Ищите возможности для повышения
стрессоустойчивости и дальнейшего совершенствования.
Совместное лидерство
Мэри Паркер Фоллетт, эксперт в менеджменте, также известная как «мать современ-
ного менеджмента», была пионером в области организационной теории и поведения.
Рассуждая о роли лидерства, она писала:
«Мне кажется, несмотря на то что власть обычно означает власть “над” (власть
одного человека или группы над другим человеком или группой), можно развить
концепцию власти “с”: совместно развиваемой власти, действующей совместно,
а не принудительно… И лидер, и его последователи следуют за незримым лиде-
ром — общей целью» [Graham1995] (с. 103, 172).
Мэри Паркер Фоллетт
Эффективные Agile-команды развивают

«власть с» среди членов команды. Они делят См. также
между собой лидерство (см. врезку «Самоорга-
низующиеся команды» в главе 7). Благодаря Вся команда (глава 7)
этому они получают максимум от своего со-
трудничества и навыков всей команды.
Мэри Паркер Фоллетт описывала «закон ситуации», в котором выступала за

следование за человеком, лучше всего знающим ситуацию. Именно так должны
функционировать Agile-команды. Это значит, что любой член команды может быть
выдвинут на роль лидера. Каждый может быть лидером в одних ситуациях и под-
чиняться коллеге-лидеру — в других.
Члены команды могут играть разнообразные лидерские роли, как показано
в табл. 11.11. Люди могут играть множество ролей, а также переключаться между
ними по желанию, и несколько человек могут выступать в одной и той же роли.
Важный момент — это охват. Командам необходимо, чтобы ее члены занимали все
эти роли.
Таблица 11.1. Лидерские роли
Ориентированный Ориентированный
на выполнение задач на сотрудничество
Направление Пионер, инструктор Дипломат, инфлюэнсер,

последователь
Наставление Комментатор, координатор Промоутер, миротворец
Оценка Критик, привратник, оппонент Рецензент, наблюдатель
zz Пионеры (направление, ориентированное на выполнение задач) задают вопросы

и ищут данные. Они исследуют, что будет дальше, ищут новые подходы и при-
носят в команду новые идеи.
zz Инструкторы (направление, ориентированное на выполнение задач) отвечают на
вопросы, предоставляют данные и обучают остальных навыкам, ориентированным
на решение задач. Они связывают команду с источниками информации.
zz Дипломаты (направление, ориентированное на сотрудничество) связывают
команду с людьми и группами за ее пределами, действуют как связующее звено
и представляют команду на внешних совещаниях.
zz Инфлюэнсеры (направление, ориентированное на сотрудничество) поощряют ко-
манду к созданию устава, заключению рабочих соглашений и другим действиям,
способствующим построению командной культуры.
zz Последователи (направление, ориентированное на сотрудничество) обеспечива-
ют поддержку и воодушевление. Они отступают, позволяя другим взять на себя
инициативу там, где дело касается их сильной стороны или ее развития. Они
подчиняются командным рабочим соглашениям.
zz Комментаторы (наставление, ориентированное на выполнение задач) объясняют
и анализируют данные. Они добавляют информацию в контекст.
1
За исключением дипломатов, эти роли были разработаны Дианой Ларсен и Эстер Дерби, осно-
вываясь на [Benne1948].
zz Координаторы (наставление, ориентированное на выполнение задач) связывают

воедино направления работы таким образом, чтобы это имело смысл. Они объ-
единяют и интегрируют данные и согласовывают действия команды с задачами.
zz Промоутеры (наставление, ориентированное на сотрудничество) фокусируются
на равноправном участии членов команды. Они дают каждому шанс поучаствовать
и помочь. Они воодушевляют самых тихих членов команды высказывать свое
мнение по вопросам, влияющим на всю команду.
zz Миротворцы (наставление, ориентированное на сотрудничество) заняты поиском
общих точек соприкосновения. Они ищут гармонию, консенсус и компромисс,
если это необходимо. Они могут урегулировать споры, когда членам команды
трудно сделать это самостоятельно.
zz Критики (оценка, ориентированная на решение задач) оценивают и анализируют
соответствующие данные, ищут риски и слабые места в командном подходе.
zz Привратники (оценка, ориентированная на решение задач) способствуют со-
хранению рабочей дисциплины и поддерживают рабочие соглашения, а также
оберегают границы команды, предотвращая вмешательство в ее работу.
zz Оппоненты (оценка, ориентированная на решение задач) защищают команду от
группового мышления, преднамеренно ища альтернативные точки зрения и вы-
ступая против привычного мышления. Они также проверяют решения команды
на соответствие командным ценностям и принципам.
zz Рецензенты (оценка, ориентированная на сотрудничество) гарантируют, что
команда соответствует критериям приемлемости и реагирует на потребности
zz Наблюдатели (оценка, ориентированная на сотрудничество) следят за тем, как
вся команда работает вместе. (Хорошо или плохо работают члены команды?)
Они оберегают психологическую безопасность команды и способствуют укреп
лению здоровых рабочих взаимоотношений между ее членами.
То, что в этот список роль последователя входит
как лидерская, может показаться странным, однако Последователь — особенно
активное подчинение лидерству других помогает важная роль для тех
членам команды учиться делиться руководящими людей, от кого ожидают
обязанностями. Это особенно важная роль для тех лидерства.
людей, от кого ожидают лидерства, таких как старшие
члены команды.
Команды, разделяющие друг с другом лидерство в соответствии с этими ролями,
можно назвать командами лидеров (leaderful teams). Чтобы стать такой командой,
обсудите вместе эти лидерские роли. Лучше всего делать это, когда вы замечаете
неравномерность участия членов команды или чрезмерную зависимость от одного
человека при принятии решений. Покажите всем список ролей и задайте следующие
вопросы:
zz Сколько лидерских ролей каждый из членов команды естественным образом
берет на себя?
zz Не перегружен ли кто-нибудь лидерскими ролями? Или выполняет роль, которая

ему не нравится?
zz Какой из этих ролей нужно несколько человек? (Например, роль оппонента лучше
распределять между несколькими членами команды.)
zz Какой роли не хватает в нашей команде? Каковы последствия отсутствия кого-
либо в этой роли?
zz Как мы можем заполнить недостающие роли? Кто хочет попрактиковаться в этом
аспекте руководства?
zz Что еще мы заметили касательно этих ролей?
Сфокусируйте членов команды на выборе способа, с помощью которого они бу-
дут обеспечивать эффективное сотрудничество, с учетом охвата лидерских ролей.
Будьте готовы к созданию новых рабочих соглашений в результате этого обсуждения.
Некоторые члены команды могут быть оппонентами от природы, но если они
будут играть эту роль постоянно, то остальная часть команды может со временем
попасть в ловушку обесценивания их комментариев. «О, не обращайте внимания.
Ли всегда ищет самые мрачные, самые пессимистичные стороны во всем!» Необхо-
димо обеспечить возможность передавать роль оппонента разным членам команды.
Так она будет оставаться эффективной.
Токсичное поведение
Токсичное поведение — это любое поведение, которое создает нездоровую и небез-
опасную атмосферу, снижает динамики команды или нарушает способность команды
достичь ее цели.
Если член команды демонстрирует токсичное поведение, то начните с напоми-
нания Первой директивы ретроспективы: «Независимо от того, что мы обнаружим,
мы должны понимать и искренне верить, что каждый делал свою работу наилучшим
образом, в соответствии с тем, что было известно на тот момент, его или ее навыками
и возможностями, доступными ресурсами и сложившейся ситуацией» [Kerth2001]
(гл. 1). Предполагайте, что человек делает все наилучшим из возможных для него
способов.
Сначала ищите проблемы, связанные с давлением окружающей среды. Например,
кто-то из членов команды не высыпается, поскольку у него родился ребенок. Или но-
вый член команды может один отвечать за жизненно важную систему, с которой еще
не очень хорошо знаком. Все вместе члены команды могут внести коррективы, кото-
рые помогут людям улучшить свое поведение. Например, договорившись перенести
утренние стендапы, чтобы молодой родитель мог приходить попозже, или разделив
ответственность за функционирование важной системы с кем-то еще.
Следующий шаг — давать обратную связь данному человеку. Используйте про-
цесс, описанный в пункте «Научитесь давать и получать обратную связь» главы 7,
чтобы описать последствия такого поведения и попросить изменить его. Очень часто
этого оказывается достаточно. Люди просто не осознавали, как их поведение влияет
на команду, и будут вести себя иначе.
Иногда команды могут называть коллег

токсичными, хотя те на самом деле не де- Будьте осторожны, чтобы
лают ничего плохого. Это легко может ошибочно не посчитать оппонентов
случиться с людьми, которые часто бе- токсичными.
рут на себя лидерскую роль оппонента.
Они не соглашаются с идеями остальной команды или видят риск или препят-
ствие, не замеченные другими, и не дают идее ход. Будьте осторожны, чтобы оши-
бочно не посчитать оппонентов токсичными. Они позволяют командам избежать
группового мышления. Однако может иметь смысл обсудить возможность ротации
этой роли.
Если человек действительно демон-
стрирует токсичное поведение, то может См. также
игнорировать замечания и обратную связь
от команды или отказываться подстраи- Безопасность (глава 7)
ваться под потребности психологической
безопасности команды. Если это случается, то такие люди перестают быть полезны
команде. Иногда это просто личностное несовпадение, и им будет хорошо в другой
команде.
В этот момент приходит время вмешаться вашему руководителю или тому, кто
отвечает за назначение людей в команду. Объясните ситуацию. Хорошие руково-
дители понимают, что продуктивность каждого члена команды зависит от всех
остальных участников. Эффективный лидер вступится, чтобы помочь команде.
Чтобы он мог сделать это, члены команды должны проинформировать его о том,
что им нужно, а также о тех шагах, которые они уже предприняли, чтобы изменить
поведение.
Некоторые руководители могут сопротивляться удалению человека из команды,
особенно если видят в этом человеке «суперзвезду». Вместо этого они могут пред-
лагать команде приспособиться к его поведению. К сожалению, это вредит произ-
водительности команды в целом. По иронии судьбы это может еще больше усилить
позиции «суперзвезды», так как этот человек подавляет окружающих.
В этой ситуации вы можете только решить сами для себя, стоит ли терпеть ток-
сичное поведение ради преимуществ, которые дает участие в этой команде. Если нет,
то лучшим вариантом для вас будет перейти в другую команду или организацию.
Вопросы
Разве не важно команде иметь одного лидера? Как это работает с командами лидеров?
Наличие единственного лидера позволяет упростить комплексную проблему, но
этот способ не так уж и удобен для самого человека в этой роли. Это также противо-
речит Agile-идеалу коллективного владения (см. врезку «Коллективное владение»
в главе 9). Вся команда несет ответственность. Нет козла отпущения, который
возьмет на себя ответственность, если все пойдет не так, или того, кто получит все
награды, если все будет хорошо, поскольку успех и провал — результат сложного
взаимодействия множества участников и факторов. Вклад каждого члена команды
критически важен.
Это не просто абстрактная философия. Команды лидеров лучше делают свою

работу и быстрее становятся высокопроизводительными. Совместное лидерство
способствует формированию более сильных команд.
Что, если у меня нет навыков, которые позволят улучшить динамики команды?
Если вам некомфортно работать над навыками командной работы, это нормально.
Вы все же можете помочь. Следите за коллегами, которые берут на себя лидерские
роли, ориентированные на взаимодействие. Делайте все, что поддержит их усилия.
Если в вашей команде нет людей, желающих взять на себя эти роли, то поговорите
с вашим руководителем или спонсором о предоставлении коуча или другого члена
команды, имеющего опыт в области динамик команды (см. подраздел «Навыки
коучинга» главы 7).
Чтобы эти идеи стали реальностью, ваша команда
и ваша организация должны быть к этому готовы.
Члены команды должны быть полны энергии См. также
и мотивированы работать вместе. Ничего не по-
лучится, если людям будет интересно только
смотреть на стрелки часов и ждать, когда им Вся команда (глава 7)
скажут, что делать. Кроме того, ваша организация Командная комната (глава 7)
должна инвестировать в командную работу. Сюда
Менеджмент (глава 10)
входит создание команды, командного помеще-
ния и подхода к менеджменту, соответствующего
принципам Agile.
Когда у вашей команды здоровые динамики:
zz члены команды с удовольствием приходят на работу;
zz они говорят, что могут положиться на своих товарищей по команде при выпол-
нении своих обязательств, а если нет, то могут сказать об этом;
zz члены команды верят, что каждый в команде стремится к достижению ее цели;
zz они знают сильные стороны коллег и относятся с пониманием к ограничениям
в возможностях друг друга;
zz члены команды успешно работают вместе и празднуют прогресс и успехи.
Материалы этой практики содержат лишь крошечную часть имеющихся ценных зна-
ний о командах, их динамиках, управлении конфликтами, лидерстве и многих других
вопросах, влияющих на эффективность команд. Больше информации можно найти
в источниках, указанных в ссылках и в подразделе «Литература для дополнительного
чтения». И даже это — капля в море. Спросите у наставника, что он может пореко-
мендовать. Продолжайте учиться и экспериментировать. Это дорога длиною в жизнь.

Кит Сойер сделал карьеру на изучении креативности, инновационности и импро-
визации и их корней в эффективном сотрудничестве. В Group Genius: The Creative
Power of Collaboration [Sawyer2017] он предлагает познавательные истории и идеи.
Роджер Ниренберг написал мемуары и руководство для лидеров: Maestro: A Sur
prising Story about Leading by Listening [Nierenberg2009]. Эта книга внесла свой вклад
в нестандартные способы размышлений о лидерстве. У автора также есть сайт с ви-
део, в которых демонстрируются его техники: http://www.musicparadigm.com/videos/.
The Wisdom of Teams: Creating the High-Performance Organization [Katzen
back2015] — классическая, базовая книга о высокопроизводительных командах, их
характеристиках и среде, способствующей их процветанию.
Shared Leadership: Reframing the Hows and Whys of Leadership [Pearce2002] —
сборник лучших идей о многолидерских командах и организациях. Он может быть
сложным для чтения, но его стоит изучить, чтобы расширить свои представления
о том, кто такой и что такое лидер.
УСТРАНЕНИЕ ПРЕПЯТСТВИЙ Аудитория

Диана Ларсен Вся команда
Мы решаем проблемы, которые замедляют нашу
работу.
Препятствия. Преграды. Затруднения, барьеры, помехи, загвоздки, угрожающие
риски (также известные как надвигающиеся препятствия). Все эти слова описывают
проблемы, которые могут подорвать производительность команды. Они могут быть
очевидными: «Сеть не работает». Они могут быть неявными: «Мы неправильно по-
няли потребности заказчика и должны начать все сначала». А могут быть и такими:
«Мы застряли!»
Есть препятствия, которые на первый взгляд не видны. Есть такие, которые вырас-
тают из сложных ситуаций. Одни препятствия являются симптомами более крупных
проблем, а другие имеют не одну причину и похожи на многоголовую гидру. Неко-
торые препятствия являют собой непреодолимую силу, наподобие плохой погоды,
и отягощены стоящими за ними культурой и традициями. А некоторые, наиболее
ценные, находятся под вашим контролем и легкоразрешимы.
Независимо от источника препятствия мешают команде и могут даже полностью
остановить ее прогресс. Устранение препятствий возвращает команду в нужное русло.
Некоторые члены команды ожидают, что
люди с лидерскими званиями возьмут на себя Устранение препятствий —
устранение препятствий, но устранение пре- это ответственность команды.
пятствий — это ответственность команды.
Не ждите, что ваш коуч или руководитель заметят и разберутся с препятствиями,

мешающими команде. Позаботьтесь об этом сами.
Точно так же некоторые команды создают до-
ски со списком препятствий или рисков, чтобы См. также
отслеживать все, что стоит на их пути. Я не ре-
комендую так делать. Вместо этого устраняйте Стендап-митинги (глава 9)
препятствия, как только заметите их. Вынесите Ретроспективы (глава 11)
их на обсуждение на следующем стендапе, ретро- Планирование задач (глава 9)
спективе или сессии планирования задач и решите,
как будете преодолевать каждое из них.
Выявление препятствий
Чтобы устранить препятствия, вы должны сначала их выявить. Задайте следующие
вопросы:
zz Что нас замедляет?
zz Что нам нужно из того, чего у нас еще нет?
zz Где бы мы могли продемонстрировать больший прогресс, если бы не ...?
zz Что нас останавливает или удерживает от ...?
zz Что постоянно способствует появлению дефектов?
zz Какие навыки нам нужны, которых у нас еще нет?
Если ваша команда не может добиться прогресса, но, кажется, на ее пути нет
никаких препятствий, то положитесь на список Уильяма Ларсена под названием
TRIPE (Tools, Resources, Interactions, Processes and Environment): инструменты,
ресурсы, взаимодействия, процессы и среда [Larsen2021]. Добавьте каждую из ка-
тегорий в предыдущий список: какие инструменты нас замедляют? Какие ресурсы
нас замедляют? Какие взаимодействия нас замедляют? И т. д.
Круги и суп
Что вам делать с препятствиями? Подумайте о них в терминах кругов и супа. Каждую
команду окружает сравнительно небольшой круг вещей, которые она может контро-
лировать, и более широкий круг вещей, на которые она только влияет. За границами
этих кругов находится суп: неизменные факты существования вашей команды. Суп
нельзя изменить, и на него нельзя оказать какого-либо влияния. Все, что вы можете
сделать, — это изменить реакцию на него вашей команды.
Следующий вид активности, основанный на [Larsen2010], использует эту идею,
чтобы помочь команде решить, как реагировать на препятствия.
Шаг 1. Используйте одновременный мозговой штурм (см. пункт «Работайте одно-
временно» главы 7) для выявления действий, которые улучшат способность вашей
команды выполнять свою работу. Запишите каждый пункт на отдельный стикер,
физический или виртуальный.
Шаг 2. Нарисуйте три концентрических круга на доске (рис. 11.2). Оставьте место
для стикеров в каждом круге.
Рис. 11.2. Круги и суп
Шаг 3. Работая одновременно, распределите стикеры по категориям следующим

образом:
zz команда контролирует — команда может самостоятельно выполнять эти действия;
zz команда влияет — команда может рекомендовать изменения или убедить другую
сторону помочь;
zz суп — команда не контролирует и имеет слабую возможность повлиять.
Шаг 4. Выберите пункт из одного из кругов, на-
чиная с внутреннего, и создайте для него задачи. См. также
Повторите при необходимости.
Всегда заканчивайте вопросом: «Что еще мы мо- Планирование задач
(глава 9)
жем сделать, чтобы предотвратить появление этого
препятствия на нашем пути в будущем?»
Контроль: прямые действия

Во время ежедневного стендапа двое участников команды сообщили о препятствии:
«Нам нужна помощь. Бизнес-правила в этой истории для нас выглядят бессмыс-
ленными». Другой член команды сказал: «Я видел это раньше». После встречи
несколько человек, знакомых с проблемой, собрались вместе, чтобы прояснить то,
что непонятно. Они также обсудили способы, позволяющие избежать подобного
недопонимания в будущем.
Во время короткой ретроспективы перед перерывом команда группового про-
граммирования, работающая удаленно, обсуждала недавно появившийся фоновый
шум. Он сильно мешал слышать друг друга. Потом один из членов команды вступил
в разговор: «Это мой вентилятор! Я не заметил, что он направлен на мой микрофон».
Он повернул вентилятор, и мешающий фоновый шум прекратился.
Когда решение, устраняющее препятствия, находится под контролем вашей ко-
манды, предпримите прямые действия для его устранения.
Влияние: убедить или рекомендовать

Во время еженедельной ретроспективы команда перечислила неясные бизнес-прави-
ла в качестве текущего препятствия. Затем она записала конкретные примеры того,
когда похожие проблемы случались в прошлом, и сформулировала решение «улучшить
доступ к экспертам в предметной области» как наиболее предпочтительное. Один из
старших инженеров вызвался показать примеры одному из ключевых стейкхолдеров
команды, чтобы они вместе смогли найти решение.
Когда ваша команда не может контролировать решение
по устранению препятствия, а ваши стейкхолдеры могут, См. также
попросите их помочь вам.
Эффективность влияющих действий зависит от сте- Контекст (глава 7)
пени понимания ваших стейкхолдеров. Если вы внесли
контекст в ваш устав, то у вас должна быть контекстная диаграмма, показывающая
группы ваших стейкхолдеров (см. пункт «Границы и взаимодействия» главы 7).
Напомним: стейкхолдеры вашей команды — это все, кто влияет на ее работу, или те,
на кого влияет работа команды.
Чтобы лучше понимать, как влиять на ваших стейкхолдеров, создайте таблицу
обязательств стейкхолдеров (рис. 11.3)1.
Рис. 11.3. Диаграмма обязательств стейкхолдеров
Каждая строка таблицы представляет обязательство стейкхолдеров по оказанию

помощи команде.
zz «Прекратить это» — стейкхолдер попытается остановить вас.
zz «Позволить этому произойти» — стейкхолдер не будет вам помогать, но и мешать
тоже не будет.
zz «Помочь этому произойти» — стейкхолдер будет помогать, если вы возьмете на
себя инициативу.
zz «Сделать так, чтобы это произошло» — стейкхолдер будет активно продвигать
эти действия.
1
Диаграмма обязательств стейкхолдеров взята и адаптирована из [Beckhard1992].
Используйте таблицу следующим образом.

1. Ключевые стейкхолдеры. Перечислите имена ваших ключевых стейкхолдеров
в первой колонке. Если стейкхолдер — это группа людей, то используйте в каче-
стве ее названия имя вашего контактного лица в этой группе.
2. Требуемое обязательство. Обсудите степень обязательства, которое вашей команде
необходимо получить от каждого из стейкхолдеров. Впишите «0» (для «целевого
статуса») в соответствующей колонке.
3. Текущий статус. Определите степень обязательства каждого стейкхолдера по
устранению препятствия. Это может потребовать участия членов команды, об-
ладающих навыками дипломатии. Поставьте «Х» в соответствующей колонке.
4. Определить потребности. Когда Х (текущий статус) находится слева от 0 (требу-
емое обязательство), нарисуйте стрелку слева направо, чтобы их соединить. Таким
образом команда узнает, кого они должны переместить. Если изменений полу-
чается много, то определите, с кем из стейкхолдеров работать в первую очередь.
5. Планировать стратегию. Всей командой решите, как вы будете влиять на каж-
дого стейкхолдера, чтобы обеспечить необходимый вам уровень обязательства.
Когда у вас будут нужные вам обязательства, вы можете просить стейкхолдеров,
давших обязательства «Помочь этому произойти» и «Сделать так, чтобы это про-
изошло», помочь вам с устранением препятствия.
Суп: измените вашу реакцию

Проведя ежегодную оценку эффективности, команда с разочарованием узнала,
что некоторые люди получили более высокий балл, чем другие, и соответственно
более высокий бонус. Члены команды были расстроены, поскольку они были очень
эффективной командой и каждый внес свой вклад в ее успех. Все попытки сделать
ситуацию более справедливой провалились: оценка эффективности по баллам была
общей политикой компании. Поэтому команда согласилась, что в следующем году
тот, кто получит самый высокий бонус, устраивает вечеринку для всей команды.
Это было не совсем то решение, которого бы все хотели, но оно превратило ситуацию,
потенциально вызывающую распри, в событие, которого все ждут.
Суп — это то, «как все устроено» в вашей организации. Он объединяет организа-
ционную культуру, бизнес-стратегию и бизнес-среду. Когда решение вашей проблемы
с препятствием находится в «супе», вы можете только изменить свою реакцию на это.
В любой сложной ситуации у нас есть три возможные реакции: изменить ситуа
цию, изменить других или изменить себя. Суп нельзя изменить, а менять других
непрактично, так что остается только один вариант. Измените себя. Признайте, что
препятствие никуда не уйдет, поэтому сделайте встречу с ним более приемлемой,
насколько это возможно.
Встретившись с препятствием из «супа», ищите как минимум три способа реак-
ции на него. Это может помочь выявить пять или десять разных реакций и отметить
некоторые из них как безумные или полностью неприемлемые. Затем выберите
из этих идей три наиболее приемлемые, из которых в итоге выберите одну, чтобы
опробовать ее.
Вопросы
Что, если член команды говорит, что нет никаких препятствий, но при этом мы
не видим прогресса?
Если кажется, что у кого-то из команды
застопорилась работа, но он постоянно со- См. также
общает, что препятствий нет, то вмешайтесь.
Возможно, в его личной жизни происходят Безопасность (глава 7)
какие-то события, которые отвлекают от рабо- Парное программирование
ты, и он может чувствовать себя слишком уяз- (глава 12)
вимым и не в безопасности, чтобы признать
это. Или он может действительно застрять на (глава 12)
чем-то, но слишком привязан к своей задаче,
чтобы просить помощи, желая разобраться
самостоятельно.
Запланируйте время, чтобы поговорить. Проявите сочувствие. Скажите о поведе-
нии, которое побуждает вас вмешаться. Это единственный способ, которым вы можете
обнаружить препятствия, мешающие устранению препятствий. Обратите внимание
члена команды на расхождение между его отчетами и результатами. Убедите его
рассказать о проблеме. Подчеркните, что команда коллективно отвечает за работу
(см. врезку «Коллективное владение» в главе 9) и просить помощи или передать
задачу кому-то еще — совершенно нормально. Предотвратить эту проблему может
помочь парное или групповое программирование.
Что, если все наши препятствия возникают из-за других людей или команд?
Всегда есть соблазн обвинить кого-то в своих проблемах, но поиски виноватых
мешают вашей команде выбирать действия, помогающие контролировать пробле-
му. Подумайте о том, как поведение вашей команды вносит свой вклад в проблему.
Есть ли способы сделать что-то по-другому? Найдите часть динамики, которая может
быть в вашей власти.
Запланируйте межкомандный диалог с другими, чтобы изучить препятствие.
(Вы можете попросить нейтральную сторону выступить посредником.) Объясните
влияние на команду и ищите решение, удовлетворяющее обе стороны.
Каждая команда встречает препятствия на своем пути, но не каждое из них может
быть устранено. Некоторые находятся за пределами досягаемости вашей команды
независимо от того, насколько сильно они влияют на вас.
Помните о необходимости взглянуть на проблему шире. Слишком узкий фокус
на локальных препятствиях команды приводит к решениям, вызывающим новые
проблемы, или перекладывает препятствия на кого-то другого. Вырабатывая подход
к препятствиям, постарайтесь сохранять системный взгляд.
Остерегайтесь использовать препятствия как оправдание медленного прогресса.
Легко превратить их в козлов отпущения.
Когда вы хорошо устраняете препятствия:
zz команда учится получать удовольствие от решения задачи путем очистки своего
пути;
zz она устраняет препятствия по мере их возникновения;
zz команда тратит меньше времени на устранение препятствий. Вместо этого она
укрепляет те практики и факторы окружающей среды, которые помогают работе.
Устранять препятствия в конечном счете нужно для того, чтобы помочь вашей ко-
манде стать более быстрой и эффективной. Не бойтесь экспериментировать.
Например, концепция позитивного исследования (Appreciative Inquiry) меняет
ситуацию. Вместо того чтобы фокусироваться на проблемах команды, ищите то, что
наполняет ее энергией, и делайте это чаще. Отследите практики или события, благо-
даря которым команда прогрессирует. Анализируйте аспекты, в которых все идет
хорошо, и изучайте, как команда может создать еще больше похожих преимуществ.
Побочный эффект фокусировки на расширении сильных сторон команды — частое
уменьшение количества проблем.
Ката бережливого совершенствования (Lean Improvement kata) — еще один под-
ход, фокусирующийся на долгосрочных препятствиях. Книга Джеспера Боэга Level Up
Agile with Toyota Kata [Boeg2019] — руководство по этому подходу, ориентированное
на программное обеспечение. Она особенно хорошо подходит для устранения пре-
пятствий, мешающих производству высококачественных продуктов.

The Little Book of Impediments [Perry2016] содержит подробное исследование того, как
обнаруживать, отслеживать и ликвидировать препятствия; представлена в удобном
формате электронной книги.
III
НАДЕЖНАЯ ПОСТАВКА
Опять октябрь. Последний год (см. часть II) ваша команда много работала над раз-
витием свободного владения навыками на уровне поставки и теперь являет собой
слаженный механизм. Никогда вы не получали больше удовольствия от работы, чем
сейчас: все мелкие раздражители и шероховатости, относящиеся к профессиональ-
ной разработке ПО (поврежденные сборки, утомительный поиск багов, тщательный
анализ изменений), ушли в прошлое. Теперь вы можете начать задачу и уже через
несколько часов увидеть ее в эксплуатационной среде.
Вы жалеете только о том, что ваша команда свободно не владела навыками на
уровне поставки с самого начала. Оглядываясь назад, можно сказать, что все было бы
быстрее и проще, но люди хотели, чтобы все было медленно. Что ж, хорошо. Теперь
вы знаете.
Входя в командную комнату, вы видите Валери и Бо, работающих вместе за пар-
ной рабочей станцией. Они оба любят приходить пораньше, чтобы успеть до начала
часа пик. Валери видит, что вы снимаете свой рюкзак, и привлекает ваше внимание.
— Сможешь поработать в паре сегодня утром? — спрашивает она. Она всегда
немногословна. — Мы с Бо работаем над обновлениями в реальном времени, и он
сказал, что у тебя могут быть идеи, как тестировать сетевой код.
Вы киваете:
— Мы с Дунканом вчера включили это в спайк и нашли кое-что многообещающее.
Хочешь поработать в паре или можем втроем организовать мини-группу?
— Можешь поработать в паре с Валери, — Бо встает и потягивается. — Мне нуж-
но сделать перерыв после сетевого кода. — Он притворно вздрагивает. — Даже CSS
лучше, чем это.
Валери закатывает глаза и качает головой.
— Устраивайся, — говорит она вам. — Я пока налью себе еще кофе.
Через полчаса вы с Валери уже достигли неплохого прогресса с сетевым кодом.
Каждый раз, когда вы сохраняете изменения, дежурный скрипт запускает ваши
402 Часть III. Надежная поставка
тесты, а затем, секунду спустя, позвякивает, сообщая, как прошел тест: успешно
или нет.
Вы вошли в устойчивый ритм. В данный момент вы — водитель, а Валери — штур-
ман. «Хорошо, теперь давай сделаем так, чтобы выдавалась ошибка, если сообщение
пустое», — говорит она. Вы добавляете тест. Донг! Тест не прошел. Не останавливаясь,
вы переключаетесь на промышленный код, добавляете оператор if и сохраняете
изменение. Дзинь! Тест проходит. «А теперь, когда сообщение повреждено, — гово-
рит Валери, — вы добавляете строку к тесту». Донг! Еще один оператор if. Дзинь!
«Окей, у меня есть несколько заметок и о других пограничных случаях, — говорит
Валери. — Но я думаю, сначала нам нужно вычистить эти if. Исключение метода
validateMessage() должно помочь». Вы киваете, выделяете код и нажимаете клавишу
Extract Method. Дзинь! Никаких проблем!
Эти звуки — результат эксперимента, проведенного несколько месяцев назад.
Несмотря на шутки о «программистах Павлова», они стали хитом. Ваша команда
работает такими маленькими шагами, что бо́льшую часть времени код делает именно
то, что вы от него ожидаете. Тесты ваших инкрементов занимают меньше секунды,
так что звуки служат мгновенной обратной связью. Вам всего лишь нужно взглянуть
на исполнителя тестов (test runner), когда что-то идет не так. Остальное время вы
остаетесь в области работы, переключаясь между тестами, кодом и рефакторингом,
а перезвон подтверждает, что все в порядке и под контролем.
Еще через полчаса сетевые изменения сделаны. Вы потягиваетесь, пока Валери
извлекает последний код из интеграционной ветки и запускает полный набор тестов.
Через минуту он проходит, и она запускает скрипт развертывания. «Готово! — говорит
она. — Пора выпить еще кофе, последишь за развертыванием?»
Вы снова устраиваетесь в кресле и наблюдаете, как выполняется скрипт разверты-
вания. Он тестирует ваш код на отдельной машине, затем сливает его в общую инте-
грационную ветку. Все в команде сливают свой код из нее и в нее каждые несколько
часов. Это позволяет поддерживать синхронизацию команды и разрешать конфликты
при слиянии на раннем этапе, до того как это превратится в проблему. Затем скрипт
развертывает код на канареечном производственном сервере. Через несколько минут
развертывание подтверждено, и скрипт помечает ваш репозиторий как успешный.
Вы неспешно идете к доске задач и отмечаете сетевую задачу зеленым. «Все сде-
лано, Бо! — зовете вы. — Готов заняться CSS?»
ДОБРО ПОЖАЛОВАТЬ НА УРОВЕНЬ ПОСТАВКИ

Свободное владение навыками на уров-
не поставки нужно командам, которые Свободное владение навыками на уровне
хотят надежно поставлять ПО. Члены поставки нужно командам, которые
команды развивают свои технические хотят надежно поставлять ПО.
навыки, чтобы их ПО требовало мало
обслуживания, его было легко улучшать и развертывать и чтобы оно содержало
минимум багов. В частности, команды, которые владеют навыками в поставке1:
1
Эти списки получены из [Shore2018b].
Часть III. Надежная поставка 403
zz выпускают свою последнюю работу с минимальным риском и затратами, когда бы

их бизнес-стейкхолдеры этого ни пожелали;
zz обнаруживают и исправляют недостатки в производственном жизненном цикле
на раннем этапе, прежде чем те смогут навредить;
zz способны предоставлять полезные прогнозы;
zz имеют низкий уровень дефектов, поэтому тратят меньше времени на исправление
багов и больше — на создание функциональностей;
zz создают ПО с хорошим внутренним качеством, что удешевляет и ускоряет про-
цесс изменений;
zz имеют высокую удовлетворенность работой и моральный дух, что улучшает про-
дуктивность и способствует удержанию сотрудников в команде.
Чтобы достичь этого, команды должны развить определенные навыки. Для этого
нужны инвестиции, описанные в главе 4.
Команда отвечает требованиям бизнеса:
zz качество написанного ею кода соответствует промышленному уровню, и последняя
работа развертывается в среду, эквивалентную эксплуатационной, по меньшей
мере ежедневно;
zz представитель бизнеса в команде может делать релиз последней работы команды
по желанию в любой момент;
zz команда предоставляет полезные прогнозы своих релизов представителям биз-
неса по запросу;
zz команда координируется со своими бизнес-стейкхолдерами, чтобы выработать
способ, позволяющий сопровождать ее ПО недорого и сколь угодно долго.
Команда эффективно работает как команда:
zz разработчики рассматривают код и другие подобные артефакты как принадле-
жащие всей команде, а не отдельным лицам, и разделяют ответственность за их
изменение и улучшение;
zz все повседневные навыки, необходимые для дизайна, разработки, тестирования,
развертывания, мониторинга, технического обслуживания и т. д., вся командная
работа доступны участникам в любой момент.
Команда стремится к техническому совершенству:
zz каждый раз, внося изменения в свое ПО, члены команды оставляют его внутрен-
нее качество в несколько лучшем состоянии, чем оно было до их вмешательства;
zz команда активно реагирует на ошибки, улучшая систему, допустившую ошибку,
снижая вероятность ошибок в будущем;
zz развертывание и релиз автоматизированы и требуют не больше 10 минут ручного
труда;
zz перед развертыванием ручное тестирование не требуется;
zz члены команды знают, как их навыки влияют на их способность достичь целей
команды и улучшить внутреннее качество, и проактивно стараются улучшить
эти навыки.
ДОСТИЖЕНИЕ СВОБОДНОГО ВЛАДЕНИЯ

НАВЫКАМИ НА УРОВНЕ ПОСТАВКИ
Практики в этой части книги помогут вашей команде достичь свободного владения
навыками на уровне поставки. По большей части они сосредоточены вокруг одно-
временных фаз.
Большинство команд, даже Agile-команд, используют подход к разработке,
основанный на фазах. Они могут работать итерациями, но внутри каждой из них
следуют фазовому подходу в анализе требований, дизайна, написания кода, тести-
рования и развертывания (части А и Б на рис. III.1). Даже команды, использующие
непрерывный поток, склонны разрабатывать каждую историю с помощью серий фаз,
используя визуализацию обзорных полос для отслеживания прогресса.
Рис. III.1. Жизненные циклы разработки ПО

Часть III. Надежная поставка 405
Но Agile по своей сути итеративный и инкрементный (поэтапный) подход. Каждая

история занимает всего лишь день или два работы. Этого недостаточно для высоко-
качественных фаз. На практике дизайн и тестирование обделяют вниманием. Каче-
ство кода со временем деградирует, командам трудно разобраться, как планировать
необходимые работы по дизайну и инфраструктуре, и у них не хватает времени на
тестирование и устранение багов.
Чтобы избежать этих проблем, экстремальное программирование ввело техники,
позволяющие разработке программ быть действительно инкрементной. Вместо того
чтобы работать по фазам, команды XP работают над всеми аспектами разработки
инкрементно и непрерывно (часть В рис. III.1).
Несмотря на то что экстремальное программирование появилось в далеких 1990-х,
его методы тестирования, кодирования и дизайна остаются самыми современными.
Они дают самый высококачественный, самый продуктивный код из того, что я когда-
либо видел. В последнее время движение
DevOps расширило их, чтобы поддержать со- См. также
временное развертывание на облачной основе.
В сочетании с поэтапным планированием ин- Адаптивное планирование (глава 8)
крементов и анализом требований эти техни- Инкрементные требования (глава 8)
ки позволяют командам регулярно и надежно
поставлять высококачественное ПО.
Практики в этой части основаны на XP. Если вы будете применять их вдумчиво
и строго, то достигнете свободного владения навыками на уровне поставки.
Практики сгруппированы в пять глав:
zz в главе 12 описывается, как создавать ПО командой;
zz в главе 13 показаны инкрементные сборка, тестирование и автоматизация;
zz в главе 14 описывается, как делать инкрементный дизайн кода;
zz в главе 15 рассказывается, как развертывать ПО надежно и в любой момент по
своему усмотрению;
zz в главе 16 описывается, как создавать ПО, которое будет делать то, что должно
делать.
ГЛАВА 12
Сотрудничество
Вдобавок к командной работе, которую ожидают от любой Agile-команды (см. гла-

ву 7), команды поставки имеют высокие стандарты технического мастерства и со-
трудничества. Ожидается, что они будут совместно работать над поддержанием
высокого внутреннего качества и обеспечивать самые важные бизнес-приоритеты.
Практики из этой главы помогут вашим командам сотрудничать.
zz Практика «Коллективное владение кодом» поощряет членов команды улучшать
код друг друга.
zz Практика «Парное программирование» способствует перекрестному опылению
идей и помогает членам команды понимать работу друг друга.
zz С помощью практики «Групповое программирование» ваша команда объединяется
для совместной работы.
zz Практика «Единый язык» помогает членам команды понимать друг друга.
Источники сотрудничества
Как это обычно бывает на уровне поставки, большинство практик в этой главе
ведут свою родословную от XP1. Практики «Коллективное владение кодом»
и «Парное программирование» пришли напрямую из XP.
Групповое программирование — разновидность парного программирования.
Вуди Зуилл формализовал его в качестве практики, основываясь на собственном
опыте его применения с одной из команд в Hunter Industries. Первоначально
Вуди называл эту практику «Программирование всей командой» (Whole Team
programming), но он использовал название «Групповое программирование» для
похожей активности (из [Hohman2002]), и это название прижилось. Групповое
программирование также известно как программирование в ансамбле (ensemble
programming).
1
Влияние экстремального программирования простирается, конечно, еще дальше. Один из наиболее
заслуживающих внимания предшественников — язык шаблонов Уорда Каннингема EPISODES
[Cunningham1995], включающий множество идей, в том числе парное программирование, которые
позже перешли в XP.
Глава 12. Сотрудничество 407
Я впервые услышал о едином языке от Джошуа Кериевски, который включил его

в свой метод промышленного XP [Kerievsky2005]. Единый язык заменил практику
XP «Метафора», которая не очень хорошо работала и в результате была удалена
из второй редакции книги по XP. Я совершенно уверен, что Кериевски вдохновила
прекрасная книга Эрика Эванса Domain-Driven Design: Tackling Complexity in the
Heart of Software [Evans2003]. Она же легла в основу моих рассуждений.
КОЛЛЕКТИВНОЕ ВЛАДЕНИЕ КОДОМ

Мы все вместе отвечаем за весь наш код. Аудитория
Agile-команды совместно управляют своей работой, Разработчики

как описывается во врезке «Коллективное владение»
в главе 9. Но как это применимо в отношении кода?
Коллективное владение кодом означает, что команда разделяет ответственность
за свой код. Вместо того чтобы назначать ответственных за модули, классы или
истории отдельных людей, команда владеет всем этим целиком. Это право и от-
ветственность вносить улучшения в любой аспект командного кода в любое
время.
Фактически улучшенное качество кода —
одно из скрытых преимуществ коллективно- Исправляйте проблемы
го владения кодом. Коллективное владение независимо от того,
подразумевает (нет, ожидает), что каждый где вы их нашли.
исправляет проблемы, которые находит. Если
вы обнаружили дублирование, непонятные названия, плохую автоматизацию или
даже код с плохим дизайном — неважно, кто его написал. Это ваш код. Исправьте его!
Как заставить коллективное владение работать

Коллективное владение кодом требует тща-
тельной координации в вопросах дизайна См. также
и планирования. Если вы используете груп-
повое программирование, эта координация (глава 12)
достается вам даром. В других случаях начать
обсуждение можно на встрече по планирова-
нию задач. Когда вы будете обсуждать, как
разбивать задачи, поговорите о дизайне. Записывайте задачи в терминах того, как
изменится дизайн: «Добавить конечную точку (endpoint) к UserReportController»,
«Обновить ContactRecord», «Добавить колонки в таблицу базы данных GdprConsent».
Когда будете готовы к новой задаче, вы можете выбрать любую задачу с доски
планирования. В большинстве случаев вы просто возьмете следующую из списка,
но можно и перескочить немного вперед

и выбрать задачу, которая вам интересна См. также
или хорошо соответствует вашим знаниям.
Сделано Сделано (глава 9)
В идеальном мире ваша команда будет
фокусироваться на каждой истории: все
будут выбирать задачи, принадлежащие одной и той же истории, и стремиться
перевести ее в состояние «Сделано Сделано», прежде чем переходить к следую-
щей. Это позволяет минимизировать объем невыполненной работы (см. врезку
«Минимизируйте объем незавершенной работы» в главе 8) и рано выявлять
риски.
На практике это нормально, когда люди
переходят к следующей истории, когда теку- Не переходите к другой истории
щая близка к завершению. Но будьте осто- только потому, что не знаете,
рожны: когда вы новичок в коллективном как скоординироваться.
владении, легко случайно прийти к тому,
что каждый фактически будет владеть отдельными историями, вместо того чтобы
действительно работать всем вместе. Не переходите к другой истории только потому,
что не знаете, как скоординироваться.
Когда вы беретесь за задачу, имеющую близкое отношение к другому человеку
или паре, кратко обсудите ее с ними. Возможно, они взялись за фронтенд-задачу,
а вы — за соответствующую бэкенд-задачу. Потратьте время на то, чтобы прийти
к единому пониманию API. Кто-то один из вас или оба могут сделать в API заглушку
из ничего не выполняющего кода, а затем один из вас может заполнить ее. Человек,
который делает коммит своего кода вторым, отвечает за дополнительную проверку
того, что все собранное воедино работает.
В процессе работы над кодом у вас будут
возникать новые идеи, влияющие на работу См. также
других людей. Парное программирование
поможет распространить эти идеи по всей Парное программирование (глава 12)
команде. Вы также можете использовать
ежедневные стендапы для того, чтобы изложить новые идеи. Если вы не использу-
ете парное или групповое программирование, то вам может понадобиться добавить
ежедневные обзоры дизайна.
Некоторые идеи заслуживают немедленного обсуждения. В физической командной
комнате просто встаньте и объявите, о чем хотите поговорить. Люди подойдут к вам.
В виртуальной команде объявите тему в командном групповом чате и пригласите
людей присоединиться к вам в режиме видеозвонка. Больше информации вы можете
найти в пункте «Легко входите в дискуссии и выходите из них» главы 7.
Программирование без эго

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

с вашими товарищами по команде и соглашаетесь принять общее решение.
С одной стороны, коллективное владение также требует того, чтобы члены коман-
ды приняли совместное обязательство производить хороший код. Когда вы видите
проблему, исправьте ее. Когда пишете новый код, не полагайтесь на то, что кто-то
другой исправит ваши ошибки. Пишите лучший код, насколько это возможно.
С другой стороны, коллективное владение также означает, что вы не обязаны
быть совершенными. Если ваш код работает и вы не знаете, как его улучшить, то
смело оставьте его. Кто-то другой его улучшит позже, если и когда это понадо-
бится.
И наоборот, когда вы работаете над «чьим-
то еще» кодом (но это не чей-то еще код — он Всегда оставляйте код
ваш!), избегайте соблазна судить о личных в немного лучшем виде,
качествах этих людей, основываясь на их коде. чем когда вы его нашли.
Но всегда оставляйте код в немного лучшем
виде, чем когда вы его нашли. Если вы видите возможность улучшения, то не стес-
няйтесь. Вы не должны спрашивать разрешения. Сделайте это!
Сотрудничество без конфликтов

Поначалу коллективное владение кодом несет в себе возможности для конфликта.
Все мелкие раздражители, связанные со стилем работы ваших коллег, усиливаются
и подчеркиваются ярчайшим образом. Это хорошо (на самом деле хорошо!), по-
скольку дает вам шанс выровнять ваши стили. Но поначалу это может быть непри-
ятным.
Чтобы помочь процессу пройти гладко,
определитесь с важными стандартами кода, См. также
дизайна, архитектуры в ходе вашей сессии
согласования устава. Когда вы впервые при- Согласование (глава 7)
нимаете коллективное владение кодом, по- Групповое программирование
пробуйте групповое программирование в те- (глава 12)
чение недели или двух, чтобы прояснить все
важные различия. Поднимайте вопросы о раз-
ногласиях во время ретроспектив и предла- Динамики команды (глава 11)
гайте планы их решения. Уделяйте внимание
динамикам команды.
Если вы не используете групповое про-
граммирование, то вам понадобится найти См. также
способ, как не мешать друг другу во время
ежедневной работы. Ежедневные стендап- Стендап-митинги (глава 9)
митинги — хороший способ координации, Планирование задач (глава 9)
пока они короткие и сфокусированные. Дос Парное программирование
ка планирования задач поможет вам быть (глава 12)
в курсе текущей ситуации, особенно если она Непрерывная интеграция (глава 13)
видна с того места, где вы сидите.
Парное программирование поможет вам быть в курсе внесенных всеми изменений.

Ваш партнер часто будет знать об изменениях, о которых вы не знаете, и наоборот.
И даже если он не в курсе, при парном программировании проще попросить другую
пару о помощи. Люди, работающие в паре, могут ненадолго отвлекаться, не влияя на
свой прогресс, — один человек просто продолжает работать, пока другой разбирается
с тем, что их отвлекло.
На самом деле настаивайте на том, чтобы люди просили помощи, когда их что-то
останавливает. Нет никакого смысла 30 минут биться головой о стену, если кто-то
другой в команде уже знает ответ.
И наконец, непрерывная интеграция предотвратит болезненные конфликты объ-
единения и будет поддерживать синхронизацию общего кода.
Работа с незнакомым кодом

Если вы работаете над проектом, в котором имеются куски кода, которые понимают
один или два человека, то совместное владение кодом может пугать. Как вы можете
взять на себя ответственность за код, который не понимаете?
Вам лучше всего подойдет групповое программирование, по крайней мере пона-
чалу. Оно поможет всей команде быстро делиться друг с другом своими знаниями.
Если это вам не по вкусу, то используйте парное программирование.
Чтобы использовать парное программирование для расширения своих знаний,
вызывайтесь добровольцем работать над задачами, которые не понимаете. Попросите
кого-нибудь, кто знает эту часть системы, поработать с вами в паре. В ходе работы
избегайте соблазна сесть позади и наблюдать. Вместо этого возьмите клавиатуру
и попросите партнера руководить вами. Благодаря тому, что клавиатура в ваших
руках, вы можете контролировать темп: задавайте вопросы и убеждайтесь, что по-
нимаете, что вас просят сделать. Больше информации см. в подразделе «Обучение
при работе в паре» далее в текущей главе.
Если никто не понимает код, то тренируйте свои навыки делать логические вы-
воды. Вам не нужно точно знать, что происходит в каждой строчке кода. В хорошо
спроектированной системе все, что вам нужно знать, — это за что отвечает каждый
пакет, пространство имен или папка. Тогда вы сможете сделать вывод о том, за что
отвечают классы и что делают методы, исходя из их имен. В подразделе «Реверс-
инжиниринг дизайна» главы 14 можно узнать более подробную информацию по
данной теме.
Хорошо написанные тесты также служат до-
кументацией и подстраховкой. Бегло просмотрите
См. также
названия тестов, чтобы понять, какой соответству-
ющий код за них отвечает. Если вы не понимаете, Разработка через тестирова-
как что-либо работает, то измените это любым ние (глава 13)
образом и посмотрите, что покажут тесты. Эф- Рефакторинг (глава 13)
фективный набор тестов покажет вам, когда ваши
предположения неверны.
В процессе этого обучения выполняйте рефакторинг кода так, чтобы он отражал

ваш прогресс в понимании. Исправляйте запутанные имена и извлекайте переменные
и функции. Таким образом вы систематизируете ваши знания, а также поможете
следующему человеку. Техника Арло Бельши «Присвоение имени как процесс»
[Belshee2019] — хорошая формализация этого подхода.
Если вы работаете с плохо спроектированным кодом, который никто не пони-
мает и у которого нет никаких тестов, то не все потеряно. Вы можете использовать
характеристические тесты (characterization tests) для безопасного рефакторинга.
В подразделе «Добавление тестов к существующему коду» главы 13 содержится
больше информации по этой теме.
Преимущества для программистов

То, что никто этого не понимает, — гарантия моей
востребованности!
Старая программистская шутка
Коллективное владение имеет большой смысл для организации. Оно снижает риск,
улучшает временной цикл и повышает качество благодаря привлечению к коду боль-
шего количества людей. Но имеет ли оно смысл для программистов? Не осложнит ли
оно еще больше признание вашего вклада?
Если честно, то может… Как обсуждается в подразделе «Измените вредные
кадровые политики» главы 4, Agile требует, чтобы ваша организация признавала
и ценила командный вклад больше, чем индивидуальный героизм. Если в вашей
организации это не так, то коллективное владение кодом может вам не подойти.
Даже если ваша организация ценит командную работу, перестать работать над
большим куском кода нелегко. Может быть трудно справиться с желанием взять на
себя почетную ответственность за особенно умное или элегантное решение.
Но все же это хорошо для вас как для программиста. Почему? Вся кодовая база
в вашем распоряжении — не только для изменений, но и для поддержки и совер-
шенствования. Вы можете расширить ваши технические навыки. Вы узнаете новые
техники дизайна и написания кода, работая с другими членами команды. Обучая
других людей знаниям из вашей экспертной области, вы также можете практиковать
свои навыки наставничества.
Вы также не должны нести бремя технического обслуживания каждого куска
кода, который напишете. Вся команда прикрывает вас. Со временем они будут знать
ваш код так же хорошо, как и вы сами, и вы сможете уйти в отпуск, не ожидая по-
стоянных звонков с вопросами и экстренных ситуаций.
Поначалу немного страшновато приходить на работу и не знать точно, над какой
частью системы вы будете работать сегодня, но это также и освобождает. У вас больше
нет долгих подпроектов, растягивающихся на ночь или на выходные. Вы получаете
разнообразие, вызов и изменения. Попробуйте — вам понравится.
Вопросы
У нас есть действительно хороший фронтенд-разработчик/программист баз данных/
гуру масштабирования. Почему не использовать их навыки?
Пожалуйста, так и делайте! Коллективное владение кодом означает, что каждый
вносит вклад в каждую часть системы, но вам все же понадобятся эксперты, которые
будут задавать тон.
Как может каждый узнать всю кодовую базу целиком?
Людей естественным образом притягивает та или иная часть системы. Они ста-
новятся экспертами в определенных областях. Каждый получает общее понимание
кодовой базы в целом, но все не могут знать всех деталей.
Несколько практик поддерживают
этот подход к работе. Простой дизайн См. также
и его фокус на ясности кода облегча-
ет понимание незнакомого кода. Тесты Простой дизайн (глава 14)
работают как подстраховка и источник Разработка через тестирование (глава 13)
документации. Парное и групповое про-
Парное программирование (глава 12)
граммирование позволяет вам работать
с людьми, разбирающимися в деталях, Групповое программирование (глава 12)
которые не понимаете вы.
Разные программисты в нашей команде отвечают за разные продукты. Должна ли
команда коллективно владеть всеми этими продуктами?
Если вы объединили программистов в одну команду, то да, вся команда должна взять
на себя ответственность за весь свой код. Если у вас несколько команд, то они могут
делить ответственность между командами или не делить в зависимости от вашего под-
хода к масштабированию. В главе 6 можно найти больше информации по данной теме.
Коллективно владеть кодом трудно с со-
циальной точки зрения. Некоторым орга- См. также
низациям сложно отказаться от практики
индивидуальных поощрений и ответ- Согласование (глава 7)
ственности. Некоторым программистам Безопасность (глава 7)
трудно избавиться от привычки брать
на себя индивидуальную ответствен-
ность или отказаться от использования Планирование задач (глава 9)
определенного языка программирования. Стендап-митинги (глава 9)
По этим причинам важно поговорить с ру-
ководителями и членами команды о кол- Групповое программирование (глава 12)
лективном владении кодом, прежде чем Парное программирование (глава 12)
пробовать его. Все эти опасения должны
стать частью ваших изначальных дискус-
сий о том, пробовать или нет Agile в целом Простой дизайн (глава 14)
(см. главу 5), а потом их следует поднять Разработка через тестирование (глава 13)
снова во время сессии согласования.
Безопасность критически важна. Если члены команды не чувствуют себя в без-

опасности, чтобы выражать и получать критику, или опасаются нападок в случае
высказывания идей или озабоченности, то не смогут разделить владение кодом.
Вместо этого будут возникать небольшие случаи «феодального владения» кодом.
«Не меняй пока этот код. Тебе нужно поговорить сначала с Энтони, чтобы удосто-
вериться, что он согласен».
Коллективное владение также требует хорошей коммуникации. Вам понадобится
командная комната, физическая или виртуальная, в которой люди смогут свободно
общаться. Используйте планирование задач и доску задач, чтобы помочь людям по-
нять суть своей работы, и стендап-митинги, чтобы координировать ее.
Вам нужен способ, благодаря которому вся команда будет знать об изменениях.
В них легко потеряться, так как любой человек может внести любое изменение
в любой момент времени. Самые простые способы — парное и групповое програм-
мирование. Если они не подходят, то вам нужно будет приложить дополнительные
усилия, чтобы информировать об изменениях. Ревью кода будет, вероятно, недоста-
точно. Большинство людей инстинктивно склоняются к документации в качестве
решения, но это слишком затратно, как обсуждалось в главе 7. Попробуйте сначала
более легкие решения. Один из вариантов — ежедневно проводить 30-минутные
«резюме дизайна» для обсуждения новых идей и недавних изменений.
Так как коллективное владение кодом повышает вероятность того, что люди бу-
дут менять один и тот же код, вам нужно минимизировать вероятность болезненных
конфликтов при объединении кода. Лучший способ — непрерывная интеграция.
В новых кодовых базах конфликты объединения более вероятны, поскольку
кода мало. Групповое программирование может быть хорошим способом загруз-
ки кодовой базы, даже если вы не планируете использовать его в долгосрочной
перспективе.
Хотя это и не всегда строго необходимо, простой дизайн и разработка на основе
тестирования являются хорошими идеями для команд, использующих коллективное
владение кодом. Они упрощают понимание и изменение кода.
Несмотря на длинный список предварительных требований, коллективное
владение кодом легко практиковать, когда все условия соблюдены. Все, что вам
нужно, — общее согласие команды по поводу того, что каждый должен работать над
любой частью кода, запрашивая и предоставляя помощь по мере необходимости.
Вам не нужно, чтобы каждый знал любой фрагмент кода; члены команды просто
должны быть в состоянии попросить помощи, работая над незнакомой частью кода,
и великодушно предоставить свою помощь взамен.
Когда ваша команда хорошо практикует коллективное владение кодом:
zz каждый в команде постоянно вносит небольшие усовершенствования во все
части кода;
zz никто не жалуется на то, что члены команды меняют код, не спрашивая разре-
шения перед этим;
zz когда вы возвращаетесь к коду, который писали изначально, вы обнаруживаете,

что он улучшен без вашего участия;
zz когда член команды уходит или берет отпуск, оставшаяся часть команды выпол-
няет его работу без каких-либо прерываний.
Главные альтернативы коллективному владению кодом — слабое и сильное владение
кодом. Если вы работаете с кодом со слабым владением, то можете изменять любую
часть кода, но хорошим тоном будет согласовать изменения с разработчиками, от-
ветственными за его качество. В случае кода с сильным владением все изменения
делаются только через его владельцев.
Оба эти подхода умаляют присущую Agile сосредоточенность на командной
работе, хотя слабое владение кодом не так плохо, как сильное. Оно может быть по-
лезно командам, которые не используют парное или групповое программирование
или у которых не получается оставлять код в лучшем состоянии, чем они его нашли.
Но если вы можете, то попробуйте применить коллективное владение кодом. Это
одна из тех идей Agile, которую часто упускают из виду, хотя на самом деле она является
одной из главных. Она не всегда означает коллективное владение кодом, но, я думаю,
это важная составляющая равенства. Хотя, вероятно, и можно быть компетентной
командой поставки без коллективного владения кодом, я такого еще не видел. Ис-
пользуйте эту практику, пока не наберетесь опыта как компетентная команда поставки.
ПАРНОЕ ПРОГРАММИРОВАНИЕ
Мы помогаем друг другу добиваться успеха.
Аудитория
Вы бы хотели, чтобы кто-то весь день загля- Разработчики, вся команда
дывал вам через плечо? Вы бы хотели тратить
половину своего времени, сидя в скучной тиши-
не и глядя на чей-то чужой код?
Конечно, нет! К счастью, парное программирование работает не так.
Парное программирование подразумевает работу двух человек за одним компью-
тером в одно и то же время над одним и тем же. Это одна из наиболее противоречи-
вых идей Agile. Два человека работают за одним компьютером? Это странно. И это
также чрезвычайно эффективно и, когда вы привыкаете, доставляет огромное удо-
вольствие. Большинство знакомых мне программистов, которые практиковали
парное программирование в течение месяца, обнаружили, что предпочитают его
программированию в одиночестве.
Что гораздо важнее, парное программирова-
ние — один из наиболее эффективных способов См. также
достижения коллективного владения и под-
Коллективное владение кодом
линного взаимодействия команды в работе над (глава 12)
кодом.
Почему парное?
Парное программирование — нечто большее, чем обмен знаниями. Помимо этого, оно
улучшает качество ваших результатов. Это потому, что парное программирование
удваивает ваш интеллектуальный потенциал.
Когда вы работаете в паре, один человек является водителем. Он (или она) пишет
код. Второй человек — штурман. Его (или ее) работа — думать. Будучи штурманом,
иногда вы думаете о том, что набирает водитель. (Однако не спешите указывать ему
на пропущенные точки с запятой, это раздражает.) Иногда вы думаете о том, что будет
дальше. А иногда — о том, как ваша работа вписывается в общий дизайн.
Такой порядок позволяет водителю свободно работать над тактическими задачами
по созданию строгого, синтаксически правильного кода, не беспокоясь об общей карти-
не, а штурману дает возможность рассматривать стратегические вопросы, не отвлекаясь
на детали кодирования. Работая вместе, водитель и штурман выполняют работу более
качественно и быстро, чем если бы это делал каждый из них по отдельности1.
Кроме того, парное программирование закрепляет хорошие навыки программи-
рования. Практики поставки требуют много самодисциплины. В процессе парного
программирования вы будете испытывать позитивное давление коллег, побуждающее
вас делать то, что необходимо. Вы также будете распространять знания и рекомен-
дации по кодированию в команде.
Как ни удивительно, вы также будете проводить больше времени в потоке — этом
высокопродуктивном состоянии, в котором вы полностью сосредоточены на коде. Это
другой вид потока, по сравнению с тем, когда вы работаете в одиночку, но он гораздо
более устойчив к прерываниям. Для начала вы обнаружите, что ваши офисные кол-
леги с гораздо меньшей вероятностью отвлекают вас, когда вы работаете с кем-либо.
А когда они это делают, один член пары может заняться тем вопросом, по которому
вас прервали, в то время как другой продолжит работу. Далее вы обнаружите, что
фоновый шум отвлекает меньше: ваши разговоры с вашим партнером по паре будут
удерживать вас в фокусе.
Если этих резонов недостаточно, то могу сказать, что программирование в паре —
это действительно очень весело. Дополнительная умственная энергия поможет вам
легче обойти препятствия. Бо́льшую часть времени вы будете взаимодействовать
с умными людьми, вашими единомышленниками. Вдобавок если у вас устанут
пальцы, то вы сможете передать клавиатуру вашему партнеру и при этом продолжать
быть продуктивным.
Рабочие станции для парного программирования

Чтобы получать удовольствие от парного программирования, необходима хорошая
рабочая станция, независимо от того, работаете вы в офисе или удаленно. Командам,
работающим в офисе, нужно предоставить достаточно места, чтобы два человека
1
Одно из исследований обнаружило, что парная работа требует приблизительно на 15 % больше
усилий, чем индивидуальная, но дает результат гораздо быстрее, при этом количество дефектов
уменьшается на 15 % [Cockburn2001]. Все команды разные, так что лучше относиться к этим
результатам с недоверием.
могли сидеть рядом. Обычные офисные кабинки, где монитор расположен в углу,
не подойдут. Они неудобны и требуют, чтобы один человек сидел за спиной у другого,
что добавляет психологические и физические барьеры на пути к тому, что должно
быть сотрудничеством с коллегами.
Вам не нужна роскошная мебель для того, чтобы сделать хорошую парную рабочую
станцию. Подойдет простой стол. Он должен быть шесть футов шириной (примерно
180 см), чтобы два человека могли комфортно разместиться бок о бок. На каждый
стол нужен мощный компьютер. Подключите две клавиатуры и мышь, чтобы у каж-
дого человека был свой комплект. Если у людей есть любимые клавиатура и мышь,
то они могут принести их с собой. На такой случай предоставьте свободный доступ
к USB-портам.
Купите большие мониторы, чтобы обоим участникам пары было все хорошо видно.
Учтите возможную разницу зрения людей, особенно в отношении размеров шрифтов
и цвета. Некоторые команды устанавливают три монитора, при этом два внешних
монитора зеркальны, чтобы каждый человек мог видеть код на мониторе напротив
себя, используя центральный монитор для вспомогательных материалов. Если вы
так делаете, то попробуйте установить утилиту, позволяющую мыши переходить
за границы рабочего стола. Это позволит обоим программистам легко добраться до
центрального экрана.
Если ваша команда работает удаленно, то вам понадобятся совместный редактор
кода и видеоконференция. Предоставьте несколько экранов, чтобы вы могли одно-
временно видеть друг друга и писать код.
Существует множество IDE-надстроек и автономных инструментов для со-
вместного редактирования, таких как CodeTogether, Tuple, Floobits и Visual Studio’s
Live Share. Кроме того, можно совместно использовать экран в программе для
видеоконференций, но инструмент для совместного редактирования позволит вам
переключать водителей гораздо быстрее. Если вам нужно совместно использовать
экран, то вы можете передавать контроль, выкладывая код во временную ветвь
с текущей работой (work-in-progress). Напишите небольшой скрипт для автома-
тизации процесса.
У Джеффа Лангра в [Langr2020] есть хороший обзор вариантов взаимодействия
при удаленном написании кода.
Как работать в паре

Я рекомендую работать в паре над всем производственным кодом. Команды, ко-
торые часто работают парами (но не исключительно парами), говорят, что в коде,
написанном соло, они обнаруживают больше дефектов. Это совпадает с тем, что
говорят исследования парного программирования, такие как [Cockburn2001], кото-
рые находят, что пары производят высококачественный код. Хорошее эмпирическое
правило — работать в паре над всем, что вам нужно поддерживать, в том числе над
тестами и автоматизацией.
Когда вы начинаете работать над задачей, попросите другого программиста рабо-
тать с вами. Если кто-то другой просит о помощи, то предложите ее. Руководители
никогда не должны назначать партнеров, пары должны свободно и самостоятельно
формироваться и переключаться в течение дня. В течение недели поработайте в паре

с каждым разработчиком в команде. Это повысит сплоченность команды и будет
способствовать распространению навыков и знаний в команде.
Если вам нужен свежий взгляд, то поменяйте
партнеров. Я обычно переключаюсь, когда расстро-
Получите свежий взгляд,
ен или застрял. Пусть один из партнеров остается поменяв партнеров.
работать над задачей и введет нового партнера
в курс дела. Часто даже объяснение проблемы
новому человеку может помочь решить ее.
Хорошая идея — менять партнеров несколько раз за день, даже если вы не чув-
ствуете себя застрявшим на чем-то. Это поможет держать всех в курсе и работать
быстро. Я переключаюсь на другого партнера, когда завершаю задачу. Если я работаю
над большой задачей, то меняю партнера в течение четырех часов.
Некоторые команды переключают партнеров в парах строго по расписанию.
[Belshee2005] отчитывается об интересных результатах, получаемых при переклю-
чении каждые 90 минут. Это отличный способ приобрести привычку переключения,
однако убедитесь, что все хотят его попробовать.
Начиная парную работу, убедитесь, что вам физически комфортно. Если вы в одном
помещении, то расположите стулья бок о бок, чтобы у каждого было достаточно личного
пространства, и поставьте монитор так, чтобы он был хорошо виден. Когда вы в роли
водителя, поместите клавиатуру прямо напротив себя. Следите за этим — почему-
то новички в парном программировании склонны изгибаться, чтобы дотянуться до
клавиатуры и мыши, вместо того чтобы подвинуть их к себе поближе.
Кроме того, уделите время тому, чтобы договориться с партнером о предпочтениях
друг друга. Когда вы в роли водителя, хотите ли вы, чтобы ваш партнер давал вам
время на самостоятельное обдумывание каких-то нюансов? Или вы хотели бы, чтобы
он (или она) управлял процессом и вам не приходилось останавливаться и думать?
Когда вы — штурман, хотите ли вы, чтобы ваш водитель проговаривал вслух, о чем
он думает, чтобы вы понимали направление движения? Или вы хотели бы иметь
возможность концентрироваться на том, что будет дальше? Хотите ли вы строгого
разделения ролей водителя и штурмана? Или предпочтете легкий, неформальный
подход?
Ожидайте поначалу чувства неловкости и неуклюжести, когда придет ваша
очередь быть в роли водителя. Вам может казаться, что ваш штурман видит идеи
и проблемы гораздо быстрее вас. Так и есть: у него гораздо больше времени на раз-
мышление, чем у водителя. Ситуация будет обратной, когда вы станете штурманом.
Через некоторое время работа в паре будет ощущаться как что-то естественное.
Пары производят код с помощью общения. В процессе работы думайте вслух.
Двигайтесь маленькими шагами (отлично подойдет разработка на основе тестиро-
вания) и говорите о своих предположениях, кра-
ткосрочных целях, общем направлении и о любой
См. также
истории, имеющей отношение к делу. Если вас
что-то смущает, то задавайте вопросы. Благодаря Разработка через тестирование
обсуждению ваш партнер может узнать полезную (глава 13)
информацию, так же как и вы.
В процессе работы переключайте роли водителя и штурмана чаще — по меньшей

мере каждые полчаса, а по возможности каждые несколько минут. Если вы — штур-
ман и обнаруживате, что говорите водителю, какие кнопки нажимать, то попросите
дать вам клавиатуру. Если вы — водитель и вам нужен перерыв, то передайте клавиа
туру вашему штурману.
Ожидайте, что устанете к концу дня. Пары
обычно чувствуют, что работали больше и до- См. также
бились большего, чем если бы работали пооди-
ночке. Практикуйте активную работу, чтобы Энергичная работа (глава 7)
поддерживать способность работать в паре еже-
дневно.
Эффективная навигация
Пребывая в роли штурмана, вы можете испытывать желание вмешаться и за-
брать клавиатуру у вашего партнера. Будьте терпеливы. Ваш водитель часто бу-
дет высказывать свои идеи как словами, так и с помощью кода. Он будет делать
опечатки и небольшие ошибки — дайте ему время исправить их самостоятельно.
Используйте свое свободное время, чтобы подумать об общей картине. Какие еще
тесты вам необходимо написать? Как этот код вписывается в остальную систему?
Есть ли дублирование, которое вы хотите удалить? Может ли код быть более по-
нятным? Может ли общий дизайн быть лучше? Есть ли шероховатости, которые
надо устранить?
Кроме того, уделите внимание потребностям вашего водителя. Людям, которые
не знакомы с IDE или кодовой базой, могут понадобиться конкретные рекомен-
дации. Но постарайтесь удержаться от микроменеджмента. Дайте людям свободу
разобраться самостоятельно, если они этого хотят.
Когда вы — штурман, ваша роль — помогать водителю быть более произво-
дительным. Думайте о том, что будет дальше, и будьте готовы дать рекомендации.
Когда я штурман, мне нравится держать перед собой индексную карточку. Вместо
того чтобы прерывать водителя, когда мне приходит что-то в голову, я записываю
идею на индексную карточку и жду перерыва в работе, чтобы вынести ее на об-
суждение. В конце сессии парного программирования я рву карточку и выбра-
сываю.
Подобным образом, когда возникает какой-то
вопрос, уделите время поиску ответов, прежде См. также
чем водитель продолжит работу. Некоторые
команды держат для этой цели отдельные но- Спайк-решения (глава 13)
утбуки. Если вам нужно больше, чем несколько
минут, то сделайте паузу в кодировании и поищите решение вместе. Иногда лучший
способ это сделать — разделиться, провести исследования, двигаясь параллельными
путями, и затем снова собраться вместе, чтобы поделиться тем, что удалось узнать.
Особенно эффективный подход — спайк-решения.
Хотя у штурмана обычно больше времени на раздумья, чем у водителя, это
не значит, что водитель — бездумный автомат. У него тоже могут быть идеи по ча-
сти дизайна. Поощряйте вашего водителя делиться своими мыслями, и когда у него
будут идеи на будущее, предложите записывать их. Кроме того, если вы столкнетесь
со сложным вопросом по дизайну, то будет разумным остановить написание кода,
взять доску и потратить немного времени на то, чтобы вместе проработать идеи.
Обучение при работе в паре

Хотя парное программирование больше всего подходит для взаимодействия на рав-
ных, иногда работать вместе приходится людям с разным уровнем опыта. В этой
ситуации важно восстановить равновесие между ними. Выделите навыки, которые
каждый человек привносит в работу. Даже если одному будет нужно обучать другого
коду, рассматривайте это как недостаток знаний, который легко восполнить, а не как
недостаток способностей со стороны обучаемого или знак превосходства со стороны
учителя.
Если вам нужно ввести вашего партнера
в курс дела по какой-то части кода, то по Цель в том, чтобы максимизировать
мните, что следует быть терпеливым. Обуче- производительность команды.
ние вашего партнера тому, как работает код,
замедляет вас, но цель не в том, чтобы максимизировать вашу производительность,
а в том, чтобы максимизировать производительность команды. Хороший разработчик
работает быстро и хорошо, но лучшие разработчики помогают так работать всем.
Чтобы научить кого-либо кодированию с помощью парного программирования,
начните с предоставления ему роли водителя. Это позволит ему контролировать
темп. Направляя его работу, воздерживайтесь от прямых указаний о том, что делать.
Вместо этого обрисуйте общую картину (может быть, даже начните с диаграммы на
доске) и предоставьте ему возможность разобраться с деталями.
Например, когда вносите изменения в сервис, не говорите: «Нам нужно изменить
SuperMailClient. Нажми на source, теперь на infrastructure, а теперь на rest…»
Вместо этого предоставьте контекст и направление: «Наша задача — изменить нашего
вендора транзакционной почты SuperMail на BetterMail. Они оба обеспечивают REST
APIs, так что все, что нам нужно сделать, — это изменить нашу обертку (wrapper)
SuperMail на использование BetterMail. (Рисует структуру проекта на доске.)
Все наши REST-клиенты находятся в папке infrastructure/rest, и каждый сервис
имеет собственную обертку». Затем позвольте вашему партнеру самостоятельно про-
смотреть файлы проекта и найти файл, с которым необходимо работать.
Как только человек, которого вы обучаете, сможет самостоятельно ориентировать-
ся, вы можете поменяться ролями. Попросите его (или ее) стать штурманом и сказать
вам, что нужно делать дальше. Однако будьте внимательны: когда вы окажетесь в роли
водителя, у вас появится желание вырваться вперед и просто делать то, что, как вы
знаете, нужно сделать. Чтобы это работало в качестве обучающей техники, вы должны
подавить это желание и позволить партнеру установить темп.
Трудности
Работа в паре поначалу может показаться неудобной или неприятной. Это естествен-
ное чувство, и обычно оно проходит через месяц или два. Ниже описаны несколько
обычных трудностей и способы их преодоления.
Удобство
Стоит повторить: парное программирование перестает быть удовольствием, если
вам неудобно. Когда вы садитесь за работу в паре, займите удобную позу, настройте
и оборудование, чтобы вам было комфортно. Уберите мусор со стола и обеспечьте
достаточно места для ног. Договоритесь с партнером о размере шрифта и располо-
жении монитора. Если вы работаете в паре в удаленном режиме, то перед началом
работы уделите время тому, чтобы убедиться, что весь инструментарий настроен
и работает безупречно.
Некоторым людям (вроде меня) нужно много личного пространства. Другим
нравится расположиться ближе. Когда вы начинаете работать в паре, обсудите ваши
потребности в личном пространстве с партнером и спросите о его запросах.
Интроверсия и социальное беспокойство

Интроверты часто беспокоятся, что парное программирование им не подойдет, но (сам
являясь интровертом) я обнаружил, что это не соответствует действительности. Рабо-
та в паре может утомлять, однако она очень сфокусирована на идеях и результатах.
Нет необходимости вступать в светские беседы, и вы обычно работаете с людьми, ко-
торых хорошо знаете и уважаете. Это очень продуктивное умственное взаимодействие,
к тому же оно может быть очень веселым. Большинство встреченных мною интровер-
тов, которые пробовали работать в парном программировании, полюбили его, как
только прошли начальную кривую обучения.
Конечно, люди не вписываются идеально
в предопределенные рамки личностных качеств. См. также
Парное программирование (и Agile в целом) мо-
жет оказаться сложным для людей с социальным
беспокойством. Если вы думаете, что парная
работа будет трудной для вас или для кого-либо в вашей команде, то обсудите спо-
собы сделать эту работу более комфортной или найдите другие варианты, с помощью
которых ваша команда может добиться коллективного владения кодом. Обсудить
все это можно во время сессии согласования.
Стиль коммуникации
Новым водителям иногда бывает трудно вовлекать своих партнеров: они берут под
свой контроль клавиатуру и полностью закрываются от общения. Чтобы попрак-
тиковаться в коммуникации и переключении ролей в парном программировании,
рассмотрите парную работу в стиле пинг-понг. В этом упражнении один человек
пишет тест. Другой выполняет его и пишет новый. Тогда первый человек выполняет
его и пишет новый тест, таким образом повторяя всю процедуру.
Еще один подход — попробовать работу в паре в сильном стиле. В этом подходе,
который изобрел Левелин Фалько, все идеи должны проходить через руки другого
человека [Falco2014]. Поэтому, когда у вас возникает идея, вы должны передать кла-
виатуру другому человеку и объяснить ему, как ее реализовать. Потом, когда у другого
человека возникает идея, он передает клавиатуру вам и объясняет, что делать. Даже
если вы не хотите делать так постоянно, это отличный способ попрактиковаться
в общении с вашим партнером.
Обратная сторона недостаточного общения — слишком много общения или,
скорее, слишком грубое общение. Откровенная критика кода или дизайна полезна,
но ее может быть трудно оценить поначалу. У разных людей разные пороги чувстви-
тельности, поэтому обратите внимание на то, как ваш партнер воспринимает ваши
комментарии. Попробуйте трансформировать заявления (такие как «Этот метод
слишком длинный») в вопросы или предложения («Не могли бы мы сделать этот
метод короче?»). Примите на вооружение подход совместного решения проблем.
Больше идей вы найдете в пункте «Научитесь принимать и давать обратную связь»
главы 7.
Инструменты и привязки клавиш

Даже если вы не падете жертвой бесконечных
войн редакторов «vi против emacs», вы можете См. также
посчитать раздражающими предпочтения ваших
коллег по части инструментов. Попробуйте вве-
сти стандарт на определенный инструментарий.
Некоторые команды даже создают стандартный образ и используют его в процедуре
контроля версий. Когда вы обсуждаете рабочие соглашения во время сессии согла-
сования, обсудите еще и эти вопросы.
Клавиатура и мышь могут быть еще одним источником раздоров. Если это так,
то не нужно вводить стандарт. Люди с жесткими предпочтениями устройств ввода-
вывода могут, меняя рабочие станции, переносить свои девайсы с собой. Только
обеспечьте свободный доступ к USB-портам.
Вопросы
Разве это не расточительно, когда два человека выполняют работу одного?
На самом деле в парном программировании два человека не делают работу одного.
В каждый момент времени используется только одна клавиатура, однако програм-
мирование — это больше чем набор кода. Один человек программирует, а другой
думает наперед, предвидит проблемы и разрабатывает стратегию.
Как мне убедить мою команду или организацию попробовать парное программи-
рование?
Попросите разрешения попробовать это в качестве эксперимента. Запланируйте
месяц, в течение которого все будут работать в парах над рабочим кодом. Сделайте
так, чтобы эксперимент обязательно продолжался целый месяц, поскольку парное
программирование может быть некомфортным первые несколько недель.
Не только попросите разрешения руководства; заручитесь также согласием ваших
коллег по команде. Необязательно, чтобы они полюбили эту идею, пусть хотя бы
не будут против нее.
Нам действительно нужно программировать парами все время? Некоторый код

этого не требует.
Некоторые производственные задачи
повторяются настолько часто, что для них Если вам скучно во время работы
не нужно дополнительной умственной энер- в паре — это верный признак
гии, которую обеспечивает парное програм- недостатков дизайна.
мирование. Однако, прежде чем отказаться
от парной работы, задумайтесь, почему ваш дизайн требует так много повторений.
Это обычный признак недостатков дизайна. Используйте свободное время штурмана
для размышлений над улучшением дизайна и рассмотрите возможность обсудить
это со всей командой.
Как я могу сконцентрироваться, когда кто-то со мной разговаривает?
Когда вы в роли штурмана, у вас не должно вызывать особых трудностей быть
на несколько шагов впереди вашего водителя. Если вам все же трудно, то попросите
вашего водителя думать вслух, чтобы вы понимали ход его мыслей, или попросите
вести, чтобы контролировать темп.
Пребывая в роли водителя, вы можете иногда обнаружить, что у вас не получа-
ется решить проблему. Дайте знать об этом вашему штурману — у него могут ока-
заться идеи, которые помогут преодолеть препятствие. В других случаях вам может
понадобиться всего лишь несколько минут тишины, чтобы обдумать проблему.
Вполне нормально сказать об этом.
Если вы часто оказываетесь в такой ситуации, то, возможно, предпринимаете
слишком большие шаги. Используйте разработку на основе тестирования и про-
двигайтесь очень маленькими шагами. По-
ложитесь на вашего штурмана, чтобы он См. также
отслеживал, что вам нужно сделать (скажи-
те ему, если у вас есть идея; он ее запишет), Разработка через тестирование
и сфокусируйтесь всего на нескольких стро- (глава 13)
ках кода, необходимых для успешного вы- Спайк-решения (глава 13)
полнения следующего теста.
Если вы работаете с технологией, ко-
торую не вполне понимаете, то потрать-
См. также
те несколько минут на разработку спайк-
решения. Вы и ваш партнер можете работать Групповое программирование
над ним вместе или по отдельности. (глава 12)
Что, если у нас нечетное количество про-
Обнаружение слепых зон (глава 16)
граммистов?
Если в вашей командной комнате есть Нулевое трение (глава 13)
станция для группового программирования,
то вы можете сформировать «мини-группу» из трех человек. Если нет, то существует
много других способов, позволяющих программисту-одиночке быть производи-
тельным, не притрагиваясь к рабочему коду. Он (или она) может исследовать новые
технологии или узнавать больше о технологии, которую использует команда. Они
могут работать в паре с заказчиком или тестировщиком, чтобы просматривать не-
давние изменения, совершенствовать приложение или проводить исследовательское
тестирование. Они могут взять на себя административные задачи команды, например,

отвечать на адресованные ей письма.
Другой вариант — программист-одиночка может захотеть улучшить потенциал
команды. Он может заняться исследованием различных несовершенств, беспокоящих
команду, таких как медленная сборка, нестабильные тесты или ненадежные цепочки
развертывания. Он может пересмотреть общий дизайн, либо чтобы улучшить свое
понимание, либо чтобы выдвинуть идеи по улучшению проблемных мест. Если
у команды имеется частично выполненный большой рефакторинг, то команда может
дать полномочия добросовестному программисту завершить его.
Работа в паре требует комфортной рабочей среды. Большинство офисов просто
не подготовлены к этому. Прежде чем пробовать парное программирование на полный
рабочий день, подготовьте свое физическое пространство. Если у вас виртуальная
команда, то подготовьте соответствующий инструментарий.
Убедитесь, что каждый хочет участвовать, прежде чем начнете эксперимент
с работой в парах. Она вносит большие изменения в рабочие стили программистов,
и вы можете встретить сопротивление. Я обычно стараюсь обойти эту проблему,
попросив людей попробовать месяц или два и потом решить. Если это не срабаты-
вает, то можно попробовать работать парами часть рабочего времени или только
с людьми, которые заинтересованы в этом. Однако я считаю, что парное програм-
мирование работает наилучшим образом, когда вся команда использует его полный
рабочий день.
Групповое программирование, как пра-
вило, менее пугающее, чем парное. Если См. также
люди не хотят пробовать работу в парах, то
проверьте, не понравится ли им идея попро- (глава 12)
бовать групповое программирование.
Когда ваша команда хорошо работает в парах:
zz вы сфокусированы и вовлечены в работу весь день;
zz вы наслаждаетесь духом товарищества, работая с вашими коллегами по команде;
zz в конце дня вы чувствуете усталость и удовлетворенность;
zz в случаях коротких прерываний один человек разбирается с проблемой, в то
время как другой продолжает работу. Затем они сразу же возвращаются в ра-
бочий режим;
zz улучшается внутреннее качество;
zz знания и советы по написанию кода быстро распространяются среди членов
команды, повышая уровень компетенции каждого;
zz новые члены команды интегрируются в команду быстро и легко.
Парное программирование — очень эффективный инструмент. За исключением
группового программирования, я не знаю другой техники, которая была бы столь же
эффективна. Сначала освойте парное (или групповое) программирование, прежде
чем экспериментировать с альтернативами.
Когда будете рассматривать альтернативы, не делайте ошибку, думая, что парное
программирование — всего лишь модный способ ревью кода. Чтобы действительно
заменить парное программирование, вам нужно заменить все преимущества, пере-
численные ниже.
Качество кода. Парное программирование привно-
сит в код много разнообразных точек зрения и приво- См. также
дит к множеству разговоров о коде, поэтому снижает
количество дефектов и улучшает качество дизайна. Коллективное владение
Частое переключение пар помогает распространению кодом (глава 12)
знаний среди членов команды, что укрепляет кол-
лективное владение кодом. Совместная работа помогает людям сфокусироваться,
поддерживает самодисциплину и уменьшает отвлекающие факторы. Всего этого
удается добиться, не принося в жертву производительность.
Формальные ревью кода также могут снизить дефекты, повысить качество и под-
держивать самодисциплину. В каком-то смысле парное программирование — это
непрерывное ревью кода. Однако при ревью нельзя делиться знаниями так же под-
робно, как при парной работе, поэтому если вы используете коллективное владение
кодом, то вам, вероятно, понадобится дополнить ревью кода обсуждениями дизайна.
Поток. Парное программирование дает потоку более тонкие преимущества.
Поскольку два человека сосредоточиваются на одной и той же проблеме, при объ-
единении в пару как будто появляется запасной мозг. Если один человек отвлекся,
то другой может «перезагрузить» его внимание и легко вернуть его назад, в нужное
русло. Кроме того, легче игнорировать вездесущие отвлекающие факторы, такие
как смартфоны, электронная почта, мессенджеры и прочие претенденты на ваше
внимание. Там, где не используется парная работа, вам понадобится другой способ
помочь людям оставаться сосредоточенными.
Взаимодействие. Устойчивость парного программирования к прерываниям
упрощает внутрикомандное взаимодействие. В идеале, когда один член команды
застревает на каком-то вопросе, на который может ответить другой член команды,
предпочтительнее, чтобы он обратился за помощью, а не «варился в собственном
соку». Если вы работаете в паре, то ответить на вопрос почти ничего не стоит, по-
скольку ваш партнер продолжает работу. Имеет смысл просить помощи каждый раз,
когда она вам нужна.
Если вы не работаете в паре, то прерывания обходятся гораздо дороже. Тут вы
должны принять решение, стоит ли время, сэкономленное благодаря ответу на во-
прос, прерывания чужого процесса. На практике в команде, не работающей в парном
программировании, гораздо меньше взаимодействия.
Меньше шума и осведомленность о происходящем. У парного программирования
есть еще одно преимущество, менее очевидное. В физической командной комнате при
парной работе возникает негромкий фоновый гул разговоров. Можно ожидать, что
это отвлекает, но на самом деле этот гул отступает на задний план, так как ваш мозг
фокусируется на взаимодействии с вашим партнером. Но фоновые разговоры все же
повышают вашу осведомленность о ситуации. Это эффект коктейльной вечеринки:
когда кто-то говорит что-то важное для вас, ваше подсознание выхватывает это из
фонового шума и выводит на уровень сознания.
Участников команд, не работающих в паре, сторонние разговоры отвлекают
и мешают концентрации. В этой ситуации отдельные офисы или перегородки-кубики
или наушники могут быть более подходящим вариантом. Но при этом вы не будете
осведомлены о ситуации.
Другими словами, парное программирование имеет множество неочевидных
преимуществ, подкрепляющих другие практики Agile. Оно определенно странное
и может вызывать много вопросов, однако точно стоит того, чтобы приложить уси-
лия и попробовать. Не сбрасывайте его со счетов. Если парное программирование
не подойдет, то попробуйте групповое программирование.

On Pair Programming Биргитты Бокелер и Нины Сиссеггер [Bockeler2020] — хорошая
онлайн-статья, в которой более подробно разбираются вопросы парного програм-
мирования.
В статье Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience [Belshee2005]
представлен занимательный взгляд на преимущества, которые дает переключение
пар через строгие интервалы времени.
В статье Adventures in Promiscuous Pairing: Seeking Beginner’s Mind [Lacey2006] ис-
следуются издержки и проблемы неупорядоченного переключения пар. Обязательна
для прочтения, если вы планируете попробовать подход Бельши.
ГРУППОВОЕ ПРОГРАММИРОВАНИЕ
Аудитория
Мы используем идеи всей команды.
Вся команда
В ранние годы экстремального программирования, когда
парное программирование только набирало популярность,
люди подшучивали над ним. «Если работать в паре хорошо, то почему бы и не попро-
бовать втроем! — смеялись они. — Или просто посадить всю команду перед одним
компьютером!»
Они пытались принизить ХР, но Agile — это путь экспериментов, обучения и со-
вершенствования. Вместо того чтобы предполагать, что что-то не будет работать, мы
просто ставим эксперимент. Некоторые эксперименты работают, некоторые — нет.
Так или иначе, мы делимся тем, что узнали.
Именно это и произошло с групповым программированием. У Вуди Зуилла была
групповая обучающая техника, которую он использовал для кодирования додзё. Его
команда в компании Hunter Industries оказалась в затруднительном положении. Они
решили попробовать групповую технику Вуди в реальной работе и посадили всю
команду перед одним компьютером.
Это сработало, и весьма хорошо. Вуди и команда поделились с другими тем, чему
научились. И теперь групповое программирование используется по всему миру.
В некоторых странах термин «групповое программирование» (mob programming)
имеет неприятный подтекст, поэтому люди называют эту практику «програм-
мирование в ансамбле» (ensemble programming). Оригинальное название, дан-
ное ей Вуди Зуиллом, было «программирование всей командой» (Whole Team
programming). Но он сказал: «Я всегда говорил: мне все равно, как это называется.
Хорошей командной работе стоит учиться, и я предлагаю людям называть это
так, как они хотят»1.
Как работать в групповом программировании

Групповое программирование — вариант пар-
ного программирования. Как и в паре, в нем См. также
есть водитель, который пишет код, и штур-
маны, которые предлагают направление. Парное программирование (глава 12)
В отличие от парного программирования,
присутствует вся команда. В то время как один человек выступает в роли водителя,
остальные члены команды отвечают за направления.
Вы можете попробовать любой подход группового программирования, кото-
рый вам нравится. Как сказал Вуди Зуилл, «нет никаких правил, кроме общей
рекомендации: “Давайте разберемся, как повысить нашу способность хорошо
взаимодействовать”»2. Экспериментируйте и выбирайте, что лучше для вас.
Для начала попробуйте подход Вуди Зуилла. Он начинает с присутствия всей
команды и ее готовности участвовать. Некоторые люди, такие как заказчики
в команде, могут не фокусироваться конкретно на программировании, но должны
быть готовы отвечать на вопросы и работают над теми же историями, что и про-
граммисты.
Поверх этой базы добавляется слой сильного стиля парного программирования
Левелина Фалько: все идеи должны проходить еще через чьи-то руки [Falco2014].
Когда приходит ваша очередь быть водителем, ваша работа — быть очень умным
устройством ввода. Насколько умным — зависит от степени вашего знакомства
с кодом и редактором. В одних случаях штурман может сказать: «А теперь обра-
батываем случаи ошибок» — и водитель сделает тестовый прогон четырех тестов
и соответствующий рабочий код, обойдясь без дальнейших подсказок. В других
случаях штурман может сказать: «Теперь извлеките метод» — и водителю придется
спросить, что вводить. Адаптируйте степень детализации к опыту каждого водителя
в кодировании и работе с инструментами.
И наконец, добавьте таймер. Для начала будет достаточно семи минут. Когда таймер
срабатывает, водитель останавливается. Другой человек берет клавиатуру и продолжает
1
Цитата из разговора с Вуди Зуиллом в Twitter (https://oreil.ly/RERXS).
2
Еще один отрывок из разговора с Вуди Зуиллом в Twitter (https://oreil.ly/UWIEK).
работу точно с того места, где остановился предыдущий водитель. Передавайте работу
таким образом по кругу через всех, кто интересуется программированием.
Почему групповое программирование работает

Групповое программирование работает, по-
скольку это простой режим взаимодействия. Групповое программирование —
Значительная часть Agile концентрируется простой режим взаимодействия.
на общении и взаимодействии. Это секрет-
ный соус, делающий Agile более эффективным, чем другие подходы. А групповое
программирование делает большинство практик взаимодействия Agile неактуаль-
ными. В них просто нет необходимости при групповом программировании.
Стендап-митинги? Прекращаются. Коллективное владение кодом? Автомати-
чески. Командная комната? Пара пустяков. Планирование задач? Все еще полезно,
но как-то необязательно.
Впервые услышав о групповом программировании, я жестко раскритиковал
его. «Я получаю те же преимущества благодаря кросс-функциональной команде,
командной комнате, работе в парах, частому переключению пар и хорошему взаи
модействию», — сказал я. И был прав. Групповое программирование не даст вам
ничего, чего бы вы еще не получили, имея хорошую команду. Но оно такое простое.
Собрать людей в пары и научить взаимодействовать — трудно. Групповое програм-
мирование? Оно получается практически автоматически.
Рабочая станция для группового программирования

Если у вас есть физическая командная комната, то организовать место для группового
программирования очень легко. Вам нужны проектор либо телевизор с большим
экраном (или несколько), столы, за которые люди могли бы сесть, и рабочая станция
уровня разработки. Убедитесь, что все могут сесть комфортно, имеют доступ к ком-
пьютерам и белым доскам (для поиска нужной информации и обсуждения идей)
и у них достаточно места, чтобы легко менять водителей. Некоторые команды имеют
в своем распоряжении станции и для группового, и для парного программирования,
чтобы люди могли переключаться туда-сюда по желанию.
Если у вас команда, работающая в удаленном режиме, то организуйте видеокон-
ференцию и попросите водителя показать свой экран. Когда приходит время сменить
водителя, он перемещает свой код во временную ветку, а следующий водитель забирает
его. Какой-нибудь скрипт, наподобие представленного на https://mob.sh, может помочь
в этом процессе. Вы можете обнаружить, что вам нужно больше времени (возможно,
десять минут вместо семи), чтобы уменьшить количество переключений.
Как заставить режим группового

программирования работать
Групповое программирование — это легко и весело, но все же работать вместе со
всей командой все дни напролет может быть утомительно. Нужно учесть несколько
важных моментов.
Динамики команды
Обратите внимание на взаимодействие членов
команды и сделайте так, чтобы голос каждого
был услышан. Установите рабочие соглашения, См. также
сделайте так, чтобы выражать несогласие и обес
покоенность было безопасно для людей, и об- Согласование (глава 7)
ратите внимание на динамики команды. Если Безопасность (глава 7)
кто-то склонен доминировать, то напомните
ему, что нужно давать высказаться другим; если
кому-то трудно высказываться, то спрашивайте
мнение таких людей.
Когда вы только начинаете использовать групповое программирование, стоит
потратить несколько минут в конце каждого дня на очень короткую ретроспективу.
Сфокусируйтесь на том, что хорошо работало и как делать этого больше. Вуди Зуилл
называет это «включить хорошее».
Энергичная работа
Групповое программирование не должно вас из-
матывать, но быть постоянно окруженным всей См. также
командой может быть несколько утомительным.
Позаботьтесь о себе. Вам не нужно быть вклю-
ченным в каждый момент времени.
Одно из преимуществ группового программирования заключается в том, что его
процесс не зависит от каждого. Люди могут выпадать из процесса и возвращаться по
необходимости. Если вам нужен перерыв на кофе или вы хотите просто развеяться,
то сделайте это. Точно так же, если вам нужно проверить свою почту или позвонить
по телефону, вы можете это сделать. Работа будет продолжаться без вас. Кроме того,
вам не нужно согласовывать свои рабочие часы.
Исследование
Все изменения в рабочем коде проходят через
водителя, но когда вы не в этой роли, вы тоже
можете использовать свой компьютер. Если вам См. также
нужно найти какой-либо запрос API, или по-
Спайк-решения (глава 13)
участвовать в параллельном обсуждении идеи
дизайна у доски, или создать спайк-решение, то
вы можете это сделать.
Строгая роль штурмана

Когда вы начинаете работать в режиме группового программирования, в вашей ко-
манде может быть столько людей, выкрикивающих разные идеи, что водителю может
оказаться трудно понять, что ему делать. В этом случае вместо того, чтобы назначать
в штурманы всю команду, вы можете выделить на эту роль одного человека. Она
может передаваться по кругу, как и роль водителя. (Мне нравится, когда водитель
становится следующим штурманом.) Его работа состоит в том, чтобы сконцентриро-
вать идеи всех, преобразовав их в конкретное направление для штурмана. Водитель
должен слушать только штурмана, а не всю группу.
Непрограммисты
Каждый в группе может быть водителем, даже люди, не умеющие программировать.
Для непрограммистов возможность развить новые навыки может стать увлекательной
перспективой. Возможно, они не станут экспертами, но узнают достаточно, чтобы
внести свой вклад в общее дело, а обучение роли водителя может улучшить их спо-
собность сотрудничать с программистами.
Помните о необходимости направлять вашего водителя на том уровне, которому
он способен следовать. Непрограммистам поначалу может потребоваться задавать
направление на уровне конкретных комбинаций клавиш, пунктов меню или кликов
мышью.
При этом никто не обязан быть водителем. Некоторые люди в команде могут
считать, что им лучше потратить свое время на какой-либо другой способ помочь
группе. Тестировщик и эксперт в предметной области могут вести сопутствующее
обсуждение примеров заказчика, относящихся к текущей истории. Продакт-менеджер
может отвлечься, чтобы провести интервью с важным стейкхолдером. Интерактивный
дизайнер может работать над персонами пользователей.
Как и во всем остальном, экспериментируйте, меняя уровень вовлеченности лю-
дей, чтобы понять, что лучше всего подходит вашей команде. Но лучше начинайте
с большей вовлеченности, а не с меньшей. Люди часто недооценивают всю силу ко-
мандной работы. Разговор о примерах заказчика, интервью со стейкхолдером или
работа над персоной пользователя может быть чем-то, чему группа учится благодаря
совместной работе.
Мини-группы и группы с неполной занятостью

Вам не нужно выбирать между парным
и групповым программированием. (Хотя См. также
я рекомендую работать только в одном или
другом режиме над всем кодом, который
вам нужно поддерживать.) Вы можете при- Стендап-митинги (глава 9)
менять групповой режим в течение части
рабочего времени и работать в парах в остальное время. Или вы можете сформиро-
вать мини-группу из трех-четырех человек, в то время как остальная часть команды
будет работать попарно.
Если вы не используете групповую активность все время, то установите, по край-
ней мере для начала, другие механизмы командной координации, такие как доска
задач и стендап-митинги. Сессии группового программирования могут помочь вам
синхронизироваться и без всего этого, но сначала убедитесь, что это так, прежде чем
отказаться от них.
Вопросы
Групповое программирование действительно эффективнее, чем работа поодиночке
или в парах?
Для новых команд почти наверняка. Эффективность команд зависит от того, на-
сколько хорошо участники знают код и друг друга, а групповое программирование
превосходит все остальные способы приобретения этого знания. Поэтому я реко-
мендую командам начинать с группового программирования (см. подраздел «Ваша
первая неделя» главы 9).
Для уже состоявшихся команд, по моему опыту, парное программирование более
эффективно, чем одиночная работа. Будет ли групповое программирование еще
более эффективно, чем парная работа? Для команд с хорошим командным помеще-
нием и отлично налаженным взаимодействием, возможно, нет. Для других команд,
вероятно, да. Здесь слишком много переменных, чтобы сказать наверняка, поэтому
попробуйте — и узнаете.
Нам бывает трудно помнить о необходимости менять водителей. Что нам
делать?
Если люди забывают о таймере, то попробуйте использовать инструменты типа
Mobster (доступен на http://mobster.cc). Когда время выходит, он гасит экран и во-
дитель вынужден остановиться.
Групповое программирование требует разрешения команды и руководства. Помимо
этого, единственным требованием являются комфортная рабочая среда и подходящая
организация групповой работы.
Когда ваша команда хорошо работает с практикой группового программирования:
zz вся команда направляет все свои усилия на одну историю за раз, завершая работу
с минимальными задержками и временем ожидания;
zz команда хорошо взаимодействует и работает друг с другом с удовольствием;
zz внутреннее качество улучшается;
zz когда возникает серьезная проблема, команда решает ее, в то время как водитель
продолжает двигаться вперед;
zz решения принимаются быстро и эффективно.
«Все блестящие умы в одном и том же месте в одно и то же время работают над од-
ним и тем же». Это центральная идея группового программирования. Сверх того,
все детали — на ваше усмотрение. Начните с базовой структуры, описанной здесь,
и ежедневно думайте над тем, что можно улучшить.
Если групповое программирование

не подходит, то лучшая альтернати- См. также
ва — парное программирование. В нем
нет того автоматического взаимодей- Парное программирование (глава 12)
ствия, которое есть в групповом про- Коллективное владение кодом (глава 12)
граммировании, поэтому вам придется
приложить больше усилий к коллек-
тивному владению, планированию Стендап-митинги (глава 9)
задач и стендап-митингам.

Книга Вуди Зуилла и Кевина Медоуза Mob Programming: A Whole Team Approach
[Zuill2021] содержит углубленный анализ «как» и «почему» в групповом програм-
мировании.
ЕДИНЫЙ ЯЗЫК
Аудитория
Все в нашей команде понимают друг друга.
Программисты
Попытайтесь объяснить бизнес-логику вашей теку-
щей системы экспертам в предметной области. Сможете
объяснить это в понятных им терминах? Сможете избежать программистских жар-
гонизмов, таких как названия структур дизайна, фреймворков, стилей кодирования?
Ваш эксперт в предметной области в состоянии определить потенциальные проблемы
в вашей бизнес-логике?
Если нет, то вам нужен единый язык. Это способ унификации терминов, которые ваша
команда использует в разговоре и коде, чтобы все могли эффективно взаимодействовать.
Дилемма экспертных знаний в предметной области

Одной из проблем профессиональной разработки ПО является то, что программисты
обычно не являются экспертами в той профессиональной области, для которой пи-
шут ПО. Например, я помогал писать ПО, которое управляет заводскими роботами;
руководит сложными финансовыми операциями; анализирует данные, получаемые
от научного оборудования; проводит актуарные расчеты. Начиная работать с этими
командами, я не знал ничего обо всех этих вещах.
Это дилемма. Люди, которые разбираются в проблемной области (эксперты
в предметной области), редко имеют квалификацию, необходимую для написания
программ. Люди, которые могут писать программы (программисты), не всегда по-
нимают что-либо в проблемной области.
Преодоление этой проблемы — фундаментальный
вопрос коммуникации. Эксперты в предметной области Задача — передать эти
передают свои знания программистам, которые, в свою знания ясно и точно.
очередь, кодируют эти знания в ПО. Задача — передать
эти знания ясно и точно.
Говорить на одном языке

Программисты должны говорить на языке экспертов в предметной области, а не
наоборот. В свою очередь, эксперты должны говорить программистам, когда язык,
который они используют, некорректен или запутывает.
Под «языком» я подразумеваю термины и определения, которые используют
ваши эксперты, а не буквально их родной язык. Представьте, что вы создаете про-
грамму для набора музыкальных партитур. Издательство, на которое вы работаете,
предоставляет описание музыки в XML, и вам необходимо правильно его отобразить.
Это трудная задача, наполненная на первый взгляд незначительными стилистиче-
скими выборами, которые жизненно важны для ваших заказчиков.
В этой ситуации вы можете сфокусироваться на элементах XML, родительских
элементах (parents), дочерних элементах (children) и атрибутах (attributes). Вы мо-
жете говорить о контекстах устройств, растровых изображениях и глифах. Если бы
вы это делали, то ваш разговор звучал бы примерно так:
Программист: Мы хотели бы узнать, как нам отображать этот ключевой элемент.
Например, если первый дочерний элемент — G, а второй — 2, а элемент измене-
ния октавы — это –1, то какой глиф нам использовать? Это скрипичный ключ?
Эксперт (думая про себя: «Я понятия не имею, о чем они говорят. Но если при-
знаюсь в этом, то они скажут в ответ что-то еще более непонятное. Лучше
подыграю».): Хм-м.. конечно, G — это скрипичный. Отлично.
Вместо этого сконцентрируйтесь на терминах предметной области, а не на тех-

нических:
Программист: Мы хотели бы узнать, как нам набирать этот ключ G. Он находится
на второй линии нотного стана, но на одну октаву ниже. Это скрипичный ключ?
Эксперт (думая про себя: «Ну это просто»): Он часто используется для партии
тенора в хоровой музыке. Это скрипичный ключ, да, но поскольку он октавой
ниже, мы используем два символа вместо одного. Я сейчас покажу вам пример.
Ответ эксперта во втором примере различается, поскольку он понял вопрос. Раз-

говор из первого примера, скорее всего, приведет к багу в ПО.
Как создать единый язык

Единый язык не возникает автоматически.
Вы должны над ним поработать. Когда го- См. также
ворите с экспертами в предметной области,
Примеры заказчика (глава 9)
слушайте, какие термины они используют.
Задавайте вопросы об их профессиональной
области, рисуйте диаграммы, представляющие модели того, что вы слышите, и про-
сите обратную связь. Сталкиваясь с трудными деталями, просите примеры.
Например, представьте, что вы впервые обсуждаете с экспертом в предметной
области программу для набора нот.
Программист: Я брал уроки фортепиано в детстве, поэтому знаю основы музы-

кальной грамоты. Но это было давно. Можете пройтись со мной по этой теме
с самого начала?
Эксперт: Мы набираем музыку для ансамблей и оркестров, так что это не со-
всем то же самое, что партитура для фортепиано, но ваш опыт будет полезен.
Начнем с основ: партитура делится на нотные станы, каждый стан делится на
такты, а ноты помещаются в такты.
Программист: Понял. То есть основа в нашей программе — партитура. (Рисует
квадрат и подписывает его «партитура».) Потом в каждой партитуре есть
нотные станы. (Добавляет квадрат, подписанный «нотный стан», и рисует
линию, соединяющую его с «партитурой».) В каждом нотном стане есть такты.
(Добавляет еще один квадрат, подписанный «такт», и соединяете его с «нотным
станом».) Сколько нотных станов может быть в партитуре?
Эксперт: Это зависит от аранжировки. Четыре — для струнного квартета. Дюжина
или больше — для оркестра.
Программист: Но должен быть по меньшей мере один?
Эксперт: Думаю, да. Партитура без хотя бы одного нотного стана не имеет смыс-
ла. У каждого инструмента должен быть нотный стан или несколько в случае
инструментов с большим диапазоном, таких как пианино и орган.
Программист: Окей, я немного запутался. У вас есть примеры, которые я мог бы
посмотреть?
Эксперт: Конечно. (Достает пример1.) Вот здесь наверху вы можете увидеть
хор. Тут есть нотный стан для каждой партии, которую можно считать тем же,
что и инструмент: сопрано, альт, тенор и бас. Потом идет большой нотный стан
для арфы, большой и обычный нотные станы для органа и т. д.
Программист (корректируя свой набросок на доске): То есть мы начинаем
с партитуры, у каждой партитуры есть несколько инструментов, и у каждого
инструмента — один или несколько нотных станов, и нотный стан может быть
обычный или большой. И еще похоже, что инструменты могут быть сгруппи-
рованы.
Эксперт: Верно, мне следовало это сказать. Инструменты могут быть сгруп-
пированы в секции. Знаете, секция струнных инструментов, духовая секция.
Программист (снова корректируя свой набросок): Понял. У нотного стана есть
секции, в секциях есть инструменты и потом все остальное.
Эксперт (смотрит на рисунок): Это только начало, многого пока не хватает.
Нам нужны ключ, тональность и тактовый размер…
Результат этого разговора — нечто гораздо большее, чем просто набросок на дос
ке. Он также может стать основой модели предметной области [Fowler2002] (гл. 9)
в вашем коде. Она нужна не для каждой программы, но если ПО вашей команды
подразумевает сложные правила предметной области, то данная модель — эффек-
тивный инструмент разработки.
1
Вот здесь есть пример нот для оркестра: https://oreil.ly/HP5Zp.
Конечно, вы не планируете буквально программировать на языке эксперта в пред-

метной области. Вы будете использовать язык программирования. Но вы будете
создавать свои модули, функции, классы и методы так, чтобы они моделировали
образ мышления ваших экспертов. Отражая в коде то, как пользователи думают
и говорят о своей работе, вы оттачиваете свои знания, выявляете пробелы, которые
иначе привели бы к багам в ПО, и создаете гибкую систему, способную реагировать
на изменения, которые захотят внести ваши пользователи.
Продолжим рассматривать пример. Программа для набора музыкальных партитур
на основе вводных данных XML могла быть спроектирована в концепциях XML.
Однако лучше будет спроектировать ее в концепциях предметной области (рис. 12.1).
Рис. 12.1. XML и предметно-ориентированное проектирование
Код не должен быть двусмысленным. Такая необходимость в жесткой форма-

лизации приводит к большему количеству обсуждений и проясняет непонятные
детали. Я часто вижу ситуации, в которых программисты сталкиваются со сложной
проблемой дизайна, задают вопрос эксперту в предметной области, и это, в свою
очередь, приводит к тому, что эксперт ставит под сомнение некоторые из их изна-
чальных предположений.
Таким образом, ваш единый язык — это живой язык. Он хорош настолько, на-
сколько хороша его способность отражать реальность. Как только проясните все
детали с экспертами, закодируйте все, что узнали, в свою модель предметной области.
Если она выявляет двусмысленности, то обращайтесь к экспертам, чтобы их про-
яснить.
В ходе работы удостоверяйтесь, что ваш ди-
зайн и язык, который вы разделяете с экспертами,
См. также
синхронизированы. Делайте рефакторинг кода,
когда меняется ваше понимание предметной об- Рефакторинг (глава 13)
ласти. Если этого не делать, то в итоге ваш дизайн
не будет соответствовать реальности, что приведет
к уродливым ляпам и багам.
Вопросы
Должны ли мы все вместе избегать использования технических терминов? В нашей
предметной области бизнеса не упоминается ничего о GUI-виджетах или базе данных.
Нормально использовать технический язык в тех областях, которые не имеют
отношения к предметной области. Например, возможно, имеет смысл называть под-
ключение к базе данных подключением, кнопку UI — кнопкой.
Как нам документировать наш единый язык?
В идеале вы кодируете свой единый язык в реальном дизайне вашего ПО с по-
мощью модели предметной области. Если это не подходит, то вы можете задокумен-
тировать вашу модель на доске (можно на виртуальной), в общем документе или на
Вики-странице. Однако будьте осторожны: поддержание этого типа документации
в актуальном состоянии требует большого внимания.
Преимущество использования кода для документа-
ции заключается в том, что код не может не отражать См. также
то, что ваше ПО делает на самом деле. С некоторой
долей осторожности вы можете разработать свой код Простой дизайн (глава 14)
так, чтобы он был самодокументированным.
Мы программируем на английском, но это не наш родной язык, и наши эксперты
в предметной области его не используют. Нужно ли нам переводить их термины на
английский, чтобы единообразить с остальным нашим кодом?
На ваше усмотрение. С одной стороны, слова не всегда переводятся напрямую,
поэтому использование языка вашего эксперта в предметной области, вероятно, будет
приводить к меньшему количеству ошибок, особенно если эксперты могут слушать
и участвовать в разговорах программистов. С другой стороны, единообразие может
облегчить другим работу с вашим кодом в будущем.
Если вы решите переводить термины вашего эксперта на английский (или другой
язык), то создайте словарь перевода для слов, которые используете, особенно для
тех, перевод которых затруднен.
Если в вашей команде нет ни одного эксперта в пред-
метной области, то вам может быть трудно понять
эту область настолько глубоко, чтобы создать единый См. также
язык. Однако попытки это сделать в данной ситуации
даже еще важнее. Когда у вас есть возможность гово-
рить с экспертом, единый язык поможет вам быстрее
обнаружить недопонимание.
В то же время некоторые проблемы настолько технические, что не касаются знаний
в области, отличной от программирования. Компиляторы и веб-серверы — примеры
из этой категории. Если вы разрабатываете этот вид ПО, то языком программиро-
вания является язык предметной области.
У некоторых команд нет опыта в создании моделей предметной области
и предметно-ориентированных дизайнов. Если это ваш случай, то будьте осто-
рожны. Предметно-ориентированные дизайны требуют изменения мышления,
что может быть непросто. Для начала изучите подраздел «Литература для допол-
нительного чтения» и подумайте о том, чтобы нанять коуча, который поможет вам
в обучении.
Когда ваша команда имеет работающий единый язык:
zz вы уменьшаете недопонимание между клиентами и программистами;
zz вы производите код, который легко понимать, обсуждать и изменять;
zz при личном общении с командой в офисе эксперты слышат обсуждения между
представителями предметной области и отдела реализации. Они присоединяются,
чтобы решить вопросы и выявить скрытые допущения.
Говорить на языке экспертов предметной области — это всегда хорошая идея, но
предметно-ориентированное проектирование — не всегда хороший выбор. Иногда
ориентированное на технологию проектирование более простое. Это чаще всего так,
когда ваши правила предметной области не очень сложные. Однако будьте осторожны:
правила этой области могут быть более сложными, чем кажется на первый взгляд,
и в этом случае ориентированное на технологию проектирование, как правило, имеет
дефекты и высокие затраты на техническое обслуживание. Дальнейшее обсуждение
этого компромисса см. в [Fowler2002].
Другой способ сформировать общее понимание предметной области — исполь-
зовать метод штурма событий (event storming) Альберто Брандолини, который на-
чинается с событий, случающихся в предметной области, а не с имен и отношений
в ее модели. На момент написания этой книги каноническая книга Event Storming
все еще писалась, но на странице https://www.eventstorming.com есть указатели на до-
полнительные ресурсы.

Domain-Driven Design: Tackling Complexity in the Heart of Software1 [Evans2003] — исчер-
пывающее руководство по созданию предметно-ориентированного проектирования.
Глава 2, Communication and the Use of Language, послужила источником вдохновения
для этой практики.
В Patterns of Enterprise Application Architecture2 [Fowler2002] содержится хоро-
шая дискуссия о компромиссах между моделями предметной области и другими
архитектурными подходами в главе 2 (Organizing Domain Logic) и главе 9 (Domain
Logic Patterns).
1
Эванс Э. Предметно-ориентированное проектирование (DDD). Структуризация сложных про-
граммных систем.
2
Фаулер М. Шаблоны корпоративных приложений.
ГЛАВА 13
Разработка
Это поразительно, насколько редко процессы разработки ПО на самом деле говорят

о практических деталях разработки. Способ, которым ваша команда ведет разработку,
имеет значение. Именно так вы проводите бо́льшую часть вашего времени.
Эта глава содержит практики, которые могут ускорить вашу разработку и сделать
ее более надежной.
zz Практика «Нулевое трение» позволяет ликвидировать задержки, замедляющие
процесс разработки.
zz Практика «Непрерывная интеграция» обеспечивает готовность вашего послед-
него кода к релизу.
zz С помощью практики «Разработка через тестирование » вы сможете делать так,
чтобы ваше ПО выполняло именно то, что от него хотят программисты.
zz Благодаря практике «Быстрые надежные тесты» тестирование не станет узким
местом.
zz Практика «Рефакторинг» позволяет программистам улучшить дизайн существу-
ющего кода.
zz Практика «Спайк-решения» помогает программистам учиться с помощью не-
больших изолированных экспериментов.
Источники разработки
Впервые я столкнулся с практиками, описанными в этой главе, в экстремальном
программировании. Некоторые из них отсутствуют в оригинальных книгах об
XP; вместо этого они упоминались в обсуждениях XP на Вики-страницах Уорда
Каннингема на c2.com.
Практика «Нулевое трение» — это современная версия «Десятиминутной сборки»
в XP.
Практика «Непрерывная интеграция» также пришла из XP. Ее обычно понимают
не совсем верно, поэтому придумывают для нее новые названия (особенно по-
пулярны «магистральная разработка» (trunk-based development) и «непрерывная
поставка» (continuous delivery)), но непрерывная интеграция в том виде, в котором
ее определяет XP, охватывает оба варианта [Beck2004] (гл. 7).
Практика «Разработка через тестирование» — одна из самых известных практик

XP. Изначально она называлась Test-First Programming. Связанная с ней практика
«Быстрые надежные тесты» основана на моем опыте реального применения TDD
в течение последних двух десятилетий, наряду с изрядной дозой вдохновения
и идей, заимствованных из широкого сообщества Agile.
Практика «Рефакторинг» предшествовала XP, но XP вывело ее в мейнстрим как
основную.
Практика «Спайк-решения» пришла из языка шаблонов EPISODES Уорда Каннингема
[Cunningham1995]. Она основана на опыте его работы с Кентом Беком в Tektronix.
Уорд Каннингем написал на Вики-странице на C2: «Я часто спрашивал Кента: “Какую
простейшую вещь мы можем запрограммировать, которая убедит нас в том, что мы
на правильном пути?” Такой выход за пределы имеющихся трудностей часто вел нас
к более простым и убедительным решениям. Кент назвал этот процесс спайком»1.
НУЛЕВОЕ ТРЕНИЕ Аудитория
Программисты, отдел эксплуатации

Когда мы готовы писать код, ничто
не может нам помешать.
Представьте, что вы только начали работать с новой командой. Один из ваших
новых товарищей по команде, Педро, сопровождает вас к рабочей станции разра-
ботчиков.
— Так как ты новенький, мы начнем с развертывания маленького изменения, —
говорит он, усаживаясь рядом. — Эта машина абсолютно новая, поэтому нам придется
настроить ее с нуля. Сначала клонируем репо. — Он говорит вам команду. — Теперь
запускаем скрипт build.
Команды начинают бежать по экрану.
— Мы используем программный инструмент для воспроизводимых сборок, —
объясняет Педро. — Он определил, что у нас ничего не установлено, поэтому он ин-
сталлирует IDE, инструментарий разработки и образы, необходимые для разработки
и локального запуска системы.
— Это займет некоторое время, — продолжает он. — Однако после первого запуска
это происходит мгновенно. Инструмент снова обновляется только тогда, когда мы
вносим изменения в конфигурацию. Давай я покажу тебе офис.
Когда вы возвращаетесь, сборка завершена.
— Окей, давай я покажу тебе приложение, — говорит Педро. — Набери rundev,
чтобы запустить его.
Информация снова начинает бежать по экрану.
— Все это запускается локально, — гордо объясняет Педро. — Раньше у нас была
общая тестовая среда, и мы постоянно наступали друг другу на пятки. Теперь это все
1
Выдержка из спайк-решений на странице https://oreil.ly/QUTY6.
Глава 13. Разработка 439
в прошлом. Сборка даже знает, какие сервисы запускать повторно в зависимости от

того, какие файлы меняешь.
Педро показывает вам приложение.
— Теперь внесем изменения. Запусти watch quick. Он создаст и протестирует
файлы, которые мы изменяем.
Вы выполняете его инструкции, скрипт начинает работу и сразу выдает BUILD OK
зеленым цветом.
— Ничего не менялось с момента последнего запуска сборки, — объясняет Педро. —
Поэтому скрипт ничего не сделал. Теперь внесем небольшое изменение.
Он направляет вас к тестовому файлу, и вы добавляете тест. Когда вы сохраняете
изменения, скрипт watch снова запускается и сообщает о сбое теста. Это занимает
меньше секунды.
— Мы очень много работали над скоростью нашей сборки и тестирования, — го-
ворит вам Педро. Он явно гордится этим. — Это было непросто, но оно того стоило.
Мы получаем обратную связь о большинстве изменений через секунду или две. Это
сотворило чудеса с нашей способностью работать итерациями и быть продуктивными.
Я не совру, если скажу, что это лучшая среда разработки из всех, в каких я только
работал. Теперь завершим эти изменения и сделаем развертывание.
Педро показывает вам изменения, которые необходимо внести для прохождения
нового теста. Когда вы сохраняете изменения, скрипт watch снова запускает тесты
примерно через секунду. В этот раз он сообщает об успешном результате.
— Окей, теперь мы готовы к развертыванию, — говорит Педро. — Это пойдет
в эксплуатационную среду, но не волнуйся. Скрипт deploy запустит полный набор
тестов, и у нас также есть канареечный сервер, который проверяет, чтобы не случи-
лось ничего плохого. Набери deploy, чтобы начать.
Вы запускаете скрипт и наблюдаете за его работой. Через несколько минут он
выдает сообщение INTEGRATION OK, затем начинает развертывать код. «Все, — сияя,
говорит Педро. — Когда интеграция проходит успешно, можно предполагать, что
развертывание тоже будет успешным. Если что-то пойдет не так, то мы получим
сообщение. Добро пожаловать в команду!»
Прошло меньше часа, а вы уже выполнили развертывание в эксплуатационную
среду. Это разработка с нулевым трением: когда вы готовы писать код, ничто не мо-
жет встать у вас на пути.
Обратная связь за секунду

Скорость разработки — та область, где устра-
нять трение очень важно. Когда вы вносите Когда вы вносите изменение, вам
изменение, вам нужно получить обратную нужно получить обратную связь
связь об этом изменении менее чем через пять менее чем через пять секунд.
секунд. Лучше — менее чем через одну секунду.
Самое большое — десять.
Этот вид быстрой обратной связи меняет все. Вам легко экспериментировать
и работать итерациями. Вместо того чтобы вносить большие изменения, вы можете
работать очень маленькими шагами. Каждое изменение может состоять всего из
одной или двух строчек кода, а это значит, вы всегда знаете, где у вас ошибки. Отладка
становится чем-то из прошлого.
Если обратная связь занимает меньше секунды, то она функционально мгновен-
на. Вы вносите изменение, смотрите на отклик и продолжаете работу. Если на это
уходит от одной до пяти секунд, то процесс, по ощущениям, не будет мгновенным,
но все еще приемлемым. Если на все уходит от пяти до десяти секунд, то процесс
будет ощущаться как медленный. Вы начнете испытывать соблазн сгруппировать
изменения. А если обратная связь будет занимать больше десяти секунд, то вы
не сможете продвигаться маленькими шагами, и это будет вас замедлять.
Чтобы достичь секундной обратной свя-
зи, установите скрипт watch, который будет
автоматически проверять ваш код, когда См. также
вы внесете изменение. Внутри скрипта ис-
пользуйте компилятор или линтер, кото- Разработка через тестирование
(глава 13)
рый будет сообщать вам о синтаксических
ошибках, и тесты, которые будут сообщать
о семантических ошибках.
В качестве альтернативы вы можете настроить вашу IDE на проверку синтаксиса
и запуск тестов, а не на написание скрипта. Это может быть простым способом на-
чать работу, хотя в конечном итоге вам придется перейти на скрипт. Если вы начнете
с подхода на основе IDE, то убедитесь, что его конфигурацию можно передать в ваш
репозиторий и использовать всеми в команде. Вам понадобится возможность легко
делиться усовершенствованиями.
Когда вы сохраняете изменения, скрипт (или IDE) должен давать вам немедлен-
ную и недвусмысленную обратную связь. Если все работает, то он должен выдать
сообщение ÎÊ. Если что-то не так, то он должен выдать сообщение FAILED и предо-
ставить информацию, которая поможет вам решить проблему. Большинство людей
настраивает свои инструменты так, чтобы они показывали зеленую полосу в случае
успеха и красную — в случае неудачи. Вдобавок к этому я программирую свои ин-
струменты так, чтобы они издавали какие-либо звуки (один звук для ошибок ком-
пилятора/линтера, другой — для ошибок в тесте и третий — для успешного завер-
шения), но так делаю только я.
По мере расширения вашей кодовой
базы добиться секундной обратной связи См. также
станет труднее. Обычно первый виновник —
скорость тестирования. Сконцентрируйтесь Быстрые надежные тесты (глава 13)
на написании быстрых надежных тестов.
По мере продолжения роста вашей системы скорость сборки (компиляция или
линтинг) станет проблемой. Решение будет зависеть от вашего языка. Поиск в сети
по фразе «ускорить сборку <язык>» поможет вам начать. Обычно это будет под-
разумевать поэтапные (инкрементальные) сборки: кеширование части сборки так,
чтобы перестраивался только код, в который внесли изменения. Чем больше будет
становиться ваша система, тем более креативными вам нужно быть.
В конце концов вам, вероятно, понадобится сконфигурировать две сборки: одну
для быстрой обратной связи и другую для развертывания в эксплуатационную среду.
Хотя желательно, чтобы ваша локальная

сборка была такая же, как и сборка для экс- См. также
плуатационной среды, быстрая обратная
связь важнее. Ваш интеграционный скрипт Непрерывная интеграция (глава 13)
может прогонять ваши тесты в сборке для
эксплуатационной среды. Пока у вас есть хороший набор тестов и вы практикуете
непрерывную интеграцию, вы будете узнавать о расхождениях между двумя сборками,
прежде чем у них может появиться шанс выйти из-под контроля.
Хорошие тесты запускаются со скоростью сотен или тысяч в секунду, однако у вас
в конце концов окажется слишком много тестов, которые надо будет запускать
менее чем в секунду. Когда это случится, вам понадобится исправить свой скрипт,
чтобы он запускал только подгруппу тестов. Самый простой способ — сгруппировать
тесты в кластеры и запускать конкретные кластеры, основываясь на измененных
файлах.
В конце концов, вы можете захотеть сделать более утонченный анализ зависи-
мостей, точно обнаруживающий, какие тесты запускать для данного изменения.
Некоторые исполнители тестов (test runners) могут делать это за вас. К тому же
их не настолько сложно внедрить, как вы можете подумать. Хитрость в том, чтобы
сфокусироваться на том, что нужно вашей команде, а не на создании общего решения,
обрабатывающего все возможные граничные случаи.
Знайте свой редактор

Не давайте вашему редактору кода мешать вашему потоку мыслей. Это особенно
важно в парном или групповом программировании: когда вы штурман, мало что
может расстраивать больше, чем наблюдение за тем, как водитель борется с ре-
дактором.
Не жалейте времени, чтобы научиться пользоваться вашим редактором действи-
тельно хорошо. Если в редакторе доступен автоматизированный рефакторинг, то
узнайте, как им пользоваться. (Если нет, то поищите редактор получше.) Используйте
преимущества автоформатирования и отправляйте конфигурационный файл фор-
матирования в ваш репозиторий, чтобы вся ваша команда была синхронизирована.
Научитесь использовать автодополнение кода, автоматические исправления, поиск
функций и методов и навигацию по справочным материалам. Выучите комбинации
горячих клавиш.
Чтобы увидеть примеры того, насколько может улучшить жизнь хорошее владе-
ние редактором, посмотрите виртуозное представление Эмили Бач в ее видео Gilded
Rose, особенно часть 2 [Bache2018].
Воспроизводимые сборки
Что происходит, когда вы проверяете произвольный коммит из вашего репози-
тория? Скажем, годичной давности. (Попробуйте!) Он все еще работает? А тесты
проходят? Или он требует какой-то эзотерической комбинации из инструментов
и внешних сервисов, которые уже канули в Лету?
Воспроизводимая сборка — это сборка,

которая продолжает работать и прохо- Каждое подтверждение (коммит)
дить свои тесты независимо от того, ка- должно работать одинаково у любого
разработчика.
кие средства разработки вы используете
и сколько лет коду, сборку которого вы
выполняете. У вас должна быть возможность проверить любой коммит и ожидать,
что он будет работать одинаково у любого разработчика. Вообще говоря, это требует
двух вещей.
Управление зависимостями
Зависимости (dependencies) — это библиотеки и программные инструменты,
которые нужны вашему коду для работы. Сюда входят компилятор или интер-
претатор, среда времени выполнения, пакеты, скачанные из вашего репозитория
пакетов языков, код, написанный другими командами в вашей организации, и т. д.
Чтобы ваша сборка была воспроизводимой, каждому нужно иметь одни и те же
зависимости.
Программируйте вашу сборку так, чтобы обеспечить корректную версию каждой
зависимости. Она может или выдавать ошибку, когда установлена некорректная вер-
сия, или (что предпочтительнее) автоматически устанавливать правильную версию.
Среди инструментов, которые это делают, — Nix, Bazel и Docker. Проверьте также
версию вашего инструмента управления зависимостями.
Простой способ сделать так, чтобы ваше ПО имело корректные зависимости, —
поместить их в ваш репозиторий. Это называется вендорингом (vendoring). Вы можете
смешать два подхода: например, команда с кодовой базой Node.js сделала вендоринг
для своего каталога node_modules, но не сделала Node исполнимым. Вместо этого
они запрограммировали свою сборку так, чтобы она давала сбой, если работала не-
правильная версия Node.
Локальные сборки
Управление зависимостями обеспечивает одинаковую работу вашего кода на любой
машине, но не делает того же для ваших тестов. Ваши тесты должны запускаться
полностью локально, не связываясь через сеть. Иначе у вас, вероятно, будут противо-
речивые результаты, когда два человека делают тесты одновременно, и вы не сможете
тестировать старые версии. Сервисы и данные, от которых они зависят, изменятся,
и тесты, которые раньше проходили, станут сбоить.
То же самое верно для случаев, когда вы запускаете код вручную. Чтобы получать
непротиворечивые результаты и иметь возможность запускать старые версии, все,
от чего зависит код, должно быть инсталлировано локально.
Могут быть какие-то зависимости, которые невозможно запустить локально.
В таком случае вам нужно запрограммировать свои тесты, чтобы они работали неза-
висимо от этих зависимостей, или у вас может не быть возможности воспроизвести
результаты своих тестов в будущем. В подразделе «Моделирование нелокальных
зависимостей» далее в текущей главе описывается, как это сделать.
Пятиминутная интеграция
Если вы используете непрерывную интеграцию, то будете интегрировать несколько
раз в день. Данный процесс должен быть сверхнадежным и быстрым. Это значит, для
него нужен скрипт. Ваш скрипт должен выдавать успешный или неуспешный результат
в течение пяти минут — максимум десяти.
Пятиминутные результаты на удивле-
ние важны. Пяти минут достаточно для не- См. также
большого перерыва и новой чашки кофе,
пока вы следите за результатами. Десять Непрерывная интеграция (глава 13)
минут — терпимо, но начинает наскучивать.
Больше — и люди начнут работать над другими задачами, пока дожидаются полу-
чения результатов. Далее, если интеграция неуспешна, код останется в подвешенном
состоянии, пока кто-нибудь к нему не вернется. На практике это ведет к системной
интеграции и проблемам сборки.
Не нужно, чтобы скрипт буквально завершался за пять минут, хотя это и жела-
тельно. Вместо этого он должен проверять код и выдавать успешный или неуспеш-
ный результат, прежде чем переходить к более длительным проверкам. В подразделе
«Многоступенчатые интеграционные сборки» далее в текущей главе объясняется,
как это работает.
Большинство команд не могут исполь-
См. также
зовать пятиминутную интеграцию именно
из-за скорости набора тестов. Решение — ис- Быстрые надежные тесты (глава 13)
пользовать быстрые надежные тесты.
Оптимизировать для сопровождения

Код пишется один раз, а читается и изменяется снова и снова. В профессиональной
среде разработки вы чаще будете смотреть измененный код, который написал
кто-то другой (или код, который вы написали давно), чем писать новый. Даже если
вы пишете новый код, его нужно будет сопровождать в течение нескольких лет.
В результате гораздо важнее снизить затраты на сопровождение, чем облегчить
написание нового кода.
Это имеет далекоидущие последствия. Фреймворк, который облегчает соз-
дание ПО, но при этом сложен для понимания и не очень хорошо интегри-
руется с другими системами, — плохой выбор. Инструмент сборки, который
автоматически управляет всем, что вам нужно на данный момент, но который
нельзя расширить, не имея глубоких знаний его внутреннего устройства, — тоже
плохой вариант.
Оптимизация для сопровождения означает выбор простых инструментов и биб
лиотек, которые легко понять, собрать и заменить, когда они больше не соот-
ветствуют вашим потребностям.
Контролировать сложность
Часто упускаемый из виду источник трения команд
разработки — сложность их среды разработки. См. также
Стремясь сделать работу быстро, команды вы-
бирают популярные инструменты, библиотеки Простой дизайн (глава 14)
и фреймворки, чтобы решать общие проблемы
разработки.
По отдельности в этих инструментах нет ничего плохого. Но любой длительный
процесс программной разработки должен иметь специализированные инструменты,
и именно здесь быстрый и простой подход начинает подводить. Все эти инструмен-
ты, библиотеки и фреймворки создают огромную когнитивную нагрузку, особенно
когда вам нужно погрузиться в их внутреннее устройство, чтобы заставить слаженно
работать вместе. В конечном итоге все это добавляет трения.
Гораздо важнее оптимизировать затраты на сопровождение, чем на изначальную
разработку, как объяснялось во врезке «Оптимизировать для сопровождения» ранее
в данной главе. Будьте внимательны к сторонним зависимостям, которые вы ис-
пользуете. Выбирая одну из них, думайте не только о проблеме, которую она решает;
думайте о нагрузке на сопровождение, которую добавит эта зависимость, и о том,
насколько хорошо она будет встраиваться в существующие системы. Простой ин-
струмент или библиотека, которые могут вызывать ваши скрипты, будут отличным
вариантом. Сложный «черный ящик» — вероятно, нет.
В большинстве случаев лучше всего обернуть сторонний инструмент или библио
теку в код, который вы контролируете. Задача вашего кода — скрыть базовую
сложность и представить простой интерфейс, адаптированный под ваши потреб-
ности. В подразделе «Сторонние компоненты» главы 14 можно найти дальнейшие
пояснения.
Автоматизировать все
Автоматизируйте любое действие, которое команда выполняет неоднократно. Это
не только снизит трение, но и уменьшит вероятность ошибок. Для начала это озна-
чает пять скриптов:
zz build — использовать компилятор и/или линтер, запускать тесты и сообщать об
успехе или неудаче;
zz watch — автоматически запускать build при изменении файла;
zz integrate — запускать build в среде, идентичной эксплуатационной, и интегри-
ровать свой код;
zz deploy — запускать integrate, затем разворачивать интеграционную ветку;
zz rundev — запускать ПО локально для оценки и тестирования вручную.
Конечно, вы можете использовать любые имена, какие захотите.
Используйте реальный язык программирования для ваших скриптов. Они могут
обращаться к инструментам, часть которых может иметь собственные конфигу-
рационные языки, но организуйте их все с помощью реального кода, которым вы
управляете. По мере того как ваша автоматизация будет усложняться, вы оцените,

насколько эффективен реальный язык программирования.
Обращайтесь с вашими скриптами так же бережно, как и с реальным рабочим
кодом. Вам не нужно писать тесты для них — скрипты может быть очень трудно
тестировать, — но уделяйте внимание тому, чтобы они были хорошо написаны и про-
думаны и их было легко понять. Позже вы себя за это будете благодарить.
У вас может появиться соблазн использовать свою IDE вместо скрипта watch.
Для начала это нормально, но вам все равно понадобится автоматизировать вашу
сборку для скрипта integrate, поэтому в итоге вы можете прийти к необходимо-
сти сопровождать две отдельные сборки. Кроме того, остерегайтесь блокировки:
в конечном итоге IDE не сможет обеспечивать секундную обратную связь. Когда
это происходит, вместо того чтобы бороться с IDE, переключитесь на подходящий
подход на основе скриптов. Он более гибкий.
Автоматизируйте инкрементно
Совершенствуйте вашу автоматизацию непрерывно и инкрементно (инкрементами),
начиная с самой первой истории. В абсолютно новой кодовой базе это означает, что
вашей первой задачей разработки станет настройка скриптов.
Придерживайтесь простой автоматизации. Поначалу вам не нужны сложные
инкрементные сборки или анализ графов зависимостей. Прежде чем вы напишете
любой код, начните с написания скрипта build, который будет просто отвечать
build OK. И ничего больше! Это как hello world для вашей сборки. Потом напиши-
те скрипт watch, который не делает ничего, кроме запуска build при изменении
файлов.
Когда заработают build и watch, создайте подобным образом пустой скрипт
integrate. Поначалу ему нужно будет только запустить build в первозданной среде
и интегрировать ваш код. В подразделе «Танец непрерывной интеграции» далее
в текущей главе описывается, как это работает.
Когда заработает скрипт integrate, вы готовы конкретизировать build. Напиши-
те ничего не выполняющий код входной точки для вашего приложения. Он может
просто говорить Hello world. Запустите build, чтобы скомпилировать сборку или
выполнить линтинг, потом добавьте управление зависимостями для компилятора или
линтера. Для начала оно может проверять номер версии относительно какой-либо
константы, или вы можете инсталлировать программный инструмент для управле-
ния зависимостями. В качестве альтернативы вы можете использовать вендоринг
для ваших зависимостей.
Далее добавьте инструмент модульного тестирования и неуспешный тест. Не за-
будьте также добавить управление зависимостями для инструмента тестирования.
Пусть скрипт build запустит тест, тот должным образом пройдет неуспешно и выдаст
код ошибки. Далее проверьте, что скрипты watch и integrate корректно обрабатывают
ошибки, и затем дайте тесту пройти успешно.
Теперь вы можете добавить скрипт rundev. Скомпилируйте его, если необходимо,
и запустите ваше ничего не делающее приложение. Сделайте так, чтобы оно автомати-
чески перезапускалось при изменении исходных файлов. Сделайте рефакторинг так,
чтобы скрипты build, watch и rundev не содержали дубликатов кода для наблюдения
за файлами или компиляции.
В конце создайте скрипт deploy. Дайте ему запустить integrate (не забудьте об-
работку сбоев) и затем разверните интеграционную ветку. Начните с развертывания
на промежуточный сервер. Каким будет правильный способ — зависит от вашей си-
стемной архитектуры, но у вас есть только один рабочий файл, так что вам не нужно
ничего сложного. Просто разверните этот один файл и его среду выполнения на одном
сервере. Это так же просто сделать, как использовать scp или rsync.
Для всего более сложного (обработки сбоев, мониторинга, конфигурирования
(provisioning)) нужна история. (Например, «Сайт продолжает работать после ава-
рии».) По мере роста вашей системы автоматизация тоже будет увеличиваться.
Если вы не выполняете развертывание на сервер, а вместо этого распространяете
инсталляционные пакеты, то создайте с помощью deploy простой дистрибутив-
ный пакет. Начните с пустого пакета, например ZIP-файла, просто содержащего
ваш один рабочий файл и его среду выполнения. Более красивую и удобную
для пользователя установку можно запланировать позже с помощью пользо-
вательских историй.
Начиная с этого момента и далее обновляйте вашу автоматизацию с каждой

историей. Когда добавляете зависимости, не устанавливайте их вручную (если не ис-
пользуете вендоринг); добавьте их в конфигурацию вашего менеджера зависимостей
и позвольте ему их устанавливать. Таким образом вы будете знать, что все будет
работать и у других людей. Когда история впервые обращается к базе данных, обно-
вите скрипты build, rundev и deploy так, чтобы они автоматически инсталлировали,
конфигурировали и разворачивали ее. То же самое касается историй, в которых есть
дополнительные сервисы, серверы и т. д.
Когда об автоматизации пишут таким образом, кажется, что она требует очень
большого объема работы. Но, создавая свою автоматизацию инкрементно, вы на-
чинаете с простого и расширяете ее вместе с остальным своим кодом. На каждое
усовершенствование уходит лишь день или максимум два работы, и бо́льшая часть
вашего времени сфокусирована на вашем рабочем коде.
Автоматизация устаревшего кода

Роскошь увеличения автоматизации одновременно с кодом может оказаться недо-
ступной. Часто вам придется добавлять автоматизацию к уже существующему коду.
Начните с создания пустых скриптов build, rundev, integrate и deploy. Пока
ничего не автоматизируйте, только найдите документацию для каждой из этих задач
и настройте скрипт так, чтобы он выдавал результаты на консоль. Например, скрипт
deploy может выдать 1. Run esoteric_command 2. Load https://obscure_web_page и т. д.
Дождитесь нажатия клавиши после каждого шага.
Такая простая «автоматизация» не должна занимать много времени, так что вы
сможете создавать каждый скрипт за счет вашего резерва времени. Когда будете
создавать каждый скрипт, он будет стано-

виться вашим новым источником истины См. также
с контролем версии. Старую документацию
или удалите, или скорректируйте так, чтобы
она описывала, как запустить скрипт.
Далее используйте ваш резерв времени, чтобы постепенно автоматизировать
каждый шаг. Сначала автоматизируйте самые простые шаги, затем сфокусируйтесь
на тех, которые вызывают наибольшее трение. Ваши скрипты пока будут содержать
смесь автоматизации и пошаговых инструкций. Продолжайте, пока скрипты не станут
полностью автоматическими, затем начните искать возможности для дальнейшего
совершенствования и упрощения.
Когда скрипт build станет полностью автоматизированным, вы, вероятно,
поймете, что он слишком медленный для секундной обратной связи (или даже
десятисекундной обратной связи). В итоге вы захотите иметь сложный поэтапный
подход, но можете начать с определения небольших фрагментов вашей кодовой
базы. Обеспечьте цели сборки, которые позволят вам собирать и тестировать каждый
фрагмент по отдельности. Чем меньше будут фрагменты, тем легче будет преодолеть
десятисекундный порог.
Как только широко используемая цель сборки составляет меньше десяти секунд,
она становится достаточно быстрой, чтобы имело смысл создать скрипт watch. Про-
должайте оптимизировать, с помощью вашего резерва времени внося небольшое
усовершенствование за раз, пока не добьетесь, чтобы все цели были менее пяти секунд.
В какой-то момент модифицируйте сборку, чтобы она автоматически выбирала цели,
основываясь на том, что изменилось.
Дальше совершенствуйте скорость и надеж-
ность развертывания. Вероятно, это потребует См. также
улучшения тестов, так что займет какое-то
время. Как и раньше, используйте ваш резерв Быстрые надежные тесты (глава 13)
времени и улучшайте понемногу за раз. Если
тест дает сбой в случайном порядке, сделайте его детерминированным. Если вас за-
медляют широкие тесты, замените их более узкими. В подразделе «Добавление тестов
к существующему коду» далее в текущей главе объясняется, что нужно делать.
Код никогда не будет идеальным, но в конце концов те части, с которыми вы рабо-
таете чаще всего, будут максимально усовершенствованы. Продолжайте использовать
ваш резерв времени, чтобы вносить улучшения, как только столкнетесь с трением.
Вопросы
Как нам найти время на автоматизацию?
Так же, как вы находите время на напи-
сание кода и тестирование: это просто часть См. также
работы, которую нужно делать. Во время игры
в планирование, когда вы думаете о размере
каждой истории, добавляйте любые изменения Резерв времени (глава 9)
автоматизации, необходимые для истории.
Кроме того, используйте ваш резерв времени, чтобы вносить усовершенствования,

как только будете сталкиваться с пробуксовками. Но помните, что резерв времени
предназначен для дополнительного усовершенствования. Если история требует из-
менений в автоматизации, то построить автоматизацию (и оставить скрипт, с кото-
рым вы поработали, хотя бы немного улучшенным, чем когда вы его нашли) — это
часть разработки истории, а не часть вашего резерва времени. История не сделана,
пока не сделана автоматизация.
Кто отвечает за написание и поддержку
скриптов? См. также
Ими коллективно владеет вся команда.
На практике члены команды с навыками про- (глава 12)
граммирования и эксплуатации берут на себя
ответственность за них.
У нас есть еще одна команда, которая отвечает за создание и развертывание
средств автоматизации. Что нам делать?
Рассматривайте их автоматизацию таким же образом, как вы рассматриваете
любые сторонние зависимости. Инкапсулируйте их инструменты в скрипты, на-
ходящиеся под вашим контролем. Это даст вам возможность адаптировать их при
необходимости.
Когда происходит миграция базы данных?
Миграция — часть вашего развертывания, но она может происходить после за-
вершения развертывания. Более подробная информация доступна в подразделе
«Миграция данных» главы 15.
Каждая команда может работать над уменьшением трения. В некоторых языках бы-
страя обратная связь затруднена, но обычно вы получаете значимую обратную связь
о конкретной части системы, над которой работаете в данный момент, даже если это
означает запуск небольшой подгруппы ваших тестов. Быстрая обратная связь очень
ценна, она стоит того, чтобы потратить время и разобраться в ней.
Ваша способность запускать ПО локально может зависеть от приоритетов вашей
компании. В среде, где работает много команд, легко случайно создать систему, ко-
торую нельзя будет запустить локально. Если это ваш случай, то вы все же можете
запрограммировать ваши тесты на локальный запуск, но способ локального запуска
всей системы может быть вне вашего контроля.
Когда ваша команда работает с нулевым трением:
zz вы проводите время, занимаясь разработкой, а не программными инструментами,
чек-листами и документацией о зависимостях;
zz вы можете работать очень маленькими шагами, что позволяет вам обнаруживать
ошибки на раннем этапе и тратить меньше времени на отладку;
zz настройка новой рабочей станции для разработки — всего лишь вопрос клони-
рования репозитория и запуска скрипта;
zz вы можете выполнять интеграцию и развертывание несколько раз в день.
Разработка с нулевым трением — идеал, к которому должна стремиться каждая ко-
манда. Лучший способ сделать это зависит от вашей ситуации, поэтому не бойтесь
экспериментировать.
Некоторые команды полагаются на свою IDE, а не на скрипты, чтобы обеспе-
чить необходимую автоматизацию. Другие используют большие «доморощенные»
инструментарии со сложными языками конфигурации. Я считаю, что эти подходы
перестают работать, когда потребности команды возрастают. Такие подходы могут
быть удобными вначале, но когда вы продолжаете работу, переключение может стать
болезненным, и будет трудно делать это инкрементно. Будьте скептичны при оценке
сложных инструментов, обещающих покрыть все ваши потребности в автоматизации.
НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ
Мы держим наш последний код готовым
к выпуску. Аудитория
Программисты, отдел эксплуатации

В большинстве случаев в программной
разработке есть скрытый временной разрыв
между моментом, когда команда говорит: «Мы закончили», и моментом, когда она
действительно готова сделать релиз. Иногда этот разрыв может растягиваться на
месяцы. Это ведь в сущности «такая мелочь»: заставить заработать код, написанный
разными людьми, написать скрипт развертывания, предварительное заполнение
базы данных и т. д.
Непрерывная интеграция — более совершенный подход. Команды, использующие
ее, поддерживают общий код в работающем и готовом к релизу состоянии. Конечная
цель непрерывной интеграции — сделать
релиз коммерческим, а не техническим ре- Когда заказчики в команде готовы
шением. Когда заказчики в команде готовы к релизу, вы нажимаете кнопку
к релизу, вы нажимаете кнопку и делаете и делаете его.
его. Без суеты, без суматохи.
Кроме того, непрерывная интеграция
является неотъемлемой частью коллектив- См. также
ного владения кодом и рефакторинга. Если
все вносят изменения в один и тот же код, Коллективное владение кодом
то им нужен какой-то способ разделять эту (глава 12)
работу. Непрерывная интеграция подходит Рефакторинг (глава 13)
для этого как нельзя лучше.
Непрерывная интеграция — это практика,

а не инструмент
Одним из самых первых пользователей непрерывной интеграции была ThoughtWorks,
аутсорсинговая фирма разработки ПО. Она создала инструмент, называемый «кру-
из-контроль» (CruiseControl), чтобы автоматически запускать свои скрипты непре-
рывной интеграции.
Разработчики назвали его сервером непрерывной интеграции (continuous integra
tion (CI) server), также называемым CI/CD-сервер или сервер сборки.
С того времени популярность этих инструментов возросла в разы. Они настоль-
ко популярны, что инструменты стали подменять собой реальную практику. Сейчас
многие думают, что «непрерывная интеграция» означает использование CI-сервера.
Это не так. CI-серверы управляют лишь небольшой частью непрерывной интегра-
ции: собирают и объединяют код по сигналу. Но непрерывная интеграция — нечто
гораздо большее, чем запуск сборки. Фунда-
ментально — это способность сделать релиз Непрерывная интеграция — нечто
последней готовой работы вашей команды по гораздо большее, чем запуск сборки.
желанию. Ни один инструмент не сделает это
за вас. Для этого требуются три вещи.
Выполняйте интеграцию несколько раз в день

Интеграция означает процесс объединения всего кода, написанного командой. Обыч-
но это подразумевает объединение кода, полученного от каждого члена команды,
в общей ветви вашего репозитория исходного кода. Эта ветвь проходит под множе-
ством вариантов названий. Наиболее часто встречающиеся — «главная», «мастер»,
«магистральная». Я использую «интеграционная», поскольку люблю ясные названия,
а это как раз то, для чего эта ветвь предназначена. Но вы можете использовать любое
название, на ваш вкус.
Команды, практикующие непрерывную интеграцию, выполняют интеграцию
как можно чаще. Это «непрерывная» часть понятия непрерывной интеграции. Люди
выполняют интеграцию каждый раз, когда завершают задачу, до и после каждого
большого рефакторинга, и всякий раз, когда готовы переключить передачу. Может
пройти от нескольких минут до нескольких часов в зависимости от работы. Чем
чаще, тем лучше. Некоторые команды даже интегрируют по мере появления каж-
дого коммита.
Если вы когда-нибудь сталкивались с многодневными, болезненными слияния-
ми кода, то такая частая интеграция может показаться глупостью. Зачем проходить
через такую боль лишний раз?
Секрет непрерывной интеграции в том, что на самом деле она понижает риск
неудачного слияния. Чем чаще вы ее выполняете, тем менее это болезненно. Более
частые интеграции означают более мелкие слияния, а те, в свою очередь, означают
меньшие шансы конфликтов слияния. У команд, использующих непрерывную ин-
теграцию, все еще бывают случайные конфликты слияния, но они довольно редки
и легко разрешаются.
Никогда не допускайте неисправности интеграционной ветви

Когда последний раз вы потратили часы, оты-
скиваия баг в своем коде, только чтобы обна- Интеграционная ветвь должна
ружить, что это вовсе не ваш код, а устаревшая всегда хорошо проходить сборку
конфигурация или чей-то еще код? И наобо- и все тесты.
рот, когда последний раз вы потратили часы,
обвиняя конфигурацию или чей-то еще код, а потом поняли, что все это время это
был ваш код? Чтобы предотвратить подобные проблемы, интеграционная ветвь
должна быть заведомо исправной. Она должна всегда хорошо проходить сборку
и все тесты.
На самом деле это проще, чем кажется. Вам
понадобится автоматизированная сборка с хо- См. также
рошим набором тестов, и как только она у вас
появится, гарантия заведомо исправной инте- Нулевое трение (глава 13)
грационной ветви — всего лишь вопрос вали- Разработка через тестирование
дации объединенного кода до перемещения его (глава 13)
в интеграционную сборку. Таким образом, если Быстрые надежные тесты
сборка не удастся, то интеграционная ветвь (глава 13)
останется в своем прежнем, заведомо исправном
состоянии.
Однако сборка должна быть быстрой и завершаться менее чем через 10 минут.
Если это не так, то всем членам команды будет слишком трудно совместно работать
над кодом. Можно обойти проблему медленной сборки с помощью многоступенчатой
интеграции, как обсуждается в подразделе «Многоступенчатые интеграционные
сборки» далее в текущей главе.
Поддерживайте интеграционную ветвь

в состоянии готовности к релизу
Каждая интеграция должна быть максимально приближена к реальному релизу.
Цель — сделать подготовку к релизу настолько обычным делом, что, когда вы дей-
ствительно его сделаете, это не будет каким-то событием. Одна команда, с которой
я работал, дошла до того, что делала релизы несколько раз в неделю. Члены коман-
ды написали маленькое мобильное приложение с большой красной кнопкой. Будучи
готовыми к релизу, они шли в местный паб, заказывали что-нибудь и нажимали на
кнопку.
Это означает, что в каждой истории содер-
жатся задачи по обновлению скриптов сбор- См. также
ки и развертывания по мере необходимости.
Изменения в коде сопровождаются тестами. Сделано Сделано (глава 9)
Решены проблемы с качеством кода. Подготов- Сборка для эксплуатации
лены скрипты для миграции данных. Важные, (глава 15)
но незаметные истории, такие как журналы Флаги функций (глава 15)
(логи) и аудит, приоритизированы наряду со
своими функциональностями. Незавершенные функциональности отключаются

с помощью флагов или ключей.
«Быть максимально приближенным к реальному релизу» — значит запустить
скрипт развертывания и видеть, что он действительно работает. Вам не нужно прове-
рять развертывание в эксплуатационную среду (это уже непрерывное развертывание,
более продвинутая практика), но вы должны проверить развертывание в тестовую
среду. То же самое касается ПО, которое находится не в онлайн. Если вы делаете
встроенное ПО, то установите его на тестовом оборудовании или симуляторе. Если вы
делаете мобильное приложение, то создайте пакет для отправки (submission package).
Если вы делаете настольное приложение, то подготовьте установочный пакет.
Не откладывайте грязную работу на самый конец (см. врезку «Минимизируйте
объем незавершенной работы» в главе 8). Делайте ее непрерывно, в течение всего
процесса разработки. С самого первого дня фокусируйтесь на создании «ходячего
скелета», который можно было бы выпустить, если бы у него было хоть немного
«мяса на костях», и стабильно добавляйте его с каждой историей и задачей.
Развертывание vs релиз
В чем разница между развертыванием и релизом? Выполнить развертывание
означает запустить ПО, написанное командой, в работу (обычно скопировав его
на рабочие серверы), но не обязательно активировав его новые функционально-
сти и возможности. Выпустить релиз означает сделать новые функциональности
доступными для использования заказчиком. Для многих команд каждое развер-
тывание одновременно является и релизом, но можно использовать техники,
такие как флаги функций, чтобы сделать развертывание без релиза.
Множество разновидностей непрерывной интеграции

Непрерывная интеграция настолько популярна и настолько неверно понимается,
что люди продолжают выдумывать новые термины для разных аспектов основопо-
лагающей идеи:
zz CI-сервер представляет собой программный инструмент, который автоматиче-
ски запускает скрипты сборки. Не имеет никакого отношения к непрерывной
интеграции;
zz разработка на основе магистрали (trunk-based development) подчеркивает «ин-
теграционную» часть в непрерывной интеграции [Hammant2020];
zz непрерывная поставка подчеркивает ту часть непрерывной интеграции, которая
относится к развертыванию [Humble2010]. Обычно воспринимается как «непре-
рывная интеграция + развертывание в тестовой среде»;
zz непрерывное развертывание — поистине новая практика. Подразумевает развер-
тывание в эксплуатационную среду при каждой интеграции. Обычно восприни-
мается как «непрерывная поставка + развертывание в эксплуатационную среду».
Хотя непрерывную поставку часто рассматривают как отдельную от непрерывной

интеграции практику, Кент Бек описывал ее как часть непрерывной интеграции еще
в 2004 году:
Интегрируйте и сделайте полный продукт. Если цель — сжечь CD, то сожгите
CD. Если цель — развернуть сайт, разверните его, пусть даже в тестовую среду.
Непрерывная интеграция должна быть достаточно полной, чтобы в итоге первое
развертывание системы не составило большой проблемы [Beck2004] (гл. 7).
Танец непрерывной интеграции

Когда вы используете непрерывную интеграцию, каждый день имеет место неболь-
шой хореографический танец.
1. Сесть за рабочую станцию и сбросить ее в заведомо исправное состояние.
2. Выполнить работу.
3. Интегрировать (и, возможно, развертывать) при любой подходящей возможности.
4. По окончании сделать очистку (cleanup).
Эти шаги должны быть доведены до автоматизма
как часть вашей среды разработки с нулевой про- См. также
буксовкой.
Для шага 1 создайте скрипт, называющийся
reset_repo, или что-то похожее. При использовании
git команды выглядят примерно так (до обработки
ошибок):
git clean -fdx # erase all local changes
git fetch -p origin # get latest code from repo,
# removing outdated branches
git checkout integration # switch to integration branch
git reset --hard origin/integration # reset integration branch to match repo
git checkout -b $PRIVATE_BRANCH # create a private branch for your work
$BUILD_COMMAND_HERE # verify that you’re in a known-good state
Во время шага 2 вы работаете нормально, как обычно, включая коммиты и пере-

мещение, как предпочитает ваша команда.
Шаг 3 — интеграция. Вы можете это делать в любое время, когда проходят тесты.
Попробуйте интегрировать хотя бы каждые несколько часов. Когда вы готовы ин-
тегрировать, объедините последние изменения в ветке интеграции с вашим кодом,
убедитесь, что все работает вместе, затем дайте задание вашему CI-серверу проте-
стировать ваш код и слить все обратно в интеграционную ветку.
Ваш скрипт integrate автоматизирует эти шаги для вас. В git это выглядит при-
мерно так (до обработки ошибок):
git status --porcelain # check for uncommitted changes (fail if any)
git pull origin integration # merge integration branch into local code
$BUILD_COMMAND_HERE # build, run tests (to check for merge errors)
$CI_COMMAND_HERE # tell CI server to test and merge code
# The following steps help git resolve merge conflicts

$WAIT_COMMAND_HERE # wait for CI server to finish
git checkout integration # check out integration branch
git pull origin integration # update integration branch from repo
git checkout $PRIVATE_BRANCH # check out private branch
git merge integration # merge repo’s integration branch changes
CI-команда меняется в зависимости от вашего CI-сервера, но обычно она выпол-

няет перемещение вашего кода в репозиторий. Позаботьтесь о том, чтобы настроить
ваш CI-сервер на сборку и тестирование кода, прежде чем снова объедините код
с интеграционной веткой, а не после. Таким образом ваша интеграционная ветка
всегда будет в заведомо исправном состоянии. Если у вас нет CI-сервера, который
может это делать, то вы можете использовать скрипт, предложенный далее.
Повторяйте шаги 2 и 3, пока не закончите все запланированное на день. После
того как выполните интеграцию последний раз, сделайте очистку:
git checkout integration # switch to integration branch
git branch -d $PRIVATE_BRANCH # delete private branch
git fetch -p origin # get latest code from repo,
# removing outdated branches
git reset --hard origin/integration # reset integration branch to match repo
Эти скрипты — только предложения, вы можете адаптировать их в соответствии

с предпочтениями вашей команды.
Непрерывная интеграция без CI-сервера

Выполнять непрерывную интеграцию без CI-сервера на удивление просто. В не-
которых средах это может оказаться лучшим вариантом для вас, так как облачные
CI-серверы могут быть удручающе слабыми. Все, что вам нужно, — это интеграцион-
ная машина, то есть дополнительная рабочая станция разработки или виртуальная
машина, и небольшой скрипт.
Начните с того, что запрограммируйте скрипт integrate, который вы запускаете
на своей рабочей станции, на то, чтобы отправить ваши изменения в частную ветку.
Команда git — git push origin HEAD:$PRIVATE_BRANCH.
После того как код отправлен, вручную войдите в систему на интеграционной
машине и запустите второй интеграционный скрипт. Он должен проверить частную
ветку, дополнительно проверить, что никто больше не делал интеграцию с момента,
когда вы выложили код, запустить сборку и тесты, затем добавить изменения об-
ратно, в интеграционную ветвь.
Запуск сборки и тестов на отдельной интеграционной машине необходим для того,
чтобы обеспечить заведомо исправную интеграционную ветвь. Это предотвращает
ошибки типа «на моей машине это работало». При использовании git команды вы-
глядят примерно так (до обработки ошибок):
# Get private branch
git fetch origin # get latest code from repo
git checkout $PRIVATE_BRANCH # check out private branch

git reset --hard origin/$PRIVATE_BRANCH # reset private branch to match repo
# Check private branch

git merge integration --ff-only # ensure integration branch has been merged
$BUILD_COMMAND_HERE # build, run tests
# Merge private branch to integration branch using merge commit

git checkout integration # check out integration branch
git merge $PRIVATE_BRANCH --no-ff --log=500 -m "INTEGRATE: $MESSAGE" # merge
git push # push changes to repo
# Delete private branch

git branch -d $PRIVATE_BRANCH # delete private branch locally
git push origin :$PRIVATE_BRANCH # delete private branch from repo
Если скрипт закончился неудачно, то внесите исправления на своей рабочей ма-

шине и затем интегрируйте снова. Благодаря этому скрипту неудачные интеграции
не будут оказывать влияния ни на кого другого.
Обратите внимание, что только один человек может делать интеграцию в каж-
дый момент времени, поэтому вам понадобится какой-то способ контроля доступа.
Если у вас физическая интеграционная машина, то побеждает тот, кто за ней сидит.
Удаленную интеграционную машину вы можете настроить так, чтобы разрешался
только один вход в систему за раз.
Этот скрипт предназначен для синхронной интеграции; это значит, вы должны
дождаться, пока интеграция закончится, прежде чем перейти к другой работе. (Я по-
ясню это чуть позже.) Если вам нужна асинхронная интеграция, то вам лучше ис-
пользовать CI-сервер. Многоступенчатые сборки могут использовать этот скрипт для
синхронной части в целях ускорения, а затем передавать CI-серверу для вторичной
сборки или развертывания.
Синхронная или асинхронная интеграция

Непрерывная интеграция работает лучше всего,
когда вы ждете, пока она завершится. Это называ- См. также
ется синхронной интеграцией, и она требует, чтобы
ваши сборка и тесты были быстрыми — желательно,
чтобы они завершались менее чем за пять минут или Быстрые надежные тесты
максимум за десять. Достижение такой скорости (глава 13)
зависит от создания быстрых надежных тестов.
Если сборка занимает слишком много времени, то вам придется использовать
асинхронную интеграцию. В этом случае (такая интеграции требует наличия CI-
сервера) вы начинаете процесс интеграции, затем переходите к другой работе, пока
CI-сервер делает сборку. Когда сборка закончена, CI-сервер сообщает вам результат.
Асинхронная интеграция выглядит эффективной, но на практике оказывается
довольно проблематичной. Вы берете код, начинаете работать над чем-то еще и за-
тем, полчаса (или больше) спустя, получаете сообщение, что сборка завершилась
неудачно. Теперь вы должны прервать свою работу, чтобы пойти исправлять ошибку.
Во всяком случае, в теории. Чаще она просто откладывается на потом. В итоге вы
получаете огромный объем просроченной на часы или даже дни работы, имеющий
гораздо более высокую вероятность конфликтов при объединении.
Особенно часто эта проблема касается плохо сконфигурированных CI-серверов.
Ваш CI-сервер должен объединять код в интеграционной ветке только после того,
как сборка выполняется успешно, чтобы интеграционная ветка была заведомо ис-
правной, однако некоторые CI-серверы по определению сначала объединяют код,
а потом запускают сборку. Если код повреждает сборку, то все, кто загружал его из
ветки интеграции, блокируются.
В сочетании с асинхронной интеграцией вы получите ситуацию, когда люди
невольно загружают поврежденный код, а затем не исправляют его, думая, что это
кто-то другой повредил сборку. Ситуация усугубляется, когда ошибки наслаиваются
одна на другую. Мне попадались команды, в которых сборки оставались поврежден-
ными целыми днями.
Лучше сделать конструктивно невозможным повреждение сборки, введя правило
сначала тестировать сборку. И все же лучше использовать синхронную интеграцию.
Когда вы интегрируете, дождитесь успешного завершения интеграции. Если она
неуспешна, сразу исправьте ошибку.
Многоступенчатые интеграционные сборки

У некоторых команд настолько сложные тесты, измеряющие такие качества, как про-
изводительность, нагрузка или стабильность, что они просто не могут завершиться
за 10 минут. Эти команды могут использовать многоступенчатую интеграцию.
Многоступенчатая интеграция состоит из двух отдельных сборок. Нормальная
сборка, или сборка подтверждения (commit build), содержит все необходимые со-
ставляющие, позволяющие продемонстрировать, что ПО работает: компиляция,
линтинг, модульные тесты, узкие интеграционные тесты, несколько дымовых тестов.
Эта сборка запускается синхронно, как обычно.
Когда сборка подтверждения завершается успешно, интеграция считается успеш-
ной и код сливается в интеграционную ветку. Тогда асинхронно запускается более
медленная вторичная сборка. Она содержит дополнительные тесты, которые не за-
пускаются в нормальной сборке: тесты производительности, нагрузочные тесты,
тесты стабильности и т. д. В нее также может входить развертывание кода в про-
межуточной или эксплуатационной среде.
Если вторичная сборка не удалась, то
команда получает сообщение, все бросают Если вторичная сборка не удалась,
текущие занятия и занимаются решением все бросают текущие занятия
и занимаются решением проблемы.
проблемы. Это позволяет команде быстро
вернуться к заведомо исправной сборке.
Однако сбои во вторичной сборке должны случаться редко. Если это не так, то
сборка подтверждения должна быть расширена так, чтобы обнаруживать подобные
проблемы и решать их синхронно.
Многоступенчатая сборка может подойти для зрелой кодовой базы со сложным

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

и ревью кода
Запросы на слияние кодов не подходят для не-
прерывной интеграции. Они слишком медлен- Пул-реквесты слишком
ные. Непрерывная интеграция работает лучше медленные для непрерывной
интеграции.
всего, когда периоды времени между интегра-
циями очень короткие (менее чем несколько
часов), а для запросов на слияние кодов требуется день или два на подтверждение.
Это повышает вероятность конфликтов при объединении кода, особенно для команд,
использующих эволюционный дизайн (о котором я расскажу в главе 14).
Вместо этого используйте парное или групповое программирование, чтобы из-
бавиться от необходимости проводить ревью кода. В качестве альтернативы, если
вам хочется сохранить ревью, то вы можете их
проводить после интеграции, а не как необходи- См. также
мый этап перед интеграцией.
Запросы на слияние кодов не очень хоро- Парное программирование
шо работают у команд, использующих непре- (глава 12)
рывную интеграцию, но все же могут служить Групповое программирование
механизмом координации между командами, (глава 12)
не связанными общим владением кодом.
Инструмент
«Непрерывная интеграция? Что вы имеете в виду, говоря, что
непрерывная интеграция может помочь? У нас уже есть инстру-
мент CI».
Ваш босс разговаривает по телефону с Agile-коучем. Это должен
был быть телефонный отбор кандидатов, но сейчас не очень по-
нятно, кто кого интервьюирует.
«Нет, они не работают вместе над историями. Здесь я руковожу процессом.

Я назначаю истории для ресурсов, и каждая история получает отдельную
ветвь функциональности. Несколько недель спустя ресурс предоставляет за-
прос на слияние кода, я его просматриваю и говорю им, что они сделали не-
правильно».
Вы не слышите, что говорит его собеседник, но лицо вашего босса наливается
интересным оттенком красного.
«Послушайте, я попросил вас помочь нам с нашей проектной документацией,
а не болтать какую-то чепуху про коммунистический стиль владения кодом и не-
прерывную интеграцию. Я говорил вам, у нас уже есть CI-инструмент. У нас есть
реальные проблемы, которые надо решать. При объединениях кода происходит
слишком много конфликтов, и никто не знает, как продолжить работу Тиффани
с тех пор, как она уволилась. Мне нужно, чтобы мои ресурсы имели одинаковое
понимание ситуации, и проектная документация — как раз тот способ, с помощью
которого я хочу этого добиться. А теперь вы готовы прекратить тратить попусту
мое время и помочь мне в этом или… алло? Алло?»
Ваш босс швыряет телефон на стол и поворачивается к вам. «Поверить не могу!
Еще один бросил трубку. Что не так с этими людьми?»
Вопросы
Вы говорите, мы должны делать очистку в конце дня, а что, если у меня осталась
незавершенная работа и я не могу сделать интеграцию?
Если вы используете флаги функций и практикуете разработку через тестирова-
ние, то можете делать интеграцию в любой момент по мере прохождения тестов,
которое должно происходить каждые несколько минут. Вы вообще не должны ока-
зываться в ситуации, когда не можете делать интеграцию.
Если работа встала, то хорошей иде-
ей может быть удаление незавершенного
См. также
кода. Если вы часто делаете интеграцию, то
его не должно быть много. Вы справитесь Флаги функций (глава 15)
с работой лучше, если начнете все сначала
утром, на свежую голову. (глава 13)
Разве синхронная интеграция — это
не потеря времени?
Нет, если ваша сборка такая быстрая, какой должна быть. Это хорошая воз-
можность сделать перерыв и подумать о дизайне, возможностях рефакторинга или
следующих шагах. На практике проблемы, вызванные асинхронной интеграцией,
отнимают больше времени.
Кажется, мы всегда сталкиваемся с конфликтами объединения, когда выполняем
интеграцию. Что мы делаем не так?
Одна из причин конфликтов объединения кода — редкая интеграция. Чем реже

вы делаете интеграцию, тем больше изменений вам приходится объединять. Попро-
буйте делать интеграцию более часто.
Еще одна возможная причина — ваши изменения накладываются на работу другого
члена команды. Попробуйте больше говорить о том, над чем вы работаете, и более
плотно координироваться с людьми, которые работают над кодом, имеющим отно-
шение к вашему. Более подробная информация доступна в разделе «Как заставить
коллективное владение работать» главы 12.
CI-сервер (или интеграционная машина) постоянно завершает сборку неуспешно.
Как можно сделать интеграцию более надежной?
Сначала убедитесь, что у вас надежные тесты. Периодические сбои тестов —
наиболее частая причина неуспешных сборок, которую я встречал. Если проблема
не в этом, то вам, возможно, понадобится объединить и протестировать ваш код
локально перед интеграцией. В качестве альтернативы, если у вас частые про-
блемы с неверными зависимостями, то
вам может понадобиться поработать над См. также
воспроизводимыми сборками, как было
описано в подразделе «Воспроизводи- Быстрые надежные тесты (глава 13)
мые сборки» ранее в данной главе.
Непрерывная интеграция наиболее эф-
фективна в сочетании с синхронной ин- См. также
теграцией, что требует сборки с нулевой
пробуксовкой, для завершения которой Нулевое трение (глава 13)
нужно не более 10 минут. Иначе вам Парное программирование (глава 12)
придется использовать асинхронную Групповое программирование (глава 12)
или многоступенчатую интеграцию.
Разработка через тестирование (глава 13)
Асинхронная и многоступенчатая
интеграции требуют использования CI- Быстрые надежные тесты (глава 13)
сервера, и он должен быть сконфигури-
рован так, чтобы проверять сборку до того, как она объединяет изменения с интегра-
ционной веткой. Иначе, вероятно, в конечном итоге вы получите наслаивающиеся
друг на друга ошибки сборки.
Запросы на слияние кодов не очень хорошо работают в сочетании с непрерывной
интеграцией, поэтому к ревью кода нужен другой подход. Лучше всего подходит
парное или групповое программирование.
Непрерывная интеграция полагается на сборку и набор тестов, которые будут
тщательно тестировать ваш код, желательно с помощью быстрых надежных те-
стов. Разработка на основе тестирования, использующая узкие коммуникативные
(sociable) тесты, — лучший способ достичь этого.
Когда вы выполняете интеграцию непрерывно:
zz развертывание и релиз происходят безболезненно;
zz ваша команда имеет мало конфликтов интеграции и запутанных багов интеграции;
zz члены команды могут легко синхронизировать свою работу;
zz ваша команда может делать релиз нажатием кнопки в любой момент, когда за-
казчики в команде готовы.
Непрерывная интеграция — базовая необходи-
мость для команд, использующих коллективное См. также
владение кодом и эволюционный дизайн. Без нее
существенный рефакторинг становится нецелесо- (глава 12)
образным, поскольку вызывает слишком много
конфликтов объединения. Это мешает команде Рефлексивный дизайн (глава 14)
непрерывно совершенствовать дизайн, что необ- Рефакторинг (глава 13)
ходимо для успеха в долгосрочной перспективе. Флаги функций (глава 15)
Самая часто встречающаяся альтернатива
непрерывной интеграции — это ветки функцио-
нальностей, которые регулярно сливаются из интеграционной ветки и интегриру-
ются в нее только тогда, когда каждая функциональность готова.
Хотя ветки функциональностей позволяют вам держать интеграционную
ветку в состоянии готовности к релизу, они обычно не очень хорошо работают
с коллективным владением кодом и эволюционным дизайном, поскольку слияния
в интеграционную ветку слишком редки. Ис-
пользовать флаги функций — лучший способ См. также
держать интеграционную ветку в состоянии
готовности к релизу. Непрерывное развертывание
Эксперименты с непрерывной интеграцией, (глава 15)
которые я видел, предполагают доведение ее
до крайности. Некоторые команды делают интеграцию по мере каждого коммита
(каждые несколько минут) или даже каждый раз, когда проходит тест. Наиболее по-
пулярный эксперимент — непрерывное развертывание, которое попало в мейнстрим
и будет обсуждаться дальше в этой книге.

Статья Мартина Фаулера Patterns for Managing Source Code Branches [Fowler2020b] —
отличный ресурс для тех, кому интересно разобраться в различиях между ветками
функциональностей, непрерывной интеграцией и прочими стратегиями ветвления.
Continuous Delivery Джеза Хамбла и Дэвида Фарли [Humble2010] — это классика,
и совершенно справедливо. В книге подробно обсуждается все, что вам нужно для
непрерывной интеграции, с упором на автоматизацию развертывания.
РАЗРАБОТКА ЧЕРЕЗ ТЕСТИРОВАНИЕ

Мы производим высококачественный код мел-
кими, легко поддающимися проверке шагами. Аудитория
«Что действительно нужно языкам програм- Программисты
мирования, так это инструкция DWIM (Do What
I Mean), — гласит известная шутка, — Делай то, что
я подразумеваю, а не то, о чем говорю».
Программирование — процесс с высокими требованиями. Оно требует систе-
матического совершенствования, месяцев и лет усилий. В лучшем случае ошибки
приведут к коду, который будет невозможно скомпилировать. В худшем — к багам,
которые до поры до времени будут незаметными и проявятся именно в тот момент,
когда смогут нанести максимальный вред.
Разве не было бы чудесно, если бы существовал способ заставить компьютеры
делать то, что вы имеете в виду? Техника, настолько эффективная, чтобы буквально
избавляла от необходимости в отладке?
Такая техника есть. Это разработка через тестирование, и она действительно работает.
Разработка через тестирование представляет собой быстрый цикл тестирования,
кодирования и рефакторинга. Добавляя функциональность, вы будете выполнять
десятки таких циклов, внедряя и отлаживая ПО крошечными шагами, пока не оста-
нется ничего, что можно добавить или убрать. Хорошо налаженная TDD позволяет
сделать так, чтобы код выполнял именно то, что вы подразумеваете, а не только то,
о чем говорите.
Вдобавок при правильном использовании TDD позволяет вам улучшить ваш
дизайн, документирует код для будущих программистов, облегчает рефакторинг
и оберегает от будущих ошибок. И что еще лучше — это весело. Вы всегда держите
все под контролем и постоянно получаете подтверждение, что вы на верном пути.
Конечно, TDD не идеальна. Она помогает программистам писать в коде то, что они
намеревались написать, но не спасает программистов от неверного понимания того, что
им нужно делать. Она помогает улучшить документацию, рефакторинг и дизайн, но
только если программисты усиленно работают над этим. Кроме того, TDD имеет кривую
обучения (learning curve): ее трудно добавить к устаревшей кодовой базе, и потребуются
дополнительные усилия, чтобы применить ее к коду, который имеет отношение к внеш-
нему миру, такому как пользовательские интерфейсы, сетевое окружение и базы данных.
В любом случае попробуйте TDD. Она выигрывает от использования и других
практик Agile, но не требует их. Вы можете использовать ее почти с любым кодом.
Почему TDD работает

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

то нужно проверить не так много кода.
Разработка через тестирование применяет тот же принцип к намерениям програм-
миста. Подобно тому как современная среда предоставляет обратную связь по син-
таксису вашего кода, TDD усиливает обратную связь, имеющую отношение к семан-
тике вашего кода. Каждые несколько минут (каждые 20–30 секунд) TDD проверяет,
делает ли код то, что, по вашему мнению, должен делать. Если что-то идет не так, то
нужно проверить всего несколько строк кода. Ошибки становятся очевидными.
TDD исполняет этот трюк, используя серию про-
веряемых гипотез. Вы продвигаетесь очень малень-
кими шагами и на каждом мысленно прогнозируете, TDD — это серия
что будет дальше. Сначала вы пишете немного тесто- проверяемых гипотез.
вого кода и даете прогноз, что он сработает неуспеш-
но определенным образом. Затем пишете немного рабочего кода и прогнозируете,
что теперь тест пройдет. Затем выполняете небольшой рефакторинг и даете прогноз,
что тест опять пройдет. Если ваш прогноз всегда неверен, то вы останавливаетесь
и выясняете, в чем дело, — или просто делаете резервную копию и пробуете еще раз.
В процессе работы код и тесты объединяются, чтобы проверять корректность
друг друга, и ваши успешные прогнозы подтверждают, что вы контролируете свою
работу. Результат — код, который делает в точности то, что вы задумали. Вы можете
забыть что-то или неверно понимать, что нужно сделать. Но можете быть уверены,
что код делает то, что вы задумали.
Когда вы заканчиваете, тесты остаются. Они подтверждаются вместе с остальным
кодом и работают как живая документация ваших предположений о том, как он должен
работать. Что еще более важно, ваша команда запускает тесты при каждой сборке, обе-
спечивая безопасность рефакторинга и продолжение работы кода так, как задумыва-
лось изначально. Если кто-то случайно меняет поведение кода (например, вследствие
ошибочной отладки), тесты становятся неуспешными, сигнализируя об ошибке.
Быстрая обратная связь

Обратная связь и итерация — ключевая идея Agile, как обсуждалось во врезке
«Обратная связь и итерации» в главе 8. Важный аспект этой петли обратной свя-
зи — скорость обратной связи. Чем быстрее вы можете ее получать, тем быстрее
можете скорректировать курс и исправить ошибки и тем проще понять, что
в следующий раз нужно делать по-другому.
Команды Agile стараются ускорить свои петли обратной связи. Чем быстрее об-
ратная связь, тем лучше. Это применимо к каждому уровню, от релизов («Были ли
наши идеи о ценности правильными?») до ежеминутного кодирования («Делает ли
та строка кода, которую я только что написал, то, что я задумал?»). Разработка
через тестирование, нулевая пробуксовка, непрерывное развертывание и ми-
нимальные ценные инкременты адаптивного планирования — все это примеры
ускорения обратной связи.
Как использовать TDD

Чтобы использовать TDD, вам понадобится программистский фреймворк для те-
стирования. Исторически они называются фреймворками модульного тестирования
(unit testing frameworks), хотя используются для всех видов тестирования. У каж-
дого популярного языка есть один или даже несколько фреймворков — просто вы-
полните поиск в Интернете по фразе «<язык> фреймворк модульного тестирования».
Популярные примеры: JUnit для Java, xUnit.net для .NET, Mocha для JavaScript
и CppUTest для C\++.
TDD выполняет цикл «красный, зеле-
ный, рефакторинг», показанный на рис. 13.1. TDD не предотвращает ошибки;
Помимо времени, затраченного на обду- она их выявляет.
мывание, каждый шаг должен быть очень
маленьким, давая вам обратную связь в течение минуты или двух. Как ни стран-
но, чем лучше люди разбираются в TDD, тем вероятнее, что они будут делать
очень маленькие шаги и быстрее продвигаться вперед. Это потому, что TDD
не предотвращает ошибки; она их выявляет. Маленькие шаги означают быструю
обратную связь, а та, в свою очередь, означает, что ошибки можно исправлять
быстрее и легче.
Рис. 13.1. Цикл TDD
Шаг 1. Подумать
TDD основана на тестировании, поскольку вы начинаете с теста и потом пишете
ровно столько кода, сколько необходимо для его прохождения. Есть поговорка:
«Не пишите никакой рабочий код, если у вас нет неуспешного теста».
Таким образом, вашим первым шагом будет начать несколько странный мысли-
тельный процесс. Вообразите поведение, которое ваш код должен демонстрировать,
а затем подумайте о самой первой части, которая позволит это реализовать. Она
должна быть маленькой. Очень маленькой. Меньше пяти строк кода.
Далее подумайте о тесте (также всего несколько строк кода), который будет
неуспешным, пока не появится именно такое поведение. Подумайте о том, что про-
веряет поведение кода, не реализацию. Пока
интерфейс не меняется, вы должны иметь См. также
возможность изменить реализацию в любой
момент, не меняя тест. Парное программирование
Это самая трудная часть TDD, поскольку (глава 12)
она требует, чтобы вы думали на два шага Групповое программирование
вперед: первый — что вы хотите сделать; (глава 12)
второй — какой тест потребует, чтобы вы Спайк-решения (глава 13)
это сделали. Поможет парное и групповое
программирование. Пока водитель работает над тем, чтобы текущий тест прошел,
штурман думает на опережение, выясняя, какой инкремент и тест должны стать
следующими.
Иногда думать на опережение трудно. Когда это случается, используйте спайк-
решение, чтобы найти подход к проблеме, а затем перестройте его с помощью TDD.
Шаг 2. Красная полоса

Когда вы придумаете следующий шаг, напишите тест. Напишите достаточно тесто-
вого кода для текущего инкремента поведения — скорее всего, меньше пяти строк
кода. Если получится больше — это нормально: просто попробуйте в следующий раз
сделать меньший инкремент.
Напишите тест с точки зрения открытого интерфейса кода, а не того, как вы пла-
нируете реализовать его внутреннее устройство. Соблюдайте инкапсуляцию. Это
значит, что ваш первый тест будет использовать пока еще не существующие имена.
Это делается намеренно, чтобы вы проектировали ваш интерфейс с точки зрения
пользователя интерфейса, а не его разработчика.
После того как тест написан, сделайте прогноз того, что произойдет. Обычно тест
должен пройти неуспешно, что приводит к появлению красного индикатора выпол-
нения в большинстве исполнителей тестов. Однако не прогнозируйте, что он просто
потерпит неудачу, — предскажите, как именно это произойдет. Помните: TDD — это
серии подтвержденных гипотез.
Затем используйте ваш скрипт watch или
IDE, чтобы запускать тесты. Вы должны по- См. также
лучить обратную связь в течение нескольких
секунд. Сравните результат с вашим прогнозом. Нулевое трение (глава 12)
Они совпали?
Если тест не проходит неуспешно или терпит неудачу не так, как вы ожидали, то
вы больше не контролируете свой код. Возможно, ваш тест поврежден или не тести-
рует то, что должен по вашему замыслу. Устраните проблему. Вы должны быть
всегда в состоянии спрогнозировать, что произойдет.
Одинаково важно исправлять как неожидан-
ные успехи, так и неожиданные неудачи. Ваша
Ваша цель — всегда знать, что
цель — не только сделать так, чтобы тесты прош-
делает код и почему.
ли; она в том, чтобы держать под контролем свой
код — всегда знать, что он делает и почему.
Шаг 3. Зеленая полоса

Сначала напишите достаточно рабочего кода, чтобы тест прошел. Повторюсь: в боль-
шинстве случаев вам должно понадобиться меньше пяти строк кода. Не беспокойтесь
о чистоте дизайна или элегантности концепции; просто сделайте то, что нужно, чтобы
тест прошел. Очень скоро вы сделаете очистку.
Сделайте еще один прогноз и запустите тесты. Это ваша вторая гипотеза.
Тесты должны пройти, в результате чего появится зеленый индикатор выпол-
нения. Если тест не пройдет, то вернитесь к заведомо хорошему коду как можно
быстрее. Часто ошибка бывает очевидной. Вы же написали всего лишь несколько

новых строк кода.
Если ошибка неочевидна, то подумайте о том, чтобы отменить все изменения,
и попробуйте еще раз. Иногда лучше удалить или закомментировать новый тест и на-
чать сначала, с еще меньшим инкрементом. Ключевая задача — сохранить контроль.
Всегда есть соблазн прыгнуть выше головы и решить проблему, вместо того что-
бы сохранить резервную копию и попробовать еще раз. Я тоже так делаю. И все же
заработанный тяжелым трудом опыт научил меня тому, что пробовать еще раз, ис-
пользуя меньший инкремент, — почти всегда быстрее и проще.
Это не мешает мне впадать в отчаяние (всегда кажется, что решение где-то ря-
дом), но в итоге я научился устанавливать таймер, чтобы минимизировать ущерб.
Если вы не можете заставить себя отменить изменения сразу, то установите таймер
на 5–10 минут и пообещайте себе, что сделаете резервную копию и начнете сначала,
используя меньший инкремент, когда сработает таймер.
Шаг 4. Сделать рефакторинг

Когда ваши тесты снова проходят, вы можете
сделать рефакторинг, не опасаясь что-то по- См. также
вредить. Просмотрите код, имеющийся у вас
на данный момент, и поищите, что можно улуч- Рефакторинг (глава 13)
шить. Если вы работаете в паре или использу-
ете групповое программирование, то спросите, нет ли каких-нибудь предложений
у вашего штурмана.
Выполняйте рефакторинг инкрементно, чтобы добавлять каждое улучшение по-
шагово. Используйте очень маленькие рефакторинги (меньше минуты или двух
каждый и точно не больше пяти минут) и запускайте тесты после каждого. Они долж-
ны всегда проходить. Как и до этого, если тест не проходит и ошибка не сразу оче-
видна, то отмените рефакторинг и просто вернитесь к заведомо хорошему коду.
Выполните столько рефакторинга, сколько
вам захочется. Сделайте код настолько чистым,
насколько сможете, не заботясь о том, чтобы См. также
сделать его идеальным. Сделайте так, чтобы
Простой дизайн (глава 14)
дизайн был сфокусирован на текущих потреб-
ностях ПО, а не на том, что может случиться
в будущем.
Пока выполняете рефакторинг, не добавляйте никаких функциональностей. Рефак-
торинг не должен менять поведение. Для нового поведения нужен неуспешный тест.
Шаг 5. Повторить
Когда будете готовы добавить новое поведение,
начните цикл сначала. Ключ к успешной TDD —
Если все идет гладко и каждая гипотеза маленькие инкременты и быстрая
совпадает с реальностью, то вы можете «повы- обратная связь.
сить передачу» и делать более крупные шаги.
(Но, как правило, не больше пяти строк кода за раз.) Если столкнетесь с проблемами,
то «понизьте передачу» и двигайтесь меньшими шагами.
Ключ к успешной TDD — маленькие инкременты и быстрая обратная связь.
Каждую минуту или две вы должны получать подтверждение, что двигаетесь в вер-
ном направлении и ваши изменения делают то, чего вы от них ожидаете. Обычно вы
пройдете через несколько циклов очень быстро, затем потратите больше времени на
обдумывание и рефакторинг для новых циклов, потом снова ускоритесь.
Разгром, основанный на тестах

— Ах, да, TDD, — хмурится Алиса, — пробовала я это однажды. Это
катастрофа.
— Что случилось? — спрашиваете вы. У вас TDD работало хорошо,
но с некоторыми вещами было трудно разобраться. Возможно,
вы что-нибудь посоветуете.
— Окей, так значит, TDD — это кодирование ваших спецификаций
с помощью тестов, правильно? — объясняет Алиса немного снис-
ходительно. — Вы начинаете с того, что выясняете, что, по вашему мнению, должен
делать ваш код, потом пишете все тесты, чтобы они полностью его определяли.
Затем пишете код до тех пор, пока тесты не пройдут. Но это просто глупо! — не-
годует она. — Постановка спецификации в начало процесса требует от вас при-
нятия решений до того, как вы полностью поймете проблему. И вот у вас есть все
эти тесты, которые трудно изменить, вы вкладываетесь в решение и не будете
искать лучшие варианты. Даже если вы решаете что-то изменить, все эти тесты
заблокированы вашей реализацией, так что почти невозможно что-то изменить,
не переделывая всю работу. Это просто смешно!
— Я… Я не думаю, что это TDD, — бормочете вы, заикаясь. — Звучит ужасно. В TDD
предполагается, что нужно продвигаться маленькими шагами, не писать все тесты
авансом. И еще предполагается, что вы тестируете поведение, а не реализацию.
— Нет, ты не прав, — твердо говорит Алиса. — TDD — это разработка, где сначала идут
тесты. Пишете тесты, потом пишете код. И это комшмар. Я знаю, я это пробовала.
Ешьте луковицу с середины

Самое сложное в TDD — это разобраться, как делать маленькие шаги. К счастью,
проблемы кодирования похожи на луковицы: у них есть слои. Хитрость с TDD
состоит в том, чтобы начать со сладкой, сочной середины и затем проложить себе
путь наружу. Вы можете использовать любую стратегию, которая вам нравится, но
я использую следующий подход.
1. Главный интерфейс. Начните с главного интерфейса, к которому вы хотите об-
ратиться, потом напишите тест, который обращается к этому интерфейсу про-
стейшим способом. Используйте это как возможность посмотреть, как интерфейс
работает на практике. Это удобно? Имеет смысл? Чтобы тест прошел, вы можете
просто жестко закодировать ответ.
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, тем более маленькие шаги вы можете
делать и тем быстрее это позволяет вам идти вперед.
Начните с главного интерфейса

Подумать. Первым делом мне нужно было решить, с чего начать. Как обычно, хо-
рошая начальная точка — главный интерфейс. Каким бы мне хотелось его видеть?
Этот пример был написан на JavaScript (а именно на Node.js), у меня был выбор
между созданием класса и просто экспортом функции из модуля. Мне показалось,
что не было особого смысла создавать полноценный класс, поэтому я решил сделать
просто модуль rot13, который экспортировал функцию transform.
Красная полоса. Теперь, зная, что хочу сделать, я мог написать тест, который ис-
пытывал этот интерфейс простейшим способом:
it("runs tests", function() { 
assert.equal(rot13.transform(""), ""); 
});
Строка 1 определяет тест, а строка 2 утверждает актуальное значение,

form(""), совпадающее с ожидаемым значением "". Некоторые библио
rot13.trans
теки утверждений ставят ожидаемое значение первым, но в этом примере исполь-
зуется Chai, которая ставит первым актуальное значение.
Прежде чем запустить тест, я выдвинул гипотезу. Конкретно, я предсказал, что
тест пройдет неуспешно, поскольку rot13 не существовал, и именно это и произошло.
Зеленая полоса. Чтобы тест прошел, я создал интерфейс и жестко запрограмми-
ровал ровно столько кода, чтобы было достаточно для теста:
export function transform() {
return "";
}
Жесткое кодирование возвращаемого значения — это своего рода трюк, и я часто

пишу немного реального кода на этом первом шаге. Но в данном случае не было
больше ничего, что код должен был сделать.
Сделать рефакторинг. Ищите возможности для рефакторинга каждый раз, исполь-
зуя цикл. В этом случае я переименовал тест из «запускать тесты», что оставалось от
моей изначальной конфигурации, в «ничего не делать, если вводные данные пустые».
Очевидно, это полезнее для будущих читателей. Хорошие тесты документируют,
как код должен работать, а хорошие названия тестов позволяют читателю получить
общее понимание, бегло просматривая названия. Обратите внимание: название
говорит о том, что делает рабочий код, а не тест:
it("does nothing when input is empty", function() {
assert.equal(rot13.transform(""), "");
});
Вычисления и ветви
Подумать. Теперь мне нужно было закодировать основную логику преобразования
ROT-13. В конечном итоге я знал, что хочу перебирать строку в цикле и преобра-
зовывать по одному символу за раз, но это был слишком большой шаг. Мне нужно
было придумать более маленький шаг.
Более маленький шаг — «сконвертировать один символ», но даже это слишком
велико. Помните, чем меньше шаги, тем быстрее вы можете продвигаться вперед.
Мне нужно было разбить их на еще более маленькие. В итоге я решил просто преоб-
разовать одну прописную букву в соответствующую ей, находящуюся на 13 символов
впереди. Заглавные буквы и цикл после z отложим на потом.
Красная полоса. С помощью таких маленьких шагов было легко написать тест.
it("transforms lower-case letters", function() {
assert.equals(rot13.transform("a"), "n");
});
Моя гипотеза заключалась в том, что тест провалится, ожидая "n", но получив "",
и именно это и случилось.
Зеленая полоса. Сделать так, чтобы тест прошел, было легко:
export function transform(input) {
if (input === "") return "";
const charCode = input.charCodeAt(0);

charCode += 13;
return String.fromCharCode(charCode);
}
Хотя это был маленький шаг, он вынудил меня проработать важный вопрос
конвертации букв в коды символов и обратно, ответ на который мне понадобилось
искать. Небольшие шаги позволили мне решить эту проблему изолированно, что
упростило задачу определить момент, когда я понял правильно.
Сделать рефакторинг. Я не видел никаких возможностей для рефакторинга, по-
этому пришло время снова вернуться в начало цикла.
Повторить. Я продолжил таким же образом, двигаясь маленькими шажками до
тех пор, пока главный алгоритм преобразования букв не был завершен.
1. Строчная буква вперед: a → n (как я только что показал).
2. Строчная буква назад: n → a.
3. Первый символ перед a не сдвигается: ` → `.
4. Первый символ после z не сдвигается: { → {.
5. Заглавные буквы вперед: A → N.
6. Заглавные буквы назад: N → A.
7. Еще пограничные случаи: @ → @ and [ → [.
После каждого шага я просматривал код и при необходимости делал рефак-
торинг. Итоговые тесты показаны ниже. Цифра соответствует шагу. Обратите
внимание, как некоторые шаги привели к новым тестам, а другие расширили
существующий тест:
});

assert.equal(rot13.transform("a"), "n"); 
assert.equal(rot13.transform("n"), "a"); 
});
it("transforms upper-case letters", function() {

assert.equal(rot13.transform("A"), "N"); 
assert.equal(rot13.transform("N"), "A"); 
});
it("doesn't transform symbols", function() {

assert.equal(rot13.transform(""), ""); 
assert.equal(rot13.transform("{"), "{"); 
assert.equal(rot13.transform("@"), "@"); 
assert.equal(rot13.transform("["), "["); 
});
Рабочий код показан ниже. Проследить соответствие каждого шага коду труднее,
поскольку было выполнено много рефакторинга (больше информации см. в эпизоде 1
в [Shore2020b]), но вы можете видеть, что TDD — итеративный процесс, постепенно
заставляющий код разрастаться.
export function transform() {
let charCode = input.charCodeAt(0); 

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(charCode, firstLetter, lastLetter) { 

return charCode >= codeFor(firstLetter) && charCode <= codeFor(lastLetter); 
} 
function codeFor(letter) { 
return letter.charCodeAt(0); 
} 
Шаг 7 (тесты остальных пограничных случаев) не привел в результате к ново-
му рабочему коду, но я добавил его, только чтобы удостовериться, что не допустил
ошибок.
Циклы и обобщение
Подумать. До сих пор код обрабатывал только строки, состоящие из одной буквы.
Теперь настало время обобщить его таким образом, чтобы он поддерживал полные
строки.
Сделать рефакторинг. Я понял, что это было бы легче реализовать, если бы
я выделил основную логику, поэтому я вернулся назад на шаг рефакторинга, чтобы
сделать следующее:
let charCode = input.charCodeAt(0);

return transformLetter(charCode);
}
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;
}
}
function isBetween...
function codeFor...
Делать рефакторинг, чтобы облегчить следующий шаг, — это техника, которую

я использую постоянно. Иногда, на шаге «Красная полоса», я понимаю, что должен
был сначала сделать рефакторинг. Когда это происходит, я временно комментирую
тест, чтобы сделать рефакторинг, пока проходят мои тесты. Это упрощает и ускоряет
обнаружение ошибок рефакторинга.
Красная полоса. Теперь я был готов обобщить код. Я обновил один из моих тестов,
чтобы доказать, что цикл был необходим:
assert.equal(rot13.transform("abc"), "nop");
assert.equal(rot13.transform("n"), "a");
});
Я ожидал, что тест провалится, ожидая "nop", а вместо этого получив "n", по-
скольку он смотрел только на первую букву, и именно это и произошло.
Зеленая полоса. Я изменил рабочий код, добавив цикл:
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...
Сделать рефакторинг. Я решил конкретизировать

тесты, чтобы они лучше работали в качестве документа- См. также
ции для будущих читателей этого кода. В этом не было
строгой необходимости, но я подумал, что это сделало бы Нулевое трение
логику ROT-13 более очевидной. Я менял одно утверж- (глава 13)
дение за раз, конечно. Обратная связь была настолько
быстрой и беспроблемной, выполнялась автоматически при каждом сохранении,

что не было причин не делать этого.
В этом случае все работало в соответствии с ожиданиями, но если бы что-нибудь
пошло неудачно, то изменение одного утверждения за раз немного упростило бы от-
ладку. Эти преимущества накладываются друг на друга:
});

assert.equal(
rot13.transform("abcdefghijklmnopqrstuvwxyz"), "nopqrstuvwxyzabcdefghijklm" 
);
assert.equal(rot13.transform("n"), "a"); 
});
it("transforms upper-case letters", function() {

assert.equal(
rot13.transform("ABCDEFGHIJKLMNOPQRSTUVWXYZ"), "NOPQRSTUVWXYZABCDEFGHIJKLM" 
);
assert.equal(rot13.transform("N"), "A"); 
});
it("doesn't transform symbols", function() {

assert.equal(rot13.transform("`{@["), "`{@["); 
assert.equal(rot13.transform("{"), "{"); 
assert.equal(rot13.transform("@"), "@"); 
assert.equal(rot13.transform("["), "["); 
});
Особые случаи, обработка ошибок и утверждения времени

выполнения
В конце я хотел взглянуть на все, что могло бы пойти не так. Я начал с утверждений
времени выполнения. Каким образом можно использовать код некорректно? Обычно
я не тестирую утверждения времени выполнения, поскольку они являются просто
страховочной сеткой, но в этот раз я сделал это в демонстрационных целях:
it("fails fast when no parameter provided", function() { 
assert.throws( 
() => rot13.transform(), 
"Expected string parameter" 
); 
}); 
it("fails fast when wrong parameter type provided", function() { 

assert.throws( 
() => rot13.transform(123), 
"Expected string parameter" 
); 
}); 
Конечно, я следовал циклу TDD и добавлял тесты по одному за раз. Их реализация

означает добавление защитного условия (guard clause), которое я тоже реализовал
инкрементно:
if (input === undefined  || typeof input !== "string"  ) {
throw new Error("Expected string parameter"); 
} 
...
Хорошие тесты также служат документацией, поэтому на последнем шаге я все

гда просматриваю тесты и думаю о том, насколько информативными они будут для
будущих читателей. Обычно я начинаю с общего случая «успешный вариант», затем
перехожу к специфике и особым случаям. Иногда я добавляю несколько тестов,
только чтобы прояснить поведение, даже если мне не нужно менять рабочий код.
Так же было и с этим кодом. Вот тесты, которыми я закончил:
it("does nothing when input is empty", ...);
it("transforms lower-case letters", ...);
it("transforms upper-case letters", ...);
it("doesn’t transform symbols", ...);
it("doesn’t transform numbers", ...);
it("doesn’t transform non-English letters", ...);
it("doesn’t break when given emojis", ...);
it("fails fast when no parameter provided", ...);
it("fails fast when wrong parameter type provided", ...);
И финальный рабочий код:

if (input === undefined || typeof input !== "string") {
throw new Error("Expected string parameter");
}
let result = "";

}
return result;
}
charCode += 13;
} else if (isBetween(charCode, "n", "z") || isBetween(charCode, "N", "Z")) {
charCode -= 13;
}
}
function isBetween(charCode, firstLetter, lastLetter) {

return charCode >= codeFor(firstLetter) && charCode <= codeFor(lastLetter);
}
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 не учитывает пригодности к тестированию.
Многие люди достигают компромисса с помощью написания очень тонкого, нетести-

руемого уровня трансляции (translation layer), который только передает UI-запросы
уровню представления (presentation layer). Они хранят всю логику UI на уровне
представления и используют на этом уровне TDD обычным образом.
Существуют инструменты, которые позволяют напрямую тестировать UI, делая
HTTP-запросы (для веб-приложений) или нажимая кнопки и симулируя события
окон (для клиентского ПО). Я предпочитаю использовать именно их. Они обычно
применяются для широких тестов, но я использую их для написания узких интегра-
ционных тестов моего уровня трансляции UI. (См. подраздел «Тестирование внешних
взаимодействий с помощью узких интеграционных тестов» далее в текущей главе.)
Должны ли мы делать рефакторинг своего тестового кода?
Конечно! Тестам тоже нужна техническая поддержка. Мне встречались хорошие
во всех остальных отношениях кодовые базы, которые выходили из строя из-за
ломких и нестабильных наборов тестов.
Таким образом, тесты — это форма документации и в целом должны читаться как
пошаговый рецепт. Циклы и логика должны быть вынесены во вспомогательные
функции, что упрощает понимание замысла теста. Однако в каждом тесте можно
иметь некоторое дублирование, если это делает его смысл более понятным. В отличие
от рабочего кода, тесты читают гораздо чаще, чем изменяют.
Арло Бельши использует аббревиатуру WET (Write Explicit Tests, «пишите четкие
тесты») в качестве руководящего принципа для дизайна тестов. Данный принцип
противоположен принципу DRY (Don’t Repeat Yourself, «не повторяйтесь»), который
используется для рабочего кода. Статья Бельши о дизайне тестов «WET: When DRY
Doesn’t Apply» просто превосходна [Belshee2016a].
Какое покрытие кода мы должны иметь?
Измерение покрытия кода часто является ошибкой. Вместо того чтобы фокуси-
роваться на покрытии, сосредоточьтесь на том, чтобы делать маленькие шаги и ис-
пользовать тесты для управления вашим кодом. Если вы это сделаете, то все, что
вы хотите протестировать, наверняка будет протестировано. Во врезке «Пример:
покрытие кода» в главе 10 этот вопрос обсуждается более подробно.
TDD — очень ценный инструмент, однако имеет двух- или трехмесячную кривую об-
учения. Его легко применять к игрушечным проблемам, таким как показанная в при-
мере с ROT-13, но перенос этого опыта на более крупные системы требует времени.
Особенно сложно освоить устаревший код, надлежащую изоляцию теста и узкие
интеграционные тесты. В то же время чем раньше вы начнете использовать TDD, тем
раньше разберетесь с ней, поэтому не позволяйте этим трудностям вас остановить.
Так как TDD имеет кривую обучения, будьте осторожны и не беритесь исполь-
зовать ее без разрешения. Ваша организация может увидеть начальное замедление
и отказаться от TDD, не уделив ей достаточно внимания. Точно так же остерегайтесь
становиться единственным пользователем TDD в вашей команде. Лучше всего, если
все согласятся использовать ее коллективно, иначе в итоге вы придете к тому, что
другие члены команды непреднамеренно будут портить ваши тесты и писать не-
дружественный к тестированию код.
Когда вы все же начнете применять TDD, не продолжайте запрашивать разреше-

ние на написание тестов. Они — нормальная часть разработки. Когда будете задавать
размер историй, включите в них время, требующееся для тестирования.
Успешность TDD напрямую зависит от
быстрой обратной связи. Убедитесь, что вы См. также
можете получать обратную связь в течение
1–5 секунд, по крайней мере, для подгруппы Нулевое трение (глава 13)
тестов, над которой сейчас работаете.
Быстрые надежные тесты (глава 13)
И последнее: не позволяйте вашим те-
стам стать подобием смирительной рубаш-
ки. Если вы не можете выполнить рефакторинг вашего кода, не повредив много
тестов, значит, что-то не так. Зачастую это результат чрезмерного использования
дублеров тестов. Подобным же образом чрезмерное применение широких тестов
может приводить к тестам, которые заканчиваются неудачно в случайном порядке.
В обоих случаях разумно использовать быстрые и надежные тесты.
Когда вы правильно используете TDD:
zz вы тратите совсем немного времени на отладку;
zz вы продолжаете допускать ошибки в программировании, но находите их за минуту
и можете легко исправить;
zz вы полностью уверены, что вся кодовая база выполняет именно то, что от нее
хотели программисты;
zz вы решительно выполняете рефакторинг при любой возможности и уверены, что
тесты найдут любую ошибку.
TDD занимает центральное место среди практик поставки. Без нее будет трудно
или даже невозможно достичь свободного владения навыками на этом уровне. Наи-
более часто встречающаяся неверная интерпретация TDD, как показывает врезка
«Разгром, основанный на тестах» ранее в данной главе, — сначала спроектировать
код, написать все тесты, а потом написать рабочий код. Этот подход раздражающий
и медленный, и он не дает вам учиться на ходу.
Еще один подход — писать тесты после написания рабочего кода. Это очень трудно
сделать хорошо: код должен быть спроектирован тестируемым, а это сложно сделать,
если вы сначала не напишете тесты. Вдобавок это скучное занятие, вызывающее
стойкое искушение заняться чем-то другим. На практике мне еще не приходилось
видеть, чтобы постфактум-тесты хоть как-то приближались к детализации и качеству
тестов, созданных с TDD.
Даже если эти подходы годятся для вас, TDD — не только тестирование. На са-
мом деле речь идет об использовании очень маленьких, непрерывно проверяемых
гипотез для подтверждения того, что вы на правильном пути и производите вы-
сококачественный код. За исключением TCR Кента Бека, о котором я расскажу
позже, я не знаю никаких альтернатив TDD, которые позволили бы вам сделать это,
одновременно предоставляя документацию и обеспечивая безопасность, присущие
хорошему набору тестов.
Вместе с тем TDD предоставляет очень много возможностей для экспериментов.
TDD — это один из тех навыков, которым «учишься моментально, а осваиваешь
всю жизнь». Ищите способы, позволяющие применять TDD ко все большему
и большему количеству технологий, и экспериментируйте, уменьшая свои петли
обратной связи.
Кент Бек экспериментирует с идеей, которую он называет TCR: test && commit ||
revert [Beck2018]. Она относится к небольшому скрипту, который автоматически
подтверждает ваш код, если тесты проходят, и возвращает все обратно, если не про-
ходят. Он дает ту же серию проверенных гипотез, что и TDD, и, пожалуй, делает их
еще меньше и более частыми. Это одна из самых сложных и наиболее важных вещей,
которую вы можете узнать о TDD. TCR стоит попробовать в качестве упражнения,
но не более того.

Test-Driven Development: By Example1 [Beck2002] — отличное введение в практику
TDD от человека, который ее изобрел. Если вам понравился пример с ROT-13, то
понравятся и расширенные примеры из этой книги. Особенно хороши модели TDD,
показанные в части III.
БЫСТРЫЕ НАДЕЖНЫЕ ТЕСТЫ Аудитория

Наши тесты не мешают нам. Программисты
Команды, которые используют разработку на
основе тестирования, накапливают тысячи тестов.
См. также
Чем больше у вас тестов, тем более важны их ско-
рость и надежность. В TDD вы запускаете тесты Разработка через тестирова-
один-два раза каждую минуту. Они должны быть ние (глава 13)
быстрыми и выдавать каждый раз один и тот же
результат. Если они этого не делают, то вы не мо-
жете получать обратную связь за 1–5 секунд, а это критично для того, чтобы петля
TDD работала эффективно. Вы перестанете запускать тесты так часто, следовательно,
не будете так быстро находить ошибки, и это замедлит вашу работу.
Вы можете обойти проблему, запрограммировав ваш скрипт watch на запуск только
подгруппы тестов, но в конечном итоге медленные тесты начнут вызывать проблемы
и во время интеграции. Вместо пяти минут на получение обратной связи будут уходить
десятки минут или даже часы. Вдобавок ко всему тесты будут случайным образом за-
вершаться неуспешно, заставляя вас начинать долгий процесс с самого начала. Из-за
этого появятся пробуксовки, и люди будут вынуждены игнорировать настоящие сбои.
1
Бек К. Экстремальное программирование. Разработка через тестирование. — СПб.: Питер, 2017.
Быстрые надежные тесты полностью все меняют. Они требуют практики и хо-
рошего дизайна, но как только вы узна́ете их секреты, вам будет проще и быстрее
написать именно их, а не медленные нестабильные тесты. Вот как это делается.
Использование узких модульных тестов

Широкие тесты пишут так, чтобы они покрывали бо́льшую часть вашего ПО: напри-
мер, они могут запустить браузер, перейти по URL, нажать кнопки и ввести данные,
затем проверить, что браузер показывает ожидаемый результат. Иногда эти тесты
называют сквозными, хотя технически это один из вариантов широких тестов.
Казалось бы, широкие тесты позволяют увеличить тестовое покрытие, но в дей-
ствительности являются ловушкой. Широкие тесты медленные и ненадежные. Вам
нужно, чтобы ваша сборка выполняла сотни или тысячи тестов в секунду и делала
все это с исключительной надежностью. Сделать это можно с помощью узких тестов.
Узкий тест сфокусирован на небольшом объеме кода. Обычно на методе либо
функции (или нескольких) в определенном классе или модуле. Иногда он фокуси-
руется на небольшой сквозной активности, в которую входят несколько модулей.
Лучшие виды узких тестов называются в сообществе Agile модульными (unit),
хотя есть некоторые разногласия насчет точного определения термина «модульный
тест». Важный момент заключается в том, что модульные тесты быстрые и детерми-
нированные. Обычно для этого нужно, чтобы тест выполнялся полностью в памяти.
Большинство ваших тестов должны быть модульными. Размер вашего модульного
тестового кода должен быть пропорционален размеру вашего рабочего кода. Соот-
ношение может меняться, но чаще всего оно будет близко к 1:1.
Создание модульных тестов требует хорошего дизайна. Если у вас сложности
с написанием тестов, это может говорить о наличии проблем в вашем дизайне.
Ищите способы разделить ваш код так, чтобы каждый класс или модуль мог быть
протестирован независимо.
Другие определения модульных тестов

Одни люди говорят, что модульный тест не может запускать код за пределами
тестируемого класса или модуля, но я думаю, что это излишнее ограничение. Узкий
модульный тест должен тестировать только определенный класс или модуль (или
сквозное поведение), но это нормально, когда тестируемый код вызывает другой
рабочий код. Это различие между одиночными (solitary) и коммуникативными
(sociable) модульными тестами, о котором я расскажу вскоре.
Другие люди говорят, что модульный тест должен иметь только одно утверждение
(assertion). Повторюсь: я думаю, что это излишнее ограничение. Хотя в большин-
стве тестов будет только одно утверждение, иногда вам может понадобиться не-
сколько, чтобы выразить идею, заложенную в тест. (Вы могли увидеть это в пункте
«Вычисления и ветви» ранее в текущей главе.)
Сообщество специалистов по обеспечению качества (quality assurance) и тести-
рования также имеет собственные определения термина «модульный тест». Они
обычно относятся к совершенно другому подходу к тестированию.
Тестирование внешних взаимодействий

с помощью узких интеграционных тестов
Модульные тесты обычно тестируют код, находящийся в памяти, но ваше ПО не ра-
ботает целиком в памяти. Оно должно общаться с окружающим миром. Для тестиро-
вания кода, который это делает, используйте узкие интеграционные тесты (narrow
integration tests), также известные как сфокусированные интеграционные тесты
(focused integration tests).
Концептуально узкие интеграционные тесты похожи на модульные. На прак-
тике, так как они вовлекают в процесс внешний мир, узкие интеграционные тесты
подразумевают сложные настройки и разборки. Они гораздо более медленные, чем
модульные: те могут запускаться сотнями или даже тысячами в секунду, а узкие
интеграционные тесты обычно идут со скоростью десятков в секунду.
Проектируйте свой код так, чтобы минимизировать необходимое вам количе-
ство узких интеграционных тестов. Например, если ваш код зависит от стороннего
сервиса, то не вызывайте его напрямую из того кода, который в нем нуждается.
Вместо этого создайте инфраструктурную обертку, также называемую шлюз
(gateway): класс или модуль, который инкапсулирует сервис и его сетевые вызовы.
Тестируйте инфраструктурную обертку с помощью узких интеграционных тестов,
но применяйте модульные тесты для тестирования кода, который ее использует.
В эпизоде Application Infrastructure в [Shore2020b] есть пример. В итоге вы должны
прийти к относительно небольшому количеству узких интеграционных тестов,
пропорциональному количеству внешних подсистем, с которыми взаимодействует
ваш код.
Моделирование нелокальных
зависимостей
Некоторые зависимости слишком сложны или дороги, чтобы запускать их на вашей
рабочей машине разработки. Однако вы все же должны иметь возможность запускать
тесты локально для целей как воспроизводимости, так и скорости.
Чтобы решить эту проблему, начните с создания инфраструктурной обертки
для зависимости, как обычно. Затем напишите узкий интеграционный тест скорее
для моделирования зависимости, чем для того, чтобы инфраструктурная оболочка
вызывала его по-настоящему. Например, если ваш код использует биллинговый сер-
вис с REST API, то вы можете написать небольшой HTTP-сервер, чтобы заменить
биллинговый сервис в ваших тестах. Больше подробностей вы найдете в шаблоне
«шпионский сервер» в [Shore2018b], а в эпизодах Microservice Clients Without Mocks
в [Shore2020b] есть пример.
В связи с этим возникает вопрос: если вы не тестируете свое ПО на его реальные
зависимости, то как узнаете, что оно работает? Поскольку внешние системы могут
измениться или сломаться в любое время, реальный ответ — использовать мониторинг
(см. подраздел «Параноидальная телеметрия» главы 15). Но некоторые команды
также используют контрактные тесты (contract tests) [Fowler2011], чтобы обнару-
живать изменения в сервисах провайдера. Лучше всего, когда провайдер обязуется
делать тесты самостоятельно.
Контроль глобального состояния

Любые тесты, имеющие дело с глобальным состоянием, требуют тщательного обду-
мывания. Сюда входят глобальные переменные, такие как статические переменные
и одиночки (singletons); внешние хранилища данных и системы, такие как файловые
системы, базы данных и сервисы; машинно-зависимые состояние и функции, такие
как системные часы, региональные стандарты (locale), часовой пояс и генератор
случайных чисел.
Тесты часто пишут, допуская, что глобальное состояние будет выставлено опре-
деленным образом. Бо́льшую часть времени так и будет. Но иногда нет, часто из-за
спешки, и тест будет неуспешным без видимой причины. Когда вы запускаете его
еще раз, он проходит успешно. Результат — нестабильный тест (flaky), то есть такой,
который работает бо́льшую часть времени, но иногда случайным образом неуспешен.
Нестабильные тесты коварны. Так как перезапуск теста «решает» проблему, люди
привыкают работать с такими тестами, просто запуская их еще раз. Как только у вас
наберутся сотни нестабильных тестов, ваш набор тестов станет требовать множества
перезапусков, прежде чем пройдет успешно. К тому моменту решение проблемы
потребует большого объема работы.
Обнаружив нестабильный тест, исправ-
ляйте его в тот же день. Такие тесты — ре- Обнаружив нестабильный тест,
зультаты плохого дизайна. Чем быстрее вы исправляйте его в тот же день.
их исправите, тем меньше проблем у вас
будет в будущем.
Недостаток дизайна, лежащий в основе нестабильных тестов, позволяет глобаль-
ному состоянию загрязнять ваш код.
Некоторые глобальные состояния, такие как статические переменные и одиноч-
ные данные, могут быть удалены с помощью тщательного дизайна. Других видов
глобального состояния, таких как системные часы и внешние данные, можно из-
бежать, но их нужно тщательно контролировать. Используйте инфраструктурную
обертку, чтобы абстрагироваться от остальной вашей кодовой базы, и протестируйте
ее с помощью узких интеграционных тестов.
Например, если вашему коду нужно взаимодействовать с системными часами
(например, чтобы вызвать тайм-аут запроса или получить текущую дату), создайте
обертку для системных часов и используйте ее в оставшейся части вашего кода.
В эпизоде No More Flaky Clock Tests в [Shore2020b] вы найдете пример.
Написание коммуникативных тестов

Тесты могут быть одиночными (solitary) или коммуникативными (sociable)1. Оди-
ночный запрограммирован так, что все зависимости тестируемого кода заменяются
специальным тестовым кодом, называющимся тестовым дублем, также известным
как мок (mock). С технической точки зрения мок — особый случай тестового дубля,
но эти термины зачастую взаимозаменяемы.
1
Термины «коммуникабельные» и «одиночные» ввел Джей Филдс [Fields2015].
Одиночные тесты позволяют вам проверять, что ваш тестируемый код запрашива-
ет свои зависимости, но не дают возможность проверять, что зависимости работают
так, как ожидает ваш код. На самом деле тест не запускает зависимости; он запускает
тестовый дубль. Так что если вы когда-нибудь внесете изменение в зависимость, ко-
торое нарушит ожидания любого кода, который ее использует, то ваши тесты будут
продолжать проходить и вы случайно внесете баг.
Чтобы предотвратить эту проблему, люди, которые пишут одиночные тесты, вдо-
бавок пишут широкие тесты, чтобы убедиться, что все вместе работает корректно.
Это двойная работа, и эти широкие тесты часто медленные и нестабильные.
На мой взгляд (сообщество разделилось в своих мнениях по этому вопросу),
гораздо лучше использовать коммуникативные тесты вместо одиночных. Комму-
никативный тест запускает тестируемый код, не заменяя его зависимостей. Код ис-
пользует реальные зависимости во время своей работы; это значит, тесты не пройдут,
если зависимости работают не так, как от них ожидает тестируемый код. На рис. 13.2
показана разница.
Рис. 13.2. Одиночные и коммуникативные тесты
Лучшие модульные тесты (повторюсь: по моему мнению) — узкие коммуникатив-

ные. Они узкие потому, что тест проверяет только тестируемый класс или модуль.
Они коммуникативные потому, что тестируемый код все еще вызывает свои реальные
зависимости. Результат — быстрые тесты, которые позволяют вам быть полностью
уверенным в том, что ваш код работает, как ожидается, при этом не требуя накладных
расходов и затрат на дополнительные широкие тесты.
В связи с этим возникает вопрос: как предотвратить общение коммуникативных
тестов с внешним миром? Значительная часть ответа — проектировать ваш код,
отделяя инфраструктуру от логики, как я вскоре поясню. Другая часть — запрограм-

мировать ваши инфраструктурные обертки, чтобы они могли изолировать себя от
внешнего мира. В моей статье Testing Without Mocks [Shore2018a] перечислены модели
дизайна, которые это делают, а в [Shore2020b] представлены развернутые примеры.
Разделение инфраструктуры и логики

Чистая логика, без зависимостей от чего-либо, касающегося внешнего мира, — самый
простой для тестирования код. Безусловно. Таким образом, чтобы сделать ваши тесты
более быстрыми и надежными, отделите логику от инфраструктуры. Оказывается,
это позволяет сохранять чистоту дизайна.
Есть множество способов разделять инфраструктуру и логику. В статьях
Hexagonal Architecture [Cockburn2008] Алистера Кокберна, Functional Core, Imperative
Shell [Bernhardt2012] Гэри Бернхарда и A-Frame Architecture (написанной мной)
[Shore2018b] представлены похожие способы решения проблемы. Вообще говоря,
они подразумевают изменение кода таким образом, чтобы логика стала «чистой»
и не зависела от инфраструктурного кода.
В случае A-Frame-архитектуры речь идет о верхнем «прикладном» (application)
уровне, координирующем уровни «логика» и «инфраструктура», которые ничего
не знают друг о друге. Вот упрощенный пример кода, который вы можете встретить
на прикладном уровне:
let input = infrastructure.readData(); // инфраструктура
let output = logic.processInput(input); // логика
infrastructure.writeData(output); // инфраструктура
В [Shore2018b] можно найти более подробную информацию. В [Shore2020b] досту-

пен полный пример. В нем используется A-Frame-архитектура, начиная с эпизода 2.
Применение широких тестов только

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

стов. Но относитесь к ним только как к стра- См. также
ховочной сетке. Если они когда-нибудь и най-
Анализ инцидентов (глава 16)
дут ошибку, которую не обнаружат узкие
тесты, — это говорит о наличии проблем в ва-
шей стратегии тестирования. Разберитесь, что пошло не так, исправьте проблему
недостающего теста и измените ваш подход к тестированию, чтобы предотвратить
подобные пробелы в будущем. В конечном итоге вы будете уверены в своем наборе
тестов и сможете уменьшить количество широких тестов.
Добавление тестов к существующему коду

Иногда вам будет нужно добавить тесты к существующему коду. Либо в коде совсем
не будет тестов, либо будут широкие нестабильные тесты, которые нужно заменить.
При добавлении тестов к коду возникает проблема: что первично — яйцо или
курица. Узкие тесты должны внедриться в код, чтобы настроить зависимости и про-
верить состояние. Если ваш код не был написан с учетом тестируемости (а код, раз-
работанный не с помощью TDD, почти никогда не бывает таким), то вы не сможете
написать хорошие тесты.
То есть вам нужен рефакторинг. Проблема в том, что в сложной кодовой базе
выполнять его опасно. Какие-нибудь побочные эффекты скрываются за каждой
функцией. Повороты логики только и ждут, чтобы сбить вас с толку. Короче говоря,
если вы выполните рефакторинг, то, вероятно, сломаете что-то, не осознавая этого.
То есть вам нужны тесты. Но чтобы тестировать, вы должны сделать рефакторинг.
Но для этого вам нужны тесты. И так далее и тому подобное.
Чтобы разрешить дилемму яйца и курицы, вам нужно быть уверенным, что ре-
факторинги безопасны: что они не изменят поведение кода. К счастью, современные
IDE имеют автоматизированные рефакторинги, и в зависимости от вашего языка
и IDE они могут быть гарантированно безопасными. Согласно Арло Бельши, базо-
вые шесть рефакторингов, нужных вам, называются «Переименовать», «Встроить»,
«Извлечь метод/функцию», «Ввести локальную переменную», «Ввести параметр»
и «Ввести поле». Его статья The Core 6 Refactorings [Belshee2016b] стоит того, чтобы
ее прочитать.
Если у вас нет гарантированно безопасных рефакторингов, то вы можете исполь-
зовать характеристичекие тесты (characterization tests). Они также известны как
фиксирующие (pinning) тесты или approval-тесты. Характеристические тесты — это
временные широкие тесты, которые разработаны для того, чтобы тщательно тести-
ровать каждое поведение кода, который вы меняете. Тестовый фреймворк Approvals
Левелина Фалько, доступный на GitHub по адресу https://github.com/approvals, — эф-
фективный инструмент для создания таких тестов. Видеодемонстрация ката Gilded
Rose Эмили Бач [Bache2018] — отличный пример того, как использовать approval-
тесты для рефакторинга незнакомого кода.
Когда у вас есть возможность делать рефакторинг безопасно, вы можете менять
код, чтобы сделать его чище. Двигайтесь очень маленькими шагами, фокусируясь
на шести базовых рефакторингах Арло Бельши, и запускайте тесты после каждого
шага. Упрощайте и совершенствуйте код до тех пор, пока одна часть его не станет
пригодной для тестов, затем добавьте в ней узкие тесты. Вам может понадобиться
сначала добавить одиночные тесты, а не коммуникативные.
Продолжайте улучшать, совершенствовать и тестировать до тех пор, пока весь
код, над которым вы работаете, не будет покрываться высококачественными узкими
тестами. Как только это произойдет, вы можете удалить диагностические и любые
другие тесты этого кода.
Если вы пишете тесты, то можете писать бы-
стрые надежные тесты. Однако добавление те- См. также
стов к существующему коду может занимать
некоторое время. Поможет внедрение практики
резерва времени.
Когда вы пишете быстрые надежные тесты:
zz вы не «исправляете» нестабильные тесты, запуская набор тестов снова;
zz ваши узкие интеграционные тесты пропорциональны количеству внешних сер-
висов и компонентов, которые использует ваш код;
zz у вас есть только небольшое количество широких тестов;
zz ваш набор тестов в среднем — 100 тестов в секунду.
В сообществе Agile есть две точки зрения о том, как создавать хорошие тесты: клас-
сический подход и мок-подход. В этой книге я отметил классический, но мок-подход,
возглавляемый Стивом Фрименом и Натом Прайсом, тоже заслуживает изучения.
Прочитать их книгу, Growing Object-Oriented Software, Guided by Tests, — лучший
способ познакомиться с этим подходом [Freeman2010].
Представители другой точки зрения полностью отказываются от узких тестов
и используют только широкие. Поначалу это быстро и просто, но по мере роста ва-
шего ПО происходят сбои. В итоге вы придете к тому, что будете тратить на тесты
времени больше, чем сбережете.

В моей статье Testing Without Mocks: A Pattern Language [Shore2018b] можно най-
ти еще больше подробной информации о том, как создавать быстрые надежные
тесты. В прилагаемой серии видео [Shore2020b] показано, как воплотить идеи
на практике.
Несмотря на то что она акцентирует внимание на одиночных тестах больше, чем

мне нравится, книга Working Effectively with Unit Tests Джея Филдса [Fields2015]
переполнена полезными советами по созданию ремонтопригодных тестов.
Working Effectively with Legacy Code1 [Feathers2004] обязательна к прочтению для
любого, кто работает с устаревшим кодом.
РЕФАКТОРИНГ
Мы улучшаем дизайн существующего кода.
Аудитория
Код портится. Это все говорят: энтропия не-
избежна, и хаос в конце концов превращает ваш
прекрасно задуманный, хорошо спроектирован-
ный код в большой ком спагетти.
Я тоже так думал раньше, до того как научился рефакторингу. Теперь у меня есть
рабочая кодовая база десятилетней давности, которая сегодня лучше, чем была в момент
создания. Я бы не хотел возвращаться в прошлое: с каждым годом база становится
значительно лучше, чем была год назад.
Рефакторинг делает это возможным. Это
процесс изменения дизайна вашего кода без Рефакторинг — это
изменения его поведения. То, что делает код, не переписывание кода.
остается тем же самым, но как он это делает —
меняется. Несмотря на распространенное неверное использование термина, ре-
факторинг — это не переписывание кода. И это не произвольное изменение.
Рефакторинг — это осторожный пошаговый подход к инкрементному улучшению
дизайна вашего кода.
Вдобавок рефакторинги обратимы: правильного ответа нет, поэтому иногда вы
будете делать рефакторинг в одном направлении, а иногда — в другом. Точно так
же, как вы можете изменить выражение x2–1 на (x+1)(x–1) и обратно, вы сможете
изменить дизайн вашего кода — и когда вам это удастся, вы сможете держать энтро-
пию под контролем.
Как делать рефакторинг

Вы можете выполнять рефакторинг
См. также
в любое время, но безопаснее это делать,
когда у вас есть хороший набор тестов. Разработка через тестирование (глава 13)
Обычно рефакторинг делают на шаге
Рефлексивный дизайн (глава 14)
«Сделать рефакторинг» цикла TDD.
Кроме того, его делают, чтобы упростить Резерв времени (глава 9)
изменения и сделать код чище.
1
Физерс М. Эффективная работа с унаследованным кодом.
В процессе рефакторинга вы будете выполнять серии очень мелких преобразова-

ний. (Звучит запутанно, но каждая трансформация также называется рефакторингом.)
Каждый рефакторинг — это как поворот кубика Рубика. Чтобы добиться чего-либо
значительного, вы должны выстроить последовательность из нескольких индивиду-
альных рефакторингов, аналогично тому, как выстраивается последовательность
вращений, позволяющая собрать кубик.
Люди, впервые встречающиеся с рефак-
торингом, иногда упускают из виду, что это Чтобы хорошо выполнять
последовательность небольших трансфор- рефакторинг, вы должны действовать
маций. Вы не просто меняете дизайн вашего серией контролируемых шагов.
кода: чтобы хорошо выполнять рефакто-
ринг, вы должны действовать серией контролируемых шагов. Каждый шаг должен
занимать всего несколько мгновений, и после каждого должны проходить тесты.
Рефакторинги весьма разнообразны. Наиболее полное руководство по теме
представлено в книге Мартина Фаулера Refactoring: Improving the Design of Existing
Code [Fowler2018]. Она содержит подробный каталог рефакторингов и заслуживает
изучения. Я узнал о хорошем коде и дизайне из этой книги больше, чем из любого
другого источника.
При этом вам не нужно запоминать все отдельные рефакторинги. Вместо этого
попытайтесь понять основополагающую идею. Автоматизированные рефакторинги
в вашей IDE помогут вам начать, но вам доступно и множество других вариантов.
Хитрость в том, чтобы разбить процесс изменения вашего дизайна на маленькие шаги.
Рефакторинг в действии
Чтобы проиллюстрировать этот момент, я продолжу пример, начатый в подразделе
«Пример TDD» ранее в данной главе. Этот пример невелик по причине экономии
места, но он показывает, как большие изменения можно разбить на индивидуальные
рефакторинги. Каждый рефакторинг занимает несколько секунд.
Чтобы следовать этому примеру, клонируйте git-репозиторий, находящийся по
адресу https://github.com/jamesshore/livestream, проверьте тег 2020-05-05-end
и измените файл src/rot-13.js. Инструкции о том, как запустить сборку, находятся
в файле в README.md.
В конце примера TDD у меня был модуль JavaScript, который выполнял шиф-
рование ROT-13:
}
let result = "";

}
return result;
}
charCode += 13;
charCode -= 13;
}
}
function isBetween(charCode, firstLetter, lastLetter) {

}
function codeFor(letter) {
return letter.charCodeAt(0);
}
Код работал и имел достойное качество, но был слишком многословным. Он ис-

пользовал коды символов для определения диапазонов, хотя JavaScript позволяет
сравнивать символы напрямую. Вместо того чтобы использовать методы codeFor(),
isBetween(), можно провести прямое сравнение, вот так:
function isBetween(letter, firstLetter, lastLetter) {
return letter >= firstLetter && letter <= lastLetter;
}
Это изменение можно внести сразу, однако при внесении больших изменений
в реально работающее ПО образуются баги и вы можете попасть в положение, из
которого трудно выбраться. (Такое со мной случалось. При публичной демонстрации
рефакторинга. Ой…) Как в примере TDD, чем лучше вы знаете, как делать рефакто-
ринг, тем меньшие шаги вы сможете делать и тем быстрее будете продвигаться вперед.
Поэтому я продемонстрирую рефакторинг шаг за шагом, безопасным способом.
Начнем с того, что isBetween() принимает значение charCode, не letter. Мне
потребовалось изменить вызывающий его transformLetter(), чтобы он передавал
символьное значение letter . Но в transformLetter() отсутствует символьная
переменная letter. Даже transform() не содержит символьной переменной letter.
Поэтому первое, что понадобилось ввести, — это следующий код:
}
let result = "";

let letter = input[i];
}
return result;
}
function transformLetter(charCode) ...
Это была ничего не исполняющая инструкция: я ввел переменную, но ничто

ее не использовало, поэтому я ожидал, что тесты пройдут. Я их запустил, и они
прошли.
Хотя переменная letter не использовалась, ее введение дало мне возможность
передавать данную переменную в transformLetter. Это был мой следующий шаг.
Обратите внимание на то, насколько малень-
кими были эти шаги. По опыту я знал, что ручной
См. также
рефакторинг сигнатур функций часто проис-
ходит неудачно, поэтому хотел, чтобы это дела- Нулевое трение (глава 13)
лось постепенно. Такие маленькие шаги требуют
сборки с нулевым трением:
exports.transform = function(input) {
}
let result = "";

result += transformLetter(letter, charCode);
}
return result;
};
function transformLetter(letter, charCode) {

charCode += 13;
charCode -= 13;
}
}
Тесты снова прошли. Теперь, когда у меня была letter в transformLetter(), я мог
передать ее в isBetween():
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;
}
}
function isBetween(letter, charCode, firstLetter, lastLetter) {

}
(Тесты прошли). И теперь, когда в isBetween() передавалась переменная letter,

я наконец мог изменить isBetween, чтобы использовать ее:
}
(Тесты прошли). Метод codeFor() больше не использовался, и я его удалил.

(Тесты прошли). Я выполнил то, что изначально намеревался, но теперь, видя, как
выглядит код, я обнаружил больше возможностей для упрощения. Это обычное дело
при рефакторинге: чистка кода делает видимы-
ми больше возможностей для чистки. Решение См. также
о том, браться ли за дополнительные очистки,
зависит от ваших предпочтений и имеющегося Резерв времени (глава 9)
в вашем распоряжении резерва времени.
Вот как выглядел код:
exports.transform = function(input) {
}
let result = "";

}
return result;
};

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;
}
}

}
У меня был достаточный резерв времени, и я решил продолжить рефакторинг.

Функция isBetween(), казалось, не имела особой ценности, поэтому я встроил ее.
Я смог сделать это с помощью одного большого шага, поскольку использовал авто-
матическую функцию рефакторинга Inline Function в своем редакторе:
if (letter >= "a" && letter <= "m" || letter >= "A" && letter <= "M") {
charCode += 13;
} else if (letter >= "n" && letter <= "z" || letter >= "N" && letter <= "Z") {
charCode -= 13;
}
}
(Тесты прошли). Передача charCode казалась лишней, поэтому я скопировал

логику charCode из transform в transformLetter():
charCode = letter.charCodeAt(0);
charCode += 13;
charCode -= 13;
}
}
(Тесты прошли). Затем я удалил ненужный параметр charCode.

}
let result = "";

}
return result;
};

let charCode = letter.charCodeAt(0);
charCode += 13;
charCode -= 13;
}
}
(Тесты прошли). Это было хорошим упрощением, но я увидел возможность

сделать еще лучше. Вместо того чтобы делать ручной цикл по строке, я понял, что
мог бы использовать регулярное выражение для вызова transformLetter():
}
return input.replace(/[A-Za-z]/g, transformLetter);

};
function transformLetter(letter) {
charCode += 13;
charCode -= 13;
}
}
(Тест прошел). Сначала я подумал, что получилось хорошо, насколько только

возможно. Но меня беспокоило /[A-Za-z]/ в регулярном выражении. Я включил это
для того, чтобы код был более читаемым, но сравнение каждого символа с /./ рабо-
тало бы так же хорошо. Регулярное выражение в действительности ничего не делало.
Потом меня осенило: если бы регулярное выражение позволяло делать так, чтобы
только буквы передавались в transformLetter(), то я мог бы упростить оператор if.
Я не был в этом уверен на 100 %, поэтому начал проверять постепенно:
charCode += 13;
charCode -= 13;
}
}
Тесты не прошли! Я забыл, что в ASCII заглавная Z идет перед строчной a. Мне
нужно было сначала нормализовать символ:
if (letter <= "m" || letter >= "A" && letter.toUpperCase() <= "M") {
charCode += 13;
charCode -= 13;
}
}
Код был исправлен. Теперь я чувствовал, что будет безопасно удалить вторую
часть оператора if:
if (letter.toUpperCase() <= "M") {
charCode += 13;
charCode -= 13;
}
}
(Тест прошел). Код был хороший, но меня беспокоило изменение переменной

charCode. Я предпочитаю более функциональный стиль. Вместо того чтобы напрямую
модифицировать переменную charCode, я решил попробовать сохранять величину
значения сдвига (rotation).
Сначала я ввел новую переменную:
let rotation;
charCode += 13;
rotation = 13;
} else {
charCode -= 13;
rotation = -13;
}
}
(Тест прошел). Тогда я использовал этот код вместо того, чтобы изменять charCode:
let rotation;
charCode += 13;
rotation = 13;
} else {
charCode -= 13;
rotation = -13;
}
return String.fromCharCode(charCode + rotation);
}
(Тест прошел). И я встроил charCode, используя автоматический рефакторинг

в моем редакторе:
let rotation;
rotation = 13;
} else {
rotation = -13;
}
return String.fromCharCode(letter.charCodeAt(0) + rotation);
}
(Тест прошел). В итоге я сконвертировал оператор if в постоянное выражение.

В моем редакторе это были два автоматических рефакторинга: автоматическое
преобразование if в ?: и автоматическое объединение объявления и назначения.
Затем я вручную изменил let на const. Тесты проходили после каждого шага, и за-
конченный код выглядел так:
}
return input.replace(/[A-Za-z]/g, transformLetter);

};
const rotation = letter.toUpperCase() <= "M" ? 13 : -13;
return String.fromCharCode(letter.charCodeAt(0) + rotation);
}
Это хорошее усовершенствование изначального кода. Я мог бы сделать его еще

более компактным, но это ухудшило бы его читабельность, поэтому я был доволен
таким результатом. Некоторые могут поспорить, что тернарное выражение — уже
слишком далекий шаг.
Именно так выглядит рефакторинг, шаг за шагом, безопасным способом. Хотя это
и маленький пример, он точно отражает реальный рефакторинг. В более крупных
кодовых базах постепенные изменения, такие как это, служат основой для больших
улучшений.
Маленькие шаги — тоже улучшение. Этот пример достаточно простой, и вы мог-
ли бы превратить все это в один или два больших шага. Но если вы научитесь делать
маленькие шаги для таких маленьких задач, как эта, то сумеете сделать это и для
больших задач, и именно так сможете успешно выполнить рефакторинг большой
кодовой базы.
Чтобы увидеть пример последовательного рефакторинга в применении к более
крупной задаче, посмотрите превосходную сессию Эмили Бач по ката Gilded
Rose [Bache2018].
Разбивая большие изменения дизайна на

последовательность мелких рефакторингов, См. также
вы можете вносить существенные изменения,
ничем не рискуя. Вы даже можете вносить их Рефлексивный дизайн (глава 14)
последовательно, инкрементами, исправляя
одну часть дизайна в один день, а другую часть — в другой. Это необходимая часть
использования вашего резерва времени для внесения больших изменений и ключ
к успешному дизайну Agile.
Вопросы
Как часто мы должны делать рефакторинг?
Постоянно. Выполняйте небольшие ре- См. также
факторинги в процессе TDD и более серьез-
ные — в свободное время, за счет резерва (глава 13)
времени. Каждую неделю ваш дизайн дол-
жен становиться лучше, чем за неделю до Резерв времени (глава 9)
этого.
Разве рефакторинг — это не переделка? Разве мы не должны проектировать наш
код правильно с самого начала?
Если бы было можно делать дизайн вашего кода великолепно с самого начала, то
рефакторинг был бы переделкой. Однако, как знает каждый, кто работал с большими
системами, ошибки закрадываются всегда. Даже если нет, потребности вашего ПО
со временем меняются, и ваш дизайн должен быть обновлен соответственно. Рефак-
торинг дает вам возможность постоянного совершенствования.
А что насчет нашей базы данных? Вот она действительно нуждается в улуч-
шении.
Вы можете делать рефакторинг и баз данных. Как и в случае с обычным рефак-
торингом, хитрость заключается в том, чтобы действовать маленькими, сохраня-
ющими поведение шагами. В книге Refactoring Databases: Evolutionary Database
Design [Ambler2006] объясняется, как это делать. Миграция данных занимает много
времени, что требует особых условий развертывания, как описывается в подразделе
«Миграция данных» главы 15.
Как мы можем вносить большие изменения, не конфликтуя с остальными членами
команды?
Регулярно общайтесь и используйте не-
прерывную интеграцию. Прежде чем пред- См. также
принять рефакторинг, который затронет
значительную часть кода, интегрируйте ваш Непрерывная интеграция (глава 13)
существующий код и сообщите людям, что
вы собираетесь делать, затем сразу же повторите интеграцию. Они могут снизить
вероятность конфликтов, копируя ваши изменения, как только вы выполните ин-
теграцию.
Я не могу делать рефакторинг, не повредив множество тестов! Что я делаю
не так?
Ваши тесты должны проверять поведение вашего кода, а не реализацию, а рефак-
торинг должен изменять реализацию, а не поведение. Так что если вы все делаете
правильно, то тесты не должны выходить из строя из-за рефакторинга.
Некоторые рефакторинги меняют сигнатуры функции или метода, но эти из-
менения касаются только интерфейса, а не лежащего в основе поведения. Рефак-
торинг интерфейса требует изменения всех вызывающих его объектов, в том числе
ваших тестов, но ваши тесты не должны требовать каких-то особых изменений.
Если ваши тесты всегда повреждаются
при рефакторинге или затрудняют изме-
нения интерфейса, это может быть связано См. также
с неправильным использованием тестовых
Быстрые надежные тесты (глава 13)
дублей (таких как объекты-имитации).
Ищите способы улучшить дизайн вашего
теста.
Рефакторинг требует хороших тестов и сборки с нулевой пробуксовкой. Без тестов
рефакторинг рискован, поскольку вы не можете с легкостью сказать, не повредили ли
ваши изменения случайно что-нибудь. (Не-
которые IDE предоставляют несколько га-
См. также
рантированно безопасных рефакторингов,
но другие рефакторинги все же требуют Разработка через тестирование
тестов.) Без сборки с нулевой пробуксовкой (глава 13)
обратная связь слишком медленная, чтобы
позволять действовать маленькими шагами.
Технически возможно сделать рефакторинг,
но это будет медленно и мучительно.
Кроме того, рефакторинг требует кол- См. также
лективного владения кодом. Любые зна-
чительные изменения дизайна потребу- (глава 12)
ют от вас изменения многих частей кода.
Коллективное владение кодом дает вам
необходимое разрешение на это. Таким же
образом рефакторинг требует непрерывной интеграции. Без нее слияние кода будет
кошмаром, состоящим из конфликтующих изменений.
Рефакторинг опубликованных интерфейсов (интерфейсов, используемых
кодом за пределами контроля вашей команды) требует осторожного управления.
Вам нужно будет координировать свои действия с каждым, кто использует такие
интерфейсы. По этой причине часто лучше избегать рефакторинга опубликован-
ных интерфейсов.
Некоторые среды программирования, особенно среды с «малым кодом» или «без
кода», могут затруднить рефакторинг. То же самое можно сказать и о высокодина-
мичных стилях программирования, таких как обезьяний патч (monkey-patching)
(код, который переопределяет существующие интерфейсы) или отражение на основе
строк. В таких ситуациях рефакторинг может не стоить затраченных средств, но обя-
зательно учитывайте возросшие затраты на изменения и снижение долговечности,
связанные с отказом от рефакторинга.
Можно, хотя и не часто, тратить слишком много времени на рефакторинг. Вам
не нужно делать рефакторинг кода, который не имеет отношения к вашей текущей
работе. Таким же образом уравновешивайте необходимость завершить истории

с необходимостью иметь хороший код. Пока код лучше, чем он был тогда, когда вы
начали с ним работать, вы делаете достаточно. В частности, если вы думаете, что код
мог бы быть лучше, но не знаете, как его улучшить, то можно оставить улучшение
кому-то другому. Это одна из замечательных особенностей коллективного владения:
кто-то сделает улучшение позже.
Когда вы используете рефакторинг как ежедневную часть вашего инструмента
рия:
zz код постоянно улучшается;
zz вы делаете значительные изменения дизайна уверенно и безопасно;
zz каждую неделю код в чуть лучшем состоянии, чем он был неделю назад.
Реальных альтернатив рефакторингу не существует. Независимо от того, насколько
тщательно вы проектируете ваш код, в конечном итоге он не будет соответствовать
потребностям вашего приложения. Без рефакторинга эта несогласованность при-
ведет к тому, что вам придется выбирать между необходимостью переписать ПО
ценой огромных затрат и риска или полностью отказаться от него.
Однако всегда есть возможности научиться делать рефакторинг лучше. Обычно
это подразумевает выяснение того, как делать маленькие, безопасные, более надеж-
ные шаги. Продолжайте практиковаться. Я занимаюсь этим 20 лет и все еще учусь
новым трюкам.

Refactoring: Improving the Design of Existing Code1 [Fowler2018] — главный справочник
по рефакторингу. Это еще и отличная книга. Раздобудьте ее.
Refactoring to Patterns2 [Kerievsky2004] вносит дополнительные разъяснения в ра-
боту Фаулера, показывая, как рефакторинги можно выстроить так, чтобы добиться
значительных изменений дизайна. Эта книга позволяет больше узнать о том, как
с помощью отдельных рефакторингов достигать больших результатов.
Refactoring Databases: Evolutionary Database Design3 [Ambler2006] показывает, как
можно применять рефакторинг к схемам баз данных.
1
Фаулер М. Рефакторинг: улучшение проекта существующего кода.
2
Кериевски Дж. Рефакторинг с использованием шаблонов.
3
Эмблер С. В., Садаладж Прамодкумар Дж. Рефакторинг баз данных: эволюционное проектиро-
вание.
СПАЙК-РЕШЕНИЯ
Мы ставим маленькие изолированные экспери- Аудитория
менты, чтобы обосновать наши решения.
Вы, вероятно, заметили, что команды Agile ценят
конкретные данные куда больше, чем домыслы. Столкнувшись с вопросом, не вы-
думывайте ответ — проведите эксперимент! Выясните, как вы можете использовать
данные, чтобы добиться прогресса.
Именно для этого нужны спайк-решения. Спайк-решение, или спайк — это тех-
ническое исследование. Это маленький эксперимент в виде кода, позволяющий
провести исследование и найти решение проблемы. Обычно это занимает меньше
одного дня. Когда у вас есть ответ, спайк удаляется.
Люди часто путают спайк-решения с «ходячими скелетами»: голым кодом, ко-
торый демонстрирует идею от начала до конца. Это начало производственной
реализации. Спайк же, напротив, сосредоточен лишь на конкретной технической
проблеме и впоследствии удаляется.
Спайк-решения используют код, так как нет ничего конкретнее. Вы можете

прочитать столько книг, учебников или ответов онлайн, сколько вам нравится, но
чтобы действительно понять решение, напишите работающий код. Важно смотреть
с практической точки зрения, а не только с теоретической. Лучший способ сделать
это зависит от того, что вы хотите узнать.
Простые вопросы
Если у вас есть вопросы о языке, библиотеках или инструментах, то напишите одну-
две строки кода. Если в вашем языке программирования есть REPL (интерактивное
программирование), то часто это самый быстрый способ получить ответ. Например,
чтобы узнать, может ли JavaScript использовать операторы сравнения для строк, вы
можете открыть консоль браузера:
> "a" < "b"
true
> "a" > "b"
false
> "a" === "a"
True
В качестве альтернативы вы можете написать короткий тест. Вы можете разме-

стить его рядом с вашими реальными тестами и потом удалить. Например, если вы
хотели узнать, выдает ли Java исключение при арифметическом переполнении, то
одноразовый тест может ответить на этот вопрос:
@Test
public void deleteMe() {
int a = Integer.MAX_VALUE + 1; // тест завершится ошибкой, если возникнет исключение

System.out.println("No exception: a = " + a);
}
// Результат тестового прогона: "No exception: a = -2147483648"
Сторонние зависимости
Чтобы узнать, как использовать сторонние зависимости, такие как библиотека,
фреймворк или сервис, напишите небольшую автономную программу, которая по-
зволит исследовать, как работает эта зависимость. Не утруждайте себя написанием
промышленного кода — сфокусируйтесь на демонстрации основной идеи. Запустите
из командной строки, жестко закодируйте значения и не используйте ввод данных
от пользователей. Создайте минимально достаточный дизайн и абстракцию, только
чтобы не запутаться.
Что касается сложных зависимостей, таких как фреймворки, то я часто начинаю
с их руководства. Однако в них, как правило, делается акцент на быстром запуске
и работе, а не на том, чтобы помочь вам понять, как работает фреймворк. В них часто
содержится много волшебного инструментария, из-за чего фреймворк сложнее по-
нять, а не проще. Поэтому сделайте собственный пример. Уберите магию, вызывайте
все API вручную и упростите ненужную сложность. Думайте о своих вариантах
использования и демонстрируйте, как они будут работать.
Когда закончите, можете разместить спайк в своем кодовом репозитории, чтобы
он выступал в качестве справочника, пока вы готовите реальную реализацию. (Я ис-
пользую каталог /spikes.) Создав производственную реализацию, вы можете или
удалить спайк, или сохранить на будущее в зависимости от его полезности.
Дизайн-эксперименты
Если у вас есть идея для улучшения дизайна,
но вы не знаете точно, как она сработает, то вы См. также
можете сделать спайк дизайна. Я применяю
этот подход, когда не уверен, что мои идеи
дизайна будут работать так, как я думаю.
Чтобы сделать спайк дизайна, создайте временную одноразовую ветку в вашем
репозитории. В ней вы можете экспериментировать, не беспокоясь о безопасности
рефакторингов или успешности прохождения тестов. Вам даже не нужно, чтобы код
работал правильно. Цель спайка — только поэкспериментировать с идеей дизайна
и посмотреть, как она работает на практике.
Если ваша идея дизайна не работает, то просто удалите ветку. Если она работает,
то вы можете сохранить ее временно, но не объединяйте ее с вашим рабочим кодом.
Переделайте изменение заново, на этот раз позаботившись о рефакторингах и об-
новлении тестов, если это необходимо. Когда закончите, удалите ветку.
Избегайте слишком интенсивного ис-

пользования дизайн-спайков. Вы вполне См. также
можете создавать дизайн-спайк в любой
Инкрементный дизайн (глава 14)
момент, когда это может вам помочь разо-
браться в вариантах вашего дизайна, однако Простой дизайн (глава 14)
не нужно применять их в каждой истории. Рефлексивный дизайн (глава 14)
Вы также должны быть в состоянии созда-
вать новые дизайны, начиная с простого, очевидного подхода, который последова-
тельно усложняется, и должны уметь изменять существующие дизайны с помощью
рефлексивного дизайна.
Найдите время для спайков

Маленькие спайки «для коротких вопросов» обычно выполняются сразу. Вы види-
те необходимость прояснить небольшой технический вопрос, пишете и удаляете
быстрый спайк, двигаетесь дальше.
Зависимости и спайки для дизайна могут
применяться несколькими способами. В од- См. также
них ситуациях они планируются намерен-
Истории (глава 8)
но, с помощью спайк-истории или задачи.
В других вы не поймете, что история требует Планирование задач (глава 9)
спайка, пока не окажетесь в середине про- Резерв времени (глава 9)
цесса работы над ней. Когда это происходит,
вы можете или добавить задачу на вашу доску планирования, или просто работать
над спайком как частью вашей текущей задачи. В любом случае ваш резерв времени
компенсирует затраты.
Вопросы
В чем разница между прототипом и спайком?
Понятие «прототип» не имеет строгого определения, но обычно относится к не-
полному или нефункционирующему ПО, которое сделано для имитации конечного
продукта. Прототип часто используют для демонстрации UI или для обучения,
создавая одноразовую версию приложения.
Спайки гораздо более целенаправленны. Они создаются для того, чтобы ответить
на узкий технический вопрос, а не для имитации конечного продукта.
Мы должны работать над спайками в режиме парного или группового програм-
мирования?
На ваш выбор. Спайки не нужно поддерживать в будущем, поэтому даже командам
со строгими правилами парного программирования не требуется писать спайки в парах.
Очень эффективный способ парного или группового программирования при ра-
боте над спайками — когда один человек исследует технологию, а в это время другой
пишет код. Еще один вариант — люди работают отдельно над разными подходами,
каждый занимается собственным исследованием и кодированием, а затем они со-

бираются вместе, чтобы оценить прогресс и поделиться идеями.
Мы действительно должны удалять спайки?
Если вы не думаете, что кто-то будет обращаться к ним позднее, то удаляйте их.
Помните: цель спайк-решения — дать вам информацию и опыт, необходимый для
решения проблемы, а не создать код, который ее решает. Реальный рабочий код
обычно оказывается лучшим справочным материалом, чем спайк.
Когда мы должны создать спайк?
Когда это может помочь. Выполняйте спайк всякий раз, когда ограничения в на-
писании промышленного кода становятся на пути поиска решения.
Что, если благодаря спайку обнаруживается, что проблема более сложная, чем
мы думали?
Это хорошо. Теперь у вас есть информация, которую вы должны знать. Возможно,
ваши заказчики в команде пересмотрят значение истории, над которой вы работаете,
или, может быть, вы должны придумать другой способ достижения своей цели.
Избегайте соблазна создать полезные или универсальные программы из своих спай-
ков. Сосредоточьтесь на ответе на конкретный технический вопрос и прекратите
работать над спайком, как только он ответит на этот вопрос. Таким же образом нет
необходимости создавать спайк, когда вы уже хорошо поняли технологию.
Не используйте спайки как предлог увер-
нуться от дисциплинарной разработки на См. также
основе тестирования и рефакторинга. Ни-
когда не копируйте код спайка в рабочий Разработка через тестирование
код. Даже если спайк делает точно то, что (глава 13)
вам нужно, перепишите его, используя TDD, Рефакторинг (глава 13)
чтобы он отвечал вашим стандартам рабо-
чего кода.
Когда вы проясняете технические вопросы с помощью хорошо управляемых изо-
лированных экспериментов:
zz вместо того чтобы строить предположения о том, как будет работать ваша про-
грамма, вы проводите эксперимент, который показывает это;
zz сложность вашего рабочего кода не мешает вашим экспериментам.
Спайк-решения — это техника обучения, основанная на выполнении маленьких
конкретных экспериментов. Некоторые выполняют эти эксперименты в своем рабо-
чем коде, что увеличивает количество возможных ошибок. Если что-то не работает
так, как ожидалось, то не потому ли, что вы неправильно понимаете технологию?
Или это из-за невидимого взаимодействия с рабочим кодом? Автономные спайки

избавляют от этой неопределенности.
Альтернатива спайк-решениям — исследование проблемы с помощью поиска
в Интернете, чтения теории и поиска фрагментов кода онлайн. Это может помочь
решить небольшие проблемы, но при более крупных проблемах лучший способ
действительно понять технологию — погрузиться в работу. Если нужно, то начните
с кода, который найдете онлайн, но затем упростите и адаптируйте пример. Почему это
работает? Что происходит, когда вы меняете выставленные по умолчанию значения
параметров? Используйте спайки, чтобы прояснить ваши представления.
Еще одна альтернатива, специально предназначенная для изучения сторонних
зависимостей, — начать с написания тестового кода, который проверяет эту зави-
симость. Узнав, как она работает, сделайте рефакторинг, разделив ваш эксперимент
на части «тест» и «реализация», а затем перенесите реализацию в ваш рабочий код.
Этот подход начинается как спайк, но превращается в высококачественный проте-
стированный рабочий код. В эпизоде 5 [Shore2020b] демонстрируется эта техника
начиная с 13:50, а в эпизоде 17 содержится больший пример.
ГЛАВА 14
Дизайн
Как правило, со временем внесение изменений в ПО становится все более дорого-

стоящим.
Я не знаю никаких хороших исследований на эту тему1, но думаю, что это испытал
на себе каждый программист. При запуске новой кодовой базы мы невероятно продук-
тивны, но с течением времени изменять что-либо становится все труднее и труднее.
Это проблема для Agile. Если изменения со временем становятся значительно
более дорогостоящими, то модель Agile перестает иметь смысл. Вместо этого было бы
разумно принимать как можно больше решений заранее, когда они наименее дороги.
Фактически это именно то, что пытались делать методы разработки, существовавшие
до Agile.
Чтобы Agile работал, кривая стоимости изменений должна быть относительно
плоской или даже снижаться со временем. Кент Бек говорил об этом в своей первой
книге об XP:
[Плоская кривая стоимости изменений] является одним из условий XP. Это тех-
ническая предпосылка XP… Если сглаженная кривая стоимости изменений делает
XP возможным, то крутая кривая делает XP неприемлемым. Если изменения
разорительно дороги, то бросаться вперед, не обдумав все тщательным образом,
будет сумасшествием. Но если изменения будут оставаться дешевыми, то дополни-
тельная ценность и снижение рисков, обеспечиваемые более ранней и конкретной
обратной связью, перевесят стоимость ранних изменений [Beck2000a] (гл. 5).
Но (как все мы знаем по опыту) стоимость изменений непостоянна. Она возрас-

тает со временем. Значит ли это, что команды Agile обречены разваливаться под
тяжестью кода, непригодного для обслуживания и поддержки?
Гениальность XP состояла в том, что в него входили практики для проактивного
снижения стоимости изменений. Эти практики в совокупности назывались эволю-
ционным дизайном. XP остается единственным из доминирующих методов Agile,
в котором они есть. И это досадно, поскольку без эволюционного дизайна команды
1
Наиболее часто цитируемый источник — Барри Боэм, у которого есть диаграмма, показывающая
экспоненциальный рост затрат, но она демонстрирует затраты на исправление дефектов по фа-
зам, а не затраты на внесение изменений с течением времени. И, как оказывается, эта диаграмма
неточно отражает лежащие в ее основе данные. Отличную работу по поиску данных проделал
Лорент Боссавит в [Bossavit2013] (гл. 10 и приложение Б).
Глава 14. Дизайн 503
Agile действительно разваливаются под тя-

жестью кода, непригодного для дальнейшего Без эволюционного дизайна
обслуживания. команды Agile разваливаются
Я впервые услышал об эволюционном дизай- под тяжестью кода, непригодного
не в 2000 году. Это звучало нелепо, но я уважал для обслуживания.
людей, рекомендовавших его, поэтому пошел
на эксперимент. Моя команда как раз должна была начинать новый проект. Мы на-
чали с традиционного предварительного дизайна, а далее применили эволюционный.
Это сработало. Это работало невероятно хорошо. Эволюционный дизайн привел
к стабильному улучшению, дав нам более чистый, понятный и легче изменяемый
дизайн по сравнению с предварительным дизайном, с которого мы начали. С того
времени я продолжаю расширять границы эволюционного дизайна.
По моему опыту, эволюционный дизайн действительно снижает стоимость из-
менений со временем. Я замечаю это снова и снова. Как и в случае с традиционным
дизайном, я не знаю никаких хороших исследований на эту тему, но могу поделиться
некоторыми эмпирическими данными.
С 2012 по 2018 год я готовил скринкасты сессий кодирования, проходивших
в прямом эфире, посвященных эволюционному дизайну и другим практикам XP.
Я записал более 600 эпизодов, что дало в сумме 150 часов тщательно задокумен-
тированного эволюционного дизайна. Феномен, о котором я говорю (стабильное
снижение стоимости изменений), многократно повторяется в ходе скринкаста1.
Один из примеров — реализация живого сетевого взаимодействия во время
скринкаста (рис. 14.1). Я разбил функциональность сетевого взаимодействия на
пять историй: сначала сделал сетевой функцию указателя мыши пользователя, что
заняло 12 часов; потом рисование линий (6½ часов); очистка экрана (2¾ часа); и две
каверзные истории-доработки (¾ часа и ½ часа). Хотя эти две финальные истории
были гораздо более сложными, чем изначальные сетевые, они так же были выполне-
ны гораздо быстрее, поскольку могли полагаться на чистый дизайн в своей основе.
Рис. 14.1. Реальный эволюционный дизайн
1
Скринкасты доступны по адресу https://www.letscodejavascript.com. Пример с сетевым взаимо-
действием можно найти в эпизодах 370–498 канала.
Это совпадает с моим опытом. В реальном мире каждый новый дизайн повторяет
кривую, показанную на рисунке, вследствие чего внешний вид стоимости изменений
становится похож на «зуб пилы». Общая тенденция, однако, нисходящая. Благодаря
эволюционному дизайну ваш дизайн стабильно улучшается со временем, все больше
и больше упрощая изменения вашего ПО. Улучшения тоже смешиваются: например,
финальным сетевым изменениям пошли на пользу предыдущие изменения дизайна,
которые я внес в код обработки событий фронтенда.
Традиционный дизайн начинается быстро, когда все делается с чистого листа.
Эволюционный дизайн — наоборот: вначале вы все еще нащупываете путь, улучшая
дизайн по мере появления у вашей команды новых идей. Но потом традиционный
дизайн замедляется, а эволюционный ускоряется. Спустя примерно 4–6 недель
в моем случае кривые пересеклись: с кодом, написанным с помощью эволюционно-
го дизайна, проще и быстрее работать, чем с традиционным кодом такого же возрас-
та. И он продолжает улучшаться.
Успешность Agile в долгосрочной перспек-
тиве зависит в первую очередь от эволюцион- Успешность Agile в долгосрочной
перспективе зависит в первую
ного дизайна. Он революционный. И об этом
очередь от эволюционного
мало кто знает. дизайна.
В этой главе содержатся три практики эво-
люционного дизайна.
zz С помощью практики «Инкрементный дизайн» члены команды могут создавать
дизайн одновременно с процессом поставки продукта.
zz Благодаря практике «Простой дизайн» можно создавать дизайны, которые легко
модифицировать и поддерживать.
zz Практика «Рефлексивный дизайн» позволяет непрерывно улучшать существу-
ющие дизайны.
Источники дизайна
Практики в этой главе основаны на подходе экстремального программирова-
ния к дизайну. В дискуссиях, посвященных XP, это называлось эволюционным
дизайном, и это обобщающее понятие я использую здесь. Кент Бек называл
это простым дизайном в первом издании книги по XP [Beck2000a] и поэтапным
дизайном — во втором [Beck2004]. Я использовал оба термина Бека для практик
в этой главе (каждый из них фокусируется на своем аспекте эволюционного
дизайна) и добавил рефлексивный дизайн, который в ранние годы XP назывался
безжалостным рефакторингом.
Детали, которые я обсуждаю в каждой из практик, почерпнуты из множества ис-
точников, как и мой собственный опыт в эволюционном дизайне. Значительное
влияние оказали Мартин Фаулер и «три товарища» XP — Кент Бек, Рон Джеффрис
и Уорд Каннингем.
ИНКРЕМЕНТНЫЙ ДИЗАЙН
Аудитория
Мы создаем дизайн в процессе поставки.
Команды Agile предъявляют жесткие требования
к своим программистам: каждые неделю или две от
команды ожидают завершения 4–10 историй, ориентированных на заказчика. Каждые
неделю или две заказчики могут пересмотреть текущий план и внести абсолютно
новые истории, не предупреждая заранее. Такой режим устанавливается с самой
первой недели.
Для программистов это означает, что вы должны быть в состоянии реализовы-
вать истории с нуля за одну неделю. Так как план может быть изменен буквально
в любой момент, вы не можете выделить несколько недель на создание проектной
инфраструктуры — эти усилия могут оказаться потраченными впустую, когда план
изменится. От вас ожидается, что вместо этого вы сфокусируетесь на поставке цен-
ных с точки зрения заказчика историй.
Это звучит как рецепт катастрофы. К счастью, инкрементный дизайн позволяет
вам создавать ваш дизайн с помощью инкрементов, маленьких фрагментов, пока вы
выполняете поставку историй.
Никогда не останавливайте работу над дизайном

Компьютерам все равно, как выглядит ваш код. Если он компилируется и запуска-
ется, то компьютер счастлив. Дизайн предназначен для людей: а именно для того,
чтобы программисты могли легко понимать
и менять код. Код хорошо спроектирован, когда Код хорошо спроектирован, когда
стоимость изменений низкая. стоимость изменений низкая.
Следовательно, секрет успешности команд
уровня поставки заключается в том, что они
никогда не перестают работать над дизайном. См. также
Как говорил Рон Джеффрис об экстремальном
программировании, дизайн настолько важен, Парное программирование
что мы делаем его все время. При работе в ре- (глава 12)
жиме парного или группового программирова- Групповое программирование
ния по меньшей мере половина программистов (глава 12)
вашей команды посвящает себя размышлениям Разработка через тестирование
о дизайне, а разработка на основе тестирования (глава 13)
поощряет вас улучшать дизайн практически на
каждом шаге.
Команды поставки постоянно говорят о дизайне, особенно работая в групповом
или парном программировании. Одни разговоры очень детальные, например: «Как
мы назовем этот метод?» Другие — гораздо более короткие, например: «Эти два
модуля имеют некоторые общие обязанности. Мы должны их разделить и сделать
третий модуль». Люди постоянно переключаются между деталями и общей картиной.
Обсуждения дизайна не должны быть запрещены ни для кого из тех, с кем вы сей-
час работаете. Обсуждайте в более многочисленных группах так часто, как считаете
необходимым, и используйте любые техники моделирования, которые, по вашему
мнению, будут полезны. (См. пункт «Легко входите в дискуссии и выходите из них»
главы 7.) Поддерживайте неформальный и совместный стиль обсуждения. Хорошо
помогают в этом простые наброски на белой доске.
Как работает инкрементный дизайн

Инкрементный дизайн работает в комбинации
с простым и рефлексивным дизайном. См. также
1. Простой дизайн — начните с самого простого
дизайна, который только может работать. Простой дизайн (глава 14)
2. Инкрементный дизайн — когда дизайн не вы- Рефлексивный дизайн (глава 14)

полняет все то, что вам нужно, вносите до-
бавления инкрементно.
3. Рефлексивный дизайн — каждый раз, когда вы вносите изменение, улучшайте
дизайн, размышляя о его сильных и слабых сторонах.
Другими словами, когда вы впервые создаете элемент дизайна, неважно, будет ли
это новый метод, новый класс или даже новая архитектура, будьте очень конкрет-
ными. Создайте простой дизайн, который решает именно ту проблему, с которой вы
столкнулись в данный момент, и ничего больше, неважно, насколько простым может
вам казаться решение более общих проблем.
Например, реализуя сетевой указатель мыши, показанный на рис. 14.1, я создал
сетевой класс с методом, посылающим координаты указателя на сервер. Все, что он
делал, — это вызывал мою сетевую библиотеку:
sendPointerLocation(x, y) {
this._socket.emit("mouse", { x, y });
}
Быть настолько конкретным трудно! Опытные программисты мыслят абстракция

ми. Фактически способность мыслить абстракциями часто является знаком хоро-
шего программиста. Избегание абстракций и кодирование для одного конкретного
сценария могут показаться странными, даже непрофессиональными.
Все равно делайте это. Если вы подождете с внедрением абстракций, это позволит
вам создавать более простые и эффективные дизайны. Вам не придется долго ждать.
Когда вы добавляете элемент к дизайну во второй раз, измените дизайн так,
чтобы он был более обобщенным — но лишь настолько, чтобы решить две пробле-
мы, которые он должен решить. Далее просмотрите дизайн и внесите улучшения.
Упростите и проясните код.
Продолжу пример: после отсылки событий указателя я должен был получить их
от сервера. Это привело меня к необходимости ввести классы ClientPointerEvent
и ServerPointerEvent вместо того, чтобы жестко закодировать объект события. Код
стал таким:
sendPointerLocation(x, y) {
this._socket.emit(
ClientPointerEvent.EVENT_NAME,
new ClientPointerEvent(x, y).toSerializableObject()
);
}
Немного сложнее, но более гибко.

Когда вы добавляете элемент к дизайну в третий раз, обобщайте далее — но
опять же лишь настолько, чтобы решить три имеющиеся проблемы. Обычно до-
статочно небольшой поправки в дизайне. Он будет довольно общим на этой стадии.
Снова просмотрите дизайн, упростите и проясните.
Мой следующий шаг в примере был направлен на то, чтобы сделать сетевыми
события рисования. Я начал с того, что сделал метод sendDrawEvent(event). Это
был эксперимент передачи ответственности за создание событий коду уровня при-
ложения. Это работало хорошо, поэтому я обобщил sendPointerLocation(x, y)
и sendDrawEvent(event) до sendEvent(event):
sendEvent(event) {
this._socket.emit(event.name(), event.toSerializableObject());
}
Продолжу эту модель. К четвертому и пятому разу, работая с элементом дизайна

(неважно, будет это метод, модуль или что-то большее), вы, скорее всего, поймете, что
его абстракция прекрасно подходит под ваши потребности. Так как ваш дизайн был
результатом объединения практических потребностей с непрерывным улучшением,
он будет элегантным и эффективным.
Уровни дизайна
Инкрементный дизайн происходит на всех уровнях дизайна — как внутри класса
или модуля, так и между классами и модулями, и даже на уровне архитектуры при-
ложения.
На каждом уровне качество имеет склонность улучшаться рывками. Как правило,
вы развиваете дизайн инкрементно, в течение нескольких циклов, по ходу внося
мелкие изменения. Затем что-то подает вам идею нового подхода к дизайну, для
поддержки которого потребуется серия более существенных рефакторингов. Эрик
Эванс называет это прорывом (breakthrough) [Evans2003] (гл. 8).
Внутри класса или модуля

Если вы практиковали разработку через те-
стирование, то практиковали и инкрементный См. также
дизайн, по крайней мере, на уровне единичного
модуля или класса. Вы начинаете с нуля и соз- Разработка через тестирование
даете полноценное решение уровень за уров- (глава 13)
нем, попутно внося улучшения. Как показывает Рефакторинг (глава 13)
подраздел «Пример TDD» главы 13, ваш код
сначала абсолютно конкретен, зачастую до той степени, когда ответ жестко закодиро-
ван, но затем он постепенно обобщается по мере добавления дополнительных тестов.
Внутри класса или модуля рефакторинги происходят каждые несколько минут, на
шаге «Рефакторинг» цикла TDD. Прорывы могут происходить несколько раз в час,
и их завершение занимает считаные минуты. Например, прорыв случился в конце
подраздела «Рефакторинг в действии» главы 13, когда я понял, что регулярное вы-
ражение позволило мне упростить функцию transformLetter(). Заметьте, что до
этого момента рефакторинги приводили к небольшим стабильным улучшениям.
После прорыва transformLetter() стала кардинально проще.
Между классами и модулями

Используя TDD, легко создавать модули и классы с прекрасным дизайном. Но этого
недостаточно. Вы должны также уделить внимание взаимодействию между модулями
и классами. Если этого не сделать, то общий дизайн будет мутным и запутанным.
В процессе работы учитывайте более широкий контекст. Задавайте себе следу-
ющие вопросы: есть ли сходство между этим кодом и другими частями системы?
Ясно ли прописаны области ответственности и ясно ли представлены концепции?
Насколько хорошо модуль или класс, над которым вы сейчас работаете, взаимодей-
ствует с другими модулями и классами?
Когда вы видите проблему, запишите ее в блокнот. Во время одного из шагов
рефакторинга во время TDD (обычно когда вы дойдете до подходящего для оста-
новки места) посмотрите внимательнее на решения, потом делайте рефакторинг.
Если вы думаете, что ваше изменение в дизайне значительно повлияет на других
членов команды, то сделайте небольшой перерыв, чтобы обсудить это со всеми, со-
бравшись у доски.
Не позволяйте обсуждениям дизайна вылиться в затяжные споры и разногласия.
Следуйте правилу десяти минут: если вы не договорились о направлении раз-
вития дизайна за это время, то попробуйте какой-либо из вариантов и посмотри-
те, как он работает. Если разногласия совершенно непримиримые, то разделитесь
и попробуйте оба варианта в качестве спайк-решений. Ничто не проясняет ва-
риант решения в дизайне так, как работающий код.
Рефакторинги между модулями и между

классами происходят несколько раз в день. См. также
В зависимости от вашего дизайна прорывы
могут случаться несколько раз в неделю, Резерв времени (глава 9)
и их завершение может потребовать не-
скольких часов. (Тем не менее не забывайте продвигаться маленькими шагами.)
Используйте резерв времени для рефакторинга прорывов. В некоторых случаях
у вас не будет времени, чтобы закончить все рефакторинги, которые вы наметили
для себя. Это нормально. Вы делаете достаточно, пока ваш дизайн в конце недели
оказывается в лучшем состоянии, чем был в начале.
Например, работая над небольшим движком для управления контентом, я начал
с реализации единичного класса Server, который обслуживал статические файлы.
Добавляя поддержку трансляции шаблонов Jade в HTML, я начал с того, что ввел
код, который делал это в Server, поскольку это был самый простой подход. Код стал
выглядеть некрасиво после того, как я добавил поддержку динамических конечных
точек, поэтому я включил области ответственности шаблонов в модуль JadeProcessor.
Это привело к прорыву в том, что статические файлы и динамические конеч-
ные точки могли таким же образом быть добавлены в модули StaticProcessor
и JavaScriptProcessor, и в том, что они все могли зависеть от одного и того же ба-
зового класса SiteFile. Это четко разделило сетевую часть, генерацию HTML и код
для управления файлами.
Архитектура приложения
«Архитектура» — слишком перегруженное слово. В данном случае я говорю о по-
вторяющихся паттернах в коде вашей команды. Не формальные паттерны в смысле
Design Patterns1 [Gamma1995], а повторяющиеся условности, проходящие сквозь всю
вашу кодовую базу. Например, веб-приложения часто реализуются таким образом, что
каждая конечная точка имеет определение маршрута и класс контроллера, а каждый
контроллер часто реализован со скриптом транзакции (Transaction Script)2.
Эти повторяющиеся паттерны воплощают вашу архитектуру приложения. Они
ведут к стабильному и согласованному коду, но при этом являются формой дубли-
рования, что усложняет внесение изменений в архитектуру. Например, изменение
подхода в веб-приложении с помощью скриптов транзакций на использование модели
предметной области требует обновления каждого контроллера конечных точек.
Здесь я сосредоточусь на архитектуре приложения, что конкретно подразуме-
вает код, которым управляет ваша команда. Есть также системная архитектура,
которая подразумевает все компоненты вашего развернутого ПО, такие как
сторонние сервисы, сетевые шлюзы, маршрутизаторы и т. д. Чтобы понять, как
применить идеи эволюционного дизайна к системной архитектуре, см. подраз-
дел «Эволюционная системная архитектура» главы 15.
Будьте консервативны при внедрении новых архитектурных паттернов. Вво-

дите только то, что вам нужно в данный момент для имеющегося у вас количества
1
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Паттерны объектно-ориентированного проектиро-
вания. — СПб.: Питер, 2021.
2
Узнать о сценарии транзакции и архитектуре модели предметной области можно из [Fowler2002]
(гл. 9).
кода и поддерживаемых функциональностей. Прежде чем вводить новый паттерн,

спросите себя, действительно ли вам нужно дублирование. Может быть, есть способ
изолировать дублирование в отдельный файл или дать разным частям системы воз-
можность использовать разные подходы.
Например, в движке управления контентом, описанным ранее, я мог начать
с грандиозной стратегии поддержки разных языков шаблонов и разметки. В конце
концов, предполагалось, что это будет одной из функциональностей, отличающих
его от других. Но вместо этого я начал с реализации одного класса Server и позволил
коду со временем вырасти в архитектуру.
Даже после того как я ввел классы для каждого типа разметки, я не пытался за-
ставить их следовать определенному паттерну. Вместо этого я позволил каждому
из них выбрать собственный уникальный подход — тот, который был простейшим
в каждом случае. Со временем оказалось, что некоторые из этих подходов работали
лучше, чем другие, и я постепенно стандартизировал свой подход. В итоге стандарт
был настолько стабильным, что я преобразовал его в архитектуру плагинов. Теперь
я могу поддерживать новый язык разметки или шаблонов, просто поместив файл
в каталог.
Так как архитектурные решения трудно изменить, важно отложить принятие
подобных обязательств. (См. врезку «Последний ответственный момент» в гла-
ве 8.) Упомянутая мною архитектура плагинов сформировалась годы спустя после
первого появления движка управления контентом. Если было необходимо, то я мог
добавить поддержку плагинов раньше, но мне это было не нужно, поэтому я не
торопился. Это позволило мне стандартизировать подход, который вобрал в себя
много опыта и мудрости, и в результате ему не понадобилось дополнительных
изменений.
По моему опыту, прорывы в архитектуре случаются каждые несколько месяцев,
хотя, я думаю, это сильно зависит от команды. Рефакторинг для поддержки прорыва
может занять несколько недель или дольше из-за количества затрагиваемых дубли-
рований. Как и для всех прорывов, это стоит делать, только если это значительное
улучшение, сто́ящее своих затрат.
Изменения в архитектуре могут быть трудоемкими, но обычно они несложные,
как только вы определили новый архитектурный паттерн. Для начала попробуйте
паттерн на какой-либо одной части вашего кода. Дайте ему немного времени (не-
делю или две), чтобы убедиться, что изменение хорошо работает на практике.
Когда убедитесь в этом, приведите остальную часть системы в соответствие с новым
паттерном. Сделайте рефакторинг каждого класса или модуля, с которыми вы ра-
ботаете ежедневно, и с помощью резерва времени обновите остальные классы
и модули.
Продолжайте поставку историй, пока вы-
полняете рефакторинг. Вы могли бы сделать Проще расширить архитектуру,
перерыв в разработке нового, чтобы сделать чем упростить то, что слишком
рефакторинг всего сразу, но это разочаро- амбициозно.
вало бы ваших локальных заказчиков. Со-
блюдайте баланс между техническим совершенством и стоимостью поставки.
Ни то ни другое не должно иметь большего приоритета. Это может приводить
к несоответствиям в коде при переключении, но, к счастью, это в основном эстети-

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

Некоторые команды используют журнал архитектурных решений (architectural
decision records, ADRs) [Nygard2011], чтобы документировать архитектурные
решения, в том числе активные в данный момент архитектурные рефакторинги.
Это простые документы, не больше страницы или двух, хранящиеся в вашем
репозитории рядом с кодом.
Например, кодовая база Node.js имела следующую запись ADR для введения
ключевого слова async. Обратите внимание, насколько запись ADR неформальная
и краткая. Это просто напоминание о решении, которое команда уже совместно
приняла:
Jan 30, 2018: async/await
Теперь поддерживается ES6, так что мы переходим с обратных вызовов на async/

await. Редактируя функцию, которая использует обратный вызов, сделайте ее
рефакторинг, чтобы она вместо этого возвращала обещание (promise), и пере-
именуйте ее, чтобы она заканчивалась на Async().
Чтобы выполнять этот рефакторинг инкрементно, обычно лучше всего добавить
новую myFunctionAsync(), которая существует бок о бок со старой myFunction().
Меняйте по одной вызывающей функции за раз и затем удаляйте старую, как
только все будет готово. (Постарайтесь не останавливаться на полпути, чтобы
у вас не было двух разных функций, делающих одно и то же.)
Поскольку использование вызывающими абонентами await вынуждает вызыва
ющего быть async(), а это имеет деструктивные побочные эффекты. Поэто-
му, вероятно, самое простое для вызывающих функций решение — перейти
с myFunction(callback) на myFunctionAsync().then(...).catch(...). Однако
переход на await myFunctionAsync() — долгосрочная цель, и ей следует отдавать
предпочтение, когда это удобно.
Когда обратные вызовы больше не будут использоваться, удалите эту запись.
Архитектура на основе рисков

Может казаться, что архитектура — слиш-
ком существенная часть, чтобы не разраба- Архитектура слишком важна, чтобы
тывать ее заранее. Я бы сказал обратное: она проектировать ее заранее.
настолько существенна, что должна быть
спроектирована как можно позже, когда у вас есть значительная часть информации
и вы можете принимать наиболее правильные решения.
Некоторые проблемы оказываются слишком дорогостоящими для поэтапных

изменений, например выбор языка программирования, однако я обнаружил, что
множество «архитектурных» решений на самом деле легко изменить, если вы ликви-
дируете дублирования и отдадите предпочтение простоте. Распределенная обработка,
устойчивость, интернационализация, безопасность и структура транзакций обычно
считаются настолько сложными, что вы должны проектировать их с самого начала.
Я не согласен; я работал с ними всеми инкрементно [Shore2004a].
Что вы делаете, если видите приближение серьезной проблемы? Например, если
ваши стейкхолдеры настаивают, чтобы вы не тратили времени на интернациона
лизацию, но вы знаете, что она на подходе и что ее поддержка будет только до-
рожать.
Сложность архитектурных дополнений зависит от качества вашего дизайна.
Например, интернационализация форматирования валюты затруднена, когда код,
выполняющий форматирование, дублируется по всему вашему программному при-
ложению. Но если код форматирования централизован, то его интернационализация
становится простой — или по меньшей мере не сложнее, чем если сделать это с само-
го начала.
Здесь и возникает архитектура на ос-
нове риска. В течение любой недели у вас См. также
будет достаточно времени для рефакторин-
га. Когда вы решите, как его использовать,
отдайте приоритет архитектурным рискам. Резерв времени (глава 9)
Например, если в вашем коде много дубли-
рований способа, которым код выполняет форматирование валюты, то интернацио
нализация рискованна. Приоритизируйте рефакторинги, которые ликвидируют
дублирование (рис. 14.2).
Рис. 14.2. Используйте риск, чтобы управлять рефакторингом

Ограничьте свои усилия улучшением дизайна. Не добавляйте новых функцио-

нальностей. Например, можно делать рефакторинг класса Currency, чтобы упростить
его интернационализацию в будущем. Однако не нужно интернационализировать
его одновременно, до тех пор пока вы не начнете работать над историей интернацио
нализации. После рефакторинга его будет так же легко интернационализировать,
как и сейчас.
Вопросы
Разве инкрементный дизайн не дороже, чем предварительный?
По моему опыту, как раз наоборот. На это есть две причины. Во-первых, инкре-
ментный дизайн реализует только код, достаточный для выполнения вашей текущей
истории, так что инкрементный дизайн позволяет вам начинать поставку гораздо
быстрее. Во-вторых, когда будущая история меняется, вы ничего не пишете для ее
поддержки, так что не тратите усилия напрасно.
Даже если бы требования никогда не менялись, инкрементный дизайн все же
был бы эффективнее, поскольку он ведет к регулярным прорывам в дизайне. Каж-
дый прорыв позволяет вам увидеть новые возможности, которые в конечном итоге
приводят к новым прорывам. Это продолжающаяся серия прорывов существенно
улучшает ваш дизайн.
Разве прорывы не оказываются напрасными усилиями, когда вам приходится воз-
вращаться назад?
В реальности вы не возвращаетесь назад. Иногда прорыв будет приводить вас
к радикально более простому дизайну, который может ощущаться как возврат,
но на самом деле это не так. Если бы вы могли подумать о более простом подходе
раньше, то сделали бы это. Простота трудно дается, и вам понадобится выполнять
свой дизайн итерациями, чтобы ее добиться. Природа прорывов, особенно на уровне
класса и архитектурном уровне, состоит в том, что обычно вы их не видите, пока
не поработаете немного со своим текущим дизайном.
Наша организация (или заказчик) требует проектную документацию. Как нам
выполнить это требование?
Если вы можете убедить вашу организацию подождать, то сможете предоставить ей
исполнительно-техническую документацию (см. пункт «Исполнительно-техническая
документация» главы 8). Ее проще создать и она более точная, чем предварительная
документация. И так как она создается после того, как вы сделали релиз, то вы можете
сделать релиз раньше. Дешевле, лучше и быстрее? Это может быть убедительно.
Если нет, то единственный способ предоставить предварительную документа-
цию — это заняться предварительным дизайном, а также, вероятно, предваритель-
ным анализом требований. Однако вам не нужно включать в дизайн абсолютно
все. Вашим стейкхолдерам, возможно, нужно, только чтобы вы подтвердили опре-
деленную часть документации дизайна с целью координации с другой группой или
в целях управления. Поработайте с ними над определением минимума, для которого
необходим предварительный дизайн, а потом используйте инкрементный дизайн
для всего остального.
Инкрементный дизайн требует самодис-
циплины, готовности к постоянному еже- См. также
дневному совершенствованию и стремления
к высококачественному коду. И, конечно, Парное программирование (глава 12)
навыка применять все это в нужное время. Групповое программирование
Эти качества присущи не всем. (глава 12)
К счастью, вам и не нужно, чтобы они Коллективное владение кодом
были присущи всем. По моему опыту, ко- (глава 12)
манды хорошо справляются, даже если все- Энергичная работа (глава 7)
го один человек обучает остальную ее часть
использованию инкрементного дизайна. Резерв времени (глава 9)
Однако вам понадобятся практики парного
или группового программирования, коллективного владения кодом, активной ра-
боты и резерва времени в качестве механизмов поддержки. Они помогают с само-
дисциплиной и позволяют людям, которые страстно увлечены качеством кода,
влиять на весь код.
Инкрементный дизайн зависит от про-
стого и рефлексивного дизайна. Важна и раз- См. также
работка через тестирование. Четкие шаги
рефакторинга, повторяемые каждые несколь- Простой дизайн (глава 14)
ко минут, позволяют людям постоянно оста- Рефлексивный дизайн (глава 14)
навливаться и вносить улучшение в дизайн. Разработка через тестирование
Парное и групповое программирование также (глава 13)
помогает в этом, гарантируя, что по меньшей Командная комната (глава 7)
мере половина программистов команды,
будучи в роли штурманов, всегда имеет воз- Согласование (глава 7)
можность думать об улучшениях дизайна.
Убедитесь, что ваша команда может свободно общаться, находясь в общей ко-
мандной комнате, физической или виртуальной, если вы используете инкрементный
дизайн. Без постоянного обсуждения межмодульных, межклассовых и архитектурных
рефакторингов ваш дизайн будет фрагментироваться и разваливаться. Договоритесь
о стандартах кодирования при изначальном процессе согласования, чтобы все сле-
довали одним и тем же паттернам.
Все, что затрудняет постоянное совершенствование, затрудняет и инкрементный
дизайн. Один из примеров — опубликованные интерфейсы; так как их трудно изме-
нить после опубликования, поэтапный дизайн обычно непригоден для интерфейсов,
используемых третьими сторонами, если только вы не имеете возможности изменять
сторонний код. (Но вы можете использовать инкрементный дизайн для внедрения
этих интерфейсов.) Точно так же любой язык или платформа, которые осложняют
рефакторинг, не позволят вам использовать поэтапный дизайн.
И наконец, некоторые организации ограничивают возможности команд исполь-
зовать инкрементный дизайн. Это организации, требующие предварительную про-
ектную документацию или имеющие жестко контролируемую схему базы данных.
В этих ситуациях инкрементный дизайн может быть непригоден.
Когда вы правильно применяете поэтапный дизайн:
zz с каждой неделей возможности ПО и дизайн улучшаются в равной мере;
zz вам не нужно пропускать истории в течение недели или больше, чтобы сфокуси-
роваться на рефакторинге или дизайне;
zz каждую неделю качество ПО становится лучше, чем было неделю назад;
zz со временем поддерживать и расширять ПО становится все проще и проще.
Если вам не нравится идея инкрементного дизайна, то вы можете застраховать свои
ставки, скомбинировав его с предварительным. Начните с фазы предварительного
дизайна, затем полностью перейдите на инкрементный. Хотя это отложит начало
вашей первой истории и может потребовать некоторой работы над предварительными
требованиями, у данного подхода есть преимущество. Он обеспечивает страховочную
сетку, не подвергая слишком большому риску.
Это не говорит о том, что инкрементный дизайн не работает, — он работает!
Но если вам с ним некомфортно, то вы можете застраховать свои ставки, начав с пред-
варительного дизайна. Именно так я научился доверять инкрементному дизайну.
Другие альтернативы инкрементному дизайну менее успешны. Широко извест-
ный подход — рассматривать Agile как серию мини-водопадов, выполняя неболь-
шой объем предварительного дизайна в начале каждой итерации. К сожалению,
эти сессии дизайна слишком короткие и маленькие, чтобы самостоятельно создать
целостный дизайн. Качество кода будет постепенно деградировать. Лучше освоить
инкрементный дизайн.
Другая альтернатива — использовать предварительный дизайн, не применяя инкре-
ментный. Это хорошо работает только в том случае, если ваши планы не меняются,
что противоречит обычному стилю работы Agile-команд.
Сначала освойте инкрементный дизайн, прежде чем экспериментировать. Как
только это произойдет, посмотрите, насколько далеко вы можете продвинуться благо-
даря ему. Не просто уменьшайте долю своего предварительного дизайна; уменьшите
также количество предположений в дизайне, которые вы мысленно делаете. Каково
минимальное количество предположений о дизайне, которым вы можете обойтись?
Найдите предельные возможности инкрементного дизайна.

В статье Is Design Dead? [Fowler2004] инкрементный дизайн обсуждается с несколько
скептической точки зрения.
В статье Continuous Design [Shore2004a] обсуждается мой опыт решения трудных
задач инкрементного дизайна, таких как интернационализация и безопасность.
В статье Evolutionary Design Animated [Shore2020a] обсуждается мой реальный
опыт в инкрементном дизайне с помощью визуализации изменений в маленькой
рабочей системе.
ПРОСТОЙ ДИЗАЙН Аудитория

Наш код легко модифицировать и поддерживать. Программисты
Совершенство достигнуто не тогда, когда больше нечего добавить, а когда не-

чего убрать.
Антуан де Сент-Экзюпери,
автор «Маленького принца»
В процессе написания кода программисты

Agile часто останавливаются, чтобы спросить См. также
себя: «Какая простейшая вещь, вероятно, бу-
дет работать?» Кажется, что они одержимы
простотой. Вместо того чтобы ожидать изме- Инкрементный дизайн (глава 14)
нений и подготавливать хуки для расширений
и точки для плагинов, они создают простой дизайн, который предполагает «как
можно меньше и максимально чище». Как ни странно, в результате возникает дизайн,
который готов к любым изменениям, ожидаемым или нет. Он комбинируется с реф-
лексивным дизайном и поэтапным дизайном, что позволяет ему развиваться в любом
Простой не значит примитивный. Не при-
нимайте глупых проектных решений только Когда (не если) мне понадобится
ради уменьшения количества строк кода. Про- изменить это решение, насколько
трудно это будет сделать?
стой дизайн — значит чистый и элегантный,
а не что-то, что можно создать, обойдясь ми-
нимумом мыслей. Когда я принимаю проектное решение, я всегда задаю себе этот
вопрос: «Когда (не если) мне понадобится изменить это решение, насколько трудно
это будет сделать?»
Следующие техники помогут вам поддерживать ваш код чистым, а стоимость
изменений — низкой.
Простота
Простота — искусство минимизации лишней работы — крайне необходима.
Agile — это результат стремления к простоте. Это касается не только дизайна ПО,
но и всех аспектов вашей работы. Как можно упростить большие тяжеловесные
процессы? Что мы можем убрать из того, что люди воспринимают как должное?
Найдите достаточное количество умных людей, отвечающих на эти вопросы, —

и получите Agile: простейший процесс, который, возможно, будет работать.
Будьте бдительны и ищите возможности упростить свою работу. Можно ли заменить
бюрократический процесс заведения заявок на личное общение? Замените его!
Вам нужно выполнять огромный объем работы ради устаревшего управленческо-
го процесса? Удалите его! Модный инструмент добавляет больше пробуксовок,
чем карточек задач на вашей белой доске? Откажитесь от него! Чем меньше вам
нужно делать, тем больше вы сможете сделать.
Вам это не понадобится

(YAGNI: You Aren’t Gonna Need It)
Эта лаконичная поговорка из XP выражает важный аспект простого дизайна: избе-
жать кодирования на основе гипотез. Когда у вас возникает соблазн добавить что-
то к вашему дизайну, спросите себя, действительно ли необходимо сегодня то, что
делает ваше ПО. Если нет, ну… значит, вам это не понадобится. Ваш дизайн может
измениться. Ваши заказчики могут передумать.
Когда вы строите догадки, а потом планы меняются, устаревшие догадки и пред-
положения в дизайне оставляют следы в коде. В итоге вы приходите к необходимости
вырезать и полностью заменить этот гипотетический код. Лучше изначально не га-
дать. Будет проще добавить код с нуля, чем заменять непригодный код.
Точно так же удаляйте код, который больше не используется. Вы уменьшите
ваш дизайн и сделаете его проще и легче для понимания. Если вам понадобится код
в будущем, то вы всегда можете достать его из системы контроля версий. На данный
момент это лишняя нагрузка с точки зрения обслуживания.
Однажды и только однажды

Однажды и только однажды — поразительно эффективное руководство по дизайну.
Мартин Фаулер сказал:
«Одна из вещей, которую я пытаюсь делать, — это искать более простые [прави-
ла], лежащие в основе хорошего или плохого дизайна. Я думаю, одно из самых
ценных правил — избегать дублирования. “Однажды и только однажды” — это
фраза из экстремального программирования. Авторы The Pragmatic Programmer
[Hunt2019] используют принцип “Не повторяйтесь”.
…Раз за разом я обнаруживаю, что, просто удалив дублирование, случайно
нахожу действительно красивое, элегантное решение. Удивительно, как часто
это происходит. Я часто обнаруживаю, что красивый дизайн может получиться
просто благодаря действительно упорному стремлению избавиться от дубли-
рований в коде» [Venners2002].
Однако «однажды и только однажды» касается не только удаления дубликатов

кода. Речь идет о том, чтобы предоставлять собственное место каждой концепции,
важной для вашего кода. Думайте об этом следующим образом.
Выражайте каждую концепцию один раз. Только один раз.1
Или, как Энди Хант и Дэйв Томас озвучивают

свой принцип DRY: «Каждая часть знаний долж- Каждая часть знаний
на иметь единственное, однозначное, достовер- должна иметь единственное,
ное представление внутри системы» [Hunt2019] однозначное, достоверное
(гл. 2). представление внутри
системы.
Эффективный способ сделать так, чтобы ваш
код проявил себя однажды (и только однажды), —
четко излагать основные концепции. Вместо того чтобы излагать их с помощью при-
митивных типов данных (подход, который называется одержимостью примитивами
(Primitive Obsession)), создайте новый тип.
Например, один интернет-магазин представлял деньги в виде чисел с плава
ющей запятой. Вместо этого они могли бы создать класс Currency. В JavaScript это
выглядело бы так:
class Currency {
constructor(amount)
this._amount = amount;
}
toNumber() {
return this._amount;
}
equals(currency) {
return this._amount === currency._amount;
}
}
Поначалу это кажется расточительством. Это всего лишь простая обертка поверх
базового типа данных, но теперь еще и с дополнительными накладными расходами.
И не только это. Кажется, что она повышает сложность, добавляя еще один класс.
Но подобные простые типы данных оказываются чрезвычайно эффективными
в реализации принципа «однажды и только однажды». Теперь любой код, имеющий
отношение к валюте, имеет очевидное место пребывания: внутри класса Currency.
Если кто-то захочет добавить новый код, то сначала заглянет туда, чтобы проверить,
не существует ли он уже. И когда что-то в концепции (например, конвертацию ино-
странной валюты) нужно изменить, есть одно очевидное место, где это следует делать.
Альтернатива не очень привлекательная. Что происходило с тем интернет-мага-
зином? Как оказалось, математика с плавающей запятой была не очень хорошим
выбором. Программисты попали в ситуацию, в которой при возврате позиции, вклю-
чающей конвертацию валюты, они не могли сгенерировать возмещение, совпадающее
1
Спасибо Эндрю Блэку за эту идею.
с изначальным счетом. (Упс.) Им пришлось много месяцев искать все, что имело
отношение к валюте, и изменять его таким образом, чтобы использовать математику
с фиксированной запятой. Реальная история.
Держу пари, они хотели бы, чтобы 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
Я слегка обновил определения. Оригинальное определение обсуждало модули, а не концепции.
компонент напрямую, ваш код будет использовать интерфейс. Это называется шлюз,
но я употребляю более общий термин обертка.
Обертка делает ваш код устойчивым к изменениям в сторонних компонентах
и, помимо этого, может также представлять интерфейс, адаптированный под ваши
потребности, а не имитировать сторонний. При необходимости вы также можете
расширить его с помощью дополнительных функциональностей.
Например, когда я писал обертку для биллингового сервиса Recurly, я не по-
казал метод для конечной точки subscriptions Recurly. Вместо этого я написал
isSubscribed(). Он обращался к конечной точке, разбирал ее XML, делал цикл по
подпискам и конвертировал множество возможных флагов статусов подписок в про-
стой результат булевой логики.
Создавайте вашу обертку инкрементно. Вместо того чтобы поддерживать каждую
функциональность компонента, который вы обертываете, поддерживайте только то, что
вам нужно сегодня, фокусируясь на предоставлении интерфейса, который соответствует
потребностям вашего кода. Это удешевит создание обертки и облегчит изменение, когда
(не если) вам понадобится заменить основной компонент в будущем.
Некоторые компоненты (особенно фреймворки) хотят «владеть миром», и их
трудно спрятать за оберткой. По этой причине я предпочитаю создавать свой код,
используя простые библиотеки с узко определенными интерфейсами вместо одно-
го большого делающего все фреймворка. Однако в некоторых случаях фреймворк
все же будет лучшим вариантом.
Можно обертывать и фреймворк, но при таком варианте обычно больше проблем,
чем пользы. Обычно вы в итоге приходите к необходимости обертывать целый на-
бор разных классов. В некоторых случаях вам придется обертывать базовые классы
фреймворка, что вы можете сделать, написав собственные базовые классы, расши-
ряющие базовые классы фреймворка.
В качестве альтернативы вы можете решить не использовать обертку для сторонне-
го компонента. Это имеет смысл, когда компонент широко распространен и стабилен,
такой как фреймворки основного языка. Вы можете принимать решение в каждом
конкретном случае: например, я буду использовать класс .NET String напрямую,
без обертки, но буду использовать обертку, чтобы изолировать криптографические
библиотеки .NET, — не потому, что думаю, что они будут меняться, а потому, что они
сложные, а обертка позволит мне спрятать и централизовать эту сложность.
Быстрое завершение с ошибкой

Одна из ловушек простого дизайна заключается в том, что в вашем коде будут про-
белы. Если вы следуете принципу YAGNI, то у вас будут сценарии, которые ваш
код просто не сможет обработать. Например, вы можете написать метод рендеринга
валюты, который не знает валюты, отличной от американской, поскольку ваш код
в данный момент отображает все в долларах США. Но позже, когда вы добавите
больше валют, этот пробел может привести к багу.
У вас может появиться соблазн предотвратить эти баги, обрабатывая каждый
случай, который вы только можете себе представить. Это медленно и легко сделать
неправильно. Вместо этого лучше использовать быстрое завершение с ошибкой (fail
fast). Оно позволяет вам писать более простой код: вместо того чтобы обрабатывать
все возможные случаи, вы пишете свой код так, чтобы он обрабатывал только те слу-
чаи, которые нужно. В любом другом случае работа быстро завершится с ошибкой.
Например, ваш метод рендеринга валюты может быстро завершиться с ошибкой,
когда его запросят отобразить валюту, отличную от американской.
Чтобы быстро завершать работу с ошибкой, напишите утверждение времени
выполнения. Это строка кода, которая проверяет условие и выбрасывает исключе-
ние (обычно это зависит от языка), когда условие не выполняется. Оно похоже на
тестовое утверждение, но является частью вашего рабочего кода. Например, версия
метода рендеринга валюты JavaScript может иметь такое утверждение:
if (currency !== Currency.USD) {
throw new Error("Currency rendering not yet implemented for " + currency);
}
Большинство языков имеет встроенное подобие утверждений времени выполне-

ния, но они обычно довольно невыразительные. Мне нравится писать собственный
модуль утверждений с выразительными функциями, которые генерируют хоро-
шие сообщения об ошибках, например, ensure.notNull(), ensure.unreachable(),
ensure.impossibleException() и т. д.
Некоторые беспокоятся, что быстрое завершение с ошибкой может сделать код
более нестабильным; но в реальности все наоборот. Быстро завершая работу с ошиб-
кой, вы делаете ошибки более очевидными, а значит, можете обнаружить их, прежде
чем они пойдут в эксплуатацию. Однако в качестве страховки, чтобы уберечь ваше
ПО от полного краха, вы можете добавить обработчик исключений верхнего уровня,
который заносит ошибки в журнал и выполняет восстановление.
Код, написанный по принципу быстрого завершения с ошибкой, лучше всего
работает в комбинации с коммуникативными тестами (см. подраздел «Написание
коммуникативных тестов» главы 13), так как они будут запускать проверки быстрого
завершения с ошибкой, позволяя вам легко найти пробелы. Изолированные тесты
требуют, чтобы ваши тесты делали предположения о том, как поведет себя зависи-
мость, а в этом случае легко предположить, что зависимость будет работать, в то
время как на самом деле она быстро завершает работу с ошибкой.
Самодокументируемый код
Простота в глазах смотрящего. Не так важно, чтобы вы думали, что дизайн простой.
Если остальная часть вашей команды (или те, кто в будущем будет поддерживать
ваше ПО) сочтет его слишком сложным, значит, это так и есть.
Чтобы этого не случилось, используйте общие для вашего языка и команды
идиомы и паттерны. Можно вносить новые идеи, но сначала обсудите их с другими
членами команды.
Имена — один из ваших наиболее эффективных инструментов написания
самодокументированного кода. Постарайтесь использовать имена, которые ясно
отражают смысл переменных, функций и т. д. Когда функция содержит много из-
меняющихся частей, применяйте рефакторинг «Извлечение функции» (Extract
Function refactoring) [Fowler2018] для наименования каждой части. Когда условное
выражение трудно понять, используйте функции или промежуточные переменные,

чтобы назвать каждый элемент условного выражения.
Обратите внимание, что я ничего не сказал о комментариях. В них нет ничего
плохого, конечно, но комментарии — это костыль. Попробуйте найти способы сделать
ваш код настолько простым и выразительным, чтобы они не понадобились.
Хорошие имена и простой код — это
трудная задача. Три вещи делают их бо-
См. также
лее простыми. Во-первых, парное или
групповое программирование дают вам Парное программирование (глава 12)
больше перспектив и идей. Если вам
трудно придумать хорошее имя или если Групповое программирование (глава 12)
вы думаете, что какой-либо код, напи- Рефакторинг (глава 13)
санный вашим водителем, неясен, то Коллективное владение кодом (глава 12)
обсудите ситуацию и попробуйте найти
лучший способ выразить его.
Во-вторых, вы всегда можете сделать рефакторинг. Сделайте все возможное
сейчас, и потом, когда вы вернетесь к этому позже, сделайте рефакторинг, чтобы
стало еще лучше.
В-третьих, воспользуйтесь преимуществами коллективного владения кодом.
Когда вы видите код, который непонятен, разберитесь, что человек, который его на-
писал, пытался сказать, затем выполните рефакторинг, чтобы сделать это намерение
более очевидным.
Опубликованные интерфейсы
Опубликованные интерфейсы снижают ваши возможности вносить изменения. Как
только интерфейс опубликован для людей, не входящих в вашу команду, изменение
этого интерфейса, как правило, требует больших затрат и усилий. Вам нужно быть
осторожными, чтобы не повредить то, на что полагаются эти люди.
Некоторые команды подходят к дизайну таким образом, что каждый публичный
метод также является опубликованным интерфейсом. Этот подход подразумевает, что
публичный метод, определенный однажды, не должен меняться никогда. Откровенно
говоря, это плохая идея: она мешает вам улучшать ваш дизайн со временем. Лучший
подход — менять неопубликованные интерфейсы при необходимости, обновляя со-
ответствующим образом то, что к ним обращается.
Если ваш код используется кем-то за пределами вашей команды, то вам нужны
опубликованные интерфейсы. Каждый из них представляет собой обязательство
на принятие в дизайне решения, которое вы можете захотеть поменять в будущем,
поэтому минимизируйте количество интерфейсов, которые вы опубликовываете.
Для каждого из них решите, стоит ли польза понесенных затрат. Иногда это будет
стоить того, но это решение, которое нужно принимать осторожно. Откладывайте
решение как можно дольше, чтобы дать дизайну усовершенствоваться и устояться.
В некоторых случаях, как с командами, создающими библиотеку для использо-
вания третьими сторонами, вся цель продукта — предоставление опубликованного
интерфейса. В этом случае проектируйте ваш интерфейс осторожно, заранее, а не
с помощью эволюционного дизайна. Чем меньше интерфейс, тем лучше — гораздо

проще что-то добавить к интерфейсу, чем удалять ошибки.
Как сказал Эрих Гамма в [Venners2005], «когда дело доходит до выставления
большего количества API [в Eclips, Java IDE с открытым исходным кодом], мы де-
лаем это по запросу. Мы выставляем API постепенно… увидев необходимость, мы
говорим: “ОК, мы вложимся в опубликование этого в качестве API, сделаем это обя-
зательством”. Таким образом, я на самом деле думаю об этом, используя максимально
маленькие шаги; мы не хотим брать на себя обязательство по API раньше времени».
Оптимизация производительности
Современные компьютеры сложны. Даже чтение единичной строки файла с диска
требует координации процессора, множества уровней кеша процессора, ядра опера-
ционной системы, виртуальной файловой системы, системной шины, контроллера
жесткого диска, кеша жесткого диска, буферов операционной системы, системных
буферов и вычислительного конвейера. Каждый компонент существует, чтобы решать
проблему, и у каждого есть определенные хитрости, позволяющие повысить произ-
водительность. Данные в кеше? В каком кеше? Как согласована память? Вы читае-
те асинхронно или блокируете?
Другими словами, ваше предположение
о производительности почти всегда будет Ваше предположение
ошибочным. Приемы оптимизации на базе о производительности почти всегда
двадцатистрочных тестов производительно- будет ошибочным.
сти не помогут. Единственный способ опти-
мизировать современные системы — использовать комплексный подход. Вы должны
измерить реальную производительность кода, найти критические места и начать с них.
Не гадайте. Не делайте предположений. Просто профилируйте код.
Конкатенация строк, вызовы функций и упаковка/распаковка (то, что восприни-
мается как нечто затратное) — обычно не проблема. Большую часть времени на вашу
производительность будут влиять сеть, база данных или файловая система. Если
нет, то, скорее всего, это будет квадратичный алгоритм. В редких случаях это будет
конфликт потоков или непоследовательный доступ к памяти внутри замкнутого
цикла. Но единственный способ убедиться — измерить реальную производитель-
ность. Не гадайте. Профилируйте, профилируйте, профилируйте.
А пока не обращайте внимания на то, что вы услышите о приемах оптимизации.
Когда (не если) вам понадобится изменить ваш код (по любой причине), будет про-
ще это сделать, если он простой и понятный.
Вопросы
Что, если мы знаем, что нам понадобится одна из историй? Разве мы не должны
встроить хук для нее в дизайн?
Ваши планы могут измениться в любой момент. Если история не является частью
вашей работы на текущую неделю, то не встраивайте хук. История может исчезнуть
из плана, оставив вас разбираться с ненужной сложностью.
Что еще более важно, эволюционный дизайн на самом деле снижает стоимость
изменений со временем, так что чем дольше вы подождете, чтобы сделать изменение,
тем дешевле оно обойдется.
Что, если игнорирование истории усложнит ее реализацию в будущем?
Если игнорирование потенциальной истории может ее усложнить, то ищите спо-
собы устранить этот риск, обойдясь без кодирования поддержки для этой истории.
Больше информации вы найдете в подразделе «Архитектура на основе риска» ранее
в текущей главе.
Простой дизайн требует непрерывного со-
вершенствования с помощью рефакторинга, См. также
рефлексивного и инкрементного дизайна.
Без них ваш дизайн не сможет развиваться Рефакторинг (глава 13)
вместе с вашими требованиями. Рефлексивный дизайн (глава 14)
Не используйте простой дизайн в каче- Инкрементный дизайн (глава 14)
стве предлога для плохого дизайна. Про-
стота требует тщательного обдумывания.
Не делайте вид, что «простой» означает код, См. также
который проще или быстрее реализовать.
Коллективное владение кодом и парное Коллективное владение кодом
или групповое программирование, хотя и не (глава 12)
строго обязательны для простого дизайна, Парное программирование (глава 12)
помогут вашей команде выделить интеллек-
туальные ресурсы, необходимые для созда- (глава 12)
ния действительно простых дизайнов.
Когда вы создаете простые дизайны:
zz ваша команда не пишет код в ожидании будущих историй;
zz ваша команда завершает работу быстрее, поскольку не создает то, что не нужно
на сегодняшний день;
zz ваш дизайн с легкостью поддерживает произвольные изменения;
zz хотя новые функциональности могут требовать много нового кода, изменения
в существующем коде локализованы и понятны.
Классический подход к дизайну — ожидать бу-
дущие изменения и формировать дизайн так, См. также
чтобы превентивно их поддерживать. Я назы-
ваю это предиктивным дизайном в отличие Рефлексивный дизайн (глава 14)
от рефлексивного, который мы обсудим далее.
Многие команды добились успеха, используя предиктивный дизайн, однако он

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

У Мартина Фаулера есть коллекция отличных онлайн-статей о дизайне IEEE (https://
oreil.ly/hVVqU). Во многих из них обсуждаются основные концепции, помогающие
в создании простого дизайна.
The Pragmatic Programmer: Your Journey to Mastery1 [Hunt2019] содержит большой
объем информации по дизайну, которая поможет вам создавать простые гибкие
дизайны.
Implementation Patterns2 [Beck2007] углубляется в детали и содержит главы, по-
священные таким темам, как состояние, поведение и методы. Если вы сможете не об-
ращать внимания на слегка устаревшие примеры из Java, то обнаружите множество
тем, дающих пищу для размышлений.
РЕФЛЕКСИВНЫЙ ДИЗАЙН Аудитория
С каждым днем наш код становится лучше. Программисты
Традиционные подходы к дизайну подразумевают, что код не должен меняться.

Новые функциональности и возможности поддерживаются с помощью добавления
нового кода. Традиционный дизайн поддерживает это, пытаясь спрогнозировать, что
может понадобиться, и встраивая хуки для будущих расширений в виде наследо-
вания, добавления зависимостей и т. д., чтобы позже можно было добавить код для
этих функциональностей. Принцип открытости/закрытости (Open-Closed Principle,
классическое руководство по дизайну) поясняет это мировоззрение следующим
образом: «Программные объекты (классы, модули, функции и т. д.) должны быть
открыты для расширения, но закрыты для изменения».
Но команды Agile создают простые дизайны, которые не предвидят будущее. В их
дизайнах нет хуков. Вместо этого у команд Agile есть возможность делать рефакто-
ринг своего кода и менять его дизайн. Это делает возможным совершенно другой
1
Хант Э, Томас Д. Программист-прагматик. — СПб.: Питер, 2006.
2
Бек К. Шаблоны реализации корпоративных приложений.
подход к дизайну: такой, в котором объекты

не спроектированы для расширения, но созданы См. также
для изменения.
Я называю этот подход рефлексивным ди-
зайном. Рефакторинг (глава 13)
Как работает рефлексивный дизайн

Рефлексивный дизайн — полная противоположность традиционному, который я на-
зываю предиктивным. В предиктивном дизайне вы предсказываете, что вашему ПО
понадобится делать, основываясь на текущих требованиях и ваших догадках и пред-
положениях о том, как эти требования могут измениться. Потом вы создаете дизайн,
четко предусматривающий все эти потребности.
В противоположность этому, рефлексивный
дизайн не пытается угадывать будущее. Его за- Рефлексивный дизайн заботят
ботят только те изменения, которые вы делаете только те изменения, которые
прямо сейчас. При использовании рефлексивно- вы делаете прямо сейчас.
го дизайна вы анализируете ваш существующий
код в контексте существующей функциональности вашего ПО, затем выясняете,
как можно улучшить код, чтобы он лучше поддерживал то, над чем вы работаете на
данный момент.
1. Посмотрите на код, над которым вы собираетесь работать. Если он вам не знаком,
то выполните реверс-инжиниринг его дизайна. В случае сложного кода может
быть полезно нарисовать диаграммы, такие как диаграмма классов или диаграмма
последовательности.
2. Определите изъяны в дизайне. Что трудно понять? Что не очень хорошо работает?
Если вы работали с этим кодом недавно, то что вызвало проблемы? Что помешает
вам при работе над вашей текущей задачей?
3. Выберите что-то одно, что можно улучшить в первую очередь. Подумайте об
изменении дизайна, которое может прояснить код и упростить и улучшить вашу
текущую задачу.
4. Выполняйте рефакторинг кода инкрементно, чтобы достичь желаемого дизайна.
Обратите внимание на то, насколько хорошо изменения в дизайне работают на
практике.
5. Повторяйте, пока ваша задача не будет завершена и код не очистится настолько,
насколько вы того хотели. Как минимум он должен быть в хотя бы чуть-чуть
лучшем состоянии, чем был в момент, когда вы начинали.
Рефлексивный дизайн на практике

Однажды мне понадобилось изменить ин-
фраструктуру входа в систему моих сайтов. См. также
Мой предыдущий провайдер аутентифика-
ции, Persona, прекратил работу, поэтому мне
было нужно переключиться на нового провайдера аутентификации, Auth0. Это было

крупное изменение, которое требовало нового процесса регистрации.
Вместо того чтобы планировать весь процесс изменений заранее, я использовал
рефлексивный дизайн, чтобы делать изменения шаг за шагом. Я сфокусировался на
первой истории, в которой добавлялся процесс входа в систему с использованием
Auth0. Она должна была быть выключена с помощью флага функций до тех пор,
пока не будет завершен переход на Auth0.
Моим первым шагом был реверс-инжиниринг дизайна кода. Прошло несколько
лет с той поры, когда я работал с этим кодом, так что теперь все было подобно тому,
как если бы я никогда его раньше не видел. К счастью, хотя код был далек от со-
вершенства, я сосредоточился на простом дизайне, поэтому его было легко понять.
Ни один метод не имел больше 20 строк кода в длину, а большинство насчитывали
менее 10 строк. В самом большом файле было 167 строк.
Я начал с существующей конечной точки входа в систему. Я не делал глубокий
анализ; я просто взглянул на импорт каждого файла и отследил зависимости.
Конечная точка Login зависела от классов PersonaClient и SubscriberAccount. Класс
PersonaClient зависел от HttpsRestClient, который являлся оберткой для стороннего
кода. Класс SubscriberAccount зависел от RecurlyClient, который, в свою очередь,
находился в зависимости от HttpsRestClient.
Эти взаимоотношения показаны на рис. 14.3. На самом деле я в тот момент не делал
диаграммы классов; я только открыл файлы в своем редакторе. Взаимоотношения
были достаточно простыми, чтобы я мог держать все это в голове.
Рис. 14.3. Анализ дизайна аутентификации
Далее мне было нужно определить изъяны в дизайне. Их было множество. Это
был один из самых первых кодов, написанных мною для сайта примерно четыре года
назад, и я с тех пор многому научился.
zz Я не отделил логику от инфраструктуры. Наоборот, SubscriberAccount (логика)
напрямую зависела от RecurlyClient (инфраструктура).
zz SubscriberAccount не делал ничего существенного. Вместо него класс User отве-

чал за логику, относящуюся к пользователю. Предназначение SubscriberAccount
было неясным.
zz Ни один из инфраструктурных классов (PersonaClient, RecurlyClient и Https
RestClient) не имел тестов. Когда я только написал их, я не знал, как писать для
них тесты, поэтому просто протестировал их вручную.
zz Конечная точка входа в систему не имела тестов, поскольку инфраструктурные
классы были написаны непригодными для тестирования. Вход в систему был
очень сложным из-за того, что выполнял еще и проверку статуса подписки.
Нехватка тестов была риском.
Я мог бы изменить многое, но отчасти осо-
бенность рефлексивного дизайна заключается Концентрируйте свои усилия
в том, чтобы концентрировать свои усилия на на том, что наиболее важно.
наиболее важных нюансах. Рудиментарный
класс SubscriberAccount и его зависимость от RecurlyClient являлись проблемой, но
ее решение не упростило бы написание новой конечной точки входа в систему.
Основная структура с зависимостью конечной точки входа в систему от Perso
naClient также имела смысл. Я решил, что введу похожий класс Auth0Client для
конечной точки входа в систему Auth0.
Отсутствие тестопригодности явно было
самой большой проблемой. Я хотел, чтобы См. также
моя новая конечная точка входа в систему
имела коммуникативные тесты. Чтобы это Быстрые надежные тесты (глава 13)
произошло, класс Auth0Client должен был
допускать значение null [Shore2018b], а для этого мне было нужно, чтобы данное
значение допускал класс HttpsRestClient. И заодно я хотел добавить к нему узкие
интеграционные тесты.
То, что мне нужно было сделать, не ограничивалось этими изменениями, но они
складывались в очевидный первый шаг. Теперь я был готов изменить код с помощью
инкрементов, чтобы получить то, что мне хотелось.
1. Я добавил узкие интеграционные тесты к HttpsRestClient и убрал пограничные
случаи (это заняло 3 часа).
2. Сделал так, чтобы HttpsRestClient допускал значение null (1 час).
3. Сделал так, чтобы RecurlyClient допускал значение null (1,25 часа).
4. Сделал так, чтобы PersonaClient допускал значение null (0,75 часа).
5. Изменил HttpsRestClient так, чтобы он лучше соответствовал потребностям
Auth0Client (0,75 часа).
6. Ввел Auth0Client (2 часа).
Рефлексивный дизайн не всегда подразумевает большие изменения. Как только
был введен класс Auth0Client, моей следующей задачей стало введение флага функций,
который позволил бы мне вручную тестировать конечную точку входа в систему Auth0
в эксплуатационной среде, но при этом скрыть ее от обычных пользователей.
Реализация флага функций представляла собой гораздо меньшую задачу, но

следовала принципам все того же рефлексивного подхода. Во-первых, я просмот
рел класс SiteContext, который должен был содержать флаг, и класс AuthCookie,
от которого он находился в зависимости. Во-вторых, я обнаружил изъяны: дизайн
был хорошим, но тесты не соответствовали моим нынешним стандартам. В-третьих,
я решил, как все улучшить: исправить тесты. В-четвертых, делать рефакторинг с по-
мощью инкрементов: я реорганизовал тесты SiteContext так, чтобы они были более
понятными, и переместил тесты AuthCookie со старого тестового фреймворка на свой
текущий тестовый фреймворк.
Все вместе это заняло около получаса работы, так что шаги не были на самом деле
такими четкими. Это было скорее что-то вроде «посмотреть на код, увидеть несколь-
ко очевидных проблем, исправить их». Рефлексивный дизайн — это не обязательно
четкая последовательность шагов. Важно то, что во время работы вы постоянно
размышляете над дизайном вашего кода и вносите улучшения.
Реверс-инжиниринг дизайна
Первый шаг в рефлексивном дизайне — проанализировать свой существующий код,
и если вы его уже не понимаете, то сделать реверс-инжиниринг его дизайна.
Лучше всего будет попросить кого-нибудь в команде объяснить вам дизайн.
Обсуждение наброска на доске, реальное или виртуальное, — быстрый и эффектив-
ный способ обучения, и он часто приводит к взаимодействию в области возможных
улучшений.
Может случиться так, что никто из команды не понимает дизайн или вы можете
захотеть сами понять код. Когда это происходит, начните с обдумывания задач, за
которые отвечают исходные файлы. Выберите файл, зона ответственности которого
наиболее тесно связана с вашей текущей задачей. Если ничего больше не находится,
то, скорее всего, вы можете начать с пользовательского интерфейса и отслеживать
зависимости от него. Например, анализируя код аутентификации, я начал с конечной
точки, относящейся к кнопке входа в систему.
Когда вы найдете стартовую точку, откройте файл и просмотрите имена методов
и функций. Используйте их, чтобы подтвердить или пересмотреть верность вашего
предположения о задачах, выполняемых файлом. Если нужны еще подсказки, то про-
смотрите названия тестов в файле тестов. Затем обратите внимание на зависимости
файла (как правило, его импорты). Проанализируйте и эти файлы и повторяйте до
тех пор, пока встречающиеся зависимости не перестанут иметь отношение к вы-
полняемым вами изменениям.
Теперь, когда у вас есть хорошее представление о задействованных файлах и зонах
ответственности каждого из них, вернитесь назад и посмотрите, как они связаны
друг с другом. Если это сложно, то нарисуйте диаграмму. Вы можете использовать
формальную технику моделирования, например UML, но подойдет и простой набро-
сок. Я обычно начинаю с того, что рисую квадраты для каждого модуля или класса
и линии с надписями, чтобы показать, как они взаимосвязаны. Когда код особенно
сложный, я рисую диаграмму последовательностей, в которой есть колонка для
каждого отдельного модуля или класса и стрелочки между колонками, показыва

ющие вызовы функций.
Некоторые инструменты автоматически создают диаграммы UML на основе
вашего исходного кода. Я предпочитаю создавать диаграммы вручную, само-
стоятельно изучая код. Создание их вручную заставляет меня изучать код более
глубоко. Это занимает больше времени, но в итоге приводит к гораздо лучшему
пониманию того, как работает код.
Это не должно занять много времени. Если все же занимает, то помните, что
лучший способ понять дизайн — попросить кого-либо в команде объяснить его вам.
Если ваша команда не работает с большими объемами кода, который не она созда-
вала, то у вас вряд ли возникнут проблемы с поиском того, кто понимает дизайн
существующего кода. В конце концов, это же ваша команда его написала. Быстрого
просмотра должно быть достаточно, чтобы освежить ваше понимание.
Определение улучшений
В основе любого кода лежит своя красота. Это наиболее важно помнить, когда вы
будете искать улучшения дизайна. Легко смотреть на существующий код и думать:
«Он ужасен». И он действительно может быть ужасным, хотя лучше стараться
не считать дизайн таким только потому, что вы не сразу разобрались в коде. Чтобы
понять код, нужно время, неважно, насколько хорошо он спроектирован.
Но даже если код действительно ужасен, он, скорее всего, создавался на основе
какого-то дизайна. Тот со временем мог перестать работать, но где-то внутри него
есть зачатки хорошей идеи.
Ваша работа — найти и оценить эту глубоко спря-
танную красоту. Вам не обязательно поддерживать Ваша работа — найти
изначальный дизайн, если он больше непригоден, и оценить эту глубоко
но вам нужно его понимать. Довольно часто изна- спрятанную красоту.
чальный дизайн все еще имеет смысл. Он нуждается
в настройках, а не в полной переделке.
Возвращаясь к примеру с аутентификацией, конечная точка входа в систему за-
висела от класса PersonaClient, который зависел от класса HttpsRestClient. Весь код
был не тестопригодным, что приводило к несколько уродливому, нетестируемому
коду входа в систему. Но основная идея создания инфраструктурных оберток была
разумной. Вместо того чтобы отказаться от нее, я усилил ее, сделав инфраструктур-
ные обертки допускающими значение null, что позднее позволило мне использовать
принципы разработки через тестирование, чтобы создать новую, более понятную
конечную точку входа в систему в Auth0.
Это не значит, что существующий дизайн будет совершенным. Всегда есть что-то,
что можно улучшить. Но когда вы думаете об улучшениях, не ищите способ удалить
все и начать сначала. Лучше ищите проблемы, уменьшающие глубоко спрятанную
красоту. Восстанавливайте и улучшайте дизайн. Не изобретайте его заново.
Проблемный код
Термин «проблемный код» (code smells) — «сжатые крупицы мудрости» в сфере про-
блем дизайна. Он представляет собой отличный способ замечать возможности для
улучшения вашего кода.
Если вы заметили проблемный код, это не обязательно означает, что есть про-
блемы с дизайном. Это как странный запах на кухне: он может сигнализировать,
что пора вынести мусор, а может означать, что кто-то всего лишь готовит блюдо
с очень пикантным сыром. В любом случае, если вы чувствуете странный запах, то
присмотритесь внимательнее.
Мартин Фаулера и Кент Бек ведут отличную дискуссию о проблемном коде
в главе 3 книги Refactoring [Fowler2018]. Ее стоит прочесть. В следующих разделах
приводятся несколько наиболее важных, по моему мнению, «запахов», в том числе
таких, о которых Фаулер и Бек не упоминали1.
Эффект дробовика и дивергентное изменение

Эти два «запаха» помогают вам определить проблемы со сплоченностью в вашем
коде. Эффект дробовика (shotgun surgery) имеет место, когда вам нужно изменить
несколько модулей или классов, чтобы выполнить одно изменение. Это признак того,
что концепцию, которую вы меняете, нужно централизовать. Дайте ей собственные
имя и модуль.
Дивергентное изменение (divergent change) представляет собой ровно обратный
процесс: оно случается, когда изменения, несвязанные друг с другом, оказывают
влияние на один и тот же модуль или класс. Это признак того, что модуль выполняет
слишком много обязанностей. Распределите эти обязанности между несколькими
модулями.
Одержимость примитивами и группы данных

Одержимость примитивами (primitive obsession) возникает, когда важные концепции
дизайна представляются общими типами. Например, когда валюта представлена
с помощью decimal или дата обновления подписки — с помощью Date. Это приводит
к тому, что код, содержащий эти концепции, распределяется по всей кодовой базе,
повышая дублирование и снижая сплоченность кода.
Группы данных (data clumps) — нечто похожее. Они возникают, когда несколько
переменных всегда появляются вместе, представляя собой какую-то концепцию, но
не имеют класса или типа, который их представляет. Например, код может постоянно
проходить строки street1, street2, state, country и postalCode в разных функциях
и методах. Это группы данных, представляющие адрес.
Решение одно в обоих случаях: инкапсулировать концепцию в специализиро-
ванный тип или класс.
1
Класс кода (Code Class), отброшенные ошибки (Squashed Errors), нянчиться с Nulls (Coddled
Nulls), зависимость от времени (Time Dependency) и полусырые объекты (Half-Baked Objects) —
мои изобретения.
Класс данных и класс кода

Одна из наиболее широко распространенных ошибок объектно-ориентированного
проектирования, которую я вижу, — данные и код в разных классах. Это часто ведет
к дублированию кода, меняющего эти данные. Когда у вас есть класс, который не-
много больше, чем переменные экземпляра в сочетании с геттерами и сеттерами,
то у вас есть класс данных. Похожим образом, когда у вас есть класс, являющийся
просто контейнером для функций, без состояния для каждого экземпляра, у вас
есть класс кода.
Классы кода не обязательно являются проблемой сами по себе, но часто находят-
ся рядом с классами данных, одержимостью примитивами или группами данных.
Объедините код и его данные: улучшите сплоченность, поместив методы в тот же
самый класс, что и данные, с которыми они работают.
Отброшенные ошибки и нянчиться с nulls

Надежная обработка ошибок — один из признаков, отличающих выдающихся про-
граммистов от просто хороших. Слишком часто код, который во всех остальных
отношениях написан хорошо, признает поражение (метафорически), встретившись
с ошибкой. Обычная концепция — перехватывать исключения, заносить в журнал
ошибку и потом возвращать null или какое-нибудь другое бессмысленное значение.
Это особенно распространенный прием в Java, где компилятору требуется обработка
исключений.
Эти отброшенные ошибки (squashed errors) приводят к ошибкам в будущем,
поскольку null в конечном итоге используется в качестве реального значения где-
нибудь еще в коде. Вместо этого лучше обрабатывайте ошибки, только если вы
можете обеспечить осмысленную альтернативу, например повторную попытку или
предоставление полезного значения по умолчанию. В противном случае сообщите
об ошибке вашему вызывающему абоненту.
Нянчиться с nulls (coddled nulls) — связанная проблема. Она возникает, когда
функция получает неожиданное значение null как параметр или как возвращаемое
значение от функции, которую она вызывает. Зная, что null вызовет проблемы, но
не зная, что с этим делать, программист выполняет проверку на null и потом сам
возвращает это значение. Null распространяется каскадом глубоко в программу,
вызывая непредсказуемые сбои при работе ПО позже. Иногда null попадает в базу
данных, приводя к повторяющимся сбоям программы.
Вместо этого используйте стратегию быстрого завершения работы с ошибкой
(см. подраздел «Быстрое завершение с ошибкой» ранее в данной главе). Не до-
пускайте использования null как параметра, если он не имеет явно определенной
семантики. Не возвращайте null в качестве указателя ошибки, лучше выдайте ис-
ключение. Когда вы получаете null там, где не ожидаете, выдайте исключение.
Зависимости от времени и полусырые объекты

Зависимости от времени (time dependencies) возникают, когда методы класса должны
вызываться в определенном порядке. Полусырые объекты (half-baked objects) —
особый случай зависимости от времени: сначала они должны быть созданы, потом
инициализированы вызовом метода, потом использованы.
Зависимости от времени и полусырые объекты часто свидетельствуют о проблеме

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

После того как вы решили, что изменить,
выполните изменение с помощью серий См. также
небольших рефакторингов. Работайте
инкрементами, один маленький шаг за Рефакторинг (глава 13)
раз, проверяя, что тесты проходят по-
сле каждого шага. Не считая времени,
потраченного на размышления, каждый
рефакторинг должен занимать минуту или две максимум. Часто меньше. Иногда
вам может понадобиться добавить недостающие функции или методы; создайте их,
применяя разработку через тестирование.
В процессе работы вы можете обнаружить, что некоторые из ваших идей улучше-
ний были на самом деле не очень хорошими. Позвольте вашим планам быть гибкими.
Выполняя каждое изменение, оценивайте результат также с помощью принципов
рефлексивного дизайна. Подтверждайте ваш код чаще, чтобы при необходимости
вы могли отменить идеи, которые не сработали.
Но не старайтесь сделать код идеальным. На данный момент хватит и того, если
вы будете оставлять его в чуть лучшем состоянии, чем нашли в начале работы.
Этюд о рефлексивном дизайне

Вы когда-нибудь слышали, как музыкант играет гаммы? Это этюд (если он нудный).
Этюд учит мастерству с помощью точного и тщательного повторения. В конце
концов этюд больше не играют, а навык остается.
Следующий этюд поможет вашей команде развить два фундаментальных навыка,
необходимых для рефлексивного дизайна: анализ дизайна существующего кода
и определение возможностей для улучшений. Выполняйте его в течение получаса,
строго по таймеру, ежедневно в течение нескольких недель. Поначалу ожидайте
ощущения, что вам необходимо спешить, чтобы успеть в обозначенные сроки.
Если этюд начинает утрачивать новизну, то обсудите, что вы можете изменить,
чтобы снова сделать его интересным.
Шаг 1. Разделитесь на пары. Каждый раз, когда выполняете этот этюд, выбирайте
себе в пару нового человека. Если у вас нечетное количество человек, то «лишний»
участник может работать один, или сформируйте тройку.
Шаг 2. (Ограничьте этот шаг 15 минутами.) Просмотрите свой код и выберите
конкретный модуль для анализа. Выберите то, что ваша группа еще не обсуждала
до этого. Вы можете выбрать функцию или метод, модуль или класс либо целую
подсистему. Не тратьте слишком много времени на выбор; если вам трудно это
сделать, то выберите наугад.
Сделайте реверс-инжиниринг дизайна кода, прочитав его. Смоделируйте дизайн
с помощью диаграммы последовательности, диаграммы классов, CRC-карт или
любой другой техники на ваш выбор. Специализированные модели тоже по-
дойдут. Определите изъяны в коде и его дизайне и обсудите, как их исправить.
Создайте новую модель, показывающую, как будет выглядеть дизайн после
внесения исправлений.
Шаг 3. (Ограничьте этот шаг 15 минутами.) Выберите три пары, каждая из которых
проведет трехминутное обсуждение своих выводов.
Повторяйте до тех пор, пока все участники не научатся производить высоко
качественные результаты через 30 минут, не чувствуя спешки.
Вопросы
Чем рефлексивный дизайн отличается от рефакторинга?
Рефлексивный дизайн решает, куда вести машину. Рефакторинг нажимает педали
и крутит руль.
Как нам найти время на рефлексивный дизайн?
Это нормальная, необсуждаемая часть вашей работы. Предполагается, что вы бу-
дете оставлять свой код в немного лучшем состоянии, чем было, поэтому, приступая
к работе над задачей, начните с рефлексивного дизайна, чтобы определить, что вы
собираетесь улучшить. Иногда эти улучшения даже уменьшают общее количество
времени, необходимое для выполнения задачи. Но даже если сейчас это не ускоряет
выполнение вашей задачи, то ускорит выполнение будущих задач. Поддерживать
чистоту дизайна — выгодно.
С другой стороны, вам нужно всего лишь оставить код в немного лучшем состоя
нии, чем он был. Не исправляйте все. Лучше используйте резерв времени, чтобы
выделить время для дополнительных возможностей совершенствования, как описано
в пункте «Повышать внутреннее качество» главы 9.
Кто угодно может использовать рефлексивный ди-
зайн для определения возможностей улучшений. Это См. также
еще один инструмент в наборе, и ничто не мешает
использовать его вместе с предиктивным дизайном Рефакторинг (глава 13)
или специализированным подходом к дизайну. Разработка через тестиро-
На самом деле выполнение улучшений требует вание (глава 13)
рефакторинга, а это обычно зависит от хорошего
набора тестов.
Когда вы правильно используете рефлексивный дизайн:
zz ваша команда постоянно улучшает дизайн существующего кода;
zz работая над задачей, программисты часто выполняют рефакторинг, чтобы упро-
стить задачу;
zz рефакторинги выполняются там, где могут принести больше пользы;
zz код стабильно становится проще и более удобным для работы.
Команды, которые не знают, как использовать рефлексивный дизайн, часто вместо
этого выступают за переписывание кода или тратят много времени на рефакторин-
ги. Это работает, но в сравнении оказывается довольно неуклюжим решением. Это
нельзя делать инкрементно, инкрементами, что приводит к конфликтам между про-
граммистами и стейкхолдерами по поводу распределения времени команды.
Рефлексивный дизайн на самом деле заключается в инкрементном улучшении
дизайна. Это та же самая работа инкрементами, которая проходит сквозь все прак-
тики области поставки. Описанный здесь подход вам не обязательно использовать
в точности, поэтому не бойтесь экспериментировать. В процессе экспериментов
фокусируйтесь на методах, которые позволяют вам определять возможности для
улучшений и вносить изменения постепенно, не вынуждая при этом никого ждать,
пока вы закончите.

В эпизоде 9 из [Shore2020b], How to Add a Feature (Cleanly), демонстрируется реф-
лексивный дизайн маленькой кодовой базы.
В своей книге Refactoring [Fowler2018] Мартин Фаулер сопровождает каждый из
рецептов рефакторинга углубленным описанием того, почему и когда рефакторинг
полезен. Эти рецепты — бесценный источник идей дизайна. Внимательно изучите
их, чтобы улучшить свою способность распознавать возможности дизайна.
ГЛАВА 15
DevOps
Когда я только начинал программировать, моя работа была понятной: написать ПО

и передать его для релиза. После передачи некий мистический процесс переносил
ПО в руки заказчиков. Сначала это подразумевало отгрузку компакт-дисков; позже
к этому подключался отдел, работающий дистанционно и называвшийся «Эксплуа
тация» (Operations, или Ops), который, казалось, помешался на птичьих криках (awk!
grep! perl!). В любом случае это было не моей заботой.
Это продолжалось даже после того, как я начал практиковать Agile. Команды Agile
должны быть кросс-функциональными, но отделом эксплуатации управляли другие
люди, которых я никогда не встречал и чьи имена даже редко знал. Я знал, что это
не в духе Agile, но в компаниях, с которыми я работал, отделы разработки и эксплуа
тации были строго изолированы друг от друга. Скажу по секрету, я был этому рад.
К счастью, другие участники сообщества Agile не были такими благодушными.
Они работали над тем, чтобы устранить барьеры между этими отделами, а позже
присоединить к этой общности еще и отдел безопасности. Данное движение стало
известно по названием DevOps. Его также называют DevSecOps.
Как и во многом в экосистеме Agile, термин DevOps был искажен людьми с доб
рыми намерениями, которые делали неверные предположения… и компаниями
с менее добрыми намерениями, пытающимися быстро заработать. Здесь я ис-
пользую его в оригинальном смысле этого слова: тесное сотрудничество отделов
разработки, эксплуатации и безопасности.
Некоторые расширяют понятие DevOps еще и до других предметных областей,

вводя такие термины, как DevSecBizOps, DevSecBizDataOps и даже Dev <все,
что только можно>Ops. Разумеется, в конечном итоге это приводит нас к кросс-
функциональным, автономным командам, имеющим все необходимые для успеха
навыки. Или, как вы знаете… к Agile.
Разрушая барьеры между отделами разработки, эксплуатации и безопасности,

DevOps позволяет вашей команде создавать ПО, которое более безопасно, более
надежно и проще управляется в эксплуатационной среде. В этой главе содержатся
четыре практики, которые помогут вам это сделать.
zz С помощью практики «Сборка для эксплуатации» вы создадите безопасное и легко
управляемое в эксплуатации ПО.
Глава 15. DevOps 537
zz Практика «Флаги функций» позволяет вашей команде делать развертывание

незавершенного ПО.
zz Благодаря практике «Непрерывное развертывание» снижаются риски и стоимость
zz Практика «Эволюционная системная архитектура» поддерживает вашу систему
простой, легкой в обслуживании и гибкой.
Источники 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 к системной архитектуре.
СБОРКА ДЛЯ ЭКСПЛУАТАЦИИ

Наше ПО безопасно, и им легко управлять на стадии Аудитория
эксплуатации.
Программисты,
Фундаментальная идея DevOps проста: включая отдел эксплуатации
в состав команды людей с навыками эксплуатации
и безопасности, мы делаем так, чтобы работоспособность и безопасность можно было
встроить в свое ПО сразу, а не добавлять их впоследствии. В этом и заключается
идея сборки для эксплуатации.
1
Гловер Э., Дюваль Поль М., Матиас С. DevOps. Непрерывная интеграция. Улучшение качества
программного обеспечения и снижение риска.
Это действительно все! Пригласите людей с навыками эксплуатации и безопас-

ности в команду или, по крайней мере, вовлекайте их в процесс принятия решений
командой. Приглашайте их участвовать в сессиях планирования. Создавайте истории
для того, чтобы упростить мониторинг, управление и обеспечение безопасности
вашей программы. Обсуждайте, почему эти истории важны, и приоритизируйте их
соответственно.
Не оставляйте истории, касающиеся
отделов эксплуатации и безопасности, на Не оставляйте истории,
конец процесса разработки. Лучше под- касающиеся отделов эксплуатации
держивать ПО в состоянии готовности и безопасности, на конец процесса
разработки.
к релизу. (См. врезку «Минимизируйте
объем незавершенной работы» в главе 8.)
Добавляя дополнительные возможности в свое ПО, расширяйте соответственно и его
работоспособность. Например, когда добавляете функциональность, требующую
новую базу данных, добавьте истории для конфигурирования (provisioning), безопас-
ности, мониторинга, резервного копирования и восстановления этой базы данных.
Какие потребности отделов эксплуатации и безопасности вы должны принять во
внимание? Ваши товарищи по команде должны вам это сказать. Следующие под-
разделы помогут вам понять, с чего начать.
Моделирование угроз
Сборка для эксплуатации подразумевает сдвиг влево: думать о потребностях отделов
безопасности и эксплуатации с самого начала разработки, а не в конце. Один из
способов понять эти потребности — моделирование угроз. Это техника из сферы
безопасности, но ее анализ также полезен и для области эксплуатации.
Моделирование угроз — это процесс пони-
мания вашей программной системы и того,
как она может быть скомпрометирована. См. также
В своей книге Threat Modeling: Designing
for Security [Shostack2014] Адам Шостак
описывает это как процесс поиска ответов Обнаружение слепых зон (глава 16)
на четыре вопроса. Это хорошая командная
работа.
1. Что вы создаете? Нарисуйте диаграмму вашей системной архитектуры: компо-
ненты вашего развернутого ПО, потоки данных между ними и границы доверия
или полномочий между ними.
2. Что может пойти не так? Примените одновременный мозговой штурм (см. пункт
«Работайте одновременно» главы 7), чтобы обдумать возможные способы, с по-
мощью которых каждый компонент и поток данных могут быть атакованы, затем
проведите точечное голосование, чтобы сузить список основных угроз.
3. Что вам делать с тем, что может пойти не так? Найдите способы проверки
или решения проблем из списка основных угроз с помощью мозгового штурма,
проведите точечное голосование и создайте для этих работ карты историй.
4. Вы проанализировали все, что было возможно? Хорошенько все обдумайте, затем

взгляните на вашу работу еще раз, чтобы убедиться, что вы ничего не упустили.
Повторяйте это упражнение регулярно, встраивая новую информацию и идеи.
Используйте технику обнаружения слепых зон, чтобы найти пробелы в ваших
размышлениях.
Более подробную информацию вы найдете в [Shostack2014]. Эта книга написана
для людей, не имеющих опыта в области безопасности, и в главе 1 есть все, что вам
необходимо, чтобы начать работу, включая карточную игру для поиска угроз с по-
мощью мозгового штурма. (Карточная игра также доступна бесплатно онлайн по
адресу https://oreil.ly/CgeKn.) Более краткое введение, описывающее хорошо сплани-
рованную командную работу, вы найдете в статье Джима Гамбли A Guide to Threat
Modelling for Developers [Gumbley2020].
Конфигурация
Согласно The Twelve-Factor App [Wiggins2017], развернутое ПО — это комбинация
кода и конфигурации. Конфигурация в этом случае означает часть вашего ПО, которая
различается для каждой среды: строки подключения к базе данных, URL и секреты
(secrets) для сторонних продуктов и т. д.
Когда вы выполняете развертывание, вы развертываете один и тот же код в каж-
дую среду, неважно, тестовая это среда или эксплуатационная. Но ваши настройки
изменятся: например, ваша тестовая среда будет настроена для использования
тестовой базы данных, а эксплуатационная — для использования вашей эксплуата-
ционной базы данных.
В определение «конфигурация» входит только то, что меняется от среды к среде.
Команды часто делают настраиваемыми другие вещи, такие как дата авторского права
в нижней части сайта, но эти типы конфигурации должны быть явно отделены от
конфигурации среды. Они являются частью поведения вашего ПО, и с ними нужно
обращаться как с кодом, включая контроль их версий вместе с кодом. Я часто ис-
пользую реальный код для этих целей, такой как константы или геттеры в модуле
Configuration. (Как правило, я программирую этот модуль также и на конфигурацию
абстрактной среды.)
Конфигурация среды, с другой стороны, должна быть отделена от кода. Она часто
хранится в отдельном репозитории. Если вы включите ее в ваш кодовый репозито-
рий, что имеет смысл, когда ваша команда отвечает за развертывания, то четко от-
делите ее: например, исходный код в каталоге source, а конфигурация среды в ката-
логе environments . Потом, при развертывании, введите конфигурацию в среду
развертывания, выставив переменные среды, скопировав файлы и т. д. Конкретика
будет зависеть от вашего механизма развертывания.
Избегайте делать ваше ПО бесконечно кон-
фигурируемым. Сложная конфигурация в итоге
становится формой кода — кода, написанного осо- См. также
бенно скверным языком программирования, без
абстракций или тестов. Если вам нужны сложные
настройки, то лучше используйте флаги функций,
чтобы выборочно включать и выключать какие-либо виды поведения. Если вам нужно
комплексное, контролируемое заказчиком поведение, то рассмотрите возможность
использования архитектуры плагинов. Оба подхода позволят вам кодировать детали,
используя реальный язык программирования.
Секреты
Секреты (secrets) (пароли, ключи API и т. д.) —
особый вид конфигурации. Особенно важно, Члены команды не должны иметь
чтобы они не были частью вашего исходного доступ к секретам.
кода. Фактически большинство членов коман-
ды вообще не должны иметь доступ к секретам. Вместо этого определите безопасную
процедуру генерирования, хранения, обращения и аудита секретов. В комплексных
системах эта процедура часто подразумевает использование инструмента или сервиса
управления секретами.
Если вы храните конфигурацию среды в отдельном репозитории, то можете
контролировать доступ к секретам, строго ограничив доступ к этому репозиторию.
Если вы храните конфигурацию среды в вашем кодовом репозитории, то должны
шифровать свои секреты в «состоянии покоя», что означает шифрование всех
файлов, которые содержат секреты. Запрограммируйте свои скрипты разверты-
вания, чтобы они выполняли дешифрование секретов перед вводом их в среду
Что касается развертывания, уделяйте особое внимание тому, как секреты управ-
ляются вашей автоматизацией сборки и развертывания. Конечно, удобно жестко
закодировать секреты в скрипт развертывания или конфигурацию CI-сервера, но
это удобство не стоит риска. Вашей автоматизации нужны те же самые процедуры
безопасности, что и остальному коду.
Никогда не записывайте секреты в ваши журналы. Это легко сделать случайно,
поэтому подумайте над тем, чтобы написать для вашей обертки записи в журнал про-
цедуру поиска данных, похожих на секреты (например, поля с именами password или
secret), и их редактирования. Когда такие данные будут обнаруживаться, команда
должна получать оповещение о том, что необходимо исправить ошибку.
Параноидальная телеметрия
Независимо от того, насколько аккуратно вы пишете ваш код, он все же будет сбоить
при эксплуатации. Даже самый совершенный код зависит от несовершенного мира.
Внешние сервисы возвращают непредвиденные данные или (что еще хуже) отвеча-
ют очень медленно. Заканчивается свободное пространство в файловых системах.
Системы обработки отказов… отказывают.
Всякий раз, когда ваш код взаимодействует с внешним миром, запрограммируйте
его так, чтобы он предполагал, что мир стремится вам навредить. Проверяйте код
каждой ошибки. Подтверждайте каждый ответ. Вводите тайм-аут для неотвечающих
систем. Программируйте логику повторных попыток использования экспоненци-

альных отсрочек (exponential back-offs).
Когда вы можете безопасно обойти неисправную систему, делайте это. Когда
не можете, инициируйте сбой управляемым и безопасным способом. В любом слу-
чае заносите проблему в журнал событий, чтобы ваша система мониторинга могла
послать оповещение.
Ведение журнала событий

Никто не хочет быть разбуженным посреди ночи из-за рабочей проблемы. Но это
все равно случается. Когда это происходит, дежурному нужно иметь возможность
провести диагностику и исправить проблему, приложив минимум усилий.
Чтобы упростить эту задачу, примите систематический и обдуманный подход
к ведению журнала. Не просто рассылайте инструкции записи в журнал по всему
коду. Лучше подумайте, что может пойти не так и что людям понадобится при этом
знать. Создайте пользовательские истории, чтобы разобраться с этими вопросами.
Например, если вы обнаружите нарушение безопасности, то как определите, какие
пользователи и данные были затронуты? Если ухудшается производительность, то
как вы определите, что нужно исправить? Перспективный анализ (см. подраздел
«Перспективный анализ» главы 8) и ваша модель угроз могут помочь определить
и приоритизировать эти истории.
Используйте структурированные журналы, направляемые в центральное храни-
лище данных, чтобы упростить поиск и фильтрацию журналов. Структурированный
журнал выводит данные в машиночитаемом формате, например JSON. Записывайте
вашу обертку записи в журнал так, чтобы она поддерживала запись произвольных
объектов. Это позволит вам легко добавлять переменные, предоставляющие важный
контекст.
Например, я работал над системой, находившейся в зависимости от сервиса, ко-
торый сообщал о нежелательности обращения к своим устаревшим API с помощью
специальных заголовков ответов. Мы написали код в нашем ПО, проверявший при-
сутствие этих заголовков и запускавший следующий код Node.js:
log.action({
code: "L16",
message: "ExampleService API has been deprecated.",
endpoint,
headers: response.headers,
});
Результат выглядел так:

{
"timestamp": 16206894860033,
"date": "Mon May 10 2021 23:31:26 GMT",
"alert": "action",
"component": "ExampleApp",
"node": "web.2",
"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"
}
}
Дополнительный контекст, содержавшийся в сообщении журнала, упрощал диа-

гностику проблемы. Строка endpoint точно показывала, какой API устарел, а объект
headers давал программистам возможность понять детали и устранить возможность
ложных срабатываний.
Предоставляйте контекст и при выдаче исключений. Например, если у вас есть
инструкция switch, которая никогда не должна запускать случай default, то вы мо-
жете заявить, что он недоступен. Но не выдавайте просто «исполнен недоступный
код» (unreachable code executed). Выдайте подробное исключение, которое позволит
вашей команде найти и устранить проблему. Например, «Обнаружен неизвестный тип
пользовательской подписки legacy-036 при попытке отправить электронное письмо,
предназначенное для адаптации новых пользователей» (Unknown user subscription
type ‘legacy-036’ encountered while attempting to send onboarding email).
В примере записи в журнале вы увидите несколько стандартных полей. Боль-
шинство из них были добавлены инфраструктурой выполнения записи в журнал.
Рассмотрите возможность добавить эти поля и в ваши журналы.
zz Timestamp (отметка времени) — машиночитаемая отметка времени, когда про-
изошла запись в журнал.
zz Date (дата) — удобочитаемая версия Timestamp.
zz Alert (оповещение) — какое оповещение послать? Часто называется уровнем.
Я объясню это чуть позже.
zz Component (компонент) — кодовая база, сгенерировавшая ошибку.
zz Node (узел) — конкретная машина, сгенерировавшая ошибку.
zz Correlation ID (идентификатор коррреляции) — уникальный идентификатор,
который объединяет взаимосвязанные записи в журналах, часто по нескольким
сервисам. Например, все записи, относящиеся к одному запросу HTTP, могут
иметь один и тот же идентификатор корреляции. Он также называется ID запроса.
zz Code (код) — произвольный уникальный код для этого сообщения в журнале.
Он никогда не меняется. Он может быть использован для поиска в журналах
и просмотра документации.
zz Message (сообщение) — удобочитаемая версия code. В отличие от code, это поле
может меняться.
Сопроводите ваши журналы документацией, в которой кратко поясняется каж-
дое оповещение и, что еще более важно, дается информация о том, что с ним делать.
Зачастую эти сведения будут частью вашего ранбука (runbook) — сборника процедур
и процессов для конкретной части ПО. Например:
L16: ExampleService API устарел

Объяснение: ExampleService, наш провайдер биллинга, запланировал удалить
API, который мы используем.
Оповещение: действие. Наше приложение прекратит работу, когда они удалят
API, так что для нас жизненно важно разобраться с этим, но они предоставля-
ют льготный переходный период, поэтому заниматься этим немедленно нет
необходимости.
Действия:
yy Вероятно, необходимо обновить код для использования нового API. Тогда
объект headers, который содержит заголовки, возвращаемые ExampleService,
должен содержать заголовок x-deprecated и заголовок x-sunset-date.
yy Поле endpoint показывает конкретный API, который вызвал уведомление
об ошибке, но другие конечные точки, которые мы используем, также могут
быть затронуты.
yy Срочность обновления зависит от того, когда API будет выведен из работы,
что показывается заголовком x-sunset-date. Вы можете это проверить, по-
смотрев документацию ExampleService на странице example.com.
yy Возможно, вы захотите отключить это уведомление до момента обновления
API. Будьте внимательны, случайно не отключите одновременно уведом-
ления для других API и при возможности включите автоматическое по-
вторное включение уведомления, чтобы не забыть о необходимости обнов-
ления.
Обратите внимание на неформальный,

недирективный тон раздела «Действия». Описывайте, что читатель должен
Это намеренно. Детальные процедуры могут знать, а не что ему (или ей) нужно
привести к двойной ловушке ответственно- делать.
сти и полномочий, в которой люди боятся
менять процедуру, даже если она не подходит для их ситуации [Woods2010] (гл. 8).
Описание того, что читатель должен знать, а не того, что ему (или ей) нужно делать,
возвращает полномочия по принятию решений читателю, позволяя ему адаптировать
совет к своей ситуации.
Показатели и пригодность к наблюдению

Помимо записи в журнал, ваш код должен также измерять элементы, представляющие
интерес, называемые показателями (metrics). Большинство показателей — техни-
ческие, например количество запросов, которое получает ваше приложение, время,
необходимое для ответа на запросы, использование памяти и т. д. Но некоторые будут
касаться бизнеса, такие как количество и стоимость покупок заказчиков.
Показатели, как правило, накапливаются в течение какого-то времени, затем

выдаются в отчете. Это можно сделать внутри вашего приложения, и отчет может
выдаваться в виде сообщения в журнале, или можно сделать с помощью отправки
событий в инструмент агрегации показателей.
Ваши журналы и показатели совместно
создают пригодность к наблюдению: возмож- Выберите осмысленный подход
ность оценить, как ведет себя ваша система к пригодности к наблюдению.
как с технической точки зрения, так и с точки
зрения бизнеса. Как и с журналами, выберите осмысленный подход к наблюдению.
Поговорите со своими стейкхолдерами. Какая пригодность к наблюдению вам нуж-
на с точки зрения эксплуатации? А с точки зрения безопасности? А с точки зрения
бизнеса? С точки зрения поддержки? Создайте пользовательские истории, чтобы
учесть все эти потребности.
Мониторинг и оповещения
Система мониторинга распознает, когда ваши журналы и показатели требуют внима-
ния. Когда это происходит, инструмент мониторинга посылает оповещение (электрон-
ное письмо, уведомление в чате или даже текстовое сообщение либо телефонный
звонок), чтобы кто-то мог об этом позаботиться. В некоторых случаях оповещения
выполняет отдельный сервис.
Решение, о чем нужно отправлять оповещение, а о чем — нет, может быть доволь-
но сложным, поэтому может понадобиться настроить ваш инструмент мониторинга
с помощью подходящего языка программирования. Отнеситесь к этой настройке
с таким же вниманием, как и к реальной программе. Храните ее в контроле версий,
уделяйте внимание дизайну и пишите тесты по возможности.
Виды оповещений, которые отправляет ваш инструмент мониторинга, зависят от
вашей организации, но, как правило, они попадают в четыре категории:
zz «Авария» — что-то очень срочное или вот-вот станет срочным, и человек должен
проснуться и исправить это немедленно;
zz «Событие» — что-то важное, требует внимания, но это недостаточно срочно,
чтобы кого-либо будить;
zz «Наблюдение» — что-то необычное, человек должен еще раз на это взглянуть
(используйте умеренно);
zz «Информация» — не требует чьего-либо внимания, но полезно для наблюдения.
Настройте ваш инструмент мониторинга так, чтобы он отправлял некоторые
оповещения на основе записей в вашем журнале. Проще всего запрограммировать
журнал на использование приведенных выше терминов, но большинство библио-
тек журналов используют вместо этого такие: FATAL, ERROR, WARN, INFO и DEBUG. Хотя
технически они имеют другие значения, вы можете напрямую наложить их на пре-
дыдущие уровни: FATAL — для категории «Авария», ERROR — для «События», WARN —
для «Наблюдения» и INFO — для… «Информации». Лучше совсем не используйте
DEBUG — он только добавляет шум.
Можно использовать записи журнала DEBUG во время разработки, но не реги-
стрируйте их. Некоторые команды программируют свой скрипт непрерывной
интеграции так, чтобы он вызывал автоматический сбой сборки, если обнару-
живает записи DEBUG.
Другие оповещения инициируются на основе показателей. Эти оповещения

обычно генерируются вашим инструментом мониторинга, а не кодом программного
приложения. Позаботьтесь о том, чтобы у каждого из них было кодовое обозначение
для поиска, сообщение, понятное человеку, и документация в вашем ранбуке, совсем
как для сообщений журнала.
При возможности я предпочитаю про-
граммировать решения для оповещений
в коде своего приложения, инициируя опо- См. также
вещения через журнал, а не в настройках
Непрерывное развертывание
мониторинга. Это позволяет членам ко- (глава 15)
манды программировать «мозги» системы
оповещений, используя код, с которым они
знакомы.
Недостаток в том, что при внесении изменений в оповещения требуется повтор-
ное развертывание ПО, так что этот подход работает лучше всего, когда команда
использует непрерывное развертывание.
Опасайтесь возникновения усталости от оповещений. Помните: оповещение
категории «Авария» должно кого-то разбудить. Нужно не так уж много ложных
сигналов тревоги, чтобы люди перестали обращать внимание на оповещения, осо-
бенно на оповещения из категории «Наблюдение». По каждому оповещению не-
обходимо предпринять действие: или отработать оповещение, или предотвратить
повторные ложные срабатывания. Если оповещение стабильно не соответствует
своему уровню (например, «Авария», которой можно заняться завтра, или «Наблю-
дение», которое никогда не подразумевает реальной проблемы), то подумайте о сни-
жении уровня или поищите способы сделать его более разумным.
Похожим образом уведомление, которое стабильно подразумевает исключительно
механическую реакцию, — кандидат на автоматизацию. Преобразуйте механическую
реакцию в код. Это особенно применимо к уведомлениям категории «Наблюдение»,
которые могут превратиться в «свалку» назойливых пустяков. Нормальное реше-
ние — создать оповещение «Наблюдение»,
чтобы помочь вам понять поведение вашей Или отрабатывайте оповещение,
системы, но как только вы его поймете, по- или предотвращайте повторные
высьте оповещение до категории «Событие» ложные срабатывания.
или «Авария», сделав его более избира-
тельным.
Чтобы держать оповещения под контролем, привлеките к вашим дежурным
сменам программистов. Это поможет им понять, какие оповещения важны, а какие
нет, и решения по части оповещений в коде будут улучшаться.
Некоторые организации имеют специально назначенные команды эксплуатации,
которые управляют системами и несут дежурство на телефоне. Это работает лучше
всего, когда команда разработки первой управляет собственными системами. Пре-
жде чем передавать свои обязанности, они должны продемонстрировать опреде-
ленный уровень стабильности. Больше информации вы найдете в [Kim2016] (гл. 15).
Напишите тесты для своих журналов и оповещений. Они так же важны для
успеха вашего ПО, как и пользовательские функции. Эти тесты может быть трудно
написать, поскольку они часто вовлекают глобальное состояние, но это решаемая
проблема дизайна, как обсуждается в разделе «Контроль глобального состояния»
главы 13. Эпизоды 11–15 в [Shore2020b] показывают, как это сделать.
Команда DevOps
Идет ваша первая рабочая неделя, когда вы заглядываете в офис
вашего босса. «Привет, Уолдо, есть минутка? У меня небольшой
вопрос». Он доброжелательно кивает и движением приглашает
вас присесть.
Вы устраиваетесь поудобнее.
— Кто из людей DevOps есть у нас в команде? У меня проблема,
которую мне надо обсудить с кем-то, но я не смог разобраться,
как у нас работает DevOps.
— В команде? — Уолдо поднимает бровь. — Нет, конечно, у нас отдельная команда
DevOps. ProdOps и DataOps тоже. DevOps занимается тестовой средой и инстру-
ментарием CI, ProdOps управляет эксплуатационной средой, и DataOps отвечает
за базы данных и схемы. Разве ты не должен это знать? Твоя предыдущая компа-
ния, наверное, была довольно маленькая, если в ней все это было объединено.
— Нет, мы… — вы трясете головой. — Долгая история. Это был другой тип DevOps.
В любом случае я же могу поговорить с людьми из ProdOps? Возможно, API, ко-
торый я использую, выдает исключение Disk Full, и я хотел бы скоординировать
с ними соответствующую реакцию на это.
Уолдо втягивает воздух через зубы.
— О-о-ох, я бы лучше этого не делал. Они довольны резкие и ужасно занятые.
Все должно проходить через их систему заявок, и они терпеть не могут, когда мы
понапрасну тратим их время. В любом случае, когда еще случится этот Disk Full?
Просто запиши это исключение в журнал и верни null. Здесь мы делаем именно
так. Нам нужно соблюдать сроки.
Вы набираете воздух в легкие, чтобы возразить, но Уолдо поднимает руку:
— Слушай, я знаю, что это отличается от того, к чему ты привык, но у нас большая
компания. Ты не можешь просто ходить и отвлекать людей всякими мелочами.
Надо все делать правильно.
Вопросы
Как нам найти время на все это?
Как сказала Сара Хоран Ван Трис, у вас нет времени, чтобы этого не делать.
«По моему опыту, команды, работающие над ПО, которое не “создано для эксплуа-
тации”, как правило, тратят много времени на то, чего можно было бы избежать или,
по крайней мере, что можно было бы диагностировать и исправить за минуты, будь
они более пригодными для наблюдения». Позаботьтесь об этом сейчас, или будете
тратить больше времени на авралы потом.
Потребности отделов эксплуатации и безопас-
ности можно запланировать как истории, как и все См. также
остальное. Чтобы убедиться, что этим историям
присвоен должный приоритет, привлеките людей Визуальное планирование
с навыками эксплуатации и безопасности к сессиям (глава 8)
планирования. Без багов (глава 16)
Обращайтесь с оповещениями, как с багами: они
должны быть неожиданными, и их следует воспри-
нимать всерьез, когда они случаются. Каждым опо-
вещением нужно заниматься немедленно. Это применимо и к ложным оповещениям
о событиях: когда вам приходит сообщение о чем-то, что не является проблемой,
отрегулируйте это оповещение так, чтобы оно не поднимало ложную тревогу.
Улучшения, влияющие на качество жизни, такие как доводка чувствительности
оповещений или усовершенствование сообщений в журнале, можно выполнять за
счет резерва времени вашей команды.
Что, если у нас в команде нет никого с навыками эксплуатации или безопасности?
Найдите время, чтобы связаться с вашим отделом эксплуатации на ранней стадии
разработки. Сообщите им, что вы хотели бы узнать их мнение по части операционных
требований и требований к аварийным оповещениям, и спросите, как организовать
регулярные встречи, на которых можно получать от них обратную связь. Я замечал,
что люди из отдела эксплуатации бывают приятно удивлены, когда команды раз-
работки приглашают их принять участие до того, как случается аврал. Они обычно
стремятся помочь.
У меня меньше опыта по части привлечения сотрудников отдела безопасности,
отчасти потому, что их меньше, чем людей из отдела эксплуатации, но в целом под-
ход должен быть тот же: свяжитесь с ними на ранней стадии разработки и обсудите,
как вы можете сразу встроить безопасность в ваш продукт, вместо того чтобы при-
страивать ее задним числом.
Делать сборку для эксплуатации может любая ко- См. также
манда. Чтобы получить лучшие результаты, вам
понадобится команда, в которой есть люди с навы- Вся команда (глава 7)
ками эксплуатации и безопасности, или хорошие
отношения с людьми, обладающими этими навыками, а также культура управления,
которая ценит долгосрочное планирование.
Когда вы делаете сборку для эксплуатации:
zz ваша команда рассмотрела и учла потенциальные угрозы безопасности;
zz оповещения адресные и актуальные;
zz когда возникает проблема в отделе эксплуатации, ваша организация готова на
нее реагировать;
zz ваше ПО жизнеспособно и устойчиво.
Эта практика в конечном счете касается подтверждения того, что работающее ПО
подразумевает его запуск в эксплуатационной среде, а не просто написание кода и со-
знательное создание вашего ПО таким образом, чтобы оно соответствовало потреб-
ностям эксплуатации. Лучший способ это сделать, который я знаю, — привлекать
экспертов по эксплуатации и безопасности к работе в вашей команде.
Вы можете экспериментировать с другими подходами. Отделы эксплуатации и без-
опасности в компаниях часто бывают малочисленными, так что может быть сложно
включить людей с этими навыками в каждую команду. В таких случаях в качестве
замены обычно используются чек-листы и автоматические инструменты. По моему
опыту, это лишь бледная копия. Лучше всего дать членам команды возможность
обучиться, чтобы развить соответствующие навыки.
Прежде чем начать экспериментировать, попробуйте поработать хотя бы с одной
командой, применяющей подлинный подход DevOps, в составе которой есть ква-
лифицированные специалисты. Таким образом, вы будете знать, с чем сравнивать
ваши эксперименты.

The Twelve-Factor App1 [Wiggins2017] — хорошее, лаконичное введение в потребности
эксплуатации, содержащее четкое руководство, как их удовлетворить.
The DevOps Handbook2 [Kim2016] представляет углубленное руководство по
DevOps. В части IV, The Technical Practices of Feedback, обсуждается материал, ана-
логичный этой практике.
The Phoenix Project3 [Kim2013] — роман о многострадальном IT-руководителе,
изучающем способы внедрить DevOps в своей организации. Хотя он и не совсем на
тему «сборка для эксплуатации», это увлекательное чтение и хороший способ узнать
больше о мировоззрении DevOps.
1
https://12factor.net/ru/.
2
Ким Дж. и др. Руководство по DevOps. Как добиться гибкости, надежности и безопасности миро-
вого уровня в технологических компаниях.
3
Ким Дж., Спаффорд Дж., Бер К. Проект «Феникс». Как DevOps устраняет хаос и ускоряет раз-
витие компании.
ФЛАГИ ФУНКЦИЙ Аудитория

Мы выполняем развертывание и релиз неза- Программисты
висимо друг от друга.
Для многих команд релиз их ПО — то же самое, что и развертывание. Они раз-
вертывают ветвь своего репозитория в эксплуатационную среду, и все в этой ветви
становится выпущенным. Если есть что-то, что команды не хотят выпускать, то они
хранят это в отдельной ветви.
Для команд, использующих непрерывную ин-
теграцию и развертывание, это не работает. Поми- См. также
мо ветвей разработки с коротким сроком жизни,
у них есть только одна ветвь: их интеграционная Непрерывная интеграция
(глава 13)
ветвь. Им негде прятать незавершенную работу.
Флаги функций, известные также как пере- Непрерывное развертывание
ключатели функций, решают эту проблему. Они (глава 15)
прячут код программным способом, вместо того
чтобы использовать отдельные ветви репозитория. Это позволяет командам выпол-
нять развертывание незавершенного кода, не делая его релиз.
Флаги функций можно запрограммировать несколькими способами. Некоторыми
можно управлять во время выполнения программы, что позволяет выпускать новые
функциональности и возможности, не используя повторное развертывание ПО. Это
передает управление релизами в руки бизнес-стейкхолдеров, а не программистов.
Флаги даже можно настроить так, чтобы они выполняли релиз ПО волнами или
ограничивали релизы так, чтобы те были доступны только определенным типам
пользователей.
Замковый камень
Строго говоря, самый простой тип флага функций — вообще не флаг функций. Кент
Бек называет это замко́вым камнем (keystone) [Beck2004] (гл. 9). Все просто: рабо-
тая над чем-либо новым, подключайте UI последним. Это замковый камень. До тех
пор, пока замковый камень не будет установлен (до тех пор, пока UI не будет под-
ключен), никто не будет знать, что есть новый код, поскольку ни у кого не будет
никаких способов доступа к нему.
Например, когда я переводил сайт на использование другого сервиса аутенти-
фикации, я начал с введения инфраструктурной обертки для нового сервиса. Мне
удалось выполнить большую часть этой работы, не подключая к ней кнопку входа
в систему. До того как я это сделал, пользователи
ничего не знали об изменениях, поскольку кнопка См. также
все еще использовала старую инфраструктуру
аутентификации. Разработка через тестирова-
Это поднимает следующий вопрос: если вы ние (глава 13)
не можете увидеть ваши изменения, то как вы их Быстрые надежные тесты
протестируете? Ответ: используя разработку че- (глава 13)
рез тестирование и узкие тесты. Разработка через
тестирование позволяет вам проверить вашу работу, не видя, как она выполняется.
Узкие тесты сосредоточиваются на конкретных функциях, не требуя, чтобы те были
подключены к остальной части вашего приложения.
В конечном счете вы, конечно, захотите увидеть работу вашего кода, чтобы или
сделать тонкую настройку UI (его тест-драйв может быть трудно сделать) с целью
получить отзывов от заказчиков, или просто проверить еще раз свою работу. В конце
концов, TDD тоже неидеальна.
Проектируйте ваш новый код так, чтобы его можно было «включить» буквально
одной строчкой. Когда вы захотите увидеть его работу, добавьте эту строку. Если
вам нужно сделать интеграцию перед тем, как вы будете готовы к релизу, заком-
ментируйте эту строку. Когда вы готовы к релизу, напишите соответствующий тест
и раскомментируйте строку окончательно.
Замковый камень не обязательно должен включать пользовательский интерфейс.
В качестве камня может быть использовано все, что скрывает вашу работу от за-
казчиков. Например, одна команда использовала непрерывное развертывание для
того, чтобы переписать свой сайт. Она развернула новый сайт на реальном рабочем
сервере, но тот не получал никакого рабочего трафика. Никто за пределами компа-
нии не видел нового сайта, пока команда не переключила трафик со старого сервера
на новый.
Замковые камни — мой любимый способ
маскировки незавершенной работы. Они Замковые камни — мой любимый
простые, понятные и не требуют никакой способ маскировки незавершенной
работы.
специальной работы по техническому об-
служиванию или дизайну.
Флаги функций
Флаги функций похожи на замковые камни, за исключением того, что для управления
видимостью используют код, а не комментарий. Обычно это простой оператор if.
Продолжая пример с аутентификацией, напомню, что я запрограммировал свою
новую инфраструктуру аутентификации, не подключая ее к кнопке входа в систему.
Прежде чем я смог бы ее подключить, мне нужно было протестировать ее в эксплуа
тационной среде, поскольку там были сложные взаимодействия между сторонним
сервисом и моими системами. Но я не хотел, чтобы мои пользователи использовали
новый вход в систему до того, как я его протестирую.
Я решил эту дилемму с помощью флага функциональности. Мои пользователи
видели старый вход в систему; я видел новый. Код работал таким образом: (Node.js):
if (siteContext.useAuth0ForAuthentication()) {
// новый Auth0 HTML
}
else {
// старый Persona HTML
}
Я должен был сделать новую страницу проверки электронной почты как часть
изменений. Это не показывалось внешним пользователям, но люди все же могли
вручную набрать URL, поэтому я использовал флаг функций, чтобы перенаправлять
их наружу:
httpGet(siteContext) {
if (!siteContext.useAuth0ForAuthentication()) return redirectToAccountPage();
⋮
}
Флаги функций — это настоящий код. Им нужен такой же подход к качеству,

как и остальному вашему коду. Например, страница проверки электронной почты
имела следующий тест:
it("redirects to account page if Auth0 feature flag is off", function() {
const siteContext = createContext({ auth0: false });
const response = httpGet(siteContext);
assertRedirects(response, "/v3/account"));
});
Не забывайте удалять флаги функций после того, как они становятся больше
не нужны. Об этом легко забыть, и это одна из причин, почему я предпочитаю ис-
пользовать замковые камни, а не флаги функций. Чтобы помочь себе это запомнить,
вы можете добавить напоминание в календарь команды или историю «удалить флаг»
в план команды. Некоторые команды программируют код своего флага так, чтобы
он записывал сообщение в журнал или вызывал сбой тестов после того, как срок
годности флага истек.
Как ваш код узнает, когда флаг включен? Другими словами, куда вы встроите
свой эквивалент useAuth0ForAuthentication()? У вас есть несколько вариантов.
Конфигурация приложения
Конфигурация приложения — самый простой способ управлять вашими флагами
функций. Ваш код конфигурации может получать состояние флага из константы,
переменной среды, базы данных или откуда вам нравится. Константа — самый про-
стой вариант, поэтому я выбираю его первым, но переменная среды или база данных
позволят вам включать или выключать флаг на отдельных машинах, что даст воз-
можность выполнять поэтапные релизы.
Пользовательская конфигурация
Если вы хотите включать ваш флаг в зависимости от того, кто авторизован в систе-
ме, то сделайте это привилегией, привязанной к вашей абстракции пользователя
или учетной записи. Например, user.privileges.logsInWithAuth0(). Вы можете
использовать это для выполнения поэтапных релизов, основанных на подгруппе
пользователей, и выборочно выпускать функциональности, чтобы тестировать
разные идеи.
Флаги функций легко внедрить, но ими может быть сложно управлять. Как только
вы начнете заниматься инкрементными релизами и сегментацией пользовате-
лей, стоит изучить имеющееся множество инструментов и сервисов, которые
позволяют управлять ими.
Не путайте флаги функций с контролем доступа пользователей. Флаги могут ис-

пользоваться, чтобы скрыть функциональность от пользователя, но они являются
способом временно скрыть новые функциональности, к которым пользователи в про-
тивном случае имели бы доступ. Контроль доступа пользователей, наоборот, нужен
для того, чтобы спрятать функциональности, к которым пользователи никогда не долж-
ны иметь доступ. И то и другое можно вводить с привилегиями пользователей, но
управляться они должны раздельно.
Например, если вы создаете новую функ-
циональность для использования белой эти- Флаги функций — способ временно
кетки для ваших корпоративных заказчи- скрыть новые функциональности.
ков, то можете использовать флаг функций,
чтобы постепенно внедрять ее для этих заказчиков. Однако вам также понадобится
ввести пользовательскую привилегию, ограничивающую доступ для корпоративных
заказчиков. Таким образом, когда код флага функций будет удален, корпоративные
заказчики останутся единственными людьми, имеющими доступ, и не возникнет
риск, что флаг функции будет случайно включен для «неправильных» пользователей.
Секреты
В некоторых случаях вам может понадобиться включать флаг от случая к случаю,
но вы не сможете привязать эту привилегию к пользователю. Например, во время
моей работы по переводу аутентификации мне было необходимо включить новую
кнопку входа в систему, прежде чем я фактически авторизовался в ней.
В таких случаях вы можете включать флаг с помощью секрета. В клиентских при-
ложениях секрет может принимать форму специального файла в файловой системе.
Для серверных приложений подойдет куки или другой заголовок запроса. Именно это
я делал для своего флага аутентификации. Я написал код, который искал куки секрета,
который можно было установить, только авторизовавшись как администратор.
Флаги на основе секрета более рискованны, чем на основе конфигурации. Если
секрет станет известен, то кто угодно сможет включить функциональность. Их так-
же труднее установить и контролировать. Я их использую только в самом крайнем
случае.
Замковые камни может использовать кто угодно. Флаги функций могут выйти из-
под контроля, поэтому ваша команда должна уделять внимание их дизайну и удале-
нию, особенно когда их количество растет. Помогут коллективное владение кодом
и рефлексивный дизайн.
Несмотря на внешнюю схожесть с приви-

легиями, контролирующими доступ пользо- См. также
вателей к функциям, флаги функций пред-
назначены для временного использования. (глава 12)
Не используйте их как замену должному
контролю доступа пользователей.
Когда вы правильно используете замковые камни и флаги функций:
zz ваша команда может развертывать ПО, в котором есть незавершенный код;
zz релиз — это бизнес-решение, а не техническое;
zz код, относящийся к флагу, понятен, хорошо спроектирован и протестирован;
zz флаги и их код удаляются после релиза соответствующей функциональности.
Широко известная альтернатива замко-
вым камням и флагам функций — ветви См. также
функций. Когда кто-то начинает работать
Рефакторинг (глава 13)
над новой функцией, он создает ветвь и не
объединяет ее с остальным кодом до тех пор, Рефлексивный дизайн (глава 14)
пока функция не будет готова. Это эффек-
тивно, когда заказчики не должны иметь доступ к незавершенным изменениям, но
важные рефакторинги имеют тенденцию вызывать конфликты объединения ветвей.
Поэтому ветви функций не подходят для команд поставки, которые стремятся ис-
пользовать рефакторинг и рефлексивный дизайн для снижения затрат.
Замковые камни настолько просты, что не предоставляют места для эксперимен-
тов. Флаги функций, напротив, можно исследовать. Ищите способы поддерживать
порядок в ваших флагах функций и сохранять чистый дизайн. Подумайте, каким
образом ваши флаги могут предоставлять новые возможности для бизнеса. Напри-
мер, флаги функций часто используются при A/B-тестировании, что подразумевает
показ разных версий ПО различным пользователям, а затем принятие решения
в зависимости от результатов.
В процессе экспериментов помните: чем проще, тем лучше. Замковые камни мо-
гут показаться дешевым трюком, но очень эффективны и сохраняют чистоту кода.
Флаги функций легко могут выйти из-под контроля. По возможности выбирайте
простые решения.

Мартин Фаулер более подробно описывает замковые камни в [Fowler2020a].
Пит Ходжсон очень основательно описывает флаги функций в [Hodgson2017].
НЕПРЕРЫВНОЕ РАЗВЕРТЫВАНИЕ
Аудитория
Наш новейший код уже в эксплуатации.
Если вы используете непрерывную интеграцию, Программисты,
значит, ваша команда ликвидировала большинство отдел эксплуатации
рисков релиза. Если все сделано правильно, то не-
прерывная интеграция означает, что ваша команда готова к релизу в любой момент
времени. Вы протестировали свой код и применили скрипты развертывания.
Остается один источник риска. Если вы делаете
развертывание не на реальные эксплуатационные См. также
серверы, то может оказаться, что ваше ПО на самом
деле не будет работать в эксплуатационной среде. Непрерывная интеграция
Разница в среде, трафике и использовании может при- (глава 13)
вести к отказам даже хорошо протестированного ПО.
Непрерывное развертывание помогает справиться с этим риском. Оно следует
тому же принципу, что и непрерывная интеграция: часто развертывая небольшие фраг-
менты, вы снижаете риск возникновения проблем, вызванных крупным изменением,
и облегчаете себе задачу поиска и решения проблемы, когда они все же возникают.
Непрерывное развертывание — ценная практика для команд, обладающих навы-
ками на уровне поставки, но при этом необязательна. Если ваша команда все еще
развивает эти навыки, то сфокусируйтесь сначала на других практиках. Полный
переход на использование непрерывной интеграции, включая автоматизированные
развертывания в тестовую среду (что некоторые называют непрерывной поставкой),
принесет вам почти такую же пользу.
Как использовать непрерывное развертывание

Непрерывное развертывание несложно, но у него
много предварительных условий. См. также
zz Создайте скрипт deploy с нулевым трением и ну-
левым временем простоя, который автоматически Нулевое трение (глава 13)
будет развертывать ваш код. Непрерывная интеграция
(глава 13)
zz Используйте непрерывную интеграцию, чтобы
поддерживать ваш код готовым к релизу. Без багов (глава 16)
zz Улучшайте качество до такой степени, когда ваше Флаги функций (глава 15)
ПО может быть развернуто без ручного тестиро- Сборка для эксплуатации
вания. (глава 15)
zz Используйте флаги функций или замковые камни,
чтобы разделить развертывания и релизы.
zz Установите мониторинг, чтобы информировать команду в случае сбоев развер-
тываний.
Как только эти предварительные условия будут соблюдены, включение непре-

рывного развертывания становится всего лишь вопросом запуска deploy в вашем
скрипте непрерывной интеграции.
Детали скрипта deploy будут зависеть от вашей
организации. В вашей команде должны быть люди
с навыками эксплуатации, которые понимают, что См. также
требуется. Если их нет, то попросите ваш отдел экс- Вся команда (глава 7)
плуатации помочь. Если вы сами по себе, то вам будут
полезны книги Continuous Delivery [Humble2010] и The
DevOps Handbook [Kim2016].
Ваш скрипт развертывания должен быть на 100 % автоматическим. Вы будете
делать развертывание каждый раз при интеграции, что будет происходить множе-
ство раз за день и даже, возможно, несколько раз в час. Ручные действия приводят
к задержкам и ошибкам.
Обнаружение сбоев развертывания

Ваша система мониторинга должна информировать вас при сбоях развертывания.
Как минимум это подразумевает мониторинг увеличения количества ошибок или
снижения производительности, но вы также можете смотреть на бизнес-показатели,
такие как показатели регистрации пользователей. Кроме того, запрограммируйте
свой скрипт deploy на обнаружение ошибок, таких как сбои сети во время развер-
тывания. Когда развертывание завершится, пусть ваш скрипт deploy пометит раз-
вернутый коммит как «успешный» или «неуспешный».
Чтобы снизить последствия сбоя, вы можете делать развертывание на подгруп-
пу серверов, называемых канареечными, и автоматически сравнивать показатели
старого развернутого ПО с новым. Если они существенно отличаются, то нужно
выдать аварийное оповещение и остановить развертывание. Для систем с большим
количеством рабочих серверов вы можете также организовать несколько волн раз-
вертывания канареечных серверов. Например, вы можете начать с развертывания
на 10 % серверов, затем на 50 % и в итоге — на все.
Устранение сбоев развертывания

Одно из преимуществ непрерывного развертывания заключается в том, что оно сни-
жает риск развертывания. Каждое развертывание занимает всего несколько часов
работы, поэтому, как правило, они оказывают слабое воздействие. Если что-то идет
не так, то изменение можно откатить, не влияя на оставшуюся часть системы.
Когда развертывание идет неуспешно, немедленно «остановите линию» (stop
the line) и направьте усилия всей команды на решение проблемы. Как правило, это
означает откат развертывания.
Остановите линию
Когда развертывание не удалось, остановите линию: все перестают работать и со-
средоточиваются на проблеме в эксплуатационной среде. Это предотвращает
наслаивание ошибок.
Вот краткий список шагов, составляющих процесс исправления неудачного раз-
вертывания.
1. Остановите линию.
2. Откатите эксплуатационную среду.
3. Отмените развернутые изменения в репозитории кода. Сделайте интеграцию
и развертывание.
4. Всей командой создайте задачи для исправления ошибочного кода.
5. Перезапустите линию.
6. После развертывания исправления запланируйте сессию анализа инцидента.
Откатить развертывание
Начните с восстановления системы до ее предыдущего рабочего состояния. Как
правило, это подразумевает откат (rollback), который восстанавливает код пре-
дыдущего развертывания и конфигурацию. Чтобы это сделать, вы можете хранить
каждое развертывание в системе контроля версий или сохранять только копию
самого последнего развертывания.
Один из простейших способов сделать откат возможным — использовать
сине-зеленое развертывание (blue/green deployment). Для этого создайте две
копии вашей эксплуатационной среды, произвольно помеченные как «синяя»
и «зеленая», и настройте вашу систему на маршрутизацию трафика на одну из
двух сред. При каждом развертывании происходит переключение между двумя
средами, позволяя вам выполнить откат с помощью маршрутизации трафика на
предыдущую среду.
Например, если активна «синяя» среда, то развертывайте на «зеленую». Когда
развертывание завершено, прекратите маршрутизировать трафик на «синюю» и пере-
направьте его на «зеленую». Если развертывание неуспешно, то откат представляет
собой просто маршрутизацию трафика обратно на «синюю» среду.
Иногда откат тоже бывает неуспешным. Это может говорить о повреждении
данных или проблеме в конфигурации. В любом случае все члены команды прила-
гают усилия до тех пор, пока проблема не будет решена. В главах 12–14 книги Site
Reliability Engineering1 [Beyer2016] содержатся практические рекомендации о том,
как реагировать на такие инциденты.
1
Бейер Б. и др. Site Reliability Engineering. Надежность и безотказность как в Google. — СПб.:
Питер, 2019.
Исправить развертывание
Откат плохой версии на предыдущую обычно решает непосредственную текущую
проблему в эксплуатационной среде, но на этом работа вашей команды не закан-
чивается. Вы должны исправить корневую проблему. Первый шаг — вернуть вашу
интеграционную ветвь назад в заведомо исправное состояние. Вы пока не пытаетесь
исправить проблему, вы лишь пытаетесь вернуть ваш код и эксплуатационную среду
обратно в состояние синхронизации.
Начните с возврата изменений в кодовом репозитории, чтобы содержимое вашей
интеграционной ветви совпадало с тем, что реально находится в эксплуатационной
среде. Если вы используете коммиты объединения (merge commits) в git, то можете
просто сделать git revert на интеграционном коммите. Затем используйте обычный
процесс непрерывной интеграции для интеграции и развертывания восстановлен-
ного кода.
Развертывание восстановленного кода должно пройти без ошибок, поскольку вы
развертываете тот же самый код, который уже работает. Важно все равно это сделать,
так как это позволяет вашему следующему развертыванию начинать с заведомо ис-
правного состояния. Кроме того, если это второе развертывание тоже будет иметь
проблемы, то проблемная область сузится до проблемы развертывания, а не про-
блемы в коде.
Вернувшись в заведомо исправное состоя
ние, вы сможете исправить корневую ошиб- См. также
ку. Создайте задачи для отладки проблемы
(обычно ее исправляют люди, которые ее Анализ инцидентов (глава 16)
развертывали), и все смогут вернуться к нор-
мальной работе. После того как проблема будет решена, запланируйте сессию анализа
инцидента, чтобы решить, как предотвратить подобные сбои развертывания в будущем.
Альтернатива: продвижение вперед

Некоторые команды вместо отката назад продвигаются вперед. Они применяют
какое-либо быстрое решение (возможно запустив git revert) и снова выполняют
развертывание. Преимущество этого подхода в том, что вы исправляете проблемы,
используя ваш обычный скрипт развертывания. Скрипты для отката могут устаре-
вать, выполняясь неуспешно именно тогда, когда особенно необходимы.
Вместе с тем скрипты развертывания обычно медленные, даже если у вас есть воз-
можность отключить тестирование (что не всегда бывает хорошей идеей). Хорошо
выполненный скрипт развертывания может выполниться за несколько секунд. Фикс
форвард может занять несколько минут. Во время аварийной ситуации каждая секунда
на счету. По этой причине я предпочитаю откат, несмотря на его недостатки.
Инкрементные релизы
В случае больших и рискованных изменений запускайте код в эксплуатационной
среде до того, как дадите пользователям доступ к нему. Это похоже на флаги функ-
ций, за исключением того, что вы на самом деле используете новый код. (Флаги
функций, как правило, вообще предотвращают

запуск скрытого кода.) Чтобы обеспечить до- См. также
полнительную безопасность, вы можете делать
релиз функций постепенно, подключая под-
группы пользователей одну за другой.
The DevOps Handbook [Kim2016] называет это тайным запуском (dark launch).
В главе 12 есть пример, в котором Facebook применяет этот подход при релизе
Facebook Chat. Код чата был загружен клиентам и запрограммирован отправ-
лять незаметные тестовые сообщения к сервису бэкенда, позволяя Facebook вы-
полнять нагрузочное тестирование кода, прежде чем распространять его среди
Миграция данных
Изменения в базе данных откатить нельзя (по крайней мере, без риска потери дан-
ных), поэтому миграция данных требует особого внимания. Это похоже на выпол-
нение инкрементного релиза: сначала вы делаете развертывание, затем миграцию.
Выполните три шага.
1. Развертывайте код, который понимает и старую, и новую схему. В это же время
развертывайте код миграции данных.
2. После успешного развертывания запускайте код миграции данных. Его можно
запустить вручную или автоматически как часть вашего скрипта развертывания.
3. Когда миграция завершена, удалите вручную код, понимающий старую схему,
затем снова сделайте развертывание.
Разделение миграции данных и развертывания позволяет каждому разверты-
ванию, если оно будет неуспешным, пережить откат без потерь данных. Миграция
происходит только после того, как будет проверено, что новый код стабилен в экс-
плуатационной среде. Это несколько сложнее, чем миграция данных в процессе
развертывания, но более безопасно и позволяет делать развертывание с нулевым
временем простоя.
Миграции больших объемов данных требуют особого внимания, поскольку ра-
бочая система должна оставаться доступной, пока идет миграция. Для этого типа
миграций напишите ваш код так, чтобы он работал инкрементно (возможно, с огра-
ничителем скорости, из соображений производительности) и использовал обе схемы
одновременно. Например, если вы переносите данные из одной таблицы в другую,
то ваш код может просматривать обе таблицы, читая и обновляя данные, но вставлять
данные только в новую таблицу.
После того как миграция закончена, поста-
райтесь сделать так, чтобы ваш код оставался См. также
чистым, удалив устаревший код. Если для ми-
грации требуется больше, чем несколько минут, Планирование задач (глава 9)
то добавьте напоминание в план задач вашей Визуальное планирование
команды. В случае очень длительных миграций (глава 8)
вы можете добавить напоминание в календарь
вашей команды или внести историю «завершить миграцию данных» в визуальный

план вашей команды.
Этот процесс миграции из трех шагов применим для любых изменений во внеш-
нем состоянии. Помимо базы данных, в нем содержатся параметры конфигурации,
инфраструктурные изменения и изменения в сторонних сервисах. Будьте очень
осторожны, когда задействовано внешнее состояние, поскольку ошибки будет не-
возможно отменить. Более мелкие и частые изменения, как правило, лучше, чем
большие и редкие.
Чтобы использовать непрерывное развер-
тывание, вашей команде нужен строгий См. также
подход к непрерывной интеграции. Вам
нужно выполнять интеграцию несколько Непрерывная интеграция (глава 13)
раз в день и каждый раз создавать заведомо Флаги функций (глава 15)
исправную, готовую к развертыванию сбор- Без багов (глава 16)
ку. «Готовая к развертыванию» в этом случае
означает, что незавершенные функциональ-
ности скрыты от пользователей и ваш код Сборка для эксплуатации (глава 15)
не нуждается в ручном тестировании. В ре-
зультате ваш процесс развертывания должен быть полностью автоматизирован, и вам
нужен способ автоматического обнаружения сбоев развертывания.
Непрерывное развертывание имеет смысл только тогда, когда развертывания
не видны пользователям. На практике имеются в виду, как правило, системы бэкенда
и веб-фронтенды. Настольные и мобильные фронтенды, встроенные системы и т. д.
обычно не подходят для непрерывного развертывания.
Когда ваша команда выполняет непрерывное развертывание:
zz развертывание в эксплуатационную среду не вызывает стресса и не является
экстраординарным событием;
zz когда случаются проблемы с развертыванием, они легко решаются;
zz развертывания редко вызывают ошибки в эксплуатационной среде, а если это
случается, то их обычно быстро исправляют.
Стандартной альтернативой непрерывному развертыванию является развертыва-
ние, ориентированное на релиз: развертывание только тогда, когда у вас есть что-то
готовое к релизу. В действительности непрерывное развертывание является более
безопасным и надежным, когда соблюдены предварительные условия, хотя поначалу
это звучит пугающе.
Вам не нужно переключаться с развертывания, ориентированного на релиз, сразу

на непрерывное. Вы можете действовать медленно, начав с написания полностью
автоматизированного скрипта deploy, затем автоматически развертывать на про-
межуточную среду как часть непрерывной интеграции и в итоге перейти на непре-
рывное развертывание.
Что касается экспериментов, то основные идеи непрерывного развертывания —
минимизация объема незавершенной работы и ускорение петли обратной связи
(см. врезку «Минимизируйте объем незавершенной работы» в главе 8 и врезку
«Быстрая обратная связь» в главе 13). Все, что вы можете сделать, чтобы ускорить
эту петлю обратной связи и сократить время, необходимое для развертывания, будет
движением в верном направлении. Чтобы получить дополнительные бонусы, ищите
способы ускорить петлю обратной связи для релизов.

The DevOps Handbook [Kim2016] содержит детальный обзор всех аспектов DevOps,
включая непрерывное развертывание, изобилующий тематическими исследованиями
и примерами из реальной жизни.
Статья Migrating bajillions of database records at Stripe [Heaton2015] — интересный
и увлекательный пример инкрементной миграции данных.
ЭВОЛЮЦИОННАЯ СИСТЕМНАЯ АРХИТЕКТУРА

Мы создаем нашу инфраструктуру для
того, что нам необходимо на сегодняш- Аудитория
ний день без ущерба для завтрашнего. Программисты, отдел эксплуатации
Простота заложена в основе Agile, как

обсуждается во врезке «Простота» в гла-
ве 14. Это особенно заметно по подходу
к эволюционному дизайну, который вы- См. также
бирают команды с навыками поставки: они
начинают с самого простого дизайна из воз-
можных, добавляют больше возможностей, Инкрементный дизайн (глава 14)
используя инкрементный дизайн, и посто- Рефлексивный дизайн (глава 14)
янно совершенствуют свой код с помощью
рефлексивного дизайна.
А что насчет системной архитектуры? Под ней я подразумеваю компоненты,
которые составляют вашу развернутую систему. Приложения и сервисы, созданные
вашей командой, и способы, с помощью которых они взаимодействуют. Ваши сете-
вые шлюзы и балансировщики нагрузки. Даже сторонние сервисы. Что насчет них?
Можете ли вы начать с простого и развиваться с этой точки дальше?
Это эволюционная системная архитектура, и я видел, что она работает на не-
больших системах. Но системные архитектуры эволюционируют медленно, поэтому
эволюционная системная архитектура не накопила такого глубокого отраслевого
опыта, как эволюционный дизайн. Опирайтесь на собственное мнение в вопросе,

как и когда ее нужно применять.
Я провожу различие между системной архитектурой и архитектурой приложения.
Архитектура приложения представляет собой дизайн вашего кода, содержащий
решения о том, как вызывать другие компоненты в вашей системе. Мы говори-
ли об этом в пункте «Архитектура приложения» ранее в текущей главе. В этой
практике обсуждается системная архитектура: решения о том, какие компоненты
создать и использовать, и высокоуровневые отношения между ними.
Вам действительно это понадобится?

Индустрия программного обеспечения наводнена историями больших компаний,
решающих большие проблемы. У Google есть база данных, которая реплицируется
по всему миру! Netflix выключил свои центры обработки данных и перенес все в об-
лако! Amazon обязал каждую команду публиковать свои сервисы и таким образом
создал миллионный бизнес Amazon Web Services!
Соблазнительно повторить эти истории успеха, но проблемы, которые решали
эти компании, вероятно, отличаются от тех, которые придется решать вам. До тех
пор, пока вы не достигнете размера Google, или Netflix, или Amazon… YAGNI. Вам
это не понадобится.
Посмотрите на Stack Overflow, популярный сайт вопросов и ответов по програм-
мированию. Он обслуживает 1,3 миллиарда страниц в месяц, создавая каждую менее
чем за 19 мс. Как они это делают?1
zz Два балансировщика нагрузки HAProxy, один в работе и один в резерве на случай
аварийного переключения, достигают максимальной скорости в 4500 запросов
в секунду и 18 % загрузки процессора.
zz Девять веб-серверов IIS достигают максимума в 450 запросов в секунду и 12 % за-
грузки процессора.
zz Два кеша Redis, один мастер и одна реплика, достигают максимума в 60 000 опе-
раций в секунду и 2 % загрузки процессора.
zz Два сервера базы данных SQL Server для Stack Overflow, один в работе и один в ре-
зерве, достигают максимума в 11 000 запросов в секунду и 15 % загрузки процессора.
zz Еще два сервера базы данных SQL Server для других сайтов Stack Exchange,
один в работе и один в резерве, достигают максимума в 12 800 запросов в секунду
и 14 % загрузки процессора.
zz Три сервера механизма тегов и ElasticSearch, достигающих в среднем 3644 запро-
сов в минуту и 3 % загрузки процессора для механизма пользовательских тегов,
и 34 миллиона поисковых запросов в день и 7 % загрузки для ElasticSearch.
zz Один сервер базы данных SQL Server для записи в журнал HTTP-запросов.
1
Stack Overflow публикует свою системную архитектуру и статистику производительности (https://
stackexchange.com/performance), и у Ника Крейвера в [Craver2016] есть подробные истории, в которых
обсуждается их архитектура. Доступ к процитированным данным осуществлялся 4 мая 2021 года.
zz Шесть серверов LogStash для всех других журналов.

zz Примерно все то же самое для резервного центра обработки данных (для аварий-
ного восстановления).
По состоянию на 2016 год они развертывали сайт Stack Overflow 5–10 раз в день.
Полное развертывание занимало около восьми минут. Помимо локализации и ми-
грации базы данных, развертывание заключалось в циклическом обходе серверов,
выводе каждого из ротации HAProxy, копировании файлов и возврате их обратно
в ротацию. Их основное приложение — единый мультитенантный монолит, обслу-
живающий все сайты вопросов и ответов.
Это явно немодный подход к системной архитектуре. Нет контейнеров, микро-
сервисов, автомасштабирования, нет даже никакого облака. Только несколько на-
дежных серверов, смонтированных в стойке, набор приложений и развертывание
с копированием файлов. Это просто, надежно, и это работает.
Одна из частых причин, благодаря которой люди оправдывают сложные архи-
тектуры, — это масштабирование. Но Stack Overflow — один из 50 сайтов в мире
с самым высоким трафиком1. Неужели ваша архитектура сложнее, чем их? Если это
так… она должна быть такой?
Нацеленность на простоту
Я не говорю, что вы должны слепо копировать архитектуру Stack Overflow. Никого
не следует слепо копировать! Лучше взгляните на проблемы, которые вам нужно
решать. («Более впечатляющее резюме» не в счет.) Какая самая простая архитектура
может их решить?
Один из вариантов подхода к этому вопросу — начать с идеализированного взгляда
на мир. Вы можете использовать этот мысленный эксперимент как для существу
ющих архитектур, так и для новых.
1. Начните с идеального мира

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

Теперь уберите предположение об идеальных компонентах и сетях. Компоненты ло-
маются; сети выходят из строя. Теперь вам нужно резервирование, которое нуждается
в компонентах, позволяющих управлять репликацией и аварийным переключением.
1
Рейтинг трафика Stack Overflow взят с alexa.com 6 мая 2021 года.
Какой простейший способ даст вам возможность удовлетворить эти потребности?

Можете ли вы понизить сложность, используя сторонний инструмент или сервис?
Например, Stack Overflow должен беспокоиться о резервных источниках питания
и генераторах. Если вы пользуетесь услугами облачного провайдера, то это его про-
блема, а не ваша.
3. Ограничьте ресурсы
Далее уберите предположение о неограниченных ресурсах. Вам могут понадобиться
несколько узлов для управления нагрузкой, а также компоненты для балансировки
нагрузки. Вам может понадобиться разбить операцию, интенсивно нагружающую
процессор, на ее компоненты и ввести очередь. Вам могут понадобиться общий кэш
и способ его заполнения.
Но будьте осторожны: вы рассуждаете
о будущей нагрузке или решаете реальные Вы рассуждаете о будущей нагрузке
задачи, основываясь на реальной эксплуа- или решаете реальные задачи?
тации и трендах? Можете ли вы упростить
архитектуру, используя более мощное аппаратное обеспечение или подождав с ре-
шениями для будущих нагрузок?
4. Примите во внимание людей и команды

И наконец, удалите идеализированное кодирование. Кто будет писать код для каж-
дого компонента? Как эти люди будут координироваться друг с другом? Нужно ли
вам разбить компоненты, чтобы облегчить кросс-командную коммуникацию, или
ограничить сложность какого-либо компонента? Подумайте и о том, как вы можете
упростить эти ограничения.
Контроль сложности
Некоторая архитектурная сложность необходима. Ваша система могла быть проще,
если бы вам не приходилось беспокоиться о балансировке нагрузки или сбое ком-
понентов, однако вам нужно беспокоиться о таких вещах. Как сказал Фред Брукс
в своей знаменитой статье No Silver Bullet: Essence and Accident in Software Engineering1
в [Brooks1995], некоторая сложность обязательна. Ее нельзя исключить.
Но есть еще одна сложность — случайная. Иногда вы разбиваете большой ком-
понент на несколько мелких, только чтобы упростить работу человека, а не потому,
что это важная часть проблемы, которую вы решаете. Случайную сложность можно
удалить или, по меньшей мере, снизить.
Эволюционный дизайн
Одна из наиболее часто встречающихся мне причин разделения компонентов — это
предотвратить большие комки грязи. Маленькие компоненты просты, и их легче
поддерживать.
1
https://ru.wikipedia.org/wiki/Серебряной_пули_нет.
К сожалению, это не уменьшает

сложность; это только переносит ее из Мелкие компоненты, как правило,
повышают общую сложность.
архитектуры приложения в системную
архитектуру. Фактически разделение
большого компонента на несколько мелких, как правило, повышает общую слож-
ность. Отдельные компоненты становится легче понять, но взаимодействия между
компонентами ухудшаются. Отслеживать ошибки труднее. Выполнять рефакторинг
труднее. А распределенные транзак-
ции… ну… их лучше вообще избегать. См. также
Вы можете снизить потребность
в разделении компонента, используя Простой дизайн (глава 14)
эволюционный дизайн. Это позволит Инкрементный дизайн (глава 14)
вам создавать большие компоненты,
Рефлексивный дизайн (глава14)
которые не будут большими комками
грязи.
Самодисциплина
Еще одна причина того, почему команды разделяют свои компоненты, — это обеспе-
чение изоляции. Когда компонент отвечает за множество типов данных, появляется
соблазн перемешать данные, что усложняет дальнейший рефакторинг.
Конечно, нет никакой внутренней причины, по которой данные должны быть
перемешаны. Это просто решение по дизайну, и если вы можете спроектировать
изолированные компоненты, то можете спроектировать и изолированные модули
внутри одного компонента. Вы даже можете сделать так, чтобы каждый модуль ис-
пользовал отдельную базу данных. Не похоже, чтобы сетевые вызовы волшебным
образом создавали хороший дизайн!
Но сетевые вызовы обеспечивают
изоляцию. Если вы не используете сеть, См. также
чтобы обеспечивать изоляцию, то вза-
мен вам понадобится команда с хоро- Коллективное владение кодом (глава 12)
шей самодисциплиной. Коллективное Парное программирование (глава 12)
владение кодом, парное или групповое Групповое программирование (глава 12)
программирование и энергичная рабо-
та — все это помогает, а рефлексивный Энергичная работа (глава 7)
дизайн позволяет вам исправлять лю- Рефлексивный дизайн (глава 14)
бые возникающие ошибки.
Быстрое развертывание
См. также
Большие компоненты часто трудно
развертывать. По моему опыту, трудно Нулевое трение (глава 13)
не само развертывание, а сборка и те-
сты, которые должны пройти перед раз-
вертыванием компонента. Это вдвойне Непрерывная интеграция (глава 13)
верно, если компонент нужно тестиро- Быстрые надежные тесты (глава 13)
вать вручную.
Разберитесь с этой проблемой, создав сборку с нулевой пробуксовкой, внедрив

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

У меня есть друг, который работает в большой широко известной компании. Благо-
даря архитектуре обмена данными «сверху вниз» его команда из трех программистов
поддерживает 21 отдельный сервис — по одному для каждого элемента, которые они
контролируют. Двадцать один! Мы потратили некоторое время на то, чтобы подумать,
как можно упростить код его команды.
zz Изначально от его команды требовали, чтобы они держали каждый сервис в от-
дельном репозитории git. Команда получила разрешение объединить сервисы
в монорепозиторий. Это позволило команде устранить дублирования кода се-
риализации/десериализации и значительно облегчить рефакторинги. До этого
одно изменение могло приводить к 16 отдельным подтверждениям (коммитам)
в 16 репозиториях. Теперь требуется только одно.
zz За несколькими исключениями, требования к CPU от сервисов его команды ми-
нимальны. Благодаря сервисному локатору, работающему по всей организации,
сервисы могут комбинироваться в один компонент, не меняя конечные точки.
Это может позволить им выполнять развертывание на меньшем количестве
виртуальных машин, снижая их затраты на облако; заменить сетевые вызовы
вызовами функций, ускорив время отклика; и упростить их сквозные тесты, что
упростит и ускорит развертывания.
zz Примерно половина сервисов команды используются только внутри его команды.
У каждого сервиса есть определенное количество шаблонов кода (boilerplate)
и оверхедов. Эти оверхеды можно было бы устранить, если бы внутренние сер-
висы были превращены в библиотеки. Это также позволило бы избавиться от
некоторого количества медленных сквозных тестов.
В общем, команда моего друга могла избавиться от множества затрат и пробук-
совок в разработке, упростив свою системную архитектуру, если бы члены команды
могли получить на это разрешение.
Я могу представить себе несколько таких видов рефакторингов системного

уровня. К сожалению, у них пока нет такой богатой истории, как у остальных идей
в этой книге. Рефакторинги «микролит» особенно бездоказательны. Таким образом,
я предоставлю лишь краткие наброски, без особых подробностей. Рассматривайте
их как коллекцию идей для рассмотрения, а не как готовый кулинарный рецепт.
Компоненты мультирепозитория → компоненты монорепозитория

Если компоненты вашей команды расположены в нескольких репозиториях, то вы
можете объединить их в один репозиторий и выделить общий код для общих типов
и утилит.
Компоненты → микролиты
Если ваша команда владеет множеством компонентов, вы можете объединить их
в один, оставив базовую архитектуру в том же состоянии. Изолируйте их в дере-
вьях отдельного каталога и используйте файл интерфейса верхнего уровня, а не
сервер для преобразования между вашей сериализированной полезной нагрузкой
и структурами данных компонента. Замените сетевые вызовы между компонента-
ми вызовом функции, но сохраняйте ту же самую архитектуру во всех остальных
отношениях, включая использование примитивных типов данных, а не объектных
или пользовательских типов.
Я называю эти внутрипроцессные компоненты микролитами1. Вы можете увидеть
пример такого рефакторинга в эпизоде 21 [Shore2020b]. Они обеспечивают изоляцию
компонента, не усложняя операции.
Мои микролит-рефакторинги абсолютно умозрительные. Я их испытывал только
на игрушечных проблемах. Я добавил их в эту книгу, поскольку они выступают
в роли промежуточного шага между компонентами и модулями.
Микролиты → модули
Микролиты строго изолированы. Они, по сути, являются компонентами, работающи-
ми в одном процессе. Это чревато определенными сложностями и дополнительными
издержками.
Если вам не нужна такая строгая изоляция, то вы можете удалить файл интерфейса
верхнего уровня и сериализацию/десериализацию. Просто вызывайте код микролита
как обычно. Результат — это модуль. (Не путать с файлом исходного кода, который
тоже может называться модулем.)
Компонент, составленный из модулей, как правило, называется модульным моно-
литом, но модули нужны не только для монолитов. Вы можете использовать их
в любом компоненте, неважно, насколько он большой или маленький.
1
Я называю их микролитами, поскольку изначально представлял их себе как комбинацию лучших
частей монолитов и микросервисов. Кроме того, «микролит» — понятие из реального мира, от-
носящееся к крошечному каменному инструменту, отколотому от большого камня, что выглядит
почти как метафора.
Модули → новые модули

Если в ваших модулях много кросс-модульных зависимостей, то вы можете упро-
стить их с помощью рефакторинга их зон ответственности. На самом деле это вопрос
архитектуры приложения, а не системной архитектуры (в пункте «Архитектура при-
ложения» текущей главы вы найдете больше информации о развитии архитектуры
приложения), но я добавляю этот вариант, поскольку он может стать промежуточным
шагом в более масштабный системный рефакторинг.
Большой комок грязи → модули

Если у вас есть большой компонент, который
превратился в хаос, то вы можете использовать
См. также
эволюционный дизайн, чтобы постепенно кон-
вертировать его в модули, попутно распутывая Инкрементный дизайн (глава 14)
и изолируя данные. У Прафула Тодкара есть
хороший пример, как это сделать [Todkar2018].
Это тоже вопрос архитектуры приложения, а не
системной архитектуры.
Модули → микролиты
Если вам нужна строгая изоляция или вы думаете, что вам может понадобиться раз-
делить большой компонент на много маленьких, то можете конвертировать модуль
в микролит. Для этого введите файл интерфейса высокого уровня и сериализируйте
параметры комплексной функции.
Обращайтесь с микролитом, как если бы он был отдельным компонентом. Вызовы
к нему должны идти только через файл интерфейса высокого уровня, и их следует
абстрагировать за инфраструктурной оберткой, как описывается в подразделе «Сто-
ронние компоненты» главы 14. Код микролита должен быть изолирован похожим
образом; кроме общих типов и утилит, которые может использовать компонент, он
должен ссылаться только на другие компоненты и микролиты и только через их ин-
терфейсы высокого уровня. Сначала вам может понадобиться сделать рефакторинг
вашего модуля, чтобы он стал более похожим на компонент.
Сетевые вызовы гораздо медленнее и менее надежны, чем вызовы функций
и методов. Конвертация модуля в микролит не гарантирует, что ваш микролит будет
хорошо работать как сетевой компонент. Теоретически вы можете подтвердить, что
ваш микролит будет работать как полноценный сетевой компонент, введя задержку
1–2 мс в ваш высокоуровневый API или даже в случайные сбои. На практике это
звучит несколько смешно, и я еще не пробовал сделать это.
Микролиты → компоненты
Если микролит пригоден для использования в качестве сетевого компонента, то
конвертировать его в компонент довольно просто. Это вопрос конвертации файла
высокоуровневого API в сервер и преобразования вызывающих его элементов для
использования сетевых вызовов. Это сделать проще всего, если вы не забыли изо-
лировать их вызовы за инфраструктурной оберткой.
Конвертация микролита в компонент наверняка потребует, чтобы те, кто будет его
вызывать, ввели обработку ошибок, тайм-ауты, повторные попытки, экспоненциаль-
ную задержку и противодавление вдобавок к операционным и инфраструктурным
изменениям, которых требуют новые компоненты. Это большой объем работы, но
такова цена сетевого взаимодействия.
Модули → компоненты
Вместо того чтобы использовать микролиты, вы можете перейти с модуля на ком-
понент. Это можно сделать с помощью извлечения кода, однако я часто вижу, как
люди вместо этого переписывают модули. Это обычная стратегия при выполнении
рефакторинга большого комка грязи, поскольку код модуля часто не заслуживает
того, чтобы его сохранять. В [Todkar2018] демонстрируется данный подход.
Компоненты монорепозитория → компоненты мультирепозитория

Если у вас множество компонентов в одном и том же репозитории, то вы можете
извлечь их в отдельные репозитории. Одна из причин так сделать — передача владе-
ния компонентом другой команде. Вам может понадобиться продублировать общие
типы и утилиты.
Составные рефакторинги
Скорее всего, вы будете связывать эти рефакторинги системного уровня в единую
цепочку. Например, самый общий подход, который я вижу, — очищать устаревший
код, используя схемы «Большой комок грязи → модули» и «Модули → компоненты».
Или более компактно: большой комок грязи → модули → компоненты.
Объединение компонентов — похожая операция в обратном направлении: компо-
ненты мультирепозитория → компоненты монорепозитория → микролиты → модули.
Если у вас есть набор компонентов с запутанными обязанностями, то, возможно,
вы сможете сделать рефакторинг для создания новых обязанностей вместо того,
чтобы переписывать: компоненты → микролиты → модули → новые модули →
микролиты → компоненты.
Вероятно, вы сможете использовать идеи,
изложенные в этой практике, только с ком- См. также
понентами, которыми владеет ваша команда.
Архитектурные стандарты и компоненты, Устранение препятствий (глава 11)
которыми владеют другие команды, скорее
всего, не будут находиться под вашим непосредственным контролем, но вы сможете
попытаться повлиять на людей, чтобы внести нужные вам изменения.
Изменения в системной архитектуре зависят от отношений между отделами раз-
работчиков и эксплуатации. Вам придется сотрудничать, чтобы определить простую
архитектуру для текущих потребностей системы, включая пиковые нагрузки и про-
гнозируемый рост, и вам придется продолжать координировать ваши совместные
действия при изменении потребностей.
Когда вы хорошо развиваете вашу системную архитектуру:
zz маленькие системы имеют маленькие архитектуры; большие — имеют управля-
емые архитектуры;
zz системную архитектуру легко объяснить и понять;
zz случайная сложность сохраняется на минимуме.
Многое из того, о чем люди думают как об
эволюционной системной архитектуре, — на См. также
самом деле просто обычный эволюцион-
ный дизайн. Например, переход компо- Простой дизайн (глава 14)
нента с использования одной базы данных Инкрементный дизайн (глава 14)
на использование другой — это проблема
эволюционного дизайна, поскольку речь Рефлексивный дизайн (глава 14)
в основном идет о дизайне одного ком-
понента. То же самое можно сказать, когда компонент переходит с использования
одного стороннего сервиса на использование другого. Такие виды изменений можно
внести с помощью практик эволюционного дизайна: простого дизайна, инкремент-
ного и рефлексивного.
Развитие системной архитектуры означает необходимость намеренно начать
с самой простой из возможных систем и расти по мере изменения ваших потребно-
стей. Это идея, которую еще предстоит изучить. Выберите те части этой практики,
которые работают для вашей ситуации, затем посмотрите, какого прогресса сможете
достичь. Основная цель — снизить пробуксовки между отделами разработки и экс-
плуатации и упростить поиск неисправностей, не принося в жертву надежность
и ремонтопригодность.

В книге Building Evolutionary Architectures1 [Ford2017] более подробно описываются
архитектурные варианты. В ней представлен скорее архитектурный взгляд, а не
взгляд командного уровня, который описал я.
В книге Building Microservices2 [Newman2021] представлен трезвый взгляд на про-
блемы дизайна и компромиссы, связанные с архитектурой микросервисов, многие
из которых применимы и к системной архитектуре в целом.
1
Форд Н., Куа П., Парсонс Р. Эволюционная архитектура. Поддержка непрерывных изменений. —
СПб.: Питер, 2018.
2
Ньюман С. Создание микросервисов. — 2-е изд. — СПб.: Питер, 2022.
ГЛАВА 16
Качество
Для многих людей «качество» означает «тестирование», но команды Agile видят

качество по-другому. Качество — это не то, что вы тестируете; это то, что вы встраи
ваете. Не только в сам код, но и во всю вашу систему разработки: в подход вашей
команды к работе, в то, как люди думают об ошибках, и даже в то, как ваша органи-
зация взаимодействует с вашей командой.
Эта глава содержит три практики, которые помогут вашей команде посвятить
себя качеству.
zz Практика «Без багов» поможет встроить качество в вашу работу.
zz С помощью практики «Обнаружение слепых зон» члены команды смогут узнать
то, чего они пока не знают.
zz Благодаря практике «Анализ инцидентов» ваша команда сможет сосредоточиться
на систематическом совершенствовании.
Источники качества
Идеи, представленные в разделе «Без багов», пришли из экстремального про-
граммирования.
Раздел «Обнаружение слепых зон» — сборник нескольких техник: «Подтвержден-
ное знание» (Validated Learning), пришедшее из бережливого стартапа, подхода
Эрика Риса; «Исследовательское тестирование» (Exploratory Testing), подход, воз-
главляемый Джемом Канером, хотя мое описание основано на работе Элизабет
Хендриксон [Hendrickson2013]; «Хаос-инжиниринг» (Chaos Engineering), который
возник благодаря Грегу Орзеллу и его коллегам из Netflix1; и «Тестирование
на проникновение и оценка уязвимостей» (Penetration Testing and Vulnerability
Assessment) — хорошо зарекомендовавшие себя техники обеспечения безопас-
ности.
1
Мне не удалось найти четко определенный источник техники «Хаос-инжиниринг». Его формали-
зовала «команда Хаоса» Кейси Розенталь в Netflix в 2015 году, но основные идеи опередили эту
команду на несколько лет. Изначальным инструментом был Chaos Monkey, который [Dumiak2021]
приписывает «Орзеллу и его коллегам из Netflix». В американском патенте US20120072571A1,
заявка на регистрацию которого была подана в 2010 году, в качестве изобретателей перечислены
Грег Орзелл и Юрий Израилевский.
Глава 16. Качество 571
Мой подход к практике «Анализ инцидентов» объединяет в себе материалы

исследований человеческого фактора и системной безопасности (а именно
Behind Human Error [Woods2010] и The Field Guide to Understanding ‘Human Error’
[Dekker2014]) с моим пониманием эффективности ретроспектив и фасилитации,
что является в значительной степени данью тому, чему я научился, работая с Диа-
ной Ларсен. О связи человеческого фактора с анализом инцидентов я узнал от
Уорда Каннингема, но считаю, что эта информация исходит из сообщества хаос-
инжиниринга, прежде всего от Норы Джонс.
БЕЗ БАГОВ
Мы смело выполняем релизы.
Аудитория
Если вы в команде, ведущей счет багов на сотни
или даже тысячи, то идея «без багов» звучит для вас Вся команда
смешно. Признаю: без багов — это идеал, к которому
надо стремиться, а не то, чего ваша команда непременно достигнет в полной мере.
Какие-то баги будут всегда. (Или дефекты; я использую «баг» и «дефект» как взаи
мозаменяемые термины.)
Но вы можете приблизиться к идеалу «без багов» гораздо больше, чем вам кажет-
ся. Рассмотрим опыт Нэнси ван Шондерворт с экстремальным программированием.
Она вела команду новичков, работавших над встроенной системой для сельскохо-
зяйственных комбайнов, действующей в режиме реального времени: параллельной
системой, написанной на С, с некоторой сборкой. Если это не рецепт разведения
багов, то не знаю, что еще может им быть. Согласно ее анализу данных по Каперсу
Джонсу, средняя команда разработчиков этого ПО произвела бы 1035 дефектов
и 207 поставила бы заказчику.
Вот что произошло на самом деле.
Команда GMS поставила этот продукт после трех лет разработки, столкнувшись
за это время всего с 51 дефектом. Открытый список багов никогда не содержал
больше двух единиц одновременно. Измерения продуктивности демонстри-
ровали результат, почти втрое превышавший уровни команд, работающих над
сопоставимым встраиваемым ПО. Первые модули для полевых тестов были
поставлены примерно через шесть месяцев разработки. После этого команда
разработки поддерживала другие дисциплины инжиниринга, продолжая улуч-
шения ПО [VanSchooenderwoert2006].
Embedded Agile Project by the Numbers with Newbies
За три года команда произвела 51 дефект и 21 поставила своему заказчику. Это

означает, что производственные дефекты были снижены на 95 %, а поставленные —
на 90 %.
Мы не должны полагаться на данные самооценки. QSM Associates — авторитет-
ная компания, выполняющая независимый аудит команд разработки ПО. В отчете
о предварительном анализе компании, практиковавшей вариант XP, они сообщали

о сокращении в среднем с 2270 дефектов до 381 дефекта, снижение на 83 %. Кроме
того, команды XP выполняли поставки на 24 % быстрее при количестве сотрудников,
меньшем на 39 % [Mah2006].
Более поздние исследования подтвердили эти результаты. QSM обнаружила сни-
жение дефектов на 11 % и сокращение временного графика команды Scrum на 58 %;
снижение дефектов на 75 % и сокращение сроков работ команды XP на 53 %; и сни-
жение дефектов на 75 % и сокращение сроков работ на 30 % при многокомандном
анализе тысяч разработчиков [Mah2018].
Как вам достичь таких результатов? Это
задача встраивания качества, а не тестиро- Ликвидируйте ошибки в их
вания на дефекты. Ликвидируйте ошибки источнике, вместо того чтобы
в их источнике, вместо того чтобы находить находить и устранять их постфактум.
и устранять их постфактум.
Встроенное качество
«Дешево, быстро или хорошо, — гласит поговорка. — Выберите два».
Десятилетиями люди думали о качестве как о чем-то стоящем дополнительных де-
нег. Чем больше времени и денег вы тратите, тем выше качество можете получить.
И в какой-то степени это правда. Если ваш подход к качеству — протестировать
работу после завершения, то чем больше времени вы тратите на тестирование
и исправление, тем больше багов устраняете.
Но это не единственный путь к качеству. Встраивая качество с самого начала, вы
получаете более высокое качество за меньшие деньги и время. Конечно, встраи
вание качества отнимает время, но оно также ликвидирует затраты времени на
поиск и устранение багов постфактум. Вы получаете чистую выгоду.
«Дешево, быстро или хорошо». Вы можете заполучить все три.
Не ищите виноватого в багах

Это баг или фича?
Я видел, как компании тратят непомерное количество времени на этот вопрос.
Пытаясь «корректно» распределить вину, они проводят сложные разграничения
между багами, дефектами, ошибками, проблемами, аномальностями и, конечно…
непредвиденными функциональностями (фичами).
Все это неважно. Что действительно
важно, так это то, будете ли вы делать Что действительно важно, так это то,
или не делать что-либо. Если есть что-то, будете ли вы делать или не делать
что вашей команде нужно делать (по лю- что-либо.
бой причине), это должно стать историей
в вашем плане.
Для целей этой главы я определяю баги следующим образом.

Баг — это все, что ваша команда считает «сделанным», но позже требующее
исправления.
Однако для ваших целей даже это отличие не имеет значения. Если что-то требует
работы, то получает карточку истории. Вот и все, что нужно.
Как встроить качество

Прежде чем рассказывать, как встраивать
качество, я должен прояснить, что имею Чем лучше внутреннее качество,
в виду под «качеством». Грубо говоря, ка- тем быстрее вы продвигаетесь.
чество можно разделить на внутреннее
и внешнее. Внутреннее качество — это способ, с помощью которого создано ваше
программное обеспечение. Это такие вещи, как хорошие имена, понятный дизайн ПО
и простая архитектура. Внутреннее качество контролирует, насколько легко ваше
ПО расширять, поддерживать и изменять. Чем лучше внутреннее качество, тем
быстрее вы продвигаетесь.
Внешнее качество — это видимые пользователю аспекты вашего ПО. Это UX
вашего ПО, функциональность и надежность. Вы можете тратить бесконечное
количество времени на все это. Правильное количество времени зависит от вашего
ПО, рынка и ценности. Определение баланса — это задача управления продуктом.
«Встраивать качество» означает поддерживать внутреннее качество максимально
высоким, сохраняя при этом внешнее качество на уровне, удовлетворяющем ваших
стейкхолдеров. Сюда входят сохранение дизайна чистым, поставка истории в вашем
плане и пересмотр плана, когда внешнее качество отстает от необходимого уровня.
А теперь поговорим о том, как это делать. Чтобы встроить качество и достичь
нулевого уровня багов, вам понадобится предотвратить четыре типа ошибок.
Предотвращение ошибок программиста

Ошибки программиста возникают, когда программист знает, что нужно программи-
ровать, но делает ошибку. Это может быть неверный алгоритм, опечатка или любая
другая ошибка, совершаемая при превращении идей в код.
Разработка через тестирование —
самый удобный способ предотвраще-
ния дефектов. Она не только гаран- См. также
тирует, что вы запрограммировали
именно то, что намеревались, но и дает
вам полный регрессионный комплект, Энергичная работа (глава 7)
который вы сможете использовать Парное программирование (глава 12)
для выявления будущих ошибок.
Групповое программирование (глава 12)
Чтобы усилить преимущества раз-
работки через тестирование, рабо- Согласование (глава 7)
тайте разумное количество времени Сделано Сделано (глава 9)
и используйте парное или групповое
программирование, что позволит взглянуть на каждую строку кода с разных точек

зрения. Таким образом вы улучшите ваши умственные способности, которые по-
могают вам делать меньше ошибок и позволяют быстрее их заметить.
Дополните эти практики хорошими стандартами (которые обсуждаются на сес-
сии согласования) и чек-листом «Сделано Сделано». Это поможет вам запоминать
распространенные ошибки и избегать их.
Предотвращение ошибок дизайна

Ошибки дизайна создают благодатную почву для багов. Согласно исследованию
Барри Боэма, 20 % модулей в программе обычно несут ответственность за 80 % де-
фектов [Boehm1987]. Это старая статистика, но она совпадает с моим опытом в со-
временном ПО.
Даже при использовании разработки через тестирование ошибки дизайна со
временем накапливаются. Иногда дизайн, который выглядит хорошо, когда вы его
только что создали, не выдерживает испытания временем. Выбранное вами рацио-
нальное решение, которое поначалу выглядит приемлемым компромиссом, может
в будущем обернуться проблемой. Иногда меняются требования, и ваш дизайн
больше не подходит.
Какой бы ни была причина, ошибки
дизайна проявляются в виде сложного, См. также
запутанного кода, который трудно по-
Коллективное владение кодом (глава 12)
нять. Вы можете взять неделю или две
выходных, чтобы исправить эти пробле- Простой дизайн (глава 14)
мы, но лучше будет все же постоянно Инкрементный дизайн (глава 14)
улучшать ваше внутреннее качество. Рефлексивный дизайн (глава 14)
Используйте коллективное владение
кодом, чтобы дать программистам право Резерв времени (глава 9)
и ответственность исправлять пробле-
мы, где бы они ни скрывались. Непрерывно улучшайте ваш дизайн с помощью
практик эволюционного дизайна. Выделяйте время на совершенствование, добавляя
ваш резерв времени в планы.
Предотвращение ошибок требований

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

ваши обсуждения примерами заказчика. См. также
Подтверждайте, что ПО делает то, что
должно, чаще запрашивая отзывы заказ-
чиков и проводя демо для стейкхолдеров. Цель (глава 7)
Делайте это поэтапно, инкрементами, как Контекст (глава 7)
только программистам будет что пока- Командная комната (глава 7)
зать, — это позволит как можно раньше
Единый язык (глава 12)
выявить недопонимание и уточнения и во-
время все откорректировать. Используйте Примеры заказчика (глава 9)
истории, чтобы помочь команде сконцен- Инкрементные требования (глава 8)
трироваться на точке зрения заказчика. Демо для стейкхолдеров (глава 10)
И наконец, не считайте, что история по-
лучила статус «Сделано Сделано», пока Истории (глава 8)
заказчики в команде не согласятся, что Сделано Сделано (глава 9)
она сделана.
Предотвращение системных ошибок

Если каждый отлично выполняет свою работу, то эти практики приводят к созданию
ПО без дефектов. К сожалению, идеал невозможен. У вашей команды наверняка есть
слепые зоны: области, в которых члены команды делают ошибки, но не знают об этом.
Эти слепые зоны вызывают повторяющиеся, системные ошибки. Они «системные»
потому, что являются следствием всей вашей системы разработки: команды, ее про-
цессов, инструментов, которые вы используете, среды, в которой вы работаете, и т. д.
Ускользнувшие дефекты — явный сигнал наличия проблем. Даже если ошибки
и неизбежны, большинство из них обнаруживаются быстро. Дефекты, обнаруженные
пользователями, «ускользнули». Каждый такой дефект указывает на необходимость
улучшить вашу систему разработки.
Конечно, вы не хотите, чтобы ваши ко-
нечные пользователи были вашими бета- См. также
тестировщиками. И именно здесь на пер-
вый план выходит обнаружение слепых
зон. Оно представляет собой многообразие
техник, таких как хаос-инжиниринг и исследовательское тестирование, которые по-
могают найти пробелы в вашем понимании. Я расскажу о них в следующей практике.
Некоторые команды используют эти техники для проверки качества своей си-
стемы программного обеспечения: они кодируют историю, ищут баги, исправляют их
и повторяют все сначала. Но для того, чтобы встроить качество, обращайтесь с ва-
шими слепыми зонами как с ключом к пониманию того, как улучшить вашу систему
разработки, а не только систему ПО. То же самое применимо для ускользнувших
дефектов. Они все — ключ к пониманию того, что можно улучшить.
Анализ инцидентов помогает расшифровать эти ключи. Независимо от послед-
ствий, если ваша команда думала, что что-то было сделано, а оно впоследствии по-
требовало исправлений, то анализ инцидентов может быть полезен. Он применим
и для ошибок, сделанных из лучших побуждений: если все думают, что определенная
новая функциональность — отличная идея, а по-

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

Как никогда не говорил великий Мастер Йода,
«Делайте. Или не делайте. Нет никаких // Делайте. Или не делайте.
TODO». Нет никаких //TODO.
Каждый дефект — результат изъяна, кото-
рый, скорее всего, приведет к новым ошибкам.
Улучшайте качество и производительность, См. также
исправляя их сразу, незамедлительно.
Быстрое исправление ошибок требует уча- (глава 12)
стия всей команды. Программисты, используйте
коллективное владение кодом, чтобы каждый
мог исправить любой баг. Заказчики и тести-
ровщики, лично сообщайте программисту о каждом баге и помогайте воспроизвести
его. Это проще всего делать, когда команда работает в общем помещении.
На практике невозможно исправить каждый баг сразу. Вы можете заниматься чем-
то другим, когда узнаете о баге. Когда это происходит со мной, я прошу своего штур-
мана сделать заметку-напоминание. Мы возвращаемся к ней через 10–20 минут, когда
достигаем подходящего для остановки места.
Некоторые баги слишком большие, чтобы их
можно было исправить быстро. В таких случаях См. также
я собираю команду, чтобы устроить быстрое
обсуждение. Мы коллективно решаем, достаточ-
но ли у нас резерва времени, чтобы исправить Планирование задач (глава 9)
баг и при этом исполнить остальные наши обя- Визуальное планирование
зательства. Если достаточно, то мы создаем за- (глава 8)
дачи для бага, добавляем их в свой план, и люди
добровольно берутся решать эти задачи, как обычно. (Если вы используете практику
оценок, то эти задачи не оцениваются и не засчитываются в ваш потенциал.)
Если резерва времени недостаточно, чтобы исправить баг, то решите всей
командой, насколько важно исправить его до следующего релиза. Если важно,
то создайте для него историю и немедленно внесите ее в план вашей следующей
итерации или слот истории. Если нет, то добавьте ее к вашему визуальному плану
в подходящий релиз.
Баги, которые не настолько важны, чтобы их исправлять, нужно удалить. Если вы

не можете это сделать, то баг следует исправить. Однако исправление может выгля-
деть как задокументированное обходное решение или запись о том, что вы решили
не исправлять баг. Для этого может подойти система отслеживания задач.
Роль тестировщика
Так как команды, обладающие навыками на уровне поставки, скорее встраивают
качество, чем тестируют на ошибки, люди с навыками тестировщиков делают сдвиг
влево. Вместо того чтобы направлять свои навыки на завершенный продукт, они со-
средоточиваются на том, чтобы помогать команде создавать качественный продукт
с самого начала.
По моему опыту, некоторые тестировщики ориентированы на бизнес: они очень
заинтересованы в том, чтобы правильно понимать бизнес-требования. Они работают
с заказчиками в команде, чтобы выявить все мельчайшие подробности, которые в про-
тивном случае заказчик бы упустил. В ходе обсуждения требований такие специалисты
часто подсказывают людям, что нужно подумать о граничных случаях.
Другие тестировщики больше ориентированы на технические аспекты. Они
заинтересованы в автоматизации тестирования и нефункциональных требовани-
ях. Эти тестировщики служат техническими исследователями команды. Они
создают испытательные стенды, которые изучают такие задачи, как масштабиру-
емость, надежность и производительность. Они просматривают журналы событий,
чтобы понять, как система ПО работает в эксплуатационной среде. Таким образом
эти тестировщики помогают команде понять поведение их ПО и решить, когда
уделить больше внимания эксплуатации, безопасности или нефункциональным
историям.
Тестировщики также помогают команде
обнаруживать слепые зоны. В целом исполь- См. также
зовать техники обнаружения таких зон может
кто угодно в команде, однако люди с навы- Обнаружение слепых зон (глава 16)
ками тестирования, как правило, особенно
хороши в этом.
Правильное мироощущение
Я поощряю особое мироощущение в своих
командах — немного элитарности, даже сно- Баги — это для других.
бизма. Его можно кратко описать следующим
образом: «Баги — это для других».
Если вы делаете все, что я описал, то баги должны быть редкостью. Ваш следу-
ющий шаг — относиться к ним именно так. Вместо того чтобы пожимать плечами,
когда возникает баг («Ах, да, еще один баг, в программах это бывает»), вы должны
быть потрясены и обескуражены. Баги — это не то, что нужно терпеть; это признак
наличия фундаментальных проблем, которые нужно решить.
В конечном итоге «без багов» — это

призыв к воспитанию культуры пре- См. также
восходства. Когда вы узнаете о баге,
исправляйте его сразу, а потом разби- Парное программирование (глава 12)
райтесь, как предотвратить появление Групповое программирование (глава 12)
этого типа багов в будущем. Командная комната (глава 7)
Вам не удастся прийти к этому за
одну ночь. Все практики, которые я опи- Коллективное владение кодом (глава 12)
сал, требуют дисциплины и упорства.
Они необязательно трудные, но теряют эффективность, если люди небрежны или
не заботятся о своей работе. Культура «без багов» помогает команде поддерживать
необходимую дисциплину, равно как и парное или групповое программирование,
командная комната или коллективное владение.
В конечном итоге вы придете к этому. Команды Agile могут и достигают почти
нулевого уровня багов. Вы тоже можете.
Вопросы
Как нам предотвращать дефекты безопасности и другие сложные баги?
Моделирование угроз (см. подраздел «Моделирование угроз» ранее в текущей
главе) может помочь вам подумать об изъянах в системе безопасности заранее. О про-
блемах, требующих решения, вам могут напоминать чек-лист «сделано сделано»
и установленные вами стандарты кодирования. Однако таким образом вы сможете
предотвращать только те баги, кото-
рые думали предотвратить. Безопас- См. также
ность, параллелизм и другие сложные
проблемные области могут порождать Сделано Сделано (глава 9)
дефекты, о которых вы никогда даже Согласование (глава 7)
не подозревали. Вот почему так важно
обнаруживать слепые зоны.
Как нам отслеживать наши баги?
Для новых багов вам вряд ли понадобится база данных багов или трекер проблем,
при условии, что ваша команда не генерирует множество багов. (Если генерирует, то
сначала сконцентрируйтесь на решении той проблемы.) Если баг слишком велик,
чтобы исправить его сразу, то превратите его в историю и отслеживайте детали та-
ким же образом, каким обрабатываете детали других требований.
Как долго мы должны работать над багом, прежде чем превратить его в историю?
Это зависит от того, какой резерв
времени у вас в наличии. В начале ите-
рации, когда такого резерва много, я мог См. также
потратить полдня на дефект, прежде
чем превратить его в историю. Позже, Резерв времени (глава 9)
когда резерва оставалось меньше, я мог
потратить на него только 10 минут.
У нас много устаревшего кода. Как нам освоить политику «без багов» и при этом
не сойти с ума?
Это потребует времени. Начните с изучения вашей базы данных багов и опреде-
лите те, которые вы хотите исправить в текущем релизе. Запланируйте по крайней
мере одно исправление каждую неделю, стараясь исправить их как можно раньше,
а не позже.
Каждую неделю или две произвольно
выбирайте какой-либо недавний баг, чтобы См. также
провести анализ инцидентов хотя бы нефор-
мально. Это позволит вам постепенно улуч- Анализ инцидентов (глава 16)
шать вашу систему разработки и предот
вращать баги в будущем.
«Без багов» — культура совершенства. Она может существовать только внутри ко-
манды. Руководители, не просите ваши команды отчитываться о количестве дефек-
тов и не награждайте и не наказывайте их на основе количества имеющихся у них
дефектов. Это приведет к тому, что дефекты будут скрыты и качество ухудшится,
а не улучшится. Я буду говорить об этом дальше в подразделе «Ответственность за
инциденты» главы 16.
Достижение идеала «без багов» зависит от огромного количества практик Agile —
по сути, от каждой практики фокусировки и поставки, описанной в этой книге. До тех
пор, пока ваша команда не достигнет компетентности в этих практиках, не ждите
значительного снижения дефектов.
В то же время если вы используете практики фокусировки и поставки, то по-
явление новых багов в количестве, большем, чем несколько штук в месяц, может
говорить о проблеме с вашим подходом. Конечно, вам понадобится время, чтобы
научиться этим практикам и усовершенствовать свой процесс, но вы должны
увидеть улучшение, касающееся количества ваших багов, в течение нескольких
месяцев. Если не увидите, то сверьтесь с врезкой «Руководство по устранению
неполадок» в главе 4.
Когда в вашей команде есть культура «без багов»:
zz ваша команда уверена в качестве своего ПО;
zz вам комфортно делать релизы в эксплуатационную среду без фазы ручного те-
стирования;
zz стейкхолдеры, заказчики и пользователи редко встречаются с неприятными
сюрпризами;
zz ваша команда тратит свое время на производство отличного ПО, а не на борьбу
с авралами.
Одна из революционных идей Agile подразумевает, что ПО с низким количеством
дефектов может быть дешевле производить, чем ПО с большим количеством дефек-
тов. Это становится возможным с помощью встраивания качества. Чтобы поэкспери-
ментировать еще больше, посмотрите на те части вашего процесса, в конце которых
проверяется качество, и поищите способ, как встроить это качество в самом начале.
Вы также можете снизить количество багов, используя еще больше высоко
качественного тестирования для поиска и исправления все большего процента ба-
гов. Однако это работает не так хорошо, как встраивание качества с самого начала.
К тому же это вас замедлит и затруднит релизы.
Некоторые компании, пытаясь улучшить качество, инвестируют в отдельные
команды по контролю качества. Случайное независимое тестирование может быть
полезно для обнаружения слепых зон, однако отдельная команда, контролирующая
качество, — не очень хорошая идея. Парадоксально, но это ведет к снижению каче-
ства, поскольку команда разработки сама тратит меньше усилий на качество. Этот
феномен исследует Элизабет Хендриксон в отличной статье Better Testing, Worse
Quality? [Hendrickson2000].
ОБНАРУЖЕНИЕ СЛЕПЫХ ЗОН

Аудитория
Мы выявляем пробелы в своем мышлении.
Тестировщики, вся команда
Как вы видели в предыдущей практике, компе-
тентные команды поставки очень хорошо умеют
встраивать качество в свой код. Но никто не идеален, и у команд есть слепые зоны.
Практика «Обнаружение слепых зон» позволяет найти эти пробелы.
Чтобы найти эти слепые зоны, посмотрите на предположения, которые делает ваша
команда, и учтите давление и ограничения, под влиянием которых она находится.
Представьте риски, с которыми может столкнуться команда, и подумайте о том, что
члены команды могут по ошибке принимать за истину. Сделайте предположение
о том, какие слепые зоны могут образоваться в результате, и проведите исследова-
ние, чтобы проверить верность вашего предположения. Тестировщики, как правило,
особенно хороши в этом.
Когда вы обнаружите слепые зоны, не просто исправляйте найденную проблему.
Исправьте пробел. Подумайте о том, как ваш подход привел к возникновению ошибки,
а затем измените его, чтобы предотвратить повторное появление этой категории багов,
как описано в пункте «Предотвращение системных ошибок» ранее в текущей главе.
Подтвержденное знание
Думая о багах, люди часто представляют себе ошибки логики, ошибки UI или кри-
тические сбои в эксплуатационной среде. Но та слепая зона, которую я вижу чаще
всего, более фундаментальная и более трудноуловимая.
Чаще всего команды создают не то, что надо. Используя терминологию береж-
ливого стартапа, им не хватает соответствия продукта рынку. Я думаю, это проис-
ходит потому, что многие команды думают о своей работе как о создании продукта,
который им приказали создать. Они действуют как послушные исполнители при-
казов: фабрика программного обеспечения, спроектированная поглощать истории на
входе и выпускать готовое ПО на выходе.
Не считайте, что ваша команда должна
создавать то, что ей приказали создать. Луч- Никто на самом деле не знает, что
ше предположите обратное: никто на самом вы должны создать, даже люди,
деле не знает, что вы должны создать, даже которые просят об этом.
люди, которые просят об этом. Работа вашей
команды состоит в том, чтобы взять идеи, протестировать их и узнать, что вам на
самом деле нужно сделать. Перефразируя The Lean Startup1 [Ries2011], фундаменталь-
ная деятельность любой команды Agile — превращать идеи в продукты, наблюдать
за реакцией заказчиков и пользователей и затем решать, что делать дальше: разво-
рачиваться или продолжать двигаться в этом направлении. Это называется под-
твержденным знанием.
Многие команды первый раз тестируют
свои идеи в тот момент, когда выполняют См. также
релиз своего ПО. Это довольно рискованно.
Лучше использовать цикл Риса «создать —
измерить — изучить» (Build-Measure-Learn). Визуальное планирование (глава 8)
1. Создать. Посмотрите на цель и план ва- Вовлечение реального заказчика
шей команды. Каковы ваши базовые пред- (глава 8)
положения о вашем продукте, заказчике
и пользователях? Выберите для тестирования одно из них, а потом подумайте:
«Какой самый маленький элемент мы можем продемонстрировать реальным за-
казчикам и пользователям?» Это не обязательно должен быть реальный продукт
(в некоторых случаях вполне подойдут макет или бумажный прототип), и вам
не обязательно вовлекать каждого пользователя, но нужно вовлечь людей, которые
на самом деле будут покупать и использовать ваш продукт.
2. Измерить. Прежде чем показывать людям, что вы создали, решите, какие данные
вам нужно увидеть, чтобы сказать, подтвердились ваши предположения или нет.
Данные могут быть субъективными, но измерения должны быть объективными.
Например, «70 % наших заказчиков говорят, что нас любят» — объективное из-
мерение субъективных данных.
3. Изучить. Ваши измерения будут либо подтверждать вашу гипотезу, либо опро-
вергать ее. Если вы подтвердили гипотезу, то переходите к следующей. Если
опровергли, измените свои планы соответствующим образом.
Например, целью одной команды было улучшить результаты хирургического лече-
ния позвоночника. Команда планировала сделать это, создав инструмент, который по-
зволит руководству клиник смотреть на хирургические данные с разных точек зрения.
Одним из базовых предположений этой команды было то, что клиники будут доверять
исходным данным, представленным этим инструментом. Но данные могли оказаться
скудными, и руководители клиник, как правило, относились к ним скептически.
1
Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.
Чтобы протестировать предположение, команда решила сделать следующее: ис-

пользовать реальные данные от семи клиник для создания макета будущего инстру-
мента (создать); показать его руководителям этих семи клиник (измерить); если
хотя бы пятеро из них сказали бы, что данные имеют приемлемое качество, то пред-
положение было бы подтверждено (изучить). Если нет, то команда должна была
разработать другой план.
Обладание подтвержденным знанием —
одна из отличительных черт команды опти- Обладание подтвержденным
мизации. В зависимости от вашей организа- знанием — одна из отличительных
ционной структуры, вы можете не суметь черт команды оптимизации.
использовать ее во всей ее полноте. Тем
не менее основная идея применима. Не просто предполагайте, что поставка идеи
сделает людей счастливыми. Делайте все, что можете, чтобы проверить свои пред-
положения и получить обратную связь.
Больше информации о подтвержденном знании и связанной с ним концепции
открытия заказчика вы найдете в [Ries2011] и [Blank2020b].
Исследовательское тестирование
Разработка через тестирование гарантиру-
ет, что код, написанный программистами, См. также
будет делать то, что они от него хотят. Но
что, если намерения программистов невер- Разработка через тестирование
(глава 13)
ны? Например, программист может думать,
что правильный способ определить длину
строки в JavaScript — это использовать string.length, но это может привести к тому,
что в слове naïve будет насчитано шесть букв1.
«Исследовательское тестирование» — это техника для поиска подобных слепых
зон. Это скрупулезный подход к тестированию, подразумевающий «планирование
и выполнение быстрой последовательности крошечных экспериментов, где резуль-
таты предыдущего эксперимента используются в качестве вводной информации
для следующего» [Hendrickson2013] (гл. 1). Эта техника состоит из следующих шагов.
1. Устав. Начните с решения, что вы собираетесь исследовать и почему. Новую тех-
нологию, недавно освоенную командой? Недавно выпущенный пользовательский
интерфейс? Критический фрагмент инфраструктуры безопасности? Ваш устав
должен быть достаточно общим, чтобы обеспечить вас работой на час или два,
и достаточно конкретным, чтобы помочь вам сфокусироваться.
2. Наблюдение. Используйте ПО. Чаще всего вы будете делать это через UI, но также
можете использовать инструменты, чтобы исследовать API и сетевой трафик;
1
Подсчет может быть ошибочным, поскольку string.length считает количество кодовых точек (что-
то вроде того), а не количество графем (того, что люди обычно считают символами), а Unicode
может хранить графему как две кодовые точки: обычное i плюс комбинированный диэрезис
(умлаут). Обработка строки имеет аналогичные проблемы. Инвертирование строки, содержащей
испанский флаг, превратит Испанию в Швецию , что наверняка удивит любителей
пляжного отдыха.
кроме того, вы можете наблюдать за скрытыми частями системы, такими как

журналы событий и базы данных. Обращайте внимание на две вещи: все, что
выбивается из разряда обычного, и все, что вы можете изменить, например URL,
поле формы или загрузку файла, что в результате может привести к неожиданному
поведению. Делайте заметки в процессе, чтобы вы могли отследить свои шаги,
когда это будет необходимо.
3. Изменение. Не просто используйте ПО обычным образом; расширьте его гра-
ницы. Добавьте эмодзи в текстовое поле. Введите значение размера как ноль
или отрицательное значение. Загрузите файл с нулевым байтом, поврежденный
файл или «взрывающийся» ZIP-файл, который расширяется до терабайтов
данных. Редактируйте URL. Измените сетевой трафик. Искусственно замедлите
свою сеть или сделайте запись в файловую систему, в которой нет свободного
места.
По мере продвижения используйте свои наблюдения и понимание системы, чтобы
решить, что исследовать дальше. Вы вполне можете дополнить эти идеи, просмотрев
код и рабочие журналы событий. Если вы исследуете возможности безопасности, то
можете использовать модель угроз вашей команды как источник вдохновения или
создать собственную. (См. подраздел «Моделирование угроз» главы 15.)
Исследовательское тестирование предоставляет гораздо больше возможностей,
чем я могу описать в этой книге. Больше информации и отличный набор эвристик
о том, что можно варьировать, вы найдете в [Hendrickson2013].
Хаос-инжиниринг
В большой сетевой системе сбои — ежедневное явление. Ваш код должен быть за-
программирован на устойчивость к ним, а это требует особого внимания к обработке
ошибок и отказоустойчивости. К сожалению, обработка ошибок — общая слепая зона
для не очень опытных программистов и команд, и даже опытные команды не могут
прогнозировать каждый случай отказа сложной системы.
Хаос-инжиниринг можно считать особой формой исследовательского тестирова-
ния, которое фокусируется на системной архитектуре1. В него входит умышленное
внесение сбоев в работающие системы (зачастую живые эксплуатационные системы)
с целью узнать, как они реагируют на сбой. Хотя такие действия кажутся рискованны-
ми, их можно выполнять контролируемо. Это позволяет вам обнаружить проблемы,
появляющиеся только в результате сложных взаимодействий.
Хаос-инжиниринг похож на исследовательское тестирование тем, что включает
в себя поиск возможностей, позволяющих изменить нормальное поведение. Однако
вместо того, чтобы думать в терминах непредвиденных данных, введенных пользо-
вателем, или вызовов по API, вы думаете в терминах непредвиденного поведения
1
Некоторые люди из сообщества хаос-инжиниринга возражают против использования слова «те-
стирование» в отношении хаос-инжиниринга. Они предпочитают термин «эксперимент». Я думаю,
это возражение возникло из-за неправильного понимания природы тестирования. Как пишет
Элизабет Хендриксон в Explore It!: «Суть тестирования вот в чем: проектировать эксперимент
для сбора эмпирических свидетельств, чтобы ответить на вопрос о риске» [Hendrickson2013]
(гл. 1). Это именно то, чем является и хаос-инжиниринг.
системы: отказы узлов, сетевые связи с высокой задержкой, необычные ответные

реакции и т. д. По сути, речь идет о проведении экспериментов, призванных опре-
делить, действительно ли ваша система ПО так устойчива, как вы думаете.
1. Начните с понятия «устойчивое состояние» для вашей системы. На что похожа
ваша система, когда она функционирует нормально? Какие предположения де-
лает ваша команда или организация относительно устойчивости вашей системы?
Какие из них было бы наиболее ценно проверить первыми? Когда вы проведете
эксперимент, как вы узнаете, был он успешен или потерпел неудачу?
2. Приготовьтесь изменить систему каким-либо образом: убрать один узел, ввести
задержку, изменить сетевой трафик, искусственно повысить количество запросов
и т. д. (Если это ваш первый тест, то начните с малого, чтобы ограничить влияние
сбоя.) Сформулируйте гипотезу о том, что произойдет. Составьте план преры-
вания эксперимента, если все пойдет слишком плохо.
3. Внесите изменение и понаблюдайте, что происходит. Была ли правильной ваша
гипотеза? Система все еще работает адекватно? Если нет, то вы обнаружили
слепую зону. В любом случае обсудите результаты с вашей командой и усовер-
шенствуйте коллективную ментальную модель системы. Используйте то, что вы
узнали, чтобы решить, какой эксперимент проводить следующим.
Многие истории, касающиеся хаос-инжиниринга, связаны с использованием
автоматизированных инструментов, например Chaos Monkey от Netflix. Однако при
использовании хаос-инжиниринга внутри команды не фокусируйтесь на создании
инструментов. Гораздо ценнее проводить множество экспериментов, чем автоматиче-
ски повторять один. Вам понадобится некий базовый инструментарий для поддержки
вашей работы, и со временем он будет становиться все более и более усложненным.
Но старайтесь проводить максимально широкий набор экспериментов, используя
наименьший объем работы.
Принципы хаос-инжиниринга можно найти на https://principlesofchaos.org. Подробное
изложение темы в формате книги см. в [Rosenthal2020].
Тестирование на проникновение и оценка уязвимостей

Исследовательское тестирование может находить слепые зоны, относящиеся к без-
опасности, однако программное обеспечение, чувствительное к вопросам безопас-
ности, требует тестирования экспертами.
Тестирование на проникновение (penetration testing), также известное как пен-
тест (pentesting), подразумевает попытки нарушить безопасность вашей системы
так, как это сделал бы реальный атакующий. В такое тестирование может входить
зондирование ПО, которое пишет ваша команда, но, помимо этого, оно рассматри-
вает безопасность более комплексно. В зависимости от правил участия, которые
вы устанавливаете, с помощью данного тестирования можно проверять вашу экс-
плуатационную инфраструктуру, конвейер развертывания, человеческие суждения
и даже физическую безопасность, например замки и двери.
Тестирование на проникновение требует специальной квалификации. Как пра-
вило, нанимают внешнюю фирму. Это дорого, и результаты во многом зависят от
мастерства тестировщика. Проявляйте особую осмотрительность, нанимая фирму

для тестирования на проникновение, и помните, что конкретные люди, выполняющие
тесты, не менее важны, чем нанятая вами фирма.
Оценка уязвимостей — менее дорогостоящая альтернатива тестированию на про-
никновение. Хотя технически пентест — это вид оценки уязвимостей, большинство
фирм заявляет в своей рекламе, что «оценка уязвимостей» выполняет автоматизи-
рованное сканирование.
Некоторые оценки уязвимостей выполняют статический анализ вашего кода и за-
висимостей. Если они достаточно быстрые, то могут быть добавлены в вашу сборку
непрерывной интеграции. (Если нет, то вы можете использовать многоступенчатую
интеграцию, как описано в подразделе «Многоступенчатые интеграционные сборки»
главы 13.) Со временем вендор, выполняющий оценку, будет добавлять в инструмент
дополнительные сканирования, которые будут оповещать вашу команду о новых
потенциальных уязвимостях.
Другие оценки проверяют ваши живые системы. Например, вендор может про-
верять ваши сервисы на открытые административные интерфейсы, стандартные
пароли и уязвимые URL. Как правило, вы будете получать периодический отчет
(например, ежемесячный), описывающий, что обнаружила оценка.
Оценка уязвимостей может быть «зашумленной» ложными результатами. Скорее
всего, вам понадобится кто-то с навыками в сфере безопасности, кто сможет про-
смотреть ее и рассортировать результаты. Вам также может понадобиться какой-то
безопасный способ игнорировать неактуальные результаты. Например, одна из оценок
выполняла сканирование на уязвимые URL, но была недостаточно «умной», чтобы
следовать HTTP-перенаправлениям. Каждый месяц она выдавала отчет, в котором
каждый URL объявлялся уязвимостью, хотя сервер просто выполнял общее пере-
направление (blanket redirect).
В целом начинайте с моделирования угроз (см. подраздел «Моделирование
угроз» главы 15) и чек-листов безопасности, таких как OWASP Топ-10 (https://
www.owasp.org), чтобы обосновать ваши усилия по программированию и исследо-
вательскому тестированию. Используйте автоматизированные оценки уязвимостей
для отслеживания и исправления дополнительных угроз и поиска слепых зон. Затем
переходите к тестированию на проникновение, чтобы понять, что вы упустили.
Вопросы
Эти техники должны выполняться индивидуально, в парах или группах?
Это зависит от вашей команды. Эти техники вполне можно выполнять индиви-
дуально. В то же время парное и групповое программирование позволяют получать
и распространять новые идеи и могут помочь
сломать барьеры, которые часто образуются См. также
между тестировщиками и другими членами
команды. Поэкспериментируйте, чтобы уви- Парное программирование (глава 12)
деть, какой подход лучше всего работает для
вашей команды. Он может варьироваться (глава 12)
в зависимости от техники.
Не будет ли нагрузка, связанная с обнаружением слепых зон, повышаться по мере

расширения ПО?
Не должна. Обнаружение слепых зон не похоже на традиционное тестирование,
которое имеет тенденцию разрастаться вместе с кодовой базой. Оно предназначено
для проверки предположений, а не постоянно растущей кодовой базы. Когда команда
работает над слепыми зонами и обретает уверенность в своей способности поставлять
высококачественные результаты, необходимость в обнаружении слепых зон должна
снижаться, а не повышаться.
Любая команда может использовать эти техники. Но помните, что они нужны для
обнаружения слепых зон, а не для проверки, что ПО работает. Не позволяйте им стать
узким местом. Вам не нужно делать проверки перед релизом, и вам не нужно про-
верять все. Вы ищете изъяны в вашей системе разработки, а не в системе вашего ПО.
С другой стороны, релиз без дополнительных
проверок требует от вашей команды способности
См. также
производить код практически с нулевым уровнем
багов. Если вы пока еще не дошли до этого или Без багов (глава 16)
просто не готовы, то вполне можете отложить
релиз до тех пор, пока не проверите наличие слепых зон. Просто удостоверьтесь,
что не используете практику обнаружения слепых зон как костыль. Исправляйте
свою систему разработки так, чтобы вы могли делать релиз, не прибегая к ручному
тестированию.
Когда вы хорошо используете практику обнаружения слепых зон:
zz команда доверяет качеству своего ПО;
zz команда не использует практику обнаружения слепых пятен как форму тести-
рования перед релизом;
zz количество дефектов, обнаруженных в эксплуатационной среде и с помощью
техники слепых зон, со временем снижается;
zz количество времени, необходимое для обнаружения слепых пятен, со временем
снижается.
Эта практика основана на предположении, что
разработчики вполне могут создавать системы См. также
практически без багов, дефекты — это результат
исправимых слепых зон, а не недостатка ручного Без багов (глава 16)
тестирования. Таким образом, техники направ- Разработка через тестирова-
лены на обнаружение сюрпризов и проверку ние (глава 13)
гипотез.
Наиболее распространенная альтернатива — традиционное тестирование: подготов-

ка планов повторяющихся тестов, которые всесторонне проверяют систему. Хотя это
может показаться более надежным, такие планы сами имеют слепые зоны. Большин-
ство тестов в итоге начинают дублировать те тесты, которые программисты создают
в процессе разработки через тестирование. В лучшем случае они могут находить те же
типы проблем, которые обнаруживает исследовательское тестирование, но с более
высокими затратами, и редко находят проблемы, выявляемые другими техниками.
Что касается экспериментов, техники, которые я описал, — это лишь начало. Основ-
ная идея — подтвердить ваши скрытые предположения. Все, что вы сможете сделать,
чтобы их определить и протестировать, будет объектом исследования. Еще одна тех-
ника, которую вы можете изучить, — фаззинг (fuzzing). Она подразумевает создание
большого количества вводных данных и мониторинг непредвиденных результатов.
АНАЛИЗ ИНЦИДЕНТОВ
Аудитория
Мы учимся на ошибках.
Вся команда
Несмотря на все ваши усилия, ПО иногда будет
отказываться работать так, как должно. Некоторые
сбои будут мелкими, вроде опечатки на веб-странице. Другие — более значительными,
такими как код, который повреждает данные заказчика, или сбой, препятствующий
доступу заказчиков.
Одни сбои называют багами или дефектами, другие — инцидентами. Различие
не особенно важно. В любом случае, как только страсти улягутся и все снова будет
идти гладко, вам нужно будет выяснить, что случилось и как вы можете это испра-
вить. Это и есть анализ инцидентов.
Подробности того, как реагировать во время инцидента, выходят за рамки этой
книги. Отличное практическое руководство по реагированию на инциденты — Site
Reliability Engineering: How Google Runs Production Systems [Beyer2016], особенно
главы 12–14.
Примите сбой
Команды Agile понимают, что сбои неизбежны. Люди делают ошибки; возникают
недопонимания; идеи не срабатывают.
Вместо того чтобы вовлекаться в идеалистический квест в надежде избежать
сбоя, команды Agile принимают его возможность. Если он неизбежен, то самое
важное — обнаружить его как можно быстрее; получить ошибку на раннем этапе,
пока еще есть время на восстановление, противостоять сбою, чтобы последствия
были минимальными; и учиться на ошибке, а не искать виноватого.
Непрерывное развертывание — хороший пример этой философии. Команды,

использующие непрерывное развертывание, обнаруживают сбои с помощью
мониторинга. Они делают развертывание каждые час или два, что позволяет вы-
явить сбои на ранней стадии, а также уменьшить их влияние. Команды используют
канареечные серверы, чтобы минимизировать последствия сбоя, и рассматрива-
ют каждый сбой как возможность понять свои границы и совершенствоваться.
Как это ни странно, принятие возможности сбоя ведет к меньшим рискам и луч-
шим результатам.
Сбои могут быть неизбежными, но это не мешает успеху.
Природа сбоя
Всегда есть соблазн думать о сбое как о ре-
зультате простой причинно-следственной Сбой — следствие специфики всей
связи. А сделал нечто, приведшее к Б, а это, вашей системы разработки.
в свою очередь, привело к В — однако на
самом деле все происходит не так1. В реальности сбой — следствие специфики всей
вашей системы разработки, в которой выполняется работа. (Ваша система разра-
ботки — это все аспекты того, как вы создаете ПО, начиная с инструментария и за-
канчивая организационной структурой. Система разработки отличается от вашей
системы ПО, которую вы создаете.) Каждый сбой, каким бы незначительным ни был,
содержит подсказку о характере и слабых местах этой системы разработки.
Сбой — результат множества взаимодействующих событий. Мелкие проблемы
происходят постоянно, но система имеет стандарты, которые удерживают их в преде-
лах безопасных границ. Программист делает ошибку смещения на единицу, но его
напарник предлагает тест, который ее находит. Локальный заказчик плохо объясняет
историю, но позже во время обсуждения с заказчиками замечает недопонимание.
Член команды случайно стирает файл, но непрерывная интеграция отклоняет под-
тверждение (коммит).
Сбой возникает не из-за одной причины, а потому что много всего одновременно
пошло не так. Программист делает ошибку смещения на единицу, и его напарник
засиделся допоздна с новорожденным и не заметил ошибку, и команда эксперимен-
тирует с менее частыми переключениями пар, и оповещения канареечных серверов
случайно были отключены. Сбои возникают не из-за проблем, а потому что система
разработки (люди, процессы и бизнес-среда) позволяют проблемам объединиться.
Более того, системы демонстрируют тенденцию к отказу. Как ни странно, для
команд, имеющих опыт противостояния отказам, угрозу представляют не ошиб-
ки, а успех. Со временем при отсутствии отказов стандарты команды меняются.
Например, команда может сделать работу в парах необязательной, чтобы дать
людям больше возможностей выбора рабочего стиля. Их безопасные границы
1
Мое обсуждение природы неудач основано на [Woods2010] и [Dekker2014].
сужаются. В конечном итоге условия отказа (которые существовали все это время!)
соединяются таким образом, что преодоление этих границ становится возможным,
и возникает отказ.
Тенденцию к отказу трудно заметить. Каждое изменение — маленькое и в каком-
то другом измерении является улучшением, как, например, скорость, стоимость,
удобство или удовлетворенность заказчика. Чтобы предотвратить эту тенденцию,
вы должны сохранять бдительность. Успехи в прошлом не гарантируют успеха в бу-
дущем.
Вы можете ожидать, что крупные сбои
являются результатом больших ошибок, Маленькие сбои — нечто вроде
но это не так. Единственной причины нет, «генеральной репетиции»
как нет и пропорциональности. Крупные для больших.
сбои — результат тех же системных проблем,
свойственных маленьким сбоям. Это хорошая новость, поскольку это значит, что
маленькие сбои — нечто вроде «генеральной репетиции» для больших. Вы можете
научиться у них тому же, чему и у больших.
Таким образом, рассматривайте каждый сбой как возможность учиться и совер-
шенствоваться. Опечатка — это сбой. Проблема, обнаруженная перед релизом, — тоже
сбой. Неважно, большая она или маленькая. Если ваша команда думает, будто что-то
«сделано» и это что-то позже нуждается в исправлении, то ситуация заслуживает
анализа.
Но все еще глубже. Сбой — следствие устройства вашей системы разработки, как
я уже сказал, но и успехи тоже. Вы можете проанализировать и их.
Опечатка? В самом деле?

Анализ небольших сбоев (даже совсем незначительных) может рассказать вам
о тех же системных моментах, которые вызывают большие проблемы. Например,
вашу команду попросили исправить опечатку в вашей политике конфиденциаль-
ности. Слово the в 13-м абзаце неправильно написано как teh. Это незначительная
опечатка, она не причиняет никакого вреда и легко исправляется.
В ходе анализа инцидентов обнаруживается, что никто в команде не думал, что
проверять политику конфиденциальности — их зона ответственности. Документ
пришел из юридического отдела, программисты его вставили, заказчики в коман-
де удостоверились, что он есть, — и все готово. Никто его даже не читал. Команда
обсуждает это и решает взять на себя ответственность за все содержимое свое-
го ПО независимо от того, откуда оно пришло.
Шесть месяцев спустя ваша команда добавляет маркетинговый документ при
подготовке к большому релизу. Благодаря новой политике команда выделяет
время на проверку этого документа. И вовремя: в нем написано, что ваш новый
релиз — sham dunk (фиктивный). Упс. Ничего страшного, вы связываетесь с отделом
маркетинга и уточняете. Через несколько дней продукт выходит в свет — и это
slam dunk (гарантированный успех).
Проведение анализа
Анализ инцидентов — вид ретроспективы.
Это ваш совместный взгляд назад на вашу См. также
систему разработки с целью изучения и со-
вершенствования. Учебник. Соответственно, Ретроспективы (глава 11)
эффективный анализ подразумевает пять
стадий ретроспективы [Derby2006].
1. Подготовить условия.
2. Собрать данные.
3. Генерировать идеи.
4. Решить, что делать.
5. Завершить ретроспективу.
Пригласите для участия в сессии анализа всю вашу команду, а также всех, кто уча-
ствует в реагировании на инцидент. Избегайте присутствия руководителей и любых
других представителей руководства; вам нужно, чтобы участники могли высказаться
и открыто признать ошибки, а это требует ограниченного круга участников, в кото-
рый входят только те, кто необходим. Если анализ вызовет большой интерес, то вы
можете создать отчет об инциденте; я расскажу подробности чуть позже.
Время, необходимое для сессии анализа, зависит от количества событий, которые
привели к инциденту. Сложные критические сбои могут иметь десятки событий
и занимать несколько часов. Однако простой дефект может состоять всего из не-
скольких событий и занять 30–60 минут. По мере накопления опыта вы будете
делать все быстрее.
В самом начале и в случаях рассмотрения деликатных инцидентов сессию должен
ввести нейтральный фасилитатор. Чем деликатнее инцидент, тем более опытным
должен быть фасилитатор.
Эта практика, как и все в данной книге, ориентирована на инциденты командного
уровня — те, которые команда может анализировать самостоятельно. Вы также
можете использовать ее для анализа участия вашей команды в более крупном
инциденте.
1. Подготовить условия
Анализ инцидентов подразумевает критиче-
ский взгляд на успехи и неудачи. Поэтому См. также
каждому участнику жизненно необходимо
чувствовать себя в безопасности, чтобы вне- Безопасность (глава 7)
сти свой вклад, включая откровенные обсуж-
дения принятых решений. Начните сессию, напомнив каждому, что ее цель состоит
в том, чтобы с помощью инцидента лучше понять, как вы создаете ПО — вашу си-
стему разработки, состоящую из людей, процессов, ожиданий, окружающей среды
и инструментов. Вы здесь не для того, чтобы сфокусироваться на самой неудаче или

найти виноватых, а для того, чтобы узнать, как сделать вашу систему разработки
более устойчивой.
Попросите всех подтвердить, что они готовы придерживаться этой цели, и пред-
полагайте добрую волю со стороны каждого, кто вовлечен в инцидент. Подходящий
способ — обратиться к Первой директиве Норма Керта.
Независимо от того что мы обнаружим, мы должны понимать и искренне верить,
что каждый делал свою работу наилучшим образом, в соответствии с тем, что
было известно на тот момент, его или ее навыками и возможностями, доступ-
ными ресурсами и сложившейся ситуацией [Kerth2001] (гл. 1).
Вдобавок подумайте о том, чтобы установить правило Вегаса: все, что сказано на
сессии анализа, остается на сессии анализа. Не записывайте ее и попросите участ-
ников согласиться на нераспространение никаких личных подробностей, которыми
люди будут делиться во время сессии.
Если в сессии участвуют люди, не состоящие в вашей команде, или если ваша
команда только начинает работать вместе, то вы также можете заключить рабочие
соглашения на время сессии. (См. пункт «Создайте рабочие соглашения» главы 7.)
2. Собрать данные
Как только условия будут подготовлены, ваш следующий шаг — понять, что случи-
лось. Вы делаете это с помощью создания визуальной хронологии событий с ком-
ментариями.
На данной стадии люди будут испы-
тывать соблазн начать интерпретировать Сосредоточьтесь на фактах,
данные, но важно, чтобы все оставались а не на интерпретациях.
сконцентрированы «только на фактах».
Возможно, понадобится множество раз напомнить об этом по мере продвижения по
данной стадии. Очень легко увлечься и начать задним числом критиковать действия
людей, но это не поможет. Успешный анализ фокусируется на понимании того, что
люди действительно сделали и какой вклад в их действия внесла ваша система раз-
работки, а не на том, что они могли бы сделать по-другому.
Чтобы создать временну́ю шкалу, начните с организации длинного горизонталь-
ного пространства на вашей виртуальной доске. Если вы проводите очную сессию,
то наклеивайте голубую клейкую ленту на большой участок стены. Разделите шкалу
на столбцы, представляющие разные периоды времени. Столбцы не обязательно
должны быть равномерными; недели или месяцы часто больше подходят для начала
шкалы, а для моментов, предшествующих инциденту, возможно, лучше использовать
часы или дни.
Предложите участникам провести одновременный мозговой штурм, чтобы по-
думать о событиях, имеющих отношение к инциденту. (См. пункт «Работайте одно-
временно» главы 7.) События — это фактические безоценочные заявления о чем-то,
что произошло, например: «Скрипт развертывания останавливает все экземпляры
ServiceGamma», «ServiceBeta возвращает код ответа 418», «ServiceAlpha не распоз-
нает код ответа 418 и дает сбой», «Дежурный инженер получает сообщение о сбое
системы» и «Дежурный инженер вручную перезапускает экземпляры ServiceGamma».
(Вы можете использовать имена участвовавших людей, но только если они при этом
присутствуют и согласны.) Постарайтесь также охватить события, которые прошли
хорошо, а не только те, которые прошли плохо.
Программные журналы, записи реагирования на инциденты и история контроля
версий могут быть для вас источниками вдохновения. Запишите каждое событие
на отдельном стикере и прикрепите его на доску. Для всех событий используйте
стикеры одного цвета.
После этого предложите всем сделать шаг назад и взглянуть на картину в целом.
Каких событий не хватает? Работая одновременно, посмотрите на каждое событие
и спросите: «Что было перед этим? Что было после?» Каждое дополнительное со-
бытие добавляйте в виде еще одного стикера. Вы можете посчитать полезным по-
казать взаимоотношения «до/после» с помощью стрелок.
Не забудьте включить события с участием
людей, а не только ПО. Решения людей — важней-
ший фактор в вашей системе разработки. Найдите Как использовалась
автоматизация? Настроена?
каждое событие, в котором задействована авто-
Запрограммирована?
матизация, контролируемая или используемая
вашей командой, затем добавьте предыдущие
события, показывающие, какой вклад в то событие внесли люди. Как использовалась
автоматизация? Настроена? Запрограммирована? Не забудьте излагать события
нейтральным тоном, без обвинений. Не гадайте, что люди должны были сделать;
записывайте только то, что они на самом деле сделали.
Например, событию «Скрипт развертывания останавливает все экземпляры
ServiceGamma» могло предшествовать «Оператор сделал опечатку в параметре
командной строки --tagre вместо --target» и «Инженер ошибочно изменяет скрипт
развертывания, чтобы остановить все экземпляры, когда параметр --target не обнару-
жен», которому, в свою очередь, предшествовало событие «Команда решает очистить
обработку командной строки скрипта развертывания».
Событиям могут предшествовать несколько других, связанных с одним и тем же
событием. Каждое предшествующее событие может произойти в разных точках
временной шкалы. Например, событию «ServiceAlpha не распознает код ответа 418
и дает сбой» могли предшествовать три: «ServiceBeta возвращает код ответа 418»
(непосредственно перед); «Инженер ошибочно отключает обработчик исключений
верхнего уровня ServiceAlpha» (несколькими месяцами ранее); и «Инженер про-
граммирует ServiceAlpha для выдачи исключения при получении неожиданного
кода ответа» (год назад).
Когда события добавлены, предложите участникам поделиться своими воспо-
минаниями и эмоциями на тот момент. Не просите людей оправдать свои действия;
вы здесь не для того, чтобы найти виноватых. Попросите их объяснить, каково это
было, находиться там, в тот момент, когда событие произошло. Это поможет вашей
команде понять социальные и организационные аспекты вашей системы разработ-
ки — не только какие решения были приняты, но и почему.
Попросите участников добавить дополнительные стикеры, другого цвета, для
этих мыслей. Например, если Джарретт сказал: «Я беспокоился о качестве кода, но
чувствовал, что нужно спешить, чтобы уложиться в срок», — то мог бы написать два
стикера: «Джарретт обеспокоен качеством кода» и «Джарретт чувствует, что нужно
спешить, чтобы уложиться в срок». Не угадывайте мысли тех людей, кто не присут-
ствует, но вы можете записать то, что они говорили в тот момент, например: «Лейла
говорит, что ей трудно запомнить параметры скрипта развертывания».
Сосредоточьтесь на том, что люди чувствовали и думали в тот момент. Ваша
цель — понять систему такой, какой она была на самом деле, а не критиковать людей
задним числом.
В конце попросите участников выделить в хронологии важные события — те,
которые кажутся наиболее относящимися к инциденту. Еще раз удостоверьтесь, что
люди запечатлели все свои воспоминания о тех событиях.
3. Генерировать идеи
Теперь пришло время превратить факты в идеи. На этой стадии вы будете изучать
временную шкалу на предмет подсказок о своей системе разработки. Прежде чем
начать, дайте людям немного времени на изучение доски. В этот момент можно
сделать перерыв.
Начните с напоминания участникам
о природе сбоев. Проблемы возникают все События не причина неудачи;
гда, но обычно не соединяются таким об- они являются симптомом того, как
разом, чтобы приводить к серьезному сбою. функционирует ваша система.
События в вашей хронологии не причина
неудачи, они являются симптомом того, как функционирует ваша система разработки.
Это именно та, более глубокая система, которую вы хотите анализировать.
Взгляните на события, которые вы определили как важные во время стадии сбора
данных. В каких из них фигурируют люди? Продолжая предыдущий пример, вы бы
выбрали события «Оператор сделал опечатку в параметре командной строки --tagre
вместо --target» и «Инженер ошибочно изменяет скрипт развертывания, чтобы
остановить все экземпляры, когда параметр --target не обнаружен», а не «Скрипт
развертывания останавливает все экземпляры ServiceGamma», поскольку это со-
бытие случилось автоматически.
Работая одновременно, присвойте каждому из событий с участием людей одну или
несколько следующих категорий1. Запишите каждую категорию на стикер третьего
цвета и добавьте его на доску.
zz В категорию «Модели знаний и ментальные модели» входит информация и реше-
ния внутри команды, вовлеченной в событие. Например, уверенность в том, что
сервис, поддерживаемый командой, никогда не возвратит ответ 418.
zz В категорию «Коммуникация и обратная связь» входит информация и решения
снаружи команды, вовлеченной в событие. Например, уверенность в том, что
сторонний сервис никогда не возвратит ответ 418.
zz Категория «Внимание» включает в себя возможность сосредоточиться на актуаль-
ной информации. Например, игнорирование аварийного оповещения из-за того,
что в тот же самый момент пришли несколько других оповещений, или неверное
понимание важности оповещения вследствие усталости.
1
Идеи категорий событий почерпнуты из [Woods2010] и [Dekker2014].
zz В категорию «Фиксация и продолжение плана» можно отнести упорство в оценке

ситуации, несмотря на наличие новой информации. Например, когда во время
аварийной ситуации продолжают устранять неполадки в проблемном маршру-
тизаторе после того, как журнал событий показывает, что трафик успешно пере-
веден на резервный маршрутизатор. Сюда же входит продолжение выполнения
установленного плана; например, релиз в запланированную дату, несмотря на то
что бета-тестировщики говорят, что ПО не готово.
zz В категорию «Конфликтующие цели» попадает выбор между несколькими целями,
некоторые из них могут быть негласными. Например, решение присвоить соблю-
дению дедлайна больший приоритет, чем повышению качества кода.
zz В категорию «Процедурная адаптация» входят случаи, в которых установленные
процедуры не соответствуют ситуации. Например, отказ от чек-листа после того,
как один из шагов сообщает об ошибке. Особый случай — двойная ловушка от-
ветственности и полномочий, которая требует, чтобы люди делали выбор — быть
наказанными за несоблюдение процедуры или следовать процедуре, которая
не соответствует ситуации.
zz Категория «Пользовательский опыт» подразумевает взаимодействие с компью-
терными интерфейсами. Например, введение неверного параметра командной
строки в программу.
zz Категория «Персональная» — вы можете создать собственную категорию, если
событие не соответствует ни одной из предложенных мною.
Эти категории применимы и к позитивным событиям. Например, «Инженер про-
граммирует бэкенд на предоставление безопасного значения по умолчанию, когда
время ожидания ServiceOmega истечет» — это событие категории «Модели знаний
и ментальные модели».
После того как вы распределили все события по категориям, найдите время, что-
бы опять рассмотреть всю картину в целом, затем разбейтесь на маленькие группы
и обсудите каждое событие. Что каждое из них говорит о вашей системе разработки?
Сосредоточьтесь на системе, а не на людях.
Например, событие «Инженер ошибочно изменяет скрипт развертывания, чтобы
остановить все экземпляры, когда параметр --target не обнаружен» звучит как ошиб-
ка со стороны инженера. Но хронология показывает, что Джарретт, упомянутый
инженер, чувствовал, что должен торопиться, чтобы уложиться в срок, хотя это
и снижало качество кода. Это значит, что это было событие категории «Конфликту-
ющие цели» и на самом деле оно говорит о том, как принимаются решения и рас-
пространяется информация о приоритетах. В ходе обсуждения события члены ко-
манды осознают, что они все испытывают давление со стороны отдела продаж
и маркетинга, заставляющего присваивать срокам более высокий приоритет, чем
качеству кода.
С другой стороны, предположим, что
анализ хронологии выявил, что Джарретт При анализе инцидента всегда
также неверно понял поведение библиоте- рассматривается система,
ки обработки командной строки команды. а не отдельные люди.
Как следствие, это событие можно было бы
переместить в категорию «Модели знаний и ментальные модели», но даже тогда вы

не обвинили бы Джарретта. При анализе инцидента всегда рассматривается систе-
ма, а не отдельные люди. Предполагается, что люди могут делать ошибки. В этом
случае при более пристальном изучении события обнаруживается, что команда ис-
пользовала разработку через тестирование и парное программирование для рабочего
кода, однако не применяла эти стандарты для своих скриптов. У команды не было
никакого способа предотвратить ошибку в своих скриптах, и ее появление было
всего лишь вопросом времени.
После сессии группы должны иметь возможность обсудить события. (Чтобы
ускорить процесс, вы можете распределить события между группами, вместо того
чтобы обсуждать в каждой группе все события целиком.) Соберитесь вместе и об-
судите, что вы узнали о системе. Запишите каждый вывод на отдельный стикер
четвертого цвета и поместите его на временную шкалу, рядом с соответствующим
событием. Пока не вносите предложения, просто сосредоточьтесь на том, что вы
узнали. Например, «Нет системного способа, позволяющего предотвратить ошибки
программирования в скриптах», «Инженеры чувствуют, что на них давят, чтобы они
жертвовали качеством кода» и «Скрипту развертывания требуется длинная и под-
верженная ошибкам командная строка».
4. Решить, что делать

Вы готовы решить, как улучшить вашу систему разработки. Вы это делаете, собрав
идеи с помощью мозгового штурма, а потом выбираете несколько лучших вариантов.
Снова начните с просмотра общей хронологии. Что вы можете изменить, чтобы
сделать систему более устойчивой? Рассмотрите все возможности, не беспокоясь об
их осуществимости. Проведите одновременный мозговой штурм и занесите резуль-
таты в таблицу или новую область вашей виртуальной белой доски. Вам не нужно
сопоставлять свои идеи с конкретными событиями или вопросами. Некоторые будут
решать несколько задач одновременно. Вопросы к рассмотрению могут быть такими1.
zz Как мы могли предотвратить этот вид сбоя?
zz Как мы могли раньше обнаружить этот вид сбоя?
zz Как мы могли потерпеть неудачу быстрее?
zz Как мы могли снизить ее воздействие?
zz Как мы могли среагировать быстрее?
zz Где нас подвела наша сетка безопасности?
zz Какие сопутствующие недостатки мы должны исследовать?
Продолжим предыдущий пример. По результатам мозгового штурма ваша ко-
манда могла предложить следующие идеи: «перестать соглашаться на соблюдение
сроков», «обновлять прогноз еженедельно и удалять истории, которые не укладыва-
ются в сроки», «применять стандарты производственного кодирования к скриптам»,
«выполнять ревью существующих скриптов для поиска ошибок кода», «упростить
командную строку скрипта развертывания» и «выполнять ревью UX и параметров
1
Спасибо Саре Хоран Ван Трис, предложившей большинство из этих вопросов.
командной строки всех скриптов команды». Одни из этих идей лучше, чем другие,
но на этой стадии вы генерируете идеи, а не фильтруете их.
Как только у вас будет набор параметров, сгруппируйте их в круги «контроль»,
«влияние» и «суп» в зависимости от способности вашей команды влиять на их по-
явление, как описано в подразделе «Круги и суп» главы 11. Вкратце обсудите все за
и против каждого параметра. Затем решите, каким параметрам ваша команда будет
следовать, используя точечное голосование, затем единогласное голосование (см.
пункты «Работайте одновременно» и «Стремитесь к согласию» главы 7). Вы можете
выбрать несколько параметров.
Когда будете думать, что выбрать, помните, что вы не должны исправлять все.
Иногда изменение более рискованно или затратно, чем те недостатки, которые оно
исправляет. Кроме того, хотя каждое событие — это информация о поведении вашей
системы разработки, не всякое событие является чем-то плохим. Например, одно из
событий в примере было «Инженер программирует ServiceAlpha на выдачу исклю-
чения при получении неожиданного кода ответа». Хотя это событие напрямую вело
к аварии, оно ускорило и упростило диагностику сбоя. Без него что-то все равно бы
могло пойти не так, а на решение проблемы ушло бы больше времени.
Предотвращение сбоя
Если вы раздумываете о вариантах того, что ваша команда может сделать, то по-
думайте о способах изменить ваш код или дизайн таким образом, чтобы сделать
ошибки невозможными. Например, представьте, что вы обнаружили потерю
данных в текстовом поле. Люди могли ввести 500 символов, но только первые
250 сохранялись в базе данных. Отчасти причина была в том, что фронтенд был
случайно настроен на неверную длину. Вы могли сделать эту ошибку невозмож-
ной, автоматически подтягивая длину из метаданных бэкенда.
Когда вы не можете сделать ошибку невозможной, попробуйте обнаруживать
их автоматически, обычно усовершенствовав вашу сборку или набор тестов.
Например, вы можете написать тест, просматривающий все шаблоны фронтенда
и проверяющий и сравнивающий длины полей с базой данных.
Не останавливайтесь непосредственно на данной ошибке. Подумайте о том, что
она говорит о системе разработки вашей команды. Например, еще одна причина
потери данных была в том, что бэкенд не проверял длины полей. Не значит ли
это, что есть проблема с проверкой полей в целом? Некоторые из ваших вари-
антов могут подразумевать дальнейшее изучение, например исследовательское
тестирование, предназначенное для углубленной проверки данных.
5. Завершить ретроспективу
Анализ инцидента может быть напряженным. Завершая ретроспективу, дайте людям
возможность сделать вдох и плавно вернуться к своей повседневной работе. Этот
вдох может быть метафорическим, или вы можете буквально предложить, чтобы
люди встали и сделали глубокий вдох.
Начните с решения о том, что оставить. Снимок экрана или фото временной
шкалы с комментариями и другие артефакты, вероятно, пригодятся вам в будущем.
Сначала пригласите участников взглянуть на шкалу, чтобы выяснить, нет ли там
чего-либо, что они не хотели бы выносить за пределы сессии. Уберите эти стикеры,
прежде чем делать фото.
Далее решите, кто и как будет отслеживать принятые решения. Если ваша команда
будет готовить отчет, то решите, кто будет участвовать в его написании.
В конце завершите сессию, выразив признательность друг другу за трудную
работу1. Объясните упражнение и приведите пример: «(Имя), я признателен тебе
за (причина)». Сядьте и подождите. Другие тоже должны высказаться. Говорить
необязательно, но оставьте в конце ретроспективы достаточно времени (минуту
или около того тишины), поскольку людям может потребоваться некоторое время,
чтобы высказаться.
Некоторые считают упражнение «Признательность» некомфортным для себя.
В качестве альтернативы каждый участник может по очереди сказать несколько слов
о том, что он или она чувствуют теперь, когда анализ завершен. Это можно пропустить.
В завершение поблагодарите каждого за участие. Напомните им о правиле Вегаса
(не делиться личными подробностями без разрешения) и закончите на этом.
Обучение организации
Организации часто требуют отчет о выводах, сделанных в ходе анализа инцидентов.
Он обычно называется постмортем-отчетом, но я предпочитаю более нейтральный
термин «отчет об инциденте».
В теории отчасти цель этого отчета об инциденте — дать другим командам воз-
можность использовать то, чему вы научились, для совершенствования их системы
разработки. К сожалению, люди склонны игнорировать уроки, полученные другими
командами. Это называется дистанцированием через дифференцирование (distancing
through differencing) [Woods2010] (гл. 14). «Эти идеи не применимы к нам, поскольку
мы — команда, ориентированная на внутренние задачи, а не на внешние», или «У нас
микросервисы, а не монолит», или «Мы работаем удаленно, а не в офисе». Поверх-
ностные различия легко использовать как причину, позволяющую уклониться от
изменений.
Предотвращение этого дистанцирования — вопрос организационной культуры,
что выходит за рамки этой книги. Однако, если говорить коротко, люди больше всего
жаждут учиться и меняться после крупного сбоя. Кроме этого, я добивался макси-
мального успеха, сделав уроки персональными. Покажите, как эти уроки влияют на
то, что беспокоит вашу аудиторию.
Это легче сделать в форме разговора, чем письменного документа. На практике,
я подозреваю (но наверняка не знаю!), наиболее эффективный способ заставить
людей прочитать уроки из отчета об инциденте и применить их — рассказать захва-
тывающую, но короткую историю. Разъясните с самого начала, что поставлено на
карту. Опишите, что случилось, и позвольте интриге раскрыться. Опишите, что вы
1
Упражнение «Признательность» основано на [Derby2006] (гл. 8).
узнали о своей системе, и объясните, как это влияет на другие команды. Опишите
потенциальные ставки для других команд и кратко изложите, что они могут сделать,
чтобы защитить себя.
Ответственность за инциденты
Еще одна причина, почему организации хотят получить отчет об инциденте, — «при-
влечь людей к ответственности». Это в лучшем случае ошибочно.
Я не говорю, что команды не должны быть ответственными за свою работу. Долж-
ны! Анализируя инцидент и работая над улучшением своей системы разработки,
в том числе взаимодействуя с остальной частью организации в целях внедрения
изменений, они и демонстрируют свою ответственность.
Поиск виноватого (single, wringable neck в неверно понимаемой терминологии
Scrum) только поощряет уклонение от ответственности и перекладывание ее на дру-
гих. Количество зарегистрированных инцидентов может снизиться, но только потому,
что люди будут скрывать проблемы. Серьезные проблемы будут лишь ухудшаться.
«Когда количество инцидентов снижается,
уровень смертности возрастает», сообщается
Поиски виноватого только
в The Field Guide to Understanding ‘Human Error’,
ухудшат серьезные инциденты.
когда речь заходит о строительстве и авиации.
«Это поддерживает важность… извлечения уро-
ков из почти аварийных ситуаций. Отказ от таких возможностей обучения на любом
уровне и любыми средствами не просто плохая идея. Это опасно» [Dekker2014] (гл. 7).
Если ваша организация понимает эту динамику и действительно хочет, чтобы
команда показала свою ответственность, то вы можете поделиться результатами,
выявленными при анализе инцидента и имеющими отношение к вашей системе раз-
работки. (Другими словами, последними стикерами стадии «Генерировать идеи».)
Вы также можете поделиться тем, что решили сделать, чтобы улучшить надежность
вашей системы разработки.
Часто организации имеют готовый шаблон отчета, который вам нужно будет ис-
пользовать. Сделайте все возможное, чтобы избежать упрощенного, причинно-след-
ственного изображения ситуации, и будьте осторожны, постарайтесь показать, как
система, а не отдельные лица позволила проблемам превратиться в критический сбой.
Вопросы
Что, если у нас нет времени, чтобы делать полный анализ каждого бага и инцидента?
Анализ инцидента необязательно должен быть формальной ретроспективой.
Вы можете использовать простую структуру, чтобы исследовать возможности нефор-
мально, с участием всего нескольких людей или даже уделив всего несколько минут
в своих мыслях. Есть основной момент, который надо запомнить: события — это
симптомы функционирования вашей базовой системы разработки. Они являются
подсказками, которые покажут вам, как работает эта система. Начните с фактов,
обсудите, как они меняют ваше понимание системы разработки, и только тогда по-
думайте, что поменять.
Успех анализа инцидентов зависит от психологи-
ческой безопасности. Если участники не чувствуют См. также
себя в безопасности настолько, чтобы поделиться
своим взглядом на случившееся как есть, без при- Безопасность (глава 7)
крас, то вам будет трудно достичь углубленного
понимания вашей системы разработки.
Более широкий организационный подход к инцидентам оказывает большое
влияние на безопасность участников. Даже компаниям, которые на словах под-
держивают «постмортем-обсуждения без обвинений», трудно перейти с упро-
щенного причинно-следственного мировоззрения на системное. Они склонны
думать, что «без обвинений» — это «не говорить, кто виноват», но чтобы быть
действительно организацией «без обвинений», они должны понимать, что никто
не виноват. Неудачи и успехи — следствия работы сложной системы, а не действий
отдельных лиц.
Вы можете проводить успешный анализ инцидентов в организациях, которые
не понимают этого, но вам понадобится быть вдвойне осторожными, устанавливая
базовые правила в части психологической безопасности, и предстоит сделать так,
чтобы в анализе не участвовали люди, имеющие мировоззрение, ориентированное
на обвинения. Вам нужно позаботиться и о том, чтобы отчет об инциденте, если он
будет, был написан с системной точки зрения, а не причинно-следственной.
Когда вы хорошо проводите анализ инцидентов:
zz инциденты признаются, и анализируются даже те инциденты, которые не имеют
заметных последствий;
zz члены команды видят, что инциденты — это способ учиться и совершенствоваться,
и даже рассчитывают на них;
zz надежность и устойчивость вашей системы со временем улучшаются, приводя
в результате к меньшему количеству скрытых дефектов и сбоев в эксплуатаци-
онной среде;
zz никого не обвиняют, не судят и не наказывают за инциденты.
Многие организации смотрят на анализ инцидентов сквозь линзы шаблона стандарт-
ного отчета. Это может приводить к поверхностным «заплаткам», а не к системному
взгляду, поскольку люди фокусируются на том, что хотят включить в отчет, а не на
исследовании самого инцидента. Формат, который я описал, поможет людям рас-
ширить свою точку зрения, прежде чем приходить к каким-либо заключениям. Про-
ведение его как ретроспективы также гарантирует, что каждый голос будет услышан
и вся команда согласится с выводами.
Многие идеи в этой практике вдохновлены книгами, освещающими темы из об-

ласти человеческого фактора и системной безопасности. Эти книги касаются вопро-
сов жизни и смерти, решения по которым часто принимаются в условиях сильного
дефицита времени в таких сферах, как, например, авиация. Программная разработка
связана с другими ограничениями, и некоторые из упомянутых идей могут оказаться
совершенно неприменимыми.
В частности, предложенные мною категории событий, вероятно, можно улучшить.
Я подозреваю, что есть возможность разбить категорию «Модели знаний и менталь-
ные модели» на несколько. Однако не добавляйте категории произвольно. Посмо-
трите раздел литературы для дополнительного чтения и сначала обучитесь основам.
Формат ретроспективы, который я предложил, дает больше всего возможностей
для экспериментов. Во время анализа инцидента легко зациклиться на решениях
или упрощенном причинно-следственном мышлении, а предложенный мною формат
разработан так, чтобы избежать данной ошибки. Но это лишь ретроспектива. Ее мож-
но изменить. Проведя несколько анализов с использованием предложенного мною
формата, посмотрите, что можно улучшить, экспериментируя с новыми действиями.
Например, можете ли вы провести части стадии «Собрать информацию» асинхронно?
Существуют ли более эффективные способы анализа хронологии во время стадии
«Генерировать идеи»? Можете ли вы предоставить больше структурных элементов
на стадии «Решить, что делать»?
И наконец, анализ инцидентов не ограничивается анализом сбоев. Вы можете
анализировать успехи. Изучая вашу систему разработки, вы получаете такую же
пользу. Попробуйте провести анализ того момента, когда команда добилась успе-
ха под давлением. Найдите события, которые могли привести к сбою, и события,
которые воспрепятствовали его возникновению. Узнайте, что это говорит вам об
отказоустойчивости вашей системы, и подумайте о том, как вы можете усилить этот
вид устойчивости в будущем.

The Field Guide to Understanding ‘Human Error’ [Dekker2014] удивительно легко чита-
ется и представляет собой отличное введение в теорию, лежащую в основе большей
части практики «Анализ инцидентов».
Behind Human Error [Woods2010] читать гораздо труднее, но в этой книге описы-
вается больше основ, чем в The Field Guide. Если вы ищете больше информации, то
прочитайте данную книгу.
Предыдущие две книги основаны на исследовании человеческого фактора и си-
стемной безопасности. Сайт learningfromincidents.io посвящен тому, как внедрить эти
идеи в программную разработку. На момент написания данной книги он содержит
довольно мало информации, но суть его верная. Я привожу его в надежде, что на
момент, когда вы будете это читать, он будет содержать больше материалов.
IV
ОПТИМИЗАЦИЯ
РЕЗУЛЬТАТОВ
Снова октябрь. В прошлом году ваша команда достигла свободного владения навы-
ками на уровне поставки (см. часть III). В то время некоторые члены команды также
хотели достичь навыков на уровне оптимизации, но руководство отнеслось к этому
скептически. Вы не смогли получить нужной вам поддержки.
Однако с тех пор как вы достигли навыков на уровне поставки, ваша команда ра-
ботает на полную мощность. Производительность значительно выросла, количество
дефектов сократилось. Ханне, вашему продакт-менеджеру, было трудно успевать за
всем. Она делегировала все больше и больше обязанностей команде, которая отлично
со всем справлялась.
Это заметили. Ханна расхваливала вас директору по маркетингу, а ваш босс го-
ворил о вас с техническим директором. Настал подходящий момент для еще одной
попытки достичь навыков на уровне оптимизации. На сей раз это сработало. Ханна
была назначена в вашу команду на полный день. И это не все: она получила разре-
шение на «эксперимент c Agile».
«Эксперимент c Agile» — это то, как они называют способ, с помощью которого
Ханна работает с вашей командой. Вместо того чтобы заниматься ежегодным плани-
рованием, как остальные специалисты отдела маркетинга, она получила разрешение
распоряжаться финансами вашей команды. Она регулярно встречается со своим
боссом, чтобы поделиться статистикой, такой как выручка и удержание заказчиков,
и постоянно пробует новые идеи и эксперименты. (Ее коллеги ревнуют. Они все
еще должны каждый год проходить через шестинедельный ад постановки целей
и планирования бюджета.)
И Ханна не одна. Активно участвует вся команда. Ханна первая среди равных,
но когда дело доходит до экспертных знаний в области маркетинга продукта, другие
602 Часть IV. Оптимизация результатов
члены команды развивают собственные экспертные знания. В частности, Шайна

любит посещать площадки заказчика, чтобы посмотреть, как работают люди.
Шайна только что попросила внимания команды. «Я только что завершила
виртуальную сессию с Магдой, — говорит она. — Вы все помните Магду, да?» Все
кивают. Магда — это разработчик, которая работает на одного из ваших новых за-
казчиков. Ее компания крупнее, чем ваши обычные заказчики, так что они довольно
требовательны.
«Компания Магды имеет дело со все более сложной налоговой ситуацией, — про-
должает Шайна. — Количество их удаленных сотрудников во все большем количестве
стран по всему миру постоянно растет, и работа с разными налоговыми и трудовы-
ми законодательствами весьма утомительна. Магда возглавляет команду, которая
должна автоматизировать часть этой работы, и хотела узнать, как интегрироваться
с нашим API».
«Но это заставило меня задуматься, — голос Шайны взволнованно повышается. —
Мы уже делаем нечто подобное. Что, если нам продать дополнительный модуль
для международного трудоустройства? Это требует много работы, но мы могли бы
начать с одной компании за раз. И Бо, у тебя есть некоторый опыт в этом, правда?»
Бо задумчиво кивает.
Ханна поджимает губы. «Это крупная ставка, — говорит она. — Но она могла бы
принести огромный выигрыш. Это может открыть рынок для большего количе-
ства компаний, подобных компании Магды. Это определенно повысило бы наши
конкурентные преимущества. Ни у кого из наших прямых конкурентов нет ничего
подобного, и крупные игроки выставляют очень большую плату за профессиональ-
ные услуги. Вдобавок мы гораздо более дружественны для пользователей», — Шай-
на широко улыбается. — Мы бы оценивали совсем в небольшую сумму. Что думают
все остальные?»
Команда быстро обсуждает идею. Когда вы приходите к согласию, что это стоит
того, чтобы попробовать, Ханна резко кивает. «Мне нравится. Нам понадобится про-
верить рынок и разобраться, как разбить процесс на более мелкие ставки. Я добавлю
историю в план следующей недели, чтобы выполнить эксперимент “Создать — из-
мерить — узнать”. Мы можем начать его после релиза нашего текущего инкремента.
Тем временем я проведу небольшое исследование и расскажу об этом боссу. Если
эксперимент сработает, то нам понадобится получить от нее одобрение на дополни-
тельное финансирование и изменение нашей миссии».
«Спасибо, Шайна, — заканчивает Ханна. — Вот именно потому мне нравится
быть частью этой команды».
ДОБРО ПОЖАЛОВАТЬ В ОБЛАСТЬ ОПТИМИЗАЦИИ

Область оптимизации — для тех команд,
которые хотят создавать больше ценности. Область оптимизации —
Они берут на себя ответственность за свои для команд, которые хотят
производственные планы и бюджет, поэто- создавать больше ценности.
му могут экспериментировать, выполнять
Часть IV. Оптимизация результатов 603
итерации и учиться. Это позволяет им производить ПО, которое лидирует на рынке.

Команды, компетентные в оптимизации1:
zz поставляют продукты, которые отвечают целям бизнеса и потребностям рынка
(команды, компетентные в других областях, поставляют то, что их попросили
поставить, что не всегда одно и то же);
zz обладают обширным опытом, который способствует принятию решений, опти-
мальных с точки зрения соотношения «затраты/ценность»;
zz понимают место своих продуктов на рынке и то, как они будут улучшать их по-
зицию;
zz координируются с руководством, чтобы на ранней стадии отменить продукты,
имеющие низкую ценность, или изменить их направление;
zz учатся на основе обратной связи, полученной от представителей рынка, чтобы
предвидеть потребности заказчика и создавать новые бизнес-возможности;
zz принимают бизнес-решения быстро и эффективно.
Чтобы достичь этих преимуществ, командам нужно развить навыки, указанные
ниже. Это требует инвестиций, описанных в главе 4.
Команда отвечает на потребности бизнеса:
zz описывает свои планы и прогресс в терминах бизнес-показателей, определенных
совместно с руководством;
zz взаимодействует с внутренними и внешними стейкхолдерами, чтобы определить,
когда и как дорожные карты обеспечат наилучший возврат инвестиций.
Команда работает как вызывающая доверие автономная команда:
zz координируется с руководством, чтобы понять и уточнить свою роль в достижении
общей бизнес-стратегии организации;
zz члены команды совместно берут на себя ответственность за выполнение работы
и достижение бизнес-результатов, которые они определили;
zz руководство дает команде ресурсы и полномочия, которые позволяют ей авто-
номно достичь ее бизнес-результатов;
zz руководство следит за тем, чтобы в команду входили постоянные члены, облада-
ющие всеми повседневными навыками, которые нужны команде для понимания
рынка и достижения ее бизнес-результатов.
Команда стремится к совершенству своего продукта:
zz взаимодействует со своими заказчиками и рынком, чтобы понимать потребности
и возможности продукта;
zz разрабатывает гипотезы о коммерческих возможностях и проводит эксперименты,
чтобы их протестировать;
zz планирует и развивает свою работу таким способом, который позволяет ей пол
ностью менять планы, избегая потерь, с уведомлением менее чем за месяц.
1
Эти перечни взяты из [Shore2018b].
ДОСТИЖЕНИЕ НАВЫКОВ
НА УРОВНЕ ОПТИМИЗАЦИИ
Инвестиции, позволяющие достичь навыков на уровне оптимизации, испытывают на
прочность предрассудки и установленный порядок большинства компаний. Требуется
отказаться от значительной части контроля и больше доверять команде. Некоторый
надзор остается, но все равно это может пугать.
В результате вам обычно приходится в течение нескольких лет демонстрировать
успех в навыках на уровнях фокусировки и поставки, прежде чем ваша компания
предоставит вам полномочия и автономность, которые позволяют достичь навыков
на уровне оптимизации. Стартапы на раннем этапе, как правило, являются исклю-
чением, но всем остальным понадобится поработать над выстраиванием доверия.
К моменту, когда вы будете готовы к оптимизации, ваша команда, вероятно,
овладеет остальными практиками, представленными в этой книге. Вам больше не по-
надобится руководство в стиле «как это делать». Вы уже овладеете мастерством.
Поэтому главы в данной части короткие и легкие. Они помогут вам начать работу
и подскажут, что делать дальше. Ваша задача — взять то, что вы узнали о разработке
Agile, объединить с этими идеями и самостоятельно создать что-то великое.
Эти главы помогут вам начать работу:
zz в главе 17 обсуждается сущность автономных команд;
zz в главе 18 описаны способы, которые позволяют вашей команде учиться;
zz в главе 19 книга завершается рассказом о том, что будет дальше.
ГЛАВА 17
Автономность
Свободное владение навыками на уровне оптимизации встречается довольно редко,

но не потому, что эта область подразумевает большие изменения в практиках Agile.
Напротив: оптимизация в основном — это применение практик, описываемых во
всех предыдущих частях книги. Навыки на уровне оптимизации являются редкостью
не из-за трудности, она — редкость, потому что требует такого уровня автономности
команды, какой большинство организаций не готовы поддерживать.
Все знают, что команды Agile должны
быть автономны, но организации с коман-
дами оптимизации — действительно такие. Оптимизация требует такого уровня
Для них автономность — это больше чем автономности команды, какой
большинство организаций не готовы
просто дать возможность командам работать поддерживать.
самостоятельно. Они дают своим командам
полную ответственность за их финансы
и также производственные планы.
ЭКСПЕРТНЫЕ ЗНАНИЯ В ОБЛАСТИ ЗАКАЗЧИКА

Конечно, для того чтобы ваша команда мог-
ла управлять своими финансовыми и про- См. также
изводственными решениями, она должна
обладать способностью принимать хорошие
решения. Общей целью всегда является ко-
манда, имеющая глубокие знания как в предметной области заказчика, так и в сфере
разработки, но многие организации недоукомплектовывают ту часть своих команд,
которая имеет отношение к бизнесу. Они назначают продакт-менеджера, который
может участвовать в работе команды лишь несколько часов в неделю, или назначают
«владельцев» продукта, не имеющих реальных полномочий для принятия решений.
Некоторым командам приходится иметь дело с худшей комбинацией обоих этих
вариантов: владельцы продукта, которые берутся за все сразу и не имеют права
принимать решения.
Команды оптимизации имеют реальные бизнес-полномочия и экспертные знания.
Все это также не закрепляется за одним человеком. Каждый в команде проявляет
интерес к производству ценности. Некоторые больше, чем другие, конечно, но ревни-

вое стремление к единоличной ответственности отсутствует. Вы получаете лучшие
результаты, когда вся ваша команда целиком видит свою задачу в том, чтобы искать
способы предоставления лучшего сервиса заказчикам, пользователям и стейк
холдерам.
БИЗНЕС-РЕШЕНИЯ
Одна из самых потрясающих черт команд оптимизации — отсутствие акцента на
пользовательских историях. Конечно, у них есть истории как механизм планирова-
ния, но они не являются темой разговоров со стейкхолдерами. Вместо этого коман-
ды сосредоточиваются на бизнес-результатах и ценности. Они не пытаются поставить
набор историй; это детали. Они пытаются добиться значимых изменений в своей
организации.
Особенно ярко это проявляется в отно-
шениях команд оптимизации с руковод- См. также
ством. Они пользуются доверием своей ор-
ганизации. Руководство высшего уровня Доверие стейкхолдеров (глава 10)
и непосредственные руководители знают,
что могут дать команде финансирование и миссию и далее не вмешиваться в ее ра-
боту. Команда самостоятельно решит, как выполнить миссию. Команда проинфор-
мирует руководство о том, как тратятся финансы, какие результаты достигаются
и какая поддержка ей нужна, чтобы быть более успешной.
Одним из последствий данного подхода
является то, что команды оптимизации ред- См. также
ко следуют предварительно составленному
плану. Как правило, их ценные инкременты Адаптивное планирование (глава 8)
маленькие, их планы в высшей степени адап-
тивны, и их горизонты планирования короткие. Вместо того чтобы работать в со-
ответствии с большим статичным планом, команды постоянно тестируют идеи
и демонстрируют инкрементный прогресс. (По крайней мере, с точки зрения вну-
тренних стейкхолдеров. При этом они все еще могут откладывать работу на потом,
до выхода большого релиза.)
В результате команды оптимизации, как
правило, не имеют традиционных дедлай- См. также
нов или дорожных карт. Они сами выби-
Прогнозирование (глава 10)
рают, когда устанавливать дедлайн. Они
делают это потому, что есть убедительная
бизнес-причина, например координация с работой отдела маркетинга, а не для того,
чтобы удовлетворить бюрократические требования. Если команды осознают, что
не могут уложиться в установленный срок, то сами решают, как и когда изменить
свои планы.
Глава 17. Автономность 607
ОТВЕТСТВЕННОСТЬ И НАДЗОР
Команды оптимизации не лишены надзора. Они могут контролировать свой бюджет
и планы, но это не значит, что им можно делать все, что захочется. Они все еще долж-
ны показывать свою работу и обосновывать свои масштабные решения. Им просто
не нужно получать предварительное одобрение своих решений, пока те соответству-
ют цели команды и не требуют дополнительных ресурсов от организации.
Организация использует командную цель, чтобы направить работу команды в нуж-
ное русло. Цель команды определяет общее направление движения (концепцию),
текущую краткосрочную цель (миссию) и вехи, которые ведут к успеху (показатели).
Руководство определяет общее направление, и команда разрабатывает детали, взаимо-
действуя с ним и другими стейкхолдерами.
Когда команда видит возможность изменить См. также
свою цель так, чтобы она принесла больше
ценности, члены команды обсуждают это Цель (глава 7)
с руководством.
Команда демонстрирует свою ответственность не тем, что показывает поставлен-
ные ею истории, а фокусируясь на бизнес-целях: как уже достигнутых на данный
момент, так и тех, которых она надеется достичь в будущем. Эти результаты могут
быть простыми, например цифры полученной выручки, или более изощренными,
как, например, рейтинг удовлетворенности сотрудников. В любом случае акцент
делается на результатах, а не просто на поставленном продукте и датах.
Однако команды оптимизации не только пытаются достичь краткосрочных
результатов. Они также постоянно изучают, как лучше обслуживать своих заказ-
чиков и рынок. Поэтому они обсуждают то,
что узнали, что хотят узнать дальше и как См. также
планируют это сделать. Они делятся этой
информацией с помощью внутренних демо, Демо для стейкхолдеров (глава 10)
внутренних дорожных карт и непосред- Дорожные карты (глава 10)
ственного общения с руководством.
ФИНАНСИРОВАНИЕ
Финансирование команды — еще один механизм организационного надзора. Коман-
ды оптимизации, как правило, финансируются на основе текущей деятельности
(см. подраздел «Agile-управление» главы 10). Организация выделяет эти средства,
основываясь на результатах, ожидаемых от команды. Команда также может получить
единовременное финансирование и ресурсы, обратившись к руководству и обосно-
вав потребность в них.
Если члены команды не думают, что
могут достичь своей цели с помощью име См. также
ющихся у них финансов и других ресурсов,
Контекст (глава 7)
то могут попросить спонсора о большем.
Если он не согласен, то команда вместе с ним ищет баланс, которого можно достичь,
или переключается на другую, более значимую цель. Как правило, это обсуждение
проводится в рамках разработки контекста для устава.
В ходе работы команды прогнозы организации о ценности сбываются… или нет.
Здесь возникает возможность скорректировать цель команды. Если команда произ-
водит больше ценности, чем ожидалось, то финансирование может быть увеличено
и команда может удвоить свои успехи. Если производит меньше, то финансирова-
ние может быть уменьшено или команда может переключиться на более ценную
и значимую цель.
ЭКСПЕРИМЕНТЫ И ЛИТЕРАТУРА
ДЛЯ ДОПОЛНИТЕЛЬНОГО ЧТЕНИЯ
Как я уже упоминал, организациям и руководителям может быть сложно перейти
к автономности и владению. 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
Открытия
Команды оптимизации сами принимают решения по всем вопросам, касающимся

продукта. Откуда они знают, что создавать?
Отчасти они это знают потому, что в них См. также
есть люди, разбирающиеся в продукте. Эти чле-
ны команды имеют квалификацию и прошли Вся команда (глава 7)
обучение, чтобы решать, что делать.
Но факт в том, что по крайней мере в начале создания нового продукта никто
не может быть на 100 % уверен, что делать. Некоторые делают вид, что знают, но
только не команды оптимизации. В лучшем случае их идеи — это очень хорошие
догадки о том, что приведет к успеху.
Таким образом, работа команды оптимиза-
ции состоит не в том, чтобы знать, что созда- Работа команды оптимизации
вать, а в том, чтобы выяснить, что создавать. состоит не в том, чтобы знать,
Стив Бланк, работа которого легла в основу что создавать, а в том, чтобы
движений бережливого стартапа, сформули- выяснить, что создавать.
ровал это следующим образом.
Задача однозначная — исследовать и выяснить, какие проблемы есть у заказчи-
ков, и решает ли эти проблемы концепция вашего продукта; понять, кто будет
покупать его; и использовать это понимание для построения дорожной карты
продаж так, чтобы команда продаж смогла его продать заказчикам. И вы долж-
ны быть достаточно привержены идеям Agile, чтобы действовать, невзирая на
неожиданные и быстрые изменения, основанные на том, что говорят заказчики,
и достаточно влиятельны, чтобы реорганизовать вашу команду, когда этого
требует обратная связь от заказчика [Blank2020a] (приложение A).
Steve Blank, The Four Steps to the Epiphany1
Стив Бланк говорил о стартапах, но эта цитата одинаково хорошо применима

и к командам оптимизации. Даже если вы не продаете свое ПО! Неважно, кто ваши
заказчики и пользователи (даже если это Кевин и Кайла, которые сидят в соседней
кабинке офиса), ваша работа состоит в том, чтобы разобраться, как принести им
пользу. И, что не менее важно, как сделать это так, чтобы они действительно купили
ваш продукт или стали его использовать.
1
Бланк С. Четыре шага к озарению. Стратегии создания успешных стартапов.
ПОДТВЕРЖДЕННОЕ ЗНАНИЕ
Бесчисленное количество раз у меня была хорошая идея, я предлагал ее реальным
заказчикам или пользователям и обнаруживал, что она не сработала. Конечно, они
мне говорили, что им нравится идея, когда я им о ней рассказывал. Иногда они это
говорили даже после того, как попробовали прототип! И только когда я предлагал
людям понести реальные расходы (времени, денег или политического капитала),
я узнавал, что моя «хорошая идея» была недостаточно хороша.
Идеи по продукту подобны вечному двигателю: если вы достаточно сильно в них
верите и придали им достаточно инерции, то они выглядят так, словно будут работать
вечно. Но подайте на них реальную нагрузку, и они замирают.
«Подтвержденное знание» — один из ваших луч-
ших инструментов для тестирования идей. Я расска-
зывал о нем в подразделе «Подтвержденное знание» См. также
главы 16, однако напомню: подтвержденное знание
Обнаружение слепых зон
подразумевает постановку гипотезы о вашем рынке, (глава 16)
создание чего-либо, что вы можете вывести на него,
Вовлечение реального за-
и измерение того, что происходит. Используйте
казчика (глава 8)
полученное знание для коррекции своих планов,
затем повторите. Этот процесс часто упоминается
как цикл «Создать — измерить — узнать».
Чтобы действительно подтвердить верность того, что вы узнали, вам нужны
реальные заказчики (или пользователи) и реальные затраты. Если вы показываете
ваше творение людям, не принадлежащим к вашему целевому рынку, то получите
обратную связь, но она может не иметь отношения к вашей реальной ситуации.
И если вы не просите их принять на себя какие-либо обязательства в ответ, то больше
узнаете о желании людей не задеть ваши чувства, чем о реальной ценности вашей
идеи. Все будут хвалить вашу идею роскошного отпуска… пока вы не попросите их
внести первый взнос1.
СПОСОБНОСТЬ К АДАПТАЦИИ
Всякий раз, проходя цикл «Создать — измерить —
узнать», вы узнаете что-то новое. Чтобы восполь- См. также
зоваться тем, что вы узнали, вам понадобится
изменить свои планы. В результате команды оп- Адаптивное планирование
(глава 8)
тимизации склонны иметь короткие горизонты
планирования и планы, пригодные для адаптации.
Они работают с помощью маленьких инкрементов, чтобы иметь возможность без-
болезненно изменить направление.
1
И тогда начинается все вот это: «Ой, у меня нет времени», «Я не могу оставить в одиночестве
своего чихуахуа Пушистика» и «Ненавижу тропический песок. Он грубый, раздражает и про-
никает везде».
Глава 18. Открытия 611
Ценные инкременты (см. подраздел «Ценные инкременты» главы 8) — это

не только функционал и возможности. Помните, есть три общие категории цен-
ности:
zz прямая ценность — вы создали нечто, представляющее один из видов ценности,
описанных во врезке «Что ценят организации?» в главе 3;
zz познавательная ценность — вы создали нечто, помогающее вам лучше понять
ваш рынок и будущие перспективы;
zz вариативная ценность — вы создали нечто, позволяющее вам менять направление,
обходясь меньшими затратами.
Для команд оптимизации познавательная и вариативная ценности так же важны,
как и прямая. В самом начале они могут быть даже более важными, чем прямая цен-
ность, поскольку позволяют команде избежать потери времени в случае создания
чего-то неправильного. Каждый цикл «Создать — измерить — узнать» — пример
инкремента, имеющего познавательную ценность.
Думать о вариантах — тоже общая черта команд оптимизации. Будущее неясно,
и никакие планы не являются окончательными, поэтому команды оптимизации
обеспечивают себе возможность адаптироваться. Они это делают, думая о будущих
возможностях и создавая инкременты, имеющие вариативную ценность. Перспек-
тивный анализ, описанный в одноименном подразделе главы 8, — один из способов
начать поиск таких вариантов.
Кроме того, использование вариантов — важная техника управления рисками.
Если ваш перспективный анализ показывает существенный риск (например, конку-
рент предоставляет менее прибыльную, но более привлекательную ценовую модель),
то вы можете создать вариант, который позволит вам изменить вашу ценовую модель
простым нажатием кнопки.
В еще один вид вариантов входят дедлайны. Хотя команды оптимизации стара-
ются избегать необоснованных дедлайнов, иногда ценность заключается в релизе
до какой-либо определенной даты. Например, видеоигры должны быть поставлены
в срок к сезону отпусков, налоговое ПО нужно обновлять ежегодно, а новые нор-
мативные регламенты могут иметь строгие дедлайны и жесткие штрафы в случае
неисполнения.
Чтобы уложиться в эти сроки, команды оптимизации часто готовят «безопасный»
инкремент, прежде чем приступить к более амбициозной идее. Данный инкремент
минимальным образом исполняет требования, реализовать которые необходимо
к дедлайну, позволяя команде спокойно работать над более амбициозными идеями.
Если эти идеи не оправдываются или не могут быть завершены вовремя, то команда
выпускает вместо них «безопасный» инкремент.
Например, рецензент Билл Уэйк поделился историей (возможно, недостоверной)
о компании, производящей принтеры, которой было нужно поставить функциональ-
ность для нового фотопринтера, удаляющую эффект красных глаз. Релиз аппаратного
обеспечения был назначен на определенную дату, поэтому команда программного
обеспечения начала с примитивного алгоритма удаления эффекта красных глаз,
а затем продолжила работать над более сложным подходом.
ЭКСПЕРИМЕНТЫ И ЛИТЕРАТУРА
ДЛЯ ДОПОЛНИТЕЛЬНОГО ЧТЕНИЯ
Определение направления развития продукта имеет гораздо больше нюансов, чем
я могу рассказать в этой книге. Источников для дальнейшего изучения множество;
изучите категорию менеджмента продукта. Можно начать с трех книг: 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
Взгляд в будущее
Команды Agile никогда не перестают учиться, экспериментировать и совершенство-

ваться. Практики в этой книге — лишь начальная точка. Как только вы поняли прак-
тику — используйте ее! Экспериментируйте с альтернативами и ищите новые идеи.
Когда станете более компетентными, сознательно нарушайте правила и смотрите, что
будет происходить. Вы узнаете, почему существуют правила… и каковы их пределы.
Что будет после этого? Это решать вам. Agile всегда подстраивается под потреб-
ности команды.
В модели Agile Fluency мы с Дианой Ларсен определили возможный четвертый
уровень: укрепление. Если вы посмотрите внимательно, то каждый уровень пред-
ставляет свой вариант расширения круга контроля команды: уровень фокусировки
позволяет команде нести ответственность за свои задачи; уровень поставки по-
зволяет владеть своими релизами; уровень оптимизации позволяет владеть своим
продуктом.
Уровень укрепления продолжает этот тренд, внося в зону ответственности команды
ее организационную стратегию. Люди не просто принимают решения, сфокусиро-
ванные на своих командах; они объединяются, чтобы принимать решения, влияющие
на множество команд. Один из примеров, начинающий становиться основным
направлением, — самоотбор команды. Ее участники решают сами для себя, частью
какой команды они будут, а не назначаются руководством.
Выглядит сумасшествием? Но это не так. Это тщательно структурированный
процесс, а не общедоступный. (Более подробную информацию см. в [Mamoli2015].)
Я сам использовал этот подход к выбору команды, и он удивительно эффективен.
Результаты лучше, чем я видел при традиционном назначении команд руководи-
телем. Это приводит к командам, которые высокопродуктивны с самого начала
работы.
Уровень укрепления предназначен для принятия такого рода восходящих решений.
Подходы к управлению, такие как социократия (https://www.sociocracy.info) и хола-
кратия (https://www.holacracy.org), экспериментируют в этой области; то же самое
делают и такие компании, как Valve Software, Semco и W. L. Gore & Associates. Более
подробные сведения содержатся в книге Ютты Экштейн и Джона Бака Company-
wide Agility with Beyond Budgeting, Open Space & Sociocracy [Eckstein2020]. В книге
Рикардо Семлера Maverick1 [Semler1995] представлено более легкое введение в тему.
1
Семлер Р. Маверик. История успеха самой необычной компании в мире.
Это увлекательный рассказ о том, как автор обновлял подход к менеджменту в своей
компании.
С учетом сказанного, модель 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:
[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:
Библиография 617
[Denne2004] Denne M., Cleland-Huang J. Software by Numbers: Low-Risk, High-Return

Development. Upper Saddle River, NJ: Prentice Hall, 2004.
[Derby2006] Derby E., Larsen D. Agile Retrospectives: Making Good Teams Great. Raleigh, NC and
Dallas, TX: Pragmatic Bookshelf, 2006.
[Derby2019] Derby E. 7 Rules for Positive, Productive Change. San Francisco: Berrett-Koehler
Publishers, 2019. https://learning.oreilly.com/library/view/7-rules-for/9781523085811.
[Dumiak2021] Dumiak M. “Chaos Engineering Saved Your Netflix.” IEEE Spectrum. March 3,
2021. https://spectrum.ieee.org/telecom/internet/chaos-engineering-saved-your-netflix.
[Duvall2006] Duvall P. M. Continuous Integration: Improving Software Quality and Reducing
Risk. Boston: Addison-Wesley Professional, 2006.
[Eckstein2020] Eckstein J., Buck J. Company-wide Agility with Beyond Budgeting, Open Space
& Sociocracy: Survive & Thrive on Disruption, 2020. (self-pub.)
[Edmonson2014] Edmonson A. “Building a psychologically safe workplace.” YouTube. Video, 11:26.
TEDxTalks, 2014. https://www.youtube.com/watch?v=LhoLuui9gX8.
[Edmonson2018] Edmonson A. The Fearless Organization: Creating Psychological Safety in the
Workplace for Learning, Innovation, and Growth. Hoboken, NJ: Wiley, 2018.
[Evans2003] Evans E. Domain-Driven Design: Tackling Complexity in the Heart of Software.
Boston: Addison-Wesley Professional, 2003.
[Falco2014] Falco L. “Llewellyn’s Strong-Style Pairing.” The Way Things Work in Llewellyn’s
World (blog). June 30, 2014. https://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-
style-pairing.html.
[Feathers2004] Feathers M. Working Effectively with Legacy Code. Upper Saddle River, NJ:
Prentice Hall, 2004.
[Feynman1974] Feynman R. “Cargo Cult Science.” 1974. https://calteches.library.caltech.
edu/3043/1/CargoCult.pdf.
[Fields2015] Fields J. Working Effectively with Unit Tests. Victoria, BC: Leanpub, 2015. https://
leanpub.com/wewut.
[Ford2017] Ford N., Parsons R., Kua P. Evolutionary Architectures. Sebastapol, CA: O’Reilly
Media, 2017.
[Forsgren2018] Forsgren N., Kimble J., Kim G. Accelerate: Building and Scaling High Performance
Technology Organizations. Portland, OR: IT Revolution Press, 2018.
[Fowler1997] Fowler M. “The Almighty Thud.” Distributed Computing 11 (1). 1997. https://www.
martinfowler.com/distributedComputing/thud.html.
[Fowler2000] Fowler M. “The New Methodology (Original).” Martin Fowler.com. July 21, 2000.
https://www.martinfowler.com/articles/newMethodologyOriginal.html.
[Fowler2002] Fowler M. Patterns of Enterprise Application Architecture. Boston: Addison-Wesley
Professional, 2002.
[Fowler2003] Fowler M. “Cannot Measure Productivity.” Martin Fowler.com. August 29, 2003.
https://www.martinfowler.com/bliki/CannotMeasureProductivity.html.
[Fowler2004] Fowler M. “Is Design Dead?” Martin Fowler.com. May 2004. http://www.martinfowler.
com/articles/designDead.html.
[Fowler2011] Fowler M. “Contract Test.” Martin Fowler.com. January 12, 2011. https://martinfowler.
com/bliki/ContractTest.html.
[Fowler2018] Fowler M. Refactoring: Improving the Design of Existing Code. 2nd ed. Boston:
[Fowler2020a] Fowler M. “Keystone Interface.” Martin Fowler.com, April 29, 2020. https://
martinfowler.com/bliki/KeystoneInterface.html.
[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.
[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.
[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.
[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.
[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.
Об авторе
Джеймс Шор руководит командами, практикующими Agile-разработку, начиная

с 1999 года. В своей работе он объединяет глубокое понимание идей Agile c десяти-
летиями практического опыта разработки. Используя этот опыт, он помогает людям
понять, как соединять все аспекты Agile в одно целое для получения выдающихся
результатов. Джеймс — обладатель премии Гордона Паска Agile Alliance за вклад
в практики Agile, организатор многих скринкастов сессий кодирования и соавтор
модели Agile Fluency. Его можно найти онлайн по адресу jamesshore.com.
Джеймс Шор, Шэйн Уорден
Искусство Agile-разработки.
Теория и практика гибкой разработки ПО
Перевела с английского Е. Дьяконова
Руководитель дивизиона Ю. Сергиенко

Ведущий редактор Н. Гринчик
Научный редактор В. Фунтов
Литературный редактор Н. Хлебина
Художественный редактор В. Мостипан
Корректоры О. Андриевич, Т. Никифорова
Верстка Г. Блинов
Изготовлено в России. Изготовитель: ООО «Прогресс книга».

Место нахождения и фактический адрес: 194044, Россия, г. Санкт-Петербург,
Б. Сампсониевский пр., д. 29А, пом. 52. Тел.: +78127037373.
Дата изготовления: 10.2023. Наименование: книжная продукция. Срок годности: не ограничен.
Налоговая льгота — общероссийский классификатор продукции ОК 034-2014, 58.11.12 — Книги печатные
профессиональные, технические и научные.
Импортер в Беларусь: ООО «ПИТЕР М», 220020, РБ, г. Минск, ул. Тимирязева, д. 121/3, к. 214, тел./факс: 208 80 01.
Подписано в печать 25.08.23. Формат 70×100/16. Бумага офсетная. Усл. п. л. 50,310. Тираж 1000. Заказ 0000.

Искусство Agile-разработки

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Искусство Agile-разработки

Загружено:

Авторское право:

Доступные форматы

Искусство Agile-разработки

Шор Джеймс, Уорден Шэйн

ЧАСТЬ I. УЛУЧШАЯ ГИБКОСТЬ

Глава 2. Как быть Agile.........................................................................................................................................44

Глава 3. Выберите свою гибкость...................................................................................................................49

Глава 4. Инвестируйте в гибкость...................................................................................................................56

Решите проблемы, связанные с безопасностью...............................................................................70

Глава 5. Инвестируйте в изменения..............................................................................................................75

Глава 6. Масштабирование гибкости............................................................................................................90

ЧАСТЬ II. ФОКУС НА ЦЕННОСТЬ

Глава 7. Командная работа............................................................................................................................. 108

Навыки коучинга.................................................................................................................................... 115

Глава 8. Планирование..................................................................................................................................... 184

Как создать план..................................................................................................................................... 206

Глава 9. Владение................................................................................................................................................ 254

Резерв времени............................................................................................................................................. 291

Глава 10. Ответственность.............................................................................................................................. 322

Предварительные требования........................................................................................................ 357

Глава 11. Совершенствование...................................................................................................................... 370

Устранение препятствий........................................................................................................................... 394

ЧАСТЬ III. НАДЕЖНАЯ ПОСТАВКА

Глава 12. Сотрудничество .............................................................................................................................. 406

Глава 13. Разработка.......................................................................................................................................... 437

Ешьте луковицу с середины.............................................................................................................. 466

Глава 14. Дизайн.................................................................................................................................................. 502

Уровни дизайна...................................................................................................................................... 507

Глава 15. DevOps.................................................................................................................................................. 536

Глава 16. Качество.............................................................................................................................................. 570

Обнаружение слепых зон......................................................................................................................... 580

ЧАСТЬ IV. ОПТИМИЗАЦИЯ РЕЗУЛЬТАТОВ

Глава 17. Автономность................................................................................................................................... 605

Глава 18. Открытия............................................................................................................................................. 609

Глава 19. Взгляд в будущее ............................................................................................................................ 613

Автор «Искусства Agile-разработки» смог совершить, казалось бы, невозможное,

Эта книга получит свое постоянное место на моей книжной полке.

Одна из самых полных книг по Agile-разработке программного обеспечения, которые

Это моя любимая книга об Agile. Она охватывает технические и управленческие

Джеймс подробнейшим образом описывает собственный опыт в Agile-разработке ПО.

Джеймс Шор полностью обновил «Искусство Agile-разработки», дополнив книгу

Когда мы писали Манифест Agile для разработки программного обеспечения, наши-

Вопрос: Что нужно делать, чтобы выступить в Карнеги-холле?

конкретной ситуации. В каждой практике есть подраздел «Альтернативы и экспе-

ЧТО НОВОГО ВО ВТОРОМ ИЗДАНИИ

Я полностью переработал книгу, чтобы она позволяла обеспечить постепенное

ДЛЯ КОГО ПРЕДНАЗНАЧЕНА КНИГА

Agile коллегам. Остальной материал книги поможет разобраться, как воплотить

ИСПОЛЬЗОВАНИЕ ПРИМЕРОВ КОДА

Что касается обратной связи, особую признательность выражаю моим рецен-

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

Подход, основанный на фазах, получил название водопадной (waterfall develop­

следующих нескольких месяцев, переписываясь по электронной почте, эти люди

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

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

Agile-разработка является скорее адаптивной, чем предиктивной; ориентиро-

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

Эти определения прекрасно иллюстрируют предиктивный тип мышления. Они

Как обнаружилось, проекты, отвечающие всем традиционным критериям

Команды Agile определяют успех как по-

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

ПОЧЕМУ AGILE ПОБЕДИЛ

Типичный провал тяжеловесного процесса

Несмотря на существование большого раз-

ПОЧЕМУ AGILE РАБОТАЕТ

к лучшему. В предисловии к первой книге по экстремальному программированию

Подход, основанный на фазах, получил название водопадной (waterfall develop