Scrum: роли, события и артефакты

← назад к разделу

Команда работает над продуктом полгода, а показать заказчику нечего: всё «почти готово», но ничего не запущено. Требования поменялись три раза, часть работы выброшена, сроки сорваны. Знакомая история — и именно её пытается решить Scrum. Это не набор ритуалов ради ритуалов, а каркас (framework) для итеративной разработки: вместо одного долгого забега к далёкой цели команда делает много коротких, и после каждого на руках оказывается что-то работающее.

Разберём каркас по частям — итерации, роли, артефакты, события — и ошибки, которые превращают его в бюрократию.

Идея: короткие итерации с готовым результатом

Центральное понятие Scrum — sprint (спринт). Это фиксированный отрезок времени — не больше месяца, на практике чаще одна-две недели, — в течение которого команда делает часть продукта. Ключевое слово — «фиксированный»: длина спринта не двигается. Если работу не успели, переносят не срок, а саму работу — в следующий спринт.

Результат каждого спринта — increment (инкремент): кусок продукта, доведённый до состояния «работает и его можно показать». Не «написали код, но не протестировали», не «сверстали, но не подключили» — а именно готовая, проверенная функциональность. Даже если она маленькая. Поэтому тестирование живёт внутри спринта, а не отдельной фазой после него: непроверенный кусок в инкремент не попадает.

Зачем такая дисциплина? Она даёт обратную связь. После каждого спринта видно реальный прогресс, а не оценку «на глаз». Заказчик смотрит на работающий продукт и корректирует направление, пока правки дёшевы. Ошибка в требованиях всплывает через две недели, а не через полгода. Это тот же принцип, что и в других моделях разработки: чем короче цикл обратной связи, тем дешевле ошибки.

Три опоры, из которых выводится всё остальное

У Scrum есть рамка, которая объясняет зачем нужны все события и артефакты сразу. Она называется эмпирическим подходом и состоит из трёх опор.

Прозрачность. Работа и её состояние видны всем, кто в ней заинтересован. Не «руководитель может спросить», а видно: список задач упорядочен и открыт, состояние спринта на доске, готовность определена одинаково для всех. Прозрачность — условие для следующей опоры: осмотреть можно только то, что видно.

Инспекция. Работу и продвижение регулярно осматривают — достаточно часто, чтобы заметить отклонение, и не так часто, чтобы мешать работе.

Адаптация. Если осмотр показал отклонение, что-то меняют — немедленно, а не «учтём в следующем квартале».

Почему это важнее списка событий: каждое событие Scrum — это инспекция плюс адаптация над одним из артефактов, и из этой таблицы вся механика выводится, а не запоминается:

Отсюда сразу видно, почему пропущенное событие ломает процесс: пропустили обзор — не осмотрели результат; пропустили ретроспективу — осмотрели работу и ничего не поменяли, то есть адаптации нет. И почему бессмысленны события без прозрачности: осматривать нечего, решения принимаются на основе домыслов.

Пять ценностей, без которых остаются ритуалы

Рядом с опорами Scrum называет пять ценностей — и это не декорация: раздел про частые ошибки ниже держится именно на них.

• Обязательство (commitment) — команда обязуется достигать цели, а не «стараться». Отсюда цель спринта, которая не меняется, и готовность, которая не обсуждается по ходу.
• Фокус — работаем над тем, что приближает к цели спринта. Отсюда отказ брать «ещё немножко» в середине.
• Открытость — говорим о работе и о проблемах как есть. Ежедневная встреча ломается не из-за регламента, а из-за отсутствия открытости: там, где признаться в застревании небезопасно, любой формат превращается в отчёт.
• Уважение — к компетентности и к разным мнениям. Отсюда «разработчики сами решают как», а не по указанию.
• Смелость — говорить о трудном: назвать проблему, признать неверную оценку, сказать «цель недостижима».

Практический смысл ценностей в том, что они объясняют причину провалов, а не их симптом. Ежедневная встреча стала отчётом — проблема в открытости и безопасности, и починить её регламентом нельзя. Готовность не соблюдается — проблема в обязательстве. Команда не говорит о недостижимой цели — проблема в смелости, и она про среду, а не про людей.

Кто отвечает за «что», «как» и за процесс

