Kanban и scrum отличия: В чем разница между Scrum и Kanban? — ProductStar на vc.ru

Содержание

В чем разница между Scrum и Kanban? — ProductStar на vc.ru

Расспросили Дмитрия Курдюмова, Agile коуча, основателя агентства Smart Units, о различиях Scrum и Kanban.

2644 просмотров

Дмитрий Курдюмов

Agile коуч, Founder Smart Units

Зачастую при построении процессов разработки возникает вопрос: «Что использовать — Scrum или Kanban? Что подойдет нашей команде?» Давайте разбираться, можно ли их вообще сравнивать.

Скрам

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

Scrum — один из таких фреймворков.

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

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

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

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

Скрам мастер — отвечает за эффективное внедрение фреймворка Скрам в процессы.

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

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

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

Когда использовать Scrum

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

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

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

Спринты).

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

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

ежедневные встречи (daily scrum или standup) — для синхронизации движения к цели спринта
обзоры спринта (review или demo) — для обсуждения готового продукта со стейкхолдерами и пользователями
ретроспективы (retro) — для обсуждения улучшения работы Скрам-команды

Работа команды и ее взаимодействие со стейкхолдерами должна быть прозрачной. Для этого используется достаточно распространенный инструмент — доска, на которой визуализируются все процессы и работы. Так как Scrum отвергает разделение ответственности и ярко выраженные этапы (например, они могут идти параллельно), количество колонок зачастую минимально, их три: to do — взяли на спринт, in progress — в процессе, done — имеем результат.

Kanban

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

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

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

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

Как начать использовать Kanban

Визуализировать работу и процесс.

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

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

Ограничить одновременно выполняемые работы.

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

Начать собираться вокруг доски и управлять потоком работы.

Например, можно проводить ежедневные встречи, на которых будет определяться план работы на день, будут рассматриваться “зависшие” задачи и оперативно приниматься решения по их урегулированию. Также, важно смотреть на метрики потока и строить гипотезы об их улучшении. Цель — создать плавный процесс прохождения работы через систему, минимизируя препятствия и потери.

Внедрить понятные правила работы.

Для каждого члена команды работа с канбан должна быть прозрачной. Крайне важно убедиться в том, что все понимают “правила игры”. Чтобы избежать недопонимания, необходимо эти правила зафиксировать и визуализировать для общей вовлеченности: например, какие критерии готовности каждого этапа системы, какие задачи являются приоритетными, как определить необходимость пополнения бэклога идей и так далее.

Совершенствовать процессы.

Канбан-метод — это не просто инструмент управления работами. Это метод эволюционных улучшений: с помощью визуализации метрик мы можем отследить несовершенства процессов и на их основе модернизировать функционирование команды. Главная цель канбан-метода — постоянные улучшения на основе метрик и экспериментов.

Как получить максимум?

Если вы заняты в сфере разработки и создаете продукт, оптимальным решением для вас будет использовать фреймворк Scrum, усиленный Kanban-методом. Например:

визуализацией всех этапов разработки от Discovery (когда происходит уточнение продуктовой ценности), до Delivery (когда происходит доведение выбранных задач до готовности)
визуализацией стратегических инициатив, крупных задач, которые будут двигаться по доске, а вы будете управлять ими

ограничением одновременно выполняемой работы на этапах
внедрением системы метрик времени выполнения

Резюмируем:

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

Также, важный момент — не всегда уместно сравнивать Scrum и Kanban, так как Скрам — это фреймворк, а Канбан — это инструмент. Они вполне могут использоваться вместе, дополняя друг друга.

Телеграмм-канал Дмитрия: https://t.me/agilegurukitchen

Больше узнать об управлении командой и проектами можно на курсе “Project manager” с гарантированным трудоустройством и обучением на реальных кейсах.

А если определиться с направлением профессии сложно, приходите на бесплатную карьерную консультацию с топовым экспертом сферы IT.

✔️ Ключевые различия между Agile, Scrum и Kanban

Что такое Agile?

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

