Критерии готовности в разработке цифровых продуктов. Definition of Ready, Definition of Done и Acceptance Criteria

Когда мы готовим обед — как мы понимаем, что блюдо готово, и его можно подавать? В зависимости от блюда ориентироваться можно на цвет, видимую или осязаемую консистенцию, текстуру, особенности вкуса, температуру... Несмотря на кажущуюся простоту и автоматизм, с которым мы ставим блюду «диагноз», на деле мы учитываем много факторов.

Другими словами, нет одного состояния «готовности», оно включает целый набор критериев, которому соответствует готовая еда. И это мы говорим о сравнительно простой сущности, с которой имеем дело несколько раз за день.

Когда речь о сложном явлении, создание которого требует месяцев труда десятков людей — вопрос, что считать готовым, ещё более важен. И мы, конечно, говорим о цифровых продуктах и о том, как определять их «готовность».

В начале этого материала вспомним матчасть — какие критерии готовности должны обеспечивать качество единицы разработки при переходе от одного этапа к другому. Во второй части статьи узнаем, как на практике с этим работают крупные продуктовые команды «Яндекса», «Иннотеха», «АльфаСтрахования», «Росбанка» и «Самолёта».

Инкременты

В соответствии с актуальным сегодня гибким подходом важное свойство процесса разработки — инкрементальность. Это значит, что продукт декомпозирован на некие части, фрагменты. На языке организации процесса разработки фрагмент называют PBI — product backlog item, единицей продуктового бэклога. Мы будем использовать термин «инкремент».

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

Инкремент проходит несколько этапов жизни. Количество и суть этапов может различаться в зависимости от компании и команды, а также вида инкремента. Например, инкремент уровня задачи может последовательно проходить этапы аналитики, разработки (написания кода) и тестирования. За каждый этап отвечают разные специалисты или отделы. Ключевое слово — «последовательно». Это значит, что инкремент вряд ли может находиться параллельно на этапе аналитики и разработки. Только когда аналитик закончит всю работу на своей стороне, а QA-специалист протестирует разработанные аналитиком требования — инкремент переходит к разработчику.

В какой момент и при каких условиях инкремент должен поступить команде разработки? Это отличный вопрос. Очевидно, когда вся работа на стороне аналитика выполнена, требования протестированы, и инкремент готов к передаче. А если на этапе, предшествующем разработке, упущено что-то важное? Это не всегда видно невооружённым (и неопытным) взглядом, но обязательно вскроется на одном из шагов разработки.

Здесь-то и приходит на помощь Definition of Ready — дословно с английского «определение готовности».

Definition of Ready (DoR)

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

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

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

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

Проверка инкремента на соответствие DoR выполняется на этапе планирования спринта. Команда обсуждает каждый инкремент (например, пользовательскую историю) и проверяет, соответствует ли он всем критериям DoR.

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

Примеры критериев DoR:

1. Пользовательская история или описание задачи конкретны и ясны.
2. Требования к инкременту протестированы.
3. Разработаны тест-кейсы.
4. Команда понимает требования и ожидания пользователей.
5. Есть все необходимые ресурсы — дизайн-макеты, данные и т. д.
6. Определены приоритеты и зависимости.
7. Оценены сложность и объём работы.
8. Определены критерии успешного завершения задачи.

Окей, инкремент перешёл к команде разработки — дизайнерам, разработчикам и тестировщикам. Рано или поздно наступает момент, когда работа над инкрементом завершена. Некая фича реализована, её можно передавать заказчику, а затем — пользователю. Как понять, что этот момент настал, и готовность инкремента — 100%?

Здесь на помощь приходит Definition of Done — критерии «сделанности», готовности к использованию.

Definition of Done (DoD)

Критерии DoD — это критерии, схожие с DoR, но применяемые на следующем этапе развития, когда команда разработки закончила работу. Критерии Definition of Done (DoD) обычно формулируются командой на раннем этапе проекта.

Соответствие инкремента критериям Definition of Done означает, что он завершён и готов к передаче заказчику и пользователю. Критерии DoD, так же, как и DoR, могут применяться к пользовательским историям, задачам, спринтам и любым другим элементам бэклога.

Критерии DoD должны быть ясными, измеримыми и достижимыми для всей команды. Если элемент не соответствует критериям DoD, команда решает, что необходимо сделать, чтобы исправить это.

Примеры критериев DoD:

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

2. Тестирование. Продукт прошёл все ручные и автотесты по кейсам, разработанным QA-специалистами. Тестами покрыт необходимый заказчику объём требований.

3. Дизайн и интерфейс. Интерфейс соответствует стандартам: внешним (например, гайдам мобильных платформ или основам доступности пользователям с ограниченными возможностями) и внутренним (например, фирменному стилю и дизайн-системе)

4. Документация. Документация полна и объясняет всё, что необходимо для использования инкремента.

5. Интеграция. Инкремент успешно интегрирован в общую систему или проект.

