В Scrum кто проверяет «Готово»?

Я являюсь менеджером QA / Test в своей организации и до сегодняшнего дня проверял качество программного обеспечения (написанные и выполненные тесты и исправленные ошибки). Кто это проверит в Scrum? Откуда мне знать, что команда написала и выполнила все правильные тесты? С другой стороны, я боюсь, что если я продолжу проверку, команда не будет чувствовать себя достаточно уполномоченной. Но мне нужен некоторый процесс проверки, что «Готово» действительно «Готово». Что ты посоветуешь?

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

Но чтобы уменьшить вероятность того, что что-то ускользнуло, имеет смысл иметь правило, согласно которому проверку «выполненного» чаще всего выполняет кто-то, кроме человека, который реализовал элемент, или назначенного парня, отвечающего за обеспечение качества, такого как вы (но это может привести к тому, что вы узкое место).

Если есть сомнения, обсудите это с командой и Scrum Master и решите вместе.

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

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

Поэтому, в конечном счете, команда должна определить, что значит «сделано». У организации могут быть стандарты, и у разных заинтересованных сторон будут свои собственные требования. Скрам-мастер или соответствующие менеджеры обычно несут ответственность за сопоставление и применение списка.

В вашем примере, как менеджер QA / Test, вы тот, кто говорит, завершены ли тесты. Однако вы можете быть не лучшим человеком, который скажет, был ли проверен код, соблюдены ли требования безопасности, продукт интернационализирован, документация завершена или что-либо еще считается «выполненным».

Единственное понятие «сделано» - закончена ли история в целом. Команда должна была создать определение выполненного, которое говорит, когда они чувствуют, что история закончена или нет. Обычно это такие вещи, как «код проверен», «проведены ночные тесты», «все критерии приемлемости выполнены» и т. Д. Когда эти действия выполнены, команда может быть уверена, что они сделали все ожидается, что они закончат рассказ.

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

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

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

Первый вопрос, который вы должны задать себе

Вы Скрам Мастер ? Если да.

В Scrum процессы контролируются и управляются Scrum Master.

Как ты делаешь это:

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

В каждом Спринте Рабочие элементы извлекаются из журнала ожидания продукта и направляются владельцем продукта. Каждый из них также будет иметь критерии проверки.

Теперь в Скраме требования не меняются после начала спринта. В конце Спринта вы можете анализировать проверку в соответствии с критериями для каждого выполненного элемента.

Если это сделано, можно найти только по ответу владельца продукта.

Помните, что в Agile вы «принимаете перемены» даже на поздней стадии разработки

Команда решает. Я использую контрольный список для того, что считается «Готово». Что «Готово» для истории, для спринта, для выпуска.

Как уже упоминали другие, в конечном итоге решение остается за владельцем продукта.

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

Проект, над которым я работаю, требует экспертной оценки изменений кода и требует, чтобы тот, кто написал код, либо предоставил / обновил регрессионные тесты, либо объяснил, почему это невозможно сделать. (Они и их рецензенты также должны подтвердить, что они проверили наличие известных недобросовестных действий. Мы, как правило, намного счастливее, если они могут показать, что они выполнили полный набор тестов и получили чистый результат (или чистый по модулю известный по крайней мере, открытые проблемы) Затем код должен выдержать интенсивное автоматизированное модульное и функциональное тестирование на нескольких платформах, чтобы продемонстрировать, что он не вызывает каких-либо регрессий против них, и он дополнительно проверяется на наличие общих антипаттернов с помощью автоматизированной системы анализа кода. затем мы принимаем его в основной поток разработки и помечаем рабочий элемент как завершенный.

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