Все Об Agile

Клод Обри
иллюстрации Этьена Аппера
все об
AGILE
Искусство создания
эффективной команды
5-е издание
Предисловие
Речь пойдет об Agility, но почему же мы решили назвать книгу «Все об Agile.

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

Мы адресуем свою работу неспециалистам, а именно тем, кто:
• слышал об Agility, но не знает, как ее можно применить и для чего;
• находится в процессе внедрения Agility в работу организации или команды,
ищет идеи или нуждается в совете;
6
• уже начал практиковать Agility, но не видит обещанных преимуществ и хочет
разобраться в причинах.
Чего вы здесь не найдете

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

«Все об Agile. Искусство создания эффективной команды» — это результат со-
вместного мастерского труда.
Спасибо Этьену Апперу за его талант и творчество. Благодаря его рисункам эта
книга об Agility отличается от прочих.
Я знаю Жан-Люка Блана с момента первого издания моей книги по Scrum в 2009 году.
Здесь Жан-Люк сыграл исключительную и решающую роль. Именно он убедил Эть-
ена присоединиться к нашему приключению. Именно он способствовал ее созда-
нию, с заботой и усердием играя роль Scrum-мастера в команде. Спасибо, Жан-Люк.
Кроссфункциональную команду дополнили Ив Трембле, который блестяще спра-
вился с версткой книги, и Максин Пузе, которая ее внимательно вычитала.
Коллективный опыт доказал, что Agility применима в отношении написания книг,
даже в нашем контексте (объединившем три варианта, предложенных в главе 6).
В конце книги процитированы три ситуации и извлеченные из них уроки.
Большое спасибо Алексису Монвиль, Клоду Андрие и Яну Ван Дравику за расска-
зы о пути их команд к Agility.
Мы скорректировали содержание книги благодаря комментариям рецензентов,
отобранных для лучшего представления нашей аудитории.
Спасибо всем, кто повлиял на результат обратной связью: Алиса Барралон,
Александрина Лубраду, Бахаре Неджат-Бахш, Элен Дехаэз, Алексис Монвиль
(из Бостона), Лора Молн (из Бергена), Клод Андрие, Жан-Паскаль Буаняр, Жан-
Франсуа Марронье, Бертран Уриг, Стефан Ланглуа, Ален Саке, Бенжамен Кабанн,
Сириль Желино, Мелани Лакеруз, Лилиан Рико и Александр Бутен.
Среди них выражаю особую благодарность Жан-Франсуа, Жан-Паскалю и Клоду,
которые дружелюбно, остроумно и быстро откликались на мои просьбы, когда
у меня возникали сомнения (что случалось часто).
Клод Обри
ǵȊǸȂȅȀǻǸȉȆȉȊȆȀȊȀǿǻȃǸǺ
ǢȃȖȏǽǺȆȁ
ǢȃȖȏǽǺȆȁ
ǺȆȇȈȆȉǟǘǯǝǤ#
ǟǸȏǽȄ
ȉȊǸȅȆǺȀȊȔȉȗ%KMPI#
ǢȃȖȏǽǺȆȁ
ǺȆȇȈȆȉǩǢǝǤ# ǢȆȄǸȅǼǸ
ǺȕȂȆȉȀȉȊǽȄǽ
ǢȃȖȏǽǺȓǽ
ǺȆȇȈȆȉȓǢǦǛǜǘ#
ǢǘǢǠǤǦǙǨǘǟǦǤ#
ǮȀȂȃ
ȆǹȈǸȊȅȆȁȉǺȗǿȀ
ǢȃȖȏǽǺȓǽ 4ǨȀȊȋǸȃȓ
ǺȆȇȈȆȉȓ ȉȇȈȀȅȊǸ
ǢǦǛǜǘ#ǩǯǝǤ#
ȈǽȊȈȆȉȇǽȂȊȀǺǸ
ȇȃǸȅȀȈȆǺǸȅȀǽ ȉȍǺǸȊȂǸ ȆǹǿȆȈ
ǚ
ǚǻȃǸǺǸȍ
ǻȃǸǺǸȍ ɝ Ǻȓ ȋǿȅǸǽȊǽ ȀȉȊȆȈȀȖ PermaBio ɞ
ǺȓȋǿȅǸǽȊǽȀȉȊȆȈȀȖ
ǚǻȃǸǺǸȍɝǺȓȋǿȅǸǽȊǽȀȉȊȆȈȀȖPermaBioɞ
ȂȆȄȇǸȅȀȀǿǸȅȀȄǸȖȑǽȁȉȗȇȆȉȊǸǺȂȆȁ
ȆȈǻǸȅȀȏǽȉȂȀȍȌȈȋȂȊȆǺȀȆǺȆȑǽȁ
ǢȃȖȏǽǺȆȁ
ǢȃȖȏǽǺȆȁ
ǺȆȇȈȆȉ ǘǯǪǦ
ǺȆȇȈȆȉǘǯǪǦ
ǧǦǪǦǤ#
ǤǸȈȐȈȋȊȅǸ
ǺǽȈȐȀȅȋ%KMPI
ǢȃȖȏǽǺȆȁ
ǢȃȖȏǽǺȆȁ
ǺȆȇȈȆȉ
ǺȆȇȈȆȉ
ǦǪǢǫǜǘ#
ǧȋȊȀ
ȌȆȂȋȉȀȈȆǺȂȀ
ǢȃȖȏǽǺȆȁ
ǢȃȖȏǽǺȆȁ
ǺȆȇȈȆȉǢǘǢǠǤ
ǺȆȇȈȆȉǢǘǢǠǤ
ǦǙǨǘǟǦǤ#
5ǥȆǺǸȗȂȋȃȔȊȋȈǸ n%KMPIȂȈȆȃȀȂȀ~ɞ
ȅǸǽǾǽǼȅǽǺȅȆȁ ȈȆȂǻȈȋȇȇǸȂȆȊȆȈǸȗ
ȆȉȅȆǺǽ ȇȆǼǽȃȀȊȉȗȉǺȆȀȄ
ȄǸȈȐȈȋȊȆȄȅǸȇȋȊȀ
ȄǸȈȐȈȋȊȆȄȅǸ ȇȋȊȀ
Ȃ%KMPMX]ǺǻȃǸǺǽ
Зачем
Глава 1
становиться
Agile?
Глава 1 Зачем становиться Agile?
Agility — это что?
https://t.me/it_boooks/2
12
13
Сила слов
Новичок в компании обязательно удивится, завидев группу людей, что стоят пе-
ред доской, на которой наклеен целый ворох стикеров. Ему подскажут, что это
«Agile-команда», однако, приблизившись, он едва ли поймет, на каком языке
они разговаривают. Их речь пестрит словами на английском и загадочными ак-
ронимами.
Мы коснемся каждого из этих семи слов и подробно их объясним. Новенький,

вероятно, услышит куда больше, но мы не станем заострять внимание на каж-
дой таинственной фразе, поскольку не терминология способствует распростра-
нению Agility.
Бóльшая часть этих терминов пришла из Scrum. Именно Scrum внес наибольший
вклад в популяризацию Agility за последние пятнадцать лет. Появившийся в ре-
зультате глоссарий — прямое тому доказательство.
Однако Scrum и Agility — не одно и то же. Тем не менее, многие до сих пор пута-
ют эти понятия, чему свидетельствуют всевозможные статьи, обсуждения в со-
циальных сетях, а также объявления о вакансиях, где смешивают одно с другим,
и в результате мы видим «Scrum / Agile».
Оба понятия можно найти в словаре:
• слово «scrum» пришло из английско-
го языка, оно относится к игре в регби
и переводится как «схватка»;
• слово «agile» в переводе с английского
означает «гибкий».
14
В своем первом значении «гибкий» — это синоним проворности и ловкости. Гиб-
кий ум — живой, быстро схватывающий.
Чтобы не путать Scrum со scrum, то есть элементом спортивной игры, интересую-
щий нас термин решено писать с заглавной буквы. Некоторые авторы делают
то же самое в отношении «agile» и «Agile». Мы будем использовать слова «Agile»,
а также «гибкий» и «гибкость», что означает способность команды к адаптации.
Сторонников Agility принято называть «аджайлистами», поэтому само движение
логично было бы назвать «аджайлизмом». Правда, этот термин не используется
в сообществе. Agility, или гибкость, обозначает как способность команд адапти-
роваться, так и поток мыслей.
Scrum — часть этого движения, один из его элементов. Важная, но далеко
не единственная. В целом, можно стать Agile и без Scrum.
Чтобы лучше понимать терминологию, следует обратиться к истокам.
15
Немного истории
Приквел (до 2001 года)
Программное обеспечение завоевывает мир. Однако его разработка появилась
сравнительно недавно. Очень быстро разработчики поняли, что их инженерия
отличается от того, что практикуется в отрасли промышленности. Нематериаль-
ные объекты (программное обеспечение) отличаются от материальных.
В 1980-х годах в программной инженерии появилось понятие итеративной и ин-
крементальной разработки. Но, поскольку менеджеры, ничего не смыслящие
в софте, хотели применить свои методы и в отношении ПО, потребовалось вре-
мя, чтобы концепция получила признание.
Попытки адаптировать промышленные методы к специфике программного
обеспечения оказались слишком трудозатратными.
Scrum, появившийся в 1990-х годах, возродил идею коротких циклов, добавив
к ней концепцию самоорганизующейся команды.
При чем же здесь регби? Десятью годами ранее японские ученые исследовали, как
лучше всего разрабатывать инновационные и сложные продукты, и продемонстри-
ровали эффективность коллективной работы, когда все действуют одновременно
и в одном направлении, — прямо как во время схватки на матче по регби.
Основатели Scrum, Кен Швабер и Джефф Сазерленд, подхватили метафору,
в центре которой стояла идея коллективных усилий.
Agile-манифест и гибкая методология разработки (2001–2006 годы)

Слово «гибкость» в нужном нам значении прозвучало в Agile-манифесте. В дека-
бре 2001 года 17 экспертов в области программной инженерии собрались в Ска-
листых горах, США, и подписали документ, содержащий протест против непово-
ротливости и тейлоризма, преобладающих в отрасли.
Agile-манифест утверждает первостепенное значение человеческого аспекта
в командной работе. Руководствуясь логикой и здравым смыслом, он опровер-
гает ценность процессов, определенных знатоками и реализованных исполни-
телями.
16
Манифест — это возглас, а не подробная инструкция к действию. В нем всего 65 слов:
Agile-манифест не дает четких указаний, не показывает, какие методы исполь-

зовать и в каком порядке. Но он объединяет такие методы, как Scrum и Экстре-
мальное программирование, под единым «гибким» знаменем. Так появилось
название Agile-методологий. Первое время они распространялись тихо и неза-
метно, но довольно быстро стали по-настоящему популярными: слово «Agile»
привлекало внимание, а Scrum выступил в качестве катализатора опыта.
Scrum — самая популярная Agile-методология (с 2006 года)

Многие из этих методологий со временем исчезли. Scrum же прочно закрепился
и занял лидирующую позицию в 2006 году. Уже больше десяти лет результаты опро-
сов наглядно показывают, что Scrum — наиболее популярная Agile-методология.
Применяемые термины это только подтверждают: активно используются слова
«спринт» (для обозначения итерации) и «бэклог» (для списка дел). Все наслыша-
ны о таких ролях, как Scrum-мастер и Владелец продукта, более того, их можно
найти и в объявлениях о вакансиях.
Конец истории? Можно было бы сказать, что Scrum и Agility — это одно и то же.
Разницы, мол, никакой, Scrum отражает способ достижения гибкой операцион-
ной модели. Но это не совсем так.
17
Agility — это модно
Новые техники
Scrum занял ведущую роль в этом растущем и развивающемся движении. Он хо-
рошо раскрылся и сильно обогатился. Манифест пустил прочные корни, из кото-
рых вырос крепкий ствол Agile-методов разработки программного обеспечения.
И уже затем появились ветви с новыми техниками для новых областей знания,
в которых было заинтересовано Agile-движение.
Все это можно прочитать в публикациях и услышать на многочисленных конфе-
ренциях по Agility, которые проходят в городах Франции и Наварры.
За последние годы в докладах этих конференций были представлены, предве-
щая будущие тенденции, новые дисциплины, такие как системология, перма-
культура и нейробиология.
Столь открытый подход позволяет в полной мере охватить жизненный цикл про-
дуктов или услуг.
Помимо процесса разработки, Agility может быть применима на всех стадиях —
от определения продукта до его ввода в эксплуатацию. Появились соответствую-
щие методы управления, возможности для масштабирования Agility в боль-
ших проектах. Стало доступно множество инструментов для улучшения работы
в команде. А практики, взятые из инженерии, только усилили стремление к тех-
ническому совершенству, что также представлено в Манифесте. Бесконечный
поток поспособствовал созданию новых способов обработки запросов.
Однако совершенно не обязательно знать все концепции, заложенные в ветвях
дерева, чтобы достичь цели и стать Agile. Большинство из этих идей направлены
на то, чтобы стать еще более гибкими, чем мы есть сейчас.
Новая публика
Благодаря экспериментированию с новыми техниками и их внедрением Agility
продолжает динамично развиваться и распространяться.
Она привлекла новых последователей вне сферы разработки программного
обеспечения — сначала в ИТ, а затем и за его пределами.
Одна из причин заключается в успешности метафоры. Agility стала модной. Все
вокруг постоянно говорят «Agile», «гибкий», «гибкость» — можно услышать эти
слова даже на выступлениях политиков или в рекламных роликах.
Потеря смысла
У успеха есть оборотная сторона — потеря смысла, которая всегда следует за ши-
роким распространением идеи и притоком новых последователей.
18
Потеря смысла неумолимо ведет к искажению Agility. Из-за этого некоторые на-
чинают верить в то, что Agility им не подходит, и отказываются даже попытаться.
19
Внимание — фальсификация!
В то время как Agility стала мейнстримом в теории, на практике иная карти-
на. Мартин Фаулер, один из подписавших Agile-манифест, ввел термин «лож-
ный Agile», чтобы обозначить и заклеймить разрыв между желаниями и реаль-
ностью.
Он считает, что сейчас это самая большая проблема в Agile-движении, с кото-
рой надо бороться.
Существует множество причин, объясняющих искажение Agile. Пять из них пред-
ставлены ниже.
Н — Незнание!
Нина игнорирует тот факт, что Agile-команда кроссфункциональна, то есть спо-

собна достигать определенного результата. Она сама — часть команды, звено
в цепочке создания стоимости. Оставлять Agility разработчикам — все равно что
пренебрегать клиентоориентированностью.
М — Мизонеизм!
Максим отрицает любые новшества — от использования стикеров до визуаль-

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

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

цесса. Это в лучшем случае приведет к локальной оптимизации, которая не даст
большого эффекта.
Г — Гордыня!
Глеб — чрезмерно самоуверенный владелец продукта. Он думает, что может

обойтись без обратной связи — одного из важнейших элементов Agility.
Мы будем бороться с искажением Agility, но сначала стоит вернуться к вопро-
су «почему».
21
И все же, почему Agility?

Говорить, что мы за Agility, потому что это модно, — не наша стезя. Что на самом
деле важно, так это понимать, подойдет нам Agility или нет.
Умственный труд vs физический труд https://t.me/it_boooks/2

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

ми слева, то у нас для вас отличные новости! Agility — это философия, идеально
подходящая для интеллектуальной работы и сильно отличающаяся от идей, при-
нятых в индустрии.
22
Смешение культур как причина искажения Agility
Основная причина ложной Agility — это сохранение культуры и инструментов ин-
дустриальной модели для интеллектуальной работы.
Люди продолжают действовать руками, когда необходимо переключиться и по-
раскинуть мозгами.
Мартин Фаулер во время своего выступления в Сиднее осудил стремление всех
тех, кто хочет индустриализировать Agility. Чаще всего они делают это по незна-
нию, ведь очень сложно мгновенно отказаться от привычной культуры после
многих лет работы в индустриальной модели.
Команда становится гибкой благодаря культуре и инструментам, подходящим
для интеллектуальной работы.
Доказательства?
Книга «Accelerate», выпущенная весной 2018 года, основана на трехлетнем ис-

следовании технологических компаний; в результате было доказано, что орга-
низации, внедрившие практики из Lean, DevOps и Agility, показывают более вы-
сокие показатели и предоставляют более качественные услуги.
К примеру, частый ввод в эксплуатацию конечными пользователями существен-
но снижает количество неисправностей. В третьей главе книги подчеркивается
влияние культуры на производительность.
Почему? Потому что экономика!

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

В чем отличие настоящей Agile-команды? И как развить эту «настоящую Agility»?
Делать Agile
Классический подход при оценке уровня Agile заключается в выявлении прак-
тик и проверке их соблюдения. Составить список Agile-практик не трудно. Затем
этот список нужно применить к команде: если она последует практикам (хотя бы
большей их части), она будет объявлена Agile.
Вот только оценка, основанная исключительно на том, что команда делает, не-
верна. Невозможно оценить уровень команды по списку практик. Более того,
Agility не заключается в одних лишь практиках.
Быть Agile
Фундамент для Agility — это ценности и принципы, например те, что представле-
ны в Манифесте.
Среди основных принципов Agility выделим два:
• самоорганизация, которая возможна только в доброжелательной обстановке
и означает, что команда сама определяет, как ей работать;
• итеративный подход, при котором продукт или услуга создается путем посто-
янного общения с пользователями.
Быть Agile — значит применять практики и следовать принципам.
Возможно ли принять решение о гибкости команды, ориентируясь на ценности
и принципы? Это довольно непросто. Кроме того, такой подход дает нам статич-
ную картинку: Agility заключается не только в том, что команда делает, и в со-
стоянии участников в данный момент, но скорее в направлении, в котором
команда продвигается.
Становиться Аgile
Чтобы убедиться, что команда движется в правильном направлении, лучше все-
го сосредоточить внимание на получаемом результате, убедиться в том, что
команда регулярно приносит пользу своим пользователям и, в более широком
смысле, заинтересованным сторонам.
Говоря об этом, мы черпаем вдохновение в модели Agile Fluency™. Agile
Fluency — это ориентированная на ценности модель, которая помогает опреде-
лить командный уровень владения Agility.
Бизнес-ценность (с английского «business value») — это отражение удовлетво-
ренности клиентов (и пользователей) от новой версии продукта. Мы также вклю-
чаем в нее ценность знания, которая позволяет улучшать продукт без необходи-
мости ввода в эксплуатацию.
24
Agility состоит в предоставлении ценности, и команда становится Agile, регуляр-
но ее поддерживая.
Тех, кто говорит: «Agility — это просто здравый смысл, мы же всегда так работа-
ли», когда речь об итеративном подходе разработки, мы с улыбкой спрашива-
ем, проводят ли они в конце итерации демонстрацию полученных результатов
перед пользователями.
Конечно, можно утверждать, что некоторые практики — это не более чем «здра-
вый смысл» (хотя стоит задуматься о том, что мы под этим имеем в виду), но поня-
тие «здравого смысла», как мне кажется, может включать в себя недооценивание
и даже отрицание усилий, необходимых, чтобы Agility начала приносить плоды.
Преимущества от инвестиций
Модель не только определяет, стала ли команда Agile, но и позволяет ответить
на два других вопроса:
• чего мы хотим достичь?
• на что мы ради этого готовы?
Модель состоит из нескольких зон, каждая из которых соответствует уровню
владения Agile. Как это часто бывает в сфере разработки, команда развивает-
ся не по дням, а по часам. «Овладение» следует понимать как эффективное вы-
полнение практики, вошедшей в привычку команды и более не подвергаемой
сомнениям, даже если команда находится под давлением.
Каждой зоне соответствуют свои преимущества, которые дает Agility, и необхо-

