Scrum kanban: Чем Канбан отличается от Scrum, и причем тут Agile — статья в блоге ScrumTrek

в чем суть и как это работает — Блог

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

 

Определение

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile.  Сам Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.   

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

К отдельным agile-подходам относятся scrum и kanban.

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

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

В чем разница между Scrum и Kanban?

Основу Scrum составляют короткие спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт. 

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

На Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с «передовой» и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда. 

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели. 

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time. 

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.
Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу. 

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

 

Scrum и Kanban на практике

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

Scrum является очень удобным инструментом планирования. Он дает некую гибкость в непосредственном улучшении продукта. К примеру, во многих ИТ-компаниях, его используют раз в две недели для планирования самой разработки. Это помогает не тратить два-три месяца на решение проблемы, а запускать MVP (Minimal Viable Product, минимальный жизнеспособный продукт) и оперативно его дорабатывать после получения обратной связи от пользователей. Kanban,в свою очередь, отлично подходит для мониторинга хода выполнения работ. Ведь его ключевая задача — обеспечить процесс и ход разработки. 

Что выбрать — Scrum или Kanban

Отметим, что каждая методология решает свою проблему. Поэтому все зависит от целей и ожиданий от проекта. К примеру, вы создаете новый удобный мессенджер. Если вы используете принцип Kanban, вы прописываете детальный план, чтобы создать идеальный продукт, — и через год разработки получаете желаемое. Kanban — строгая последовательность задач, равномерная загруженность, четкость на каждом этапе. А если у вас нет конкретного плана? Тогда, на помощь приходит метод Scrum, с которым мелкими «шажками» (спринтами) можно постоянно разрабатывать и улучшать продукт благодаря быстрой обратной связи. В итоге конечный продукт может быть совершенно другим, чем тот, который планировался в начале, но он будет максимально соответствовать ожиданиям пользователей.

Agile, Scrum, Kanban: что это и как работает?

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

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

Мы не будем навязывать мнение, восхвалять один подход и говорить о недостатках другого. Тогда зачем эта статья? Расскажем, что и с чем едят, а вы уже сами сможете сделать выводы — какой фреймворк подойдет вашему проекту. 

Гибкие подходы

Agile — это гибкий структурированный итеративный подход к управлению проектами. Собственно, отсюда и название — Agile — «гибкий, проворный». На самом деле, это нечто большее. Это не отдельная методология, а целая система гибких подходов, в которую входят не только Scrum и Kanban. 

Ценности Agile:

• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.

«Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева», — подчеркивается в Agile-манифесте.

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

Принципы Agile

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

Мотивация — то, на чем держится проект. PM заинтересован в том, чтобы замотивировать команду и обеспечить поддержку владельцам бизнеса. Эффективнее всего это можно сделать на встречах, где передача информации происходит лично, в присутствии всех и вне переписок, чтобы избежать эффекта «испорченного телефона». 

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

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

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

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

Как в Agile отслеживается прогресс проекта? Работающим программным обеспечением. Этот пункт включает в себя все предыдущие. Без успешной реализации каждого предыдущего этапа и следования каждому из принципов, на которых базируется Agile, работающего ПО не выйдет.

Популярные Agile-подходы

Нет какого-нибудь достоверного рейтинга «Самые популярные подходы в проджект менеджменте». Те графики, что гуляют по интернету, едва ли можно считать точными. Дело в том, что для достоверных цифр должны быть опрошены PM-ы со всех уголков Земли — от Америки до Китая. Согласитесь, сложновато. 

Еще одно препятствие на пути создания точной статистики — не все понимают, по какому фреймворку работают, как бы смешно это не звучало. Кому-то, у кого команда состоит из 30 разработчиков, которые объединены в одну команду, может казаться, что он работает по Scrum-у. Кто-то думает, что менеджерит по Kanban-у, при этом раздавая каждому участнику роль в команде (спойлер для новичков: так делать в этом фреймворке ни в коем случае нельзя). Кто-то вообще работает без фреймворков в каноническом понимании и ни капли этого не стыдится.

Scrum и Kanban

С такими неточными исходными данными очень сложно определить, какой из подходов наиболее популярный. Опираясь на практику наших студентов, менторов и спикеров менеджерских направлений, наиболее ходовыми из «чистых» фреймворков являются Scrum и Kanban. Гибридные (50% от одного и 50% от другого) и кастомные не брали в счёт. 

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

Scrum

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

Scrum-команда: можно ли накормить всех двумя пиццами

Некогда Джефф Безос, создатель Amazon, установил правило: каждая внутренняя команда должна включать в себя такое количество сотрудников, чтобы их можно было накормить двумя пиццами. Дело в том, что продуктивно работать и сотрудничать друг с другом можно, только если в команде будет немного людей. Скажем, 5-9. 

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

В такой команде существует 3 роли: 

