《用户故事与敏捷方法》读书笔记

User Stories Applied

第一部分 起步

第一章 概览

什么是用户故事

用户故事描述了对用户、系统或软件购买者有价值的功能。

• 一份书面的故事描述，用来做计划和作为提示。 （Card）
• 有关故事的对话，用于具体化故事细节。（Conversation）
• 测试，用户表达和编档故事细节且可用于确定故事何时完成。（Confirmation）

规划发布和迭代

假设开发团队每轮迭代的速率是13个故事点：

故事	故事点数
故事A	3
故事B	5
故事C	5
故事D	3
故事E	1
故事F	8
故事G	5
故事H	5
故事I	5
故事J	2

用户故事的发布计划：

迭代	故事	故事点数
迭代1	A、B、C	13
迭代1	D、E、F	12
迭代1	G、H、J	12
迭代1	I	5

分割故事，做更好的发布计划：把故事I分成故事Y（3个点）和故事Z（2个点）

迭代	故事	故事点数
迭代1	A、B、C	13
迭代1	D、E、F	12
迭代1	G、H、Y	13
迭代1	J、Z	4

什么是验收测试？

假设写下故事“用户可以用信用卡为购物车中的物品付款”。然后再故事卡背面写下测试描述：

• 用Visa信用卡、万事达信用卡测试（通过）。
• 用大来卡测试（失败）
• 用Visa借记卡测试（通过）
• 用有效、无效和反面丢失卡ID号的信用卡测试
• 用过期卡测试。
• 用不同购买金额测试（包括超出信用卡额度）

为什么要变？

Change is a law, and no amount of pretending will alter the reality.

• 用户故事强调对话交流而不是书面沟通。
• 用户故事可以同时被你和开发人员理解。
• 用户故事的大小适合于做计划。
• 用户故事适用于迭代开发。
• 用户故事鼓励推迟考虑细节，直到你非常清楚地了解自己的真正需求。

小结

• 故事卡包含对用户或者客户有价值的功能的简短描述。
• 故事卡是故事的可见部分，但客户团队和开发人员关于故事的对话更重要。
• 客户团队包括那些确保软件符合潜在用户需求的人，可以包括测试人员、产品经理、实际用户和交互设计师。
• 故事卡由客户团队编写，因为他们最了解如何表达需要实现的需求，也因为他们会在后期于开发人员共同确定故事细节并安排故事的优先级。
• 按照故事对客户的价值来安排故事的优先级。
• 将各个故事放入迭代，进行发布与迭代规划。
• 速率是开发人员可以在一轮迭代中完成的工作量。
• 放入一轮迭代的故事估计总和不能超过事先开发人员预计的速率。
• 如果故事太大以至于无法在一轮迭代中完成，可以考虑把它分成两个或更多的小故事。
• 验收测试用于验证实现的故事是否开发成符合客户团队的设想。
• 用户故事是很有意义的，因为它们强调口头交流，你和开发人员都可以理解，可以用于进行迭代计划，在迭代开发中能很好地工作，而且因为它们鼓励推迟细节。

第 2 章 编写故事

优秀的故事的特点：（INVEST）

• 独立性（Independent）
• 可讨论的（Negotiable）
• 对用户或客户有价值的（Valuable to Purchasers or Users）
• 可估计的（Estimatable）
• 小的（Small）
• 可测试的（Testable）

小结

• 理想情况下，故事之间是独立的。故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现。
• 故事细节由用户和开发人员讨论得出。
• 故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事。
• 故事可以注释一些细节，但是过多的细节会使故事难以理解。
• 给故事加上注释的最好方法是给它编写测试用例。
• 如果故事太大，复合故事和复杂故事可以分成几个小的故事。
• 如果故事太小，几个小故事可以合并成一个较大的故事。
• 故事应该是可以测试的。

开发人员职责

• 帮助客户编写故事，故事要能提醒你们同客户交谈，不是记录详细的需求定义，故事应该对用户或者客户有价值，它们是独立的、可测的、大小合适的。
• 使用对用户或客户有价值的术语来描述实现故事所用的技术或者基础架构信息。

客户团队职责

• 负责编写故事。

第 3 章 用户角色建模

• 通过头脑风暴，列出初始的用户角色集合
• 整理最初的角色集合
• 整合角色
• 提炼角色

小结