DoR и DoD — универсальные критерии. Как правило, они применимы ко всем инкрементам одного уровня в рамках продукта. То есть можно сформировать один набор критериев и применять их ко всем пользовательским историям. Свой единый набор критериев можно создать для эпиков и других инкрементов. Их не нужно каждый раз писать заново. С Acceptance Criteria дело обстоит иначе.

Acceptance Criteria (AC, критерии приёмки)

Как и Definition of Done, AC помогают определить успешное завершение работы над инкрементом. Отличие в том, что Acceptance Criteria более конкретны. Это набор условий и требований, которые определяют, что должен «уметь» продукт или фича, чтобы считаться успешно завершёнными.

Acceptance Criteria обычно формулируются в виде конкретных верифицируемых условий, которые должны быть выполнены. Они могут быть связаны с функциональностью, производительностью, надёжностью, пользовательским опытом и другими требованиями. Для каждого инкремента AC будут уникальными. Они также служат основой для проведения тестирования.

Acceptance Criteria также применимы к любыми элементам бэклога: пользовательским историям, задачам, этапам, релизам и версиям.

К формулированию AC могут быть привлечены представители заказчика, пользователи, аналитики, разработчики и другие участники проекта. Acceptance Criteria могут быть сформулированы в процессе сбора требований к инкременту, разработки пользовательских историй, взаимодействия с заказчиком или пользователем.

Проверять инкремент на соответствие AC может как представители заказчика (например, QA-специалист), так и участники команды разработки. Пользователь — это идеальный, но часто труднодоступный агент для проверки на соответствие продукта критериям AC. Его привлекают к оценке опосредованно, через юзабилити-тестирование.

Примеры Acceptance Criteria:

1. Пользователь может добавлять товары в корзину и оформлять заказ.

2. Система поддерживает одновременную работу не менее 1 000 пользователей без заметных задержек.

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

4. Приложение отображается корректно на устройствах моделей A, B, С и других устройствах с экраном диагональю X*Y.

5. Все документы должны быть доступны для скачивания в формате PDF.

По мнению Agile-экспертов критерии DoR, DoD и AC повышают управляемость процесса разработки и качество итогового продукта, а также эффективность сотрудничества специалистов, отвечающих за разные этапы разработки. А что на практике?

Что говорят эксперты в крупных компаниях

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

Выяснилось, что большие компании с развитой внутренней технологической культурой не воспринимают принципы Agile как догмы и, в частности, практически не используют терминов Definition of Ready, Definition of Done и Acceptance Criteria. Впрочем, и не отрицают их пользу.

«АльфаСтрахование»

Антон Исанин, директор по разработке в «АльфаСтраховании» считает, что эти атрибуты, конечно, полезны, но не заменяют определённый уровень компетенций команды. И в целом если компания инвестирует в наём, обучение и построение культуры — команда может работать без этих формальностей.

«Мне на практике доводилось видеть, как критериями Definition of Ready или Definition of Done пытались заменить вещи более высокого порядка — культуру работы, ценности, общие требования к процессам и политику компании. В других случаях необходимость в этих атрибутах была следствием недостатка компетенций — например, в аналитике. Я допускаю, что критерии DoR и DoD могут выступать как „доталкивающий“ механизм, точечно дополнять договорённости в команде или с заказчиком. Но если нет фундамента — они не исправят ситуацию в корне».
Антон Исанин, «АльфаСтрахование»

Группа «Иннотех»

Владимир Ларин, ведущий системный аналитик в Группе «Иннотех», рассказывает, что их команды не пользуются Definition of Ready и другими терминами, но работают по строгим внутренним регламентам. Эти регламенты не позволяют перескочить какой-либо этап или пренебречь важными артефактами инкремента.

«Разработка у нас выстроена по внутренней методике, которая предполагает жёсткие регламенты на каждом этапе. В нашей терминологии нет Definition of Done или Definition of Ready, но в действительности все эти атрибуты зашиты в процессах. Например, разработчики не возьмутся за фичу, если предварительно не описаны все интеграции, вызовы и ответы, базы данных вплоть до полей и множество других деталей — по сути это и есть Definition of Ready. То, что должна делать фича, описано на самом раннем этапе работы — это Acceptance Criteria. Перед релизом пользовательскую историю проверяют на выполнение КТ — контрольных точек, то есть на наличие всех согласований, атрибутов и прочего. Нет 100 % КТ — нет релиза. Это ни что иное, как Definition of Done».
Владимир Ларин, «Иннотех»

«Росбанк»

Елена Мелентьева, руководитель направления центра цифровых решений для корпоративного бизнеса в «Росбанке», считает, что залог качественного результата — это личные качества участников процесса. Задача продакт-менеджера — выстраивать эффективные коммуникации и слышать заказчика, а в команде каждый должен понимать не только что он делает, но и какую бизнес-ценность это принесёт.

«Мы в „Росбанке“ работаем по Agile, но не пытаемся слепо следовать всем принципам. Мы давно отказались от терминов Definition of Ready и Definition of Done, так же как и от жёстких списков этих критериев. Сами по себе критерии не гарантируют ничего, хотя и присутствуют в неявном виде. Чтобы выкатывать качественные продукты, которые удовлетворяют клиента и несут ценность, нужно выстраивать коммуникации с заказчиком и в команде, контролировать процесс, развивать культуру ответственности».
Елена Мелентьева, «Росбанк»

