Функция safe что это
SAFe или Scaled Agile Framework
Что такое SAFe?
Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.
Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?
Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.
Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.
SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. Т.е. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек
Выгода?
В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead
Во-вторую очередь отделы управления программами. Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. То же самое относится к разного рода архитекторам. В SCRUM для них нет функции в SAFe — есть карьерный путь.
Далее — это может быть выгодно тем владельцам бизнеса, где управляющие работают над большими, пожирающими огромное количество человеко-часов проектами и не могут (иногда по объективным причинам) сделать эти проекты независимыми.
Множеству разработчиков с квалификацией ниже среднего, т.к. часто для того, чтобы что-то сделать их нужно экспоненциально больше чем тех самых опытных и замотивированных профессионалов.
В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.
SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).
На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.
Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)
Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.
Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.
Плюсы
Недостатки
Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.
Что такое SAFe, кому он нужен и где его применять
Scaled Agile Framework® (SAFe) — это онлайн-база знаний, состоящая из доказанных, интегрированных принципов, практик и компетенций внедрения Lean, Agile и DevOps при масштабировании.
Так что это, Scaled Agile Framework или SAFe?
Методология Scaled Agile Framework — это гибкий фреймворк для масштабирования процессов и проектов в организациях, плавающий в айти-вселенной на трех китах: Команда, Программа и Портфель.
Думаете, это выглядит так?
Нет. По сути, SAFe внедряет принципы равенства лишь внутри каждого из китов:
Вся же структура организации выглядит как-то так:
На первом этаже SAFe — Scrum
Это почти что классический скрам: команды по 3-9 человек, спринты по 2-3 недели, скрам-роли, скрам-артефакты и скрам-события. Но только команда теперь не полностью независима. И спринт не полностью самостоятелен.
Для того, чтобы связать между собой работу разных команд над одним продуктом, спринты теперь объединяются в программные инкременты (обычно 5 спринтов = 1 PI). И если в Scrum коррекция производилась по окончанию каждого отдельного спринта, то в SAFe — по окончанию PI. В чем-то это экономит время и упрощает работу в масштабе. С другой стороны, если мы ошиблись вначале, то часто тащим и развиваем этот груз до следующего PI Planning.
На втором этаже SAFe
Ходят Agile Release Trains (по-простому поезда). Здесь же “живут” носители новых ролей: системный архитектор (управляющий архитектурой), продакт-менеджер (старше владельца продукта по званию и полномочиям) и Release Train Engineer (тот же профессионал проектного менеджмента, по-простому PMP в SAFe).
На втором этаже SAFe добавляются некоторые наработки канбана — velocity metrics, scope, способ назначения приоритетов и, конечно же, доска.
Последний из 5 спринтов объявляется организационным. На собрания этого спринта приходят все команды, то есть, 100 и более человек. Здесь анализируется технический долг, производится планирование архитектуры и в целом синхронизируется работа команд.
На третьем этаже SAFe
Происходит координация больших систем и взаимодействия между директорами, отделами и клиентом. На этом этаже анализируются и проверяются гипотезы, а также создаются долгосрочные планы (ура waterfall).
Этот этаж может быть последним, если у компании нет портфеля. А вот если есть…
На четвертом этаже SAFe
Происходит бережливое управление портфелем — Lean Portfolio Management. Здесь выбираются перспективные направления и распределяются средства, принимаются решения о покупке или слиянии организаций, создаются новые направления и закрываются старые. На этом этаже рождается, корректируется и переназначается бюджет. Для оценивания существует ряд метрик, для синхронизации — свои ритуалы.
“Вишенка на торте” — стратегия. Но так глубоко фреймворк SAFe уже не заходит.
Ценности SAFe
Четыре основные ценности SAFe — это ключ и основа для эффективного применения этой методологии.
1. Согласованность
Согласованность необходима, чтобы идти в ногу с быстрыми изменениями, разрушительными силами конкуренции и географически распределенными командами.
Согласованность не подразумевает и не поощряет каскадный менеджмент. Согласование происходит, когда все работают в одном направлении. Оно обеспечивает расширение прав и возможностей, автономию и децентрализованное принятие решений, позволяя тем, кто реализует ценности, принимать более правильные решения на местном уровне.
2. Встроенное качество
Встроенное качество гарантирует, что каждый элемент и инкремент решения отражает стандарты качества на протяжении всего жизненного цикла разработки. Качество — это не то, что «добавляется позже».
Повышение качества является требованием бережливого производства и потока — без него организация, скорее всего, будет работать с большими партиями непроверенной работы. Вероятные результаты — чрезмерная потребность в переделках и снижение скорости.
3. Прозрачность
Без доверия никто не может создать высокопроизводительные команды и программы, а также укрепить (или восстановить) уверенность, необходимую для принятия и выполнения разумных обязательств. Без доверия рабочая среда намного менее увлекательна и меньше мотивирует.
Прозрачность, которую вы обеспечиваете с помощью некоторых практик SAFe, — первый шаг к доверию.
4. Программная реализация
Первые три ценности SAFe не имеют значения, если команды не могут работать и постоянно доставлять ценность. Поэтому SAFe уделяет большое внимание рабочим системам и бизнес-результатам.
Первые три ценности позволяют командам SAFe сосредоточиться на четвертой. И если они будут бороться (а они будут, потому что разработка сложных решений — непростая задача), у них есть краеугольный камень воркшопов по инспекции и адаптации. Таким образом, они замыкают цикл и работают все лучше и лучше во время каждого программного инкремента.
Все эти ценности невозможны без настоящего Lean-Agile лидерства и культуры непрерывного обучения. Только так, создавая постоянную и осмысленную культуру для команд и стейкхолдеров, можно организовать постоянную поставку ценности в потоке.
Принципы SAFe
1. Обосновывайте экономически. Традиционно бюджеты были известны только лицам, принимающим решения. Повседневные решения участников процесса на всех уровнях принимались без понимания экономической составляющей. Это приводило к задержкам, ограниченным возможностям и сниженной эффективности команд на всех уровнях.Экономика должна обосновывать и определять решения на всех уровнях, от портфолио до гибких команд.
2. Мыслите системно. Системное мышление предполагает целостный подход к разработке решений, включающий все аспекты системы и ее среды в ее проектирование, разработку, развертывание и обслуживание.Три аспекта системного мышления:
Понимание этих концепций помогает лидерам и командам ориентироваться в сложности разработки решения, организации и общей картине времени вывода на рынок в целом.
3. Предполагайте изменчивость. Сохраняйте варианты. Человеческая природа стремится к стабильности и устойчивости. Чем меньше изменений, тем нам спокойнее.Изменчивость сама по себе — это ни плохо, ни хорошо. Однако, именно экономика, связанная со сроками и типом изменчивости, определяет результаты. Наша цель в том, чтобы управлять изменчивостью и сохранять варианты. Так у нас будет и контроль, и гибкость, необходимые командам для разработки отличных решений.
4. Разрабатывайте поэтапно (инкрементально) с помощью быстрых интегрированных циклов обучения. Вместо того, чтобы на раннем этапе выбрать один вариант требований и дизайна, мы строим решение постепенно, каждый раз учитывая серию требований и вариантов дизайна.Каждый результат дает инкремент рабочей системы, который можно оценить отдельно. Дальнейшие временные рамки основываются на предыдущих шагах. Так решение развивается поэтапно вплоть до релиза.
5. Основывайте майлстоуны на объективной оценке рабочих систем. Обычно в отрасли применяется последовательный каскадный процесс разработки, где измерение и контроль прогресса происходит через ряд конкретных этапов: открытие идеи, подготовка требований, дизайн, разработку, тестирование и доставку.SAFe советует не привязываться к этим этапам, а определять контрольные точки для инспекции и адаптации исходя из конкретной рабочей системы, над которой работает команда команд. Благодаря этому систему можно будет проверять и улучшать чаще, и делать это будут стейкхолдеры, релевантные конкретному этапу разработки. Коммерческая ценность системы также повысится.
6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей. Ограничьте количество параллельно реализуемых решений. Поработайте над тем, чтобы уменьшить сложность каждого элемента и всей работы целиком.Небольшие задачи позволяют чаще проверять правильность направления и лучше контролировать очередь задач.
7. Применяйте каденции и выполняйте синхронизацию с помощью кросс-доменного планирования. Гибкая разработка лучше всего работает в «зоне безопасности», где достаточная неопределенность обеспечивает свободу для внедрения инноваций и реагирования на события, а также уверенность в работе бизнеса. Основное средство достижения этого баланса — объективное знание текущего состояния. Эти знания приобретаются путем применения каденции, синхронизации и периодического междоменного планирования.Каденция — это ритмичный паттерн событий, обеспечивающий устойчивое сердцебиение процесса развития. Он делает рутинным все, что может быть рутинным, поэтому разработчики могут сосредоточиться на управлении переменной частью разработки решения.Синхронизация позволяет одновременно понять, решить и интегрировать несколько точек зрения.В дополнение к общей каденции, периодическое междоменное планирование (пример: PI Planning в SAFe) дает возможность одновременно интегрировать и оценивать различные аспекты решения — деловые и технические.Вcе это позволяет управлять изменчивостью за счет частого пересмотра и обновления плана.
8. Раскройте внутреннюю мотивацию работников умственного труда. С SAFe, работники умственного труда могут больше:
9. Децентрализируйте процесс принятия решений. Централизировать нужно только решения стратегического характера. Они:
Все прочее нужно решать на местах.
10. Организовывайте вокруг ценности. Этот принцип описывает, как освободить предприятие от самоорганизации, оптимизируя доставку ценности. Это получается сделать за счет трех вложенных частей:
SAFe для проектных менеджеров #1
Мы запускаем серию ознакомительных статей про SAFe для менеджеров проектов. В них мы расскажем о преимуществах, структуре и ролях Scaled Agile Framework, а также о том, где проектные менеджеры могут найти себе применение в данном подходе. Первая часть посвящена обзору подхода с точки зрения классического проектного управления.
Часть 1: Место проектов в SAFe
SAFe – один из наиболее популярных в мире подходов для организации работы гибкой компании. Его преимущество перед другими методами состоит в следующем:
В минимальном виде SAFe выглядит как уровни Team + Program. Уровни Portfolio и Large Solution опциональны в зависимости от потребностей организации. В этой статье мы не будем рассматривать уровень Large Solution и сконцентрируемся на трёх основных.
Командный уровень
На уровне команд SAFe придерживается базовых принципов гибкой разработки, описанных в Agile-манифесте и поддерживает итеративно-инкрементальную разработку по фреймворку Scrum или методу Kanban. Команды итеративно разрабатывают элементы продукта двухнедельными итерациями (спринтами) и проводят демонстрации результатов своей работы и ретроспективу.
Единица управления на данном уровне – команда, реализующая пользовательские истории из бэклога. Роли на данном уровне такие же, как и в классическом Scrum: Владелец продукта, Scrum-мастер, член команды разработки.
Программный уровень
Уровень программы является ключевым как со стороны бизнеса, так и с точки зрения координации. На этом уровне все ресурсы, команды, заинтересованные лица кооперируются вокруг одной важной цели, чаще всего представляющую собой поток создания ценности (Value Stream) или продукт. Синхронизируют свою работу команды при помощи совместных сессий планирования (Program Increment Planning) в начале каждого квартала и демонстрации интегрированного инкремента продукта (System Demos) каждые 2 недели и ретроспективы (Inspect & Adapt) в конце каждого квартала.
Соответственно, все роли и процессы ориентированы на поставку ценных элементов функциональности. Метафорой этого процесса является “Поезд” (Agile Release Train).
ART – это долгоживущая группа команд, заинтересованных лиц и других участников, объединённых общей целью, создающая в едином ритме общее решение или его часть. Длина итераций и частота общего планирования внутри поезда фиксирована.
Управляет «Поездом», соответственно, «Машинист» (Release Train Engineer). Он коучит весь «экипаж» поезда для повышения эффективности работы, взаимодействует с заинтересованными сторонами, фасилитирует общие собрания поезда поставки. Он не начальник, он лидер этого поезда. Release Train Engineer больше всего похож на Scrum-мастера, но отвечающего не за одну, а за много команд и их взаимодействие между собой. В терминах PMI «Машинист» соответствует Менеджеру программы по уровню ответственности и исполняемым функциям (The PM role in a lean and agile world).
У поезда также есть главные «пассажиры» – Представители бизнеса (Business Owners). Это основные заинтересованные лица, которые отвечают за финансовые показатели Поезда. Business Owners – это руководители, которые будут получать выгоду от создаваемого решения, пользоваться им или продавать его.
Управляет продуктом и владеет бэклогом поезда команда Продуктового менеджмента (Product Management). В неё входят Владельцы продуктов отдельных команд, а также Продуктовые менеджеры. Они выявляют потребности клиентов, формируют дорожную карту и приоритезируют элементы функциональности. Говоря простыми словами, Представители бизнеса ставят цели, а команда Продуктового менеджмента стараются их достичь силами команд.
Также на программном уровне есть роль Системного архитектора (System Architect). Архитектор определяет архитектуру будущего решения, направляет работу команды с технической стороны системы, взаимодействия подсистем и нефункциональных требований к системе.
Уровень Портфеля
Цель портфельного уровня – согласование стратегии компании с реализацией портфеля за счёт организации процессов вокруг потоков создания ценности. Этот уровень появляется, если у организации несколько потоков создания ценности.
Портфель в SAFe состоит из Потоков создания ценности. Это могут быть продукты или направления деятельности организации. На этом уровне определяется стратегия инвестирования, бюджеты и показатели эффективности. Также на этом уровне реализуется функция принятия решения самого высокого уровня – портфельное управление (Lean Portfolio Management). И хотя глядя на схему может показаться, что Менеджер портфеля это некая отдельная роль, но это не так. На самом деле это группа функций, исполняемая людьми, которые могут также исполнять другие высокоуровневые роли в организации.
Корпоративный архитектор (Enterprise Architect) принимает решения относительно архитектуры всех систем в компании и их взаимодействия, для их гармоничного взаимодействия внутри организации.
«Проекты» в SAFe
Как можно заметить из схемы, роли проектного менеджера в SAFe нет, как и отдельного уровня проектов. Все бизнес инициативы связанные с созданием ценности реализуются в рамках «Поездов», уже существующих или созданных под инициативу.
Как же тогда в организациях, практикующих SAFe, реализуются инициативы по автоматизации, внедрению новых систем, затрагивающих всю организацию и многие «Поезда»? Для таких случаев в SAFe существует понятие Эпика (Epic). И он больше всего похож на классический проект.
Если возникает такая необходимость, Владелец эпика (Epic Owner) определяет описание Эпика и его Минимальный Жизнеспособный Продукт (Minimum Viable Product). Затем он взаимодействует напрямую с заинтересованными сторонами и «Машинистами» соответствующих «Поездов» для реализации Эпика.
Главное отличие от классического проекта в том, что разработка Эпика ведётся итеративно-инкрементально, а фокус функций Владельца Эпика смещается с управления командой на координацию взаимодействия с командами разных «Поездов». Реализация Эпика, как и у классического проекта, ограничена во времени. В отличие от потока создания ценности, развитие которого, как правило не останавливается.
Особенность эпика, вероятно повлиявшая на название (от англ. — «эпически, грандиозный»), в его масштабе. Это по-настоящему колоссальная инициатива, «прошивающая» большую часть организации. А потому Владельцем эпика чаще всего выступает кто-то близкий к C-уровню менеджмента в организации. Простому менеджеру проекта Эпик доверят вряд ли.
Что делать менеджерам проектов дальше?
Цифровизация, ускорение запуска инноваций, продолжающийся рост роли Интернета привели к тому, что уровень неопределённости бизнеса в целом и проектов в частности вырос. И предпосылок для замедления этого роста не наблюдается. Технологии, потребности, конкурентное окружение и прочие факторы меняются не только постоянно, но и с высокой скоростью. Со временем всё меньше организаций будут предпочитать классическое проектное управление гибким подходам в качестве инструмента развития своего бизнеса. А в большинстве Agile-методологий нет роли менеджера проекта. Увы, но это так.
Если организация хочет сохранить ценных, опытных и компетентных менеджеров проектов и использовать их потенциал в своём бизнесе, ей придётся приспособить их для исполнения новых функций. А менеджерам проектов, чтобы остаться в игре, придётся освоить новые роли и навыки. Какие, мы расскажем во второй части нашей статьи.