Отличие scrum от kanban: в чем разница и что выбрать? / Блог компании Hygger / Хабр

в чем разница и что выбрать? / Блог компании Hygger / Хабр

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

Две популярные Agile-методологии

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

Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:

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

Можно смело согласиться со всеми аргументами, ведь действительно:

• Люди важнее инструментов, потому что несколько человек, объединенных вместе и «заряженных» на одну общую цель могут иметь больший потенциал и прийти в итоге к бОльшему результату.
• MVP-подход в разработке: выпускаем минимально-жизнеспособную версию продукта на рынок ASAP. Все «свистелочки» оставляем на потом.
• Слово «заказчик» очень просится поменять на «пользователь». Требования к проекту надо собирать не у заказчика, а у пользователей будущего продукта. Об этом детально написано у Карла Вигерса и Джоя Битти.

Зачастую в последнее время проект — это стартап. В контексте стартапов приходит на ум «customer development» (оригинальную методику замечательно описал Стив Бланк).

По сути, во время customer development мы проверяем наши гипотезы до начала разработки даже прототипа. Наши цели – убедиться в том, что:

— проблемы, решением которых мы занимаемся, существует в жизни пользователя.

— эти проблемы существенные.

— пользователь будет за них платить

— есть рынок, и это не проблема одного человека.

— есть каналы привлечения пользователей (например Facebook Ads, или Googl Adwords), и мы сможем найти такую стоимость привлечения пользователей, которая будет давать нам прибыль (CAC < LTV).

• Пункт про гибкость нужен тогда, когда ваш UX или менеджер проекта меняет требование в задаче, и программист говорит: «У вас там семь пятниц на неделе». Вот в этой точке пространства и времени вы ссылаетесь на пункт про гибкость. А вообще, нужно “копнуть” глубже. Для чего нужна готовность к изменениям? Для того, чтобы уметь реагировать на обратную связь. Вы запустили фичу в продакшн, собрали статистику поведения пользователей, убедились в том, что надо менять какие-то параметры фичи и отправили ее на допроектирование. И вот у вас уже на проде улучшенная версия функции. Чтобы все это сделать, нужно быть готовым к изменениям (это про Agile) и способность эти изменения улавливать (это про аналитику и данные).

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

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

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

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

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

Вот вы заказываете в Москве на Кутузовском новую Toyota Camry на «максималке», и для вас уже делают зеркала в козырьке (вы выбрали «максималку» как раз из-за зеркал в козырьке). Важный момент тут — мы можем менять приоритеты в любой момент. Мы очень быстро можем переключать станок в другой режим.

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

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера вы залили на прод новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». Вы «даете по шапке» UX, он дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.

В 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 — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.

Что интересного в Kanban позволяет удачно использовать его и в спринтах? Рассмотрим на примере инструмента для управления проектами Hygger.io.

WIP

Во-первых, это WIP (Work in progress). Мы ставим ограничение на число задач, которые может одновременно делать один сотрудник. Выполнять несколько задач одновременно могли только Наполеон и Цезарь. Мы знаем, как они закончили. Поэтому мы бережем своих людей и спасаем от выгорания: они делают только одну задачу в единицу времени.

А если серьезно, то переключение «с задачи на задачу» у программиста в среднем занимает 15 минут. Пока сделаешь чай, пока полистаешь Habr, прочитаешь требования к новой задаче, вспомнишь где ты остановился и найдешь место в коде. Каждое переключение — это выход из потока, а войти в поток не всегда получается — могут мешать внешние раздражители. Поэтому все строго: одна задача на сотрудника. Как мы это контролируем? Вот здесь должно быть понятно:

Когда мы впервые внедряли Kanban, WIP лимиты сразу же показали узкие места в нашем процессе: в колонке Testing скапливалась большая очередь задач  —  наш тестировщик не справлялся с проверкой задач. Задачи очень долго находились в очереди. В итоге, программисты успевали подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать, о чем там шла речь, снова погружаться в детали. Это все издержки, которые понижали наш КПД. Тогда мы подключили на проект еще одного QA и проблема была решена.

