Как интегрировать QA в спринт [закрыто]
2 ответа
У обоих подходов есть свои проблемы, поэтому мне интересно, какие магазины выпускают каждый спринт?
На мой взгляд, конечной целью Scrum является выпуск нового инкремента после окончания спринта. Другими словами, результатом спринта является выпускаемый инкремент (а не выпущенный инкремент).
Таким образом, вариант № 1 кажется мне немного преждевременным (наши элементы бэклога продукта выполняются в конце спринта, но до демонстрации, и мы не включаем «выпуск в производство» в наше определение готовности, потому что это на самом деле не находится под нашим контролем, это работа другой команды).
И почему-то я думаю, что вариант № 2 означает, что вы не включаете все, что требуется для того, чтобы быть «ГОТОВО ГОТОВО» в ваше определение ГОТОВО. Я определенно не говорю, что это легко сделать, и, скорее всего, потребуется некоторое время, чтобы действительно включить все необходимые шаги для достижения выпуска в ваше определение готовности и внести необходимые организационные изменения для достижения Цель.
Лично я так и не на самом деле достиг такого уровня текучести (релизы в каждом спринте), и хотя часть контроля качества выполняется во время каждого спринта (IST, UAT), на самом деле мы выпуск каждые 4 спринта по 2 недели, последний спринт является своего рода релизным спринтом с «особыми» элементами бэклога продукта, такими как выполнение нагрузочных тестов, оптимизация при необходимости (хотя сейчас не так много неприятных сюрпризов), написание документации (для производства команда, для пользователей).Сокращение циклов релизов потребует более глубоких изменений, которые пока невозможны и в нашем случае нежелательны. Ваш контекст, конечно, отличается.
См. также
Смежные вопросы:
Это зависит от отрасли, рынка и многих других факторов. Однозначного ответа нет. Помните, что Scrum — это фреймворк, и он подходит не всем. Я чаще всего видел решение №1 в действии.
В конце спринта у вас должна быть потенциально готовая к выпуску версия продукта. Он очень хорошо работает в небольших стартапах или небольших компаниях. Это одно из их конкурентных преимуществ. QA людей можно легко включить в команду. Этого можно добиться в крупной корпорации, когда программное обеспечение не критично (решение №2).
Я внедрил скрам на крупном предприятии, где безопасность была критически важной. Релиз после спринта был невозможен из-за правил и сертификационных ограничений. Вам пришлось пройти долгий процесс выпуска, в котором должны были участвовать разработчики. Нам пришлось с этим поработать.
Но на большинстве софтверных заводов они могут выпустить после демоверсии и почти в один клик. Вы получаете всю мощь итерационной разработки, когда делаете это возможным, и это очень большое конкурентное преимущество.
С коммерческой точки зрения также рекомендуется не выпускать релиз в конце каждой итерации.