Комментарии 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, где задачи оцениваются и понятно когда они будут сделаны.
Scrum не нужен. Нужно лишь правильно использовать Kanban