Здесь легко споткнуться о терминологию. Раньше Scrum Guide описывал три роли, одна из которых — «команда разработки», а Product Owner и Scrum Master стояли как бы рядом с ней. С редакции 2020 года команда одна, Scrum Team, и все трое внутри неё; вместо ролей говорят о трёх зонах ответственности: Product Owner, Scrum Master и разработчики. Размер такой команды Scrum Guide задаёт мягко: обычно десять человек или меньше. Делят ответственность так, чтобы никто не тянул одеяло на себя.

Product Owner отвечает за «что и зачем». Он решает, какие задачи важнее, формулирует их ценность для бизнеса и пользователя, ведёт список требований. Его работа — чтобы команда всегда делала самое нужное прямо сейчас. Product Owner не диктует, как писать код, — он приносит проблемы и приоритеты, а не готовые технические решения.

Scrum Master отвечает за процесс. Он не начальник и не раздаёт задачи — его дело в том, чтобы Scrum работал как задумано, а команде ничто не мешало. Заблокировали доступ, тормозит соседний отдел, встречи превратились в болото — это его зона. По сути, Scrum Master убирает препятствия и защищает команду от помех извне.

Про Scrum Master стоит добавить сравнение, потому что вопрос возникает ровно здесь: чем он отличается от руководителя команды и от проектного менеджера.

Три практических следствия, из-за которых это важно:

Scrum Master без административной власти — это норма, а не недоработка. Его инструмент — влияние и авторитет, а не приказ. Отсюда и главный признак работающего Scrum Master: препятствия исчезают, хотя он не может никому приказать.

Роли можно совмещать, но не все. Scrum Master плюс разработчик — частое и рабочее совмещение в небольшой команде. Scrum Master плюс руководитель команды — конфликт: тот, кто оценивает людей, не получит от них честного рассказа о проблемах, а без этого нет открытости. Scrum Master плюс владелец продукта — тоже конфликт: интересы процесса и интересы объёма тянут в разные стороны.

Проектный менеджер в Scrum не исчезает, а меняет работу. Согласование с заказчиком, бюджет, внешние зависимости остаются; распределение задач и контроль исполнения — нет. Команда, где проектный менеджер продолжает раздавать задачи, а Scrum Master «следит за встречами», получает два процесса одновременно, и побеждает тот, у кого власть.

Разработчики (Developers в Scrum Guide) отвечают за «как». Это все, кто делает инкремент: программисты, тестировщики, любые нужные специалисты. Они сами решают, как выполнить работу и сколько взять в спринт, — никто снаружи не распределяет задачи по людям.

Артефакты: что команда ведёт на бумаге и в коде

Команда говорит «сделано», а что за этим стоит — каждый понимает по-своему; чтобы это чинить, работу делают видимой через артефакты. В Scrum Guide их три: Product Backlog, Sprint Backlog и Increment. У каждого есть обязательство (commitment) — то, ради чего артефакт ведут: у Product Backlog это Product Goal, у Sprint Backlog — цель спринта, у инкремента — Definition of Done. Product Goal — цель продукта, одна большая задача, к которой команда идёт сейчас: «запустить оплату картой» или «выйти на второй регион». Без неё упорядоченный список остаётся просто списком, и непонятно, почему наверху именно это. В работе DoD ведут наравне с артефактами, поэтому он идёт здесь четвёртой строкой.

Product Backlog — единый упорядоченный список всех идей, требований и правок. Наверху самое важное, внизу — то, что подождёт. Список живёт: приоритеты меняются, что-то добавляется, что-то выкидывается.

Sprint Backlog — то, что команда обязалась сделать в этом спринте, вместе с планом. Формируется на планировании, но в камне не высечен: по ходу спринта разработчики сами его правят — что-то дробят, что-то добавляют, — а объём можно пересогласовать с Product Owner, если по дороге выяснилось новое. Неизменна цель спринта, а не список под ней.

Increment мы уже разобрали — это результат спринта.

Definition of Done (определение готовности) — договорённость, что значит «сделано». Например: код написан, покрыт тестами, прошёл ревью, развёрнут на тестовом стенде. Без единого DoD каждый понимает «готово» по-своему, и инкремент оказывается ненадёжным.

События: пять встреч и зачем каждая

Scrum задаёт ритм через пять событий. Каждое решает конкретную задачу, а не «потому что так принято».

