Scrum-подход в разработке продукта: как его применять и почему многие делают неправильно

*Источник: Перфоманс лаб

В чем суть Scrum-подхода

Scrum — это методология управления разработкой, которая предполагает гибкий подход к созданию продуктов. Работа строится на спринтах: коротких отрезках времени (1–2 недели), когда команда берет ограниченный пул задач и обязуется их завершить.

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

Работа через спринты помогает легко адаптироваться к новым переменным.

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

Для scrum обязательны ритуалы:

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

Как объясняет Денис Подковин, эти практики дисциплинируют, позволяют быстро выявлять проблемы и учиться на собственном опыте.

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

Процессы работы по Scrum достаточно прост. Главное — соблюдать все этапы и понимать их суть.

Сформировать команду и распределить роли

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

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

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

Сформировать бэклог

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

Формированием бэклога занимается владелец продукта.

Провести цикл спринта

Спринт состоит из трех этапов:

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

Через эти этапы работы команда проходит многократно, пока не закончит работу над продуктом.

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

Что мешает применять Scrum эффективно

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

У этого может быть несколько причин.

Подход применяют там, где он не нужен

Иногда «Scrum не работает» означает, что он вообще не может сработать в конкретной ситуации. Это не команда плохая или кто-то что-то сделал не так, а просто инструмент не подходит.

Если вы пока еще не видите ясно свой продукт, то есть нет конкретной цели, Scrum тоже бесполезен. Это типичная ошибка — попытка ускорять то, что еще не определено.

Меняется название подхода, но не мышление

Другая причина провалов — когда технически Scrum использовать можно, но на практике никто к нему не готов.

Как говорит Ольга Ладога-Ячменева, основополагающий фактор успеха внедрения Scrum-подхода — это изменение мышления.

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

Один из примеров не перестроенного на Scrum мышления — нарушение идеи спринтов.

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

Не меняется роль лидера

Scrum требует перестраивать мышление в том числе относительно роли лидера: собственника или основателя компании.

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

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

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

Scrum-мастер не соответствует своей роли

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

Неправильно подобранный Scrum-мастер — отсутствующий Scrum-мастер. А значит, посыпется вся система.

Как объясняет Ольга Ладога-Ячменева, многие поучились на Scrum-мастеров, но так и не изменили свое мышление. В результате они работают как администраторы процессов: делают самые красивые доски, следят за таймингом, но не работают на уровне ценностей, культуры и психологии команды.

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