Принятие спринта на обзорной встрече? И некоторые другие обзорные вопросы

Question

Моя компания внедрила новый процесс, чтобы команда отвечала за определение выполненного в спринте.

На собрании по проверке спринта РО впервые показывает работу, и перед каждой командой они просматривают каждую проблему, а затем комментируют проблему, например, "работает ли она как задумано. Если нет, то как? Дефект создан". ".

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

Проблема в том, когда ПО должно видеть работу? Когда мы принимаем / отклоняем спринт?

В настоящее время мы не проводим тестирование ПО в спринте по нескольким причинам:

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

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

Answer 1

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

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

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

Обратите внимание, что они рассматривают не тестирование. Несмотря на то, что владелец продукта не испытывает никакого вреда, проводя какое-либо тестирование, если его команда и владелец продукта считают это ценным

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