Дейлик и стендап — что это, правила ежедневной встречи и польза

Что такое дейлик и стендап?

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.