Особенности разработки мобильной MMO RTS. Часть 6

Это последняя статья из моего цикла. В ней будет много о менеджерской и организационной сторонах разработки.

Подход к разработке

Рынок и игроки очень требовательны к частоте обновлений. Поэтому мы релизимся раз в 3 недели. Конечно, чем чаще – тем лучше, но у вас должны быть отлажены все процессы разработки. Кроме того, нужно накопить достаточно функциональности для релиза. Такой темп мы выстроили благодаря feature-командам.

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

Через полтора года такой работы команда стала выглядеть так:

15 программистов;
9 тестировщиков;
3 Technical Artists.

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

Мы решили кардинально изменить подход к разработке. Создали подкоманды, способные решать задачи любой сложности. Это обеспечило замкнутый цикл разработки.

Проанализировав специализации разработчиков, мы выделили такие направления:

• серверная часть и программирование модели клиента;
• core-разработка – реализация игровой функциональности и UI;
• интеграция сторонних библиотек и сервисов, работы с платформами iOS / Android и различными платежными системами;
• рендер-разработка в Unity – к примеру, написание шейдеров.

После этого мы равномерно поделили команду разработчиков на 3 feature-команды. Добавили по равному количеству QA, по одному Technical Artist, изменили рабочий процесс в Jira и описали правила работы с таким подходом.

Менеджер проектов распределяет между feature-командами задачи, которые уже проанализировали и описали project-координаторы. Они уже соответствуют требованиям разработчиков. После этого менеджеру нужно отметить задачи, которые необходимы для следующего релиза. Потом – уточнить требования по срокам, организовать по приоритетности и следить, чтобы каждой команде было чем заняться.

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

Плюсы подхода:

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

Недостатки:

• Падение эффективности команды в целом.
• Сложно организовать работу в Jira, оценить индивидуальный вклад и эффективность каждого разработчика.

GitFlow-разработка

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

Параллельно с созданием feature-команд мы перешли на git и ввели GitFlow. Суть нововведений заключается в строгих правилах работы с ветками:

• ветка со стабильным кодом;
• ветка, в которую попадают только релизы;
• несколько веток для разработки новой функциональности и хотфиксов по версиям.

Подробнее о таком подходе можно почитать здесь. ^[1]

У Unity есть проблема со слиянием сериализованных ресурсов. У нас она усугубляется повсеместным использованием PrefabEvolution. К сожалению, хорошего решения нам найти не удалось. Стараемся не работать над ресурсами, которые могут конфликтовать. Например, атласы NGUI сразу коммитим в стабильную ветку разработки, и она расходится по всем бранчам. Из-за этого в билде может быть неиспользуемая графика, пока не будут замёрджены feature-бранчи.

Мои предыдущие статьи можно найти здесь:

Часть 1 ^[2]
Часть 2 ^[3]
Часть 3 ^[4]
Часть 4 ^[5]
Часть 5 ^[6]

Автор: Plarium

Источник ^[7]