димые для этого инвестиции. Важно знать и принимать во внимание и то, и дру-
гое, потому что без инвестирования выходит лишь искаженная, ложная Agility.
Следует иметь в виду, что модель применима к команде, а не к отдельному че-
ловеку или всей организации.
25
Agility и рок-н-ролл
Для наглядности возьмем метафору рок-группы и с ее помощью попробуем про-
иллюстрировать каждую из зон — от «не Agile» до «усиления».
Не Agile
История начинается с троих ребят, которые пока что играют каждый у себя дома.
Они знают друг друга, иногда пытаются играть вместе, но у них не особо получа-
ется. Они не настоящая группа.
О них еще никто не слышал.
Фокус на цели
И вот их стало четверо — присоединился ударник. Они стали репетировать в га-
раже, чтобы стать настоящей группой. Они придумали себе название: «Agile-
кролики».
26
Спустя несколько месяцев у них в репертуаре уже несколько песен и каверов.
Впервые они выступают на публике во время фестиваля «Праздник музыки».
В толпе было с десяток восторженных зрителей. Сами ребята были счастливы
играть вместе, хотя и пару раз сфальшивили.
Техническое совершенство
Музыканты усердно занимаются сольфеджио и нарабатывают технику. Они пи-
шут свои песни и находят более приятное место для репетиций. Кое-что из ав-
торского ребята опубликовали в интернете, чтобы о них узнало больше людей.
«Agile-кролики» выступают в качестве гостей радиопередачи от «Молодежного
центра». Их начинают приглашать на небольшие площадки, и они с радостью со-
глашаются, потому что у них есть отработанный репертуар.
27
Оптимизация
«Agile-кролики» узнаваемы за пределами родного города. Одна из их песен ча-
сто звучит на радио. Они подписали контракт с крупным лейблом, наняли арт-
директора и техническую команду для гастролей. Их мечта осуществилась. Они
собирают стадионы. На выходе со сцены их ждут поклонницы. Они выпускают
альбом для большой аудитории.
Усиление
«Agile-кролики» триумфально шествуют по миру, а в перерывах между концер-
тами помогают развиваться другим музыкантам. Их приглашают на выступле-
ния, и они соглашаются. Группа открыла продюсерский центр, чтобы оказывать
поддержку молодым коллективам.
Мы вернемся к ним в седьмой главе.
28
У каждой команды своя цель
Модель представляет собой градацию навыков, приобретаемых с каждой по-
следующей зоной, но это не означает, что цель команды заключается в перехо-
де к самой последней зоне или достижении наивысшего уровня. Не все, кто ре-
шил побренчать на гитаре, становятся Led Zeppelin или IDLES.
Фактически, каждая зона обладает своими преимуществами, и даже если мы бо-
лее гибки в зоне «Усиления», чем в «Фокусе на цели», команда может сосредо-
точиться на последней, учитывая ее нынешний уровень.
Так что же получается, нет необходимости в компетенциях зоны «Тех-

ническое совершенство», когда ты в зоне «Фокуса на ценность»?
Улучшение технических навыков очень важно и необходимо для полу-
чения качественных результатов. Но первоочередной задачей стано-
вится создание целенаправленной команды. Только с командой, знаю-
щей свою цель, можно переходить на следующий уровень.
29
Agile в фокусе
Именно благодаря фокусировке мы становимся Agile. Чтобы этого достичь, не-
обходимы изменения в культуре команды. Для этого команда должна овладеть
основами Agility и постоянно добиваться результата, имеющего ценность.
Менеджеры и все, кто заинтересован в результатах команды, получают в итоге:
• возможность повлиять на выбранное командой направление и наблюдать
за достижением результатов;
• возможность увидеть командную работу.
Инвестиции менеджмента и организации

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

Мы будем выбирать даже не метод, а путь. Их несколько, и для команды, кото-
рая еще не Agile, но стремится к этому, воспользуемся самым легким.
Нам следует придерживаться самых основ Agility, игнорируя все остальное
(«остальное», но ни в коем случае не «лишнее», так как что-то из этого может
пригодиться позднее для укрепления Agility команды).
Создатели Agile Fluency утверждают, что сфокусироваться на цели помогают
Scrum, Kanban и нетехническая часть Экстремального программирования.
Путь пролегает через идеи и концепции этих трех методологий:
• возьмем глоссарий Scrum, роли Владельца продукта и Scrum-мастера, бэклог
и спринт;
• используем концепцию истории из Экстремального программирования, а так-
же практику работы в паре;
• позаимствуем Kanban-таблицу из, соответственно, Kanban и идею ограниче-
ния текущей работы.
Получившийся Agile-микс сделает наш путь к достижению «Фокуса» простым
и поможет обрести свою культуру команды.
Вы готовы к путешествию в команде?

В главах 2–6 на этом пути вас сопроводит вымышленный проект PermaBio, о ко-
тором вы совсем скоро узнаете.
Цель нашего путешествия — достижение первой ступеньки: стать Agile, сфокуси-
ровавшись на цели. После этого мы сможем устремиться дальше, к следующим
зонам модели. К этому мы вернемся в главе 7.
31
Проект PermaBio
Пьер — основатель PermaBio. Вот что он рассказывает о своем проекте:
«PermaBio появилась на свет в ре-
зультате осознания, что люди хо-
тят есть вкусные домашние продук-
ты. С развитием пригородной
пермакультуры все больше и больше
садоводов имеют излишки, которы-
ми могут поделиться. PermaBio
стремится стать местной площад-
кой для обмена экологически чисты-
ми фруктами и овощами.
Что касается производства,
PermaBio располагает гектаром зем-
ли под пермакультуру. Также компа-
ния занимается развитием сети сер-
тифицированных садоводов.
Принцип в том, что фрукты и овощи собираются по запросу, склада
хранения продуктов у нас нет. Разумеется, в результате мы имеем
только сезонные фрукты и овощи.
PermaBio уже протестировала идею доставки продуктов частным ли-
цам. Сейчас мы идем дальше — наша цель в том, чтобы вместо фрук-
тов и овощей предлагать все необходимое для приготовления того
или иного блюда. Клиенту больше не придется вдаваться в детали
того, что ему пригодится для готовки, — он просто запрашивает
блюдо и указывает количество порций, а PermaBio приносит ему все,
что нужно. Клиенту остается только приготовить блюдо по рецеп-
ту, который идет в комплекте».
Пример: отец семейства хочет приготовить суп, но дома не хватает овощей; он

заказывает у PermaBio ингредиенты и рецепт супа.
Цена указана по акции за блюдо: не нужно взвешивать каждый овощ или пла-
тить как за килограмм. Цена уменьшается в соответствии с запрошенным коли-
чеством.
Доставка осуществляется на велосипеде, максимально возможный радиус —
10 км. Компания обязуется привезти продукты менее чем за час с момента заказа.
PermaBio предлагает исключительно то, что выращивается на ее собственном
поле или у одного из сертифицированных садоводов. Ассортимент обновляется
с учетом урожая фруктов и овощей.
32
Компания предлагает супы, закуски, овощные блюда и фруктовые десерты.
Каждый день меню обновляется. PermaBio доставляет все необходимые ингре-
диенты, а также специи, которые фигурируют в рецепте.
Наш проект состоит в том, чтобы сделать эту услугу доступной для новых после-
дователей пермакультуры и любителей органических овощей и фруктов. Мы ви-
дим ценность в следующем:
Почему PermaBio хочет стать Аgile?

Давайте вместе с Пьером вернемся к списку характеристик интеллектуальной
работы и посмотрим, сможем ли мы имплементировать Agility в его проект:
• у Пьера есть видение продукта, но потребности четко не определены;
• у Пьера небольшой бюджет и нет готовых решений, придется действовать
по ситуации;
• проект учитывает взаимодействие с сертифицированными садоводами, курь-
ерами и пользователями, что весьма непросто.
По этим пунктам можно судить, что проект Пьера относится к сфере интеллекту-
альной работы, и стоит задуматься о внедрении в него Agility.
Четвертая характеристика проекта это только подтверждает: работа по разви-
тию новой услуги, которую предлагает компания, не материальна. И PermaBio
никогда раньше подобным не занималась. Новая идея довольно сильно отлича-
ется от всего, с чем компания сталкивалась прежде, будь то сбор картофеля или
вишни. Несмотря на то, что речь идет больше о сельском хозяйстве, нежели про-
мышленности, можно сказать, что работу по сбору овощей и фруктов компания
уже мастерски освоила, чего нельзя сказать о новой услуге.
Переход к Agility для физической составляющей проекта неуместен. Но если бы
Пьер захотел автоматизировать сбор или разработать новый прополочный ком-
байн, мы бы вернулись к интеллектуальной работе, основанной на Agility. То же
самое касается услуги по созданию земельных участков, предназначенных для
пермакультуры. В этих случаях предпочтительнее работать короткими итера-
циями, оставляя возможность для экспериментов.
Пьер убежден, что команда PermaBio должна стать Agile.
33
Глава 2
Команда
в экосистеме
Глава 2 Команда в экосистеме
Кто? Команда ПАЛАС!

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

Изменения в состоянии духа приходят в первую очередь с новой используемой
терминологией. Люди больше не воспринимаются как взаимозаменяемые части
механизма, а все заточенные под устаревшие взгляды процессы устраняются.
36
Метафора схватки показывает, какую огромную роль играют отношения между
участниками.
Превращение обычной группы людей в настоящую сфокусированную коман-
ду не требует внедрения нового процесса. Возможно, кто-то из вас разочарует-
ся, но здесь вы не найдете подробного описания новых ролей, детального спис-
ка действий, входной и выходной информации. Ведь группа людей становится
командой только благодаря совместному опыту.
Доверие в команде
Границы Agile-команды обозначены четко: все знают, кто в нее входит, а кто
нет. Но граница — это не каменная стена между участниками и внешним миром,
и они продолжают взаимодействовать с людьми, не состоящими в команде. Бо-
лее того, общение необходимо. Команда не обособлена, она — часть экосисте-
мы, которая, помимо самих участников, включает тех, кому важен результат. Та-
ких людей называют заинтересованными сторонами.
Чтобы стать настоящей Agile-командой, необходимо изменить культуру не толь-
ко внутри команды, но и культуру заинтересованных сторон. Стоит учитывать,
что этот процесс протекает куда медленнее.
Если команда стремится стать Agile в не-Agile среде, есть вероятность, что за-
интересованные стороны — носители старой культуры — попытаются навязать
свой авторитет или добавить участникам работу, которую считают срочной.
Очень важно защитить команду от подобного вмешательства. Необходимо обра-
тить внимание заинтересованных сторон на новую культуру. Но этого не всегда
достаточно, потому что они менее вовлечены в процесс. Не будучи Agile, заин-
тересованные стороны могут остаться приверженцами старой модели. В таком
случае есть риск искажения Agility.
Гетеротопия
Чтобы создать доверительные отношения в команде
и вовне, наилучшим способом будет обратиться к фено-
мену гетеротопии (с греческого «другое место»), то есть
другому, отличному пространству со своими правилами
(поддерживающими Agility команды) и своим обустрой-
ством. Это позволит команде успешнее развиваться.
Мишель Фуко, представляя концепцию гетеротопии, взял
в качестве примера ковер-самолет. Действительно, первые
ковры, созданные персами, изображали сады — великолепный
образец «другого места». Ковер-самолет символизирует переме-
щающийся в пространстве сад.
Мы отправимся в путешествие с командой на волшебном ПАЛАСе — ковре-
самолете.
37
П — Подходящий размер
Вопрос о том, сколько людей должно быть в идеальной команде, волнует всех
уже очень давно. Алексис Монвиль в своей книге «Changing your team from
inside» цитирует Бенджамина Франклина, утверждавшего, что в группе должно
быть не больше двенадцати человек. В случае большего количества участников
разговор перестает быть интересным. При Agile-подходе очень важны общение
и взаимодействие между всеми участниками команды. Если мы подсчитаем ко-
личество каналов коммуникации в команде из 12 человек, то получим 66.
размер команды 3 4 5 6 7 8 9 10 11 12
количество
3 6 10 15 21 28 36 45 55 66
взаимодействий
Это много. Даже слишком.

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

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

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

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

гое время оставалось расхожим мифом. Теперь же это стало реальностью для
Agile-команд. Хотя стоит для начала разобраться, что люди понимают под авто-
номией. Agile-манифест не очень развернуто отвечает на этот вопрос. Чуть боль-
ше деталей, хотя недостаточно много, нам дает Scrum:
«Команда автономна. Это значит, что у нее есть право

и авторитет для организации своей работы».
Существуют разные мнения о том, что представляет собой самоорганизация.

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

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

За содержание или суть работы (ответ на вопрос «что делаем?») отвеча-
ет Владелец продукта. Другое дело, что вариантов решения задачи (ответ
на вопрос «как делаем?») может быть множество, и тогда обсуждение затя-
гивается. Для таких случаев есть Scrum-мастер, который помогает команде
принять финальное решение. Мы еще вернемся к этому в главе 5.
В двух словах автономия — это одна из базовых характеристик Agile-команды.

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

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

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

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

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

Чтобы попасть в зону «Фокус на цели», не кроссфункциональная команда дол-
жна стать открытой, научиться обмениваться информацией и перенимать друг
44
у друга те или иные компетенции. Неразумно надеяться, что команда сразу ста-
нет полностью кроссфункциональной. Поначалу можно полагаться на компетен-
ции людей, не входящих в команду. Для создания цепочки стоимости участникам
разрешается обращаться к экспертам. Чтобы ограничить риски, команде следу-
ет определить все зависимости от тех заинтересованных сторон, которых она на-
значила экспертами по тому или иному вопросу.
Получается, каждый мастер на все руки? Да это невозможно!

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

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

ками. Они строятся на ежедневной основе и требуют стабильности. Хотя в неко-
торых организациях сохранение сплоченной команды не является приоритетом.
Скажем «нет» управлению ресурсами

Представим ситуацию: менеджер хочет уволить одного из участников команды
и заменить его другим. При этом он считает, что управляет взаимозаменяемы-
ми ресурсами.
Но он не прав! Это провал.
При замене всего одного человека придется заново настраивать коммуникацию

с остальными членами команды и, вероятно, с людьми извне — заинтересован-
ными сторонами. На это потребуется время и энергия. Вместо этого, пожалуй,
лучше заменить менеджера.
46
Закон Брукса
Что происходит, когда традиционный проект «отстает»? Все тот же менеджер ре-
шает вопрос путем добавления новых «ресурсов», чтобы уложиться в сроки. Он,
вероятно, не знает, что:
Если проект не укладывается в сроки, то появление нового

работника только задержит его сдачу.
Эта фраза, известная как Закон Брукса, была написана еще в далеком 1975 году!
Удивительно, что до сих пор встречаются менеджеры, которые ее не знают.
Но куда больше поражает то, что их всячески убеждают в обратном, утверждают,
что «отставание» проекта можно компенсировать, добавив в него больше людей.
Закон Брукса, очевидно, применим на протяжении всего спринта, но и после
него состав команды не должен меняться.
Стабильность помогает быстрее сфокусироваться на цели

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

Привычки надо менять… Ну или искать вдохновение в компании Menlo,
по всей видимости единственной, где закон Брукса не применим. Ри-
чард Шеридан, генеральный директор компании и автор книги «Joy»,
объясняет, почему: это систематическая практика работы в паре.
Почему же размер команды должен быть неизменным?

Если все время что-то менять, люди перестанут чувствовать себя ком-
фортно — прежде всего, психологически. А без доверия в команде сфо-
кусироваться на цели не получится.
Иными словами, команда сможет стать Agile исключительно в атмосфере дове-

рия, а для этого важна стабильность ее состава.
47
Владелец продукта
Сфокусированная команда способна к концу спринта принести своим пользова-
телям ценность. Поэтому ей так важно знать, что нужно пользователю, или, если
точнее, что может облегчить ему жизнь.
Задача расстановки приоритетов ложится на конкретного человека, который бу-
дет представлять интересы пользователей в команде. Этого человека называют
Владельцем продукта.
Это понятие пришло из методологии Scrum и широко используется даже во Фран-
ции. Правда, некоторые команды предпочитают другие названия. Например,
Алексис Монвиль в своей книге говорит о роли «адвоката пользователей».
Быть адвокатом пользователей — значит исполнять лишь часть возложенных
на него функций. На мой взгляд, называть его так ошибочно по двум причинам:
• Владелец продукта — это представитель всех заинтересованных сторон,
а не только пользователей;
• адвокат должен в то же время быть судьей с правом принимать решения.
Адвокат пользователей и
других заинтересованных
сторон
48
Право Владельца продукта
Его основная обязанность состоит в расстановке приоритетов. Он упорядочива-
ет список дел в соответствии с их ценностью. Иными словами устанавливает по-
рядок выполнения действий для получения результата.
Поскольку ничего нельзя утверждать заранее и наверняка, он будет тем, кто
принимает решения в команде, несмотря на неопределенность.
Функции в зоне «Фокуса на цели»

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

