Discovery и Delivery: где они в Scrum-команде

Как-то на одном из тренингов, когда я рассказывала про Discovery и Delivery голосом, участники попросили меня написать это текстом. Я откладывала написание статьи, и финальным ускорителем стала цитата из книги «Как приготовить проект. Рецепты для создания успешных продуктов и команд», которая убедила меня, что пора написать.

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

На тренингах по «Управлению бэклогом продукта и построению USM», а также в Школе Скрам-мастеров, я замечала, что у участников происходит путаница между сущностями: артефакт и процесс и я делала дополнительную остановку, чтобы проговорить, что есть что.

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

В один прекрасный день в вашей компании началась Agile-трансформация, по итогу которой появились Scrum-команды. Участники этих команд проходили обучение по основам Agile и Scrum, их запускали опытные Agile-консультанты, и в них появились Скрам-мастера.

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

В команду приходит опытный Скрам-мастер, который наблюдает за происходящим и понимает, что в команде не хватает основного элемента - не выстроен процесс Discovery. С этой мыслью он идёт к Владельцу Продукта (PO), который смотрит на него весьма озадаченно.

— Мы же работаем по спринтам. Про какое Discovery ты говоришь?
Скрам-мастер берёт маркер и начинает рисовать на доске, начиная диалог с Владельцем Продукта.
— PO, как ты получаешь элементы в свой бэклог?
— Я общаюсь с заказчиками и понимаю их сложности и пожелания к продукту, а также у меня бывают свои идеи.
— Хорошо, когда ты пообщался со своими заказчиками, что происходит дальше?
— Я даю задание, чтобы его описал аналитик.
— То есть ты просишь сделать ТЗ?
— Ну да!
— И этого всё равно не хватает разработчикам, раз они проясняют всё в течение спринта?
— Им всегда чего-то не хватает.
— А чего им не хватало в прошлом спринте?
— Они сказали, что не понимают образ результата и зачем это нужно заказчику?
— А были ли у твоих элементов бэклога Критерии Приёмки?
— А что это такое?
— Давай расскажу. Когда ты приносишь элемент бэклога продукта на планирование, чтобы его уже взяли в работу на разработку, этот процесс называется Delivery. Этот элемент должен быть одинаково понят всеми — какой результат должен получиться в конце. Чтобы вариативность понимания была сведена к минимуму (а стремимся мы к нулю), в твоём элементе бэклога должны быть прописаны Критерии Приёмки, которые дают ответ на вопрос: «Как мы поймём, что сделали то, что просил от нас заказчик?».
Через Критерии Приёмки закрываются все общие слова в формулировке элемента бэклога продукта. Например, у тебя есть элемент: «Я как HR хочу иметь возможность управлять вакансиями, чтобы повысить эффективность своей работы». Видишь ли ты здесь общие слова?
— Да, это «управлять», «повысить» и «эффективность».
— Верно. И чтобы у нас не было галлюцинаций, эти слова надо уточнить у самого HR, что они значат для него. Если ты его спросишь, то узнаешь, например, что «управлять» для него — это: редактировать все поля, удалять вакансии с возможностью восстановления в течение 30 дней, при этом при удалении всплывает предупреждение, чтобы случайно не удалить то, что не хотел; архивирование вакансий, автосохранение изменений (сейчас надо постоянно нажимать кнопку).
— Скрам-мастер, я тебя понял, но когда мне это делать?
— Когда ты понимаешь, что необходимо будет разработать этот функционал в ближайших спринтах. Каждая компания отвечает на этот вопрос «когда?» самостоятельно. Главное придерживаться правила: это не слишком рано, чтобы не обнадёжить заказчика и чтобы пожелания не устарели, и не слишком поздно, чтобы было достаточно времени на проработку деталей, необходимых и достаточных для процесса Delivery.
— Я тебя понял, будем идти через эмпиризм. Давай представим, что я пошёл к заказчику, тому самому HR, и начал у него прояснять. Прояснил его «хотелки», а дальше что?
— А дальше тебе надо найти ответ на вопрос: что ещё необходимо сделать, для того чтобы элемент был готов к взятию в процесс Delivery?
— И как мне это понять?
— В Скрам существует такое дополнительное событие, как PBR (Product Backlog Refinement) - уточнение бэклога продукта. На нём команда смотрит на элементы, которые планируется разрабатывать в ближайшие 2−3 спринта, а также на готовность тех, которые надо будет брать в следующий спринт.
— Так, подожди, а не поздновато ли спрашивать там?
— И да, и нет. Если вам уже сейчас нужен ответ на вопрос «Что надо прояснить для Delivery?», то можешь презентовать элемент команде в конце Ежедневного Скрама. Скажи об этом заранее, чтобы участники команды понимали, что от них требуется. Важно, чтобы это не затянулось в длительное обсуждение. Если обсуждение затягивается, то можно посмотреть в сторону проведения двух PBR в течение спринта: один на обсуждение и сбор пожеланий к проработке, второй — как результат того, что сделали. Такое бывает в командах, где сложные элементы и нет типового подхода к прояснению.
— Что значит типового?
— Со временем команда понимает, что для вот таких элементов необходимо согласовать макет и только после этого передавать в Delivery; для вот таких элементов — описание таблиц и источников данных и т. п.
— Ага, понял тебя.
— Скрам-мастер, а у этого всего, что ты рассказываешь, есть какое-то объединяющее название?
— Да, мы называем это Definition of Ready (DoR) - критерии готовности к взятию в спринт.
— Правильно ли я тебя понимаю, что DoR — это своего рода чек-лист, который мы проходим на PBR, и только после этого говорим, что элемент может быть представлен на планировании?
— Да, всё верно, но тут главное правило, что в комплексной среде не будет описано всё на 100%. В элементе должно быть достаточно информации, чтобы все одинаково понимали образ результата («что и зачем») и смогли создать дорогу к нему («как это сделать?») — это уже на планировании. При этом на PBR может произойти такое, что остался какой-то маленький вопрос, который нужно допрояснять. Поэтому его проводят на 7 или 8 день текущего спринта, чтобы к первому дню следующего спринта ответы уже были найдены или принято решение, что можем взять без этого ответа (так как не критично), или же, наоборот, не берём, так как без ответа на этот вопрос необходимо будет разрабатывать дважды.
— Окей, про DoR я понял, это тоже будем искать эмпирически. Помогай нам, пожалуйста, на PBR, планировании и ретроспективе, чтобы мы со временем нашли свой идеальный DoR.
— Хорошо.
— Вот ты много говорил про Delivery, а что же про Discovery? Если я тебя правильно слышу, то весь процесс до момента появления DoR — это и есть Discovery?
— Да, ты правильно подметил. Если в процессе Delivery его главное событие — это событие Sprint Review (Обзор спринта), и выходим мы на него, когда убеждаемся, что инкременты соответствуют DoD (Definition of Done), то для Discovery таким событием будет PBR, на котором в первую очередь будут представлены элементы, которые будут разрабатываться в следующем спринте, и эти элементы должны соответствовать DoR.
— Таким образом, если я правильно тебя слышу, когда у нас запускается спринт, у нас параллельно идут два процесса: и Delivery, и Discovery.
— Да, всё верно. Спринт — это отрезок времени, внутри которого происходит Delivery и Discovery.
— Скрам-мастер, по разделению и совмещению процессов я понял. Чего я не могу понять, как мне с командой-то быть? У меня их что, две должно быть?
— Нет, это частое заблуждение. У нас есть Scrum Team, куда входит PO, Developers и SM. Частым заблуждением является то, что Developers — это только разработчики. На самом деле Developers — это все, кто тебе нужен на 100% для создания Инкремента. А создание — это и Discovery, и Delivery. Часть команды, чаще это дизайнер и аналитики, совместно с PO занимаются Discovery. Иногда требуется привлечение тех, кто занят Delivery (FE, BE, QC), но тут действует правило: приоритетом для тех, кто занят Delivery, являются элементы, которые находятся в Delivery. И здесь появляется дилемма: как же быть, если BE, например, был занят, и из-за этого аналитик (SA) не успел?
Она решается также на планировании. Когда ты представляешь элементы бэклога для Delivery, также представляются элементы для Discovery, но только с той целью, чтобы те, кто будет заниматься Discovery, получили информацию: «А что ещё исследовать?» и проинформировали, чья поддержка им нужна будет. Так что все смогут совместно распланировать своё время, поскольку все заинтересованы и в поставке, и в получении задач на Delivery. 
— Скрам-мастер, тут я тебя тоже понял. Мне ещё кое-что не понятно. Если у нас Delivery работает по Scrum, как выстроить Discovery?
— Это отличный вопрос. Нам надо будет посмотреть, как идёт наш процесс Discovery. Чаще для него используется Kanban-метод. Основная наша задача, чтобы процесс помогал ответить на вопросы: разрабатываем или нет? Если разрабатываем, то что и зачем.
— А как мы находим эти ответы?
— В этой части у каждой компании тоже свои подходы в зависимости от контекста продукта. Когда продукт уже есть, а это наш с тобой случай, Discovery может выглядеть так: 
1. Разработка прототипа (-ов).
2. Проверка прототипа (-ов) на техническую реализуемость.
3. Составление матрицы фичей (Кано).
4. Тестирование прототипа (-ов) (при этом данный этап считается пройденным, если проведено тестирование прототипа и заполнены таблицы по методу Кано).
5. Подведение итогов.
6. Анализ (подготовка элемента для передачи в разработку).
7. Финал: «Готово к Delivery».
Основная задача Discovery — это ответить на вопрос, точно ли мы нашли решение той задачи, которая стояла перед заказчиком (Problem-Solution Fit), верны ли наши гипотезы и можем ли мы это реализовать технически.
Важная задача — попасть на пересечение трёх составляющих:
• «полезность для пользователя»
• «ценность для бизнеса»
• «техническая реализуемость»
— А почему ты подсвечиваешь ещё техническую реализуемость на этапе Discovery, разве это не про Delivery?
— Эта часть про Discovery и этот этап у ряда компаний может выглядит как прохождение через архитектурный совет или комитет, в том числе получение согласия со стороны безопасности. При этом результаты прохождения этого этапа у компаний может отличаться. Например, для крупной компании это может означать, что надо просчитать, сколько денег будет стоить новая архитектура и сколько займет по времени её построение для данного решения и этот этап — получение разрешения на изменение архитектуры и выделение бюджета. Для компаний, чей бюджет ограничен, техническая реализуемость будет означать, смогут ли они это сделать на текущих своих решениях, а если нет, то как это повлияет на конечную ценность для пользователя.
— Скрам-мастер, я тебя понял, давай начнем выстраивать Discovery и разрабатывать наши DoR. Я со своей стороны тебя поддержу и подготовлю всё, что от меня потребуется.

История, которую вы только что прочитали, показывает фундаментальный сдвиг парадигмы в работе команды. Мы уходим от модели, где команда – это просто фабрика по выпуску фич (output), к модели, где команда – это поисковый отряд, доставляющий ценность (outcome).

Delivery без Discovery превращается в хаотичную трату времени и ресурсов. DoR (Definition of Ready) – это не просто чек-лист, это официальная граница между Discovery и Delivery, которую команда принимает самостоятельно.

Главное, помните: зрелая Agile-команда не просто строит правильно (Delivery), она сначала убеждается, что строит правильное (Discovery). Успехов в вашем пути!