Что такое критерии приемки? Примеры и рекомендации

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

В чем секрет создания программного обеспечения, которое действительно работает? Если вы менеджер по продукту или владелец продукта, то точное определение критериев приемки — это ключ к созданию функций, которые точно попадут в ожидания клиентов.

Без ясно определенных критериев приемки команды рискуют столкнуться с недопониманием, не выполнить поставленные задачи и потратить усилия впустую. Но что такое критерии приемки и как их правильно составлять?

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

Что такое критерии приемки?

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

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

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

Критерии приемки и пользовательские истории

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

• Пользовательские истории объясняют, для чего выполняются какие-либо задачи, и доносят цель и значение функции с точки зрения пользователя.

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

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

Например, пользовательские истории могут быть такими:

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

Эта история задает направление. В ней не указана реализация.

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

• Функция поиска должна выдавать результаты, точно совпадающие с введенным названием продукта.

• Функция поиска должна выдавать результаты, частично совпадающие с введенным названием продукта.

• Результаты должны отображаться в понятном, упорядоченном и удобном для пользователя формате.

Все это помогает команде не только создавать нужные продукты, но и делать это правильно.

Характеристики хороших критериев приемки

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

Ясность и краткость

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

Критерии должны быть краткими и ориентированными на результат. Избегайте жаргона и любых формулировок, которые могут быть истолкованы неправильно.

Тестируемость

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

Возможность тестирования устраняет любую субъективность и помогает всем понимать, что на самом деле означает «готово».

Конечный результат

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

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

Измеримость

По возможности выражайте ожидания в количественной форме, чтобы установить четкий критерий успеха. Такая точность ускоряет тестирование и сокращает объем доработок.

Избавьтесь от расплывчатых формулировок, таких как: «Страница с результатами должна хорошо выглядеть». Вместо этого используйте утверждения, содержащие конкретные цифры, например: «Каждое изображение продукта должно иметь разрешение не менее, чем 300×300 пикселей».

Независимость

Каждый критерий должен быть самостоятельным. Независимые критерии упрощают тестирование, уменьшают связанность и облегчают диагностику проблем в случае сбоя.

Если критерии зависят друг от друга, их, вероятно, следует пересмотреть.

Зачем нужны критерии приемки?

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

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

• Сокращение неопределенности и доработок. Четкие критерии готовности (DoD) — это самый быстрый путь к предотвращению доработок. Расплывчатые ожидания ведут к бесконечным итерациям, а четкие критерии помогают избежать субъективности (и расширения области проекта). Добиться ясности на начальном этапе всегда более выгодно, чем вносить исправления на последующих.

• Повышение эффективности тестирования. Четко определенные критерии приемки фактически служат для отдела контроля качества готовым шаблоном для тестирования. Критерии удобно преобразуются в шаги для проверки, с помощью которых можно легко подтвердить, что функциональность соответствует ожиданиям, либо выявить несоответствия.

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

• Повышение удовлетворенности заинтересованных сторон. Когда функциональность стабильно соответствует ожидаемой, заинтересованные стороны доверяют процессу и продукту. Четкие критерии приемки позволяют задать реалистичные ожидания, свести к минимуму неоднозначность и создать продукт, который действительно отвечает потребностям пользователей.

Критерии приемки устраняют различия между концепцией продукта и его реализацией. Они превращают намерение в согласованность, согласованность — в действие, а действие — в надежный результат.

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

Как написать критерии приемки

Для успешной разработки программного обеспечения важно правильно составить критерии приемки. Вот несколько основных шагов и советов.

1. Начните с пользовательской истории

Сверяйтесь с пользовательской историей, к которой относятся критерии приемки. Это позволит связать критерии с желаемыми функциями.

2. Определите результаты

Сформулируйте критерии, касающиеся к взаимодействия с пользователем и ожидаемых результатов. Чем функция должна быть полезна для пользователя? Не заостряйте внимание на технических деталях реализации.

3. Позаботьтесь об общей тестируемости

Каждому критерию должен соответствовать четкий и поддающийся выполнению тест. Это поможет объективно оценить, соответствует ли функция требованиям.

4. Определите количественные показатели

По возможности выражайте критерии в количественно измеримом виде. Так можно легко и однозначно определить, пройден тест или нет.

5. Стремитесь к независимости

Старайтесь сформулировать независимые критерии, которые можно проверять по отдельности. Это упрощает тестирование и позволяет избежать зависимостей.

Рассмотрите возможность включения критериев приемочного тестирования пользователями (UAT) наряду с критериями команды разработчиков. По критериям UAT можно отследить, соответствует ли функция ожиданиям с точки зрения удобства использования.

