Отделение "Что" от "Как" - Проектирование в гибкой среде [закрыто]

Question

Как в гибкой среде (scrum) заставить руководство продукта создавать достаточно небольшие элементы невыполненной работы или истории, не заставляя их выполнять весь дизайн, который не является их специализацией?Другими словами, как вы отделяете "что" (бизнес-требования) от "как" (дизайн) в гибкой разработке?

Answer 1

С помощью scrum управление продуктом должен быть один человек:тот самый владелец продукта .

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

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

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

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

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

Answer 2

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

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

Что вы всегда должны иметь в виду, когда пишете истории пользователей или помогаете своему руководителю в написании ваших пользовательских историй, так это то, что эти истории должны быть ИНВЕСТИЦИОННЫМИ. Янезависимый, Nэгоистичный, Vдоступный для клиентов, Eстимулируемый, Sторговый центр и Tустойчивый.

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

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

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

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

В приведенном выше примере возможны два приемочных теста:

"Тест для голосования за ответ"

"Тест на отклонение ответа голосованием"

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

Answer 3

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

Answer 4

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

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