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

Ретроспективы. Также в конце каждого спринта команда проводит «ретроспективное совещание», на котором обсуждает не столько продукт, над которым работает, столько используемые процессы. Это возможность обсудить, что команда делает правильно, а что – нет, и то, как им следует улучшить процессы для следующего спринта.

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

Пример: Prisoners of Bubbleville

Предположим, вы с вашей командой решили сделать игру о прыжках с парашютом в городскую местность. У вас уже есть краткое описание дизайна, основанное на элементной тетраде.

Prisoners of Bubbleville. Краткое описание

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

Механика. Спускаясь по направлению к городу, вы должны собирать волшебные пузыри, которые поднимаются в воздух. Они дают вам энергию, необходимую для стрельбы по стервятникам, которые будут пытаться лопнуть пузыри и порвать ваш парашют. Одновременно вы должны направлять персонажа к целевым зданиям, на которые нужно приземлиться.

Эстетика. Мультипликационная графика.

Технология. Мультиплатформенная консольная игра на трехмерном движке от стороннего разработчика.

Вы могли бы просто приступить к созданию игры. Начать писать код, разрабатывать детальный дизайн уровней, потом собрать все вместе и посмотреть, что игра из себя представляет. Но, как мы уже выяснили, такой подход может быть чрезвычайно опасным. При условии, что ваш проект рассчитан на 18 месяцев, вам понадобится минимум шесть месяцев только на то, чтобы получить материал для первого плейтеста. Но вдруг после него вы поймете, что в вашей игре нет фана? Или движок не подходит под ваши цели? У вас были бы большие проблемы. Вы потратили треть доступного времени, а ваша игра прошла только один цикл!

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

Prisoners of Bubbleville. Список рисков

Риск 1. Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется.

Риск 2. Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников.

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

Риск 4. Мы не уверены, что людям понравятся наши персонажи и история.

Риск 5. Вполне возможно, что выйдет какой-то фильм о парашютных трюках и издатель захочет, чтобы наша игра была привязана к тематике этого фильма.

На деле рисков будет куда больше, но ради нашего эксперимента мы ограничимся только этими. Так что же делать с рисками? Мы могли бы скрестить пальцы и понадеяться, что ничего из вышеперечисленного не произойдет. Или поступить умнее: оптимизировать риски. Чтобы смягчить или даже предотвратить риски, нам потребуется разработка небольших прототипов. Давайте рассмотрим, как можно оптимизировать каждый из описанных рисков.

Prisoners of Bubbleville. Оптимизация рисков

Риск 1. Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется.

Чаще всего игровую механику можно представить в упрощенной форме. Пусть программист создаст очень абстрактную версию вашей механики, например в 2D, с простыми геометрическими фигурами вместо анимированных персонажей. Таким образом вы сможете получить рабочую версию игры в течение первых двух недель, что позволит вам провести первые тесты и понять, интересна ли ваша механика. Если нет – вы сможете без особых затрат вносить коррективы в упрощенный прототип до тех пор, пока тот не станет достаточно интересным, и лишь после этого приступить к разработке сложной 3D-версии. Впереди вас ждет множество циклов, и грамотное применение Правила цикла предоставит вам ряд преимуществ. Разумеется, вы можете не согласиться с этим подходом, резонно заметив, что разработка 2D-прототипа, которого игрок никогда не увидит, – трата времени. Но это позволит вам сэкономить время на последующих этапах: вы сможете раньше приступить к написанию правильного варианта игры, а не бесконечно писать и переписывать неправильные варианты.

Риск 2. Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников.

Если вы будете ждать, пока художники закончат свою работу и смогут ответить на этот вопрос, вы можете попасть в весьма затруднительное положение. Если движок не справляется со своей задачей, вам придется обратиться к художникам с просьбой облегчить графику, или же просить программистов уделить больше времени на доработку движка (или, что вероятнее, и то и другое). Чтобы снизить риск, создайте быстрый прототип, показывающий приблизительное количество графических элементов на экране, и вы узнаете, сможет ли движок их поддержать. В прототипе нет гейм-плея, он нужен исключительно для тестирования технических лимитов. Если вы видите, что движок справляется, – отлично! Если нет – у вас есть возможность приступить к поиску решения проблемы до того, как вся графика будет готова.

И да, это снова исключительно «одноразовый» прототип.

Риск 3. Согласно нашему изначальному видению, для игры нам потребуется тридцать разных домов – создание такого числа различных интерьеров и анимированных персонажей может занять больше времени, чем мы предполагали.

Если вы, пройдя полпути разработки, внезапно осознаете, что у вас недостаточно художников для отрисовки всей графики в срок, вы обречены. С самого начала попросите художника создать один дом и одного анимационного персонажа, чтобы получить представление о том, сколько времени это может занять. Если это занимает больше времени, чем вы можете себе позволить, сразу же меняйте дизайн – может быть, вам и не нужно столько домов, некоторых персонажей и интерьеры можно использовать повторно.