1. Definitions of Done (DoD)

Это четкий, согласованный список критериев, которым должна соответствовать задача или пользовательская история, прежде чем она будет считаться завершенной. DoD помогает обеспечивать согласованность, качество и единое понимание внутри команды.

Основные аспекты DoD:

• Код написан, проверен и объединен.
• Код покрыт модульными тестами на определенном уровне (например, 80%).
• Функциональные и интеграционные тесты пройдены.
• Функция задокументирована (если требуется).
• Процесс развертывания завершен, и функция работает в продакшене (если применимо).

Почему DoD важно?

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

Когда использовать DoD?
Agile и Scrum проекты – гарантирует, что каждый спринт приносит полностью завершенные функции.
Kanban-процессы – помогает убедиться, что каждая задача соответствует стандартам качества.
Разработка программного обеспечения – определяет, когда функция, исправление бага или релиз считаются завершенными.
Создание продуктов – помогает выпускать качественные продуктовые инкременты.

Пример DoD в Scrum-проекте:

• Код написан, проверен и влит в основную ветку.
• Юнит-тесты и интеграционные тесты пройдены.
• Функция протестирована в стейджинг-среде.
• Документация и инструкции обновлены.
• Функция продемонстрирована заказчикам.

2. Definitions of Ready (DoR)

Определение готовности (Definition of Ready, DoR) — это набор четких критериев, которым должна соответствовать пользовательская история, задача или элемент бэклога, прежде чем их можно будет передать в разработку. Это гарантирует, что команда разработки имеет всю необходимую информацию, согласования и ресурсы перед началом работы.
Четко определенный DoR помогает избежать недопонимания, уменьшает потери времени и повышает эффективность планирования и выполнения спринтов.

Основные аспекты DoR:

• Четко определена бизнес-ценность.
• Прописаны критерии приемки.
• Команда полностью понимает требования.
• Определены и устранены все зависимости.
• Задача оценена командой.
• История достаточно мала, чтобы быть выполненной в течение спринта.
• Доступны все необходимые макеты, API-контракты и другие артефакты.
• Нет открытых вопросов, которые могут заблокировать разработку.

Почему DoR важно?

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

Когда использовать DoR?
Во время уточнения бэклога. Чтобы убедиться, что истории соответствуют DoR перед планированием спринта.
Перед планированием спринта. Чтобы команда выбирала только подготовленные задачи.
В Agile/Scrum проектах, чтобы поддерживать бесперебойный рабочий процесс.
В Kanban, чтобы элементы работы, поступающие в разработку, были полностью определены.

Пример DoR для User Story:
User story: Как пользователь, я хочу иметь возможность сбросить пароль через email, чтобы восстановить доступ к аккаунту.

• Определена бизнес-ценность.
• Прописаны критерии приемки (например, «Пользователь получает письмо со сбросом пароля в течение 5 минут»).
• Доступны UI/UX макеты.
• Определены API-эндпоинты для сброса пароля.
• Устранены зависимости (например, почтовый сервис).
• Задача оценена и достаточно мала для выполнения в течение спринта.

3. Acceptance Criteria (AC)

Критерии приемки (Acceptance Criteria, AC) – это заранее определенные условия или требования, которым должна соответствовать функция, пользовательская история или задача, чтобы считаться успешно завершенной. Эти критерии помогают определить объем работы, ожидаемое поведение и условия для приемки, служа связующим звеном между бизнес-требованиями и технической реализацией.

Основные характеристики критериев приемки:
AC должны быть четкими и однозначными. Они определяют, что именно должно быть выполнено.
AC должны быть тестируемые и измеримые, они могут быть проверены вручную или с помощью автоматизированного тестирования.
AC должны быть ориентированы на бизнес, они отражают потребности пользователей и заинтересованных сторон.
AC должны соответствовать бинарным условиям (пройдено/не пройдено), либо выполнены, либо нет (нет частичного выполнения).
AC определяются совместно, создаются с участием владельца продукта, разработчиков и тестировщиков.

Типы критериев приемки (AC):
Функциональные критерии – описывают ожидаемое поведение или функциональность.
Пример: "Система должна отправлять письмо для сброса пароля в течение 5 минут после запроса пользователя."

Нефункциональные критерии – определяют производительность, безопасность, удобство использования и другие качества.
Пример: "Страница должна загружаться не более чем за 2 секунды у 95% пользователей."

Границы и крайние случаи – охватывают валидацию ввода, обработку ошибок и другие особые сценарии.
Пример: "Если пользователь вводит неверный email, должно появляться сообщение об ошибке."

Зачем нужны критерии приемки (AC)?

• Предотвращают недопонимание, гарантируют, что разработчики, тестировщики и заинтересованные стороны имеют одинаковые ожидания.
• Улучшают тестируемость, помогают команде QA проверять, работает ли функция должным образом.
• Поддерживают Agile-разработку, определяют, что означает "Готово" для пользовательской истории.
• Снижают риск изменения объема работ, предотвращают незапланированные изменения, четко определяя, что должно быть реализовано.
• Улучшают коммуникацию, способствуют эффективному взаимодействию между бизнесом и технической командой.

Когда используют критерии приемки?

• АС описывают до начала разработки. AC должны быть определены до старта кодинга, чтобы обеспечить четкие требования.
• Во время планирования спринта, AC помогает разработчикам и тестировщикам понять объем работы.
• Во время тестирования и контроля качества AC используются в качестве ориентира для тест-кейсов и приемочного тестирования.
• При завершении пользовательской истории необходимо проверить, что все AC выполнены. История не считается "Готовой", пока все AC не выполнены.

Пример критериев приемки (в формате Gherkin – Given/When/Then):
Пользовательская история: Как пользователь, я хочу сбросить свой пароль, чтобы восстановить доступ к аккаунту.

• Сценарий 1: Успешный запрос на сброс пароля

✅ Дано, что пользователь вводит зарегистрированный email
✅ Когда он нажимает кнопку "Сбросить пароль"
✅ Тогда он должен получить письмо для сброса пароля в течение 5 минут

• Сценарий 2: Ввод неверного email

✅ Дано, что пользователь вводит незарегистрированный email
✅ Когда он нажимает "Сбросить пароль"
✅ Тогда должно появиться сообщение об ошибке: "Email не найден"


User Story: As a user, I want to reset my password so that I can regain access to my account.

• Scenario 1: Successful Password Reset Request

✅ Given the user enters a registered email
✅ When they click the "Reset Password" button
✅ Then they should receive a reset email within 5 minutes

• Scenario 2: Invalid Email Entry

✅ Given the user enters an unregistered email
✅ When they click "Reset Password"
✅ Then an error message should appear: "Email not found"