© 2022 Scaled Agile, Inc. All rights reserved.

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

Learn more

Clear explanations and actionable guidance

SAFe Distilled 5.0

SAVE 35% WITH CODE SCALEDAGILE

ORDER NOW

SAFe Glossary

The SAFe glossary is a set of definitions for all SAFe Big Picture elements.  The extended glossary provides definitions for additional terms used in the Framework. Some are unique to SAFe (e.g., PO Sync), while others are common in Lean-Agile development (e.g., MVP). They are provided here for clarity in their meaning in the context of SAFe. All extended glossary terms appear in the English configuration and will appear in other language configurations once translated.

Author

A

  • Acceptance Criteria (Критерии Приемки)

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

  • Acceptance Test Driven Development (Разработка на Основе Приёмочных Тестов)

    Разработка на Основе Приёмочных Тестов (TDD) является Agile практикой раннего тестирования (test-first), синонимичной по отношению к Разработке на Основе Поведения (BDD).

  • Agile

    Agile - это набор ценностей, принципов и практик для итеративной разработки, которые в основном описаны в Agile Манифесте.

  • Agile Manifesto (Agile Манифест)

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

  • Agile Product Delivery (Agile Доставка Продукта)

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

  • Agile Program Management Office, APMO (Офис Управления Agile Программами)

    Офис Управления Agile Программами (APMO) является функцией организации, которая отвечает за фасилитацию процесса Бережливого Управления Портфелем (LPM), а также за совершенствование операционной деятельности и бережливого управления в рамках Lean-Agile трансформации.

  • Agile Release Train, ART (Релизный Поезд Agile)

    Релизный Поезд Agile — это долгосрочная команда, состоящая из Agile команд, которые вместе с другими заинтересованными лицами (stakeholders) инкрементально разрабатывают, доставляют и, если применимо, эксплуатируют одно или несколько решений в рамках потока ценности.

  • Agile Team (Agile Команда)

    В SAFe Agile Команда — это кросс-функциональная группа из 5–11 человек, которая за короткий срок определяет, создает, тестирует и доставляет инкремент ценности.

  • Architect Sync (Синхронизация Архитекторов)

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

  • Architectural Runway (Архитектурное Русло)

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

  • ART Sync (Синхронизация Релизного Поезда Agile)

    Синхронизация Релизного Поезда Agile (ART) - это мероприятие поезда, которое совмещает одновременно Синхронизацию Владельцев Продукта (PO Sync) и Скрам Скрамов (SoS).

B

  • Backlog Refinement (Уточнение Беклога)

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

  • Baseline Solution Investments, BSI (Базовый уровень Инвестиций в Решения)

    Базовый уровень Инвестиций в Решения (BSI) — это те затраты, которые приходятся на каждый поток ценности, пока он разрабатывает, поддерживает и эксплуатирует решения, которые создают текущие возможности для бизнеса.

  • Batch Size (Размер партии)

    Размер партии — это мера, показывающая, сколько работы (требования, дизайн, код, тесты и другие элементы работ) поступает в систему в заданный интервал времени.

  • Behavior-Driven Development, BDD (Разработка на Основе Поведения)

    Разработка на основе Поведения (BDD) - это Agile практика раннего тестирования (test-first), которая обеспечивает встроенное качество, определяя (и потенциально автоматизируя) тесты до или в рамках описания поведения системы.

  • Benefit Hypothesis (Гипотеза выгоды)

    Гипотеза выгоды - это предполагаемая измеримая выгода для конечного пользователя или бизнеса, являющаяся частью фичи или капапилити.

  • Big Visible Information Radiator, BVIR (Большой Видимый Информационный Радиатор)

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

  • Built-In Quality (Встроенное Качество)

    Практики Встроенного Качества обеспечивают соответствие каждого элемента Решения в каждом инкременте необходимым стандартам качества на протяжении всей разработки.

  • Burn-Down (Burn-Up) Chart (Диаграммы Сгорания вниз/вверх)

    Диаграммы Сгорания вниз (или вверх) - это графические отображения прогресса выполнения работы относительно времени.

  • Business Agility (Бизнес Гибкость/Бизнес Проворность)

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

  • Business and Technology (Бизнес и Технологии)

    Иконка Бизнес и Технологии в SAFe описывает, как функциональные домены во всех частях предприятия обеспечивают гибкость бизнеса путем непрерывного исследования новых способов применения Lean-Agile принципов и практик в отношении их уникальных контекстов.

  • Business Context (Бизнес-контекст)

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

  • Business Owners (Владельцы Бизнеса)

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

