Определить, готов ли к выводу на рынок цифровой продукт, не так уж просто. Как мы понимаем, что блюдо можно подавать на стол? Ориентироваться можно на цвет, консистенцию, текстуру, особенности вкуса, температуру… Несмотря на автоматизм, с которым мы ставим блюду «диагноз», на деле мы учитываем много факторов — и это мы говорим о сравнительно простой сущности, с которой имеем дело каждый день. Еще сложнее делать выводы, когда речь идет о сложном явлении, создание которого требует месяцев труда десятков людей. Вспоминаем, какие критерии готовности должны обеспечивать качество единицы разработки при переходе от одного этапа к другому, и как на практике с этим работают крупные продуктовые команды «Яндекса», «АльфаСтрахования», «Росбанка» и «Самолета».
Инкременты
В соответствии с актуальным сегодня гибким подходом важное свойство процесса разработки — инкрементальность. Это значит, что продукт декомпозирован на некие части, фрагменты. На языке организации процесса разработки фрагмент называют PBI — product backlog item, или единица продуктового бэклога. Мы будем использовать термин «инкремент».
Примеры инкрементов разного уровня — спринт, эпик, задача, релиз, пользовательская история… Продукт целиком — тоже инкремент, но самого высокого уровня.
Инкремент проходит несколько этапов жизни. Количество и суть этапов может различаться в зависимости от компании и команды, а также вида инкремента. Например, инкремент уровня задачи может последовательно проходить этапы аналитики, разработки (написания кода) и тестирования. За каждый этап отвечают разные специалисты или отделы. Ключевое слово — «последовательно». Это значит, что инкремент вряд ли может находиться параллельно на этапе аналитики и разработки. Только когда аналитик закончит всю работу на своей стороне, а QA-специалист протестирует разработанные аналитиком требования — инкремент переходит к разработчику.
В какой момент и при каких условиях инкремент должен поступить команде разработки? Когда вся работа на стороне аналитика выполнена, требования протестированы, и инкремент готов к передаче. А если на этапе, предшествующем разработке, упущено что-то важное? Это не всегда видно невооруженным (и неопытным) взглядом, но обязательно вскроется на одном из шагов разработки.
Здесь-то и приходит на помощь Definition of Ready — дословно с английского «определение готовности».
Definition of Ready (DoR)
Это набор критериев, которые определяют, когда инкремент готов к началу разработки. Иначе говоря, это описание того, что должно быть выполнено прежде, чем задача будет взята в работу.
DoR применяется к пользовательским и техническим историям, эпикам, задачам, спринтам, релизам и любым другим инкрементам.
Формулирование критериев DoR обычно происходит на ранних этапах планирования проекта. К процессу могут быть привлечены любые участники команды разработки, представители заказчика и пользователи продукта.
Критерии DoR должны быть максимально четкими, понятными и достижимыми. DoR могут меняться и дорабатываться на протяжении жизни проекта по мере приобретения опыта и получения обратной связи от заинтересованных сторон.
Проверка инкремента на соответствие DoR выполняется на этапе планирования спринта. Команда обсуждает каждый инкремент (например, пользовательскую историю) и проверяет, соответствует ли он всем критериям DoR.
Инкремент, соответствующий критериям DoR, готов к началу разработки. Если инкремент не отвечает каким-то критериям — он считается неготовым и отправляется на доработку, прежде чем будет включен в производственный цикл.
Примеры критериев DoR
- Пользовательская история или описание задачи конкретны и ясны.
- Требования к инкременту протестированы.
- Разработаны тест-кейсы.
- Команда понимает требования и ожидания пользователей.
- Есть все необходимые ресурсы — дизайн-макеты, данные и т. д.
- Определены приоритеты и зависимости.
- Оценены сложность и объем работы.
- Определены критерии успешного завершения задачи.
Консалтинговый центр Scrum Inc. приводит следующий набор критериев DoR:
- Описание цели PBI.
- Ценность PBI для бизнеса.
- Оценка трудозатрат для реализации PBI.
- Порядок приоритетности PBI по их бизнес-ценности.
Итак, инкремент перешел к команде разработки — дизайнерам, разработчикам и тестировщикам. Рано или поздно наступает момент, когда работа над ним завершена. Некая фича реализована, ее можно передавать заказчику, а затем — пользователю. Как понять, что этот момент настал, и готовность инкремента — 100 %? Здесь на помощь приходит Definition of Done — критерии «сделанности», готовности к использованию.
Definition of Done (DoD)
Критерии DoD — это критерии, схожие с DoR, но применяемые на следующем этапе развития, когда команда разработки закончила работу. Критерии Definition of Done (DoD) обычно формулируются командой на раннем этапе проекта.
Соответствие инкремента критериям Definition of Done означает, что он завершен и готов к передаче заказчику и пользователю. Критерии DoD, так же, как и DoR, могут применяться к пользовательским историям, задачам, спринтам и любым другим элементам бэклога.
Критерии DoD должны быть ясными, измеримыми и достижимыми для всей команды. Если элемент не соответствует критериям DoD, команда решает, что необходимо сделать, чтобы исправить это.
Примеры критериев DoD
- Код. Закончена разработка и код-ревью, код соответствует принятым в компании стандартам, отсутствуют ошибки и предупреждения компилятора (алерты). Код успешно компилируется, все составляющие продукта функционируют корректно.
- Тестирование. Продукт прошел все ручные и автотесты по кейсам, разработанным QA-специалистами. Тестами покрыт необходимый заказчику объем требований.
- Дизайн и интерфейс. Интерфейс соответствует стандартам: внешним (например, гайдам мобильных платформ или основам доступности пользователям с ограниченными возможностями) и внутренним (например, фирменному стилю и дизайн-системе)
- Документация. Документация полна и объясняет все, что необходимо для использования инкремента.
- Интеграция. Инкремент успешно интегрирован в общую систему или проект.
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 000 пользователей без заметных задержек.
- Все введенные данные проходят валидацию. Система не обрабатывает данные, не соответствующие заданным стандартам, и уведомляет пользователя об ошибке в введенных данных.
- Приложение отображается корректно на устройствах моделей A, B, С и других устройствах с экраном диагональю X*Y.
- Все документы должны быть доступны для скачивания в формате 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, помогает взглянуть на вопрос несколько под другим углом — с позиции представителя аутсорсинговой компании. По его мнению, в модели «заказчик-исполнитель», где есть ограничения по времени и бюджету, четко понятные критерии — не просто формальность.
За 10+ лет работы с заказчиками самого разного калибра вовремя сформулированные критерии приемки уберегли не одну команду arcsinus от бесконечного дрейфования в неизвестном направлении и обеспечили ожидаемый результат. Кстати, уберегли еще и от выгорания.
«По комментариям коллег понятно, что подход отличается от компании к компании, — отмечает эксперт. — Однако так или иначе критерии готовности присутствуют у всех, пусть часто и в неявном виде. Мы — за гибкость. Каждый проект уникален и может требовать разных подходов и процессов. На большинстве наших проектов критерии приемки добавляют эффективности и мотивированности и всей команде, и каждому отдельному специалисту. Когда у специалиста есть понимание, чего от него ждут — он охотно берет на себя ответственность за результат. Когда ожидаемый результат в тумане — то и отвечать не за что. Из понятных критериев приемки складывается и общее понимание ценности продукта».
Подведем итог: на практике многие зрелые продуктовые компании не используют термины Definition of Ready, Definition of Done и Acceptance Criteria. От жестко установленных критериев отказываются в пользу большей гибкости и открытости. При этом критерии могут быть встроены в процессы и культуру работы, а высокий уровень компетенций сотрудников избавляет от необходимости прописывать критерии для каждой единицы поставки.
Поделиться
