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

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

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

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

Не слишком увлекайтесь процессом переоценки. Когда выясняется, что одна или несколько историй оценены неправильно относительно других историй, старайтесь переоценивать как можно меньше объектов, ограничиваясь лишь приведением относительных оценок в соответствие. Используйте переоценку для учебы и накопления полезного опыта, который пригодится вам при оценке будущих пользовательских историй. Как говорил мне Том Поппендик [5] Автор книги по бережливой разработке программного обеспечения. — Прим. пер . , «неспособность учиться — единственная настоящая ошибка». Учитесь на каждой переоценке истории и приближайтесь к успеху.

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

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

1. Как скорость корректирует неправильные оценки?

2. Почему переоценку следует проводить только тогда, когда изменяется относительный размер? Приведите несколько примеров из текущего или прошлого проекта, в котором изменялся относительный размер одной или нескольких функций.