© 2024 Scaled Agile, Inc. All rights reserved.

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Learn More

Evolving the Scaled Agile Framework:

Update to SAFe 5

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

Learn more

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.

5

  • 5 Whys (5 Why)

    5 Why는 검사 및 적응[Inspect and Adapt]에서 특정 문제의 기저에 있는 인과 관계[cause-and-effect]를 탐색할 때 사용하는 검증된 문제 해결 기법입니다.

A

  • Acceptance Criteria (승인 기준)

    승인 기준[Acceptance Criteria]은 스토리[Story], 피처[Feature] 또는 케이퍼빌러티[Capability]를 올바르게 구현하고 관련 기능 및 NFR[Nonfunctional Requirements]이 포함되도록 하는 데 필요한 정보를 제공합니다.

  • Acceptance Test Driven Development (인수 테스트 주도 개발)

    인수 테스트 주도 개발[ATDD, Acceptance Test Driven Development]은 테스트 우선의 애자일 테스트 프랙티스로, 행위 주도 개발[BDD, Behavior-Driven Development]과 동의어입니다.

  • Agile (애자일)

    애자일[Agile]은 애자일 매니페스토에서 가장 명확하게 설명된 반복[iterative] 개발의 가치, 원칙, 프랙티스 모음을 말합니다.

  • Agile Manifesto (애자일 매니페스토)

    애자일 매니페스토[Agile Manifesto]는 애자일 소프트웨어 개발의 4가지 가치와 12가지 원칙을 설명하는 중요한 애자일 문서입니다.

  • Agile Product Delivery (애자일 제품 전달)

    애자일 제품 전달은 고객과 사용자에게 가치 있는 제품과 서비스[Service]를 연속적인 흐름으로 정의[Defining], 구축[Building] 및 릴리스[Releasing]하기 위한 고객 중심 접근방식[Approach]입니다.

  • Agile Program Management Office (애자일 PMO)

    애자일 PMO[APMO, Agile Program Management Office]는 린-애자일 트랜스포메이션의 일환으로 Lean Portfolio Management 프로세스를 촉진하고 운영 우수성과 린 거버넌스[lean governance]를 증진하는 책임을 가진 조직의 역할입니다.

  • Agile Release Train, ART (애자일 릴리스 트레인)

    애자일 릴리스 트레인은 장기간 지속되는 애자일 팀[Agile team]으로서 다른 이해관계자들과 함께 가치 흐름 내에서 하나 이상의 솔루션[Solution]을 점진적으로[Incrementally] 개발[Develop], 전달[Deliver]하고 필요하다면 운영[Operate]합니다.

  • Agile Team (애자일 팀)

    SAFe에서 애자일 팀은 5-11명으로 구성된 교차-기능 그룹[Cross-Functional Group]으로서 짧은 타임 박스[Time Box] 내에 가치의 증분을 정의[Define], 구축[Build], 테스트[Test] 및 전달[Deliver]합니다.

  • Architect Sync (아키텍트 싱크)

    아키텍트 싱크[Architect Sync]는 솔루션 트레인[Solution Train]에서 새로운 설계 및 상충관계[Tradeoff]를 일관된 방식으로 관리하기 위한 솔루션 트레인 이벤트로서, 이를 이용하면 지연[delay]을 유발하지 않고 구현 방식을 조정할 수 있는 기회를 많이 가지게 됩니다.

  • Architectural Runway (아키텍처 런웨이)

    아키텍처 런웨이는 과도한 재설계와 지연없이 단기 피처[Feature]를 구현하는데 필요한 기존 코드, 구성요소 및 기술 인프라스트럭처[Technical Infrastructure]로 구성됩니다.

  • ART Sync (ART 싱크)

    ART 싱크[ART Sync]는 제품 책임자[PO, Product Owner] 싱크와 스크럼의 스크럼[SoS, Scrum of Scrums]을 결합한 ART 이벤트입니다.

B

  • Backlog Refinement (백로그 개선)

    백로그 개선[Backlog Refinement]은 팀 백로그에서 앞으로 진행할 스토리에 대한 승인 기준[acceptance criteria]을 논의 및 추정하고 기본적인 이해를 구축하기 위해 이터레이션[iteration] 또는 증분[increment] 동안 한두 번 수행하는 활동입니다.

  • Baseline Solution Investments (베이스라인 솔루션 투자(BSI))

    베이스라인 솔루션 투자[BSI, Baseline Solution Investment]는 각 가치 흐름[value stream]에서 현재 비즈니스 케이퍼빌러티를 전달하는 솔루션을 개발, 지원, 운영하는데 발생하는 비용입니다.

  • Batch Size (배치 크기)

    배치 크기[Batch Size]는 주어진 타임박스[timebox]동안 시스템으로 가져오는 작업량(요구 사항, 설계, 코드, 테스트 및 기타 작업 항목)을 측정한 것입니다.

  • Behavior-Driven Development(행위 주도 개발(BDD))

    행위 주도 개발[BDD, Behavior-Driven Development]은 테스트 우선[test-first]의 애자일 테스트 프랙티스로, 시스템 행위를 지정하기 이전이나 지정하는 과정에서 테스트를 정의함으로써 품질 내재화[built-in quality] 및 잠재적인 자동화[Automating]를 제공합니다.

  • Benefit Hypothesis (이익 가설)

    이익 가설[Benefit Hypothesis]은 피처 또는 케이퍼빌러티의 요소로서 최종 사용자 또는 비즈니스에서 얻게 될 것으로 예상되는 측정 가능한 이익입니다.

  • Big Visible Information Radiator (빅 비저블 인포메이션 래디에이터(BVIR))

    빅 비저블 인포메이션 래디에이터[BVIR, Big Visible Information Radiator]는 중요한 데이터를 한눈에 추적하고 소통할 수 있는 그래픽 디스플레이입니다(예: 번다운 차트, 프로그램 보드, 빌드 상태 보드).

  • Built-In Quality (품질 내재화)

    품질 내재화 프랙티스[Practice]는 각 솔루션[Solution] 요소가 매 증분[Increment]마다 개발 전반에 걸쳐 적절한 품질 표준을 만족하도록 보장합니다.

  • Burn-Down (Burn-Up) Chart (번다운/번업 차트)

    번다운 차트와 번업 차트[Bun-Down/Burn-Up]는 시간에 따른 작업 진행률을 표시하는 그래픽 디스플레이입니다.

  • Business Agility (비즈니스 애질리티)

    비즈니스 애질리티[Business Agility]는 혁신적인, 디지털을 활용한[Digitally-Enabled] 비즈니스 솔루션[Business Solution]으로 시장 변화와 새로운 기회[Emerging Opportunities]에 신속하게 대응함으로써 디지털 시대에 경쟁하고 번창[Thrive]할 수 있는 능력입니다.

  • Business and Technology (비즈니스 및 기술)

    SAFe의 비즈니스 및 기술 아이콘은, 엔터프라이즈 전반에 존재하는 기능 도메인이 린-애자일 원칙과 프랙티스를 엔터프라이즈 상황에 맞게 적용하는 새로운 방법을 지속적으로 탐색하여, 어떻게 비즈니스 애질리티[Business Agility]를 지원하는지를 설명합니다.

  • Business Context (비즈니스 컨텍스트)

    비즈니스 컨텍스트[Business Context]는 비즈니스 책임자가 제시하는 PI 계획수립 일정표 항목으로, 비즈니스의 현재 상태를 설명하고 포트폴리오 비전을 공유하며 기존 솔루션이 현재 고객의 요구를 얼마나 효과적으로 충족시키고 있는지에 대한 관점을 제시합니다.

  • Business Owners (비즈니스 책임자)

    비즈니스 책임자는 애자일 릴리스 트레인[Agile Release Train (ART)]이 개발한 솔루션의 거버넌스[Governance], 컴플라이언스[Compliance] 및 투자수익률[Return on Investment (ROI)]에 대한 주요 비즈니스 및 기술적 책임이 있는 소규모의 이해관계자 그룹[Group]입니다. 이들은 사용 적합성을 평가하고 특정 애자일 릴리스 트레인 이벤트[Event]에 적극적으로 참여해야 하는 애자일 릴리스 트레인의 핵심 이해관계자[Key Stakeholder]입니다.