• product owner (владелец продукта), который по сути выступает в роли голоса заказчика;
• scrum-мастер — мастер-джедай, который координирует работу в команде и является своеобразным мостом между продакт оунером и командой разработки;
• команда разработки — самоорганизующаяся и кросс-функциональная. 

Итерации: почему спринты, а не рабочие недели

Scrum — итеративный подход. Итерации называются «спринтами», их длительность определяется на старте проекта и фиксирована до конца. Обычно спринты длятся от двух до четырех недель (очень редко — одну неделю). Чем они короче, тем легче работать с изменениями. Когда спринт 1- или 2-недельный, легче вносить правки в продуктовый бэклог в случае необходимости, чем когда итерация длится 4 недели. Миллионы корректировок нежелательны во время спринта, но возможны. Если выясняется, что задача в работе не так уж важна для клиента и абсолютно нерелеванта для проекта в целом, то она однозначно убирается. 

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

Скоуп (scope) — содержание проекта: что, каким образом и для кого должно быть сделано, чтобы проект считался реализованным. 

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

Цель фреймворка — закончить спринт, в идеале выполнив все задачи. Самое главное — предоставить клиенту рабочую версию продукта на демо. Бывает, что какую-то из задач не успевают реализовать. Если для того, чтобы фича работала, эта задача не обязательна, не страшно: она перенесётся на следующий спринт. 

Митинги: трата времени или важная стратегическая часть Scrum-а

Митинг. Слово, заставляющее сердца Scrum-мастеров биться быстрее, а разработчиков вздыхать. Последние часто злятся и не понимают, зачем это всё, когда можно просто лишний час поработать. Agile, из которого вытекает Scrum, говорит, что личное взаимодействие важнее и продуктивнее, чем опосредованное. Легче договориться face-to-face, чем в слаке, когда висит 50+ новых сообщений, и уже не помнишь, с чего все начиналось.  

Sprint planning meeting

На этом митинге решается судьба. Нет, не человечества — спринта. На нём присутствуют Scrum-мастер, Product Owner и команда разработки. Владелец продукта рассказывает, какой результат хочет видеть в конце спринта. Разработчики выясняют нужные моменты во избежание миллиона вопросов, которые могут появиться в процессе. Команда разбирается с нагрузкой. Исходя из всего этого определяется цель спринта. Так проходит первая часть митинга. Во второй части команда составляет спринт бэклог — задачи, которые нужно реализовать. 

Длительность митинга зависит от длительности спринта. На собрание по планированию выделяется по 2 часа на каждую неделю в спринте. Если определяем, что спринты будут длиться 2 недели, то на планирование нужно выделить 4 часа. Если весь кофе выпит, спина заболела от долгого сидения на митинге, а длительность перевалила за 8 часов — что-то пошло не так. Задумайтесь: это случайность или есть тенденция затягивать собрания? В случае закономерности скорее всего ваш Scrum нужно масштабировать.

 

Daily Scrum Meeting

Ежедневное собрание, которое помогает синхронизироваться членам команды. Именно синхронизироваться, а не пожаловаться, похвастаться или обвинить всех в этом мире. 

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

Вопросы, которые хоть и повторяются из митинга в митинг, но которые очень помогают понять текущую ситуацию по прогрессу:

• Что было сделано? 
• Что запланировано? 
• Есть ли проблемы, и что может помочь?

Sprint review meeting

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

Время для ревью выделяется прямо пропорционально количеству недель в спринте: для недельного спринта — час, для трёхнедельного — три. 

Sprint retrospective meeting

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

• Что было хорошо? 
• Что было плохо? 
• Что можно улучшить?

Ретро проводится в последний день спринта. Не существует каких-то четких временный рамок. Обычно на этот митинг потребуется 45 минут, умноженные на количество недель в спринте. 

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

Kanban

Если Scrum — структурный подход, то Kanban можно назвать подходом баланса. Визуальный метод, благодаря которому предельно ясно, за что нужно браться в первую очередь. Здесь целью являются выполнение задачи. Изменения и смещения по плану принимаются безболезненно. Никого пиццами кормить не нужно. В Kanban-е нет ограничения по количеству человек в команде и по длительности итераций, нет командных ролей и обязательных митингов. Что есть вместо этого? Обо всём по порядку. 

Командные роли: есть кто живой

Scrum — не Scrum без Scrum-мастера и других ролей. В Kanban-е всё по-другому. Командных ролей нет, есть «команда». «И за всё, что мы делаем, отвечаем тоже вместе!» — слышали такое? Это девиз команды, работающей по Kanban-у, потому что за ход всего проекта отвечают все. 

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

Процесс: бездедлайновый хаос

