Как стать автором
Обновить

Scrum не нужен. Нужно лишь правильно использовать Kanban

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров8.1K
Всего голосов 30: ↑26 и ↓4+22
Комментарии14

Комментарии 14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий