Featureban++
Недавно Алексей Пименов выпустил русский перевод Featureba 3.0. Внесу свои 5 копеек и поделюсь своим опытом игры в Featureban.
Как-то мне понадобилось провести тренинг по Kanban для 20 человек, но лишних 80 000 р. на 4 комплекта getKanban не оказалось. Распечатывать старую версию getKanban я посчитал ненадежным. Стал искать альтернативы и нашел Featreban.
Featureban понравился своей простотой и тем, что позволяет вносить в игру изменения. К тому же, я видел плюс в том, что команды сами генерируют бэклог — это весело и объединяет людей вокруг цели.
Делать фуршет мне было неинтересно. У меня двое детей, поэтому я выбрал пилить моды для Minecraft. Оказалось, половина аудитории не знала вообще, что такое Minecraft. Тем менее, это не помешало им накидать весёлый бэклог из 25 карточек. Последними модами стали Полиция и Путин. 😆
С тех пор я не выбираю тему за игроков, и на моем следующем тренинге девчата уже готовили свадьбу. 🙃
Поиграв в Featureban больше 10 раз, я решил кое-что изменить.
Деньги
После первых пяти игр добавил деньги, чтобы показать важность сокращения Lead Time. Деньги не сильно усложняют процесс, зато вносят соревновательный момент — игра идет бодрее, появляется понятная метрика для сравнения результатов.
Доход вычисляю по формуле:
Revenue = 15 - Lead TimeВ конце итерации команды считают Доход за каждый день, затем накопительный, и отмечают его на диаграмме.
Число максимальной выручки 15 вывел эмпирически. Если сделать 20, трудно почувствовать опасность штрафов из-за большого Lead Time. Если сделать 10, легко уйти в минус или почти ничего не зарабатывать, что демотивирует. В любом случае, с магическим числом 15 можно экспериментировать.
Метрики с первой итерации
Для меня принципиально важно, чтобы люди научились читать метрики потока и следить за ними. Поэтому я веду Cumulative Flow Diagram (CFD), Control Chart и Revenue Diagram с первой итерации, как в getKanban.
По опыту, с CFD хорошо справляются и технари, и гуманитарии.
Первые три дня я показываю, как строить графики сам: беру бланки диаграмм одной из команд, цепляю на флипчарт и отмечаю точки под диктовку членов команды. Другие команды делают то же со своими данными. Оставшиеся дни первой итерации команды заканчивают сами. На второй итерации диаграммы вопросов уже не вызывают.
Интересно, что для себя я сделал почти такие же таблицы и графики в Google Sheets, что и в Featureban 3.0. Но командам их не даю. Уверен, когда рисуешь график руками, быстрее понимаешь природу метрик.
Акцент на блокировках
Когда в игре появляются WiP-лимиты, команды быстро замечают, что карточки стали двигаться быстрее. Но WiP-лимиты не обязательно приводят к росту Дохода и снижению Lead Time в ближайшей итерации.
Проблема в том, что когда мы вводим WiP-лимиты, в системе много старых карточек, Lead Time которых растет и снижает Доход. Если команды не сфокусируются на старых карточках, они не увидят роста Дохода и снижения Lead Time еще две итерации, по сути до конца игры. Тогда встанет вопрос об эффективности метода в целом.
Поэтому на ретроспективах я спрашиваю команды, как они снимают блоки — навожу на мысли, но не решаю за них. Команды, которые стараются протащить старые карточки быстрее, зарабатывают больше и раньше видят снижение Lead Time на Control Chart.
Как правильно заметили некоторые игроки, карточки в игре имеют одинаковую ценность, но в жизни не всегда так. Вопрос о разной ценности карточек — удобный момент, чтобы обсудить Классы сервисов и показать, как с ними работают в Kanban.
Кубик вместо монеты
С монетами заметил особенность:
- не все их умеют ловить
- если не поймать, они сильно шумят об стол
- взрослые люди начинают с ними баловаться, пока объясняешь правила 😂
Поэтому в большей части игр я применяю кубик и чёт/нечет. От шума кубик не избавит, зато балуются с ним меньше и ловить его не надо.
Вообще, поиграв, я понял, почему в Featureban 3.0 осталась только версия с картами. 😅
Lead Time на карточках
Пока мы мы вели таблицу Lead Time, я заметил, что часто игроки забывают записать день, когда карточку берут в работу.
После 10-ти игр я отказался от таблицы с Lead Time и отмечаю время прямо на карточке, как в getKanban. День начала пишет тот, кто берет карточку в Doing, день окончания — тот, кто двигает карточку в Done.
Так ответственность за время карточки равномерно распределяется по команде и меньше зависит от одного игрока. К тому же, это оказалось удобнее во время игры — одной учетной таблицей меньше.
В конце итерации команды подсчитывают Lead Time каждой карточки, считают Доход и строят Control Chart. Затем мы складываем карточки итерации стопкой и пишем сверху количество, чтобы дальше не запутаться при подсчете WiP.
Прерывание первой итерации
Обычно я прерываю первую итерацию, когда в ход пошла карточка #10 — иначе команды будут долго “съедать” набранный WiP и увидят эффект от лимитов на графиках только в третьей итерации, которой может и не быть.
Карточку #10 помечаю цветом и говорю командам, что работаем до 10-й карточки или до 10-го дня.
Две итерации
За 2 часа я успеваю рассказать правила и проиграть 2 итерации. Хотелось бы успеть больше, но зато остается время на теорию. Так, за 4 часа удается поиграть, показать основные практики и принципы Kanban и на примере игровых CFD разобрать основные метрики потока.
Обычно я беру диаграмму одной из команд и рисую “магический треугольник” прямо прямо на ней.
На самом деле, это “магический прямоугольник”, из которого можно вычислить Delivery Rate двумя способами. Сначала мы вычисляем Delivery Rate из Time и Work Done, а затем переходим к Закону Литтла и смотрим, как гипотенузу Delivery Rate можно вычислить из WiP и Lead Time.
Перерыв
Долгая работа в команде довольно выматывает, поэтому поле двух часов я делаю перерыв.
Помню, после второй итерации и перед подведением итогов сделал перерыв на 15 мин. Было интересно наблюдать, как люди в неформальной обстановке спрашивали друг друга, кто сколько заработал, удивлялись, почему у одних вышло в два раза больше, интересовались, почему.
Правила по ходу
Объяснять простые правила игры для меня оказалось непросто. Даже слайды, на которых я по шагам описал процесс движения и заполнения карточки, помогают не вполне — все равно остаются те, кто отвлекся, недопонял и т.п. Кто-то начинает выкрикивать: “Давайте начнем и по ходу разберемся”.
Так что сейчас я вывожу правила на слайде и приступаю к игре.
Первая команда бросает монеты/кубик и мы в отрытую обсуждаем, что нужно сделать. Затем переходим ко второй команде, в отрытую проводим их день и т.д.
После первого дня обязательно кто-то умный скажет: “Так можно было просто каждому взять по карточке”, — это нормально. 😁 Как правило, через полтора дня вся аудитория понимает, как действовать.
Разделение труда в команде
Чтобы приблизить ситуацию к реальной, иногда я ввожу в команде разделение труда, например, 3 разработчика + 1 тестер. Таким образом я ввожу явный боттлнек — ведь в любой системе есть ограничение. 😉
Тестер на втором этапе получает одно право переброса на нечет/орел. Вы можете решить, может ли тестер помогать разработчикам — у меня тестер помогал, но это необязательно.
Это наиболее сомнительный эксперимент, потому что усложняет правила. Зато ситуация получается более жизненной.
Материалы
Напоследок раздаточные материалы, которые я использую в игре:
