Джесси Шелл - Геймдизайн [Как сознание определяет наше бытие] [litres]

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

• Вопрос цикла 1: Как сделать каждый цикл эффективным?

• Вопрос цикла 2: Как можно максимально ускорить циклы?

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

В 1960-е, когда разработка ПО была относительно новой индустрией, еще рано было говорить о формализации процесса. Программисты просто старались угадать, сколько времени займет процесс, и начинали писать программы. Часто их предположения оказывались ошибочны, и они катастрофически не вписывались в бюджет. В 1970-е с целью привнести немного порядка в эту непредсказуемую сферу, многие разработчики (обычно по распоряжению менеджеров, не имеющих отношения к технологиям) пытались внедрить в разработку ПО «модель водопада»: упорядоченный алгоритм создания ПО за семь шагов. Обычно эта модель выглядела вот так.

И это, конечно, выглядит привлекательно! Модель состоит из семи упорядоченных шагов: выполнив один из них, вы просто переходите к следующему. Само название «водопад» не предусматривает повторов, ведь водопады не текут вверх по течению.

У этой модели несомненно было одно хорошее качество: она мотивировала разработчиков посвящать больше времени планированию и дизайну до того, как они приступят непосредственно к написанию кода. Но в остальном это полная ерунда, подобный подход нарушает Правило цикла. Менеджеры нашли модель привлекательной, но программисты знали, что это абсурд: в применении к таким сложным сферам, как разработка ПО, подобные линейные процессы обречены на провал. Даже Винстон Ройс (Winston Royce), чья работа послужила фундаментом для создания этой модели, не признает ее эффективность в общепринятом виде. Интересно, что в своей работе он подчеркивает важность циклов в разработке и говорит о возможности возврата на несколько шагов назад, если ситуация того требует. И он никогда не использовал слово «водопад»! Но в университетах и корпорациях изучали именно этот линейный подход. Это можно объяснить лишь тем, что люди, которые никогда в жизни не имели дело с разработкой программного обеспечения, принимали желаемое за действительное.

Позже, в 1986-м, Барри Бим представил другую модель, имевшую гораздо больше общего с реальным процессом разработки ПО. Это несколько пугающая своим видом схема, в которой процесс разработки начинается с середины и раскручивается по часовой стрелке, проходя через окружность снова и снова (рис. 8.3).

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

1. Определиться с основой дизайна.

2. Высчитать самые большие риски вашего дизайна.

3. Создать прототипы, которые уменьшат эти риски.

4. Протестировать прототипы.

5. Определиться с более детальным дизайном, основываясь на информации, которую вы получили.

6. Вернуться к пункту 2.

В целом вы просто повторяете этот цикл, пока все не встанет на свои места. При таком раскладе у модели водопада нет никаких шансов, потому что в данном цикле все основывается на вышеупомянутом Правиле цикла. Также это позволяет нам ответить на вопросы, которые мы задавали ранее.

• Вопрос цикла 1:Как сделать каждый цикл эффективным? Ответ спиральной модели:Оцените ваши риски и оптимизируйте их.

• Вопрос цикла 2:Как можно максимально ускорить циклы? Ответ спиральной модели:Создавайте больше «черновых» прототипов.

У спиральной модели было множество последователей, но еще более широкого распространения добился манифест Agile.

В 2001 году на лыжном курорте Сноуберд в штате Юта произошло событие, оказавшее очень сильное влияние на современный геймдизайн и разработку: группа программистов приняла Манифест Agile . Следуя по стопам Барри Бима, они сформировали список ценностей и принципов, лежащих в основе разработки высококачественного ПО. Давайте ознакомимся с самим манифестом и его 12 принципами.

Люди и взаимодействия важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

Готовность к изменениям важнее следования первоначальному плану

Иными словами, мы осознаем ценность понятий, которые находятся справа, но понятия слева мы ценим выше

Мы исповедуем следующие принципы.

1. Наша главная цель – удовлетворить заказчика быстрой и бесперебойной поставкой качественного программного обеспечения.

2. Приветствие изменений требований даже на поздних этапах разработки. Это может повысить конкурентоспособность полученного продукта.

3. Поставлять работающее ПО с частотой от раза в несколько недель до раза в несколько месяцев, стараясь изменять частоту в меньшую сторону.

4. Тесное общение заказчика с разработчиками на протяжении всего проекта.

5. Проектом должны заниматься заинтересованные люди, нужно обеспечить их необходимыми условиями работы, поддерживать их и доверять им.

6. Самый эффективный способ передавать информацию между членами команды – это личный разговор (лицом к лицу).

7. Работающее ПО – лучшая оценка хода процесса.

8. Процессы Agile подразумевают устойчивое развитие. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного срока.

9. Постоянное внимание к улучшению технического мастерства и удобному дизайну увеличивает гибкость.

10. Простота – искусство минимизации лишней работы – крайне необходима.

11. Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды.

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Существует множество методологий, придерживающихся заявленных ценностей и принципов, но чаще других можно услышать про Scrum. Agile и Scrum оказали огромное влияние на разработчиков ПО и, в частности, на разработчиков видеоигр, особенно воодушевленных появлением этих принципов. По моим наблюдениям, около 80 % разработчиков используют в своей работе практики Agile. Если посмотреть на природу этого метода, станет понятно почему.