Сказано так красиво и убедительно, что отпадает всякая необходимость добавлять к игре определение серьезная (serious game), чтобы не показаться вдруг слишком легкомысленным. Рифкин использует термин глубокая игра как способ эмпатичного взаимодействия с другими.
Agile-игра – это не серьезная игра. Это инструмент, позволяющий достичь результата, получая при этом удовольствие.
Рисунок 17.7 – «Я сомневаюсь: дать вам прибавку или лишить премии?»
✓ Чтобы приобщиться к Agile-культуре. Эти игры направлены на Agile-трансформацию организации, приобщение к новой культуре с ее ценностями и принципами. Среди очень многих выделю, к примеру, Draw the drawing game и Lego Scrum.
✓ Чтобы научиться работать в команде. Большое количество игр! Многие были созданы вне Agile-культуры, направлены на так называемый тимбилдинг – искусство командообразования.
Мы уже поговорили о некоторых их них. Наиболее известная в этой категории – пожалуй, покер планирования, чья цель – в оценке размера историй.
✓ Для определения продукта. Аgilitу подталкивает к командной работе, и лучший способ определить продукт – провести собрание в игровом формате. Сюда отлично подойдут Innovation Games [Хоманн, «Бизнес-игры»], в которые играют совместно с пользователями. Заинтересованные стороны, представители бизнеса, обычно являются участниками таких игр.
✓ Во время спринтов. Команда может веселиться и во время спринтов, но особенное время для игры – это ретроспектива. Здесь игры направлены на обеспечение комфортной атмосферы и сбор информации.
Существует огромное количество небольших игр, используемых в качестве техник для быстрого принятия решений с участием всех участников команды.
Встает очевидный вопрос, особенно во время прелюдии: с кем играть?
Ответ прост: с правильными людьми. Это принцип, о котором вспоминают на открытых совещаниях. Не нужно специально ждать чьего-то присутствия. Игра запускается – и кто участвует, и являются правильными людьми.
Многие игры имеют деловую направленность. В таких, конечно, примут участие заинтересованные стороны. Однако я считаю важным привлечь и разработчиков.
Игра способствует обмену и помогает устранить недопонимание. Формат вынуждает заинтересованные стороны сразу переходить к делу и расставлять приоритеты, позволяет им освободиться от предрассудков: ведь игра предлагает защищенное пространство, где каждый имеет право на ошибку.
Ведение игры на уровне компании требует определенной подготовки. Лучше сначала попробовать, а потом уже проводить полноценную игру.
Можно найти подопытных кроликов в своем близком окружении или среди единомышленников. Как, например, в Agile-ассоциации в Тулузе, которая открыла свой игровой клуб.
Сторонники Post-it®, тем не менее, признают, что все исписанные стикеры нужно потом собирать и переписывать для документации, необходимой для проверок качества или аудитов.
На самом деле, это не всегда так. Но в любом случае всегда можно использовать фотографии. Камера (или смартфон) – Agile-инструмент наших дней. Можно делать регулярные снимки досок, а также сохранять память о моментах, проведенных в команде, особенно во время празднования конца спринта.
Если у вас есть конкретная цель, касающаяся обучения или совместной работы, не нужно медлить: создавайте свою игру или адаптируйте уже существующую. Можно почерпнуть идеи в [Макануфо, «Game Storming»], участвовать в конференциях, где предлагается множество игр.
Существует даже не-конференция, посвященная играм. Она проводится ежегодно где-нибудь во Франции (в 2018 году состоялась в Лавале в Майенне), и на ней можно предлагать и тестировать новые, только-только разработанные игры.
17.5 Антипаттерны
Ситуация. Инструмент используется только одним человеком, а не командой. Например (и особенно это относится к любителям Excel), только Владелец продукта имеет доступ к бэклогу. Или Scrum-мастер единолично обновляет задачи всей команды в плане спринта.
Последствия. Обмен ограничен или его вовсе нет.
Как сделать лучше? Бэклог, и уж тем более план спринта, принадлежат всей команде. Надо прекращать пользование инструментом и перейти к визуальному управлению.
Ситуация. Иногда команды заботятся об эстетической составляющей их досок, и это отлично. А иногда участники считают, что самое важное – сделать доску впечатляющей. Я видел несколько таких внушительных досок. Действительно, количество столбцов и элементов произвело на меня неизгладимое впечатление.
Последствия. Доска перестает быть простой в использовании. Участники больше не ограничивают себя в масштабах таблицы.
Как сделать лучше? Не стоит пытаться вместить все в одну доску. Мы знаем, что в Scrum есть три уровня: функциональность, история, задача. Для них нужны как минимум две разные доски.
Ситуация. Под предлогом интеграции и стандартизации команда прибегает к инструменту, который умеет делать все.
Последствия. Инструмент, который делает все, опасен. В частности, работа с Agile-функциональностями в инструментах, предназначенных для другой цели, может существенно усложнить процесс и исказить применяемые Agile-практики.
Как сделать лучше? В статье об Agile-инструментах [52] Кент Бек утверждает, что лучше инвестировать в один (или несколько) элементарных инструментов, адаптированных к нашему процессу, чем пытаться адаптироваться к более сложным и большим инструментам, созданным для других процессов и подходов.
Ситуация. Игры проводятся при помощи классических материалов (флипчартов) в классических местах.
Последствия. Теряется игровой формат, это препятствует креативности.
Как сделать лучше? Некоторые игры нуждаются в дополнительном оборудовании. В дополнение к запасу Post-it® у Scrum-мастера должен быть укромный уголок с запасом наклеек, пусть даже совсем детских, конфет, клеевых подушечек «Patafix» и хронометром – и это только минимальный набор!
Есть еще колокольчик, чтобы прекращать затянувшиеся обсуждения, кухонный Pomodoro-таймер, устройство для непрерывной интеграции (см. главу 19) и т. д.
Ситуация. Команда пользуется инструментами с устаревшим интерфейсом.
Последствия. Теряется инновативность, это препятствует креативности.
Как сделать лучше? Agile-движение – это радикальное изменение. И как мне кажется, оно должно охватывать и техническую сторону вопроса.
Новые интерфейсы веб-приложений позволяют еще больше сблизиться с Post-it®, даже с некоторыми дополнительными преимуществами.
Еще один путь – использование приложений, для которых, как в видеоиграх, не требуются ни клавиатура, ни компьютерная мышь.
Чтобы идти дальше
Книги
‣ Люк Хоманн, «Бизнес-игры. Создание революционных продуктов с помощью клиентов», Символ-Плюс, 2008
‣ Джеймс Макануфо, Санни Браун, Дэйв Грей, Gamestorming – Jouer pour innover, VF, 2014.
‣ Джереми Рифкин, «Третья промышленная революция», Альпина нон-фикшн, 2017
Онлайн-ресурсы
‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/
‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum
‣ Agile Games France, Википедия
18Наглядность при помощи индикаторов
Эмпирический подход Scrum основан на проверке и адаптации и требует прозрачности в процессе создания продукта. Визуальное управление, рекомендованное в предыдущих главах, помогает разобраться в любой ситуации и в любой момент времени. Таблицы, показывающие задачи, истории и функциональности, содержат очень важную информацию для тех, кто научился ими пользоваться.
Значение, которое обычно придается индикаторам (знаменитым KPI, Key Performance Indicators, или ключевым показателям эффективности), в результате просто утрачивается. Но индикаторы нужны для наглядности: они предоставляют информацию, которая не указывается на досках, а именно динамику.
Индикатор помогает укрепить (или наоборот) уверенность в достижении цели спринта или сезона.
Традиционный индикатор Scrum – это burndown-график, он же диаграмма сгорания задач. Этот индикатор является средством для отслеживания выполненных задач. Часто используемый неправильно, он имеет ограничения в определенных условиях, для которых приемлемы другие индикаторы. Мы представим их в этой главе.
Чтобы получить индикаторы, нужны определенные метрики. В Scrum наиболее важные из них относятся к конкретным результатам, собранным с помощью циклов проверки и адаптации: каждый день, каждый спринт, каждый сезон. На их основе получаются индикаторы, помогающие принимать решения при обсуждениях во время схваток, обзоров и ретроспектив.
Индикаторы, представленные ниже, не универсальны для всех проектов. Решение о выборе тех или иных индикаторов принимает команда, исходя их своих целей и возможностей.
Некоторые метрики относятся к величинам, не известным в момент, когда команда в них нуждается. Возникает необходимость оценивания. Для этого можно использовать