• 大部分项目小组只考虑单一的用户类型。导致软件忽略原本需要的一些用户类型。
• 为了避免从单一用户的角度编写所有故事，要识别与软件交互的不同用户角色。
• 通过对每个用户角色定义相关特征，可以更清楚地看到不同角色间的不同点。
• 对于有些用户角色而已，用代表人物来描述会很有帮助。虚构人物是假想出来的用户角色代表。他们有名字，有照片，还有足够的相关细节，因为对项目成员来说，很真实。
• 对于有些应用程序，极端人物可能有助于搜集原本被遗漏的故事。

开发人员职责

• 负责参与确认用户角色和虚拟人物的过程。
• 负责理解每个用户角色或虚拟人物，以及它们之间的异同。
• 开发软件时，负责考虑不同的用户角色对于软件如何运行的不同偏好。
• 负责确保在识别和描述用户角色时，它们只是这个过程中的工具，不应超越作为工具之外的任何用途。

客户职责

• 负责寻找用户（多多益善），并识别恰当的用户角色。
• 确保软件没有关注不恰当的用户。
• 确保每个故事都能和至少一个用户角色或虚构人物联系起来。
• 开发软件时，负责考虑不同的用户角色对于软件如何运行的不同偏好。
• 负责确保在识别和描述用户角色时，它们只是这个过程中的工具，不应超越作为工具之外的任何用途。

第 4 章 搜集故事

创建故事最有用的一些方法：

• 用户访谈
• 问卷调查
• 观察
• 故事编写工作坊

简单原型.png

通过画上面这个原型，得到以下故事：

• 求职者可以发布他的简历。
• 雇主可以发布工作。
• 雇主可以查看提交的简历。
• 求职者可以搜索工作
• 求职者可以看到符合搜索条件的工作。
• 求职者可以看到指定工作的详细信息。

画原型的过程中，问一些有助于找到遗漏故事的问题：

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

小结

• 能够引出及捕捉需求这一想法是错误的。
• 拖网捕鱼的比喻非常有用。
• 即使敏捷流程支持需求的后期涌现，依然需要对预期的发布进行展望并开始写下容易发现的故事。
• 可以通过用户访谈、观察用户、问卷调查和举办故事编写工作坊来发现用户故事。
• 使用多种方法比过度使用一种方法更能获得好的效果。
• 通过开放式、与背景无关的提问更容易获得有用的答案。

开发人员职责

• 负责理解并使用多种技巧来捕捞用户故事。
• 负责知道怎么使用开放式和背景无关的提问。

客户职责

• 负责理解并使用多种技巧来捕捞用户故事。
• 负责尽早写更多的用户故事。
• 作为软件用户的主要代表，负责和他们多沟通。
• 了解怎么使用开放式和背景无关的提问。
• 如果需要关于编写故事的帮助，负责安排并举办一次或多次故事编写工作坊。
• 负责确保在捕捞故事过程中考虑所有用户角色。

第 5 章 与用户代理合作

小结

• 除非用户的经理也是用户，否则他就不是合适的用户代理。
• 开发经理会试图担任用户代理，因为他们已经参与到项目每天的细节中。然而，开发经理大多不是正在开发的软件的用户，所以他们不是理想的用户代理。
• 在产品公司里，客户经常来自市场团队。
• 与很多不同的客户联系的销售人员可以是很好的开发项目客户。
• 领域专家可以成为优秀的用户代理。
• 客户，那些做出购买决定的人，如果他们能与用户密切地交流，那么他们能成为非常好的用户代理。
• 为了成为好的用户代理，培训师和技术支持人员必须避免仅仅关注产品中那些他们每天关心的方面。

开发人员职责

• 负责帮助组织机构为项目物色合适的客户。
• 负责了解不同类型的用户代理怎么考虑你们正在开发的系统，他们的背景如何影响交付。

客户团队职责

• 如果你不是软件的用户，则要负责了解自己属于哪类用户代理。
• 负责理解自己会将哪些偏见带到项目中，如何克服这个问题，无论是依靠别人还是其他方法。

第 6 章 用户故事验收测试

测试是一个两步流程：

• 将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面；
• 将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整地实现。

一般在这些时候写测试：

• 开发人员和客户讨论故事且需要记录明确的细节时。
• 在迭代开始时，在写代码前作为一项专门的任务。
• 在开发中或之后的任何时候发现新的测试时。

客户和开发人员讨论故事的时候，比较好的做法是问一些类似的问题：

• 关于这个故事，程序员还需要知道什么？
• 对怎么实现这个故事，我的想法是什么？
• 有没有一些特殊情况会使这个故事有不一样的行为？
• 这个故事在什么情况会出错？

测试类型

• 用户交互测试，确保所有用户交互组件如期工作。
• 可用性测试，确保程序好用。
• 性能测试，测量应用程序在各种负荷下的工作状况。
• 压力测试，使应用程序在用户和事务的极限情况或其他任何让应用程序处在压力下的情况运行。

