Background Image
Table of Contents Table of Contents
Previous Page  57 / 94 Next Page
Information
Show Menu
Previous Page 57 / 94 Next Page
Page Background

Scrum и XP: заметки с передовой

57

Красные

=

обязательно

должны быть добавлены в версию 1.0 (банан – груша)

Жёлтые

=

желательно

включить в версию 1.0 (изюм – лук)

Зелёные

= могут быть добавлены позже (грейпфрут – персик)

Итак, если к крайнему сроку мы закончим всё: от банана до лука, то нам бояться нечего. Если время будет

нас поджимать, то мы ещё

успеем выкрутиться

, убрав изюм, арахис, пончик и лук. Всё, что ниже лука –

бонус.

Оцениваем наиболее важные истории

Чтобы спл нир вать релиз, product owner'у нужны оценки, как минимум оценки всех включенных в

контракт историй. Как и в случае планирования спринта, это – коллективный труд команды и product owner'а.

Команда планирует, а product owner объясняет и отвечает на вопросы.

Оценка считается

ценной

, если впоследствии она оказалась близкой к реальности. Менее полезной, если

отклонение составило, скажем, 30%. И абсолютно бесполезной, если она не имеет ничего общего с реально

потраченным временем.

А вот что я думаю о зависимости ценности оценки от того, кто и как долго её делает.

Время

,

потраченное на оценку

Ценность

оценки

Командная оценка

Оценка

product owner’

а

Резюмируя вышесказанное:

Пусть

команда

проведёт оценку.

Не давайте им тратить на это много времени.

Убедитесь, что команда понимает, что нужно получить приблизительные оценки, а не контракт,

под которым надо ставить подпись.

Обычно product owner собирает всю команду, делает вводный обзор и сообщает, что целью этого

совещания является оценка двадцати (например) наиболее значимых историй из product backlog'а. Он

проходится по каждой истории и позволяет команде приступить к процессу оценки. Product owner остаётся с

командой, чтобы, в случае необходимости, отвечать на вопросы и прояснить объём работ историй. Так же,

как и при планировании спринта, колонка "как продемонстрировать" – отличное средство, чтобы избежать

недопонимания.

Совещание должно быть строго ограниченным по времени – команды склонны тратить очень много

времени на оценку всего нескольких историй.

Если product owner захочет потратить больше времени на оценку, он просто назначит другое совещание

позже. Команда должна убедиться в том, что product owner осознаёт, что проведение подобных совещаний

отразится на их текущем спринте. То есть, что он понимает, что за все (и за оценку в том числе) нужно платить.

Ниже приведен пример результатов оценки (в story point'ах):