Бизнес-игра «Агильная Дженга для тестирования» — популярное упражнение для команд, переходящих на гибкие методы разработки. Суть игры: участники по очереди вытягивают блоки из башни, символизируя изменения или добавления в продукт. Задача — сохранить башню устойчивой, одновременно внедряя новые «фичи». Это наглядно демонстрирует, как без качественного тестирования и рефакторинга (подтягивания блоков) система становится хрупкой и рушится.
Организация проведения бизнес-игры развивает навыки работы в команде, приоритизации, планирования итераций и показывает ценность тестирования на каждом этапе. Подходит для тимбилдингов, тренингов по Agile и фасилитации ретроспектив. Оборудование: классическая или специализированная Дженга (можно с метками). Время: 20–40 минут. Ведущий моделирует ситуации: «добавление срочного требования», «пропуск теста» и т.д. Обсуждение после игры помогает закрепить уроки.
Цели бизнес игры
Наглядно показать, как инкрементальная разработка и непрерывное тестирование снижают время на переделку.
Доказать, что вовлечение тестировщика на ранних этапах уменьшает стоимость и количество дефектов .
Проиллюстрировать негативные эффекты «технического долга», когда ошибки накапливаются до самого конца проекта.
Продемонстрировать преимущества подхода TDD (Test-Driven Development), где качество закладывается еще до написания кода .
Необходимые материалы
Один набор Jenga (около 45–54 брусков) .
Маркер, чтобы пронумеровать все бруски от 1 до N (количества блоков в наборе). Для удобства можно раскрасить их в разные цвета по группам (например, 1-15, 16-30, 31-45) .
Генератор случайных чисел (игральные кубики или сайт random.org) для определения «дефектных» блоков .
Секундомер, для замера времени выполнения каждого этапа .
Правила игры и ход раундов
В каждом раунде участники делятся на роли: один или несколько «разработчиков» (строят башню) и один «тестировщик» (ищет и удаляет баги). В начале каждого раунда всем командам дается единое техническое задание: использовать все блоки и построить башню высотой минимум в 3 уровня .
Раунд 1: Каскадная разработка (Большой взрыв)
Этот раунд имитирует классическую «Waterfall» модель.
Разработка: «Разработчики» строят башню, не получая никакой обратной связи от тестировщика .
Тестирование: Когда башня готова, «тестировщик» с помощью генератора выбирает несколько (например, 3 или 4) случайных номеров — это «баги, найденные в продакшене». Он называет номера разработчикам .
Переделка: Разработчики должны найти и удалить эти дефектные блоки из башни, не разрушив её. Если башня падает, ее нужно перестроить, чтобы она снова соответствовала требованиям.
Замер: Фиксируется время на разработку и, отдельно, время на мучительную переделку .
Раунд 2: Итеративная разработка (Спринты)
Этот раунд моделирует работу в Agile-спринтах.
Разработка по частям: Блоки делятся на группы, и «разработчики» строят башню частями. Например, сначала используют блоки 1-15, затем 16-30, и наконец 31-45 .
Тестирование в конце итерации: После завершения каждой части (спринта) «тестировщик» генерирует новые случайные числа и указывает на «баги» в только что построенной части.
Переделка: Разработчики немедленно удаляют дефектные блоки из этой части башни до того, как приступать к следующей.
Замер: Фиксируется общее время разработки и время на исправления на каждом шаге.
Раунд 3: Непрерывное тестирование (Pair Programming / TDD)
Этот раунд симулирует идеальный агильный процесс с постоянным контролем качества.
Тестирование до разработки: Перед тем как взять блок, «тестировщик» проверяет его: генерирует список «дефектных» номеров. Если номер совпадает с «дефектным», этот блок нельзя использовать в строительстве .
Разработка: Разработчики строят башню только из «качественных» блоков. «Тестировщик» по-прежнему может удалять найденные дефекты прямо по ходу сборки, но теперь их значительно меньше.
Итог: В конце раунда у команды готовая башня, которая изначально была построена из «качественных деталей».
Ключевые выводы: почему это работает
После проведения всех трех раундов команда видит драматическую разницу в цифрах. Во время обсуждения (дебрифинга) становятся очевидны главные уроки :
Время — деньги: Общее время на «доставку» готовой башни (включая переделки) в первых двух раундах значительно больше, чем в третьем. Раннее тестирование сокращает переделки и ускоряет выход продукта .
Стоимость ошибки: В первом раунде удаление одного блока могло разрушить всю башню — это дорогостоящий и рискованный «рефакторинг». В третьем раунде «дефекты» просто не попадают в систему .
Коммуникация: В первых раундах «тестировщик» и «разработчики» работали изолированно. В третьем раунде они работали в связке, что напоминает о важности парного программирования и кросс-функционального взаимодействия .
От игры к реальности
Бизнес-игра для компаний «Дженга» — это мощный инструмент не только для обучения, но и для диагностики команды. Она вскрывает проблему «силосов» (Silos), когда тестировщики и разработчики изолированы друг от друга . Игра дает возможность участникам самим прийти к выводу, что качество — это не финальный этап, а непрерывный процесс, в который вовлечена вся команда . Главный урок «Дженги для тестирования»: предотвратить дефект всегда дешевле и быстрее, чем его исправлять.
Разработка бизнес-игр https://selfie-center.ru/razrabotka/