概述
Scrum和顺序产品开发对待需求的方式非常不同。顺序产品开发中，需求不可协商、早早地就已细化并且是独立的。Scrum中，需求细节是开发期间持续不断的对话中协商出来的额，而且是等到团队构建功能的时候，及时、刚好地细化需求为团队提供支持。
因此，使用Scrum时，我们不会在前期就投入大量的时间和成本详细描述需求。因此我们认为，等过段时间进一步了解特性之后，细节会变的，所以要避免在今后要丢弃的需求上投入太多精力和时间。
利用对话
需求是一种沟通工具，可用于引导大家对特性达成共识。通过需求，了解应该创建哪些特性的人便可以和负责创建特性的人讲清楚自己想要什么。
有一种方法能够更好的确保构建出客户想要的特性，即邀请对特性有想法的人及时与设计、构建并测试这些特性的人对话。
口头沟通具有高宽带和可提供快速反馈的优势，能够更简便地取得共识。另外，对话使双向沟通成为可能，可以激发与问题和机会相关的想法，阅读文档可没有这种效果。
逐步细化
强制所以需求同时达到相同的详细程度，缺点如下：
- 必须在产品开发早期、对所知最少的情况下预测所有的需求细节。
- 对所有需求一视同仁，不考虑它们的优先顺序，这迫使我们把当下的宝贵资源全部用于细化日后也许永远不必构建的需求。
- 创建一个庞大的需求库存，但一旦事情有变，因返工或丢弃而导致的成本会很高。
- 减少了通过对话来细述和澄清需求的可能性，因为需求已经完整。
用户故事是什么？
用户故事是可用于陈述业务价值的一种简便格式，适合各种FBI,特别是特性。用户故事的制作方式旨在帮助业务人员与技术人员都能理解需求。
那么用户故事究竟是什么呢？有一个简单有效的方法来帮助我们理解用户故事。3C:卡片（Card）、会话（Conversation）和确认（Confirmation）。
卡片
用户故事模板与卡片.jpg
写用户故事有一个通用模板格式。即写明用户种类（即用户角色）、这类用户想要达成=什么（目标）以及用户为什么想达成目标（收益）。除非每个人都理解，否则每个用户故事都得有这部分描述。
对话
开发团队、产品负责人和利益干系人会在对话中发现并探讨需求的细节。用户故事仅仅是进行次会话的承诺。会话 通常都不是一次性事件，而是持续的深度对话。写用户故事的时候有一个对话，修订的时候又有一个会话，估算的时候再有一个，冲刺规划会议（团队深入至任务级细节）的时候还有一个，最后冲刺中间设计、构建并测试用户的时候都有持续对话。
用户故事的好处在于它能把关注点从写作转移到会话。对话开启了一个更丰富的信息交换与协作形式，从而确保正确描述需求并使每个人都能理解需求。
确认
用户故事还要包含确认信息，它体现为满意条件的形式，是接收标准。如果卡片正面是对故事的几行描述，背面就可以写上最重要的基本满意条件。这些满足条件也可以看作高一级的接收测试。
详细程度
用户故事是一种优秀的工具，可以承载着客户或用户价值的条目贯穿于Scrum的价值创造流程。然而，如果故事的大小都一样，就很难做好概要计划并体会到逐步细化的好处。
在冲刺级别使用的故事太小太多，是无法为概要产品规划和发布规划提供支持的。在这些层级上，我们需要更少、更不详细、更抽象的条目。否则，我们就会淹没在大量无关的细节中。
用户故事的抽象层级结构.jpg
第一级别故事跨度较大也不太详细，称为史诗，是个很好的占位符，等将来到合适时间再创建大量更详细的故事。
第二级别故事的大小通常以周为单位，对单个冲刺来说还是有点大。有些团队称之为“特性”。
最小的用户故事通常称之为“故事”。为了和其他级别故事区别，有些人把这些故事叫做冲刺故事或者可实现故事，暗示它们的大小以天为单位，足够小，可以一个冲刺完成。有些团队也使用“主题”这个术语来指代一组相关联的故事。主题用一种便捷的方式来表明一串故事是有共性。
好故事的INVEST原则
- 独立
- 可协商
- 有价值
- 可估算
- 大小合适
- 可测试
独立
用户故事应该是独立的，至少也应该是相互松散解耦的，尽量避免依赖关系，这样才实用。相互依赖程度高的故事会使估算、牌友顺序和规划复杂化。
可协商
故事不是以前需求文档形式写就的书面合同。相反，故事是占位符，用于协商细节。
好故事能够清晰地捕捉哪些业务功能是用户想要的，他们为什么想要。它们要为产品负责人、利益干系人与团队留出空间。
可协商性有助于当事人避免在使用详见的前期文档是常见的推诿和相互职责心态。所以，可协商的故事就能避免事先写详尽需求所带来的种种问题。故事关乎的是做什么以及为什么这么做，而不是如何做。如果不可协商，就会减少团队的创新机会。由此而导致的创新浪费可能造成毁灭性经济影响。
有价值
对客户、用户或者两者来说，故事都要有价值。
有价值的标准关键在于，列表中所有故事都必须由产品负责人以客户与用户代言人的身份认可他们的价值。不是所有的故事都是独立的，也不是所有的故事都是完全可协商的，但她们都必须有价值。
可估算
故事应该是做设计、构建已经测试工作的团队可以估算的。估算故事的大小，可以指明故事的工作量和成本。
估不出来的原因
- 故事太大太模糊：团队和产品负责人在一起，把它拆成更容易管理的故事。
- 团队积累的知识不够：需要通过某种方式来获取信息。
大小合适、
已经开工的故事应该是大小合适的。冲刺中正在做的故事应该足够小。故事太大，完不成的风险实在是很高。
可测试
故事的相关测试要么通过、要么失败。“可测试”意味着故事要有相应的优质接收标准，即之前介绍的故事“确认”。
<br />
<br />
<br />
网友评论