Один из основных артефактов гибких методологий разработки ПО — бэклог. В проекте может быть несколько видов бэклогов:

1. Бэклог продукта — функции продукта, которые вы хотите реализовать, но ещё не определили приоритеты для выпуска.
   
2. Бэклог релиза — функции продукта, которые должны быть реализованы для конкретного релиза.
   
3. Бэклог спринта — User Stories, которые должны быть завершены в течение определённого периода времени.
   

Бэклог продукта состоит из элементов — Product Backlog Item (PBI). Обычно их классифицируют так:

1. User Story — это облегчённый формат записи требований к системе, в котором больше внимания уделяется цели и меньше — деталям.
   
2. User Story может содержать дочерние задачи (Task). Это основные этапы, которые нужно сделать для того, чтобы история была реализована.
   
3. Эпик (Epic) — это высокоуровневое описание того, что хочет клиент. Его полное выполнение имеет максимальную ценность. Фактически это большая бизнес-задача, которую делят на несколько пользовательских историй.
   
4. Группа эпиков, реализующих одну и ту же функцию, образует Тему (Theme). Темы часто называют Фичами (Features).
   

Примеры DoR для US:

• US имеет ясное и краткое описание
  
• DоD определены и утверждены командой
  
• Все необходимые ресурсы, технические спецификации и прототипы доступны
  
• Все зависимости от других US зафиксированы
  
• US приоритезирована и оценена командой
• Команда договорилась об Acceptance Criteria

Примеры DoR для спринта:

• Все пользовательские истории, выбранные для спринта, оценены и имеют DoR
  
• У команды определены цели и ожидаемые результаты для спринта
  
• Вся необходимая документация и дизайн доступны
  
• Команда имеет доступ к необходимым ресурсам, таким как серверы, тестовые данные и так далее
  
• Команда имеет определённый бюджет и ресурсы для выполнения спринта
  
• Команда имеет понимание требований проекта и его структуру
  
• Команда имеет определённый план спринта и понимает, как он будет реализован
  
• Команда имеет определённую методологию разработки, такую как Scrum или Kanban
  
• Команда имеет общее понимание того, какие задачи будут выполнены в течение спринта и кто за них ответственен
  
• Команда имеет определённую систему отслеживания прогресса и отчётности о выполнении задач в рамках спринта
  

Примеры DoR для релиза:

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

DoD (Definition of Done) — критерии готовности PBI к передаче в эксплуатацию.

Для DoD актуальны те же особенности, что для DoR:

• Могут применяться как к любому PBI, так и к релизам и спринтам
  
• Одинаковы для всех US (спринтов, релизов) в проекте
  
• Определяются командой до начала первого спринта
  
• Могут видоизменяться в рамках работы команды (обычно в рамках ретроспективы)
  

Примеры DoD для US:

• Реализация US соответствует Acceptance Criteria
  
• Код, связанный с историей протестирован и отлажен
  
• Документация истории создана или обновлена
  
• Все необходимые одобрения истории получены
  
• Код, связанный с историей выложен в систему контроля версий
  
• Все возможные риски оценены и предусмотрены
  

В контексте спринта DoD — список условий, которые должны выполняться для завершения спринта. Аналогично в контексте релиза DoD — перечень условий, выполнение которых говорит о том, что новая версия продукта выпущена успешно.

Примеры DoD для спринта:

• Все US в спринте соответствуют критериям DoD
  
• Проектная документация актуализирована в соответствии с изменениями продукта
  
• Тест-кейсы актуализированы в соответствии с изменениями продукта
  
• Проведена ретроспектива по спринту

Примеры DoD для релиза:

• Весь код, связанный с релизом, успешно развернут в production-окружении
• Релиз проходит все smoke-тесты с пользовательскими данными
• Служба поддержки обучена особенностям новой функциональности
• Release Notes написаны
• Владелец продукта принял релиз

Например, для US «Поиск товара на сайте в рамках заданного ценового диапазона» AC могут быть такими:

• Пользователь может установить диапазон цены с клавиатуры
  
• Пользователь может установить диапазон цены поиска при помощи бегунка
  
• Для активации поиска пользователь нажимает кнопку «Найти»
  
• Если пользователь вводит некорректный диапазон цен, система должна выдавать сообщение об ошибке и не показывать пустой список товаров
  

Критерии готовности (DoD, DoR) и критерии приёмки (AС) являются важными элементами гибких методологий.

Несмотря на то, что критерии часто путают при поверхностном рассмотрении, они значимо различаются и используются на разных этапах жизненного цикла US:

1. DoR — общие критерии готовности (подготовленности) PBI (US, спринта, релиза) к передаче в работу команде разработки
   
2. DoD — критерии готовности PBI (US, спринта, релиза) к передаче в эксплуатацию пользователем
3. АС — критерии приёмки результата реализации US