«Яндекс»

Игорь Аскаров, руководитель разработки инфраструктурной платформы в «Яндексе», считает, что в проектах, которые только запускаются, без атрибутов типа Definition of Done не обойтись. Это особенно важно в тех случаях, когда начальный MVP разрабатывает внешняя команда на основе чётких требований и в рамках фиксированного срока.

Если основатели запускают продукт на свои деньги, важность конкретики только возрастает. Страх впустую потратить собственные средства, как правило, несравнимо сильнее, чем когда речь о ресурсах, выделенных инвесторами и акционерами. Критерии готовности и приёмки призваны уберечь команду от этих ошибок.

Но если продукт уже зрелый, компания чувствует себя уверенно, и операционные расходы на порядки превышают инженерные — скрупулёзный формализм скорее ограничивает. Это может даже вызвать критику, и вопросы не о том, что удалось сделать, а о том, когда будут наняты десятки или сотни инженеров, необходимых для интенсивного развития продукта.

«В „Яндексе“, как мне кажется, неважно, насколько подробно прописаны критерии приёмки и насколько результат работы соответствует им. Важно, что новая функциональность проходит по базовым критериям производительности и устойчивости, а главное — что пользователи довольны, а метрики бизнеса растут. Соответственно, и работают здесь, как правило, инженеры, ориентированные на ценность для пользователя и бизнеса, болеющие за результат. Для программистов, которые „пилят“ строго по ТЗ и не задают вопросов, это не лучшая среда».
Игорь Аскаров, «Яндекс»

«Самолёт Финансовые технологии»

Александр Комаров, руководитель проектного офиса «Самолёт Финансовые технологии», рассказывает, что в глазах компании важнейшая составляющая Agile-философии — это зрелость, автономность и самодостаточность команды разработки. Каждая команда сама решает, какие практики применять.

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

«Команды, которые развивают уже сформированный и работающий продукт, действительно, могут использовать критерии DoR, DoD и AC как механизм перевода user story между этапами. А вот команды, которые имеют дело с новыми продуктами, как правило, действуют в режиме стартапа: берут в работу всё, что приходит от бизнес-заказчика, не придают значения формальным деталям, быстро исследуют, запускают, проверяют. Критерии приёмки присутствуют, хотя и не играют критической роли. Не взять фичу в работу могут, только когда её бизнес-ценность не очевидна».
Александр Комаров, «Самолёт Финансовые технологии»

arcsinus

Павел Голуб, директор по развитию и сооснователь компании arcsinus, помогает взглянуть на вопрос несколько под другим углом — с позиции представителя аутсорсинговой компании. По его мнению, в модели «заказчик-исполнитель», где есть ограничения по времени и бюджету, чётко понятные критерии — не просто формальность. Definition of Ready, Definition of Done и Acceptance Criteria помогают всем участникам процесса сохранять единое понимание результата на каждом этапе, в том числе на уровне отдельного тикета. За 10+ лет работы с заказчиками самого разного калибра вовремя сформулированные критерии приёмки уберегли не одну команду arcsinus от бесконечного дрейфования в неизвестном направлении и обеспечили ожидаемый результат. Кстати, уберегли ещё и от выгорания.

«По комментариям коллег понятно, что подход отличается от компании к компании. Однако так или иначе критерии готовности присутствуют у всех, пусть часто и в неявном виде. Мы за гибкость. Каждый проект уникален и может требовать разных подходов и процессов. На большинстве наших проектов критерии приёмки добавляют эффективности и мотивированности и всей команде, и каждому отдельному специалисту. Когда у специалиста есть понимание, чего от него ждут — он охотно берёт на себя ответственность за результат. Когда ожидаемый результат в тумане — то и отвечать не за что. Из понятных критериев приёмки складывается и общее понимание ценности продукта»
Павел Голуб, arcsinus

TL;DR

1. Гибкий подход к разработке цифрового продукта предполагает деление на инкременты — пользовательские истории, задачи, эпики, спринты и т. д.

2. Согласно принципам Agile движение инкремента по этапам жизненного цикла происходит на основе его соответствия определённому набору критериев.

3. Критерии, на основании которых команда разработки берёт инкремент в работу, называются Definition of Ready. Критерии, на основании которых инкремент передают заказчику, а затем пользователю — Definition of Done.

4. Передача инкремента заказчику или пользователю также может происходить на основании соответствия Acceptance Criteria. Это более точные условия, описывающие, что должен «уметь» готовый продукт.

5. На практике многие зрелые продуктовые компании не используют термины Definition of Ready, Definition of Done и Acceptance Criteria. От жёстко установленных критериев отказываются в пользу большей гибкости и открытости. При этом критерии могут быть встроены в процессы и культуру работы, а высокий уровень компетенций сотрудников избавляет от необходимости прописывать критерии для каждой единицы поставки.

‍

Это материал опубликован на cnews.ru