Как адаптировать Scrum под цели команды

Во всем мире фреймворк Scrum применяют 66% компаний, которые придерживаются гибкого подхода. В России их доля меньше — 44%. Но не всем Scrum подходит в классическом варианте. Какой вариант фреймворка нужен вашей ИТ-команде и как его внедрить, рассказали agile-коуч Эдуард Галиев и исполнительный директор Департамента развития цифровых систем Антон Филимонов.

Что такое Scrum и каким он бывает

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

В 2014 году Джефф Сазерленд выпустил книгу The Art of Doing Twice the Work in Half the Time. На российском рынке она появилась через три года под названием «Революционный метод управления проектами». Перевод оказался неточным: Scrum строят вокруг продуктов, а не проектов. Чтобы понять, почему это так, надо разобраться в терминах.

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

Проект — временно́е предприятие, которое направлено на создание уникального продукта, услуги или результата. Например, компания хочет выпустить на рынок сервис для юридических лиц. Она выделяет бюджет и собирает команду, которой говорит, что разработку надо запустить 24 февраля, а закончить 24 июня. Это проект с конкретными сроками. Какой результат получит команда, тоже заранее ясно. Например, сервис, в котором бизнес будет смотреть даты, когда сдавать отчеты в налоговую. 24 июня проект закончится и будет ли дальше развиваться — неизвестно.

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

1. Команда разрабатывает финтех-приложение для онлайн-платежей и предполагает, что пользователям важно видеть на главном экране, сколько они потратили за месяц.
2. Она добавляет новую функциональность за спринт — временной промежуток, в течение которого внедряет новую функцию. Обычно спринт длится две недели, но в зависимости от удобства для команды он может составлять до 4 недель.
3. Далее команда запускает приложение в работу и собирает обратную связь от пользователей, чтобы понять, удобно ли им с новыми возможностями.
4. Оказывается, что поле, в котором отражается сумма трат, закрывает пол-экрана. Пользователям приходится скролить его, чтобы найти нужные функции.
5. На основе отзывов разработчики решают уменьшить поле или перенести информацию о тратах в другую вкладку.

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

Использовать продуктовый подход в управлении проектами не всегда возможно. Например, команда запускает систему, в которой компании смогут контролировать расходы и доходы. На проект выделен конкретный бюджет и определены сроки. Руководитель проекта считает, что команде нет смысла встречаться каждый день на Daily Scrum, как этого требует классический вариант фреймворка. Тогда она адаптирует его под себя и берет только те принципы, которые полезны команде, — такой подход называется ScrumBut.

Кто входит в Scrum-команду

Прежде чем внедрить фреймворк, надо распределить роли в Scrum-команде. Их три:

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

Что такое антипаттерны в Scrum и как их избежать

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

Антипаттерн 1. Продакт-оунер не принимает решения по продукту. Если надо внедрить новую функцию, он идет к руководству компании, чтобы согласовать разработку. Это тормозит работу команды, и двухнедельный спринт затягивается на месяц или два.

Как решить. Надо понимать, что Scrum будет работать, если продакт-оунер будет сам решать, как развивать продукт. Для этого руководству компании нужно расширить зону его ответственности и отслеживать результаты работы команды после спринтов.

Антипаттерн 2. Команда не кросс-функциональна. Например, первоначально в нее были набраны разработчики на JavaScript и тестировщики. Но в процессе оказалось, что не хватает аналитика и архитектора. Без них команда не сможет работать эффективно, она вынуждена ждать, пока найдут нужного человека.

Как решить. Изучить первые 5–6 фич бэклога, которые команда должна в ближайшее время выполнить. Затем заполнить таблицу, в которой отметить, какие компетенции нужны, и под них набрать команду.

Антипаттерн 3. Scrum-мастер решает задачи команды, вместо того чтобы учить ее делать это самостоятельно. Его задача — сделать так, чтобы команда могла работать без него.

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

Как решить. Scrum-мастер собирает команду и спрашивает ее: «Что мы можем сделать, чтобы разрешить проблему?» Специалисты договариваются, кто будет отвечать за этот вопрос, и сами занимаются его поиском.

Антипаттерн 4. Работа одного сотрудника в нескольких разных командах одновременно. Участники команды могут брать разные задачи, между которыми приходится переключаться. Из-за этого они теряют эффективность, делают больше ошибок и выгорают. В Scrum занятость должна быть полная.

Как решить. Все выделенные в Scrum-команду сотрудники должны быть погружены в нее на 100% и не заниматься работой в других группах.

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

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

Как адаптировать Scrum под цели команды

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

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

Scrum — идеальное решение?

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

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

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