Почему вы выбрали фреймворк Scrum, а не метод управления проектами Kanban? Не можете ответить? Значит — лично вы Scrum и не выбирали. Кто-то сделал это за вас.

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

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

  • Scrum облегчает оценивание задач.

  • Scrum позволяет наглядно представлять задачи.

  • Scrum сокращает ненужную трату времени.

  • Scrum способствует регулярному проведению совещаний.

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

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

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

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

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

Кроме того, я объясню ещё и то, почему каждое из вышеперечисленных достоинств внедрения Scrum характерно и для Kanban. Расскажу я и о том, как применение Kanban усиливает эти достоинства.

Как Kanban усиливает достоинства Scrum

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

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

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

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

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

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

Scrum облегчает оценку задач

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

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

Необходимость оценивания задач ведёт к непродуктивным и ненужным оценочным совещаниям. Я называю их «непродуктивными» из‑за того, что они заставляют разработчиков тратить время на разговоры о том, сколько стори‑пойнтов, два или три, нужно чему‑то назначить, вместо того, чтобы работать и писать код. А «ненужными» они тут названы по причине того, что в системе, перегруженной работой, оценки не имеют никакого значения.

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

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

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

Scrum позволяет наглядно представлять задачи

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

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

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

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

Scrum сокращает ненужную трату времени

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

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

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

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

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

Scrum способствует регулярному проведению совещаний

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

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

А вот ежедневные стендапы и ретроспективные совещания — это, с другой стороны, полезные и продуктивные мероприятия.

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

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

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

Итоги

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

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

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

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

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

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

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

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

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

О, а приходите к нам работать? ???? ????

Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.

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

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

Присоединяйтесь к нашей команде.

Комментарии (13)


  1. MAXH0
    15.05.2023 08:45

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


  1. Aleks_ja
    15.05.2023 08:45

    А как в Канбане с планированием и приоритизацией?

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

    Оценка также помогает приоретизации.

    Получается, если у вас Канбан, то оценить весь проект вы можете только при помощи "чуйки". Например, "думаю у нас займет запилить эту фичу - 3 месяца". А в Скраме - можно это оценить в зависимости от "velocity". И сказать Product Owner-у - за спринт мы можем сжигать 40 принтов - можешь сам накидать user stories и видеть, что будет сделано через 2 недели, и прикинуть, что будет в следующие спринты и что и когда будет готово.


    1. khulster
      15.05.2023 08:45

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

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

      Throughput - замеряется сколько задач за выбранный интервал прошли от стартовой точки канбан-доски, до финишной.

      Lead Time и Cycle Time для расчета скорости на различных этапах.

      Поэтому имея перед глазами проект 1, реализация которого занимает, допустим 20, дней, который состоит из 5 этапов, каждый из которых занимает 4 дня вы получаете все нужные вам цифри и вполне сможете наложить матрицу проекта 1 на матрицу проекта 2 для оптимального распределения задач.


      1. Aleks_ja
        15.05.2023 08:45

        Но задачи бывают разной сложности.


        1. khulster
          15.05.2023 08:45

          Конечно. Но ведь и Velocity у нас не про сложность задач, а про эффективность команды в условных попугаях. ;)

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


          1. Aleks_ja
            15.05.2023 08:45

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


            1. khulster
              15.05.2023 08:45

              Так, а почему нет?

              Фикс бага - одна доска.

              Фикс второго бага - вторая,

              Запил фичи - третья.

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

              На интересующем нас отрезке делаем срез и смотрим сколько всего было закрыто. Это и будет наш Throughput. Для которого дальше мы можем прикинуть, что при этом cреднее время фикса одного бага (Lead Time), было X при (Cycle Time) Y.
              А среднее время одной фичи уже X*2, но при этом Cycke Time все тот же Y или не сильно отличается.


              1. Aleks_ja
                15.05.2023 08:45

                Фичи бывают также разных размеров )


    1. Hottych
      15.05.2023 08:45

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

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


  1. devllart
    15.05.2023 08:45

    Я как гофер выбираю Kanban, потому что он не фреймворк)


  1. hippoage
    15.05.2023 08:45
    +1

    Скрам -- это про отсутствие линейного менеджера и групповую динамику (Скрам-мастер -- не менеджер).

    Если есть менеджер, то это уже не скрам (скрам -- организационный фреймворк вокруг расщепления руководителя проекта на скрам-мастера и владельца продукта).

    Перечисленные причины выбора скрам странные, они все как раз больше за Канбан.

    Да, Канбан часто лучше, т.к. мало кто готов к Скрам-мастерам.


  1. slytimer
    15.05.2023 08:45
    +1

    По моему опыту (компания около 100 dev команд, где 60% собственная разработка и 40% внешняя) - собственная разработка где гибкость важнее - больше чаще выбирают скрам если проекты стабильные и переходят на канбан в период, когда проект только начинается или завершается. Команды которые в основном работают с внешними системами и выступают в роли постановщика задач/тестировщика - в канбане (но тоже не все). Очень интересная история с командами создания управленки на КХД. Живут по канбану но мы всё время задаёмся вопросом применим ли скрам. А в целом считаю правильным когда оба метода/фреймвока (если вы крупные, то вам и канбан приходится в фреймворк заворачивать иначе не взлетит) существуют в компании и команда САМОСТОЯТЕЛЬНО решает что ей удобнее с учётом жизненного цикла, проекта, технологий, скилов и интереса. Интерес тоже важно. Если команде интересно поработать в скраме - так пусть работают если нравится.


  1. Hottych
    15.05.2023 08:45

    Три мысли на тему:

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

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

    • Я ни разу не видел чистый скрам. Обычно со временем добавляют менеджера. А еще накидайте роадмап на год, очень нужно. Ну и продукт оунер уже всем пообещал, что фича точно выйдет в следующем месяце, а вы ее еще даже не пытались оценивать. Хотя друг рассказывал, что бывает и чистый Скрам :D