Моя компания внедрила новый процесс, согласно которому команда несет ответственность за определение готовности внутри спринта.
На собрании по обзору спринта PO впервые показывают работу, и они обсуждают каждую проблему перед командой, а затем комментируют проблему, например, «работает ли это так, как задумано. если нет, то как? Создан дефект.. ."
Много читая о Scrum, это не похоже на то, что «Scrum» должен был что-то делать, на самом деле многие ресурсы прямо говорят, что проводить собрание по обзору как собрание по приемке — это плохо, и оно должно быть связано с обратной связью.
Проблема в том, когда PO должен увидеть работу? Когда мы принимаем/отклоняем спринт?
В настоящее время у нас нет тестирования PO в спринте по нескольким причинам:
Опять же, это все предположения, которые мы сделали, поэтому любые мысли по этому поводу будут чрезвычайно полезны.
Это очень распространенная проблема. Короткий и прямой ответ заключается в том, что обзор спринта не должен быть первым, когда PO видит завершенные истории. PO должен просматривать истории сразу после их завершения в спринте. Это освободит обзор спринта, чтобы сосредоточиться на обратной связи.
В вашем вопросе есть еще три пункта, на которые стоит обратить внимание.
1) Если PO «тестирует» историю, возможно, он берет на себя слишком много работы.
В то время как PO, безусловно, рассмотрит и опробует новую функциональность, ответственность за техническое качество по-прежнему принадлежит команде. Если критерии приемлемости гласят:
Пользователь должен иметь возможность изменить свой адрес
Тогда я ожидаю, что PO изменит адрес, но не будет использовать специальные символы, отрицательные регистры, SQL-инъекцию и т. д. Команда должна быть уверена, что их работа завершена и соответствует ожиданиям по качеству, когда они просят PO подписать ее. . Мы надеемся, что это должно сделать просьбу PO о просмотре историй в спринте гораздо более практичной для вашей команды.
2) PO должен быть вовлечен в команду на протяжении всего спринта.
Это нормально для команды, которая в основном понимает вопрос пользовательской истории и проверяет PO по мере их продвижения. На самом деле, это почти наверняка произойдет в любом случае. Иногда вы не уверены, какие вопросы вам нужно задать, пока не начнете программировать и не столкнетесь с проблемой, поэтому вместо того, чтобы пытаться избежать этого сценария, мы должны вместо этого убедиться, что прояснение вопросов между командой и PO проходит легко и гладко.
Теперь ваше беспокойство небезосновательно. Можно злоупотреблять этой динамикой, и PO должен сообщить об этом, если он думает, что это происходит, но ожидается значительное количество обменов мнениями.
3) Присоединяются ли ваши заинтересованные стороны к вам для обзора спринта?
Это может быть именно так, как вы это описали, но похоже, что ваш Sprint Review на самом деле только между командой разработчиков и PO. На самом деле это должна быть вся команда Scrum (PO, SM и команда разработчиков), представляющая работу заинтересованным сторонам и собирающая отзывы от них.
На самом деле, в Scrum нет такой концепции принятия/отклонения Спринта. Спринт может, при определенных обстоятельствах, быть отменен до его завершения, но никто не может отказаться от спринта. Кроме того, спринт почти всегда состоит из выполненной и невыполненной работы, и это не зависит от суждения одного человека. Вот почему существует DoD: чтобы гарантировать, что видение того, что ожидается, ясно и разделяется командой.
Таким образом, обзор предназначен для того, чтобы подвести итоги ситуации, изучить проделанную работу и посмотреть, как это повлияет на работу, которую еще предстоит выполнить.
Вот что по этому поводу говорит путеводитель :
Обзор Спринта проводится в конце Спринта для проверки Инкремента и адаптации Бэклога Продукта, если это необходимо. Во время Обзора Спринта Скрам-команда и заинтересованные стороны обсуждают, что было сделано в Спринте. Основываясь на этом и любых изменениях в Бэклоге Продукта во время Спринта, участники совместно работают над следующими вещами, которые могут быть сделаны для оптимизации ценности. Это неформальная встреча , а не статусная встреча, и презентация Инкремента предназначена для получения обратной связи и содействия сотрудничеству .
Тем не менее, и если это необходимо, PO должен иметь возможность увидеть и протестировать потенциальное увеличение, как только оно будет сделано, и самым прозрачным образом.
Нет такой вещи, как «принятие спринта». Если вы сделали все, что нужно для отправки в производство, то ваш код принят и протестирован. Это в продукте.
Единственная цель обзора спринта — предоставить обратную связь.
PO должен работать с командой во время спринта и быть хорошо осведомленным о том, что было сделано, и о том, какие решения были приняты для достижения этого результата.
Приемочное тестирование не является частью обзора спринта. Это должно быть частью вашего определения готовности и интегрировано в сам спринт.
Здесь уже есть несколько других замечательных ответов, но я думаю, что нужно больше внимания уделять тому, как приемочное тестирование вписывается в структуру Scrum. Для этого стоит отметить несколько основных моментов:
Чего, по-видимому, не хватает в вашем текущем процессе, так это включения формальных приемочных тестов в определение готовности. Приемочное тестирование должно быть неотъемлемой частью самого Спринта, а не чем-то, что делается постфактум или путем захвата церемонии Скрама с совершенно другой целью, такой как Обзор Спринта.