• Sprint — сама итерация, контейнер для всего остального. Начинается планированием, заканчивается обзором и ретроспективой.
• Sprint Planning (планирование спринта) — в начале спринта команда с Product Owner решает, что войдёт в спринт и как это делать. На выходе — Sprint Backlog и понятная цель.
• Daily Scrum (ежедневная встреча) — короткая, до 15 минут, синхронизация команды. Каждый сверяет: движемся ли к цели спринта, где застряли. Это разговор команды с самой собой, а не отчёт кому-то.
• Sprint Review (обзор спринта) — в конце спринта команда показывает инкремент заинтересованным людям и собирает обратную связь. Здесь решают, куда двигаться дальше, и корректируют Product Backlog.
• Retrospective (ретроспектива) — команда обсуждает не продукт, а сам процесс: что сработало, что мешало, что улучшить в следующем спринте. Это встроенный механизм самоулучшения.

У каждого события есть потолок по времени. Для месячного спринта Scrum Guide даёт так: планирование — до восьми часов, обзор — до четырёх, ретроспектива — до трёх, Daily — пятнадцать минут. Спринт короче — потолки соразмерно ниже: для двухнедельного это примерно вдвое меньше. Так что «планирование на весь день» при двухнедельном спринте — уже не норма, а повод разобраться, почему не влезаем.

Первые четыре события про продукт, последнее — про то, как команда работает. Ретроспектива легче всего вылетает из графика «ради экономии времени», и именно поэтому команда перестаёт расти.

Уточнение списка задач: работа, которой нет в расписании

Пять событий — это то, что стоит в календаре. Есть шестая работа, которая идёт постоянно и без которой планирование превращается в четырёхчасовой разбор того, что имелось в виду: уточнение списка задач (refinement).

Что это. Владелец продукта и разработчики разбирают задачи, которые пойдут в работу через один-два спринта: уточняют смысл, добавляют критерии приёмки, дробят крупное, отвечают на вопросы, иногда выбрасывают. Это не событие с потолком по времени, а непрерывная деятельность; многие команды всё же ставят под неё регулярную встречу на час в неделю — и это разумно.

Зачем — по симптомам, которые она лечит:

• Планирование идёт три часа, потому что половину времени выясняют, что вообще надо сделать.
• В середине спринта выясняется, что задача требует решения, которое никто не принимал.
• Оценки скачут, потому что оценивают непонятное.
• В работу попадает задача, у которой нет критериев приёмки, и «готово» решается спором.

Признак, что задача уточнена достаточно (его называют готовностью к работе): понятно, зачем она нужна и кому; есть критерии приёмки; нет внешних блокировок или они названы; команда понимает, как её делать, и может оценить; она влезает в спринт. Этот список полезно записать один раз и сверяться по нему на планировании — задача, не прошедшая его, в спринт не берётся, и это экономит больше времени, чем любое улучшение встреч.

Сколько на это уходит. Ориентир — до 10 % времени команды, и это не потери: время, сэкономленное на планировании и на переделках, больше. Практическое правило: в верхней части списка всегда есть готовых задач на один-два спринта вперёд — тогда планирование занимает час, а не четыре.

Задача не закончена к концу спринта

Ситуация, которая случается у всех, и обращаются с ней неправильно чаще, чем правильно.

Что делают: незаконченная задача возвращается в список задач продукта целиком и попадает в общую очередь на приоритезацию. Не «переносится в следующий спринт автоматически» — владелец продукта может решить, что теперь важнее другое.

Чего не делают:

• Не «дозачисляют» баллы. Задача на 5 баллов, сделанная на 80 %, даёт ноль в этом спринте. Половина оценки не начисляется, потому что половина результата не приносит пользы. Это выглядит несправедливо и намеренно: скорость команды должна измерять готовое, иначе она перестаёт быть основой прогноза.
• Не дробят задним числом, чтобы «закрыть часть». Дробить надо было раньше — и это вывод для уточнения списка, а не способ спасти отчётность.
• Не продлевают спринт. Срок спринта не меняется, это его главное свойство.

Оценку пересматривают. Когда задача вернётся в работу, её оценивают заново: теперь известно больше, и остаток может оказаться и меньше, и больше первоначальной оценки.

И главное — вопрос на ретроспективе, а не в отчёте. Одна незаконченная задача — обычное дело. Две-три спринта подряд — сигнал: берут слишком много, задачи недостаточно уточнены, или в оценках систематическая ошибка. Разбирают именно это, а не «кто не успел».

Цель спринта недостижима: что делать

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

Сначала — разговор, а не молчание. Это ровно та ситуация, ради которой в ценностях есть смелость: команда сообщает владельцу продукта сразу, как только стало ясно, а не в последний день. Дальше есть три исхода, и все три нормальны.

1. Пересогласовать объём, сохранив цель. Самый частый ответ: из спринта убирают часть задач, цель остаётся достижимой в урезанном виде. Список задач спринта меняют разработчики вместе с владельцем продукта — он для этого и не высечен в камне.

2. Изменить понимание цели. Если цель была сформулирована слишком широко, её уточняют до достижимой. Это не подгонка результата: цель — инструмент фокуса, и уточнить её честнее, чем идти к недостижимой.

3. Отменить спринт. Крайняя мера, и у неё есть правило: отменить спринт может только владелец продукта. Основание одно — цель устарела: изменился рынок, отменили направление, появилось срочное обстоятельство, делающее работу бессмысленной. Не «не успеваем» (это первый или второй исход), а «то, что мы делаем, больше не нужно».

Что происходит при отмене: незаконченные задачи возвращаются в список продукта, готовое — принимается и остаётся, команда проводит ретроспективу и сразу начинает новый спринт с новым планированием. Отмена спринта — редкое событие; если она случается регулярно, проблема не в спринтах, а в том, как выбираются цели.

Частые ошибки, которые ломают Scrum

Scrum легко имитировать, повторяя внешние ритуалы и теряя их смысл. Несколько типичных провалов.

Daily Scrum как отчёт начальнику. Каждый по очереди докладывает руководителю, чем занимался. Смысл встречи — синхронизация команды, а не контроль. Как только Daily превращается в планёрку с отчётами, люди начинают отчитываться «красиво», а не решать проблемы, и встреча становится пустой.

Спринт без Definition of Done. Команда «закрывает» задачи, но что значит «закрыто», никто не договорил. В итоге инкремент собран из полуготовых кусков: где-то нет тестов, где-то не проверено на стенде. Показать нечего, долги копятся. DoD — это страховка от «почти готово».

Product Owner-«диктатор». Product Owner не просто расставляет приоритеты, а лезет в то, как команда делает работу: диктует технические решения, распределяет задачи по людям, давит сроками. Роли смешиваются, команда теряет ответственность за «как» и перестаёт самоорганизовываться. Product Owner отвечает за ценность, а не за инженерные решения.

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

Глубже: откуда берётся карточка: история, критерии приёмки и готовность к работерасширенное

Backlog в статье уже существует, и стоит сказать, из чего состоит одна его строка, потому что половина проблем спринта это карточки, которые нельзя ни оценить, ни закрыть.

Пользовательская история. Не «сделать экспорт», а кто, что и зачем: «Бухгалтер выгружает платежи за месяц в файл, чтобы сверить с банком». Формула не ради формы: «кто» задаёт, с кем говорить о деталях, «зачем» позволяет найти решение проще, чем просили. История описывает результат для пользователя, а не задачу для разработчика; «добавить колонку в таблицу» это не история, а шаг одной из них.

Критерии приёмки. Проверяемые условия, при которых история закрыта: «файл содержит все платежи со статусом проведён за выбранный месяц», «пустой месяц даёт файл с заголовком, а не ошибку», «выгрузка на десять тысяч платежей занимает не больше минуты». Пишут их до начала работы, вместе с тем, кто будет принимать, и они же становятся тестами; история без критериев принимается «на глаз» и возвращается. Формулировка «дано, когда, тогда» помогает не забыть исходное состояние.

Готовность к работе. Договорённость команды, какую карточку можно брать в спринт: есть история и критерии, зависимости от других команд известны, размер оценён и не больше нескольких дней, вопросы к заказчику закрыты. Это зеркало Definition of Done для входа, и оно защищает спринт от карточек, которые начинают выяснять на второй день.

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

Глубже: до бэклога: discovery, гипотезы и кто приносит задачурасширенное

Статья начинается с момента, когда список задач уже есть. Откуда он берётся, решает, будет ли команда делать нужное или просто быстро.

Три роли, которые путают. Product Owner отвечает за порядок в бэклоге и за то, что в него попадает, и это роль в команде. Продуктовый менеджер отвечает за продукт в целом: рынок, стратегия, деньги; в маленьких компаниях это тот же человек, в больших нет. Аналитик превращает потребность в требования и критерии, и он не решает, что делать, а помогает описать. Когда задачу приносит любой из них или сам разработчик, ответ на «зачем» обязан быть один и тот же, и он записан в карточке.