Его основная миссия в следующем:
Максимизировать ценность, минимизируя затраченные ресурсы.
Другими словами, его решения способствуют тому, чтобы команда выполняла
наиболее ценные для заинтересованных сторон задачи, а не тому, чтобы заста-
вить участников больше работать.
У нас есть менеджер по продукту. Зачем нам еще и Владелец?

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

за результат перед заинтересованными сторонами.
49
Scrum-мастер
Фокус на цели требует от команды хорошей самоорганизации: как только Вла-
делец продукта закончит с расставлением приоритетов среди задач, участни-
ки сами должны решить, как организоваться для их выполнения. Этот новый
способ совместной работы формируется и развивается благодаря особой роли
в команде.
Этого человека можно называть «фасилитатором» или «командным катализато-
ром». Но обычно используется термин «Scrum-мастер».
Задача Scrum-мастера — быть на службе у команды, помогать выполнять запро-
сы Владельца продукта, при этом совершенствуясь и развивая свой коллектив-
ный разум.
Миссия Scrum-мастера
Его миссия — поддерживать автономию команды — осуществляется в рамках:
• ограничений, установленных организацией, будь то выбор инструмента или
процесс запроса отпуска;
• принципов, практик и правил Agile-подхода.
Таким образом, Scrum-мастер — это человек в команде, который лучше всех
знает об Agility и делится своими знаниями с другими участниками. Эта грань
Scrum-мастера как коуча постепенно исчезает по мере того, как команда при-
обретает опыт и становится Agile.
Функции в зоне «Фокуса на цели»

Роль Scrum-мастера меняется с течением времени и зависит от уровня автоно-
мии команды.
Чтобы помочь команде сфокусироваться на цели, Scrum-мастер:
• получает от менеджеров гарантии того, что они готовы вложиться в переход
к Agile;
• предлагает, но не навязывает свои идеи (в отличие от Владельца продукта,
Scrum-мастер не принимает решения);
• развивает самобытность команды;
• организует мероприятия и придумывает ритуалы, старается воодушевить
участников их соблюдать;
• помогает Владельцу продукта исполнять его роль, если в этом есть необходи-
мость.
В течение этого времени (от двух до шести месяцев) человек находится в роли
на полной ставке. Ему при этом помогает Agile-коуч.
50
Человек на службе у команды
Так или иначе, всегда возникают трудности, препятствующие прогрессу команды.
Scrum-мастер старается их вовремя выявлять и гарантирует быстрое устранение.
Некоторые из этих препятствий связаны с отношениями команды с окружающей
средой, поэтому в задачи Scrum-мастера также входит разграничение зон влия-
ния заинтересованных сторон.
Scrum-мастер находится на службе у команды и посвящает свое время следую-
щим задачам:
• разговаривает с заинтересованными сторонами, способными отвлечь коман-
ду, и защищает участников;
• разрешает конфликтные ситуации;
• проводит беседы с людьми, которые, как ему кажется, чувствуют себя не в сво-
ей тарелке;
• подталкивает команду к празднованию успехов.
А что будет, если Владелец продукта примет решение, с которым

не согласен Scrum-мастер?
Решения Владельца продукта касаются продукта, а не способов орга-
низации работы. Они со Scrum-мастером, очевидно, разделяют обязан-
ности. Тем не менее Scrum-мастер имеет право высказать свое мнение
по любым вопросам и даже попытаться убедить Владельца продукта.
51
Заинтересованные стороны
Сфокусированная на цели команда производит ценный результат. Все люди,
на которых влияет эта ценность, и те, кому не безразличен такой результат, —
потенциально заинтересованные стороны.
Это пользователи, клиенты, а также спонсоры, представители пользователей,
специалисты по маркетингу или продажам, менеджеры, люди, связанные с ин-
фраструктурой, качеством и т. д.
Заинтересованная сторона менее вовлечена в процесс, чем участник команды:
она не выполняет работу, которая приводит к результату. Однако она участвует
в достижении общей цели. Поэтому важно, чтобы участники команды и заинте-
ресованные стороны были на одной волне и держались общего курса.
Приглашение к участию
Заинтересованные стороны приглашаются к участию в таком событии, как об-
зор. Во время этой встречи у них запрашивается обратная связь. Цель участия —
улучшение продукта и обмен новыми идеями.
Поощряется сотрудничество и вне обзора. Команда вполне может извлекать вы-
году из вклада заинтересованных сторон:
• заинтересованные стороны, обладающие достаточной властью, могут помочь
команде устранить препятствие, разрешение которого находится за предела-
ми досягаемости участников;
• заинтересованные стороны, владеющие необходимыми знаниями в той или
иной сфере, могут помочь команде в работе.
Ошибкой было бы не вовлекать заинтересованные стороны там, где они могут
пригодиться.
Заинтересованные стороны имеют влияние на результат через Владельца про-
дукта, который представляет их в команде. Но нельзя забывать, что принимают
решения не они, а Владелец продукта.
Просьба не беспокоить
Команда может сфокусироваться только в том случае, если все заинтересован-
ные стороны знают, как она работает, и не мешают ей.
С точки зрения команды, отношения с заинтересованными сторонами будут вклю-
чать в себя несколько моментов, на которые нужно всегда обращать внимание:
• снижение рисков относительно зависимостей от заинтересованных сторон,
когда команде необходима экспертиза, чтобы двигаться к результату;
• ограничение перерывов, вызванных срочными запросами от заинтересован-
ных сторон;
52
• приобретение знаний в процессе общения с заинтересованными сторонами:
о продукте — с пользователями, и о функциональных или технических аспек-
тах — с другими заинтересованными сторонами.
Что делать с теми, кто не хочет вовлекаться?

Если человек приглашен, но не принимает участие, значит, он не заин-
тересован в том, что делает команда. Этого человека нельзя назвать за-
интересованной стороной.
Как правило, люди, которым объяснили принципы и ценности Agility,
и которых обучили методологиям, хотят участвовать в процессе. Если
кто-то решил не вовлекаться, обязательно найдутся другие.
53
Как обрести веру

Преимущества фокусировки
Фокусировка команды дает свои преимущества — прогресс с точки зрения биз-
неса, смещение курса на ценность, — которые говорят о том, что участники на-
чинают доверять друг другу.
Во многих организациях это доверие потеряно. В частности, сильно возрастает
дистанция между сотрудниками IT и другими специалистами. Люди не понимают
друг друга. Не знают, как снова начать друг другу доверять.
Первое наблюдение, сделанное после нескольких месяцев внедрения Agility
в работу, часто звучит так: «Мы заново научились работать вместе. Доверие вос-
становлено».
В книге «Вера в себя» Шарль Пепен описывает три формы доверия. Давайте по-
пробуем рассмотреть их на примере команды.
Вера в других
• С точки зрения команды: если один из участников помогает другому в реше-
нии проблемы, которая мешает выполнению его задач, между ними возника-
ет доверие.
• С точки зрения заинтересованных сторон: когда в конце каждого спринта
команда представляет заинтересованным сторонам результаты проделанной
работы, они доверяют участникам и дают согласие на то, что команда в тече-
ние следующих спринтов будет продолжать рассказывать о результатах.
• Когда заинтересованные стороны видят, что Владелец продукта способен на-
правлять усилия команды на то, что важно для них, они доверяют ему роль
своего представителя.
Вера в команду и ее возможности

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

а контроль — еще лучше!
Руководитель, который так говорит, вероятно, не знает,

что эта фраза приписывается В. И. Ленину. Это лозунг
культуры контроля, от которой руководители должны
отказаться, если хотят, чтобы команда могла по-на-
стоящему сфокусироваться на цели.
В качестве первой инвестиции от-
лично подойдет изменение в самом
себе: новый образ мышления совер-
шенно необходим для создания до-
верительной обстановки в команде.
55
Команда PermaBio
и ее экосистема
В прошлой главе мы познакомились с Пьером и узнали о новой услуге компании
PermaBio, которую Пьер хочет развивать при помощи Agile-команды.
Сейчас мы встретимся с командой PermaBio и заинтересованными сторонами.
Команда ПАЛАС
• Подходящий размер: команда из шести человек. Оптимально!

• Автономия: конечно, команда еще не совсем автономна. Но Пьер решительно
настроен развивать ее самоорганизацию и позволить участникам самим ре-
шать все вопросы, связанные с «как» выполнять ту или иную задачу.
• Личностность: участники придерживаются ценностей пермакультуры, иными
словами, они согласны заботиться о нашей планете, о людях и делиться уро-
жаем.
• Адаптивность: участники обладают всеми необходимыми компетенциями для
получения результата. Не все еще хорошо разбираются в специфике деятель-
ности компании, то есть садоводстве, но Мари — эксперт — будет доступна
и в любой момент сможет проконсультировать участников по всем возникаю-
щим вопросам.
• Стабильность: шесть человек, входящие в команду, включены в работу как ми-
нимум на ближайшие полгода.
Роли
Так как Сара немного разбиралась в том, что такое Scrum, и даже применяла
свои знания на прошлой работе, она стала в команде Scrum-мастером.
С ролью Владельца продукта все оказалось не так просто. С момента возникно-
вения компании PermaBiо Пьер занимался всем, что касается продукта. Но он
не может позволить себе такую вовлеченность: все время быть с командой
и взаимодействовать с участниками, как того требует роль Владельца продукта.
56
Понятно, что Пьер должен делегировать эту функцию. Он осознает, что будущий
Владелец станет принимать тактические решения без его участия.
Команда продемонстрировала свою автономию и сама выбрала человека
на роль Владельца продукта. Было организовано голосование без кандидата,
и Лука получил наибольшее количество голосов. Он согласился на эту роль.
Заинтересованные стороны
Заинтересованным сторонам — Пьеру, Мари и Виктору — подробно рассказа-

ли про Agility.
Виктору, привыкшему давать Лее срочные задачи, объяснили, что теперь все бу-
дет иначе. Ему, как и остальным, рассказали о важности циклов обратной связи.
Элоди и Боб не входят в состав компании PermaBio. Боб — садовник, много знаю-
щий о пермакультуре и занимающийся выращиванием экологически чистых
овощей, которые затем продаются в PermaBio. А Элоди в качестве заинтересо-
ванной стороны предложил Натан. Она обожает проводить время на кухне и ре-
гулярно готовит супы и вторые блюда для своей небольшой семьи.
Рабочее пространство
У команды есть свое рабочее пространство. Участники могут организовывать
его по своему желанию. На одной из стен разместилась вся необходимая инфор-
мация о задачах команды, а перед этой стеной достаточно места, чтобы участни-
ки могли собираться и обсуждать статус дел.
Рядом с рабочей зоной располагается пространство для отдыха, которое также
можно использовать для встреч с заинтересованными сторонами.
Команда решила развиваться в визуальном менеджменте и закупилась всем не-
обходимым, чтобы на их стене были красивые доски с таблицами.
57
Цикл
Глава 3
обратной
связи
Глава 3 Цикл обратной связи
Рабочий поток
Команду можно считать Agile, если она регулярно производит результат, показы-
вает его заинтересованным сторонам и получает обратную связь.
Через этот цикл команда проходит в каждом спринте. Спринт лежит в основе под-
хода и задает рабочему процессу ритм.
Чтобы произвести результат спринта, команда использует список дел, называе-
мый бэклогом.
В бэклоге перечислены задачи, которые необходимо выполнить команде. Зада-
чи попадают в этот список благодаря обратной связи от заинтересованных сторон.
Полный цикл обратной связи — и есть фундамент Agility. В следующей главе мы
узнаем, как можно его регулировать. Но сначала нам следует сосредоточиться
на процессах, отвечающих на вопрос «что делаем» (бэклог, результат) и «когда
делаем» (спринт).
60
Бэклог как список задач
для команды
Бэклог — это список задач к выполнению во время спринта. Всего лишь? Так
и есть, однако, помимо текущих задач, в бэклог входит то, что ждет команду в бу-
дущих спринтах. Его особенность в том, что он позволяет выбрать нужный эле-
мент в нужное время.
Как же удивятся те, кто привык к сложнейшим, месяцами разрабатываемым
«кругу ведения», «описанию работ», «детальным спецификациям»! Ведь все это
можно заменить одним простым списком.
Зато сторонники to-do list’ов несомненно обрадуются: бэклог мало чем от них
отличается.
Бэклог легок и доступен в понимании, но в том, что касается использования,
дела обстоят чуть сложнее. Теперь, когда мы установили, что бэклог отличается
от to-do, описания работ и спецификации, посмотрим, что же это все-таки такое.
Доступный
Бэклог находится во всеобщем доступе, то есть,
он открыт для всех участников команды и заин-
тересованных сторон, поддерживая прозрач-
ность процесса и упрощая обратную связь.
Я думал, что единственный, кто отвечает за бэклог — это Владелец

продукта!
Бэклог — это инструмент для коммуникации как между Владельцем
продукта и командой, так и между командой и заинтересованными сто-
ронами. Очень важно обеспечить его доступность для всех участников
процесса. Так каждый сможет добавлять в бэклог элементы. Функция
Владельца продукта заключается в приоритезации этих элементов в за-
висимости от их ценности.
Конструктивный
Конструктивное сокращение бэклога делает его по-
нятным и упрощает управление для Владельца про-
дукта.
61
Как бэклог может быть коротким, если продукт содержит много

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

сти (высокий, средний, низкий). Зачем что-то менять?
Следует учитывать, что пользователи в 90% случаев считают свои за-
просы наиболее приоритетными и требуют рассмотреть их как можно
скорее. Концепция порядкового приоритета состоит в учете ценности
и предполагаемых усилий. Самый простой способ приоритизировать
задачи — это сравнить их на основе относительных оценок.
Уникальный
Бэклог — единственный список задач для команды.
Уникальность бэклога концентрирует усилия коман-
ды и помогает избежать негативных последствий
многозадачности.
Если речь о новых функциональностях, которые команда только пла-

нирует разработать, то ладно, здесь я согласен. Но для всего осталь-
ного у нас есть рабочая тикет-система, через которую мы трекируем
баги и небольшие запросы!
Кроме бэклога, у команды больше списков нет. В него и вносятся баги.
Решение за Владельцем продукта: добавить новую функциональность
Ф или исправить баг Б? В этом и заключается его роль.
62
Живой
Бэклог живой, потому что продукт постоян-
но развивается: одни элементы добавляют-
ся, другие, не несущие ценности, убираются,
какие-то элементы разбиваются на несколько,
их порядок постоянно корректируется…
Мне кажется, удалять запросы пользователей ужасно сложно. Поче-

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

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

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

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

Команда и заинтересованные стороны делятся идеями о возможных функцио-
нальностях новой системы:
• предложение супов, закусок, вегетарианских блюд и десертов дня;
• сбор кожуры и очистков для компостирования;
• новые рецепты с учетом отдельных предпочтений в еде;
• партнерство с кулинарными сайтами (например, mesrecettes.com), чтобы
на страницах с рецептами под списком ингредиентов была кнопка «заказать
все необходимое через PermaBio».
Что касается блюда дня, то это в первую очередь суп дня из ингредиентов, кото-
рые, по прогнозам Мари, будут доступны для сбора. В этом сезоне она может по-
ставить овощи для зимних супов.
Первый бэклог команды состоит из идей, с которыми согласились все участники:
Доработка крупных частей бэклога

Команда собирается, чтобы доработать первоначальный бэклог; истории в нем
слишком большие, считать их готовыми для реализации еще рано. Поэтому спер-
ва участникам нужно разбить истории на части. Начнем с самого важного: с супа.
Лука рассказывает:
66
67
Рассказ Луки вызывает шквал вопросов. Наконец, большой кусок «Суп» разде-
лен на четыре истории: «добавить суп», «выбрать суп дня», «заказать суп», «оце-
нить суп». Команда заменяет стикер «Суп» этими четырьмя историями.
Дальше команда обсуждает каждую из них.
После продолжительной дискуссии, начатой Лукой, выясняется, что еще нужно
настроить систему платежа, а также геолокацию. Участники прикрепляют соот-
ветствующие стикеры в столбец «Доработка».
Компостирование, партнерство с mesrecettes.com и предпочтения в еде оста-
лись в песочнице, на этапе идей.
68
Согласование готовых историй
Как и всегда во время доработки, Владелец продукта Лука обсуждает с коман-
дой готовность историй и расставляет их в порядке приоритетности.
Команда начинает с истории Добавить суп.
69
Вот краткий пересказ обсуждения командой истории Выбрать суп дня.

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

Клиент знакомится с предложением PermaBio и решает заказать суп дня. Он де-
лает заказ и указывает количество порций, а затем заполняет адрес доставки.
Если он живет в радиусе больше 10 км, появляется уведомление о невозмож-
ности доставки на такую большую дистанцию. Если клиент хочет заказать боль-
ше порций, чем доступно на сайте, об этом также появляется предупреждение.
Если заказ принят, количество доступных порций на сайте уменьшается, а кли-
ент информируется о том, что продукты будут доставлены в течение одного часа
(оплата курьеру при доставке). Бланк доставки направляется садовнице Мари.
70
Спринт — это ТОП!
Метафора спринта мгновенно рисует в воображении человека, который прила-
гает максимум усилий, чтобы пробежать дистанцию за короткое время.
Вспомните легкую атлетику или велоспорт. Гонщики «Тур де Франс» соревнуются
в спринте в конце этапа, чтобы одержать победу. Лучшие спринтеры ведут оже-
сточенную борьбу на дорожке до самой финишной черты. Этап составляет око-
ло 200 км, подготовка к спринту — 5 км, а сам спринт — 200 м. После этого на-
конец можно выдохнуть.
Agility сохраняет идею короткого промежутка времени. На этом все! Забудьте
о феноменальных усилиях, чтобы ускориться. Забудьте о том, что происходит
до и после спринта! Мы не должны останавливаться, нам не нужно время на вос-
становление, мы сразу запускаем следующий спринт.
Будем думать, что в данном случае «спринт» —

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