Swimlanes

Во-вторых, это Swimlanes. Представьте себе, что у вас «лег» сайт. Как это часто бывает — в рабочее время. Вы делегируете задачу вашему лиду или devops – «Поднять сайт сию же минуту». А он сейчас делает другую задачу и планирует ее закончить завтра после обеда. Что делать? Бежать к нему и умолять переключиться на блокера? Можно, но так вы скоро получите прозвище «черный лебедь». Поэтому мы используем Swimlanes.

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

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

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

Sub-columns

У вас есть колонка Программирование, а за ней – Тестирование. Когда программист закончил задачу, он ее переносит в Тестирование. И получается, что тестировщик как-бы начал тестировать задачу. Но, на самом деле, тестировщик проверяет другую. Да и вообще, вы поставили ограничение WIP на число задач и после того, как программист перенес задачу на тест, у QA нарушен этот лимит. Стало две задачи.

Допустим, программист не будет переносить задачу на Тестирование и оставит ее в Программировании. Но как ему брать следующую задачу, если у него есть WIP лимит, который он не может нарушить. В таком случае, на помощь приходят Sub-columns. Например, для колонки Программирование делаем под-колонки In progress и Done. И когда программист заканчивает задачу, он переносит ее в Done. Когда тестировщик освободится, он возьмет новую задачу из под-колонки Done колонки Программирование и перенесет ее в свою колонку Тестирование.

Заключение

Подводя итоги, хочу отметить, что Scrum — гибкая методика разработки, а Kanban — еще более. Всему свое время и место. Если это разработка нового продукта, то на старте разработки и до релиза лучше использовать Scrum, так как он делает разработку более контролируемой по срокам. Также в Scrum много коммуникаций в команде: ребята обсуждают весь бэклог спринта перед стартом, задают вопросы авторам задачи (UX, продакт-менеджерам, бизнес-аналитикам), оценивают задачи сообща с помощью Planning poker. Scrum помогает детально погрузить команду в суть продукта.

А после релиза продукта начинается совсем другая жизнь: начинает идти обратная связь от пользователей продукта, нужно быстро на нее реагировать. Вы начинаете работать над HADI циклами — вам нужно постоянно проверять различные гипотезы, где на гипотезу может банально влиять цвет кнопки. Вы начинаете измерять и оптимизировать метрики продукта, например, Pirate Metrics (AARRR) и так далее. Все увеличивает ваш цикл разработки, вы начинаете делать много маленьких задач в непредсказуемой последовательности. И для этого как раз идеально подходит Kanban.

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

А на чем вы остановили свой выбор: Scrum и Kanban? Делитесь своими примерами и наблюдениями в комментариях!

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

4. Временные рамки

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

Каждый спринт состоит из четырех последовательных этапов:

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

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

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

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

В Kanban же не требуются обязательные встречи-отчеты. Они могут проводиться раз в месяц или неделю.

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

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

Разница между Scrum и Kanban

12 Сен 2020

Перевод оригинальной статьи

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

Давайте проанализируем каждую конкретную тему Scrum и отличия от Канбана:

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

Итак, что же находится в Канбане? Давайте посмотрим на контраст со Scrum:

• Канбан фокусируется на представлении рабочего процесса команды, давая им возможность визуализировать его и улучшить как можно скорее. Scrum имеет фиксированный процесс и церемонии.
• Канбан позволяет использовать любые именованные столбцы в вашей доске, чтобы проиллюстрировать, где находится каждый элемент, продукт или услуга в рабочем процессе. Scrum фокусируется на результатах с конкретными столбцами: “бэклог”, “бэклог спринта”, “работа в процессе” и “выполненная работа”.
• Канбан ограничивает “работу в процессе» WIP-лимитом. В Канбане необходимо установить ограничения на количество работ, которые могут выполняться в каждом столбце рабочего процесса. В Scrum нет никаких правил на этот счет.
• Одна из самых важных вещей в Канбане — это измерение среднего времени выполнения одного элемента, называемое “временем цикла”. Это очень важно, потому что это дает вам возможность оптимизировать процесс, чтобы сделать работу как можно короче и предсказуемее.
• В Канбан можно вносить изменения по мере необходимости. В Scrum изменения не должны прерывать спринт (хотя, по нашему мнению, это вполне возможно – примечание редактора).

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

