Scrum: что это и зачем нужно

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

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

Что такое Scrum

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

”

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

Однако такое «чисто процессное» определение Scrum не вполне соответствует роли этого подхода в современном управлении (на это и намекает вышеприведенное определение из Scrum Guide 2020). Scrum глубже, чем процессы.

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

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

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

Зачем нужен Scrum, и чем он отличается от прежних методологий разработки

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

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

Водопадная модель

До появления Scrum и других подобных подходов чаще всего применялась водопадная модель разработки, где есть последовательные этапы, например:

— формирование первичных требований;
— анализ требований;
— оценка;
— формирование ТЗ;
— разработка;
— тестирование;
— приемка;
— поставка.

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

Итеративная модель

Такие методологии как RUP, появившиеся в конце XX века, были более эффективны за счет итеративной модели: все или некоторые этапы выполняются несколько раз в цикле, а при обнаружении проблем есть возможность вернуться на предыдущий этап. Тем не менее, и здесь первый результат виден клиенту после первой итерации только по окончании всех последовательных этапов. Это может оказаться слишком долго относительно ожиданий заказчиков в XXI веке.

Основная проблема всех подобных методологий и методов разработки — в неполноте и несвоевременности обратной связи от клиентов. Это приемлемо для типовых продуктов, когда потребности клиентов во многом известны по прошлому опыту. Но неприемлемо в ситуации высокой неопределенности требований, которая имеет место для новых инновационных продуктов.

Фреймворк Scrum – эмпирический подход

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

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

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

Выделим 3 главные особенности процесса разработки, основанного на Scrum.

Работа ведется итерациями, которые в Scrum называют спринтами

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

Результатом работы может считаться лишь то, что готово к использованию

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

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

Продукт разрабатывает самоуправляемая команда

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

Начиная с 2020 года, Руководство по Scrum сменило фокус с самоорганизованной команды разработчиков на самоуправляемую Scrum-команду. Это еще больше подчеркнуло важный факт: разработчики, скрам-мастер и владелец продукта находятся в одной лодке, ответственность за результат эта Scrum-команда несет как единое целое. Самоуправление в Scrum подразумевает самостоятельность не только в выборе того, кто и как будет делать работу (самоорганизацию), но и в выборе того, над чем именно работать, чтобы достичь цели продукта.

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

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

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

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

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

• Команда является «кросс-функциональной»: она должна включать всех необходимых для разработки данного продукта специалистов.
• При этом число разработчиков должно быть небольшим: до 9 человек. (А для больших продуктов есть дополняющие Scrum подходы к организации разработки одного продукта несколькими командами: например, Large-Scale Scrum.)
• В идеале, все участники команды выделены на 100% для работы по этому продукту, не отвлекаясь на что-либо другое.
• По возможности, состав команды не меняется по протяжении всей разработки продукта.
• Scrum не признает различия ролей между разработчиками, чтобы стимулировать кросс-функциональность и обмен компетенциями между ними. Это делает команду независимой от внешних специалистов и более готовой к таким неизбежным ситуациям как болезнь, отпуск или уход одного из членов команды.
• Scrum устроен так, чтобы стимулировать разработчиков работать совместно и помогать друг другу закончить каждый взятый в спринт элемент бэклога.
• Это в конечном итоге приводит к тому, что разработчики не нуждаются в руководителе (team lead), который распределял бы задачи между членами команды и контролировал бы передачу их результатов по цепочке.

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

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

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

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

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

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

Иногда владельца продукта путают с менеджером проекта. Это совсем не одно и то же:

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

Подробнее об отличиях владельца продукта и менеджера проекта смотрите в 4-минутном видео от Дмитрия Кустова:

Scrum-мастер

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

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

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

В чем заключается повседневная работа Scrum-мастера — смотрите в видео от Василия Савунова:

А как директивные руководители постепенно превращаются в Scrum-мастеров — подробно рассказывает статья Василия «От контроля к самоорганизации в команде».

Agile и Scrum: в чем разница и что общего

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

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

Основную цель Agile и Scrum часто формулируют как сокращение Time2Market — времени выпуска на рынок новых продуктов / времени их поставки потребителю.

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

Ценности Agile:

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

Agile и Scrum: конкретный пример

Это реальный пример из одного крупного российского банка. Он иллюстрирует не столько процесс на базе Scrum, сколько практическое применение Scrum-командой следующих принципов Agile:

• «Изменение требований приветствуется, даже на поздних стадиях разработки.»
• «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды» .

Ситуация: бизнес отдал разработчикам техническое задание про SMS-рассылки для заемщиков с задолженностью, в которых предлагалось простить им пени за просрочку, если они перейдут по ссылке и отправят в банк обязательство погасить долг в такой-то срок. Разработчики почитали ТЗ и оценили срок проекта в 3 месяца, что совершенно не устраивало заказчика.

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

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

Разработчики стали предлагать оптимизацию задания, чтобы достичь той же цели быстрее и дешевле:

•  Например, для SMS с именем-отчеством нужно было бы сделать интеграцию с базой личных данных. Было предложено вместо «Иван Васильевич» писать просто «Уважаемый клиент».
• Также в ТЗ было требование сводить в отчете вместе разные данные: базу личных данных, базу получивших SMS, базу переходов по ссылкам из SMS и базу для проверки факта погашения задолженности. Но в общении выяснилось, что в аналогичных случаях свести такие данные вместе — это ручная работа. Было принято решение пока не тратить ресурсы на такой не относящийся к цели отчет (делая его вручную до тех пор, пока гипотеза не будет проверена).

