SAFe需求模型
从本质上讲，所有的模型都是错的，但有些模型是有用的。
——George E. P. Box
SAFe需求模型
为了支持将精益和敏捷开发的好处带给大型企业，或带给构建更复杂系统的小型企业，SAFe提供了一个可扩展的需求模型，该模型展示了一种表达系统行为的方法：史诗（Epics）、能力（Capabilities）、特性（Features）、故事（Stories）、非功能需求（NFR，Nonfunctional Requirements）等等。如图1所示，每一个工作项都以不同的方式表示。
图1. SAFe需求模型
例如，特性（feature）是由短语（phrase）、收益假说（benefit hypothesis）和验收标准（acceptance criteria）来描述；故事（story）由用户发言陈述（user-voice statement）和验收标准（acceptance criteria）来阐述。
这些工件主要是用基于精益-敏捷开发（Lean-Agile development）的新范式来取代传统的系统和需求规格说明书（requirements specifications），同时也是为了帮助团队避免过早关注一个点的解决方案、避免在学习过程的开始就选择具体的需求和设计。相反，它们鼓励为基于意图而非具体内容的涌现认知留下空间。
此外，还包括属性（attributes）、验收指南（acceptance guidelines）和测试（testing）的模式和关系，以支持同样适用于世界上最重要系统的NFRs。
总的来说，这是一个综合的模型，如图1所示。
大多数从业者只需要这些条目中的一部分。例如，敏捷团队主要采用用户故事、故事验收测试（story acceptance tests）和NFRs。然而，每个元素的设计都是为了在SAFe的各个层面提供适量的行为表达和测试。
这篇指导文章适用于那些需要知道如何将其作为一个系统一起运作的顾问和SAFe专家，以及那些围绕SAFe提供工具（在这里语义必须是明确的）的人。
如果这个模型看起来很复杂，那是因为当代大规模软件和系统的开发是很复杂的，即使使用敏捷开发也是如此。如果一个元素是不需要的，那么就不需要使用它。然而，那些正在建立世界一流的企业解决方案的团队和项目可能可以应用这些元素中的大多数。
了解更多
Last update: 10 February 2021
