В Scrum, где сидит деталь?

Question

Мы используем Scrum для нескольких проектов с переменным успехом, и теперь у меня есть запрос, связанный с документацией.

В Scrum у вас, очевидно, есть отставание продукта («Приложение начинается с воссоздания последнего документа, с которым работал пользователь».) И отставание задачи спринт («Реализовать экран забытого пароля»). Тем не менее, во всех примерах, которые я видел, эти два элемента довольно высокого уровня с точки зрения детализации (они разработаны в соответствии с записью после публикации).

Итак, где сидит деталь? Допустим, у клиента есть очень специфические требования к экрану управления запасами или сложный API, который необходимо интегрировать на задней стороне, где это документировано, как и кто фиксирует эту информацию? Разделяется ли она на отставание, но заполняется по принципу «точно в срок» или каким-то другим способом?

Answer 1

Sprint backlog

Спринт отставание является значительно подробный документ, содержащий информацию о том, как команда собирается выполнять требования для предстоящего спринта. Задачами являются , разбитые на часы без заданий более 16 часов. Если задание более 16 часов, оно должно быть . Задачи в спринтерских записях никогда не назначаются, скорее всего задаются членами команды , как им нравится.

Answer 2

Я понимаю, что определенные требования, такие как это, обрабатываются владельцем продукта. Они будут связываться с клиентом во время планирования Sprint 2 и обновлять задачи с определенными требованиями по мере необходимости - следовательно, владелец продукта является необязательным участником собрания Sprint Planning 2. Это дает вам гибрид «Just-in-Time» и «Sprint Planning 2». Все, что не удовлетворено к тому времени, когда вы приступите к работе над этой задачей, будет препятствием и должно быть рассмотрено ежедневной схваткой владельца продукта.

Поскольку разработка Agile при использовании Scrum, вы не должны находить слишком много проблем, требующих как можно скорее.

Answer 3

Деталь может находиться в вики, доступной для всей команды и редактируемой всей командой.

Answer 4

Не уверен, что это так просто, как кажется. Мы также видели проблемы с деталью. Допустим, если мы разрабатываем историю, которая требует захвата простой контактной информации, можно сказать, что CRM-система. Теперь у меня есть истории из ПО, и мы прошли совещание по планированию спринта и поняли первые 5 историй, которые соответствуют нашей скорости. Тем не менее, это всегда борьба за захват всех деталей разговора, например, как должен быть выложен экран, каковы 20+ полей, которые вам нужно иметь на экране, могут ли некоторые из этих полей искать информацию из других таблиц/просмотров и т. д. Кто записывает эти детали, должен ли он быть PO или разработчиком и какова наилучшая практика для хранения этих деталей. Мы сейчас пытаемся использовать wiki для этого, однако это становится накладными расходами при попытке сохранить элементы действия, кто должен обновлять данные и когда.