C

  • CALMR

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

  • Capabilities (Капабилити, Возможность)

    Капабилити — это высокоуровневое поведение решения, которое обычно реализуется несколькими Релизными Поездами Agile (ART). Для Капабилити определяется их размер и они разбиваются (декомпозируются) на несколько Фич, чтобы обеспечить их реализацию в рамках одного PI.

  • Capacity Allocation (Аллокация Ёмкости)

    Аллокация Ёмкости является бережливой бюджетной направляющей для беклогов, помогающей сбалансировать выделение ёмкости для новых фич, энейблеров и технического долга в рамках предстоящего Инкремента Программы (PI).

  • Committed PI Objectives (Цели на Инкремент Программы с Принятыми Обязательствами )

    Цели на Инкремент Программы с Принятыми Обязательствами - это набор целей по SMART, которые создаются каждой командой и имеют бизнес-ценность, установленную Владельцами Бизнеса.

  • Communities of Practice, CoP (Сообщества Практик)

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

  • Compliance (Соответствие)

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

  • Confidence Vote (Голосование Уверенности)

    Голосование Уверенности проводится ближе к концу Планирования Инкремента Программы, когда команды голосуют за свою уверенность в достижимости целей Инкремента Программы.

  • Continuous Delivery Pipeline, CDP (Конвейер Непрерывной Доставки)

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

  • Continuous Deployment, CD (Непрерывное Развертывание)

    Непрерывное Развертывание — это процесс перемещения подтвержденных (валидированных) Фич из промежуточной среды (staging) в продуктивную среду, где они готовятся к выпуску.

  • Continuous Exploration, CE (Непрерывное Исследование)

    Непрерывное Исследование — это процесс, который обеспечивает инновации и стимулирует выравнивание (alignment) вокруг того, что должно быть создано, посредством постоянного изучения рынка и потребностей Клиента, а также определения Видения, Дорожной Карты и набора Фич для Решения, которое удовлетворяет эти потребности.

  • Continuous Integration, CI (Непрерывная Интеграция)

    Непрерывная Интеграция — это процесс, при котором Фичи из Бэклога Программы разрабатываются, тестируются и валидируются на промежуточной среде (staging), где они подготавливаются к развертыванию и выпуску.

  • Continuous Learning Culture (Культура Непрерывного Обучения)

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

  • Core Values (Основные Ценности)

    Основные Ценности: выравнивание (alignment), встроенное качество (built-in quality), прозрачность (transparency) и выполнение программы (program execution); представляют собой фундаментальные убеждения, лежащие в основе эффективности SAFe. Эти направляющие принципы определяют поведение и действия каждого участника портфеля SAFe.

  • Cost of Delay, CoD (Стоимость Задержки)

    Стоимость Задержки (CoD) представляет собой деньги или ценность, которые будут потеряны в результате задержки или не выполнения работы в течение какого-то времени; CoD используется в WSJF приоритизации.

  • Customer (Клиент)

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

  • Customer Centricity, CC (Клиентоцентричность)

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

  • Customer Journey Map, CJM (Карта Пути Клиента)

    Карта Пути Клиента (CJM) иллюстрирует опыт взаимодействия пользователя с операционным потоком ценности, продуктами и услугами компании.

D

  • Daily Stand-Up, DSU (Ежедневная Стендап Встреча)

    Ежедневная Стендап Встреча (DSU) - это ежедневное мероприятие команды, в котором каждый член команды описывает то, что он сделал вчера для достижения целей итерации, над чем он будет работать сегодня для достижения целей итерации, и сообщает о сложностях, с которыми он сталкивается при доставке этих целей.

  • Decentralized Decision-Making (Децентрализация Принятия Решений)

    Децентрализованное Принятие Решений наделяет полномочиями по принятию решений тех, кто находится ближе всего к знаниям и информации, для сокращения задержек, ускорения потока создания продукта, и улучшения качества решений.

  • Definition of Done (Определение Выполненности/Завершенности)

    Определение Выполненности сообщает о завершённости инкремента ценности и создает общее понимание того, какая часть работы была завершена в рамках Инкремента.

  • Design Thinking (Дизайн-Мышление)

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

  • Develop on Cadence (Разработка в Каденции)

    Разработка в Каденции является скоординированным набором практик, которые поддерживают Agile команды путем предоставления испытанного набора событий и активностей, которые происходят на основе регулярного, предсказуемого графика.

  • Development Value Streams (Разработческие Потоки Ценности)

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

  • DevOps (Девопс)

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

