Сценарий: у нас есть архитекторы, которые пишут спецификации и критерии приемлемости. Бизнес-специалисты и владелец продукта не предоставляют никаких документированных бизнес-спецификаций/логики, поэтому архитекторы пишут критерии приемки и обсуждают их с бизнес-специалистом и владельцем продукта на встрече.
Проблема: В то время как PO тестировал задачу (Тестирование владельца продукта, упомянутое в этом посте: Сообщение о тестировании владельца продукта , она обнаружила сценарий, который не работает. Но мы прочитали критерии приемлемости, и этот сценарий никогда не упоминался, и она хочет провалить задание.
Вопрос: Может ли заказ на покупку не выполнить задачу из-за того, что сценарий не был упомянут в критериях приемки?
Я бы сказал Нет! потому что это может привести к расползанию области.
Проблема:
Специалист по закупкам/бизнесу должен написать бизнес-логику/требования, чтобы, когда архитектор работает над спецификацией/критериями приемки, он мог учесть все сценарии.
Не отклоняйтесь от критериев приемки, потому что они могут добавлять всевозможные сценарии или запросы после разработки.
У вас не одна проблема, у вас их много. Помимо отсутствия межфункциональной команды, которая полностью сотрудничает, две самые большие проблемы процесса, по-видимому, заключаются в следующем:
Пока вы не решите обе проблемы, вы не используете Scrum. Что еще более важно, Скрам-команда будет оставаться недееспособной до тех пор, пока Владелец Продукта и Команда Разработки спорят друг с другом, а не тесно сотрудничают друг с другом.
Вся Scrum-команда (а не только владелец продукта) должна быть заново обучена тому, как на самом деле работает итеративная разработка. В Scrum у каждого Спринта есть одна цель (Цель Спринта), над достижением которой работает вся команда. Работа определяется по приоритетам Владельцем Продукта, отбирается и планируется для Спринта Командой Разработки, а затем завершенная работа демонстрируется заинтересованным сторонам на Обзоре Спринта. Обзор спринта также может быть местом для обсуждения того, почему цель спринта не была достигнута (если она не была достигнута), а также для сбора отзывов о продукте или обсуждения следующих шагов и будущих приоритетов с заинтересованными сторонами.
Во время планирования спринта Скрам-команда сотрудничает в следующих областях:
Если Scrum-команда выполнила свою работу во время уточнения невыполненной работы и правильно работает вместе во время планирования спринта, то владелец продукта не может «сдать» или «не сдать» работу. Это просто не является частью структуры и неприемлемой практикой.
На самом деле здесь происходит то, что Владелец Продукта, заинтересованные стороны или члены команды обнаруживают новую работу, которая ранее не была определена в Уточнении невыполненной работы или Планировании спринта. Замечательно! Далее должно произойти то, что недавно обнаруженная работа будет добавлена в Бэклог Продукта, чтобы Владелец Продукта мог уточнить и расставить приоритеты в качестве будущей работы для какого-то другого Спринта.
В итеративной разработке «расползание масштаба» не происходит, потому что новая открытая работа или новые требования не могут коренным образом изменить текущую ограниченную по времени итерацию. Вместо этого они становятся сырьем для мельницы, поскольку продукт продолжает постепенно увеличиваться с течением времени.
Единственным исключением является обнаружение чего-то, что ставит под угрозу текущую цель спринта. Если цель спринта не может быть достигнута, пока команда не вернется к чертежной доске, владелец продукта должен объявить о досрочном прекращении всего спринта и вернуться к планированию спринта. Это имеет видимую стоимость для проекта (видимость — это хорошо, стоимость — не так уж и велика), поэтому обычно лучше рассматривать новую работу как будущую работу, если только ее влияние не достаточно велико, чтобы оправдать затраты. Это решение владельца продукта, и принятие этого решения является фундаментальной частью его работы.
Кроме того, работа либо сделана , либо не сделана . Если это было сделано в соответствии с планом команды, выполнено в соответствии с определением выполненного и продемонстрировано в рамках текущего временного интервала, то нет возможности «провалить» или «отклонить» работу. Команда создала то, над чем работали все, и все согласились, что это необходимо, включая владельца продукта.
Если позже выяснится, что Скрам-команда построила что- то не то , то это проблема сотрудничества или коммуникации, которую следует решить на ретроспективе спринта. Исправление проблемы с процессом, скорее всего, потребует более тесного сотрудничества с заинтересованными сторонами, не входящими в команду, как со стороны владельца продукта, так и с членами команды разработчиков.
С другой стороны, если команда просто обнаружила новую работу или потребность в дополнительных доработках, то это здорово! Это то, что должны делать agile-фреймворки. Новая работа может быть расставлена по приоритетам и запланирована так же, как и любая другая работа в рамках.
Тодд А. Джейкобс
Руан