JS Fest 2019: Опыт спикеров из 15+ стран. Смотри доклады на сайте >>
×Закрыть

Безопасный путь. Что такое SAFe и как его внедрить

Всем привет, я — Виталий Бараш, Project Manager и Agilist до мозга костей в Luxoft. А конкретнее — в Excelian Financial Services.

За годы в роли менеджера я повидал много разных шлюпок, капитанов, матросов, весел. Роль менеджера — это достигнуть максимума при заданных ограничениях. Максимума в чем? В ожиданиях всех стейкхолдеров: команды сервисной компании, команды заказчика, самого заказчика, конечного пользователя, непосредственного руководства и т.д. Ограничения — зарплаты, домены, технологический стэк, рынок труда в локациях, межкультурные особенности, регуляторы и прочее. Хочется, чтобы все это заработало вместе — как одно целое. Для этого существует много подходов, техник, методологий, фреймворков, whatever.

Сегодня мы пойдем безопасным путем — путем SAFe. Я попытаюсь на пальцах объяснить фундамент, на котором строится этот фреймворк. Перед началом добавлю, что меня радует интерес к этой теме украинской аудитории. Чуть раньше мой тренер по SAFe Елена Лубчак уже успела опубликовать выжимку по SAFe Essentials. Эта статья будет о другом — о том, на чем всё это держится, и как мы начали внедрение этого фреймворка у себя.

Эффективность и использование

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

Бесплатная и исчерпывающая вики

По ссылке вы можете найти всё необходимое для работы с SAFe: блоги, форумы, статьи, энциклопедию, словарь, кейсы и т.д. Именно там стоит искать ответ, как лучше провести трансформацию бизнеса, продукта, проекта. Невзирая на возможный скепсис, для вас нет лучшего инструмента и союзника, чем наличие такого бесплатного образовательного портала или вики для ваших коллег. Хорошая база, чтобы быть on the same page — понимание того, что мы делаем, и что «same» значит одно и тоже для вас и коллег.

Кейсы успешных трансформаций в разных доменах

ОК, вики, энциклопедия и вдохновение — это хорошо. А это вообще хотя бы один раз заработало? Да, много больших организаций уже работают, применяя SAFe, а некоторые — в процессе трансформации. Множество кейсов доступно для ознакомления на все том же портале. Там вы увидите таких лидеров, как Nordea, Capital One, Deutsche Bank, Standard Bank, Westpac в финансовом мире, а также Sony, Intel, Dell, Motorola, McAfee и других с разных доменов.

Roadmap по проведению трансформации

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

У SAFe есть понятная Roadmap, которой рекомендуется придерживаться для успешного старта и окончания трансформации как таковой. Нет серебряной пули, как говорил Фредерик Брукс, но это уже что-то для начала, верно?

Обучение и сертификаты

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

И да, согласно 12-му ежегодному отчету от Version One, SAFe является наиболее популярным фреймворком для масштабирования. +100 к уверенности ☺

Конфигурации

«Чистая» реализация по книге встречается очень редко, и на практике мы видим некие комбинации из Scrum + Kanban (Scrumban), где-то RUP + ATDD, или даже Crystal Clear + SAFe и другие. Тем не менее SAFe попытался максимально продумать «уникальности», с которыми могут столкнуться агенты трансформации. Как результат, SAFe декларирует приведенные ниже конфигурации.

Essential

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

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

Другими словами: организации, которые работают исключительно над одним продуктом средней или высокой сложности.

Portfolio

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

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

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

Large Solution

Эта конфигурация предназначена для разработки больших и сложнейших решений, которые разрабатываются несколькими ART (Agile Release Train) с возможным привлечением вендоров, но при этом нет необходимости в управлении портфелем.

Масштаб: подходит организациям, которые работают над одним комплексным и сложным решением и делают ставку только на это решение. Вовлекают в процесс более 150 человек. Например, создание нового космолета однозначно требует разработки software (SW), hardware (HW), firmware (FW) и других вещей, при том, что над каждой может работать до или более 150 человек одновременно.