В Kanban-е нет спринтов. Вся работа над проектом происходит непрерывно. Важные проектные события — планирования, релизы — происходят тогда, когда решит команда. Это может быть конкретный день недели, а может быть «делаем это после того, как сделаем это». Таким образом релизы не привязаны к концу итерации. Сделали существенно раньше, чем предполагалось? Отлично! Сделали позже? Бывает. 

Доска Kanban

Свидетели доудалённого периода еще помнят доску Kanban в физическом виде — доску, на которой происходило распределение задач с помощью стикеров или маркера. Сейчас в основном используются электронные варианты. 

Движение задач на доске происходит слева направо: от статуса To Do, где собраны все задачи для реализации, до Done, где задачи достигают своеобразного дзена. Когда все задачи перейдут в колонку Done, считается, что проект готов.

Задачи на доске визуализированы благодаря карточкам, на которых указан приоритет, нужный для понимания очередности выполнения задач. Для того, чтобы мозг не закипел, а команда не работала над задачами 24 часа в сутки, задачи в каждом из статусов ограничены по их общему весу. Вес — мера, которая показывает, сколько времени «весит» задача. Команда сама определяет на начальном этапе, как долго нужно просидеть над задачей, и ставит каждой задаче свой вес. Если в колонке «Testing» ограничение в 3, то общий вес задач в этом статусе может быть 3. 

Статусы Kanban

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

Основные:

• To Do 
• In Progress 
• Testing 
• Done 

Исходя из потребностей команда может добавить и другие колонки. Например, Blocked — когда задача уже сделана, протестирована, но из-за каких-то ошибок не может быть перенесена в колонку Done как готовая и без багов. 

Что лучше: Agile, Scrum или Kanban

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

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

	Scrum	Kanban
Командные роли	Есть (Product Owner, Scrum-мастер, команда разработки)	Нет
Итерации	Спринты (2-4 недели)	Нет, работа в непрерывном потоке
Митинги	Sprint planning, Daily Scrum, Sprint Review, Sprint Retrospective	Опционально, по решению команды
Коммуникация в команде	Есть, очень много	Есть
Изменения	Нежелательны без надобности  в ходе спринта	Могут произойти в любой момент
Релиз	В конце каждого спринта	Непрерывно
Цель	Закончить спринт	Закончить задачу

Мы не задавались целью написать в финальной части статьи «…как вы понимаете, лучше всего работать по…».   Лучше всего в выборе подхода или фреймворка для вашего проекта поможет ваше личное понимание и здравый смысл. Между ценностями подхода в управлении проектами и вашими должен быть мэтч. 

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

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

Professional Scrum™ с сертификацией Канбан

Сертификация Professional Scrum with Kanban (PSK I) подтверждает ваши знания о том, как команды Scrum могут использовать Scrum с Kanban для поддержки создания и доставки ценности.

PSK I гарантирует, что вы понимаете, как Скрам-команды могут использовать Канбан. Многие вопросы требуют, чтобы вы обдумали или интерпретировали сценарии, основанные на теории из Kanban Guide for Scrum Teams и Scrum Guide.

PSK Я также проверяю вашу способность применять концепции из предметных областей PSK и, в некоторых случаях, применять ваш собственный опыт. Хотя присутствие не является обязательным условием, настоятельно рекомендуется пройти курс Professional Scrum with Kanban.

PSK I основан на предметных областях Professional Scrum с Kanban: 

• Понимание и применение Scrum Framework :
  • Как можно использовать Scrum и Kanban вместе для получения большей выгоды без ущерба для основных принципов Scrum или Kanban
• Дополнительные практики :
  • Канбан-практики
    • Знание практик Канбана, перечисленных в Руководстве по Канбану для Scrum-команд
  • Гибкие метрики для Канбана
    • Знание обязательных метрик, перечисленных в Канбан-руководстве для Scrum-команд, и способы их эффективного использования

Перевод

Многие люди успешно используют плагин Google Translate для прохождения теста на своем родном языке. Если вы планируете использовать подключаемый модуль Google Translate, НЕОБХОДИМО следовать этим инструкциям по использованию подключаемого модуля Google Translate. Мы не можем гарантировать качество перевода, однако отзывы были довольно хорошими.

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

Мы очень серьезно относимся к этим соображениям и рассматриваем каждый случай индивидуально. Пожалуйста, свяжитесь [email protected] в отношении ваших обстоятельств, и мы можем посоветовать вам, что делать дальше.

Готовы сделать следующий шаг?

Купить Подготовить Старт

Сведения о сертификации

• Плата: 200 долларов США за попытку

• Проходной балл: 85%

• Лимит времени: 60 минут

• Количество вопросов: 45

• Формат: множественный выбор, множественный ответ и верно/неверно

• Бесплатные цифровые учетные данные Credly в комплекте

• Рекомендуемый курс: профессиональный Scrum с Канбан

• Практические оценки: Scrum с Kanban Open

• Бессрочная сертификация — ежегодная плата за продление не требуется

