— Наша разработка работает по Scrum, но мы транспонировали процесс — разные роли в разных спринтах, например: спринт разработки, спринт тестирования, спринт девопсов.
— Несмотря на то, что все эти фазы — часть разработки, у вас не Спринты сразу по многим причинам:
во-первых, в рамках спринта должны порождаться инкременты ПО, которые буквально можно использовать, принять решение об установке в пром.эксплуатацию или принять решение о необходимости продолжения исследования и модификации без релиза. Это правило — за спринт вы должны породить работающее ПО, пусть даже прототип;
во-вторых,
у спринта есть цель, связывающая всю команду и обязывающая слажено работать над ней. Эта цель в большинстве случаев бизнесовая, то есть требует реализации одного из сценариев, описанных, например, методом оформления пользовательских историй. Целью спринта не может быть "разработать по спеке", "протестировать то, что разработано" или "установить в прод то, что протестили";
в-третьих, основные задумки Scrum при его создании: понизить степень "бункеризации" и повысить интенсивность живой коммуникации для решения большей части задач в рабочем порядке, то есть забыть процесс, когда каждый этап разработки ПО осуществлялся в своём специализированном отделе/департаменте, а общение между ними было бюрократизировано и осуществлялось организацией больших собраний или пересылкой подробно оформленных "карточек"-задач и исчерпывающей документации.
Специализировать спринты под стадии процесса/конвейера разработки не просто противоречит определению Спринта, такой подход противоречит самой сути Scrum и культивирует то, с чем он призван бороться.