保险箱的故事
故事是敏捷中用来定义系统行为的主要工件。它们是功能的简短描述，通常从用户的角度用用户的语言编写。每个故事的目的是实现一个小的、垂直的系统行为片段，以支持增量开发。
这个故事为商业人士和技术人员理解其意图提供了足够的信息。故事的细节将被推迟，直到故事准备实施。通过验收标准和验收测试，故事变得更加具体，并有助于确保系统的质量。
用户故事直接向最终用户交付功能。启用者故事带来了支持探索、架构、基础设施和法规遵从性所需的工作项目的可见性。
SAFe的需求模型描述了工件的四层结构，它概述了功能系统的行为:史诗、能力、特征和故事。它们描述了创建解决方案预期行为的所有工作。但是详细的实现工作是用故事来描述的，这些故事构成了团队Backlog。大多数故事来自于“计划积压”中的业务和使能特性，一些故事来自于团队识别的工作。
每个故事都是一个小的、独立的行为，可以逐渐实现，为用户或解决方案提供一定的价值。它是一个垂直切片的功能，确保每次迭代都能带来新的价值。要将故事分割得相对较小，必须在一次迭代中完成(参见关于分割故事的部分)。
通常，故事会先写在索引卡或便条上。索引卡的物理性质在团队、故事和用户之间建立了一种有形的关系:它有助于整个团队参与故事的写作。便利贴还提供了其他好处:它们有助于作品的可视化，可以很容易地放在墙上或桌子上，按顺序重新排列，甚至在必要时传阅。故事可以让人更好地理解工作的范围和进度:
虽然任何人都可以编写故事，但是产品负责人有责任批准它们进入团队待办事项列表，并接受它们进入系统基线。当然，便利贴无法在整个企业中很好地扩展，所以故事通常会很快转移到ALM(敏捷生命周期管理)工具中。
在SAFe中，有两种类型的故事，即用户故事和授权故事，如下所述。
如图1所示，故事通常由业务和使能特性的分离所驱动。
用户故事是表达所需功能的主要方式。它们在很大程度上取代了传统的需求规范。(然而，在某些情况下，它们可用于解释和开发系统行为，然后记录这些行为以支持合规性、可追溯性或其他要求。)
因为他们关注的是用户感兴趣的话题，而不是系统，所以用户故事是以价值为中心的。为了支持这一点，建议采用“用户声音”的形式，如下所示:
通过使用该表格，引导团队了解谁在使用该系统，他们正在使用该系统做什么，以及他们为什么这样做。经常使用“用户声音”的形式，往往会提高团队的领域能力；他们会更好地理解用户真正的业务需求。图2提供了一个例子。
“人物角色”描述了代表性用户的具体特征，可以帮助团队更好地理解他们的最终用户。图2中骑手角色的例子可以是一个令人兴奋的“简”和一个胆小的骑手“鲍勃”。然后，故事描述会引用这些人物(如简，我希望……)。
虽然用户故事语音很常见，但并不是每个系统都会和终端用户交互。有时“用户”是一个设备(如打印机)或一个系统(如交易服务器)。在这些情况下，故事可以采用图3所示的形式。
团队可能需要开发系统架构或基础设施来实现一些用户故事或系统的支持组件。在这种情况下，故事可能不会直接接触任何最终用户。这些是支持探索、架构或基础设施的成功案例。使能故事可以用技术而不是以用户为中心的语言来表达，如图4所示。
还有许多其他类型的赋能故事，包括:
与用户故事一样，使能故事通常通过显示获得的知识、制造的工件或用户界面、堆积或模拟来显示。
一个好的故事需要多个视角。在敏捷中，整个团队(产品所有者、开发人员和测试人员)对要构建的内容有一个共同的理解，以减少返工并提高吞吐量。团队使用行为驱动开发(BDD)来协作，定义详细的验收测试，并清楚地描述每个故事。好的故事需要多角度思考:
共同编写一个故事，可以保证所有观点都被考虑，每个人对故事的行为都有* * *的理解，结果体现在故事的描述、验收标准和验收测试中。验收测试是使用系统的领域语言和行为驱动开发(BDD)编写的。然后，BDD测试将自动执行并持续运行，以保持内置质量。BDD测试是根据系统需求(故事)编写的，因此它可以作为系统行为的确定性陈述，而不是基于文档的规范。
XP的发明者之一Ron Jeffries被认为是第一个提出3C方法来描述故事的人:
敏捷团队通常用业务可读的领域特定语言自动执行验收测试。自动化创建一个可执行的规范来验证和确认解决方案。自动化还提供了系统快速回归测试的能力，从而增强了持续集成、重新配置和维护的能力。
Bill Wake [1]开发的投资模型描述了优秀用户故事的特征:
敏捷团队使用故事点和“评估扑克”来评估他们的工作[1，2]。一个故事点是一个单一的数字，它代表了以下特征的组合:
故事点是相对的，与任何具体的计量单位无关。每个故事的大小(工作量)是相对于最小的故事来估算的，最小的故事被赋予“1”的大小。应用修正的斐波那契数列(1，2，3，5，8，13，20，40，100)来反映估计中固有的不确定性，特别是大的数字(如20，40，100) [
敏捷团队经常使用“评估扑克”，它结合了专家意见、类比和分解来创建快速但可靠的评估。分解是指将一个故事或特征分成更小的部分，以便于评估。
(请注意，还有一些其他方法在使用。)估计扑克的规则是:
进行一些初步的设计讨论是合适的。然而，花太多时间在设计讨论上往往是浪费精力。评估扑克的真正价值在于同意一个故事的范围。这也是一种乐趣！
团队在迭代中的速度等于所有满足完成定义(DoD)的已完成故事的故事点的总和。随着团队的不断合作，他们的平均速率(每次迭代中完成的故事点)将变得可靠和可预测。可预测的速度有助于计划和限制WIP，因为团队承担的故事数量不会超过其历史速度所允许的范围。这种方法也用于估计交付史诗、特性、能力和推动者所需的时间，这也可以通过使用故事点来预测。
能力指的是团队比率中可以实际用于任何特定迭代的部分。假期、培训和其他事件将阻止团队成员在某些部分为迭代的目标做出贡献。这降低了团队在该迭代中的最大潜在速率。例如，一个平均每次迭代交付40分的团队，如果团队成员休假一周，他们的最高比率将被调整为36分。提前知道这一点，团队在迭代规划中只承诺了最多36个故事点。这也有助于预测PI计划期间PI中每个迭代的实际可用容量，以便团队在构建PI目标时不会过度承诺。
在标准的Scrum中，每个团队的故事点估计和由此产生的比率是团队内部的独立事务。从规模敏捷性的角度来看，当团队之间的速度基准差异很大时，将很难预测更大的史诗和特征的故事点大小。为了克服这个问题，SAFe团队将首先校准一个起始故事点基准，在这个基准上，所有团队都有大致相同的故事点定义。没有必要重新校准团队评估或比率。当新的agile发行系列启动时，将会执行校准。
标准化故事点为故事和费率提供了一种达到商定的起始基准的方法，如下所示:
例:假设一个6人团队由3个开发人员、2个测试人员和1个PO组成，没有请假和假期，那么估计初始率=5×8分=40分/迭代。(注:如果开发人员和测试人员中有一人兼职，可能需要降低)。
这样各队的故事点就有了一定的可比性。管理层可以更好地了解故事点的成本，并更准确地确定即将推出的功能或史诗的成本。
虽然随着时间的推移，团队倾向于提高速度是一件好事，但事实上，这个数字倾向于保持稳定。团队的速度受团队规模和技术环境变化的影响远远大于生产力变化的影响。
较小的故事将导致更快和更可靠的实现，因为小项目在任何系统中都更快、更少变化和更少风险。所以，把一个较大的故事拆分成较小的故事，是每个敏捷团队必备的技能。这不仅是增量开发的艺术，也是一门科学。Leffingwell的敏捷软件需求[1]介绍了十种拆分故事的方法。以下是这些技术的总结:
图6显示了一个用例场景分割的例子:
正如文章《安全需求模型》中所描述的，这个框架应用了一系列的工件和连接，以一种精益和敏捷的方式来管理复杂系统的定义和测试。图7说明了故事在外管局全局中的作用。
在伸缩敏捷性中，故事通常(但不总是)由新特性创建。而且每个故事都有验收测试，可能还有单元测试。单元测试主要是保证故事的技术实现是正确的。同时，它也是测试自动化的一个关键起点，因为单元测试可以很容易地自动化，这在论文测试驱动开发(TDD)中有所描述。
注意:图7使用统一建模语言(UML)符号来表示对象之间的关系:零到多(0...*)，一对多(1...*)、一对一(1)等等。
最后更新:17 12月2019