Непрерывное изучение в SAFe®
Дата: 31.01.2025

Непрерывное изучение в SAFe® (Scaled Agile Framework®) – это часть конвейера непрерывной поставки, которая продвигает инновации и обеспечивает согласованность того, что должно быть доставлено, за счет постоянного изучения рынка и потребностей клиентов, определения видения, дорожной карты и набора фич для создания решения.
Содержание
Стоит потратить время и силы на выработку, своего рода, «взгляда на свою компанию снаружи». Такой взгляд в состоянии уравновесить подход, когда в центре мироздания ставится не рынок, а ваша компания и то, как в ней делаются дела, что и отражено в ее прошлогоднем плане.
Джеффри Мур, Вторая космическая: Искусство управления и стратегии будущего
На этапе CE работа возникает за счет новых идей. Они уточняются и организуются в виде списка приоритизированных Фич в Бэклоге ART. Agile-команды реализуют Фичи, приоритизированные Продуктовым Менеджментом во время PI-планирования, что запускает процесс CI. После этого CD-цикл переносит их на промышленное окружение, где они проверяются и подготавливаются к релизу.
Agile-поставка Продуктов является одной из семи ключевых компетенций SAFe. Это позволяет организации поставлять конечным пользователям Решение с высокой ценностью с оптимальной частотой. CE является неотъемлемой частью этого процесса и фокусируется на применении Клиентоориентированности и Дизайн-мышления, чтобы осознать и согласовать идеи для создания новых возможностей. При этом понятно, что все подобные идеи являются гипотезами, которые нуждаются в проверке.
CE заменяет традиционный «водопадный» подход, когда все требования определяются на старте. Вместо этого процесс генерирует в Бэклоге ART непрерывный целостный поток Фич, готовых к реализации. Разбиение Фич на небольшие по размеру Истории позволяет быстро продвигать работу по оставшимся этапам CDP до Клиента. Получение быстрой обратной связи встроено в процесс, что позволяет командам адаптировать разработку к потребностям рынка. Смотрите статью «Поток ART» для получения дополнительной информации о том, как создать поток ценности без прерываний (Принцип №6 – Создавайте поток ценности без прерываний).
Клиенты, Поставщики, партнеры, Представители Бизнеса, Agile-команды, Владельцы Продуктов и Lean-управление Портфелем входят в число внутренних и внешних заинтересованных лиц, вовлеченных в этот процесс. Их участие может быть косвенным, например, посредством вторичного исследования потребностей рынка. Или оно может быть прямым, например, когда Agile-команды участвуют в Итерации Инноваций и Планирования. Процесс CE позволяет организации согласовать совокупность Фич в бэклоге и прогнозируемую Дорожную Карту с общей Концепцией организации.
Четыре активности непрерывного изучения
Создание гипотезы
На этапе создания гипотезы используются практики для генерации идей и измерения, необходимые для их проверки их с Клиентами. Основная цель этого этапа – сформулировать гипотезу для Решения, которая будет подтверждена или опровергнута командами после прохождения всего Конвейера Непрерывной Поставки.
У Продуктового Менеджмента есть представления о потребностях клиентов, основанные на их понимании рынка, Стратегических Темах, Концепции и Дорожной Карте. Однако, эти идеи не следует считать фактами. Команды должны рассматривать их как гипотезу, которая требует проверки и подтверждения. Практики, связанные с разработкой на основе гипотез, включают в себя:
- Мышление бережливого стартапа (Lean Startup) – определение Фич, минимально пригодных для продажи (MMF, Minimum Marketable Feature) и минимально жизнеспособных продуктов (MVP, Minimum Viable Product) помогает быстро проверить гипотезы с минимальными инвестициями. MMF и MVP представляют собой наименьший объем полезной функциональности для первых клиентов, которые могут предоставить обратную связь для будущей разработки продукта.
- Учет инноваций – проверка гипотез для нового продукта или Фичи требует иного подхода, чем оценка существующих решений. Это требует от нас рассмотрения двух вопросов: 1) Продвигаемся ли мы к нашей гипотезе о конечном результате? 2) Как мы это можем понять? Учет инноваций использует метрики для определения действий, способствующих достижению бизнес-целей (опережающие показатели). Такие метрики позволяют определить первые результаты, что является базисом для прогнозирования будущих бизнес-результатов. Опережающие показатели отвечают на упомянутые два вопроса и улучшают экономические решения на этапе разработки начального Решения и оценки MMF или MVP.
Сотрудничество и исследования
Создание убедительной и дифференцированной концепции требует от Продуктового Менеджмента организации непрерывного процесса сотрудничества различных заинтересованных лиц, вносящих свой вклад, как показано на рисунке 3.
- Системные Архитекторы обладают глубокими техническими знаниями в области решений. Они ответственны за понимание их на уровне системы, а также их вариантов использования и нефункциональных требований (Non-Functional Requirements, NFRs). Несмотря на то, что эти роли считаются техническими и направленными вовнутрь системы, архитекторы должны быть также в большой мере и на постоянной основе вовлечены во взаимодействие с клиентами, что позволяет им находить новые способы решения незакрытых потребностей.
- Клиенты определяют ценность, голосуя своими кошельками или ногами. Соответственно, они являются основным источником обратной связи о реализованном Решении и о том, насколько хорошо оно соответствует их потребностям. Но нужно иметь в виду, что восприятие клиентов часто сильно привязано к контексту текущего решения, поэтому они часто настроены только на постепенное улучшение. Другими словами, продуктовую стратегию не строят исключительно на обратной связи от клиентов. Но верным путем к провалу будет не попадание в текущие и возникающие потребности клиентов.
- Представители Бизнеса и заинтересованные лица – Представители Бизнеса обладают знаниями бизнеса и рынка, необходимыми для определения миссии и концепции. Решение, которое не соответствует их ожиданиям, скорее всего, не имеет ценности.
- Владельцы Продуктов и команды – Владельцы продуктов и Agile-команды создают экспертные знания в предметной области благодаря своей работе над Решением. Во многих случаях именно они ближе всего как к техническим нуждам, так и к проблемам пользователей. Их вклад является неотъемлемой частью в постоянное развитие Решения.
Сотрудничество и исследования основаны на конкретных практиках:
- Первичное изучение рынка – Продуктовый Менеджмент получает дополнительную информацию от первичных исследований рынка, включая опросы, взаимодействие с фокус-группам, анкетирование и конкурентный анализ для понимания клиентов.
- Визиты клиентов и Гемба – Гемба или визиты клиентов – это процесс, в ходе которого продуктовая команда наблюдает за тем, как заинтересованные лица выполняют конкретные действия в своих потоках поставки ценности, чтобы выявить возможности для постоянного улучшения. Ничто не заменит наблюдения от первого лица за повседневной деятельностью людей, выполняющих работу. Продуктовому Менеджменту и Владельцам Продуктов необходимо понимать, как люди используют системы в своей рабочей среде. Они не могут делать это за своим рабочим столом, поэтому ничто не может заменить “выход из офиса”, посещение клиентов и наблюдение за пользователями в их конкретном контексте решения.
- Вторичное изучение рынка – Чтобы расширить свое мышление, Продуктовый Менеджмент использует различные методы вторичного исследования рынка, чтобы всесторонне понять клиентов и рынки, которые они обслуживают. Быть в курсе тенденций рынка/отрасли – важнейший результат вторичного исследования рынка.
- Мышление LeanUX – Lean UX это процесс совместной работы с заинтересованными лицами для определения Фич, минимально пригодных для продажи (Minimum Marketable Feature, MMF), и быстрой проверки их с клиентами.
Исследование в сотрудничестве позволяет организации усовершенствовать дальнейший процесс и создавать артефакты, которые ясно выражают формирующееся понимание пространства проблемы. Это включает следующие методы:
- Разработка персон для фокусирования дизайна – персоны, созданные на основе исследований, помогают организации понять своих целевых клиентов.
- Формирование эмпатии к пользователю – Карты Эмпатии гарантируют, что команда учитывает потребности пользователя и то, как они могут развиваться в ходе последующих релизов.
- Проектирование клиентского опыта – Карты пути клиента (Customer Journey Map, CJM) обеспечивают связь между операционным потоком создания ценности и пользовательским опытом Клиента.
Хотя эти артефакты, как правило, относительно стабильны от релиза к релизу, организация должна находить пути, как избежать принятия стратегических решений на основе устаревших аналитических данных.
Архитектура
С четким пониманием проблемы CE переходит в пространство решений, определяя минимальный объем архитектуры, который будет поддерживать Решение и обеспечивать непрерывное развертывание.
Архитекторы работают для бизнеса и клиента, гарантируя, что Архитектурная Полоса (Architectural Runway) достаточна для обеспечения поставки требуемой функциональности и спроектирована таким образом, чтобы обеспечить Непрерывный Конвейер Поставки (CDP). Системные Архитекторы поддерживают CDP с помощью пяти практик:
- Создание архитектуры,обеспечивающей возможность выпуска релизов – Для разных частей решения требуются разные стратегии релизов. Поэтому разрабатывайте решения которые позволяют реализовать различные релизные стратегии и развивайте их с течением времени, основываясь на потребностях бизнеса.
- Создание архитектуры, обеспечивающей возможность тестирования – Системы, спроектированные и построенные модульно, обеспечивают непрерывное тестирование.
- Разделение развертывания и релиза – Для обеспечения возможности непрерывного развертывания требуются архитектурная поддержка, которая позволяет отправлять функциональность на промышленное окружение, но скрывать ее от клиентов.
- Создание архитектуры, обеспечивающей эксплуатацию – Встраивайте возможности телеметрии и логирования в каждое приложение и решение для удовлетворения потребностей в оперативной поддержке. Обеспечьте возможность отката сервисов или даже удаления их при высоких нагрузках или в ответ на инциденты. Создайте возможности для быстрого восстановления и возможности исправления ошибок.
- Моделирование угроз – Необходимо на ранней стадии начинать учитывать аспекты информационной безопасности, понимая угрозы в предлагаемой архитектуре, инфраструктуре и приложениях. Фиксируйте существенные требования безопасности в нефункциональных требованиях в бэклоге.
Синтез
Синтез преобразует полученные знания в новое будущее состояние решения. Концепция, дорожная карта и приоритизированный бэклог направляют команды ART в одном общем направлении. Сосредоточьте синтез на обеспечении готовности этих артефактов к PI-планированию. Для достижения этой цели необходимы следующие методы:
- Создание концепции решения – Концепция определяет причины или цель разработки новых Фич.
- Поддержка дорожной карты решения – Дорожная карта ART обеспечивает видение ближайшего будущего, помогая Продуктовому Менеджменту расставлять приоритеты в работе, позволяя Системным Архитекторам расставлять приоритеты в архитектуре, а также обеспечивая наглядность для Представителей Бизнеса.
- Определение бэклога с помощью четко прописанных элементов – Определение фич для планирования командами. Фичи укладываются в планируемый интервал (Planning Interval, PI) и имеют решающее значение для ART, обеспечивая соответствие тому, что сейчас нужно. Бэклог также отражает основные требования безопасности.
- Разработка, ориентированная на поведение (Behaviour Driven Development, BDD) способствует сотрудничеству между Продуктовым Менеджментом, Владельцами Продукта и Agile-командами, которые уточняют требования, добавляя критерии приемки.
- Экономическая расстановка приоритетов – Приоритизированные фичи обеспечивают эффективную разработку. При расстановке приоритетов решающее значение имеют правила бюджетирования в виде распределения мощностей, инвестиционных горизонтов и постоянного взаимодействия с Представителями Бизнеса.
- PI-планирование – Работы по исследованию и изучению, выполняемые в ART, являются важным вкладом в данные для последующего PI-планирование и помогают согласованности.
Там, где есть ориентация на то, что необходимо создать, фичи плавно переходят в CI-сегмент CDP. Однако, это не означает, что исследование завершено. Обратная связь о выпущенных фичах поступает постоянно. Эта обратная связь информирует о новых решениях над которыми ART следует работать дальше, так как это и неотъемлемая часть процесса CE.
Обеспечение непрерывного исследования с помощью DevOps
Действия непрерывного исследования задают темп для всего CDP. Реализация проходит медленно, когда работа выполняется большими партиями, с жесткими спецификациями и обязательствами по фиксированным планам. Таким образом, для обеспечения непрерывной работы ART эти ‘восходящие’ действия должны основываться на стремлении к скорости и подтвержденному обучению. Применение мышления DevOps, практик и инструментария на ранних этапах процесса создания ценности укрепляет соответствие всем принципам SAFe, приводит весь процесс в соответствие с мышлением DevOps и поддерживает CDP.
На этом уровне применимы многие концепции, связанные с DevOps. На рисунке 4 показан подход SAFe к поддержке CE с помощью CALMR для DevOps (в центре) и практических областей (внутренние кольца). Каждое из четырех действий (выделено зеленым цветом) является результатом совместной работы, в которой используется опыт DevOps из различных дисциплин для максимального увеличения скорости и качества доставки.
Например, разработка архитектуры для непрерывной поставки – это не одномерная деятельность. Как видно из рисунка 4, она охватывает несколько дисциплин. Agile-архитектура должна учитывать желаемые уровни качества и безопасности, соответствовать целям производительности потока создания ценности, создавать реальные конфигурации в контроле версий и генерировать элементы бэклога и NFR, которые поддерживают гибкое планирование и оперативный дизайн. Более того, мышление CALMR должно определять все архитектурные решения и действия для максимального увеличения скорости доставки и ценности решения.
Все четыре вида деятельности CE поддерживаются DevOps, хотя в различных комбинациях технических приемов и инструментов.