E

  • Empathy Map (Карта Эмпатии)

    Карта Эмпатии - это инструмент Дизайн Мышления, который помогает командам создать глубокое коллективное понимание своих клиентов.

  • Enablers (Энейблер)

    Энейблер поддерживает действия по расширению Архитектурного Русла для обеспечения будущей бизнес функциональности. Эти действия включают в себя исследование (exploration), архитектуру, инфраструктуру и Соответствие. Энейблеры фиксируются в различных бэклогах и встречаются на всех уровнях Фреймворка.

  • Enterprise (Предприятие)

    Предприятие представляет собой бизнес-единицу, которой принадлежит каждый портфель SAFe.

  • Enterprise Architect (Архитектор Предприятия)

    Архитектор Предприятия определяет технологическую стратегию и дорожную карту, позволяющие портфелю поддерживать текущие и будущие бизнес возможности (capabilities).

  • Enterprise Solution Delivery (Доставка Решений Предприятия)

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

  • Epic Hypothesis Statement (Заявление Гипотезы Эпика)

    Заявление Гипотезы Эпика отражает, организует и коммуницирует критическую информацию об Эпике.

  • Epic Owners (Владельцы Эпиков)

    Владельцы Эпиков отвечают за координацию Эпиков портфеля с помощью Канбан системы Портфеля. Они совместно определяют Эпик, его Минимальный Жизнеспособный Продукт (MVP) и Бережливый Бизнес Кейс (Lean Business Case), а после утверждения фасилитируют его выполнение.

  • Epics (Эпик)

    Эпик является контейнером для существенной инициативы разработки Решения, который фиксирует наиболее крупные инвестиции, осуществляемые в портфеле. Из-за их большого масштаба и влияния, эпики требуют определения Минимального Жизнеспособного Продукта (MVP) и утверждения Бережливым Управлением Портфелем (LPM) до начала выполнения.

  • Essential SAFe (Базовый SAFe)

    Базовый SAFe содержит минимальный набор ролей, событий и артефактов, необходимых чтобы непрерывно поставлять бизнес решения с помощью Релизного Поезда Agile (ART) в виде команды Agile Команд.

  • Estimating Poker (Покер Оценки)

    Покер Оценки - это совместная техника для относительной оценки размера историй, фич и WSJF (Взвешенная Кратчайшая Работа Сначала) в SAFe.

  • Extreme Programming, XP (Экстремальное Программирование)

    Экстремальное Программирование – набор инженерных практик Agile разработки программного обеспечения, повышающих качество и отзывчивость на меняющиеся пользовательские требования. Преимущественно разработаны Кентом Беком.

F

  • Feature (Фича)

    Фича — это сервис, удовлетворяющий потребность заинтересованного лица (stakeholder). Каждая фича включает в себя гипотезу выгоды (benefit hypothesis) и критерии приемки и масштабируется или по необходимости разбивается (декомпозируется) таким образом, чтобы она могла быть доставлена одним Релизным Поездом Agile (ART) в рамках одного Инкремента Программы (PI).

  • Final Plan Review (Финальный Обзор Плана)

    В Финальном Обзоре Плана во время PI планирования команды презентуют финальные планы (Цели Инкремента Программы, загрузку, риски) для информирования Релизного Поезда Agile (ART) и их принятия Владельцами Бизнеса.

  • Foundation (Фундамент)

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

  • Full SAFe (Полный SAFe)

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

G

  • Gemba (Гемба)

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

H

  • Hackathon (Хакатон)

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

