Во многих российских ИТ‑компаниях Scrum используется близко к исходному фреймворку. Хотя форма и состав ритуалов могут отклоняться от базовой модели, ядро Scrum часто остается неизменным: инкрементальная разработка, короткие циклы, прозрачность, эмпирический подход и фокус на пользе для клиента.
В этой статье речь о тех практиках, которые хорошо прижились в российских командах: какие элементы фреймворка используются практически «как есть», какие упрощены или модифицированы, какие практики показали свою устойчивость и оказались легко тиражируемыми в разных компаниях и командах.
Что такое Scrum в российских ИТ‑компаниях
Scrum в современных российских ИТ‑компаниях обычно понимается, как удобный каркас для организации командной работы. Это некий понятный всем язык и набор устоявшихся практик, адаптированных под конкрентные команды, продукты и ограничения.
В основной массе компаний Scrum используется для управления разработкой продукта или, как минимум, ограниченного по времени и объёму проекта. В центре подхода — небольшая команда, работающая итерациями и регулярно показывающая результат заказчикам.
При этом терминология и базовые элементы фреймворка сохраняются близкими к исходным: бэклог, спринты, дейлики, роли владельца продукта и т. п. Именно вокруг этих понятий выстраиваются ритуалы, договорённости и настройки в конкретной компании.
Краткое определение Scrum
Scrum — это лёгкий фреймворк для управления разработкой продукта короткими итерациями (спринтами). Он опирается на:
- небольшие кросс‑функциональные команды;
- прозрачный и приоритизированный бэклог работы;
- регулярное планирование и пересмотр приоритетов;
- эмпирический подход: решения принимают на основе фактически полученных результатов и обратной связи, а не единожды составленного детального плана.
Как в реальности организованы команды
Классический Scrum предполагает одну кросс‑функциональную команду на продукт. В российских реалиях чаще всего применяются две модели:
- «один продукт — одна команда»;
- «один проект — одна команда».
Формально идея типичная для Scrum: есть понятный объект работы (продукт или проект) и есть команда, которая за него отвечает. Но реальные параметры команд заметно отличаются от того, что написано в учебниках.
- Вместо рекомендуемых 7±2 человек в команде нередко работает до 15–20 участников. В состав входят разработчики, тестировщики, аналитики, иногда — дизайнеры и DevOps‑специалисты.
- Роль Product Owner часто совмещается с другими ролями: её выполняет руководитель продукта, бизнес‑заказчик, реже — тимлид или проектный менеджер. Это влияет на скорость принятия решений и загрузку людей «управленческой» работой.
Общий тренд: названия ролей и событий сохраняются, но конкретное распределение обязанностей варьируется в зависимости от размеров команды, готовности участников принимать решения самостоятельно, профессиональных отношений внутри команды и т. д.
Как работает итерационная модель на практике
В практическом применении Scrum‑подобная модель работы строится вокруг повторяющихся итераций — спринтов.
Спринты
Спринт — это ограниченный по времени период работы, в течение которого команда реализует согласованный набор задач из бэклога. Обычно продолжительность спринта составляет от 2 недель до 1 месяца.
На начало спринта команда:
- формулирует цель спринта — какой ощутимый результат она хочет получить;
- выбирает задачи из бэклога в соответствии с приоритетами и собственной нагрузкой;
- фиксирует план на спринт в таск‑трекере.
В идеальной модели объём работ в спринте после старта не меняется. В реальной практике российских команд почти всегда допускаются корректировки:
- добавляются задачи по инцидентам и критическим багам;
- включаются срочные изменения по запросу заказчика;
- иногда часть менее приоритетных задач сознательно снимается, чтобы освободить место под более важные.
Важно, что спринт задаёт ритм: команда регулярно планирует, выполняет работу, показывает результат и на этом фоне принимает следующие решения.
Бэклог
Бэклог — это упорядоченный список задач по продукту или проекту. Сначала в бэклоге появляются крупные элементы (эпики, фичи), затем по мере приближения к разработке их «нарезают» на более мелкие задачи, пригодные для выполнения в рамках одного спринта.
В реальных командах бэклог редко бывает стабильным документом. С ним постоянно что‑то происходит:
- добавляются новые элементы по инициативе клиентов, команды или по результатам релизов;
- меняются приоритеты в зависимости от рыночной ситуации, внутренних ограничений, договорённостей с заказчиками;
- крупные задачи дробятся на более мелкие по мере того, как команда уточняет требования и подход к реализации.
Этот процесс часто называют грумингом, или уточнением бэклога. Важно понимать, что бэклог — это живой артефакт: он должен регулярно обновляться и отражать текущее представление о том, что действительно важно сделать.
Планирование, оценка и ежедневная синхронизация
Когда есть бэклог и длина спринта, включаются три опоры: оценка задач, планирование спринта и ежедневные собрания.
Story Points — это условные единицы относительной трудоёмкости задач. Они помогают сравнивать задачи между собой, учитывая не только объём разработки, но и неопределённость, риски, согласования и зависимости от других команд.
Чаще всего используют ряд Фибоначчи: 1, 2, 3, 5, 8, 13… Story Points позволяют оценивать задачи без привязки к часам и планировать объём работы на спринт по средней «ёмкости» команды.
Как использовать Story Points
Story Points — это относительный показатель трудоёмкости. Для оценки трудоемкости задачи в условных единицах нужен эталон — такая задача, которая хорошо понятна всей команде, не слишком простая, но и не слишком сложная, без явных зависимостей. При оценке трудоемкости команда будет отталиваться от эталанной задачи, которой присваивается определенное количество сторипойнтов. Например, вот эта задача в 2 раза сложнее эталонной — начисляем ей 5 очков. Другая задача наоборот в 2 раза проще эталонной — начисляем ей 1 или 2 очка.
Планирование спринта
На планировании команда:
- берёт из бэклога задачи по приоритету, пока не наберёт объём, который обычно успевает;
- уточняет формулировки и критерии приёмки;
- при необходимости переоценивает задачи.
В результате приоритизированный, но сырой список превращается в конкретный план на ближайший спринт.
Ежедневные собрания (дейли)
Дейли — короткая ежедневная встреча для синхронизации и выявления препятствий в рамках одного спринта.
После дейлика задачи могут перераспределяться, приоритеты — уточняться, срочные баги — оперативно попадать в спринт. Формат варьируется: от классических 15‑минутных стендапов до более свободных созвонов, но сама привычка кратко синхронизироваться по работе закрепилась почти везде.
Подведение итогов спринта и обратная связь
По завершении спринта команда подводит итоги:
- какие задачи завершены, а какие перенесены на следующий спринт или в общий бэклог;
- достигнута ли цель спринта;
- что конкретно готово к показу стейкхолдерам.
Часто это совмещают с демонстрацией результата (review):
- команда показывает реализованный функционал владельцу продукта и другим заинтересованным сторонам;
- собирается обратная связь: что получилось, что нужно доработать, нужно ли менять приоритеты;
- по итогам уточняются направления работы на следующие спринты.
Именно здесь эмпирический подход становится практикой: решения о будущем принимаются, опираясь на фактический результат и отзыв стейкхолдеров, а не на планы, составленные месяцами ранее.
Измерения и визуализация прогресса
Velocity (скорость команды)
Velocity — это объём работы, выполненный командой за спринт, обычно в сторипойнтах. На практике этот показатель используют как ориентир для:
- понимания, сколько условных единиц работы команда реально успевает за спринт;
- более точного планирования объёма задач в следующих спринтах;
- отслеживания динамики: не произошло ли резкое падение или рост, которые требуют отдельного анализа.
В устойчивой практике velocity рассматривают как индикатор, а не как KPI для давления на команду. Его задача — помогать планировать, а не устраивать «соревнования» между командами или внутри одной команды.
Burndown‑чарты
Burndown‑чарт — это график, который показывает, как уменьшается оставшийся объём работы в спринте (или по релизу) по мере его выполнения. Он помогает визуально оценить:
- идёт ли команда в темпе, соответствующем плану;
- не накапливается ли «хвост» незавершённых задач;
- когда именно начались отставания — в начале, середине или в конце спринта.
Во многих компаниях burndown‑чарты строятся автоматически средствами таск‑трекера, и команда просто периодически смотрит на них в ходе спринта или на его завершении.
Что остаётся опциональным и роль таск‑трекеров
Не все элементы «классического» Scrum используются регулярно и в полном объёме.
Наиболее распространённые отклонения:
- митинги и стендапы могут проходить в упрощённом, сокращённом или нерегулярном формате;
- роль Scrum‑мастера часто отсутствует как отдельная позиция — его функции распределены между тимлидом, продакт‑овнером или проектным менеджером.
При этом почти везде опорой для применения фреймворка становятся таск‑трекеры (Jira, Trello, Timetta Tasks и др.). Через них планируют спринты, ведут и уточняют бэклог, отслеживают загрузку команды, анализируют скорость и динамику выполнения задач.
Типичная модель применения в компаниях
Если собрать всё вместе, общая схема работы в большинстве команд выглядит так:
- Формируется дорожная карта продукта или ключевые этапы проекта.
- Определяются приоритеты: что важно сделать в первую очередь, что может подождать.
- Крупные элементы (эпики, фичи) декомпозируются на более мелкие задачи, которые попадают в бэклог.
- Бэклог регулярно уточняется (груминг): задачи конкретизируются по мере приближения к спринту, устаревшие или нерелевантные элементы убираются или перерабатываются.
- На планировании спринта команда выбирает задачи из бэклога, оценивает их в сторипойнтах и формирует план на ближайший спринт.
- В ходе спринта проводятся дейлики для синхронизации, выявления препятствий, уточнения приоритетов внутри уже набранного объёма, добавления задач по багам и инцидентам.
- В конце спринта проводится закрытие: фиксируются результаты, анализируются отклонения от плана, на основе этого корректируются бэклог и ожидания по следующим спринтам.
При всём разнообразии деталей, устойчивым ядром остаются понятные и привычные для команд элементы: бэклог, спринты, сторипойнты, дейлики, velocity, burndown‑чарты и работа через таск‑трекеры. Именно вокруг них дальше выстраиваются остальные настройки фреймворка и адаптации под реальную практику.