C

  • CALMR

    데브옵스에 대한 SAFe의 CALMR 접근 방식은 가치 전달 문화, 자동화, 린 흐름, 측정 및 복구의 동시적 개선을 관리하여 ART가 지속적 가치 전달을 이룰 수 있도록 안내하는 사고방식입니다.

  • Capabilities (케이퍼빌러티)

    케이퍼빌러티는 일반적으로 여러 애자일 릴리스 트레인[Agile Release Trains (ART)]에 걸쳐 있는 더 높은 레벨[Higher-Level]의 솔루션[Solution]을 확보하기 위한 행위[Behavior]입니다. 케이퍼빌러티는 단일 프로그램 중분[Single Program Increment] 내에서 쉽게 구현할 수 있도록 크기를 조정하고 여러 피처[Multiple Features]로 분할합니다.

  • Capacity Allocation (작업가능량 할당)

    작업가능량 할당[Capacity Allocation]은 백로그에 대한 린 방식의 예산수립 가드레일[lean budgeting guardrail]로, 새로운 피처, 인에이블러 및 예정된 PI를 위해 할당된 기술 부채[technical debt]의 백로그 균형을 조정하는 데 도움이 됩니다.

  • Committed PI Objectives (달성가능 PI 목표)

    달성가능 PI 목표[Committed PI Objectives]는 비즈니스 책임자가 할당한 비즈니스 가치를 반영하여 각 팀에서 만든 SMART 목표 모음입니다.

  • Communities of Practice, CoPs (전문가 모임)

    전문가 모임은 특정 기술 또는 비즈니스 영역[Domain]에 대한 공통적인 관심을 갖고 있는 사람들로 이루어진 그룹[Group]입니다. 이들은 정기적으로 협력하여 정보를 공유하고, 기술을 향상시키며, 해당 영역의 일반적인 지식을 발전시키기 위해 적극적으로 노력합니다.

  • Compliance (컴플라이언스)

    컴플라이언스란 팀이 린-애자일[Lean-Agile] 개발 방법을 적용하여 가능한 최고 품질의 시스템을 구축하면서 동시에 규제[Regulatory], 산업[Industry], 기타 관련 표준[Standards]을 만족하도록 하는 전략 및 일련의 활동과 산출물[Artifact]을 의미합니다.

  • Confidence Vote (자신감 투표)

    자신감 투표[Confidence Vote]는 각 팀이 PI 목표 달성에 대한 자신감을 투표로 확인하는 것으로, PI 계획수립 막바지에 진행됩니다.

  • Continuous Delivery Pipeline, CDP (지속적 전달 파이프라인)

    지속적 전달 파이프라인은 아이디어 생성[Ideation]에서 릴리스 온 디맨드[Release On-Demand]에 이르기까지 최종 사용자에게 새로운 기능[Functionality]을 제공하는데 필요한 업무흐름[Workflow], 활동 및 자동화[Automation]를 나타냅니다.

  • Continuous Deployment, CD (지속적 배포)

    지속적 배포는 스테이징[Staging] 환경에서 검증된 피처[Feature]를 가져와 출시[Release]가 준비된 운영 환경[Production Environment]에 배치[Deploy]하는 프로세스[Process]입니다.

  • Continuous Exploration, CE (지속적 탐색)

    지속적 탐색은 시장과 고객의 요구를 지속적으로 탐색하고, 이런 요구를 해결하는 솔루션의 비전[Vision], 로드맵[Roadmap], 일련의 피처[Set of Features]를 정의하여 혁신[Innovation]을 이끌고 구축해야 할 사항에 대한 얼라인먼트[Alignment]를 촉진[Foster]하는 과정입니다.

  • Continuous Integration, CI (지속적 통합)

    지속적 통합은 프로그램 백로그[Backlog]에서 피처[Feature]를 가져와 배치[Deployment]와 출시[Release] 준비가 된 운영검증[Staging] 환경에서 이 피처[Features]를 개발, 테스트, 통합 및 검증하는 프로세스[Process]입니다.

  • Continuous Learning Culture (지속적인 학습 문화)

    지속적인 학습 문화 역량[Competency]은 개인[Individual] 및 엔터프라이즈 전체가 지식[Knowledge], 역량[Competence], 성과[Performance] 및 혁신[Innovation]을 지속적으로 증가하도록 장려하는 일련의 가치[Value]와 프랙티스[Practice]입니다.

  • Core Values (핵심 가치)

    얼라인먼트[Alignment], 품질 내재화[Built-In Quality], 투명성[Transparency], 프로그램 실행[Program Execution]의 네 가지 핵심 가치는 SAFe의 효과성에 핵심이 되는 기본 신념[Belief]을 의미합니다. 이런 지침 원칙은 SAFe 포트폴리오[Portfolio]에 참여하는 모든 사람들의 행위[Behavior]와 행동[Action]을 좌우하는[Dictate] 데 도움이 됩니다.

  • Cost of Delay (지연 비용)

    지연 비용[CoD, Cost of Delay]은 일정 기간 작업을 지연하거나 작업을 하지 않아 상실되는 비용 또는 가치를 나타내며, 가중치를 고려한 최단 작업 먼저하기[WSJF, Weighted Shortest Job First]의 우선순위를 지정할 때 사용됩니다.

  • Customer (고객)

    고객은 포트폴리오 가치 흐름[Portfolio Value Stream]에 의해 창출 및 유지되는 비즈니스 솔루션[Business Solution]의 가치를 누리는 궁극적인 수혜자[Ultimate Beneficiaries]입니다.

  • Customer Centricity (고객 중심)

    고객 중심은 엔터프라이즈[Enterprise]가 제공하는 모든 제품과 서비스를 통해 고객에게 긍정적인 경험을 선사하는 데 중점을 둔 사고방식[Mindset]이자 사업 방법[Way of Doing Business]입니다.

  • Customer Journey Map (커스터머 저니 맵)

    커스터머 저니 맵[Customer Journey Map]은 사용자가 회사의 운영 가치 흐름, 제품, 서비스에 참여할 때의 경험을 나타냅니다

D

  • Daily Stand-Up (데일리 스탠드업)

    데일리 스탠드업[DSU, Daily Stand-Up]은 각 팀원이 이터레이션 목표[iteration goal]를 진전시키기 위해 어제 했던 활동, 이터레이션 목표를 달성하기 위해 오늘 할 활동, 이터레이션 목표 달성의 장애물[block]을 설명하는 일일 팀 이벤트입니다.

  • Decentralized Decision-Making (의사결정권 분산)

    의사결정권 분산[Decentralized Decision-Making]은 지식과 정보에 가장 가까운 구성원에게 의사결정 권한을 부여함으로써 지연[delay]을 줄이고, 제품 개발 흐름을 촉진하며, 의사 결정의 품질을 개선합니다.

  • Definition of Done (완료 기준)

    완료 기준[DoD, Definition of Done]은 가치 증분[increment]의 완료를 소통하고 증분을 통해 완료된 작업에 대한 이해를 공유합니다.

  • Design Thinking (디자인 씽킹)

    디자인 씽킹은 제품 수명주기[Lifecycle] 전체에 걸쳐 수익성[Profitable]이 있고 지속 가능한[Sustainable] 바람직한 제품[Desirable Product]을 만드는 고객 중심[Customer Centric]의 개발 과정입니다.

  • Develop on Cadence (일정한 개발주기)

    일정한 개발주기[Develop on Cadence]는 정기적이고 예측 가능한 일정에 따라 발생하는 일련의 신뢰할 수 있는 이벤트와 활동을 제공함으로써 애자일 팀을 지원하는 잘 조정된 프랙티스 모음입니다.

  • Development Value Streams (개발 가치 흐름)

    개발 가치 흐름(DVS)은 비즈니스 가설을 디지털 기반[Digitally-Enabled] 솔루션으로 실체화 시키는 데 필요한 순차적 활동입니다. 예를 들면 의료 기기 또는 지형 위성 등의 설계, 소프트웨어 애플리케이션, SaaS 시스템 또는 전자 상거래 웹 사이트 등에 대한 개발 및 배포가 있습니다.

  • DevOps (데브옵스: Development(개발) + Operations(운영))

    데브옵스는 사고방식[Mindset], 문화[Culture], 그리고 일련의 기술적 프랙티스[Technical Practice]입니다. 데브옵스는 솔루션을 계획[Plan], 개발[Develop], 테스트[Test], 배치[Deploy], 릴리스[Release] 및 유지관리[Maintain]에 필요한 모든 사람 간의 소통[Communication], 통합[Integration], 자동화[Automation] 그리고 긴밀한 협력[Cooperation]을 제공합니다.