I

  • Innovation and Planning Iteration (Итерация Инноваций и Планирования)

    Итерация Инноваций и Планирования (IP) происходит внутри каждого Инкремента Программы (PI) и служит для целого ряда задач. Она выполняет роль буфера оценок в части достижения Целей Инкремента Программы, а также обеспечивает выделенное время на инновации, непрерывное обучение, а также событие PI Планирования и событие Инспект-Адапт (I&A).

  • Inspect & Adapt, I&A (Инспект-Адапт)

    Инспект-Адапт — значимое событие, происходящее в конце каждого Инкремента Программы (PI), где поездом (ART) демонстрируется и оценивается текущее состояние Решения. После этого команды обсуждают и идентифицируют элементы бэклога улучшений в рамках структурированной Мастерской Решения Проблем (Problem Solving Workshop).

  • Integration Point (Точка Интеграции)

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

  • Investment Horizons (Инвестиционные Горизонты)

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

  • Iteration (Итерация)

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

  • Iteration Execution (Выполнение Итерации)

    Выполнение Итерации — это то, как Agile Команда организует свою работу внутри временного интервала Итерации для создания высококачественного, работающего и протестированного инкремента системы.

  • Iteration Goals (Цели Итерации)

    Цели Итерации — это краткое высокоуровневое изложение бизнес- и технических целей, которые Agile Команда соглашается выполнить в Итерации. Они играют важную роль в координации работы Релизного Поезда Agile (ART), как самоорганизующейся и самоуправляемой команды команд.

  • Iteration Planning (Планирование Итерации)

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

  • Iteration Retrospective (Ретроспектива Итерации)

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

  • Iteration Review (Обзор Итерации)

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

K

  • Knowledge Worker (Работник Умственного Труда)

    Работники Умственного Труда - это люди, обладающие навыками, опытом и образованием, необходимыми для решения сложных проблем в их предметной области (домене).

L

  • Large Solution SAFe (Крупное Решение SAFe)

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

  • Lead Time (Время Выполнения)

    Время выполнения - время, которое занимает выполнение работы с момента её завершения на предыдущем шаге до момента её завершения на текущем шаге.

  • Lean (Бережливость)

    Бережливость - совокупность знаний и набор практик для повышения эффективности и результативности за счет сокращения задержек и устранения активностей, не участвующих в создании ценности (non-value-added).

  • Lean Budget Guardrails (Бережливые Бюджетные Направляющие)

    Бережливые Бюджетные Направляющие описывают политики и практики бюджетирования, осуществления расходов и надзора для конкретного портфеля.

  • Lean Budgets (Бережливые Бюджеты)

    Бережливые Бюджеты — это Lean-Agile подход к финансовому надзору, который повышает пропускную способность и продуктивность путем снижения накладных расходов и затрат, вызываемых проектным подходом к учету издержек (себестоимости).

  • Lean Business Case (Бережливый Бизнес Кейс)

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

  • Lean Governance (Бережливое Управление)

    Бережливое Управление - одно из измерений Бережливого Управления Портфелем, которое поддерживает надзор и принятие решений в отношении расходов, аудит и соответствие (регуляторное, нормативно-правовое, корпоративное и иное), прогнозирование расходов и учет.

  • Lean Portfolio Management (Бережливое Управление Портфелем)

    Компетенция Бережливого Управления Портфелем выравнивает стратегию и выполнение посредством применения подходов Lean и системного мышления к стратегии и инвестиционному финансированию, операционной деятельности Agile портфеля и надзору.

  • Lean Quality Management System, QMS (Бережливая Cистема Управления Качеством)

    Cистема Управления Качеством (QMS) диктует практики, политики и процедуры, необходимые для подтверждения безопасности и результативности. SAFe организации переходят от традиционного к Lean QMS управлению.

  • Lean User Experience, Lean UX (Бережливый Опыт Пользователя)

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

  • Lean-Agile Center of Excellence, LACE (Центр Lean-Agile Мастерства)

    Центр Lean-Agile Мастерства (LACE) - это небольшая команда людей, специализирующаяся на внедрении SAFe Lean-Agile способов работы.

  • Lean-Agile Leadership (Lean-Agile Лидерство)

    Компетенция Lean-Agile Лидерства описывает, как Lean-Agile Лидеры ведут и поддерживают организационные изменения и совершенство операционной деятельности, предоставляя сотрудникам и командам возможность максимальной реализации их потенциала.

  • Lean-Agile Mindset (Lean-Agile Мышление)

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

  • Lean-Agile Principles (Lean-Agile Принципы)

    SAFe основан на десяти неизменных основополагающих Lean-Agile Принципах. Эти утверждения и экономические концепции вдохновляют и наполняют содержанием роли и практики SAFe.

  • Little's Law (Закон Литтла)

    Закон Литтла - это закон теории очередей, который гласит, что среднее время ожидания обслуживания со стороны системы равно отношению средней длины очереди к средней скорости обработки.

