Использование Канбана Для Подготовки Бэклога Scrum

Разработчики согласовывают элемент и оценивают его.

5. Только элементы, согласованные командой разработчиков, могут быть включены в спринт во время планирования.

Для поддержки описанного выше процесса мы используем доску Канбан.

Канбан-доска Наша доска Канбан содержит четыре столбца, которые визуализируют описанную выше поэтапность: 1. Новые задания 2. Аналитика 3. Требования готовы 4. Отставание (или согласованные требования) Когда элемент добавляется в бэклог впервые, он помещается в столбец новых задач.

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

Если да, то он перемещается в столбец аналитики.

Это своего рода статус «В разработке» для владельца продукта и аналитика.

Когда они чувствуют, что анализ завершен, они перемещают элемент в столбец «Требования готовы».

Когда в этом столбце будет 10-20 элементов (жесткого ограничения у нас нет), наступит время совещания по очистке отставания, во время которого разработчики разбирают элементы из последнего столбца.

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

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

Планирование спринта Когда приходит время нового совещания по планированию спринта, рассматриваются только те элементы, которые находятся в статусе «Отставание».

Мы работаем в Jira и фильтруем Scrum-доску, чтобы задачи со статусом, отличным от Backlog, вообще не отображались.

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

Фокус планирования смещается к владельцу продукта, который утверждает список приоритетных элементов и переносит эти элементы в спринт. К этому времени у Product Owner уже есть оценка сроков внедрения, так что, имея информацию о стоимости внедрения и бизнес-ценности этих задач (а Product Owner должен понимать бизнес-ценность), становится возможным сделать обоснованное решение о том, стоит ли задачу решать уже сейчас, отложить на более поздний спринт или, возможно, вообще не стоит ее реализовывать.

Мониторинг процесса обработки отставания Для эффективной команды Scrum-разработчиков как никогда важно обеспечить, чтобы резервная копия была заполнена данными, которые необходимы команде для сохранения эффективности.

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

Можно сказать, что это невозможно для большинства проектов, за исключением самых маленьких.

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

Я также думаю, что наличие четко определенного процесса подготовки элементов к размещению в бэклоге продукта, к сожалению, встречается довольно редко.

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

Я собираюсь продолжить работу со своей доской Канбан, чтобы убедиться, что управление невыполненной работой по продукту не превращается в бессистемный процесс.