Scrum

Скрам — это гибкий метод (фреймворк) управления проектами, который помогает создавать продукт пошагово, с постоянной обратной связью и улучшением процесса.Он основан на идеях прозрачности, адаптации, эмпиризма: команда делает короткие циклы работы — спринты, анализирует результат, улучшает способ работы.

Scrum и Agile

Scrum не существует сам по себе — он вырос из философии Agile. Agile (гибкая разработка) — это набор ценностей и принципов (Agile Manifesto), которые говорят:

• люди, взаимодействие важнее процессов;

• работающий продукт важнее документации;

• сотрудничество с заказчиком важнее формальных контрактов;

• готовность к изменениям важнее следования плану.

Scrum же — это фреймворк, то есть конкретная структура, которая помогает эти принципы реализовать на практике. Agile — это “философия”, а Scrum — “инструмент” для её воплощения.

Применять Scrum целесообразно там, где нельзя заранее точно определить все требования: в ИТ-разработке, маркетинге, образовании, исследовательских проектах.

Роли Scrum-команды

Скрам-команда — самоорганизующаяся и кросс-функциональная, обычно до 10 человек. В ней нет менеджеров, подчинённых. Только три роли с четкими зонами ответственности.

1. Product Owner (владелец продукта)

Отвечает за ценность продукта, приоритеты. Он управляет Product Backlog — списком идей, требований. Основные обязанности:

• формулировать, доносить цель продукта (Product Goal);

• определять приоритеты элементов бэклога;

• обеспечивать прозрачность задач, критериев готовности.

Анти-паттерны: “всё контролирующий PO”, “продакт-призрак”, “PO как секретарь команды”.

2. Scrum Master (мастер скрама)

Не начальник, а фасилитатор и коуч. Он помогает команде, организации правильно использовать Scrum, устраняет препятствия и следит, чтобы фреймворк соблюдался.

Задачи Scrum Master’а:

• обучает команду Scrum-практикам;

• устраняет блокеры;

• защищает сотрудников от внешнего давления;

• способствует самоорганизации.

Анти-паттерны: “Scrum-менеджер”, “псевдо-PM”, “контролёр”.

3. Developers (разработчики, исполнители)

Это не только программисты. Это все специалисты, которые создают инкремент продукта в каждом спринте. Они:

• планируют работу;

• оценивают задачи;

• несут коллективную ответственность за результат.

Артефакты Scrum и их обязательства

Каждый артефакт связан с обязательством (commitment), которое делает его прозрачным, измеримым.

Product Goal отвечает на вопрос: “Зачем мы делаем продукт?”

Sprint Goal — “Что мы хотим достичь за этот спринт?”

Definition of Done — “Когда работа считается завершённой?”

События Scrum

Scrum опирается на пять обязательных событий, каждое со своей целью и таймбоксом.

1. Sprint (Спринт)

Главный цикл работы — обычно 1–4 недели. Во время спринта команда реализует поставленные задачи, чтобы получить готовый инкремент продукта. В Scrum нет “паузы” между спринтами — следующий начинается сразу после завершения предыдущего.

2. Sprint Planning (Планирование спринта)

Цель: выбрать задачи, сформулировать Sprint Goal. Команда обсуждает, какие элементы из Product Backlog можно реализовать, оценивает их сложность, договаривается о критериях успеха. Таймбокс: до 8 часов.

3. Daily Scrum (Ежедневный скрам)

Короткое (15 минут) собрание сотрудников. Каждый отвечает на три вопроса:

1. Что я сделал вчера?

2. Что собираюсь делать сегодня?

3. Что мешает мне продвигаться?

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

4. Sprint Review (Обзор спринта)

Проходит в конце. Команда демонстрирует готовый инкремент, обсуждает, что удалось достичь, и собирает обратную связь от стейкхолдеров. Это не формальная “демо-встреча”, а открытый диалог о продукте, его будущем направлении.

5. Sprint Retrospective (Ретроспектива)

Заключительное событие каждого спринта. Команда анализирует процесс:

• что сработало хорошо;

• что можно улучшить;

• какие эксперименты стоит попробовать в следующем спринте.

Цель — не искать виновных, а создавать культуру непрерывного улучшения.

Планирование спринта и оценка задач

Этапы планирования

• Определяется Sprint Goal — короткое, но емкое описание основной цели. Это общий фокус, вокруг которого строится работа. Sprint Goal помогает каждому участнику понимать, зачем выполняется та или иная задача, как она влияет на ценность продукта.

• Из Product Backlog (списка всех возможных требований, идей) выбираются элементы — user stories или задачи, которые напрямую способствуют достижению цели. Product Owner объясняет приоритеты, а сотрудники оценивают, сколько элементов реально можно выполнить за итерацию.

• Команда оценивает объем работы, используя разные подходы: story points, часы или относительную сложность. Основная цель — понять, насколько задачи сопоставимы по трудозатратам и рискам, а не составить детальный график.

• Результат планирования фиксируется в Sprint Backlog — это документ (или доска), отражающий выбранные задачи и Sprint Goal. Он становится планом, ориентиром для всех.

Оценка задач