M

  • Measure And Grow (Измерять и Развивать)

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

  • Metrics (Метрики)

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

  • Milestones (Вехи)

    Вехи используются для отслеживания прогресса по достижению определенной цели или события. В SAFe существует три типа вех: Инкремент Программы (PI), с фиксированной датой и вехи накопления знаний (learning).

  • Minimum Marketable Feature, MMF (Минимальная Маркетируемая Фича)

    Минимальная Маркетируемая Фича (MMF) - это минимальная функциональность, которую команды могут создать, чтобы выяснить, верна ли гипотеза выгоды этой фичи или нет.

  • Minimum Viable Product, MVP (Минимально Жизнеспособный Продукт)

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

  • Model-Based Systems Engineering, MBSE (Инжиниринг Систем на Основе Моделей)

    Инжиниринг Систем на Основе Моделей — практика разработки набора взаимосвязанных моделей, которые помогают определять, проектировать и документировать находящуюся в разработке систему. Эти модели обеспечивают эффективный способ изучения, обновления и коммуникации аспектов системы заинтересованным лицам (stakeholders), при этом значительно сокращая или устраняя зависимость от традиционной документации.

  • Modified Fibonacci Sequence (Модифицированная Последовательность Фибоначчи)

    Модифицированная Последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100) используется во время относительной оценки, чтобы учесть неопределенность по мере увеличения размера оцениваемой работы.

N

  • Nonfunctional Requirements, NFR (Нефункциональные Требования)

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

O

  • Objectives and Key Results, OKR (Цели и Ключевые Результаты)

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

  • Operational Value Streams (Операционные Потоки Ценности)

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

  • Organizational Agility (Организационная Гибкость)

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

  • Organizational Change Management (Управление Организационными Изменениями)

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

P

  • Pareto Analysis (Анализ Парето)

    Анализ Парето - это техника, используемая во время мероприятия «Инспект-Адапт», для уменьшения количества действий, которые создают наиболее значительный суммарный эффект.

  • Participatory Budgeting (Самобюджетирование)

    Самобюджетирование (PB) - это процесс, используемый Бережливым Управлением Портфелем (LPM) для распределения всего бюджета портфеля между его потоками ценности.

  • Personas (Персоны)

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

  • Phase Gate (Фазовые Ворота)

    Фазовые Ворота - это традиционные управленческие вехи (этапы работ), которые в SAFe заменяются вехами, основанными на объективной оценке работающих систем.

  • PI Objectives (Цели Инкремента Программы)

    Цели Инкремента Программы представляют собой краткое изложение бизнес- и технических целей, которые Agile Команда или поезд собираются достичь в предстоящем Инкременте Программы (PI).

  • Plan-Do-Check-Adjust, PDCA (Планирование-Выполнение-Проверка-Корректировка)

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

  • Portfolio (Портфель)

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

  • Portfolio Backlog (Бэклог Портфеля)

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

  • Portfolio Canvas (Канва Портфеля)

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

  • Portfolio Kanban (Канбан Портфеля)

    Система Канбан Портфеля — это метод, используемый для визуализации и управления потоком Эпиков портфеля, от идеи (ideation) через анализ, разработку до их завершения.

  • Portfolio SAFe (Портфель SAFe)

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

  • Portfolio Vision (Видение Портфеля)

    Видение Портфеля — это описание будущего состояния Потоков Ценности и Решений, которое описывает, как они будут взаимодействовать для достижения задач портфеля и более широкой цели Предприятия.

  • Pre-and Post-PI Planning (Пре- и Пост- Планирование Инкремента Программы)

    Мероприятия Пре- и Пост- Планирования Инкремента Программы (PI) используются для подготовки к PI Планированиям и последующей обработке их результатов для Релизных Поездов Agile (ARTs) и Поставщиков внутри Поезда Решений.

  • Problem-Solving Workshop (Мастерская Решения Проблем)

    Мастерская Решения Проблем является частью события Инспект-Адапт (I&A) и представляет собой структурированный подход к поиску корневых причин системных проблем.

  • Product Management (Менеджмент Продукта)

    Менеджмент Продукта несет ответственность за определение и поддержку создания востребованных (desirable), осуществимых (feasible), жизнеспособных (viable) и устойчивых (sustainable) продуктов, которые удовлетворяют потребности клиента на протяжении всего жизненного цикла продукта-рынка.

  • Product Owner, PO (Владелец Продукта)

    Владелец Продукта — это член Agile Команды, ответственный за определение Историй и приоритизацию Бэклога Команды для рационализации потока выполнения приоритетов Программы с сохранением концептуальной и технической целостности Фич или компонент для команды.

  • Product Owner (PO) Sync (Синхронизация Владельцев Продукта)

    Синхронизация Владельцев продукта - это мероприятие Релизного Поезда Agile (ART) для получения представления о том, насколько хорошо ART продвигается к достижению Целей Инкремента Программы, обсуждения проблем или возможностей, связанных с разработкой фич, и для оценки объёма возможных корректировок.

  • Program Backlog (Бэклог Программы)

    Бэклог Программы представляет собой хранилище будущих Фич, которые направлены на удовлетворение потребностей пользователей и обеспечение конкурентных преимуществ, для одного Релизного Поезда Agile (ART). Он также содержит Фичи Энейблеры, необходимые для построения Архитектурного Русла.

  • Program Board (Доска Программы)

    Доска Программы отражает даты доставки фич в Инкременте Программы (PI), зависимости между командами по фичам, а также соответствующие вехи.

  • Program Increment, PI (Инкремент Программы)

    Инкремент Программы — это временной интервал, в течение которого Релизный Поезд Agile (ART) доставляет инкрементальную ценность в виде работающего, протестированного программного обеспечения и систем. Продолжительность PI обычно составляет от 8 до 12 недель. Наиболее типовой паттерн PI обычно включает в себя четыре Итерации разработки, за которыми следует Итерация Инноваций и Планирования (IP).

  • Program Increment (PI) Planning (Планирование Инкремента Программы)

    Планирование Инкремента Программы (PI Планирование) — это событие на основе каденции, проводимое «лицом к лицу», которое служит в качестве “сердечного ритма” Релизного Поезда Agile (ART), выравнивая все команды внутри ART в отношении общей миссии и Видения.

  • Program Kanban (Канбан Программы)

    Системы Канбан Программы и Решения являются методом визуализации и управления потоком Фич и Капабилити от идеи к анализу, разработке и выпуску через Конвейер Непрерывной Доставки (CDP).

  • Program Predictability Measure (Мера Предсказуемости Программы)

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

  • Program Risks (Риски Программы)

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

