Scrum и XP: заметки с передовой - Хенрик Книберг

Цель спринта должна отвечать на главный вопрос «Зачем мы работаем над этим спринтом? Почему мы все просто не уйдём в отпуск?». На самом деле, самый простой способ вытянуть цель спринта из product owner'a — напрямую задать ему этот вопрос.

Целью должно быть что-то, что не было ещё достигнуто. «Удивить исполнительного директора» может быть неплохой целью. Но только не в том случае, когда он и так в восторге от текущего состояния системы. В этом случае, все могут просто собраться и пойти домой, а цель спринта всё равно будет достигнута.

Цель спринта может показаться слегка глупой и надуманной на протяжении всего планирования. Но чаще всего, основная её ценность начинает проявляться к середине спринта, когда люди начинают забывать чего они хотят достичь в этом спринте. Если у вас работают несколько Scrum-команд (как у нас) над разными продуктами, очень полезно иметь возможность просмотреть список целей спринтов для всех команд на одной wiki-странице (или ещё где-нибудь), а также вывесить их на видном месте, чтобы все (а не только топ-менеджеры) знали, чем занимается компания и зачем!

Выбор историй, которые войдут в спринт

Основное в планировании спринта — процедура выбора историй, которые войдут в спринт. А точнее, выбор историй, которые нужно скопировать из product backlog'a в sprint backlog.

Взгляните на картинку. Каждый прямоугольник представляет собой историю, расположение которой соответствует уровню её важности. Наиболее важная история находится наверху списка. Размер истории (т. е. количество story point’а) определяет размер каждого прямоугольника. Высота голубой скобки обозначает прогнозируемую производительность команды, т. е. количество историй, которое команда собирается завершить в следующем спринте.

Честно говоря, sprint backlog — это выборка историй из product backlog'a. Он представляет собой список историй, которые команда обязалась выполнить в течение спринта.

Именно команда решает, сколько историй войдёт в спринт. Ни product owner, ни кто-нибудь ещё.

В связи с этим, возникают два вопроса:

1. Каким образом команда решает, какие истории попадут в спринт?

2. Как product owner может повлиять на их решение?

Начну со второго вопроса.

Как product owner может влиять на то, какие истории попадут в спринт?

Допустим, на планировании спринта возникла следующая ситуация:

Product owner’а разочаровал тот факт, что история «Г» не попадает в спринт. Что он может сделать в ходе совещания?

Второй вариант — изменение объёма работ: product owner начинает уменьшать объём истории «А» до тех пор, пока команда не решит, что историю «Г» можно втиснуть в спринт.

Первый вариант — изменение приоритетов. Если product owner назначит истории «Г» более высокий приоритет, то команда будет обязана включить её в спринт первой (исключив при этом историю «В»).

Третий вариант — разбиение истории. Product owner может решить, что некоторые части истории «А» не так уж и важны. Таким образом, он разбивает историю «А» на две истории «А1» и «А2», а затем назначает им разный приоритет.

И так, несмотря на то, что в большинстве случаев product owner не может контролировать прогнозируемую производительность, у него существует множество способов повлиять на то, какие истории попадут в спринт.

Как команда принимает решение о том, какие истории включать в спринт?

Мы используем два подхода:

1. на основе интуиции

2. на основе подсчёта производительности

Планирование, основанное на интуиции

ScrumMaster: «Ребята, мы закончим историю „А“ в этом спринте?» (Показывает на самую важную историю в product backlog’а)

Лиза: «Конечно, закончим. У нас есть три недели, а это довольно тривиальная функциональность». ScrumMaster: «Хорошо. А как на счёт истории „Б“?» (Показывает на вторую по важности историю) Том и Лиза одновременно: «Легко!»

ScrumMaster: «Хорошо. Как на счёт историй „А“, „Б“ и „В“?»

Сэм (обращаясь к product owner): «Нужно ли реализовывать расширенную обработку ошибок для истории „В“?»

Product owner: «Нет. Пока хватит базовой». Сэм: «В таком случае историю „В“ мы тоже закончим». ScrumMaster: «Хорошо, как на счёт истории „Г“?» Лиза: «Хмм…»

Том: «Думаю, что сделаем». ScrumMaster: «Вероятность 90 % или 50 %?» Лиза и Том: «скорее 90 %.»

ScrumMaster: «Хорошо, значит, включаем историю „Г“ в этот спринт. Что скажете на счет истории „Д“?» Сэм: «Возможно».

ScrumMaster: «90 %? 50 %?» Сэм: «Ближе к 50 %». Лиза: «Сомневаюсь».

ScrumMaster: «В таком случае, не включаем историю „Д“. Обязуемся реализовать истории „А“, „Б“, „В“ и „Г“. Конечно, если успеем, то реализуем и историю „Д“, однако не стоит на это расчитывать. Поэтому историю „Д“ исключаем из плана спринта. Согласны?» Все: «Согласны».

Интуитивное планирование хорошо работает для маленьких команд и коротких спринтов.

Планирование, основанное на методе оценки производительности

Этот подход включает в себя два этапа:

1. Определить прогнозируемую производительность

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

Производительность является мерой «количества выполненной работы». Она рассчитывается как сумма первоначальных оценок всех историй, которые были реализованы в течение спринта.

На следующем рисунке показан пример прогнозируемой производительности в начале спринта и реальной производительности в конце спринта. Каждый прямоугольник обозначает историю, число внутри прямоугольника — это его начальная оценка.

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

Я уже слышу ваши возражения: «Какая от этого польза? Высокий или низкий уровень производительности зависит от миллиона факторов! Недалёкие программисты, неправильная начальная оценка, изменение объёма работ, незапланированные потрясения в ходе спринта и т. д.»

Согласен, производительность — это приблизительная величина. Но, тем не менее, очень полезная. Она лучше, чем ничего. Производительность даёт нам следущее: «Независимо от причин, мы имеем разницу между запланированным и выполненным объемом работ».

А что, если история была почти закончена? Почему мы не используем дробные значения для таких историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу «Managing the Design Factory» автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.

Так каким же магическим способом мы оцениваем производительность?

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

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

Более продвинутый вариант оценки производительности заключается в определении доступных ресурсов. Допустим, мы планируем трёхнедельный спринт (15 рабочих дней). Команда состоит из 4-ёх человек. Лиза берёт два отгула. Дэйв сможет уделить проекту только 50 % времени плюс берёт один отгул. Сложим всё вместе …

Получили ли мы прогнозируемую производительность? Нет! Потому что наша единица измерения — это story point, который, в нашем случае приблизительно равен «идеальному человеко-дню». Идеальный человеко-день — это максимально продуктивный день, когда никто и ничто не отвлекает от основного занятия. Такие дни — редкость. Кроме того, нужно принимать во внимание, что в ходе спринта может быть добавлена незапланированная работа, человек может заболеть и т. д.

Без всякого сомнения, наша прогнозируемая производительность будет менее пятидесяти. Вопрос в том, насколько? Для ответа на него введём определения фокус-фактора.

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