Требования к сбору с Scrum

Моя команда разработчиков работает над методологией Scrum, в значительной степени. У нас есть приоритетное отставание продуктов, которое мы разбиваем на спринты, отслеживаемые графиком сжигания.

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

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

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

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

Есть ли у кого-нибудь предложения по улучшению или опыт такого рода проблем?

Изменить: Это, вероятно, самый худший сценарий для нас - иногда требования довольно стабильны, и мы действительно используем Scrum правильно! Однако чаще мы видим этот сценарий в наших спринтах, поэтому я задал вопрос. Я знаю, что вышесказанное не является действительно правильным Scrum, это своего рода проблема:)

Ответ 1

Привлеките своих участников к схваткам; их привлечение приведет к "китайским шепотам" через менеджеров продуктов. Также им нужно отдать приоритет журналу back, а не разработчикам. Когда заинтересованные стороны находятся в схватках, они также видят последствия изменений лучше, и пока они не перестанут вносить изменения, у них будет более четкое представление о том, как их изменения влияют на итерацию.

об изменении требований; см. "Магический манифест"... "Обнимите изменения!"

Доброта,

Dan

Ответ 2

Да. И это важно: не принимайте изменения в рассказах после запуска спринта.

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

В некоторых случаях требования законно изменяются после запуска спринта. Здесь рассмотрим прерывание спринта. (Это должно привлечь их внимание.)

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

Подробнее см. Agile Project Management с помощью Scrum от Ken Schwaber.

Ответ 3

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

Пожалуйста, не называйте метод Agile или схватку.

Это просто безумие.

Если вы настраиваете вещи после запуска спринта, вы не делаете это правильно.

Вы включаете (действительно, свое ободряющее) плохое поведение. Если они не могут получить требования до, начинается спринт, у вас есть два варианта.

Подождите. Ничего плохого в этом. Это дешевле в долгосрочной перспективе.
Start. Однако. Поскольку требования фиксируются на время спринта, вы должны завершить спринт без "настройки". Изменения становятся частью отставания.
- Вы можете делать более короткие спринты.
- Вы можете просто отстать от настроек, пока не получите представление о том, что они вызывают собственные проблемы.

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

Ответ 4

У нас есть кто-то в команде, который отвечает за исправление требований от имени владельца продукта. Иногда у нас есть своевременные требования, иногда у нас есть некоторые доработки. QA принимает требования, рассмотренные формально в последних спринтах выпуска.

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

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

Ответ 5

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

Ответ 6

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

Я бы сказал, что ваш Scrum Master не выполняет свои обязанности Хранителя процесса. Почему он разрешает вам запускать спринт, когда у вас нет действующего товарного портфеля, чтобы выбрать свои элементы спринтерского отставания? У вас даже есть мастер Scrum?

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

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