SAFe Glossary

A

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

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

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

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

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

B

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

Практики Встроенного Качества обеспечивают соответствие каждого элемента Решения в каждом инкременте необходимым стандартам качества на протяжении всей разработки.
Business Agility (Бизнес Гибкость/Бизнес Проворность)

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

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

C

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

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

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

Соответствие (регуляторное, нормативно-правовое, корпоративное и иное) подразумевает под собой стратегию, набор действий и артефактов (документов), которые позволяют командам применять Lean-Agile методы разработки для построения систем максимально возможно высокого качества, одновременно обеспечивая их соответствие регуляторным, отраслевым и прочим необходимым стандартам.
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.
Customer (Клиент)

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

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

D

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

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

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

E

Enablers (Энейблер)

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

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

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

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

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

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

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

F

Feature (Фича)

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

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

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

I

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

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

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

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

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

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

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

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

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

L

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

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

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

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

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

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

M

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

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

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

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

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

N

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

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

O

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

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

P

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

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

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

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

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

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

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

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

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

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

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

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

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

R

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

Выпуск по Требованию — это процесс переноса новой функциональности в промышленную среду а также немедленного либо инкрементального её выпуска для клиентов по запросу.
Release Train Engineer, RTE (Инженер Релизного Поезда)

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

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

S

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

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

SAFe для Бережливых Предприятий — это база знаний проверенных, интегрированных принципов, практик и компетенций для достижения бизнес гибкости с помощью Lean, Agile и DevOps в масштабе.
SAFe Implementation Roadmap (Дорожная Карта Имплементации SAFe)

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

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

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

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

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

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

Каждый Поток Ценности производит одно или более Решений, которые представляют собой продукты, сервисы или системы, доставляемые Клиенту, внутреннему или внешнему по отношению к Предприятию.
Solution Architect/Engineer (Архитектор/Инженер Решения)

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

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

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

Демо Решения позволяет интегрировать, оценивать и наглядно демонстрировать Клиентам и другим заинтересованным лицам (stakeholders) усилия по разработке в рамках Поезда Решений.
Solution Intent (Интент Решения, Намерение Решения)

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

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

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

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

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

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

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

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

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

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

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

T

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

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

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

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

V

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

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

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

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

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

W

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

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

Authors

A

B

C

D

E

F

I

L

M

N

O

P

R

S

T

V

W

CONTACT US

Business Hours