Привет, меня зовут Катя, я QA Lead в Social Quantum. В геймдеве я с 2011 и за это время успела поработать над разными жанрами: MMORPG, Shooter, match-3. Проекты были на разных платформах, таких как ПК, Android, iOS.  Были и кроссплатформенные, которые выпускали даже под Gameroom Facebook.

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

Вопросы которые мы задаем себе:

• Какой процесс использовать?

• Когда встраивать процесс?

• Как быстро это нужно сделать?

Давайте попробуем разобрать эти вопросы и ответы на них.

Как понять, какой процесс выбрать?

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

Когда встраивать процесс?

В мобильных игровых проектах разделяют несколько стадий разработки. Рассмотрим один из способов разделения:

MVP версия обычно направлена на проверку Core-геймплея и ретеншена 1-го дня. В игре может быть готова маленькая часть только для проверки самой идеи игры, насколько игрокам интересно в нее играть, когда в игре больше нечем заняться кроме core-геймплея.

После того как мы убедились, что наша игра имеет право на жизнь, мы начинаем прорабатывать мета составляющую и монетизационную часть, отладка этой части игры обычно и происходит в Soft Launch. Для тестов выбирают регион, приближенный к целевому по поведению. Основная часть игры готова, обычно в игре достаточно геймплея примерно на неделю.  Закупают трафик, собирают аналитику, на основе аналитики делают правки.

Global Launch — это глобальный релиз игры, когда  мы отладили самые необходимые показатели, вышли на весь мир и переводим нашу игру в оперирование.

Operate — оперирование игры,  в проекте появляются регулярные релизы, обновление контента, активная работа комьюнити с игроками и т.п.

Период между релизами на MVP и Soft Launch может быть различным. Разработка игры до выхода в MVP может занимать до полугода. Дальнейшие релизы зависят от количества необходимых правок и их подготовка может занимать 2-3 месяца. После Global launch (далее GL) релизы становятся регулярными, с достаточно короткими промежутками (от раза в неделю до раза в месяц). Из этого можно сделать вывод, что оптимальный период для настраивания  процессов и решения проблем является время подготовки к Soft Launch.

Почему этот период оптимальный?

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

Люди как-будто ждут GL, чтобы выдохнуть, как будто все закончится, но на самом деле, все только начинается. Это не значит, что нет шансов улучшить/изменить процесс после GL, но сделать это будет в разы сложнее. Поэтому я предлагаю выстраивать процесс и решать основные проблемы проекта при подготовке к Soft Launch.

Как быстро нужно встраивать процесс?

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

План для выбора процесса

Какие могут быть проблемы:

• Сложно оценить крупные фичи;

• При разработке фичи возникают недопонимания и делают не совсем то;

• Версии часто поломаны;

• Нельзя отдать версию на плейтест в любой момент;

• Нет опыта подготовки версии к релизу;

• Демотивация сотрудников из-за долгой невозможности посмотреть\показать результат проделанной работы.

Что делать дальше?

Предлагаю взять эти проблемы и попытаться решить их с помощью добавления или улучшения процесса.

Перед тем как приступить, нужно проработать структуру для рассмотрения процесса.

1. Проблема — выбираем проблему, которую хотим решить, рассуждаем действительно ли это проблема.

2. Процесс для решения — рассуждаем какие процессы могут помочь, выбираем какой будем встраивать.

3. Почему процесс может не работать — рассуждаем  какие проблемы могут возникнуть, какие риски есть, предполагаем, какие еще проблемы могут вылезти).

4. Решение — находим решение для тех проблем, которые озвучили в предыдущем пункте, применяем сразу при встраивании процесса.

Решение проблем

Первая проблема — сложно оценить крупные фичи

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

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

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

Давайте начнем со стандартного метода — попробуем добавить спринты и посмотрим что получится.

Что за процесс?

Спринт длится 2 недели. Планирование происходит на 2 недели. В конце спринта проводится Demo и Ретроспектива.

Достаточно ли добавить спринты, чтобы решить наши проблемы?

Наши проблемы не решены. Почему?

