что такое критерии приемки

Критерии Приемки (Acceptance Criteria)

Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.

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

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

Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.

Оценка (Estimation)

Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.

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

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

Источник

Программист, менеджер, MVC и критерии приемки

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

О том кто же является контроллером, а кто моделью под катом.

В этой статье предполагается, что читатель знает, что такое MVC.

При построении модели я иду на умышленные упрощения.

Действующие лица

Заказчик — лицо, которое заказывает продукт или проект. Может быть как внешним, так и внутренним.

Компания (исполнитель) — сторона договорных отношений с Заказчиком.

Менеджер — лицо, которое взаимодействует с Заказчиком и конечным исполнителем (программистом). Принимает на вход задачи от Заказчика, транслирует эти задачи Исполнителю и возвращает Заказчику результат.

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

Процесс

Процесс заказной разработки выглядит примерно так:

Самым сладким пунктом для Компании является пункт 9. Но путь до него обычно долго и тернист.

Проблема такого процесса

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

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

Менеджер ставит программисту задачу проговаривая ее голосом или в чатике. Уточнения по задаче нигде не фиксируются. Программист постановку задаче вроде бы понял. Но разумеется понял по своему, а не так как объяснял менеджер (с точки зрения менеджера). Так как постановка задачи не зафиксирована, то каждый из участников трактует ее по своему.

При таком подходе появляется много итераций 4-6 и 3-8. Хорошего менеджера от плохого отличает соотношение между числом этих итераций. У хорошего менеджера число попыток сдать задачу заказчику равно единице. И попытка, как вы догадались, сразу удачная. При этом итераций по сдаче работ с программистом может быть много. Маршрутизатор не перепроверяет ничего за программистом и просто передает задачу Заказчику. И число итераций 3-8 достигает максимальных значений и равно числу итераций 4-6. И разумеется во всем виноват программист, ведь с точки зрения менеджера он плохо выполнил задачу.

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

Что же делать, чтобы избежать такие нежелательные явления?

Ассоциации

Давайте посмотрим на упрощенную схему работы с Заказчиком:

Опытный разработчик увидит полное совпадение с MVC:

Очень просто провести сопоставление сущностей.

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

Первые шаги в починке

Какие инструменты у нас есть когда мы занимаемся разработкой?

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

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

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

Декомпозиция

Большие задачи нужно разделять на маленькие. Маленькая задача — это задача максимум на пару дней.

Всем известно выражение: Без внятного ТЗ — результат ХЗ.

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

В любой нормальной компании ТЗ является обязательным элементом к задаче. Правда это касается только крупных задач.

Казалось бы что ТЗ вполне похоже на контракт в контексте программирования. Какие я вижу проблемы с ТЗ:

Тут видно, что ТЗ явно недостаточно. Возникает вопрос что же делать?

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

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

Можем ли мы применять тесты и в нашей практике? Да мы и так все тестируем и даже в описании процесса это есть, скажет внимательный читатель. Да, но нет. Я говорю немного о другом тестировании.

Тестирование в описанном выше процессе заключается в ручной проверке соответствия результата поставленному ТЗ. Каждый участник такого тестирования, ознакомившись с ТЗ, как-то его интерпретирует в собственную картину. Проблема в том, что у всех получается разная картина. Человек неидеальный интерпретатор. Нужно скомпилировать ТЗ в бинарник один раз. Не интерпретировать много раз и по-разному. А один раз и на “бумагу”. В результате должен появится некий набор артефактов. Это могут быть тест-кейсы или критерии приемки.

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

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

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

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

Возражения

Предвижу вопрос от менеджеров:

Разработка критериев приемки занимает дополнительное время. Где же его взять?

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

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

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

Смею вас заверить, что разработка критериев приемки окупается сторицей.

Результат

Как изменяется процесс после внедрения критериев приемки наравне с ТЗ?

Программист делает свою работу в соответствии с критериями приемки. Менеджер принимает работу. Затем то же самое делает и Заказчик. И у него нет повода не оплатить эту задачу.

