В 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. Если посмотреть на природу этого метода, станет понятно почему.

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

Гибкие цели. Центральным понятием Agile-философии является утверждение, что мы не можем знать точно, какой результат получится в конце разработки. Команда куда легче приспосабливается к новым идеям по ходу разработки, если заранее не только допускает возможность внесения изменения в утвержденный план, но и действительно готова их вносить.

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

Спринты. Вместо того чтобы фокусироваться на выполнении долгосрочной (многомесячной) цели, в Agile программисты работают сериями так называемых спринтов – коротких этапов (несколько недель) с четко сформулированными задачами, решение которых необходимо предоставить к концу этапа. Основатель Atari Нолан Бушлелл как-то сказал: «Лучший источник вдохновения – это дедлайн», и это правда. Часто случается, что задачи волшебным образом выполняются, когда дедлайн уже рядом, и именно эта философия лежит в понятии спринтов: чем больше дедлайнов, тем больше задач будет сделано.

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

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

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

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