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

Большинство встреч по планированию спринта посвящены историям из 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, и команда совместными усилиями определили критерий готовности. Можно ли считать историю готовой, если весь код был добавлен в репозиторий? Или же она считается готовой, лишь после того как была развёрнута на тестовом сервере и прошла все интеграционные тесты? Где только это возможно, мы используем следующее определение критерия готовности: «история готова к развёртыванию на живом сервере», однако, иногда мы вынуждены иметь дело с определением типа «развёрнуто на тестовом сервере и готово к приёмочному тестированию».

Поначалу мы использовали детализированные контрольные листы для определения того, что история готова. А сейчас мы часто просто говорим: «история готова тогда, когда так считает тестировщик из нашей Scrum-команды». В этом случае проверка того, что пожелания product owner’а были правильно восприняты командой, остаётся на совести тестировщика. В его задачи также входит контроль того, что история достаточно «готова» для того, чтобы удовлетворить принятому критерию готовности.

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

Если вы часто путаетесь с определением критерия готовности (как это было поначалу у нас), то вам, наверное, стоит ввести поле «критерий готовности» для каждой истории.

Оценка — это командная работа, и, зачастую, все члены команды участвуют в оценке каждой истории. Почему?

• Во время планирования мы обычно не знаем, кто будет выполнять ту или иную часть.

• Реализация историй обычно требует участия различных специалистов (дизайн пользовательского интерфейса, кодирование, тестирование, и т. д.).

• Для того, чтобы каждый участник команды мог выдать какую-то оценку, он должен более или менее понимать, в чём суть этой истории. Получая оценку от каждого члена команды, мы убеждаемся, что все понимают, о чём идёт речь. Это увеличивает вероятность взаимопомощи по ходу спринта. А также это увеличивает вероятность того, что наиболее важные вопросы по этой истории всплывут как можно раньше.

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

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

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