Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Истории для команды разработчиков вытекают из невыполненной работы владельца продукта . Журнал ожидания продукта отслеживает все входные данные, которые владелец продукта имеет о направлении продукта от клиента, наряду с исследованиями, опытом тестирования, проектирования и инженерной обратной связи, которую владелец продукта получил.
В отличие от историй о незавершенном спринте, предметы для незавершенного производства не должны быть структурированы каким-либо определенным образом. Это потому, что их основная цель — позволить владельцу продукта отслеживать все необходимые функции. Эти элементы журнала невыполненных работ могут быть довольно расплывчатыми, пока они не превратятся в ясную историю разработки для журнала ожидания спринта. Элементы в журнале ожидания продукта всегда должны отражать последние мысли владельца продукта о долгосрочных целях продукта, в то время как команда работает над определенными функциями для текущего приращения.
Примечание. Задержка продукта является обязанностью владельца продукта.
В то время как владелец продукта может по своему усмотрению делиться всем журналом работы с командой на регулярной основе, ответственность за элементы здесь лежит на владельце продукта. Возможно, будет нецелесообразно постоянно напоминать команде об элементах в списке невыполненных работ продукта, которые не были затронуты в течение длительного времени, поскольку это отвлечет внимание от работы, необходимой для завершения текущего приращения.
В то время как многие владельцы продуктов предпочитают отслеживать элементы в бэклоге продуктов, как если бы они собирались стать финальными историями, не должно быть однозначного соответствия между элементами в бэклоге продукта и историями, которые делают его в спринте отставание. Функции и требования, которые владелец продукта должен отслеживать, могут превратиться в несколько историй, или несколько элементов могут быть объединены для создания единой истории соответствующего размера и масштаба для разработки.
Например, если клиенту необходимо добавить платежную систему на сайт, это может быть одна история для команды разработчиков или несколько историй. Могут быть истории разработчиков, посвященные созданию возможности принимать платежи через службу, и отдельные истории для приема кредитных карт, чеков или даже обслуживания системы токенов, чтобы покупки можно было совершать с использованием виртуальной валюты. Может быть возможно разработать каждый из них независимо, и запустить систему только с одним. Независимо от того, кто выйдет первым, возможно, потребуется нести вес реализации некоторых основных функций, которыми будут делиться все остальные.
Многие владельцы продуктов считают удобным отслеживать состояние элементов в бэклоге продукта, используя поэтапный процесс, в результате которого элемент переходит от идеи к дизайну и проверке инженерии, пока не будет готов к формулировке как история отставания спринта и добавлен к предстоящему спринту. , Владельцы продукта должны иметь четкое представление о том, что требуется для перемещения элемента из каждого состояния в другое, и это должно быть задокументировано, чтобы оно было согласованным для каждой истории.
Предупреждение: не пишите истории, пока они не будут готовы работать
Обычно владелец продукта ошибается, создавая истории разработки для элементов в бэклоге продукта слишком долго, прежде чем они будут готовы для включения в конкретный спринт. Элементы в списке продуктов должны оставаться достаточно расплывчатыми и достаточно гибкими, чтобы они могли адаптироваться к изменениям, возникающим в результате итеративного гибкого процесса разборки. Элементы незавершенного производства продукта, над которыми не работали недели или месяцы, могут легко устареть, и владельцы продукта могут легко забыть контекст, в котором они находились при написании истории, если она не была обработана вскоре после ее написания. Написание подробных историй слишком рано часто может быть пустой тратой времени владельца продукта и может привести команду к работе, которая может не соответствовать тому, что требуется в настоящее время.