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

• Идеальные дни легче использовать для оценки в начальный момент.

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

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

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

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

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

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

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

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