Регби, доски, два спринта: как устроен Scrum

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

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

Метафору регби для управления проектами в 1986 году предложили Такэути и Нонака, противопоставив классический «эстафетный» подход с передачей работы по цепочке «регбийному» — где разнопрофильные специалисты движутся к цели вместе, постоянно взаимодействуя.

В 1993 году Джефф Сазерленд применил этот подход в разработке ПО в Easel, объединив его с уже использовавшейся там итеративной разработкой. В 1995 году Сазерленд вместе с Кеном Швабером представил Scrum публично. Так Scrum вышел за пределы одной команды и стал самостоятельным подходом к разработке.

Если вы из ИТ-сферы, про Скрам вы точно слышали. Возможно, даже работаете в команде, где есть спринты, стендапы и ретроспективы.

Хотя если попросить 20 человек объяснить, что такое Скрам, вы услышите примерно столько же разных версий. Кто-то скажет, что это спринты и ретроспективы. Кто-то — доска в Jira и стори поинты. А кто-то скажет, что это когда задачи расписаны на две недели и ничего нельзя менять.

А рядом, как тень и вечный спутник, непременно прозвучит «Канбан», который часто грубо отождествляют со Скрамом: мол, это почти одно и то же — везде доски, карточки, Agile... И все бы ничего, если бы это было так.

Эта статья — о популярном фреймворке Scrum. Мы расскажем, почему это именно фреймворк, на чем держится его эмпирический подход, как устроен спринт и зачем Скраму цели, артефакты и инкременты. А заодно проясним, почему его не стоит путать с Канбаном.

Начнем с главного: Скрам — это фреймворк (framework). Так написано в Scrum Guide, где есть прямая формулировка:

Почему «фреймворк»

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

Но разве это не похоже на метод?

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

Поэтому две команды могут работать по Скраму и при этом по-разному организовывать разработку.

Скрам и Agile

Скрам часто ставят в один ряд с Agile. Но это не синонимы и не альтернативы.

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

Scrum — один из фреймворков, построенных вокруг этих идей. Он предлагает конкретную структуру работы команды: зоны ответственности (роли), события, артефакты и правила их взаимодействия. Наряду со Scrum существуют Kanban, XP, Lean и другие подходы, которые по-своему воплощают идеи Agile.

Три столпа эмпиризма

В основе Scrum лежит эмпирический контроль процесса. Мы принимаем решения, оглядываясь на то, что происходит на самом деле. Смотрим, что получилось, делаем выводы — и корректируем маршрут. Как моряки, которые сверяются с компасом в открытом море, а не плывут вслепую, надеясь на авось.

Эмпиризм в Скраме держится на трех столпах:

Прозрачность. Все участники должны понимать, к чему движется команда, над чем она работает и какой результат можно считать готовым. В Скраме для этого есть Sprint Goal, Sprint Backlog и Definition of Done (ниже все термины разберем подробнее).
Проверка. Команда регулярно оценивает прогресс, результат и ход работы. Это позволяет вовремя увидеть отклонения и понять, что конкретно требует изменений. В Скраме такую проверку обеспечивают, в частности, Daily Scrum и Sprint Review.
Адаптация. Когда проверка показывает, что реальность расходится с планом, команда меняет дальнейшие действия — корректирует работу с учетом новой информации.

Увидели, что происходит → проверили, что это значит → изменили работу. Так эмпирический цикл повторяется снова и снова.

Итерации и инкременты

Команда работает короткими циклами — итерациями. В Scrum такая итерация называется Спринтом. Каждый Спринт длится не больше месяца, чаще всего — две недели.

Внутри Спринта команда создает Инкремент — новую готовую часть продукта, которой уже можно пользоваться. Она должна соответствовать Definition of Done — заранее согласованным критериям готовности. Инкремент можно показать заинтересованным сторонам, получить обратную связь и, если принято такое решение, выпустить.

Инкремент может появиться в любой момент Спринта. За один Спринт их может быть несколько. К концу Спринта должен существовать как минимум один Инкремент.

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

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

Команда: три зоны ответственности

Скрам-команда (Scrum Team) включает три зоны ответственности (accountabilities), которые работают вместе над достижением общей цели:

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

Developers (буквально «разработчики») превращают выбранную работу в работающий продукт. Они планируют, как выполнить работу в рамках Спринта, обеспечивают качество и следят за Definition of Done. Developers в Скраме — не только программисты. В зависимости от продукта в команде могут быть инженеры, дизайнеры, тестировщики, аналитики и другие специалисты.

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

