Гибкая методология SCRUM — что это такое и зачем она нужна

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

Методология Scrum появилась благодаря «двум родителям»: Agile-манифесту и…регби. Но обо всем по порядку!

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

Хорошо, ну а причем тут регби? И что означает само слово Scrum? Scrum — термин из регби: это схватка игроков, которая назначается судьей для возобновления игры после нарушения правил. Во время нее игроки обеих команд выстраиваются кругом, плотно сцепившись руками.

Именно с такой схваткой сравнивали в своем исследовании японские ученые  Икуджиро Нонаки и Хиротаки Такеучи работу небольших IT-команд, которые интенсивно работали над проектом  и получали более высокий результат. Позже этот термин использовали создатели метода Джефф Сазерленд и Кен Швабер. Разрабатывая новую методологию работы над IT-проектами, они наблюдали за работой военных спецназовцев и регбистов. «Сцепка»/Scrum стала отличной метафорой сплоченности и командной работы — того элемента, которого недоставало IT-подразделениям для успеха.

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

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

Работа спринтами. Команда работает короткими итерациями (1-3 недели): задачи ставятся конкретно на каждый спринт, а в конце него клиенту презентуется законченная версия (часть) продукта.

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

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

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

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

Agile – определенный подход к разработке IT-продуктов, который воплощен в манифесте Agile. Можно сказать, что это некая идеология, а Scrum – рабочий инструмент, основанный на этой идеологии.

Kanban – еще одна методология работы над проектами, отвечающая принципам Agile. Главные идеи Kanban – визуализация всех процессов и нахождение баланса в работе команды. Есть отличия от Scrum: нет «трех главных ролей» —  заказчик, scrum-мастер, команда, нет работы со спринтами – всё делится на этапы работы над продуктом. Тем не менее, многие инструменты Kanban используются в Scrum: например, доски со стикерами, где задачи перемещаются  из одной колонки в другую по мере выполнения. Есть даже Scrumban – гибридная методология, совмещающая принципы обеих.

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

Scrum базируется на трех ролях в работе над продуктом: только при их полноценном взаимодействии и грамотной работе результат будет достигнут.

Владелец продукта (product owner). Владелец продукта — «мостик» между продуктом и пользователем. Он понимает параметры рынка, на который будет выпущен продукт, и запросы потребителей. Поэтому именно владелец продукта направляет команду: расставляет приоритеты, определяет важность тех или иных задач, принимает и тестирует новую версию продукта после очередного спринта.

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

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

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

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

Команда. Команда — единый организм, который движется к цели спринта и отвечает за разработку продута. Удобнее, чтобы команда была небольшой. А лучше, чем Джефф Безос не скажешь: в команде должно быть столько человек, чтобы разделить на них 2 пиццы. Второй важный критерий команды — кросс-функциональность, она должна включать всех специалистов, необходимых для разработки продукта. Обращение к внешней экспертизе должно сводиться к минимуму, иначе процесс работы будет сильно тормозиться.

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

Использование scrum-артефактов. Три главных артефакта (документа), на котором строится scrum-подход к управлению продуктом:

• Бэклог (журнал) продукта.

• Бэклог (журнал) спринта.

• График спринта.

Эти артефакты — рабочие живые документы, в которых постоянно фиксируются изменения и новые вводные данные.

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

Регулярные совещания. Подход предполагает ежедневные короткие совещания (митапы) по продукту. Не стоит пугаться слова «ежедневные»: это совсем не те бессмысленные и беспощадные совещания, которые все ненавидят. Митапы длятся не более 15-20 минут, они всегда происходят в начале дня. За конструктив отвечает Scrum-мастер, в случае возникновения дискуссий или «флуда» он возвращает митап в нужное русло. Никаких споров, мозговых штурмов и выяснения отношений во время митапа нет и быть не может. Цель митапа — обмен информацией о состоянии дел. Для этого каждый член команды отвечает на три вопроса:

• Что сделано с прошлой встречи?

• Что будет сделано сегодня?

• Какие есть препятствия для выполнения задуманного?  

Если в работе возникают препятствия, задача Scrum-мастера — ликвидировать их (возможно, при участии владельца продукта). Владелец продукта отслеживает, движется ли работа над продуктом в нужном направлении: участие в митапах позволяет вовремя направить команду в нужное русло.

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

Корректировка задач. Что если, член команды понимает, что не укладывается в сроки? Он оперативно сообщает об этом Scrum-мастеру, чтобы тот перераспределил задачи. Бывает и наоборот: если команда раньше закончила задачи на день, могут быть добавлены дополнительные задачи из бэклога спринта. «Аварийная остановка» спринта существует, но применяется крайне: редко в случае возникновения непредвиденных внешних обстоятельств, значительных изменений со стороны заказчика и так далее. Тогда команда может остановить спринт и ждать дальнейших указаний.

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

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

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

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

Из каких этапов строится работа над продуктом по scrum-методологии?

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

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

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

4. Создать бэклог продукта. За создание журнала отвечает владелец продукта. Команда разработчиков должна обязательно ознакомиться с ним заранее, чтоб убедиться, что изложенные им требования понятны, а информация достаточно. Далее общий список задач делится по спринтам.

5. Спланировать и начать спринт. Длительность спринта индивидуальна, но в среднем спринт длится не более 30 дней и не менее 7 дней. Правило от создателей методологии: чем больше неизвестных данных, тем короче должен быть спринт. Каждый спринт стартует с общей встречи-обсуждения, на которой определяется бэклог спринта и распределяются задачи. Важно помнить, что к объему работ во время спринта не может ничего добавиться: бэклог спринта может изменить только сама команда.

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

7. Реагировать на изменения. Один из принципов, унаследованный от философии Agile — готовый продукт превыше всего. А для этого нужно быстро реагировать на все, что может помешать уложиться в сроки.  

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

Основные преимущества, которые дает проекту технология Scrum:

• Гибкость и быстрая подстройка под новые параметры.

• Возможность менять требования к продукту вплоть до совершения pivot.

• Соблюдение сроков.

• Эффективное использование ресурсов команды.

• Тесное взаимодействие заказчика и команды.

• Постоянный информационный обмен.

• Быстрая реакция на изменения.

Какие могут быть минусы у Scrum?

• Метод требует обучения команды.

• Сложно подобрать подходящих членов команды.

• Трудно найти опытного Scrum-мастера.

• Есть риск превращения ежедневных митапов в долгие бессмысленные совещания (при отсутствии должной модерации).

• Одна и та же команда не сможет работать над несколькими продуктами параллельно.

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

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

Удачи вам в работе над продуктом!