Все статьи

Дина Соболева

Agile-коуч, Cкрам-мастер. Умею и люблю работать с командами любого уровня зрелости и руководителями, помогая им улучшать процессы и продукты. Практикую разумный Agile и Скрам. Знаю короткий путь к крутым процессам, но работаю в том темпе, к которому готова команда. Agile-трансформация и внедрение SAFe с нуля до продвинутого уровня. Люблю метрики и умею их использовать как инструмент для улучшений.

Непрерывное изучение в SAFe®

Дата: 31.01.2025

Непрерывное изучение в SAFe® (Scaled Agile Framework®) – это часть конвейера непрерывной поставки, которая продвигает инновации и обеспечивает согласованность того, что должно быть доставлено, за счет постоянного изучения рынка и потребностей клиентов, определения видения, дорожной карты и набора фич для создания решения.

Содержание

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

Непрерывное Изучение (Continuous Exploration, CE) является первой частью Конвейера Непрерывной Поставки (Continuous Delivery Pipeline, CDP), состоящего из четырех частей и также включающего в себя Непрерывную Интеграцию (Continuous Integration, CI), Непрерывное Развертывание (Continuous Deployment, CD) и Релиз по Требованию (Release On Demand).

Конвейер непрерывной поставки (Continuous Delivery Pipeline) SAFe, agile
Рисунок 1. Непрерывное Изучение в контексте Конвейера Непрерывной Поставки ​

На этапе CE работа возникает за счет новых идей. Они уточняются и организуются в виде списка приоритизированных Фич в Бэклоге ART. Agile-команды реализуют Фичи, приоритизированные Продуктовым Менеджментом во время PI-планирования, что запускает процесс CI. После этого CD-цикл переносит их на промышленное окружение, где они проверяются и подготавливаются к релизу.

Agile-поставка Продуктов является одной из семи ключевых компетенций SAFe. Это позволяет организации поставлять конечным пользователям Решение с высокой ценностью с оптимальной частотой. CE является неотъемлемой частью этого процесса и фокусируется на применении Клиентоориентированности и Дизайн-мышления, чтобы осознать и согласовать идеи для создания новых возможностей. При этом понятно, что все подобные идеи являются гипотезами, которые нуждаются в проверке.

CE заменяет традиционный «водопадный» подход, когда все требования определяются на старте. Вместо этого процесс генерирует в Бэклоге ART непрерывный целостный поток Фич, готовых к реализации. Разбиение Фич на небольшие по размеру Истории позволяет быстро продвигать работу по оставшимся этапам CDP до Клиента. Получение быстрой обратной связи встроено в процесс, что позволяет командам адаптировать разработку к потребностям рынка. Смотрите статью «Поток ART» для получения дополнительной информации о том, как создать поток ценности без прерываний (Принцип №6 – Создавайте поток ценности без прерываний).

Клиенты, Поставщики, партнеры, Представители Бизнеса, Agile-команды, Владельцы Продуктов и Lean-управление Портфелем входят в число внутренних и внешних заинтересованных лиц, вовлеченных в этот процесс. Их участие может быть косвенным, например, посредством вторичного исследования потребностей рынка. Или оно может быть прямым, например, когда Agile-команды участвуют в Итерации Инноваций и Планирования. Процесс CE позволяет организации согласовать совокупность Фич в бэклоге и прогнозируемую Дорожную Карту с общей Концепцией организации.

Четыре активности непрерывного изучения

На рисунке 2 показаны четыре шага Непрерывного Изучения, описанные в следующих разделах.
Непрерывное изучение (continuous integration) в SAFe, agile
Рисунок 2. Четыре шага Непрерывного Изучения

Создание гипотезы

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

