Agile: оценка и планирование проектов

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

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

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

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

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

Более быстрое добавление деталей в пользовательские истории

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

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

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