В феврале 2001 года на лыжном курорте The Lodge at Snowbird(США,Юта) собрались семнадцать менеджеров крупных компаний, работающих над проектами по разработке программного обеспечения. На повестке дня стоял злободневный вопрос – разработка универсального набора принципов, ведущего к улучшению организационных мероприятий по созданию бизнес-проектов для любого направления деятельности и размера команды. Результатом их совещания стал грамотно составленный управленческий кодекс под названием Agile Manifesto. В основе этого документа, использующегося теперь во многих отраслях жизнедеятельности человека, лежат четыре основные ценности или концепции управления проектами.

1. Люди и взаимодействие между ними важнее процессов и инструментов

Чтобы получить четкое представление о требованиях сторон, условиях работы и остальных стратегически важных нюансах, требуется правильная коммуникация между бизнесом и разработчиками. Хотите построить по-настоящему адаптивно-гибкий процесс взаимодействия по схеме заказчик-исполнитель – научитесь общаться между собой!

2. Работающий продукт или программное обеспечение важнее исчерпывающей документации

Методология Agile не заставляет полностью отказываться от документации, а ограничивает ее составление несколькими самыми необходимыми документами. Оформление требований, спецификаций, проспектов, проектной сметы, планов испытаний и утверждения отнимает у разработчиков довольно много времени. Вместо этого в Agile мы создаем «User Stories» – некий пошаговый список дел, составленный клиентом в соответствии с его приоритетами. Его достаточно, чтобы специалисты начали работу над проектом, не обращая внимания на бюрократические издержки.

3. Сотрудничество с клиентами в ходе переговоров важнее длительного согласования условий контракта

Как правило, при обычной постановке дел, заказчик взаимодействует с командой разработчиков на этапе обсуждения требований и сроков, а также по завершении работы – для получения обратной связи и предложений.

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

4. Оперативное реагирование на изменение вместо следования плану

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

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

Что такое Scrum?

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

В Scrum циклы называются «спринтами» и, как правило, длятся от одной до четырех недель. Работа поэтапная и каждый этап целиком зависит от предыдущего. Scrum-команды обычно небольшие, от трех до девяти человек со scrum-мастером, отвечающим за правильное применение методологии и владельцем продукта, отвечающим за успех всего предприятия. Коммуникация с членами команды – последовательна, с постоянной обратной связью. Это наиболее часто используемая методология Agile. Согласно отчету State of Agile, опубликованному в 2021 году статистическим сайтом digital.ai, около 66 процентов пользователей Agile используют при работе Scrum.

В основе методологии лежат три принципа работы:

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

Scrum отлично подходит для работы со сложными задачами в изменяющихся условиях, а также для новаторских новых проектов – стартапов.

Однако Scrum и Agile невзаимозаменяемые термины.

Agile и Scrum

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

Ключевые сходства этих двух определений, отчетливо делающие Scrum Agile-процессом:

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

Вот что отличает Scrum от других методологий Agile:

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

Что такое Kanban?

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

Scrum и Kanban

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

Основное различие между рассматриваемыми agile-фреймворками — в длине итераций. В Scrum, как мы уже говорили, между этапами разработки проходит 2-3 недели, в Kanban же задачи работникам можно «подкидывать» хоть каждый день.

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

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

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

Подытожим, в Scrum наша цель — закончить спринт, в Kanban — задачу.

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

А еще в некоторых компаниях, менеджеры проектов объединяют концепции Scrum и Kanban в гибридную методологию, называемую Scrumban.

***

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

Основной ресурс – люди!
В топку бюрократическую волокиту.
Клиентоориентированность навсегда.
Оперативность реагирования на все поступающие задачи, но без фанатизма.

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

Материалы по теме

Хватит говорить об Agile. Почему нельзя просто работать?
Scrum мастер и Agile Scrum: 20 вопросов собеседования
Применение принципов Agile на практике

Канбан

против Scrum: в чем разница?

Оглавление

При выборе между Канбан и Скрам не всегда нужно проводить индивидуальное различие, потому что Канбан и Скрам могут идти рука об руку. Вот больше о Kanban и Scrum, их сходствах и различиях.

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

Справочник Agile-менеджера: Как стать эффективным Agile-лидером

Изучите основы Agile-лидерства, включая 5 основных навыков, которыми должны обладать все Agile-менеджеры.

