Спринт у мобільній розробці: суть, тривалість і планування

Що таке спринт у розробці?

Спринт — це часовий інтервал (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% більше корисних інсайтів.