Спринты нам добавили планирование на две недели, но это краткосрочное планирование. Мы все еще не видим, в долгосрочной перспективе, успеваем мы или нет. Так же, как и не можем оценить крупные фичи без большой погрешности. Многие говорят: «у нас есть спринты, мы гибкая Agile команда, у нас нет документации» и т.п. Люди часто путают хаос с гибкостью. Поэтому в данном случае просто наличие спринта не поможет решить проблему. Хотя, в краткосрочной перспективе, работать становится лучше.

Минутка про геймдев:

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

Возвращаемся к проблеме

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

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

Почему может не работать?

• Нежелание команды разбивать фичу;

• Неправильная декомпозиция — декомпозиция, которая привела к усложнению разработки, упустили какую-то часть при декомпозиции и т.п.;

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

Решение:

• Обсуждение и выявление причин этого нежелания, возможно команда просто не видит варианты и если им их показать, то все побегут декомпозировать фичи;

• Понять, как правильно декомпозировать, поможет только опыт;

• Не  планируем в один спринт несколько фичей из одной крупной, чтобы избежать проблем с зависимостью.

Что получилось?

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

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

Минутка про геймдев:

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

Вторая проблема — при разработке фичи возникают недопонимания и делают не совсем то

Это проблема, и достаточно серьезная, т.к. время на разработку тратится, а на выходе получают не тот результат, которого ожидали. Как попытаемся решить? Добавим проведение Storytime. Что это?

Storytime — это встреча всех заинтересованных в фиче для ее обсуждения. Здесь мы можем задать вопросы, обсудить детали реализации и т.п. Перед тем, как проводить сторитайм, все лиды отделов делают ревью документа.

Почему может не работать?

• Участники не задают вопросы, потому что не читали документ;

• Документ не обновляется по итогам встреч;

• Документа нет.

Решение:

• Обязательно ведется документация;

• Документация обновляется;

• Все участники готовятся к сторитаймам;

• Встречи всегда в одно время, чтобы у участников было время подготовиться.

Что получилось?

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

Минутка про геймдев:

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

Третья проблема — версии часто поломаны

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

Как будем решать проблему? 

Добавим работу в ветках и проверку каждого пуллреквеста.

Что это?

• Разработка каждой фичи ведется в отдельной ветке;

• Тестировщик проверяет билд ветки и аппрувит пуллреквест, до аппрува тестировщика вмерджить в dev нельзя.

Почему работа в ветках может не работать?

• Долго висит пуллреквест -> конфликты при мерже. Усложняет и удлиняет работу с веткой, демотивирует сотрудников так, что они будут просить вернуть все назад;

• проверка не каждого пуллреквеста — баги, блокирующие команду, все равно могут попадать в dev, и тогда проблема не будет решена.

Решение:

• Всю команду перевести на пуллреквесты;

• Должно быть достаточное количество тестировщиков для теста пуллреквестов;

• Могут быть договоренности в каких-то случаях не проверять пуллреквест, но в таком случае те, кто мержат этот пуллреквест должны нести ответственность за влитие правок в dev и быть уверенными, что проблем не возникнет.

Что получилось?

Стоит отметить, что бывают проблемы с ветками. В UE есть Блюпринты и бинари, которые  плохо переносят решение мерж конфликта, если поработало несколько человек над файлом.

Очевидным решением тут кажется, что нужен лок файлов, чтобы избежать этих конфликтов. И вот тут могут возникнуть проблемы. На одном из проектов команда использовала Perforce, работала в монорепе, прекрасно блокируя файлы в рамках одной ветки. Но в момент когда речь зашла о работе в ветках, то выявилась проблема. В Perforce нельзя сделать сквозной лок между веток. Было принято решение перейти на Git, т.к. часть команды уже имела опыт работы с ним и в нем есть сквозной лок между веток.

Минутка про геймдев:

Обычно так и происходит, что аргументы «делать нормально мы будем 2 месяца, а на костылях за пару недель запилим. А вот после релиза мы все переделаем, начнем работать по нормальным процессам». Стоит помнить, что это капкан. Маловероятно, что это произойдет потом. Мы так и будем мечтать о завтра, которое никогда не наступит.

Четвертая проблема — нельзя отдать версию на плейтест в любой момент