Другими словами: организации, которые занимаются исключительно одним, но комплексным и сложным решением (как следствие, нет нужды в управлении портфелем).

Full

Это наиболее исчерпывающая конфигурация фреймворка. Предназначена для поддержки организаций, которые разрабатывают несколько комплексных и сложных решений одновременно, где вовлекаются все уровни SAFe: team, program, large solution и portfolio. В такого рода организациях могут быть реализованными несколько различных конфигураций SAFe.

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

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

Итого

У нас есть 4 конфигурации для поддержки любого рода организаций: от одного продукта средней-высокой сложности до нескольких комплексных и сложных решений одновременно. Сам же SAFe при этом достаточно обширный и основывается на принципах Lean и Agile. А что же лежит в основе SAFe?

Фундамент SAFe

Давайте начнем с базовых вещей, а именно с ценностей и принципов.

Ценности

Внедрить Scrum на уровне команд — задача порой не из простых. Можете представить, что такое провести трансформацию организации?

Схемы выглядят довольно сложно, но это работает. Трансформируясь по SAFe, необходимо разделять его ценности.

Alignment

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

Звучит знакомо? Я не раз наблюдал нехватку коммуникации — в одной команде, между несколькими командами, организациями, поставщиками и третьими сторонами. И если мы все же планируем проводить трансформацию, необходимо убедиться, что коммуникацией легко управлять, и она достаточно быстрая и простая, иначе мы потеряем много денег. 1 день 150 высококвалифицированных профессионалов делали неправильные вещи. Стало грустно уже от самой фразы ☺

Build-in Quality

SAFe утверждает: «You can’t scale crappy code». Я добавлю — «You can’t scale crappy agility». Те же 150 высококвалифицированных профессионалов потратили на сомнительную архитектуру 2 месяца. Результат тот же, только масштаб больше. В конечном итоге мы просто избавимся от наработок и начнем с начала. Мы не можем позволить себе сомнительный дизайн и архитектуру, когда через несколько месяцев мы увидим, что наше решение уже неподдерживаемое. Время прошло, деньги потрачены, продукт... продукт, возможно, закрыт.

Кроме того, что мы не хотим, чтобы это случилось, нам еще бы и сохранить необходимые гибкость и маневренность при разработке, которая ведет к техническому долгу. Основная цель этой ценности — это сохранить вариационность. Это позволит быстро расширять архитектуру, чтобы можно было удовлетворить бизнес-потребности. Нужно продолжать «улучшаться» при помощи реализации PoC, поддерживать уровень технологической инновационности, научиться предугадывать развитие продукта и формировать для этого фундамент как можно ранее. Не может быть никакой неточности и неопределенности в ценности built-in-quality для больших решений. Это просто must have.

Transparency

Никто не может пофиксить тайну. Да и мы не читаем мысли. Разработка решений сложна, иногда даже болезненна. Увы, чтобы таки достигнуть успеха, мы не можем делать всё самостоятельно (да-да, хочешь что-то сделать, сделай это сам). Как следствие, мы должны в значительной мере положиться на коллег, отделы, подразделения и при этом работать как одно целое с предсказуемым результатом. Механизм не будет работать без доверия, где прозрачность — это всего лишь рычаг включения доверия. Каждый знает, что он делает, почему мы это делаем сейчас, когда ожидать конечного результата, что мы будем делать дальше, какая у нас пропускная способность и многое другое. Процессы должны быть прозрачными для каждой из команд: разработка, операционка, бизнес, аккаунт, отдел продаж и других.

Program execution

Выполнение — это ключевая составляющая. Если мы не можем, как говорится, «заделиверить» бизнес-ценность, то ничто другое не имеет значения. Это касается не только уровня команд. Все мы знаем, чтобы успешно провести гибкую трансформацию, её должен поддержать топ-менеджмент. В противном случае, максимум, чего мы достигнем — гибкий пузырь, в котором будут жить команды, тогда как весь остальной мир будет продолжать работать по устоявшимся подходам. Просто показуха, при которой теряются все остальные плюшки. Лидеры Lean-Agile поддерживают команды и выступают гарантами соблюдения принципов Lean-Agile каждой из команд.

