Обзор лучших
agile-практик применительно к разработке игр

Страница 1 из 3

Михаил Дубаков
Основатель и CEO TargetProcess, Inc., известной своими разработками по управлению проектами с использованием XP, SCRUM и других Agile методологий.

Вадим Гайдукевич
Разработчик и руководитель проектов в компании Wargaming.net, Inc.

Предисловие

Прежде чем начать читать эту статью, задайте себе всего один вопрос: "Хочется ли мне, чтобы новый проект прошел так же, как предыдущий?"


function bool ShouldIReadTheArticle(bool previousProjectSucceed)
{
	return !previousProjectSucceed;
}

Если входное условие пройдено, начнем.

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

В последнее время разработчики игр все чаще обсуждают и применяют практики, связанные с гибкой разработкой ПО (agile development). Среди наиболее проверенных и работающих практик можно выделить следующие:

  • Итеративная разработка / Iterative Development
  • Юнит тестирование / Unit Testing
  • Разработка через тестирование / Test Driven Development (TDD)
  • Рефакторинг / Refactoring
  • Парное программирование / Pair Programming
  • Постоянная интеграция / Continuous Integration

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

Итеративная разработка и планирование

Цикл разработки приложений известен любому курсанту:

  1. Сбор требований
  2. Планирование
  3. Разработка
  4. Тестирование
  5. Поставка

Типичный проект выглядит примерно так:

  • Сбор требований. Группа заинтересованных лиц собирается и обсуждает проект. Например, пошаговую стратегию. После горячих споров, дюжины ящиков пива и нескольких блоков сигарет рождается диздок, который в какой-то мере описывает будущую игру.
  • Планирование. На работу в срочном порядке нанимается человек, в совершенстве владеющий знаниями о таком сакральном инструменте как MS Project (в игровой компании такого человека обычно нет). В MS Project составляется план проекта с красивой диаграммой Гантта. Такой план очень сильно влияет на инвесторов и помогает выбить деньги под проект. Инвесторы любят красивые диаграммы и толстые документы с описанием требований.
  • Разработка. Когда деньги получены можно заниматься самым интересным - разработкой. Через несколько дней выясняется, что план недостаточно детален для текущих задач и его надо постоянно уточнять и дополнять. План проекта устаревает примерно через полтора месяца, когда желание переделывать его окончательно растворяется в рутине управления проектом. К середине проекта план заменяется документом в Excel, который просто содержит все необходимые требования с оценкой, датой выпуска и ответственными за исполнение. К концу разработки Excel документ также исчезает из процесса и заменяется феноменальной памятью управляющего проектом и прочих руководящих работников.
  • Тестирование. Если в компании есть здравомыслящие люди, то к великому счастью конечных пользователей у нее есть отдел контроля качества (QA - quality assurance). Когда большинство руководящих работников соглашается, что вроде бы все требования реализованы, проект отдается в отдел QA для тщательного тестирования и исправления ошибок. Тестирование и исправление ошибок занимает времени столько же, сколько разработка, потому что именно сейчас выясняется и уточняется огромное количество деталей.
  • Поставка. Альфа-версия вылетает не оттестированой. Бета-версия выбегает не оттестированной. Демо-версии выходят не оттестированными. Версия к выставке выходит не оттестированной. Голд-мастеру везет больше, и он выползает оттестированным и в принципе довольно стабильным, если конечно QA отдел в компании работает. Голд-мастер никогда не выходит вовремя, особенно если эта дата отражена в первоначальном плане в MS Project.

Вот типичная схема "водопадного" процесса (Waterfall).

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

  1. Короткий цикл разработки / Short development life-cycle
  2. Фиксированные интервалы / Time Boxing

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

