第14章 用户故事的不良征兆一览
用户故事虽好，但是使用起来也不简单，如果使用不善，还是会出现各式各样的问题。下面就是一些常见的不良征兆（症状，解决方案）：故事太小（经常需要调整估算，将相关的故事进行合并）、故事相互依赖（很难做迭代计划，如果因为故事小就相应合并或者是看一看故事划分是否得当）、镀金（实现功能超出计划需要、开发者因此浪费额外精力，规定好每次迭代计划的每人工作尽量减少冗余）、细节太多（浪费过多时间写故事而非讨论收集故事，使用小卡片记录用户故事）、过早考虑用户界面细节（编写的故事中包括界面细节，避免或者修改成具体的功能描述）、想的太远（由于种种原因导致故事难以整理总结，让开发者学会收集用户故事）、故事划分太过频繁（多次划分，扫描剩余故事找到真正需要划分的故事）、客户很难为故事安排优先级（故事太大或者用户故事无商业价值，更换小故事、让客户努力重写）、客户不愿意写故事，也不愿意为故事安排优先级（不愿承担相应责任，和用户私下讨论交涉）。解决这些问题，用户故事才能更健壮，开发也就更加流畅。
第15章 Scrum与用户故事
Scrum也是一种迭代递增的软件过程。迭代指的是持续改进，在迭代中，软件才能够逐步完善；增进指的是团队按照功能点开发和发布软件，这就可以使得项目稳步前进，减少返工几率。实施Scrum过程的项目常以30天为周期迭代，这一过程称为Sprint。ScrumMaster相当于传统的项目经理，但更像是领导者和组织者，他与开发者的关系比经理更近。一般的Scrum团队包括4~7个开发人员。产品Backlog是一个待开发的功能需求列表，里面的条目都是尚未进行实现或计划的。Sprint Backlog是一个团队承诺在当前Sprint完成的任务列表。Scrum里的产品负责人相当于极限编程里的客户，他负责给Backlog排列优先级。每次Sprint开始时，软对都要在尚未实现或计划的列表中选择要进行的任务。每日的简会中，每个团队成员需要自我三省：已完成、要完成、问题。在每个周期中都要有实际的产品功能增量，这样项目才能健康有序的向前进行。在最后Sprint结束时，阮队要在审评会议上演示完成的功能。这就是一个Scrum的相关内容与流程。
第16章 其他话题
本章对前几章进行一些补充，主要谈探讨一些其他主题。
①处理非功能性需求：并非所有的需求都能使用恰当的故事来表达，这些往往就是系统的非功能性需求。他们可以表达各种系统需要，常见的例如：性能、准确性、可移植性等。他们大多都是对系统行为的约束。为了保证他们，我们只需要使用一些测试或者直接牢记就可以。
②纸质还是软件：故事首推应该写在纸质笔记卡上，因为它简单，技术含量低，可以鼓励交流和讨论。并且它也能限制字数。但是与软件相比，它也有不足，它不能让不在同一地点的工作团队交流。
③用户故事与用户界面：敏捷过程是高度迭代的，我们可以反复完善系统，但是如果这些修改事关界面，就不那么简单。所以，敏捷版本的设计应该以使用为中心，用故事替换基本用例。如果不能保证正确性，一个万无一失的方案，就是同时写两种用户界面，给用户选择，选择结束后，再向其中添加功能代码。
④保留故事：保留故事的确很重要，并且要保留多份。因为这很可能事关你以后的修改或者纠正，这是一个良好的习惯。
⑤缺陷的用户故事：我们可以把一些缺陷报告也当成用户故事来对待，当成单一的故事。