Спринты. Вместо того чтобы фокусироваться на выполнении долгосрочной (многомесячной) цели, в Agile программисты работают сериями так называемых спринтов – коротких этапов (несколько недель) с четко сформулированными задачами, решение которых необходимо предоставить к концу этапа. Основатель Atari Нолан Бушлелл как-то сказал: «Лучший источник вдохновения – это дедлайн», и это правда. Часто случается, что задачи волшебным образом выполняются, когда дедлайн уже рядом, и именно эта философия лежит в понятии спринтов: чем больше дедлайнов, тем больше задач будет сделано.
Scrum-собрания. Вместо еженедельных собраний для подведения итогов в Agile разработчики проводят ежедневные scrum-собрания, специально созданные для краткости и эффективности. Обычно эти собрания длятся всего 10–15 минут и проводятся стоя, что лишь подчеркивает их краткость. Во время такого собрания каждый из членов команды должен объяснить не больше трех вещей: что они сделали вчера, что они собираются сделать сегодня и с какими проблемами они столкнулись. Решение этих проблем обсуждается уже после окончания собрания один-на-один с членами команды, обладающими нужной квалификацией. С таким подходом каждый член команды знает, чем занимаются остальные, и каждый может оперативно получить помощь, если он в ней нуждается.
День демо. В конце каждого спринта команда собирается вместе, лицом к лицу, чтобы посмотреть на результаты. В этот день команда проводит анализ рисков и планирует следующий спринт.
Ретроспективы. Также в конце каждого спринта команда проводит «ретроспективное совещание», на котором обсуждает не столько продукт, над которым работает, столько используемые процессы. Это возможность обсудить, что команда делает правильно, а что – нет, и то, как им следует улучшить процессы для следующего спринта.
Важно помнить, что Agile – это философия, а не четко сформулированная методология и что разные разработчики могут трактовать эту философию по-разному. Несмотря на то что подходы разных команд могут различаться, все они преследуют одну цель: осуществить как можно больше итераций и сделать все, чтобы каждая из них была результативна с точки зрения управления рисками и целей прототипирования.
Предположим, вы с вашей командой решили сделать игру о прыжках с парашютом в городскую местность. У вас уже есть краткое описание дизайна, основанное на элементной тетраде.
Prisoners of Bubbleville. Краткое описание
История. Вы – кот-парашютист по имени Смайли. Добрые жители городка Баблвилля оказались заперты в собственных домах силами злого волшебника. Ваша задача – найти способ победить волшебника, для этого вы раз за разом прыгаете с парашютом в город и через дымоходы спускаетесь в дома горожан, чтобы получить от них подсказки.
Механика. Спускаясь по направлению к городу, вы должны собирать волшебные пузыри, которые поднимаются в воздух. Они дают вам энергию, необходимую для стрельбы по стервятникам, которые будут пытаться лопнуть пузыри и порвать ваш парашют. Одновременно вы должны направлять персонажа к целевым зданиям, на которые нужно приземлиться.
Эстетика. Мультипликационная графика.
Технология. Мультиплатформенная консольная игра на трехмерном движке от стороннего разработчика.
Вы могли бы просто приступить к созданию игры. Начать писать код, разрабатывать детальный дизайн уровней, потом собрать все вместе и посмотреть, что игра из себя представляет. Но, как мы уже выяснили, такой подход может быть чрезвычайно опасным. При условии, что ваш проект рассчитан на 18 месяцев, вам понадобится минимум шесть месяцев только на то, чтобы получить материал для первого плейтеста. Но вдруг после него вы поймете, что в вашей игре нет фана? Или движок не подходит под ваши цели? У вас были бы большие проблемы. Вы потратили треть доступного времени, а ваша игра прошла только один цикл!
Вместо этого соберитесь со своей командой и проведите анализ рисков. Составьте список всех обстоятельств, способных поставить под угрозу ваш проект. Список рисков для этой игры выглядит приблизительно так.
Prisoners of Bubbleville. Список рисков
Риск 1. Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется.
Риск 2. Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников.
Риск 3. Согласно нашему изначальному видению, для игры нам потребуется тридцать разных домов: создание такого числа различных интерьеров и анимированных персонажей может занять больше времени, чем мы предполагали.
Риск 4. Мы не уверены, что людям понравятся наши персонажи и история.
