Daily Process

DSM (Daily Standup Meetings)

Мы не практикуем классические созвоны "стендапов". Вместо этого используется асинхронная система отчетов — DSM (Daily Standup Meetings), автоматизированная через GitHub.

Каждый день для участников команды создаётся GitHub Issue со следующими вопросами:

#### Какие задачи выполнял вчера? Укажи #issues
#### Какие задачи будешь делать сегодня? Укажи #issues
#### Что тебя блокирует? (Этот пункт используется когда тебя что-то блокирует)
#### Есть ли личные дела из-за которых нужно отсутствовать на рабочем месте в течение рабочего дня? (Этот пункт используется когда дела есть)

Принципы

• Автоматически создаётся issue с шаблоном — без созвонов, без слак-ботов, без календарей
• Команда отвечает в issue, указывая номера задач
• Заполнение допускается в конце дня, если задачи меняются в течение дня
• Участники упоминаются автоматически через @mention, привязка идёт к GitHub Team DSM

Пример

• https://github.com/atls/dsm/issues/1769

Да, логика абсолютно ясна, структура процессов читается чётко. Вот как я предлагаю оформить вторую часть в том же ключе — как продолжение страницы Daily Process.

---

Check-ins (end-of-day updates)

К концу рабочего дня каждый участник фиксирует свой прогресс по задачам, указанным в DSM, чтобы сохранить контекст и держать всех в курсе. Это делается в комментариях к самим задачам, по простой форме:

#### Что сделано
- описание выполненного

#### Что дальше
- что планируется или осталось

#### Артефакты
- https://github.com/atls/hyperion/pull/598

Что сделано указывается всегда. Сюда входит и завершённое расследование, даже если оно не привело к изменениям.

Если подтверждённой выполненной работы нет, Check-in не публикуется.

Что дальше добавляется, только если по задаче осталась работа.

Артефакты добавляются, только если в ходе работы создан или изменён результат, который можно открыть и проверить, либо работа велась через конкретный PR.

Разделы идут только в порядке Что сделано → Что дальше → Артефакты. Названия разделов оформляются заголовками четвёртого уровня, содержимое — маркированным списком. Короткие пункты пишутся без точки в конце.

Пустые разделы не добавляются и не заменяются словами «Нет», «Не создавались» или другими заглушками.

Артефакты

• PR указывается один раз
• ссылки на коммиты не указываются
• ссылку на коммит в Wiki указываешь только тогда, когда менялась сама Wiki
• если работа состояла только в проверке PR, указывается сам PR, а не отдельные замечания и ответы
• документ, макет в Figma, информационная панель, сборка или другой результат указываются только тогда, когда они созданы или изменены в ходе работы
• слияние PR, публикация, развёртывание и выпуск сами по себе не являются артефактами
• задача, DSM, Check-in, Project Pulse, замечания и ответы в PR, проверки, запуски и логи сами по себе не являются артефактами
• ссылка на источник или подтверждение работы сама по себе не становится артефактом

Important

ВАЖНО

• Ветка создаётся сразу, как только вы взялись за задачу
• Прогресс фиксируется в виде коммитов в течение дня. Коммиты должны быть:
  • по смыслу: гранулированные, соответствующие сделанному
  • по форме: в формате Conventional Commits
• Для поставки изменений открывается PR:
  • если не готов — открой в Draft-режиме
  • ссылку на PR указываешь в Артефакты
  • Для дизайнеров — актуальные изменения в виде Figma-ссылки

Пример

• https://github.com/atls/hyperion/issues/596#issuecomment-2695592975

Зачем это нужно?

• Утром ты вспомнишь что делал накануне
• Команда и менеджмент видят прозрачный прогресс
• Нет нужды в проджект-менеджерах, excel-файлах и ручных сводках