Как интегрировать QA в Sprint

Ответ 1

Оба подхода имеют свои проблемы, поэтому мне интересно, что делают большинство магазинов, которые выпускают каждый Sprint?

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

Таким образом, вариант №1 кажется мне слишком ранним (наши элементы отставания продукта выполняются в конце Sprint, но перед демонстрацией, и мы не включаем "выпуск на производство" в нашем определении "Готово", потому что это не находится под нашим контролем, это работа другой команды).

И как-то, я думаю, что опция № 2 означает, что вы не включаете все, что требуется для "DONE DONE" в вашем определении DONE. Я определенно не говорю, что это легко сделать, и, скорее всего, потребуется некоторое время, чтобы действительно включить все необходимые шаги для достижения освобождаемого в определении "Готово" и внести необходимые организационные изменения для достижения цель.

Лично я до сих пор не достиг такого уровня текучести (выпуская в каждом Sprint), и, хотя часть QA выполняется во время каждого Sprint (IST, UAT), мы фактически выпускаем каждые 4 спринта 2 недель, последний Sprint - это своего рода релиз Sprint с "специальными" продуктами Backlog Items, такими как выполнение нагрузочных тестов, оптимизация при необходимости (хотя сейчас не так много неприятных сюрпризов), написание документации (для производственной команды, для пользователей). Сокращение циклов выпуска потребует более глубоких изменений, которые не могут быть выполнены на данный момент и на самом деле не желательны в нашем случае. Конечно, ваш контекст конечно отличается.

См. также

• Ловушки QA во время Sprint?

Похожие вопросы:

• Лучшие практики QA/тестирования в Agile (Scrum + XP):
• Помогите мне понять, как работает QA в Scrum
• Лучшие способы для исправления ошибок в процессе Scrum?

Ответ 2

Это зависит от отрасли, рынка и множества других факторов. Единого ответа нет. Помните, что Scrum является структурой и он не подходит для всех. Я больше всего видел решение # 1.

В конце спринта вы должны иметь потенциально выпускаемую версию продукта. Он отлично работает в небольших стартапах или небольших компаниях. Это одно из их конкурентных преимуществ. QA люди могут легко попасть в команду. Это может быть достигнуто в крупной корпорации, когда программное обеспечение не критично (решение № 2).

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

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

Это также хорошая практика не выпускать в конце каждой итерации в коммерческой точке зрения.

Ответ 3

Если я могу смиренно предположить, что вы в индустрии программного обеспечения, ответ на ваш вопрос или решение вашей проблемы будет заключаться в использовании Enterprise Scrum Model с твердым планом выпуска проектов и планом сроков проекта.

Должна быть команда Scrum Operations Support, которая может включать администратора БД, администратора сервера приложений, старших сотрудников QA и старших аналитиков поддержки производства. Эта команда может следить за полной регрессией и нагрузочным тестированием QA, управлением выпуском, развертыванием кода и другими операциями поддержки для команд Scrum Development. С другой стороны, группы разработчиков Scrum просто выпускают выпущенное программное обеспечение и помещают его на полку для группы поддержки операций.

В этом конкретном сценарии ваша группа поддержки операций будет иметь Backlogs в своем списке Backlog продукта, чтобы выполнять регрессионное тестирование и тестирование нагрузки для отложенного продукта, созданного командой разработчиков. Примечание. Регрессия в идеале должна быть частью процесса разработки!!!

Теперь организациям, выпускающим каждый Sprint, необходимо, чтобы операционная группа отставала на неделю или 2 от команды разработчиков, поэтому, например, если команда Scrum Development Team работает над кодом версии 2.0, группе поддержки Operations необходимо развернуть код версии 1.0 который команда разработчиков закончила "стеллажи" 2 недели назад.

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

Ответственность за координацию сроков и организацию отставания в соответствии с временными рамками проекта будет в основном лежать на плечах ПО и отменить СМ, который отвечает за подготовку ПО, как максимально эффективно выполнять эту работу. Таким образом, простой ответ = 2 недели - это хороший разрыв между командой разработчиков и оперативной группой, выполняющей QA или мероприятиями по выпуску, но сроки и пробелы должны быть скорректированы в соответствии с потребностями проекта.

Если вам нужна дополнительная информация об этом, пожалуйста, спросите. Разговор, чтобы обсудить это, было бы намного легче объяснить, но я надеюсь, что это ответит на ваш вопрос. И, кстати, освобождение (до PROD) на следующий день после того, как Спринт закончился, команда разработчиков - плохая идея, но вы всегда можете попробовать ее и проверить и адаптировать;) и 1 неделя - достаточно хороший пробел, но зависит насколько велико ваше приложение и насколько велики ваши данные, а также сколько у вас ресурсов.

Спасибо, Сид Теланг. Сертифицированный мастер Scrum

Ответ 4

Я понимаю, что в конце спринта важно "сделать", а не выполнять "технический долг" в другом спринте, где люди могут переработать предыдущее выпущенное программное обеспечение.