¶ Блок 4 "Артефакты Scrum"
¶ Definition of Ready (DoR) и Definition of Done (DoD)
DoR и DoD — это договорённости команды о качестве входа и выхода задач.
-
DoR отвечает на вопрос: готова ли задача к тому, чтобы взять её в работу?
-
DoD отвечает на вопрос: можно ли считать задачу действительно завершённой?
Без этих договорённостей возникают типовые проблемы:
-
в спринт попадают «сырые» задачи,
-
задачи «почти готовы», но не закрываются,
-
QA и разработка спорят о статусе задачи,
-
спринты формально закрываются, но продукт не готов.
¶ Definition of Ready (DoR)
Definition of Ready — это набор критериев, которым задача должна соответствовать, чтобы команда могла без риска взять её в спринт.
DoR защищает команду от:
-
неясных требований,
-
постоянных уточнений в процессе работы,
-
недооценки и срывов сроков.
¶ Типовые критерии DoR
Задача может попасть в спринт, если:
-
понятна бизнес-ценность (зачем эта задача нужна продукту или пользователю),
-
есть описание и Acceptance Criteria (что именно должно получиться в результате),
-
понятен ожидаемый результат (как понять, что задача выполнена),
-
известны зависимости (другие команды, сервисы, решения),
-
задача оценена (story points или другая система оценки),
-
отсутствуют критические блокеры.
Важно: если задача не соответствует DoR — это не «плохая задача», а сигнал, что её нужно доработать на груминге, а не тащить в спринт.
¶ Пример задачи, не готовой по DoR
«Сделать авторизацию»
Проблемы:
-
неясно, для кого,
-
не описаны сценарии,
-
нет критериев приёмки,
-
невозможно оценить.
Такая задача почти гарантированно сорвёт спринт.
¶ Definition of Done (DoD)
Definition of Done — это единый для команды набор критериев, по которым задача считается полностью завершённой.
DoD защищает продукт от:
-
технического долга,
-
недотестированных фич,
-
«почти готово, но не сейчас».
¶ Типовые критерии DoD
Задача считается завершённой, если:
-
код реализован и закоммичен,
-
пройден code review,
-
выполнено тестирование (ручное или автоматизированное),
-
исправлены найденные дефекты,
-
задача задеплоена в нужное окружение (dev / stage),
-
обновлена документация (если требуется),
-
acceptance criteria выполнены.
Важно: если хотя бы один пункт DoD не выполнен — задача не Done, даже если «почти всё работает».
¶ Почему DoD должен быть общим
-
DoD не индивидуален для разработчика,
-
DoD не меняется от задачи к задаче,
-
DoD — это стандарт качества команды.
Если у каждого своё понимание Done —
возникают конфликты и размывается ответственность.
¶ Частые ошибки с DoR и DoD
-
DoR и DoD существуют только «на бумаге»,
-
критерии слишком размытые,
-
DoD игнорирует тестирование,
-
задачи закрываются без деплоя,
-
DoR используют как формальность, а не фильтр.
¶ Ежедневный стендап (Daily Standup)
Daily Standup — это короткая ежедневная встреча команды, которая помогает синхронизироваться и выявить проблемы как можно раньше.
Длительность стендапа — не более 15 минут.
¶ Цели стендапа
-
понять, как движется спринт,
-
выявить блокеры,
-
согласовать работу команды.
Стендап нужен не для отчёта менеджеру, а для того, чтобы команда могла помочь сама себе.
¶ Стандартные вопросы стендапа
-
Что я сделал вчера для достижения цели спринта?
-
Что планирую сделать сегодня?
-
Есть ли препятствия или риски?
Формулировки могут отличаться,
но смысл вопросов должен оставаться неизменным.
¶ Правила хорошего стендапа
-
проходит в одно и то же время каждый день,
-
участвует вся команда,
-
без обсуждения решений и споров,
-
проблемы фиксируются и выносятся в отдельные обсуждения.
¶ Типовые ошибки стендапа
-
превращение в отчёт для менеджера,
-
обсуждение деталей и решений,
-
опоздания и пропуски,
-
отсутствие реакции на блокеры.
Если после стендапа проблемы не решаются —
значит, стендап не выполняет свою функцию.
¶ Один на один (One-to-One, 1-1, O2O)
One-to-One — это регулярные индивидуальные встречи между руководителем
(Scrum Master, Team Lead, Engineering Manager)
и участником команды.
Фокус о2о — не задачи и статусы, а:
-
состояние человека,
-
рабочий контекст,
-
сложности и риски,
-
развитие и мотивация.
One-to-One не являются частью официальных Scrum-церемоний,
но напрямую влияют на стабильность команды,
качество работы и удержание людей.
¶ Цели One-to-One
1-1 используются для того, чтобы:
-
понять текущее состояние сотрудника,
-
выявить проблемы до того, как они станут конфликтами,
-
дать и получить честную обратную связь,
-
обсудить развитие и ожидания,
-
укрепить доверие между человеком и командой.
Важно: 1-1 — это диалог, а не отчёт и не проверка.
¶ Когда и как часто проводить 1-1
Поводы для проведения 1-1:
-
снижение или резкий рост эффективности,
-
признаки выгорания или перегруза,
-
конфликты или напряжение в команде,
-
адаптация нового сотрудника,
-
изменение роли или зоны ответственности,
-
запрос со стороны самого сотрудника.
Рекомендуемая регулярность:
-
раз в 1–2 недели — для ключевых участников команды,
-
по необходимости — в кризисных или чувствительных ситуациях.
Главное — не формальная периодичность,
а стабильность и предсказуемость встреч.
¶ Структура эффективного 1-1
Типовая структура встречи:
-
Общее состояние и настроение.
-
Что сейчас даётся легко, а что вызывает сложности.
-
Обратная связь (в обе стороны).
-
Поддержка, ожидания, договорённости.
-
Следующие шаги (если они есть).
-
1-1 не обязаны заканчиваться списком задач.
-
Иногда лучшим результатом является просто прояснение ситуации.
¶ Метод сэндвича для обратной связи
Один из простых и безопасных способов дать фидбэк:
-
Позитивное наблюдение Что у человека получается хорошо, какой вклад он вносит.
-
Конструктивная критика Конкретное поведение или ситуация, без обобщений и личных оценок.
-
Поддержка и вера в рост Готовность помочь, ожидания и точки развития.
Важно:
-
говорить про факты и поведение, а не про личность,
-
не смешивать 1-1 с разбором задач спринта,
-
не использовать 1-1 как инструмент давления.
¶ Чего не должно быть на О2О
-
публичной критики,
-
сравнения с другими членами команды,
-
обсуждения слухов и личных оценок,
-
скрытых решений без согласования.
о2о — это безопасное пространство. Нарушение этого принципа разрушает доверие надолго.
¶ Адженда встреч (Meeting Agenda)
Адженда — это заранее подготовленный план встречи,
который отвечает на главный вопрос:
зачем мы вообще собираемся?
Отсутствие адженды почти всегда означает:
-
растянутые митинги;
-
отсутствие решений;
-
ощущение «поговорили и разошлись».
¶ Зачем нужна адженда
Хорошая адженда:
-
экономит время команды;
-
задаёт фокус обсуждения;
-
помогает прийти к конкретным решениям;
-
снижает количество лишних встреч.
¶ Что должно быть в адженде
Минимально полезная адженда включает:
-
Цель встречи
Что должно измениться после митинга? -
Список тем
Чёткие пункты, без абстракций. -
Тайминг
Сколько времени выделено на каждый пункт. -
Участники
Кто обязательно должен быть на встрече. -
Ожидаемый результат
Решение, список задач, договорённости.
¶ Пример адженды
-
Цель: определить приоритеты задач на следующий спринт
-
Темы:
-
обзор текущего velocity — 10 минут
-
обсуждение задач с высоким RICE — 20 минут
-
финальное согласование — 10 минут
-
-
Участники: PM, Tech Lead, QA Lead
-
Результат: согласованный backlog спринта
¶ Хорошая практика
-
отправлять адженду заранее;
-
закрывать встречу фиксацией решений;
-
если нет адженды — встречу можно не проводить.
¶ Ретроспектива (Retrospective)
Ретроспектива — это регулярный разбор того, как команда работала в спринте, а не кто виноват. Цель — выявить успешные практики, узкие места и договориться о конкретных улучшениях.
Ретроспектива проводится после завершения спринта и направлена на непрерывное улучшение процессов и взаимодействий.
¶ Основные цели ретроспективы
-
зафиксировать успешные практики и подходы, которые стоит сохранять,
-
выявить препятствия и узкие места в процессах, коммуникациях или инфраструктуре,
-
определить конкретные действия по улучшению для следующего спринта,
-
повысить эффективность и качество работы команды,
-
укрепить прозрачность и доверие внутри команды.
Важно: ретроспектива не про поиск виноватых, а про совместное улучшение.
¶ Типовые вопросы для ретроспективы
-
Что сработало хорошо? Какие практики и подходы помогли команде достигнуть результатов?
-
Что мешало работе? Какие блокеры, коммуникационные или технические проблемы замедляли процесс?
-
Что можно улучшить? Какие процессы, инструменты, взаимодействия стоит скорректировать?
-
Какие конкретные действия мы внедрим? Какие шаги команда готова выполнить в следующем спринте?
¶ Практические советы
-
Используй Timeboxing: ретроспектива для месячного спринта — до 3 часов.
-
Фиксируй action items с ответственными и сроками.
-
Вовлекай всю команду, даже удалённо (Zoom Breakout Rooms, Miro/Notion для заметок).
• • Применяй разные форматы: Start-Stop-Continue, Mad-Sad-Glad, 4Ls (Liked, Learned, Lacked, Longed for).
¶ Кик-офф (Kick-off)
Kick-off — стартовая встреча проекта, которая формирует общее понимание и ожидания у команды и стейкхолдеров.
Это важный шаг для того, чтобы все участники проекта понимали цели, рамки и роль каждого в команде с самого начала.
¶ Основные задачи кик-оффа
-
ввести команду в контекст проекта: цели, задачи, ограничения и бизнес-ценность,
-
познакомить участников между собой и установить базовые коммуникации,
-
обозначить верхнеуровневый план: ключевые этапы, сроки, зависимые задачи,
-
определить зоны ответственности и роли участников,
-
договориться о формате коммуникаций и инструментах (Slack, Jira, Confluence и т.д.),
-
согласовать правила проведения встреч и регулярных чекпоинтов.
¶ Подготовка к кик-оффу
- Рассылка Agenda: Краткий план встречи с темами обсуждения и участниками. Помогает команде понять, зачем они приглашаются и чего ожидать. Пример:
-
Введение: цели и контекст проекта
-
Знакомство участников и ролей
-
Основные требования и ограничения
-
Ключевые этапы и сроки
-
Вопросы и ответы
- Сбор исходных материалов: ТЗ, бриф, макеты, документация по архитектуре, данные о клиентах — всё, что поможет команде понять проект.
• 2. Материалы для визуализации: Используй Miro, Figma или доску Jira для наглядного распределения задач и зон ответственности.
¶ Уточнение бэклога (Grooming / Refinement)
Grooming (или Refinement) — это регулярная работа с Product Backlog, которая помогает поддерживать его актуальным, прозрачным и готовым к планированию спринта.
Хотя Grooming не входит в официальный набор Scrum-церемоний, это критически важное мероприятие для продуктивной работы команды. Обычно оно занимает не более 10% времени спринта.
¶ Основные цели Grooming
-
Уточнить требования и бизнес-ценность задач.
-
Декомпозировать крупные элементы на подзадачи.
-
Добавить Acceptance Criteria и проверить Definition of Ready (DoR).
-
Провести оценку задач (Story Points или другие метрики).
-
Приоритизировать задачи по ценности и зависимости.
-
Определить потенциальный технический долг и способы его устранения.
¶ Что происходит на Grooming
-
Обсуждение новых элементов бэклога Product Owner представляет задачи, команда задаёт уточняющие вопросы и обсуждает детали.
-
Декомпозиция задач Крупные задачи разбиваются на подзадачи, каждая из которых может быть завершена за один рабочий день.
-
Оценка задач Команда оценивает сложность и усилия для выполнения задач (Story Points, T-shirt sizing или аналогичные метрики).
-
Приоритизация задач Product Owner совместно с командой расставляет задачи по приоритету с учётом бизнес-ценности и зависимостей.
-
Выявление зависимостей и рисков Обсуждаются блокеры, технические ограничения, необходимость участия других команд.
• 6. Фиксация результатов Все задачи обновляются в Jira/Trello/Confluence, чтобы бэклог был прозрачным и готовым к следующему спринту.