Спринт в мобильной разработке: суть, длительность и планирование

Что такое спринт в разработке?

Спринт — это временной интервал (timebox) фиксированной длительности, в конце которого команда предоставляет готовый к использованию инкремент продукта. Концепция спринта — основа Scrum, но используется и в других Agile-фреймворках. В мобильной разработке инкремент — это билд приложения, который можно установить на устройство, протестировать и показать стейкхолдерам. Спринт нельзя продлить — если задачи не выполнены, они переносятся в следующий спринт.

Ключевая особенность спринта — фиксированная длительность. Команда не меняет цель спринта после утверждения. Это даёт предсказуемость: стейкхолдеры знают, когда получат результат. Внутри спринта команда сама решает, как распределить работу. Scrum Master защищает команду от внешних вмешательств — новые задачи не добавляются в текущий спринт. По данным Scrum Guide 2025, это единственный способ сохранить устойчивый темп разработки (sustainable pace).

Спринт состоит из четырёх обязательных событий: Sprint Planning (планирование), Daily Scrum (ежедневная синхронизация), Sprint Review (демонстрация результата), Sprint Retrospective (анализ процесса). Между ними — основная работа: реализация задач, тестирование, код-ревью. Продолжительность каждого события прямо пропорциональна длине спринта: для 2-недельного спринта Planning — 4 часа, Review — 2 часа, Retro — 1.5 часа, Daily — 15 минут. Суммарно ритуалы занимают около 8 часов на спринт — 10% рабочего времени команды.

Scrum-ритуалы спринта

Scrum-ритуалы (церемонии/события) — структурированные встречи команды в рамках спринта. Sprint Planning — в начале, Daily Scrum — каждый день, Sprint Review и Retrospective — в конце. Все события имеют timebox (ограничение по времени). Scrum Master следит за соблюдением timebox и фокуса. На каждом ритуале участвует вся Scrum-команда: Product Owner, Scrum Master, разработчики. Исключение — Daily Scrum (участвуют только разработчики, PO и SM — опционально).

Связь ритуалов с этапами спринта: Planning задаёт направление (что и как делаем), Daily синхронизирует (кто что делает, какие блокеры), Review показывает результат (что сделали, что нет), Retrospective улучшает процесс (как сделать следующий спринт лучше). Пропуск ретроспективы — самая частая ошибка команд: когда сроки горят, жертвуют именно Retro. Это ведёт к стагнации процессов и повторению одних и тех же ошибок. Исследование Scrum.org (2025) показывает: команды, проводящие Retro каждые 2 недели, на 35% быстрее улучшают velocity.

Sprint Planning: планирование итерации

Sprint Planning — встреча команды в начале спринта, на которой определяется, что будет сделано и как. Product Owner представляет приоритетные задачи из Product Backlog. Команда оценивает capacity (доступное время с учётом отпусков, митингов, техдолга) и выбирает задачи, которые может выполнить за спринт. Результат Planning — Sprint Goal (цель спринта) и Sprint Backlog (список задач). Sprint Goal формулируется как короткое предложение: «Реализовать экран заказа и интеграцию оплаты через СБП».

Velocity — скорость команды, измеряемая в стори-поинтах за спринт. Средняя за 3-5 последних спринтов. По данным Scrum.org (2025), команда из 5 мобильных разработчиков (3 Android + 2 iOS) имеет velocity 25-40 SP за 2-недельный спринт. Planning использует velocity как верхнюю границу — берут на 10-15% меньше для учёта непредвиденных задач (code review, инциденты, помощь другим командам). Capacity vs Velocity: capacity — это «человеко-часы», velocity — «стори-поинты». Capacity учитывает отпуска, больничные, митинги. Типичная loss rate — 25-30% рабочего времени уходит на не-кодовую активность.

Планирование делится на две части: «что» (PO рассказывает задачи, команда уточняет) — 2 часа, и «как» (команда декомпозирует и оценивает) — 2 часа. Для мобильных проектов на «как» обсуждают: совместимость с версиями Android/iOS, необходимость feature flag, влияние на размер APK/IPA, новые permission. Техника Planning Poker используется для оценки: каждый разработчик даёт свою оценку в стори-поинтах (1, 2, 3, 5, 8, 13). Расхождение > 2 единиц — обсуждают причины. Это выявляет скрытые риски на этапе планирования, а не в середине спринта.

Выполнение спринта: Daily Standup и трекинг

Daily Scrum (Standup) — ежедневная 15-минутная встреча для синхронизации команды. Каждый участник отвечает на три вопроса: «Что сделано вчера?», «Что планирую сегодня?», «Какие блокеры?». Daily — не статус-отчёт для менеджера, а инструмент самоорганизации команды. Если в Daily выясняется, что два разработчика работают над одной задачей — это сигнал к реорганизации. Важно: Daily не решает проблемы, а выявляет их — для решения созывается отдельная встреча после Daily.

Scrum Board (доска спринта) — визуализация Sprint Backlog. Колонки: To Do / In Progress / In Review / Done. Каждая задача перемещается по доске. Burndown Chart — график оставшейся работы по дням спринта. Идеальный burndown — прямая линия от total SP до 0. Реальный burndown — ступенчатый график с учётом закрытия задач. Падающий burndown (ниже идеальной линии) — опаздываем. Проблемный сигнал: если к середине спринта выполнено менее 30% задач — нужна корректировка. Возможно, не учтены риски или задачи переоценены.

Для мобильной разработки на трекинг спринта влияют специфичные факторы: время сборки (сборка Android проекта в CI может занимать 30+ минут), ожидание модерации App Store / Google Play (если нужно выпустить билд тестерам через TestFlight), совместимость с разными устройствами (тестирование на 10+ моделях занимает время). Совет: закладывайте 1 день буфера в конце спринта на финальное тестирование и сборку релизного билда. Это снижает риск незавершённого спринта на 40% по данным Mind the Product (2025).

Sprint Review и Retrospective

Sprint Review — демонстрация инкремента стейкхолдерам. Команда показывает работающий билд приложения, а не слайды. Продолжительность — 2 часа для 2-недельного спринта. Product Owner проверяет соответствие Acceptance Criteria. Стейкхолдеры дают обратную связь, которая может повлиять на Product Backlog. Review — не отчёт, а диалог: стейкхолдеры могут задать вопросы и предложить изменения. Ключевое правило: Sprint Review — про продукт, а не про процесс. Показываем, что получилось, а не как делали.

Sprint Retrospective — внутренняя встреча команды для анализа прошедшего спринта. Формат: Start Doing (что начать делать), Stop Doing (что прекратить), Continue Doing (что продолжить). Длительность — 1.5 часа для 2-недельного спринта. Retrospective — безопасное пространство для обсуждения проблем. Правило: в Retro не обсуждаются технические детали (для этого есть технические митинги). Только процесс, коммуникация, инструменты, культура. Scrum Master фасилитирует встречу и следит, чтобы каждый участник высказался.

Результат Retrospective — 1-3 улучшения на следующий спринт. Если команда определила проблему «Слишком долгий code review» — action item: «Установить SLA на ревью — 4 часа. Если ревью не сделано вовремя — разработчик напоминает в Slack». Action Items должны быть конкретными, измеримыми и назначенными на конкретного человека. По данным Atlassian (2025), команды, которые выполняют свои Retro action items, улучшают velocity на 15-25% за 3-4 спринта. Те, кто не выполняет — топчутся на месте.

Как выбрать длительность спринта

2 недели — стандарт для мобильной разработки. Оптимальный баланс между предсказуемостью и гибкостью. Успевает: спланировать, реализовать 3-5 средних фич, протестировать, показать результат. 1 неделя — для команд с высокой зрелостью процессов и CI/CD. Требует быстрых решений, минимальной бюрократии. Подходит для стартапов на ранней стадии, когда нужно быстро экспериментировать. Недостаток: высокий overhead на ритуалы (каждую неделю Planning + Review + Retro = 7.5 часов).

3-4 недели — для сложных проектов, где интеграция с хардвером (wearables, IoT, BLE-устройства), долгая модерация сторов или крупные миграции (например, переход с RxJava на Coroutines). Длинные спринты дают больше времени на тестирование, но увеличивают риск «эффекта водопада» — команда теряет agile-гибкость. Рекомендация Scrum Guide: не превышайте 1 месяц. Если спринт дольше — на Review будет слишком много контекста, стейкхолдеры не смогут дать качественную обратную связь.

Типичные проблемы спринтов

Проблема 1: Scope Creep. В середине спринта Product Owner добавляет новую задачу «срочную и важную». Команда соглашается — и спринт проваливается. Решение: Sprint Goal — контракт. Любое изменение требует пересмотра Sprint Goal, а это возможно только в экстренных случаях. Новая задача идёт в Product Backlog и в следующий спринт. Если задача действительно критическая — старый Sprint Goal отменяется, спринт перепланируется, но это исключение, а не практика. Частота scope creep больше 1 раза в 3 спринта — признак слабого Product Owner-а.

Проблема 2: Незавершённые задачи. К концу спринта 50% задач в In Progress, 20% в Review, только 30% Done. Причины: переоценка capacity, недооценка сложности, незапланированные баги. Решение: анализируйте причину на Retro. Если систематически не успеваете — не увеличивайте количество задач в Planning, а уменьшайте. Команды, которые берут на 20% меньше задач, показывают более высокий процент завершения (80%+ против 50-60%). Чек-лист для Planning: на каждую задачу проверить Acceptance Criteria, Definition of Ready и dependency с другими задачами.

Проблема 3: Формальные Retro. Команда проводит Retro для галочки — 15 минут, общих фраз, без action items. Решение: меняйте формат каждой Retro. Методы: Sailboat (что тормозит, что ускоряет), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Назначайте action items с дедлайном и ответственным. В начале следующей Retro проверяйте выполнение предыдущих action items. По данным Atlassian (2025), команды, использующие разные форматы Retro, генерируют на 50% больше полезных инсайтов.