Принципы SAFe

Перейдем к «безопасным» принципам.

Всегда держать в голове экономическую составляющую (Take an economic view).

Наиболее распространенная причина неудач продуктов связана именно с деньгами. Да и речь вовсе не об инвестициях, а об их окупаемости. Сам же принцип состоит из двух составляющих:

  • Деливерить как можно раньше и чаще (Deliver Early and Often). Достаточно очевидная (привет, айджалисты!) вещь для нас. «Водопады» против гибких подходов — просто оставлю картинку.

  • Понимать экономические компромиссные параметры (Understand Economic Trade-off parameters). Выделю 5 таковых: время цикла (и вот тот же Kanban со своим lead time), костовая составляющая продукта, траты на разработку, ценность и, конечно же, риски. Успех или провал решений и будет определяться эффективностью управления этими параметрами.

Системное мышление (Apply system thinking).

«Моя хата скраю — нічого не знаю» ☺ К сожалению, люди стремятся изолировать себя от всего вокруг, чтобы упростить существование. Программисты, ООП, абстракции.... Берем самое важное и про остальное не думаем. При создании больших решений это приведет к тому, что мы не сможем заинтегрироваться в конце и получим полуживое решение. Потому используем этот принцип — фиксируем картину в целом, а не частично. Вовлекаем все касты при планерке. Рисуем зависимости на Program Board.

Предполагаем вариационность, сохраняем опции (Assume variability, preserve options).

Этот принцип про наличие плана Б. Всегда и в любой ситуации. И чем больше таких планов мы имеем про запас, тем выше наши шансы на успех. Мы очень часто ограничиваемся вначале только одним целевым решением и на более поздних фазах запугиваем команду продукта фразами: «Нужно переписать всё приложение», «Это потом в фазе тестирования просидит вечность» и другими. С другой же стороны, излишняя вариационность очень усложняет и так достаточно сложный продукт и может привести к негативным эффектам. Потому держим баланс и помним про set-based design.

Разрабатываем инкрементально с быстрыми циклами обучения и интеграции (Build incrementally with fast, integrated learning cycle).

«Plan-Do-Check-Act», — говорят нам agilist’ы. И правильно делают. Про цикл Деминга знают многие, кто посещал тренинги по гибкостям, кто читал TPS (!=PMS), кто применяет SCRUM или что-то SCRUM-подобное. Чем чаще циклы, тем быстрее мы получаем фидбэк и обучаемся, а конечная наша цель — в каждой итерации получить рабочую систему кросс-модулей и компонентов, а также синтегрированные при необходимости soft и hardware-ные части.

Основывать майлстоны на объективных оценках работающих систем (Base milestones on objective evaluation of working systems).

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

Визуализация и лимитирование WIP, сокращение размера пакетов и управление длиной очередей (Visualize and limit WIP (work-in-progress), reduce batch sizes, and manage queue lengths).

«You can’t manage what you don’t measure», — причитает нам Питер Друкер. WIP, размеры пакетов, длина очередей — это только некоторые вещи, за которыми необходимо следить, чтобы повысить наши шансы на успех и убедиться, что наш роадмэп вообще выполним. Как много всего мы можем сделать через 1-2 дня, 3 недели, месяц? Когда какие задачи будут выполнены, в какой итерации? Когда мы должны сделать запуск, чтобы сократить наши издержки на это упражнение? Увы, но подобные вопросы должны преследовать нас всегда.

Соблюдение каденции, синхронизация с кросс-доменным планированием (Apply cadence, synchronize with cross-domain planning).

Представим роту солдат, около 150 человек. Как выглядит в их случае строевой шаг? Все солдаты соблюдают синхронность шагов. Аналогично и тут — около 150 разработчиков, которые движутся командами итерационно и синхронно (2 недели — один шаг). Наша задача заключается в выборе этой каденции и её следовании кросс-командно. Это «must have» для частых интеграционных циклов. В противном случае — не видать нам интеграции и рабочего продукта в конце.