У Продуктового Менеджмента есть представления о потребностях клиентов, основанные на их понимании рынка, Стратегических Темах, Концепции и Дорожной Карте. Однако, эти идеи не следует считать фактами. Команды должны рассматривать их как гипотезу, которая требует проверки и подтверждения. Практики, связанные с разработкой на основе гипотез, включают в себя:

  • Мышление бережливого стартапа (Lean Startup) – определение Фич, минимально пригодных для продажи (MMF, Minimum Marketable Feature) и минимально жизнеспособных продуктов (MVP, Minimum Viable Product) помогает быстро проверить гипотезы с минимальными инвестициями. MMF и MVP представляют собой наименьший объем полезной функциональности для первых клиентов, которые могут предоставить обратную связь для будущей разработки продукта.
  • Учет инноваций – проверка гипотез для нового продукта или Фичи требует иного подхода, чем оценка существующих решений. Это требует от нас рассмотрения двух вопросов: 1) Продвигаемся ли мы к нашей гипотезе о конечном результате? 2) Как мы это можем понять? Учет инноваций использует метрики для определения действий, способствующих достижению бизнес-целей (опережающие показатели). Такие метрики позволяют определить первые результаты, что является базисом для прогнозирования будущих бизнес-результатов. Опережающие показатели отвечают на упомянутые два вопроса и улучшают экономические решения на этапе разработки начального Решения и оценки MMF или MVP.

Сотрудничество и исследования

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

Сотрудничества Продуктового менеджмента (Product Management) с Системным Архитектором, Клиентами, Владельцами продукта, Представителями бизнеса (Product Owners) и Заинтересованными лицами (Stakeholders). SAFe
Рисунок 3. Продуктовый Менеджмент взаимодействует с разными заинтересованными лицами, чтобы актуализировать требования
  • Системные Архитекторы обладают глубокими техническими знаниями в области решений. Они ответственны за понимание их на уровне системы, а также их вариантов использования и нефункциональных требований (Non-Functional Requirements, NFRs). Несмотря на то, что эти роли считаются техническими и направленными вовнутрь системы, архитекторы должны быть также в большой мере и на постоянной основе вовлечены во взаимодействие с клиентами, что позволяет им находить новые способы решения незакрытых потребностей.
  • Клиенты определяют ценность, голосуя своими кошельками или ногами. Соответственно, они являются основным источником обратной связи о реализованном Решении и о том, насколько хорошо оно соответствует их потребностям. Но нужно иметь в виду, что восприятие клиентов часто сильно привязано к контексту текущего решения, поэтому они часто настроены только на постепенное улучшение. Другими словами, продуктовую стратегию не строят исключительно на обратной связи от клиентов. Но верным путем к провалу будет не попадание в текущие и возникающие потребности клиентов.
  • Представители Бизнеса и заинтересованные лица – Представители Бизнеса обладают знаниями бизнеса и рынка, необходимыми для определения миссии и концепции. Решение, которое не соответствует их ожиданиям, скорее всего, не имеет ценности.
  • Владельцы Продуктов и команды – Владельцы продуктов и Agile-команды создают экспертные знания в предметной области благодаря своей работе над Решением. Во многих случаях именно они ближе всего как к техническим нуждам, так и к проблемам пользователей. Их вклад является неотъемлемой частью в постоянное развитие Решения.

