Введение
Методы управления проектами в сфере разработки программного обеспечения, такие как Scrum и Kanban, стали основными инструментами для команд, работающих по методологии Agile. В этой статье я рассмотрю, какие преимущества даёт Kanban по сравнению со Scrum.
1. Отсутствие необходимости в спринтах
В Scrum работа организована в виде спринтов, каждый из которых длится от одной до четырёх недель. Чаще всего команды выбирают двухнедельные спринты. На протяжении этого времени команда обязана выполнить все запланированные задачи, что может создавать давление на исполнителей и вынуждать их принимать не самые оптимальные решения, а также склонять их к «срезанию углов», чтобы успеть всё выполнить к ранее обозначенным срокам.
Никто и никогда не знает реальных сроков выполнения той или иной задачи, поэтому команды впустую тратят своё время, чтобы примерно оценить сроки выполнения. Было бы лучше, если бы это время было потрачено на реальную работу, а не попытки угадать сроки выполнения задач.
Если во время планирования спринта исполнитель сообщает о коротких сроках выполнения, то на спринт ему просто дают больше задач, чтобы он не скучал без работы. Если же исполнитель называет очень большие сроки, то ему говорят, что это очень долго и что сроки нужно уменьшить. И вообще, у нас тут очень много задач в очереди, поэтому работать надо быстрее и эффективнее.
Примерные сроки выполнения, названные наугад во время планирования, становятся вдруг обязательствами во время спринта, что ещё сильнее демотивирует команду и ведёт к постоянным спорам между исполнителями и Product Owner»ом по поводу сроков и количества задач для спринта.
Второй важный момент. Если человек весь свой объём работы выполнил за одну неделю, то вторую неделю спринта он сидит без работы и скучает, а задачи следующего спринта просто стоят в ожидании. Это, конечно, пытаются обойти всякими «костылями», например, делить задачи спринта на обязательные и которые было бы неплохо сделать, если обязательные будут выполнены раньше срока. Но использование таких «костылей» — это явный признак того, что с методологией scrum имеются большие проблемы.
Третий момент. Scrum — это работа спринтами, т. е. интенсивная работа над задачами в течение короткого промежутка времени. Любой спринт, например, в спорте, предполагает длительную фазу отдыха после окончания спринта. Но в Scrum ничего подобного нет, поэтому команды очень быстро выгорают из‑за постоянных интенсивных нагрузок. Спринты хороши лишь в краткосрочной перспективе, например, чтобы закончить работу, когда до дедлайна осталось всего пару недель или месяц. Scrum же превратил спринты в долгосрочный марафон на выживание, в котором сжигаются целые команды.
Kanban не использует спринты, что позволяет команде работать в режиме непрерывного потока. Задачи выполняются по мере их поступления, и нет необходимости ограничиваться конкретными временными рамками. Команда может адаптироваться к изменениям более гибко и быстро, без необходимости подгонять работу под спринт.
Вместо спринтов Kanban использует ограничение на количество одновременно выполняемых задач, которое называется WIP (Work in Progress). Это один из ключевых принципов, направленных на управление потоком работы и повышение эффективности команды. На Kanban доске WIP обозначает ограничение на количество задач, которые могут находиться одновременно на каждом из этапов рабочего процесса. Эти ограничения являются важной частью методологии и играют критическую роль в обеспечении плавного и стабильного потока работы.
Например, каждый исполнитель может иметь в один момент времени только 2 задачи (Work in Progress). Закончив одну из задач он может из backlog-а взять себе ещё одну задачу, т. е. не менеджер запихивает задачи в workflow, а исполнитель сам вытягивает себе задачу по мере того, как он заканчивает выполнять предыдущую задачу. Исполнитель не может взять себе в работу новую задачу, пока не закончит предыдущую. Этот механизм известен как вытягивающая система, поскольку новая работа втягивается системой, когда она обладает достаточной ёмкостью для этого, а не вталкивается вышестоящим менеджером.
Ограничение WIP (Work in Progress) помогает решить сразу несколько ключевых задач:
Предотвращение перегрузки команды: Без ограничения количества задач, которые могут быть одновременно в работе, команда может оказаться перегруженной. Когда слишком много задач одновременно находятся в процессе, это может привести к снижению качества работы, а также к тому, что задачи будут завершаться медленно. Ограничение WIP помогает сбалансировать нагрузку на команду и предотвращает «затопление» её задачами.
Улучшение потока работы: Ограничения WIP позволяют команде сосредоточиться на завершении текущих задач, прежде чем они смогут взять в работу новые задачи. Команда начинает понимать, на чём стоит сосредоточиться и что необходимо завершить перед тем, как переходить к новым задачам.
Быстрое выявление узких мест: Когда на каком‑то этапе появляется слишком много задач, это может быть сигналом о том, что на этом участке существует узкое место. Например, если в разделе «Тестирование» накопилось слишком много задач, это может означать, что тестировщики перегружены, и необходимо перераспределить ресурсы или оптимизировать процесс тестирования. Ограничение WIP помогает оперативно выявить и устранить такие проблемы.
Повышение качества работы: Когда команда работает над меньшим количеством задач одновременно, у неё появляется больше времени для тщательной проработки каждой задачи. Это способствует повышению качества работы, так как сотрудники не торопятся завершить работу сразу, а могут уделить больше внимания деталям.
Поддержание фокуса и уменьшение многозадачности: Ограничения WIP также помогают снизить уровень многозадачности, что часто приводит к снижению производительности. Когда команда вынуждена завершать текущую задачу, прежде чем переходить к новой, она сохраняет фокус на одном процессе, что повышает общую эффективность работы.
2. Гибкость и отсутствие фиксированных ролей
Одним из главных отличий Kanban от Scrum является отсутствие фиксированных ролей. В Scrum четко определены роли: Scrum Master, Product Owner, и команда разработчиков. Эти роли накладывают определенные обязательства и требуют от участников команды строго придерживаться своих задач и обязанностей.
Scrum Master, Product Owner, Agile Coach, фасилитатор — кто все эти люди? Почему Scrum не может работать без них?
Kanban, напротив, не ограничивает команду жесткими ролями. Команда сама решает, как распределять задачи, и кто за что отвечает. Это предоставляет больше гибкости, так как члены команды могут переключаться между задачами в зависимости от текущих потребностей проекта.
3. Более высокая прозрачность и управление потоком
Kanban делает акцент на визуализации рабочего процесса с помощью доски Kanban. Задачи на доске проходят через различные этапы: от «Backlog» и «To do» до «Done», что даёт полное представление о текущем состоянии всех задач в проекте. Такой подход позволяет всем членам команды и заинтересованным сторонам быстро оценить, на какой стадии находятся работы и какие задачи требуют дополнительного внимания.
В Scrum каждая команда планирует задачи на конкретный спринт, но нет такой же глубокой визуализации потока задач, как в Kanban. Scrum ориентирован на завершение определенного объёма работы в ограниченное время, что может затруднить наблюдение за прогрессом работы в реальном времени.
4. Процесс непрерывного улучшения
Хотя Scrum включает регулярные ретроспективы для оценки и улучшения процесса, Kanban позволяет внедрять изменения гораздо более гибко и постепенно. В Kanban можно внедрять улучшения по мере выявления проблем, в отличие от Scrum, где улучшения часто происходят в рамках определенных спринтов.
5. Более эффективное управление при изменяющихся приоритетах
В проектах, где приоритеты могут изменяться часто, Kanban может быть более подходящим выбором, чем Scrum. В Scrum изменения приоритетов между спринтами могут привести к нарушению планов и перераспределению задач, что требует времени и усилий. В Kanban изменения могут быть внесены мгновенно — задачи могут быть переоценены и перемещены по доске без необходимости ждать завершения спринта.
Это особенно полезно в динамичных средах, где важно быстро реагировать на изменения в бизнесе или на рынке.
6. Нет необходимости в сложном планировании
В Scrum планирование является важной частью работы. Команды должны заранее определить задачи на весь спринт и утвердить их на планировании. Это может стать затратным и временами излишне сложным процессом, особенно если проект динамичен и часто меняются требования.
Большие статьи, как правило, мало кто дочитывает до конца, поэтому если тебе это удалось, то пусть удача и хорошее настроение не покидают тебя весь следующий год.
Kanban, в свою очередь, минимизирует необходимость в детализированном долгосрочном планировании. Задачи поступают и выполняются по мере необходимости, а управление происходит через ограничение работы в процессе и контроль за её потоками. Это упрощает планирование и позволяет команде сфокусироваться на текущих задачах, а не на долгосрочных планах.
Комментарии (42)
ozzyBLR
24.12.2024 05:37Автор говорит: Скрам мёртв.
Я говорю: Скрам ещё переживёт автора.
А теперь рубрика "Разрушаем мифы о Скраме":
Команда обязана выполнить все задачи, взятые в спринт. Строго говоря, команда обязана создать инкремент - полезную доработку продукта. Возможно ли сделать это, не допилив все-все-все задачи? Возможно.
Сложность и неточность оценок. Это проблема неопытных разработчиков, молодых команд, ранних этапов проекта, отсутствия документации. Со временем ситуация выравнивается и команда работает с хорошим процентом попадания в оценки. Важно понимать ещё и вот что: процесс оценки это своего рода тестирование требований и ретроспективная оценка уже проделанной работы.
Спринты - это ненужное давление. Скажем так, время - деньги. А значит заказчик не будет ждать свой продукт вечно. В Канбане нет спринтов? Окей, а сроков там тоже нет? Вообще никаких? И по мере приближения сроков ни заказчик, ни менеджер не просят апдейтов, не проводят какие-то срезы? Анбеливабл!
Фиксированные роли. Посмотрите на сами роли и задайте себе вопрос: в разработке по Канбану у вас их точно нет? У вас нет владельца продукта? Или нет разработчиков? Чаще всего достаётся Скрам мастеру, конечно. Но роли ведь можно и совмещать. И если у вас в команде никто и никогда не занимается процессами?
Более высокая прозрачность. Ну да, ну да, в Канбане команды прописывают все зависимости на год вперёд. Слышу звуки водопада.
Не в коем случае не хочу принизить Канбан и говорить, что ему нет места в мире. Любой инструмент имеет свои сильные и слабые стороны. И выбирать инструмент нужно исходя из тех вводных, которые вы получаете.
Ну а натягивать сову на глобус и сообщать, что Скрам мёртв... Это уже классика для статей на Хабре. Можно уже конкурс каждый месяц проводить)
Thomas_Hanniball Автор
24.12.2024 05:37Я говорю: Скрам ещё переживёт автора.
Я даже больше скажу. Древний язык программирования Cobol, появившийся 65 лет назад, переживёт меня и моих будущих внуков.
Newcss
24.12.2024 05:37Работали по канбану с пулом задач и ежедневным непрерывными микрорелизами. Максимальной быстрая коммуникация с заказчиком и фидбек от команды.Пришли ИБешники со своими НОВЫМИ требованиями, сроки релиза увеличились до 14 дней. Команда вынуждена была перейти на SCRUM - релизы перестали были прогнозируемыми ,а так же выросла стоимость ошибки. SCRUM хорош, когда у Вас нет внешних факторов от которых зависит хоть 1 из этапов выхода в прод.
ahdenchik
24.12.2024 05:37SCRUM хорош, когда у Вас нет внешних факторов от которых зависит хоть 1 из этапов выхода в прод.
Но ведь scrum заявляется как agile-методика для постоянно меняющихся условий заказчика?!
Frankenstine
24.12.2024 05:37Строго говоря, команда обязана создать инкремент - полезную доработку продукта. Возможно ли сделать это, не допилив все-все-все задачи? Возможно.
А можно создавать инкремент по мере запиливания фич / выпиливания багов, а не по таймеру спринта? Можно же.
Со временем ситуация выравнивается и команда работает с хорошим процентом попадания в оценки.
А без спринтов, опытная команда не может оценивать время выполнения задач? Считать сроки не в спринтах, а в неделях?
В Канбане нет спринтов? Окей, а сроков там тоже нет? Вообще никаких?
При необходимости, дедлайны в канбане добавляются элементарно. Ничто этому не мешает. Причём ведь, в отличии от спринтов, у каждой задачи может быть свой дедлайн.
thekingoftheworld
24.12.2024 05:37Что-ж, прежде всего хочу сказать, что я разделяю Вашу боль и негодование по поводу скрама. Мое отношение к нему подробнее раскрывается в моих предыдущих комментариях.
Лет 12 назад, когда скрам начал бодро шагать по умам, ходило такое утверждение: "Все, что не по скрам-гайду это не скрам". Теперь же, спустя десятилетие, доказавшее ущербность этого подхода, утверждение сменилось на: "пук-среньк, скрам это набор рекомендаций для профессионалов".
Должен сказать, что реально "настоящего" скрама я не встречал ни разу в жизни. Так же и то, что Вы описываете - это, скорее, "краткосрочное планирование", а не скрамный скрам.
Разница в следующем:
Во первых, утверждение, что "команда обязана выполнить все запланированные задачи", противоречит положениям скрама. Вот такая неожиданность! В большинстве команд, с которыми я взаимодействовал, тоже, почему-то, воспринимали конец спринта как дедлайн. Тут возникает много вопросов компетенциям менеджеров и скрам-мастеров...
Тем не менее, идея скрама(тоже не работающая) как раз в том, что мы не можем ничего заранее спланировать и оценить, но можем начать делать, собрать статистику за пол года, и предположить что в ближайший спринт мы сможем сделать примерно столько же, сколько в предыдущие.
Во вторых, задачи следующего спринта, конечно, не стоят в ожидании. Допускается взять в текущий спринт новую задачу, если:
а) цели спринта достигнуты
б) есть задача, которая по оценке влезет в оставшиеся сторипоинтыТак же, хотел бы заметить темную сторону Kanban-а, которую обычно прячут за формулировками типа "перераспределить ресурсы" или "оптимизировать процесс".
Например, если в разделе «Тестирование» накопилось слишком много задач, это может означать, что можно уволить парочку программистов, парочку аналитиков и провести сокращения далее по цепочке - тогда, в теории, выход продукции окажется прежним (сколько может переварить тестировщик), а затраты сократятся. На практике, конечно, надо учитывать пики загрузки разработки, настроения в коллективе, общий уровень комфорта и чувство безопасности работников, и много чего еще. Но простые методы приманивают "простых" людей - в этом есть некоторая опасность.Thomas_Hanniball Автор
24.12.2024 05:37Спасибо за отличное дополнение к моей статье. Не могу поставить плюсик в карму, т.к. пишет, что у вас нет статей и выше +4 карму поднять нельзя, хотя я ясно вижу, что карма у вас сейчас +5.
утверждение, что "команда обязана выполнить все запланированные задачи", противоречит положениям скрама. Вот такая неожиданность!
Scrum предполагает, что в конце спринта будет создан некий инкремент, т.к. кусочек готовой работы. А он, в свою очередь, появляется, если выполнить запланированные на спринт задачи.
Если выполняются не все задачи спринта, а только их часть, то это либо исполнители плохо поработали, либо аналитики плохо разделили большие задачи на более мелкие и попался слишком большой кусок работы, либо менеджер запихнул в спринт больше задач, чем может выполнить команда.
nv13
24.12.2024 05:37А разве менеджер запихивает задачи, а не команда их берет на основании своих оценок? А остатки времени забиваются тасками из бэклога как баблайтемы?
И как аналитик может эстимировать объём работы по задаче и подводные камни?
Frankenstine
24.12.2024 05:37Scrum предполагает, что в конце спринта будет создан некий инкремент, т.к. кусочек готовой работы.
Чем это отличается от "давайте будем выпускать по релизу примерно раз в две недели, включая в него то что готово к этому времени (попало в колонку Done)"?
Ivan22
24.12.2024 05:37зачем? Еще лучше просто раз в две недели демо делать вот и все, а релизить по готовности (Continious Deployment так сказать)
nv13
24.12.2024 05:37А что, в канбане нет планирования и оценки? Откуда берутся таски, которых не более чем сколько то на разработчика? Как увязать тест план новой фичи по 3 командам с её разработкой и деплоем? Эстимейты фиксов и фич откуда берутся, или менеджмент не требует сроков и не считает ресурсы?
Точно такие же статьи писали про аджайл и вотерфол - как трудно работать по второму и какое счастье по первому - теперь "они" начали пожирать себя изнутри, ха-ха-ха)))
Команда могла бы выбрать способ организации работы сама, но есть продакты, проджект менеджеры, релиз менеджмент, адм деление на команды и отделы, и всем нужны какие то красивые доски с перманентно улучшающимися показателями. Всё это упирается в команду из нескольких "ресурсов", которая в итого и делает всех счастливее.) И во что превращается какой то конкретный аджайл определяется именно этим менеджментом. И как срезают углы в ясно прописанном скраме или канбане -тоже, а их срезают..
kma21
24.12.2024 05:37возможно тут есть опытные управленцы проектами и они смогут мне объяснить прописные истины.
часто я вижу в описаниях канбана, что есть три группы задач - к исполнению, в работе, завершено (названия могут отличаться, промежуточные группы тоже могут быть добавлены, например на ревизии).
это выглядит так, что в таком подходе люди это некоторые роботы, которые мгновенно переключаются на следующие задачи, порой даже в другом контексте. но это не так.
как быть с срочными/авральными задачами? в канбане это выглядит так, что одна задача ставится на паузу, а другая задача берётся в работу.второй вопрос это сроки в канбане. закончили одну задачу, делаем следующую. конвейер, все дела. но как заказчику/менеджеру планировать сроки? у нас же не каждый проект дебиан с его релизным циклом "оно будет готово тогда, когда будет готово". все хотят планирования и хотя бы приблизительных сроков. и я хоть и управленец проектами, я понимаю своих коллег.
в итоге, для меня канбан выглядит как какая-то заготовка методики управления проектом. будто её написал какой-то менеджер, абсолютно не понимающий, а что там происходит "под капотом". нам нужна фича? вот мы создали задачу с описанием фичи (максимально верхнеуровневым), вот задача когда-то пошла в работу, вот мы получили фичу через какой-то срок (нам не известный).
может кто-то пояснить, как в канбане происходит планирование сроков и как отрабатываются срочные задачи?
thekingoftheworld
24.12.2024 05:37Дело тут вот в чем.
Два важнейших понятия для канбана: потоки и лимиты.
Канбан, как Вы правильно заметили, изначально изобретен именно для конвейерных задач. Т.е. вы "штампуете" на производстве какую-нибудь свистульку - у нее есть этапы, типа (фантазирую): грубая заготовка, точная заготовка, покраска, лакировка, забивание гвоздика - это и будут этапы канбана. Процесс строго определен, спроектирован и посчитан. Тут нет места "переключению" на задачи, так же как и сроков в it-шном понятии. Допустим, 10 минут на свистульку - 6 свистулек в час.
Канбан позволяет наглядно видеть следующие ситуации:
1. Допустим, поток упал до 5 свистулек в час, Вы смотрите на доску, и видите, что например, на последнем этапе скопились свистульки(задачи), оказывается, что например, не вовремя поставляют гвоздики.
2. Вы хотите увеличить производительность до 7 свистулек в час, для этого смотрите на доску и видите самые загруженные участки - это будут первые претенденты на оптимизацию, а не загруженные, наоборот, можно не трогать.Проблема же в том, что разработкой новых продуктов в новых отраслях пытаются управлять как 200-летней фабрикой. Такие вот у нас компетенции менеджеров. И соответствующие результаты.
dersoverflow
24.12.2024 05:37Допустим, поток упал до 5 свистулек в час, Вы смотрите на доску, и видите, что например, на последнем этапе скопились свистульки(задачи), оказывается, что например, не вовремя поставляют гвоздики.
О! Отличная кстати подводка для моей статьи Горизонтальное масштабирование https://ders.by/arch/scale/scale.html
Потоки и лимиты ОБЯЗАТЕЛЬНО надо видеть! Иначе даже такая простая задача, как масштабирование серверов, будет НЕПРАВИЛЬНО сделана. А "масштабирование" людей - проблема гораздо сложнее!
Thomas_Hanniball Автор
24.12.2024 05:37Потоки задач и любые задержки в их выполнении можно наглядно увидеть на Kanban доске.
Лимиты на число выполняемых задач помогают не перегрузить всю систему работой, а также помогают выявлять узкие места в производительности рабочего потока (конвейера).
Thomas_Hanniball Автор
24.12.2024 05:37Канбан - это управление потоком задач, т.е. да, это как работа конвейера. Производительность канбан - это производительность конвейера по производству ценности (полезного для бизнеса продукта).
Планирование там на самом деле очень простое. После нескольких месяцев работы по канбан становится понятно, сколько задач команда решает за одну неделю. Например, команда решает 8 задач.
Один раз в неделю руководители бизнес подразделений собираются вместе на планирование и в течение часа решают, какие задачи они хотят получить выполненными через неделю. Среди этих задач они выбирают 8 наиболее актуальных, которые команда будет выполнять всю следующую неделю. Неделя закончилась, бизнес получил 8 выполненных задач, руководители снова собрались, выбрали 8 новых задач на следующую интеракцию и т.д. В данном случае релизный цикл - это одна неделя. Задачи получили, через неделю они все выполнены.
Если кто-то заболел или в отпуске, то производительность упадёт до 6 задач в неделю, т.е. на следующую неделю можно будет предложить команде для выполнения только 6 задач.
как быть с срочными/авральными задачами? в канбане это выглядит так, что одна задача ставится на паузу, а другая задача берётся в работу.
Сотрудник всегда видит только 2 активные задачи. Больше ничего. Сотрудник выбирает одну задачу и начинает её выполнять. Если сделал, то приступает к выполнению второй задачи. Представим, что прилетает срочная задача. Сотрудник делает одну задачу, а вторая в очереди. Сотрудник заканчивает первую и у него есть выбор: начать вторую задачу, как он планировал ранее или же взять в работу новую срочную задачу. Нет никакого переключения контекста, т.к. первую задачу сотрудник выполнил, вторую он ещё не начинал, а о срочной узнал только что. В канбан приоритет всегда отдаётся тому, чтобы сначала закончить свою текущую задачу, прежде чем браться за новую задачу, т.е. приветствуется однозадачность, а не многозадачность.
dkfbm
24.12.2024 05:37в итоге, для меня канбан выглядит как какая-то заготовка методики управления проектом
В общем-то, так оно и есть. Канбан – просто один из инструментов, полная система управления проектом им не ограничивается. Но инструмент весьма полезный.
может кто-то пояснить, как в канбане происходит планирование сроков и как отрабатываются срочные задачи?
Да с целом так же, как и без него. Но доска помогает увидеть ошибки планирования, и оперативно корректировать их по мере выполнения работ.
dersoverflow
24.12.2024 05:37Scrum и Kanban, стали основными инструментами для команд
Жаль, что люди забыли еще один метод: Бригада хирурга!
Где-то лежит у меня старая бумажная книга времен СССР. Перевод еще более старой книги, естественно.
Там, на заре компьютерной эры, очень неглупые люди пытались найти эффективные формы организации труда. И предложили взглянуть на хирургов:
Операцию выполняет хирург! А бригада ему помогает.
Высококвалифицированный хирург приходит к уже подготовленному пациенту. А низкоквалифицированные помощники готовят пациента, подают инструменты, держат края раны, зашивают что могут...
В результате чего самый квалифицированный специалист работает с МАКСИМАЛЬНОЙ ЭФФЕКТИВНОСТЬЮ, не отвлекаясь на ерунду.
WindMill
24.12.2024 05:37А теперь берем макдональдс. Там любой сотрудник в ротации и может делать все что угодно. И нет никакого "великого" хирурга, который есть не что иное как огромный риск для бизнеса.
nv13
24.12.2024 05:37И манагеров так же перемешать - сегодня ты сто а завтра проджект менеджер))
dersoverflow
24.12.2024 05:37"Предложение Харлана Миллза дает свежее и творческое решение. Миллз предложил, чтобы на каждом участке работы была команда разработчиков, организованная наподобие бригады хирургов, а не мясников.
dersoverflow
24.12.2024 05:37А теперь берем макдональдс. Там любой сотрудник в ротации и может делать все что угодно
ну что тут ответишь...
хирург не пойдет мыть сортиры. а в операционную не пустят из толчка!
Grikhan
24.12.2024 05:37Это не метод, а подход. Называется предложение Харлана Миллза. Был такой математик, теоретик структурного подхода к созданию ПО и один из CTO в IBM в 70-х годах.
akod67
24.12.2024 05:37Всё справедливо, но нельзя о процессах (любых) говорить, забывая, зачем команда работает. А работает она, что бы выпускать продукт. Именно ВЫПУСКАТЬ. И в плане релизов скрам - модель более логичная, так как в идеале релиз складывается именно из спринтов. Это даёт возможность планировать релизы оунеру и стейхолдерам более понятным для них образом. При канбане планирование релизов становится более сложной задачей, особенно если, как в статье написано, разработчик дёргает то, что ему нравится из беклога, а не менеджер следит за очерёдностью выполняемых задач.
Но, такой канбан способен работать, если релизный процесс позволяет выкатывать фичи не релизами, а on demand, со всей соответсвующей инфраструктурой вокруг этого процесса, что само по себе далеко не бесплатно и просто.
Gorthauer87
24.12.2024 05:37Вообще, канбан, по ощущениям, требует большего уровня осознанности и ответственности от всех сторон. Это не всем по нраву, поэтому вот и хочется прикрываться какие-нибудь ритуалами.
И ещё, кажется, что канбан лучше работает, когда команда совсем небольшая. Сильно большие команды, при этом в принципе не жизнеспособны, а вот в средних некоторые элементы скрама неплохо помогают бороться с хаосом.
Хотя вот помню эти утомительные сессии планирования, когда берешь с потолка сторипойнты и пытаешься в спринт впихнуть работы чтобы он не лопнул. При том, что многие фичи, когда их делать начинаешь, сразу нарываются на тех долг, который не был запланирован, но который вот прямо надо сделать, иначе пара таких фичей ещё сверху и проект погибнет под грузом комбинаторного взрыва. А потом в конце спринта часть задач переезжала в следующий и приходилось резать скоуп. И начинались утомительные споры о том, что важнее а что нет.
Что для себя понял, что сроки, сторипойнты и все такое сами по себе не имеют смысла и ценности. Они нужны лишь для того, чтобы сприоритезировать что делать дальше. И тут сложность и длительность умножается на срочность задачи. В итоге где-то на этой связке между срочностью и трудоемкостью все и балансирует. А вот какие сроки в реальности будут, то это одному Ктулху известно.
Grikhan
24.12.2024 05:37Вы просто не умеете их готовить. Такой скрам, который вы описали не то, что не мёртв, он никогда и не рождался как методология гибкой разработки.
Оценка сроков нужна для оценки корректного разбиения задачи на подзадачи, которые выполняются за спринт - это не угадайка. Срок задачи в один спринт некуда ускорять и некем. Если задача большая, то ее нужно разбить на более мелкие - в этом основной смысл. Если у вас за спринт у каждого несколько задач - укорачивайте спринты.
Скрам-мастер - это роль, а не специально обученный человек. Эту роль хорошо передавать между членами команды.
Если на спринт вам "дают" задачи, то у вас не знакомы с Agile-манифестом и это у вас что угодно, только не скрам. Задачи разбирают те, кому они интересны.
Ну и сравнение гибкой методологии разработки с доской задач - это, похоже, какая-то шутка.
dmitriy_minaev
24.12.2024 05:37Как по мне, дело не в методиках как таковых, а в деталях их применения. Скрам уместно применять, если стоит цель хоть как-нибудь (даже костылями) закрыть задачу и потом улучшать то, что натворили (по сути, путь mvp). В таком случае, конечно, нет смысла спрашивать исполнителя за качество и пытаться выжать из него все соки. Либо, как второй вариант, накидывают теоретический максимум задач, а решается только, сколько успели, без претензий к исполнителям. Такое тоже не всем подходит, но если нет критически важных взаимозависимых задач - работает. Оба варианта не работают, если в это влезает менеджер, который пытается оценить качество и количество закрытых задач, как раз потому что скрам не про это. Из описанного понятно, что скрам - это про работу маленькой команды или стратапа.
dersoverflow
24.12.2024 05:37Как по мне, дело не в методиках как таковых, а в деталях их применения
Ох, ребята...
Уже 150 лет на каждом серьезном Экономическом Форуме бушуют ЖАРКИЕ дискуссии на тему "Что же на самом деле сказал Маркс в своем Капитале"!
Скрам такое же фуфло.
stroitskiy
24.12.2024 05:37Вы просто смотрите с колокольни разработчика, и как для молотка все в мире гвозди, то и для девелопера все задачи это про немедленное и жесточайшее написание кода. Отступление законченно.
Я рискну предположить что проблемы со скрамом и канбаном проистекают из проблем с планированием. Если у вас канбан, то все задачи должны быть одинакового размера, иначе ритмичности работы вы не добьетесь. И вот тут и прячеться дьявол, ибо это довольно сложная сама по себе задача, грамотно разбить сложный таск на допустим 6 «стандартных» которые можно сделать за день и протестировать за день.
В скраме задачи могут быть любого размера, но и там проблема с эстимейтвми.
Грамотное среднесрочное планирование и многократное разбиение тасков на более мелкие отнимает много времени и сил, и потому очень непопулярно у команд - ну все и так же ясно, погнали!
Thomas_Hanniball Автор
24.12.2024 05:37Полностью согласен с вами, что задачи должны быть одинакового размера, иначе ритмичности работы добиться будет сложно. Спасибо за отличное дополнение.
Frankenstine
24.12.2024 05:37Поясните, зачем нужна некая мифическая ритмичность? 80% задач имеют примерно одинаковую длительность, 20% же требуют заметно большего или наоборот меньшего времени. Тем не менее их всех нужно делать согласно приоритетности. Если в приоритете сейчас сложная длительная задача, её всё равно будем делать, потому что она должна быть готова, прежде чем можно будет заниматься чем-то другим. И наоборот, если есть две-три срочные задачи не требующие много времени, их делаем друг за дружкой, но при чём тут какой-то ритм?
yrub
24.12.2024 05:37автор слишком плохо замаскировал свое предвзятое отношение ;) все работают по как бы по скраму и используют для этого канбан доску, даже интересно узнать у кого и почему не так. Просто потому, что бизнес платит деньги и ему нужен результат, а не ваше "когда сделаю хз, just leave me alone". Для скрама действует простая житейская логика: надо ставить людям маленькие дедланы, потому что попасть в один большой дедлайн невозможно (ну только если вы сильно не переэстимируете). Такова человеческая натура. Чтобы люди не выгорали надо ставить неделю на тестирование и доделки между двумя-тремя неделями разработки. Вот и вся наука.
dersoverflow
24.12.2024 05:37не ваше "когда сделаю хз, just leave me alone"
как ни смешно, но это САМЫЙ ЭФФЕКТИВНЫЙ метод! Инженер сел за Задачу и полностью на ней сосредоточен. а любые сторонние прерывания лишь удлиняют сроки.
да, есть вариант, когда надо вмешаться чтобы прекратить выполнение (если задача утратила бизнес смысл). но вмешаться чтобы потом продолжить - это потеря Времени!
dersoverflow
24.12.2024 05:37Называется предложение Харлана Миллза. Был такой математик
из статьи:
При некотором размышлении ясно, что эта идея приведет к желаемому, если ее удастся осуществить. Лишь несколько голов занято проектированием и разработкой, и в то же время много работников находится на подхвате. Будет ли такая организация работать? Кто играет роль анестезиологов и операционных сестер в группе программистов, а как осуществляется разделение труда?
а знает ли Уважаемая Общественность для чего нужен анестезиолог?
анестезиолог нужен не для того, чтобы пациент уснул. анестезиолог нужен, чтобы пациент проснулся!
ЗЫ а усыпыпить могут даже в макдональдсе.
kwalag
24.12.2024 05:37Начнем.
Пункт 1.
На протяжении спринта команда обязана выполнить все запланированные задачи, что может создавать давление на исполнителей и вынуждать их принимать не самые оптимальные решения, а также склонять их к «срезанию углов», чтобы успеть всё выполнить к ранее обозначенным срокам.
Вы хотите сказать, что, поскольку в Канбане нет формальных ограничений по времени выполнения задач, в условиях использования этого метода исполнители будут зачастую иметь возможность принимать оптимальные решения? Или вы хотите сказать, что в Канбане вообще нет сроков выполнения задач? Уточните, пожалуйста, что вы имеете в виду.
Отвечу наперед:
Ограничение по времени выполнения задачи напрямую не относится ни к Скраму, ни к Канбану. Это базовые вопросы проектного управления, которые стоят над методами и фреймворками. В Скраме идея спринтов (если упрощенно) – это вовсе не «жесткий коридор», а средство снизить неопределенность и структурировать работу, аккуратно спланировать ближайший блок работы и вместе обсудить, как именно мы это будем делать. Если необходимость «срезать углы» и происходит в реальной практике, то это, скорее, проблема конкретной организации или менеджмента, а не теоретическая установка Скрама.
В Канбане задачи не делают «вечно» — есть понятие срока поставки (delivery date), которое может оговариваться со стейкхолдерами. Если же вы имеете в виду, что формат спринтов поощряет жёсткие сроки, тогда стоит уточнить, что это не установка самого Скрама, а возможный перекос в практике конкретных команд.
Пример: Есть компании, которые успешно совмещают Скрам и точечные сроки, не провоцируя команду на «героизм» и «уголосрезание». А в Канбане, как правило, тоже есть дедлайны, когда это оговаривается со стейкхолдерами. Спринты в Скраме – просто один из форматов, а не жесткое правило «успеть любой ценой».
Пункт 2.
Никто и никогда не знает реальных сроков выполнения той или иной задачи, поэтому команды впустую тратят своё время, чтобы примерно оценить сроки выполнения. Было бы лучше, если бы это время было потрачено на реальную работу, а не попытки угадать сроки выполнения задач.
Здесь вы фактически говорите: «Не нужно ничего планировать, просто работайте». Но полный отказ от планирования противоречит и классическому треугольнику «Scope—Time—Budget», и любым разумным подходам к управлению проектами. Скрам, кстати, не настаивает на «угадывании» точных сроков: достаточно грубых оценок (story points, t-shirt sizes и т. д.), чтобы понимать примерный объём работы.
Добавьте уточнение, если речь идёт о слишком детальных или долгосрочных прогнозах, которые действительно могут быть излишне трудозатратны. Но говорить, что «вообще не надо оценивать» — звучит радикально и не отражает гибкие практики, используемые в реальных командах.
Пункт 3.
Если во время планирования спринта исполнитель сообщает о коротких сроках выполнения, то на спринт ему просто дают больше задач, чтобы он не скучал без работы. Если же исполнитель называет очень большие сроки, то ему говорят, что это очень долго и что сроки нужно уменьшить. И вообще, у нас тут очень много задач в очереди, поэтому работать надо быстрее и эффективнее.
Примерные сроки выполнения, названные наугад во время планирования, становятся вдруг обязательствами во время спринта, что ещё сильнее демотивирует команду и ведёт к постоянным спорам между исполнителями и Product Owner’ом по поводу сроков и количества задач для спринта.
Подобная ситуация говорит не о Скраме как таковом, а о неправильной реализации: команда должна сама определять, сколько задач способна взять на спринт, и Scrum Guide это чётко фиксирует. Если в вашей практике происходит давление на оценки (когда «меньше времени» = «возьмём больше задач», а «больше времени» = «не оправдывает ожиданий») — значит, налицо организационная проблема, а не дефект Скрама.
Пункт 4.
Третий момент. Scrum – это работа спринтами, т.е. интенсивная работа над задачами в течение короткого промежутка времени. Любой спринт, например, в спорте, предполагает длительную фазу отдыха после окончания спринта. Но в Scrum ничего подобного нет, поэтому команды очень быстро выгорают из-за постоянных интенсивных нагрузок. Спринты хороши лишь в краткосрочной перспективе, например, чтобы закончить работу, когда до дедлайна осталось всего пару недель или месяц. Scrum же превратил спринты в долгосрочный марафон на выживание, в котором сжигаются целые команды.
Kanban не использует спринты, что позволяет команде работать в режиме непрерывного потока. Задачи выполняются по мере их поступления, и нет необходимости ограничиваться конкретными временными рамками. Команда может адаптироваться к изменениям более гибко и быстро, без необходимости подгонять работу под спринт.
Вы пишете "В Скраме нет отдыха - это плохо". А затем вы пишете "Канбан лучше, потому что позволяет работать в режиме непрерывного потока". Слово непрерывно, вроде бы, обозначает без перерыва.
Как Канбан или другие методы / фреймворки / методологии предусматривают время на отдых по вашему? Конечно, никак. И то, сколько команда будет отдыхать, каким образом, и от чего это зависит - не зависит от метода / фреймворка / методологии.
Ни один фреймворк (Scrum, Kanban и др.) напрямую не регламентирует перерывы или отдых. То, как команда берёт отпуск или распределяет нагрузку, — это вопрос менеджмента и организационных процессов.
Если говорить про «выгорание» из-за спринтов: в теории Скрам не подразумевает постоянные «забеги на максимальной скорости». Это обычные короткие итерации (1–4 недели), и нет запрета договориться о паузах. Точно так же в Канбане можно столкнуться с выгоранием, если поток задач нескончаемый.
Пункт 5.
В статье вы упоминаете WIP-лимиты как отличительную черту Канбана. Но WIP-лимиты (ограничение количества задач в работе) можно применять и в Скраме, как и в любой другой методологии, если это помогает команде не «распыляться» и грамотно контролировать «незавершёнку». Канбан-система сделала упор на этом инструменте, но это вовсе не значит, что он «эксклюзивный» и недоступен тем, кто практикует Скрам.
Пункт 6.
2. Гибкость и отсутствие фиксированных ролей.
Одним из главных отличий Kanban от Scrum является отсутствие фиксированных ролей. В Scrum четко определены роли: Scrum Master, Product Owner, и команда разработчиков. Эти роли накладывают определенные обязательства и требуют от участников команды строго придерживаться своих задач и обязанностей.
Scrum Master, Product Owner, Agile Coach, фасилитатор – кто все эти люди? Почему Scrum не может работать без них?
Сначала вы верно определяете ограниченный набор ролей в Скраме, а следующим абзацем перечисляете роли, совершенно не относящиеся к Скраму. Зачем? Для чего? Какую пользу несет этот комментарий?
В Канбане есть Менеджер, естественно. Который также управляет потоком, договаривается, проводит общие встречи и координирует поток в рамках системы.
Kanban, напротив, не ограничивает команду жесткими ролями. Команда сама решает, как распределять задачи, и кто за что отвечает. Это предоставляет больше гибкости, так как члены команды могут переключаться между задачами в зависимости от текущих потребностей проекта.
Кстати, в классическом Скраме, Команда тоже сама решает, как распределить задачи, и кто за что будет отвечать.
Пункт 7.
3. Более высокая прозрачность и управление потоком.
Kanban делает акцент на визуализации рабочего процесса с помощью доски Kanban. Задачи на доске проходят через различные этапы: от «Backlog» и «To do» до «Done», что даёт полное представление о текущем состоянии всех задач в проекте. Такой подход позволяет всем членам команды и заинтересованным сторонам быстро оценить, на какой стадии находятся работы и какие задачи требуют дополнительного внимания.
В Scrum каждая команда планирует задачи на конкретный спринт, но нет такой же глубокой визуализации потока задач, как в Kanban. Scrum ориентирован на завершение определенного объёма работы в ограниченное время, что может затруднить наблюдение за прогрессом работы в реальном времени.
Как применение визуализации противоречит Скрам? Почему вы считаете что в скраме не применяют визуализацию рабочего процесса? Вы пишете что задачи проходят через различные этапы. И потом выделяете "такой подход позволяет..". А в скраме этого использовать нельзя, чтоли? Что такое глубокая визуализация?
На практике большинство Скрам-команд тоже используют доску, очень похожую на Канбан-доску: «To Do / In Progress / Done». Визуализация — общий подход к гибкому управлению. Говорить, что Scrum-команды не визуализируют поток, неверно.
Пункт 8.
4. Процесс непрерывного улучшения.
Хотя Scrum включает регулярные ретроспективы для оценки и улучшения процесса, Kanban позволяет внедрять изменения гораздо более гибко и постепенно. В Kanban можно внедрять улучшения по мере выявления проблем, в отличие от Scrum, где улучшения часто происходят в рамках определенных спринтов.
Абсолютно не раскрыты способы и методики внедрения изменений "Более гибко и постепенно". В чем проблема внедрить изменение в течение 2-х недель? Приведите пример изменений, которые Канбан позволит внедрить быстрее чем Скрам и это сильно поможет бизнесу в цифрах? И как это измерить?
Пункт 9.
5. Более эффективное управление при изменяющихся приоритетах.
В проектах, где приоритеты могут изменяться часто, Kanban может быть более подходящим выбором, чем Scrum. В Scrum изменения приоритетов между спринтами могут привести к нарушению планов и перераспределению задач, что требует времени и усилий. В Kanban изменения могут быть внесены мгновенно — задачи могут быть переоценены и перемещены по доске без необходимости ждать завершения спринта.
Это особенно полезно в динамичных средах, где важно быстро реагировать на изменения в бизнесе или на рынке.
Вы думаете, что если планы бизнеса поменялись в течение спринта, вся команда или команды полностью проигнорируют эту информацию и будут работать по изначальному плану? Что за бред? Это не так работает. Корректировать бэклог спринта можно при необходимости, естественно.
Пункт 10.
6. Нет необходимости в сложном планировании.
В Scrum планирование является важной частью работы. Команды должны заранее определить задачи на весь спринт и утвердить их на планировании. Это может стать затратным и временами излишне сложным процессом, особенно если проект динамичен и часто меняются требования.
Большие статьи, как правило, мало кто дочитывает до конца, поэтому если тебе это удалось, то пусть удача и хорошее настроение не покидают тебя весь следующий год.
Kanban, в свою очередь, минимизирует необходимость в детализированном долгосрочном планировании. Задачи поступают и выполняются по мере необходимости, а управление происходит через ограничение работы в процессе и контроль за её потоками. Это упрощает планирование и позволяет команде сфокусироваться на текущих задачах, а не на долгосрочных планах.
Для вас 2 недели это долгосрочное планирование? Что вообще такое долгосрочное планирование в контексте вашего 6 пункта? Скрам-итерации, которые длятся обычно 1–4 недели, трудно назвать «долгосрочным горизонтальным планированием». Даже если требования меняются каждую неделю, концепция коротких циклов позволяет подстраиваться.
Не существует разработки без планирования. И там и там есть лицо или группа лиц, которые должны сделать так, чтобы было понятно к чему идти и из чего будет примерно состоять работа. Планирование - неотъемлемая часть разработки.
--------------------------------------
Пункт 11. Итоги.
Важно понимать, что Скрам в том виде, в каком он описан в скрам-гайде полностью от начала и до конца - используют очень маленькое количество компаний / команд. Учитывая это и то, что скрам это фреймворк - вы вольны брать принципы / практики и применять их на свои процессы. Тоже самое, кстати, что и с Канбан-методом.
Один из самых важных моментов что вы упускаете - Скрам не противоречит Канбану. Это взаимодополняемые инструменты. Можно использовать принципы Канбан в Скраме.
Ваш текст, к сожалению, иногда смешивает критические замечания об отдельных «косячных» реализациях Скрама с самим фреймворком и принципами. При этом вы не раскрываете до конца все аспекты Канбана, которые делают его действительно мощным инструментом.
Вы попытались написать экспертную статью о преимуществах Канбана, но не упомянули многих его ключевых возможностей и инструментов для управления проектами — например, каденций, метрик (Lead Time, Cycle Time, CFD) или Kanban Maturity Model (KMM). Если ваша цель — показать глубину понимания Канбана, стоит раскрыть эти детали.
Просто процитирую Василия Савунова:
"Прежде всего, Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей.
..
Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов."Полезный смысл статьи не понятен. В основном противоречивое чуть ли не в каждом заголовке сравнение фреймворка и метода с абсолютно неполными знаниями. Вывод о «превосходстве Канбана над Скрамом» в вашей статье выглядит спорным. Если хочется подчеркнуть, что вы предпочитаете Канбан, то лучше было бы дать детальное описание его преимуществ, подкреплённое метриками, каденциями и примерами реальной практики.
xxxDef
24.12.2024 05:37Все, абсолютно все методики управления, начиная от водопада и заканчивая скрамом, стоят на одном основании - на оценке задач.
Но ведь именно это основание по сути своей миф. Давайте уже наконец признаем - любая оценка - это просто случайное число, которая высасывается из пальца. Да, какие то тривиальные вещи можно оценить, но много ли тривиальных и похожих вещей приходится делать разработчику? Уровень неопределенности в разработке просто запредельный.
И вот на таком основании из тумана в головах разработчиков держатся вообше все методики, даже те которые призваны нивелировать эту проблему.
Можно до хрипоты спорить про то что лучше, но в итоге все выходит боком, просто потому что оценка задачи - это миф. Любая методика основанная на этом мифе сама становится мифом.
TimurTukaev
Всегда готов поставить лайк статье, которая набрасывает на скрам и хорошо отзывается о канбан-методе:)
Thomas_Hanniball Автор
Спасибо! :)