Всегда ли это будет работать совсем без сбоев? Полагаю, что нет. Сначала будут проблемы с выработкой, формулировкой критериев приемки и их согласование с Заказчиком. И это будет причиной повторения итераций с Программистом и Заказчиком. Но их количество сведено до минимума.

Источник

Критерии Готовности и Критерии Приёмки в Скраме: в чём разница

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

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

Критерии Приёмки

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

У нас есть инновационная пиццерия «У Сергея». Её главная фишка — пицца необычных вкусов. Чтобы предприятие было успешным, пиццерия работает по Скраму. В текущем Спринте Команда «У Сергея» придумывает рыбную пиццу.

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

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

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

Важный момент: даже если Продукт соответствует Критериям Приёмки, то ещё не значит, что он сделан качественно. Та же рыбная пицца может быть с кусочками судака, но пережаренной. Чтобы Продуктом можно было пользоваться, он должен соответствовать Критериям Готовности.

Критерии Готовности

Критерии Готовности — это договорённость внутри Команды, когда считать Продукт готовым. Выглядит как список того, что нужно сделать, чтобы Продукт работал. На языке Скрам-мастеров это звучит так: «Критерии Готовности обеспечивают прозрачность Инкремента».

Вот как выглядят Критерии Готовности для рыбной пиццы «У Сергея»:
— делаем пиццу чистыми руками — для этого пиццамейкеры моют руки каждый час;
— пиццамейкеры работают в шапочках, чтобы не было волос в пицце;
— пиццу выпекают 12 минут;
— начинка для пиццы нарезана в день готовки;
— Критерии Приёмки для рыбной пиццы: в начинке есть кусочки судака, нет анчоусов и рыбного соуса;
— клиенту доставляют теплую пиццу.

В зависимости от вида пиццы меняются только Критерии Приёмки. Рыбную и любую другую пиццу делают чистыми руками, в шапочках, выпекают ровно 12 минут и так далее.

Детали

В табличку не влезло, но мы всё равно напишем, что постоянно Критерии Готовности применяют на Планировании Спринта, во время Спринта, перед Обзором Спринта и на Ретроспективе Спринта.

На Планировании Спринта — чтобы понять, сколько задач Команда сможет сделать за Спринт. Во время Спринта — чтобы понять, что задача готова. Перед Обзором Спринта — чтобы знать, что на нём показывать, когда Команда сделала не всё, что обещала. И на Ретроспективе Спринта — чтобы постоянно совершенствовать Критерии Готовности. Например, ужесточить их, то есть добавить ещё пункты в список, или ослабить, если Команда не может их выполнить за Спринт.

Критерии Готовности и Критерии Приёмки — важная часть Скрама. Они помогают Команде держать планку качества и создавать именно то, что нужно заказчикам.

Катя Кондратьева Редактор Unusual Concepts

Источник

критерии приемки

3.1.1 критерии приемки (acceptance criteria): Установленные границы характеристик, определяющих область приемлемости процесса или продукции.

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

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

Смотри также родственные термины:

3.1.5 критерии приемки проекта (design acceptance criteria): Границы характеристик материалов, продукции или услуг, установленные организацией, потребителем, и/или техническими требованиями для достижения соответствия продукции требованиям проекта.

Полезное

Смотреть что такое «критерии приемки» в других словарях:

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

критерии приемки проекта — 3.1.5 критерии приемки проекта (design acceptance criteria): Границы характеристик материалов, продукции или услуг, установленные организацией, потребителем, и/или техническими требованиями для достижения соответствия продукции требованиям… … Словарь-справочник терминов нормативно-технической документации

производственные критерии приемки — 3.1.8 производственные критерии приемки (manufacturing acceptance criteria): Границы характеристик материалов, продукции или услуг, установленные организацией для проверки соответствия требованиям производства или обслуживания. Источник … Словарь-справочник терминов нормативно-технической документации