Сотрудничество и исследования основаны на конкретных практиках:

  • Первичное изучение рынка – Продуктовый Менеджмент получает дополнительную информацию от первичных исследований рынка, включая опросы, взаимодействие с фокус-группам, анкетирование и конкурентный анализ для понимания клиентов.
  • Визиты клиентов и Гемба – Гемба или визиты клиентов – это процесс, в ходе которого продуктовая команда наблюдает за тем, как заинтересованные лица выполняют конкретные действия в своих потоках поставки ценности, чтобы выявить возможности для постоянного улучшения. Ничто не заменит наблюдения от первого лица за повседневной деятельностью людей, выполняющих работу. Продуктовому Менеджменту и Владельцам Продуктов необходимо понимать, как люди используют системы в своей рабочей среде. Они не могут делать это за своим рабочим столом, поэтому ничто не может заменить “выход из офиса”, посещение клиентов и наблюдение за пользователями в их конкретном контексте решения.
  • Вторичное изучение рынка – Чтобы расширить свое мышление, Продуктовый Менеджмент использует различные методы вторичного исследования рынка, чтобы всесторонне понять клиентов и рынки, которые они обслуживают. Быть в курсе тенденций рынка/отрасли – важнейший результат вторичного исследования рынка.
  • Мышление LeanUX – Lean UX это процесс совместной работы с заинтересованными лицами для определения Фич, минимально пригодных для продажи (Minimum Marketable Feature, MMF), и быстрой проверки их с клиентами.

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

  • Разработка персон для фокусирования дизайна – персоны, созданные на основе исследований, помогают организации понять своих целевых клиентов.
  • Формирование эмпатии к пользователю – Карты Эмпатии гарантируют, что команда учитывает потребности пользователя и то, как они могут развиваться в ходе последующих релизов. 
  • Проектирование клиентского опыта – Карты пути клиента (Customer Journey Map, CJM) обеспечивают связь между операционным потоком создания ценности и пользовательским опытом Клиента.

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

Архитектура

С четким пониманием проблемы CE переходит в пространство решений, определяя минимальный объем архитектуры, который будет поддерживать Решение и обеспечивать непрерывное развертывание.

Архитекторы работают для бизнеса и клиента, гарантируя, что Архитектурная Полоса (Architectural Runway) достаточна для обеспечения поставки требуемой функциональности и спроектирована таким образом, чтобы обеспечить Непрерывный Конвейер Поставки (CDP). Системные Архитекторы поддерживают CDP с помощью пяти практик:

  1. Создание архитектуры,обеспечивающей возможность выпуска релизов – Для разных частей решения требуются разные стратегии релизов. Поэтому разрабатывайте решения которые позволяют реализовать различные релизные стратегии и развивайте их с течением времени, основываясь на потребностях бизнеса.
  2. Создание архитектуры, обеспечивающей возможность тестирования – Системы, спроектированные и построенные модульно, обеспечивают непрерывное тестирование.
  3. Разделение развертывания и релиза – Для обеспечения возможности непрерывного развертывания требуются архитектурная поддержка, которая позволяет отправлять функциональность на промышленное окружение, но скрывать ее от клиентов.
  4. Создание архитектуры, обеспечивающей эксплуатацию – Встраивайте возможности телеметрии и логирования в каждое приложение и решение для удовлетворения потребностей в оперативной поддержке. Обеспечьте возможность отката сервисов или даже удаления их при высоких нагрузках или в ответ на инциденты. Создайте возможности для быстрого восстановления и возможности исправления ошибок.
  5. Моделирование угроз – Необходимо на ранней стадии начинать учитывать аспекты информационной безопасности, понимая угрозы в предлагаемой архитектуре, инфраструктуре и приложениях. Фиксируйте существенные требования безопасности в нефункциональных требованиях в бэклоге.

Синтез

Синтез преобразует полученные знания в новое будущее состояние решения. Концепция, дорожная карта и приоритизированный бэклог направляют команды 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 из различных дисциплин для максимального увеличения скорости и качества доставки.

SAFe DevOps в непрерывном изучении
Рисунок 4. DevOps обеспечивает непрерывное изучение

Например, разработка архитектуры для непрерывной поставки – это не одномерная деятельность. Как видно из рисунка 4, она охватывает несколько дисциплин. Agile-архитектура должна учитывать желаемые уровни качества и безопасности, соответствовать целям производительности потока создания ценности, создавать реальные конфигурации в контроле версий и генерировать элементы бэклога и NFR, которые поддерживают гибкое планирование и оперативный дизайн. Более того, мышление CALMR должно определять все архитектурные решения и действия для максимального увеличения скорости доставки и ценности решения.

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

Автор:

Поделиться

VK
Telegram

Product Owner и Product Manager в SAFe®

Тренинг SAFe® Product Owner/Product Manager раскрывает роли Владельца и Менеджера Продукта, работающих в крупной компании. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Product Owner/Product Manager (POPM).

Зарегистрироваться