Разделение чего и как-дизайн в среде Agile

Первое, что вы должны сделать, и это является причиной большого количества неудачных проектов Scrum, - это научить ваше управление продуктом играть роль владельца продукта. Вы должны показать ему, что он несет ответственность за ROI проекта, и для этого он несет ответственность за приоритетность stories/itens/business потребностей/функций или того, что вы используете для составления своего отставания по продукту таким образом, что наиболее ценные iten имеют более высокие приоритеты.

Я выступаю за использование пользовательских историй в качестве бэклога продукта, а затем, при планировании спринта, разбиваю на более мелкие задачи истории, выбранные для составления бэклога спринта.

То, что вы всегда должны иметь в виду, когда пишете или помогаете своему PO писать, ваши пользовательские истории-это то, что истории должны быть INVEST. I ndependent, N egotiable, V aluable к клиентам, E stimatable, s mall и T estable.

Я думаю, что в начале использования шаблона ниже может быть полезно, чтобы держать PO сосредоточены на бизнес-целей:

"Как-тип пользователя-я хочу-какую-то цель-так что-какая-то причина-."

Один пример истории был бы "как пользователь stackoverflow, я хочу проголосовать за ответ, чтобы можно было легко найти самый ценный ответ."

Не забудьте сделать запись PO или определить приемочный тест для каждой истории вашего Sprint Backlog, поскольку он может использоваться в качестве основного критерия для определения того, полностью ли реализована история.

К примеру выше, два возможных приемочных испытания являются:

"Test to vote up a answer"

"Test to Vote Down a answer"

С этой историей и двумя приемочными тестами команда знает, что пользователь stackoverflow может голосовать за ответы и обновлять статус истории do Done, необходимо, чтобы система позволяла пользователю голосовать вверх и вниз по ответу без исключения.

В scrum управление продуктом должно осуществляться одним человеком: владельцем продукта .

То , что вы хотите сделать, делается во время планирования спринта, где должна присутствовать вся команда (product owner, scrummaster, developers).

То, что должно быть определено как пользовательские истории владельцем продукта . Пользовательские истории должны быть высокого уровня, ограничивая владельца продукта, чтобы выразить бизнес-требования в одном предложении истории должны сделать трюк .

напр. Как пользователь StackOverflow, я хотел бы видеть свою репутацию

Одной из целей планирования спринта является определение историй, которые должны быть сделаны во время спринта. Поэтому, когда истории выбираются владельцем продукта, команда может разделить их, кратко рассказать о дизайне (как) и оценить их.

В двух словах, что должно быть сделано владельцем продукта, как командой. Если этот процесс четко объяснен владельцу продукта,он не будет пытаться спроектировать все. Если он все равно попытается, мастер схватки остановит его.

Не забывайте, что элементы невыполненной работы по продукту должны быть оценены в порядке важности, используя систему взвешивания (простые числа, Фибоначчи,..), так что если у вас есть элементы в вашем отставании, которые имеют аналогичную важность (т. е. 2 элемента с весом 21), то они должны теоретически попытаться и быть вставлены в спринт впереди 13s и 8s.

Во время оценки отставания (ре) (после определения приоритетов) команда должна заниматься моделированием, чтобы понять всю полноту Пользовательской истории и иметь возможность точно оценить сложность. Это не полный объем моделирования, которое может иметь место (команды могут делать больше, занимаясь разработкой), но это отличное место для начала и сможет воспользоваться преимуществом клиента/владельца продукта, чтобы ответить на вопросы там и тогда.

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