×Закрыть

Превращаем пожелания заказчика в Acceptance Criteria: 3 практики

Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.

Меня зовут Анна Лаврова, сейчас я Agile Coach, живу и работаю в Брюсселе. До этого больше девяти лет управляла проектами в Дубае и в Украине, занималась проектным и программным менеджментом.

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

Думаю, что статья будет полезной для РМ’ов, бизнес-аналитиков и других специалистов, которые работают с заказчиками и создают требования.

Критерии приемки и завершенности: как не перепутать

Поскольку критерии приемки и определение «завершенности» применяют к пользовательским историям, давайте договоримся, что понимать под каждым термином:

  • Definition of Done — критерий завершенности, глобальный контрольный список требований для всех пользовательских историй. Критерии завершенности описывают процесс, как должно быть разработано. Команда создает Definition of Done для себя: это список договоренностей с Product Owners, бизнес-стороной либо между участниками команды.
  • Acceptance Criteria — критерий приемки, детали, необходимые для выполнения конкретной пользовательской истории, описание того, что должно быть выполнено. Acceptance Criteria составляют один-два человека, отдельно для каждой User Story.
  • User Story — тема для разговора о том, как удовлетворить потребности пользователя.

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:

  1. Сделать Scrum-презентацию.
  2. Сделать DevOps-презентацию.
  3. Сделать PMP-презентацию.

Критерии завершенности, общие для всех трех задач, могут быть такими:

  • страницы презентации пронумерованы;
  • тексты вычитаны редактором на предмет ошибок;
  • указана информация об авторских правах;
  • на каждой странице есть логотип компании;
  • по крайней мере в 30% каждой из презентаций есть визуальные образы;
  • презентация прошла «4 eyes principle», то есть ее посмотрели и одобрили два человека.

Acceptance Criteria

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

Критерии приемки всегда можно проверить по четкому параметру «да/нет». Нельзя выполнить какой-то критерий наполовину: он либо выполнен, либо нет. Благодаря Acceptance Criteria команда разработки знает, как должен выглядеть готовый результат конкретного требования.

В одном ряду с критериями приемки есть похожие, но не идентичные, термины от Хенрика Книберга «как продемонстрировать» (How to demo) или Майка Кона «условия удовлетворения ожиданий» (Conditions of Satisfaction).

В целом Acceptance Criteria должны соответствовать следующим характеристикам:

  • Бинарные: могут иметь только два уникальных результата — успех или отказ. Не может быть термина «частичный успех», потому что критерий приемки всегда должен давать «зеленый» или «красный».
  • Однозначные: их можно интерпретировать только одним способом. Неправильно прописывать: «Форма окрашена в яркий цвет» или «Система должна быть user friendly», ведь такие критерии можно интерпретировать по-разному.
  • Подтверждаемые: должны быть написаны так, чтобы клиент мог быстро их проверить.
  • Полные: список критериев должен включать все функциональные требования. Все, что нужно сделать по каждому требованию, описывают в критериях приемки.

Примеры требований и Acceptance Criteria к ним:

1. Требование — разрешить пользователю загружать файл с картинкой. Критерии приемки:

  • доступны определенные форматы файлов, например, jpeg, png, gif;
  • после загрузки появляется сообщение, что файл успешно загрузился.

2. Требование — разрешить пользователю менять пароль. Критерии приемки:

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

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

Практика «три С»: Card, Conversation, Confirmation

Давайте вспомним полезную для хороших пользовательских историй практику «трех С», которая помогает:

  • структурировать важную информацию и ничего не упустить, когда пишете требования к историям;
  • договориться о том, что считать требованиями, а что — критериями приемки для них.

Три компонента для работы с User Story: записать, обсудить, подтвердить

Методика состоит из трех компонентов:

  1. Card — любое требование фиксируется. Важно не только сказать о том, что нужно сделать, но и записать историю для выполнения. Традиционно история записывается (например, на стикере), используется для планирования и служит напоминанием.
  2. Conversation — требования нужно обсуждать. В Scrum их обсуждают во время refinement в каждом спринте. Если человек создал требования, записал их, презентовал команде и «ушел» — это не будет conversation, более того, это не тот самый Scrum. Для conversation нужно еще проговорить детали истории и создать критерии приемки.
  3. Confirmation — должны быть конкретные критерии приемки для требования, ответ на вопрос: как разработчики поймут, что история закончена и требование «завершено»?

Как выглядит работа с конкретной 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 (тогда) — теперь ситуация выглядит по-другому: система реагирует на пользовательские действия.

Как формулируется критерий приемки по этому шаблону:

Дано: у меня есть деньги на счету в банке.

Когда я пытаюсь снять деньги со счета, и сумма не превышает лимит.

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

Обратите внимание, формат Given-When-Then тоже бинарный: либо «да», либо «нет». В примере выше система должна позволить снять деньги без сообщений об ошибке. Если деньги сняты, но система показала сообщение об ошибке, это не значит, что требование выполнено на 90%. Это значит, что оно не выполнено.