чи! Уверен, с внедрением Agility ничего не изменится!
Попробуйте объяснить ему концепцию спринта. А если этого будет недо-
статочно, за команду обязательно вступится Scrum-мастер. На самом деле
большинство срочных задач вовсе не такие срочные, и мы это еще увидим.
Концепция коротких и беспрерывных спринтов обладает рядом преимуществ:

• дата окончания будущих спринтов известна заранее, что позволяет своевре-
менно приглашать на встречи заинтересованные стороны;
• фиксированная продолжительность делает планирование спринта более эф-
фективным;
• легче отказываться от якобы «срочных» задач;
• на основе работы, проделанной в предыдущих последовательных спринтах,
можно делать прогнозы и планировать на среднесрочную перспективу.
Но прежде всего, заданный ритм — это эффективный способ ритуализации
спринта, о чем мы еще поговорим в следующей главе.
73
O — Ориентир
Во время спринта у команды есть ориен-
тир — цель, которую она себе задала в на-
чале спринта.
Цель спринта — все равно, что обещание
себе достичь определенного результата.
Это полезно для команды, но также и для
заинтересованных сторон.
Ориентир задает Владелец продукта. При этом он должен учитывать интересы
заинтересованных сторон, которые представляет в команде. Затем поставлен-
ная им цель в начале каждого спринта обсуждается и согласуется с участниками.
Цель, вовлекающая в рабочий процесс

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

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

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

няла свои задачи!
Мы просим от участников командной работы вовлечения в процесс,
а не выполнения списка задач, который сам по себе не поможет коман-
де сфокусироваться на ценности своей работы.
Вот почему так важно, чтобы команда нашла ориентир. У нее должна
быть цель. В течение спринта цель может измениться исключительно
в том случае, если изменились начальные условия, определяющие во-
влеченность участников.
75
П — План
Цель соответствует предназначению
спринта, а план спринта — это его конкре-
тизация.
Если сначала выбранная командой, так
сказать, черновая цель становится ориен-
тиром при планировании, то затем план
позволяет скорректировать уже оконча-
тельный вариант цели.
Цель доводится до сведения заинтересованных сторон, план же полезен толь-
ко для самой команды. Зато насколько полезен! План спринта, пожалуй, зани-
мает центральное место в повседневной практике Agility. С его помощью прово-
дятся ежедневные схватки. Он позволяет отслеживать прогресс в достижении
цели спринта.
План показывает команде, что еще нужно сделать, а также текущую и завершен-
ную работу. Можно сказать, что это инструмент, при помощи которого выстраи-
вается самоорганизация команды. В частности, в плане четко определено, кто
за что и когда отвечает.
План не «замораживается» в начале спринта, он развивается по ходу, в зависи-
мости от задач и встречающихся на пути команды препятствий. Благодаря огра-
ничению количества выполняемых задач, он помогает участникам избежать
многозадачности, о вредных последствиях которой мы уже сказали выше.
Визуальный менеджмент
Те, кто представил себе план спринта в форме диаграммы Ганта, как в тради-
ционном управлении проектами, пускай подумают еще раз. Диаграмма такого
типа, обычно составляемая одним человеком, мгновенно устаревает и совер-
шенно бесполезна для командной работы во время спринта.
Чтобы использовать план спринта максимально эффективно, необходимо обес-
печить его видимость, доступность и простоту. Вот почему командам, в особен-
ности начинающим, настоятельно рекомендуется практиковать визуальный ме-
неджмент.
План спринта изображается в виде таблицы, где каждый столбец соответству-
ет статусу работы («к выполнению», «в процессе» и «завершено»), а сама рабо-
та располагается горизонтально в ряд. Такая визуализация называется спринт-
доской, Scrum-доской или чаще Kanban-доской.
В плане, разработанном командой на этапе планирования, истории можно раз-
бить на задачи. Задача — это небольшая часть работы, выполнение которой за-
нимает меньше одного дня и способствует завершению истории. Но сама по себе
задача не несет ценности.
76
Визуальный менеджмент приносит большие результаты, если использовать на-
стоящую доску с наклеенными на нее стикерами. Так легко обеспечить доступ-
ность плана каждому участнику команды.
А что делать команде, участники которой не работают в одном офисе?

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

окончания спринта.
Ориентация на ценность, которая
очень в духе Agility, скорее все-
го, придется по вкусу заинтере-
сованным сторонам и понравит-
ся руководителям.
Но как измерить эту ценность?
Как понять, что команда достаточ-
но сфокусирована на ней? На эти
вопросы непросто ответить. В це-
лом, мы могли бы основывать
наши вычисления на степени удо-
влетворенности заинтересован-
ных сторон или количестве полу-
ченной обратной связи.
Но легче все же рассчитывать, исходя из того, достигла ли команда поставлен-
ной цели спринта (при условии, что цель ориентирована на ценность), потому
что на этот вопрос можно ответить совершенно однозначно: да или нет.
Достигнута ли цель спринта? Владелец продукта должен знать об этом заранее
и сообщить заинтересованным сторонам во время представления результатов
команды. Если есть сомнения, то он может попросить их помочь вынести решение.
Но как ответить на поставленный вопрос? Результат должен быть ДИВным!
Д — Достигнутый
Достигнутый результат состоит из историй, но не всех, а только завершенных
командой.
78
При принятии решения о том, завершена ли работа над историей, следует учи-
тывать качество ее выполнения. Если недоглядеть на этом этапе, есть большие
риски, что команда столкнется с трудностями в будущей работе. Это тот случай,
когда в погоне за скоростью команда может получить продукт плохого качества.
Как и цель, ожидаемый уровень качества определяется коллективно в нача-
ле спринта: участники составляют список, состоящий из контрольных пунктов,
то есть критериев завершенности. Следует учитывать, что в Agile-команде каж-
дый отвечает за качество. Не кто-то со стороны, а непосредственно участники
команды.
Каждое решение о завершении работы над историей требует обсуждения
в команде, так как у каждого участника свое видение и восприятие. Как сказал
Пьер Дак, французский актер и юморист, «все, что закончено, не может быть за-
вершено, пока не положить этому конец».
И — Используемый
Результат спринта позволяет команде учиться. Участники узнают больше о про-
дукте, о потенциальной бизнес-ценности и том, как они могут ее реализовать.
Получение знаний о продукте (или услуге) осуществляется путем демонстрации
результата заинтересованным сторонам, а в идеале — будущим пользователям.
После демонстрации результата они могут дать команде обратную связь. Все
это — часть ритуала, связанного со спринтом: обзором.
В — Важный
А если команда к концу спринта не достигает результата, который можно пока-
зать заинтересованным сторонам?
Результат состоит из историй, и, если не возникнет непредвиденных ситуаций,
команде удастся завершить хоть парочку. В среднем за двухнедельный спринт
можно завершить порядка десяти историй.
Достижение результата в конце каждого спринта — необходимое условие фоку-
сировки команды.
Если цель не достигнута, ничего страшного. В неудачах есть свои преимущества,
это хороший способ учиться, особенно если команда только в начале пути.
Как утверждает Кен Швабер, создатель Scrum, любую проблему можно решить
за тридцать дней (максимальная продолжительность спринта).
Команде потребуется несколько спринтов, чтобы сфокусироваться на цели. По-
началу, вероятно, не всё будет гладко, но впоследствии спринты обязательно
станут успешными.
Вопрос в том, сколько неудач команде придется преодолеть, чтобы достичь хо-
роших результатов.
79
Сфокусироваться
за один сезон
Как и Agility, в наши дни стали чрезвычайно популярны сериалы. Создатели того
или иного сериала сначала проверяют интерес к своей идее, выпуская пилотную
серию и подготавливая несколько эпизодов первого сезона. Если сезон будет хо-
рошо принят зрителями, за первым на экраны выйдет второй, и третий, и еще
больше, пока сохраняется интерес публики.
Аналогия спринта с эпизодом сериала поразительна, и по этой причине мы бу-
дем в дальнейшем использовать термин «сезон» для обозначения последова-
тельности из нескольких спринтов.
Продолжительность сезонов
Принцип, который применяется к спринту, действует и для сезона: все сезоны
имеют фиксированную продолжительность.
Оказывается, в расчетах нам может помочь деление на триместры. Посчитаем:
триместр длится около 13 недель.
• Если спринт длится две недели, у команды выходит шесть спринтов за сезон.
• Если спринт длится три недели, у команды выходит четыре спринта за сезон.
Плюс, каждый раз в конце сезона остается одна неделя, в течение которой мож-
но заниматься чем-то отличным от спринтерской рутины. Сделать шаг назад, по-
размышлять, дать команде передохнуть.
80
Первый спринт первого сезона команда начинает с прелюдии.
Мы вернемся к этому в шестой главе и обсудим, чем можно заняться во время
прелюдии и в конце сезона.
Первый сезон PermaBio

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

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

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

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

Agility?
Все так. И поэтому, как только команда достигает следующего уровня
Agility, входит в новую зону, например, «Фокуса», она может менять
свои ритуалы и избавляться от устаревших.
Четыре ритуала спринта

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

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

ни повестки дня, ни отчета после. Они помогают команде развивать коллектив-
ный разум.
Вскоре мы познакомимся с ними поближе. На следующих страницах этой кни-
ги вы найдете:
• интеллект-карту каждого из ритуалов;
• принципы их проведения и моменты, на которые стоит обратить внимание;
• способы проведения ритуалов на примере PermaBio;
• и, наконец, наши ответы на сомнения и возражения относительно их целесо-
образности.
87
Планирование спринта
Это ритуал, подготавливающий участников к постоянному фокусу на цели.
Принципы планирования
Слово «планирование» наталкивает на мысли о классической модели управле-
ния проектами, когда руководитель распределяет работу между сотрудниками,
то есть исполнителями. При этом контроль со стороны руководителя чаще всего
превращается в микроменеджмент задач коллег.
Но мы стремимся к другой модели, в которой нет руководителя.
Вычеркивая роль менеджера проекта, мы возвращаемся к определению плани-
рования: это «метод», состоящий из постановки цели и поиска способов ее до-
стижения. Agility подразумевает, что цель и способы — дело всей команды, это
то, что определяет ее автономность.
Agility ставит во главу угла адаптацию к изменениям и регулярное создание цен-
ности, а не четкое следование плану с целью соблюдения сроков и выделенно-
го бюджета. Ведь дата окончания спринта и так известна заранее и не меняется,
а затраты на разработку одинаковы для каждого спринта при должной стабиль-
ности команды.
88
Разделение работы на задачи
Поскольку у команды еще не много опыта совместной работы, вполне вероят-
но, что участники не очень хорошо умеют разделять свою деятельность на ма-
ленькие истории, а затем быстро и автономно с ними расправляться. Поэтому
участникам сперва полезно собраться и поразмышлять над содержанием исто-
рий. Результат их встречи отображается в плане спринта путем внесения задач,
из которых состоят истории.
Задача — это небольшой блок работы, выполнение которого занимает меньше
одного дня и который способствует завершению истории. Но сама по себе зада-
ча не несет ценности.
89
Как команда PermaBio проводит планирование

Команда обсуждает контекст спринта
Команда согласует истории с Владельцем продукта
90
Команда изучает истории и решает, что нужно для их реализации
Обсуждение сводится к содержанию историй. Команда определяет, какие зада-
чи необходимо выполнить, чтобы реализовать каждую из них. Все задачи запи-
сываются на стикерах; у каждой из них может быть свой координатор.
Команда с Владельцем продукта корректируют цель спринта
91
Каждый участник команды берет себе часть работы
92
Замечания в отношении планирования спринта
Если каждый будет выбирать и делать только то, что ему нравится, не-
ужели что-то вообще получится?
Принцип самоорганизации заключается в том, что в команде нет руко-
водителя, распределяющего работу.
На практике доказано, что самоорганизация работает, если дать основу
для ее выражения. Так обстоит дело и с планированием спринта.
Успокоим самых скептически настроенных:
• участники не могут брать любую работу; бэклог упорядочен в соот-
ветствии с приоритетностью задач, и это, конечно, нужно учитывать
при выборе;
• роль Scrum-мастера в том, чтобы стимулировать самоорганизацию
команды и помогать ей продвигаться к цели спринта.
Но ведь нет распределения работы на весь спринт.

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

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

но в том, что она происходит на ежедневной основе.
Принципы сотрудничества
Схватка увеличивает шансы команды на успех по итогам спринта и помогает
участникам сохранить фокус на цели.
У этого ритуала много названий: standup, daily scrum meeting и всевозможые
производные от них. При слове standup мы часто думаем об индивидуальном
и импровизированном сценическом выступлении. Daily scrum в переводе зву-
чит как ежедневная схватка, что усиливает идею взаимодействующей команды.
Момент ежедневного обмена внутри команды помогает участникам организо-
вать свой день и зафиксировать точки синхронизации.
Принцип схватки в том, что все участники отвечают на три ключевых вопроса
о цели спринта:
• что я делал вчера, чтобы помочь команде достигнуть цели?
• что я буду делать сегодня, чтобы достигнуть цели?
• есть ли что-то, что мешает мне продвигаться к цели?
94
Препятствия
Во время схватки участники выявляют возможные препятствия.
Препятствие — это определенный факт, замедляющий команду или мешающий
ей продолжать работу в нужном темпе.
Препятствия заносятся в специальную Kanban-доску. Связь между этой доской
и Kanban-доской команды можно визуализировать через маркировку задач или
историй яркими цветами.
Препятствия есть всегда. Схватка позволяет их быстро выявить, но это не время

и не место для их устранения.
В задачи Scrum-мастера входит назначение встреч с людьми, которые могут по-
мочь команде в разрешении выявленных препятствий. Бывает, что для этого не-
обходимо вмешательство людей со стороны.
95
Как команда PermaBio проводит схватку
96
Сара отвечает на три основных вопроса схватки, перечисленных выше:
Натан тоже работал над этой историей. Он говорит, что не видит никаких препят-
ствий, и поэтому предполагает, что завершит работу над ней уже послезавтра.
Надо будет уточнить доступность Луки, чтобы сразу же все проверить.
97
Команда переходит к следующей истории: «заказать суп дня». Говоря о ней, Тео
поднимает вопрос об ограничении в 10 км: имеется в виду расстояние с высо-
ты птичьего полета или расстояние, проезжаемое курьером по дороге? Так как
Лука сегодня отсутствует, нерешенный вопрос заносится в таблицу препятствий.
В столбце «в процессе» осталось всего две истории. Сара спрашивает, что дума-
ет команда по поводу запуска в работу третьей истории. Участники предлагают
вернуться к этому вопросу завтра.
Схватка завершается на 12 минуте. Каждый возвращается к работе, только Леа

и Тео остаются обсудить формат фотографий, подгружаемых на сайт.
98
Замечания в отношении схватки
Мы пробовали проводить схватки, но они выходили слишком долгими!

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

собираться. У каждого всегда есть возможность обсудить задачи, если
возникла необходимость. Зачем тогда нужна схватка?
Схватка — это ритуал, полезный для любой команды, даже той, где участ-
ники могут свободно друг с другом общаться. Схватка не требует боль-
ших затрат, и опыт показывает, что она наиболее эффективна, когда
команда ее проводит, стоя перед Kanban-доской. В процессе схватки
участники могут акцентировать внимание на препятствиях и на завер-
шении задач или историй. В регби есть известная поговорка, которая
точно так же применима и для Agility: no scrum no win.
Невозможно проводить схватку с теми, кого нет в офисе! Вы говори-

те «команда стоит полукругом перед Kanban-доской». Каким образом,
если часть коллектива работает удаленно?
Географическая разрозненность команды неизбежно снижает эффектив-
ность схватки. Но к счастью есть инструменты, позволяющие общаться ди-
станционно, например при помощи видеоконференций или онлайн-таблиц.
Однако здесь следует остерегаться подводных камней:
• подобные инструменты иногда превращают схватку в отчетный до-
клад от каждого участника, хотя цель ритуала совершенно не в этом;
• участие людей на расстоянии может затянуть схватку, с одной сторо-
ны, потому что они сидят, а с другой стороны, в связи с тем, что они
больше остальных нуждаются в обмене с другими участниками.
Мы вернемся к концепции рассредоточенной команды в главе 6.
99
Обзор спринта
Обзор спринта — это наиболее открытый ритуал команды с точки зрения вовле-

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

Спринт заканчивается во вторник. Утром, в десять часов, команда собирается,
чтобы подготовиться к обзору, который назначен на тот же день. Сара просит
всех, включая Владельца продукта Луку, прийти в комнату, где будет происхо-
дить обзор. Сейчас команда порепетирует, как будет проходить демо.
Команда очень быстро договаривается о том, что они покажут сегодня днем.
100
Лука фиксирует сценарий встре-
чи на флипчарте: сначала список
историй в том порядке, в котором
они будут представлены, затем он
дополняет этот список актуальны-
ми данными. Леа представит пер-
вые две истории (добавить суп
и выбрать суп дня), Натан займет-
ся третьей (заказать суп). Коман-
да пробует провести демо на теле-
фоне Сары.
Как хорошо, что они сразу все про-
веряют, ведь в этой комнате не ра-
ботает Wi-Fi! Нужно получить до-
ступ к тест-серверу.
Во время репетиции команде не хватает динамики. В части об используемом на-
боре данных недостает связности и конкретики. Лука предлагает более значи-
мый пример для демонстрации заинтересованным сторонам.
На репетицию у команды ушло 35 минут, и это было очень полезно для участников!
Стоит отметить, что им не нужно готовить презентацию для демо, достаточно сце-
нария, разработанного вместе.
101
Как PermaBio проводит обзор спринта: демонстрация

Команда собирается в два часа. Садовница Мари и Пьер, основатель PermaBio,
также присутствуют. Не хватает Виктора, менеджера по продажам, но зато
на встречу пришла Элоди, одна из постоянных покупателей.
Пока Леа подключает телефон к ви-

