Как мы внедряли Scrum в команде из 20 разработчиков и прошли все пять стадий принятия

Немного контекста

Для тех, кто не очень знаком с терминологией, коротко поясню основные понятия.

Scrum — это набор правил, благодаря которым команда налаживает гибкий рабочий процесс. Разработка ведётся короткими итерациями (спринтами), у каждой итерации есть чёткая цель, а у каждого члена команды — понятные задачи.

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

Спринт — короткий рабочий цикл длиной до четырёх недель. Достаточно короткий, чтобы команда не теряла фокус, и достаточно длинный, чтобы выдавать значимый результат.

Бэклог — упорядоченный по приоритету список задач.

Story points — условная величина для оценки сложности задач.

Daily — ежедневная встреча длительностью не более 15 минут, на которой разработчики обсуждают прогресс и возникшие препятствия.

С чего всё началось

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

Проблемы с коммуникацией

У нас было одно собрание в неделю. Этого катастрофически не хватало. Руководители зачастую не понимали, кто какие задачи выполняет и какой они сложности. Взаимодействие между командами тоже хромало: некоторые решения можно было принимать на уровне компонентов, а не тащить на уровень продукта.

Но самая большая боль — расфокус разработчиков. Представьте ситуацию. Разработчик Вася приходит на работу, пьёт кофе, открывает задачу, садится работать — и тут к нему подходит кто-то из отдела маркетинга: «Срочно нужно вот это!» Потом кто-то из техподдержки. Потом ещё кто-то. За день к Васе могли подойти 10–15 раз. В итоге мы просто теряли Васю на весь день — он не мог сфокусироваться ни на одной задаче.

А ещё у нас не было инструмента, чтобы проговаривать проблемы, — и ребята их просто замалчивали. Всё это вело к тому, что не было ощущения команды, не было атмосферы единения. А ведь от этого напрямую зависит, с каким настроем мы приходим на работу.

Организационные проблемы

Вернёмся к Васе. К нему подошли, дали задачу из соседнего отдела. А с кого спрашивать результат? С техлида? С продакт-менеджера? С самого Васи? Непонятно. Границы ответственности отсутствовали.

Команда большая, и техлидам было сложно отслеживать рост сотрудников. Одно собрание в неделю — это, по сути, отсутствие регламентов как таковых.

Стратегические проблемы

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

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

Пять стадий принятия Scrum

1. Отрицание

На старте было совершенно непонятно, как Scrum вообще сможет нам помочь. И сможет ли.

В идеальном Scrum команда — это 7–10 человек. У нас — 20, с разным стеком и уровнем подготовки. Кроссфункциональности нет, задачи из общего бэклога «сверху вниз» просто брать невозможно. Добавьте к этому здоровый скепсис: мы все боимся нового. Веры в то, что Scrum поможет, не было.

2. Гнев

Многие ритуалы вызвали негатив. Мы начали с системы оценки задач от 1 до 10 — и сразу столкнулись с проблемой: чем сложнее задача, тем труднее определить её вес. Это семёрка или восьмёрка? А может, девятка?

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

Отдельная головная боль — взаимодействие с другими отделами. Приходилось обозначать границы и объяснять, как теперь нужно работать с нашей командой.

3. Торг

На этой стадии мы начали дорабатывать Scrum под себя.

• Правила команды. Например, каждый спринт обязательно включает написание части технической документации и тестирование каждой фичи.
• Числа Фибоначчи вместо шкалы 1–10. Мы перешли на последовательность 1, 2, 3, 5, 8, 13, 21, 40. Чем сложнее задача, тем проще определить её вес — разница между соседними значениями становится очевиднее.
• Индивидуальные бэклоги. Поскольку команда не кроссфункциональная, у каждого разработчика появился свой приоритезированный список задач внутри общего бэклога.
• Жёсткие тайминги. Для каждого собрания установили чёткие временны́е рамки. Если ребята не укладываются — мягко, но настойчиво закругляю.