R

  • Refactoring (Рефакторинг)

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

  • Relative Estimation (Относительная Оценка)

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

  • Release on Demand (Выпуск по Требованию)

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

  • Release Train Engineer, RTE (Инженер Релизного Поезда)

    Инженер Релизного Поезда — это лидер-слуга (servant leader) и коуч для Релизного Поезда Agile (ART). Основные обязанности RTE включают в себя фасилитацию мероприятий и процессов ART и помощь командам в доставке ценности. RTE поддерживают связь с заинтересованными лицами (stakeholders), эскалируют препятствия, помогают управлять рисками и стимулируют неустанное улучшение (relentless improvement).

  • Relentless Improvement (Неустанное Улучшение)

    Неустанное Улучшение – четвертая колонна Дома Бережливости SAFe, которая поощряет обучение и развитие через непрерывную рефлексию и улучшения процесса.

  • Roadmap (Дорожная Карта)

    Дорожная Карта представляет собой график событий и Вех, который описывает доставку Решения относительно горизонта планирования.

  • ROAMing Risks (Роуминг рисков)

    Роуминг рисков (от акронима ROAM – Resolved-Owned-Accepted-Mitigated) – активность PI планирования, на которой риски программы, обозначенные командами, адресуются более широкому кругу менеджмента.

  • Root Cause Analysis (Анализ Корневых Причин)

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

