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

Практика показывает, что 0 спринт - никогда не успевают закончить за 1 неделю, и всегда возникает куча новой информации, которой на момент 0 спринта - люди не владели. Это может полностью изменить концепт, например, выяснилось, что в компании есть некий сервер, который просто стоит без дела, и он локальный, и теперь хотят все на нем. Поэтому, наличие этого спринта указывает на то, что в компании уже начался процеcс структуризации знаний :)

Цель данного спринта очень простая - команда должна захотеть работать по новым методикам. Необходимо объяснить людям - почему это важно, что будет получено в конце, как будет выглядеть результат, какой профит от этого получат разработчики, тим лиды, архитекторы, QA инженеры и т.д. И для того, чтобы это не была голая теория - мы будем делать это все практически.

Если после первого спринта, компания и команда решили целиком перейти на EDT, то может быть приобретен отдельно курс по EDT + GIT.
Прохождение курса займет около 20 часов.
После прохождения курса - разработчики уже четко будут понимать как работать с git и EDT, поэтому этот спринт - это консультации по вопросам курса.

После применения практик на легких задачах - начинаем усложнение. Теперь уже разработчики должны перейти на разработки по GitHub flow, CI контуры должны начать уже выполнять анализ первых запросов на слияние. QA инженеры должны следить за этим и проверять актуальность тестов после разработки.

После второго спринта - эйфория немного поубавится, и если на старте речь обычно идет о том, что компания хочет идеальный код, идеальное покрытие тестами и много всяких других идеальных показателей. То к этому спринту - люди осознают свои возможности, возможности своего оборудования и начинают приходить к компромисcам.
И задача этого спринта - зафиксировать правила игры, по которым будет работать компания. Например - не будет приниматься работа до тех пор, пока код не будет покрыт на 80% тестами. Или компания пока решила отключить часть правил анализа кода, так как они не критичны, а время тратить на их исправление - нет. И т.д.

Теперь уже команда понимает, что оказывается, у каждого разработчика есть свои всякие задачи, которые вписываются в парадигму DevOps. Например, ему лень постоянно разворачивать тестовую базу на своем рабочем месте, он хочет это автоматизировать. И тут, мы приходим к тому, что DevOps - это не должность, а это некий аналог философии работы, и что каждый участник процесса разработки (и не только) - является частью DevOps парадигмы.
И в этом спринте - мы знакомим всех со всеми этапами разработки/тестирования/поддержки контура и т.д.
Кроме этого - формируем роль релиз инженера, и готовим первые релизы через сервера сборок.

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

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