Как мы оцениваем задачи или как играть в Planning Poker

Как играть в Planning Poker

Уже несколько лет наша команда разработки использует Скрам (Scrum). Внедрения Cкрама было очень интересным и непростым.
Не зря Cкрам определяется как простой в понимании, но сложный в овладении.
Возможно некоторые азы мы не используем, и не всегда идем по правилам. Но мы стараемся гибко приспосабливаться к проектам и достигать поставленных целей.
А без Скрама, думаю, их достижение было бы сложнее.

В данной статье я не буду вам описывать, что собой представляет Cкрам и с чего он состоит. Данной литературы на просторах интернет очень много. Да и сам Скрам Гайд есть в свободном доступе.

Сегодня я хочу поделиться с вами опытом планирования спринта разработки. А именно как мы проводим оценку задач.

В Cкраме есть три основных мероприятия:

  • Sprint Planning - планирование спринта.
  • Daily Scrum - ежедневный скрам.
  • Sprint Review - обзор спринта.

Каждое из этих мероприятий обязательное при использовании Cкрама в процессе разработки программного обеспечения.

Их использование позволяет максимально сократить потребности в совещаниях и соответственно позволяет максимально эффективно использовать свои силы на достижение цели спринта.

И так, бэклог продукта (Product Backlog) готов. Настал день “Икс” для планирования спринта и составления Sprint Backlog.

Для оценки задач мы играем в игру под названием “Planning Poker”.

Задачи (User Story) мы оцениваем в стори-поинтах (Story Point). То есть задачи мы оцениваем не в часах и не в днях.

"Что же это за стори-поинты?", - спросите вы.

Начиная с первых спринтов с использованием Скрама, мы оценивали сложность задачи сравнивая её с другими задачами (пользовательскими историями).

Например, у нас есть три задачи:

  • нарисовать квадрат
  • нарисовать дом
  • нарисовать дом с дверью и окном

Берем первый элемент бэклога “Нарисовать квадрат” и сравниваем с другим элементом, например, “Нарисовать дом”.

Задача “Нарисовать квадрат” проще, поэтому откладываем её влево, а задачу “Нарисовать дом” - вправо.

Изначально договариваемся, что задачи слева более простые, а справа - посложнее.

Далее “Нарисовать дом” сравниваем с задачей “Нарисовать дом с дверью и окном”.

“Нарисовать дом с дверью и окном” более сложная. Поэтому откладываем её правее задачи “Нарисовать дом”.

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

Получается что-то вроде следующего рисунка:

Домики

Далее мы группировали схожие по сложности задачи и присваивали для них сложность в стори-поинтах.

Со временем наша команда без сравнения задач между собой смогла определять сложность задачи. Поскольку мы уже знали приблизительную скорость команды и её производительность (Velocity).

Но это приходит с опытом.

Вернемся к нашему Planning Poker.

Правила игры следующие:

  • Каждому разработчику (участнику, который берет участие в разработке задач спринта) дается набор карт с цифрами.
  • Владелец продукта (Product Owner) читает задачу (пользовательскую историю).
  • При необходимости команда разработки уточняет детали задачи.
  • Каждый участник выбирает свою карту с оценкой и (не показывая её другим) кладет рубашкой вверх на стол.
  • Далее все одновременно открываю свои выложенные карты.
  • Сравниваются результаты.
  • Если разница не большая, то оценка усредняется.
  • Если разница в оценка большая, то обсуждаются причины такой разницы в оценках.
  • Делаем еще один раунд оценки, пока большинство не сойдется на одном числе.

Несколько лет мы не заморачивались. Брали обычные стикеры бумаги. Писали там свои числа, в которых мы будем оценивать задачи и при оценке задачи просто показывали необходимый стикер с цифрой.

Стикер

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

Было принято решение приобрести специальные карты для Planning Poker.

Проведя несколько часов в поисках подходящего варианта, возникла идея. А почему бы не нарисовать свои карты?

Когда-то на День Админа мы подарили нашему ИТ-директору бубен. Как говориться, если что-то не получается - постучи в бубен.

Эту великую силу бубна мы решили использовать как тематику наших "шаманских" карт.

Рубашка

Теперь что касается значения самих карт. То есть, значений карт для оценки задач.

Можно использовать числа подряд. Например, 1,2,3,4,5,6. Но на практике сложно сказать какая разница в сложности между, например, 4 и 5.

Поэтому мы пользуемся последовательностью Фибоначчи, где каждое последующее число равно сумме двух предыдущих чисел. То есть, 0, 1, 2, 3, 5, 8, 13, 21…

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

Но всю последовательность Фибоначчи мы не используем.

Максимальная цифра у нас 8.

8

С практики скажу, что если оценка больше 8, то уже сложно сказать точную оценку задачи. И в большинстве случаев что 8, а что 13 - разницы нет. Задача получается сложной и понять её длительность очень трудно.

Мы даже стараемся очень редко использовать оценку 8.

Если участники планинга показывают оценку 8 (что означает, что задача сложная), мы стараемся максимально понять все аспекты и нюансы задачи и разбить её на более мелкие.

В таком случае более четко можно отследить прогресс задачи с учетом ее подзадач.

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

Бывают временами случаи, что оценить задачу сложно или оценка точно больше 8.

Тогда мы используем карточку со знаком вопроса - “?”.

Вопрос

Если один из участников игры показал карту “?” тогда:

  • Участник, что показал "?" аргументирует причину использования данной карты.
  • Product Owner более детально объясняет суть задачи.
  • Разработчики пытаются понять и объяснить друг другу особенности разработки задачи.
  • Задача при необходимости разбивается на более мелкие.
  • Оцениваем повторно задачу.

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

Смелость - одна с главных ценностей Скрама.

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

Также при оценке задач, если появляется карточка “8” или “?”, при необходимости смотрим в код. То есть, если по задаче проекта уже есть наработки или это оптимизация проекта, то лучший способ понять некоторые нюансы задачи - это открыть её код.

После исследования кода, оценка может резко измениться как в меньшую, так и в большую сторону :)

Кроме целых цифр мы еще используем оценку ½. То есть, половину стори-поинта. Зачастую такая оценка присваивается для очень мелких задач, которые быстро решаются.

Как и в любой работе, нужно делать перерывы и дать голове отдохнуть.

Для таких ситуаций есть карточка с изображением “Кофе”.

Кофе

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

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

Очень часто перед планированием спринта Владелец продукта делает предварительные встречи с командой, чтобы уточнить детали будущих проектов, получить обратную связь для исследования и т.д. Такие встречи мы называем Грумминг (Backlog Grooming).

Но это уже совсем другая история :)

П.С. - Если вам понравились наши карты для Planning Poker, обращайтесь к нам. Кроме того, наш отдел дизайна может сделать специальный дизайн под вашу “хотелку”. Пишите :)

Карты Planning Poker

Автор: Андрей Харечко
e-mail: andriy.st.kh@gmail.com
skype: andriy.st.kh

 

Автор: Андрей Харечко - Янв 25, 2017 -