Критерии — 24. Критерии безопасности гидротехнических сооружений как основы контроля их состояния / А.И. Царев, И.Н.Иващенко, В.В. Малаханов, И.Ф.Блинов //Гидротехническое строительство, 1994. №1, С.9 14. Источник … Словарь-справочник терминов нормативно-технической документации

критерии приемлемости — (acceptance criteria): Числовые предельные значения, диапазоны или другие критерии, применяемые для приемки результатов испытаний. Источник: ГОСТ Р 52249 2009: Правила производства и контроля качества лекарственных средств … Словарь-справочник терминов нормативно-технической документации

Критерии приемлемости результатов испытаний — Критерии приемлемости (acceptance criteria): числовые предельные значения, диапазоны или другие критерии, применяемые для приемки результатов испытаний. Источник: ПРАВИЛА ПРОИЗВОДСТВА И КОНТРОЛЯ КАЧЕСТВА ЛЕКАРСТВЕННЫХ СРЕДСТВ. ГОСТ Р 52249 2009 … Официальная терминология

ГОСТ Р 53711-2009: Изделия электронной техники. Правила приемки — Терминология ГОСТ Р 53711 2009: Изделия электронной техники. Правила приемки оригинал документа: 3.1 группа испытаний: Одна или несколько подгрупп испытаний, объединенных по определенному признаку. Определения термина из разных документов: группа … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р ИСО 21247-2007: Статистические методы. Комбинированные системы нуль-приемки и процедуры управления процессом при выборочном контроле продукции — Терминология ГОСТ Р ИСО 21247 2007: Статистические методы. Комбинированные системы нуль приемки и процедуры управления процессом при выборочном контроле продукции оригинал документа: 3.1.23 аудит качества (audit): Систематическая экспертиза… … Словарь-справочник терминов нормативно-технической документации

Критерий — признак, на основе которого производится оценка состояния ядерной и радиационной безопасности ядерных установок судов и иных плавсредств. Источник … Словарь-справочник терминов нормативно-технической документации

Источник

Проектирование программного обеспечения: что такое Acceptance Criteria и зачем они нужны?

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

Поля ввода для имен пользователей и паролей

Способ сообщить пользователю, если он ввел свои данные неправильно

Способ восстановления забытых данных

Способ регистрации учетной записи, если у пользователя ее еще нет.

Итак, достаточно ли этого?

А что, если вы хотите написать что-то вроде поведенческого теста? Как перевести то, что написано выше, в шаги пользователя? И достаточно ли такой подход «короткого теглайна» говорит вам о том, как пользователь на самом деле выполняет эти действия? Задумывались ли вы о том, что происходит после того, как пользователь успешно вошел в систему? Помогает ли такой подход размышлять подобным образом?

Мы знаем, что нам нужно, но как это воплотить в хорошо спроектированную функцию?

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

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

Пример критериев приемки для вашей формы входа в систему может выглядеть следующим образом:

Given определяет некое предварительное условие для выполнения действия. When определяет действие. Then определяет результат действия. Мы также можем использовать And для дополнения любого из этапов, внося дополнительные условия. Этот подход логичен, понятен и прост. Каждый из этих этапов точно объясняет, что должно произойти в сценарии.

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

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

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

Как написать хороший AC?

Итак, вы решили написать этот продукт, но как сделать это правильно? Приведенная выше функция входа в систему очень проста, но более сложные концепции могут привести к путанице в AC, поэтому важно помнить о следующих вещах:

1. Пишите с точки зрения пользователя

2. Простота

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

3. Понятный язык

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

4. Не заостряйте внимания на деталях реализации

5. Не будьте техническими специалистами

Достаточно ли AC как такового?

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

Перевод материала подготовлен в рамках курса «Системный аналитик. Basic». Если вам интересно узнать подробнее о формате обучения и программе курса, приглашаем на день открытых дверей онлайн.

Источник