Дейлі-стендап — що це, правила щоденної зустрічі та користь

Що таке дейлі-стендап?

Daily Standup (щоденний стендап, дейлі) — коротка зустріч Scrum-команди, яка проводиться в один і той самий час і в одному місці кожного робочого дня. Timebox — 15 хвилин. Зустрічається під різними назвами: Daily Scrum (у Scrum Guide), ранкова синхронізація, morning circle, дейлі. Мета — синхронізувати команду, виявити блокери та скоригувати плани на день. Дейлі — не звіт для менеджера, а інструмент самоорганізації команди. Команда вирішує, як структурувати зустріч, а не менеджер.

Походження терміна «стендап» — від практики стояти під час зустрічі в прямому сенсі: учасники збираються біля дошки і не сідають. Це створює відчуття тимчасовості — ніхто не хоче стояти довше 15 хвилин. Фізичний стендап досі використовується в 60% команд (за даними Scrum.org 2025), решта перейшли на віддалений формат через Zoom, Slack Huddle або Teams. У віддаленому форматі важливо зберігати дисципліну: увімкнені камери, відсутність багатозадачності, готовність заздалегідь подумати над відповідями.

Scrum Guide 2025 визначає Daily Scrum як подію для Developers (розробників). Product Owner і Scrum Master можуть бути присутніми, але не зобов'язані. Якщо PO або SM присутні — вони не керують зустріччю. Команда сама обирає структуру: класичні три запитання або обхід дошки (board walk). Ключове: дейлі — про інспекцію прогресу до Sprint Goal, а не про статус кожного таска. Якщо зустріч перетворюється на перерахування тасок по дошці — значить, команда втратила фокус на Sprint Goal.

Три запитання Daily Standup

Запитання 1: «Що я зробив учора для досягнення Sprint Goal?» — стислий перелік завершених завдань. Не «я працював над APP-123», а «закінчив екран логіна, PR відправлено на рев'ю». Формулювання «для досягнення Sprint Goal» — не випадкова: вона пов'язує щоденну роботу із загальною метою спринту. Якщо розробник не бачить зв'язку свого завдання з Sprint Goal — це сигнал, що завдання не потрібне в поточному спринті. У мобільній розробці вчорашній результат — це не лише код, а й тести, документація, налаштування CI/CD.

Запитання 2: «Що я планую зробити сьогодні для досягнення Sprint Goal?» — план на поточний день. Не більше 2-3 пунктів. Розробник може сказати: «Сьогодні закінчу ViewModel для екрана профілю, напишу Unit-тести, проверну білд на реальному пристрої». Якщо план збігається з тим, що було «вчора» — це сигнал, що завдання занадто велике і його потрібно декомпозувати. Правило двох днів: якщо завдання не завершено за 2 дні роботи — воно має бути розбите на підзавдання, інакше воно зависне в In Progress на тижні.

Запитання 3: «Які блокери заважають моєму прогресу?» — найважливіше запитання. Блокер — це те, що розробник не може вирішити сам: чекає рев'ю (якщо SLA по рев'ю вичерпано), не працює емулятор, не готовий API, потрібен доступ до репозиторію. Важливо: блокер має бути названий, але не вирішуватися на дейлі. Після зустрічі розробник і Scrum Master / менеджер домовляються про вирішення блокера. За даними Scrum.org (2025), 70% блокерів мобільної команди пов'язані з: очікуванням рев'ю (30%), недоступністю тестових пристроїв (20%), залежностями від бекенду (20%).

Як правильно проводити стендап

Час і місце. Дейлі проводиться в один і той самий час щодня — зазвичай на початку робочого дня (9:00-10:00). Для розподілених команд обирається час, комфортний для всіх часових поясів. Тривалість — строго 15 хвилин. Таймер — обов'язковий. Якщо команда не вкладається — проблема не в дейлі, а в процесі: або занадто багато учасників, або завдання обговорюються замість того, щоб лише називатися. Правило пінг-понгу: кожен учасник говорить не більше 60 секунд. Після відповіді передає слово наступному.

Формат «обхід дошки» (Board Walk). Альтернатива трьом запитанням: команда по черзі переміщує завдання на Scrum-дошці, коментуючи зміни. Розробник бере свій таск із To Do, переміщує в In Progress і каже: «Беру APP-123 — екран замовлення, додаю поле промокоду». Board Walk дає візуальне розуміння прогресу та виявляє «забуті» таски — ті, що висять без руху 3+ дні. Board Walk кращий для розподілених команд із Jira/Linear — усі бачать дошку, а не слухають монолог.

Для віддалених команд: обов'язкові ввімкнені камери — за даними Microsoft Research (2025), увімкнена камера збільшує залученість на 40%. Використовуйте спільний екран із дошкою завдань (Jira, Linear, Miro). Пишіть блокери в чат — це створює письмовий запис. Заохочуйте reaction-емодзі (крім завдання користувача — емодзі не використовуються) — thumbs up на повідомлення колеги. Після дейлі — 2-3 хвилини на «парковку» (parking lot): теми, що потребують окремого обговорення, записуються до списку follow-up зустрічей. Ключовий навик Scrum Master-а: зупинити обговорення на дейлі та перенести його в parking lot.

Типові помилки при проведенні

