Scrum vs Kanban — что, где, когда?

Где-то давным давно услышал принцип — профессионал выбирает инструмент под задачу, выбор подходящего инструмента позволяет максимизировать соотношения затраты-результат. В этой статье опишу своё видение области применимости данных гибких методологий — когда и какую выбирать.

О себе: получил образование менеджера в ИТ, около 4 лет применял гибкие методологии на практике, из которых 2 года — в строго иерархически-бюрократическом окружении. Эта повышенная сложность позволила получить много опыта в кратчайшие сроки.

Идея данного подхода родилась в момент, когда в разговоре с аналитиком одной из команд я осознал, что ей неважны все эти скрам-мероприятия — она не видела в них смысла. Дальнейшие размышления на эту тему привели к мысли, что в полном соответствии с фундаментальной ошибкой атрибуции причиной тому, возможно, являются разные исходные условия. На мой взгляд, это очень хорошо видно в следующем графике, на который для удобства добавлены несколько точек:

​Зависимость точности оценки от усилий<br /> Майк Кон "Agile: оценка и планирование проектов"<br />
​Зависимость точности оценки от усилий
Майк Кон "Agile: оценка и планирование проектов"

Если команда работает над продуктом, то у неё высока степень неопределённости того, каким будет будущий продукт в условиях конкуренции. Таким образом, затраты от x1 до x2 на проведение Scrum-мероприятий приводят к повышению определённости от y1 до y2, в некоторых случаях может быть даже от 0 до x1, и выхлоп — от 0 до y1 соответственно.

Если команда работает над проектом, то степень неопределённости ниже. Известно, каким должен быть продукт. Таким образом, затраты выглядят как переход от x2 до x3, с выхлопом от y2 до y3; или даже в случае типовых проектов от x3 до x4 — дополнительные затраты практически не приносят дополнительного результата! Иными словами, здесь действует закон убывающей предельной отдачи.

К чему это приводит на практике? В компании внедряется фреймворк Scrum, и оказывается, что ряд команд отлично работает по Scrum'у, а другие — плюются и открещиваются от него. Казалось бы — вот одни молодцы, а вторые — ретрограды. Ведь компания одна, люди вроде одинаковые, но одним командам Scrum помогает, а другим - мешает. Детальное рассмотрение позволило увидеть, что ряд команд создают продукты, а другие команды реализуют проекты. Последние команды страдают от того, что их заставляют делать то, в чём они не находят ни малейшей пользы. Ужасные ощущения. А учитывая, что внешний стресс и выполнение работы без осознания результата приводит к вьетнамскому синдрому, когда выбирается не лучшее, а похожее на лучшее, решение, соответственно, качество продукта данных команд ухудшается, что приводит к ложному выводу - они не работают по Scrum'у, поэтому у них ничего не получается!

​Демонстрационная резьба по дереву<br /> Владимир Бамбурин<br />
​Демонстрационная резьба по дереву
Владимир Бамбурин

Если посмотреть на мастеров своего дела, то мы увидим, что они имеют множество инструментов для выполнения своих задач (об инструментах мышления для аналитика я написал предыдущую статью). Scrum не должен генерировать проблему непроизводительных затрат (когда научился пользоваться молотком, всё вокруг превращается в гвоздь), он становится полезным инструментом при разумном и грамотном применении.

ДНК всех модных методологий и фреймворков - военная сфера. Agile - это название проекта Минобороны США по борьбе с повстанческими движениями в Юго-Восточной Азии. Джефф Сазерленд в своей книге пишет, как вдохновлялся идеями групп спецназа. Donald G. Reinertsen в книге "The Principles of Product Development Flow: Second Generation Lean Product Development" пишет про то, что не всегда нужен Scrum, ссылаясь на опыт корпуса морской пехоты США.

Всё очень просто, когда от выбранного фреймворка зависит не только как быстро ты разгребёшь свой бэклог, но твоё здоровье и жизнь, то мозг работает правильно и интенсивно - остальные не выживают. Риск на собственной шкуре великолепно чистит мозги от шелухи. Поэтому военные и выработали действенные подходы, которые потом позаимствовали технари.

У Андрея Загорцева (полковник ГРУ МО РФ, участник операций на Северном Кавказе, Приднестровье, награжденный медалями и орденами и заодно автор книг про военную службу) было рассуждение о том, что спецназ должен выполнить свою задачу, при её решении он может маневрировать, перемещаться, лишь бы её выполнить; пехота должна любой ценой держать установленный ей участок фронта. Ценность задач спецназа оправдывает практически любые затраты на подготовку спецназовцев, их экипировку и т.п.; пехота же должна держать свой участок фронта данными силами. Сюда же можно добавить строевую (комендантскую) службу, которая обеспечивает выполнение требований уставов в строгой форме.