деопроектору, Лука представляет
сценарий сегодняшней демонстра-
ции. Леа отлично справляется со сво-
ей частью, получается гораздо лучше,
чем утром. В конце ее демонстрации
Лука напоминает заинтересован-
ным сторонам, какие сейчас были
показаны истории, и просит выска-
зать свое мнение. У Мари есть пред-
ложение по улучшению, Лука все за-
писывает. Элоди задает вопрос, Лука
отвечает на него. Тео продолжает де-
монстрацию.
Демо длится 22 минуты. В конце Лука благодарит заинтересованные стороны
за обратную связь, которую он записал и занесет в бэклог. Он объявляет, что
продукт доступен на сервере, и они сами могут его попробовать. Также он гово-
рит о следующем спринте.
102
Как PermaBio проводит обзор спринта:
управление продуктом
Пьер остается с Лукой и Сарой, чтобы поговорить о продукте. Они обсуждают
прошедшую демонстрацию и обратную связь от заинтересованных сторон. Лука
напоминает, что еще осталось в бэклоге для следующих спринтов.
Решение принято! Продукт будет

введен в эксплуатацию, как толь-
ко завершится работа над систе-
мой оплаты. Это произойдет через
20 дней, то есть почти сразу после
окончания следующего спринта.
Лука говорит, что сообщит об этом
команде, а также попросит Виктора,
чтобы тот написал объявление, ко-
торое они распространят заинтере-
сованным сторонам.
103
Замечания в отношении обзора
Если мы покажем нашим заинтересованным сторонам, что продукт

не содержит все то, что они ожидают, они будут разочарованы...
Разве они будут довольны, когда в конце года увидят, что долгожданный
продукт не соответствует ожиданиям? То-то же! Пригласите их к себе,
объясните, что и как вы делаете. Они очень быстро войдут во вкус, зная,
что участвуют в создании продукта и их мнение учитывается при разра-
ботке.
Зачем ждать обзор, чтобы показать пользователям функциональ-

ность? Можно ведь продемонстрировать ее сразу по завершении.
И неважно, середина это или конец спринта.
Обзор — это ритуал для обмена. Он объединяет команду и заинтересо-
ванные стороны, помогает укрепить доверие.
Команда регулярно показывает завершенную работу во время сприн-
та. Только она это делает для Владельца продукта, который в команде
представляет пользователей.
У нас все основные решения принимаются руководящим комитетом.

Входящие в него люди зачастую слишком заняты, чтобы присутство-
вать на обзорах.
Пригласите тех, кто принимает решения в руководящем комитете, и на-
стаивайте, чтобы они пришли! Что касается решений о продукте, — этим
людям следует напомнить, что именно Владелец продукта представля-
ет заинтересованные стороны, частью которых стали и они в том числе.
Владелец продукта находится в постоянном контакте с командой, и он
явно в лучшем положении для принятия тактических решений. Объяс-
ните, что последняя часть обзора посвящена управлению продуктом,
и что их присутствие только приветствуется.
Чего действительно следует избегать, так это наличия двух инстанций,
имеющих право принимать решения относительно продукта.
104
Ретроспектива спринта
Завершающий ритуал спринта — ретроспектива. Это последний, но наиболее

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

Укрепление доверия
106
Взгляд в прошлое
Сара подходит к доске и ри-
сует временнýю шкалу. Сле-
ва она указывает дату начала
спринта, справа — сегодня-
шний день. Она обращается
к доске препятствий; на каж-
дом стикере указано назва-
ние препятствия и дата его
появления. Так их легко рас-
положить на временной шкале, и участники сразу вспомнят все детали. Сара
спрашивает у команды, были ли во время спринта еще какие-либо значимые
события. В качестве примера она приводит торт, который Натан принес в про-
шлую пятницу, чтобы вместе отпраздновать его день рождения. Леа рассказы-
вает о своей встрече с Мари в понедельник, которая позволила ей лучше понять
потребности пользователей. Тео рассказывает о тренинге по JavaScript в среду.
Такой взгляд в прошлое позволяет команде сформировать целостную картину,

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

Сара рисует на доске красивую морскую звезду. Она объясняет смысл каждого
из пяти лучей.
108
Выбор идеи для реализации во время следующего спринта
Участники снимают стикеры с морской звезды и прикрепляют к пустой доске.

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

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

изменилось. В итоге участники решили просто отказаться от церемо-
нии, которая не приносит никаких результатов.
Существует множество причин, по которым реальность может не соот-
ветствовать ожиданиям. Чаще всего это небезызвестное сопротивле-
ние переменам. Но если люди сопротивляются, то это потому, что они
не чувствуют себя в атмосфере доверия.
Несоответствие ожиданиям может возникать из-за следующих факторов:
• команда не приняла четкое решение по улучшению. По итогам ре-
троспективы у участников должна быть цель, понятная для всех и ви-
димая в течение следующего спринта. У каждого должно быть жела-
ние ее достичь;
• у команды нет времени на самосовершенствование. Команда, загру-
женная на 100% во время спринта, не может работать на улучшение;
• решения по улучшению, принятые во время ретроспективы, вне ком-
петенции команды.
Здесь отлично вписывается стоический принцип: бесполезно пытать-
ся изменить то, что от нас не зависит. Лучше направить свою энергию
на то, что зависит от нас.
Или же, возможно, ретроспективы всегда проходят одинаково, и все
просто по очереди высказываются. В таком случае команде это бы-
стро наскучивает. Есть множество техник проведения ретроспективы,
их можно использовать и каждый раз применять новую. Команда лишь
должна определить форму, наиболее подходящую для ее контекста.
111
Привычка быть Agile

Четыре ритуала спринта лежат в основе Agility. Все они крайне важны для коман-
ды, которая стремится стать Agile. Все они дополняют и усиливают друг друга.
Участникам нужно всегда ставить цель и выводить из нее задачи, которые необ-
ходимы для ее достижения (планирование), всегда синхронизироваться между
собой (схватка), всегда проверять результат (обзор) и всегда совершенствовать-
ся (ретроспектива). Ритуализация облегчает организацию. Команда не тратит
силы на то, чтобы отдельно собираться для синхронизации, планировать ее,
проверять доступность каждого участника, искать место проведения и т. д.
Команда знает, что схватка проходит каждый день в 9:30 перед доской. Понача-
лу Scrum-мастер напоминает участникам правила, но вскоре они входят в при-
вычку, и команда сама собирается на ежедневную схватку.
112
Для проведения обзора необходимо участие и вовлеченность заинтересован-
ных сторон. Возможно, для них формирование привычек, связанных с ритуали-
зацией, займет больше времени, чем для команды, но со временем они точно
будут знать, что демонстрация проходит раз в две недели по четвергам, и коман-
да будет их ждать после обеда в месте, где всегда происходит обзор.
Ритуалы спринта структурируют жизнь команды и ее экосистемы, укрепляя уве-
ренность каждого участника в себе и остальных. Эта вера нужна во время сприн-
та, когда все работают, как единое целое, над достижением цели и получением
ценного результата.
Когда что-то происходит, мне кажется, нужно сразу действовать,

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

совещания!
Ритуал — это момент активного участия всей команды с целью получе-
ния ценного результата. Согласитесь, он отличается от тех совещаний,
где все молча сидят или проверяют личные сообщения.
Ритуалы — важная часть жизни команды, хотя отнимают всего 1/10
от общего времени. 90% — обычная рабочая рутина.
Изменение культуры, вызванное внедрением ритуалов в жизнь коман-
ды, должно отражаться на всей ее работе.
113
Новая культура
Глава 5
на ежедневной
основе
Глава 5 Новая культура на ежедневной основе
Команда разрабатывает
истории
В результате сессии планирования перед участниками стоит цель, общая для
всей команды, а также появляется представление о том, с чего необходимо на-
чать. Каждое утро во время схватки команда проводит оценку своего прогресса,
и в зависимости от этого происходит разделение работы.
Оба обряда — планирование и схватка — помогают команде работать сообща,
держать в уме общую цель и определять точки синхронизации.
Сотрудничество
Все остальное время участники
команды работают над задачами.
Обычно один человек выполняет
одну задачу. Но бывают случаи, ко-
гда стоит взяться за задачу бóльшим
количеством людей. В разработ-
ке ПО часто используется практи-
ка парного программирования, ко-
гда два человека работают сообща
за одним рабочим местом. Один пи-
шет код, а другой его проверяет. Этот
способ доказал свою эффективность
при поиске высококачественных ре-
шений.
Такая форма сотрудничества напоминает связь между падаваном и джедаем
с точки зрения передачи знаний.
Выполнение задач способствует завершению всей истории. Желательно, чтобы
задачи внутри одной истории были разделены между несколькими участниками.
Ведь если каждый работает над своей историей, невозможно говорить о сотруд-
ничестве, и уж тем более о фокусировке на общей цели.
Концентрация
Избежать многозадачности можно, если быстро завершать истории, а не растя-
гивать их, при этом постоянно приступая к новым. В этом команде может поспо-
собствовать такая Kanban-практика, как ограничение работы. Она заключается
в установке лимита на количество одновременно выполняемых заданий.
Например, команда PermaBio может установить ограничение в три одновремен-
но разрабатываемые истории.
116
Команда опытным путем приходит к пониманию, какое количество будет для нее
оптимальным, и может корректировать это число. Всякий раз, когда в работу бе-
рется история сверх установленного лимита, команда собирается, чтобы это об-
судить и принять целесообразное решение.
Завершение
Приступая к новому заданию или истории, каждый должен помнить следующее:
На первых порах участникам может быть сложно завершать истории, несмотря

на усердие команды. Причина, вероятнее всего, кроется в слабой доработке.
117
Доработка историй
Доработка — это практика, благодаря которой команда может увеличить свои
шансы на завершение истории в течение спринта. В результате получается гото-
вая история, то есть достаточно небольшая и понятная для всех.
Доработка ВО ВРЕМЯ спринта

В течение сессии доработки участники фокусируются только на тех историях, ко-
торые планируют запустить в работу в рамках следующего спринта.
Доработка отнимает совсем немного времени — примерно 10% от спринта. Она
никак не отражается в его текущем плане. Нужно понимать, что доработка исто-
рий происходит во время спринта, предшествующего их непосредственной реа-
лизации.
Ритуализация доработки
Начинающая команда еще не приобрела навыки доработки; более того, она мо-
жет забыть о том, что это необходимо сделать во время текущего спринта, а по-
том сломать себе голову во время сессии планирования следующего.
Один из способов познакомить команду с доработкой — это ритуализировать
ее, зафиксировать место проведения, продолжительность и применить к каж-
дому спринту. Как вариант, проводить ее каждый четверг с 14:00 до 16:00. Сле-
дует учитывать, что в этом случае время, затрачиваемое на ритуалы, увеличи-
вается примерно до 20%.
118
Доработка через разговоры с командой
Решение о готовности истории принимается командой после обсуждения с Вла-
дельцем продукта:
• если команда понимает, что может реализовать историю за один спринт, зна-
чит, она готова;
• в ином случае Владелец продукта должен пересмотреть историю к следующей
сессии доработки, чтобы команда могла взять ее в спринт.
То, что было сказано вслух, легко забыть. Для каждой истории следу-
ет писать документацию.
Только если очень хочется, но стоит задуматься вот о чем: если идеи ис-
чезают сразу после появления, не слишком ли они хрупкие?..
Неопределенность остается
Во время разговора внутри команды участники обязательно должны обсудить
будущий обзор и, в частности, демонстрацию: это помогает понять критерии за-
вершенности истории.
Речь не о том, чтобы попытаться определить детали истории и расписать весь
процесс ее реализации. Это слишком утопично, более того, может привести
к расслоению внутри команды на тех, кто решает, и тех, кто делает, — системе,
от которой мы пытаемся уйти при помощи Agility.
119
Обучаемая команда
Знания, полученные в ходе ретроспективы
К концу ретроспективы у команды есть четкая цель на следующий спринт. Чтобы
ее достичь и улучшить способ работы, участникам нужно время: сперва на об-
суждение того, какие действия необходимо предпринять, а затем на их выпол-
нение.
Команда может повысить свои шансы на успех, если зафиксирует цель на доске
и будет к ней возвращаться во время ежедневной схватки.
На следующий день команда договаривается о месте и времени проведения сес-

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

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

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

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

К тому, что остается после оценки Scrum-мастера и признается действительно
«срочным», существуют разные подходы:
• можно поменять еще не начатые истории на срочные задачи; команда решает

взять в работу срочную задачу, но при этом удаляет из текущего спринта исто-
рию, требующую примерно равных усилий;
• если команда принимает в работу срочную задачу, по ее выполнении она пе-
ресматривает свою цель;
122
• срочные задачи, влияющие на всю организацию, очевидно, будут приняты
командой, как в примере ниже:
123
Принятие решений
Принятие решений в Agile-команде отличается от традиционного подхода, где
за все отвечает руководитель проекта.
Автономная команда обладает правом и авторитетом, чтобы самостоятельно
принимать решения. Но есть ли у этого права ограничения? И каким образом
выносятся все те многочисленные решения, которые необходимы для продви-
жения команды во время спринта?
Какие решения?
При внедрении Agility в работу организации могут возникнуть сомнения по по-
воду права команды принимать стратегические решения о продукте, финансах
и человеческих ресурсах. Начинающая, несфокусированная команда вряд ли
решится сама атаковать африканский рынок, увеличить свой бюджет или
кого-то уволить.
Зато она может изменить свой рабочий график, обустроить рабочее простран-
ство, выбрать удобный инструмент для ведения бэклога, начать работать в паре
или, наоборот, отказаться от этой практики. Все это в полномочиях Agile-команды.
Роли и решения
Владелец продукта обладает особым полномочием приоритизировать истории
в бэклоге. В связи с этим он отвечает за максимизацию ценности. Это не исклю-
чает того, что Владелец продукта обсуждает приоритетность каждой взятой ис-
тории вместе с командой, но, если участники не могут согласиться по какому-
либо вопросу, он выступает арбитром, и ответственность за принятие решения
ложится на его плечи. В течение первого сезона он также сохраняет право ре-
шать, завершена работа над историей или нет.
Вопреки распространенному мнению, Scrum-мастер не имеет особых полномо-
чий, он участвует в принятии решения на тех же основаниях, что и другие участ-
ники команды.
Техники принятия решений

Чтобы ускорить процесс принятия решений во время ритуалов, Agile-команда мо-
жет использовать техники голосования, например голосование большинством
или посредством набора очков, как во время ретроспективы команды PermaBio.
Для повседневных решений рекомендуется предварительный сбор мнений.
Имеется в виду, что участник команды может принять решение при условии, что
он проконсультировался с экспертами в этом вопросе и теми, на кого впослед-
ствии это может повлиять. Само же решение в таком случае поддерживается
всей командой.
124
Например, у Леи появилась идея о том, как можно улучшить Kanban-доску
команды. Вот как она поступит:
125
Один день из жизни

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

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

Scrum-мастера
День начинается со схватки
Утром Сара проверяет электронную почту, а потом идет к кофемашине, где при-
ветствует участников команды. Накануне вышла очередная серия сериала, ко-
торый они все смотрят, и сейчас ребята делятся впечатлениями.
В 9:30 перед доской спринта начинается схватка. Команда уже знает, как себя
вести, поэтому Саре не нужно быть модератором этого ритуала. В рамках про-
шлой ретроспективы было предложено улучшение, касающееся продолжитель-
ности схватки. Сейчас Сара отмечает, что схватка действительно длится не бо-
лее четверти часа.
128
Забег с препятствиями
Сразу после схватки она видится с Леей
и системным инженером. Их разго-
вор касается препятствия, связанного
с промежуточным сервером, который
еще не запущен и на каждом спринте
затрудняет развертывание.
Как только решение найдено, Сара об-
новляет таблицу препятствий. Ох, оста-
лось всего три!
Заодно она проверяет, были ли обнов-
лены задачи после схватки. Все сдела-
но, хорошо.
Во второй половине дня, как обычно по четвергам, состоится сессия доработ-
ки бэклога. Сара недолго говорит с Владельцем продукта Лукой, чтобы удосто-
вериться, что на следующий спринт для команды есть задачи и они смогут рабо-
тать в прежнем темпе.
В полдень она устраивает пробежку вдоль канала со своей подругой, Софией.
129
После душа Сара идет на кухню, где уже обедает ее команда. Она присоединя-
ется к ним.
Наступает время сессии доработки. На нее команда пригласила Лорана, специа-

листа по картографированию, потому что на эту тему есть история, которую надо
доработать. Но похоже, что Лоран забыл о совещании! Сара звонит ему и узнает,
что у Лорана ЧП, но он уже едет и будет через пятнадцать минут. Чтобы не тратить
время, команда решает обсудить другие вопросы. Доработка проходит хорошо,
в результате получается много готовых историй: онлайн-оплата заказа, оценка
супа, партнерство с mesrecettes.com.
После совещания Сара остается с Лукой, чтобы обновить бэклог. Но ей звонит
Тео и сообщает, что сервер разработки упал. Сара оставляет бэклог Луке и спе-
шит к Тео. К счастью, достаточно перезагрузки сервера. Она пытается тактично
объяснить Тео, что тот вполне мог справиться с этим в одиночку.
130
У Сары есть немного времени до собрания в 16 часов, чтобы проанализиро-
вать причины крупного бага на прошлой неделе, поэтому она идет к участникам
команды, Лее и Мехди, которые занимаются историей «заказать суп дня». Сара
помогает им с критериями завершенности. Остается только добавить текст для
онлайн помощника. История будет закончена сегодня вечером!
Сара ведет обсуждение крупного бага, стремясь обеспечить согласованность
в работе над улучшением. Хм, причин целое множество. Об этом следует пого-
ворить с командой на завтрашней схватке.
Во благо команды
Во время утренней схватки Сара заме-
чает, что Леа чем-то обеспокоена. Она
решает увидеться с ней до конца рабо-
чего дня. Из разговора выясняется, что
Леа поссорилась с Тео. Стоит поговорить
с ним завтра. Сара раздумывает над тем,
чтобы во время следующей ретроспек-
тивы предложить паттерн «Niko-Niko».
Он помогает избегать таких ситуаций
и отслеживать настроение команды
за счет того, что каждый участник в кон-
це дня подбирает смайлик, наиболее
подходящий его состоянию.
Перед уходом Сара просматри-
вает свои сообщения и видит за-
прос от Пьера. Тот хочет забрать
Тео на два дня, пока идет демо
для клиентов. Посоветовавшись
с участниками команды, Сара вы-
нуждена честно отказать Пьеру,
поскольку это бы подорвало цель
спринта. Взамен, она предлагает
ему пригласить клиентов на сле-
дующий обзор.
131

