Всем привет! Меня зовут Анфиса Лаврова, я старший инженер по автоматизации тестирования, а также тимлид проектной команды разработки компании «Синимекс». Помимо этого, я сертифицированный Scrum-мастер и специалист по Agile. В данной статье расскажу о фреймворке SAFe и поделюсь опытом его внедрения на крупном проекте. Этот материал будет полезен тем, кто интересуется гибкими методологиями и их применением в больших масштабах.

Уровни SAFe: командный, программный, портфельный

SAFe представляет собой набор шаблонов и практик для проектирования процессов, включая встречи, роли и распределение ответственности с чёткой структурой проведения. Его ключевое преимущество — гибкое масштабирование для команд и проектов большого масштаба. Фреймворк структурирует процессы на три уровня:

• командный (внутри одной команды), 

• программный (координация сквозных потоков), 

• портфельный (управление проектами компании).

Основная цель — повышение скорости команд и качества продукта через выравнивание стратегических целей с тактическими задачами.

Критерии оценки масштаба проекта

При оценке масштаба проекта нужно ориентироваться на три критерия:

• численность вовлечённых сотрудников, 

• объём кодовой базы, 

• объём финансирования.

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

Ключевая особенность крупных инициатив — необходимость координации распределённых команд с пересекающимися зонами ответственности, что требует внедрения прозрачных практик синхронизации.

Команды часто разделяются по функциональному (backend, frontend) или системному принципу (авторизация, телефония). В Agile оптимальный размер команды — 3-9 человек, включая Scrum-мастера и консультантов.

Важно! Забегая вперед скажу, что если команда превышает этот размер, возникают сложности с коммуникацией и координацией. Это особенно актуально для распределённых команд, где сотрудники могут работать part-time или full-time.

Проблема: Встречи и митинги затягиваются из-за большого количества участников, что снижает их эффективность.

Решение: Мы начали искать баланс между сокращением времени проведения встреч и уменьшением числа участников. Для этого мы внедрили асинхронные форматы обсуждения и ограничили количество участников на ключевых встречах, оставляя только тех, кто непосредственно вовлечён в текущие задачи. Это позволило сократить время встреч и повысить их продуктивность.

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

Опыт внедрения SAFe на проекте: брокер сообщений

Наш продукт — это брокер сообщений и средство его администрирования. У продукта много пользователей, некоторые из них отправляют сообщения в разных неподдерживаемых брокером форматах. Это создало необходимость разработки адаптера для обработки форматов входящих и исходящих сообщений (см. рисунок 1).

Структура команд и их взаимодействие

В рамках проекта у нас две основные команды (см. рисунок 1):

1. Команда брокера — занимается разработкой бэкенда и базы данных. Это самая крупная команда, в которой работает более 10 специалистов.

2. Команда веб-приложения — отвечает за полный цикл разработки приложения, включая бэкенд и фронтенд.

Кроме того, мы зависим от команды адаптера, которая занимается обработкой входящих и исходящих сообщений в нестандартных для системы форматах.

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

Проблемы, которые мы решаем применением SAFe

Проблемы согласованности и управление зависимостями

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

Для работы с данной проблемой мы предлагаем использовать методологию SAFe, которая предусматривает классификацию задач с точки зрения рисков. Все задачи анализируются на предмет межкомандных зависимостей, которые могут нести угрозу, после чего в спринт включается только 10-20% таких «рисковых» задач. Однако этот подход оказался недостаточно эффективным: ограничение количества задач привело к увеличению сроков и простоям в работе команд. Под «простоем» подразумевается выполнение задач с низкой ценностью для конечного потребителя — например, изменение цветового дизайна некоторых форм приложения вместо решения ключевых задач.

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

Принцип SAFe: системное мышление и контрольные точки

Мы столкнулись с ситуацией, которая заставила пересмотреть подход к управлению зависимостями между командами. Заказчик запросил добавление нового параметра в сообщение, что требовало взаимодействия команд брокера данных и адаптера. Команда брокера отвечала за модификацию схемы сообщения, расширение БД и обновление методов сохранения данных. Команда адаптера должна была приступить к своей части работы только после завершения задач на стороне брокера, хотя, по сути, ей требовался лишь готовый формат сообщения для интеграции (см. Рисунок 2). Изначальное требование полного завершения всех задач брокером создавало ложную зависимость — адаптеру были не нужны работа с базой данных или проверка сохранения информации.

