agile фреймворк что это
Что такое 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. Организовывайте вокруг ценности. Этот принцип описывает, как освободить предприятие от самоорганизации, оптимизируя доставку ценности. Это получается сделать за счет трех вложенных частей:
Agile Frameworks
Введение в Agile Frameworks
Понимание Agile Framework
Ниже приведен список некоторых из фреймворков, которые широко используются и наиболее популярны. Следует отметить, что между ними существует много общего, поскольку базовая структура является гибкой для всех из них. В конце концов, речь идет о том, какая структура более удобна с точки зрения реализации и подходит для решаемой проблемы.
Как работает Agile Framework?
Мы проанализируем и поймем, как работает каждая из вышеупомянутых структур
1. Методология Agile Scrum
Это простая структура, которая облегчает командную совместную работу над сложными программными проектами. Scrum подчеркивает командную работу в управлении проектами. Он подчеркивает ответственность и является итеративным прогрессом в достижении цели, которая уже предопределена и установлена. Scrum является частью гибкой разработки программного обеспечения.
Внутри Scrum есть две важные позиции или роли, которые нужно решить. Эти
2. Бережливая разработка программного обеспечения
Он опирается на быструю и надежную обратную связь между программистами и клиентами, он повышает производительность и эффективность, предлагая клиентам выбрать ценные функции, а затем расставить приоритеты этих функций, а затем работать над их предоставлением.
3. Kanban Разработка программного обеспечения
Это соответствует и в некотором роде основано на программном обеспечении Lean. Фактически, исследования показывают, что большой процент команд, практикующих Lean, использует Kanban для визуализации и активного управления созданием продуктов.
Канбан основан на 3 принципах
с. Улучшение потока: Когда что-то закончено, обрабатывается следующий элемент с наивысшим приоритетом.
В целом Kanban способствует постоянному сотрудничеству и поощряет активное постоянное обучение и улучшение.
4. Экстремальное программирование
Это подход, который направлен на предоставление высококачественного программного обеспечения, быстро и непрерывно. Он предназначен для улучшения качества и возможностей программного обеспечения. Он учитывает изменение требований клиента.
Он поддерживает и продвигает привлечение ваших клиентов, обеспечивает очень быструю обратную связь, постоянное тестирование, постоянное планирование и тесную работу с командами для поставки рабочего программного обеспечения с очень частыми интервалами, обычно каждые 1-3 недели.
Оригинальный метод экстремального программирования основан на четырех простых принципах:
5. Кристалл
С точки зрения других рамок кристалл отличается от других с точки зрения:
6. Метод разработки динамических систем (DSDM)
DSDM основан на восьми ключевых принципах, на которых сосредоточена работа команды над ним. Эти принципы служат для них основой, когда они работают с клиентами. Эти принципы в первую очередь:
Таким образом, общий DSDM развился, чтобы обеспечить всеобъемлющую основу для планирования, управления и выполнения Agile процесса.
7. Функциональная разработка (FDD)
Разработка, основанная на функциях, включает пять основных видов деятельности, ниже приведен список этих видов деятельности. Команда, работающая над функционально-ориентированной разработкой, использует эти действия в качестве эталона.
Зачем нам Agile Framework?
Вышеупомянутые гибкие фреймворки, каждая из которых обладает своими уникальными качествами, все они учитывают схожий процесс итеративной разработки и непрерывную обратную связь при работе с программным обеспечением. Agile защитники работают постепенно, совместно и гибко
Вывод
Рекомендуемые статьи
Agile фреймворки и чем они отличаются: Scrum vs Kanban
Все, кто работали и работают в сфере ИТ, хоть раз слышали про Agile, а еще про Scrum и Kanban. Сейчас практически любая компания хочет быть хоть немножечко аджайл, и это хорошо, когда есть выбор, но что именно подойдет вам? Чтобы окончательно не запутаться в этих понятиях и знать, в чем их преимущества, в этой статье мы предлагаем вам более детально ознакомиться с Agile и его основными фреймворками: Scrum и Kanban.
Что же такое Agile?
Agile — это методология “гибкой” разработки ПО. И, хотя это направление появилось в ИТ сфере, оно удачно применяется и в любой другой. Сейчас различные фреймворки и подходы Agile успешно прижились в таких корпорациях, как Microsoft, Salesforce, Trenches, Hewlett-Packard, Spotify, причем не только в сфере ИТ, но еще и в сфере маркетинга и управления. Это итеративный подход, суть которого отражается в Agile манифесте, и ее можно описать следующими тезисами:
В отличие от других подходов вроде Waterfall, где можно выполнять задачи только если они были запланированы ранее, с Agile команда сможет легко подстраиваться под новые требования и факторы. Особенно это актуально для крупных проектов, где стейкхолдеры постоянно хотят что-то поменять.
Проще говоря, Agile — это своеобразная философия, но как ее придерживаться, зависит от конкретного случая. Есть 2 основных фреймворка, которые основываются на базовых принципах Agile: Scrum и Kanban.
Scrum
Термин Scrum пришел из регби. Он означает особую фигуру, в которую собираются игроки перед началом матча, и выглядит это примерно так:
Фигура Scrum в регби
В бизнес среде слово Scrum у многих людей ассоциируется с ежедневными короткими собраниями команды в начале дня для обсуждения проделанной работы и планирования следующих задач.
Суть данного фреймворка в том, что вся работа делится на спринты — промежутки времени от 1 до 3 недель. Как только спринт выполняется, происходит его ревью — оценка и анализ проделанной работы, чтобы понять, что можно улучшить. В Scrum задачи необходимо оценивать в Story points или в часах. Без этой оценки у вас не получится сформировать спринт, ведь нужно знать, сколько часов потребуется на выполнение той или иной задачи. Еще один параметр — Velocity, то есть производительность команды за один спринт. Таким образом, Scrum подойдет для объемных проектов со строгим дедлайнами, где всю работу можно распланировать по четким спринтам, зная, сколько времени тратится на выполнение задачи и получая ценную статистику, благодаря которой можно предвидеть, где команда будет через 2 недели.
Kanban
Это еще один трендовый Agile фреймворк, который пришел в сферу ИТ прямиком с конвейера компании Toyota. В отличие от Scrum, где выполняются заранее запланированные задачи, здесь работникам можно время от времени “подбрасывать” новые таски.
Kanban визуализирует весь рабочий процесс и позволяет разделить все текущие задачи на 3 основных этапа: “Сделать”, “В процессе”, и “Сделано”. Еще один важный нюанс — Limit Work in Progress (WIP), то есть обычно ограничивается количество задач, которые сейчас находятся в процессе. Лучше синица в руках, чем журавль в небе, и стабильное выполнение небольшого количество задач лучше, чем если браться за множество тасков и толком не закончить и одного.
Независимо от количества задач, сначала будут выполняться таски с наивысшим приоритетом. В Kanban также не проводится оценка, и нет такого понятия, как “скорость работы команды”, можно просчитать только среднее время на задачу с помощью специального отчета Cycle Time. Если в Scrum цель команды — закончить спринт, то в Kanban — задачу.
Каждый Agile фреймворк хорош по-своему, и нам часто задают вопрос: “Какой фреймворк лучше выбрать?”. Наш ведущий эксперт Алекс Енин отвечает, что подобрать универсальное решение для всех — это из разряда фантастики, ведь то, что сработало в одной команде, далеко не всегда заработает в другой. Scrum держит всю работу над проектом под контролем, планируя все до мелочей, а Kanban позволяет сконцентрироваться на выполнении текущих задач, планомерно внося изменения в рабочий процесс. Нужно отталкиваться от конкретного случая, размеров команды, объема работы и сферы применения.
Обратитесь к экспертам Polontech, и наша команда проконсультирует вас по всем Agile фреймворкам, поможет подобрать и внедрить подходящий софт, а также сопроводит на начальных этапах. Расскажите нам о своем проекте, и мы подберем уникальное решение под ваши нужды.
Наши авторы
Профессионалы, работающие с Sony, NASA, Сбербанк, МТС, Nokia и многими другими компаниями. Спикеры на конференциях, авторы статьей
Что такое SAFe?
Узнайте о платформе SAFe, ее принципах и чем она отличается от других agile-платформ.
Просмотр тем
Scaled Agile Framework ® (SAFe ® ) — это набор организационных шаблонов и шаблонов рабочих процессов для реализации agile-методик в масштабе всей компании. Эта платформа представляет собой совокупность знаний, куда входят структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, а также соответствующие ценности.
Платформа SAFe применяется во множестве agile-команд, обеспечивая согласованность, помогая выполнять совместную работу и поставку. В ее основу легли три основных блока знаний: гибкая (agile) разработка программного обеспечения, «бережливая» (lean) разработка продукции и системное мышление.
SAFe предоставляет структурированный подход к масштабированию agile-методик по мере роста бизнеса. SAFe имеет четыре конфигурации, подходящие для различного масштаба применения: Essential SAFe, Large Solution SAFe, Portfolio SAFe и Full SAFe.
Дин Леффингвелл и Дрю Джемило выпустили платформу SAFe в 2011 году, чтобы помочь организациям разрабатывать более эффективные системы и программное обеспечение, которые лучше соответствовали бы меняющимся потребностям клиентов. В то время для поставки программного обеспечения команды использовали традиционные процессы управления проектами. Поскольку потребность в быстром реагировании на изменяющиеся условия рынка стремительно нарастала, появлялись новые платформы, помогающие бизнесу улучшать поставку решений в масштабах всей компании, в том числе и платформа SAFe. На сегодняшний день SAFe является одной из самых популярных масштабируемых agile-платформ поставки, а всемирное сообщество пользователей SAFe продолжает развивать ее.
Основные принципы и ценности
Основные ценности
Основные ценности SAFe описывают культуру, которую должно продвигать руководство, и поведение людей в этой культуре для эффективного использования данной платформы.
Соответствие
Платформа SAFe требует, чтобы компании устанавливали на всех уровнях организации последовательность планирования и рефлексии. Благодаря этому каждый сотрудник понимает текущее состояние бизнеса, цели и направление движения для достижения таких целей. Регулярная синхронизация людей и действий позволяет поддерживать согласованность всех уровней портфеля. Потоки информации своевременно движутся как вверх, так и вниз, в отличие от традиционных структур управления, где информация спускается сверху вниз.
Встроенное качество
В платформе SAFe гибкость никогда не должна достигаться за счет качества. SAFe требует, чтобы команды всех уровней определяли, в чем заключается «готовность» каждой задачи или проекта, и закрепляли качественные методы разработки в каждом соглашении о сотрудничестве. Согласно SAFe, существует пять основных показателей встроенного качества: процесс, качество архитектуры и дизайна, качество кода, качество системы и качество релиза.
Прозрачность
SAFe поощряет поведение, способствующее построению доверительных отношений, в том числе разбиение работы на пакеты сокращенного объема при планировании, чтобы быстрее выявлять проблемы, обеспечение в бэклоге наглядного представления прогресса по всем уровням в режиме реального времени, а также проверку и адаптацию ритуалов.
Выполнение программы
Выполнение программы лежит в основе SAFe и поддерживает все остальное на платформе. Команды и программы должны на регулярной основе доставлять качественное, работающее программное обеспечение и коммерческую ценность.
Руководство
SAFe требует от руководителей поведения, в котором сочетаются принципы бережливости и гибкости, поскольку только руководители могут изменить систему и создать среду, необходимую для внедрения всех ключевых ценностей.
Принципы SAFe
Принципы Scaled Agile Framework предусматривают улучшение компании в целом за счет принятия гибких и бережливых решений с охватом всех функциональных и организационных единиц. Эти принципы влияют не только на решения руководителей и менеджеров, но и на решения каждого сотрудника организации; они обуславливают необходимость перехода от традиционного мышления к мышлению, опирающемуся на методы гибкого и бережливого управления, которые применяются, к примеру, в практиках Lean Portfolio Management.
Принцип № 1. Смотрите с точки зрения экономики
Согласно теориям о процессе разработки продуктов, приводимым в бестселлерах Дональда Райнертсена, для достижения кратчайшего устойчивого времени выполнения нового заказа необходимо, чтобы каждый человек в цепочке принятия решений понимал экономические последствия задержек. Скорой и частой поставки не всегда достаточно. Согласно SAFe, по всей организации необходимо распределить следующие задачи: определение последовательности работ для получения максимальной выгоды, понимание экономических компромиссов и работу в рамках «бережливых» бюджетов. Многие концепции и инструменты опираются на теории Райнертсена о процессе разработки продуктов.
Принцип № 2. Применяйте системное мышление
Платформа SAFe создает условия для применения системного мышления в трех основных областях: собственно решение, компания, которая занимается разработкой системы, и потоки создания ценности. Решениями могут быть продукты, услуги или системы, поставляемые клиентам, как внутренним, так и внешним по отношению к предприятию.
Крупные решения имеют множество взаимосвязанных составных частей, поэтому участники команды должны обладать высокоуровневым представлением о том, как их часть вписывается в общую картину. При решении вопросов, которые касаются компании, занимающейся построением системы, платформа SAF рекомендует учитывать людей, менеджмент и процессы организации. Так, если организация стремится оптимизировать методы работы людей, ей может потребоваться устранить барьеры, стать межфункциональной и сформировать новые рабочие соглашения с поставщиками и клиентами. Наконец, компания должна четко определить, каким образом потоки создания ценности при разработке решения превращают ценность из концепции в измеримую прибыль. Руководителям и менеджменту необходимо добиться максимального увеличения потока создания ценности по всем функциональным и организационным единицам.
Принцип № 3. Допускайте вариативность; сохраняйте варианты
По умолчанию проектирование систем и программного обеспечения является занятием с неопределенным исходом. Данный принцип решает проблему неопределенности путем введения концепции вариативного проектирования (Set-Based Design), которое требует сохранять в цикле разработки множество требований и вариантов разработки на протяжении длительного времени. Вариативное проектирование опирается на эмпирические данные, чтобы к окончательному варианту разработки можно было переходить на более поздних этапах.
Вариативное проектирование помогает принимать обоснованные решения в периоды неопределенности путем выявления вариантов и ожидаемых конечных результатов; это похоже на стратегическую ставку. Важную роль в вариативном проектировании играют «контрольные точки обучения», которые связаны с крайним сроком принятия решения. Чем больше знаний команды обретают с течением времени, тем больше вариантов они могут исключить. Чем больше вариантов они исключат, тем легче будет определить оптимальный путь и достичь наилучшего из возможных результатов для клиентов.
Принцип № 4. Выполняйте инкрементальные сборки с быстрыми циклами обучения, интегрированными в процесс
Как и принцип № 3, этот принцип направлен на устранение рисков и неопределенности с помощью контрольных точек обучения. Недостаточно, чтобы работоспособность доказала каждая составляющая часть системы. Необходимо рассмотреть систему в целом, чтобы оценить возможность технической реализации текущих вариантов разработки. Чтобы ускорить циклы дальнейшего обучения, необходимо регулярно планировать последовательности точек интеграции. Эти точки интеграции являются примером цикла Уолтера Э. Шухарта планируй — делай — проверяй — корректируй, который является схемой для постоянного улучшения качества и механизмов контроля вариативности разработки. В SAFe часто используются работа Шухарта и другие работы, вдохновленные его трудами.
Принцип № 5. Контрольные точки должны основываться на объективной оценке работающих систем
Демонстрация действующей рабочей системы предоставляет более надежные основания для принятия решений, чем документ с требованиями или другая поверхностная оценка успеха. Заинтересованные стороны, с ранних этапов участвующие в принятии решений о технической реализации, способствуют построению доверительных отношений и поддерживают системное мышление.
Принцип № 6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей
Ограничение объема незавершенной работы помогает заинтересованным сторонам четко увидеть, как идет процесс.
Три элемента этого принципа демонстрируют основные способы максимального увеличения объема и скорости поставки ценности, т. е. реализации «потока». Как говорится, слона лучше есть по кусочкам.
Применительно к разработке программного обеспечения это означает ограничение количества параллельных работ, сложности каждого элемента работы и общего объема работы, выполняемой в данный момент времени. Небольшие задачи позволяют проводить постоянную проверку правильности хода работы и должным образом управлять длиной очереди.
Этот принцип служит ориентиром в оптимизации этих задач для достижения наилучших результатов.
Принцип № 7. Применяйте каденции, выполняйте синхронизацию с помощью кросс-доменного планирования
Agile-команды применяют каденции с помощью спринтов или итераций. Создание каденции для всех возможных работ позволяет уменьшить сложность, устранить неопределенность, выработать автоматизм, обеспечить качество и постепенно прививать сотрудничество. Синхронизация этих каденций позволяет людям и активностям перемещаться подобно винтикам механизма, где полученная информация сообщает о решениях и инкрементном планировании.
Принцип № 8. Раскройте внутреннюю мотивацию работников умственного труда
Этот принцип создан под влиянием идей консультанта по управлению Питера Друкера и автора Дэниела Пинка, и мы его очень любим! Речь идет о раскрытии потенциала команд и замене командно-административного мышления руководства на обучающий и помогающий подход к работе с командами.
Принцип № 9. Децентрализуйте принятие решений
Сокращение длины очередей и использование экономически эффективного подхода путем децентрализации процесса принятия решений дают командам независимость, необходимую для выполнения работы. Руководители должны сохранять свои полномочия по принятию решений по вопросам стратегической важности и позволять командам решать все остальные вопросы.
Как работает SAFe?
Организации, готовые внедрить платформу SAFe, обычно обладают поддержкой на уровне руководства, сильным намерением измениться и фундаментом в виде scrum.
Компания Scaled Agile, Inc. предоставляет дорожную карту внедрения SAFe, которая содержит подробные инструкции по началу работы и подготовке организации к проведению широкомасштабного применения платформы по всем портфелям. Внедрение SAFe состоит из следующих 12 шагов.
Чем SAFe отличается от других масштабируемых agile-платформ?
Несмотря на то, что платформа Scaled Agile Framework® (SAFe®) широко распространена среди предприятий с большими командами разработчиков программного обеспечения, с течением времени набрали популярность и другие масштабируемые agile-платформы. Все платформы для масштабирования agile объединяют пять основных компонентов: вдохновение от 12 принципов манифеста agile-методологии, последовательность действий, синхронизация, scrum и методы качественной разработки. Понимание происхождения других платформ, основных отличий и условий их успешного применения поможет организациям выбрать структуру, которая оптимально соответствует их потребностям.
Хотите познакомиться с предысторией некоторых основных масштабируемых agile-платформ? Прочтите обзор Agile-подход при любом масштабе на странице тренера по agile.
SAFe и Scrum@Scale
В Scrum@Scale (S@S) каждый сотрудник является частью взаимозаменяемой scrum-команды. В зависимости от целей сети scrum-команд объединяются, образуя экосистему. Платформа S@S предназначена для создания сети scrum-команд с помощью «немасштабируемой архитектуры», т. е. основные роли и события scrum масштабируются линейно, без введения в процесс новых движущих сил. Например, для очень сложного продукта с 25 scrum-командами одного Scrum of Scrum (SoS) может оказаться недостаточно, и тогда понадобится Scrum of Scrum of Scrums (SoSoS) и Scrum of Scrum of Scrums Master (SoSM).
Несмотря на то что платформа S@S в целом носит менее директивный характер, для определения готовности организации к масштабированию она предлагает ответить на один наводящий вопрос: если в систему добавить больше людей, производительность резко возрастет или ухудшится?
Как и SAFe, платформа S@S предлагает справочные материалы, доступные онлайн, в том числе набирающее популярность подробное руководство Scrum@Scale.
S@S приносит наибольшую пользу, когда:
SAFe и Large-Scale Scrum (LeSS)
Large-Scale Scrum (LeSS) применяет минималистический подход к ролям, структуре и артефактам. Там, где SAFe предлагает четыре конфигурации размещения все более крупных команд со все более сложными решениями, LeSS предлагает две: LeSS для организаций с 2–8 командами и LeSS Huge для организаций более чем с 8 командами. Согласно LeSS, владельцы продуктов должны обладать всеми полномочиями и стратегическим влиянием на контент, тогда как SAFe предлагает более демократичный подход. В то время как в SAFe многие факторы влияют на стратегию, LeSS опирается на клиентоориентированный подход с фокусом на клиентах, оплачивающих услуги.
Как и S@S, LeSS масштабируется на основе событий, артефактов и ролей scrum. И SAFe, и LeSS придают особое значение системному и бережливому мышлению, а также схожим руководящим принципам. Однако LeSS уделяет большое внимание сокращению отходов во всей организации с целью постоянной оптимизации.
LeSS приносит наибольшую пользу, когда:
SAFe и DA
В отличие от остальных описанных платформ, платформа Disciplined Agile (DA) представляет собой набор инструментов, который позволяет организациям решать, какой способ работы подходит им лучше всего. Она предлагает упрощенное agile-управление на основе scrum и kanban, а также способствующие трансформации знания в таких областях, как управление персоналом и финансами, менеджмент, DevOps, управление портфелем и многих других. DA предполагает ситуационное использование различных уровней масштабирования для каждого проекта и акцентирует внимание на том, что для определения стратегического направления необходимо создать условия для принятия решений.
DA приносит наибольшую пользу, когда:
SAFe и Spotify
«Модель» Spotify — это автономный набор практик с акцентом на людей, который можно применять для координации agile-команд. Она не задумывалась как модель или платформа, но некоторые компании внедрили ее именно в таком варианте. Модель Spotify ориентирована на самоорганизующиеся многофункциональные команды, расположенные в одном месте; их называют «отрядами» (эквивалент scrum-команд). Для сравнения, в SAFe нет оговорки по поводу совместного нахождения команд, которое рекомендуется для проведения PI-планирования.
Отряды организованы в более крупные подразделения, называемые «кланами». Проблемы, вызванные немногочисленными зависимостями между отрядами, при необходимости разрешаются на основе принципов Scrum of Scrums. Обмен знаниями происходит через «отделы» и «гильдии»; такие неформальные группы организуются на основе наборов навыков и интересов.
В отличие от других примеров, где доступны онлайн-ресурсы, учебные курсы и сертификации, ресурсы Spotify ограничиваются общедоступным блогом и другими сопутствующими материалами, разработанными основоположниками и поклонниками этой модели. Поскольку популярность Spotify растет, вероятно, в будущем мы увидим больше соответствующих материалов.
Spotify приносит наибольшую пользу, когда:
SAFe 5.0
Основным принципом SAFe является то, что эта платформа продолжает развиваться совместно с сообществом своих пользователей по всему миру. Совсем недавно компания Scaled Agile, Inc. выпустила SAFe версии 5.0. Основными изменениями стали добавление принципа № 10 «Организация происходит вокруг ценности» и изменение шага 12 с «Поддерживайте и улучшайте» на «Ускоряйте». На самом деле изменений гораздо больше. Хотите узнать подробности? Ознакомьтесь со статьей о том, что появилось и что изменилось в SAFe 5.0, в нашем блоге.
Заключение
Платформы типа SAFe и рассмотренных выше предоставляют компаниям экономически приемлемый способ эффективного масштабирования методики agile в организациях и достижения конечных бизнес-результатов. Но не менее важны и инструменты, которые они выбирают для укрепления существующих методов работы и реализации всех преимуществ этих методов. Используйте Jira Align от Atlassian, платформу для корпоративного agile-планирования, созданную для SAFe. С помощью Jira Align вы сможете повысить наглядность, стратегическое соответствие и адаптивность предприятия для ускорения цифрового преобразования.
Джессика Пииккила более десяти лет работает в сфере agile-преобразований, к тому же имеет большой опыт управления продуктами и agile-консультирования в компаниях разного размера из разнообразных отраслей. Привычка мыслить в категориях agile помогла ей пройти через ряд сложных жизненных ситуаций и питает страсть к обучению. Вы увидите, как она находит ключи к внедрению agile на корпоративном уровне вместе с нашими клиентами.