Поначалу мы использовали детализированные контрольные листы для определения того, что история готова. А сейчас мы часто просто говорим: «история готова тогда, когда так считает тестировщик из нашей Scrum-команды». В этом случае проверка того, что пожелания product owner’а были правильно восприняты командой, остаётся на совести тестировщика. В его задачи также входит контроль того, что история достаточно «готова» для того, чтобы удовлетворить принятому критерию готовности.
В конце концов, мы осознали, что нельзя все истории ровнять под одну гребёнку. История «форма поиска пользователей» будет очень сильно отличаться от истории под названием «руководство по эксплуатации». В последнем случае «готово» может просто означать «принято отделом поддержки клиентов». Поэтому здравый смысл часто лучше, чем формальный контрольный лист.
Если вы часто путаетесь с определением критерия готовности (как это было поначалу у нас), то вам, наверное, стоит ввести поле «критерий готовности» для каждой истории.
Оценка трудозатрат с помощью игры в planning poker
Оценка — это командная работа, и, зачастую, все члены команды участвуют в оценке каждой истории. Почему?
• Во время планирования мы обычно не знаем, кто будет выполнять ту или иную часть.
• Реализация историй обычно требует участия различных специалистов (дизайн пользовательского интерфейса, кодирование, тестирование, и т. д.).
• Для того, чтобы каждый участник команды мог выдать какую-то оценку, он должен более или менее понимать, в чём суть этой истории. Получая оценку от каждого члена команды, мы убеждаемся, что все понимают, о чём идёт речь. Это увеличивает вероятность взаимопомощи по ходу спринта. А также это увеличивает вероятность того, что наиболее важные вопросы по этой истории всплывут как можно раньше.
• При оценке истории совместными усилиями разностороннее видение проблемы приводит к сильному разбросу оценок. Такие разногласия лучше выявлять и обсуждать как можно раньше.
Если попросить всех оценить историю, то обычно человек, который понимает её лучше остальных, выдаст оценку первым. К несчастью это сильно влияет на оценки других людей.
Но существует прекрасная практика, которая позволяет этого избежать. Она называется planning poker (придуманная Майком Коном, насколько я знаю).
Каждый член команды получает колоду из 13-ти карт, таких же, как на картинке выше. Всякий раз, когда нужно оценить историю, каждый член команды выбирает карту с оценкой (в story point'ах), которая, по его мнению, подходит, и кладёт её на стол рубашкой наверх. Когда всё члены команды определились с оценкой, карты одновременно вскрываются. Таким образом, члены команды вынуждены оценивать самостоятельно, а не «списывать» чужую оценку.
Если получается большая разница в оценках, то эту разницу обсуждают и пытаются выработать общее понимание того, что должно быть сделано для реализации этой истории. Возможно, они разобьют задачу на более мелкие. После этого команда оценит историю заново. Этот цикл должен повторяться до тех пор, пока оценки не сойдутся, т. е. не станут примерно одинаковыми.
Очень важно напоминать всем членам команды, что они должны оценивать общий объём работ по истории, а не только «свою часть». Тестировщик должен оценивать не только работы по тестированию.
Заметьте, последовательность значений на картах — нелинейная. Вот, например, между 40 и 100 ничего нет. Почему так?
Это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 20 story point’а, то нет смысла обсуждать должна ли она быть 20, или 18, или 21. Всё, что нам нужно знать, это то, что её сложно оценить. Поэтому мы примерно назначаем ей оценку в 20.
Если у вас возникло желание более детально переоценить эту историю, то лучше разбейте её на более мелкие части и оцените уже их!
И, кстати, жульничать, выкладывая карты 5 и 2, чтоб получить 7, нельзя. Вы должны выбрать или 5 или 8 — семёрки нет.
Есть ещё несколько специальных карт:
• 0 = или «история уже готова» или же её оценка «пара минут работы».
•? = «Я понятия не имею. Абсолютно».
• Чашка кофе = «Я слишком устал, чтобы думать. Давайте сделаем перерыв».
Уточнение описаний историй
Нет ничего ужасней, чем ситуация, когда команда с пафосом демонстрирует новую функциональность продукта, а product owner тяжко вздыхает и говорит: «ну да — всё это красиво, вот только не то, что я просил!»
Как убедиться, что product owner и команда понимают историю одинаково? Или что все члены команды понимают все истории одинаково? Да никак. Есть простые способы выявить разницу в понимании. Наиболее простая практика — всегда заполнять все поля для каждой истории (точнее, для всех историй, которые могут попасть в текущий спринт).
Пример № 1:
Команда и product owner вполне довольны планом на спринт и уже готовы закончить планирование, но тут ScrumMaster говорит: «Минуточку! У нас нет оценки для истории „добавить пользователя“. Давайте-ка оценим!». После пары сдач в planning poker, команда сходится на оценке в 20 story point’а, на что product owner вскакивает с криком: «ЧЕГООО?!?». Пара минут ожесточённых споров и вдруг выясняется, что команда имела в виду «удобный web-интерфейс для функций добавить, редактировать, удалить и искать пользователей», а product owner имел в виду только «добавлять пользователей напрямую в базу данных с помощью SQL-клиента». Команда оценивает историю заново и останавливается на 5-ти story point'ах.
Пример № 2:
Команда и product owner вполне довольны планом на спринт и уже готовы закончить планирование, но тут Scrum master говорит: «Минуточку! Вот тут у нас есть история „добавить пользователя“… Как она может быть продемонстрирована?». Народ пошепчется и через минуту кто-то встанет и начнёт: «ну, для начала надо залогиниться на сайт, потом…», a product owner тут же перебьёт: «залогиниться на сайт?! Не-не-не-не… эта функция вообще к сайту не должна иметь никакого отношения — это будет просто маленький SQL-скрипт, только для администраторов».
Поле «как продемонстрировать» может (и должно) быть очень кратким! Иначе вы не успеете вовремя закончить планирование спринта. По сути, это лаконичное описание на обычном русском языке, как вручную выполнить наиболее общий тестовый пример: «Сделать это, потом это, потом проверить, что получилось так-то».
И я понял, что такое простое описание часто позволяют обнаружить разное понимание объёма работ для историй. Хорошо ведь узнать об этом заранее, не так ли?
Разбиение историй на более мелкие истории
Истории должны быть не слишком маленькими, но и не слишком большими (в смысле оценок). Если вы получили кучу историй в половину story point'a, то вы наверняка падёте жертвой микроменеджмента. С другой стороны, история в 40 story point'oB несёт в себе риск того, что к концу спринта её успеют закончить лишь частично, а незавершённая история не представляет ценности для вашей компании, она только увеличивает накладные расходы. Дальше — больше: если ваша прогнозируемая производительность 70 story point'oB, а две наиболее важные истории оценены в 40, то планирование несколько усложнится. Команда станет перед выбором: или расслабиться (т. е. включить в спринт только одну историю), или взять на себя невыполнимые обязательства (т. е. включить обе).
Я считаю, что практически всегда есть возможность разбить историю на более мелкие. Однако, в этом случае нужно следить за тем, чтобы меньшие истории всё ещё представляли ценность с точки зрения бизнеса.
Обычно мы стремимся получить истории объёмом от двух до восьми человеко-дней. Производительность нашей среднестатистической команды обычно находится в пределах 40-ка — 60-ти человеко-дней, что позволяет нам включать в спринт примерно по 10 историй. Иногда всего 5, а иногда целых 15. Кстати, таким числом учётных карточек достаточно удобно оперировать.
Разбиение историй на задачи
Секундочку… В чём разница между «задачами» и «историями»? Очень правильный вопрос.
А различие очень простое: истории это нечто, что можно продемонстрировать, что представляет ценность для product owner'a, а задачи либо нельзя продемонстрировать, либо они не представляют ценности для product owner'a.
Пример разбиения истории на более мелкие:
Пример разбиения истории на задачи:
Несколько интересных наблюдений:
• Молодые Scrum-команды не любят тратить время на предварительное разбиение историй на задачи. Некоторые считают это «водопадным» подходом.
• Абсолютно понятные истории разбивать на задачи заранее так же легко, как и по мере их выполнения.