Помилка 1: звіт про статус для менеджера. Розробники по черзі читають, що написано в Jira, менеджер ставить уточнювальні запитання, зустріч триває 45 хвилин. Рішення: нагадати, що дейлі — для команди, а не для менеджера. Менеджер може дізнатися статус із дошки. Якщо менеджер ставить запитання — перенести їх в 1:1. Команда, яка перетворила дейлі на звіт, втрачає 2-3 години на тиждень на всіх учасників. При 8 розробниках це 16-24 людино-годин на місяць — втрата цілого спринту на рік.

Помилка 2: вирішення проблем на місці. Розробник каже «У мене бага з gRPC — не збирається проєкт», і вся команда 20 хвилин обговорює варіанти вирішення. Рішення: записати блокер у parking lot, продовжити дейлі. Після зустрічі — зібрати зацікавлених (розробник + хто може допомогти) на 10-хвилинне обговорення. За даними Basecamp (Shape Up), лише 20% проблем, виявлених на дейлі, потребують обговорення всією командою. Інші вирішуються парою розробників за 10 хвилин.

Помилка 3: запізнення та відсутність. Хтось приходить через 5 хвилин після початку — доводиться повторювати. Рішення: встановлюємо правило «дейлі починається вчасно, запізнілі не входять» або «запізнілий платить штраф» (каву команді). Ще жорсткіше: дейлі проходить в один час, якщо хтось запізнюється систематично — це питання до його дисципліни, вирішується в 1:1. Дейлі — синхронізація дня. Якщо розробник пропустив — він не синхронізований і ризикує робити не ту роботу, яку потрібна команді.

Помилка 4: занадто багато учасників. Команда 15+ осіб, кожен говорить по хвилині — разом 20+ хвилин. Рішення: розділіть команду на підгрупи по фічах/модулях. Кожна підгрупа проводить свій дейлі (5-7 осіб). Один представник від підгрупи може прийти на загальний крос-командний стендап (якщо потрібна синхронізація між командами). Альтернатива: асинхронний стендап через Slack/GeekBot, де кожен пише що зробив/планує/блокери.

Асинхронний стендап: альтернативи

Асинхронний стендап — формат, у якому учасники пишуть свої відповіді в чат (Slack, Telegram, Teams) або спеціалізований бот (GeekBot, Standuply, Status Hero) замість усної зустрічі. Підходить для розподілених команд із різницею в часових поясах 3+ години. Кожен учасник відповідає на ті самі три запитання до певного часу (наприклад, до 11:00). Бот збирає відповіді та публікує дайджест у загальний канал. Переваги: гнучкість, письмовий запис, немає проблеми запізнень.

Недоліки асинхронного формату: немає живого спілкування — втрачаються невербальні сигнали, складніше виявити блокери (розробник може не написати про проблему). Блокер, написаний у чаті, може залишитися непоміченим до кінця дня. За даними GitLab (2025), 40% команд, які перейшли на async standup, повернулися до усного протягом 3 місяців. Рекомендація: використовуйте гібрид — 3 дні усний стендап (пн, ср, пт), 2 дні асинхронний (вт, чт). Або: усний стендап 1-2 рази на тиждень, в інші дні — асинхронний.

Інструменти для асинхронного стендапу: GeekBot (Slack) — ставить три запитання, публікує зведення; Standuply — з інтеграцією з Jira, автоматичним трекінгом; Status Hero — збирає статуси та формує weekly report для менеджменту. Вибір інструменту залежить від культури команди: у стартапах достатньо бота в Slack, в ентерпрайзі може знадобитися Standuply з інтеграцією в корпоративні процеси. Важливе правило: незалежно від формату, відповіді мають бути видні всій команді, а не лише менеджеру. Прозорість — ключова цінність Agile.

Особливості дейлі для мобільної команди

Мобільна команда на дейлі стикається зі специфічними блокерами. Основні: збірка проєкту в CI (Gradle build може тривати 20+ хвилин — якщо зламався, розробник витрачає годину на з'ясування), очікування TestFlight / Firebase App Distribution (публікація білда тестерам займає 30-60 хвилин), проблеми з емуляторами та симуляторами (Android Emulator вимагає KVM/HAXM, iOS Simulator лише на Mac). Дейлі мобільної команди має включати швидкий чек-статус збірки: «Білд збирається? Всі тести зелені?».

Для крос-платформних проєктів (Flutter, React Native) дейлі може включати питання про стан shared-коду. Якщо два розробники одночасно правлять один Dart-файл і один із них вливає зміни — у другого будуть конфлікти. Порада: використовуйте Board Walk на дошці з розділенням по платформах (Android / iOS / Shared). Це допомагає побачити, хто де працює і чи не перетинаються зміни. Для проєктів із Flutter — дошка з колонками Platform Channel, BLoC/Cubit, UI, Tests.

Release-готовність — ще один специфічний для мобільної розробки пункт у дейлі. За 3-5 днів до релізу додавайте запитання: «Чи готовий білд до релізу? Всі метадані (іконки, скріншоти, опис) оновлені?». Це запобігає ситуації, коли розробники закінчують код у день релізу, а збірка та публікація займають ще 3-4 години. Release-трекер — окрема дошка з чек-листом: оновлення versionCode/versionName, перевірка ProGuard, підпис AAB, завантаження в консоль розробника, release notes.