Сбор требований с [закрытой] толпой

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

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

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

Если вы настраиваете что-то после начала спринта, вы делаете это неправильно.

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

1. Подождите. В этом нет ничего плохого. В конечном итоге это дешевле.

2. Начать. Однако. Поскольку требования фиксированы на время спринта, вы должны закончить спринт без «доработки». Изменения становятся частью невыполненной работы.

   • Вы можете выполнять более короткие спринты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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