Все статьи
Что нового в SAFe® 5.1
Дата: 10.02.2021
Кратко о самом важном в обновлении фреймворка Scaled Agile Framework® (SAFe®) 5.1, лидирующего в мире подхода обеспечения Business Agility для крупных компаний.
Икона, на которую молишься каждый раз когда открываешь сайт Scaled Agile Inc., называется SAFe Big Picture. Показываю вам эту картинку новой версии. По крайней мере, именную такую нам показали на закрытых партнерских митапах. То есть она, возможно, еще изменится, но нам сказали, что она будет вот такой. Я сейчас пробегусь по ней, покажу, что на ней поменялось. Сбоку QR-код на видео, оно на 17 минут (прим. ред. — What’s New in SAFe 5.1, видео 17 минут), но я постараюсь еще быстрее рассказать, что же на самом деле нового появилось. А все мы эту картинку увидим 10 февраля, по крайней мере, как обещано.
Я обвел зеленым цветом первое, на что нужно обратить внимание 10 февраля — обновилась ли версия до 5.1. Кстати, прикольно, обратите внимание, ролик у них называется: «Что нового в SAFe 5» — а рассказывают про SAFe 5.1.
Portfolio SAFe
Cамое интересное, что появилось. Смотрите, я выделил это красным: появились иконки двух типов цепочек создания ценности (прим. ред. — Value Streams). Явно они не сказали, но, скорее всего, под каждую из них статья отдельная появится. У них же все так: если есть иконка, значит, в нее можно ткнуть и погрузиться в подробнейшую статью. Сейчас такой статьи нет, есть объединенная статья про то, как подходить к нарезке Agile Release Train — Value Stream Workshop. Это изменение позволит сильнее сфокусировать нас на том, что есть 2 типа стримов: клиентский путь и зарабатывающий Operational Value Stream, а Agile Release Train – это все-таки Development Value Stream, которых может быть несколько в рамках одного операционного.
Тоже интересная штука, выделил рыжим. Появился маленький зелененький квадратик, внутри него написано РВ, это расшифровывается Participatory Budgeting, а на русский мы перевели как «Инициативное Бюджетирование». Дальше я расскажу подробнее, что это такое. Забегая вперед, это полугодовое PI-планирование топ-менеджмента про деньги, про распределение бюджетов. Также на выходе появились Solutions, раньше там этих иконок разноцветных коробочек не было. Это очень важно, потому что сильно связано с тем, как проходит полугодовое бюджетирование. Дальше я тоже расскажу подробнее.
Essential SAFe
Очень много изменений произошло на уровне Essential. Чуть по-другому они нарисовали змеевик, который показывает, что есть три одновременных зацикленных процесса: определить, что нужно сделать, сделать это и все-таки дотащить до клиента. Обратите внимание, они засунули тот же самый процесс внутрь итераций. Видите, где написано CE (прим. ред. — Continuous Exploration), CI (прим. ред. — Continuous Integration) и CD (прим. ред. — Continous Deployment). Это они еще раз упирают, что у вас даже на уровне Scrum-команд не должно быть спринта исследования, затем спринта разработки и так далее, а все должно выполняться параллельно.
Что еще? Раньше Release on Demand, то есть кубики релизов были в конце поезда. Это старый атавизм. Откуда вообще поезда взялись, почему не самолеты, например? Эту метафору придумал Дин Леффингвелл (прим. ред. — автор Scaled Agile Framework): если ты опоздаешь на электричку, то все, ты не успел. Грубо говоря, если фича не успела сесть в поезд в начале квартала, то есть прибежать на PI-планирование проработанная, приоритизированная, то все: «Приходи в следующем квартале». Поэтому релизы были в конце поезда. Сейчас, как видите, они явно через картинку уже говорят нам: «Нет, релизиться надо чаще! Все, прошли те времена, когда SAFe только придумывался».
Пятое изменение, фиолетовым цветом в нижнем левом углу. Раньше там было несколько типов команд, но они ни о чем конкретном нам не говорили. Сейчас будут 2 статьи, как работать с технологическими и бизнес-командами. Это все уже есть во фреймворке. Но добавится явное разделение технологических команд на hardware teams и software teams. Пока эта статья якобы не опубликована. А вот для бизнес-команд появится сводная статья. Обещано, что там будет собрана инструкция по тому, как прыгать в Agile: HR, маркетингу и закупкам — а также будут добавляться новые функции.
Program
Так, шестое изменение, SPC. Раньше тут было написано SAFe Program Consultant. Также везде Program Increment стали рисовать просто как PI. Слово Program начинают потихонечку наконец-то выпиливать. Раньше оно нужно было как стыковка с PMBoK, со всей терминологией оттуда. Программа проектов — это раньше было Program Level. Слава Богу, сейчас он называется Essential SAFe. Потихонечку все связки со старым миром убирают. Cейчас, получается, SPC, видимо, надо называть просто SPC, не использовать слово Program.
Теперь подробнее про артефакты, которые на самом деле уже доступны.
Participatory Budgeting
В том числе, благодаря волонтерам, мы перевели статью и видеоролик на 4 минуты (прим. ред. — Инициативное Бюджетирование в SAFe®), чтобы быстро познакомиться.
В чем основная идея? Представьте маленький кейс, например, вы стартап, у вас четыре партнера, конечно, у вас есть набор инициатив. У вас есть стратегия, куда бежать, она разбита на эпики, вам примерно понятно, что надо делать и куда бежать. Вы понимаете, во что вы инвестировали в прошлом полугодии. GTB (Grow The Business) и RTB (Run The Business) — это вы знаете, сколько вам нужно на операционку тратить, а сколько у вас остается бюджета на развитие. Так вот, вы садитесь за стол, берете остаток, то есть GTB-бюджет. Например, это 100 тысяч, вы ж еще маленький стартап. Вы эти 100 тысяч раскладываете равными долями по партнерам, например, покупаете 100 конфеток и распределяете по 25 конфеток каждому сидящему партнеру за столом. После этого каждый из вас может своими конфетками распорядиться, как он сам считает нужным, никто его заставить не может, и так делает каждый. Перед вами набор инициатив, вы должны конфетками их бюджетировать. У каждой инициативы есть запрашиваемый бюджет. Соответственно, нужно договариваться.
На большом масштабе, представьте, у вас таких людей будет очень много. Соответственно, это правление и руководители функциональных и бизнес-подразделений, без которых такую приоритезацию, такое бюджетирование вы провести не сможете. Их множество за столами, таких столов много, но за каждым столом кросс-функциональная группа.
Как это примерно в реальной жизни происходит? Пока известных примеров проведения такой штуки в России мы не знаем. Надеемся, что в этом году появится первая реальная экспертиза. Но мы успели протестировать вначале на таком же митапе, а потом стали на тренингах наблюдать, как себя ведут люди в этой игре. Так вот, на самом первом прогоне, мы тогда с Русланом это делали, интересный инсайт. Оказывается, максимально сильная прозрачность появляется.
Как там история развивалась? Я вам показываю итоги такого форума по бюджетированию. Посмотрите, в первом столбце перечислены были эпики, которые надо было инвестировать, во втором столбце – сколько они хотели денег на себя. Дальше столбцы — группы. Одна группа – это один стол, за которым порядка 5 человек сидело. У нас тогда было две группы по 5 человек, потенциально у вас их может быть чуть ли не бесконечное количество. Обратите внимание, там где написано: «Полностью» — это если группа решила разложить конфетки, и полностью инвестировала требуемый бюджет, то есть, например, 100 тысяч в первый эпик, который и требовал такую сумму. Но есть, как вы видите, варианты, когда одна группа полностью инвестировала, а другая нет, такое бывает. Но обратите внимание, насколько сильна сходимость у групп. Такую же сходимость мы наблюдаем и на более больших группах участников. Это самая интересная штука в этом: если есть общий контекст, проведена подготовка к мероприятию — ничего страшного не произойдет. В целом набор умных людей мыслит примерно одинаково, если их запитать единой информацией.
Так, красным я выделил, смотрите, тогда был забавный кейс, в последних двух столбцах, там я, как бы играя роль генерального директора, смотря на голоса моего электората, я как бы принимал решения, то есть точно бюджетируем или нет. Y (Yes) – это точно бюджетируем. Видите, получился перерасход на 300 тысяч, красным показывается внизу перерасход, то есть у нас нет этих денег. Оказывается, я случайно Y поставил на второй эпик «Обеспечить геймификацию». Я реально совершенно случайно это сделал.
К чему это привело? Это было очень смешно, мы потом даже комикс с Русланом специально нарисовали про это. У Саши Колесникова из Kaspersky, у которого фраза зачеркнута, случилась техническая проблема с платформой: он говорит, а его никто не слышит. Потом оказалось, что он говорил: «Вы что там, генеральный директор, делаете?» В шутку потом мы нарисовали такую ситуацию, что произошел сговор между генеральным директором и руководителем проектного офиса. Да, вот так все становится прозрачным.
Топология команд
Вторая суперинтересная штука, которая появляется, это топология команд. Уже сейчас она тоже доступна. Мы подсуетились, самые интересные вещи мы уже перевели для вас, все это уже есть на русском языке.
Откуда это взялось? Классная книжка про топологию команд, которая нам принесла интересную информацию. Раньше мы команды отстраивали только от 2 векторов. Мы их называли или фича-командами, которые в идеале могут все сделать на цепочке поставки ценности, или компонентными командами, которые фокусируются на технической экспертизе конкретного компонента, который поддерживает только один или несколько шагов обслуживания клиента. Авторы книжки сказали: «Ребят, так слишком просто, такое разделение не решает огромное количество задач, связанных с дизайном стримов».
По факту они предложили 4 типа команд.
Первый тип они называют их потоковыми командами. В принципе, это практически то же самое, что фича-команды. Фича-команды – это, конечно, классно, потому что они снижают Time-to-Market. Но в чем проблема? Очень часто у вас возникает повышенное когнитивное напряжение на эти команды. Мне как-то один знакомый из одного известного банка рассказал следующую историю, точнее байку про их банк. Говорит, что была такая ситуация… Разработчик пришел к своему начальнику и сказал: «Слушай, я хожу по собеседованиям, просто чтобы знать, каков я на рынке труда. Но вот никто не хочет мне специально доплачивать сверх того, что я Java-программист, за то, что я уже знаю Cobol, 1С и прочее, все, что мне тут пришлось узнать, работая в фича-команде. Как же дальше жить, как мне такому дикообразу цениться на рынке труда?» Вас может ограничивать рынок труда, если вы реально крупная компания. Это напряжение на фича-команды остается, то есть не всегда это разумно делать.
А вот компонентные разделили аж на три типа. Платформенные команды, для которых являются потребителями все остальные команды. Вспомогательные команды — это концепция системной команды, которая есть уже в SAFe. Точно новым является тип команды «сложных подсистем».
Как это использовать? Можно посмотреть, как ваш поезд структурирован вдоль цепочки поставки ценностей. Вы рисуете Operational Value Stream, то есть раскладываете, как обслуживание клиента происходит, получение им услуги. Затем внутри рисуете ваш поезд, чтобы видеть, какие шаги сам поезд поддерживает и развивает. Вы видите, на какие итоговые метрики фокусируются поезд. А внутри поезда уже опять же этими полосочками раскладываете ваши команды и смотрите, насколько у вас, получается, структура реально выстроена вдоль оптимизации прыжков работы между разными командами.
