Что такое acceptance criteria
Критерии Приемки (Acceptance Criteria)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в Стори Поинтах по дням спринта. Это графическое представление того, сколько работы уже сделано и сколько еще остается сделать. Диаграмма позволяет Команде прогнозировать успех Спринта и предпринимать меры, чтобы к моменту окончанию Спринта все запланированные задачи были были завершены.
Описание того, что нужно сделать, чтобы работа над Инкрементом и реализованными в нем Элементами Бэклога Продукта считалась завершенной. Эта информация помогает команде оценивать, проверять и доводить работу над Инкрементом до конца. Определение Критериев Готовности звучит похоже на Критерии Приемки, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов и Инкрементов в целом.
Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.
Оценка (Estimation)
Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.
Величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Является важной метрикой в Скраме. Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Превращаем пожелания заказчика в Acceptance Criteria: 3 практики
Меня зовут Анна Лаврова, сейчас я Agile Coach, живу и работаю в Брюсселе. До этого больше девяти лет управляла проектами в Дубае и в Украине, занималась проектным и программным менеджментом.
В статье расскажу, как превратить пожелания заказчика в критерии приемки готового продукта. На конкретных примерах объясню, чем отличаются понятия Definition of Done и Acceptance Criteria, поделюсь техниками работы с требованиями для пользовательских историй.
Думаю, что статья будет полезной для РМ’ов, бизнес-аналитиков и других специалистов, которые работают с заказчиками и создают требования.
Критерии приемки и завершенности: как не перепутать
Поскольку критерии приемки и определение «завершенности» применяют к пользовательским историям, давайте договоримся, что понимать под каждым термином:
Acceptance Criteria прописываются отдельно для каждой User Story, а Definition of Done — общие требования для всех User Stories проекта
Definition of Done
Критерий завершенности — список требований, которым должна соответствовать любая пользовательская история, чтобы команда назвала ее завершенной. Список атрибутов завершенности применяется абсолютно ко всем историям или ко всем элементам бэклога.
Definition of Done — это договоренность о том, как команда будет работать в процессе. Один из элементов scrum set up — это командное соглашение (team working agreements) о критериях завершенности и создание estimation baselines.
Например, обычный критерий завершенности для команд разработки — у каждой конкретной задачи есть шаг code review. Может быть и такой критерий, что у изменения нет известных дефектов — все, что нашли, уже закрыли и починили. В такие договоренности включается и бизнес-сторона: заказчик или Product Owner. Definition of Done — это четкие критерии, по которым мы договариваемся работать и создавать качественный продукт каждую итерацию.
Посмотрим, как будут выглядеть критерии завершенности для трех work items:
Критерии завершенности, общие для всех трех задач, могут быть такими:
Acceptance Criteria
Если пользовательскую историю создают как некую формулировку намерения, чтобы команда была свободна в поиске решения, то критерии приемки — это точные детали, уникальные для каждой User Story, набор условий, подтверждающий, что она реализована.
Критерии приемки всегда можно проверить по четкому параметру «да/нет». Нельзя выполнить какой-то критерий наполовину: он либо выполнен, либо нет. Благодаря Acceptance Criteria команда разработки знает, как должен выглядеть готовый результат конкретного требования.
В одном ряду с критериями приемки есть похожие, но не идентичные, термины от Хенрика Книберга «как продемонстрировать» (How to demo) или Майка Кона «условия удовлетворения ожиданий» (Conditions of Satisfaction).
В целом Acceptance Criteria должны соответствовать следующим характеристикам:
Примеры требований и Acceptance Criteria к ним:
1. Требование — разрешить пользователю загружать файл с картинкой. Критерии приемки:
2. Требование — разрешить пользователю менять пароль. Критерии приемки:
Перечисленные атрибуты должны быть выполнены для конкретных требований, они не описывают весь процесс.
Практика «три С»: Card, Conversation, Confirmation
Давайте вспомним полезную для хороших пользовательских историй практику «трех С», которая помогает:
Три компонента для работы с User Story: записать, обсудить, подтвердить
Методика состоит из трех компонентов:
Как выглядит работа с конкретной User Story: «Как пользователь мобильного телефона я хочу проверять прогноз для своего актуального местоположения, чтобы мне не приходилось искать его каждый раз, когда я еду в новое место».
Card: актуальное местоположение для прогноза погоды.
Conversation: команда обсуждает с PO или ВА, кто будет использовать продукт, зачем это нужно людям и какая в этом ценность для бизнеса. Создают примеры использования (техника Example Mapping).
Confirmation: прописываются критерии приемки и варианты non happy flow к этой истории, например:
Given-When-Then: переводим с языка заказчика на язык критериев приемки
Given-When-Then — это стиль представления тестов или, как сказали бы его сторонники, — определение поведения системы с помощью Specification By Example. Это подход, разработанный Дэниелом Терхорст-Нортом и Крисом Мэттсом в рамках программы Behavior-Driven Development (BDD).
Given-When-Then выглядит как структурный подход для многих сред тестирования, таких как Cucumber (чтобы быть точным, он использует Gherkin, что является названием DSL от Cucumber). Шаблон Given-When-Then позволяет автоматизировать тест для определения, разработано требование или нет.
Можно описывать Acceptance Criteria пунктами или сразу в формате Given-When-Then:
Как формулируется критерий приемки по этому шаблону:
Дано: у меня есть деньги на счету в банке.
Когда я пытаюсь снять деньги со счета, и сумма не превышает лимит.
Тогда система позволяет мне это сделать и не показывает никаких сообщений об ошибке.
Обратите внимание, формат Given-When-Then тоже бинарный: либо «да», либо «нет». В примере выше система должна позволить снять деньги без сообщений об ошибке. Если деньги сняты, но система показала сообщение об ошибке, это не значит, что требование выполнено на 90%. Это значит, что оно не выполнено.
Функционал: пользователь торгует акциями.
Сценарий: пользователь запрашивает продажу до закрытия торгов.
Дано:
Когда я прошу продать 20 акций MSFT.
Тогда:
Как выглядит создание критериев приемки для отдельной User Story:
User Story: как пользователь веб-сайта я хочу оставлять отзывы, чтобы владельцы могли учитывать моё мнение или озабоченность в ходе будущих обновлений платформы.
Сценарий: пользователь отправляет форму обратной связи с действительными данными (prerequisite). Учитывать, в какой роли находится человек: авторизованного или гостевого пользователя.
Дано: я открываю страницу обратной связи, и система показывает мне форму отправки отзыва с обязательными полями: Email, Name и Comment.
Когда я вписываю в поле Email действительный адрес электронной почты и заполняю Name своим именем, а в поле Comment пишу комментарий и нажимаю кнопку «Отправить отзыв».
Тогда система отправляет мой отзыв, показывает флэш-сообщение: «Вы успешно отправили свой отзыв», и очищает поля формы «Отправить отзыв».
Шаблон Given-When-Then не создается в одиночестве PM’ом или Product Owner’ом. Этот формат прописывается на командной встрече, которая называется «Три амигос».
Работа с требованиями на встрече «Три амигос»
Agile-практика «Три амигос» помогает донести голос команды до клиента и прийти к общему пониманию требований.
Результат встречи — это договоренность о том, что будем разрабатывать, и написанные критерии приемки, которые можно автоматизировать, те самые Given-When-Then.
На встречу собираются представители трех ролей:
Три участника представляют голос всей команды, потому что могут рассмотреть каждое требование с разных сторон и убедиться, что все вопросы и пограничные случаи будут обработаны.
Обмениваясь различными точками зрения на проект, участники встречи могут обсудить требования в режиме реального времени:
На встрече «Три амигос» специалисты обсуждают требования, которые еще недостаточно детализированы и не имеют критериев приемки. Требования, уже прошедшие валидацию и верификацию, не обговариваются.
Как проходит встреча «Три амигос»
Встреча длится от 30 минут до часа. Участники собираются за спринта до того, как функция должна быть в разработке, и рассматривают требования на будущее.
На встречу приглашают людей, которые будут разрабатывать и тестировать обсуждаемую функцию: один разработчик и один QA.Человек, написавший требование (BA или Product Owner), начинает собрание с представления того, что должно быть сделано: отвечает на вопрос, зачем нужна функция, как будет выглядеть, кто ею будет пользоваться. Есть высокоуровневый requirement, а дальше вы его детализируете: задаете вопросы и формируете критерии приемки, актуальные для этого конкретного требования. Бизнес-аналитик представляет требования, подготовленные заранее, а другие участники дают обратную связь. Требования обновляются на сессии до тех пор, пока не будут признаны «готовыми к разработке». Затем БА представляет тестовые сценарии, подготовленные до собрания, и они также рассматриваются другими «амигос».
Что может пойти не так:
Технику можно использовать и вне Agile-процесса. Практика обсуждений в формате трех ролей будет полезна в любом проекте, потому что везде есть разработчики и тестировщики, которые дальше будут внедрять и проверять созданные требования.
Что еще почитать
Все техники, о которых шла речь в статье, необходимы, чтобы составить качественные требования к пользовательским историям:
Четко прописанные критерии приемки и завершенности помогают создавать качественный продукт, подтверждают для команды и заказчика, что конкретная история реализована.
Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно. І підписуйтеся на Telegram-канал редакції DOU
Гайд по User Stories для Junior BA / PO / PM
Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчерпнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.
Содержание:
Вводная информация о User Stories
Что такое User Stories
Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.
Дать емкое определение этому приёму сложно. Его внешняя простота заставляет сводить его описание к внешним характеристикам. Поэтому я, как автор, хотел бы дать читателю несколько определений.
В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».
Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта.
Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:
Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!
Пройдя круг обсуждений с ментором, прочитав и посмотрев много статей и видео, я понял, что главное в пользовательской истории — это ценность, которую пользователь получит от функции. Поэтому я попытался сгенерировать определение:
Очень важно отметить, что история и ее ценность может быть направлена не только на какую-то группу пользователей. Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код. ), Product Owner или представителей бизнеса.
Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.
Так, истории пишутся в три строки:
Job Stories
В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.
Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
«Тело» JS делится на три части:
Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.
Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции.
Expected Outcome: описывает, что получит юзер после использования функции.
Job Stories могут писаться по двум форматам:
В одну строку:
When X I want to Y so I can Z» или «When X, actor is Y so that Z.
В три строки:
When X
I want to Y
So I can Z.
When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
Вопросы, которые следует задавать во время написания стори
Решает ли это настоящую проблему юзера?
Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?
Какие последствия от такого решения?
А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».
Пример работы техники «5 почему».
Три С в User Story
Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».
Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.
Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.
Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.
User Personas
Этот метод представляет собой детализированное описание пользователя продукта. Описание пользователя должно быть конкретным и детальным, ведь по его описанию члены команды должны понять, что это целевая аудитория приложения, которое они делают.
Создавая четкого и детального персонажа, аналитик требований или Product Owner уменьшает вероятность того, что нужды пользователя будут забыты или заменены на нужды тех членов проектной команды, которые ставят себя на место пользователей.
Карточка персонажа не обязана быть полностью правильной, но она обязана содержать максимальное количество деталей.
Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:
Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.
Стоит также отразить маркетинговые характеристики персонажа такие как предпочитаемые бренды, блюда, увлечения и хобби. Эти характеристики важны не только, чтобы знать для кого мы создаем ПО, но и как его рекламировать и продавать. Описание должно также раскрывать и характер персонажа. Он веселый или чаще хмурится? Он делится информацией в соцсетях или вовсе не ведет их?
В описании следует отразить и задачи, которые наиболее важны для персонажа в его работе с системой. Это поможет всей команде увидеть нужды персонажа и поможет создать стимул для покупки премиум-версии или подписки.
Не стоит забывать и об еще одной важной детали. Персонажи не могут «гулять» из продукта в продукт, но человек, который создаёт их описание, может обращаться к давно созданным образам как за вдохновением, так и за шаблоном описания.
Создав одного персонажа, можно отдохнуть и насладиться проделанной работой. Однако не стоит останавливаться, так как именно набор персонажей (от 3 до 10) поможет в будущем выстроить систему, которая поможет приоритизировать истории, благодаря пониманию того, что нужно тому или другому персонажу. А если что-то нужно двум из трех персонажей, то следует бросить все силы на эту функцию.
Что же в сухой практике использования User Personas?
Отрицательный персонаж
Не все персонажи должны создаваться, чтобы показать пользователей системы. Задача некоторых указать, кому в приложении нет места.
Создавая любое приложение для такси, мы вспомним, что в процессе заказа традиционно есть 3 участника: клиент, водитель, оператор. Скорее всего, задачей нашего приложения будет автоматизация работы оператора так, чтобы клиент мог связаться с водителем напрямую. В таком случае самому оператору в системе не будет места.
Ключевой персонаж
Ключевыми персонажами являются те, для кого и будет проводиться проектирование решения. Такой персонаж олицетворяет группу пользователей, которая будет либо чаще всего пользоваться приложением, либо имеет какие-то особенности, из-за которых им следует пользоваться приложением иначе. Такие персонажи заслуживают отдельных интерфейсов в системе.
Давайте вернемся к приложению для саппорта. В нем оба персонажа, которые всё-таки будут пользоваться системой, будут ключевыми. Так, тому, кто будет устранять жалобы, нужен интерфейс, который показывает жалобы и помогает выстроить маршрут. В тоже время клиенту, скорее всего, нужно посмотреть все его жалобы и оставить новую.
INVEST
По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.
I — Independent — Независимый
Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).
На практике это стремление не всегда достижимо. Например, в случае зависимости нескольких историй друг от друга, следует искать другой способ разбить их.
Мы хотим добавить в наш продукт поддержку банковских карт MasterCard, Visa и третьей системы. Тогда проще всего разделить эту стори на три. В первой, самой большой, разработчик должен добавить поддержку банковских карт в целом и какую-то из списка. А остальные две могут пойти в другую стори, которая зависит от первой.
N — Negotiable — Обсуждаемый
После написания черновика истории следует обсудить ее со стейкхолдерами и, возможно, внести изменения, исправить ошибки. В ходе обсуждения команда ещё не говорит о том, как данная история будет реализована, а обсуждается лишь то, как будет удовлетворяться нужда пользователя.
V — Valuable — Ценный
Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.
Если ценность историй, которые несут новый функционал или улучшают старый, очевидна, то с теми, которые завязаны на технической стороне продукта, не все так очевидно. Но и истории, в рамках которой команда избавляется от легаси-кода, делает рефакторинг или переносит старый функционал на новую инфраструктуру (например, в новую базу данных) несут ценность для как для продукта, так и для пользователя. Скорее всего, пользователь ощутит их благодаря улучшению отзывчивости или скорости работы системы. Это следует отразить в описании такой задачи.
E — Estimable — Оцениваемый
История должна быть настолько ясно написана, чтобы у разработчика было достаточно понимания ведь без него он сможет выдать оценку, близкую к правде. Есть три причины, почему dev не может выдать оценку:
история слишком большая;
в описании недостаточно данных;
разработчику нужно больше опыта.
Однако подробнее об оценках поговорим в отделе “Оценка историй”.
S — Small — Компактный
Этот пункт говорит не о самом описании под историей, а о ее размере, времени на реализацию. На многих проектах команды устанавливают рамки, в которые должна уместиться история. Так, часто можно услышать о правиле, согласно которому история должна укладываться в рабочий день. Однако на других же пользовательской историей может считаться функция, на реализацию которой нужно несколько месяцев времени разработчика.
T — Testable — Тестируемый
Суть этого пункта не только в том, что команда тестировщиков должна понимать, что проверять, но и в том, что пользовательская история должна обладать чем-то, что можно посмотреть, запустить.
Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.
Как добавить деталей к истории?
Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.
Acceptance Criteria
Что такое АС
Элемент User Stories, который дополняет их так, что команда начинает видеть историю в деталях. Этот инструмент помогает понять, что должно быть сделано, чтобы удовлетворить потребность бизнеса.
АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться.
Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.
Для чего нужны
Показывают фичу с точки зрения конечного юзера.
Для понимания задач бизнеса.
Достижения консенсуса с бизнесом относительно какой-то стори.
Служат базой для тестов.
Помогают эстимировать стори.
Правила написания
Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими «способностями» обладает юзер или система).
Должны быть измеримы.
Пишутся ДО работы над задачей.
Включают функциональные и нефункциональные критерии.
Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.
Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).
Не содержат технического арго.
Что делать, когда надо выбрать одно из нескольких решений?
Тогда на помощь приходит Evaluation Criteria. Используются, чтобы оценить ценность нескольких решений и выбрать нужное.
Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:
1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.
Gherkin
Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see «Your article was published»
Базовый синтаксис Gherkin
1) Пишется сценарий-скелет.
Scenario Outline: Dr Bill posts to his own blog.
Given I Have published
When I try to post a new blog
Then I should see
2) Создается таблица с примерами.
В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например: