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

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

2. К каким проблемам, на ваш взгляд, приводит разбивка истории на задачи с последующей придачей этим задачам статуса пользовательских историй?

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

Следующие две главы начинаются с рассмотрения принципиальных этапов планирования релиза, а затем итерации. За ними идет глава, в которой предлагаются рекомендации по выбору оптимальной длины итерации. Помимо определения размера подлежащей выполнению работы, если мы хотим узнать, сколько времени займет проект, нам необходимо оценить скорость выполнения этой работы командой. Таким образом, темой очередной главы является оценка скорости.

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

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

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

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

В-третьих, план релиза служит ориентиром, по отношению к которому команда может оценивать прогресс. Без концепции релиза команды бесконечно переходят от одной итерации к другой. План релиза создает контекст, который позволяет объединить итерации в отвечающее запросам потребителей целое. Это фундаментальная цель любого итеративного процесса, а не только agile-процесса. Турист, который хочет добраться до вершины горы, может ориентироваться на самый высокий видимый пик. Однако после достижения этой вершины он узнает, что пик был ложным. Более высокую вершину не было видно за тем пиком, который он покорил. Турист нацеливается на эту, более высокую вершину, но лишь обнаруживает, что и она является ложной, поскольку теперь ему видна еще более высокая вершина. Такой непрямой путь покорения вершин в равной мере применим и к итеративным проектам. К счастью, проблемы, которые он создает, устраняются в результате составления плана релиза, показывающего текущие ожидания команды в отношении того, куда она хочет в конечном итоге добраться.

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

В первом приближении определение того, какой объем работы потребуется для релиза и какие пользовательские истории войдут в него, выглядит очень простым — умножение планового количества итераций на ожидаемую или известную скорость команды дает нам общий объем работы, которую можно выполнить. Затем подбирается такое количество пользовательских историй, которое соответствует общему объему работы. Предположим, что мы хотим отгрузить новый продукт через шесть месяцев. Мы планируем работать двухнедельными итерациями, поэтому в нашем проекте будет 13 итераций. Мы ожидаем, что скорость команды составит 20 пунктов или идеальных дней на итерацию. Тогда размер всего проекта будет равен 13 × 20 = 260 пунктов или идеальных дней. Теперь владелец продукта и команда могут обсудить все истории и определить их приоритет, с тем чтобы создать наибольшую стоимость и при этом не выйти за пределы 260. План релиза обычно представляет собой перечень пользовательских историй, которые будут реализованы в течение проекта.

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

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