На протяжении спринта команда обязана выполнить все запланированные задачи, что может создавать давление на исполнителей и вынуждать их принимать не самые оптимальные решения, а также склонять их к «срезанию углов», чтобы успеть всё выполнить к ранее обозначенным срокам.
Вы хотите сказать, что, поскольку в Канбане нет формальных ограничений по времени выполнения задач, в условиях использования этого метода исполнители будут зачастую иметь возможность принимать оптимальные решения? Или вы хотите сказать, что в Канбане вообще нет сроков выполнения задач? Уточните, пожалуйста, что вы имеете в виду.
Отвечу наперед:
Ограничение по времени выполнения задачи напрямую не относится ни к Скраму, ни к Канбану. Это базовые вопросы проектного управления, которые стоят над методами и фреймворками. В Скраме идея спринтов (если упрощенно) – это вовсе не «жесткий коридор», а средство снизить неопределенность и структурировать работу, аккуратно спланировать ближайший блок работы и вместе обсудить, как именно мы это будем делать. Если необходимость «срезать углы» и происходит в реальной практике, то это, скорее, проблема конкретной организации или менеджмента, а не теоретическая установка Скрама.
В Канбане задачи не делают «вечно» — есть понятие срока поставки (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 — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов."
Полезный смысл статьи не понятен. В основном противоречивое чуть ли не в каждом заголовке сравнение фреймворка и метода с абсолютно неполными знаниями. Вывод о «превосходстве Канбана над Скрамом» в вашей статье выглядит спорным. Если хочется подчеркнуть, что вы предпочитаете Канбан, то лучше было бы дать детальное описание его преимуществ, подкреплённое метриками, каденциями и примерами реальной практики.
Начнем.
Пункт 1.
Вы хотите сказать, что, поскольку в Канбане нет формальных ограничений по времени выполнения задач, в условиях использования этого метода исполнители будут зачастую иметь возможность принимать оптимальные решения? Или вы хотите сказать, что в Канбане вообще нет сроков выполнения задач? Уточните, пожалуйста, что вы имеете в виду.
Отвечу наперед:
Ограничение по времени выполнения задачи напрямую не относится ни к Скраму, ни к Канбану. Это базовые вопросы проектного управления, которые стоят над методами и фреймворками. В Скраме идея спринтов (если упрощенно) – это вовсе не «жесткий коридор», а средство снизить неопределенность и структурировать работу, аккуратно спланировать ближайший блок работы и вместе обсудить, как именно мы это будем делать. Если необходимость «срезать углы» и происходит в реальной практике, то это, скорее, проблема конкретной организации или менеджмента, а не теоретическая установка Скрама.
В Канбане задачи не делают «вечно» — есть понятие срока поставки (delivery date), которое может оговариваться со стейкхолдерами. Если же вы имеете в виду, что формат спринтов поощряет жёсткие сроки, тогда стоит уточнить, что это не установка самого Скрама, а возможный перекос в практике конкретных команд.
Пример: Есть компании, которые успешно совмещают Скрам и точечные сроки, не провоцируя команду на «героизм» и «уголосрезание». А в Канбане, как правило, тоже есть дедлайны, когда это оговаривается со стейкхолдерами. Спринты в Скраме – просто один из форматов, а не жесткое правило «успеть любой ценой».
Пункт 2.
Здесь вы фактически говорите: «Не нужно ничего планировать, просто работайте». Но полный отказ от планирования противоречит и классическому треугольнику «Scope—Time—Budget», и любым разумным подходам к управлению проектами. Скрам, кстати, не настаивает на «угадывании» точных сроков: достаточно грубых оценок (story points, t-shirt sizes и т. д.), чтобы понимать примерный объём работы.
Добавьте уточнение, если речь идёт о слишком детальных или долгосрочных прогнозах, которые действительно могут быть излишне трудозатратны. Но говорить, что «вообще не надо оценивать» — звучит радикально и не отражает гибкие практики, используемые в реальных командах.
Пункт 3.
Подобная ситуация говорит не о Скраме как таковом, а о неправильной реализации: команда должна сама определять, сколько задач способна взять на спринт, и Scrum Guide это чётко фиксирует. Если в вашей практике происходит давление на оценки (когда «меньше времени» = «возьмём больше задач», а «больше времени» = «не оправдывает ожиданий») — значит, налицо организационная проблема, а не дефект Скрама.
Пункт 4.
Вы пишете "В Скраме нет отдыха - это плохо". А затем вы пишете "Канбан лучше, потому что позволяет работать в режиме непрерывного потока". Слово непрерывно, вроде бы, обозначает без перерыва.
Как Канбан или другие методы / фреймворки / методологии предусматривают время на отдых по вашему? Конечно, никак. И то, сколько команда будет отдыхать, каким образом, и от чего это зависит - не зависит от метода / фреймворка / методологии.
Ни один фреймворк (Scrum, Kanban и др.) напрямую не регламентирует перерывы или отдых. То, как команда берёт отпуск или распределяет нагрузку, — это вопрос менеджмента и организационных процессов.
Если говорить про «выгорание» из-за спринтов: в теории Скрам не подразумевает постоянные «забеги на максимальной скорости». Это обычные короткие итерации (1–4 недели), и нет запрета договориться о паузах. Точно так же в Канбане можно столкнуться с выгоранием, если поток задач нескончаемый.
Пункт 5.
В статье вы упоминаете WIP-лимиты как отличительную черту Канбана. Но WIP-лимиты (ограничение количества задач в работе) можно применять и в Скраме, как и в любой другой методологии, если это помогает команде не «распыляться» и грамотно контролировать «незавершёнку». Канбан-система сделала упор на этом инструменте, но это вовсе не значит, что он «эксклюзивный» и недоступен тем, кто практикует Скрам.
Пункт 6.
Сначала вы верно определяете ограниченный набор ролей в Скраме, а следующим абзацем перечисляете роли, совершенно не относящиеся к Скраму. Зачем? Для чего? Какую пользу несет этот комментарий?
В Канбане есть Менеджер, естественно. Который также управляет потоком, договаривается, проводит общие встречи и координирует поток в рамках системы.
Кстати, в классическом Скраме, Команда тоже сама решает, как распределить задачи, и кто за что будет отвечать.
Пункт 7.
Как применение визуализации противоречит Скрам? Почему вы считаете что в скраме не применяют визуализацию рабочего процесса? Вы пишете что задачи проходят через различные этапы. И потом выделяете "такой подход позволяет..". А в скраме этого использовать нельзя, чтоли? Что такое глубокая визуализация?
На практике большинство Скрам-команд тоже используют доску, очень похожую на Канбан-доску: «To Do / In Progress / Done». Визуализация — общий подход к гибкому управлению. Говорить, что Scrum-команды не визуализируют поток, неверно.
Пункт 8.
Абсолютно не раскрыты способы и методики внедрения изменений "Более гибко и постепенно". В чем проблема внедрить изменение в течение 2-х недель? Приведите пример изменений, которые Канбан позволит внедрить быстрее чем Скрам и это сильно поможет бизнесу в цифрах? И как это измерить?
Пункт 9.
Вы думаете, что если планы бизнеса поменялись в течение спринта, вся команда или команды полностью проигнорируют эту информацию и будут работать по изначальному плану? Что за бред? Это не так работает. Корректировать бэклог спринта можно при необходимости, естественно.
Пункт 10.
Для вас 2 недели это долгосрочное планирование? Что вообще такое долгосрочное планирование в контексте вашего 6 пункта? Скрам-итерации, которые длятся обычно 1–4 недели, трудно назвать «долгосрочным горизонтальным планированием». Даже если требования меняются каждую неделю, концепция коротких циклов позволяет подстраиваться.
Не существует разработки без планирования. И там и там есть лицо или группа лиц, которые должны сделать так, чтобы было понятно к чему идти и из чего будет примерно состоять работа. Планирование - неотъемлемая часть разработки.
--------------------------------------
Пункт 11. Итоги.
Важно понимать, что Скрам в том виде, в каком он описан в скрам-гайде полностью от начала и до конца - используют очень маленькое количество компаний / команд. Учитывая это и то, что скрам это фреймворк - вы вольны брать принципы / практики и применять их на свои процессы. Тоже самое, кстати, что и с Канбан-методом.
Один из самых важных моментов что вы упускаете - Скрам не противоречит Канбану. Это взаимодополняемые инструменты. Можно использовать принципы Канбан в Скраме.
Ваш текст, к сожалению, иногда смешивает критические замечания об отдельных «косячных» реализациях Скрама с самим фреймворком и принципами. При этом вы не раскрываете до конца все аспекты Канбана, которые делают его действительно мощным инструментом.
Вы попытались написать экспертную статью о преимуществах Канбана, но не упомянули многих его ключевых возможностей и инструментов для управления проектами — например, каденций, метрик (Lead Time, Cycle Time, CFD) или Kanban Maturity Model (KMM). Если ваша цель — показать глубину понимания Канбана, стоит раскрыть эти детали.
Просто процитирую Василия Савунова:
"Прежде всего, Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей.
..
Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов."
Полезный смысл статьи не понятен. В основном противоречивое чуть ли не в каждом заголовке сравнение фреймворка и метода с абсолютно неполными знаниями. Вывод о «превосходстве Канбана над Скрамом» в вашей статье выглядит спорным. Если хочется подчеркнуть, что вы предпочитаете Канбан, то лучше было бы дать детальное описание его преимуществ, подкреплённое метриками, каденциями и примерами реальной практики.
Возможно в госухе когда-то так перевели и пошло. Там любят переводить понятия на русский и по-своему называть процессы.