Моя команда разработчиков работает над методологией Scrum, в значительной степени. У нас есть приоритетное отставание продуктов, которое мы разбиваем на спринты, отслеживаемые графиком сжигания.
Проблема заключается в том, что менеджеры продуктов (которые собирают требования от заинтересованных сторон) дадут нам краткое описание требований, скажем, за несколько дней до начала спринта или набора спринтов.
Затем мы просматриваем их, пересматриваем их с возможными (технически и в разумные сроки). Это отправляется для проверки руководством, другими управляющими продуктами и заинтересованными сторонами и обычно пересматривается/корректируется дальше, что, как правило, продолжается по кругу, пока оно не успокоится.
Между тем, датой начала спринта на нас, и мы начинаем хвататься за требования, которые мы уверены, являются стабильными. Как только это будет сделано, мы останемся с бесконечными днями настройки кода, так как требования немного сдвинутся.
Хотя я знаю, что требования не следует считать фиксированными, я просто чувствую, что мы плохо справляемся с этим, и стараемся подходить к подходу к требованиям водопада к гибкому развитию.
Есть ли у кого-нибудь предложения по улучшению или опыт такого рода проблем?
Изменить: Это, вероятно, самый худший сценарий для нас - иногда требования довольно стабильны, и мы действительно используем Scrum правильно! Однако чаще мы видим этот сценарий в наших спринтах, поэтому я задал вопрос. Я знаю, что вышесказанное не является действительно правильным Scrum, это своего рода проблема:)