Инструкция по Scrum: правила, события, команда

Фото: BongkarnGraphic / Shutterstock

Зачем нужен Scrum

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

В Scrum нет строгой регламентации процессов: кто, что и когда должен делать. На первое место выходят люди, а упор делается на тесное взаимодействие между Scrum-командой и пользователем. Ключевая опора — принципы Scrum «прозрачность — инспекция — адаптация», а также таймбоксинг (фиксированное ограничение времени на задачи) и короткие петли обратной связи.

Три артефакта Scrum

Бэклог продукта (Product Backlog) — это упорядоченный по приоритету и постоянно обновляемый список требований к продукту, которые планируется выполнить с учетом имеющихся на данный момент знаний. Это, по сути, единственный источник работы для Scrum-команды. Элементы бэклога удобно оформлять как user stories/epics с критериями приемки — это упрощает приоритизацию и связь с целями продукта.

Инкремент (Increment) — результат спринта, который отражает шаг на пути к цели продукта. Инкремент включает в себя результат работы текущего спринта и всех предыдущих спринтов. Это готовая к поставке обновленная версия продукта. Команда заранее договаривается, что значит «готово» — это Definition of Done (список условий, по которым продукт считается полностью готовым и ценным для пользователя).

Бэклог спринта (Sprint Backlog) — цель спринта, набор элементов бэклога продукта, выбранных для выполнения в текущем спринте, а также план разработки инкремента продукта. Служит для наглядного представления работы, которую команда определила для достижения цели спринта. Визуализация плана снижает риски и делает управление потоком наглядным.

Пять событий Scrum

Спринт (Sprint) — короткий регулярный цикл длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый объем работы. Все остальные мероприятия Scrum проводятся в рамках спринта. Итеративная и инкрементальная разработка позволяет быстрее адаптироваться к изменениям и лучше понимать потребности рынка, повышая тем самым предсказуемость и скорость обучения.

Планирование спринта (Sprint Planning) — встреча, на которой команда планирует работу на спринт. Результат встречи — бэклог спринта и цель спринта, которые могут быть определены ответами на три вопроса.

• Почему этот спринт ценен?
• Что может быть сделано в этом спринте?
• Как будет выполняться выбранная работа?

На планировании команда договаривается о скоупе (объем работы на спринт) и подходе, оценивает сложность задач в стори-поинтах (баллах, отражающих размер работы) и свою velocity (скорость выполнения работы за спринт). Это помогает распределить задачи и планировать реальный объем работы.

Ежедневный Scrum (Daily Scrum) — регулярная встреча длительностью не более 15 минут, которая проводится каждый рабочий день в одном и том же месте в одно и то же время. В ней принимают участие все разработчики. Цель встречи — оценка прогресса, движения к цели спринта, выявление препятствий. Это не отчет руководителю, а синхронизация команды и план на 24 часа.

Обзор спринта (Sprint Review) проводится в конце спринта, чтобы клиенты и заинтересованные лица провели инспекцию инкремента и дали обратную связь по нему, а скрам-команда при необходимости сделала адаптацию бэклога продукта. Для спринта длиной в месяц обзор спринта длится не более четырех часов.

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

Ретроспектива спринта (Sprint Retrospective) — встреча с целью проинспектировать процессы, инструменты и взаимодействие команд. Результатом встречи является план улучшений на следующий спринт. Проходит после обзора спринта и перед планированием спринта и длится не более трех часов.

Владельцы продукта также проводят уточнение бэклога продукта (Product Backlog Refinement) — рабочие сессии для добавления деталей, оценки и упорядочивания элементов. Это неформальное, но важное мероприятие, которое обычно занимает до 10% времени спринта.

Состав Scrum-команды

Владелец продукта

С одной стороны, владелец продукта — это человек, который общается с клиентами и другими заинтересованными в продукте лицами (нередко их называют заказчиками). На основе этого владелец продукта формирует видение продукта, создает бэклог продукта, а также определяет приоритеты его элементов. Он должен иметь право говорить заказчику «нет», если видит, что его желания уводят продукт от конечной цели. Иначе Scrum не даст ожидаемого бизнес-эффекта.