В итоге, поговорив с заказчиком, разработчики предложили довольно много оптимизаций, и сообща выработали внятное видение MVP требуемого функционала. И этот MVP (Minimum Viable Product) был сделан всего за 2 недели.

Какие компании применяют Scrum

В первом десятилетии XXI века Scrum стал самым популярным среди гибких подходов к разработке новых программных продуктов. Однако сейчас фреймворк успешно используется во многих других индустриях: в материальном производстве (например, Северсталь, SOKOLOV), в маркетинговых агентствах и дизайнерских студиях, в телеком-компаниях (Tele2, МТТ), в фармакологии (BIOCAD), в розничных сетях (X5 Retail Group, МВидео) и др.

Наиболее известные в мире кейсы внедрения Agile и Scrum — Google, Amazon, Zappos.

Российские кейсы применения Scrum вы можете найти в видеозаписях докладов ежегодной конференции AgileDays от руководителей из таких компаний как UnitedTraders, Технологический Центр Дойче Банка, SEMrush, Uniscan-Research, QIWI, Банк Агророс, Додо Пицца и от десятков других.

Например, в 2016 году у компании Северсталь появилось желание ускорить выпуск на рынок новых марок стали. Изначально этот процесс занимал в среднем 2-2,5 года и иногда к моменту появления их на рынке, они часто не находили спроса, или оказывалось что конкуренты (в частности, Китай) уже закрыли потребность рынка в этой марке стали. Компания запустила первые пилотные команды для разработки продуктов по Scrum. Они оказались успешными — срок разработки новой продукции сократился с 2,5 лет до 4 месяцев.

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

Scrum — это не для всех

Чтобы Scrum был выгоден, нужно немало условий. В частности:

1. Должно быть поле для экспериментов и исследований. Если задачу можно просчитать от начала до конца, а полезность результата зависит от точного выполнения плана или алгоритма, то смысла работать по Scrum нет никакого. Это просто будут неоправданные расходы на формирование выделенной под продукт команды, на Scrum-мастера, на проведение встреч этой командой и т.д.
2. Стоимость ошибки не должна быть слишком большой. Scrum изначально предполагает, что мы многого не знаем на старте и в процессе работы. Поэтому работа идет итерациями: сделали шаг, проверили наше понимание потребности заказчика, и если все хорошо, идем дальше. Если нет — переделываем. То есть, переделки заложены в самом процессе, ради быстрого движения в правильном направлении. По Scrum нельзя, например, построить ядерный реактор или сделать хирургическую операцию, так как цена ошибки будет слишком большой.
3. Заказчик должен быть готов вовлекаться в процесс и давать обратную связь. Если он просто ставит ТЗ, затем отстраняется и появляется только в конце, чтобы принять работу, то ничего не получится. Scrum построен на плотном общении с заказчиком и вовлечении его в корректировку направления движения.

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

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

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

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

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

Попытка внедрить Scrum там, где он не подходит

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

Подробнее о том, когда и зачем нужны Agile и Scrum, вы узнаете из бесплатных видеоуроков Алексея Пименова (11 видео, 65 минут).

Неверное понимание зон ответственности

Типичный пример: владелец продукта не наделен полномочиями формировать видение и состав продукта, он скорее является бизнес-аналитиком, поэтому не может сказать «нет» заказчику.

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

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

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

Не меньше проблем бывает и с зоной ответственности Scrum-мастера.

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

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

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

Scrum без Agile: карго-культ Scrum

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

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

Другими словами, в компании есть все атрибуты Scrum: бэклог, доска, ежедневные встречи и что-то похожее на демонстрацию результата в конце спринта. Формально все вроде бы соблюдают методику, но вот про ценности Agile забывают. Дмитрий Павлов в своей статье Антипаттерны Agile-команд называет подобное поведение «Scrum-турбацией».

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

Что касается Scrum-доски:

• Доска должна служить «информационным радиатором». Для этого вся команда должна ее видеть ежедневно, а доска не должна быть перегружена техническими деталями: беглый взгляд на доску должен сразу давать представление о ключевых проблемах, которые могут помешать успешному завершению спринта.
• Доска должна помогать сплочению команды и взаимопомощи. Если команда решает заменить один столбец «В работе» на столбцы «Анализ», «Разработка», «Тестирование», то это с большой вероятностью приведет командной безответственности («Я свою часть работы сделал, теперь дело за тестировщиком»). И в итоге это может приводить к провалу спринтов (многие элементы бэклога спринта могут зависнуть в столбце «Тестирование», тогда как некоторые члены команды под конец спринта бездельничали, сделав «свою часть работы»). Вообще говоря, выделение столбцов для каждой из стадий работы над задачей вполне возможно, но команда должна учитывать эти риски.

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

Применение практик Scrum без Agile-мышления нередко называют «карго-культом», и это — очень частая причина неудачного внедрения Scrum.

Подробнее об Agile-ценностях и карго-культе смотрите в 5-минутном видео Артемия Анцупова:

Как правильно применять Scrum в вашей ситуации

Вы уже разобрались, как должен работать Scrum в теории? И эта статья не разубедила вас в том, что Scrum подходит вашей команде / вашей компании?

Тогда за ответами на вопросы по правильному применению Scrum в вашем кейсе приглашаем вас на онлайн-курс Agile и Scrum, который мы проводим с 2018 года и постоянно совершенствуем. С 2019 года онлайн-занятия курса проходят исключительно в формате практики в мини-командах и разбора вопросов Аджайл-коучем, а вся теория записана на видео и изучается в любое удобное время.

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

Кейсы и материалы для статьи предоставил Василий Савунов, Agile Coach, партнер ScrumTrek. Их дополнил и оформил Алексей Евдокимов, владелец продукта из ScrumTrek.