Почему вы выбрали фреймворк Scrum, а не метод управления проектами Kanban? Не можете ответить? Значит — лично вы Scrum и не выбирали. Кто-то сделал это за вас.
Даже в тех редких случаях, когда люди способны ответить на вышеприведённый вопрос, их мотивы раскрывают глубокие заблуждения относительно Kanban. Выражаются эти заблуждения в упоминании следующих причин выбора Scrum:
Scrum повышает скорость реакции команд на обратную связь.
Scrum облегчает оценивание задач.
Scrum позволяет наглядно представлять задачи.
Scrum сокращает ненужную трату времени.
Scrum способствует регулярному проведению совещаний.
Всё это применимо не только к Scrum, но и к Kanban. Разница между ними заключается лишь в двух моментах. Во‑первых — Scrum полностью игнорирует нюансы вашего рабочего процесса. Во‑вторых — он точно сообщает вам о том, что и как нужно делать. В каком‑то смысле, Scrum — это страховка для менеджеров, вроде тренировочных колёс на велосипеде: фреймворк не даёт им разбить коленки, но при этом и не позволяет их командам работать с той быстротой и динамичностью, на которые они способны.
А Kanban, с другой стороны, лишь устанавливает принципы. Как только вы поймёте эти принципы — вы сможете адаптировать их к вашей конкретной ситуации и получить гораздо лучшие результаты. Менеджерам, которые овладели этими принципами, не нужны «тренировочные колёса». На чём бы они ни ездили — хоть на велосипеде, хоть на мотоцикле, им нужно пройти лишь несколько кругов для того чтобы понять особенности трассы, оптимизировать свою стратегию и обойти соперников.
И, обратите внимание, я не говорю о том, что Scrum — это нерабочая тема. Я говорю как раз об обратном. Scrum — это рабочий фреймворк, но работает он по тем же причинам, что и Kanban. Разница между ними заключается в том, что Scrum медленнее и «нормативнее», чем Kanban, и в результате хуже поддаётся адаптации под конкретные проекты (или является менее «agile», менее «гибким», чем Kanban, если угодно).
Применение Scrum приносит ещё больше вреда в том случае, когда менеджеры создают собственные разновидности этого фреймворка, пытаясь впихнуть нормативные руководства туда, куда они не подходят. Когда такое происходит, менеджеры превращают неэффективный, но глубоко продуманный фреймворк, в неэффективный и неполноценный процесс. Происходит так из‑за того, что они игнорируют механизмы Kanban, благодаря которым и работает «правильный Scrum».
В этом материале я порассуждаю о причинах, по которым я выбираю Kanban вместо Scrum, и расскажу о том, как именно применение Scrum ухудшает эффективность команд.
Кроме того, я объясню ещё и то, почему каждое из вышеперечисленных достоинств внедрения Scrum характерно и для Kanban. Расскажу я и о том, как применение Kanban усиливает эти достоинства.
Как Kanban усиливает достоинства Scrum
Scrum повышает скорость реакции команд на обратную связь
Применение Scrum повышает «отзывчивость» команд по следующей причине: если длительность спринтов составляет две недели, то чтобы отреагировать на обратную связь нужно не больше двух недель.
При этом команды, использующие Kanban, могут реагировать на обратную связь даже ещё быстрее. Дело в том, что им не нужно ждать до совещания по планированию следующего спринта для того чтобы принять решение о том, какими будут их следующие шаги, и чтобы эти шаги реализовать.
Более того — так как Kanban ориентирован на отдельные задачи, а не на пакеты задач, укладывающиеся в длительность спринта, его применение сдвигает ответственность на границы команд. То есть — сами программисты несут ответственность за получение тех фрагментов информации, которые нужны им для того чтобы идти вперёд.
Когда это происходит, то, вместо коллективного проектирования возможностей продукта на больших совещаниях, что требует массы обсуждений, решения принимаются в рамках команд. Это облегчает процесс принятия решений.
И ещё: то, что принятием решений занимается меньшее количество людей, ведёт к меньшему количеству предположений. А наличие меньшего количества предположений, в свою очередь, ведёт к тому, что небольшие фрагменты приложений быстрее доходят до состояния готовности. Это позволяет командам раньше отказываться от неправильных путей развития проекта.
Scrum облегчает оценку задач
Scrum сокращает горизонты планирования, ограничивая длительность пакетов задач двухнедельными спринтами. Двухнедельные пакеты — это лучше, чем пакеты задач, рассчитанные на год. Дело в том, что оценивание меньшего количества задач означает меньшую вероятность возникновения ошибок. Более того — ошибки оказываются менее критичными, так как скорректировать курс развития проекта можно в достаточно короткие сроки.
Но при этом, так как Scrum — это система, которая основана на назначении задач командам, при её применении необходимо использовать какую‑то форму оценивания трудоёмкости выполнения задач. Это позволяет узнать о размерах пакета задач, который нужно передать в работу.
Необходимость оценивания задач ведёт к непродуктивным и ненужным оценочным совещаниям. Я называю их «непродуктивными» из‑за того, что они заставляют разработчиков тратить время на разговоры о том, сколько стори‑пойнтов, два или три, нужно чему‑то назначить, вместо того, чтобы работать и писать код. А «ненужными» они тут названы по причине того, что в системе, перегруженной работой, оценки не имеют никакого значения.
Но это не значит, что трудоёмкость задач невозможно оценить точно. Точные оценки можно дать тогда, когда точно известно о том, какой код нужно написать для решения той или иной задачи. Но в таком случае, вероятно, лучше будет написать этот код, а не размышлять о нём, занимаясь бесполезным планированием.
Kanban, с другой стороны — это система, основанная на выборе задач командами. При применении этой системы исполнитель берёт новые задачи в тот момент, когда он к этому готов.
Получается, что вместо необходимости оценивания задач, нужно лишь обеспечить поступление задач в систему с той же скоростью, с которой они из неё выходят. Когда всё происходит именно так — достаточно не допустить простоя системы, что гораздо легче, чем точное оценивание трудоёмкости задач.
Scrum позволяет наглядно представлять задачи
Эта причина применения Scrum видится мне крайне ироничной. Это так из‑за того, что в Scrum для визуализации задач используется Kanban‑доска.
Не думаю, что этот вопрос нуждается в дальнейших пояснениях. По‑моему, достаточно сильным аргументом в пользу Kanban тут служит сам факт существования Kanban‑досок, созданных специально для Kanban. Но при этом стоит обратить внимание на то, что наглядное представление задач, само по себе, ни к чему не приводит, если только визуализацию задач не используют для выполнения неких действий.
В Kanban доска используется для визуализации того, какие задачи застревают в конкретной колонке на слишком длительное время, и для анализа того, почему это происходит. Далее — либо принимают решение о том, что именно из проекта нужно убрать, либо предпринимают дальнейшие действия для устранения узкого места проекта.
В Scrum нет каких‑то особых структур, которые стимулируют подобное поведение, так как Scrum — это непрозрачный фреймворк. Он скрывает от тех, кто им пользуется, тот факт, что чем больше элементов имеется на доске — тем более длительным будет время среднего цикла. Он, кроме того, не предлагает рекомендаций по поводу того, что делать с такими вот «стареющими» элементами.
Scrum сокращает ненужную трату времени
Представьте, что вы — владелец автомобильного завода. На заводе имеется три производственных этапа. Сначала производятся шины, потом их прикрепляют к шасси автомобилей, а на финальном этапе производства собирают детали кузова.
Если шины у вас производятся быстрее, чем их можно прикреплять к шасси — то всё закончится тем, что цеха вашего завода будут завалены бесполезными резиновыми изделиями. И наоборот — если не получается производить шины достаточно быстро — линия производства шасси будет простаивать. Та же проблема возникнет в том случае, если шасси производятся быстрее, чем можно отправить их на следующий этап, где собирают и устанавливают детали кузова. Возможна и обратная ситуация.
При применении Scrum нужно обеспечить слаженную работу каждой «линии» производства на протяжении всего спринта. Это так из‑за того, что в работу единовременно отправляют двухнедельные пакеты задач. Если слаженную работу обеспечить не удастся — то получится как в нашем примере, когда шины создаются быстрее, чем шасси, к которым они крепятся, или наоборот, окажется, что производство шин не обеспечивает потребностей других этапов производства.
А вот при использовании Kanban, вместо того, чтобы тщательно оценивать каждый этап производства, вместо того, чтобы обеспечивать слаженность всех этапов, держат в центре внимания согласованность скорости работы процессов справа налево. То есть — к выпуску следующей партии шин приступают только тогда, когда производство шасси сообщает о том, что оно готово к выполнению дополнительной работы.
При таком подходе можно динамически адаптироваться к временным задачам, возникающим на любом из этапов производства. Если, например, у вас проблемы с процессом развёртывания ПО — вы сможете уделить внимание их исправлению, а не начинать новые задачи, увеличивая при этом среднее время выполнения всех задач. Это происходит по двум причинам — из‑за того, что накапливается множество задач, ожидающих выполнения, и из‑за того, что приходится переключаться с одних задач на другие, тратя на это время.
Scrum способствует регулярному проведению совещаний
При применении Scrum команды обычно устраивают регулярные стендапы, совещания по планированию спринтов и ретроспективные совещания. Это всё, за исключением «спринтовых» совещаний — полезные мероприятия. Но при этом нет нужды практиковать Scrum для того чтобы вписать в планировщики всех членов команды регулярные совещания. Кроме того, непродуктивным может оказаться проведение подобных совещаний с фиксированной периодичностью.
Как я уже говорил, совещания по планированию спринтов непродуктивны из‑за того, что они ведут к «коллективному проектированию» и ориентированы на правильное оценивание трудоёмкости задач. Делать подобные оценки — это не только бесполезно, но ещё и нереально в такой среде, как разработка ПО, подверженной всяческим случайным воздействиям.
А вот ежедневные стендапы и ретроспективные совещания — это, с другой стороны, полезные и продуктивные мероприятия.
Регулярные ежедневные стендапы помогают командам раньше принимать решения о том, что из проекта нужно что‑то убрать, помогают скоординироваться ради ускорения работы над «стареющими» задачами, позволяют лучше синхронизировать свои производственные циклы и обеспечивают более высокий уровень предсказуемости этих циклов. При применении Kanban подобные совещания становятся ещё полезнее. Дело в том, что у тех, кто практикует Kanban, имеются более чёткие точки вмешательства благодаря ограничениям на задачи, находящиеся в процессе выполнения. Кроме того — люди сами работают с Kanban‑доской, что обеспечивает ориентацию членов команд на результаты, а не на детали реализации.
Ретроспективные совещания — это важнейший элемент непрерывного улучшения качества работы команд. Проблема с подобными совещаниями при применении Scrum заключается в том, что они проводятся либо слишком рано, либо — слишком поздно. Хотя командам полезно обсуждать свои подходы к работе и искать способы их улучшения, в ретроспективных совещаниях может и не быть необходимости в том случае, если всё получается невероятно хорошо. И наоборот — вредным может оказаться недельное или двухнедельное ожидание обсуждения системных проблем, влияющих на текущий фронт работ или на конечную цель, к которой стремится команда.
При применении Kanban ничто не мешает командам планировать регулярные совещания. Но при этом у них есть возможность ориентироваться в этом на реальную необходимость таких совещаний.
Итоги
Scrum — это не обязательно плохо, так как это — рабочий фреймворк. Но он, при этом, представляет собой «тренировочные колёса» для менеджеров. Он помогает менеджерам быстро организовать работу, избавляет от необходимости тратить слишком много времени на детальную проработку процессов. Но при этом Scrum, из‑за своей «нормативности», не даёт командам двигаться с той скоростью, на которую они способны.
Команды могут взять все плюсы Scrum, но при этом не пользоваться его «нормативными» практиками, которые могут не подойти к их сценариям работы.
Kanban — это прекрасный инструмент проектирования рабочих процессов, так как он проще Scrum, в нём меньше жёстких регулирующих механизмов, он основан на выборе задач, а не на их назначении. Хорошо продуманные принципы этого метода управления проектами образуют динамичную среду, в которой можно создавать эффективные системы. На самом деле — именно эти принципы встроены в Scrum, и именно поэтому Scrum — это работоспособная система.
Команды, применяющие Kanban, могут и быстро реагировать на обратную связь, и эффективно оценивать задачи, и визуализировать рабочие процессы, и экономить время, и непрерывно совершенствоваться, проводя те совещания, которые им нужны.
Kanban улучшает «отзывчивость» команд из‑за того, что этот инструмент не предусматривает двухнедельной задержки, необходимой для реакции на обратную связь пользователей, или на адаптацию к чему‑то новому.
Более того — Kanban позволяет командам эффективно оценивать масштабы работ, так как он полагается на согласование скоростей решения задач, а не на точную оценку времени их выполнения. Такая оценка, с учётом вероятностной природы процессов разработки ПО, практически невозможна.
Подобное внимание к согласованию скоростей решения задач, скомбинированное с такими принципами, как ограничение количества текущих задач, ведёт к снижению пустой траты ресурсов. Дело в том, что это стимулирует своевременную оценку объёмов работ, что позволяет командам выходить на нужные результаты в заданные временные рамки.
И наконец — Kanban позволяет визуализировать задачи, так как Kanban‑доска была создана, что понятно, специально для Kanban. В рамках Kanban, кроме того, имеются правила, касающиеся анализа доски и принятия необходимых мер.
Большинство регулярных совещаний Scrum, за исключением тех, где планируются спринты, тоже приносят пользу. Но при этом командам не обязательно применять Scrum для того чтобы планировать регулярные совещания, вроде ежедневных стендапов. А в некоторых случаях командам могут не понадобиться и подобные регулярные мероприятия. Например — ретроспективные совещания могут оказаться бесполезными, если всё работает безупречно и если команде нужно сосредоточиться на выпуске определённого функционала, а не на встречах, на которых говорится только о том, что всё идёт просто замечательно.
О, а приходите к нам работать? 🤗 💰
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.
