Величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта. Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований.
Суть этого пункта не только в том, что команда тестировщиков должна понимать, что проверять, но и в том, что пользовательская история должна обладать чем-то, что можно посмотреть, запустить. Команда и заказчик могут иметь разные взгляды на пути решения проблемы, в зависимости от их точек зрения. Убедитесь, что вы донесли свои критерии приемки до заказчиков и достигли взаимопонимания. Каждый должен рассмотреть критерии приемки и подтвердить, что он понимает и согласен с каждой из них. Теперь, когда у вас есть некоторые примеры критериев приемки и готовые шаблоны, давайте рассмотрим, кто должен быть ответственным за написание таких требований к программному обеспечению. Если вам нужны готовые шаблоны критериев приемки для быстрого заполнения необходимой информацией и организации пользовательских историй, будут полезны следующие ресурсы .
Они предоставляют точные детали функциональности, которые помогают команде понять, выполнена ли история и работает ли она, как ожидалось. Представьте, что вы просите свою команду разработчиков сделать возможным поиск продукта в интернет-магазине книг по категориям. Вы ожидаете видеть четкий интерфейс с кликабельными ссылками на категории для клика (например, фэнтези, нон-фикшн, история и т. д.). Хотя в таком виде функционал тоже работает, вашей первоначальной целью было представить все доступные категории и позволить пользователям работать с ними дальше. Критерии должны отражать точку зрения пользователя. Критерии приемки – это средство взглянуть на проблему с точки зрения клиента.
Как и в случае с большинством Agile, существуют разные определения Acceptance Criteria. Критерии приемки — это неоправданно расплывчатое название набора шагов, которые описывают, как пользователь может взаимодействовать с конкретной функцией. Они написаны в формате, использующем шаги Given, When, и Then , и сопоставлены с действиями пользователя. Благодаря этому их легко преобразовать в поведенческие тесты.
- Хорошие критерии приемки должны быть простыми для понимания, но с достаточной детализацией, чтобы убедиться, что они не слишком расплывчаты.
- Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.
- Эффективные критерии приемки определяют разумный минимальный объем функциональности, который вы способны предоставить.
- Неспособность строить и воплощать средне- и долгосрочные планы ставит крест на любых перспективах выживания бизнеса клиента.
Gherkin отлично подходит для описания сложных сценариев с ветвлением, вариантами. Тем не менее, этот способ не вызвал положительные отзывы со стороны (вообще не вызвал) команды разработки или тестирования. Получается так, что балом в "деталях" к историям правят критерии приёмки - именно на них команда смотрит чаще всего во время оценки и изучения задач.
Достаточно Ли Ac Как Такового?
Одно из главных преимуществ такого подхода заключается в том, что он может быть понятен нетехническим людям. Инструмент, способный описать функцию для любого человека и одновременно управлять реализацией/тестированием, бесценен. Длинная строка AC, которая пытается вместить в себя несколько вещей, может повлиять на ясность и тем самым свести на нет многие преимущества, упомянутые выше. Даже простые функции могут быть сложными для разработки. Уже сейчас вы перечислили пять вещей, которые хотите отслеживать. Торопиться с разработкой функции без должного планирования - это безрассудство, но вы это знаете и написали вышеприведенный контрольный список.
В продуктовой парадигме нефункциональные требования фиксируются в понятиях определений или критериях приемки. Пишите критерии приемки, которые можно протестировать. Это позволит тестировщикам проверить, были ли выполнены все требования. В противном случае разработчики не поймут, завершена ли пользовательская история. Ваши критерии приемки могут потребовать от системы распознавать небезопасные пароли и предотвратить дальнейшие действия пользователя.
Вводная Информация О User Stories
Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код...), Product Owner или представителей бизнеса. Лучше использовать несколько простых предложений, чем одно сложное. Чем меньше ненужных слов и союзов, таких как "но", "и", "так как", в ваших критериях приемки, тем более понятными становятся требования для команды разработки. Всегда лучше избегать использования наречия "не", так как оно часто делает требования неясными и менее поддающимися проверке. Однако использование "не" возможно, если есть необходимость представить уникальные требования к функциональности системы. Например, "Форма входа не должна подсвечиваться красным, когда пользователь вводит неверные значения."
Мы расширили часть “I need...”, чтобы каждая “хотелка” из третьей части истории была соотнесена с функцией из второй части. Эти сценарии используются чаще всего для описания критериев приёмки и могут стать отличным помощником для автоматизации тестирования. Их большим минусом является нечитабельность, ведь сценарии представляют из себя длинные тексты, в то время как АС - это чаще всего 1-2 строчки текста. Gherkin - это способ описания сценариев использования систем, который понятен разработчикам, тестировщикам, бизнесу. Он строится по строгому синтаксису и потому позволяет "обходить" многие вольности естественного языка.
Если ценность историй, которые несут новый функционал или улучшают старый, очевидна, то с теми, которые завязаны на технической стороне продукта, не все так очевидно. Скорее всего, пользователь ощутит их благодаря улучшению отзывчивости или скорости работы системы. Критерии приемки должны быть задокументированы до начала фактической разработки. Таким образом, команда скорее всего заранее учтет все потребности клиента.
Концепция Определений Из Information To Product Ownership Analysis
В конце концов, вам нужна вся доступная информация для эффективной расстановки приоритетов. Важно, чтобы ваши критерии были максимально простыми и понятными. Их будет читать и на них будет ориентироваться ваша команда.
Acceptance Criteria («критерии приема», AC) — это набор условий, которым должна удовлетворять User Story, чтобы ее считали выполненной. Одной из распространенных хворей историй является главной болезнью плохой пользовательской истории автор acceptance criteria это считает истории “хочу Х чтобы Х”. Как не все фломастеры красные, так и не все пользовательские истории хорошие. Существует несколько типичных черт, которые характерны плохим историям. Давайте рассмотрим наиболее распространенные из них.
Когда Следует Писать Acceptance Criteria?
Поскольку разные люди могут иметь разные точки зрения и идеи решения одной проблемы, необходимо создание единого видения того, как должна быть реализована функциональность. Это именно то, что делают четко сформулированные критерии приемки. Высокоуровневой целью является уточнение требований заинтересованных сторон.
Поскольку вы превосходный разработчик, то решили провести базовое планирование, прежде чем приступить к проектированию. По крайней мере, вы хотите определить некоторые аспекты функции, которую собираетесь создать. Хотя вы тратите время на приоритетный список пользовательских историй, отсутствие Acceptance Criteria перед определением приоритетов может помешать прогрессу приоритизации. Практически каждый в кросс–функциональной команде может написать Acceptance Criteria для пользовательских историй.
Декомпозиция Бэклога (backlog Slicing, Слайсинг Или Нарезка Бэклога)
Переполненность истории негативно скажется на нескольких аспектах. Во-первых, она не оставляет места для творчества разработчику - он становится просто руками, которые делают, что сказали; во-вторых, детали превращают историю в исторический роман. “So that” - это часть про ценность истории, а не функции, которые будут в её рамках реализованы. АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться. Например, в случае зависимости нескольких историй друг от друга, следует искать другой способ разбить их.
Когда я вписываю в поле Email действительный адрес электронной почты и заполняю Name своим именем, а в поле Comment пишу комментарий и нажимаю кнопку «Отправить отзыв». Тогда система позволяет мне это сделать и не показывает никаких сообщений об ошибке. Думаю, что статья будет полезной для РМ’ов, бизнес-аналитиков и других специалистов, которые работают с заказчиками и создают требования.
Как Добавить Деталей К Истории?
Подтверждении того, что они имеют ценность для стейкхолдеров. Эффективные критерии приемки определяют разумный минимальный объем функциональности, который вы способны предоставить. Но если вы поддадитесь описанию всех мелких деталей, существует риск того, что ваша команда застрянет с сотнями мелких задач. Критерии приемки определяют границы пользовательских историй.
Чтобы понять, чем является сама нужда, давайте рассмотрим следующий пример. Внимательный читатель уже догадался, что главная нужда человека -- инструмент, которым можно добыть еду (например, удочка). Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта. На первый взгляд, критерии приемки кажутся очень легкими для написания. Несмотря на их простой формат, написание может вызвать затруднения для многих команд.
На конкретных примерах объясню, чем отличаются понятия Definition of Done и Acceptance Criteria, поделюсь техниками работы с требованиями для пользовательских историй. Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта. Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте.