S

  • SAFe Big Picture, BP (Большая Картина SAFe)

    Большая Картина SAFe (BP) - это виртуальное представление основных ролей, активностей и артефактов фреймворка, которое используется для доступа к статьям SAFe через интерактивные иконки при просмотре с сайта scaledagileframework.com

  • SAFe for Government (SAFe для Правительства)

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

  • SAFe for Lean Enterprises (SAFe для Бережливых Предприятий)

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

  • SAFe Implementation Roadmap (Дорожная Карта Имплементации SAFe)

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

  • SAFe Lean Startup Cycle (Цикл Бережливого Стартапа SAFe)

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

  • SAFe Program Consultants, SPC (Консультанты Программ SAFe)

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

  • Scrum Master (Скрам Мастер)

    Скрам Мастера — это лидеры-слуги (servant leaders) и коучи Agile Команд. Они помогают команде обучаться в области Скрам, Экстремального Программирования (XP), Канбан и SAFe и следят за соблюдением согласованного Agile процесса. Они также помогают устранять препятствия и создают атмосферу, поощряющую высокоэффективную динамику работы команды, непрерывный поток и неустанное улучшение (relentless improvement).

  • Scrum of Scrums, SoS (Cкрам Скрамов)

    Скрам Скрамов – событие релизного поезда (ART) для помощи в координации зависимостей ART и обеспечения видимости прогресса и препятствий.

  • ScrumXP (СкрамЭкспи)

    ScrumXP — это легковесный процесс доставки ценности для кросс-функциональных, самоорганизующихся команд в SAFe. Он объединяет в себе силу практик управления Скрам с практиками Экстремального Программирования (XP).

  • Set-Based Design, SBD (Множественный Дизайн)

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

  • Shared Services (Общие Сервисы)

    Общие Сервисы представляют собой специализированные роли, людей и услуги, необходимые для успеха Релизного Поезда Agile (ART) или Поезда Решений, которые при этом не могут быть привлечены на постоянной основе.

  • Silos (Силосы)

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

  • Solution (Решение)

    Каждый Поток Ценности производит одно или более Решений, которые представляют собой продукты, сервисы или системы, доставляемые Клиенту, внутреннему или внешнему по отношению к Предприятию.

  • Solution Architect/Engineer (Архитектор/Инженер Решения)

    Архитектор/Инженер Решения отвечает за определение и коммуникацию единого технического и архитектурного видения внутри всего Поезда Решений для обеспечения соответствия разрабатываемой системы или Решения ожидаемому предназначению.

  • Solution Backlog (Бэклог Решения)

    Бэклог Решения представляет собой хранилище для будущих Капабилити и Энейблеров, каждый из которых может разделяться на несколько ART и предназначен для развития Решения и создания его Архитектурного Русла.

  • Solution Context (Контекст Решения)

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

  • Solution Demo (Демо Решения)

    Демо Решения интегрирует усилия по разработке всех Релизных Поездов Agile и поставщиков в Поезде Решения каждый Инкремент Программы и делает их видимыми для Клиентов и других стейкхолдеров для оценки и обратной связи.

  • Solution Intent (Интент Решения, Намерение Решения)

    Интент Решения — это репозиторий для хранения, управления и коммуникации знаний о текущем и ожидаемом поведении Решения. По необходимости включает в себя фиксированные и переменные спецификации и дизайн; ссылки на применимые стандарты, модели систем, функциональные и нефункциональные тесты; трассируемость/прослеживаемость (traceability).

  • Solution Management (Менеджмент Решений)

    Менеджмент Решений отвечает за определение и поддержку создания востребованных (desirable), осуществимых (feasible), жизнеспособных (viable) и устойчивых (sustainable) крупномасштабных бизнес решений, которые будут удовлетворять нуждам клиента в течение времени.

  • Solution Train (Поезд Решений)

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

  • Solution Train Engineer, STE (Инженер Поезда Решений)

    Инженер Поезда Решений — это лидер-слуга (servant leader) и коуч Поезда Решений, который фасилитирует и направляет работу всех ART и Поставщиков в Потоке Ценности.

  • Spanning Palette (Перекрывающая Палитра)

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

  • Spike (Cпайк)

    Cпайк – тип исследовательской Enabler Истории, который направлен на получение знаний, необходимых для снижения риска технической реализации, позволяющий лучше понять требование или повысить достоверность оценки Истори.

  • Sprint (Cпринт)

    Cпринт – термин из фреймворка Скрам, синоним термина "Итерация" в SAFe.

  • Stories (Истории)

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

  • Story Map (Карта Историй)

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

  • Story Point (Сторипоинт)

    Сторипоинт – единица, используемая при относительной оценке историй, представляющая собой комбинацию качеств: объём, сложность, знания и неопределённость.

  • Strategic Themes (Стратегические Темы)

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

  • Sunk Costs (Невозвратные Затраты)

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

  • Supplier (Поставщик)

    Поставщик — внутренняя или внешняя организация, разрабатывающая и поставляющая компоненты, подсистемы или сервисы, которые помогают Поездам Решений и Релизным Поездам Agile (ART) создавать Решения для своих Клиентов.

  • SWOT Analysis (SWOT Анализ)

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

  • System Architect/Engineer (Архитектор/Инженер Систем)

    Архитектор/Инженер Систем отвечает за определение и коммуникацию единого технического и архитектурного видения внутри всего Релизного Поезда Agile (ART), для обеспечения соответствия разрабатываемой системы или Решения ожидаемому предназначению.

  • System Demo (Демо Системы)

    Демо Системы представляет собой важное событие, которое позволяет увидеть новые интегрированные Фичи по результатам последней Итерации всех команд, находящихся в Релизном Поезде Agile (ART). Каждая демонстрация позволяет заинтересованным лицам (stakeholders) ART объективно измерить прогресс во время Инкремента Программы (PI).

  • System Team (Команда Системы)

    Команда Системы — это специализированная Agile Команда, которая помогает создавать и обслуживать среду разработки Agile, как правило, включая разработку и обслуживание набора средств, поддерживающих Конвейер Непрерывной Доставки (CDP). Команда Системы также может поддерживать интеграцию результатов создания ценности (assets) Agile Командами, по необходимости осуществлять сквозное (end-to-end) тестирование Решения и оказывать поддержку развертыванию (deploy) и Выпуску по Требованию.

  • Systems Thinking (Системное Мышление)

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

