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

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

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

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

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

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

Теперь, когда я описал суть покера планирования, стоит назвать несколько причин, по которым он работает так хорошо.

Во-первых, покер планирования сводит вместе мнения нескольких экспертов и позволяет получить общую оценку. Поскольку эти эксперты образуют кроссфункциональную команду, представляющую все дисциплины софтверного проекта, они более компетентны в сфере оценки, чем кто-либо другой. На основе тщательного анализа литературы по оценке программного обеспечения Йоргенсен (Jørgensen, 2004) пришел к выводу, что «оценивать задачи должны те, кто наиболее компетентен в их выполнении».

Во-вторых, в процессе игры в покер планирования возникает живой диалог, и оценщики обращаются к мнению коллег для подтверждения своих оценок. Это повышает точность оценки, особенно когда дело касается объектов со значительным уровнем неопределенности (Hagafors and Brehmer, 1983). Обращение за подтверждением оценок в определенной мере компенсирует недостаток информации (Brenner at al., 1996). Это очень важно в agile-проекте, поскольку оцениваемые пользовательские истории нередко намеренно составляются нечетко.

В-третьих, исследования показывают, что усреднение индивидуальных оценок дает лучшие результаты (Hoest and Wohlin, 1998), как и коллективное обсуждение оценок (Jørgensen and Moløkken, 2002). Коллективное обсуждение является основой покера планирования, а такие обсуждения ведут к усреднению различных индивидуальных оценок.

Наконец, покер планирования работает, потому что это занятие доставляет удовольствие.

Более значительные затраты времени и усилий на оценку не обязательно повышают точность результата. Трудозатраты на оценку должны определяться целью этой оценки. Хотя все знают, что наилучшие оценки дают те, кто выполняет работу, в agile-команде исполнитель работы не известен заранее. Таким образом, оценка должна представлять собой коллективную деятельность членов команды.

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

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

1. Насколько правильны ваши оценки сегодня? Какой метод вы в основном используете: экспертную оценку, оценку по аналогии или разбивку?

2. Какую шкалу оценки вы предпочитаете использовать? Почему?

3. Кто должен участвовать в покере планирования для вашего проекта?

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