На фоне гибкой разработки ясность является валютой успеха. Когда команда приступает к работе над новой функцией, основой является пользовательская история. Однако пользовательская история — это всего лишь временный маркер для обсуждения. Чтобы превратить это обсуждение в рабочий продукт, необходимы два критически важных элемента: критерии приемки и определение готовности. Эти понятия служат ориентирами, обеспечивающими качество, согласованность и предсказуемость.
Многие команды испытывают трудности с различием между этими двумя понятиями. Иногда их рассматривают как одно и то же, что приводит к путанице при тестировании или развертывании. В других случаях их полностью игнорируют, что приводит к расширению объема работ или попаданию незавершенных функций в производство. Этот гид исследует механизмы, цели и реализацию критериев приемки и определения готовности, чтобы помочь вашей команде последовательно предоставлять ценность.
Что такое пользовательская история? 📝
Прежде чем разбирать компоненты истории, важно вспомнить, что на самом деле представляет собой пользовательская история. В гибких рамках пользовательская история — это краткое и простое описание функции, изложенное с точки зрения человека, желающего получить новую возможность. Обычно она следует следующему формату:
- Как [тип пользователя],
- Я хочу [некоторая цель],
- Чтобы [некоторая выгода].
Этот формат фокусируется на ценностипредоставляемой пользователю, а не на технической реализации. Однако этот формат сам по себе недостаточен для руководства разработкой. Он не определяет границы работы или стандарты, необходимые для завершения. Именно здесь на помощь приходят критерии приемки и определение готовности.
Критерии приемки (КП): Условия завершения ✅
Критерии приемки — это набор условий, которые пользовательская история должна выполнить, чтобы считаться завершенной с точки зрения владельца продукта. Они определяют границы истории и дают четкое понимание того, каким должен быть конечный продукт.
Цель критериев приемки
Критерии приемки выполняют несколько функций в жизненном цикле разработки:
- Уточнение: Они устраняют неоднозначность. Если разработчик спрашивает: «Кнопка должна становиться зеленой или синей при наведении?», критерии приемки должны на это ответить.
- Тестирование: Они выступают в качестве тестовых случаев. Инженеры по тестированию используют эти условия для проверки функции.
- Согласие: Они обеспечивают, что владелец продукта и разработчики согласны с тем, что считается «завершенным» для этой конкретной истории.
Характеристики хороших критериев приемки
Эффективные критерии приемки — это конкретные, измеримые и однозначные. Избегайте неопределенных терминов, таких как «удобный для пользователя» или «быстрый», без определения метрик. Вместо этого уточните точное поведение.
- Атомарные: Каждый критерий должен отражать одну конкретную потребность.
- Проверяемые: Должно быть возможно проверить критерий, получив результат «успешно» или «неудачно».
- Независимо:Критерии не должны полагаться на внешние истории для проверки.
- Актуально:Сосредоточьтесь на ценности для пользователя, а не на внутренней структуре кода.
Примеры критериев приемки
Рассмотрим историю по добавлению функции «Забыли пароль?». Вот как могут выглядеть критерии приемки:
- Предположим, что пользователь находится на странице входа,
Когда они нажимают ссылку «Забыли пароль?»,
То они перенаправляются на страницу восстановления пароля. - Предположим, что пользователь вводит действительный адрес электронной почты,
Когда они отправляют форму,
То отображается сообщение подтверждения. - Предположим, что пользователь вводит недействительный адрес электронной почты,
Когда они отправляют форму,
То сообщение об ошибке указывает, что формат электронной почты неверен.
Эти примеры следуют структуре Дано/Когда/Тоструктуры (часто связанной с синтаксисом Gherkin), которая способствует ясности и соответствует фреймворкам автоматизированного тестирования.
Определение выполнения (DoD): контрольный пункт качества 🚧
В то время как критерии приемки относятся к одной конкретной истории пользователя, определение выполнения — это глобальный стандарт, применяемый к всемработе в рамках спринта или релиза. Это чек-лист требований, которые должны быть выполнены, чтобы любой этап работы считался потенциально пригодным к выпуску.
Цель определения выполнения
DoD выступает в качестве контрольного пункта качества. Он гарантирует, что технический долг не накапливается, а продукт всегда находится в состоянии, пригодном к выпуску. Если история соответствует критериям приемки, но не соответствует определению выполнения, она не может быть помечена как завершенная.
Общие элементы, входящие в определение выполнения, включают:
- Проверка кода:Весь код должен быть проверен как минимум одним коллегой.
- Юнит-тесты:Автоматизированные тесты должны проходить с покрытием 100% для новой логики.
- Документация:Документация API или руководства пользователя обновлены.
- Производительность:Функция соответствует минимальным требованиям времени загрузки.
- Доступность:Функция соответствует руководящим принципам WCAG.
- Безопасность:Нет известных уязвимостей.
Почему важно определение готовности
Без определения готовности команды часто попадают в ловушку «технически выполнено, но на самом деле не готово». Функция может работать так, как задумано согласно критериям приемки, но при этом может нарушить другую часть системы, не иметь должной документации или создать риски безопасности. Определение готовности предотвращает это, обеспечивая базовый уровень качества по всему бэклогу.
Критерии приемки против определения готовности: Ключевые различия 🆚
Часто возникает путаница, потому что оба понятия касаются «завершенности». Однако их охват и ответственность значительно различаются. Понимание различий предотвращает несогласованность между разработчиками, тестировщиками и владельцами продукта.
| Функция | Критерии приемки | Определение готовности |
|---|---|---|
| Область применения | Специфично для одного пользовательского сценария | Глобально для всей команды или проекта |
| Ответственность | Владелец продукта и разработчики | Вся разработческая команда |
| Гибкость | Изменения для каждого сценария в зависимости от требований | Стабильное, хотя может обновляться со временем |
| Цель | Определяет функциональные требования | Определяет стандарты качества и нефункциональные требования |
| Проверка | Функциональное тестирование в соответствии с потребностями пользователя | Техническая и процессная проверка |
Представьте критерии приемки как пункт назначения для конкретного путешествия, а определение готовности — как контрольный список безопасности, необходимый для каждого транспортного средства на дороге.
Как написать эффективные критерии приемки 📝
Написание критериев приемки — это совместная работа. Это не должно выполняться изолированно продукт-менеджером. Наилучшая практика включает концепцию «Трех друзей», при которой продукт-менеджер, разработчик и тестировщик совместно работают на ранних этапах процесса уточнения.
Шаг 1: Определите цель пользователя
Начните с переформулировки предложения о ценности. Какую проблему решает пользователь? Это гарантирует, что критерии будут ориентированы на пользовательский опыт, а не на технические детали.
Шаг 2: Определите положительные и отрицательные сценарии
Не пишите только «счастливый путь». Подумайте, что происходит, когда что-то идет не так.
- Счастливый путь: Пользователь выполняет действие точно так, как ожидается.
- Крайние случаи: Что происходит с особыми символами, отсутствующими данными или медленными соединениями?
- Отрицательный путь: Как система корректно обрабатывает недопустимые входные данные?
Шаг 3: Используйте ясный язык
Где возможно, избегайте жаргона. Если необходимы технические термины, убедитесь, что они определены. Используйте активный залог. Например, «Система должна проверять…» менее понятно, чем «Пользователь получает сообщение об ошибке…».
Шаг 4: Приоритезируйте
Если история большая, разбейте её на части. Критерии приемки должны быть выполнимыми в рамках спринта. Если критерии предполагают работу, которую невозможно завершить в спринте, история должна быть разделена.
Как установить надежное определение готовности 🛠️
Определение готовности — это не статический документ. Оно развивается по мере зрелости команды и изменения технологий. Оно должно быть доступно всем, часто отображается на физической или цифровой доске.
Шаг 1: Проконсультируйтесь с командой
Определение готовности принадлежит команде, которая выполняет работу. Разработчики, тестировщики и дизайнеры должны участвовать в составлении списка. Если разработчик добавляет требование, он с большей вероятностью будет ему следовать.
Шаг 2: Классифицируйте требования
Сгруппируйте элементы определения готовности по логическим категориям, чтобы чек-лист был управляемым.
- Качество кода: Проверка линтинга пройдена, нет предупреждений, рецензирование коллегами завершено.
- Тестирование: Написаны юнит-тесты, пройдены интеграционные тесты, ручное тестирование подтверждено.
- Развертывание: Развернуто в стейджинге, пройдены smoke-тесты.
- Документация: Readme обновлено, документация API синхронизирована.
Шаг 3: Сделайте жесткое завершение
Если история не соответствует критериям готовности, ее нельзя закрыть. Это требует дисциплины. Искушение сказать: «Мы исправим документацию позже», велико, но это создает технический долг. История остается в статусе «В процессе» до тех пор, пока не будут выполнены критерии готовности.
Шаг 4: Обзор и улучшение
Во время ретроспектив спросите команду: «Захватили ли наши критерии готовности какие-либо проблемы?» или «Есть ли требование, которое мы постоянно упускаем?» Обновите критерии готовности на основе этих выводов.
Распространенные ошибки, которые нужно избегать ⚠️
Даже опытные команды ошибаются при внедрении этих практик. Осознание распространенных ловушек может сэкономить значительное время и нервы.
1. Неясные критерии приемки
Формулировка критериев, таких как «Система должна быть безопасной», бесполезна. Она не поддается тестированию. Вместо этого уточните: «Система должна требовать многократной аутентификации для учетных записей администратора».
2. Критерии готовности как формальность
Если команда просто отмечает галочку в критериях готовности, не выполняя при этом реальной работы (например, пропуская проверку кода), критерии готовности теряют смысл. Критерии готовности должны уважаться, а не просто читаться.
3. Излишняя сложность критериев готовности
Критерии готовности с 50 пунктами становятся неподъемными. Сосредоточьтесь на ключевых контрольных точках качества. Если требование редко нарушается, оно может быть рекомендацией, а не жестким пунктом критериев готовности.
4. Пренебрежение нефункциональными требованиями
Команды часто сильно фокусируются на критериях приемки (функциональных) и игнорируют критерии готовности (нефункциональные). Производительность, безопасность и доступность являются частью критериев готовности, а не критериев приемки. Игнорирование их приводит к функциям, которые работают, но медленно или небезопасно.
5. Создание критериев готовности без согласия команды
Если Product Owner устанавливает критерии готовности без участия разработчиков, команда может им сопротивляться. Критерии готовности должны быть общим соглашением.
Интеграция в рабочий процесс 🔄
Критерии приемки и критерии готовности должны интегрироваться на каждом этапе жизненного цикла разработки, а не только в конце.
Фаза уточнения
Во время уточнения бэклога Product Owner составляет критерии приемки. Команда их проверяет, чтобы убедиться, что они проверяемы и выполнимы. Вопросы задаются и отвечаются здесь, а не во время спринта.
Планирование спринта
При принятии истории команда проверяет, что критерии приемки четкие. Если они неясны, история не готова к спринту.
Фаза разработки
Разработчики пишут код, чтобы соответствовать критериям приемки. Одновременно они обеспечивают соблюдение критериев готовности (например, написание тестов, запрос проверки).
Фаза тестирования
Инженеры по тестированию проверяют критерии приемки по готовому функционалу. Они также проверяют критерии готовности (например, проверяют отчеты по покрытию кода, сканирование доступности).
Обзор и закрытие
Перед тем как история будет перемещена в статус «Готово», команда подтверждает, что выполнены как критерии приемки, так и критерии готовности. Если нет — история возвращается в очередь.
Оценка успеха 📊
Как вы узнаете, работают ли ваши критерии приемки и критерии готовности? Следите за метриками с течением времени.
- Уровень дефектов: Уменьшается ли количество ошибок, обнаруженных в производстве? Сильный критерий готовности должен выявлять проблемы до выпуска.
- Уровень отказов: Часто ли истории отклоняются продукт-менеджером? Это указывает на слабую формулировку критериев приемки.
- Стабильность скорости команды: Сохраняется ли стабильной скорость команды? Если истории часто возвращаются из-за отсутствующих элементов критерия готовности, скорость будет колебаться.
- Частота развертывания: Позволяет ли четкий критерий готовности более плавному и частому развертыванию?
Часто задаваемые вопросы ❓
Вот наиболее распространенные вопросы, которые команды задают при внедрении этих стандартов.
В: Могут ли критерии приемки меняться во время спринта?
О: В идеале — нет. Если критерии приемки существенно меняются, это может указывать на то, что история не была хорошо понята на этапе уточнения. Небольшие уточнения допустимы, но значительные изменения объема должны привести к созданию новой истории или корректировке объема спринта.
В: Нужен ли каждой истории уникальный критерий готовности?
О: Нет. Критерий готовности является общим. Однако отдельные технические истории могут иметь дополнительные требования, добавленные в чек-лист для этого конкретного элемента, но базовый критерий готовности применяется ко всем.
В: Что делать, если команда не согласна с критерием готовности?
О: Организуйте обсуждение. Цель — достижение консенсуса. Если разработчик настаивает на требовании, которое не согласен с ним тестировщик, обсудите риск. Если риск низкий — отбросьте его. Если высокий — оставьте.
В: Насколько подробными должны быть критерии приемки?
О: Достаточно подробными, чтобы можно было проверить. Если инженер по тестированию может написать тест-кейс непосредственно из критериев приемки, значит, они достаточно детализированы. Если им нужно задавать вопросы — требуется больше деталей.
В: Может ли автоматизированное тестирование заменить ручное тестирование в критерии готовности?
О: Зависит от ситуации. Для критической логики — да. Для пользовательского опыта или визуальных элементов может потребоваться ручная проверка. Критерий готовности должен отражать лучшие практики обеспечения качества.
Заключительные мысли о качестве и согласованности 🌟
Внедрение критериев приемки и критерия готовности — это не бюрократия; это уважение. Уважение к пользователю, который ожидает рабочую функцию, уважение к разработчику, который хочет четких требований, и уважение к продакт-менеджеру, которому нужна уверенность в доставке.
Когда эти два понятия используются правильно, они создают общую лексику для команды. Они уменьшают необходимость постоянных встреч для уточнения. Они предотвращают накопление технического долга. И, что самое важное, они обеспечивают, что каждая завершенная история приносит реальную ценность продукту.
Начните с малого. Определите базовый критерий готовности. Напишите четкие критерии приемки для вашей следующей истории. Обсудите их на следующем ретроспективе. Со временем эти практики станут привычными, встроится в культуру вашей команды. Результат — стабильный поток высококачественного программного обеспечения, отвечающего потребностям людей, которые его используют.