Scrum Guide указывает, что Скрам-команда состоит из 10 человек или меньше. Небольшой команде проще сохранять эффективность коммуникации и создавать значимый Инкремент в течение Спринта. Если команда становится слишком большой, Guide предлагает рассмотреть разделение на несколько Скрам-команд, работающих над одним продуктом.

Артефакты — что создает команда

В Скраме есть три артефакта: Product Backlog, Sprint Backlog и Инкремент. Мы уже разобрали, что каждый из них представляет собой, теперь важнее понять их связь с целями Скрама.

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

🔹 Product Backlog

Product Goal — цель продукта. Она задает направление развития продукта и связывает элементы Product Backlog в единое целое.

🔹 Sprint Backlog

Sprint Goal — цель Спринта. Она объясняет, зачем команда взяла именно эту работу и позволяет адаптировать Sprint Backlog по ходу Спринта, сохраняя общий замысел.

Например, цель «Сделать так, чтобы пользователь мог зарегистрироваться через Яндекс» объединяет интерфейс регистрации, авторизацию, обработку ошибок и тесты в одну задачу Спринта.

🔹 Increment

Definition of Done (DoD) — критерии готовности. Они определяют, что должно быть выполнено, чтобы Инкремент можно было считать готовым.

События внутри Спринта

Если артефакты показывают, с чем работает команда, то события определяют, когда команда собирается вместе, чтобы с этой работой разобраться.

Внутри Спринта есть 4 события (формально в Скраме пять событий, включая сам Спринт). Они задают основные точки совместной работы команды.

Sprint Planning. В начале Спринта команда определяет, чего хочет достичь и какую работу для этого нужно выполнить. Здесь формируется Sprint Goal, выбирается работа из Product Backlog и планируется ее выполнение. Для месячного Спринта Sprint Planning отводится до 8 часов. Для более короткого — меньше.

Daily Scrum. Ежедневное 15-минутное событие для Developers. Команда смотрит, как продвигается к Sprint Goal, и при необходимости меняет план работы. Scrum Guide не задает конкретный формат встречи — команда выбирает его сама.

Sprint Review. В конце Спринта команда вместе с заинтересованными сторонами рассматривает результат и обсуждает, что изменилось и что делать дальше. Для месячного Спринта — до 4 часов.

Sprint Retrospective. После Review команда обсуждает, как улучшить свою работу в следующем Спринте. Что мешало? Что сработало хорошо? Что стоит изменить? Например, раньше подключать тестирование, ограничить количество задач в работе или изменить формат планирования. Для месячного Спринта — до 3 часов.

Возьмем обычный двухнедельный Спринт и посмотрим, как команда проходит его от начала до конца.

⏱️ До Спринта: что ждет в бэклоге

У команды есть Product Backlog. В нем — задачи, фичи, исправления, технические улучшения. Все, что может приблизить продукт к Product Goal.

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

⏱️ Sprint Planning: цель и план

В начале Спринта команда проводит Sprint Planning. Для двухнедельного Спринта Planning обычно занимает меньше максимальных 8 часов, установленных для месячного Спринта.

На Planning собирается вся Скрам-команда. Product Owner рассказывает, что сейчас наиболее важно в бэклоге, какие появились новые данные от стейкхолдеров (stakeholder — «заинтересованная сторона») и что изменилось в продукте или на рынке.

Developers определяют, какую работу команда сможет выполнить в Спринте, исходя из Sprint Goal, текущей ситуации и своей способности выполнить работу.

Главный вопрос Planning: Какую цель мы хотим достичь за этот Спринт?

Допустим, команда формулирует Sprint Goal: «Дать пользователям возможность самостоятельно восстановить доступ к аккаунту через email».

🎯 Sprint Goal определяет смысл Спринта. Команда выбирает из Product Backlog элементы, которые помогут достичь цели, уточняет необходимую работу и формирует Sprint Backlog.

⏱️ Дни работы: движение к цели

Спринт начался. Каждый день Developers встречаются на Daily Scrum — timebox 15 минут. Задача встречи: посмотреть, как команда продвигается к Sprint Goal, и при необходимости скорректировать план.

Дальше начинается обычная работа: кто-то пишет код, кто-то тестирует, кто-то делает code review. Главным ориентиром остается Sprint Goal. Отдельные задачи — лишь части плана, который ведет к этой цели.

Если появляется новая информация или срочная работа, Sprint Backlog можно адаптировать, пока это не ставит под угрозу Sprint Goal. Scrum Guide прямо допускает изменение Sprint Backlog по мере того, как команда узнает больше, при условии, что Sprint Goal не подвергается опасности.

