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

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

Что если команда новая и не имеет никакой статистики? В этом случае можно использоать фокус-фактор других команд, которые работают в похожих условиях.

Нет возможности взять данные других команд? Выберите фокус-фактор наугад. Хорошая новость состоит в том, что фокус-фактор придётся угадывать лишь для первого спринта. После первого спринта вы будете располагать статистическими данными и сможете непрерывно измерять и совершенствовать ваш фокус-фактор и прогнозируемую производительность.

В качестве «значения по умолчанию» фокус-фактора для новых команд мы обычно используем 70 %, т. к. это именно тот предел, которого нашим командам удавалось достичь за всё время их работы.

Я упоминал несколько подходов подсчёта производительности: на основе интуиции, на основе «вчерашней погоды» и на основе определения доступных ресурсов с учётом фокус-фактора.

Какой же подход используем мы?

Обычно мы совмещаем все перечисленные подходы. На это не требуется много времени.

Мы анализируем фокус-фактор и реальную производительность последнего спринта. И, проанализоровав доступные ресурсы, получаем фокус-фактор будущего спринта. Обсуждаем любые различия этих двух фокус-факторов и вносим необходимые коррективы.

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

Вобщем, цель — принять решение о том, какие истории включать в спринт. А фокус-фактор, доступные ресурсы и прогнозируемая производительность являются лишь инструментами её достижения.

Большинство встреч по планированию спринта посвящены историям из product backlog’а: их оценке, расстановке приоритетов, уточнению требований, разбиению на части и т. д.

Как это происходит у нас?

Обычно команда включает проектор, который показывает backlog в БхсеГе. Кто-то (обычно product owner или ScrumMaster) садится за клавиатуру, быстро зачитывает историю и начинает обсуждение. По мере того, как команда и product owner обсуждают приоритеты и детали, парень за клавиатурой обновляет историю прямо в Excel’е.

Неплохо, да? А вот и нет! На самом деле это фигня. И что ещё хуже, команда обычно не замечает, что это фигня, аж до конца встречи, когда оказывается, что ещё куча историй не обработана!

Есть способ получше — сделать учетные карточки и прикрепить их на стену (или на большой стол).

Такой «пользовательский интерфейс» выигрывает по сравнению с компьютером и проектором, по следующим причинам:

• Люди вынуждены вставать и ходить, поэтому они более сконцентрированы и не засыпают.

• Каждый чувствует себя причастным к процессу (а не только парень за клавиатурой).

• Можно редактировать несколько историй одновременно.

• Изменить приоритеты очень просто — достаточно поменять местами учетные карточки.

• После окончания встречи учетные карточки можно забрать в комнату, где работает команда, и использовать их на доске задач (см. стр. 38 «Как мы создаём sprint backlog?»).

Вы можете заполнить учетные карточки собственноручно или (как мы обычно делаем) сгенерировать версию для печати прямо из product backlog’а, используя простой скрипт.

PS — скрипт можно найти в моём блоге на http://blog.crisp.se/henrikkniberg.

Важно:После планирования спринта наш scrummaster вручную обновляет product backlog в Ехсеl’е, чтобы учесть все изменения, которые были сделаны на карточках. Да, это определённая морока, но мы на это согласны с учетом того, насколько эффективнее проходят встречи по планированию спринта с использованием бумажных учетных карточек.

Несколько слов о поле «Важность» (Importance). Это значение «важности» из product backlog'a в Ехсеl’е на момент распечатки карточки. Её обозначение на карточке помогает нам отсортировать карточки на стене. Обычно мы располагаем более важные элементы левее, а менее важные — правее. Однако, когда карточки уже на стене, можно забыть о значении поля «важность» и, вместо этого, использовать порядок, чтобы показать относительную важность истории. Если product owner меняет местами карточки, не тратьте время на обновление значений на бумажках. Просто после встречи убедись, что обновили значения степени важности историй в product backlog'e.