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

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

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

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

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

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

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

Если посмотреть на мастеров своего дела, то мы увидим, что они имеют множество инструментов для выполнения своих задач (об инструментах мышления для аналитика я написал предыдущую статью). 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'ом - сложно, сложнее, чем потоками, сегодня эта сфера мало проработана наукой и философией. Поэтому порой ситуация столь плачевна - сложный в реализации Scrum, да ещё и не в тех условиях - мощнейшее сочетание, удивительной "пессимизирующей" силы в сфере разработки программного обеспечения.

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

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

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

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

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