safe less что это

LeSS — Scrum на больших масштабах

LeSS — это Scrum, применяемый к множеству команд, работающих совместно над одним продуктом.

Тема работоспособности и, вообще, возможности применения Agile в больших масштабах не дает покоя отрасли разработки программного обеспечения последний десяток лет. Появилось большое количество подходов таких как Scaled Agile Framework, Disciplined Agile Delivery, Nexus, примитивный Scrum-of-Scrums и т.п. Все они либо сложны, поэтому применение их очень затруднительно и часто не дает ожидаемых результатов, либо настолько просты, что решают лишь частные проблемы в ограниченном количестве кейсов.

Хочется найти какую-то золотую середину, что-то «элегантное», такое же «элегантное», простое и провоцирующее к развитию продукта, процессов и команд, как Scrum.

И вот оно свершилось. Встречайте Large-Scale Scrum, сокращённо LeSS, или по-русски Скрам на больших масштабах. LeSS — это Скрам, применяемый к множеству команд, работающих совместно над одним продуктом.

С этого момента мы начинаем серию статей о подходе Large-Scale Scrum и о том, как он применяется в реальных компаниях. Начнем мы с простого — рассмотрим, из чего состоит LeSS в целом и его особенности.

Коротко о LeSS

LeSS — это Скрам. Скрам на больших масштабах (LeSS, Large-Scale Scrum) — это не новый или улучшенный Скрам. И это не разделение на «Скрам на уровне каждой команды» и «что-то другое на уровне выше». Скорее это о том, как применить принципы, назначение, элементы и элегантность Скрама в контексте большого масштаба настолько просто, насколько это возможно. Так же, как Scrum или любой другой настоящий Agile-фреймворк, LeSS является «минимально достаточным подходом» для максимальной отдачи.

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

В LeSS основная часть команд — это кросс-функциональные, обладающие всеми необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9 нацеленных на обучение участников, выполняющих всю работу (от пользовательских интерфейсов и разработки до снятия продуктовых метрик) для создания полноценного рабочего продукта.

Эти команды работают вместе над одним Бэклогом Продукта, потому что у них есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к поставке продукт, и каждая команда вовлечена в это, потому что она является не компонентной, а продуктовой командой (feature-team), и отвечает за end-to-end продукт, а не только за его отдельную часть.

Что представляет собой продукт в LeSS? Это полноценное (end-to-end), клиенториентированное решение, которое будет использоваться реальными людьми. Понятие продукта в LeSS гораздо шире, чем просто компонент, платформа, слой или библиотека.

LeSS — это не просто процессный фреймворк. LeSS включает в себя:

Скрам на больших масштабах состоит из двух фреймворков:

Обычный LeSS-фреймворк предполагает наличие одного (и только одного) Владельца Продукта, который владеет продуктом, оптимизируя продукт в целом, и управляет одним Бэклогом Продукта, над которым работают команды в рамках общего для всех Спринта. Элементы LeSS-фреймворка практически идентичны элементам Скрам для одной команды, только применяются уже не к одной команде, а к «команде команд».

LeSS Huge

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

В LeSS Huge по-прежнему есть один владелец Продукта, но у него есть команда помощников (Area Product Owners). В LeSS Huge работа над продуктом разделяется по Областям Требований (Requirement Areas). Область требований — это не компонент продукта, а определённая группа end-to-end функционала продукта с точки зрения клиента, то есть каждый элемент Бэклога Области Требований (Area Backlog) несет конечную ценность для клиента. Работа над Requirement Area осуществляется Area Product Owner и от 3-х до 8-ми команд.

Вот в целом как выглядит LeSS, но, конечно же, под капотом много нюансов: как плавно запустить LeSS, какие изменения необходимы в организации, как происходит распределение команд, как плавно перейти к feature-team, как определить, что является продуктом в вашей компании? Об этом всем читайте в наших следующих статьях.

Приходите на наш тренинг

Источник

Сравнение LeSS и SAFe