E

  • Empathy Map (엠퍼시 맵)

    엠퍼시 맵[Empathy Map]은 팀이 고객에 대한 깊게 공유된 이해를 도출할 수 있도록 하는 디자인 씽킹 도구입니다.

  • Enablers (인에이블러)

    인에이블러는 향후 비즈니스 기능[Functionality]을 제공하기 위하여 아키텍처 런웨이[Architectural Runway]를 확대하는 데 필요한 활동을 지원합니다. 여기에는 탐색[Exploration], 아키텍처[Architecture], 인프라스트럭처[Infrastructure] 및 컴플라이언스[Compliance]가 포함됩니다. 인에이블러는 다양한(포트폴리오[Portfolio], 솔루션[Solution], 프로그램[Program], 팀[Team]) 백로그[Backlog]에서 포착[Capture]되며 프레임워크(Framework) 전체에서 발생합니다.

  • Enterprise (엔터프라이즈)

    엔터프라이즈는 각 SAFe 포트폴리오[SAFe Portfolio]가 속한 비즈니스 엔터티[Business Entity]를 의미합니다.

  • Enterprise Architect (엔터프라이즈 아키텍트)

    엔터프라이즈 아키텍트는 포트폴리오[Portfolio]가 현재 및 미래의 비즈니스 케이퍼빌러티[Capability]를 지원할 수 있도록 기술 전략[Technology Strategy] 및 로드맵[Roadmap]을 수립합니다.

  • Enterprise Solution Delivery (엔터프라이즈 솔루션 전달)

    엔터프라이즈 솔루션 전달 역량[Competency]은 세계 최대 규모의 복잡한[Sophisticated] 소프트웨어 애플리케이션, 네트워크, 가상-물리적[Cyber-Physical] 시스템의 사양[Specification], 개발[Development], 배치[Deployment], 운영[Operation] 및 진화[Evolution]에 린-애자일[Lean-Agile] 원칙[Principle]과 프랙티스[Practice]를 적용하는 방법을 설명합니다.

  • Epic Hypothesis Statement (에픽 가설)

    에픽 가설[Epic Hypothesis Statement]은 에픽에 관한 중요 정보를 포착, 구성, 소통합니다.

  • Epic Owners (에픽 책임자)

    에픽 책임자는 포트폴리오 칸반[Portfolio Kanban] 시스템을 통해 포트폴리오 에픽[Portfolio Epic]을 조정[Coordinate]할 책임이 있습니다. 에픽 책임자는 에픽과 최소 판매 가능 제품[Minimum Viable Product (MVP)]및 린-비즈니스 사례[Lean Business Case]를 함께 정의하고, 승인된 경우 구현[Implementation]을 촉진합니다.

  • Epics (에픽)

    에픽은 포트폴리오[Portfolio] 내에서 발생하는 보다 실질적인 투자[Investment]를 포착하는 중요한 솔루션 개발 계획[Solution Development Initiative]을 위한 컨테이너[Container]입니다. 에픽은 상당한 범위와 영향 때문에 구현하기 전에 최소 판매 가능 제품[Minimum Viable Product (MVP)]의 정의와 Lean Portfolio Management (LPM)의 승인을 필요로 합니다.

  • Essential SAFe (에센셜 SAFe)

    에센셜 SAFe 구성[Configuration]은 애자일 팀들의 팀[Team of Agile Teams]으로서 애자일 릴리스 트레인[Agile Release Train (ART)]을 통해 비즈니스 솔루션을 지속적으로 제공하는 데 필요한 최소한의 역할[Role], 이벤트[Event] 및 산출물[Artifact]을 포함하고 있습니다.

  • Estimating Poker (추정 포커)

    추정 포커[Estimating Poker]는 SAFe에서 스토리, 피처, WSJF의 크기를 상대적으로 추정하기 위한 협업 기술입니다.

  • Extreme Programming (익스트림 프로그래밍)

    익스트림 프로그래밍[XP, Extreme Programming]은 소프트웨어 품질 개선 및 변화하는 고객 요구사항에 대한 대응성을 개선하는 애자일 소프트웨어 공학[Agile Software Engineering] 프랙티스로 켄트 벡[Kent Beck]이 주도적으로 개발했습니다.

F

  • Features (피처)

    피처는 이해관계자[Stakeholder]의 요구[Need]를 충족[Fulfill]시키는 서비스[Service]입니다. 각 피처[Feature]에는 이익 가설[Benefit Hypothesis] 및 승인 기준[Acceptance Criteria]을 포함하며, 필요에 따라 크기를 조정하거나 분할하여 PI[Program Increment (PI)] 기간 동안 단일 애자일 릴리스 트레인[Agile Release Train (ART)]에 의해 제공됩니다.

  • Final Plan Review (최종 계획 평가)

    PI 계획수립 중 최종 계획 평가[Final Plan Review] 활동에서는 각 팀이 최종 계획(PI 목표, 예상작업량, 리스크)을 제시하며, 이를 ART에 전달하고 비즈니스 책임자의 승인을 받습니다.

  • Foundation (기반)

    기반에는 규모를 고려하여 가치를 성공적으로 제공하는 데 필요한 지원 원칙[Supporting Principle], 가치[Value], 사고방식[Mindset], 구현 지침[Implementation Guidance], 리더십 역할[Leadership Role]이 포함되어 있습니다.

  • Full SAFe (풀 SAFe)

    풀 SAFe는 비즈니스 애질리티[Business Agility]에 필요한 일곱 가지 핵심 역량[Core Competency]을 포함하는 가장 포괄적인 구성[Comprehensive Configuration]입니다.

G

  • Gemba (현장)

    현장[Gemba]은 작업이 수행되는 장소이자 팀이 끊임없는 개선의 기회를 더 잘 식별하기 위해 이해관계자가 운영 가치 흐름의 특정 활동과 단계를 어떻게 실행하는지 관찰할 수 있는 장소입니다.

H

  • Hackathon (해커톤)

    해커톤[Hackathon]은 팀원들이 누구든 원하는 사람과 함께 무엇이든 원하는 작업을 할 수 있는 혁신 이벤트입니다. 단, 기업 사명을 반영한 작업이어야 하며 해커톤을 마칠 때 작업 결과를 시연할 수 있어야 합니다.

I

  • Innovation and Planning Iteration, IP Iteration (혁신 및 계획수립 이터레이션)

    혁신 및 계획수립 이터레이션은 모든 PI[Program Increment (PI)]마다 발생하며 다양한 목적을 수행합니다. 이는 PI 목표[PI Objective]를 달성하기 위한 추정 여유[Estimating Buffer] 역할을 하며 혁신[Innovation], 지속적인 교육[Continuous Education], PI 계획수립[PI Planning], 검사 및 적응[Inspect and Adapt(I&A)] 이벤트[Event]를 위한 전용[Dedicated] 시간을 제공합니다.

  • Inspect & Adapt, I&A (검사 및 적응)

    검사 및 적응은 각 PI[Program Increment]의 끝에서 이루어지는 중요한 이벤트로, 애자일 릴리스 트레인[Agile Release Train (ART)]에 의해 현재 솔루션[Solution]의 상태가 시연되고 평가됩니다. 그런 다음 팀은 구조화된 문제해결 워크숍[Problem-Solving Workshop]를 통해 개선 백로그[Improvement Backlog] 항목을 반영하고 식별합니다.

  • Integration Point (통합 시점)

    통합 시점[Integration Point]은 다양한 솔루션 요소를 통합된 환경으로 '가져오는 이벤트'를 만들어, 이해 관계자들이 진화하는 솔루션으로 실질적인 비즈니스 요구사항과 미래의 요구사항을 해결할 수 있도록 합니다.

  • Investment Horizons (투자 영역 구분)

    투자 영역 구분[Investment Horizons]은 가치 흐름에서 생성된 솔루션에 대한 비용 할당을 강조합니다. 해당하는 가치 흐름은 가치 흐름 책임자와 수탁자가 정보에 입각하여 현명한 투자 결정을 내리고 전략 테마에 맞춰 포트폴리오를 조정하는 동시에 전반적인 상태와 성장을 촉진하는 데 도움이 됩니다.

  • Iteration (이터레이션)

    이터레이션은 애자일[Agile] 개발의 기본 구성 요소입니다. 각 이터레이션은 고정된-길이의 타임박스[Timebox] 및 표준으로 애자일 팀은 작업하고, 측정한 소프트웨어 및 시스템의 형태로 증분 가치[Incremental Value]를 제공합니다. 제한된 시간의 권장 기간은 2 주입니다. 그러나 비즈니스 컨텍스트[Business Context]에 따라 1 주에서 4 주도 허용됩니다.

  • Iteration Execution (이터레이션 실행)

    이터레이션 실행은 애자일 팀[Agile Team]이 이터레이션의 타임박스[Timebox] 전체에 걸쳐 팀의 작업을 관리하는 방법으로서 고품질[High-Quality]의, 동작하고[Working], 테스트가 완료된 시스템 증분[System Increment]을 만듭니다.

  • Iteration Goals (이터레이션 목표)

    이터레이션 목표는 애자일 팀[Agile Team]이 이터레이션을 통해 달성하기로 합의한 비즈니스 및 기술 목표를 높은-수준으로 요약[High-Level Summary]한 것입니다. 이는 애자일 릴리스 트레인[Agile Release Train (ART)]을 자기 조직화[Self-Organizing] 및 자기 관리[Self-Managing]하는 팀으로 구성하는 데 필수적입니다.

  • Iteration Planning (이터레이션 계획수립)

    이터레이션 계획수립이란 모든 팀 구성원이 다음 이터레이션 동안 얼마나 많은 팀 백로그[Team Backlog]를 전달[Delivery]할 수 있는지를 결정하는 이벤트입니다. 팀은 작업을 약속된 일련의 이터레이션 목표[Iteration Goal]로 요약합니다.

  • Iteration Retrospective (이터레이션 회고)

    이터레이션 회고[Iteration Retrospective]는 애자일 팀 구성원들이 이터레이션 결과를 논의하고, 자신들의 프랙티스[Practice]를 검토하고, 개선할 방법을 식별[Identify]하는 정기적인 이벤트입니다.

  • Iteration Review (이터레이션 리뷰)

    이터레이션 리뷰는 일정한 주기[Cadence] 기반의 이벤트로서 각 팀은 모든 이터레이션이 끝날 때마다 증분[Increment]을 검사[Inspect]하여 진행 상황을 평가한 후 다음 이터레이션에 대한 백로그를 조정합니다.

K

  • Knowledge Worker (지식 근로자)

    지식 근로자[Knowledge Workers]는 관심 영역의 복잡한 문제를 해결하는 데 필요한 기술 및 전문 지식을 갖추고 관련된 훈련을 받은 사람입니다.

L

  • Large Solution SAFe (라지 솔루션 SAFe)

    라지 솔루션 SAFe 구성[Configuration]은 세계 최대 규모의 애플리케이션, 네트워크 및 가상-물리적[Cyber-Physical]시스템을 구축하고 발전시키기 위한 추가 역할[Additional Role], 프랙티스[Practice] 및 지침[Guidance]을 설명합니다.

  • Lead Time (리드 타임)

    리드 타임[Lead Time]은 이전 단계에서 작업이 완료된 시점부터 현재 단계에서 작업이 완료될 때까지 걸리는 시간입니다.

  • Lean (린)

    린[Lean]은 지연을 줄이고 부가 가치가 없는 활동을 제거하여 효율성과 효과성을 개선하기 위한 지식과 프랙티스의 모음입니다.

  • Lean Budget Guardrails (린 예산 가드레일)

    린 예산 가드레일은 특정 포트폴리오의 예산[Budgeting], 지출[Spending] 및 거버넌스[Governance]에 대한 정책[Policy]과 프랙티스[Practice]를 설명합니다.

  • Lean Budget (린 예산)

    린 예산은 프로젝트 비용 회계[Cost Accounting]와 관련된 간접비[Overhead] 및 비용을 줄여 처리량[Throughput]과 생산성[Productivity]을 높이는 재무적 거버넌스[Financial Governance]에 대한 린-애자일 접근방식[Lean-Agile Approach]입니다.

  • Lean Business Case (린 비즈니스 케이스)

    린 비즈니스 케이스[LBC, Lean Business Case]는 MVP와 예상 비즈니스 가치 등 에픽을 설명하는 간단한 접근 방식입니다.

  • Lean Governance (린 거버넌스)

    린 거버넌스[Lean Governance]는 지출[spending], 감사[audit] 및 컴플라이언스[Compliance], 비용[expenses] 예측, 측정[measurement]에 대한 감독과 의사결정을 지원하는 린 포트폴리오 관리의 한 부분입니다.

  • Lean Portfolio Management (린 포트폴리오 관리)

    Lean Portfolio Management 역량[Competency]은 전략 및 투자 자금 조달[Funding], 애자일 포트폴리오 운영 및 거버넌스에 린[Lean] 및 시스템 씽킹 접근방식[System Thinking Approach]을 적용하여 전략 및 실행을 조정[Align]합니다.

  • Lean Quality Management System (린 품질 관리 시스템(QMS))

    품질 관리 시스템[QMS, Quality Management System]은 안전성과 효능[efficacy]을 확인하는 데 필요한 프랙티스, 정책[policy], 절차[procedure]를 규정합니다. SAFe 조직은 전통적인[traditional] QMS에서 린 QMS 거버넌스로 전환합니다.

  • Lean User Experience, Lean UX (린 사용자 경험)

    린 사용자 경험 설계[Design]는 린-애자일[Lean-Agile] 방법을 수용하는 사고방식[Mindset], 문화[Culture], 프로세스[Process]입니다. 최소 판매 가능 증분[Minimum Viable Increment]으로 기능성[Functionality]을 구현하고 이익 가설[Benefit Hypothesis]에 대한 결과를 측정하여 성공을 결정합니다.

  • Lean-Agile Center of Excellence (린 애자일 변화관리 팀)

    린 애자일 변화관리 팀[LACE, Lean-Agile Center of Excellence]은 SAFe 린 애자일 작업 방식의 구현[implementing]을 전담하는 소규모 팀입니다.

  • Lean-Agile Leadership (린-애자일 리더십)

    린-애자일 리더십 역량[Competency]은 린-애자일 리더[Lean-Agile Leader]가 어떻게 개인과 팀이 최고의 잠재력을 발휘할 수 있도록 권한을 부여하여 조직의 변화와 운영의 우수성을 추구하고 유지할 수 있는지 설명합니다.

  • Lean-Agile Mindset (린-애자일 사고방식)

    린-애자일 사고방식은 애자일 매니페스토[Agile Manifesto]와 린 씽킹[Lean thinking]의 개념을 수용하는 SAFe 리더와 실무자들의 신념[Belief], 가정[Assumption], 태도[Attitude], 행동[Action]의 조합입니다. 이는 SAFe의 원칙[Principle]과 프랙티스[Practice]를 채택하고 적용하기 위한 개인적[Individual], 지적[Intellectual], 리더십 기반[Leadership Foundation]입니다.

  • Lean-Agile Principles (린-애자일 원칙)

    SAFe는 열 가지 고정불변[Immutable]의 기초가 되는 린-애자일[Lean-Agile] 원칙을 기반으로 합니다. 이런 신조[Tenet]와 경제 개념은 SAFe의 역할과 프랙티스[Practice]에 영감을 주고 정보를 제공합니다.

  • Little's Law (리틀의 법칙)

    리틀의 법칙[Little's Law]은 시스템의 평균 대기 시간이 평균 대기열[queue] 길이를 평균 프로세스 속도로 나눈 비율과 같다는 대기열 이론[queuing theory]의 법칙입니다.

M

  • Measure And Grow (측정 및 성장)

    측정 및 성장은 포트폴리오가 비즈니스 애질리티[Business Agility]에 대한 진행 상황을 평가하고 다음 개선 단계를 결정하는 방법입니다.

  • Metrics (기준)

    기준은 조직이 포트폴리오[Portfolio], 대규모 솔루션[Large Solution], 프로그램[Program], 팀[Team]의 비즈니스 및 기술 목표를 얼마나 잘 달성하고 있는지 평가하는 데 사용되는 합의된 측정 척도[Agree-upon Measure]입니다.

  • Milestones (이정표)

    이정표는 특정 목표[Goal] 또는 이벤트[Event]에 대한 진행 상황을 추적하는 데 사용됩니다. SAFe 이정표의 유형은 다음 세 가지입니다: PI[Program Increment(PI)], 고정-날짜[Fixed-Date], 학습[Learning] 이정표.

  • Minimum Marketable Feature (미니멈 마케터블 피처)

    미니멈 마케터블 피처[MMF, Minimum Marketable Feature]는 피처의 이익 가설이 유효한지 확인하기 위해 팀에서 구축할 수 있는 최소한의 기능[functionality]입니다.

  • Minimum Viable Product (최소 판매 가능 제품)

    SAFe에서 최소 판매 가능 제품[MVP, Minimum Viable Product]은 에픽 가설을 입증 또는 반증하는 데 사용되는 신제품 또는 비즈니스 솔루션의 초기 및 최소 버전입니다. MVP는 스토리보드, 프로토타입, 목업[mockup], 와이어프레임, 기타 탐색[exploratory] 기법과 달리 실제 고객이 검증된[validated] 학습을 생성하기 위해 사용하는 실제 제품[actual product]입니다.

  • Model-Based Systems Engineering (MBSE: 모델 기반 시스템 엔지니어링)

    모델 기반 시스템 엔지니어링은 개발 중인 시스템을 정의[Define], 설계[Design], 문서화[Document]하는 데 도움이 되는 일련의 관련 시스템 모델을 개발하는 프랙티스입니다. 이런 모형은 전통적인 문서에 대한 의존도를 크게 줄이거나 제거하면서 이해관계자들이 시스템 측면을 탐색[Explore], 갱신[Update], 소통[Communicate]할 수 있도록 하는 효율적인 방법을 제공합니다.

  • Modified Fibonacci Sequence (변형된 피보나치 수열)

    변형된 피보나치 수열[Modified Fibonacci Sequence](1, 2, 3, 5, 8, 13, 20, 40, 100)은 상대적 추정에서 추정할 작업의 크기가 커질 때 내재된 불확실성을 반영하기 위해 사용합니다.

N

  • Nonfunctional Requirements, NFRs (비기능적 요구사항)

    비기능적 요구사항은 보안[Security], 신뢰성[Reliability], 성능[Performance], 유지관리성[Maintainability], 확장성[Scalability], 사용성[Usability] 등의 시스템 속성[Attribute]을 정의합니다. 이는 서로 다른 백로그[Backlog]에 걸쳐 시스템의 설계를 제약[Constraint]하거나 제한[Restriction]하는 역할을 합니다.

O

  • Objectives and Key Results (목표 및 핵심 결과(OKR))

    SAFe에서는 목표 및 핵심 결과[OKR, Objectives and Key Results]를 사용하여 전략 테마에 대한 중요 정보를 정의·구성·소통하고, 구체적이고 명확하고 측정 가능한 활동을 통해 진행 상황을 추적할 수 있습니다.

  • Operational Value Streams (운영 가치 흐름)

    운영 가치 흐름(OVS)은 고객에게 제품 또는 서비스를 전달하는 데 필요한 순차적 활동입니다. 예를 들면 제품 제조, 주문 이행, 의료 환자 입원 및 치료, 대출 제공 또는 전문가 서비스 전달이 있습니다.

  • Organizational Agility (조직 애질리티)

    조직 애질리티 역량[Competency]은 린 씽킹[Lean Thinking]을 하는 사람들과 애자일 팀[Agile Team]이 비즈니스 프로세스[Process]를 최적화[Optimize]하고, 명확하고 결정적인 새로운 약속[Commitment]으로 전략을 발전시키며, 필요에 따라 조직을 신속하게 적응[Adapt]하여 새로운 기회를 이용[Capitalize]하는 방법을 설명합니다.

  • Organizational Change Management (조직 변화 관리)

    조직 변화 관리[Organizational Change Management]는 조직의 변화를 추진할 때 개인, 팀 및 조직을 준비시키고 지원하기 위한 모든 접근 방식을 통칭하는 용어입니다.

P

  • Pareto Analysis (파레토 분석)

    파레토 분석[Pareto Analysis]은 검사 및 적응[inspect and adapt] 이벤트에서 전체적으로 가장 중요한 효과를 만드는 의미있는 요인을 선정하기 위해 사용되는 기법입니다.

  • Participatory Budgeting (예산배정 참가 회의)

    예산배정 참가 회의 (PB)는 Lean Portfolio Management (LPM)가 전체 포트폴리오 예산을 여러 가치 흐름에 배정하는 데 사용하는 프로세스입니다.

  • Personas (페르소나)

    페르소나[Persona]는 제품 개발을 위해 고객 중심[customer-centric]의 접근 방식을 추진하는 고객 연구에서 파생된 가상의[fictional] 소비자 및/또는 사용자입니다.

  • Phase Gate (페이즈 게이트)

    페이즈 게이트[Phase Gate]는 전통적인 거버넌스 이정표[traditional governance milestone]로서, SAFe에서는 작업 시스템의 객관적 평가[objective evaluation]를 기반으로 한 이정표로 대체됩니다.

  • PI Objectives (PI 목표)

    PI[Program Increment] 목표는 애자일 팀[Agile Team] 또는 애자일 릴리스 트레인[Agile Release Train (ART)]이 다음 PI에서 달성하고자 하는 비즈니스와 기술 목표를 요약한 것입니다.

  • Plan-Do-Check-Adjust (계획-실행-검사-조정)

    계획-실행-검사-조정[PDCA, Plan-Do-Check-Adjust]은 제품 개발 중 피드백에 대응하여 변동성[variability]을 제어하고 조정하는 데 사용되는 반복적인[iterative] 4단계 방법입니다.

  • Portfolio (포트폴리오)

    SAFe 포트폴리오는 개발 가치 흐름 모음을 통해 실행 전략을 조정합니다. 공통 거버넌스 모델에 따라 운영되는 각 가치 흐름은 엔터프라이즈가 비즈니스 임무를 수행하는 데 필요한 하나 이상의 솔루션을 제공합니다.

  • Portfolio Backlog (포트폴리오 백로그)

    포트폴리오 백로그는 SAFe의 최상위 수준의 백로그[Backlog]입니다. 이는 포괄적인 일련의 솔루션을 만들고 발전시키려는 다가오는 비즈니스[Upcoming Business]와 인에이블러 에픽[Enabler Epic]을 위한 보관 영역[Holding Area]을 제공합니다.

  • Portfolio Canvas (포트폴리오 캔버스)

    포트폴리오 캔버스[Portfolio Canvas]는 SAFe 포트폴리오에 포함된 개발 가치 흐름[development value stream], 제공되는 가치 제안[value proposition] 및 솔루션, 고객, 각 가치 흐름에 할당된 예산[budget] 및 포트폴리오 비전을 달성하는 데 필요한 각종 주요 활동과 이벤트를 정의합니다.

  • Portfolio Kanban (포트폴리오 칸반)

    포트폴리오 칸반 시스템[System]은 아이디어 생성[Ideation]에서 분석[Analysis], 구현[Implementation], 완성[Completion]에 이르기까지 포트폴리오 에픽[Epic]의 흐름을 시각화[Visualize]하고 관리하는 방법입니다.

  • Portfolio SAFe (포트폴리오 SAFe)

    포트폴리오 SAFe 구성[Configuration]은 전략을 실행에 맞추고 하나 이상의 가치 흐름[Value Stream]을 통해 가치의 흐름[Flow of Value]을 중심으로 솔루션이 개발되도록 구조화[Organize]합니다.

  • Portfolio Vision (포트폴리오 비전)

    포트폴리오 비전은 포트폴리오의 가치 흐름[Portfolio’s Value Stream]과 솔루션의 미래 상태[Future State]에 대한 설명으로서 포트폴리오의 목표와 엔터프라이즈의 광범위한 목표를 달성하기 위해 어떻게 협력할 것인지 설명합니다.

  • Pre-and Post-PI Planning (전-후- PI 계획수립)

    전-후- PI 계획수립 이벤트는 솔루션 트레인[Solution Train] 내의 애자일 릴리스 트레인[Agile Release Train (ART)]과 공급자[Supplier]를 위한 PI 계획수립을 준비하고 후속 조치[Follow-Up]를 취하기 위해 사용됩니다.

  • Problem-Solving Workshop (문제해결 워크숍)

    문제해결 워크숍[Problem-Solving Workshop]은 검사 및 적응[I&A, Inspect and Adapt] 이벤트의 요소로, 시스템 문제의 근본 원인을 찾기 위한 구조화된 접근방식[structured approach]입니다.

  • Product Management (제품 관리자)

    제품 관리자는 제품-시장 수명주기[Product-Market Lifecycle] 전체에 걸쳐 고객의 요구를 충족시켜 주는 바람직하고[Desirable], 달성 가능하고[Feasible], 판매 가능[Viable]하며, 지속 가능[Sustainable]한 제품의 구축을 정의하고 지원할 책임이 있습니다.

  • Product Owner, PO (제품 책임자)

    제품 책임자는 팀의 피처[Feature]나 컴포넌트[Component]의 개념적이고 기술적인 무결성[Integrity]을 유지하면서 프로그램 우선 순위의 실행을 간소화[Streamline]하기 위해 스토리[Story]를 정의하고 팀 백로그[Team Backlog]의 우선 순위를 지정할 책임이 있는 애자일 팀[Agile Team]의 구성원입니다.

  • Product Owner (PO) Sync (제품 책임자(PO) 싱크)

    제품 책임자 싱크[Product Owner Sync]는 PI 목표 달성을 위해 ART가 잘 진행되고 있는지 파악하고, 피처 개발의 문제나 기회에 대해 논의하며, 범위 조정[scope adjustments]을 평가하는 ART 이벤트입니다.

  • Program Backlog (프로그램 백로그)

    프로그램 백로그는 사용자의 요구[Need]를 해결하고 단일 애자일 릴리스 트레인[Agile Release Train (ART)]에 대한 비즈니스 이점[Benefit]을 제공하기 위해 예정된 피처[Features]를 보관하는 영역[Holding Area]입니다. 여기에는 아키텍처 런웨이[Architectural Runway]를 구축하는 데 필요한 인에이블러 피처[Enabler Features]도 담겨 있습니다.

  • Program Board (프로그램 보드)

    프로그램 보드[Program Board]는 PI의 피처 제공 날짜, 팀 간의 피처 종속성[dependencies], 관련 이정표를 강조합니다.

  • Program Increment, PI (PI)

    PI는 애자일 릴리스 트레인[Agile Release Train (ART)]이 제대로 작동하며 테스트된 소프트웨어와 시스템의 형태로 점진적인 가치를 제공하는 타임박스[Timebox]입니다. PI의 기간은 보통 8–12주입니다. PI의 가장 일반적인 패턴은 네 번의 개발 이터레이션[Iteration]에 뒤 이은 하나의 혁신 및 계획수립 이터레이션[Innovation and Planning (IP) iteration]이 있습니다.

  • Program Increment Planning (PI 계획수립)

    PI 계획수립은 애자일 릴리스 트레인[Agile Release Train (ART)]에 있는 모든 팀이 공유된 미션[Mission]과 비전에 맞춰 조정하는 일정한 주기 기반[Cadence-based]의 대면 또는 비대면 이벤트로서 애자일 릴리스 트레인의 심장 박동[Heartbeat] 역할을 합니다.

  • Program Kanban (프로그램 칸반)

    프로그램과 솔루션 칸반[Solution Kanban] 시스템은 지속적 전달 파이프라인[Continuous Delivery Pipeline]을 통해 아이디어 생성[Ideation]에서 분석[Analysis], 구현[Implementation], 출시[Release]로 이어지는 피처[Feature]와 케이퍼빌러티[Capability]의 흐름을 시각화하고 관리하는 방법입니다.

  • Program Predictability Measure (프로그램 예측가능성 측정)

    프로그램 예측가능성 측정[Program Predictability Measure]은 ART의 모든 팀에 대해 계획된 비즈니스 가치와 실제 비즈니스 가치를 비교하여 요약하며, ART의 성과와 신뢰성을 보여주는 핵심 지표입니다.

  • Program Risks (프로그램 리스크)

    프로그램 리스크[Program Risk]는 PI 계획수립 중에 각 팀이 식별하며, 목표 달성 역량에 영향을 미칠 수 있는 리스크와 걸림돌[impediment]을 나타냅니다.

R

  • Refactoring (리팩토링)

    리팩토링[Refactoring]은 외부 행위[external behavior]를 변경하지 않고 코드 또는 컴포넌트의 내부 구조[internal structure]나 알고리즘[operation]을 개선하는 활동입니다.

  • Relative Estimation (상대적 추정)

    상대적 추정[Relative Estimation]은 작업을 서로 비교하여 크기와 가치를 빠르게 추정하는 기법입니다.

  • Release on Demand (릴리스 온 디맨드)

    릴리스 온 디맨드는 새로운 기능[Functionality]을 운영 환경[Production]에 배치하고 따라 즉시 또는 점진적으로 고객에게 출시하는 프로세스[Process]입니다.

  • Release Train Engineer, RTE (릴리스 트레인 엔지니어)

    릴리스 트레인 엔지니어는 애자일 릴리스 트레인[Agile Release Train (ART)]의 서번트 리더[Servant leader]이자 코치[Coach]입니다. 릴리스 트레인 엔지니어의 주요 책임은 애자일 릴리스 트레인 이벤트[Event] 및 프로세스[Process]를 촉진하고 팀이 가치를 제공할 수 있도록 지원하는 것입니다. 릴리스 트레인 엔지니어는 이해관계자들과 의사소통하고, 걸림돌[Impediment]을 상급자에게 보고하고, 위험요소[Risk] 관리를 지원하고, 지속적인 개선을 추진합니다. [걸림돌[Impediment]를 => 걸림돌[Impediment]을]

  • Relentless Improvement (끊임없는 개선)

    끊임없는 개선[Relentless Improvement]은 SAFe 린 하우스[House of Lean]의 네 번째 축으로, 지속적인 성찰[reflection]과 프로세스 개선[enhancement]을 통한 학습과 성장[learning and growth]을 장려합니다.

  • Roadmap (로드맵)

    로드맵은 계획된 솔루션[Solution] 결과물을 계획된 기간 동안 전달[Communicate]하는 이벤트[Event] 및 이정표[Milestone]의 일정입니다.

  • ROAMing Risks (리스크 로밍)

    리스크 로밍[Roaming Risks]은 팀이 제기한 프로그램 리스크를 보다 광범위한 관리 컨텍스트에서 해결하는 PI 계획수립 활동입니다.

  • Root Cause Analysis (근본 원인 분석)

    근본 원인 분석[Root Cause Analysis]은 문제 해결 도구[problem-solving tool] 집합을 적용하여 문제의 실제 원인[actual causes]을 검사 및 적응[Inspect and Adapt] 이벤트의 일환으로 식별합니다.

S

  • SAFe Big Picture (SAFe 빅 픽처(BP))

    SAFe 빅 픽처[BP, Big Picture]는 scaledagileframework.com에서 아이콘을 클릭하여 SAFe 내용을 확인하기 위해 사용되는 프레임워크의 주요 역할, 활동, 아티팩트를 시각적으로 표현한 것입니다.

  • SAFe for Government (정부를 위한 SAFe)

    정부를 위한 SAFe는 공공 부문 조직[Public Sector]이 린-애자일[Lean-Agile] 프랙티스[Practice]를 정부 맥락에서 구현하는데 도움이 되는 일련의 성공 패턴[Pattern]입니다.

  • SAFe for Lean Enterprises (린 엔터프라이즈를 위한 SAFe)

    린 엔터프라이즈를 위한 SAFe[SAFe for Lean Enterprises]는 비즈니스 애질리티[Business Agility]를 위한 세계 최고의 프레임워크입니다. SAFe는 린[Lean], 애자일[Agile] 및 데브옵스[DevOps]의 기능을 포괄적인 운영 체제에 통합하여 혁신적인 제품과 서비스를 더 빠르고 예측 가능하며 고품질로 제공함으로써 엔터프라이즈가 디지털 시대에 성공[Thrive]할 수 있도록 지원합니다.

  • SAFe Implementation Roadmap (SAFe 내재화 로드맵)

    SAFe 내재화 로드맵은 SAFe를 성공적으로 구현하는 데 효과적인 것으로 입증된[Proven] 전략 및 일련의 활동을 설명하는 큰 그림[Overview Graphic]과 12개의 핵심 단계[Article]들로 구성됩니다.

  • SAFe Lean Startup Cycle (SAFe 린 스타트업 사이클)

    SAFe 린 스타트업 사이클[SAFe Lean Startup Cycle]은 제품 혁신 및 전략적 투자를 위한 매우 반복적인 구축-측정-학습[build-measure-run] 주기입니다. 이런 에픽 구현 전략은 SAFe의 흐름[flow]과 가시성[visibility]이 주는 이익을 활용하는 동시에 투자와 리스크를 점진적으로[incrementally] 관리함으로써 린 스타트업을 위한 경제적·전략적 이점을 제공합니다.

  • SAFe Program Consultants, SPCs (SAFe 프로그램 컨설턴트)

    공인된[Certified] SAFe 프로그램 컨설턴트는 SAFe에 대한 기술적 지식과 회사의 소프트웨어 및 시스템 개발 과정[Development Process]을 개선하기 위한 내재적 동기[Intrinsic Motivation]를 결합하는 변화 관리 전문가[Agent]입니다. 이들은 SAFe를 성공적으로 구현하는 데 있어 중요한 역할을 합니다. SAFe 프로그램 컨설턴트는 비즈니스[Business] 및 기술 리더[Technology Leaders], 포트폴리오[Portfolio] / 프로그램[Program] / 프로젝트[Project] 관리자, 프로세스 선임자[Process Lead], 아키텍트[Architects], 분석가[Analyst], 컨설턴트[Consultant] 등을 포함하여 수많은 내부 또는 외부 역할 출신입니다.

  • Scrum Master (스크럼 마스터)

    스크럼 마스터는 애자일 팀[Agile Team]의 서번트 리더[Servant Leader] 및 코치[Coach]입니다. 이들은 스크럼, 익스트림 프로그래밍[Extreme Programming (XP)], 칸반[Kanban] 및 SAFe에서 팀을 교육하고 합의된 애자일 프로세스[Agile Process]가 준수되도록 보장합니다. 이들은 또한 장애 요소를 제거하고 높은 성과를 내는 팀 역학[Team Dynamics], 지속적인 흐름[Continuous Flow], 끊임없는 개선 [Relentless Improvement]을 위한 환경을 조성하는 것을 도움을 줍니다.

  • Scrum of Scrums (스크럼의 스크럼)

    스크럼의 스크럼[SoS, Scrum of Scrums]은 ART 의존성[dependency]을 조정하고 진행 상황[progress] 및 걸림돌[impediment]에 대한 가시성[visibility]을 제공하는 ART 이벤트입니다.

  • ScrumXP (스크럼엑스피)

    스크럼엑스피는 SAFe 내의 교차-기능적[Cross-Functional]이고 자기-조직화[Self-Organized] 팀에게 가치를 제공하는 경량[Lightweight] 프로세스입니다. 이는 스크럼 프로젝트 관리 프랙티스[Management Practice]의 뛰어남[Power]을 엑스피[Extreme Programming (XP)] 프랙티스와 결합합니다.

  • Set-Based Design (세트-기반 설계)

    세트-기반 설계는 개발 프로세스에서 요구사항[Requirement]과 설계 옵션[Design Option]을 최대한 유연하게[Flexible] 유지하는 프랙티스입니다. 세트-기반 설계는 단일 지점의 솔루션[Solution]을 미리 선택하는 대신 여러 가지 선택을 식별하고 동시에 탐색하여 시간을 두고 더 열악한 선택을 제거[Eliminating]합니다. 이는 가정의 유효성을 검증한 후에만 기술 솔루션을 적용하기 때문에 설계 프로세스[Process]의 유연성을 향상시키고 더 나은 경제적 결과[Economic Result]를 만들어 냅니다.

  • Shared Services (공유 서비스)

    공유 서비스는 애자일 릴리스 트레인[Agile Release Train (ART)] 또는 솔루션 트레인[Solution Train]의 성공에 필요하지만 상시 전담으로 업무를 할 수 없는 전문적 역할[Specialty Role], 사람[People], 서비스[Service]를 나타냅니다.

  • Silos (사일로)

    사일로[Silos]는 기능 단위 간에 더 큰 가치 흐름에 대한 이해 없이 기능 단위 내에서 반복 가능하고 효율적인 운영을 보장하는 정책[policy]과 절차[procedure]를 사용하여 전문가[specialist]에 맞게 지역적으로 최적화하는, 기능적으로 조정된[functionally-aligned] 조직 구조입니다.

  • Solution (솔루션)

    각 가치 흐름[Value Stream]은 엔터프라이즈 내부 또는 외부에 관계없이 고객에게 제공되는 제품, 서비스, 시스템인 하나 이상의 솔루션을 만들어 냅니다.

  • Solution Architect/Engineer (솔루션 아키텍트/엔지니어)

    솔루션 아키텍트/엔지니어는 개발중인 시스템[System] 또는 솔루션[Solution]이 의도한 목적[Intended Purpose]에 적합하도록 솔루션 트레인[Solution Train] 전체에 걸쳐서 공유된 기술 및 아키텍처 비전[Technical and Architectural Vision]을 정의하고 제공할 책임이 있습니다.

  • Solution Backlog (솔루션 백로그)

    솔루션 백로그는 예정된 케이퍼빌러티[Capability] 및 인에이블러[Enabler]용 케이퍼빌러티를 위한 보관 영역[Holding Area]으로서 각각은 여러 개의 애자일 릴리스 트레인[Agile Release Train (ART)]에 걸쳐 있을 수 있으며 솔루션을 발전시키고 아키텍처 런웨이[Architectural Runway]를 구축하기 위한 것입니다.

  • Solution Context (솔루션 컨텍스트)

    솔루션 컨텍스트는 솔루션 운영 환경[Operational Environment]의 중요한 측면을 식별합니다. 이는 솔루션 자체의 요건[Requirement], 사용[Usage], 설치[Installation], 운영[Operation], 지원[Support]에 대한 필수적인 이해를 제공합니다. 솔루션 컨텍스트는 릴리스 온 디맨드[Release on Demand]를 위한 기회[Opportunity]와 제약[Constraint]에 크게 영향을 미칩니다.

  • Solution Demo (솔루션 데모)

    솔루션 데모[Solution Demo]는 솔루션 트레인[Solution Train]의 모든 PI에 대한 ART 및 공급업체의 개발 노력을 통합[Integrate]하고, 평가[Evaluation] 및 피드백[Feedback]을 위해 고객 및 다른 이해관계자가 볼 수 있도록 합니다.

  • Solution Intent (솔루션 인텐트)

    솔루션 인텐트는 현재 및 의도된 솔루션 행위[Behavior]에 대한 지식을 저장[Storing], 관리[Managing] 및 소통[Communicating]하기 위한 저장소[Repository]입니다. 필요한 경우 고정 및 가변 사양 및 설계와 적용 가능한 표준[Standard], 시스템 모델[System Model], 기능 및 비기능 테스트[Functional and Nonfunctional Test]에 대한 참조[Reference], 그리고 추적성[Traceability]이 포함됩니다.

  • Solution Management (솔루션 관리자)

    솔루션 관리자는 시간의 흐름에 따라 고객의 요구[Need]를 충족시켜 주는 바람직하고[Desirable], 달성 가능하고[Feasible], 판매 가능하며[Viable], 지속 가능한[Sustainable] 대규모 비즈니스 솔루션[Large Scale Business Solution]의 구축을 정의하고 지원하는 역할을 담당합니다.

  • Solution Train (솔루션 트레인)

    솔루션 트레인은 공급자[Supplier]의 기여[Contribution] 뿐만 아니라 다수의 애자일 릴리스 트레인[Agile Release Train (ART)]의 조정[Coordination]이 필요한 크고 복잡한 솔루션을 구축하는 데 사용되는 조직 구조입니다. 이는 비전[Vision], 백로그[Backlog], 로드맵[Roadmap], 조정된 PI[Aligned Program Increment (PI)]를 사용하여 애자일 릴리스 트레인을 공유된 비즈니스[Business] 및 기술 미션[Mission]과 맞춥니다.

  • Solution Train Engineer, STE (솔루션 트레인 엔지니어)

    솔루션 트레인 엔지니어는 솔루션 트레인[Solution Train]의 서번트 리더[Servant Leader]이자 코치[Coach]로서 가치 흐름[Value Stream] 내의 모든 애자일 릴리스 트레인[Agile Release Train (ART)] 및 공급자[Supplier]의 작업을 촉진하고 안내합니다.

  • Spanning Palette (스패닝 파레트)

    스패닝 파레트에는 특정 팀[Team], 프로그램[Program], 대형 솔루션[Large Solution] 및 포트폴리오[Portfolio] 컨텍스트[Context]에 적용될 수 있는 다양한 역할과 산출물[Artifact]을 포함합니다.

  • Spike (스파이크)

    스파이크[Spike]는 기술 적용[technical approach]의 리스크를 줄이거나, 요구 사항[requirement]에 대한 이해도를 높이거나, 스토리 추정치의 신뢰성을 높이는 데 필요한 지식을 습득하는 탐색 인에이블러[exploration Enabler] 스토리의 한 유형입니다.

  • Sprint (스프린트)

    스프린트[Sprint]는 스크럼 방식에서 유래한 용어이며, SAFe의 이터레이션과 동의어입니다.

  • Stories (스토리)

    스토리는 원하는 기능[Functionality]의 작은 부분에 대해 사용자의 언어로 쓰여진 간략한 설명입니다.  애자일 팀은 시스템 기능[Functionality]의 소규모 수직 부분업무[Vertical Slice]를 구현하고 단일 이터레이션[Single Iteration] 내에서 완료할 수 있도록 크기를 조정합니다.

  • Story Map (스토리 맵)

    스토리 맵[Story Map]은 목표 달성에 필요한 업무에 따라 사용자가 스토리 순서[sequence]를 정리하는 디자인 씽킹 기법[design thinking technique]입니다.

  • Story Point (스토리 포인트)

    스토리 포인트는[Story Point] 상대적 추정[relative estimating]에서 사용하는 단일한 숫자[singular number]로 양, 복잡성, 지식, 불확실성[volume, complexity, knowledge, uncertainty]의 양적[quantity] 조합을 나타냅니다.

  • Strategic Themes (전략 테마)

    전략 테마는 포트폴리오를 엔터프라이즈[Enterprise]의 전략과 연결하는 차별화된 비즈니스 목표[Business Objective]입니다. 이는 포트폴리오 전략에 영향을 주고 포트폴리오 의사 결정을 위한 비즈니스 컨텍스트[Business Context]를 제공합니다.

  • Sunk Costs (매몰 비용)

    매몰 비용[Sunk Costs]은 이미 지출된[spent] 금액을 의미하며, 효과적인 전환[pivot]을 위해 향후 투자를 결정할 때 무시해야 합니다.

  • Supplier (공급자)

    공급자는 솔루션 트레인[Solution Trains] 및 애자일 릴리스 트레인[Agile Release Trains (ART)]이 자신들의 고객들에게 솔루션[Solution]을 제공하도록 지원하는 컴포넌트[Component], 하위시스템[Subsystem] 또는 서비스[Service]를 개발하고 제공하는 내부 또는 외부 조직[Organization]입니다.

  • SWOT Analysis (SWOT 분석)

    SWOT 분석[SWOT Analysis]은 SAFe 포트폴리오 비전의 일환으로 현재 비즈니스 상황과 관련된 강점, 약점, 기회 및 위협[Strengths, Weaknesses, Opportunities, Threats]을 식별하는 데 사용되는 전략적인 계획 수립 기법입니다.

  • System Architect/Engineer (시스템 아키텍트/엔지니어)

    시스템 아키텍트/엔지니어는 개발 중인 시스템[System] 또는 솔루션[Solution]이 의도한 목적[Intended Purpose]에 맞도록 보장하기 위해 애자일 릴리스 트레인[Agile Release Train (ART)]에 대하여 공유된 기술 및 아키텍처 비전[Technical and Architectural Vision]을 정의하고 제공할 책임이 있습니다.

  • System Demo (시스템 데모)

    시스템 데모는 애자일 릴리스 트레인[Agile Release Train (ART)] 내의 모든 팀이 제공한 최근의 이터레이션[Iteration]에 대한 새로운 피처[Features]를 통합적으로 볼 수 있도록 해주는 중요한 이벤트[Event]입니다. 각 시연은 애자일 릴리스 트레인 이해관계자들에게 PI[Program Increment (PI)] 동안의 진행 상황에 대한 객관적인 측정[Objective Measure]을 제공합니다.

  • System Team (시스템 팀)

    시스템 팀은 일반적으로 지속적 전달 파이프라인[Continuous Delivery Pipeline]을 지원하는 툴체인[Toolchain]의 개발 및 유지보수를 포함하여 애자일[Agile] 개발 환경을 구축하고 지원하는 전문적인 애자일 팀[Agile Team]입니다.  시스템 팀은 애자일 팀의 자산 통합을 지원하고 필요한 경우 처음부터 끝까지의[End-to-End] 솔루션 시험을 수행하며 배치[Deployment] 및 릴리스 온 디맨드[Release on Demand]를 지원할 수 있습니다.

  • Systems Thinking (시스템 씽킹)

    시스템 씽킹[System Thinking]은 시스템 자체의 설계, 개발, 배포, 유지관리[design, development, deployment, maintenance]에 시스템과 해당 환경의 모든 측면을 통합하여 솔루션 개발에 전체적으로 접근[holistic approach]합니다.

T

  • Team and Technical Agility (팀 및 기술 애질리티)

    팀 및 기술 애질리티 역량[Competency]은 고성과[High-Performing] 애자일 팀[Agile Team]과 애자일 팀들의 팀[Teams of Agile Teams]이 고객을 위한 고품질 솔루션을 만들기 위해 사용하는 중요한 기술[Skill]과 린-애자일[Lean-Agile] 원칙[Principle]과 프랙티스[Practice]를 설명합니다.

  • Team Backlog (팀 백로그)

    팀 백로그에는 프로그램 백로그[Program Backlog]에서 시작된 사용자 및 인에이블러 스토리[Enabler Story]와 팀에 국한된 컨텍스트[Local Context]에서 발생한 스토리[Story]가 포함됩니다. 여기에는 팀이 시스템의 일부를 발전[Advance]시키기 위해 수행해야 하는 모든 것을 대표하는 다른 작업 항목도 포함될 수 있습니다.

  • Team Kanban (팀 칸반)

    팀 칸반은 팀이 업무 흐름[Workflow]을 시각화[Visualize]하고, 프로세스 내 작업[Work In Process (WIP)]의 한계를 설정하고, 처리량[Throughput]을 측정하고, 프로세스[Process]를 지속적으로 개선함으로써 가치 흐름을 원활히 할 수 있도록 지원하는 방식[Method]입니다.

  • Team Topologies (팀 토폴로지)

    팀 토폴로지[Team Topologies]는 4가지 조직 유형을 정의하여 애자일 팀과 ART를 조직하기 위한 명확한 모델을 제공합니다.

  • Technical Debt (기술 부채)

    기술 부채[Technical Debt]는 대개 차선의 솔루션 또는 불완전한 솔루션을 무의식적으로 또는 고의로 선택함으로써 발생하는 미래 작업의 잠재 비용[implied cost]과 누적 이자[accumulating interest]를 반영합니다.

  • Test-Driven Development (테스트 주도 개발)

    테스트 주도 개발[TDD, Test-Driven Development]은 시스템 코드 또는 시스템 컴포넌트를 구현[implementing]하기 전에 테스트 구축 및 실행[building, executing]하는 사고방식이자 프랙티스[mindset & practice]입니다.

  • TOWs Analysis (TOWS 분석)

    TOWS 분석[TOWS Analysis]은 SAFe 포트폴리오 비전에 따라 개선된 미래 상태를 만들기 위한 전략적 옵션을 식별하는 데 도움이 되도록 SWOT 분석과 함께 사용됩니다.

U

  • U-curve Optimization (U자형 곡선 최적화)

    배치 크기[batch size]에 대한 U자형 곡선 최적화[U-curve Optimization]는 거래 비용[transaction cost]과 유지 비용[holding cost]의 균형을 맞춤으로써 최적의 배치 크기를 결정합니다.

  • Uncommitted Objectives (달성 불확실 PI 목표)

    달성 불확실 PI 목표[Uncommitted Objectives]는 팀의 약속[commitment]에 포함되지 않거나 프로그램 예측가능성[program predictability] 측정 계산 시 팀에 반영되지 않기 때문에 비즈니스 가치 전달[delivering business value]의 예측가능성을 개선하는 데 도움이 됩니다. 팀은 목표 달성에 대한 신뢰도가 낮을 때마다 달성 불확실 PI 목표를 적용할 수 있습니다.

V

  • Value (가치)

    가치[Value]는 기업이 고객과 이해 관계자에게 제공하는 이익을 나타내며, SAFe의 다양한 컨텍스트에서 나타납니다.

  • Value Stream Coordination (가치 흐름 조정)

    가치 흐름 조정은 의존성[Dependencies]을 관리하고 가치 흐름 간의 상호연관[Interconnection]된 것에만 존재하는 기회를 활용[Exploit]하는 방법을 정의합니다.

  • Value Stream Identification (가치 흐름 식별)

    가치 흐름 식별[Value Stream Identification]은 포트폴리오가 지원하는 개발 가치 흐름[development value stream]과 운영 가치 흐름[operational value stream]을 식별하는 데 사용하는 활동입니다.

  • Value Stream KPI (가치 흐름 핵심성과 지표)

    가치 흐름 핵심 성과 지표[Key Performance Indicators (KPIs)]는 예상한 비즈니스 성과[Business Outcome]에 비해 가치 흐름이 어떤 성과를 얻고 있는지 평가하기 위해 사용하는 정량화 가능한 척도[Measure]입니다.

  • Value Stream Mapping (가치 흐름 매핑)

    가치 흐름 매핑[Value Stream Mapping]은 지연을 발생시키는 흐름[flow]에서 병목 현상 및 문제 영역[bottleneck and problem]을 식별하기 위해 필요한 가시성을 제공함으로써 지속적 전달 파이프라인[continuous delivery pipeline] 전반의 가치 흐름을 개선하는 데 꼭 필요한 도구입니다.

  • Value Streams (가치 흐름)

    가치 흐름은 조직[Organization]이 고객에게 가치의 지속적인 흐름[Continuous flow of value]을 제공하는 솔루션[Solution]을 구현하기 위해 사용하는 일련의 단계[Series of Step]를 나타냅니다.

  • Velocity (벨로시티)

    벨로시티[Velocity]는 완료 기준[DoD, Definition of Done]을 충족하는 모든 완료된 스토리 포인트의 합과 같습니다.

  • Vision (비전)

    비전은 개발 중인 솔루션[Solution]의 미래 상태에 대한 설명[Description]입니다. 이는 고객 및 이해관계자의 요구[Need]와 그런 요구를 충족시켜 주기 위해 제안된 피처[Feature] 및 케이퍼빌러티[Capability]를 반영합니다.

W

  • Weighted Shortest Job First, WSJF (가중치를 고려한 최단 작업 먼저하기)

    가중치를 고려한 최단 작업 먼저하기는 가장 큰 경제적 이익을 창출하기 위해 작업(예: 피처[Feature], 케이퍼빌러티[Capability], 에픽[Epic])의 순서를 정하는 데 사용되는 우선 순위 지정 모델[Model]입니다. SAFe에서 가중치를 고려한 최단 작업 먼저하기는 지연비용[Cost of Delay (CoD)]을 작업 크기[Job Size]로 나눈 값으로 추정[Estimate]합니다.

  • Work in Process (프로세스 내 작업)

    프로세스 내 작업[WIP, Work in Process]은 부분적으로 완료된 작업을 나타냅니다. WIP가 너무 많으면 우선순위가 혼란해지고, 컨텍스트 전환[context switching]이 자주 발생하며, 간접비가 증가합니다.

© 2024 Scaled Agile, Inc. All rights reserved.