6. Поощряйте совместную работу

Поощряйте сотрудничество в ходе формулирования критериев. Привлеките владельца продукта, разработчика (или команду разработчиков) и другие заинтересованные стороны, чтобы набор критериев отражал все точки зрения.

7. Пересматривайте и уточняйте

Не бойтесь пересматривать и уточнять критерии приемки на всем протяжении разработки. Корректируйте критерии по мере появления новой информации.

8. Формулируйте критерии четко и лаконично

Старайтесь использовать ясные, краткие и понятные каждому формулировки. Технический жаргон или обтекаемые фразы могут привести к путанице.

Кто должен описывать критерии приемки?

Написание критериев приемки в рабочих средах и рабочих процессах методологии Agile относится к совместной, а не индивидуальной работе. Вот краткое описание типичных ролей.

• Владелец продукта. Хорошо знает потребности клиентов и концепцию продукта, играет решающую роль в инициировании обсуждения и определении желаемой функциональности.

• Команда разработчиков. Благодаря своему техническому опыту вносит значительный вклад в оценку осуществимости и подтверждаемости критериев. Ее участники могут предложить подходящие способы формулирования критериев для четкой оценки.

• Scrum-мастер (если применимо). Руководит обсуждением в команде и дает высказаться каждому участнику. Он также может помочь составить критерии согласно передовым подходам.

Хотя владелец продукта может инициировать процесс, окончательные критерии необходимо формулировать коллективными усилиями, чтобы учесть точки зрения всех участников.

Такой совместный подход способствует общему пониманию и повышает вероятность поставки успешного продукта.

Примеры критериев приемки

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

Пример 1. Поиск продуктов

• Пользовательская история: как клиент, я хочу иметь возможность искать продукты по названию, чтобы быстро находить то, что меня интересует.

• Критерии приемки:

  • Система выдает все продукты, которые в точности соответствуют введенному ключевому слову.

  • Система выдает частичные совпадения, когда пользователь вводит не менее трех символов.

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

  • Для результатов поиска предусмотрена разбивка на страницы, при этом на одной странице отображается не более 20 результатов.

  • Если не найдено ни одного совпадения, система должна отображать сообщение «Ничего не найдено» и рекомендовать дальнейшие действия.

Пример 2. Изменение данных аккаунта

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

• Критерии приемки:

  • Пользователи могут перейти в раздел Edit Profile (Редактировать профиль) через настройки своего аккаунта.

  • Пользователи могут изменять свое имя, фамилию, адрес электронной почты и номер телефона.

  • Система проверяет обязательные поля и отображает ошибки, если информация указана неверно или отсутствует.

  • Нажатие кнопки Сохранить приводит к обновлению информации о пользователе в системе.

  • При успешном обновлении система выводит подтверждающее сообщение.

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

Пример 3. Отчетность по действиям пользователей

• Пользовательская история: как администратор, я хочу создавать отчеты о действиях пользователей, чтобы отслеживать их вовлеченность.

• Критерии приемки:

  • Дашбоард администратора содержит специальный раздел Reports (Отчеты).

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

  • Отчеты можно фильтровать по диапазону дат и типу пользователя.

  • Администраторы могут экспортировать отчеты как минимум в двух форматах, включая CSV и PDF.

  • Если создать отчет не удается, система отображает понятное сообщение об ошибке.

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

Составляйте четкие критерии приемки на централизованной платформе

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

Их можно легко разместить прямо в описании истории или в поле Acceptance Criteria (Критерии приемки). А инструменты Jira для форматирования, такие как маркированные списки и флажки, помогают командам отслеживать прогресс и четко оформлять требования.

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

Вместе все эти функции и инструменты помогают устранить неоднозначность и облегчить процесс разработки. Начните работу с ними уже сегодня.

Часто задаваемые вопросы о критериях приемки

В чем разница между критериями приемки и критериями готовности работы?

Для успеха проекта важны и критерии приемки, и критерии готовности работы (definition of done, DoD), но они служат разным целям. Критерии приемки описывают конкретные функции, которые должны быть реализованы в проекте, чтобы он удовлетворял пользовательским историям конечных потребителей.

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

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

Когда следует описывать критерии приемки?

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

Другой вариант — сделать это во время планирования спринта, когда команда совместно дорабатывает критерии приемки для пользовательских историй, связанных с предстоящим спринтом. Так критерии будут актуальны и отразят текущее понимание потребностей.

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

Какие проблемы возникают при написании критериев приемки?

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

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