Вот еще пример.

Функционал: пользователь торгует акциями.

Сценарий: пользователь запрашивает продажу до закрытия торгов.

Дано:

  • 100 акций MSFT;
  • 150 акций AAPL;
  • время до закрытия торгов.

Когда я прошу продать 20 акций MSFT.

Тогда:

  • должно быть 80 акций MSFT;
  • должно быть 150 акций AAPL;
  • ордер на продажу 20 акций MSFT должен быть исполнен.

Как выглядит создание критериев приемки для отдельной User Story:

User Story: как пользователь веб-сайта я хочу оставлять отзывы, чтобы владельцы могли учитывать моё мнение или озабоченность в ходе будущих обновлений платформы.

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

Дано: я открываю страницу обратной связи, и система показывает мне форму отправки отзыва с обязательными полями: Email, Name и Comment.

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

Тогда система отправляет мой отзыв, показывает флэш-сообщение: «Вы успешно отправили свой отзыв», и очищает поля формы «Отправить отзыв».

Шаблон Given-When-Then не создается в одиночестве PM’ом или Product Owner’ом. Этот формат прописывается на командной встрече, которая называется «Три амигос».

Работа с требованиями на встрече «Три амигос»

Agile-практика «Три амигос» помогает донести голос команды до клиента и прийти к общему пониманию требований.

Цели встречи:

  • максимально обсудить требования;
  • минимально потратить ресурсов;
  • максимально быстро решить, как будут выглядеть критерии приемки.

Результат встречи — это договоренность о том, что будем разрабатывать, и написанные критерии приемки, которые можно автоматизировать, те самые Given-When-Then.

На встречу собираются представители трех ролей:

  • тот, кто описывает требования (ВА или Product Owner);
  • кто будет разрабатывать;
  • кто будет тестировать то, что описано в требованиях.

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

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

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

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

Как проходит встреча «Три амигос»

Встреча длится от 30 минут до часа. Участники собираются за 1-2 спринта до того, как функция должна быть в разработке, и рассматривают требования на будущее.

На встречу приглашают людей, которые будут разрабатывать и тестировать обсуждаемую функцию: один разработчик и один QA.Человек, написавший требование (BA или Product Owner), начинает собрание с представления того, что должно быть сделано: отвечает на вопрос, зачем нужна функция, как будет выглядеть, кто ею будет пользоваться. Есть высокоуровневый requirement, а дальше вы его детализируете: задаете вопросы и формируете критерии приемки, актуальные для этого конкретного требования. Бизнес-аналитик представляет требования, подготовленные заранее, а другие участники дают обратную связь. Требования обновляются на сессии до тех пор, пока не будут признаны «готовыми к разработке». Затем БА представляет тестовые сценарии, подготовленные до собрания, и они также рассматриваются другими «амигос».

Что может пойти не так:

  • Часто будет казаться, что голос команды ограничен только тремя мнениями. Чтобы такого не произошло, создавайте рабочие группы (других «амигос») для разных требований. Тогда на встречи каждый раз будут ходить новые три человека, в зависимости от обсуждаемой темы.
  • Цель встречи «Три амигос» — услышать каждую точку зрения, собирая при этом как можно меньше участников.
  • Если «три амигос» тратят на обсуждение слишком много времени, есть риск, что команда будет воспринимать встречу как не особо полезную церемонию. Не рассматривайте одну историю целый час. Собирайте объем работ, который можно обсуждать один раз в спринт в процессе refinement для следующего спринта.

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

Что еще почитать

Все техники, о которых шла речь в статье, необходимы, чтобы составить качественные требования к пользовательским историям:

  • Практика «три С» — быстрый способ договориться о критериях приемки.
  • Формат Given-When-Then — хороший шаблон для автоматизации приемочных тестов.
  • Встреча «Три амигос» — возможность обсудить требования с минимальной тратой ресурсов.

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

LinkedIn

19 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Дякую за статтю
П.С. мабуть зза власної профдеформації приклади не англійською мовою вже важко сприймати.

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

Для работы с требованиями и критериями приемки подойдет Jira или любая другая система управления задачами. Для отслеживания изменений требований более уместно использовать отдельные документы — реестры изменений, например в банальном Google Spreadsheet или Excel. Требования имеет смысл группировать по эпикам, чтобы или было легче управлять.

Спасибо за статью.
Интересно было бы послушать тех, кто пишет AC в формате Given-When-Then, в чем ценность кроме как автоматизация тестов? Если мы говорим про Conversation, то для обсуждения, требования в таком формате тяжелее понять и разработчикам и бизнесу при согласовании АС например.
Про Gherkin понравилась в свое время статья habr.com/ru/post/275013

Объявленная ценность (все читают тесты и могут их править на лету) работает в 1% случаев. Если есть аналитики, если они это умеют, если им удобно, если все вовлечены, тогда взлетит.

Я еще ни разу не попадал в такие рабочие группы.

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

