用户故事与敏捷方法阅读笔记02

第6章 用户故事验收测试

比起写冗长的需求列表，可以用测试来充实很多用户故事的细节。测试是一个两步走的流程：第一，将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面；第二，将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整地实现。

测试验收提供了确认故事是否被完整实现的基本标准。有了这个标准，我们就知道什么时候某件事算是做完了。比较好的做法是，考虑每一个故事，然后问类似下面的问题：

• 关于这个故事，程序员还需要知道什么？
• 有没有一些特殊情况会使这个故事有不一样的行为?
• 这个故事在什么情况下回出错？

客户定义测试

既然软件是用来实现用户的愿景，验收测试当然应当由客户来定义。只要这些测试还在继续为故事增加价值使它更加清晰，客户就应该继续写测试。同时，一个优秀的开发团队会为很多详细的测试写单元测试。

第7章 优秀用户故事准则

在一个大型项目中，尤其是有许多用户角色的项目，确定用户故事有时让人无从下手。最好的办法是考虑每一个角色，了解用户使用我们软件的目的。

切蛋糕

当面临一个大的故事时，通常有许多方法将其分解为较小的故事。其原则是：每一故事都提供某种程度的完整性。例如：“求职者可以发布简历”，这个故事可以做如下拆分:

• 求职者可以提交简历，简历上包括诸如名字、地址和教育背景等基本信息。
• 求职者可以提交简历，简历上包括雇主想看到的所有信息。

编写封闭的故事

封闭的故事是指：随着一个有意义的目标的实现，能让用户使用后觉得他完成了某个任务。例如：“招聘者可以管理她发的招聘广告”者不是一个封闭的故事，而是一个持续进行的活动。这个故事应该更好的被拆分如下：

• 招聘者可以审核发给他的简历。
• 招聘者可以更改招聘广告的过期日。
• 招聘者可以删除不适合的申请。

卡片约束

对于任何必须遵守而不需要直接实现的故事，在其故事卡上标注“约束”，例如：

• 设计的软件要便于今后的国际化
• 新系统必须使用我们现有的订单数据库
• 该软件必须能在所有的Windows系统上运行
• 该系统的无故障运行时间要达到99.99%

这些约束，最终可能会转换为非功能需求。

第8章 估算用户故事

• 故事点：故事复杂度的模糊测量，不同的团队可以有不同的标准，只要保证2个故事点的复杂度约为1个故事点的2倍即可。
• 以团队估算：故事估算应该由整个团队集体完成。
• 三角测量：在做了几个估算后，我们必须对估算做三角测量。具体的做法就是拿出一些故事，大家要同意4个故事点的故事大约是2个故事点故事2倍的复杂度，3个故事点的故事介于两者之间。这些都不用太过精确，但会帮助团队检验他们的估算。
• 使用故事点：在一轮迭代结束时，团队计算已完成的故事点数。这个点数可以作为下个迭代完成的故事点数的预报。

想要用好故事点，请记住以下几个问题：

• 你团队的故事点和我团队的故事点时不一样的。
• 不必强求一个史诗的故事点，一定等于子故事故事点之和。

第9章 发布计划

为了计划一个发布，客户必须排列故事的优先级：

• 必须有：系统的基本功能。
• 应该有：很重要但短期内有替代方法的功能。如果没有时间约束，是必须要上的功能。
• 可以有：如果没有时间，可以在发布中不予考虑的功能。
• 这次不会有：客户希望有，但承认可以在后续发布中交付的功能。

敏捷方法旗帜鲜明地支持先做最有价值的部分，但在排列故事优先级时仍然要考虑风险。高风险的故事经常与基础性或非功能性需求相关。开发人员应该帮助客户识别出那些可以推迟实现，但越晚实现开发成本可能越高的故事。

第10章 迭代计划

整个团队通过举行迭代计划会议来为下一轮迭代做计划。客户以及团队的所有人要都要参加这个会议。团队将仔细研究用户故事，需要客户随时回答这些问题。迭代会议的内容一般如下：

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

讨论故事

团队获得一个已经排好优先级的故事集合，以此作为迭代计划会议的输入。迭代会是客户为团队调整故事优先级最佳的时机。会议开始时，客户从最高优先级的故事开始，讲给开发人员听。然后由开发人员提问，直到他们充分理解故事，能从中分解出任务。没有必要理解故事所有的细节，过分深入会让会议变得冗长、低效。再会议过后开发人员任然可以和客户一起清理故事的细节。