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

Посмотрим, что произойдет, если провести переоценку. Допустим, я переоцениваю пять реализованных историй и присваиваю каждой из них оценку «два». Моя скорость теперь составляет 10 (пять реализованных историй, каждая по два пункта), а объем оставшейся работы — 45 пунктов. При скорости 10 и оставшихся 45 пунктах я рассчитываю завершить проект за 4,5 итерации. Проблема здесь состоит в смешивании пересмотренной и первоначальной оценок. Я задним числом переоценил реализованные истории и назначил каждой два пункта. К сожалению, глядя на оставшиеся 45 историй, я не могу предсказать, какие из этих однопунктовых историй мне захочется переоценить задним числом в два пункта.

Продолжим работать с сайтом SwimStats, в этот раз пользовательские истории и оценки приведены в табл. 7.2.

Первые три истории связаны с построением графика для пользователя. Допустим, команда запланировала включить в первую итерацию истории 1, 2 и 6 из табл. 7.2. Ее плановая скорость составляет 13. Однако к концу итерации она реализовала только истории 1 и 6. По словам членов команды, они сделали меньше предполагаемого потому, что история 1 оказалась значительно более трудоемкой, чем ожидалось, и должна оцениваться «как минимум в шесть пунктов». Предположим, что команда недооценила не одну историю, а трудоемкость построения графиков в целом. В этом случае, если история 1 оказалась в два раза более трудоемкой, чем ожидалось, мы должны быть готовы повысить также и трудоемкость историй 2 и 3.

Рассмотрим три сценария развития событий.

При таком сценарии мы оставляем оценки неизменными. Команда достигает скорости восемь пунктов в завершенной итерации. Это позволяет нам ожидать, что она будет иметь скорость в среднем на уровне восьми пунктов и в последующих итерациях. Вместе с тем команда знает, что не может реализовать истории 2 и 3 за одну итерацию, хотя они и оцениваются всего в восемь пунктов. Поскольку каждая из этих историй связана с построением графиков и ожидается, что каждая связанная с графиками история должна быть в два раза более трудоемкой по сравнению с текущей оценкой (как и история 1), команда приходит к выводу о невозможности реализации историй 2 и 3 за одну итерацию. Они оцениваются в восемь пунктов, но это слишком много.

Посмотрим, поможет ли переоценка одной лишь истории 1 устранить проблему. После завершения итерации команда понимает, что история 1 оказалась в два раза более трудоемкой, чем ожидалось первоначально. Поэтому она принимает решение повысить оценку этой истории до шести. Это означает, что скорость в предыдущей итерации составила 11 — шесть пунктов для истории 1 и пять пунктов для истории 6.

Поскольку другие истории не переоцениваются, команда планирует реализовать в следующей итерации истории 2, 3 и 4. Эти истории оцениваются в 11 пунктов, т. е. представляют такой же объем работы, который был выполнен в предыдущей итерации. Однако команда сталкивается с той же проблемой, что и в первом сценарии: истории 2 и 3 потребуют, скорее всего, в два раза больше времени, чем ожидалось, и выдержать среднюю скорость на уровне 11 пунктов на итерацию не удастся.

В этом сценарии команда переоценивает каждую историю, связанную с построением графиков. Оценки историй 1, 2 и 3 удваиваются по сравнению с тем, что показано в табл. 7.2. Как и во втором сценарии, скорость первой итерации составляет 11 — шесть пунктов для истории 1 и пять пунктов для истории 6. Поскольку в первой итерации скорость была равна 11, команда ожидает, что будет держаться на этом уровне и в следующей итерации. Вместе с тем при планировании следующей итерации она выбирает только историю 2. Эта история, первоначально оцененная в пять пунктов, получает оценку 10 пунктов и оказывается настолько большой, что не оставляет места для дополнительной истории.

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

Потребность в переоценке может возникнуть, когда команда реализовала только часть истории в процессе итерации. Допустим, команда работает над историей, которая выглядит следующим образом: «Как тренер я могу получать от системы рекомендации, кого ставить в какой заплыв». Эта история первоначально оценивалась в пять пунктов, но оказалась неожиданно сложной.

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

Сначала подчеркну, что при определении скорости я обычно придерживаюсь подхода «всё или ничего»: если история реализована (запрограммирована, протестирована и принята владельцем продукта), то команда получает все пункты, но если в истории что-то осталось недоделанным, она не получает ничего. Если команда предполагает реализовать оставшуюся часть истории в следующей итерации, то такой подход работает хорошо. Ее скорость в первой итерации будет немного ниже ожидаемой, поскольку она ничего не зарабатывает на частично реализованной истории. Во второй итерации, однако, скорость команды будет выше ожидаемой в силу того, что она получит все пункты, хотя часть работы выполнена до начала этой итерации. Это работает хорошо до тех пор, пока все помнят, что нам важно поддерживать стабильную скорость команды на протяжении всего времени, а не учитывать скачки или падения скорости в отдельно взятой итерации.

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