ИНТЕРВЬЮ WCCFTECH С ЭРИКОМ КИРОН ДЭВИСОМ
Журналисту Wccftech Адриану Ипу (Adrian Ip) удалось встретиться с директором студии в Лос-Анджелесе и главой продакшена CIG Эриком Кирон Дэвисом (Eric Kieron Davis) и задать ему несколько вопросов. Ниже приводится перевод интервью.
Wccftech: Спасибо, что нашел время побеседовать со мной, Эрик! Несколько лет назад я написал серию статей о разработке ПО и гипотетически связал их с процессом разработки Star Citizen, каким он был в моем представлении. Так что это просто замечательно – получить возможность пообщаться с тобой и подтвердить некоторые из моих догадок. Давай начнем с простого, вы используете какую-то разновидность Agile или Scrum?
Эрик Кирон Дэвис: Как я полагаю, Адриан, мы в основном будем говорить о методиках разработки, а не о командах поддержки и других направлениях. Я присоединился в 2015 году, и с тех пор проект естественным образом эволюционировал. На раннем этапе мы определили, что хотим позволить командам в каждой локации работать в тесном сотрудничестве друг с другом, но при этом оставаться в системе, которая корректно функционирует в глобальном масштабе. Когда мы впервые начали, ты помнишь, что у нас каждая студия была как отдельная ячейка и работала изолированно. За эти годы мы наняли множество сотрудников, поэтому упомянутые тобой ключевые слова, вроде Agile и Scrum, сейчас глубоко интегрированы в процесс. Я ежедневно общаюсь с владельцами продукта и мастерами Scrum. У нас есть Story Points (//относительные оценки объёма работы в истории, прим. перев.) и, как ты знаешь, с новым планом ежеквартальных релизов каждый отдельный релиз обладает большим количеством целевых задач, которые формируют оговоренные сроки разработки. Так что мы берем эти задачи и используем их, чтобы составить проект и сказать: “вот здесь мы видим 3.3 и 3.4”.
Дорожная карта Star Citizen. Версия 3.2 уже вышла, но многое еще впереди
Со временем, поскольку у нас тут есть люди, которые работают в компании на протяжении более длительного времени, ты узнаёшь людей и понимаешь на что они способны. Это действительно помогает в работе. Я знаю, что если поручу что-нибудь “Джилл”, она выполнит задачу за сутки, но если я дам такое же задание “Чаку”, он может оказаться не так хорош в этой области, и работа займет у него несколько недель.
Так что изучение команды, структуры управления, кода – всё это влияет на разработку продукта. Поэтому по мере формирования команд и продвижения через эти циклы, вещи естественным образом встают на свои места. Вам больше не требуется так усердно размышлять, и вы понимаете, какому человеку или команде вы обычно передадите конкретную задачу.
Сейчас мы придерживаемся ежеквартального графика релизов. Небольшая реструктуризация помогает нам улучшить процесс предоставления контента.
Wccftech: Говоря о версиях и релизах, какова ваша стратегия разделения работы на ветви? Предположим, что у вас есть основной рабочий поток, куда вносят вклад все команды. В какой-то момент времени вы выделяете из него конкретную функцию и говорите, что работа над ней завершена. После чего вы стабилизируете ее состояние, возвращаете ее обратно в основной поток и переходите к работе над следующей функцией? А как это выглядит в случае со Star Citizen?
Эрик Кирон Дэвис: Адриан, ты сейчас сказал буквально то, что я собирался ответить. Именно так мы и поступаем, здесь нет никакой магии. Когда я пришел, мы в силу сложившихся обстоятельств называли основной репозиторий “Главным”, что довольно забавно. Мы переименовали его, чтобы он стал называться “Геймдев”. Сейчас это основная ветвь разработки, которая содержит всё. Когда мы начинаем подготовку к релизу в какой-либо ветви, то называем ее ветвью “SC3.2”, так и появлются наши ежеквартальные релизы. У нас работает процесс добавления/исключения – так мы убеждаемся, что некоторые ресурсы либо отправятся в релиз, либо останутся в разработке, если они еще не готовы. Так начинается процесс перехода от этой большой беспорядочной свалки к изящному обработанному пакету, который мы в конечном итоге выпускаем на PTU.
Например, мы внесли несколько исправлений в систему гравитационной левитации, но мы не хотим, чтобы они присутствовали в ветви 3.1. Кроме того, их нет в Squadron, так что мы отправляем их обратно в “Геймдев”. Обычно практически все функции отправляются обратно, если только мы не проводим так называемый релиз “без слияния”. Если, к примеру, мы что-то добавляем в релиз 3.2, но в будущем планируем улучшить реализацию этой функции, мы не хотим возвращать ее обратно в “Геймдев”, так как она может сломать другие системы, над которыми мы трудимся.
Prospector разбивает скалы
Wccftech: Да, мне это известно! Моя команда выполняет множество задач схожим образом.
Эрик Кирон Дэвис: Ха! Нам нужно быть осторожными. Многим людям не нравится такой способ, если только ты не знаешь, как он работает, и как правильно его применять. Если работать в таком ключе, можно достичь поставленных целей, чтобы предоставить сообществу то, что оно хочет. А в последствии мы отлаживаем все надлежащим образом.
Wccftech: Мне вот что интересно: вы, парни, уже некоторое время работаете над функционалом для Star Citizen по ежеквартальным релизам и, похоже, вливаетесь в регулярный ритм. Сколько времени сейчас занимает объединение функции с основным потоком?
Эрик Кирон Дэвис: Сейчас это довольно быстрый процесс. Конечно, он был у нас еще в прошлой версии, так что процесс для объединения уже какое-то время существовал. В основном это проходит достаточно быстро, но все зависит от самого релиза и целей, которых мы пытаемся достичь с этим релизом. Если релиз действительно крупный, а мы откусили больше, чем можем прожевать, то процесс слияния с “Геймдевом” может занять больше времени. Но в конце концов мы справляемся. Слияния у нас проходят постоянно: как на стадии PTU, так при “живом” релизе, но в случае с 3.2 речь шла о днях. Так и должно быть, ведь мы знаем, что нам нужно быстрее переходить к следующей ветви.
У нас есть Шон Трейси – еще одно знакомое тебе имя. Парни вроде него чрезвычайно сосредоточены на техническом “здоровье” наших билдов. Они поддерживают репозиторий “Геймдева” в хорошем состоянии.
Wccftech: Когда ты говорил о техническом здоровье, то напомнил мне о другой теме, которую я хотел обсудить. Это одна из тех вещей, которые я терпеть не могу при смене работы. Ты всё копаешь и копаешь, пытаясь узнать, насколько глубока кроличья нора. В любом случае, если у тебя есть проект с горсткой устаревшего кода, ты обнаружишь там множество технических недоработок, с которыми тебе придется разбираться. Ты присоединился к проекту в 2015 году. Какое впечатление произвел на тебя уровень технических недоработок в кодовой базе Star Citizen, и как, если быть честным, ты бы оценил ее текущее состояние?
Эрик Кирон Дэвис: Как ты знаешь, Крис сам программист, и он каждую ночь тщательно изучает код. С таким проектом, как Star Citizen, человек становится машиной. Еще до меня здесь были ситуации, вроде “мы должны выпустить модуль ангара” или “мы должны выпустить модуль Arena Commander”. Когда ты хочешь отправить их в релиз, ты расставляешь различные элементы по своим местам, и они работают, а затем кто-то говорит: “это лучше отложить на потом!”
Ты употребил негативный термин “технические недоработки”. Если честно, когда я присоединился к проекту, их было нормальное количество в моем понимании. Не было такого, чтобы я воскликнул: “Воу! Это все технические недоработки!”, и команда проделала хорошую работу по отслеживанию элементов, с которыми нам предстояло разобраться. Что было действительно классно, так это то, что мы расширили команду и продолжили разработку. Мы перенесли множество этих элементов на наши двухнедельные периоды (спринты), и количество технических недоработок за последние два года существенно сократилось.
У нас всегда есть длинный список вещей, которые мы хотели бы сделать правильно, и мы знаем, что нам просто нужно продолжать устранять эти технические недоработки. Система Предметов 2.0 была для нас серьезной задачей. Она была не идеальна, мы хотели сделать ее лучше. Поэтому с каждым нашим релизом мы вносим в нее улучшения. Это стало очень разумной позицией по опережению наших технических недоработок, и мы постоянно совершенствуемся.
Жду не дождусь увидеть этот корабль в игре
Wccftech: Мы постоянно слышим об общей кодовой базе для Squadron 42 и Star Citizen, и порой сообщество удивляется тому, что однопользовательский контент не вышел раньше. Насколько сильно одиночная игра зависит от разработки таких вещей, как системы Предметов 2.0, связывания сетевых сущностей и других, учитывая, что это, очевидно, именно одиночная игра, а не сетевая?
Эрик Кирон Дэвис: Кодовая база общая, но очевидно, что здесь присутствуют некоторые вещи, которые в будущем будут важнее остальных. И ты прав. Поскольку это одиночная игра, сетевые компоненты для нее не так важны. Тем не менее, Star Citizen содержит множество компонентов, которые будут использованы в Squadron 42, так что это интересный вопрос. Есть много вещей, о которых я сейчас не могу говорить, но в конечном итоге мы хотим сделать самую лучшую игру. На высоком уровне люди смотрят на Star Citizen и видят “$200 миллионов, 500 разработчиков”, и спрашивают, почему она еще не вышла?
Wccftech: Ага, это как старое “девять женщин не родят ребенка за месяц”.
Эрик Кирон Дэвис: Да, это мой любимый пример продуктивности. Все время его использую.
Wccftech: Я не хочу обсуждать конкретных людей, поскольку в прошлом имели место некоторые расхождения во мнениях, но текучка кадров – это жизненный факт для любой компании. Как вы, ребята, находите свою базовую скорость, на которую влияет отток персонала, необходимость вводить в курс дела новых сотрудников и т.п.?
Эрик Кирон Дэвис: Раньше я довольно сильно зависел от того, кто именно уходил. Если это был художник по концептам, которому предложили работать над новым костюмом Железного человека, возможно, мы просто возьмем другого парня, который довольно быстро займет его место. Но если это был инженер, глубоко вовлеченный в какую-то конкретную область кода, найти ему замену оказывалось сложнее, и в результате страдала наша скорость работы. Думаю, в большей степени эта проблема затрагивала нас, когда команда была меньше, и все были чрезвычайно сосредоточены в одной области. Но по мере роста мы получили куда больше возможностей по перераспределению задач. Мы расширили компанию, мы строим тут карьеру и хотим, чтобы это место осталось нашим местом работы до конца дней. Так что мы действительно делимся знаниями. Вдобавок нам помогает модель разработки “следуй-за-солнцем”, потому что все мы трудимся над множеством различных компонентов.
Есть места, где ты всегда можешь что-то улучшить и усовершенствовать, но мы постоянно работаем в этом направлении.
Aegis Eclipse
Wccftech: Одна из сложностей заключается в том, что в командах разработки вы всегда хотите добиться взаимного обогащения опытом. Чтобы не получилось так, что у вас есть “вон тот парень”, который знает всё, и его переехало автобусом. Но взаимное обогащение опытом также отбирает время, так что вам всегда приходится поддерживать баланс. Планируете ли вы спринты в глобальном масштабе?
Эрик Кирон Дэвис: Планирование носит глобальный характер, таким оно и должно быть. Несколько лет назад мы обнаружили, что если не будем заниматься этим глобально, то просто столкнемся с блокерами, и нам придется ждать, пока кто-то в другом офисе проснется и поможет устранить проблему. Конечно, какие-то вещи происходят локально, потому что подобным образом мы повышаем эффективность, но у нас есть инструменты, которые помогают справляться с трудностями. Также мы пользуемся Confluence и Jira, и у нас общие доски. Поэтому вы не столкнетесь с ситуацией, когда кто-то в другом офисе скажет: “Я не знал, что это грядет!”. Так что планирование в некоторой степени происходит глобально. Мы, очевидно, не собираем всех наших разработчиков в одной комнате.
Мы можем осознать, что “ох, нам нужно сделать это в 3.3, потому что это критически важно для 3.4”, и в таком случае все должны быть осведомлены о сложившейся ситуации. Именно так мы выстроили работу компании, чтобы убедиться в распределении знаний.
Wccftech: Несколько коварный вопрос, на который ты, возможно, не захочешь отвечать! Я работал в нескольких местах, где над тобой находится какой-то парень. Он программист, занимает вышестоящий пост в компании, является одним из основателей и делает, что ему захочется. Он выступает и говорит: “Это должно работать вот так!” и затем творит в кодовой базе, что ему вздумается. Во многих случаях все разработчики в компании докладывают Крису, но в то же время, если Крис рассекает код для Star Citizen, он тоже должен кому-то докладывать. Что происходит в такой ситуации? Крис приходит на планирование спринта, где ему назначаются задачи, а его тикеты висят на доске в Jira, где каждый может видеть, чем он занимается? Просматривает ли кто-либо из коллег его код? Или он такой: “к черту всё это, я делаю что хочу, а вы, парни, разбирайтесь с последствиями”?
Эрик Кирон Дэвис: Каверзный вопрос! Для нас очень важно поддерживать максимально близкую связь с продуктом на всех уровнях, особенно со стороны руководства. Для управления этим требуется прикладывать массу усилий, но вся работа по программированию, без сомнения, проверяется коллегами. Пол Рейнделл – наш инженерный директор Star Citizen, но помимо него у нас есть и другие потрясающе талантливые инженеры. И Крис тесно сотрудничает с ними. У нас на всех уровнях поддерживается определенная степень уважения. Шон Трейси знает все о Perforce и о нашем движке, а еще он потрясающе умный парень. Он сказал, что попробует отправить запрос, который очистит всю базу данных только лишь за тем, чтобы посмотреть, что из этого выйдет. Слава богу, запрос был заблокирован! У нас повсюду проверки и балансы. Мы проводим множество тестов, и во всем, что мы делаем, присутствует полноценное чувство разделенной ответственности.
Раньше, когда тут было 10 человек, вещи, пожалуй, работали иначе. Но когда мы выросли, нам потребовалось убедиться, что творческий процесс все еще принимает во внимание нашу независимую натуру, но при этом позволяет выпускать вещи быстрее и лучшего качества, и все вокруг согласны с этим.
Система Stanton
Wccftech: Итак, если бы я был сотрудником CIG, работающим над Star Citizen, я мог бы зайти в вашу Jira и увидеть тикеты, над которыми работает Крис Робертс? Он придерживается процесса? Не нападет ли он на меня, потому что самый главный тут…
Эрик Кирон Дэвис: Может и так… я шучу! Конечно. Тебе нужно понять, что все это выросло из ничего. Если ты пойдешь работать в Activision, у них уже выстроена вся инфраструктура для разработки и производства игр. Для нас в ранний период это просто был найм новых людей и выполнение текущих задач. Так что мы не просто создаем игру и развиваем компанию, но также разрабатываем все процессы, которые нужны, чтобы все это могло функционировать. Поручу ли я какую-то действительно сложную исследовательскую задачу или работу над архитектурой младшему инженеру или передам ее своему Председателю или Тони Зуровеку? Ответ очевиден. Во время работы над каким-то продуктом существует несколько расплывчатая стадия исследования и разработки и прототипирования. Так что для решения таких задач я задействую различные ресурсы.
Существует искусство продюсирования и максимально эффективного применения способностей своих сотрудников. Совершенно не факт, что вы сможете прочитать об этом в книгах, особенно когда вы трудитесь над творческими задачами.
Wccftech: Ранее в проекте значительный объем работ для Star Citizen был проделан на аутсорсе. У меня был некоторый опыт в этой области, и это крайне полезный инструмент. Но в то же время требуется очень высокая степень точности, чтобы процесс производства выполнялся надлежащим образом. Помимо Turbulent, которые больше сосредоточены на веб-сайте, существуют ли сейчас какие-то ключевые компоненты игры, над которыми трудятся аутсорсеры? И если да, как вы их контролируете?
Эрик Кирон Дэвис: Как ты знаешь, и у аутсорсинга, и у домашней разработки существуют свои плюсы и минусы. Когда мы только начали, мы отдали часть задач на аутсорс, чтобы ускорить процесс. Также это позволило нам изучить наши внутренние сильные стороны. Поскольку с тех пор наши студии крупно разрослись, мы теперь используем другой подход. Теперь у меня есть невероятно талантливая команда в Германии, и они разбираются во всем вдоль и поперек. Я каждый день общаюсь с ними, вижу их в своей Jira и в своих процессах. Очевидно, что мы до сих пор прибегаем к услугам аутсорсеров, но поручаем им куда меньше задач по ключевым технологиям игры и гораздо плотнее контролируем их работу. Мы уже видели вещи, которые отдаются на аутсорс. Теперь мы можем использовать их максимально эффективно и действительно быстро вносить в них улучшения.
Wccftech: Говоря о Германии, там работают парни в основном из числа бывших сотрудников Crytek. Создается впечатление, что там сосредоточены, как я их называю, “центры высоких достижений” компании. Даже при том, что здесь идет глобальная работа с передачей задач от одной команды к другой, существуют ли такие вещи, которые в любом случае отправятся в Германию или наоборот, останутся в ЛА?
Эрик Кирон Дэвис: Конечно, но мы не хотим слишком злоупотреблять таким подходом, потому что не хотим сильно зависеть от одного человека или группы.
Wccftech: Большое спасибо, Эрик, за то, что уделил время! Это был прекрасный вводный курс в рабочий процесс Star Citizen и CIG. Быть может, однажды еще увидимся с тобой на мероприятии!
Эрик Кирон Дэвис: Непременно, и увидимся во Вселенной!
Перевод: H_Rush
Редактирование: -W.R.A.I.T.H-
