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

尽早发布产品，打开一条与用户沟通的途径。

验收测试的两步流程，测试要点和实现这些测试要点。测试要点记录了客户提出的假设。

验收测试的测试要点能够让程序员在写代码时考虑到这些有用的信息。所以，故事的细节写入测试是比较好的做法。

每轮迭代都要执行以往迭代通过的验收测试。所以尽可能做自动化测试。FIT&FitNesse（表格格式）

验收测试提供了检查故事是否被完整实现的基本标准。

确定用户故事：考虑每一个用户角色，了解用户使用我们软件的目的。

每一个故事都提供某种程度的完整（end-to-end）,以保证每一个发布的功能都是可以给用户使用的。

编写的故事是封闭的。

如“用户A可以管理他的个人信息”；

“用户A可以增加他的个人信息XXX”、“用户A可以更改他的个人信息”…

后几个封闭的每一个故事都是原来非封闭故事的一部分。

不要过早涉及用户界面；

在故事里包括用户角色；

如“用户”与“社区民警”的差别。

故事的格式编写：我作为（角色），想要（功能），以此（商业价值）。

这种格式有助于区分重要故事与无关紧要的故事。

故事只为一个用户编写。

如“社区民警可以查看工作日志”，可能解释为社区民警可以查看自己的工作日志，还可以查看他人的。

故最好是“社区民警可以查看他自己的工作日志。”

故事以主动语态编写。

如“工作日志可以被社区民警查看”是不太好的故事。

故事由客户编写，有利于故事优先级的排列，以及对故事的解释。

不要给故事编号，如果非要编号，试着给卡片加上一个简短的标题。

故事卡的意图是为了提醒：开发人员与客户团队对功能进行讨论。

故事的大小，能够让用户在使用后有些成就感（去喝杯咖啡休息一下）。

如果有项目领域和环境的需要，可以用其他需求搜集或文档技术来补充故事

用故事点来估算故事，故事点是故事复杂度、工作量或工期的相对估算。

产品的开发路线图，可能是未来几个发布要关注的重点列表；

也或者是主题故事。

可以用两个问题来启动发布计划：

我们想在什么时候发布？

每个故事的优先级是什么？

DSDM方法中有一个排列优先级的方法，莫斯科规则（MoSCoW）

must have;should have;could have; won’t have this  time.

先做高风险故事还是先做最有价值的故事，这个由客户决定。不过，客户应该考虑技术团队的意见。