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

— И такая оценка будет довольно точной? — спросил Фрэнк.

— Должна быть. После трех итераций у вас будет хорошее представление о том, сколько пунктов вы можете реализовать за двухнедельную итерацию, — ответил Карлос.

— Не следует забывать, что я собираюсь поговорить еще с некоторыми потенциальными покупателями и могу обнаружить новые привлекательные функции, — сказала Делани. — Как уже говорилось, наши существующие привлекательные функции слабоваты, и было бы неплохо дополнить их.

— Но можно хоть как-то оценить сроки прямо сейчас?

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

— Я уже сделал это, — сказал Прасад. — Сумма равна 18. Восемь пунктов приходится на историю «Как игрок я могу играть против слабого движка, распознающего только кольца», пять пунктов — на историю «Как игрок я могу играть против слабого движка, распознающего только мосты», два пункта — на историю «Как игрок я хочу, чтобы компьютер распознавал выигрышную фигуру» и три пункта — на историю «Как игрок я хотел бы иметь возможность использовать систему для игры с другим человеком на моем компьютере».

— Сколько итераций потребует реализация проекта при скорости 18?

— Чуть больше семи итераций. У нас 132 пункта. Семь на 18 — это 126. Итого шесть пунктов сверх семи итераций, — сказал Прасад.

— Можем ли мы сказать, что нам нужно семь итераций? — спросил Фрэнк.

— Можем, но делать этого не стоит, — ответил Карлос. — Я предпочитаю давать оценки в виде диапазона. Если посмотреть на объем работы, которая приходится на восьмую итерацию, то лучше всего сказать, что проект займет от шести до 10 итераций.

— Мне как-то не хочется, чтобы этот проект растягивался на 20 недель. Но ты говоришь, что он может занять и 12 недель, так ведь? — спросил Фрэнк.

— Может, но с равным успехом может растянуться до 20, — настаивал Карлос. — Чтобы этого не случилось, ты можешь удалить наименее приоритетные функции, если скорость покажет, что мы ближе к 10 итерациям. Не забывайте также, что Делани активно занимается поиском новых функций. Если она обнаружит что-то, нам придется отодвинуть срок или отказаться от каких-нибудь текущих функций.

— Ну хорошо, я смогу объяснить руководству разброс от 12 до 20 недель, — сказал Фрэнк. — Давайте теперь займемся нашим начальным планом.

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

— Понимаю. Но все хотят знать хотя бы на уровне идеи, как выглядят сроки реализации этого проекта.

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

— Так нам нужен план того, над чем мы будем работать в каждой итерации? — спросил Фрэнк.

— Не совсем, — ответил Карлос. — Самое важное — это знать, что будет разрабатываться в следующей итерации. Мы делали это, когда планировали итерацию. Следующий важный момент — определить те функции в конце списка, которые можно включать в релиз, а можно и не включать.

— Я понимаю, зачем нужно знать главные приоритеты, но зачем нам функции из нижней части списка? — заметил Фрэнк.

— Это не так важно для первого совещания, но ситуация меняется по мере приближения к завершению релиза. Например, вряд ли мы захотим, чтобы маркетинговая служба разработала упаковку с надписью «Теперь с музыкальным фоном», если эта функция может быть выброшена в последнюю минуту.

— Хорошо, но почему бы не потратить сегодня немного времени на планирование того, что мы будем делать в каждой итерации?

— Нет смысла, — ответил Карлос. — Через две недели мы будем знать намного больше, чем сегодня. Зачем планировать то, что мы будем делать в итерации, до того, как возникнет необходимость? Этого не нужно делать. В крупном проекте, особенно с участием нескольких команд, работу которых необходимо координировать, можно забегать вперед на две-три итерации. Но в нашем проекте это ни к чему.

— Так мы закончили с планированием релиза? — спросил Фрэнк.

— Да. Я сейчас соберу карточки историй, которые вы определили как действительно необходимые в релизе, это и будет нашим планом, — сказал Карлос. — Прежде чем мы вновь соберемся через две недели, вы с Делани должны рассмотреть истории и определить те, которые, вероятнее всего, войдут в следующую итерацию. На совещании мы поговорим о том, почему вы остановились именно на этих историях. Другие участники могут попросить вас пересмотреть или добавить одну или две истории, которые они считают рискованными или о которых получили новую информацию в процессе разработки. Так или иначе, окончательное решение о приоритизации принимаете вы.

— Не пойми меня неправильно, — сказал Фрэнк, — но я не уверен, что справлюсь с этим сегодня.

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

— Абсолютно. Будет чудесно увидеть все это через две недели.