Обычно мы воспринимаем гибкие подходы как почти синонимы адаптивности, и предполагаем, что смена парадигмы или культуры в сторону её увеличения – правильный шаг чтобы начать agile-трансформацию. Но на деле одна из самых распространённых целей организаций, которую они хотят достичь с помощью трансформаций, – это предсказуемость. Почему? Потому что она приносит организации бизнес-результаты и итоги, которые руководство хочет получить для успешности и роста компании в целом.

Однако, в то время как уровень руководства нуждается в предсказуемых результатах и итогах, приверженцы гибких методологий склонны думать, что нельзя стать предсказуемыми, будучи адаптивными. Отнюдь – можно. Вы не только можете, но и должны, если вы хотите достичь гибкости организации в целом.

Предсказуемость по сути своей – про выяснение того, как брать на себя обязательства и выполнять их, делать то, что вы собирались сделать, таким образом, чтобы организация становилась надёжным и достойным доверия партнёром для её руководителей. И когда вы построите доверие, которое привнесёт собой предсказуемость, станет гораздо проще доказать ценность гибкой трансформации – и получить больше поддержки на уровне высшего руководства для дальнейших изменений в том же направлении.

В то время как предсказуемость всегда начинается на уровне команд, предсказуемость корпоративного уровня сталкивается с совершенно другим классом проблем, которые предстоит преодолеть, а потому нуждается в совсем иной стратегии достижения.

В каком уровне предсказуемости мы нуждаемся?

Потребность в предсказуемости разнится от организации к организации. В то время как некоторым нужен максимально возможный уровень, другим вообще не нужно ничего предвидеть. Здесь мы поговорим о предсказуемости в масштабе всей организации там, где от этого многое зависит.

3 аспекта предсказуемости на уровне команд

Полные, кросс-функциональные команды

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

Бэклоги

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

Получение работающего, протестированного продукта

Как только команда понимает размер своего бэклога и выходит на стабильную скорость поставки (velocity), она уже может прикинуть сколько спринтов понадобиться чтобы поставить всё, что в этом бэклоге находится, или какое количество единиц бэклога может быть сделано за предзаданное количество спринтов. Имея все эти данные, команда спокойно может брать на себя и выполнять обязательства по производству работающего, протестированного продукта.

Препятствия для предсказуемости

Зависимости

На деле же не все начинают с командой, в которой есть все и всё необходимое для поставки работающего протестированного инкремента продукта или программного обеспечения в том виде, как это описано в бэклоге. А не имея этого, вы тут же столкнётесь с кучей зависимостей. Если вы вынуждены зависеть от другой команды или внешних ресурсов чтобы осуществить поставку, вы не сможете стать предсказуемыми. Зависимости – это самые популярные убийцы гибкости.

Чтобы освободиться от зависимостей, вам нужно создать необходимые условия, в которых предсказуемость возможна.

Проблемы бэклога

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

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

Предсказуемость в масштабе

Три аспекта масштаба: структура, управление, метрики

Даже несмотря на то, что всё это сводится к тем же трём концепциям на уровне команд (команды, бэклоги и работающее протестированное ПО), когда мы начинаем смотреть на более серьёзный масштаб, мы видим несколько отличные классы проблем и препятствий предсказуемости, так что фокус каждого из этих трёх моментов слегка смещается.

Структура

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

Управление

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

Метрики

В то время, как на командном уровне мы производим инкременты работающего протестированного продукта (ПО), в масштабе мы сосредотачиваемся и на измерении ценности во многих командах с помощью метрик.

Гибкость командного уровня недостаточна для гибкости уровня организации

Большинство организаций оперирует проектами, и одобряет финансы под проекты, чтобы затем привлечь на эти проекты людей, сформировать из них команды, составленные «нарезанием» людей и команд на кусочки, вписывающиеся в проектное видение, чтобы  на выходе проект был сделан. Команды, составленные по такому принципу, приобретают огромное количество зависимостей. А зависимости убивают гибкость.

Что если вместо этого мы бы нарезали проект на кусочки, подходящие для того, чтобы отправить их в правильную команду, которая может выполнить части работ, для которых она лучше всего предназначена? Обычно при таком подходе мы оказываемся в ситуации, когда у одних команд ужасный перебор задач, а с одной стороны, есть команды, которые «голодают» без работы.

Это – замысловатая ситуация потому, что здесь – не проблема приоритизации или управления зависимостями, или даже взятия на себя и исполнения обещаний. Проблема – в том, что вы со своей задачей просто никогда не подниметесь достаточно высоко в очереди ограниченных в своих ресурсах команд, которые делают всю работу с самой высокой бизнес-ценностью.

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

В заключение

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

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