, и применим к ней критерии принятия:
• Дата доставки – всегда будет на следующий рабочий день после заказа.
• Если заказ был оставлен в субботу, то доставка будет в понедельник.
• Заказы на следующий рабочий день принимаются до трех часов по полудню.
• Клиент получает подтверждение о заказе по электронной почте.
• Все продукты в наличии доставляются по этим правилам.
• Мы сообщаем день заказа, но не точное время.
• У пользователя должна быть возможность оставить комментарий для курьера.
• Ожидаемый день доставки будет показан на экране при заказе.
Критерии принятия, написанные командой разработки, являются самым предпочтительным способом учесть все мелочи. Под руководством владельца продукта или бизнес-представителя команда может обсуждать пользовательские истории, устранять любые двусмысленности и определять конечный результат. Это лучший способ добиться согласованной работы, и эти обсуждения не должны быть длительными или трудоемкими. Их можно сделать как раз перед началом основной работы над проектом; цель состоит именно в том, чтобы начать с конца!
Кроме того, по критериям принятия можно отслеживать прогресс выполнения работ. Зачастую бизнесменов беспокоят расплывчатые фразы вроде «мы почти закончили» или «полагаю, мы на верном пути». Поэтому критерии принятия могут служить вехами на пути к завершению работ: мы реализовали половину из заявленных критериев принятия. Если критерии сформулированы должным образом, отслеживание прогресса будет легким – и все будут понимать, следует беспокоиться или нет.
Разделяя истории
Иногда в результате плодотворных обсуждений появляется очень много материала. Это хороший признак, не волнуйтесь и продолжайте записывать обсуждение. Некоторые идеи могут не подходить пользовательской истории, над которой вы сейчас работаете, или быть для нее слишком продвинутыми. Как только вы это поймете, сможете такие идеи отфильтровать и в дальнейшем добавить в более подходящие истории.
Другой подход заключается в том, чтобы написать новую историю – так называемое разделение историй. Типичный пример – ситуация, когда владелец продукта считает некоторые из критериев принятия необязательными и хочет выработать новую историю, включающую в себя дополнительные характеристики продукта. Как только новая история написана, она может быть включена в журнал требований (бэклог) вместе со всем остальным.
При написании историй очень важно знать, когда остановиться. Чем сложнее история, тем меньше вероятность того, что она будет полезна. Чрезмерно широкие критерии принятия – важный индикатор того, что что-то пошло не так. Обычно это значит, что историю