4. Депрессия

Это стадия, на которой любой скрам-мастер задаётся вопросом: «А правильно ли мы сделали, что внедрили Scrum?» Я долго ругала себя за то, что не получилось сделать «как по учебнику». Ребята, наверное, тоже думали: «Может, вернёмся к тому, как работали раньше?»

5. Принятие

В какой-то момент я поняла важную вещь: не нужно делать «как правильно» — нужно делать так, как нужно именно нам.

К концу третьего спринта у нас выработалась чёткая методология. Мы привыкли к новому ритму, проговорили алгоритм взаимодействия с другими отделами, а ребята стали ответственнее готовиться к собраниям.

Как выглядит наш процесс сейчас

Спринт длится три недели и строится так:

Планирование. Все задачи приоритизирует продакт-менеджер — они проходят строго через него. Если прилетает срочная задача, она тоже идёт через продакта: разработчик берёт её в работу, а последнюю задачу из своего бэклога переносит на следующий спринт.

Оценка задач. Проводим дважды за спринт — в начале и в конце (дооценка). Используем покерное планирование: каждый открывает бесплатный онлайн-инструмент, обсуждаем задачу, голосуем. Если оценки расходятся больше чем на один шаг, я опрашиваю ребят с крайними оценками, они аргументируют свою позицию, и мы перезапускаем голосование — до тех пор, пока не придём к консенсусу.

Канбан-доска. Три колонки: новые задачи → на тестировании → готово к выпуску.

Daily. Каждый день, 15–20 минут. Ребята рассказывают, что сделали и есть ли проблемы.

Демо. В конце спринта команда показывает, что реализовала: какие баги устранили, какой функционал расширили.

Ретроспектива. Мой любимый ритуал. Я рассказываю, сколько story points команда закрыла за спринт. Разработчик с наибольшим количеством очков получает кубок переходящего дракона 🐉.

И ещё одна отличная традиция: приносить на ретроспективу что-нибудь сладкое — торт или пирожные. Когда человек жуёт, он меньше фильтрует то, что говорит, и обратная связь получается честнее. Однажды я принесла торт, а на следующей ретроспективе — нет. В графе «недостатки спринта» все написали: «Отсутствие торта». Теперь торт — обязательная часть процесса 😄.

К чему мы пришли

Вот что изменилось:

✅ Наладилось взаимодействие внутри команды и между командами. Ребята стали больше общаться и высказываться.

✅ Появились границы ответственности. Продакт-менеджер отвечает за развитие продукта, команда — за реализацию задач. Никто больше не идёт напрямую к Васе.

✅ Story points дали прозрачность. Мы увидели, кто сколько и какой сложности задач выполняет. Это, кстати, позволило пересмотреть зарплаты некоторым сотрудникам.

✅ Появилось предсказуемое планирование. У нас есть среднее значение очков, которое команда выполняет за спринт — это позволяет планировать развитие продукта на будущее.

✅ Команда видит картину целиком. В начале года продакт-менеджер представил Road Map продукта — у всех появилось понимание, куда мы движемся и что нужно нашим клиентам.

✅ Улучшилась атмосфера. Ребята сами инициировали ежедневную традицию — в 16:00 идут вместе подтягиваться на турник. Мелочь, но она говорит о многом.

✅ Ушла текучка кадров. Команда стала стабильной. Чтобы не быть голословной: я проводила анонимный опрос внутри команды — никто не сказал, что хочет вернуться к старому подходу. Практически все отметили, что продукт стал качественнее.

Главный вывод

Не бойтесь адаптировать методологию под свою реальность. Scrum «по учебнику» нам не подошёл — и это нормально. Важно взять саму суть: прозрачность, регулярную обратную связь, чёткие ритуалы — и подстроить всё остальное под свою команду.

Ну и не забывайте про тортик на ретроспективе. Проверено — работает.