Это последняя статья из моего цикла. В ней будет много о менеджерской и организационной сторонах разработки.
Подход к разработке
Рынок и игроки очень требовательны к частоте обновлений. Поэтому мы релизимся раз в 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. Суть нововведений заключается в строгих правилах работы с ветками:
- ветка со стабильным кодом;
- ветка, в которую попадают только релизы;
- несколько веток для разработки новой функциональности и хотфиксов по версиям.
Подробнее о таком подходе можно почитать здесь.
У Unity есть проблема со слиянием сериализованных ресурсов. У нас она усугубляется повсеместным использованием PrefabEvolution. К сожалению, хорошего решения нам найти не удалось. Стараемся не работать над ресурсами, которые могут конфликтовать. Например, атласы NGUI сразу коммитим в стабильную ветку разработки, и она расходится по всем бранчам. Из-за этого в билде может быть неиспользуемая графика, пока не будут замёрджены feature-бранчи.
Мои предыдущие статьи можно найти здесь:
Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Автор: Plarium
