Геймдизайн - Джесси Шелл Страница 34

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

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

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

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

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

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

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