Покер планирования

На мой взгляд, наилучший для agile-команд способ оценки — это покер планирования (Grenning, 2002). Покер планирования объединяет экспертную оценку, оценку по аналогии и разбивку в удобный подход, позволяющий быстро получить надежные результаты.

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

Перед началом процесса каждому оценщику дают колоду карт. На каждой карте написана одна из возможных оценок. Оценщик может получить, например, колоду карт, на которых написано 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Карты необходимо подготовить до начала игры в покер планирования, а цифры, написанные на них, должны быть достаточно крупными, чтобы разглядеть их с другого конца стола. Карты можно сохранить и использовать в следующей сессии покера планирования.

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

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

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

Например, оценщик с максимальным результатом может сказать: «Ну, чтобы протестировать эту историю, нам нужно создать мок-объект. На это может уйти целый день. Кроме того, я не уверен, что стандартный алгоритм сжатия будет эффективен, а раз так, то нам, возможно, придется писать новый». Оценщик с минимальным результатом может сказать: «Я полагал, что мы будем хранить эту информацию в XML-файле — это было бы легче, чем создавать базу данных. К тому же я не подумал об увеличении объема данных — это может стать проблемой».

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

Во многих случаях уже во втором раунде оценки сходятся. Если этого не происходит, повторите процесс. Цель заключается в получении одной оценки, которую можно использовать для истории. Редко когда требуется более трех раундов оценки, однако продолжайте процесс до тех пор, пока оценки не сблизятся. Совершенно не обязательно, чтобы все присутствующие открыли карту с одной и той же оценкой. Если бы я вел заседание, посвященное оценке, и во втором раунде результаты четырех оценщиков выглядели бы как 5, 5, 5 и 3, то я бы спросил оценщика с минимальным результатом, не согласится ли он на оценку 5. Подчеркну, что целью является не абсолютная точность, а разумность.

Правильная продолжительность дискуссии

Предварительное обсуждение дизайна всегда полезно для оценки. Вместе с тем чересчур длительное обсуждение приводит к слишком сильному смещению команды вправо по кривой «усилия/точность» (рис. 6.1). Существует простой способ поддержать дискуссию, но не дать ей затянуться.

Приобретите песочные часы на две минуты и поставьте их на центр стола, за которым сидят участники покера планирования. Любой из присутствующих может в любой момент перевернуть часы. Когда песок кончается (истекают две минуты), начинается следующий раунд игры в карты. Если согласие не достигается, дискуссию можно продолжить, но при этом кто-нибудь должен сразу же перевернуть часы, чтобы ограничить ее двумя минутами. Редко когда часы переворачиваются более двух раз. Такой прием со временем помогает команде научиться быстрее приходить к общей оценке.