Команда работает над продуктом полгода, а показать заказчику нечего: всё «почти готово», но ничего не запущено. Требования поменялись три раза, часть работы выброшена, сроки сорваны. Знакомая история — и именно её пытается решить Scrum. Это не набор ритуалов ради ритуалов, а каркас (framework) для итеративной разработки: вместо одного долгого забега к далёкой цели команда делает много коротких, и после каждого на руках оказывается что-то работающее.
В этой статье разберём Scrum по частям: зачем нужны короткие итерации, кто за что отвечает, какие артефакты команда ведёт и какие встречи проводит. И главное — какие ошибки превращают Scrum из полезного каркаса в бюрократию.
Идея: короткие итерации с готовым результатом
Центральное понятие Scrum — sprint (спринт). Это фиксированный отрезок времени, обычно одна-две недели, в течение которого команда делает часть продукта. Ключевое слово — «фиксированный»: длина спринта не двигается. Если работу не успели, переносят не срок, а саму работу — в следующий спринт.
Результат каждого спринта — increment (инкремент): кусок продукта, доведённый до состояния «работает и его можно показать». Не «написали код, но не протестировали», не «сверстали, но не подключили» — а именно готовая, проверенная функциональность. Даже если она маленькая.
Зачем такая дисциплина? Она даёт обратную связь. После каждого спринта видно реальный прогресс, а не оценку «на глаз». Заказчик смотрит на работающий продукт и корректирует направление, пока правки дёшевы. Ошибка в требованиях всплывает через две недели, а не через полгода. Это тот же принцип, что и в других моделях разработки: чем короче цикл обратной связи, тем дешевле ошибки.
Роли: кто отвечает за «что», «как» и за процесс
В Scrum три роли, и они делят ответственность так, чтобы никто не тянул одеяло на себя.
Product Owner отвечает за «что и зачем». Он решает, какие задачи важнее, формулирует их ценность для бизнеса и пользователя, ведёт список требований. Его работа — чтобы команда всегда делала самое нужное прямо сейчас. Product Owner не диктует, как писать код, — он приносит проблемы и приоритеты, а не готовые технические решения.
Scrum Master отвечает за процесс. Он не начальник и не раздаёт задачи — его дело в том, чтобы Scrum работал как задумано, а команде ничто не мешало. Заблокировали доступ, тормозит соседний отдел, встречи превратились в болото — это его зона. По сути, Scrum Master убирает препятствия и защищает команду от помех извне.
Команда разработки отвечает за «как». Это те, кто делает инкремент: разработчики, тестировщики, все нужные специалисты. Команда сама решает, как выполнить работу и сколько взять в спринт. Она самоорганизуется — никто снаружи не распределяет задачи по людям.
Разделение простое: Product Owner приносит «что», команда решает «как», Scrum Master следит, чтобы механизм не заедал.
Артефакты: что команда ведёт на бумаге и в коде
Артефакты — это то, что делает работу видимой. Их четыре.
| Артефакт | Что это | Кто ведёт |
|---|---|---|
| Product Backlog | Полный список всего, что нужно продукту, по приоритету | Product Owner |
| Sprint Backlog | Задачи, взятые в текущий спринт, + план как их делать | Команда |
| Increment | Готовая часть продукта по итогам спринта | Команда |
| Definition of Done | Общее правило «когда задача считается готовой» | Команда + Product Owner |
Product Backlog — единый упорядоченный список всех идей, требований и правок. Наверху самое важное, внизу — то, что подождёт. Список живёт: приоритеты меняются, что-то добавляется, что-то выкидывается.
Sprint Backlog — то, что команда обязалась сделать в этом спринте, вместе с планом. Формируется на планировании и на время спринта не пополняется извне.
Increment мы уже разобрали — это результат спринта.
Definition of Done (определение готовности) — договорённость, что значит «сделано». Например: код написан, покрыт тестами, прошёл ревью, развёрнут на тестовом стенде. Без единого DoD каждый понимает «готово» по-своему, и инкремент оказывается ненадёжным.
События: пять встреч и зачем каждая
Scrum задаёт ритм через пять событий. Каждое решает конкретную задачу, а не «потому что так принято».
- Sprint — сама итерация, контейнер для всего остального. Начинается планированием, заканчивается обзором и ретроспективой.
- Sprint Planning (планирование спринта) — в начале спринта команда с Product Owner решает, что войдёт в спринт и как это делать. На выходе — Sprint Backlog и понятная цель.
- Daily Scrum (ежедневная встреча) — короткая, до 15 минут, синхронизация команды. Каждый сверяет: движемся ли к цели спринта, где застряли. Это разговор команды с самой собой, а не отчёт кому-то.
- Sprint Review (обзор спринта) — в конце спринта команда показывает инкремент заинтересованным людям и собирает обратную связь. Здесь решают, куда двигаться дальше, и корректируют Product Backlog.
- Retrospective (ретроспектива) — команда обсуждает не продукт, а сам процесс: что сработало, что мешало, что улучшить в следующем спринте. Это встроенный механизм самоулучшения.
Первые четыре события про продукт, последнее — про то, как команда работает. Ретроспектива легче всего вылетает из графика «ради экономии времени», и именно поэтому команда перестаёт расти.
Частые ошибки, которые ломают Scrum
Scrum легко имитировать, повторяя внешние ритуалы и теряя их смысл. Несколько типичных провалов.
Daily Scrum как отчёт начальнику. Каждый по очереди докладывает руководителю, чем занимался. Смысл встречи — синхронизация команды, а не контроль. Как только Daily превращается в планёрку с отчётами, люди начинают отчитываться «красиво», а не решать проблемы, и встреча становится пустой.
Спринт без Definition of Done. Команда «закрывает» задачи, но что значит «закрыто», никто не договорил. В итоге инкремент собран из полуготовых кусков: где-то нет тестов, где-то не проверено на стенде. Показать нечего, долги копятся. DoD — это страховка от «почти готово».
Product Owner-«диктатор». Product Owner не просто расставляет приоритеты, а лезет в то, как команда делает работу: диктует технические решения, распределяет задачи по людям, давит сроками. Роли смешиваются, команда теряет ответственность за «как» и перестаёт самоорганизовываться. Product Owner отвечает за ценность, а не за инженерные решения.
Общий корень всех трёх ошибок один: ритуал остаётся, а его назначение теряется. Scrum работает не потому, что есть встречи и списки, а потому, что за каждым элементом стоит конкретная цель — обратная связь, прозрачность, распределённая ответственность.
Коротко
- Scrum — каркас итеративной разработки: продукт делается короткими фиксированными итерациями (sprint), каждая даёт готовый инкремент.
- Три роли: Product Owner отвечает за «что и зачем», команда — за «как», Scrum Master — за то, чтобы процесс не заедал.
- Четыре артефакта: Product Backlog (всё по приоритету), Sprint Backlog (взято в спринт), Increment (результат), Definition of Done (когда «готово»).
- Пять событий: Sprint и внутри него Planning, Daily Scrum, Review, Retrospective — у каждого своя цель.
- Смысл коротких итераций — быстрая обратная связь: ошибки всплывают через недели, а не через месяцы.
- Daily Scrum — синхронизация команды, а не отчёт руководителю.
- Без Definition of Done инкремент недостоверен, а Product Owner-«диктатор» ломает самоорганизацию команды.
Что почитать дальше
- Kanban
- Оценка и планирование
- Модели разработки