Что такое Scrum и как правильно использовать эту методологию в рабочем процессе?
Scrum — это один из способов организации работы в команде, который помогает людям эффективнее работать и достигать намеченных целей. Главный принцип — регулярно поставлять бизнесу и пользователям готовую часть продукта, которой можно пользоваться, а не тратить на разработку несколько месяцев или годов, а только потом выкатывать полноценный релиз.
Scrum — это особый подход к организации командной работы. Почитайте, какие преимущества он даёт и подойдёт ли такой метод управления проектами вашей компании.
В статье расскажем что такое методика Scrum, чем она отличается от Agile и Kanban, плюс, про преимущества и недостатки такого подхода к организации работы. Дополнительно поговорим и о том, кому такой метод вообще подходит. Ведь часто руководство компаний слышит про новый модный способ организации труда и быстрее торопится внедрить его у себя в бизнесе. Но Scrum — это точно не для всех. И очень часто просто не стоит временных и денежных затрат.
Что такое Scrum?
Простыми словами Scrum — это специальная методика, которая помогает небольшим группам сотрудников эффективнее вести совместную работу. Команда при таком подходе — это объединение специалистов, которые в состоянии сами решать задачи и справляться с трудностями. Обычно в таких группах не больше десяти человек, ведь если людей будет больше, это усложнит коммуникацию между ними.
Ещё одна особенность — в такой методологии нет жёсткой иерархии, никто не диктует, как именно нужно работать. Каждый член команды может высказывать своё мнение и вносить предложения по улучшению рабочего процесса, причём голос каждого одинаково значим. Таким образом достигается общая гибкость: в процессы и сам продукт можно внести корректировки на любой стадии разработки. И не придётся проходить через сто кругов бюрократического ада.
Основной смысл технологии в том, что работа ведётся одинаковыми по длительности этапами. И по завершению каждого, сотрудники готовы представить часть продукта, которая сразу же готова к использованию.
Эту методику обычно применяют в IT при разработке приложений, но сейчас её использование вышло за рамки только этой сферы. Общие принципы работы могут подойти почти любым организациям.
Как появилась методология Scrum?
Этот метод управления проектами появился в 90-х годах прошлого века. До этого момента чаще всего использовали водопадную модель. Её смысл в том, что команда выполняет последовательные этапы.
Например:
-
Формирование базовых пожеланий к конечному продукту;
-
Составление ТЗ;
-
Работы по созданию продукта;
-
Тестирование;
-
Итоговая оценка;
-
Релиз продукта для конечного пользователя.
И ни один этап не может начаться, пока не сделан предыдущий. То есть команда работает над продуктом очень продолжительное время и только в самом конце может получить обратную связь от конечных пользователей. Конечно, если продукт типовой, всё и так понятно, и дополнительные правки и комментарии от клиентов не играют особо важной роли. Но в случае когда создаётся что-то радикально новое, такой подход к работе может принести проблемы.
В конце 20 века стали появляться другие методы организации работы, один из которых как раз Scrum. Чем он отличается от водопадного подхода? Из-за того, что работа ведётся итерациями, у команды есть возможность регулярно получать обратную связь от конечных пользователей и вносить правки в следующие шаги разработки. Такой процесс организовать не просто, но зато бизнес экономит деньги на полную переделку продукта, которая вполне вероятна при водопадной модели.
Само слово “Scrum” разработчики подхода позаимствовали из терминологии регбистов. Перевод этого понятия примерно такой: “готовность совершить рывок”. Это означает состояние команды, которая стоит на поле, сцепившись вместе, и ждёт первого броска мяча.
Основные термины из методологии Scrum
Давайте сразу обсудим все важные термины, которые вы будете встречать по ходу статьи. Если какое-то слово будет вам непонятно, вы всегда можете вернуться к этому списку.
Спринт — это период, в течение которого Scrum-команда выполняет задачи, важные для увеличения ценности продукта. По окончанию каждого спринта сотрудники представляют готовую к использованию часть финального проекта. Обычно он занимает 1-2 недели, но может длиться и до месяца.
Бэклог продукта — это список задач, которые расставлены по приоритетности: от самых важных и срочных до тех, что можно выполнить позже. Бэклог готовят бизнес и владелец продукта, а команде его представляют на планинге (мероприятии по планированию спринта).
Бэклог спринта — список задач, которые сотрудники готовы взять в текущий спринт.
Стори-поинты — это баллы, с помощью которых в системе Scrum оцениваются трудозатраты на выполнение каждой задачи. Стори-поинты выставляются каждым членом команды в ходе планирования спринта. Обычно для оценки используются числа Фибоначчи, то есть 1, 2, 3, 5, 8, 13, 21 и т.д. Идеальная ситуация — когда все поставили одинаковые оценки. Если нет, приходится вычислять среднюю. Если оценки слишком сильно различаются (например, кто-то поставил 1, а кто-то 13), то можно выйти на второй круг обсуждения и решить, насколько задача всё-таки сложная. После этого опять проводится оценка с помощью стори-поинтов.
Scrum-доска (или доска спринта) — инструмент, который помогает визуализировать задачи команды в текущем спринте. Может быть представлен в виде трёх колонок: “Сделать”, “В работе” и “Готово”.
Блокеры — препятствия, которые мешают выполнять задачи из бэклога.
Инкремент — результат работы одного спринта. Если по окончанию спринта есть хотя бы один инкремент, то он считается успешно завершённым. Каждый инкремент увеличивает ценность готового продукта.
MVP (minimum viable product или минимально жизнеспособный продукт) — версия, на которую сотрудники потратят минимальное количество усилий, но при этом с её помощью смогут получить достаточно обратной связи от клиентов.
Критерии готовности — конкретные пункты, которые должны быть готовы, чтобы инкремент считался завершённым.
Диаграмма сгорания задач — визуализация, которая наглядно показывает, сколько работ уже сделано, а сколько осталось сделать. Помогает спрогнозировать успех конкретного спринта и видеть прогресс команды в стори поинтах.
Рабочие соглашения — список командных практик и норм поведения, который описывает правила совместной работы в конкретном коллективе.
Основные принципы и особенности Scrum
В этой методологии есть три основных принципа, на которых держатся все процессы:
-
Работа ведётся одинаковыми итерациями, которые называются спринтами. На каждый такой этап устанавливается своя цель, которую вся команда старается достичь. Конечно, если цель слишком глобальная, её можно разбить и на два этапа, но в большинстве случаев длительности одного спринта должно хватать.
-
В конце каждого спринта сотрудники выдают часть конечного продукта, которая полностью готова к использованию. Например, результатом спринта не может считаться только новый дизайн сайта. Пусть это будет одна готовая страница, но с полностью написанным и протестированным кодом, которым уже могут пользоваться люди.
-
Команда — это объединение всех нужных для реализации конкретного продукта специалистов. То есть если нам нужно создать сайт, в группе будут программист, маркетолог, дизайнер, копирайтер и т.д. Таким образом все люди, важные для проекта, в курсе, что происходит с ним на каждом этапе.
Scrum также предусматривает четыре основных события (их ещё называют митинги):
-
Планирование спринта — мероприятие, на котором определяется главная цель команды на ближайшие несколько недель. На встрече обязательно должны присутствовать все участники команды и владелец продукта. Здесь происходит обсуждение задач, трудозатрат и всех подводных камней. А ещё тут же выставляются стори поинты.
Но это не значит, что выставленные в процессе совещания оценки не могут поменяться после начала работы. Например, один из сотрудников приступил к задаче и понял, что она намного сложнее, чем казалось изначально. Тогда он может рассказать о своих затруднениях на ежедневной встрече и задачу переоценят. Конечно, лучше не допускать таких ситуаций, но в начале они точно будут.
Для стандартного спринта (две недели) рекомендуется тратить на планирование не больше четырёх часов. Но в некоторых командах есть практика разбивать такое мероприятие на две части: груминг и сам планинг. На груминге происходит встреча с владельцем продукта и другими заинтересованными сторонами. Они доносят свои желания и рассказывают об их приоритетности. А на планинге команда подробно обсуждает каждую задачу, ставит им оценки и решает, что взять в текущий спринт. Из-за того, что встреча разбивается на две части, люди не так устают. Ведь не каждый может быть полностью включённым в процесс целых четыре часа.
- Ежедневный стендап. Мероприятие, которое проводится каждый день и помогает понять, чем занимается каждый член команды. Вот несколько вопросов, вокруг которых строится стендап:
✔ Что я сделал вчера;
✔ Что я планирую делать сегодня;
✔Есть ли ли у меня проблемы в выполнении работы.
Главное — не растягивать такие ежедневные встречи. Оптимальное время на стендап — 15 минут. Если кому-то нужно обсудить какие-то моменты более подробно, лучше если они отдельно встретятся после общего собрания. Иначе все участники команды, вместо выполнения своих функций, будут просто терять время.
- Обзор итогов (ещё называют демонстрацией или просто демо) — это мероприятие, на котором команда презентует владельцу продукта и бизнесу, результат своей работы за спринт. Длится демо около 1-2 часов. В ходе встречи заказчики могут задавать вопросы, высказывать своё мнение и при необходимости вносить правки.
- Ретроспектива спринта — встреча, на которой команда обсуждает прошедший спринт. Основные вопросы:
✔Что было хорошо;
✔В чём возникли трудности;
✔Что нового узнали.
Цель такого мероприятия — постоянно улучшать процессы внутри коллектива и повышать эффективность работы. По результатам ретроспективы может быть сформирован список улучшений, который нужно внедрить в ближайшее время.
Состав Scrum-команды
Всего есть три основные роли сотрудников:
-
Разработчик;
-
Владелец продукта;
-
Scrum-мастер.
Разработчик — это необязательно программист. Это просто один из сотрудников, который выполняет любую работу по продукту. Туда могут входить разные люди. Например, аналитик, копирайтер, SEO-специалист и т.д.
Владелец продукта — это представитель бизнеса, который доносит желания заказчиков до разработчиков. Одна из главных задач владельца продукта — это расстановка приоритетности задач. Он учитывает “хотелки” бизнеса, сопоставляет их с возможностями команды и формирует бэклог.
Простыми словами Scrum-мастер — это тот, кто делает всё, чтобы команда с каждым новым спринтом была лучше. Он ведёт все основные мероприятия и помогает владельцу продукта выставлять приоритетность задач, разработчикам — вовремя готовить релизы, а всей команде — становиться эффективнее. Это лидер с лояльным подходом к руководству.
Вот основные принципы, которых стремится придерживаться Scrum-мастер:
-
Эмпирический подход. Группа людей работает и постепенно учится на своих ошибках. А Scrum-мастер выполняет роль того, кто ей в этом помогает.
-
Самоорганизация. Мастер старается делать так, чтобы разработчики могли сами наладить процессы и решать все возникшие трудности.
-
Ценности. В методологии Scrum есть пять главных ценностей: смелость, сфокуссированность, открытость, уважение и ответственность. Так вот Scrum-мастер следит, чтобы каждый человек придерживался этих ценностей при общении с коллегами, высказывании своего мнения и выполнении задач в общем.
Agile, Scrum, Kanban: чем они отличаются друг от друга?
Сначала поговорим про Agile. Это понятие намного шире, чем Scrum. Оно включает в себя общую философию и набор ценностей для гибкого подхода к разработке продуктов. Кратко сформулировать смысл Agile можно в четырёх постулатах:
-
Люди и их совместная работа важнее, чем соблюдение строгих процессов;
-
Хороший функциональный продукт важнее, чем составление документов и отчётов;
-
Продуктивное сотрудничество с клиентом важнее, чем жёсткое соблюдение условий договора;
-
Готовность меняться важнее, чем строгое следование запланированным пунктам.
Теперь перейдём к Scrum и Kanban. Это не отдельные совершенно разные методологии, а всего лишь два подхода к пониманию философии Agile. Ещё их называют фреймворками. То есть когда спрашивают про отличия Agile от Scrum, вопрос ставят немного некорректно, потому что одно включает в себя другое. Про Scrum мы уже поговорили, поэтому подробнее остановимся на Kanban.
В этом подходе нет спринтов или конкретных ролей. Главное тут — сократить время выполнения каждой задачи и не допускать такого, чтобы один сотрудник работал сутками, а другой сидел без дела. Плюс, во фреймворке Kanban стремятся сократить количество незавершённой работы. Здесь тоже используется доска визуализации, и задачи перемещаются между столбцами “Нужно сделать”, “В процессе”, “На проверке”, “Завершено”, но конкретного срока на выполнение всех дел (той самой длины спринта) нет. Чтобы не плодить незавершённые задачи, в некоторых сервисах специально нельзя перемещать слишком много позиций в одну колонку.
Ещё одно отличие Kanban от Scrum в том, что при этом подходе в процессе работы могут регулярно добавляться новые задачи, а какие-то из них можно просто удалять. В Scrum такое недопустимо.
Иногда компании используют не конкретно одну или другую методику, а берут из них полезные для себя моменты и создают некий гибрид на основе Agile-подхода. У этого даже есть название — Scrumban.
Как внедрить методологию Scrum?
Если вы решили внедрять Scrum, вам понадобится специальный сервис, где можно отслеживать ход выполнения задач в спринте. Самые популярные из них — Jira, Trello, Битрикс. В любом из них можно:
-
Выставлять задачи на текущий спринт;
-
Менять их статусы;
-
Распределять задачи между людьми;
-
Писать комментарии к задачам;
-
Визуализировать ход спринта и т.д.
Но помимо инструментов, важно ещё и подготовить сотрудников. Если в компании в целом много бюрократии, микроменеджмента и жёсткого руководства, то просто внедрить принципы Agile в одной команде не получится. Ведь время будет уходить на долгие согласования между отделами и подготовку отчётов, а вышестоящие руководители будут стремиться постоянно регулировать работу команды и вмешиваться в мелкие процессы. Поэтому прежде чем внедрять новую методику работы, нужно убедиться, что организация в целом к этому готова. Иначе никакой разницы в работе по Scrum и без него заметно не будет.
Если у вас несколько продуктов, протестируйте новую методологию на одном из них. И лучше, если это будет не тот, от которого на 80% зависит ваша прибыль. Если резко переехать на новые стандарты работы, первое время что-то точно будет идти не так. И вряд ли вы захотите, чтобы от этого пострадал доход всей компании.
Вот несколько основных ошибок, которые в начале работы могут привести к тому, что руководство разочаруется в таком подходе:
-
Непонимание целей проекта и того, как вообще работает Scrum. Одна из важных ценностей подхода — это прозрачность. Поэтому все члены команды должны понимать глобальную миссию, цели на спринт, важность каждой задачи и основные принципы работы.
-
Растягивание тайминга встреч. Да, обсуждения очень важны. Но их время не должно растягиваться слишком сильно. Не зря специалисты по внедрению Scrum приводят конкретные цифры, в рамках которых должны проводиться встречи. Если на мероприятия тратится слишком много времени, его не остаётся на саму работу. В итоге руководство просто разочаровывается в методике, потому что производительность падает.
-
Постоянное добавление новых задач. Бэклог формируется один раз на всю продолжительность спринта, и его нельзя постоянно дополнять. То есть если сейчас в организации задачи постоянно прилетают с пометкой “должно быть готово вчера”, то наладить работу по Scrum будет трудно.
-
Неумение оценивать трудозатраты. Если в спринт берётся больше задач, чем команда в состоянии выполнить, то это приводит к тому, что бизнес каждый раз разочаровывается. Ну либо страдает качество выполнения задач, потому что разработчики несутся, стараясь хоть как-то успеть всё, что наметили.
Важно понимать, что внедрять новые процессы — всегда непросто. В начале сотрудники могут саботировать процессы, проваливать каждый спринт, не справляться с объёмом задач (хотя вам кажется, что их уже и так меньше некуда). Чтобы понять, что пошло не так, нужно быть готовым углубляться в процессы и обсуждать неудобства вместе со всей командой.
Преимущества и недостатки метода
Теперь давайте остановимся на плюсах и минусах. Какие-то из них мы уже обсудили, но нагляднее будет, если собрать их в одном месте.
Плюсы Scrum:
-
Люди замотивированы и лояльны за счёт того, что к мнению каждого прислушиваются;
-
В компании не плодится лишняя документация, отчёты и не процветает бюрократия, за счёт чего растёт скорость создания продукта;
-
Система достаточно проста для понимания, логична и понятна;
-
В итоге бизнес получает актуальный продукт, который удовлетворяет все их желания и нравится целевой аудитории, ведь на всех этапах собиралась обратная связь и вносились доработки;
-
Не возникнет ситуации, когда продукт готов, его выпустили на рынок и только потом поняли, что он устарел, неактуален, не решает потребности пользователей и т.д. Без Scrum достаточная аналитика может быть и не проведена.
Минусы такой методологии:
-
Сложно подобрать людей, которые будут гореть идеей продукта и эффективно работать друг с другом;
-
Не подходит для крупных команд, где больше десяти человек;
-
Регулярные встречи с бизнесом могут тормозить процесс;
-
На обучение сотрудников тратятся время и деньги.
Кому подходит и не подходит Scrum?
Глобально Scrum не нужен компаниям, которые создают типовой продукт, где нет никаких неопределённостей. Ведь глобальная задача этой методологии — получать обратную связь, постоянно совершенствовать процессы и вносить изменения в продукт. Потому что на первых этапах может быть до конца неизвестно, как итоговые пользователи его воспримут. А если всё предсказуемо и понятно, то тратить время и деньги на внедрение нового метода, куда входят довольно специфические процессы, нет никакого смысла.
В каких ещё случаях Scrum лучше не использовать:
-
Команда не замотивирована на результат. Если внутри коллектива плохие отношения между сотрудниками, людей мотивирует только жёсткое руководство, а принимать самостоятельные решения они не хотят, внедрить Scrum будет довольно трудно.
-
Заказчик изначально не готов включаться в процесс. Если бизнес не готов принимать участие в планировании спринта, чётко формулировать свои требования и регулярно общаться с разработчиками, то действительно нового и актуального продукта не получится.
Подходит эта методология командам, которые готовы вместе работать над продуктом и брать на себя ответственность, а не ждать пока начальник спросит, готова ли задача. Если в компании уже практикуется мягкое лидерство, то внедрить Scrum будет проще.
Список конкретных сфер, в которых рекомендуют использовать Scrum, назвать будет сложно. Раньше он использовался преимущественно в IT, но сейчас его применяют в маркетинге, образовании, ритейле, промышленности и т.д. Поэтому понять, подойдёт ли метод именно вам, можно, если ещё больше углубиться в тему, пообщаться с коллегами, которые уже его используют, ну и, конечно, протестировать все этапы внедрения Scrum на себе.