При этом критерии могут быть встроены в процессы и культуру работы, а высокий уровень компетенций сотрудников избавляет от необходимости прописывать критерии для каждой единицы поставки. Каждая команда сама решает, какие практики применять. Acceptance Criteria обычно формулируются в виде конкретных верифицируемых условий, которые должны быть выполнены.
Это набор критериев, которые определяют, когда инкремент готов к началу разработки. Иначе говоря, это описание того, что должно быть выполнено прежде, чем задача будет взята в работу. Как не все фломастеры красные, так и не все пользовательские истории хорошие. Существует несколько типичных черт, которые характерны плохим историям. Давайте рассмотрим наиболее распространенные из них.
Как посетитель кафе, я хочу смотреть историю заказов, видеть чеки, печатать чеки, чтобы я мог пересматривать их, сравнивать их, отправлять такие же заказы в ресторан. Как посетитель кафе, я хочу смотреть историю заказов, видеть чеки, печатать чеки, чтобы я мог изменять чеки, сравнивать их, отправлять новые заказы в ресторан. Gherkin – это способ описания сценариев использования систем, который понятен разработчикам, тестировщикам, бизнесу.
Наконец, критерии приемки часто определяют тестирование «прошел/прошел», чтобы определить, завершена ли пользовательская история. В Agile критерии приемки (Acceptance Criteria) относятся к набору предопределенных требований, которые должны быть выполнены, чтобы отметить User Story как завершенную. Критерии приемки также иногда называют «definition of done», потому что они определяют объем и требования, которые должны быть выполнены разработчиками, чтобы считать User Story завершенной. Обычно в создании критериев приемки участвуют несколько человек или команд. Тем не менее, это в первую очередь делает product manager (или “product owner”).
Технику можно использовать и вне Agile-процесса. Практика обсуждений в формате трех ролей будет полезна в любом проекте, потому что везде есть разработчики и тестировщики, которые дальше будут внедрять и проверять созданные требования. На практике многие зрелые продуктовые компании не используют термины Definition of Ready, Definition of Done и Acceptance Criteria. От жёстко установленных критериев отказываются в пользу большей гибкости и открытости.
Результат встречи — это договоренность о том, что будем разрабатывать, и написанные критерии приемки, которые можно автоматизировать, те самые Given-When-Then. Критерии, на основании которых команда разработки берёт инкремент в работу, называются Definition of Ready. Критерии, на основании которых инкремент передают заказчику, а затем пользователю — Definition of Done. Игорь Аскаров, руководитель разработки инфраструктурной платформы в «Яндексе», считает, что в проектах, которые только запускаются, без атрибутов типа Definition of Done не обойтись. Это особенно важно в тех случаях, когда начальный MVP разрабатывает внешняя команда на основе чётких требований и в рамках фиксированного срока. Примеры инкрементов разного уровня — спринт, эпик, задача, релиз, пользовательская история… Продукт целиком — тоже инкремент, но самого высокого уровня.
Это заставляет вас позаботиться о том, как пользователь сможет испытать приложение, а не только о том, какие замечательные вещи вам хотелось бы сделать. Given определяет некое предварительное условие для выполнения действия. Мы также можем использовать And для дополнения любого из этапов, внося дополнительные условия. Каждый из этих этапов точно объясняет, что должно произойти в сценарии.
Диаграмма позволяет Команде прогнозировать успех Спринта и предпринимать меры, чтобы к моменту окончанию Спринта все запланированные задачи были были завершены. Пользовательская история сама по себе оставляет много места для интерпретации. Критерии приемлемости конкретным образом разъясняют ожидаемые результаты. Это также дает разработчикам и специалистам по контролю качества четкий способ определить, выполнена ли история.
Проектирование Программного Обеспечения: Что Такое Acceptance Standards И Зачем Они Нужны?
Мы давно отказались от терминов Definition of Ready и Definition of Done, так же как и от жёстких списков этих критериев. Сами по себе критерии не гарантируют ничего, хотя и присутствуют в неявном виде. Окей, инкремент перешёл к команде разработки — дизайнерам, разработчикам и тестировщикам. Рано или поздно наступает момент, когда работа над инкрементом завершена.
И мы, конечно, говорим о цифровых продуктах и о том, как определять их «готовность». Я очень надеюсь, что список правил и лайфхаки, которые я вывела в ходе своей многолетней практики, помогут вам усовершенствовать ваши требования. Что касается инструкций, я также, как и с критериями INVEST, прохожусь по всем критериям приёмки и проверяю их на соблюдение каждого «критерия хороших AC».
На большинстве наших проектов критерии приёмки добавляют эффективности и мотивированности и всей команде, и каждому отдельному специалисту. Когда у специалиста есть понимание, чего от него ждут — он охотно берёт на себя ответственность за результат. Когда ожидаемый результат в тумане — то и отвечать не за что. Из понятных критериев приёмки складывается и общее понимание ценности продукта».
Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin. Acceptance Criteria — это способ взглянуть на проблему с точки зрения клиента. Они должны быть написаны в контексте реального опыта пользователя. Участники собираются за 1-2 спринта до того, как функция должна быть в разработке, и рассматривают требования на будущее. Если основатели запускают продукт на свои деньги, важность конкретики только возрастает. Страх впустую потратить собственные средства, как правило, несравнимо сильнее, чем когда речь о ресурсах, выделенных инвесторами и акционерами.
Так команда точно увидит, что задача не такая простая и там есть над чем подумать.Но даже такая история не становится хорошей, ведь кто угодно замучается читать такой длинный “исторический роман”. “So that” – это часть про ценность истории, а не функции, которые будут в её рамках реализованы. В описании следует отразить и задачи, которые наиболее важны для персонажа в его работе с системой. Это поможет всей команде увидеть нужды персонажа и поможет создать стимул для покупки премиум-версии или подписки.
Соответственно, и работают здесь, как правило, инженеры, ориентированные на ценность для пользователя и бизнеса, болеющие за результат. Для программистов, которые “пилят” строго по ТЗ и не задают вопросов, это не лучшая среда». Как правило, они применимы ко всем инкрементам одного уровня в рамках продукта. То есть можно сформировать один набор критериев и применять их ко всем пользовательским историям. Свой единый набор критериев можно создать для эпиков и других инкрементов. Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner.
Решение о том, пойдёт ли новая функция в работу, принимают не по признаку соответствия неким формальным критериям, а на основе информации, собранной в ходе дискавери-фазы. Ключевой фактор принятия решения — потенциальное влияние новой фичи на бизнес. Инкремент, соответствующий критериям DoR, готов к началу разработки. Если инкремент не отвечает acceptance criteria примеры каким-то критериям — он считается не готовым и отправляется на доработку, прежде чем будет включен в производственный цикл. Критерии DoR должны быть максимально чёткими, понятными и достижимыми. DoR могут меняться и дорабатываться на протяжении жизни проекта по мере приобретения опыта и получения обратной связи от заинтересованных сторон.
Здесь-то и приходит на помощь Definition of Ready — дословно с английского «определение готовности». Количество и суть этапов может различаться в зависимости от компании и команды, а также вида инкремента. Например, инкремент уровня задачи может последовательно проходить этапы аналитики, разработки (написания кода) и тестирования. За каждый этап отвечают разные специалисты или отделы. Это значит, что инкремент вряд ли может находиться параллельно на этапе аналитики и разработки. Только когда аналитик закончит всю работу на своей стороне, а QA-специалист протестирует разработанные аналитиком требования — инкремент переходит к разработчику.
В идеале они должны помещаться на канцелярский стикер, который должен клеиться на реальную доску. Как посетитель кафе, я хочу, чтобы мой заказ сохранялся где-то, чтобы я мог смотреть историю заказов, распечатать чеки, отправить чеки по e-mail. АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться. В нем оба персонажа, которые всё-таки будут пользоваться системой, будут ключевыми.
Гайд По Consumer Stories Для Junior Ba / Po / Pm
В любом процессе или явлении не может быть единой-верной позиции и лишь в споре (сопоставлении различных мнений) рождается истина. Всё, как всегда, зависит от контекста проекта, от команды и от стейкхолдеров — правда, как всегда, где-то посередине! Agile-практика «Три амигос» помогает донести голос команды до клиента и прийти к общему пониманию требований. Перечисленные атрибуты должны быть выполнены для конкретных требований, они не описывают весь процесс.
Во время написания истории для аналитика важен не только её текст, но и то содержание – ценность, проблема – которая описывается этим текстом. Чтобы написать историю, которая сможет решить проблему пользователя, аналитику надо лучше понять пользователя и задать себе следующие вопросы. Очень важно отметить, что история и ее ценность может быть направлена не только на какую-то группу пользователей. Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код…), Product Owner или представителей бизнеса.
Задача некоторых указать, кому в приложении нет места. Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции. Чтобы понять, чем является сама нужда, давайте рассмотрим следующий пример.
Person Story Та Acceptance Criteria: Пишемо Чіткі Та Зрозумілі Вимоги
Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта. Он будет определять ваш дизайн, передавать ваше видение и помогать для тестирования, однако это еще не все и не всегда. Вы должны писать подзадачи, чтобы лучше определить технические аспекты ваших функций, создавать макеты и писать конкретные примеры. Соответствие инкремента критериям Definition of Done означает, что он завершён и готов к передаче заказчику и пользователю.
К формулированию AC могут быть привлечены представители заказчика, пользователи, аналитики, разработчики и другие участники проекта. Acceptance Criteria могут быть сформулированы в процессе сбора требований к инкременту, разработки пользовательских историй, взаимодействия с заказчиком или пользователем. Сложно сделать однозначный вывод относительно полезности Gherkin. Я много раз пытался начать постоянно использовать его на проекте.
