Майк Кон - Agile: оценка и планирование проектов

11. Оставляйте небольшой резерв.Особенно при планировании итерации не пытайтесь задействовать 100 % времени каждого члена команды. Точно так же, как на шоссе возникает пробка при его загрузке на 100 %, команда разработчиков начинает работать медленнее, когда время каждого члена команды полностью заполнено.

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

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

1. Есть ли другие причины, которыми, на ваш взгляд, объясняется успех agile-подхода к оценке и планированию?

2. Какие из 12 правил применимы к вашему текущему процессу оценки и планирования? Будет ли полезно следовать другим правилам?

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

В этой главе описывается вымышленная ситуация, однако в ней обобщаются многие ключевые моменты книги. В данной главе представлена выдуманная компания Bomb Shelter Studios, которая осуществляет свой первый agile-проект. В процессе повествования вы познакомитесь со следующими персонажами:

• Аллан — программист;

• Делани — аналитик;

• Карлос — agile-тренер;

• Лора — финансовый директор;

• Прасад — тестировщик;

• Роуз — художник;

• Саша — программист;

• Фил — генеральный директор;

• Фрэнк — менеджер по продукту.

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

Как менеджер по продукту в Bomb Shelter Studios, он знал, что их последняя игровая программа Deep Black & White демонстрировала хорошие результаты. Она позволяла играть в игру под названием го, которая была чрезвычайно популярна в Японии, Китае и Корее, но вызывала лишь умеренный интерес в Европе, Северной Америке и остальном мире. Программисты из его команды использовали решения на основе искусственного интеллекта, которые позволили Deep Black & White дойти в игре до уровня сложности, известного как пятый дан. Это, конечно, далеко от девятого дана — уровня лучших профессиональных игроков, однако значительно лучше, чем у конкурентов компании Bomb Shelter.

Фрэнк был полон энтузиазма в отношении выпуска и продажи Deep Black & White в Азии через одного издателя, с которым удалось договориться о дистрибуции во время конференции. Доход от продаж на этих рынках был бы очень кстати для Bomb Shelter. Фрэнк знал: дополнительные шесть месяцев, которые потребовались для завершения Deep Black & White, чуть было не привели к разорению небольшую частную компанию по разработке игр, соучредителем которой он являлся.

Из малоперспективной начинающей компании за три года Bomb Shelter Studios превратилась в признанного разработчика интеллектуальных и стратегических игр. В дополнение к только что законченной Deep Black & White у Bomb Shelter были программы для игры в шахматы, триктрак, реверси, бридж, шашки, манкалу и др. После создания игры права на ее дистрибуцию продавались тому или иному издателю, который занимался производством и распространением, позволяя Bomb Shelter полностью сконцентрироваться на разработке новых игр.

Пока Фрэнк был на конференции, его аналитик и небольшая команда в Санта-Барбаре обдумывали новую игру Havannah, разработку которой они были практически готовы начать. Из-за проблем с Deep Black & White — не только из-за шестимесячной задержки, но и из-за слишком большого количества ошибок и обнаруженного в последний момент неудобства использования — им нужно было срочно найти другой подход к планированию и реализации проектов. Саша, ведущий разработчик архитектуры в компании, проработала ряд выдвинутых командой идей. Она предложила в следующем проекте использовать то, что называют «agile-процесс». Фрэнк не совсем понимал, что это означает, однако у него не было сомнений в том, что им нужно подходить к делу по-другому. Шестимесячное опоздание с выпуском следующей игры было бы концом. Все члены команды горели идеей попробовать agile-процесс и знали, чтó поставлено на кон.

— Всем привет, — сказал Фрэнк, входя в конференц-зал. До девяти оставалась еще целая минута, однако почти вся команда была в сборе и ожидала его появления. Это был хороший знак. Несмотря на то, что команда измоталась в процессе последнего рывка с Deep Black & White, она выглядела так, словно была готова взяться за разработку Havannah.

— Привет, Фрэнк. Я видел твое электронное письмо о Deep Black & White. Сделка по дистрибуции — отличная новость, — сказал Аллан, программист C++, который разрабатывал игровой движок на искусственном интеллекте, сделавший Deep Black & White таким сильным игроком.

— Возьми пончик, Фрэнк, — предложила Саша и подвинула к нему почти пустую коробку.

— Спасибо, — ответил Фрэнк и запустил руку в коробку.

— Фрэнк, это Карлос, — сказала Саша. — Он опытный agile-тренер. Мы пригласили его, чтобы он помог нам освоить этот новый agile-подход к работе.

Фрэнк и Карлос обменялись рукопожатиями и приветствиями.

— Похоже, все в сборе, за исключением Роуз, — сказал Фрэнк. — Давайте начнем. Мы введем ее в курс дела позже. Вряд ли на этом совещании разговор пойдет о художественном оформлении.

— Мы не можем начать, Фрэнк, — сказал Карлос. — Это важный момент. Нужно, чтобы присутствовала вся команда . Значительная часть выгоды, которую мы хотим получить в результате применения agile-процесса, зависит от участия всех членов команды. Роуз, возможно, мало что скажет об искусственном интеллекте в игровом движке, но нам все равно нужно знать ее мнение, если мы хотим создать лучшую игру.