Программисты живут в своих иде, ваяют кодЪ строго по акксептанс-сценариям из сториз, и тоже не любят ВНЕЗАПНЫЕ упдатесы. Оно и понятно. Аппликуха внутри так усложнилась, что кукуха закукухает, если поверить в то, что какие-то аппрувнутые сториз неадекватны.

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

Авторкини статьи врут о том, что

формат Given-When-Then тоже бинарный: либо «да», либо «нет».

Ыхы, бинарно-винрарно оно ДОЛЖНО БЫТЬ... посмотрели бы вы эту лапшу из трех и более непоследовательных блоков иф вен твен, снабженные изрядным перечнем And, And, And, And, And, которую пишут взрослые, вроде бы, аналитики с аналитическим складом теплой рисовой водки. В быту одним геркин-сценарием описывают целые эндТуЭнд ворк, извиняюсь, флоу, в которых Юзер Царевич на сером волке идет туда, он изначально знает куда, а придет туда, он понятия не имеет куда в зависимости от ряда условностей, которые зависят от перечня условностей, которые... Местами вспоминается родной и послушный GOTO в бейсике.

Но тесты придумывать вот это вот всë не мешает. Затрудняет, но не мешает.

Работал на похожем проекте )

Даже Agile Coach не верит в аджайл и хочет все зафиксировать, иметь хорошие требования и критерии приемки и ожидаемое поведение системы в тестируемых случаях :)

А как же:
1) Работающий продукт важнее исчерпывающей документации
2) Сотрудничество с заказчиком важнее согласования условий контракта
3) Готовность к изменениям важнее следования первоначальному плану

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

Хотя то что Вы написали мне очень нравиться, но очень редко где делаться ибо «У нас Аджайл и сами подумайте за бизнес как нужно правильно сделать» :)

Как пересекается критерии приёмки и аджайл? Это разные сущности не исключающие одна другой.

но очень редко где делаться

Делается ровно там, где это нужно. Очень часто это делается в аутсорсе по понятным причинам.

«У нас Аджайл и сами подумайте за бизнес как нужно правильно сделать»

А бизнес и не должен думать как это нужно правильно сделать. Есть роль продакт менеджера или бизнес аналитика, и так далее

Есть роль продакт менеджера или бизнес аналитика, и так далее

Половина программистов думают, что они разбираются в бизнесе клиента лучше всех этих бизнес-аналитиков. Эффект Даннинга-Крюгера

начал читать комментарий, подумал: «хм, qa?». Поднял глаза — действительно)

«У нас Аджайл и сами подумайте за бизнес как нужно правильно сделать» :)

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

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

В таком случае, нанятому менеджеру лучше ответить:"Я не имею экспертизы в этом вопросе, т.к. я — технический специалист«.
У меня так не происходило ни разу за 8 лет.
Почему?
Потому что на любом собеседовании с представителем клиента я всегда прошу его описать организацию процесса разработки.
Если в ответе я слышу такие слова, как «скрам», «юзер стори», «плэннинг», «бэклог», значит, имею дело с профессионалом, а не дилетантом. И в дальнейшей работе любую хотелку я вполне резонно могу попросить оформить в юзер стори и положить в бэклог, не забыв все уточнения указать в акксептанс критериях. В такой парадигме попытка спросить меня «как будет лучше для бизнеса», вызовет недоумённый взгляд:"ну, вы же и есть бизнес, вам виднее".
Просто не работайте с аматорами, только и всего.

Работающий продукт важнее исчерпывающей документации

Продукт, который работает, но не документирован — мёртв. Завтра там нужно будет что-то поменять, а документации, которая проливает свет на то, что и как работает — нет. И непонятно, что фича, а что баг. На этом продукт в принципе можно закрывать.

Сотрудничество с заказчиком важнее согласования условий контракта

Если сотрудничество с заказчиком вместо прибыли будет приносить убытки из-за несогласованных условий контракта, то в чём его важность?

Готовность к изменениям важнее следования первоначальному плану

Неспособность строить и воплощать средне- и долгосрочные планы ставит крест на любых перспективах выживания бизнеса клиента.

Простота — искусство минимизации лишней работы — крайне необходима.

Лишняя работа — это работа, не предусмотренная первоначальным планом.

:)
Судя по тому как Вы прошлись по всем основным принципам аджайл манифеста Вы тоже не верите в аджайл.
Ну вот:
девелопер — не верит в аджайл,
куа — не верит в аджайл,
аджайл коуч — тоже не очень верит в аджайл
кто же тогда верит в аджайл
ок тогда ждем еще ПМ :)

Я верю в скрам.
И хотя скрам — разновидность аджайла, но на практике он работает примерно так:
— Если стори соответствует АС — она закрывается.
— Любое требование к продукту, на которое нет Юзер Стори — не существует. Если оно выявлено — это баг.
— Процесс важнее результата. Потому что результат без процесса, как и процесс без результата — временная случайность, которую не стоит учитывать. Исключение из этого правила — только во время финального релиза. Но там уже методологии не работают.

Хорошая, полезная статья

Подписаться на комментарии