Хотите лучше разобраться в Scrum и Kanban?

Тогда приходите на наш тренинг по Agile!

Agile vs Scrum vs Kanban методы управления проектами

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

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

Agile – больше, чем просто методология

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

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

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

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

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

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

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

Scrum – структурный подход на базе Agile

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

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

Преимуществом применения Scrum-методологии является возможность использования универсального коллектива специалистов – вам не придется составлять отдельную команду для каждого нового проекта. Дополнительно в его реализации принимают участие еще 2 участника:

• владелец продукта – это связующее звено между исполнителями и непосредственным заказчиком, специалист, назначенный на этот пост, выполняет функции куратора всей команды;
• scrum-мастер – на него ложатся задачи по организации бизнес-процесса, он проводит собрания членов команды, решает общие вопросы, контролирует соблюдение принципов Scrum.

Особенностями использования Scrum является получение конкретного результата по итогам каждого спринта. Его можно протестировать, представить заказчику, если есть какие-то замечания – тут же их устранить.

Kanban: в приоритете баланс

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

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

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

Kanban vs Scrum – в чем разница?

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

Отличие Scrum от Kanban

Команды

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

В Kanban команда может быть как многопрофильная, так и нет. Средняя численность команды от 5 до 9 человек.

Доска

В Scrum-доска очищается каждую итерацию. В стандарте имеет 3 столбика: To do, In process, Done.

В Kanban, в свою очередь, доска находится в постоянно заполненном состоянии.

Роли

Никаких должностей, а только роли – такова философия Scrum. Если коснуться только основы, то основные роли в Scrum – Product Owner и Scrum Master, а также, если хотите, Команда.

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

Scrum Master ведёт этот процесс. Он не погоняет кнутом команду, а, наоборот, делает абсолютно всё, чтобы её участники могли эффективно работать.

Что же на счет Kanban? А ничего, нет там ролей. Это не хорошо и не плохо. Довольно часто встречаются команды, которым не нужно и не интересно отыгрывать какие-то роли, а нужно просто брать и работать.

Планирование

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

Реализация

В данном пункте хочется отметить, что ограничения есть и у Kanban, и у Scrum. Правда ограничения не идентичны. В Scrum есть чёткие рамки по времени итерации (1 неделя – 4 недели), а в Kanban можно работать в режиме non-stop. В Kanban, в свою очередь, есть ограничения по количеству задач в статусе, а в Scrum такого нет. В Scrum редко идёт оценка именно по количеству задач, так как задача задаче рознь. Одна задача может занимать 10 минут, а вторая – 4 часа (использование SP).

В заключение

По особенностям методологий написаны целые книги, много книг, и писать об этом можно очень долго, хоть про метрики, хоть про тайм-боксы.

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

Мы же предлагаем вам использовать аккумуляцию данных методологий и применять симбиоз. Именно так советуют поступать многие умы человечества в области гибких методологий. В системе управления проектами Scrum Time мы и стремимся к тому, чтобы дать эту возможность. И не просто возможность интегрировать друг в друга, а ещё и управлять: 20% Scrum, 80% Kanban, или как душе угодно.

Сравнение методологий управления проектами Kanban vs Scrum vs Agile

Kanban

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

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

Доска разделена на три логические секции: «ожидание», «работа в процессе» и «завершенная работа». Но Kanban-доска может быть организована несколько иначе, в зависимости от конкретного проекта. Секции доски могут меняться: «ожидание», «работа в процессе», «численность команды», «проверка кода», «тестируется», «результат».

Любой рабочий элемент выглядит как Kanban-карточка (физическая или виртуальная), чтобы было нагляднее отслеживать работу.

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

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

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

Главные элементы помещаются в верхнюю часть списка «ожидание». Приоритет элементов можно изменить.

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

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

Scrum

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

Каждый спринт начинается с планирования, во время которого:

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

Ежедневные скрам-совещания

• На совещаниях присутствуют все участники команды.
• Совещания, как правило, длятся не дольше 15 минут.
• Участники команды отвечают на два вопроса: что было сделано после прошлой встречи, что будет сделано к следующей?
• Обсуждаются блокировщики, слабые места и прочее вопросы.
• В конце спринта проводятся т.н. ретроспективные совещания.
• Демонстрируется готовая работа.

Анализируются два аспекта: успешные детали спринта и то, что планируется охватить за следующий спринт.

По завершении спринта, эти же шаги повторяются для оставшихся элементов бэклога.

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

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

Скрам-мастер. Они занимаются планированием спринтов, проверками, ежедневными совещаниями и пр.

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

Kanban Vs Scrum

В описаниях этих методик немало общего. Но на практике отличий предостаточно.

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

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

Чем отличается Scrum и Agile?

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

Скрам или Канбан? | Data Science

Основы kanban и scrum

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

• «список задач» (to do),
• «работа в процессе» (in progress),
• «завершенная задача» (done).

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

Целью методологии scrum является повышение скорости и гибкости процесса разработки. Ее основные принципы — разделять и оптимизировать. Вся работа, которая может быть разделена на подзадачи, должна быть разделена. Задания распределяются между членами команды и выполняются по очереди.

Сходства между методологиями kanban и scrum

Методологии kanban и scrum имеют некоторые общие черты, уникальные для цикла разработки agile. К ним относятся:

Гибкость

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

Ограничение для незавершенных задач

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

Эмпирический подход

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

Управление потоком

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

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

Визуализация

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

Быстрое и постоянное наличие результата

И scrum, и kanban сфокусированы на быстром и частом выпуске потенциально «готовых» фрагментов работы. В scrum это происходит в конце каждой итерации, обычно после демо.

Самоорганизованные команды

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

Дробление работы на небольшие, но конкретные подзадачи

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

Различия между kanban и scrum

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

Особенности метода scrum

Роли и обязанности

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

Измерение производительности

Scrum измеряет скорость «Velocity» (то есть количество Story Points, которые команда может выполнить за один спринт). После первых спринтов видна скорость выполнения задач и, следовательно, можно более точно планировать.

Каденция

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

Типы совещаний

Методология scrum предполагает проведение четырех типов совещаний: планирование, ежедневные, демонстрационные и ретроспективные.

Методология выпуска

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

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

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

Ключевые метрики

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

Особенности метода kanban

Роли и обязанности

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

Измерение производительности

В kanban-методе измеряется время цикла — среднее время, в течение которого продукт проходит все этапы (например, от «списка задач» до «завершенной задачи»).

Каденция

Каденция kanban основана на непрерывном рабочем процессе. Команда может демонстрировать инкременты так часто, как это необходимо.

Методология выпуска

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

Виды совещаний

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

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

Метод kanban очень гибок к изменениям, которые могут быть сделаны в любое время (когда это возможно).

Ключевые метрики

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

Плюсы и минусы разработки по scrum и kanban

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

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

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

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

Какую методологию выбрать?

Ни одна из этих методологий не является ни идеальной, ни полной. Знаменитый коуч agile и lean Хенрик Книберг сравнил scrum и kanban с ножом и вилкой. Скажем, если вам нужно порезать хлеб, вы возьмете нож, а если решите съесть котлету, вы выберете вилку. Для некоторых блюд лучше использовать два прибора, чем один. Однако могут быть ситуации, когда ни один из них не подходит должным образом.

Источник

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

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

Легко указать на разницу между практиками scrum и kanban, но это только на поверхностном уровне. Хотя практики и различаются, принципы в основном одинаковы. Обе структуры помогут вам создавать лучшие продукты (и услуги) с меньшими проблемами.

Итак, где мы были?

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

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

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

Непрерывная поставка

Scrum: структурированный гибкий подход

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

Каденция Scrum

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

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

Методология выпуска

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

Роли Scrum

Scrum имеет три четко определенных роли.

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

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

Ключевые показатели

Скорость — количество набранных очков истории за спринт — является центральным показателем для команд схватки. Он определяет будущие обязательства по спринту или объем работы, которую команда Scrum берет на себя в будущих спринтах. Если команда набирает в среднем 35 очков истории за спринт (скорость = 35), она не соглашается на отставание в спринте, которое содержит 45 очков.

Изменить философию

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

Подробнее о методологиях Scrum см. Что такое Scrum?

Канбан: постоянное совершенствование, гибкие процессы

Канбан помогает визуализировать вашу работу, ограничивать незавершенное производство (WIP) и быстро перемещать работу из «Выполнено» в «Выполнено».

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

Каденция Канбана

Канбан основан на непрерывной структуре рабочего процесса, которая позволяет командам быть гибкими и готовыми адаптироваться к меняющимся приоритетам. Рабочие элементы, представленные карточками, организованы на доске канбан, где они переходят от одного этапа рабочего процесса (столбец) к следующему. Общие этапы рабочего процесса: To Do, In Progress, In Review, Blocked, и Done . Но это скучно.

Лучшая часть Канбана — это создание настраиваемых столбцов для работы вашей команды. Моя команда отправляет контент, поэтому наши столбцы (упрощенные) идут от Backlog до Prioritized , до Outlines Ready , до Writing , Designing , Technical Review и Shipped . Наш совет помог нам узнать, что мы отправляем примерно один контент в неделю, и где у нас есть узкие места (смотрите на ваш технический обзор !).

Методология выпуска

В канбане обновления выпускаются всякий раз, когда они готовы, без регулярного графика или заранее установленных сроков.

Теоретически канбан не предписывает фиксированное время для выполнения задачи. Если задача будет завершена раньше (или позже), ее можно выпустить по мере необходимости, не дожидаясь контрольной точки выпуска, такой как проверка спринта.

Канбан-роли

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

Ключевые показатели

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

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

Еще один способ справиться с узкими местами — установить лимиты незавершенной работы (WIP). Ограничение WIP ограничивает количество карточек, которые могут одновременно находиться в любом столбце. Когда вы достигнете предела незавершенной работы, такой инструмент, как Jira Software, закрывает этот столбец, и команда набрасывается на эти элементы, чтобы продвинуть их вперед.

Изменить философию

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

Подробнее о методологиях канбана см. Что такое канбан?

Инструменты Scrum и инструменты Канбан

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

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

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

Канбан против схватки: что делать, если вы не можете выбрать?

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

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

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

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

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

Max Rehkopf

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

.

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

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

Вот что вы узнаете:

• 1. Что такое Канбан и как работает Канбан
• 2. Канбан: плюсы и минусы (преимущества, недостатки и преимущества)
• 3.Что такое Скрам и как работает Скрам
• 4. Скрам: плюсы и минусы (преимущества, недостатки и преимущества)
• 5. Что такое Scrumban и как работает Scrumban на практике
• 6. Scrumban: плюсы и минусы (преимущества, недостатки и Преимущества)
• 7. Сравнение Kanban, Scrum и Scrumban

Итак, приступим сразу к делу!

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

Канбан — это производственная система с экономичным планированием, разработанная Taiichi Ohno для Toyota в Японии. С японского канбан переводится как рекламный щит или вывеска. Он использует визуальные подсказки, которые вычисляют:

• Что производить
• Когда производить
• Сколько производить

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

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

Как работает Канбан?

1. Визуализируйте рабочий процесс

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

2. Ограничение незавершенной работы (WIP)

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

3. Управление потоком

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

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

4. Сделайте политики процессов явными.

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

5. Внедрение циклов обратной связи

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

6. Совершенствуйте вместе, экспериментируйте и адаптируйте

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

🕹 Интерактивный пример проекта Канбан в Ora

Преимущества:

✅ Все на одной странице

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

✅ Канбан гибок в производстве

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

✅ Канбан выявляет узкие места в вашем рабочем процессе

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

✅ Канбан легко внедрить

Канбан прост для понимания и не требует смены ролей, например, наличия «Владелец продукта», «Скрам-мастер», «Заинтересованные стороны» и «Скрам-команда», как в Скраме.

Недостатки:

⚠️ Менее эффективен в ситуациях с совместным использованием ресурсов

Предположим, что дизайнер совместно используется группами маркетинга и разработки программного обеспечения. Команде программного обеспечения требуется дизайн UI / UX, а команде маркетинга нужны маркетинговые материалы. В связи с повышенным спросом как на UI / UX-дизайн, так и на маркетинговые материалы, дизайнер не может эффективно расставить приоритеты, и и маркетинг, и разработка могут быть заблокированы.

⚠️ Отсутствие гибкости в изменении ассортимента продукции и потока поставок

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

⚠️ Устаревшая доска Канбан может блокировать разработку

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

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

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

Как работает Scrum?

Методология

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

Уточнение бэклога

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

Совещание по планированию спринта

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

Daily Standup Meeting

Как следует из названия, Daily Standup Meeting — это ежедневная повторяющаяся встреча продолжительностью не более 15 минут, обычно проводимая в начале каждого рабочего дня. Цель ежедневной встречи — синхронизировать Scrum-команду, Scrum-мастера и владельца продукта, разблокируя текущие задачи каждым членом команды, отвечая на следующие вопросы:

«Что я делал вчера?»

«Что я буду делать сегодня?»

«Какие препятствия и проблемы для моих задач сегодня?»

Совещание по обзору спринта

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

Ретроспективное собрание спринта

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

🕹 Интерактивный пример проекта Scrum в Ora

Преимущества:

✅ Scrum устанавливает четкие цели и сроки

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

✅ Scrum помогает справляться с большими проектами.

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

✅ Хорошо подходит для быстро меняющихся проектов разработки

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

✅ Отчетливо видны индивидуальные усилия каждого члена команды

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

✅ Scrum улучшает коммуникацию

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

Недостатки:

⚠️ Scope Creep

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

⚠️ Невозможно отреагировать на внезапные изменения

Поскольку Scrum основан на времени и вся работа запланирована на 1–4 недели Спринтов, которые нельзя изменить после начала, это ограничивает и заставляет Владельца продукта ждать до конца Спринт.

⚠️ Scrum сложно принять

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

⚠️ Scrum может занимать много времени

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

Scrumban — это методология гибкого управления, представляющая собой гибрид Scrum и Kanban.Название Scrumban является комбинацией [Scrum + (Kan) ban]. Scrumban был разработан, чтобы упростить существующим командам Scrum переход на Kanban и изучить методологии бережливого производства.

Scrumban сочетает в себе структуру Scrum с методами на основе потоков и визуализацией Канбана. Это позволяет командам иметь гибкость Scrum и простоту Kanban, при этом не требуя обновления ролей и легко адаптируясь.

Как работает Scrumban?

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

Итерация

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

Планирование по требованию

Планирование в Scrumban основано на спросе и происходит только при срабатывании триггера планирования. Триггер планирования связан с количеством задач, оставшихся в разделе «Задачи» на доске. Когда оно опускается ниже определенного числа, проводится мероприятие по планированию. Задачи, запланированные для следующей итерации, добавляются в раздел доски «To Do».

Приоритизация

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

Планирование размера ковша дает возможность долгосрочного планирования в Scrumban. Он основан на системе трех сегментов, через которые рабочие элементы должны пройти, прежде чем попасть на доску Scrumban. Три периода представляют три разных этапа плана и обычно называются 1-летним периодом, 6-месячным периодом и 3-месячным периодом .

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

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

Доска

Базовая доска Scrumban состоит из трех столбцов: To-Do, Doing и Done . После собрания по планированию задачи добавляются в столбец To-Do , когда член команды готов работать над задачей, он перемещает его в столбец Выполнение , и когда он / она завершает его, он / она перемещает его в столбец Done .

Столбец «Выполнение» может быть расширен дополнительными столбцами в зависимости от рабочего процесса команды.Наиболее распространенные примеры — проектирование, разработка, проверка и тестирование. Кроме того, плата Scrumban должна поддерживать установку лимитов:

• WIP limits — число, представляющее максимальное количество выполняемых задач, которое указано в верхней части столбца. Обычно он равен количеству людей в команде (наиболее оптимально, чтобы один человек работал над одной задачей за раз)
• Пределы To-Do — чтобы проводить более продуктивные собрания по планированию, количество задачи в разделе To-Do также могут быть ограничены.Предел To-Do указан в верхней части раздела To-Do.

🕹 Интерактивный пример проекта ScrumBan в Ora

Команда

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

Принцип вытягивания

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

Фиксация функций

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

Сортировка

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

Преимущества:

✅ Экономия времени

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

✅ Scrumban поможет вам справиться с большими проектами.

Большие проекты состоят из множества функций и задач, которые должны выполняться в течение месяцев или лет.В Scrumban все они могут быть распределены по 1-летнему, 6-месячному или 3-месячному сегменту и приоритизированы короткими 1-2-недельными итерациями.

✅ Scrumban выявляет узкие места в вашем рабочем процессе

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

✅ Все на одной странице

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

✅ Простой в использовании и простой процесс

Scrumban не требует смены ролей и требует специального «Scrum Master» или «Product Owner». Легко получить визуально представленную методологию, состоящую из одной встречи по планированию и простых правил.

✅ Scrumban обеспечивает равенство и меньше стресса в команде

Члены команды в Scrumban выбирают задачи, используя принцип вытягивания.Задачи не назначаются менеджером проекта, и каждый член команды выбирает, какую задачу из столбца To-Do выполнить следующей. Поскольку у всех есть полная видимость проекта, равные права и отсутствие ежедневных выступлений перед руководителями проекта, стресс и разочарование меньше.

Недостатки:

⚠️ Может превратиться в методологию мешанины

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

⚠️ Трудно отслеживать усилия и вклад отдельного члена команды

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

⚠️ Меньше контроля со стороны менеджера проекта

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

⚠️ Устаревшая доска Scrumban может вызвать проблемы.

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

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

Сравнение методологий

904 19 Ограничения незавершенного производства Текущее количество работ

Ограничения 904 Только несколько ограничений 904 процесс

Сравнение преимуществ

индивидуальные усилия члена команды

Заключение

Мы рассмотрели Scrum, Kanban и Scrumban, а также их преимущества и недостатки.Резюмируем:

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

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

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

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

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

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

P.S: Если вы ищете работу по управлению проектами, мы рекомендуем попробовать наших друзей в Jooble. Здесь более 661 тысячи рабочих мест для управления проектами.

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

.

Scrum против. Канбан: знай разницу

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing
    • Jmeter Testing

    JUnit

    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр качества (ALM)
    • RPA
    • SAP Testing
    • RPA

    Управление тестированием

    • TestLink

• SAP

  • • Назад
    • ABAP
    • AP O
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • MMO
    • HANA
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • SAP Tutorials

  000

• Web

• AngularJS
• ASP.Net
• C
• C #
• C ++
• CodeIgniter
• СУБД
• JavaScript

• Назад
• Java
• JSP
• Kotlin
• Linux
• Linux
• Kotlin
• Linux

js

• Perl

• Назад
• PHP
• PL / SQL
• PostgreSQL
• Python
• ReactJS
• Ruby & Rails
• Scala
• SQL

000

• SQL

000

0003 SQL

000

0003 SQL

000

• UML
• VB.Net
• VBScript
• Веб-службы
• WPF