• Пароли не имеют срока действия, но действительны только для одной попытки
   

Почему Scrum.

org

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

Защита целостности процесса сертификации очень важна для нас. Проходя тест на Scrum.org, вы соглашаетесь соблюдать наши Стандарты поведения. Вы не получите информацию о конкретных вопросах, на которые были даны правильные или неправильные ответы, однако вы получите разбивку своей производительности на основе компетенций Professional Scrum.

Узнайте больше о том, чем отличается Scrum.org.

Профессиональный Scrum™ с Канбан-обучением

В курсе Professional Scrum with Kanban вы узнаете, как улучшить свою работу, применяя методы Kanban в контексте Professional Scrum. Узнайте о важности потока и получите практические знания для внедрения методов Канбана, чтобы помочь командам Scrum улучшить свою работу.

Узнать больше

Professional Scrum™ с Канбан-обучением

В связи с вторжением России в Украину мы приостановили все закупки и обучение в России и за ее пределами.

Professional Scrum™ with Kanban (PSK) — это интерактивный учебный курс, основанный на деятельности, который учит опытных Scrum-мастеров и других практиков Scrum, как улучшить свою работу, применяя методы Kanban в контексте Professional Scrum. С помощью теории, тематических исследований и практических упражнений студенты узнают, как методы Канбана могут помочь командам Scrum достичь лучших результатов за счет улучшения рабочего процесса.

Организации, использующие DevOps, непрерывную интеграцию и непрерывную доставку (CI/CD), обнаружат, что добавление потока к их применению Scrum будет естественным дополнением.

Курс также включает бесплатную попытку сдачи всемирно признанного сертификационного экзамена Professional Scrum with Kanban (PSK I).

Обзор курса

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

Студенты узнают, как оптимизировать свой рабочий процесс, добавив в Scrum четыре практики Kanban:

• Визуализация рабочего процесса Sprint Backlog на доске Kanban
• Ограничение незавершенного производства (WIP) 
• Активное управление рабочими элементами в процессе 
• Постоянная проверка и адаптация того, как команда использует оптимизацию потока

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

Scrum.org и наши профессиональные тренеры по Scrum работали с Даниэлем Ваканти и Ювалем Йеретом над созданием этого курса, используя их опыт и знания Канбана. В 2007 году Дэниел помог разработать Канбан-метод для умственной работы, в том числе руководил первым в мире проектом по внедрению Канбана. Юваль, автор книги «Канбан Святой Земли», получил награду Brickell Key Award сообщества Lean Kanban за свою работу по созданию сильного сообщества Kanban с несколькими разработками корпоративных продуктов в Израиле и во всем мире. Кроме того, все тренеры этого класса должны иметь реальный опыт работы как в Scrum, так и в Kanban.

Просмотр различных областей внимания, охватываемых этим и другими классами.

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

Цели обучения курса

• Понимание методов потока и Канбана с точки зрения Скрам-команды
• Объясните, как методы Канбана можно использовать для улучшения потока в рамках Спринта
• Повысьте прозрачность, помогая Скрам-команде визуализировать рабочий процесс
• Использование данных для создания ожидаемого уровня обслуживания (SLE) Скрам-команды для повышения предсказуемости доставки
• Применять концепцию потока и методы Канбан во время мероприятий Scrum
• Помочь команде в преодолении проблем с общим потоком, активно управляя НЗП

Кто должен посещать этот класс?

Курс Professional Scrum with Kanban предназначен для опытных Scrum-практиков, которые хорошо понимают профессиональный Scrum и хотят научиться применять методы Kanban в своих Scrum-командах. В идеале, участники должны прочитать Kanban Guide for Scrum Teams и пройти Scrum Open Assessment. Курс особенно полезен для:

• Scrum-мастера  , которые хотят узнать, как поток, метрики потока и другие методы Канбан могут помочь им и их командам Scrum улучшить работу в Scrum 
• Профессиональные практики Scrum  с желанием улучшить свои текущие методы и заинтересованы в том, чтобы узнать, как методы Канбан могут помочь им и их командам улучшить

Сертификация Professional Scrum

Все участники, завершившие курс Professional Scrum with Kanban, получат пароль для попытки сдать экзамен Professional Scrum with Kanban I (PSK I). Участникам класса PSK, которые попытаются сдать экзамен PSK I в течение 14 дней после получения бесплатного пароля и не наберут как минимум 85 %, будет предоставлена ​​вторая попытка без дополнительной оплаты.

Примите участие в профессиональном скрам-классе

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

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

Поиск класса    Найти тренера

Что говорят профессиональные Scrum-студенты с Kanban

Вы также можете узнать больше об опросах студентов PSK и их отзывах.

Trustpilot

Почему Scrum.org

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

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

Чтобы стать PST, они должны иметь несколько лет опыта Scrum.