• Story points — популярный инструмент для оценки, который измеряет не время, а сложность, риск выполнения. Один элемент может быть “на 3 балла”, другой — “на 8”, в зависимости от того, сколько усилий он требует по сравнению с другими.

• Planning Poker — командная техника, которая помогает выровнять понимание задач между участниками. Каждый оценивает ее “вслепую”, показывая карточку с числом (например, 3, 5, 8). После этого команда обсуждает, почему оценки различаются, и приходит к общему мнению.

• DoR (Definition of Ready) — необязательная, но полезная практика. Она помогает убедиться, что элемент бэклога действительно готов к работе: у него есть описание, критерии приемки, зависимости, понятная цель. Если история не соответствует DoR, лучше отложить её на будущее.

Схема Scrum-процесса

Работа строится как циклический поток действий, где каждый этап логично вытекает из предыдущего:

1. Product Backlog — список всего, что потенциально может быть сделано. Он постоянно уточняется, обновляется.

2. Sprint Planning — команда выбирает, что будет реализовано в ближайшие 1–4 недели, и формирует Sprint Goal.

3. Выполнение — команда начинает работу, ежедневно синхронизируясь на Daily Scrum, чтобы видеть прогресс, устранять препятствия.

4. Increment — по завершении создается работающий кусочек продукта, соответствующий Definition of Done.

5. Sprint Review — команда демонстрирует результат заинтересованным сторонам, получает обратную связь, обсуждает, что делать дальше.

6. Retrospective — встреча для анализа процесса: что получилось, что можно улучшить, какие шаги предпринять в следующем спринте.

Визуализация процесса

На Scrum-доске (в инструментах вроде Jira, Trello, Miro или Notion) вся работа отображается в виде колонок: To Do → In Progress → Done.

Каждая карточка на доске — это отдельная задача или пользовательская история. Команда видит, сколько работы осталось, какие задачи активны, а какие уже завершены.

Для отслеживания динамики используется burndown chart — диаграмма сгорания задач. Она показывает, как быстро “сжигается” оставшийся объём работы. Идеальная линия отражает прогноз, а реальная помогает заметить отклонения, скорректировать план.

Чего в Scrum нет

В оригинальном фреймворке много чего намеренно нет:

• Нет роли Project Manager — ответственность распределена между PO и командой.

• Нет “Sprint 0” или “Hardening Sprint” — подготовка, стабилизация интегрируются в процесс.

• Нет отдельного релиз-планирования как события.

• Refinement (уточнение бэклога) — это не церемония, а постоянная активность.

• Нет фаз “анализ → разработка → тестирование” — Scrum заменяет их итеративным циклом.

Scrum — это рамки, а не инструкция. Любое “дополнение” должно проходить проверку: не противоречит ли оно базовым принципам.

Scrum vs Kanban (и Scrumban)

Scrumban — гибрид. Он часто применяется при переходе от водопада к Agile.

Метрики и визуализация

Основные метрики:

• Velocity — средний объём работы, который завершается за спринт.

• Burndown chart — график оставшейся работы по дням.

• Burnup chart — показывает накопленный прогресс.

Метрики нужны не для “контроля”, а для улучшения прогнозирования. Опасность — “геймификация”: попытка искусственно завысить velocity или “рисовать” красивые графики без реального улучшения процесса.

Частые ошибки

Scrum не работает “по чек-листу” — он требует изменений в командной культуре. Чтобы “скрамить” правильно, нужно:

1. Определить Definition of Done — чёткие критерии готовности.

2. Создавать работающие инкременты в конце каждого спринта.

3. Развивать самоорганизацию — команда решает, как достичь цели.

4. Фокусироваться на ценности, а не на занятости.

5. Делать процесс прозрачным: доски, ретро, открытые цели.

Частые ошибки:

• превращение Scrum Master’а в менеджера;

• работа без реальных инкрементов (“всё почти готово”);

• игнорирование ретроспектив;

• фиктивные оценки, “гонка за скоростью”;

• перегруженные спринты без фокуса.

FAQ и глоссарий

1. Scrum — это акроним? Нет. Слово взято из регби и означает “схватку” — слаженное командное взаимодействие для достижения общего результата.

2. Что главное в Scrum? Работающие люди, короткие итерации, прозрачность, улучшение через опыт.

3. Можно ли использовать Scrum вне ИТ? Да. Его применяют в маркетинге, дизайне, образовании, HR, даже в управлении личными проектами.

4. Agile и Scrum — одно и то же? Нет. Agile — философия, Scrum — ее практическое воплощение.

Итоги

Scrum — это не просто метод управления проектами. Это гибкий фреймворк, который строит культуру сотрудничества, самоорганизации, постоянного улучшения. Он помогает командам быстрее адаптироваться к изменениям, создавать ценные продукты, развивать устойчивость.

Scrum - это методология управления проектами, которая фокусируется на итеративной разработке и постоянном улучшении процессов. Она включает в себя роли Scrum-мастера, Product Owner и команды разработчиков, а также использование доски Scrum для планирования и отслеживания прогресса. Scrum может быть использован для создания продуктов в различных отраслях, включая IT, маркетинг и дизайн.