Discovery. До того, как задача попала в бэклог, кто-то должен выяснить, что проблема существует, у кого и насколько она стоит решения: разговоры с пользователями, данные о поведении, прототип на бумаге. Это работа до разработки, и команда участвует в ней, а не получает готовое: разработчик, который слышал пользователя, режет историю иначе. Как это устроено у продукт-инженера, разбирают статьи про проблему вместо решения и про разговор с пользователями.

Гипотеза, а не задача. Строка бэклога это ставка: «если дать выгрузку в файл, бухгалтеры перестанут просить отчёты вручную, и обращений станет меньше на треть». У ставки есть измеримый исход и срок проверки. Ставка не подтвердилась, и это не провал спринта, а результат: функцию убирают или переделывают, и об этом говорят на обзоре спринта так же честно, как о подтвердившихся. Бэклог, в котором нет неподтвердившихся гипотез, это бэклог, где ничего не измеряют.

Порядок в бэклоге это следствие: сверху ставки с самым большим ожидаемым эффектом на единицу работы, и это решение Product Owner с цифрами, а не список пожеланий по дате поступления.

Глубже: ретроспектива, которая меняет процессрасширенное

Ретроспектива в списке событий стоит последней и первой вылетает из графика, потому что «поговорили и разошлись» ничего не даёт, и команда перестаёт видеть в ней смысл. Ретроспектива это встреча про процесс с одним результатом: одно-два изменения, которые команда попробует в следующем спринте.

Что на ней делают. Собирают факты спринта: что сделали, что не успели, где ждали, где переделывали; смотрят на числа (прогноз против факта, сколько задач вернулось из приёмки, сколько времени ушло на незапланированное). Из фактов выделяют одну-две причины, которые повторяются, и на каждую формулируют действие: не «лучше общаться», а «задачи с внешней зависимостью не берём в спринт без подтверждённой даты». У действия есть исполнитель и проверка на следующей ретроспективе: сработало или нет.

Почему список пожеланий не работает. Десять пунктов «надо бы» никто не сделает; одно изменение, которое проверят через две недели, сделают. Ретроспектива это тот же цикл проверки гипотез, что и для продукта, только про команду, и её итоги ведут в том же бэклоге, а не в отдельном документе, который никто не открывает.

Что мешает. Присутствие руководителя, при котором не говорят о настоящих причинах; поиск виноватого вместо причины в процессе (та же безобвинительность, что и в разборе аварий); повторение одной формы («что хорошо, что плохо») до автоматизма, лечится сменой формата раз в несколько спринтов; и ретроспектива без фактов, на ощущениях, которая превращается в спор. Тридцать минут с фактами и одним действием ценнее двух часов обсуждения.

Коротко

• 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-«диктатор» ломает самоорганизацию.
• Строка бэклога это история «кто, что, зачем» с критериями приёмки «дано, когда, тогда», проверенная на готовность к работе; режут по сценариям и данным, не по слоям. До бэклога идёт discovery: Product Owner, продуктовый менеджер и аналитик это разные роли, задача это гипотеза с измеримым исходом, неподтвердившаяся гипотеза это результат, а не провал.
• Ретроспектива это факты спринта, одна-две причины, одно-два действия с исполнителем и проверкой через спринт; без руководителя, без виноватых, со сменой формата.
• Три опоры — прозрачность, инспекция, адаптация: каждое событие это осмотр одного артефакта и изменение по результату, и отсюда видно, что ломает пропущенное событие. Пять ценностей объясняют причину провалов: ежедневная встреча становится отчётом из-за отсутствия открытости, и регламентом это не лечится.
• Scrum Master отвечает за работоспособность процесса, не распределяет задачи и не имеет административной власти; совмещение с руководителем команды или владельцем продукта — конфликт.
• Уточнение списка — постоянная работа до 10 % времени: в верхней части списка всегда есть готовых задач на один-два спринта, и задача без критериев приёмки в спринт не берётся.
• Незаконченная задача возвращается в список продукта целиком, баллы не дозачисляются, спринт не продлевается, оценка пересматривается, а повторение — тема ретроспективы.
• Недостижимая цель обсуждается сразу: пересогласовать объём, уточнить цель или отменить спринт — и отменить может только владелец продукта, и только если цель устарела.

Что почитать дальше

• Kanban — что делать, когда работа не режется на фиксированные итерации.
• Оценка и планирование — откуда берётся «сколько влезет в спринт».
• Extreme Programming — инженерные практики, без которых DoD остаётся на бумаге.
• Модели разработки — откуда взялись короткие итерации и что было до них.