И еще раз всем привет!
Последнее время, в ходе работы в продуктовых командах обратил внимание, что многие недооценивают важность и плюсы грумминга бэклога.
Грумминг или в новом Scrum Guide- Product Backlog Refinement (PBR), это один из ритуалов в работе с бэклогом продукта и подготовке к планированию спринта. Многие команды воспринимают грумминг, как встречу лидов, где они планируют спринта, а на планировании просто уже распределяют задачи на команду.
Но на самом деле грумминг - это фиксация того самого этапа Дизайна, отсутствие которого так беспокоит многих сторонних водопадной модели. Результатом Грумминга являются истории, который четко соответствуют критериям готовности к разработке (Definition of Ready) и перечень вопросов по тем историям, которые еще не готовы пойти в работу.
Подготовка у Груммингу - это по сути основная часть аналитической работы, с которой сталкиваюсь я, как член команды разработки. И от качества моей работы напрямую зависит, сколько времени займет грумминг даже одной истории. Например, могу сказать, что когда я не нашел двух часов на проработку задачи перед груммингом, грумминг вылился в эти же два дополнительных часа, но только уже для 9 человек, итого вместо двух - восемнадцать рабочих часов. Этот момент стал для меня уроком, теперь максимум проработки делаем до грумминга, иногда привлекая других членов команды или архитектора для детальной проработки.
Итак, как мы готовим историю к груммингу:
1. Продакт приносит фичу, как правило эпик, поэтому первая часть - это обсудить все с продактом, сформировать список открытых вопросов по бизнес-смыслам, понять, что нужно бизнесу. Дальше мы делим этот список по тем стейкхолдерам, которые могут нам помочь, и решаем кто из нас к какому стейкхолдеру пойдет. Определяем, как правило, по уровню отношений со стейкхолдерами и по направлению бизнеса. Например, сейчас у меня сложились хорошие отношения с нашими департаментом финансов и все истории, касающиеся финансов или бухгалтерии, прорабатываю я (да-да, занудство с проводками - наш конёк).
2. Общаемся с архитектором, чтобы понять, может ли история затронуть бизнес-критичные сервисы или сервисы других команд. Понимаем, нужно ли нам создавать новые сервисы и куда мы это будем размещать физически - на отдельную машину, в отдельный контейнер, думаем про нагрузку, балансировку и т.п. Обычно на выходе есть набор НФТ и компонентов + понимание, какие технические таски могут понадобиться.
3. Опционально. Если история затрагивает несколько команд и добавляет значимые изменения, то мы собираем архитектурный комитет со всеми заинтересованными командами, техническим и корпоративным архитекторами. На комитете обсуждаем, какая команда когда и что сможет реализовать и как это будет аффектить на остальных. На выходе это обычно роад мап по реализации всей истории в продуктиве.
4. Дальше начинаемся много "бумажной работы". Надо описать все стори, на которые побили фичу, подготовить по ним критерии приемки, описать бизнес-правила, которые влияют на истории, описать основные кейсы, которые будем покрывать, на основании кейсов тестировщики потом подготовят свои тестовые кейсы для проверки фичи и для включения в регресс. Это основное время, которое тратится на подготовку к груммингу.
5. Еще раз по всему пройтись с продактом, проверить, что все сходится и ничего не упустили.
6. И вот теперь можно рассказать всей команде, что же нам нужно будет сделать. Тут, как правило, возникает еще целая пачка вопросов, которые мы с продактом и архитектором пропустили. И это нормально, ради этого грумминг и проводится. Наша задача - подготовить для команды бизнес-смыслы и наброски решения. Если мы хорошо подготовились к груммингу, то на все вопросы мы можем сразу найти ответы и у нас с командой зафиксируется правильно понимание того, что нужно сделать, сформируется список тасок для реализации истории и оценка по реализации, влезем мы вообще в один спринт или нет.
