Критерии приёмки Acceptance Criteria Глоссарий владельца продукта

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

Что такое критерии приемки и их роль в проектах?

Лучше использовать несколько простых предложений, чем одно сложное. Чем меньше ненужных слов и союзов, таких как “но”, “и”, “так как”, в ваших критериях приемки, тем более понятными становятся требования для команды разработки. Всегда лучше избегать использования наречия “не”, так как оно часто делает требования неясными и менее поддающимися проверке. Однако использование “не” возможно, если есть необходимость представить уникальные требования к функциональности системы. Например, “Форма входа не должна подсвечиваться красным, когда пользователь вводит неверные значения.” Команда и заказчик могут иметь разные взгляды на пути решения проблемы, в зависимости от их точек зрения.

• Если абстрагироваться от теории, то US + AC – это та же самая статья, в начале которой описывается краткая суть, краткое содержание того, чем вы хотите поделиться с читателем.
• Это набор условий и требований, которые определяют, что должен «уметь» продукт или фича, чтобы считаться успешно завершёнными.
• Все вышеупомянутые формулы для написания критериев приемки легки в применении и, что еще более важно, эффективны.
• Уже сейчас вы перечислили пять вещей, которые хотите отслеживать.
• Критерии приемки также иногда называют «definition of done», потому что они определяют объем и требования, которые должны быть выполнены разработчиками, чтобы считать User Story завершенной.

Given-When-Then: переводим с языка заказчика на язык критериев приемки

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

Давайте посмотрим на это, на примере метафоры нашего любимого аэропорта.

Список атрибутов завершенности применяется абсолютно ко всем историям или ко всем элементам бэклога. Критерии приемки должны быть задокументированы до начала фактической разработки. Таким образом, команда скорее всего заранее учтет все потребности клиента. В начале достаточно установить критерии для небольшого количества пользовательских историй, чтобы заполнить бэклог на два спринта (если вы используете Scrum или подобный метод).

Основные цели критериев приемки

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

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

Пишите Acceptance Criteria с точки зрения пользователя, как если бы у него были конкретные пожелания к функциональности. В этом смысле написание похоже на описание User Story — простое и понятное каждому, отражающее потребность пользователя. Мое рецензирование jira задач не похоже на классическое книжное ревью, потому что у нас часто бывает, что Product Manager торопится и не прописывает все детали.

Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц. Поскольку разные люди могут иметь разные точки зрения и идеи решения одной проблемы, необходимо создание единого видения того, как должна быть реализована функциональность. Это именно то, что делают четко сформулированные критерии приемки. Критерии приемки определяют границы пользовательских историй. Они предоставляют точные детали функциональности, которые помогают команде понять, выполнена ли история и работает ли она, как ожидалось. Как менеджер продукта, вы можете нести ответственность за написание Acceptance Criteria в вашем бэклоге продукта.

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

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

Практически любой член кросс-функциональной команды мог написать критерии приемки для пользовательских историй. Обычно владелец продукта или менеджер отвечает за написание критериев приемки или, по крайней мере, за содействие их обсуждению. Идея состоит в том, чтобы гарантировать, что требования написаны с учетом потребностей клиентов, и кто лучше понимает потребности клиентов, чем специалист по продукту? Тем не менее рекомендуется сделать написание критериев  групповой деятельностью, в которую входят как разработчики, так и представители QA.

Этот пункт связан с пунктом 2 и напрямую влияет на него. Одно из главных преимуществ такого подхода заключается в том, что он может быть понятен нетехническим людям. Инструмент, способный описать функцию для любого человека и одновременно управлять реализацией/тестированием, бесценен. Неспособность строить и воплощать средне- и долгосрочные планы ставит крест на любых перспективах выживания бизнеса клиента.

Продукт, который работает, но не документирован — мёртв. Завтра там нужно будет что-то поменять, а документации, которая проливает свет на то, что и как работает — нет. Аффтаматизатары живут в Индокитаях, они все эти сценарии к себе высасывают, бездумно их аффтаматизируют, дженкинс мутится, тесты крутятся, всем всë норм. Расхождение между мануальным и коньпедальным тестированием крепнет и ширится, но это не так существенно, как кажется в теории.