用户故事和敏捷方法 读书摘要

1 编写故事

这一章只列出了好故事的特点INVEST：独立的、可讨论、对用户有价值、开发人员可评估、小的、可测试的。

2 用户角色建模

这一章只列出了如何获得用户角色的方法，但并没有给出何种划分为好的依据。具体方法是一种精化的过程。

•  大家头脑风暴找出所有可能的角色 
•  初步整理，查看相关性 
•  对相关的角色进行合并及移除 
•  抽象出用户角色。

此外这一章给出了虚拟角色、极端人士两种考虑分类以保证我们考虑的齐全。

3 搜集故事

本章指出搜集需求与捕鱼的相似性，指出需求收集是一个由粗到精，先大后小，逐步精练的过程，并且需要掌握一定的技巧。

敏捷的用户故事推崇延迟细节，对于当前需要做的故事进行细化，而未来的故事则可以比较大，作为点位符，等到时机合适的时候才考虑。

作者列出了一些搜索故事的方法：用户访谈。观察、问卷、故事编写工作室。

在用户访谈时要通过开放式和背景无关的问题来从用户那里获取更多客观的信息。

在故事编写工作室中要先有一人原型，由系统的高层组件构成，针对每个角色都走一遍原型以发现用户故事。在运用原型时，最好利用深度优先的方法，把一条线上的故事都发掘出来，再切换其他的功能线。为了帮助发现故事，通过回答下面的问题可以为我们获取灵感。

•  用户接下来最可能做什么
•  用户会在这里犯什么错误
•  在这里，用户会有什么困惑
•  用户需要什么额外的信息

同时作者建议，在这个阶段，故事的数量比质量更重要。

4 与用户代理合作

本章列举了一些可能作为用户代理的群体，并给出了对应群体作为用户代理的问题，指出若不能和真实用户打成一片，最好以多个用户代理群体合作以获得软件的成功。并以最快速度发布软件，让用户使用，一旦软件发布就可以直接获得一线用户的反馈。

•  用户经理：用户经理可能并不真正使用软件，或更关注软件的管理功能。但用户经理在软件应用结果上有一定话语权上，因此要和经理搞好关系并接触真正的用户。
•  开发经理：开发经理也不真正使用软件，他们更关注技术先进性，除非开发经理和用户目的一致，否则开发经理用用户代理是最危险的选择之一。
•  销售人员：销售人员更关注特性的数量，而非质量，并过分关注订单的丢失，可能导致技术线失去长远战略。
•  领域专家：领域专家在领域软件开发中十分重要，但他们可能从专家的角度来使用软件，可能与普通用户的需求不一致。
•  营销人员：类似与销售人员
•  客户：决定用户是否能使用软件的人，其与使用用户的目的也可能不同，必须小心使用他们作为代理。
•  培训师与技术支持：使用他们可能让系统最终成为培训软件或技术支持软件。
•  业务分析师和系统分析师：很好的用户代理之一，问题是他们可能在用户问题上分析的时间过长，想的过多，而不是做调查。

5 验收测试

作者建议客户编写验收测试来判断故事是否完成，这些测试需要在开发人员写代码之前来确定，这可以让开发人员在开发时写出更完善的程序，验收测试是开发的一部分，测试用例用来 向开发团队说明故事的意图，而开发人员仍需要编写单元测试来发现验收测试之外的问题。

作者建议使用Fitness这个验收测试工作。

6 如何编写优秀的用户故事

本章是第1节的方法论，讲述怎么写出符合INVEST特性的故事。其中许多规则与编写有效用例的规则是一致的。

•  作者建议从目标故事开发，采用纵向切分的方式切蛋糕，每个故事都能贯穿系统架构的各层。
•  故事是独立封闭的，每个故事对用户而都完成一个完整的功能，让用户觉得有意义。
•  故事里包含用户角色，可以使用模板：我作为（角色），想要（功能），为此（商业价值）
•  虽然我们可以为一类用户编写故事，但从单个用户角度考虑故事，有些问题会变得更清楚
•  以用户为主语来编写故事。
•  为约束编写卡片，对于非功能需求，但系统必须遵守的规则可以写为约束卡。
•  不要过早在故事中涉及用户界面
•  虽然故事是敏捷中很好的分析需求的方法，但其他任务可以用来说明需求细节的技术都可以使用，如界面图，接口文档等。同时作者强调故事只是作为团队之间沟通的线索，故事并不能包含所有细节，但里面可以记录相关线索以供沟通时考虑，包含验收测试。

