Что-то за последнее время я часто возвращаюсь к дискуссии о “Критериях готовности” (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 элементов, которого будет более чем достаточно. Такой список пригодится и для планирования итерации и, если есть отдельный список, то и для всего выпуска. Ведь необходимо запланировать ровно столько функциональности, сколько вы успеете сделать согласно всем пунктам проверочного листа с “критериями готовности”. Будьте реалистами 🙂