T

  • Team and Technical Agility (Командная и Техническая Гибкость)

    Компетенция Командная и Техническая Гибкость описывает критические навыки и Lean-Agile принципы и практики, которые высокопроизводительные Agile команды и команды Agile команд используют для создания высококачественных решений для клиентов.

  • Team Backlog (Бэклог Команды)

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

  • Team Kanban (Канбан Команды)

    Канбан Команды — это метод, помогающий командам фасилитировать поток ценности посредством визуализации работ, установки лимитов Незавершенного Производства (НЗП/WIP), измерения пропускной способности (throughput) и непрерывного улучшения их процессов.

  • Team Topologies (Топологии Команд)

    Топологии Команд определяют четыре организационных типа, обеспечивающих единую модель для организации Agile-команд и поездов (ART).

  • Technical Debt (Технический Долг)

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

  • Test-Driven Development, TDD (Разработка на Основе Тестирования)

    Разработка на Основе Тестирования – способ мышления и практики, требующие создания и выполнения тестов до имплементации кода или компоненты системы.

  • TOWs Analysis (TOWS Анализ)

    TOWS Анализ используется в связке со SWOT Анализом как помощь в выявлении стратегических опций для получения лучшего целевого состояния как часть видения SAFe портфеля.

U

  • U-curve Optimization (Оптимизация U-кривой)

    Оптимизация U-кривой для размера партий определяет оптимальный размер партии, балансируя транзакционные издержки и издержки владения.

  • Uncommitted Objectives (Цели без Обязательств)

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

V

  • Value (Ценность)

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

  • Value Stream Coordination (Координация Потоков Ценности)

    Координация Потоков Ценности определяет как управлять зависимостями и реализовать возможности, которые проистекают исключительно из взаимосвязей между потоками ценности.

  • Value Stream Identification (Идентификация Потоков Ценности)

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

  • Value Stream KPIs (Ключевые показатели эффективности Потока Ценности)

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

  • Value Stream Mapping (Картография Потока Ценности)

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

  • Value Streams (Потоки Ценности)

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

  • Velocity (Скорость)

    Скорость равна сумме сторипоинтов по всем завершенным историям, которые удовлетворили соответствущим Определениям Выполненности (DoD).

  • Vision (Видение)

    Видение — описание будущего состояния Решения, находящегося в разработке. Оно отражает потребности Клиентов и заинтересованных лиц (stakeholders), а также Фичи и Капабилити, предлагаемые для удовлетворения этих потребностей.

W

  • Weighted Shortest Job First, WSJF (Взвешенная Кратчайшая Работа Сначала)

    Взвешенная Кратчайшая Работа Сначала — это модель расстановки приоритетов, используемая для определения последовательности выполнения работ (например: Фич, Капабилити, Эпиков) с целью производства максимальной экономической выгоды. В SAFe WSJF рассчитывается как Стоимость Задержки (CoD), поделенная на размер работы.

  • Work in Process, WIP (Незавершенная Работа)

    Незавершенная Работа (WIP) представляет собой частично выполненную работу, избыточное количество которой затрудняет приоритизацию, вызывает частое переключение контекста и повышает накладные расходы.

5

  • 5 Whys (5 Почему)

    5 Почему - это проверенная техника решения проблем, используемая для изучения причинно-следственных связей, лежащих в основе конкретной проблемы в рамках мероприятия Инспект-Адапт (I&A).

© 2022 Scaled Agile, Inc. All rights reserved.