Раскрыть внутреннюю мотивацию сотрудников (Unlock the intrinsic motivation of knowledge workers).

Autonomy, Purpose и Mastery — те самые «золотые ключи» к мотивации сотрудников, как утверждает Дэниел Пинк. Сможем раскрыть потенциал наших команд, как только набьем руку в правильном подходе к творческим людям: убрать микроменеджмент и предоставить необходимую автономность, дать возможность развиваться и развивать других, а также показывать, как их работа влияет на общий результат.

Децентрализованное принятие решений (Decentralized decision-making).
Как же уменьшить время цикла? Один из вариантов — делегировать принятие решений. Конечно же, мы не можем делегировать все решения — мы должны держать при себе стратегические вопросы, а остальное — забота наших коллег. Это еще и поможет открыть внутреннюю мотивацию сотрудников, а также увеличит их вовлеченность. Если у вас не практикуется делегирование, то для начала такую культуру вам необходимо внедрить. С этим вам может помочь «Delegation Poker & Management 3.0» авторства Jurgen Appelo.

Как мы начали внедрение

Большинство прочитавших подумают: «Какие красивые слова... Вот только на практике всё иначе». Отчасти согласен, все «уникальны» по-своему. Немного расскажу о том, как мы стартовали SAFe-трансформацию. Оговорюсь сразу, что это тот самый кейс, когда «пролетариат» инициировал трансформацию снизу.

Сама идея зародилась давно, а мы как консалтинг-структура эту возможность упустить просто не могли. Чистое деливери хорошо, но никто не отменял added value. Начали подготавливать почву для нашего консервативного клиента, где практически все проекты ведутся итеративно (изначально Waterfall). Это значит четко выделенные стадии, меняющийся скоуп по ходу релиза («это впихнем, но вот это тоже пока оставь.... вдруг проскочит»), периодические демо, длительность релизов зависит от требований для имплементации (от 2 недель до квартала). И не каскадная модель, но и не SCRUM или Kanban. Вроде, все работает, да вот только:

  • Change Management занимает много времени у лидеров;
  • много команд, которые живут своей жизнью, а зависимости между командами довольно сильные;
  • lead time задач достаточно высокий из-за отсутствия автоматизации как таковой (быстро выкатить значимое value на рынок затруднительно).

Начали делать обоснование, исходя из вышесказанного. Переводили слова в доллары:

  • CoD (cost of delay) нового функционала;
  • стоимость выкатки релизов;
  • стоимость фикса багов, связанных с неразрешенными зависимостями между командами;
  • количество героев-часов (это число часов, которые люди проводили в режиме овертаймов, авралов и т.д.).

Были и другие, но эти статьи — самые затратные. «Сейчас мы точно начнем трансформацию», — думал я. Однако, после представления этих данных клиенту, люди не прониклись и ничего не сдвинулось с места, а при малейших попытках продвинуть обсуждение дальше, можно было услышать: «У нас сейчас очень важные релизы идут. Мы не можем начать это делать прямо сейчас». Разумеется, с течением времени релизы всё ещё оставались важными ☺

Если гора не идет к Магомету, то Магомет идет к горе. Во время командировки в Нью-Йорк мы с командой решили действовать проактивно и провели обучение и тренинги для разных уровней: директора, тимлиды, разработчики, продактовики. Побывали мы с аналогичной программой и в Индии, охватив там широкую аудиторию специалистов. Работа была проделана, да вот результатов было немного и ничего не завелось.

Пока мы обдумывали как быть дальше, сарафанное радио таки запустилось, добралось до менеджмента. Через некоторое время нас пригласили в одну инициативу для старта трансформации как консультантов, предложив примерить роли RTE (Release Train Engineer). Здесь трансформация и берет свое начало.

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

