Эта статья состоит из цитат из "Руководства по Скраму". Дополнительный контент от себя оформлен не как цитаты.
Одна из ключевых концепций Скрама:
Increment — это конкретная ступенька к достижению Product Goal (цели продукта). Работа не может считаться частью Increment, если она не соответствует определению готовности.
Что такое "определение готовности"?
Согласно ScrumGuide, определение готовности является одной из 3 приверженностей/commitments Скрам-команды. Другие две – цель продукта и цель спринта.Приверженность: Определение готовности — это формальное описание состояния Increment, при котором он соответствует требованиям качества, предъявляемым продукту. Developers должны неукоснительно следовать определению готовности.
Другими словами,
в момент, когда элемент Product Backlog стал соответствовать определению готовности, рождается Increment. Если элемент Product Backlog не соответствует определению готовности, его нельзя выпускать или даже показывать на Sprint Review. Вместо этого он возвращается в Product Backlog для дальнейшего рассмотрения.
Кто создает определение готовности?
Если определение готовности для Increment является частью единых стандартов организации, все Scrum Teams должны использовать его в качестве необходимого минимума.
Если оно не определено стандартами организации, то Scrum Team должна создать определение готовности, подходящее поставляемому продукту.
Если несколько Scrum Teams работают над общим продуктом, они должны совместно определить и соблюдать одно и то же определение готовности.
Кто отвечает за соответствие элементов бэклога и инкреемнта DoD?
Конкретные навыки, необходимые Developers, зависят от предметной области выполняемой работы и могут быть очень разными. Однако Developers всегда несут ответственность за: [...] стремление к качеству посредством соблюдения определения готовности [...]
Scrum Master [...] помогает Scrum Team фокусироваться на создании Increments с высокой ценностью, соответствующих определению готовности.
Зачем нужно определение готовности?
1) Онообеспечивает прозрачность, предоставляя всем единое общее понимание того, какая работа была выполнена в рамках Increment.2) DoD помогает точнее планировать
Sprint Planning, тема вторая: что может быть готово в этом Sprint?
Developers обсуждают с Product Owner, какие элементы Product Backlog выбрать для включения в текущий Sprint. Выбор элементов, которые получится завершить за Sprint, может оказаться трудной задачей. Однако, чем больше Developers знают о своей прошлой производительности, своих возможностях на следующий Sprint и своем определении готовности, тем более уверенно они могут прогнозировать работу на следующий Sprint.
Sprint Planning, тема третья: как будет выполняться выбранная работа? Developers для каждого выбранного элемента Product Backlog планируют работу, необходимую для создания Increment, соответствующего определению готовности.
Когда анализировать и обновлять DoD?
Цель Sprint Retrospective — запланировать повышение качества и эффективности. Scrum Team инспектирует то, как прошел последний Sprint в отношении людей, взаимодействий, процессов, инструментов и определения готовности.
SAFe Definition of Done
Команды создают и придерживаются определения готовности.Определение готовности:
- обеспечивает общие критерии для всех элементов бэклога,
- устанавливает ожидания в отношении качества;
- сообщает о полной реализации инкермента стоимости,
- создает общее понимание того, какая работа была выполнена при создании инкремента,
- гарантирует, что поставляемая функциональность соответствует внутренним правилами и политикам.
Не путайте "Определение готовности" с "Критериями приёмки". Критерии приёмки гарантируют, что функциональность работает так, как ожидалось. Они описывают детали пользовательской истории с точки зрения тестирования. Критерии приёмки создаются командой и владельцем продукта по мере уточнения пользовательских историй.
Определение готовности содержит пункты трёх типов:
1) Политики о том, как проверять результаты. Например:
- Истории удовлетворяют Критериям приёмки.
- Модульные и приемочные испытания пройдены.
- Весь код добавен в ветку версии.
- Документация по API и модели данных обновлена.
- Состав релиза для маркетинга и продаж описан.
- Пользовательская документация обновлена.
- Раздел часто задаваемых вопросов обновлён на сайте.
SAFe выделяет 4 вида DoD в зависимости от уровня инкремента. Они не исключают, а дополняют друг друга. При этом используются те, которые актуальны для вашего инкремента.
Инкремент команды
- Истории удовлетворяют Критериям приёмки
- Приемочные испытания пройдены (автоматизированы, где это целесообразно)
- Модульные и компонентные тесты закодированы, пройдены и включены в бизнес-тестирование
- Модульные тесты инкремента пройдены
- Версионирование выполнено
- Инженерные стандарты соблюдены
- NFR выполнены
- Обязательных к исправлению дефектов нет
- Истории приняты владельцем продукта
Икремент системы (для Релизного поезда и Решения)
- Истории завершены всеми командами в ART и интегрированы
- Функции (features) соответствуют Критериям приёмки
- NFR выполнены
- Обязательных к исправлению дефектов нет
- Верификация и валидация ключевых сценариев
- Включено в сборку и процесс развертывания
- Инкремент системы продемонстрирован; обратная связь получена
- Принят менеджментом продукта
Инкремент решения (для Поезда решения и Большого решения)
- Возможности (сapabilities) реализованы всеми поездами и соответствуют Критериям приёмки
- Развернуто/установлено в пред-промышленной среде
- NFR выполнены
- Обязательных к исправлению дефектов нет
- Сквозная интеграция выполнена; верификация и валидация выполнены
- Включено в сборку и процесс развертывания
- Документация обновлена
- Инкремент решения продемонстрирован; обратная связь получена
- Принят менеджментом решения
Релиз
- Все возможности (capabilities) реализованы и соответствуют Критериям приёмки
- Сквозная интеграция выполнена; верификация и валидация решения выполнены
- Регрессионное тестирование проведено
- NFR выполнены
- Обязательных к исправлению дефектов нет
- Документация релиза завершена
- Все стандарты соблюдены
- Утверждено менеджментом решений и релизов