Разница между DoR, DoD, NFR, критериями приёмки и Канбан политиками?

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

На основе этих практик в SAFe был создан набор взаимоувязанных техник и подходов, позволяющих децентрализованно управлять процессом выполнения и завершения любой работы.

Далее в статье мы опишем основные элементы определения завершённостью работы в SAFe.

Стандарты артефактов (Artifact Standards, DoR)

Определение

В Agile распространено понятие «Определение Подготовленности к работе» (Definition of Ready, DoR), однако на практике подобное ограничение в столь широком понимании может свести на нет любую гибкость разработки и бизнеса, поскольку, например, может с лёгкостью включать в себя требования, описывающие водопадное завершение этапа проекта. Вместо DoR в SAFe рекомендуется использовать максимально легковесные, понятные, согласованные командами Стандарты Артефактов, которые не противоречат Agile мышлению.

• Стандарт Артефакта – это набор критериев, которым должен соответствовать элемент беклога, прежде чем команда сможет начать разработку в соответствии с ним.
• Стандарт гарантирует, что элемент понятен и содержит всю необходимую информацию.
• Отсутствие полного соответствия Стандарту Артефакта не должно препятствовать его предварительному обсуждению, анализу, оценке, помещению его в дорожные карты и первые столбцы Канбан систем.

Кто устанавливает?

• Базовые установки Стандарта Артефактов содержатся в самом фреймворке.
• Основным установщиком Стандартов Артефактов на уровне портфеля является Офис управления ценностью (VMO), который отвечает за согласованность артефактов на уровне всего портфеля.
• Основными источниками Стандартов на уровне Поезда являются Архитекторы, Менеджмент Продукта/Решения и RTE/STE.
• Команды, обсуждая создание конкретных инкрементов ценности должны предлагать собственные Стандарты с целью ускорения потока, повышения гибкости, но с сохранением предсказуемости.

Примеры областей, покрываемых Стандартами Артефактов:

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

Определение Завершённости (Definition of Done, DoD)

Определение

Определение Завершённости (Выполненности) содержит требования к тому, какую работу можно действительно считать завершённой – по инкременту ценности или продукту.

• Является чек-листом, полное заполнение которого помогает команде понять, что работа над элементом выполнена.
• Отражает правила проверки результатов, обязательные технические практики и практики управления продуктом.
• Требует регулярного уточнения, является инструментом неустанного улучшения и предметом рассмотрения на ретроспективах.
• Не содержит Критериев Приёмки для конкретного функционала.

Кто устанавливает?

• Для уровня Фич и Капабилити устанавливается Архитекторами, RTE/STE и Менеджментом Продукта/Решения
• Для уровня Историй часть DoD может «наследоваться» с уровня Поезда, другая часть устанавливается командой, Владельцем Продукта команды при участии Скрам Мастера/Коуча команды

Пример некоторых Definition of Done уровня команды:

• История соответствует своим критериям приёмки.
• Пройдено приёмочное тестирование (по возможности автоматизированное).
• Пройдены юнит-тесты.
• Отсутствуют критические дефекты.
• Соблюдены инженерные стандарты.
• Успешно включено в сборку.
• Обновлена документация.
• История принята Владельцем Продукта команды.

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

Определение

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

• Критерии Приёмки определяют, какие важные элементы функциональности должен продемонстрировать результат разработки Истории или Фичи, чтобы быть принятым Владельцем Продукта или Менеджментом Продукта.
• Критерии Приёмки предоставляют чёткое понимание элемента работы для команды и заинтересованных лиц, позволяя выровнять ожидания и оценку со стороны команды.
• Являются результатом итерационного уточнения, в котором принимают участие Менеджеры и Владельцы Продукта, Архитекторы, участники команд разработки, которые будут в итоге создавать ожидаемый инкремент ценности.

Кто устанавливает?

• Первую версию Критериев Приёмки создаёт автор соответствующего элемента беклога: Менеджер Продукта, Архитектор, Владелец Продукта команды.
• Уточнённую версию Критериев Приёмки для Фич и Капабилити создают продуктовые и технологические лидеры Поезда с возможным привлечением экспертов от команд разработки.
• Финальную версию Критериев Приёмки Историй создают совместно команды разработки со своими Владельцами Продукта.

Пример одного Критерия Приёмки в рекомендуемом SAFe формате «Дано-Когда-Тогда»:

01:

Дано: пользователь вошёл и находится в системе
Когда: пользователь инициировал добавление товара в корзину
Тогда: товар появился в списке товаров в корзине

02: …

Нефункциональные Требования (НФТ, NFR)

Определение

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

• Это качества, которые описывают то, как должна работать система, а не то, что она делает.
• На основе НФТ для их соблюдения могут появляться новые элементы беклога любого уровня и/или одновременно может изменяться сложность выполнения существующих элементов.
• После выполнения некоторых элементов беклогов они могут «оставлять после себя» Нефункциональные Требования для ограничения будущей разработки.
• НФТ требуют тестирования и демонстрации как и любые другие элементы беклога.

Кто устанавливает Нефункциональные Требования?

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

Примеры NFR:

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

Политики Канбан системы (Kanban policies)

Определение

Политики Канбан системы — это правила, которые регулируют управление работой на Канбан доске.

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

Кто устанавливает Канбан Политики?

• Базовые Политики Канбан содержатся в самом фреймворке.
• Установщиком деталей базовых Политик на уровне портфеля является Офис управления ценностью (VMO).
• На уровне Поезда политики определяют RTE/STE, Архитекторы, Менеджмент Продукта/Решения.
• Для уровня Команд часть Политик может «наследоваться» с уровня Поезда, другая часть устанавливается командой, Владельцем Продукта команды при участии Скрам Мастера/Коуча команды.

Пример некоторых базовых Канбан политик уровня Релизного Поезда (ART):

• Анализ: Описана гипотеза выгоды, вычислен WSJF, соблюдается ограничение НЗР (WIP)
• Подготовлено: Фича утверждена Менеджментом Продукта, проводится непрерывная приоритизация WSJF, соблюдается ограничение НЗР (WIP)
• Разработка: Фича декомпозирована на Истории, Команды определяют-разрабатывают-тестируют Решение, соблюдается ограничение НЗР (WIP)