Почему это проблема?

Dev-билды не подойдут для сторонних людей вне dev-команды, билды ставятся на iOS не самым простым способом. Собрать новый билд требуется время, поставить его всем на девайсы тоже требует время. Проведение плейтеста выходит дорого. В геймдеве плейтест частое явление и дороговизна, и сложность его проведения является серьезной проблемой, особенно на стадии активной разработки.

Как будем решать? Добавляем сборку Nightly билда.

Каждую ночь собирается билд и отправляется в TestFlight во внутреннее тестирование.

Почему может не работать?

• Проверяются не все пуллреквесты — возможны баги в сборке;

• Большая команда (ограниченное количество тестировщиков во внутреннем тестировании, ограниченное количество провижнов в аккаунте) —  не всех можно добавить в тестировщики;

• Проблемы с TestFlight;

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

Решение:

• Мердж только после проверки, хотя бы на блокеры;

• Для большой команды нужен поиск альтернатив (FireBase App Distribution, AppCenter);

• Автоматизируем процесс сборки и отправки билдов в TestFlight;

• Повлиять на проблемы с самим TestFlight нельзя.

Что получилось?

Nightly билд дает возможность любому сотруднику в проекте быстро получить свежий билд из TestFlight. Это позволяет лиду арта отслеживать работу своих сотрудников в билде и смотреть, как результат будет выглядеть на мобильном устройстве. Любой человек легко может посмотреть результат своей вчерашней работы, а также показать кому-то эту работу и запросить фидбек. Команда ГД может заниматься наигрыванием уровней для сбора статистики.

Минутка про геймдев:

Плейтесты в геймдеве имеют большое значение и используют их для разных целей и с разной массовостью.

• Плейтест могут проводить для поиска багов в рамках QA отдела;

• Плейтест может проводить ГД отдел для отладки баланса;

• Плейтест могут проводить на всю компанию для сбора общего фидбека по игре;

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

Пятая проблема — нет опыта подготовки версии к релизу

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

Как будем решать? Добавляем сборку Release Candidate (далее RC) в конце каждого спринта.

Что это?

Каждый спринт появляется понятие End Of Development.

End of Development (конец разработки) — это временная отсечка, фиксирующая набор фичей, которые войдут в итоговый билд по результатам спринта.

Выводится ветка -> собирается билд и отправляется в TestFlight для внутреннего теста -> тестируется -> вносятся правки при необходимости -> Отправка RC билда во внешнее тестирование TestFlight на команду.

Почему процесс с RC билдом может не работать?

• Проблемы с TestFlight;

• Нет автоматической сборки\отправки билдов — выше упомянуто более подробно, почему именно это может быть проблемой.

Решение:

• Автоматизируем процесс сборки и отправки билдов в TestFlight;

• Повлиять на проблемы с самим TestFlight нельзя, но с TestFlight проблемы бывают не часто.

Итоги

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

RC и Nightly-билды — это разные билды в TestFlight. RC не выходит обновлением для Nightly. Как мы это сделали? В App Store Connect 2 приложения: одно для Nightly, другое для RC. Это позволяет иметь доступ к предыдущим версиям RC, т.к в TestFlight можно установить и предыдущие версии.

Минутка про геймдев

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

Шестая проблема — демотивация сотрудников из-за долгой невозможности посмотреть\показать результат проделанной работы

Почему это проблема?

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

Как будем решать? Добавляем плейтест команды в конце спринта.

Что это?

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

Почему может не работать?

• Люди не знают, что смотреть в билде — внимание рассеивается и человек каждый раз смотрит одно и то же;

• Не видят результат с прошлого фидбека -> не видят смысл писать фидбек — человеку кажется, что его мнение не имеет значение, а зачем тогда играть и высказывать его.

Решение

• К каждому билду есть свой Changelog c перечислением сделанных фичей;

• На каждый пункт из фидбека сотрудника есть реакция (баг, отгрузка ответственному, ссылка на ГДД и тп).

Что получилось?

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

Минутка про геймдев:

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

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

Заключение

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

Если процесс не улучшает ничего в вашей работе, то возможно он не нужен. Главное правильно оценить пользу.