Методика Scrum (Скрам): как быть гибким, но не провалить проект

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

Идее Scrum уже 25+ лет, ее основатели — японские ученые Хиротаку Такэути и Икудзиро Нонака. В 1986 г. они наблюдали за компаниями-инноваторами — Fuji-Xerox, Honda и Canon и заметили, что эффективнее те команды, в которых разнопрофильные специалисты одновременно работают над проектом. А традиционный подход, когда работа выполняется последовательно, и сотрудник только после завершения задачи передает ее следующему, проигрывает.

Эти наблюдения были опубликованы в статье в Harvard Business Review. В одном из ее разделов приводилась аналогия с игрой в регби и рассказывалось о scrum (в переводе «схватка») — это такой элемент, при котором игроки группируются вместе, обхватывают друг друга руками и ждут вброса мяча.

Взаимодействие и командная работа легли в основу скрам методики, которую теперь используют даже такие крупные игроки как Amazon, Apple и Microsoft. Давайте сформулируем понятие.

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

Подобным образом строится работа по этой методике, если сильно упростить. А теперь рассмотрим подробнее.

Scrum — одна из основных методик Agile-методологии, поэтому разделяет ее философию и ценности.

Главные ценности Agile (и, соответственно, Scrum) звучат так:

✅ Транспарентность или прозрачность: вся информация о проекте и его текущем состоянии должна быть доступна всей команде. Участники не пытаются утаить шило в мешке, действуют открыто, делятся не только достижениями, но и проблемами.

✅ Инспекция. В процессе работы выполняются регулярные проверки, анализ, выявление возможных проблем и рисков. Оцениваются, как они повлияют на проект.

✅ Адаптация — быстрое реагирование на выявленные проблемы или риски, пока они еще не переросли в «пожары», которые надо тушить.

✅ Сотрудничество: команда работает в тесном взаимодействии друг с другом и с заказчиком, решения принимаются совместно.

✅ Ориентация на результат: исполнители фокусируются на том, чтобы создать работающий продукт, а не на текущих задачах. Если какие-то действия стали неактуальными, они обсуждаются и отбрасываются, а не делаются «ради галочки».

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

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

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

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

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

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

Начинается спринт с планирования. Команда:

⚡️ составляет список приоритетных задач, которые сможет выполнить в рамках одного цикла;

⚡️ определяет, какой продолжительности будет этот цикл (обычно это 2-4 недели);

⚡️ определяет, какой промежуточный результат должен получиться по завершении спринта: это может быть продукт, новые функции, решение проблемы и т. д. Этот промежуточный результат называется инкремент.

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

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

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

Стендап-митинг обычно длится 15 минут и проводится стоя, чтобы морально настроиться на быстрое совещание и не превращать его в «посиделки».

Для визуализации и отслеживания динамики по проекту команда использует скрам-доску. Это физическая или виртуальная таблица, в которой каждый столбец — определенный этап работы. Например:

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

На этом этапе команда обсуждает результат (инкремент). Владелец продукта проверяет, соответствует ли он всем требованиям. На этапе обзора итогов также можно обсудить план на следующий спринт.

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

⚡️ коммуникации: не было ли конфликтов, недопониманий;
⚡️ инструменты;
⚡️ способы решения проблем.

Дальше при необходимости вносятся корректировки и начинается новый «забег», то есть спринт.

Как мы уже выяснили, работающий продукт в этой методике важнее документов, но это не значит, что работа не регламентирована. В Scrum документы называются артефактами, вот список самых основных:

⚡️ Журнал продукта. Это то же самое, что бэклог, в нем описываются характеристики будущего продукта, требования, проблемы, которые нужно решить. Журнал можно редактировать по мере необходимости — как правило, в ходе работы он становится более объемным и конкретным.

⚡️ Журнал спринта или Бэклог спринта. В этот документ мы переносим задачи, которые будем выполнять в следующем спринте.

⚡️ График спринта. Здесь мы отображаем сроки задач и отслеживаем динамику проекта. Если есть какие-то «заторы», то их можно будет вовремя заметить и принять меры, чтобы успеть все выполнить до завершения спринта.

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

2. Гибкость и адаптивность. Работа по проекту разбивается на этапы, за счет чего гораздо легче «попутно» вносить изменения.

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

4. Повышение мотивации команды. Scrum создает условия для автономии и творческой свободы, формирует чувство ответственности у членов команды, что повышает их уровень удовлетворенности работой.

5. Win-Win подход. Здесь нет иерархии, лишней отчетности и действий «ради галочки», весь процесс заточен под то, чтобы всем членам команды было комфортно работать друг с другом, и все были в выигрыше.

1. Подходит не для всех типов проектов. Scrum не используют, когда нужно строго придерживаться ТЗ, когда проект большой и сложный, или когда работу можно выполнить только последовательно.

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

3. Нужна постоянная обратная связь. Здесь уже речь про заказчика — если он не будет участвовать в обсуждениях тогда когда это требуется, мониторить изменения на рынке и сообщать о них команде, то работа по Скрам будет неэффективной.

4. Сложно оценить сроки реализации проекта. Из-за деления на этапы и постоянных корректировок иногда трудно определить итоговые сроки сдачи проекта, что может повлиять на успех задуманного в целом.

Если вы работаете над продуктом в удаленном режиме, то вести проекты можно в специальных сервисах, например, в Кванте. Чем это облегчает работу: