Постановка задачи разработке: Definition of Ready, чек-лист

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

Кейс: одна строка вместо карточки

В «Узелке» задачу «Отмена заказа с причиной» (ЗД-48) передали разработчику одной строкой в трекере. Через два дня он вернулся с семью вопросами. Какая длина причины допустима? Что показать, если заказ уже у курьера? Где взять текст отказа? Ответы уже были в требованиях, макетах и критериях приёмки, но в карточку они не попали. (Номер задачи, количество вопросов и сроки условные: мы взяли их для иллюстрации.)

Работа была сделана, но не передана. Чек-лист готовности создаётся именно для таких случаев.

Что такое Definition of Ready

Definition of Ready (далее DoR, определение готовности) - это список условий, при которых задачу можно брать в работу. Это способ зафиксировать общее понимание команды о том, когда задачу можно считать готовой к работе.

Нужно оговорить статус понятия. DoR не входит в Scrum Guide и не является обязательным артефактом, хотя иногда в гайде видят неявное требование: элемент должен умещаться в один спринт. Это распространённая практика, а не официальная рекомендация. Общая мысль такая: список снижает риск, и критерии каждая команда выбирает сама.

Карточка задачи - это запись в трекере, которую читает исполнитель. Допущение - это то, что мы считаем верным, но пока не проверили: его записывают в карточке, чтобы оно не осталось невидимым.

Чек-лист из восьми вопросов

Обычно в список входят понятное название, польза для клиента, критерии приёмки, зависимости и риски, нужные материалы и оценка. Мы собрали из них и из предыдущих статей раздела восемь вопросов. Состав примерный: у каждой команды будет свой.

• Цель. Зачем задача нужна, кому и какую пользу даёт.
• Требование. Что именно делаем: есть номер и связь с целью (статья 02-22).
• Приёмка. По каким критериям поймём, что готово (статьи 02-09 и 02-25).
• Макет и тексты. Что увидит покупатель: экраны, состояния и подписи (статьи 02-15 и 02-17).
• Данные и API. Какие системы, поля и интеграции затронуты.
• Риски. От чего зависим и что может помешать; пробелы в требованиях ищем по статье 02-18.
• Оценка. Команда оценила задачу, и она помещается в итерацию (статья 02-23).
• Приоритет. Почему берём это, а не другое (статья 02-21).

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

Часто используют критерии INVEST: задача независимая, обсуждаемая, ценная, оцениваемая, небольшая и проверяемая. Однако и подходящая по INVEST задача может застрять: неясен следующий приоритет, нет макетов или нет общего понимания рисков.

Как передать задачу: разговор вместо записки

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

Разбор карточки вместе с командой даёт три вещи. Во-первых, мы слышим вопросы до старта. Во-вторых, оценку дают те, кто будет работать. В-третьих, допущения и риски обсуждаются вслух и не всплывают позже.

Как не превратить чек-лист в барьер

Чек-лист готовности сам может стать проблемой. Определение готовности нужно не всегда: если команда уже стабильно поставляет работающий продукт, оно может не понадобиться. Слишком высокая планка превращает список в препятствие, а принцип такой: «достаточно деталей и вовремя». Часть деталей лучше уточнять, когда работа уже началась. Исчерпывающие чек-листы могут привести к «похожей на водопад» ситуации.

Для нашей команды из этого следуют простые правила:

• список пишет сама команда, а не один человек для всех;
• в нём только то, без чего работу нельзя начать;
• пункт, который никогда не мешает старту, можно убрать;
• если чек-лист задерживает работу, его пересматриваем вместе с командой.

Где это встречается в работе

• Разбор бэклога с командой перед планированием итерации.
• Оформление карточки задачи в трекере.
• Ответы на вопросы разработчика во время работы: мы видим, какого пункта не хватило в карточке.
• Обсуждение задержек итерации: какие задачи были взяты неготовыми.
• Передача задачи между командами с общим списком требований к готовности.

Итог

Definition of Ready - это список условий, при которых задачу можно брать в работу. Мы собрали восемь вопросов: цель, требование, приёмка, макет, данные, риски, оценка, приоритет. Задачу лучше передавать разговором, а не одной карточкой, и держать список коротким, чтобы он не стал барьером.

Что дальше

Раздел требований на этом заканчивается. Дальше разберём, что такое бизнес-процесс и как он отличается от функции и регламента (статья 03-01).