С другой стороны, владелец продукта работает с разработчиками, отвечает на их вопросы по элементам бэклога, своевременно уведомляет об изменениях, приходящих со стороны бизнеса/клиентов. Как член Scrum-команды, он участвует в мероприятиях Scrum: в планировании, обзоре и ретроспективе спринта.

Разработчики

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

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

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

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

Scrum-мастер

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

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

Основы работы по Scrum

1. Работа ведется итерациями — спринтами не длиннее четырех недель.
2. В начале каждого спринта команда ставит цель и планирует работу, которую берется выполнить в спринте.
3. На ежедневной встрече длительностью не более 15 минут команда синхронизирует свои усилия и выявляет препятствия, которые могут помешать достижению цели спринта.
4. В конце спринта она демонстрирует результат заинтересованным лицам и получает обратную связь. Результатом работы может считаться лишь то, что готово к использованию. То есть это не может быть промежуточный результат дизайна или непротестированного кода программного продукта. Как правило, это то, что может принести ценность клиенту или конечному потребителю продукта.
5. По окончании спринта элемент считается выполненным, если он полностью готов к использованию и может быть передан клиентам сразу после спринта (решение об этом принимается владельцем продукта).
6. Продукт разрабатывает самоорганизуемая команда. Самоуправление в Scrum подразумевает самостоятельность не только в выборе того, кто и как будет работать, но и над чем именно работать, чтобы достичь цели продукта. Начиная с 2020 года руководство по Scrum сменило фокус с самоорганизованной команды разработчиков на самоуправляемую Scrum-команду. Это еще больше подчеркнуло важный факт — ответственность за результат Scrum-команда несет как единое целое.

Для измерения прогресса удобно использовать согласованные метрики (например, velocity, предсказуемость поставок) и визуальные индикаторы (burn-up/burn-down).

Сколько времени нужно, чтобы перейти на Scrum

Чтобы команда вышла на нужный уровень зрелости и работоспособности, нужно минимум три месяца. А через год работы по Scrum при условии постоянства состава и отсутствии непреодолимых внешних препятствий Scrum-команда вполне может стать своеобразным «‎спецназом» и самостоятельно решать сложные задачи, при этом быстрее такой же команды до перехода на Scrum.

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

Почему работа по Scrum может быть неэффективной

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

Неверное понимание зон ответственности. Типичный пример: владелец продукта не наделен полномочиями формировать видение и состав продукта, он скорее является бизнес-аналитиком и не может сказать «нет» заказчику. Бывает еще хуже — когда несколько заказчиков одного продукта не могут договориться между собой. Хороший владелец продукта должен помочь им договориться об общем списке пожеланий и сформировать согласованное видение продукта и «дорожную карту» его реализации. А если владелец продукта слабый и не имеющий полномочий, то разные заказчики дергают команду в разные стороны, в итоге получается слабый продукт.

Не меньше проблем бывает и с зоной ответственности Scrum-мастера. Нередко эта роль сохраняет функции тим-лида с распределением задач между разработчиками и контролем над их выполнением (такого человека в шутку называют Scrum-менеджером). Более частый пример: функции распределения задач у Scrum-мастера уже нет, но его «ответственность за процесс» понимается слишком буквально. Он организует и ведет все Scrum-встречи, записывает и высылает команде их решения. А заодно и сам устраняет все препятствия: например, самолично убеждает «сложных» членов команды не саботировать ее решения. Наконец, некоторые организации ради экономии предлагают одному Scrum-мастеру вести не менее четырех команд. Все это разрушает Scrum методологию управления.

Чтобы Scrum был выгоден

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

Пять провалов и одна победа: как улучшить стратегическое планирование

Образование

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

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

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

Мини-чек-лист запуска (как применять scrum подход):

• соберите кросс-функциональную команду (до 10 человек) и выделите ее на продукт;
• назначьте владельца продукта с реальными полномочиями и четким видением;
• согласуйте цель продукта, метрики ценности и критерии «готово»;
• заведите Product Backlog, определите «события Scrum» и таймбоксы;
• начните короткими спринтами, каждую итерацию улучшайте процесс по ретро.

По материалам pro.rbc.ru.