Scrum vs Kanban: в чем разница и что выбрать?

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

    image

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


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

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

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

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

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

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

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

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

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

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

    image

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

    image

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

    Swimlanes


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

    image

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

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

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

    Sub-columns


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

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

    image

    Заключение


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

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

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

    А на чем вы остановили свой выбор: Scrum и Kanban? Делитесь своими примерами и наблюдениями в комментариях!
    Hygger 84,88
    Hygger
    Поделиться публикацией
    Комментарии 16
      0
      Дожили — методологию сравнивают с практикой.

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


      Для большинства ошибок лечится установкой четких критериев серьезности ошибки
      — Critical — все валится, система не работает в принципе
      — High — система работает, но невозможно использовать основную функциональность (основная функциональность должна быть перечислена отдельно) — пользователь не может сделать покупку, положить в корзину и т.п.
      — Low — ошибки, с которыми можно жить, сделать нужную операцию другим способом, некрасивости и т.п.
      — Medium — всё остальное.
        0
        Но вот любят несмотря на все регламенты некоторые люди нереализованную возможность создавать список из 50 пунктов автоматически вместо ручного подбора в critical закинуть. Или баг требующий в систему перезайти для исправления. Понятно что утрирую немного, но в целом бывает такое не так уж редко.
          0
          В нашем случае такое случилось ровно после того, как руководство ввело KPI тестировщикам, в котором найденные High приносили больше денег, чем Medium.
        +2
        И как обычно, из Agile манифеста потеряли главную фразу… «Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.»
          0
          Скрам не исключает постоянную доставку фич и багфиксов, а канбан их не подразумевает.

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

              Различные *DD не про управление разработкой, роли менеджера в них нет.

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


            Если у аналитиков платформы такой же поверхностный уровень понимания scrum и kanban, как оно изложено в статье, то я сильно сомневаюсь в качестве реализации.
            Можно привести хоть какие-нибудь преимущества по сравнению с JIRA + Agile add-on?
              0
              Основное отличие от Jira в том, что Jira заточена под разработку ПО и основная ЦА — это программисты, QA и project managers.

              Hygger — софт для product management. Для продуктовых команд, в которых разработка начинается с вижна и стратегии:
              — нужна стратегия и roadmap
              — нужен actionable план для выполнения выбранной стратегии
              — нужно собрать идеи от клиентов и структурировать их
              — нужно приоритезировать идеи и разбить их на релизы
              — нужно держать в курсе маркетинг, продажи, саппорт относительно выхода новых билдов/версий
              — нужно отправить отобранные идеи в разработку и мониторить прогресс их выполнения
              Этот блок называется Strategy.

              И потом уже отправить таски в программинг в спринты или в Канбан. Это — execution. Сейчас в Hygger есть своя разработка — есть и Scrum и Kanban, который ни в чем не уступает Jira. Но скоро мы сделаем интеграцию с Jira и те команды, которые уже «сидят плотно» на Jira, смогут использовать Hygger для product management.

              Чем Hygger отличается от Jira — наличием функционала для работы со strategy — Roadmap и Backlog доски.

              Подробнее про отличия можно прочитать вот тут.
              0
              А как решается проблема с параллельной работой над «задачей»?

              Пример:
              Разработчик закончил задачу и передал ее сразу в 3 подразделения:
              1. Тестирование
              2. Документирование
              3. Code review

              В релиз задача уйдет когда будут выполнены п1 и п2.
              На п3 она останется пока специалист занимающийся «Code review» не просмотрит ее.
                0
                Есть ряд вопросов, будет интересно узнать.
                Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
                Как соблюдается баланс между новыми фичами и правкой багов?
                И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.

                  0
                  Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
                  Мы используем Zendesk.com и Intercom.com для сбора обратной связи от наших пользователей. Скоро сделаем плагин для Hygger, который позволит автоматически отправлять запросы из этих систем в Hygger. А пока наш саппорт менеджер вручную переносит идеи и предложения от пользователей в Hygger на backlog-доску.

                  Также мы постоянно генерируем новые гипотезы роста для увеличения различных показателей. Мы используем AARRR метрики для этого.

                  Анализ конкурентов, чтение статей, книг, юзабилити-тестирование — все это тоже помогает генерировать новые идеи — их мы также заносим на backlog доску. И далее уже мы приоритезируем эти идеи. Более подробно процесс работы с бэклогом я описал в отдельной статье.

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

                  И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.
                  Опыт реальный, а на скриншотах — доски из демо-компании, которая доступна всем, кто регистрируется в Hygger.
                  0
                  Статья интересная.
                  Если разобраться, то Kanban как метод разрабатывался для решения задач в машиностроительном производстве, и только потом он был перенесен на задачи разработки ПО. Соответственно он больше подходит для проектов с большим количеством разработчиков.
                  Scrum же изначально был заточен для задач разработки ПО и он более гибок для этих целей, и подходит для проектов с командами разных масштабов, начиная с малых.
                    0
                    Не буду вступать в долгие дискуссии про термины и чужое понимание принципов (на мой взгляд заблуждений полно и в статье и в комментариях).
                    У меня практический вопрос: Lead Time Distribution Chart, Run Chart, Cumulative Flow Diagram планируется внедрить как фичу? Хотя бы CFD, ибо без него Канбан не особо полезен для анализа и постоянного улучшения.
                      0
                      Да, есть в планах, обязательно сделаем.

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

                    Самое читаемое