读书笔记3——《用户故事与敏捷方法》

在计划发布时，有必要知道客户预期的大致发布日期和故事的相对优先级；
故事应该以明确顺序排列，第一个、第二个…而不是利用诸如“非常高、高、中等”的分组；

迭代计划是发布计划的进一步计划，但只是在迭代即将开始时才开始做迭代计划。

 -迭代计划会议的一般内容：
讨论故事；
从故事中分解出任务；
开发人员承担每个任务的职责；
讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出乐观承诺。

迭代燃尽图展示了用完成的故事点表示的进度和剩余故事的改变。
为每轮迭代计划和实际完成的故事点数画图是检测实际和计划速率区别的好方法。
累计故事点图可以反映每轮迭代中完成的故事点。
每日燃尽图展示迭代中每天剩余的小时数。

-用户故事不良症兆（smell）：
故事太小；
故事互相依赖；
镀金（开发人员主动去增加的客户没有要求的功能）；
细节太多；
过早考虑用户界面的细节；
想得太远；（利用用户故事的关键在于承认实现不可能发现所有需求，好的软件是在不断的迭代中发展而来，而在每轮迭代中都会发现新的细节需求，然后被添加到软件。）
故事划分太过频繁；
很难为故事安排优先级；
客户不愿意写用户故事，为故事安排优先级；