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

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



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

    Часть 1
    Часть 2
    Часть 3
    Часть 4
    Часть 5

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


    Рынок и игроки очень требовательны к частоте обновлений. Поэтому мы релизимся раз в 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-бранчи.
    Метки:
    • +10
    • 4,8k
    • 9
    Plarium 87,10
    Разработчик мобильных и браузерных игр
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Похожие публикации

    Вакансии компании Plarium

    Комментарии 9
    • 0
      А работаете ли с unity сценами параллельно, если да, то как мерждите?
      • 0
        Сцены у нас практически пусты. Весь контент создаётся динамически из префабов. Префабы стараемся делать как можно меньше, чтоб избегать проблем с мёрджем. Также используем утилиту для мёрджа от Unity.
      • 0
        Есть вопрос возможно банальный и неуместный, но всё же… Бывали ли у Вас случаи и если да — решалось ли как-то, что кто-то из команды разработчиков желает работать на другом проекте в компании, но это может навредить команде?

        И исходя из «Лид-разработчик начал назначать задачи по специализации.» — Вы не боялись, что это может привести к ситуации с незаменимыми игроками? Когда потеря любого сотрудника может очень сильно подкосить…
        • 0
          Конечно же бывали. Это в целом всё очень индивидуально и решения, соответственно, тоже были индивидуальны. Общий паттерн поведения вывести сложно.

          Вы не боялись, что это может привести к ситуации с незаменимыми игроками?


          Боялись, но практически всегда было и есть несколько разработчиков, которые имеют общую специализацию. Личные зоны ответственности стараемся шарить как можно быстрее через ревью или выполнением задач под присмотром.
        • 0
          Почему NGUI, а не uGUI?
          Спасибо за статьи, с нетерпением жду про архитектуру серверной части и взаимодействием бд.
          • 0
            Вам первая фраза в статье «Это последняя статья из моего цикла. » ни о чем не говорит по поводу ваших ожиданий? )
            • 0
              Последняя статья в этом цикле, но не последняя в целом. Мы продолжим делиться опытом разработки игр в других материалах :)
              • 0
                В таком случае я присоединяюсь к ожиданиям выше. )
            • 0
              Когда начинали разработку игры uGUI еще не было и NGUI был практически стандартом. Позже мы использовали uGUI для других проектов, так что опыт есть и в том и другом.

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

            Самое читаемое