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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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