Таким образом, если команда работает над продуктом, который окупает практически любые усилия на его разработку специалистами, то это аналогично работе спецназа. Если команда работает над потоками проектов, где она должна решать задачи в рамках определённых бюджетов, сроков и функционала, то это аналогично целям пехоты. Если команда работает строго над одним проектом, необходимо что-нибудь из PMBoK, аналогичное комендантской службе.

Поэтому в зависимости от исходных данных нужно ориентироваться либо на Д. Сазерленда, либо на Donald'а G. Reinertsen'а. Например, мой бывший коллега Алексей снизил очередь задач в бэклоге с 40 недель до 20 за счёт применения идей Канбан-подхода по Дэвиду Андерсону (Канбан. Альтернативный путь в Agile).

При этом со Scrum'ом дело усложняется следующим образом:

Scrum vs Kanban — что, где, когда?

Как видно - управлять Scrum'ом - сложно, сложнее, чем потоками, сегодня эта сфера мало проработана наукой и философией. Поэтому порой ситуация столь плачевна - сложный в реализации Scrum, да ещё и не в тех условиях - мощнейшее сочетание, удивительной "пессимизирующей" силы в сфере разработки программного обеспечения.

Надеюсь, данный материал поможет кому-то выбрать правильный инструмент для соответствующих условий:

- Если команда работает над продуктом, то Scrum;

- Если команда работает над потоками проектов, то Kanban/иная методология для работы с потоками;

- Если команда собрана для одного проекта, то и другие методологии от PMI по PMBoK.

Выражаю благодарность за идеи для данной статьи моим бывшим коллегам: руководителю проектов Дмитрию и скрам-мастеру Алексею. В статье использована фотография Владимира Бамбурина. Дополнительные материалы на тему развития аналитического мышления для всех желающих в моём канале - @antxt.

33
8 комментариев

Фраза "ДНК всех модных методологий и фреймворков" статью не красит.

Тезисы типа "Если команда работает над продуктом, то Scrum" не являются очевидными и требуют детального обоснования.

1
Ответить

 > Например, мой бывший коллега Алексей снизил очередь задач в бэклоге с 40 недель до 20 за счёт применения идей Канбан-подхода

Вот это поворот.
Если перспективы развития вашего проекта-продукта-ватэвер насколько ясны, что вы можете запилить бэклог на 40 недель, то в общем-то причем тут скрам?

1
Ответить

Отличное summary методологий управления! Спасибо!

Читал ряд других статей на тему "выбора методологии управления" и всё время задавался вопросом: а вообще менеджеры, которые "выбирают инструмент под задачу" (скрам, канбан, вотерфол /PMI) в природе существуют? И в каких компаниях водятся?
Практически всегда приходишь в средУ компании, где на вопрос об организации раб. процесса обозначают "у нас Скрам" или "У нас Канбан" или "У нас смесь Скрам\ Канбан" или "у нас все по PMBoK". А вот такого, чтоб "давайте оценим задачу и выберем методологию" - не припомню такого. :)

1
Ответить

Думаю, все дело в том, что многие не отдают себе отчет, что для решения разных задач могут использоваться разные методологии, даже если работают в режиме многозадачности. Например, зачем использовать Scrum, если можно работать по инструкции, верно? Но если команда сталкивается с новой задачей, то тогда этот метод применить было бы вполне логично. Вот тут, кстати, хорошо описано, для каких целей лучше использовать Scrum https://leadstartup.ru/db/scrum 

1
Ответить

Постановка вопроса "Scrum vs Kanban" некорректна.

Картинка "При этом со Scrum'ом дело усложняется следующим образом:" еще менее корректна.

Kanban-метод не противоречит Scrum фреймворку и не конкурирует с ним в чистом виде.
Результат применения Канбан-метода как измененный процесс работы может конкурировать. Но не Канбан-метод.

Scrum может быть одним из этапов развития процессов по Канбан-методу. А может быть преобразован в что-то иное, если это "иное" лучше подходит для конкретного сервиса.


Для полного следования канону "Scrum vs Kanban" нужно добавить в статью "Waterfall" (тм).

Ответить

Комментарий недоступен

Ответить

А если проект - это проект о проекте по созданию проекта?!

Ответить