Просмотреть электронную книгу • Справочник Agile-менеджера

Бесплатная пробная версия AgilePlace: программное обеспечение AgilePlace Online Kanban

Подпишитесь на 30-дневную бесплатную пробную версию, и вы и ваша команда сможете начать создавать онлайн-доски Kanban уже сегодня. Убедитесь сами, как AgilePlace поддерживает инициативы непрерывной доставки, устраняет потери и улучшает процессы и скорость доставки вашей команды.

Начните бесплатную пробную версию • Бесплатная пробная версия AgilePlace

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

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

Канбан против Scrum

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

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

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

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

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

Является ли Канбан Скрам?

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

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

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

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

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

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

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

Что подходит именно вам? – Forbes Advisor

Редакционная заметка: мы получаем комиссию от партнерских ссылок на Forbes Advisor. Комиссии не влияют на мнения или оценки наших редакторов.

Гетти

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

Избранные партнеры

Monday.com

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

через веб -сайт Monday.com

Clickup

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

на веб -сайте ClickUp’s

Wrike

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

На защищенном веб-сайте Wrike

Канбан и скрам Краткий обзор

Позже мы рассмотрим эти концепции более подробно. А пока вот краткий обзор того, как складываются Скрам и Канбан.

Каденция планирования	Контуры обратной связи	Спринт с фиксированной длиной
Важные показатели	Незавершенное производство (WIP) Совокупная блок-схема (CFD)	Скорость
Философия изменений	Быстрая адаптация в ходе проекта	Нельзя менять посреди спринта; использовать информацию для адаптации к будущим спринтам
Задействованные роли	Диспетчер предоставления услуг Диспетчер запросов на обслуживание (Роли не всегда необходимы, так как каждый член команды Канбан может брать на себя обязанности, связанные с этими ролями)	Владелец продукта Скрам Мастер-разработчик
Популярные программные инструменты	Канбанизе Monday. com Трелло КанбанФлоу МейстерТаск Хюггер Джира (программное обеспечение)	нТаск Цепель Джира (программное обеспечение) Спринтли Йодиз Трелло Зохо Спринт

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

Что такое канбан?

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

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

Канбан-доски

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

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

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

Почему в Канбан-командах часто не хватает выделенных ролей

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

Хотя определенные роли не обязательны, есть несколько примечательных должностей, которые могут быть в Канбан-команде:

Менеджер по предоставлению услуг: Иногда его называют SDM, менеджером потока или мастером потока. в первую очередь касается повышения эффективности рабочего процесса. Они достигают этого путем проведения регулярных совещаний, наблюдения за доской, чтобы убедиться, что рабочие задачи не блокируются, и общения с членами команды, чтобы убедиться, что они соблюдают сроки выполнения задач.
Кроме того, менеджеры по предоставлению услуг ищут возможности минимизировать потери и оптимизировать рабочий процесс. Они также следят за соблюдением политик и отслеживают удовлетворенность клиентов.
Менеджер запросов на обслуживание: В то время как менеджер по предоставлению услуг стремится поддерживать эффективность команды, менеджер запросов на обслуживание (SRM) в конечном итоге заботится об удовлетворенности клиентов. SRM обычно отвечает за отправную точку поступающих проектов. Они ведут обсуждения, в которых определяется приоритетность каждой части проекта, в конечном счете, с намерением предоставить клиентам наибольшую ценность.

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

Что такое скрам?

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

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

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

Спринты

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

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

Церемонии Scrum

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

Планирование спринта: В начале спринта встречаются владелец продукта, скрам-мастер и разработчики. Владелец продукта раскрывает бэклог продукта и связанные с ним приоритеты. Вместе команда определяет продолжительность спринта в зависимости от того, сколько времени, по их мнению, потребуется для создания высококачественного конечного продукта.
Ежедневные скрамы или стендапы: Быстрое утреннее совещание, обычно в среднем 15 минут. Они известны как «стоячие выступления», потому что часто настолько кратки, что ни у кого нет возможности сесть. Владелец продукта, скрам-мастер и разработчики быстро регистрируются. Участники делятся тем, что они сделали в предыдущий день, что они надеются сделать в этот день, и информируют команду о любых потенциальных проблемах. Несмотря на то, что они проходят быстро, эти ежедневные Скрамы имеют решающее значение для прозрачности, подотчетности и предотвращения любых потенциальных блокировок.
Обзоры итераций: Проводятся в конце спринта. Акционеры могут присоединиться к этому собранию, но обычно это не требуется. Обзоры дают команде Scrum возможность поделиться своими достижениями. Для контроля качества члены команды должны выделять свою работу только в том случае, если она соответствует минимальным стандартам выполнения. Так как в спринты уходит так много тяжелой работы, тон, как правило, состоит из поздравлений и чувства взаимной гордости.
Ретроспектива: После обзоров команда собирается, чтобы внимательно рассмотреть результаты спринта. Что сработало хорошо или замедлило процесс? Что клиенты говорят о конечном продукте? Эта внутренняя и внешняя обратная связь играет решающую роль в задании тона для будущих спринтов.
Дело не только в критике; это действенная критика, помогающая Скрам-команде достигать большего и быстрее.
Уточнение невыполненной работы по продукту: Уточнение невыполненной работы над продуктом представляет собой возможность привести в порядок невыполненную работу путем добавления деталей, корректировки оценок или изменения приоритетов. Это неофициальное событие, поэтому на него не всегда ссылаются. Как правило, эти встречи происходят ближе к концу спринта и часто содержат вопросы, возникающие на начальном этапе планирования.

Некоторые церемонии Scrum могут длиться часами или несколькими минутами; обычно это зависит от характера встречи и отведенного времени для рассматриваемого спринта.

Роли в Скрам-команде

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

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

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

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

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

Скрам-мастер

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

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

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

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

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

Канбан и Скрам: ключевые отличия

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

Каденция расписания

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

Важные метрики

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

Метрики Канбана

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

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

Метрики Scrum

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

Философия изменений

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

Какой из них лучше для вас?

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

Scrum лучше, если вы:

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

Канбан больше подходит для ваших нужд, если вы:

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

Возможно, вы объедините аспекты каждого подхода. Например, команда Scrum может использовать доски Канбан. Но, в конце концов, все сводится к убеждениям и, возможно, к проверке того, какая система лучше всего соответствует вашим конкретным потребностям.

Часто задаваемые вопросы

Канбан лучше скрама?

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

Являются ли Kanban и Scrum частью методологии Agile?

И Kanban, и Scrum считаются Agile по своей природе; просто приоритеты в каждой методике и подход к выполнению задач существенно различаются.

Сколько человек вы должны добавить в команду Scrum?

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

Как выбрать между Kanban и Scrum?

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

Существуют ли другие виды методологий управления проектами, кроме Kanban и Scrum, которые следует учитывать?

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

Эта статья была полезной?

Оцените эту статью

★ ★ ★ ★ ★

Пожалуйста, оцените статью

Пожалуйста, введите действительный адрес электронной почты

Комментарии

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

Неверный адрес электронной почты

Спасибо за отзыв!

Что-то пошло не так. Пожалуйста, попробуйте позже.

Еще от

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

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

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

Роб — писатель и редактор SMB из Нью-Джерси. До прихода в Forbes Advisor он был продюсером контента в Fit Small Business. В этой роли он отвечал за написание, редактирование и разработку стратегии контента, ориентированного на владельцев малого бизнеса. До этого он работал в PCMag бизнес-аналитиком.

Редакция Forbes Advisor независима и объективна. Чтобы поддержать нашу отчетную работу и продолжать предоставлять этот контент бесплатно нашим читателям, мы получаем компенсацию от компаний, размещающих рекламу на сайте Forbes Advisor. Эта компенсация происходит из двух основных источников. Сначала мы предоставляем рекламодателям платные места для представления своих предложений. Компенсация, которую мы получаем за эти места размещения, влияет на то, как и где предложения рекламодателей появляются на сайте. Этот сайт не включает все компании или продукты, доступные на рынке. Во-вторых, мы также включаем ссылки на предложения рекламодателей в некоторые наши статьи; эти «партнерские ссылки» могут приносить доход нашему сайту, когда вы нажимаете на них.