Nokia использовала фреймворки масштабирования Agile: LeSS и SAFe. Какую проблему они решали и как?

Перевод статьи Ари Тикка и Рана Нюмана LeSS SAFe comparison выполнен с разрешения авторов.

Как Large-Scale Scrum (LeSS), так и Scaled Agile Framework (SAFe) имеют публичные истории применения в компании Nokia. Однако, не многие знают, что Nokia представляла собой две большие слабо связанные компании. LeSS использовался и преимущественно используется в Nokia Networks (сейчас называется так же), в то время как SAFe в основном использовался в подразделениях Nokia Mobile Phones (сейчас по большей части принадлежат Microsoft или закрыты).

Обе части Nokia постепенно начали сталкиваться с одной и той же проблемой, которую позже пытались решить масштабированием Agile: узкоспециализированные подразделения и необходимость координации. Крупные организации по всему миру сталкиваются с этой же проблемой. История Nokia позволяет понять и сравнить, что же эти подходы предлагают.

Наш анализ компании Nokia может показаться грубым, но на это есть причина. Мы хотим ясно донести свою точку зрения. Координационный Хаос — это серьезный и опасный шаблон (прим. пер. — перевод видеоролика). Его реальное влияние будет описано ниже.

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

Авторы участвовали во внедрении и развитии LeSS и SAFe в Nokia Networks, а также работали с SAFe в Nokia Mobile Phones. Основатели компании Gosei (прим. пер. — https://gosei.fi/about) работали со всеми финскими компаниями, которые в числе первых начали пробовать SAFe около пяти лет назад (прим. пер. — 2010 год). Одна из них сейчас (прим. пер. — март 2015 года) массово внедряет SAFe в огромной глобальной продуктовой компании. В прошлом году (прим. пер. — 2014 год) авторы прошли SPC-тренинг по SAFe от Дина Леффингвелла (прим. пер. — Dean Leffingwell, создатель SAFe ), а сейчас сертификационные тренинги по LeSS от База Водда и Крэйга Лармана (прим. пер. — Bas Vodde и Craig Larman, создатели LeSS).

Какую проблему решает «масштабирование Agile»?

В течение долгого времени Nokia росла на 35% каждый год, чем очень сложно управлять. Естественным решением была специализация: компонентные и функциональные команды, специалисты знают, что нужно делать, но решения принимают менеджеры, а команды их исполняют. Так было и в Nokia Networks, и в Nokia Mobile Phones. Обе компании отчаянно возлагали надежды на то, что со всем этим справится программное и проектное управление.

Но со временем становилось только тяжелее. Чем больше организационная структура ориентирована на узкую специализацию, тем больше требуется внешней координации. Этот шаблон Координационного Хаоса (прим. пер. — перевод видеоролика) стал одной из основных причин знаменитой «Горящей Платформы» Nokia Mobile Phones (прим. пер. — «Горящая платформа по имени Nokia» или письмо CEO Nokia).

Скрытая проблема — обучение

При специализации и внешнем контроле инженеров на местах Nokia все меньше нуждалась в обучении большинства из них. Специалисты знали, что нужно делать, а руководители проектов их координировали, что позволило продвинутым рекрутерам легко ориентироваться в таких узких ролях. Эта практика позволила думать, что большее обучение не требуется, и укрепила метафору «организации как машины» в головах руководителей. Подобное мышление руководства оптимизирует ресурсы и издержки, причем локально и краткосрочно. Обучение воспринимается издержками, особенно за рамками своей специализации.

Давайте ограничимся Scrum-командой (команда + владелец продукта + Scrum-мастер). Взаимообучение происходит внутри команды с помощью инспекции и адаптации к рынку. В этом случае обучение создает ценность. Вот, что вам следовало бы масштабировать.

И LeSS, и SAFe базируются на Scrum на уровне команд. Каждый из фреймворков имеет собственный набор бережливых (Lean) и гибких (Agile) практик для поддержки масштабирования. Ключевое отличие в том, как предлагаемые процесс и организационная структура стимулируют обучение, поскольку Организации обучаются подобно лошадям.

SAFe и проблема Nokia Mobile Phones

Новая модель телефона Nokia ориентировалась на ограниченный срок службы, а также были сжатые сроки ее выпуска. Огромный бэклог (план) включал детализированные старые и новые фичи по многочисленным компонентам. Каждый компонент требовал реализации фич по всем частям системы, как например новый целостный дизайн пользовательского интерфейса.

В качестве решения примерно в июне 2009 года в Nokia Mobile Phones было проведено первое внедрение SAFe-процесса c поездами релизов (release train), совместными планированиями и 4-уровневой иерархией в бэклоге продукта. Это была первая версия знаменитой общей картины SAFe (прим. пер. — SAFe big picture), которую снабдили 170 слайдами, кропотливо проработанными Дином и руководством Nokia. С тех пор SAFe вобрал в себя широкий набор Agile-практик и избавился от устаревшего «душка» Nokia. Однако, ключевая ценность все еще представлена в нем явным образом:

Исполнение Программы

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

Ядро SAFe — новый очень детализированный процессный слой поверх Scrum, нацеленный на координацию бардака и обеспечение предсказуемости. Часто новый процесс позволяет отказаться от устаревших глупостей и сделать шаг навстречу Agile-ценностям. Например, запуск всеобщего планирования может придать энергии и улучшить коммуникации. SAFe устраняет проекты и стимулирует контроль незавершенной работы (прим. пер. — Work In Progress).

Авторам трудно вообразить, что старая погрязшая в неприятностях организация смогла бы внедрить SAFe как есть «по книжке». Компетенции людей ограничивают возможности. В большой организации обязательно будут отличия между различными внедрениями SAFe. И со временем порядок вещей в каждой из реализаций процесса SAFe обязательно будет меняться. Это лишь вопрос времени: когда и как долго новый подход все еще будут называть SAFe.

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

Обучение в SAFe

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

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

LeSS в Nokia Networks

Nokia Networks производит невероятно сложные продукты с длительным сроком службы. Для некоторых продуктов требовалось обеспечить 20-летний срок обслуживания. И по-прежнему разработка в основном координировалась внутри программ с тяжеловесными релизами, часто длящимися годами.

Эволюция LeSS не может быть приписана единственной корпорации. LeSS в Nokia Networks начался примерно в 2005 году. Сейчас (прим. пер. — в 2015 году), через приблизительно десять лет, в Nokia Networks продолжают функционировать подразделения калибра LeSS Huge.

Большее через меньшее.

LeSS — фреймворк масштабирования командной работы по Scrum вверх и наружу, без добавления слоев или процессов. Напротив, он радикально упрощает организацию — большее через меньшее. Команда берет на себя заботу о технической координации. Команда владельца продукта работает с рынком и командами. Менеджеры становятся коучами. Никаких вспомогательных слоев не добавляется.

Фича-команда — ключевая концепция в LeSS. Специализация необходима. Она создает ясность и эффективность. Однако, важно, в каком направлении вы развиваете специализацию. LeSS явным образом рекомендует специализироваться в “клиентоцентричности” и продукте, а не компонентах.

Если организация новая и развивающаяся, то LeSS может быть идеальным вариантом, чтобы избежать смертельного штопора.

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

Обучение в LeSS

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

Стратегическое решение

Какой путь выбрать? Решение сильно зависит от того, как лица, принимающие решения, осознают ситуацию в организации.

SAFe предполагает прямое решение через сжигание осознанной проблемы — новый улучшенный программный процесс, объясненный знакомыми терминами. Его проще понять классическому операционному менеджменту. Он расчесывает тот же координационный зуд, что и вся отрасль тяжеловесного проектного и программного управления, но добавляя при этом методы Lean/Agile.

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

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

Далее…

В следующих заметках блога мы более детально исследуем, к примеру, различные варианты масштабирования Scrum, а также сравним организационные слои SAFe и клиенто-ориентированные команды LeSS. Мы опишем: 1) лидерство и власть; 2) организационную структуру и иерархию; 3) поток ценности; 4) обучение, адаптацию и непрерывное улучшение.

