Scrum is dead или почему Kanban намного эффективнее Scrum

Введение.

Методы управления проектами в сфере разработки программного обеспечения, такие как 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) помогает решить сразу несколько ключевых задач:

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

2. Улучшение потока работы: Ограничения WIP позволяют команде сосредоточиться на завершении текущих задач, прежде чем они смогут взять в работу новые задачи. Команда начинает понимать, на чём стоит сосредоточиться и что необходимо завершить перед тем, как переходить к новым задачам.

3. Быстрое выявление узких мест: Когда на каком-то этапе появляется слишком много задач, это может быть сигналом о том, что на этом участке существует узкое место. Например, если в разделе «Тестирование» накопилось слишком много задач, это может означать, что тестировщики перегружены, и необходимо перераспределить ресурсы или оптимизировать процесс тестирования. Ограничение WIP помогает оперативно выявить и устранить такие проблемы.

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

5. Поддержание фокуса и уменьшение многозадачности: Ограничения 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, в свою очередь, минимизирует необходимость в детализированном долгосрочном планировании. Задачи поступают и выполняются по мере необходимости, а управление происходит через ограничение работы в процессе и контроль за её потоками. Это упрощает планирование и позволяет команде сфокусироваться на текущих задачах, а не на долгосрочных планах.