Scaled Agile Framework® Terms and Definitions
规模化敏捷框架术语及定义
中文简体翻译由©Scaled Agile, Inc授权京东敏捷创新教练SPC4赵卫翻译。 Scaled Agile Inc.没有审查或认证这些翻译，对翻译的准确性不做任何保证。
A
Architecture
Agile Architecture is a set of values and practices that support the active evolution of the design and architecture of a system while implementing new system capabilities.
敏捷架构（Agile Architecture）
敏捷架构是一系列价值观和实践的组合，这些价值和实践可在实施新的系统能力（capabilities）的同时支持系统设计和架构的积极演进。
David说
敏捷架构 = 持续的【多个迭代前刻意的、前瞻的概要架构设计（小于瀑布的一次性架构设计）（刻意的架构/架构展望/架构跑道）+ 每个迭代内根据经验、技术、业务等风险，有针对性的对部分特性进行设计（及时制JIT：涌现式设计/迭代建模/模型风暴）】
传统一次性的过度架构设计，导致了PPT架构不能落地或者很少使用导致的部分浪费，或者花费很长时间，而只顾眼前迭代的设计，导致了Rush to code不去做设计、依赖没有考虑到以及返工等，所以敏捷架构既要避免过度设计，又要尽量避免没有全局考虑的局部设计导致的返工
架构的演进，是靠真正的代码实现来演进，而代码实现不是一次性的实现所有的架构，而是采用“架构切片”的方式，结合SAFe的架构跑道，持续的按迭代增量地实现，既保证基础设施、框架的持续发展，也保证业务功能持续的基于架构而发展，从而验证了架构的可行性。
Agile Release Train (ART)
The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length Iterations within a Program Increment (PI) timebox. The ART aligns teams to a common business and technology mission.
敏捷发布火车（Agile Release Train，ART）
敏捷发布火车（ART）是一个长期存在的、由多个敏捷团队组成的团队，该团队与其他利益相关者一同使用项目群增量（Program Increment，PI）时间盒内的一系列固定长度的迭代，增量地开发并交付解决方案。ART可使多个团队在共同的业务及技术目标上保持一致。
David说
ART（50-125人）是大规模敏捷在SAFe中的核心体现，无论是Craig&Bas的LeSS，Dr. Jeff Sutherland的Scrum@Scale，还是Ken Schwaber的Nexus，无论战术上如何操作，和SAFe的ART要解决的事情是一样的，都是百人级团队，围绕一个产品/系统，如何进行计划和开发进行价值交付。
Agile Team
The SAFe Agile Team is a cross-functional group of 5 to 11 people who have the responsibility to define, build, test, and where applicable deploy, some element of solution value—all in a short Iteration timebox. Specifically, the SAFe Agile Team incorporates the Dev Team, Scrum Master, and Product Owner roles.
敏捷团队（Agile Team）
SAFe敏捷团队是一个由 5 到 11 人组成的跨职能团队，该团队负责在较短的迭代时间盒内定义、构建、测试，并适时部署解决方案（Solution）价值的部分元素。具体而言，SAFe 敏捷团队包括开发团队（Dev Team）、Scrum Master 和产品负责人（Product Owner ）等角色。
David说
SAFe的敏捷团队采用的是Scrum的组织结构，所以包含Scrum的三个角色，并且如果团队采用看板方法，SAFe仍然建议采用这三个角色。
为什么是5-11人呢，因为最新版的Scrum Guide提到开发团队是3-9人，所以加上PO和Scrum Master, 那么就是5-11人。这里没有讨论Scrum Master是专职还是兼职的情况。
敏捷团队除了是跨职能的（包含前端、交互和视觉设计、后端开发、测试等角色），还是特性团队Feature team, 因为通常来讲要围绕用户感知的有价值的用户故事做开发和交付，而不是按软件架构的分层、分模块、分组件的去交付。
自从2001年敏捷宣言发布以来，对于业界有关敏捷团队的认知，SAFe的敏捷团队是都遵循的。默认的是，当提到敏捷团队的时候，除了特殊情况，一般都是：10人级的面对面集中办公的跨职能、自组织、自管理、特性团队。所以从这个角度来说其他的大敏捷方法提到的小敏捷团队也是具有相同特征的。
如果说Scrum Team(PO, Scrum Master, Dev Team)是敏捷的，那么SAFe的敏捷团队也是敏捷的。为什么不呢？
Architectural Runway
The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.
架构跑道（Architectural Runway）
架构跑道包括现有代码、组件和技术基础设施，它们对于实现近期的特性（features）必不可少，无需过度重新设计，也不会由于重新设计导致过度延迟。
David说
架构跑道就是代码，在当前迭代，架构跑道的设计和代码都要完成，以便下一个迭代业务功能（业务用户故事）可以直接使用架构跑道的代码。
通常短视的Story by Story的开发时，如果多个故事之间有依赖、有共同可抽取重用的代码、有可以共同使用的基础设施代码等，在进行新的Story开发的时候，就需要重构或者重新设计，重新编写公共类、模块等，或者改动之前的Story代码，这就是开发人员常说的返工。所以架构跑道的存在避免了这种返工。
架构跑道，通常是由前瞻性的刻意架构设计出来的。实施的时候，也正如铺设真正的火车轨道一样，是一段一段的向前铺设，如果铺设好一段，那么火车就可以前进一步。
B
Built-In Quality
Built-In Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development.
内建质量（Built-in Quality）
内建质量实践确保在整个开发过程中，每个增量上的每个解决方案元素均符合相应的质量标准。
David说
内建质量是SAFe的四个核心价值观之一。无论是小敏捷还是大敏捷，核心思想是一致的，都是借鉴极限编程的工程实践来内建质量，来前移质量。
但是在SAFe中，考虑到了百人级，千人级去开发一个系统或一个解决方案的时候，如何内建质量。除了常规的持续集成、测试先行、测试自动化等实践，SAFe在每个迭代边界设置了百人级的System Demo以及千人级的Solution Demo活动。
Business Owners
Business Owners are a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events.
业务负责人（Business Owners，BOs）
业务负责人是一个利益相关者小组，他们对由敏捷发布火车（ART）开发的解决方案的治理、合规和投资回报（ROI）负有主要的业务和技术责任。他们是 ART 的关键利益相关者，必须评估适用性（fitness for use）并积极参与特定的 ART 事件。
David说
BO在规模化敏捷中至关重要，他们通常来源于传统企业的传统的领导层，例如产品线经理、开发总监、测试总监、产品经理总监、产品线总监、事业线/业务线总监等，获得他们的支持和一线参与，才有可能真正的培养领导层的精益-敏捷思维和精益-敏捷领导力，以及真正的围绕价值交付，全局的看待敏捷规划和交付，持续的指引和调整产品开发的大的方向。
无论是小团队还是大团队的敏捷运作，脱离领导层的一线参与，完全就是自嗨，尽管会产生一定的敏捷收益和业务效果，但是当遇到系统性的组织级的疑难杂症的时候，领导层通常是“思想”上支持敏捷，行动上可能会参考“传统思想”来看待问题，反而会制约敏捷的实施。
BO通常会参与PI计划给团队PI目标进行价值打分，并在项目群增量结束的时候参与检视和调整工作坊并给团队PI目标实际业务效果打分。(本文于2018年发布)
