用户故事与敏捷开发 读书笔记 04
第6章 用户故事验收测试
比起写冗长的需求列表，可以用测试来充实很多用户故事的细节。测试是一个两步走的流程：第一，将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面；第二，将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整地实现。
测试验收提供了确认故事是否被完整实现的基本标准。有了这个标准，我们就知道什么时候某件事算是做完了。比较好的做法是，考虑每一个故事，然后问类似下面的问题：
- 关于这个故事，程序员还需要知道什么？
- 有没有一些特殊情况会使这个故事有不一样的行为?
- 这个故事在什么情况下回出错？
客户定义测试
既然软件是用来实现用户的愿景，验收测试当然应当由客户来定义。只要这些测试还在继续为故事增加价值使它更加清晰，客户就应该继续写测试。同时，一个优秀的开发团队会为很多详细的测试写单元测试。
第7章 优秀用户故事准则
在一个大型项目中，尤其是有许多用户角色的项目，确定用户故事有时让人无从下手。最好的办法是考虑每一个角色，了解用户使用我们软件的目的。
切蛋糕
当面临一个大的故事时，通常有许多方法将其分解为较小的故事。其原则是：每一故事都提供某种程度的完整性。例如：“求职者可以发布简历”，这个故事可以做如下拆分:
- 求职者可以提交简历，简历上包括诸如名字、地址和教育背景等基本信息。
- 求职者可以提交简历，简历上包括雇主想看到的所有信息。
编写封闭的故事
封闭的故事是指：随着一个有意义的目标的实现，能让用户使用后觉得他完成了某个任务。例如：“招聘者可以管理她发的招聘广告”者不是一个封闭的故事，而是一个持续进行的活动。这个故事应该更好的被拆分如下：
- 招聘者可以审核发给他的简历。
- 招聘者可以更改招聘广告的过期日。
- 招聘者可以删除不适合的申请。
卡片约束
对于任何必须遵守而不需要直接实现的故事，在其故事卡上标注“约束”，例如：
- 设计的软件要便于今后的国际化
- 新系统必须使用我们现有的订单数据库
- 该软件必须能在所有的Windows系统上运行
- 该系统的无故障运行时间要达到99.99%
这些约束，最终可能会转换为非功能需求。
