Барри Бим любит тебя

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

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

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

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

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

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

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

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

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

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

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

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

Манифест 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 минут и проводятся стоя, что лишь подчеркивает их краткость. Во время такого собрания каждый из членов команды должен объяснить не больше трех вещей: что они сделали вчера, что они собираются сделать сегодня и с какими проблемами они столкнулись. Решение этих проблем обсуждается уже после окончания собрания один-на-один с членами команды, обладающими нужной квалификацией. С таким подходом каждый член команды знает, чем занимаются остальные, и каждый может оперативно получить помощь, если он в ней нуждается.