小结

• 验收测试可以用来记录客户和开发人员讨论的很多细节。
• 验收测试记录了有关故事的一些假设，这些假设可能还没有和开发人员讨论过。
• 验收测试提供了检查故事是否被完整实现的基本标准。
• 验收测试应由客户来写而不是开发人员。
• 验收测试应在程序员写代码之前写好。
• 如果新的测试对阐明故事的细节或意图没有任何帮助，就不用再写。
• FIT 和 FitNesse 是写验收测试的优秀工具，它们用的是我们熟悉的表格或电子表格格式。

开发人员职责

• 若团队觉得有需要，则负责实现自动化验收测试。
• 开始开发一个新的故事时，负责考虑更多的验收测试。
• 负责为代码作单元测试，使验收测试就不必顾及故事的每个细节。

客户职责

• 负责编写验收测试
• 负责执行验收测试

第 7 章 优秀用户故事准则

• 从目标故事开始

• 切蛋糕

• 编写封闭的故事

• 卡片约束

• 根据实现时间来确定故事规模

• 不要过早涉及用户界面

• 有些需求并不是故事

• 在故事里包括用户角色

• 只为一个用户编写

• 以主动语态编写

• 由客户编写

• 向故事卡编号说“不”

• 不要忘记意图

小结

• 为了确定故事，从每个用户角色使用系统的目标开始考虑。
• 分割故事时，试着将它分割成贯穿应用程序所有层面的故事。
• 试着让故事的大小能够在使用后让用户有成就感。
• 如果有项目领域和环境的需要，可以用其他需求搜集或文档技术来补充故事。
• 创建约束卡，将它们贴在公共的墙上，或者编写测试来确保系统没有违反约束。
• 为团队即将实现的功能编写小的故事，针对未来实现的功能编写宽泛的、高层次的故事。
• 不要让故事过早涉及用户界面。
• 实际编写故事时，要包括用户角色。
• 用主动语态编写故事。
• 为单个用户编写故事。
• 让客户，而不是开发人员，编写故事。
• 用户故事要简短。
• 不要给故事卡编号。

第 2 部分 估算和计划

第 8 章 估算用户故事

估算故事的最好方法具有如下特点：

• 无论什么时候获得有关故事的新信息，都允许我们改变之前的想法。
• 适用于史诗故事和小故事
• 不需要花很多时间
• 提供进度和剩余工作的有用信息
• 不太精确的估算也不会有太大问题
• 可以用来制定发布计划

故事点

理想工作日：一天中没有任何干扰，没有会议，没有电子邮件，没有电话等等

以团队估算

• 还不确定团队中谁负责完成这个故事；
• 团队决定的估算可能比个人估算更有用。

所有事情都要花4小时

Mad About You中， 主角是住在纽约的一对新婚夫妇。有一集中，妻子缠着丈夫去买沙发。她坚持认为只需要花一个小时。丈夫告诉她“这个世界上所有的事情都要花4个小时。你会去那，做各种事情，吃东西，谈论你其实应该在哪里进餐更好，然后回家。这至少是4个小时。”
程序员估算一个故事时，应该考虑完成这个故事需做的所有事。他们要全盘考虑测试代码，和客户讨论，可能帮助客户计划或自动化验收测试等诸多因素。如果不将这些考虑在内，无异于期望只花一个小时买个沙发。

可以用纸牌的方式，让大家估算时间。估算值很可能相差很大。这其实是一件好事。如果估值不同，估算值高的和低的再解释一下估算依据。值得注意的是，这时不要互相攻击对方，而是耐心听取他们的想法。

讨论完之后，开发人员再次将估算值写在卡片上。当大家都写好修改的估算值，将卡再次展示给所有人看。如果估算值还是相差很大，重复让估高和估低的人解释他们的想法。

三角测量

image.png

使用故事点

如果用结对编程呢？

如，有个两个开发人员的团队按理想日来估算故事点。他们没有用结对编程。他们计划一个一星期的迭代，一共两个故事，每个估算3个故事点，完成这轮迭代，他们完成了这两个故事并算出其团队速率为6。如果他们用结对编程并且以理想结对日来估算。他们研究故事后决定每个故事需要两个理想结对日。这个迭代结束后，他们完成了这两个故事，并算出其团队速率为4。数字不一样，但这两种情况速率是一样的。一个迭代都是完成这两个故事。

一些提醒

