用户最初信仰（什么是用户故事）
用户最初信仰（什么是用户故事）“ 用户故事”是一份简要的意向声明，描述了为用户执行的操作的系统需要。出于我们的目的，我们将用户故事定义为：我在更广泛的白皮书 “精益和可扩展” 的背景下简要讨论了用户故事敏捷企业需求信息模型 与企业敏捷性大局 1 ，其中，与主题，史诗和功能一起，它们是敏捷团队使用的主要需求工件。在本白皮书中，我们将更详细地描述用户故事，因为在这里我们将找到其中一个关键的敏捷实践，帮助我们将我们的解决方案直接与用户的特定需求保持一致，并帮助确保质量在同一时间。在引用的白皮书和相关的博客系列中，我突出了许多贡献企业敏捷实践的Scrum模型，例如，产品所有者的定义角色，这是我们的要求实践不可或缺的。 但是对于XP来说，我们欠用户的发明故事，它是XP的支持者，已经发展了这个神器的广度和深度。 然而，因为用户故事现在经常出现，所以这不像是“路上的方法论分叉” 在Scrum培训的构建中教授，作为构建产品积压和定义S
在敏捷开发中， 用户故事 (user stories) 是一种轻量级，更灵活的替代品指定软件需求的传统方法 - 软件需求规范，用例规格等。 实际上，可以说用户故事是最重要的敏捷开发 (Agile Development) 中的工件 (Artifacts)，因为它是主要将值流传递给用户的容器，敏捷开发就是快速实现价值 (Value)。
用户故事也可以作为我们整个增量价值交付 (incremental-value-delivery approach) 方法的隐喻，即：
定义有价值的用户价值故事 - 在短时间内实施和测试 - 演示和或交付
它对用户 - 捕获反馈 - 学习 - 永远重复！
我在更广泛的白皮书 “精益和可扩展” 的背景下简要讨论了用户故事敏捷企业需求信息模型 与企业敏捷性大局 1 ，其中，与主题，史诗和功能一起，它们是敏捷团队使用的主要需求工件。
在本白皮书中，我们将更详细地描述用户故事，因为在这里我们将找到其中一个关键的敏捷实践，帮助我们将我们的解决方案直接与用户的特定需求保持一致，并帮助确保质量在同一时间。
用户故事概述在引用的白皮书和相关的博客系列中，我突出了许多贡献企业敏捷实践的Scrum模型，例如，产品所有者的定义角色，这是我们的要求实践不可或缺的。 但是对于XP来说，我们欠用户的发明故事，它是XP的支持者，已经发展了这个神器的广度和深度。 然而，因为用户故事现在经常出现，所以这不像是“路上的方法论分叉” 在Scrum培训的构建中教授，作为构建产品积压和定义Sprint的工具内容。 也许我们让Mike Cohn感谢大部分的整合，因为他开发了用户在他的书“ 用户故事应用 [Cohn 2004]”中广泛讲述了他的 故事 ，并且他一直非常积极地参与其中Scrum联盟也是如此。
出于我们的目的，我们将用户故事定义为：
“ 用户故事”是一份简要的意向声明，描述了为用户执行的操作的系统需要。
在XP中，用户故事通常由客户编写，从而直接将客户集成到客户中发展进程。 在Scrum中，产品所有者经常使用来自的输入来编写用户故事客户 (Users)，利益相关者 (Stakeholders) 和团队 (Team)。 但是，在实际操作中，任何团队成员都有足够的领域知识可以编写用户故事，但是产品所有者 (Product Onwer)可以接受并优先考虑这些故事进入产品积压 (Product Blacklog)。
用户故事是一种工具 用于以开发人员和用户都能理解的方式定义系统的行为。用户故事将工作重点放在用户定义的价值上 而不是功能分解结构上 这是传统上工作的任务方式。它们为管理系统的需求提供了一种轻量级且有效的方法。
用户故事在索引卡上捕获功能的简短声明，或者可能使用在线工具。
例子：
登录我的网络能源监控门户网站
看我每天的能源使用情况
检查我当前的电费计费率
系统行为的详细信息不会出现在简要声明中，稍后将继续开发团队与产品所有者之间的对话和验收标准。
用户故事帮助桥接开发人员 - 客户沟通差距
在敏捷开发中，开发人员的工作是说出用户的语言，而不是用户的工作说技术语言。 有效的沟通是关键，我们需要一种共同的语言。用户故事提供了用于在用户和技术之间建立理解的通用语言球队。
XP的创造者之一Bill Wake用这种方式描述 [2] ：
洋泾浜语 (pidgin language)是一种简化的语言，通常用于交易，允许不能用他们的母语沟通的人，但仍然一起工作。 用户故事的行为就像这样。 我们没有期望客户或用户以与程序员相同的方式查看系统; 用户故事充当了洋泾浜语 双方都能达成一致同意有效合作的语言 。
通过用户故事，我们了解彼此语言的必要条件无需和熟练到足以制作十四行诗 (sonnet)的程度; 我们只需要了解对方就知道我们什么时候适当的交流！
用户故事不是软件需求
虽然用户故事完成了以前由软件需求规范 (software requirement specification)、用例 (use cases) 等所做的大部分工作，但它们在许多微妙但关键的方面却有着本质上的不同。
· 它们不是详细的要求规范（系统 应该做的事情）但是而意图转让的表达式（它需要做一些事情 好像是这样 ）
· 它们简短易读，易于开发人员，利益相关者 和用户理解
· 它们代表了有价值的功能的小增量，可以在a中开发几天到几周的时间
· 它们相对容易估计，因此可以实现功能迅速确定
· 它们不是大型的，笨拙的文件，而是组织在可以的列表中随着新信息的发现，更容易安排和重新安排
· 它们在项目开始时并未详细说明，而是在时间基础上详细阐述 - 从而避免过早的特异性，延迟开发，需求库存，以及解决方案的过度约束声明•它们几乎不需要维护，实施后可以安全丢弃
·
用户故事以及此后快速创建的代码作为输入文档，然后逐步开发
·
用户故事3Cs: 卡 (Card)，会话 (conversation) 和确认 (Confirmation)另一位XP的创造者Ron Jeffries描述了我们最喜欢的用户故事的思考方式。 他使用卡片 (card) ， 对话 (conversation) 和确认 (Confirmation) 来描述这三者的用户故事的元素：
卡片代表2-3句话，用来描述故事的意图。这一意图值得提醒以便将来进一步发展。，它概括了意图，代表了一个更详细的要求，其细节有待确定。
注意：在XP和敏捷中，故事通常是手动编写的索引卡 。 更典型的是在企业中采用电子表格或敏捷项目管理工具为文本和附件捕获“card”元素，但团队通常仍然使用卡片进行早期规划和头脑风暴，如我们稍后会看到。
对话 (Conversation) 代表团队，客户，产品所有者和其他利益相关者，这是必要的实现意图所需的更详细的行为。 其他话说， 卡片也代表了“谈话的承诺”意图。
确认 (Confirmation) 代表验收测试 ，这是如何客户或产品所有者将确认故事已经存在实施令他们满意。 换句话说，确认表示将适用的满足条件确定故事是否符合意图以及更详细的要求。
通过这个简单的头韵，我们有一个关于如何实现敏捷质量的对象课程比以后，实际的代码开发。 我们通过简单地确保每个新用户故事都是这样做的 a）以必要的细节进行讨论和改进，b）进行测试以满足关键
利益相关者。
用户故事声音在过去几年中，应用了一种新的标准化表格，增强了用户故事构建显着。 表格如下：
作为<role>我可以<activity>以便<business value>
哪里：
· 角色 - 表示正在执行操作的人员或可能正在接收该值的人员来自活动。 它甚至可能是另一个系统，如果那是启动活动的那个系。
· 活动 - 表示系统要执行的操作。
· 商业价值 - 代表企业的价值。
我们称之为用户故事表达的“用户语音”形式，并发现它是一个非常有用的结构。 [5] 因为它跨越了问题空间（<业务价值>交付）和解决方案空间（<活动>）用户执行系统）。 它还为团队提供了用户优先（<role>）透视图他们专注于商业价值并为真实的人解决实际问题。
这个用户故事的形式，大大提高了 为何以及如何理解，开发人员需要实现一个真正满足用户需求的系统。
例如，家庭能源管理系统的用户可能想要: [6]
作为消费者， （<role>）我希望能够看到我的日常能源使用情况（<我对系统的处理方式>）
这样我就可以开始了解如何随着时间的推移降低成本 （<我收到的商业价值>） 。
每个元素都提供重要的，扩展的上下文。 该 角色允许对产品进行细分功能，通常为活动提取其他基于角色的需求和上下文。 活动通常代表角色所需的“要求”。 和 值传达为什么活动需要，这往往可以引导团队找到可能提供的替代活动减少努力的相同价值。
用户故事详情用户故事的详细信息主要通过产品所有者和产品之间的对话传达团队，从一开始就让团队参与其中。 但是，如果需要有关故事的更多细节，它们可以以附件（模型，电子表格，算法或其他）的形式提供，其中附加到用户故事。 在这种情况下，用户故事充当“令牌”，其也携带更多对团队的具体行为。 应该随着时间的推移收集额外的用户故事细节（及时 Just-in-time) 在此之前和期间通过与团队和其他利益相关者的讨论和协作发展。
用户故事接受标准除了用户故事的陈述之外，还可以有其他说明，假设和验收标准与用户故事保持一致。 关于团队和客户之间的故事的许多讨论可能会采取在故事提交代码之前和期间放置。 活动中的替代流动，接受界限和其他说明应与故事一起捕捉。 其中很多可以将故事变成验收测试用例或其他功能测试用例。
例如，
作为消费者，我希望能够看到我的日常能量使用量，以便我可以开始了解如何使用随着时间的推移降低我的成本
验收标准：
· 每10秒读取一次DecaWatt仪表数据，并以15分钟为增量在门户上显示并在每次阅读时显示在家庭显示器上
· 阅读KiloWatt仪表以获取可用的新数据，并在每小时和每小时显示在门户上每次阅读后的家庭显示
· 目前 没有多日趋势（另一个故事）。
· 等等…
验收标准不是功能或单元测试，而是满足的条件放在系统上。 功能和单元测试在测试所有功能流程时更加深入，例外流程，边界条件以及与故事相关的相关功能。
INVEST - 好的用户故事敏捷团队花费大量时间（可能多达一半或更多）来发现，详细阐述，理解用户故事并为其编写验收测试。 这是应该的，因为它代表了以下事实：
为理解的目标编写代码不一定是软件开发中最难的部分，相反，它是理解的代码的真正目的是什么。
因此， 投资于良好的用户故事，尽管是在最后一个负责任的时刻，是值得努力的球队。 比尔·威克（Bill Wake）创造了第 7个 缩写词INVEST [7]来描述一个好的用户故事的属性。
Independent (獨立的)
Negotiable ( 可商议的)
Valuable (有价值的)
Estimable (可估计的)
Small (细小的)
Testable (可测试的)
INVEST模型相当普遍，许多敏捷团队根据这些模型评估他们的故事属性。 以下是我们对团队投资价值的看法。
独立独立意味着可以自己开发，测试甚至可能传递故事。因此，它也可以独立评估 。
随着产品功能的构建，许多故事将具有一些自然的、连续的依赖性，但是每一个故事都可以独立地交付价值。例如，一个产品可能显示一条记录，然后显示一个列表，然后对列表进行排序，筛选列表，准备多页列表，导出列表，编辑列表中的项目等。这些项目中的许多都具有顺序依赖性，但每个项目都提供独立的值，并且产品可能通过任何开发停止点进行发货。
但是，许多非价值的依赖关系，无论是技术的还是功能的，都倾向于找到自己的方式积压和这些我们需要找到并消除。 例如，非值函数依赖可能：
作为管理员，我可以设置消费者的密码安全规则，以便用户需要创建并保留安全密码，保证系统安全。
作为消费者，我需要遵循管理员设置的密码安全规则，以便我可以保持我的帐户的高安全性。
在此示例中，消费者故事取决于管理员故事。 管理员的故事只是在设定，清除和保留政策方面是可测试的; 但它对消费者的强制执行是不可测试的。此外，完成管理员故事不会使产品处于潜在的可交付状态 - 因此，没有独立的价值。
通过重新考虑故事（以及系统的设计），我们可以通过拆分来消除依赖性这些故事以不同的方式 - 在这种情况下通过应用的安全策略类型和在每个故事中将设置与执行相结合：
作为管理员，我可以设置密码有效期，以便用户被迫更改他们的密码定期。
作为管理员，我可以设置密码强度特征，以便用户需要创建难以破解的密码。现在，每个故事都可以独立存在，并且可以独立开发，测试和交付。
可面议......并可协商的
与传统要求不同，用户故事不是特定功能的合同，而是一个占位符，用于讨论，开发，测试和接受的要求。 这个谈判过程企业和团队之间认识到商业投入的合法性和首要地位，但是允许通过协作和反馈进行发现。
在我们之前的孤岛组织中，通常需要书面要求来促进有限的部门之间的通信带宽，并作为过去协议的记录。 敏捷，然而，它建立在一个基于团队的方法更有效地解决问题的概念的基础上动态协作环境。 用户故事是实时的和结构化的，以利用这种有效和直接沟通和协作方法。
最后，用户故事的可转让性有助于团队实现可预测性。 缺乏过度约束和过于详细的要求增强了团队和企业进行权衡的能力功能和交付日期之间。 因为每个故事都具有灵活性，团队具有更大的灵活性达到发布目标，增加可靠性并促进信任。
有价值
敏捷团队的目标很简单：在给定现有时间和资源的情况下提供最大价值限制。 因此，Value是INVEST模型和每个用户故事中最重要的属性必须为产品的用户，客户或利益相关者提供一些价值。 积压的优先顺序是价值和业务根据团队可以提供的价值成功或失败。
团队面临的典型挑战是学习如何编写可以的小型增量用户故事有效地提供价值。 传统方法已经根深蒂固地创造了功能性细分基于技术组件的结构。 这种用于构建软件延迟的技术分层方法值递送，直到多次迭代后将所有层放在一起。 Wake [8] 提供了他的垂直而非技术层次的视角。
将整个故事视为多层蛋糕，例如网络层，持久层，逻辑图层和表示层。 当我们[横向]分割一个故事时，我们只提供一部分那个蛋糕 我们想给顾客整个蛋糕的精髓，最好的方法是垂直切片穿过图层。 开发人员通常倾向于仅在一个层上工作一次（并使其“正确”）; 但是完整的数据库层（例如）几乎没有价值客户，如果没有表示层。
创建有价值的故事需要我们将功能分解结构从水平重新定位到垂直方法。 我们创建的故事贯穿整个架构，以便我们能够为其提供价值用户并尽可能早地寻求他们的反馈。
虽然通常价值集中在用户与系统交互，但有时价值更高适当关注客户代表或关键利益相关者。 例如，也许是营销导演要求对网站上展示的广告提高点击率。 虽然故事可能是从最终用户的角度编写：
作为消费者，我可以看到其他吸引我的能源定价计划，以便我可以参加程序更适合我的生活方式......为了提供一个更清晰的真实价值观，它会更恰当地写出来营销总监的观点：
作为公用事业营销总监，我可以为用户提供新的定价计划，以便他们更多可能会继续从我这里购买能源。
团队面临的另一个挑战是阐明代码重构等技术故事的价值，组件升级等。例如，产品所有者如何确定以下值：
重构错误记录系统。
将技术解决方案的价值阐述为用户故事将有助于与业务沟通相对重要性。 例如：
作为消费者，我可以在产品的任何位置收到一致且明确的错误消息，以便我知道如何解决这个问题。 要么作为技术支持成员，我希望用户随时随地收到一致且明确的消息应用程序，以便他们可以解决问题，而无需调用支持。
在后面这些例子中，价值对于用户 - 对产品所有者 - 利益相关者 - 以及对团队。
可估计
一个好的用户故事是可以估计的。 虽然任何规模的故事都可以在积压中，但为了它在迭代中开发和测试，团队应该能够提供它的近似估计完成它所需的复杂性和工作量。 估算的最小投资是确定它是否可以在一次迭代中完成。 额外的估计准确性将增加团队的可预测性。如果团队无法估计用户故事，则通常表明故事太大或不确定。
如果它 太大而无法估计，则应将其拆分为较小的故事。 如果故事太不确定无法估计，然后可以使用技术或功能尖峰故事来减少不确定性，从而使一个或多个可估计用户故事结果。 （以下各节将详细讨论这些主题中的每一个）。
估算用户故事的主要好处之一不仅仅是获得精确的大小，而是来自提出任何隐藏的假设，缺少验收标准，并澄清团队的共享了解这个故事。 因此，围绕估计过程的对话是（或更多）
重要的，比实际估计。 估计用户故事的能力受到大小的影响很大这个故事，我们接下来会看到。
足够小
用户故事应足够小，以便能够在迭代中完成，否则他们不能提供任何价值或在此时考虑 完成 。 但是，即使是较小的用户故事也能提供更敏捷性和生产力。 这有两个主要原因： 吞吐量增加和减少复杂性 。
增加吞吐量
从排队论 (queUIng theory) 来看，我们知道较小大小的批量可以更快地通过系统。 这是其中之一精益流动的主要原则在Little定律中得到了体现：
在一个稳定的系统中（吞吐量，单位时间内可以完成的工作量是不变的），我们必须减少在制品（我们正在处理的事情的数量），以减少周期时间（过程开始和结束之间经过的时间）。 在我们的例子中，这意味着 更少，正在处理的小故事会更快出来 。
而且，当系统加载到容量时，它可能变得不稳定，并且问题变得复杂。在负载较重的系统中，较大的批次移动速度不成比例地降低（吞吐量降低）系统。 （想想高峰时段的高速公路系统。摩托车的吞吐量要高得多汽车和卡车。 通过加载系统可以有更多空间来操纵较小的东西。）因为开发团队通常完全分配到或超过容量（80-120％），他们陷入“匆忙”小时“公路类别。
当容量达到80％左右时，较大的物体会比较小的物体增加周期时间（减速）对象。 更糟糕的是，周期时间的 变化会增加，这意味着预测何时变得更难批次实际上可能退出系统，如在图1的下方 9 中可以看到 。 反过来，这种可预测性较低对计划，承诺和团队的可信度造成严重破坏。
图1
大批量生产量较低，循环时间变化较大复杂性降低较小的故事不仅因为原始的，按比例的大小而更快地通过，但它们经历了更快，因为它们的 复杂性降低 ，并且复杂性与大小有非线性关系 。
在测试验证功能所需的测试排列时，最容易看到这一点随着函数本身的复杂性以指数速率增加。 这与我们的建议相关关于开发清洁代码，正如罗伯特马丁[马丁2009]注意到他的写作规则
软件功能：
· 规则1：做一件事
· 规则2：保持小
· 规则3：使它们小于那个
这是Fibonacci估计序列（即1 2 3 5 8 13 21 ......）的主要原因之一有效估计用户故事 - 努力估计随着故事规模的增加而非线性增长。
论规模与独立的关系
关于规模和独立性之间的关系，出现了一个公平的问题，因为这似乎是合乎逻辑的较小的故事增加了依赖的数量。 然而，较小的故事，即使有一些增加依赖性，提供更高的吞吐量并提供比大型故事更快的用户反馈。 所以agilist总是倾向于较小的故事， 然后使它们变得更小。
可测试
在正确完成的敏捷中， 所有代码都是经过测试的代码 ，因此故事必须是可测试的。 如果一个故事似乎不是可测试的，那么故事可能形成不良，过于复杂，或者可能依赖于积压中的其他故事。
为了确保 故事如果不能脱离， （成功测试）很多敏捷， 就不会进入迭代今天的团队采取了一种先试后试的方法。 这开始于使用Test Driven的XP社区开发，在编写代码以通过测试之前编写自动化单元测试的实践。
从那时起，这种方法哲学被应用于故事接受标准的制定和在编写故事本身之前进行必要的功能测试。 如果一个团队真的知道如何测试它，那么他们可能也知道如何编码。
为了确保可测试性，用户故事与模糊的需求共享一些常见的可测试性缺陷。
诸如 快速，管理，漂亮，干净等词语很容易编写，但很难测试，因为它们的意思对不同的人有不同的东西，因此应该避免。 虽然这些话确实提供了可转让性，提供一些明确，客观的界限将有助于团队和业务共享对产量的期望并避免重大意外。
拆分用户故事用户故事通常以特征或史诗开头 - 一个大而模糊的概念我们想要为用户做的事情。 我们经常发现这些大模糊的故事在我们的发现过程中，并在积压中捕获它们。 但是，这些是 复合故事 ，如右图所示，通常都太大了在迭代中实现。 为了准备迭代工作，a团队必须把它们分解成更小的故事。
没有用于将用户故事分成迭代大小的其他方式的例程比一般指导使每个故事提供一个垂直切片，一些用户价值，通过系统。 但是，基于最近的一些工作理查德劳伦斯，我们建议适当选择 十个常见模式来分割用户故事 ，如表1表示 [10]：
1.工作流程步骤
确定用户完成特定工作流然后实现的具体步增量阶段的工作流程。
作为一个实用程序，我想更新和发布为我的客户定价计划
......我可以向客户发布定价程序家用显示器
...我可以向客户的网站发送消息门户
...我可以将定价表发布给客户智能恒温器
2.业务规则变更
乍一看，有些故事看起来相当简单。但是，有时业务规则更复杂或者比第一眼看到的还要广泛。在这种情况下，将故事分成几个可能是有用的处理业务规则复杂性的故事。
作为 (As a) [一个实用工具]，我可以 (I want) [按客户排序不同的人口统计]
...按邮政编码排序
...按家庭人口统计排序
......按能耗排序
3.重大努力
有时故事可以分成几个部分，其中大部分工作将用于实施第一。在下面显示的示例中，应构建处理基础架构以支持第一个故事;添加更多功能应该在以后相对简单。
作为 (As a) 用户，我希望 (I want) 能够选择/更改我的定价程序与我的实用程序通过我的门户网站
...我想使用使用时间定价
......我想预付我的精力
...我想报名参加Critical-Peak-Pricing
4.简单/复杂
当团队讨论故事时，故事似乎越来越大（“x怎么样？ -你考虑过吗？“），停下来问”什么是最简单的东西可能有用？“抓住它简单版本作为自己的故事，然后将所有的变化和复杂性分解成自己的故事。
作为 (As a) 用户，我基本上想 (I want) 要固定价格，但是我还希望得到关键峰值的通知定价事件。
...回应时间和持续时间关键的峰值定价事件
......回应紧急事件
5.数据的变化
数据变体和数据源是范围和复杂性的另一个来源。考虑添加故事 -
在构建最简单的版本后及时。此处显示了本地化示例。
作为 (As a) 一个实用工具，我可以 (I can) 发送消息顾客
...用英语讲。
...在西班牙语中
......用阿拉伯语等
6.数据输入方法
有时复杂性在用户界面而不是功能本身。在这种情况下，分开故事使用最简单的UI构建它，然后再构建更丰富的UI。
作为用户，我可以查看我的能耗在各种图表中
...使用每周比较的条形图消费
...在比较图表中，所以我可以比较我的用于具有相同或相似的人家庭人口统计学
7. 推迟系统质量
有时，最初的实施并不是那么困难，而且努力的主要部分在于快速实现- 或可靠 - 或更精确 - 或更具可扩展性。但是，团队可以从基地学到很多东西实现，它应该对用户有一些价值，否则他们将无法完成所有这些工作。 在这案例，将故事分解为连续的“能力”。
作为用户，我希望看到实时从我的仪表消耗
...插入最后一次已知读数的数据
...显示来自仪表的实时数据
8. 操作（例如：创建读取更新删除（CRUD））
像 管理或控制这样的词是一个赠品，故事涵盖了多个操作，可以提供一个分裂故事的自然方式。
作为用户，我可以管理我的帐户。
...我可以注册一个帐户。
...我可以编辑我的帐户设置。
...我可以取消我的帐户。
...我可以在帐户中添加更多设备
9.用例场景
如果已经开发了用例来表示复杂的用户到系统或系统到系统的交互，那故事通常可以根据用例的各个场景进行划分。
“(I want) 我想参加节能活动通过零售经销商进行计划。“
用例/故事＃1（快乐路径）：通知实用程序消费者有设备
用例/故事＃2：实用程序提供设备和数据，通知消费者
用例/故事＃3（备用方案）：处理数据验证错误
10.突破一个尖峰
在某些情况下，故事可能太大或太复杂，或者实施可能很差了解。 在这种情况下，建立一个技术或功能峰值来解决它; 然后基于分裂故事结果。（请参阅以下部分中的Spikes）。
表格1
用于分割用户故事的十种模式团队通常会使用上述技术的组合来调整故事大小。有了这个技能，团队将能够以更快的速度向前发展，在发布和迭代时分割用户故事将边界规划成一口大小的块以供实施。
SpikesSpikes是XP的另一项发明，是一种特殊类型的故事，用于消除风险和不确定性用户故事或其他项目方面。可能出于多种原因使用尖峰：
1. 团队可能不了解新域名，并且Spikes值可能用于基础研究以使团队熟悉新技术或领域。
2. 故事可能太大而无法进行适当估计，团队可能会使用Spikes分析隐含的行为，这样他们就可以将故事分成可估计的部分。
3. 故事可能包含重大技术风险，团队可能需要做一些研究或原型设计，以获得对允许的技术方法的信心他们将用户故事提交给未来的时间框。
4. 这个故事可能包含重大的功能风险，因为故事的意图可能会有要理解，目前还不清楚系统如何与用户进行交互来实现利益暗示。
技术峰值和功能峰值技术Spikes值用于研究解决方案中的各种技术方法域。例如，技术Spikes值可用于确定构建与购买决定，评估新用户故事的潜在性能或负载影响，评估可应用于解决方案的特定实施技术，或者出于任何原因，当团队需要对a进行更自信的理解时在将新功能提交给时间盒之前所需的方法。
只要用户如何存在重大不确定性，就会使用功能Spikes值可能会与系统交互。功能Spikes值通常最好通过评估某种程度的原型设计，无论是用户界面模型，线框，页面流量，或任何最适合从客户那里获得反馈的技术利益相关者。某些用户故事可能需要两种类型的Spikes值。 例如：
作为一个消费者，我想在直方图中看到我的日常能量使用，这样我就能很快理解我的过去，现在，可能是近期，未来的能源消耗。
在这种情况下，团队可能会创建两个Spikes值：
技术Spikes值 ：研究将客户显示更新为当前使用所需的时间，确定通信要求，带宽以及是否推送或拉取数据。功能峰值：在门户网站中对直方图进行原型设计，并获得一些用户对演示文稿的反馈大小，样式和图表属性。
Spikes指南
可估计 Estimable，可证明 (Demonstratable) 和可接受 (Acceptable)
与其他故事一样，Spikes值被放入积压，可估计和大小以适应迭代。秒杀结果是与故事不同，因为它们通常产生信息，而不是工作代码。穗可能导致决策，原型，故事板，概念证明或其他部分解决方案，以帮助推动最后的结果。在任何情况下，钉子应该只发展足以解决问题的信息能够识别和调整隐藏在Spikes下面的故事的不确定性。
Spikes的结果对团队来说是可以演示的。这给研究和结果工作带来了能见度 也有助于建立集体自主权 并对正在作出的关键决定分担责任。
和其他故事一样，当峰值的验收标准得到满足时，产品所有者会接受峰值。
例外，而不是规则每个用户故事都有不确定性和风险——这就是敏捷开发的本质。团队通过讨论、协作、实验和协商发现正确的解决方案。因此，从某种意义上说，每个用户故事都包含Spikes级别的活动，以消除技术和功能风险。敏捷团队的目标是学习如何接受并有效地解决每个团队中的这种不确定性。
在考虑未来工作的Spikes时，首先考虑通过策略分解故事的方法上面讨论过。使用Spikes作为最后一个选项。
考虑在单独的Sprint中实现Spike由于Spikes代表一个或多个潜在故事的不确定性，因此计划Spikes和Spikes在同一次迭代中产生的故事是有风险的，通常应该避免。但是，如果穗是小而直接，可能会找到快速解决方案，没有任何问题在同一次迭代中完成故事。小心使用索引卡进行故事建模
使用索引卡进行故事建模进行故事编写和可视化建模值传递提供了强大的视觉效果和动态的手段让整个团队参与积压开发。有很多这种互动方式的优点：
索引卡的物理大小会强制文本长度限制，要求故事作者阐明他们的想法只用一两句话。这有助于保持用户故事小而专注 - 一个关键属性。有形的，卡片的物理性质使团队有能力在视觉上和空间上将它们排列成各种各样的配置以帮助定义积压：
· 卡可以按特征（或史诗或主题）并且可以写在相同的颜色上卡作为视觉区分的特征。
· 卡也可以按大小排列，以帮助开发人员看到之间的大小关系不同的故事。
· 卡可以按时间或迭代排列，以帮助评估依赖关系，理解逻辑排序看到对团队速度的影响，更好地协调和沟通不同利益相关者优先事任何
任何团队成员都可以写一张故事卡 将这些小的、有形的 "价值对象" 移动到桌子周围的物理行为都会创建一个互动的动态学习设置 参与者可以 "看到并触摸" 他们即将为自己的价值创造的价值。利益 相关 者。
经验表明 具有共同愿景的团队更致力于落实这一愿景。使用物理故事卡建模价值交付为所有团队成员和利益相关者提供了一个自然的参与模型 并为所有人提供了一个共同的、有形的愿景。
摘要在本白皮书中，我们概述了用户故事的衍生和应用敏捷团队使用的主要要求代理。除了背景和历史，我们已经描述了alliteration Card，Conversation 和 Confirmation，定义用户故事的关键元素。我们根据 INVEST 提供了一些开发良好用户故事的建议模型，并具体描述了小故事如何提高吞吐量和质量。一组模式还将描述将大型故事分成小故事，以便每个结果故事都可以在迭代中独立地交付价值。我们还提供了创建峰值的指南，作为故事 -
用于了解和管理开发风险的积压项目。总之，我们已经提出过这样的建议团队使用物理索引卡应用可视化建模来开发用户故事并创建共享愿景使用这种独特的敏捷需求构造实现用户价值。
参考书目
科恩，迈克。2004. 用户故事应用：敏捷软件开发。马萨诸塞州波士顿：Addison-韦斯利。
马丁，罗伯特。2009年 清洁守则：敏捷软件工艺的手册。波士顿：MA：Pearson教育。
Poppendieck，Mary和Tom Poppendieck。2007. 实施精益软件开发：来自现金的概念。马萨诸塞州波士顿：Addison-Wesley。
杰弗里斯，罗恩。2001年8月。“ 基本的XP：卡片，对话和确认。“XP杂志。
来源：转载
关注公众号:PMP项目管理之家、才聚项目管理PMP暨NPDP考试中心
