敏捷软件开发-用户例事、例事卡和例事点

用户例事

用户例事（User Story）用于描述用户通过系统完成其一个有价值的目标。用户例事只是以客户能够明白的方式，描述了一个系统的外在行为。而像产品采用何种语言实现、采用何种架构、哪种数据库等则不应该包含在其中。用户例事不应该太长太大，一个笼统的用户例事可以和一些作为补充的用户例事联系起来。只要一个用户例事最终覆盖所有需要的细节，那么它就不需要再进行分解。
建立一个用户组来随时跟踪和确认用户的需求，应该包含测试人员、开发人员、项目经理、客户代表、ui设计师等。用户例事由用户组来完成，在编写用户例事的时候，应该采用头脑风暴的方式，尽可能多的编写例事。之后，由程序员对每个用户例事进行评审，确认例事的尺寸（一个用户例事应该能在半天到两个星期内完成）。
由用户组和开发者一同指定每一次迭代的周期。在本次迭代结束的时候，开发者负责交付所有的代码、开发文档和测试用例，而用户组负责确认本次迭代是否朝着预期的目标在前进，一次迭代完成整个系统的一部分。

例事点

项目开始的时候，会由开发者预测一次迭代可以完成的工作量，并把这个工作量叫做“velocity”。每次迭代完成的时候，都需要根据实际完成的情况对velocity进行调整，一次迭代中实际包含的用户例事个数也需要根据velocity进行调整，确保每次迭代中包含的用户例事都能够完成。如果无法完成，则将无法完成的例事调整到下一次迭代中，甚至调整到下一个版本中。下次迭代中包含的例事数量也需要根据velocity的值进行动态调整。
每次迭代开始的时候，由开发者和用户组一起确认那些是重要的必须优先实现的例事，并将这些例事优先放入当前的迭代中。三种情况下的用户例事是应该被优先实现的：
大部分用户广泛需要的。
少数但是是重要用户需要的。
其他高优先级例事依赖的。
在提高一个用户例事的优先级的时候，必须仔细考虑这个用户例事的成本，这个成本用例事点（Story Point）来表示，衡量这个例事本身的复杂性，以及和其他例事之间的依赖度，值越高表示实现这个例事需要花费的成本越高。注意，不要将一个例事点大于项目组velocity的例事分配给一个项目组。

例事卡

用来记录一个用户例事及其例事点的卡片叫做例事卡（User Story Card）。例事卡上应同时注明用户对于这个例事工作时的期望，例如能否和如何处理输入异常。这些期望可以用来作为测试和编程的指导。
例事卡上只需要一个简单的描述，具体涉及到的细节应该在同用户的讨论中得出，以注释的方式记录到例事上（也许是背面），这些细节讨论出来后应该形成测试用户。注意，注释不要太多，假如一个例事拥有太多的注释，那么将注释中的内容抽取出来形成新的例事；或者将此例事拆分。