总览
作者 Mike Cohn
豆瓣评分8.0分
我的评分7.5分
阅读时间20200502-20200504
拆解
char 1 概览
1. 为什么需要用户故事
目的：
（1）以更快的速度、更少的消耗应对现实世界需求的快速变化。
（2）但不仅仅是为了快.，而是相比与传统亢长的需求文档，人的大脑更喜欢图文并茂的说明，且面对同一主题，只有通过多种不同方式、不同活动的刺激，大脑才能深刻理解并记忆。
（3）可以从用户角度出发描述功能，避免程序员自行其是，降低系统开发进入后期出现整体风险的可能，为系统带来更大的灵活性。
Ron Jeffries，极限编程创始人之一，提出了“3C原则”：card、conversation、confirmation。
使用卡片记录用户故事：
①可以隐藏底层细节
②可以方便各方人员在白板上将其移动，以整体图形的方式将客户需求有关的内容深深印在团队的脑海中
③可以从全局角度查看，有利于项目的规划。
④用户故事的确认环节，则以反复的方式，与用户确认某个具体使用场景中的关键细节，从而不会导致遗漏。
2. 什么是用户故事
用户故事的组成
①一份书面的故事描述，用来做计划和作为提示
②有关故事的对话，用于具体化故事细节
③测试，用于表达和编档故事细节且可用于确定故事何时完成
“卡片代客户需求而不是记录需求”，卡片包含故事的文字描述，而需求细节要在“对话”中获得，并在“确认”部分得以记录 ---即：3C原则
故事不具有契约性质。达成的协议将由测试来记录，这些测试将演示故事是否被正确开发。
3. 规划发布和迭代
一个发布由一个或多轮迭代组成。在规定的时间内发布用户需求。
在进行发布规划时，需要将故事进行优先级排序，一般考虑以下几点：
①大部分用户和客户对特定特许的渴望程度
②小部分重要用户和客户对特定特性的渴望程度
③故事之间的关系。 e.g. “缩小”（zoom out ）这个故事的优先级可能不高，但是它可能被看作是高优先级的，因为它与高优先级的另一个故事“放大”（zoom in）。💡【即需求间的关联性】
④当与开发人员的意见相左时，应倾听其观点，但要坚持客户组织利益最大化的原则
⑤要考虑故事的实现成本，其成本由开发者给出，每个故事用故事点来估计，故事点表明一个故事相对于其他故事的大小和复杂度。
4. 验收测试
验收测试是用来验证实现用户故事是否符合客户团队的期望。
测试应该尽早的在迭代中编写测试用例，这样可以尽早的查漏补缺。
char 2 编写故事
1. 优秀用户故事的特点
独立的（Independent）
当故事之间存在依赖时，尽可能地将相互依赖的故事合并成一个大的、独立的故事，或是用一个不同的方式去分割故事。
可讨论的（Negotiable）
故事卡是对功能的简短描述，细节将在客户团队和开发团队的讨论中产生。如果我们在编写故事的时候已经知道了一些重要细节，那么可以在故事卡中以注释的形式记录这些细节。
过早地制定细节会带来更多的工作量，且会导致一种错觉，故事卡反应了所有细节，没必要跟客户进行进一步的讨论。
有意义的故事卡应：
①一两句短语，用来提醒开发人员和客户进行对话。
②一些注释，用以表明在对话中待解决的问题
e.g.
user story：公司可以用信用卡支付发布的工作信息的费用.
备注：我们将支持发现信用卡吗？
用户界面备注：不需要专门的字段来输入信用卡的类别卡片种类（可以从卡号的前两位数字获得该信息）
对用户或客户有价值的（Valuable to Purchasers or users）
保证每个故事对客户或用户有价值的最好办法是让客户来编写故事。--💡【不太可能】
应当避免那些只对开发人员有价值的故事。（技术细节）
可估计的（Estimatable）
导致故事没办法估计的原因有：
①开发人员缺少领域知识
②开发人员缺少技术知识
需要做预研，研究对应的技术知识
③故事太大了
可以按照“创建”、“编辑”、“删除”这些动作来分解故事；也剋按数据的边界来进行分解
可测试的（Testable）
成功通过测试才可以证明开发人员正确地实现了故事。通常不能被测试的故事发生在一些非功能性的需求上，这些需求和软件有关，但不直接与功能有关
e.g.
用户必须觉得软件很好用；
用户绝不需要花很长时间等待窗口出现。
char 3 用户角色建模
用户角色 User Role ：是一组属性的集合，这些属性刻画了一群人的特征以及这群人与系统可能的交互。
要坚持“用户角色定义的是人，而不是其他外部系统”
1. 角色建模的步骤
①通过头脑风暴，列出初始的用户角色集合
②整理最初的角色集合
③整合角色
④提炼角色
💡可以构建虚拟人物和极端人物
虚拟人物：一般为产品的目标用户，可以使用户故事更加生动和贴合需求
极端人物：一般在考虑新系统的设计是，可以使用极端人物，可以让我们编写出原本可能遗漏的故事，或其他灵感。（但不宜花过多的时间）
char 4 搜集故事
1. 如果进行需求调研
我们要承认无法一次性全部获取到用户的需求，但还是要在早期尝试编写我们可以编写的故事，即便还是史诗级故事。随着时间的推移以及先前迭代中加入产品的故事，一个故事的相关性会有所变化。我们要用拖网（trawling）的形式，即“拖网渔船捕捞鱼”一样来收集用户需求。
2. 获取需求的方法
用户访谈
①访谈成功的关键之一是，选择正确的受访者
②要询问开放式、与背景无关的问题
问卷调查
适用于收集已有故事的相关信息、需要用户就某些具体问题的回答。
不适合作为捕获新故事的主要方法。
观察
观察可以让我们快速直接地从用户那里获得反馈，从而可以更早、更频繁地发布软件。
故事编写工作坊
是开发人员、用户、产品客户和其他对编写故事有帮助的人共同参加的会议。
在工作坊期间，参与人员编写尽可能多的故事，此时不对故事排优先级。
💡【类似头脑风暴，适用于研发新产品】
char 5 与用户代理合作
当我们无法接触到真正是使用用户时，就需要求助与用户代理（user proxy），他们自己可能不是用户，但是在项目里代表着用户。
选择合适的用户代理对于项目的成功至关重要，但是要充分考虑潜在用户代理的背景和动机。
1. 用户代理有哪些
① 用户的经理
②开发经理
③销售人员
④领域专家
⑤市场营销团队
⑥以前的用户
⑦培训师和技术支持
⑧业务分析师或系统分析师
2. 设立客户团队
当我们没办法接触实际的使用用户时，且又为了避免用户代理的“一面之词”，我们可以设立客户团队，来尽量获取到非偏颇的用户故事。
设立用户团队的方法
① 邀请真实用户加入。如果有不同类型的用户使用软件，试着邀请每种类型的用户
② 在客户团队中确定一位“项目负责人”，主要负责协调客户团队的协作，尽力做到传递一致的信息。
③ 确定项目成功必须的关键因素。
char 6 用户故事验收测试
验收测试提供了确认故事是否被完整实现的基本标准。
在一个敏捷的由故事驱动项目中，测试不是一个与开发相对抗的活动。发现bug时，不应该有“被我逮到了”的心态。若有bug直到系统投产的时候才被发现，团队成员不应该相互推卸责任，应以“我们共同负责”的心态防范这种事情发生。
测试的目的是发现并消除bug，没有必要追求100%代码覆盖率或测试所有的边界条件。可以运用我们的直觉、知识和过去的经验来指导测试。--💡【测试人员应该要遍历所有边界条件，产品可以不用】
1. 什么时候开始写测试用例
为了让程序员尽早了解这些信息，应当在为这个故事编写代码前就开始制定验收测试。
💡【测试用例评审】
在需求宣讲后进行测试用例评审，可以在测试用例评审过程中确认开发团队对需求的理解，也可以在测试用例过程评审中重新审视需求，看需求有哪些分支未考虑周全。
恰当编写测试用例的时机：
①开发人员和客户讨论故事且需要记录明确的细节时
②在迭代开始时，在写代码前作为一项专门的任务
③在开放中或之后任何时候发现新的测试时
为了测试用例的完整，应要自问：
①关于这个故事，程序员还需要知道什么？
②对怎么实现这个故事，我的想法是什么？
③有没有一些特殊情况会使这个故事有不一样的行为？
④这个故事在什么情况会出错？
2.多少测试才算多？
只要这些测试还在继续为故事增加价值和使它更加清晰，那么就应该继续编写测试。
但是客户不负责定义所以可能的测试，客户应该更专注于能向开发团队说明故事意图的测试。
3. 测试类型
用户交互测试：确保所有用户交互组件如期工作。
可用性测试：确保程序号用。
性能测试：测量应用程序在各种负荷下的工作状况。
压力测试：使应用程序在用户和事务的极限值情况或其他任何让应用程序处在压力下的情况运行。
char 7 优秀用户故事准则
为了确定用户故事，可以从每个用户角色使用系统的目标开始考虑
当用户故事较大时，可以将它分割成贯穿应用程序所有层面的故事，即可以提供某种程度的完整（end-to-end）的功能
如果有项目领域和环境的需要，可以用其他需求搜集或文档技术来补充故事
可以为故事创建卡片约束（即需求的约束条件）
不要让故事过早涉及用户界面
用主动语态来描述谷歌书
为单个用户编写故事，这时故事的可读性通常是最强的
用户故事要简短，它的目的是提醒其要沟通。更多的细节conversation中讨论。
char 8 估算用户故事
用故事点（story point）来进行估算用户故事的完成时间。
故事点代表hi见的模糊单位，可以是一个理想日的工作，也可以是一个理想周的工作。
故事点应该由各个团队来定义自己认为合适的故事点。
对于用户故事点，开发人员的职责：
①负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。
②负责给出诚实的估算。不屈服于诱惑或压力二给出低的估算
③负责以团队估算
④负责估算应与其他估算一致。即工作量故事要统一，大小相似的需求，则工作量时间应一样
客户职责
负责参加估算会议，但是你的任务是回答问题并澄清故事细节。不必参加故事估算
char 9 发布计划
发布计划涉及到用户故事优先级的排序。我们需要确定哪些故事要排在这个迭代的发布计划中。
1. MoSCow原则
必须有（Must have）：指系统的基本功能
应该有（Should have）：指很重要但短期内有替代解决方法的功能。如果项目没有时间约束，则通常认为应该有的功能是强制性的
可以有（Could have）：指如果没有时间可以在发布中不考虑的功能
这次不会有（Won't have this time）：客户期望拥有但同时承认需要在后续发布中实现的功能
char 10 迭代计划
1. 迭代计划会议内容
①讨论故事
②从故事中分解出任务
③开发人员承担每个任务的职责
④讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。
char 11 测量并监控速率
💡【实际上就是团队中迭代的进度及开发的速率】 对于SM而言，可以知道自己的团队完成一个用户故事需要多长时间。
迭代燃尽图（Burndown Char）：可以了解到当前迭代的进展，及剩余的工作量
char 12 故事不是什么
用户故事不是IEEE830软件需求规格
不管预想多么全面，我们都无法事先完全定义一个完整的具有相当规模的系统；考虑用户的目标比列出方案的特性更重要
用户故事不是用例
用例往往比单个故事大，更容易包含关于用户界面的嵌入式假设；
用例比用户故事完整，用例存在于整个开发过程中，用户故事往往只是暂时的
用户故事与用例以不同的目的编写。用例被编写成方便开发人员和客户讨论并达成共识。用户故事编写成方便计划发布，并用于提醒需求细节的讨论
用户故事不是场景
交互式设计场景比用户故事具体，其提供的细节类型也不同于用户故事。一个场景可以由多个用例组成，它可以组成许多用户故事。
char 13 用户故事的优势
用户故事强调口头沟通
人人都可以理解用户故事
用户故事的大小适合做计划
用户故事适合于迭代开发
用户故事鼓励延迟细节
用户故事支持随机应变的开发
用户故事鼓励参与性设计
用户故事传播隐性知识
char 14 用户故事的不良征兆
故事太小
故事相互依赖
镀金
故事中包含太多的细节
过早包含用户界面细节
想得太远
故事划分太过频繁
很难为故事安排优先级
客户不愿意写用户故事，为故事安排优先级
char 15 Scrum与用户故事
1.Scrum基础
Sprint
实施Scrum过程的项目往往采用30天为周期的迭代，其迭代就称为Sprint，即迭代周期。
在每个Sprint开始的时候，团队需要确定这个Sprint需要完成而定工作。
surum是一种迭代和递增的过程。
产品Backlog
产品需求池，即包含了产品所有待开发的需求列表
Sprint Backlog
团队将需要计划迭代的需求从产品Backlog中移入下个迭代的需求池，即为Sprint Backlog。
Scrum团队
一个Scrum团队通常由4-7个开发人员组成。有两个承当特殊角色的人员是：产品负责人和ScrumMaster。
Scrum产品负责人：主要负责管理Product Backlog的内容以及排列优先级
ScrumMaster：职能类似于项目经理，只不过他不是管理者的角色，更像是研发leader。
Sprint计划会议
在每个Sprint的开始是Sprint计划会议。会议的参与者包含：PO、SM及团队的所有开发人员（其他的管理人员或用户代表也可参加）
在Sprint计划会议，PO负责把待开发的高优先级功能介绍给团队成员 ；团队成员根据所宣讲的内容进行提问。如果团队达成一致无疑问，则可以将该功能从产品Backlog移到Sprint Backlog 中。团队和产品负责人一起确定整个Sprint目标。一旦Sprint开始，只有团队成员才能向Sprint中添加工作。
💡 【类似需求迭代会议，但是需求迭代会议并不会像Sprint计划会议一样，在会议中确定需求的优先级以及决定需要移入Sprint Backlog中；而是在需求迭代会议之前单独与SM确定需求的优先级及下个迭代的计划。在需求会议的时候直接向团队成员进行迭代需求的宣讲。
好处：避免需求迭代会议时间过长；缺点：团队其他成员的参与感不强】
Sprint评审会议
在每个Sprint结束时，都会有一个Sprint评审会议。在会议上大家一起苹果是否达到了Sprint计划会上设定的Sprint目标。Sprint评审会议应该是非正式会议性质，尽量不要用幻灯片，准备时间也不要超过两个小时，不要让团队成员感到干扰或是负担
💡同需求回顾会议类似，即在每个迭代需求上线后，团队成员举行需求回顾会议。每个团队成员进行发言，回顾在迭代过程中自己或他人做得到的好的，做得不好的，以及对团队的建议
每日Scrum简会（Daily Scrum）
团队每天都会有一个简单的会议，在会议上所有成员审查团队的进度，并根据需要做出调整。每日Scrum简会一般安排在9：00或是9：30。所有的团餐成员都需要参加。会议必须简短，一般在15分钟内结束，最多不能超过30分钟。为了保证会议时间不至于过长，很多团队要求参加者站着开会，所以也被称为“每日站会”
在每日Scrum简会中，每个团队成员要求回答以下三个问题：
①你昨天做了什么？
②你今天打算做什么？
③有什么困难？
PS：不要让每日Scrum简会演变成成员向Sm汇报工作的会议。这个会议的重要目的是了解团队成员自己负责的需求开发进度。PO也需要向其他团队成员一样汇报进度。SM作为会议的组织者，需要保证会议的节奏。
管理层人员和其他人如果有兴趣了解项目状况，可以参加；但是非团队成员参加需要遵守一个规则：在会议中只有项目组内不人员才能够提问。
附录-极限编程概览
1. 极限编程的原则
快速反馈（rapid feedback）
向客户提供快速反馈，并从反馈中学习
假设简单（assuming simplicity）
喜欢简单，并总是试图在转移到更复杂的解决方案前，先做简单的解决方案
增量变化（incremental change）
通过小的、增量的i安华提高软件质量
拥抱变化（embrace change）
拥抱变化，因为他们知道自己是真正地善于包容和适应
高品质产品（quality work）
坚决主张软件应该始终展示出最高的质量工艺
2. 极限编程的价值
沟通（communication）
简单（simplicity）
反馈（feedback）
勇气（courage）
3. 极限编程的12个实践
短交付周期（small releases）
计划游戏（the planing game）
重构（refactoring）
测试（testing）
结对编程（pair programming）
持续一致的速度（sustainable pace）
团队代码所有权（team code ownership）
编码标准（coding standard）
简单设计（simple design）
隐喻（metaphor）
持续集成（continuous integration）
现成客户（on-site customer）
