© 2021 Scaled Agile, Inc. All rights reserved.

Clear explanations and actionable guidance

SAFe Distilled 5.0

SAVE 35% WITH CODE SCALEDAGILE

ORDER NOW

Remote-Enabled SAFe: Tools & Resources

Learn More

SAFe Glossary

Authors

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), поделенная на размер работы.

© 2021 Scaled Agile, Inc. All rights reserved.