Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
То есть во время спринта или даже целого этапа проекта мы можем всегда понимать, отстаем ли мы в среднем от графика или опережаем его, что в дальнейшем поможет нам принять верное решение о скоупе проекта. Нужно ли нам еще больше сокращать проект? (Вот тут пригодятся приоритеты, которые мы устанавливаем для каждой задачи.) Должны ли мы привлечь в команду больше людей? Можем ли мы предпринять другие меры – действуя на опережение, – чтобы успеть отполировать игру до высокого уровня качества?
На рис. 19.6 вы можете увидеть ту же инфографику диаграммы сгорания задач через несколько дней после рис. 19.4 и 19.5. Обоим членам команды удалось выполнить еще немного работы, но их скорость значительно снизилась. Вы можете видеть, что ступени лестницы на сером фоне становятся все мельче. Возможно, команда столкнулась с неожиданными проблемами в разработке, из-за которых задачи занимали намного больше времени, чем ожидалось, или, возможно, какие-то внешние факторы отвлекли их от работы над проектом.
Теперь линия больше не касается горизонтальной оси инфографики, а это значит, что всю работу едва ли получится выполнить. По инфографике мы можем понять, что если команда продолжит работать с той же средней скоростью, то ко 2 августа, последнему дню спринта, останется около двенадцати часов работы.
Рис. 19.6. Та же инфографика диаграммы сгорания задач через несколько дней. Авторы изображения: Джереми Гибсон Бонд, Ричард Лемаршан, Питер Бринсон и Аарон Чейни
Теперь этой команде надо составить план, чтобы вернуть проект в нужное русло. Их проект в настоящее время выходит за рамки этого спринта. Скорее всего, им придется убрать некоторые задачи, или они могут подождать еще пару дней, чтобы посмотреть, не увеличится ли их рабочая скорость. Возможно, они переоценили количество времени, которое займет выполнение следующих нескольких задач, и их средняя скорость работы снова увеличится. Тем не менее они должны начать составлять план того, что смогут убрать, чтобы успеть все вовремя.
Решаем, что можно убрать
Почти в каждом игровом проекте приходится рано или поздно сокращать масштабы игры на этапе продакшена. Вырезание фич и контента для соблюдения сроков – это ключевой навык, которому должен научиться каждый гейм-дизайнер. Когда мы решаем, что сократить, нашими первыми кандидатами становятся задачи с низким приоритетом. Думая над дизайном нашей игры при определении приоритетов, мы уже прикидываем, без чего можно обойтись. (Пожалуйста, обратите внимание, что, в зависимости от структуры проекта, мы можем либо полностью убрать что-то из игры, либо убрать что-то из текущего спринта и, возможно, перенести в следующий.)
Однако не каждую низкоприоритетную задачу можно запросто выкинуть. Одни задачи удалить будет куда проще, нежели другие. Некоторые относительно низкоприоритетные задачи на самом деле могут быть прочно закреплены в дизайне игры благодаря их взаимосвязи с другими ее частями. Марк Черни недавно напомнил мне: «Здесь важно знать, какие части можно удалить, а какие нельзя. Если какая-то локация необходима для развития повествования или персонажа, ее нельзя убрать… поэтому очень важно постоянно проверять содержание проекта и корректировать дизайн со знанием того, что необходимо сохранить. Таким образом, вы сможете вносить коррективы на поздних стадиях разработки, не вредя игре». У каждого типа игр есть свои критерии относительно того, что можно легко вырезать, а что должно остаться, и по мере развития ваших навыков в гейм-дизайне вы научитесь отличать одно от другого.
Изменение планов в диаграмме сгорания задач
Когда мы поймем, что не справляемся с объемом работ для текущего спринта (периода проекта, охватываемого диаграммой сгорания задач), и решим что-то вырезать, мы должны удалить уже ненужные задачи из диаграммы. Лучший способ сделать это – зачеркнуть задачу в электронной таблице и в столбце с расчетным временем этой задачи поставить ноль. (Иногда в диаграммах сгорания задач удаление строки приводит к поломке самой диаграммы, к тому же я предпочитаю видеть то, что было вырезано – зачеркивание вполне выполняет эту задачу.) Это уберет вырезанные задачи из вычислений, и линия переместится налево, поскольку теперь до конца спринта осталось меньше работы.
Если вы обнаружите, что сильно недооценили время, необходимое для выполнения задач, или что вам нужно выполнить новые задачи, работу над которыми вы не предполагали, перед вами встанет выбор. Как правило, добавлять задачи в диаграмму сгорания задач или увеличивать расчетное время в середине спринта – плохая идея, потому что это может сбить расчеты. Вы можете просто продолжить работу до тех пор, пока не закончите задачи, время на выполнение которых вы недооценили, убрав при этом другие задачи из спринта. Однако это путь вслепую. Как правило, лучше начать новый спринт в конце недели с обновленным списком задач и лучшими прогнозами.
Диаграмма сгорания задач – это вспомогательное средство для выполнения расчетов. Это не способ узнать будущее наверняка, но это невероятно мощный инструмент для понимания того, как продвигается наша разработка. По моему опыту, разработчики игр (включая меня!) плохо прикидывают время завершения работ. Математика, спрятанная внутри диаграммы сгорания задач, устраняет этот наш недостаток. Ни один метод планирования не работает так же отлично, как диаграмма сгорания задач, особенно при планировании относительно коротких проектов или коротких периодов работы.
Большое спасибо Джереми Гибсону Бонду, разработавшему оригинальную диаграмму сгорания задач, из которой взяты эти примеры, и научившему меня ею пользоваться. Вы можете найти более подробную информацию об использовании диаграмм сгорания задач в его превосходной книге «Unity и C#. Геймдев от идеи до реализации»[132]. (Кстати, я написал предисловие!)
Диаграммы сгорания задач создают атмосферу доверия и уважения
Методы организации производства и инструменты планирования
