本书概览
主要带着每章的问题，看书找答案
第Ⅰ部分：起步
第一章 概览
问题
1.1 用户故事描述了对用户、系统或软件购买者有价值的功能，由以下三部分组成：
一份书面的故事描述，用来做计划和作为提示；
有关故事的对话，用于具体化故事细节；
测试，用于表达和编档故事细节且可用于确定故事何时完成
1.2 客户团队包括确保软件满足用户需求的所有人，可以包括测试人员、产品经理、实际用户、交互设计师
1.4 面向瀑布的模型过程中，客户和用户只在开始的适合参与进来写需求，在结束的适合验收软件，不参与中间环节，故事驱动的项目，客户和用户在项目整个过程中全程参与
用户故事优势：
强调对话交流而不是书面沟通、可同时被你和开发人员理解、大小适合于做计划、适用于迭代开发、鼓励推迟考虑细节，知道非常清楚的俩姐自己的真正需求
1.5 测试应该尽早的在迭代中编写，客户团队的假设和预期会更早与开发人员沟通。
小结
答案
第二章 编写故事
问题
小结
史诗故事分两种：复合和复杂
架构刺探(Architectural Spike) -源于极限编程模式中的技术探险，写足够的代码来探知某个新兴技术（或不熟悉的技术）的使用所可能带来的技术风险， 对于复杂的调研任务，架构Owner可能需要部分团队成员的配合，在Sprint中安排Spike类型的任务。
探针(Spike) - Spike是一种技术尝试，用于通过快速失败来降低风险。
答案
第三章 用户角色建模
问题
小结
答案
第四章 搜集故事
问题
小结
不过在过程中评价故事的好坏，参与者觉得大家只是积累而不是评价故事，会更乐意参与
答案
第五章 与用户代理合作
问题
小结
开发人员：负责帮助组织机构为项目物色合适的客户，了解不同类型的用户代理怎么考虑你们正在开发的系统，他们的背景如何影响交互
客户团队：如果你不是软件的用户，则要负责了解自己属于哪类用户代理；理解自己会将哪些偏见带入项目中，如何克服这个问题，无论是依靠别人还是其他方法
答案
第六章 用户故事验收测试
问题
小结
测试是一个两步流程：第一，将测试要点记录在故事卡的背面，任何适合发现新的测试，都可以记录到故事卡的背面；第二，将测试要点变成全面的测试，这些测试可以用来演示故事已争取、完整的实现。
一般在下面这些时候写测试：开发人员和客户讨论故事且需要记录明确的细节时；在迭代开始时，在写代码前作为一项专门的任务；在开发中或之后的任何时候发现新的测试时
考虑每个故事，然后问类似问题：关于这个故事，程序员还需要知道什么？对怎么实现这个故事，我的想法是什么？有没有一些特殊情况会使这个故事有不一样的行为？这个故事在什么情况会出错？
测试类型：用户交互测试，确保所有用户交互组建如期工作；可用性测试，确保程序好用；性能测试，测量应用程序在各种符合下的工作情况；压力测试，使应用程序在用户和事务的极限值情况或其他任何让应用程序处于压力下的情况运行
测试和开发活动是合作负责不应相对抗，测试的是缺陷，而不是覆盖率，不必追求100%的代码覆盖率，随着时间的推移，通过沟通和观察哪些类型的测试经常出现问题，项目中所有人都可以知道测试重点在哪些地方
答案
第七章 优秀用户故事准则
问题
小结
封闭故事：一个封闭的故事是指那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得她完成了某个任务。
如：招聘者可以审核针对他发布的招聘广告发的简历；招聘者可以更改招聘广告的过期日期；招聘者可以删除不合适的申请；
编写封闭故事其实实在相互冲突得各种需求之间权衡的结果，故事要小到能做评估，小到方便的安排到一轮迭代中，也要足够大（粗颗粒度、高层次的、抽象的），从而避免过早捕获当下还不需要的细节。
需求和解决方案不要混在一起
有些需求并不是故事，用户故事不是“万灵药”
答案
第Ⅱ部分 估算和计划
第八章 估算用户故事
问题
小结
故事点（story point）估算，特性是团队可以定义自己认为合适的故事点。团队可能决定定义一个故事点为一个理想日的工作，也可以定义为一个理想周的工作，还可以把故事点作为故事复杂度的测量。故事点有很多意义，是代表时间的模糊单位，或叫做NUT（Nebulous Units of Time）。建议用一个故事点工作量看到一个理想日。
三角测量，估算一个故事时，根据这个故事与其他一个或多个故事的关系来估算，不用太精确，三角测量是帮助团队验证他们没有逐渐改变一个故事点含义的有效方法。
速率（velocity）代表一个团队再一轮迭代中完成（或期望完成）的故事点数。可用一轮迭代的速率来预测未来迭代的速率。
如使用结对编程，团队可选择以理想结对日或理想个人来估算故事点，区别会表现再速率值上。
开发人员职责：负责用一个方式定义故事点，并且对团队可用和相关的，努力保证整个定义的一致性；负责给出诚实的估算，不屈服于诱惑或压力而给出低的估算；负责以团队估算；负责估算与其他估算一致，即所有2点的故事都应差不多
客户职责：负责参加估算会议，但是你的任务是回答问题并澄清故事细节，不必参与故事估算
答案
第九章 发布计划
问题
小结
DSDM包括一个排列优先级的方法，称为MoSCoW规则
必须有（must have）
应该有（Should have）
可以有（Could have）
这次不会有（Won't have this time）
必须有指系统的基本功能，应该有指的重要但短期有替代解决方法的功能，如果项目没有时间约束，通常应该有的功能是强制性的。
可以有的指如果没时间可以再发布中不予考虑的功能
不会有的功能，是客户期望拥有但同时承认需要再后续发布中实现的功能
多维度排列故事优先级
故事不能如期完成的风险
推迟实现一个故事时对其他故事的影响
故事对于广泛用户或客户的重要性
故事与其他故事的内聚性（如Zoom out 缩写功能本书可能低优先级，但Zoom In放大高优先级）
混合优先级
如有优先级有异议，可分割整个故事，对独立的故事排列出不同的优先级
成本可改变优先级、高风险故事、根据架构需求按排优先级
选择迭代长度
迭代长度通常为1至4周，短迭代允许项目更加频繁的做出调整，项目进度也会更加透明，但每轮迭代会有少许额外开销，假如不确定迭代长度，请选择短迭代而不是长迭代，长迭代更容易犯错。
项目开发期间，尽量坚持固定的迭代长度，保持固定的节奏，利于团队的开发速度。视需要可以调整迭代长度，但不要随意修改。
初始速率
三种方法获得初始速率：使用历史值、执行一轮初始迭代，使用那轮迭代的速率；猜测
答案
第十章 迭代计划
问题
小结
迭代计划，把粗颗粒度的故事分配到发布中的多轮迭代。
迭代计划会议一般内容：讨论故事、从故事中分解任务、开发人员承担每个任务的职责、讨论过所有故事，并接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。
故事的任务分解时即时设计（just in time design）中的一次短脉冲，这些脉冲的集合取代了瀑布过程中的前期设计阶段。
准则:因为故事已经很小了，没必要围绕任务的期望大小设定非常精确的准则，从故事分解任务时可使用一下准则。
- 如果故事的某个任务特别难于估算，就把那个任务从故事的其余任务中分离出来
- 倘若有些任务可以很容易安排个多名开发人员共同完成，就分割他们
- 若有必要让客户了解故事某一部分的完成情况，可以把那部分拿出来作为一个任务
开发人员职责
负责参加迭代计划会议
负责把所有故事分为任务，而不只是自己想做的故事
负责为认领的任务承担责任
负责确保承担适当工作量的工作
在整轮迭代中，负责监控自己剩余的工作，同时也要监控队友剩余的工作，如果很快就能完成自己的工作，就有责任帮助队友承担部分工作
客户职责
负责对迭代中包含的故事排列优先级
负责指导开发人员交付他们能提供的最大商业价值，从发布计划设定后，若有更高价值的故事，要负责调整优先级以交付最大的商业价值
负责参加迭代计划会议
答案
第十一章 测量并监控速率
小结
、
迭代后的机会速率和实际速率
累计计划故事点数和实际故事点
燃尽迭代图
迭代中的进度和改变
开发人员职责
尽量在完成一个故事后再去做下一个故事，我们更希望看到少量已完成的故事，而不是较多未完成的故事
清楚所作的任何决定对项目速率的影响
理解本章所讲的所有图
经理或者极限编程项目中的追踪者，应知道怎样以及再什么时候画本章中的这些图
客户职责
理解本章所讲的所有图
知道团队的速率
知道实际速率和机会速率的差别和是否需要调整计划
为发布添加或删除故事，以确保团队再种种限制团结下尽量多实现项目目标
答案
第Ⅲ部分 经常讨论的话题
第十二章 故事不是什么
不是IEEE 830
IEEE标准文档的建议覆盖了诸如如何整理需求规则文档、角色原型和良好需求特性等主题。
使用项目需求规格书的问题，规格文档再开发小组和其他小组（如市场、产品管理）会来回打乒乓，不可能吧需求描述到想要的精度。
用户故事不是用例
用例（use case）是对系统质检以及一个或多个用户质检交互的一般性描述。用例可以编写为非结构化的文本，或者符合结构化的模板。
用例和故事的目的不同，用例编写成客户还开发人员都可以接受的格式，目的是记录客户和开发团队之间的协议，而编写故事是为了更方便发布计划和迭代计划，并且它充当这用户具体需求对话的占位符。
用户故事不是场景
场景是用户与计算机交互的详细描述，交互涉及场景通常比用例更大或更全面。
用户故事和场景的主要区别是范围和细节，场景包含更多细节，范围通常涵盖多个故事。
问题
第十三章 用户故事的优势
用户故事的好处
强调口头沟通
人人都可以理解用户故事
大小适合做计划
适合于迭代开发
鼓励延迟细节
支持随机应变的开发
鼓励参与性设计
传播隐形知识
用户故事的不足
在拥有大了用户故事的大型项目中，故事之间的关系可能是错综复杂，难以捕捉。可以使用角色来淡化此问题，进来保证用户故事不要过于细节化，直到团队开发这些故事时才开始细化。面对大量的需求时，用例的固有层级性会使需求收集比较方便。
如果开发过程规定需要有需求的可追溯性，比如离不开额外的文档。可以通过轻量的方式解决，在每一轮迭代时，生成一份文档，列出改迭代中计划开发的每一个故事。随着测试的不断出现，我们把测试的名词添加到文档中，在迭代进行期间，挪入或挪出故事时我们保持文档的更新。
我们要在两种情况取得平衡：很多人都知道一点点信息（通过低带宽的书面文档）或者一小群人知道非常多信息（通过搞贷款的面对面交流）
小结
开发人员职责
理解选择任何方法的原因，如果团队决定使用用户故事，需要明白为什么
了解其他需求方法的优先以及知道什么情况下适合使用
客户职责
用户故事与其他需求管理方式相对的一大有点事鼓励参与性设计，应该积极参与软件的设计。
问题
第十四章 用户故事不良征兆一览
问题
第十五章 Scrum与用户故事
问题
第十六章 其他话题
问题
第Ⅳ部分 一个完整实例
网友评论