• 你的团队的故事点和我的团队的故事点是不一样的。你的团队估算的故事有3个故事点，可能我的团队估算有5个故事点。
• 一个故事（可能是一个史诗故事）分解成一些小故事后，这些小故事估算的总和不需要与开始那个故事或史诗故事估算相等。
• 类似地，一个故事分解成一些任务。这些任务估算的总和不需要与故事的估算相等。

小结

• 用故事点估算故事，故事点是故事复杂度、工作量或工期的相对估算。
• 应由团队估算故事，估算属于团队而不是个人。
• 通过和其他估算进行比较来进行三角测量。
• 团队是否使用结对编程对故事点估算没有影响。结对编程影响的是团队的速率，不是他们的估算。

开发人员职责

• 负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。
• 负责给出诚实的估算，不屈服于诱惑或压力而给出低的估算。
• 负责以团队估算
• 负责估算应与其他估算一致。即所有2点的故事都应差不多。

客户职责

• 负责参加估算会议，但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。

第 9 章 发布计划

DSDM(Business Focused Development) 包括一个排列优先级的方法，称为莫斯科（MoSCow）规则：

• 必须有（Must have）
• 应该有（Should have）
• 可以有（Could have）
• 这次不会有（Won't have this time）

可以通过多个维度为故事排列优先级：

• 故事不能如期完成的风险（如需要有预期的性能特点或全新算法时）
• 推迟实现一个故事时对其他故事的影响。
• 故事对于广泛用户或客户的重要性
• 故事对于少部分重要用户或客户的重要性
• 故事与其他故事的内聚性

获得初始速率的三种方式：

• 使用历史值
• 执行一轮初始迭代，使用那轮迭代的速率
• 猜测

一个由6人组成的团队，使用为期2周的迭代长度（10个工作日），每轮迭代会有60个开发日。取决于他们预计的工作日与理想日之间的差异，他们可能想把速率估算为每轮迭代只能完成20~30个故事点。

小结

• 在计划发布时，有必要知道客户预期的大致发布日期和故事的相对优先级
• 故事应该以明确的顺序排列。
• 故事的优先级有客户确定，但也要考虑开发人员的想法
• 使用速率将以理想日为单位的估算转换成日历日
• 估算团队的初始速率是很有必要的

开发人员职责

• 负责提供信息给客户，以帮助她排列故事优先级
• 负责在基础性需求或者架构性需求与其他客户需求之间取得权衡，避免不切实际地提高基础性需求或架构性需求的优先级
• 建立发布计划时，负责在实际估算的基础上，适当包括一定长短的时间用以项目缓冲。

客户职责

• 负责以自己对故事价值的估计来确切排列用户故事的优先级。
• 负责诚实地表达发布期限。
• 负责理解理想日和日历日的不同
• 在想对故事的不同组件排列不同的优先级时，负责分割故事。
• 负责了解为何不应该谴责或批评一位个人速率为0.6的程序员，只因为她的速率小于1.0

第 10 章 迭代计划

迭代计划会议内容：

• 讨论故事
• 从故事中分解出任务
• 开发人员承担每个任务的职责
• 讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。

小结

• 迭代计划是发布计划的进一步计划，但只在迭代即将开始时才开始做迭代计划。
• 迭代计划中，团队讨论每个故事，然后从故事中分解出任务。
• 任务的大小没有强制的范围。相反，从故事中分解出任务用来帮助估算或鼓励多个开发人员合作完成一个故事。
• 每个任务都有开发人员承担。
• 开发人员通过估算他们承担的任务，评估他们是否承诺过度。

开发人员职责

• 负责参加迭代计划会议
• 负责帮助把所有故事划分为任务，而不只是自己想做的故事
• 负责为认领的任务承担责任。
• 负责确保承担适当工作量的任务
• 在整轮迭代中，负责监控自己剩余的工作，同时也要监控队友剩余的工作。如果很快就能完成自己的工作，就有责任帮助队友承担部分工作。

客户职责

• 负责对迭代中包含的故事排列优先级
• 负责指导开发人员交付他们能提供的最大商业价值，意味着，从发布计划设定后，诺有更高价值的故事，要负责调整优先级以交付最大的商业价值。
• 负责参加迭代计划会议。

第 11 章 测量并监控速率

尚未全部完成的故事不能包括在计算中，因为：

• 没法计算故事已完成的百分比；
• 不能使用带小数的值为速率引入错误的精度；
• 没完成的故事通常不能给用户或客户带来任何价值。

用集中全部力量完成一个故事的方法会提高团队的意识：大家一起先完成一些故事比所有故事都只完成一部分更有价值。

为每轮迭代画出计划速率和实际速率：

image.png image.png

Burndown Chart