участника команды
Мехди работает в PermaBio
уже два месяца.
Опоздание на схватку
Мехди добирается до офи-
са на велосипеде. Сегодня ут-
ром у него в дороге спустило
заднее колесо. Починка заня-
ла некоторое время, и, как бы
сильно он ни крутил педали,
ему не удалось успеть к нача-
лу схватки.
Он опоздал всего на три минуты, но процесс уже начался. Мехди тихонько при-
соединяется к команде и встает в полукруг перед доской. Когда очередь доходит
до него, он объясняет причину задержки и обещает на следующий день принес-
ти всей команде круассаны — это правило для опаздывающих. Он рассказыва-
ет, как обстоят дела с историей «заказать суп дня», над которой работает с Леей.
Мехди предполагает, что задача «создать форму для заполнения» будет завер-
шена в течение дня. Затем он должен синхронизироваться с Леей, чтобы прове-
рить завершенность истории, прежде чем передать ее Луке на проверку во вто-
рой половине дня. После этого он сможет помочь в какой-либо другой истории
или же начнет новую. Поскольку все отлично справляются и необходимости в его
помощи нет, Мехди возьмет в работу другую историю.
132
Фокус на задаче
Мехди берется за задачу «форма для заполнения». Он
устраивается поудобнее на своем рабочем месте, вклю-
чает плейлист, концентрируется и работает непрерывно
в течение 40 минут. Удовлетворен-
ный результатом, он идет на кухню,
чтобы налить себе кофе, после чего
возвращается к работе. Его ненадол-
го отрывает Леа, которая подходит
забрать эскизы для значков. К 11:30
он завершает работу над задачей,
сообщает об этом Лее и делает все
для того, чтобы Лука мог проверить
задачу во второй половине дня.
Начало новой истории

Работа над историей «заказать суп дня» завершена. Все остальное за Леей, пока
Мехди ждет проверку задачи от Луки.
Поэтому Мехди берется за новую историю —

«оценить суп». Он уже знает, о чем она, потому
что участвовал в ее доработке на прошлой не-
деле. Но чтобы лучше понять потребности биз-
неса, он приходит к Мари, которая объясняет,
почему эта история так важна: доверие клиен-
тов и желание заказывать у PermaBio складыва-
ется из хороших отзывов. Мехди возвращается
к своему столу и принимается думать. Было бы
неплохо обсудить все это с Тео. Но он в данный
момент занят, и Мехди не будет его беспокоить.
Во время завтрашней схватки он предложит
Тео поработать в паре в течение часа.
133
Время на размышление
Цель спринта побуждает команду добиваться результата. Но не стоит думать, что
спринт посвящен исключительно этому. Мы увидели, что у команды заложено
время, чтобы учиться и, следовательно, совершенствоваться. Работа в команде
состоит не просто в создании продукта; всегда, и особенно в интеллектуальной
сфере, очень важно РАЗМЫШЛЯТЬ.
Индивидуальное и коллективное размышление

Во время таких ритуалов, как планирование или ретроспектива, команда ду-
мает коллективно. Совместные размышления могут так или иначе происходить
во время спринта. Например, участники собираются вместе и думают над со-
держанием истории или решением по устранению препятствия и т. д. Во вре-
мя схватки участники могут назначать встречи, чтобы сообща над чем-то пораз-
мышлять.
Но командная работа, лежащая в основе Agility, вовсе не отнимает у участни-
ков возможность для индивидуальных размышлений. Думать своей головой
по-прежнему важно, чтобы не потонуть в коллективе.
Размышление в одиночку? Или совместно с другими? Выбор зависит от каждо-
го: от личности, характера, типа мышления.
Чтобы повысить эффективность размышлений, а иногда даже медитаций,
команда может установить удобные кресла или зону релаксации в специально
отведенном пространстве. Или, как вариант, участники могут вместе отправить-
ся на прогулку в лес или по набережной — совместные вылазки на природу по-
казали себя как отличный катализатор творческого мышления.
134
Жизнь, поделенная на части
Каждый день в команде похож на тренировки марафонцев. Он поделен на ин-
тервалы, которые следуют один за другим: в 9:30 схватка, до обеда индивиду-
альная работа и концентрация на своей задаче, в 14:00 доработка и т. д.
На протяжении спринта вся жизнь участников команды подобным образом по-

делена на части, отделяемые друг от друга схватками. Одни части состоят из ин-
тенсивной работы, другие отведены под размышления. Одни из них вовлекают
всю команду, другие оставляют время на индивидуальную работу.
Рабочий ритм
Стратегия, основанная на принципе чередования, состоит в структуризации
жизни посредством постоянной смены интенсивной деятельности и интроспек-
тивных перерывов.
Идея не нова и соответствует подходу, который пропагандировали стоики и тео-
ретизировал Сенека, говоря о преимуществах чередования звеньев жизненной
цепи.
Непрерывная работа ломает импульс духа; восстановить свои силы
можно лишь расслабившись.
Ритм, заданный спринтом, чередование коллективных ритуалов и более инди-
видуальной рутины, разделение между действием и самоанализом — вот что по-
зволяет команде жить интенсивно и долго.
А для тех, кого смущает слово «спринт» и метафора немалого, но краткосрочно-
го усилия, скажем, что в спринте участвуют истории, а не люди!
135
Глава 6
Пути
фокусировки
Глава 6 Пути фокусировки
Множество путей
Мы прошли путь, ведущий к первой ступеньке овладения Agility, первой зоне
модели. Чтобы сфокусироваться, команда PermaBio использовала Agile-микс,
включающий идеи Scrum, Экстремального программирования, Kanban и опи-
рающийся на основные Agile-ритуалы.
Этот путь, вероятно, был кратчайшим для команды PermaBio, и участники успеш-
но достигли своей цели. Но контексты для команд не всегда одинаковые.
Поэтому у каждой группы свой путь.
Команда может начать с Agile-микса, а потом сойти на другую тропу, если того
потребует ситуация. Это и есть Agility. Участники также могут вдруг осознать, что
поставленная цель недостижима, и ни один путь не приведет их к ожидаемым
результатам.
Какой бы маршрут команда ни выбрала, дорога будет проще, если участники хо-
рошо экипированы. Лучше потратить некоторое время на подготовку снаряже-
ния до начала первого спринта.
Этот период — прелюдия — используется командой для того, чтобы создать оп-
тимальные условия для фокусировки на цели и достижения Agility за один сезон.
138
Подготовка к путешествию
Прелюдия перед отправлением
Прелюдия — это период жизни команды от решения стать Agile до начала перво-
го спринта. Это время используется для того, чтобы рассказать всем участникам
экосистемы о новом способе работы и создать тем самым благоприятные усло-
вия для внедрения Agility.
Помимо составления первоначального бэклога, необходимого к началу сприн-
та, в течение прелюдии участники должны пройти через три последовательных
этапа:
О двух последних пунктах частенько забывают, что приводит к ложной Agility.

Стоит помнить, что команда не изолирована. Она развивается в среде, которая
включает заинтересованные стороны и рабочее пространство. Чтобы увеличить
шансы на успех, команде нужно вовлекать заинтересованные стороны и объяс-
нять, что именно от них требуется в рамках Agile-подхода. Наконец, перед нача-
лом первого спринта следует убедиться, что совместно выстроенная экосистема
позволит добиться результата.
Канва прелюдии
Канва прелюдии — это инструмент, помогающий команде подготовиться к пер-
вому спринту.
Канва, изображенная в виде таблицы с ячейками, представляет собой технику,
которая заметно упрощает творческую работу в коллективе.
Мы заполним все десять ячеек канвы для команды PermaBio.
139
Создать команду
1. Определить состав и роли. В команде PermaBio шесть участников. Мы зна-
ем, как были избраны люди на роли Scrum-мастера и Владельца продукта
(➥ страница 45).
2. Определить командную этику, то есть ценности, разделяемые всеми участ-
никами.
Участники команды PermaBio разделяют ценности пермакультуры.
Уже на этом этапе можно понять, насколько команда жизнеспособна и в со-
стоянии сфокусироваться на цели. Если есть какие-то сомнения, нужно
с ними разобраться как можно раньше.
140
Обеспечить согласованность между командой
и заинтересованными сторонами
3. Перечислить заинтересованные стороны (➥ страница 46).
4. Определить природу отношений между командой и заинтересованными сто-
ронами.
Мари — заинтересованная сторона, которая хорошо знает свою сферу дея-
тельности; команда стремится поддерживать с ней контакт и всячески со-
трудничать. Пьер, основатель компании, обладает соответствующими пра-
вами и авторитетом. Виктор, менеджер по продажам, часто считает, что его
задачи самые срочные. Чтобы избежать перебоев в работе из-за давления
руководства и возникновения срочных задач, Пьер, Виктор, а также Мари
прошли обучение Аgilе.
5. Разработать смысл и цели экосистемы, общее видение.
Пьер рассказал о смысле PermaBio и поделился со всеми своим видением
(➥ страница 24).
6. Определить контекст, чтобы выбрать свой путь.
Команда PermaBio следовала Agile-миксу, представленному в этой книге.
Участники приняли решение о двухнедельных спринтах, начинающих-
ся по средам, и о сезонах, чья продолжительность составляет три месяца.
Команда также зафиксировала дни и время проведения ритуалов.
Построить экосистему
7. Создать благоприятную среду для достижения результата.
В течение прелюдии команда PermaBio реализовала небольшую историю
из первоначального бэклога, чтобы проверить свою способность успешно
использовать среду разработки.
8. Сформулировать правила жизни в команде.
О срочных задачах ➥ страница 92.
О принятии решений ➥ страница 94.
9. Создать рабочее пространство для команды.
Команда PermaBio находится в одном рабочем пространстве; участники ор-
ганизовали свободное место перед стенами для внедрения визуального ме-
неджмента в работу.
10. Договориться о том, что можно считать завершенным (➥ страница 62).
141
Выбор пути
Команда принимает решение о том, какой выбрать путь, когда начинает запол-
нять ячейку n°6 канвы прелюдии — контекстуализацию.
Как определить контекст экосистемы? При помощи нескольких характеристик,
каждая из которых влияет на выбор пути.
• Динамика изменений: много или мало срочных задач?
• Экономическая модель: разработка полностью выполняется внутренней
командой, или есть аутсорсные участники из других организаций?
• Географическая разрозненность: команда находится в едином рабочем про-
странстве, или есть участники, работающие удаленно?
Если срочных задач не так много, команда состоит из сотрудников одной органи-
зации и находится в едином рабочем пространстве, то Agile-микс, выбранный
командой PermaBio, будет лучшим вариантом. Если нет, всегда можно рассмо-
треть другие варианты. Три пути, представленные ниже, адаптированы для си-
туаций, которые наиболее часто встречаются в командах: непрерывный поток
срочных задач, аутсорсинг и разрозненная команда.
При внедрении Agility не нужно быть догматичными. Наоборот, всегда следует ис-
кать свой собственный путь, и он может отличаться от Agile-микса и вариантов
ниже. Но начинающим командам без опытного проводника рекомендуется все же
придерживаться проторенных дорожек, потому что любые другие могут в конеч-
ном итоге привести к ложной Agility (о которой мы с вами говорили в главе 1).
142
Путь постоянного потока
срочных задач
Мы видели, как команда PermaBio отреагировала на срочную задачу по сбо-
ру абрикосов, пока не начался град. Ее выполнение не поставило под сомне-
ние цель спринта. Но климат может меняться, и подобные ситуации, вредящие
сельскохозяйственным культурам, могут возникать чаще. Цель спринта в таком
случае необходимо постоянно пересматривать и корректировать, и в конечном
счете она потеряет всякую актуальность.
Непрерывный поток новых запросов, которые нужно быстро разрешать, несо-
вместим с достижением цели спринта.
Когда нет четко поставленной цели, команда не может сфокусироваться на цен-
ности. Тогда первостепенное значение обретает концепция ограничения работы
(см. страницу 88), помогающая участникам сконцентрироваться на задачах и со-
хранить командный дух. Этот вариант больше ориентирован на работу с Kanban,
откуда и взялась идея ограничения.
Вместо плана спринта с его классическими столбцами «к выполнению, в про-
цессе, завершено», Kanban-доска может изображать статус обработки запросов.
Например, эта таблица может включать специальную колонку для тестирования,
команде лишь нужно не забывать о верхних пределах и не скапливать задачи.
Цель спринта не нужна, и сама концепция спринта в таком случае тоже под во-
просом. Тем не менее для лучших результатов рекомендуется проведение ритуа-
лов, причем на регулярной основе, а не по запросу. Ежедневные схватки и, на-
пример, ретроспектива каждые два месяца помогут команде стать Agile.
143
Путь аутсорсинга
Все участники команды PermaBio состоят в одной организации. Но бывают ситуа-
ции, когда к ним присоединяются люди «со стороны», например аутсорс-штат.
Такой путь может довольно быстро привести к ложной Agility, если заинтересо-
ванные стороны из одной или другой организации оступятся и вернутся к преды-
дущей модели. Чтобы этого избежать, стоит взять на заметку несколько советов,
в частности: 1) использовать этап прелюдии для создания жизнеспособной эко-
системы, состоящей из обеих организаций, 2) выделить участникам их собствен-
ное рабочее пространство и обеспечить доверительную обстановку как внутри,
так и снаружи команды.
Представим ситуацию, в которой Пьер решает нанять аутсорс-штат для разработ-
ки новой услуги. Он выбирает компанию, которая уже участвовала в Agile-про-
ектах и готова работать в пространстве PermaBio. Контракт рассчитан на один
сезон.
Компания предлагает ему своего Владельца продукта, но Пьер не соглашается —
и правильно делает. Эта роль требует хорошего знания в области бизнеса, а де-
легированные ей полномочия сложно передать внешней организации. Таким
образом, Лука остается Владельцем продукта.
Даже если все пойдет хорошо, вполне вероятно, что Пьер захочет узнать, что он
получит за свои деньги. Он запросит прогнозы на конец сезона. И скорее все-
го, руководитель аутсорсинговой компании будет внимательно следить за коли-
чеством затраченного каждым сотрудником времени, потому что для него это
обычный способ составления счетов.
Все это усложнит команде путь. Придется ответить Пьеру и разработать план
на сезон. Команда вынуждена делать оценки. Поскольку у нее еще нет доста-
точного опыта совместной работы, прогноз получится весьма неопределенным.
В общем, команда будет двигаться, но ее прогресс замедляется из-за постоянных
трений между двумя организациями и их требованиями к оценкам и прогнозам.
144
Путь географически
разрозненной команды
Все участники команды PermaBio работают в одном пространстве.
Но представим следующую ситуацию. Леа работает удаленно из дома. Мехди
переехал в другую часть города и больше не может приезжать на велосипеде
в офис. Тео работает вне офиса два дня в неделю.
Подобная разрозненность налагает на команду ряд ограничений. Необходимо
скорректировать ритуалы, которые изначально планировались как мероприя-
тия с личным присутствием каждого участника.
Но для начала всем надо как следует узнать друг друга во время прелюдии. Команде
нужно провести несколько дней вместе — только в этом случае они смогут сфокуси-
роваться на цели. Обязательное условие для разработки канвы прелюдии и планиро-
вания первого спринта — это участие всей команды в одном рабочем пространстве.
Зато разработка цели спринта может проходить удаленно. Существует много ин-
струментов для дистанционной совместной работы, команда внедряет их также
во время прелюдии.
Для ежедневной схватки необязательно находиться в одной комнате. Участники
могут присоединяться к ритуалу удаленно (при помощи видеоконференций, те-
лефона, фото Kanban-доски, веб-камеры, инструментов управления бэклогом).
Это касается и сессии доработки, которая традиционно проходит в середине спринта.

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

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

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

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

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

чтобы добраться до конца запланированного маршрута.
Чтобы объективно оценить ситуацию, во время обзора команда спрашива-
ет заинтересованные стороны, принесла ли она им ценный результат. Только
та команда, что регулярно производит ценность, сфокусирована на цели.
В дополнение к этой оценке результата, во время ретроспективы команда спра-
шивает себя, что еще нужно сделать, чтобы достичь цели. Вопросы ниже пред-
ставляют собой хорошую пищу для размышлений:
• чего нам не хватило, чтобы стать командой ПАЛАС?
• что мы можем улучшить в ролях Scrum-мастера и Владельца продукта?
• достаточно ли наш бэклог доступный, конструктивный, упорядоченный,
уникальный, живой и развивающийся? Если нет, что нам для этого необхо-
димо сделать?
• что мы можем сделать, чтобы наш результат был ДИВным?
• как улучшить проведение ритуалов?
На основании полученных ответов команда определяет, на что ей нужно обра-
тить внимание в дальнейшей работе, и, конечно, должна ли она изменить свой
путь.
148
Двигаться дальше,
учитывая ситуацию
Случается, что анализ обстановки показывает: команда не приносит ожидаемой
ценности. Тогда участникам следует применить свои навыки адаптации и сме-
нить выбранную тропу.
Смена курса на бизнес-ценность

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

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

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

треть ситуацию, сделать выводы и начать все сначала.
151
Достичь цели
Конец сезона
В конце одного сезона и до перехода к следующему команда на несколько дней
прекращает свой «спринтерский забег».
За это время участники делают паузу и переключаются на что-то другое.
Вот, чем можно заняться в этот период:
• отметить успех команды;
• поразмышлять о способе работы в следующем сезоне и возможных новых
практиках;
• подготовить при необходимости изменение в составе команды и обучить но-
вичков;
• очистить и подготовить к следующему сезону бэклог;
• определить цель следующего сезона.
Оценка
Именно в этот период команда отвечает на главный вопрос: смогли ли мы сфо-
кусироваться на цели? стали ли мы Agile?
Хорошо, если в обсуждении участвует вся команда, а также заинтересованные
стороны, так как достижение цели определяется за счет регулярного предостав-
ления им ценности. Поэтому нормально спрашивать их мнение.
Празднование
Получилось! Ретроспектива в конце сезона завершена, команда успешно пере-
шла в зону «Фокуса». Что дальше?
Конечно, нужно отметить! Празднование успехов команды — это отличный спо-
соб вдохновить и мотивировать участников продолжать свой путь.
По правде говоря, для празднования не нужно ждать конца сезона, потому
что каждое завершение спринта — уже повод хорошо провести время вместе.
Ну а празднование окончания сезона должно быть грандиозным, ведь на него
приглашаются заинтересованные лица и наутро не нужно спешить на схватку…
Команда PermaBio стала Аgile!

