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

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

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

Выбрать разумный фокус-фактор лучше всего, взяв его из последнего спринта (а ещё лучше — среднее значение за несколько последних спринтов).

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

Допустим, в ходе последнего спринта командой из трёх человек в составе Тома, Лизы и Сэма реализовано 18 story point'ов. Продолжительность спринта была 3 недели, что составляет 45 человеко-дней. Необходимо спрогнозировать производительность команды на будущий спринт. Слегка усложним задачу появлением Дэйва — нового участника команды. Принимая во внимание отгулы членов команды и другие вышеупомянутые обстоятельства, получим 50 человеко-дней.

Таким образом, наша прогнозируемая производительность будущего спринта — это 20 story point'ов. Это означает, что команде следует включать истории в план спринта до тех пор, пока их сумма не будет примерно равна 20.

В нашем случае команда может выбрать 4 наиболее важные истории (что составляет 19 story point'ов) или 5 наиболее важных историй (24 story point’а). Остановимся на четырёх историях, т. к. их сумма близка к 20. Если возникают сомнения, выбирайте меньше историй.

Ввиду того, что выбранные 4 истории составляют 19 story point’а, окончательная прогнозируемая производительность будущего спринта составляет 19.

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

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

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

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

В качестве «значения по умолчанию» фокус-фактора для новых команд мы обычно используем 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.

Историю обычно можно оценить легче и точнее, если она разбита на задачи. На самом деле мы использует термин «действие» (activity), потому что слово «задача» (task) значит на шведском кое-что совершенно другое: о) [прим. переводчика — шведско-русский онлайн словарь находится по адресу http://lexin.nada.kth.se/swe-eng.html1

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

На нашей доске мы отображаем задачи в виде маленьких стикеров под каждой историей. Каждый стикер соответствует одной задаче в рамках этой истории.

Мы не добавляем задачи в product backlog в Ехсеl’е по двум причинам:

1. Список задач обычно часто меняется: к примеру, задачи могут изменяться и пересматриваться на протяжении sprint'a. Чтобы синхронизировать с ними product backlog в Ехсеl’е нужно слишком много усилий.

2. Скорее всего, на этом уровне детализации product owner не будет участвовать в процессе.

Так же, как и учетные карточки, стикеры с задачами можно использовать в sprint backlog'e (см. стр. 38 «Как мы создаём sprint backlog?»).

Критерий готовности

Важно, чтобы и product owner, и команда совместными усилиями определили критерий готовности. Можно ли считать историю готовой, если весь код был добавлен в репозиторий? Или же она считается готовой, лишь после того как была развёрнута на тестовом сервере и прошла все интеграционные тесты? Где только это возможно, мы используем следующее определение критерия готовности: «история готова к развёртыванию на живом сервере», однако, иногда мы вынуждены иметь дело с определением типа «развёрнуто на тестовом сервере и готово к приёмочному тестированию».