7 估算用户故事

 敏捷中以故事点来估算用户故事，不同的团队可以定义不同的点含义，1点可以是理想的1人天，也可以完成故事的难度评估，只要团队成员以一致的方法来评估即可。

 在敏捷团队中，故事是由团队评估的，而不是个人来评估的，这要求团队成员对于项目而言，技能差别不太大。

 估算的方法就是一群人坐在一起评估一个故事需要多少点，对于故事的细节，开发人员需要向客户进行详细的了解，以做出合理的评估，若大家的评估不一致，则需要相互沟通以消除这些不一致。

 对于评估出来的一组故事，需要进行三角测量。可以按点数对故事分类，检查故事点数为2的故事是否是故事点1的工作的2倍，以此类推。

 每个迭代中团队完成的故事点可以作为团队的开发速率，以在后续的迭代来作基准参考。需要注意的是，速率取的点为评估的点，而不是后来进行过校正的点数。

 作者认为对与大的点数，相差1点并不算误差，团队成员没有必要为1点之差进行讨论，因而作者建议了一个故事点的取值集合：1 2 3 5 8 13 20 40 80

8 发布计划

产品开发需要有一个路线图，它描述了产品的重点功能列表。从一份路线图上，发布计划取决于两点：发布时间和故事优先级，有了这两点，再结合团队的开发速度，就可以创建发面计划。

理想情况下，发布日期是一个时间范围，而不是一个具体的日期。而故事优先级需要由用户来排序，按照MoSCoW规则来进行排序，考虑故事未完成的风险、故事完成的价值、推迟一个故事的影响。

 必须有(MUST)  应该有(SHOULD)  可以有(COULD) 不会有(WON'T)

此外故事需要按明确的顺序排序，如第1，第2等，而不是非常高、中等等模糊顺序的分组

即使如何客户仍需要开发人员的时间评估方可进行有效的排序。因为高成本可能改变故事的优先级，相应的高风险、架构变更级别的故事都可能影响故事的优先级。当然如果用户在评估后仍然坚持选择了高成本和高风险的故事，那开发团队就需要满足客户的需要。

在计划时需要考虑一个因素是迭代长度，短迭代意味着更灵活的变更和透明性，但它会带来一些消耗。长迭代相反。不论如何迭代长度需要稳定而不能随意变化。

团队的初始速率有三种方法来获得：历史值、猜测、试运行两个迭代

9 迭代计划

本章主要讲述迭代计划会的组成内容：

•  讨论故事
•  从故事中分解任务
•  开发人员评估并承担任务
•  讨论所有故事，评估承担任务，以避免作出过于乐观的承诺

10 测量并监控速率

 注意每次迭代完成的点数不能包含部分完成的任务。

•  通过记录多个迭代中计划点数和实际完成点数而画图，可以评估团队的评估水平和实际完成水平的变化趋势
•  通过记录多个迭代中累积计划点和累积实际完成点而画图，可以评估团队的是否可以按计划完成发布
•  迭代燃尽图记录了每轮迭代后团队还未完成的点数，在任务变化不大的情况下，也可以较好的预测团队的完成计划是否满足预期。
•  迭代内的燃尽图显示了每日中还未完成的任务点数，可以帮助我们预测一个迭代的完成情况。这需要团队成员随时保持白板为最新。

 11 故事的其他讨论

 作者先将故事与IEEE 830软件需求规范进行了对比，指出830过于乏味不易理解，费时，不易管理变化。

 然后又将故事与用例进行了对比，指出二者在生存期、需求范围、完整性、目的上的不同点。

 以我的经验，用例是瀑布中需求的结果，比较重。但用例分析方法与故事分析法可以说是一样的，都以用户角色为出发点，以用户完成有价值的功能为核心。可以把故事看成用例的一种轻量级表示和应用。在软件过程中，用例可以用来组织故事，可以通过用例分析获取多个故事，在后期可以把故事组织成用例，生成文档以组织故事之间的关系。

 12 用户故事的优势

 故事比较小，且强调沟通，因而易于理解，适合计划和评估，鼓励延迟细节，支持随机应变的开发，便于传播隐性知识。适合迭代开发的轻量级的需求分析工作。

 当然故事也不是万能的，大型项目若依靠人与人之间的沟通则显得过于复杂，大量故事之间的关系也难以组织和管理，考虑到需求的可追溯性，仍需要进行一定的额外工作。

13 用户故事不良症状

•  故事太小
•  故事相互依赖
•  为故事完成了额外的功能或完成了额外的故事
•  细节过多
•  过早考虑UI
•  想的太远
•  用户很难排列优先级：一般是故事过大，需要拆分
•  用户不愿意写故事，也不愿意排列优先级

14 Scrum与故事

 本章介绍了一些Scrum的基础知识，不在此记录，用用Scrum works两天就能理解上面提到的概念与Scrum的对应。

整体来说，当你用Scrum运行个几个迭代之后，这本书里的许多知识你基本上已经掌握了，读这本书无非是把经验整理成理论，方便未使用过Scrum的同学入门，对于成熟的Scrum团队，这本书用处不太大。