28 / 94
Scrum и XP: заметки с передовой
28
Критерий готовности
Важно, чтобы и product owner, и команда совместными усилиями определили критерий готовности.
Можно ли считать историю готовой, если весь код был добавлен в репозиторий? Или же она считается
готовой, лишь после того как была развёрнута на тестовом сервере и прошла все интеграционные тесты? Где
только это возможно, мы используем следующее определение критерия готовности: “история готова к
развёртыванию на живом сервере”, однако, иногда мы вынуждены иметь дело с определением типа
“развёрнуто на тестовом сервере и готово к приёмочному тестированию”.
Поначалу мы использовали детализированные контрольные листы для определения того, что история
готова. А сейчас мы часто просто говорим: “история готова тогда, когда так считает тестировщик из нашей
Scrum-команды”. В этом случае проверка того, что пожелания product owner’а были правильно восприняты
командой, остаётся на совести тестировщика. В его задачи также входит контроль того, что история
достаточно “готова” для того, чтобы удовлетворить принятому критерию готовности.
В конце концов, мы осознали, что нельзя все истории ровнять под одну гребёнку. История “форма поиска
пользователей” будет очень сильно отличаться от истории под названием “руководство по эксплуатации”. В
последнем случае “готово” может просто означать “принято отделом поддержки клиентов”. Поэтому здравый
смысл часто лучше, чем формальный контрольный лист.
Если вы часто путаетесь с определением критерия готовности (как это было поначалу у нас), то вам,
наверное, стоит ввести поле “критерий готовности” для каждой истории.
Оценка трудозатрат с помощью игры в planning poker
Оценка – это командная работа, и, зачастую, все члены команды участвуют в оценке каждой истории.
Почему?
•
Во время планирования мы обычно не знаем, кто будет выполнять ту или иную часть.
•
Реализация историй обычно требует участия различных специалистов (дизайн пользовательского
интерфейса, кодирование, тестирование, и т.д.).
•
Для того, чтобы каждый участник команды мог выдать какую-то оценку, он должен более или
менее понимать, в чём суть этой истории. Получая оценку от каждого члена команды, мы
убеждаемся, что все понимают, о чём идёт речь. Это увеличивает вероятность взаимопомощи по
ходу спринта. А также это увеличивает вероятность того, что наиболее важные вопросы по этой
истории всплывут как можно раньше.
•
При оценке истории совместными усилиями разностороннее видение проблемы приводит к
сильному разбросу оценок. Такие разногласия лучше выявлять и обсуждать как можно раньше.
Если попросить всех оценить историю, то обычно человек, который понимает её лучше остальных, выдаст
оценку первым. К несчастью это сильно влияет на оценки других людей.
Но существует прекрасная практика, которая позволяет этого избежать. Она называется planning poker
(придуманная Майком Коном, насколько я знаю).