На сегодня начало переходу на SAFe положено. У нас уже:

  • успешно стартовал Architectural Runway вместе с CTO и другими техническими специалистами;
  • команда продукта начинает внедрять WSJF для приоритезации;
  • команды начали реализовывать SCRUM Framework с двухнедельными спринтами и классическим набором встреч;
  • для старта использовали двухуровневое планирование и уже начали отказываться от валидации capacity, т.к. velocity команд выровнялось;
  • команды определили DoD и стандарты качества, основываясь на SonarQube, Burp Suite и Veracode.

Сейчас новые команды еще формируются, и мы стремимся к идеальному PI Planning’у, но System Demos уже проводим успешно.
Для лучшего визуального восприятия, как некий бонус для тех, кто дочитал до этого места, поделюсь одной из презентаций по фреймворку.

Выводы

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

В этой статье мы рассмотрели, на чем же базируется SAFe:

  • 4 конфигурации, которые рассчитаны для различных организаций;
  • 4 ценности (alignment, built-in-quality, transparency, program execution), на которых построена культура (Culture eats strategy on the breakfast — Drucker);
  • 9 принципов, которыми мы оперируем при принятии решений каждый день.

Фактически мы посмотрели на план внедрения, рекомендованный SAFe, из которого видно, что мы начинаем с обучения коллег. Если кто не читал Management 3.0 от Jurgen Apello , крайне рекомендую. Книга рассказывает о подходах к управлению и связанных с ними особенностях: от примитивных конвейеров до современных технологических предприятий. В ней автор приводит 3 версии менеджмента:

  • 1.0 — Doing wrong things;
  • 2.0 — Doing the right things wrong;
  • 3.0 — Doing the right things right.

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

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

Я собираюсь больше фокусироваться на точечных моментах реализации SAFe: экономических обоснованиях, роли DevOps, Built-in-Quality практиках и других топиках. И, разумеется, рассказать, как проходит трансформация в личном кейсе.

LinkedIn

26 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Фаулер рекомендует и я с ним согласен:
www.thoughtworks.com/radar/techniques/safe
Имел опыт на одном большом аккаунте, сама процедура релиз треина забавна и задорна, но в реальности планы ВСЕГДА менялись через некоторое время в итоге решили перейти на более гибкий подход и это работало лучше

А на что перешли? Scrum of Scrums или ещё что-то?

Мне кажется SAF нужен менеджерам. На уровне девелоперов («снизу») переход на SAF мало что меняет кроме появления PI. Конечно круто что вы снизу продавили SAF, но это похоже на эксперимент чем на необходимость. В моей компании SAF вводили сверху.

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

SAFe отличный фреймворк, вот только буква «А» в нем лишняя.

1. Как сказал Дейв Томас в его Agile is dead, не может быть agile разработки в не-agile среде. Даже очень эджайл команда, будучи зажатой между строгими (хоть и редко когда эффективными) правилами по безопасности, методологией разработки (которую навязали, конечно, сверху), технологическим стэком, забюрократизированным отделом закупок, внутренними правилами и прочими рамками, быстро превращается в неповоротливого и неэффективного увальня. Если говорить откровенно, SAFe это просто система правил по вписыванию разработки по условно-эджайл фреймворку в традиционную бюрократическую организацию. Не больше и не меньше.

2. Еще одно несомненное «преимущество» SAFe — это удлиннение водопадного цикла. Если в скраме «каскад водопада» 1-4 недели, то в SAFe с его PI planning он уже составляет 3-4 месяца. Безусловный эчивмент в глазах менеджмента, который хочет сидеть на старом стуле изо всех сил делая вид, что следует современным трендам.

аджайл менеджеры совсем е$%бу дались, по теме — все что не умещается на две три страницы с несколькими простыми схемами не взлетит

не взлетит

ну это жы ж классика жы ж ))

youtu.be/3S9GBi9PCfg

1) «Не забывайте, что без поддержки топов, никакой трансформации не будет». Удачи Вам с этим в Luxoft.
2) «4 конфигурации, 4 ценности, 9 принципов» — да прибудет с Вами Bandersnatch
3) Серебряной пули нет, как и волшебной пилюли

Some time ago we’ve introduced this and shortly after that abandoned. One of the problems is that PI is long and during PI a lot of things can go wrong. Thus, PI planning is basically in vain. That’s far from agile.

Andrii, PI Planning is really the masterpiece in SAFe.

Do you consider it as long one? Let’s assume we have usual 5 sprints with usual cadence of 2 weeks within Program Increment (PIs). PI Planning is 2-day long event. Hence, each team spends 2 days to plan their work for the next 10 weeks (~2.5 months). Comparing it to Sprint Planning of SCRUM that says 1 day for 1 month, it is relatively less time-consuming.

Regarding “a lot of things can go wrong”. Definitely, especially if teams are not educated well and key participants are not confident in the procedure. However, it can get mitigated with training courses and involvement of professional SAFe consultants.

I am keen on getting more details of your case :)

There is no magic in SAFe . . . except maybe for PI Planning. — Authors

Hi Vitalii,

I did not mean the overall time spent on meetings.

10 weeks is long. Planning for 10 weeks ahead is not really effective. Because over those 10 weeks a lot of things can change or go totally wrong (requirements, software, people, business needs, etc.). In this regard I agree with Robert Martin in his videos cleancoders.com/...​lean-code&subseries=agile

In our case PI plannings did not work out as expected because there were many teams in different countries working on the same project and many things were changing basically on a daily basis. It’s really hard to predict the next 10 weeks in such a project.

Finally, I’m not a SAFe expert and maybe it works well in certain circumstances. Just sharing my experience...

Основополагающие принципы Agile-манифеста
...
10. Простота — искусство минимизации лишней работы — крайне необходима.
:)

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

Полностью согласен, Женя!
Достаточно раз пройтись по картинке и начинаешь понимать, что она очень логичная :) Однако, ньюансы есть и их нужно разобрать ;)

Да, пугает только то, что пушить её надо именно сверху вниз :) Ну, кому надо, те смогут это сделать. Спасибо за статью!

на первый взгляд SAFe кажется именно тем, чем является — извращение самой сути Agile/Scrum, возведенное в степень.
Вместо гибкой методологии, представляющей собой набор инструментов для решения четко определенных проблем разработки (вам не нужны все, но вы должны понимать границы применимости каждого и зависимости между ними) — получаем максимально жестко забюрократизированный фреймворк для проведения многодневных тренингов и дорогих сертификаций.
Который в комбинации с «евангелистами» превращается в «ритуалы важнее результата» и «термины важнее здравого смысла»

Это схемы по созданию атомного оружия?

И как результаты?
Скорость выкатки нового релиза увеличилась?
Стоимость уменшилась?
Люди перестали овертаймить?

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

Особых требований к Scrum Master SAFe не выдвигает на уровне команды. На этом уровне у нас самый что нинаесть SCRUM или Kanban или другой гибкий подход для работы с командой.
Однако, SAFe вводит роль RTE (Release Train Engineer), который aka Scrum Master of Scrum Masters и еще общается с архитектором и продакт-менеджментом продуктаю.

Краткий ответ: SAFe на уровне команд не выдвигает особых требований к Scrum Master отличных от классичего SCRUM. RTE же общается со скрам мастерами, архитектором и продакт-менеджментом. Как следствие, технические навыки очень сильно ему помогут в обсуждениях :)

Т.е. если он случайно оказался не технический, то будет страдать каждый день на всех митингах/обсуждениях, не понимаю о чем вообще речь, как было(и до сих пор есть) на одном из проваливающихся проектов где работал...

Технические навыки помогут, но не являются «must have». Если проект проваливается, то он проваливается в большинстве из-за менеджера как такового, а не из-за наличия/отсутствия технического бэкграунда. Ну и, собственно, если менеджер страдает каждый день на митингах, то хочется спросить, что же с ним не так :D

Глянул на схемы — это жесть

Подписаться на комментарии