Решение пришло через переосмысление принципа SAFe: вместо оценки готовности по количеству выполненных задач и подзадач мы начали определять контрольные точки через призму потребностей «внутреннего потребителя».

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

Результат: такой подход сократил простои и ускорил доставку, хотя для конечного пользователя критично наличие всех компонентов решения — формата сообщения, обновлённой БД и методов работы с данными. Таким образом, если раньше релиз считался готовым только после выполнения всех трёх задач брокера, то теперь мы разделяем понятия «готово для команды» и «готово для пользователя».

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

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

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

Проблемы тестирования и роль программного QA-специалиста

Рассмотрим типичный сценарий: реализация новой функциональности упирается в ограничения тестовой инфраструктуры.

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

Проблема возникает при согласовании приоритетов. Когда каждая из всех команд помечает свои запросы как «критически важные», в очереди на обработку скапливаются десятки задач с одинаковым формальным приоритетом (Рисунок 5). Это приводит к ситуации: технически простая функция может спринтами ждать тестирования из-за зависимости от доработки инфраструктуры.

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

1. влияние изменения на всю экосистему продуктов,

2. экономический эффект от внедрения,

3. синергию с другими запланированными улучшениями.

Такой подход исключает субъективность оценок. Например, доработка для работы с Kafka получила повышенный приоритет, потому что именно комитет изучил совокупность зависимых задач и планы других проектов, а не, например, потому что этого очень сильно захотелось руководителю проекта.

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

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

Рассмотрим пример (рис. 3). В нашей системе есть три основных компонента: брокер, веб-приложение и адаптер. Брокер и Адаптер мы тестируем на Java, потому с интеграционными тестами для них проблем не возникает.

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

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

Здесь также действует уже знакомый нам принцип — применение системного мышления. Это подразумевает понимание работы системы в целом и взаимосвязей между её компонентами. Например, мы используем smoke-тесты и регрессионное тестирование веб-приложения, проверяя доступность endpoints и корректность ответов. Однако в одном из случаев это не предотвратило проблему: при изменении типа данных параметра запрос возвращал статус-код 200 и непустой ответ, но в ответе отображались некорректные символы. Более детальные тесты нашли бы эту проблему, но из-за неверного анализа влияния было решено не запускать полноценный регресс веб-приложения, ведь оно не менялось.

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

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

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

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

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

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

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

Системный подход к тестированию в масштабируемых проектах

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

Программный QA-специалист координирует взаимодействие между командами для достижения согласованности и повышения качества.

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

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

Таким образом, программный QA-специалист взаимодействует со всеми командами, анализирует зависимости между ними и контролирует их согласованность, что позволяет комплексно оценивать работу системы. На основе этих данных он помогает разрабатывать сценарии тестирования для команды A с учётом потребностей команды B, что сокращает время на проверки. Например, фокус делается только на критичные кейсы, которые непосредственно влияют на работу других команд или конечных пользователей, что снижает количество багов.

Для выявления не только текущих, но и будущих зависимостей программный QA-специалист требует (увы, не всегда успешно) доступа к ресурсам всех команд: бэклогам, доскам задач и текущим мероприятиям. Это позволяет отслеживать не только актуальные, но и будущие зависимости. Удобно использовать общую доску с базовым описанием задач, которая будет служить инструментом визуализации зависимостей и синхронизации информации между участниками.

Внедрение SAFe: стоит ли?

Это подводит нас к вопросу: стоить ли внедрять SAFe? Наш опыт показал, что даже частичная реализация методологии на программном уровне (без охвата портфеля проектов) дала положительные результаты. Однако однозначного ответа нет — решение зависит от контекста. SAFe предназначена для масштабирования Agile в крупных проектах: минимальное количество участников проекта должно превышать 50 человек. В идеале, 10 команд по 50 человек — там методология проявляет себя наилучшим образом.

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

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

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

При внедрении программного QA-специалиста важно учитывать, что времени на другие привычные задачи (например, тестирование) у него будет меньше. Следовательно, может потребоваться временное привлечение дополнительных ресурсов, что повлечет дополнительные расходы. Поэтому бюджет должен быть заложен с учетом этих факторов.

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

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

Заключение: уроки и рекомендации

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

Критерии успеха:

1. грамотное управление рисками,

2. экономическая оправданность,

3. готовность принять возможные неудачи.

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

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

Благодарю за внимание.