Инкремент не обязательно появляется в последний день Спринта. Он может быть создан на второй день, на пятый, на десятый — и за один Спринт их может быть несколько. Каждый Спринт должен создавать как минимум один Инкремент.

Представим, что команда реализовала восстановление пароля. Код написан, протестирован, прошел code review и соответствует Definition of Done (DoD). Инкремент уже можно использовать 🚀. Его можно показать стейкхолдерам и, если принято такое решение, выпустить. Наличие Инкремента не означает, что его обязательно нужно немедленно отправлять в production. Инкремент можно доставить заинтересованным сторонам и до окончания Спринта, а Sprint Review не является обязательным «шлюзом» перед выпуском.

Команда не ждет окончания Спринта, чтобы впервые получить результат. Работающий продукт появляется по ходу Спринта.

⏱️ Sprint Review: результат и новый курс

В конце Спринта проходит Sprint Review. Скрам-команда вместе со стейкхолдерами рассматривает результат, обсуждает, что изменилось, и решает, что имеет смысл делать дальше.

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

После Review Product Backlog может измениться: какие-то элементы потеряют приоритет, какие-то поднимутся выше, появятся новые, какие-то будут переформулированы. Так команда связывает результат Спринта с дальнейшим развитием продукта. Это соответствует назначению Review: инспектировать результат и совместно определить дальнейшие адаптации.

⏱️ Sprint Retrospective: как улучшить следующую итерацию

После Review — ретроспектива. Здесь внимание уже не на продукте, а на работе команды.

Что сработало хорошо?
Что мешало?
Где теряли время?

Например: «Нам было сложно тестировать фичи в конце Спринта — давайте перенесем тестирование на более ранний этап». Или: «Мы слишком часто переключались между задачами — попробуем ограничить количество задач в работе». Или: «Sprint Planning длился три часа — попробуем сократить до двух».

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

🔄 Следующий Спринт

Спринты идут один за другим без пауз. Следующий начинается сразу после завершения предыдущего. Команда учитывает результаты Review и ретроспективы, снова формулирует Sprint Goal, проводит Planning и начинает следующий цикл. Scrum Guide прямо указывает, что новый Sprint начинается сразу после завершения предыдущего.

Ритм Спринта выглядит так:
цель → план → работа → результат → обратная связь → улучшение → новая цель.

Каждый следующий Спринт начинается уже с того, что команда узнала в предыдущем.

И на горячее🔥. Вопрос, на котором провалилось не одно собеседование: чем Скрам отличается от Канбана?

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

* Источник: Scrum.org — Survey Results
**, *** Источник: Scrum Guide (2020), K. Schwaber, J. Sutherland

Вот такая получилась картина. Пожалуй, Если свести все к одной мысли, Scrum строит работу вокруг Спринта, а Kanban — вокруг потока. Отсюда и остальные различия: в ритме, планировании, управлении незавершенной работой, обратной связи и прогнозировании.

И здесь легко впасть в соблазн выбрать единственно «правильный» подход, а второй объявить проигравшим. Но у Скрама и Канбана есть важные точки пересечения. Оба требуют прозрачности, постоянного наблюдения за происходящим и непрерывного улучшения процесса.

Про гибкость... Скрамбан?

Как это часто бывает в жизни, жесткая дихотомия «или-или» уступает гибкому «и». Многие команды, наигравшись в чистые подходы, начинают их комбинировать. Они берут структуру Скрама (роли, ретроспективы) и смешивают ее с канбановским управлением потоком (визуализация, WIP-лимиты). В индустрии для этого даже прижился термин — Скрамбан (Scrumban).

Такой «гибрид» прагматично отвечает на вопрос: «Как взять лучшее от обоих миров под конкретную задачу?»

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

Чтобы такой подход работал в команде, нужен инструмент, который его поддерживает и при этом остается удобным для ежедневной работы.

Благо, рынок предлагает их немало. В России на выбор инструментов дополнительно повлияло импортозамещение: появились отечественные альтернативы Jira, Trello, ClickUp и другим зарубежным сервисам. Многие из них повторяют привычные возможности этих инструментов, но сочетание удобства и функциональности по-прежнему найти непросто.

В taskITnow легкость ежедневной работы сочетается с возможностями для сложных процессов. Преднастроенные Scrum и Kanban создаются за минуту, все необходимые атрибуты уже на месте, а процессы можно гибко настраивать под конкретную команду. Есть автоматизация, планирование и аналитика, при этом доска остается компактной, наглядной и настраиваемой под человека.

Персональное демо — лучший способ познакомиться с taskITnow.