Второй принцип требует, чтобы итерации были одинаковой длины. Например, итерации могут длиться один месяц. Первая итерация - 1 месяц, вторая итерация - 1 месяц и так далее. Совершенно необходимо через месяц выпустить продукт, который можно проинсталлировать и показать конечному пользователю. Фиксирование длины итерации дает огромное преимущество для контроля за ходом проекта. Если в первой итерации команда выполнила объем работ в 200 идеальных дней, то во второй итерации объем работ будет примерно таким же. Так что уже после первых двух итераций есть представление о том, какая скорость разработки и когда продукт будет выпущен.

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

  • Сбор требований. Группа заинтересованных лиц собирается и обсуждает проект. Например, пошаговую стратегию. После горячих споров, дюжины ящиков пива и нескольких блоков сигарет рождается диздок, который максимально кратко описывает будущую игру.
  • Планирование. Из требований составляется список. Каждое требование оценивается и устанавливается его полезность (Business Value). Самые полезные требования планируются на первый релиз, из них выбирается некоторое количество требований на первую итерацию. Таким образом, за несколько часов составляется план релиза и план первой итерации. Все остальные требования лежат мертвым грузом и терпеливо ждут. Каждое требование в первой итерации разбивается на задачи. Команда собирается и быстренько расхватывает самые интересные задачи как горячие пирожки. Неинтересные задачи достаются самым безынициативным и неопытным программистам.
  • Разработка. Каждое утро команда собирается вместе и каждый разработчик рассказывает, что он сделал вчера, какие были проблемы, и что он будет делать сегодня. Лидер проекта помечает все сделанные задачи и отражает прогресс команды с помощью Burn down chart, который висит в красном углу поверх пыльной диаграммы Гантта из предыдущего проекта. Все четко знают, какая ситуация в текущей итерации. Все знают скорость команды и представляют, что она может сделать за одну итерацию, а что нет.
  • Тестирование. Тестирование начинается одновременно с началом первой итерации. Вместо привычного разноса кофе и закупки булочек тестировщики уже пишут тест кейсы для требований из первой итерации. Как только разработка требования закончена, QA с радостью берут промежуточный билд и тестируют его на предмет соответствия тест кейсам. Найденные дефекты тут же исправляются разработчиками по горячим следам. Поставка. Альфа версия вылетает оттестированной и вовремя. Бета версия выбегает оттестированной и вовремя. Демо версии выходят оттестированными и вовремя, за редким исключением. Версия к выставке выходит оттестированной и практически со всем запланированным к выставке функционалом. Голд мастер выходит оттестированным и стабильным. Голд мастер запаздывает редко.

У итеративного процесса несколько преимуществ по сравнению с традиционным водопадом:

  • Требования уточняются после каждой итерации, потому что заказчик получает готовый продукт, но с ограниченным функционалом.
  • Задается четкий ритм проекта.
  • Значительно упрощается внесение изменений в требования проекта.
  • Улучшается качество за счет раннего и немедленного тестирования функционала в каждой итерации.
  • Снижается время и стоимость исправления каждого дефекта за счет раннего тестирования.
  • Увеличивается предсказуемость проекта и сроки его завершения.

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

Рекомендуемая длина итерации при разработке игр - 2-4 недели, но это сильно зависит от команды. При разработке игр есть вероятность, что за первую/ вторую итерацию ничего работающего выпустить не получится. Но надо стремиться к тому, чтобы запускающаяся игра с минимальным функционалом появилась как можно раньше.

Разбиение требований

Специфика разработки игр в том, что обычно программистов в составе команды всего около 20-25%. Остальная команда состоит из художников, 3d-моделлеров, тестировщиков и еще многих других людей занятных профессий. Важно научиться не просто выделять отдельные фичи (Feature), но и уметь эти фичи разбивать на пользовательские истории (User Story) и задачи (Task).

Пользовательская история это, собственно, история, рассказанная пользователем. Например, увлеченный продюсер смотрит на голубое небо и говорит мечтательным голосом: "А еще в этой замечательной игре обязательно должны быть авианосцы. С каким наслаждением я создам себе небольшую эскадру с парочкой авианосцев, аккуратно подплыву к берегам наглой маленькой страны и нанесу ракетно-бомбовый удар по позициям зарвавшегося соседа".

Из всего этого инфантильного монолога можно выделить всего одно требование: мальчик хочет авианосец с самолетиками.

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

Фича: Сделать авианосец.
Пользовательские истории (с точки зрения игрока):

  • В игре должен быть авианосец, который может плавать только по глубоким морям и не может зайти в порт (потому что он большой).
  • Самолеты взлетают и садятся на авианосец.

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

  1. Обсудить на предмет здравого смысла ("Эта идея с летающей подводной лодкой совершенно идиотская").
  2. Выбрать те истории, которые в принципе должны быть реализованы в игре.
  3. Грубо оценить трудозатраты на реализацию этих историй.
  4. Расставить приоритеты ("Какая история важная?", "Какая не очень важная?").

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

Ниже в качестве примера приведены Истории пользователя/Задачи (с точки зрения разработчика) для авианосца.

  • Создать юнит авианосца:
    • Набросок авианосца (художник)
    • 3D-модель авианосца (3d-моделлер)
    • Текстура авианосца (художник)
    • Анимация (аниматор)
    • Спецэффекты (художник по спецэффектам)
    • Озвучивание авианосца (звукорежиссер)
  • Вставить авианосец в игру:
    • Создать набор тест кейсов для авианосца (QA)
    • Программирование логики (плавает по морю) (программист)
    • Программирование логики (не может заходить в порты) (программист)
    • Программирование логики (перевозка самолетов, посадка и взлет самолетов) (программист)
  • Научить AI пользоваться авианосцем:
    • Программирование стратегии (программист АИ)
    • Программирование тактики (программист АИ)

Более подробно прочитать про Agile-планирование можно здесь[3].

 
  стр. 1 из 3  

Copyright © 2017 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение