Business Analyst Blog: Критерии готовности VS Критерии приёмки

Что-то за последнее время я часто возвращаюсь к дискуссии о «Критериях готовности« (done criteria) и их отличии от «Критериев приёмки» (acceptance criteria). И в отдельных командах, с которыми я работаю, и на тренингах, люди поднимают похожие вопросы. Для меня, обычно, это повод написать пост.

Если высказать свою точку зрения коротко, то, как говорят в Одессе: «Это две большие разницы» :-).

О «Критериях готовности» говорят почти всегда, когда рассказывают о внедрении в Scrum. Хотя не всегда вдаются в подробности, и это порождает волну вопросов позже, когда люди начинают пробовать и «примерять» Скрам на себя. В реальности, ответ не такой однозначный в силу того, что русский перевод фраз «Acceptance criteria» и «Done criteria» может звучать очень похоже. Даже Хенрик Книберг (который, кстати, будет на AgileEE 2010) в своей популярной книге “Scrum and XP: from the trenches” был достаточно туманен, и это отразилось в русском переводе книги такой же неоднозначностью.

Конечно, если говорить философски, то и для одной отдельной Истории Пользователя (Фичи, требования, пожелания, какой_там_термин_вы_используете) нужно определить, когда она сделана/готова. Хенрик предлагает называть всё термином «Как продемонстрировать» (How to demo), хотя многие возмущаются, мол, у нас не демонстрируемая функциональность: «мы пишем сервисы» или «API для разработчиков». По схожей причине многие не любят термин «Критерии приёмки» (Acceptance Criteria), так как не у всех выполняется приёмочное тестирование заказчиком. Лично я люблю термин Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction). Хотя, всё-таки, чаще всего используют Acceptance Criteria – давайте понимать его в широком смысле слова.

«Критерии приёмки» нужны нам для проверки каждой отдельной Истории Пользователя (фичи и т.п.) и подтверждения, что после реализации система работает, как этого хотел заказчик. Такие критерии будут почти уникальные для каждого элемента бэклога (Product Backlog Item) и должны уточняться, перед тем как команда возьмёт тот или иной элемент в итерацию (спринт).

Когда же речь заходит о результатах целой итерации (спринта), то тут уже стоит вопрос о том, что вся новая функциональность не просто сделана, а ещё и потенциально готова к передаче пользователям, ну или хотя бы демонстрации заинтересованным лицам. Вот тут-то на сцену и выходит термин «Критерии готовности» (Done Criteria или Definition of Done). «Критерии готовности» включают в себя ряд действий, которые нужно выполнить для того, чтобы сократить дополнительные действия между тем, когда команда говорит «мы сделали», и заказчик говорит «заверните, я беру». Если между этими двумя моментами вам нужно сделать ещё много телодвижений, то задумайтесь о том, каков же «Definition of Done» в вашей команде :-).

Поскольку почти все шаги «критериев готовности» должны быть выполнены для каждого элемента в бэклоге, то чаще всего говорят о простом проверочном списке. Важно помнить, что эти критерии применяются ко всем элементам бэклога, которые были сделаны в спринте. Хорошо бы спросить об идеях ваших тестировщиков и заказчиков, и тогда вы будете выпускать «потенциально готовый продукт» максимально подходящий к вашей ситуации.

Если у вас команда, которая работает над долгосрочными выпусками стабильной версии (т.н. релизами), то, скорее всего, у вас будут критерии ещё более высокого уровня. Их можно назвать «критерии готовности выпуска» (Definition of Done for a Release). Эти критерии повлияют на планирование всего выпуска, и о них нужно помнить постоянно и не откладывать на последний момент.

Простой мозговой штурм позволит вам сделать список из 3-10 элементов, которого будет более чем достаточно. Такой список пригодится и для планирования итерации и, если есть отдельный список, то и для всего выпуска. Ведь необходимо запланировать ровно столько функциональности, сколько вы успеете сделать согласно всем пунктам проверочного листа с «критериями готовности». Будьте реалистами