Команде PermaBio удалось сфокусироваться за один сезон, то есть три месяца.
Это отличный результат! Некоторые команды закладывают на это больше време-
ни и все равно не успевают.
Успех команды заключается не столько в достижении Agility, сколько в том,
что она регулярно приносит ценные результаты заинтересованным сторонам.
152
Первая версия продукта была развернута за месяц, и теперь клиенты могут за-
казывать блюда онлайн и делиться обратной связью с командой. Ежедневно
PermaBio поставляет более 100 блюд.
Уже совсем скоро команда возьмет в работу следующую услугу: сбор отходов для
компостирования. К ним приходят первые запросы от пользователей, так что со-
ответствующая история, как наиболее приоритетная, перемещается на первую
строчку в бэклоге.
Ну а сейчас участники готовятся к празднику. Они организуют большую вечерин-
ку, на которой уж точно не будет никакого супа!
В качестве тоста
Пьер произносит краткую вступительную речь, в которой напоминает, как мно-
го клиентов пользуются новой услугой благодаря Agility. Он говорит, что команде
предстоит реализовать еще множество функциональностей за эти полгода. Сре-
ди них в том числе управление поставками, хотя первые спринты показали, что
в этом нет смысла.
Но сейчас пускай команда PermaBio фокусируется на вечеринке, а мы вернем-
ся к нашим «Кроликам».
153
Как
Глава 6
усовершенствовать
свой уровень Agile
Глава 6 Как усовершенствовать свой уровень Agile
Что дальше? Сперва —

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

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

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

Поразмыслив, ребята решают вложиться в улучшение своей музыкальной тех-
ники. Клара единственная, у кого есть классическое образование, остальным же
придется осваивать сольфеджио.
В их выступлениях должна быть изюминка, которая поможет увеличить количе-
ство слушателей и привлечь организаторов музыкальных фестивалей и конкур-
сов. Саймон предлагает выходить на сцену в костюмах кроликов, и остальные
участники группы поддерживают эту идею.
В Agile-команде все так же. Чтобы идти дальше, команды, достигшие первой
ступеньки овладения Agility и сумевшие сфокусироваться на цели, должны вло-
житься в улучшение своих технических навыков.
В реальности же, вероятно, более половины команд этого не делают, потому что
потраченное время вызывает временное снижение производительности. «Иг-
рать гаммы и повторять одно и то же, пока пальцы не привыкнут», нужно во всех
сферах деятельности, не только в музыке.
Командам, действующим в области программного обеспечения, следует сосре-
доточиться на инженерных практиках. Сейчас на каждом углу кричат о цифро-
вой трансформации; методология, направленная на быструю и частую поставку
ПО, называется DevOps.
В зависимости от того, обладают участники какими-либо навыками или еще нет,
сфокусированной на цели команде потребуется от 3 до 24 месяцев для достиже-
ния технического совершенства.
Результат: предоставление ценности по запросу

«Agile-кролики» тренируются вот уже несколько месяцев. Их усилия не напрасны,
группа далеко продвинулась в технике исполнения. Благодаря Кларе, которая на-
ладила контакты, они теперь узнаваемы. Музыканты часто играют на сценах сво-
его города. Иногда их узнают на улице, и это каждый раз очень приятно.
158
15 8
Благодаря Саймону у группы появляется собственный веб-сайт, на котором му-
зыканты публикуют свою песню «Дедлайн». Она мгновенно разлетается по сети,
становится хитом и звучит на радио.
Владение техническими навыками позволяет Agile-команде всегда поставлять
качественный конечный продукт. Это качество ощущают:
• пользователи, которые не видят в продукте ошибок и ценят простоту исполь-
зования;
• участники команды, которые легко обрабатывают пользовательские запросы
ввиду отсутствия технических недостатков.
Технически подкованная команда обеспечивает ценные результаты, отвечаю-
щие требованиям бизнеса.
Продолжать или остановиться?

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

щаются тому, где они теперь! Все-таки жизнь прекрасна.
Сейчас группа владеет отменной техникой игры и освоила разнообразный ре-
пертуар. Джимми и Клара хотят продолжать восхождение к славе и в конечном
итоге убеждают двух других участников последовать за ними.
В команде, достигшей своего технического совершенства, возникают те же во-
просы. Потому что все прекрасно понимают, что подниматься дальше по Agile-
лестнице будет непросто: придется менять структуру организации.
159
Оптимизация ценности
«Аgile-кролики» все-таки решились следовать мечте и стать рок-звездами. Они
готовы покорять мир своей музыкой.
Необходимые условия: изменить структуру организации

Для этого им нужно изменить размер команды. Они подписывают контракт
с лейблом и нанимают пиар-менеджера для связи с организаторами концертов.
Благодаря этому у Клары появляется больше времени, и она может посвятить
себя музыке.
То же самое происходит и в Agile-команде. Чтобы компания могла оптимизиро-
вать ценность, предоставляемую пользователям, и стать лидером на своем рын-
ке, необходимо встряхнуть организацию.
Для лучшего понимания рынка команда обращается к заинтересованным сторо-
нам. Владелец продукта начинает выполнять свои функции на более ранних ста-
диях жизненного цикла продукта. Для проверки гипотез будут применяться та-
кие техники исследования, как, например, Lean Startup.
Если для фокусировки на цели или овладения техническим совершенством
команды могут оставаться относительно независимыми от организации, то для
оптимизации ценности все иначе.
Чтобы освоить всю цепочку, от запроса до использования, нужно скорректиро-
вать состав команды. Цель этого в том, чтобы помочь командам работать ста-
бильно и слаженно.
160
16 0
Результат: оптимизация ценности
«Agile-кроликам» понадобилось три года, чтобы осуществить свою мечту. Они
стали известной группой. Теперь они собирают огромные залы и выступают
на крупных фестивалях.
Выпуск новых альбомов и частые турне еще больше вдохновляют их создавать
музыку и радовать поклонников по всему миру.
Команда, оптимизирующая ценность, может строить гипотезы и проверять их,
не полагаясь на экспертов, которые, к тому же, не всегда доступны. Она умеет
принимать правильные решения касательно продукта.
Ключевой момент при оптимизации ценности — это то, что команда самостоя-
тельно и свободно управляет своим бюджетом.
Именно в этой зоне модели сбываются все обещания Agility. Популяризованный
Джеффом Паттоном принцип «минимизировать затраты, максимизировать
результат» обретает полный смысл.
Продолжать или остановиться?

«Аgile-кролики» могли бы остановиться здесь, на вершине своей славы, получая
деньги с продаж и выступая с отработанным репертуаром.
Но они хотят поделиться знаниями и опытом, чтобы принести пользу молодым
группам, которые только начинают свой путь. Им также хочется поэксперимен-
тировать с музыкантами других стилей и жанров.
То же самое и с Agile-командой, которая смогла оптимизировать свою ценность.
Скорее всего, она захочет передать бесценный опыт другим командам.
161
Усиление
«Agile-кролики» хотят делиться накопленными знаниями и продолжать разви-
ваться — в том числе благодаря новым знакомствам.
Во благо экосистемы
Вдохновленные всемирной известностью, но помнящие о том, как трудно начи-
нать, «Agile-кролики» готовы делиться опытом. Они создают лейбл, который от-
ныне помогает молодым музыкантам начать карьеру. Это очень нравится Берту,
и он проводит много времени, консультируя новые группы. Он приглашает их за-
писываться в свою студию с ультрасовременной техникой.
Agile-команда, успешно оптимизировавшая ценность, может пойти дальше, уси-
лив Agility своей экосистемы:
• изобретая новые практики для стимулирования инноваций;
• оптимизируя всю цепочку создания ценности, в том числе звенья этой цепи, от-
носящиеся к другим отделам или даже организациям.
Усиление Agility тесно связано с экспериментированием с другими формами
управления. В книге «Reinventing Organizations» Фредерик Лалу приводит не-
сколько примеров компаний, которые внедрили новые формы управления.
162
Познавать новое через обмен с другими
В музыкальном плане каждый участник группы волен проявлять инициативу,
а открытость новым музыкальным культурам приносит им новые радости.
Джимми время от времени играет с джазовыми исполнителями. Импровизации
с ними вдохновляют его и рождают идеи, которые можно воплотить с «Agile-кро-
ликами».
Участники опытной Agile-команды обычно с удовольствием передают знания

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

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

А могла быть совсем другая история: «Agile-кролики» поучаствовали бы в музы-
кальном фестивале и поняли, что идти дальше и совершенствоваться они не хо-
тят, тем более что нет ни времени, ни денег на тренировки и занятия сольфе-
джио.
Иногда Agile-команды достигают зоны «Фокус на цели» и останавливаются
на этом. Так обстоит дело, например, когда команда разрабатывает версию про-
дукта, чтобы важный клиент понял, что ему нужно. Эта версия выполняет свою
задачу — она служит для проверки гипотезы, но не предназначена для «инду-
стриализации».
Когда продолжительность жизненного цикла продукта коротка, не нужно чрез-
мерно много инвестировать в его качество. Ценность достигается за счет уроков,
которые команда извлекает из процесса.
Перед тем как идти дальше, нужно сфокусироваться на цели

Команда может хотеть стать более Agile не для того, чтобы быть лучше других ко-
манд, но чтобы достигать лучших результатов. Это амбициозный путь, который,
тем не менее, потребует новых инвестиций, а также времени, что только силь-
нее отдаляет цель. Agility же подталкивает нас ставить более близкие цели и ра-
ботать в коротких итерациях. Поэтому начинать с фокусировки не так рискован-
но, как, например, с оптимизации.
Вдобавок, если вас действительно интересует практика, связанная с оптимиза-
цией (например, Lean Startup), ничто не мешает вам попробовать ее, даже если
ваша приоритетная задача — овладеть основами Agility.
164
Фокусировка нужна, чтобы не прийти к ложной Agility
Популяризация Agility рождает большой интерес, и это замечательно. Но это
усложняет выбор для команд. С чего начать? Как научиться завершать задачи,
а не начинать все время новые? Как не упасть в ложную Agility?
Стремление к фокусировке на цели создает рамки для команды, направляя ее
к тому, что важно в первую очередь, — к коллективной культуре.
Искусство быть Agile-командой: попробуйте сами!

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

Red Hat
История от Алексиса Монвиля, Engineering Leadership Team, Red Hat®.
Организация
Red Hat разрабатывает программное обеспечение для бизнеса с 1993 года со-
гласно модели разработки с открытым исходным кодом. Мы считаем, что, со-
трудничая с широкой сетью ИТ-лидеров, сторонников open source, разра-
ботчиков и партнеров, нам удастся создавать решения, наилучшим образом
соответствующие будущему информационных технологий.
Нашей отправной точкой стал Red Hat® Enterprise Linux®. Сейчас же мы выпу-
скаем большую линейку продуктов и услуг, построенных по той же открытой биз-
нес-модели, поддерживающей сотрудничество, а также по модели с доступной
и удобной подпиской.
Проблема
Когда я присоединился к Red Hat после его слияния с eNovance, команды, с кото-
рыми я собирался работать, ясно дали знать, что Scrum и Agility им не подходят.
Их прошлый опыт сильно напоминал то, что Клод называет ложной Agility. Встал
вопрос о том, насколько эта трансформация нужна.
Но в нашей области Agility, которая, конечно же, не является самоцелью,
по-прежнему остается естественным и надежным подходом к постоянному пре-
доставлению ценности, радуя наших пользователей.
Решение
Фокус на цели, о котором говорит Клод, был первым шагом на избранном нами
пути. Мы объединились в небольшие кроссфункциональные команды. Каж-
дая точно вывела для себя роль, а также все возможные взаимосвязи с други-
ми командами. Мы обучили менеджеров, поощряя их более четко делегировать
свои полномочия.
Делегирование функций происходило в соответствии с ролями внутри команды.
После первого неудачного опыта нам пришлось изобрести собственную терми-
нологию. В итоге мы получили User Advocate, или адвокат пользователей, и Team
Catalyst, или катализатор команды.
166
Вывод
Определение ролей помогло команде понять и согласовать между собой функ-
ции каждого участника. Адвокат пользователей отвечает за то, чтобы команда
знала, что она делает и для чего, в то время как катализатор команды следит
за тем, чтобы команда придерживалась выбранного курса и совершенствова-
лась.
Еще один важный аспект нашего изменения — это согласование целей команды

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

культуры в Legrand
История, рассказанная Клодом Андрие, R&D-менеджером в компании Legrand,
занимающейся электрическими и информационными системами зданий.
Продукты, разрабатываемые Legrand Building Systems, могут быть интегриро-
ваны в системы пожарной безопасности и освещения, а также для управления
другим электрическим оборудованием в зданиях. Они предназначены для ме-
ждународных рынков с нормативными ограничениями. Команды R&D выполня-
ют разные функции: это проектировщики механической и электронной аппа-
ратуры, разработчики встроенного программного обеспечения, разработчики
веб- или мобильных приложений, а также тестировщики, специалисты по каче-
ству и технические редакторы.
Проблема
Сталкиваясь в течение нескольких лет с трудностями при выпуске новых продук-
тов, отдел R&D в 2016 году принял решение начать Agile-трансформацию. Она
стартовала плохо, в узких кругах и без какой-либо поддержки. Непонимание ме-
жду руководством и сотрудниками, усиленное социальной напряженностью, бы-
стро свело все усилия на нет.
Именно в этот период я присоединился к Legrand в качестве R&D-менеджера.
Все указывало на то, что успешно завершить Agile-трансформацию невозможно.
Большая компания из CAC 40 (САС 40 — важнейший фондовый индекс Франции. —
Прим. пер.) с пирамидальной организацией и жестким финансовым менеджмен-
том, основанная на культуре контроля, планирует перейти на Agility, тем самым
спасая одно из своих подразделений? Все говорили, что затея обречена на провал.
Решение
Начать все сначала мы смогли благодаря тому, что сделали акцент на изменении ко-
мандной культуры. Почти все сотрудники R&D, а также заинтересованные стороны,
непосредственно связанные с разработкой продукта, такие как маркетинг, закупки,
логистика, промышленные методы, прошли Agile-обучение. В то же время велась
работа над укреплением взаимоотношений внутри команды и с заинтересованны-
ми сторонами. Был реализован открытый форум для решения многих вопросов,
не связанных с проектами разработки продуктов. Проводились рабочие встречи,
на которых особое внимание уделялось важности кроссфункциональной команды
и эмпирического подхода. Не все привели к значимым изменениям, но в результа-
те команды стали автономнее и за пределами проводимых ритуалов.
168
Одна из таких рабочих встреч, к примеру, привела к капитальному ремонту по-
мещения R&D. Рабочее пространство теперь заточено под кроссфункциональную
команду и разнообразие функций (и их ограничения), чтобы обеспечить макси-
мально широкое размещение всей команды в одном месте. Центральная мастер-
ская прототипирования теперь доступна для совместной работы. В рабочем
пространстве каждой команды есть место для доски, где визуализирована вся ин-
формация по проектам, а также «зона конвергенции», где участники могут встре-
титься с заинтересованными сторонами. Вокруг производственной территории
расположены офисы постоянных или временных заинтересованных сторон.
Все команды, в состав которых входит от 5 до 15 человек, включая заинтересо-
ванные стороны, проводят Scrum-ритуалы (планирование, схватка, демонстра-
ция, ретроспектива) и систематически пользуются Kanban-доской. Члены R&D
естественным образом переквалифицировались во Владельцев продукта или
Scrum-мастеров, вне зависимости от того, менеджеры они или дизайнеры, ру-
ководители или обычные сотрудники. Был даже случай, когда Владелец продук-
та был выбран командой кооптационно.
В нашем промышленном контексте невозможна поставка потребителю частич-
но выполненных продуктов в конце каждого спринта. Но желание собрать боль-
ше обратной связи привело к появлению «супер-демонстраций», так называе-
мых «meet ups», которые проводятся в более открытом пространстве, нежели
обычные помещения команд разработчиков, чтобы иметь возможность вовле-
кать всех сотрудников компании и потенциальных клиентов.
Для актуализации контекста регулярно, но не ежедневно, проводится схватка,
и раз в неделю в том случае, когда ритм производства (электроника, механика
или программное обеспечение) не требует ежедневной синхронизации.
Вывод
Многим командам удалось поставить продукты конечным пользователям менее
чем за два года (чего никогда раньше не случалось). На данный момент они под-
держивают бэклог и разрабатывают новые функциональности.
В итоге за два года компания прошла свой путь, на лица вернулись улыбки, ста-
ли появляться новые инициативы, команды достигли первых успешных резуль-
татов. Но это еще не конец: осталось много вопросов.
На сегодняшний день в компании много Agile-команд, достигших зоны «Фокуса
на цели». Другими словами, участники команд и заинтересованные стороны те-
перь думают с точки зрения ценности для потребителя, даже если их решения
иногда могут базироваться на иных приоритетах и быть не столь клиентоориен-
тированными. И если уже произошла поставка продукта, необходима его под-
держка на постоянной основе и регулярное применение Agile-практик и ри-
туалов. Следующей ступенькой станет консолидация технических компетенций,
относящихся к профессии (craftmanship), что укрепит доверие внутри команд
и повысит их жизнеспособность.
169
Оценка уровня Agility команд