А еще проведем сессию по этой теме на XP2015 в Хельсинках!

Источник

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-методологий нет роли менеджера проекта. Увы, но это так.

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

Источник

Переход от Scrum к LeSS и SAFe

Скрам (Scrum) — фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов. Он работает эффективно в рамках одной команды, но при масштабировании могут возникнуть проблемы. Проект слишком большой и у владельца продукта возникают сложности с управлением бэклогом? Над проектом работает много команд и появляются проблемы с интеграцией отдельных решений? Не хватает системности и синхронизации между командами? Тогда вам следует обратить внимание на SAFe или LeSS.

Согласно 13th Annual State of Agile Report от VersionOne, SAFe является самым популярным фреймворком для масштабирования скрама — 30 % компаний используют его. LeSS используется только в 3 % случаев.

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

LeSS (Large-Scale Scrum) в переводе на русский означает «скрам на больших масштабах». Это фреймворк, позволяющий применить принципы скрама в больших проектах. В зависимости от количества команд используется либо LeSS (2–8 команд), либо LeSS Huge (больше 8 команд).

Одним из принципов LeSS является «получать большее за счёт меньшего», что значит не создавать бюрократии и обходиться без лишних ролей, процессов и артефактов.

Организация работы по LeSS

Таблица 1. Отличия LeSS от Scrum

