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

Пользовательские истории или другие объекты, работа с которыми, скорее всего, не будет осуществляться в ближайших итерациях, можно представить в виде эпопей или тем. Такие объекты можно оценивать в единицах за пределами рекомендуемого мною диапазона от 1 до 8. Чтобы оценивать крупные объекты, я добавляю 13, 20, 40 и 100 к своей любимой последовательности 1, 2, 3, 5 и 8.

Наибольшее распространение получили следующие три метода оценки:

• экспертная оценка;

• оценка по аналогии;

• разбивка на более мелкие части.

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

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

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

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

Альтернативой экспертной оценке является оценка по аналогии. Именно к ней мы прибегаем, когда говорим: «Эта история немного больше, чем та история». При оценке по аналогии оценщик сравнивает оцениваемую историю с одной или несколькими другими историями. Если данная история превышает другие по размеру в два раза, то говорят, что она в два раза больше. Существуют явные свидетельства того, что мы оцениваем относительные размеры лучше, чем абсолютные (Lederer and Prasad, 1998; Vicinanza et al., 1991).

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

Разбивка предполагает разделение истории или функции на более мелкие, легче поддающиеся оценке части. Если большинство пользовательских историй, включаемых в проект, требуют для реализации от двух до пяти дней, крайне трудно оценить историю, для реализации которой нужно, скажем, 100 дней. Дело не только в том, что крупные объекты труднее поддаются оценке, в этом случае просто очень мало сходных историй для оценки. Спросить «действительно ли эта история в 50 раз сложнее, чем та?» — совершенно иное дело, чем спросить «действительно ли на эту историю нужно в полтора раза больше времени, чем на ту?».

Для решения подобной проблемы нужно разбить большую историю или функцию на несколько более мелких объектов, а затем провести их оценку. Вместе с тем применять такой подход следует осмотрительно, чтобы не зайти слишком далеко. Наиболее наглядно эту проблему демонстрирует следующий, не относящийся к программному обеспечению пример. Воспользуемся методом разбивки для оценки моего счета в гольфе в эти выходные. Будем считать, что на поле, где я играю, 18 лунок, каждая из которых классифицируется как «пар 4». (Если вы не знакомы с правилами подсчета очков в гольфе, то замечу, что пар — это количество ударов, которые должен сделать игрок, чтобы загнать мяч в лунку.)

Чтобы сделать оценку методом разбивки, нужно оценить мой результат на каждой лунке. Первая лунка довольно легкая, поэтому на ней дадим мне три. На следующей лунке я обычно загоняю мяч в озеро, поэтому здесь семь. Еще там есть лунка с преградой «сэндтрэп»; пусть здесь будет пять. И так далее. Однако если я мысленно представлю все поле, то, скорее всего, забуду об одной из лунок. Конечно, обнаружить это очень легко, поскольку, как известно, должно быть 18 индивидуальных оценок. Когда же мы разбиваем историю, такого контрольного теста у нас нет.

Чрезмерная разбивка приводит не только к повышению вероятности пропуска задачи, суммирование оценок по множеству мелких задач также ведет к проблемам. Например, для каждой из 18 лунок я могу оценить свой результат в диапазоне от 3 до 8. Умножение оценок на 18 дает мне полный диапазон от 54 до 144. Вряд ли я пройду все лунки так хорошо или так плохо. Если меня попросят оценить общий результат, то я, скорее всего, назову диапазон от 80 до 120, что меньше полного диапазона и ближе к реальности.

Конкретная рекомендация по разбивке пользовательских историй приведена в главе 12 «Разбивка пользовательских историй».

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

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

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