​Discovery vs Delivery, ч.1

Что если разработчик будет не только кодить? Как встроить проработку задач в рабочий процесс разработчика?
В серии из 3 постов расскажу о процессе и профитах для продукта и самого разраба.

Процесс проработки бэклога не очень подробно описан в Scrum, но по идее он подразумевает вовлечение всей команды.
В отличие от проектной работы, в продуктовой разработке задачи попадают в бэклог совсем сырыми.
Перед тем, как думать о коде, нужно доуточнить и согласовать бизнесовую постановку, требования, ожидаемый эффект.
В эту работу не получается продуктивно вовлечь всю команду.
С другой стороны, разделение участников команды на Discovery и Delivery по сути делит команду пополам. Скрам явно не про это.

Ага! Этот ваш скрам не работает!

На помощь приходит Jeff Patton и его Dual-Track development. Он говорит, что Discovery и Delivery - это два направления работы одной команды.

Посмотрите на картинку.
Снизу - спринты Scrum, а сверху что?
- циклы вариативной длины
- непрерывная поставка задач, готовых к спринту

добавим к этому визуализацию процесса через столбцы на доске + лимиты work in progress...

Да это ж Kanban!

Выходит, что мы в этом своём Scrum-based LeSS-like добавляем еще "Kanban-discovered"?

Оригиналная статья Jeff Patton
Адаптация Авито и их опыт
Сравнение Scrum и Kanban от Atlassian