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

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

Предположим теперь, что вместо обсуждения длины дорожки эти два бегуна начинают обсуждать время, за которое пробегут ее. Быстрый бегун может сказать: «Это пятиминутная дорожка». Медленный бегун может ответить так: «Нет, чтобы одолеть ее, нужно не менее восьми минут». Конечно, и тот и другой правы, но прийти к согласию они могут только в том случае, если всегда будут обсуждать дорожки с точки зрения времени одного из них (или кого-то другого).

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

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

Доводы в пользу идеальных дней

Ниже приводится перечень основных доводов в пользу выбора идеальных дней для оценки размера:

• Идеальные дни легче объяснить за пределами команды.

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

Идеальные дни легче объяснить за пределами команды

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

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

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

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

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

Рекомендации

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