в BNP Paribas
Этой историей поделился Ян Ван Дравик, отвечающий за Agile-трансформацию
и DevOps в BDSI.
BDSI, дочерняя компания группы BNP Paribas, созданная в 2004 году, занимает-
ся управлением и развитием информационной системы четырнадцати банков
в Африке и за рубежом. BDSI — инновационная организация, модернизирующая
методы работы в рамках цифровой трансформации группы BNP Paribas.
Проблема
Наша Agile-история началась в 2015 году, когда первая команда разработчиков
внедрила Scrum в свои процессы, затем появилась вторая команда, третья, а по-
сле этого еще две, обратившиеся к Kanban.
В 2017 году мы захотели единого Agile-подхода в ИТ-отделе, а также расширить
наши ноу-хау и укрепить культуру DevOps. В то время мы были разнородной
компанией с точки зрения используемых технологий — от «большого» основно-
го бизнес-приложения до небольших, новых, более диджитальных. То же самое
можно сказать и о нашем составе: на тот момент одновременно существовали
и Scrum-команды, и те, кто в лучшем случае слышал об Agility и чувствовал, что
их оставили позади.
Кроме того, мы хотели иметь возможность оценивать нашу Agile-трансформа-
цию, чтобы понимать, какие цели перед собой ставить.
Но в конце концов мы поняли, что это изменение не следует навязывать коман-
дам. Мы должны уделять больше внимания культуре и учитывать каждый кон-
кретный контекст.
Решение
Мы искали прагматичный подход к измерению нашего уровня Agility.
Когда Пабло Перно предложил путешествие с моделью Agile Fluency в качестве
компаса, этот подход нам показался вполне подходящим. Многим командам по-
надобилась поддержка коуча, чтобы точно определить, где они находятся, и на-
чать двигаться к большей Agility.
Поэтому все команды прошли тренинг. Ознакомившись с моделью, участники
между собой согласовали уровень, которого хотели бы достичь в среднесрочной
перспективе, а затем с помощью коуча определили зону, в которой находились
170
на тот момент. Заключительная часть тренинга была посвящена практикам, не-
обходимым для достижения цели.
В результате появилась таблица практик, разделенных по четырем столбцам: «неже-
лательные», «нужно приобрести», «в процессе приобретения» и «приобретенные».
На основе этой таблицы команды приняли решения, в каком направлении им

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

на написание этой книги
Глава 1: Зачем становиться Аgile?
• Agile Manifesto, 17 авторов, 78 слов. В Agile-манифесте содержится двенадцать
основных принципов Agility. Надо отметить, что почти двадцать лет спустя сам
текст остается неизменным. Его регулярно пытаются обновить, особенно при-
ложение. Наиболее значительным изменением можно назвать Modern Agile
Джошуа Керевиески.
• Post-industrial project, Майк Гриффитс. Приведенные здесь различия ме-
жду умственным и физическим трудом основаны на этой статье из его блога
Leadinganswers.com. Я адаптировал несколько характеристик. Гриффитс так-
же стал автором справочника по сертификации PMI-Agile. Понятие «умствен-
ный труд» (knowledge work в англоязычной Википедии) пришло от Питера Дру-
кера, гуру менеджмента.
• The State of Agile Software in 2018, Мартин Фаулер. Статья представляет со-
бой запись выступления на конференции в Сиднее. Именно там он впервые
произнес термин «ложная Agility». Мартин Фаулер известен своими знаниями
и опытом в области разработки программного обеспечения (новое издание
его книги «Refactoring» было опубликовано в 2019 году), а также своим виде-
нием Agile-движения.
• Accelerate!, Николь Форсгрен, Джес Хамбл, Джин Ким. Эта книга — результат
многолетнего полевого исследования. С помощью статистических методов,
описанных во второй части доказывается эффективность практик, применяе-
мых в Lean, DevOps и Agility.
• Agile Fluency, Джеймс Шор и Диана Ларсен. Модель Agile Fluency появилась
в статье, опубликованной еще в 2012 году; обновленная версия была выпуще-
на в 2017 году. Я немного адаптировал эту модель, выйдя за пределы программ-
ного обеспечения, и переименовал вторую зону «поставка» в «техническое со-
вершенство». Agile Fluency — это лишь модель, но в то же время она задает курс
и становится путеводителем для команды. Моя книга в основном посвящена
зоне фокусировки, достижение которой позволяет команде стать Agile.
• В ногу с принципом избавления от всего, что препятствует становлению Agility,
шагают идеи Алистера Кокберна, одного из подписантов Agile Manifesto (Heart
of Agile и Shu Ha Ri).
Глава 2: Команда в экосистеме

• Changing your Team from the Inside, Алексис Монвиль. Вслед за Алексисом
я процитировал Бенджамина Франклина, когда говорил о размере группы.
В его книге есть множество других интересных ссылок, и, хотя в ее названии
не фигурирует слово «Agile», она содержит много полезной информации для
команд, которые хотят достичь Agility.
172
• «Словарь влюбленных в регби», Даниэль Эрреро. Прекрасные примеры со-
трудничества во время схватки или красивого паса на поле. Спортивные ме-
тафоры часто используются в речи Agility. Мы поняли, что некоторые из них
подходят меньше остальных, например «спринт», но регби остается велико-
лепной иллюстрацией командной работы и коллективного разума.
• Agile-толпа, Пабло Перно. Шаг назад в те времена, когда индустриальная мо-
дель еще не разрушила автономию общества. Содержит ссылку на работы Ро-
бина Данбара о наиболее оптимальном размере групп.
• Management for Happiness, Юрген Аппело. Я использовал его пример с фут-
болками, чтобы проиллюстрировать идею идентичность команды. Аппело на-
писал несколько книг по Менеджменту (3.0). Management for Happiness — это
иллюстрированная версия предлагаемых им практик.
• Joy, Ричард Шеридан. Эта книга рассказывает историю Menlo, сервисной компа-
нии, сумевшей достичь Agility за счет систематической практики работы в парах.
• «Вера в себя», Шарль Пепен. Я процитировал различные типы веры и приме-
нил их к Аgile-команде. Пепен ведет колонку в журнале Philosophie Magazine.
«Вера в себя» — его последняя работа (2018).
Глава 3: Цикл обратной связи

«Инструкция по применению Agile-практик», Клод Обри. Цикл обратной свя-
зи — понятие, пришедшее из кибернетики и часто используемое в изучении
комплексных систем, как, например, системология или пермакультура, о кото-
рых мы говорили в пятом издании моей книги. В ней я ввожу термин «сезон».
Также там можно найти подробный анализ структуры и доработки бэклога.
Глава 4: Ритуалы спринта

• «Путеводитель по Scrum», Кен Швабер и Джефф Сазерленд. В «Путеводителе»
впервые звучат такие принципы эмпиризма, как видимость, инспекция и адап-
тация. То, что я называю «ритуалами», в «Путеводителе» значится как «события».
• «Вера в себя», Шарль Пепен. Благодаря этой книге я принял решение исполь-
зовать слово «ритуал», когда говорю о событиях спринта.
• «Маленький принц», Антуан де Сент-Экзюпери. Прекрасная книга, чтобы на-
чать разговор о ритуалах.
Глава 5: Новая культура на ежедневной основе

• «Искусство прокрастинации», Джон Перри. Хотя прокрастинация несовме-
стима с Agility, иногда она помогает избавиться от ложных срочных задач, ко-
торые со временем исчезают сами по себе. В этой книге блестяще передано
чувство удовлетворения от завершения задачи.
• «Kanban, подход к выполнению задач в потоке в Agile-организации», Лоран
Мориссо, Пабло Перно. Я использую концепцию верхнего лимита, о которой
можно подробно узнать в этом справочнике.
• «Положительные аспекты неудачи», Шарль Пепен. Право на ошибку и даже
неудачу — это настоящий переворот во французской культуре и особенно в обра-
зовании. Полезная книга для тех, кому, как и мне, внушили страх перед неудачей.
173
О том, что вдохновило нас на написание этой книги
Глава 6: Пути фокусировки

• «Инструкция по применению Agile-практик», Клод Обри. Понятие «прелю-
дии» появилось в пятом издании этой книги. Также из нее можно подробнее
узнать о контекстуализации и миксе двух методологий — Scrum и Kanban.
• «Kanban, подход к выполнению задач в потоке в Agile-организации», Лоран
Мориссо, Пабло Перно. Когда команда сталкивается с непрерывным потоком
срочных задач, сфокусироваться на цели и стать Agile ей помогает Kanban,
а также распределение ролей в команде и регулярное проведение ритуалов.
Как говорят Лоран и Пабло, Kanban может применяться и в других контекстах,
на других уровнях, с целью стать Agile или без нее.
• «Культура Agile», Жан-Клод Грожан. В этой книге содержится масса полезных
советов для команды, например, о том, как организовать удаленную работу,
если участники команды не находятся в одном рабочем пространстве. Также
в ней представлены инструменты, с помощью которых можно изменить куль-
туру организации.
Глава 7: Как усовершенствовать свой уровень Аgile

• Fluent@agile — visualizing your way of working, Питер Антман. В статье расска-
зывается о воркшопе на основе модели Agile Fluency, проведенном в Spotify.
Именно здесь появляется метафора музыкальной группы (весьма логично для
Spotify), которую я подхватил и развил с Пабло Перно во время Agile Raids,
и представляю вам в этой книге.
• Running Lean, Аш Маурья. Эта книга (переведенная на французский) доступ-
но и на примерах объясняет, как начать использовать Lean Startup в работе.
• «Story mapping — Визуализируйте ваши истории, чтобы создать каче-
ственный продукт», Джефф Паттон. Здесь раскрывается принцип «миними-
зировать затраты, максимизировать результат». Джефф — эксперт в том, что
касается определения продукта. Чрезвычайно полезно применять технику
story mapping во время прелюдии для определения первоначального бэклога.
• Reinventing Organizations, Фредерик Лалу, версия с иллюстрациями от Этьена
Аппера. Эта книга — мой первый и основной источник вдохновения. Именно
после ее прочтения у меня появилась идея написать иллюстрированную книгу
про Agility. И, как вишенка на торте, Этьен согласился стать ее иллюстратором.
Многие из этих книг обсуждались в Книжном клубе Agile Toulouse. Спасибо Эн-
тони Кассэню и Жан-Паскалю Буаняру за управление сей воодушевляющей ас-
социацией. Я добавляю к этим источникам вдохновения два сайта, которые сам
регулярно посещаю:
• Philonomist, онлайн-издание, философски рассуждающее о мире работы.
Оно было запущено в конце 2018 года в дополнение к журналу Philosophie
Magazine (постоянным читателем коего я являюсь вот уже несколько лет).
174
Оглавление
Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Владелец продукта. . . . . . . . . . . . . . . . . . . . . . . . . 48
Scrum-мастер. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Заинтересованные стороны . . . . . . . . . . . . 52
Как обрести веру . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Команда PermaBio
и ее экосистема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ГЛАВА 1
Зачем становиться Agile?. . . . . . . . . . . . 11
Agility — это что? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Сила слов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Немного истории . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Agility — это модно . . . . . . . . . . . . . . . . . . . . . . . . . . 18 ГЛАВА 3
Внимание — фальсификация! . . . . . . . . 20 Цикл обратной связи. . . . . . . . . . . . . . . . . . 59
И все же, почему Agility? . . . . . . . . . . . . . . . . 22 Рабочий поток . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
А что такое настоящая Agility? . . . . . . . . 24 Бэклог как список задач
для команды . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Agility и рок-н-ролл . . . . . . . . . . . . . . . . . . . . . . . . 26
Бэклог состоит из историй. . . . . . . . . . . . . . 64
У каждой команды своя цель . . . . . . . . . . 29
Бэклог PermaBio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Agile в фокусе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Спринт — это ТОП! . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Проект PermaBio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
T — Темп . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
O — Ориентир . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
П — План . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ДИВный результат! . . . . . . . . . . . . . . . . . . . . . . . . . 78
Сфокусироваться за один сезон . . . . . 80
ГЛАВА 2
Команда в экосистеме . . . . . . . . . . . . . . . 35
Кто? Команда ПАЛАС! . . . . . . . . . . . . . . . . . . . . . 36
П — Подходящий размер . . . . . . . . . . . . . . . . 38
А — Автономия. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Л — Личностность . . . . . . . . . . . . . . . . . . . . . . . . . . 42 ГЛАВА 4
А — Адаптивность . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Ритуалы спринта. . . . . . . . . . . . . . . . . . . . . . . . . 83
С — Стабильность . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Соблюдение обрядов . . . . . . . . . . . . . . . . . . . . . 84
175
Четыре ритуала спринта . . . . . . . . . . . . . . . . 86 Подготовка к путешествию . . . . . . . . . . . . 139
Планирование спринта . . . . . . . . . . . . . . . . . . 88 Выбор пути . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Ежедневная схватка . . . . . . . . . . . . . . . . . . . . . . . 94 Путь постоянного потока срочных
Обзор спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 задач . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Ретроспектива спринта . . . . . . . . . . . . . . . . . 105 Путь аутсорсинга. . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Привычка быть Agile . . . . . . . . . . . . . . . . . . . . . 112 Путь географически разрозненной
команды . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Начинать с малого . . . . . . . . . . . . . . . . . . . . . . . . 146
Анализ обстановки . . . . . . . . . . . . . . . . . . . . . . . 148
Продолжить путь с учетом анализа
обстановки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Вернуться и все начать с начала . . . 150
Отказаться от путешествия . . . . . . . . . . . . 151
ГЛАВА 5 Достичь цели . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Новая культура на ежедневной
основе. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Команда разрабатывает истории . . . 116
Доработка историй . . . . . . . . . . . . . . . . . . . . . . . 118
Обучаемая команда . . . . . . . . . . . . . . . . . . . . . . 120
Лицом к лицу со срочными
задачами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Принятие решений . . . . . . . . . . . . . . . . . . . . . . . 124 ГЛАВА 7
Один день из жизни Владельца Как усовершенствовать
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 свой уровень Agile . . . . . . . . . . . . . . . . . . . 155
Один день из жизни Scrum-мастера . . . 128 Что дальше? Сперва — закрепить
успехи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Один день из жизни участника
команды . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Техническое совершенство . . . . . . . . . . . 158
Время на размышление . . . . . . . . . . . . . . . . 134 Оптимизация ценности . . . . . . . . . . . . . . . . . 160
Жизнь, поделенная на части . . . . . . . . . 135 Усиление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
О том, как важно правильно
выбирать свой путь . . . . . . . . . . . . . . . . . . . . . . . 164
Путь фокусировки команд
Red Hat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Развитие новой командной
культуры в Legrand . . . . . . . . . . . . . . . . . . . . . . . . 168
Оценка уровня Agility команд
в BNP Paribas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
ГЛАВА 6
О том, что вдохновило нас
Пути фокусировки. . . . . . . . . . . . . . . . . . . . 137 на написание этой книги . . . . . . . . . . . . . . . 172
Множество путей . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Все Об Agile

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Все Об Agile

Загружено:

Авторское право:

Доступные форматы

Клод Обри

иллюстрации Этьена Аппера

Речь пойдет об Agility, но почему же мы решили назвать книгу «Все об Agile.

Для кого эта книга

Чего вы здесь не найдете

Спасибо всем, кто внес свой вклад в эту книгу

ȇȃǸȅȀȈȆǺǸȅȀǽ ȉȍǺǸȊȂǸ ȆǹǿȆȈ

Мы коснемся каждого из этих семи слов и подробно их объясним. Новенький,

Чтобы лучше понимать терминологию, следует обратиться к истокам.

Agile-манифест и гибкая методология разработки (2001–2006 годы)

Agile-манифест не дает четких указаний, не показывает, какие методы исполь-

Scrum — самая популярная Agile-методология (с 2006 года)

Нина игнорирует тот факт, что Agile-команда кроссфункциональна, то есть спо-

Максим отрицает любые новшества — от использования стикеров до визуаль-

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

Наташа сокращает концепцию Agility до малой части большого неизменного про-

Глеб — чрезмерно самоуверенный владелец продукта. Он думает, что может

И все же, почему Agility?

Умственный труд vs физический труд https://t.me/it_boooks/2

Если ваш проект обладает преимущественно характеристиками, расположенны-

Книга «Accelerate», выпущенная весной 2018 года, основана на трехлетнем ис-

Почему? Потому что экономика!

А что такое настоящая Agility?

Каждой зоне соответствуют свои преимущества, которые дает Agility, и необхо-

Мы вернемся к ним в седьмой главе.

Так что же получается, нет необходимости в компетенциях зоны «Тех-

Инвестиции менеджмента и организации

Какой метод поможет сфокусироваться?

Вы готовы к путешествию в команде?

Пример: отец семейства хочет приготовить суп, но дома не хватает овощей; он

Почему PermaBio хочет стать Аgile?

Кто? Команда ПАЛАС!

Новое состояние духа

Это много. Даже слишком.

Получается, Agility — не для крупных проектов?

Но нас всего трое. А вы говорите, что оптимальный размер — от пяти

У ограничения численности есть цель — поддерживать высокий уровень творче-

Связанное с Agility еще со времен Манифеста, понятие автономии команды дол-

«Команда автономна. Это значит, что у нее есть право

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

Нет руководителя — будет анархия. Все-таки не в сказке живем!

Будем бесконечно говорить — так ни о чем и не договоримся!

В двух словах автономия — это одна из базовых характеристик Agile-команды.

Команда движется к единой цели. Цель направлена на результат, иными слова-

Что делать, если наши ценности истолковывают неправильно? А если

Предполагается, что Agile-команда регулярно предоставляет бизнес-ценность.

Никаких больше «силосных башен»

Agility при частичной кроссфункциональности

Получается, каждый мастер на все руки? Да это невозможно!

Если мы включим в команду людей со всеми нужными компетенция-

Чтобы стать Agile-командой, следует учитывать взаимоотношения между участни-

Скажем «нет» управлению ресурсами

При замене всего одного человека придется заново настраивать коммуникацию

Если проект не укладывается в сроки, то появление нового

Стабильность помогает быстрее сфокусироваться на цели

А в сервисных компаниях состав команд меняется постоянно!

Почему же размер команды должен быть неизменным?

Иными словами, команда сможет стать Agile исключительно в атмосфере дове-

Функции в зоне «Фокуса на цели»

Миссия Владельца продукта

У нас есть менеджер по продукту. Зачем нам еще и Владелец?

Таким образом, Владелец продукта — это человек в команде, который отвечает

Функции в зоне «Фокуса на цели»

А что будет, если Владелец продукта примет решение, с которым