Когда количество команд превышает 8, то требуется дополнительная структура, используется LeSS Huge:

Организация работы по LeSS Huge

Таблица 2. Отличия LeSS Huge от Less

Если LeSS является масштабированной версией Scrum, то SAFe — это комбинация Lean, Agile и DevOps. SAFe расшифровывается как Scaled Agile Framework, или масштабированный гибкий фреймворк. Это открытая база данных, на официальном сайте можно найти подробную информацию по каждому элементу SAFe — по ролям, обязанностям, артефактам и событиям, необходимым для внедрения концепции Lean-Agile в масштабе предприятия.

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

Essential SAFe

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

Portfolio SAFe

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

Large Solution SAFe

Подходит организациям, занимающимся разработкой одного большого, комплексного решения несколькими командами команд. Создаются планы работ на 12–36 месяцев, проводится анализ экономической целесообразности изменений.

Full SAFe

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

Базовая конфигурация состоит из двух уровней — уровня команды и уровня программы. На уровне команды работа осуществляется по Scrum, Kanban, XP.

На уровне программы вводятся новые роли.

Таблица 3. Роли SAFe на уровне программы

Отвечает за координацию и организацию процесса работы не отдельной команды, а программыART (Agile Release Train)Команда команд (50–125 человек), которая постепенно разрабатывает и поставляет решения в потоке ценностиSystem Architect / EngineerЧеловек, отвечающий за общее техническое и архитектурное видение разработки продукта. Нет аналога, так как в скраме сама команда отвечает за архитектуру

Используется много терминологии, связанной с поездами: ART (Agile Release Train), RTE (Release Train Engineer). Это связано с тем, что работа команд в какой-то мере похожа на работу поезда — имеется стабильное расписание. Если вы не успеваете на один поезд, то всегда можно сесть на следующий. Если в текущий инкремент не получается уместить какие-то цели, то их можно поместить в следующий.

Организация работы на уровне программы в SAFe напоминает организацию работы по скраму, только в более крупном масштабе, с планированием на более долгий период.

Таблица 4. Сравнение этапов работы в Scrum и SAFe на уровне программы

События SAFe Essential

Заключение

В статье были рассмотрены основные отличия LeSS и SAFe от скрама. У каждого фреймворка свои особенности.

LeSS более простой и понятный. Не требует таких сильных изменений, как SAFe.

SAFe предлагает более комплексный подход. Появляются дополнительные роли, артефакты и события. Введение требует больше ресурсов.

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

Источник