读《用户故事与敏捷方法》

必须说明的是，我是囫囵吞枣读的，应该没有读透，其次，这些东西的实践性很强，需要真正的工作里应用过，才能有更多体会

 什么是用户故事？
 用户故事是对用户有价值的功能

一个用户故事包含哪些东西？
  1 卡片： 一句话的描述或定义
  2 讨论：功能的相关的细节（或约束）
  3 验证：验收测试，通过验收测试才能说完成了用户故事

 如何用实物表达用户故事
 敏捷团队其实特别喜欢用真实的东西表达抽象的概念，例如用白板表示项目进度，那么可以真的用一张卡片表达一个用户故事，正面写定义，反面写讨论

关于验证

定义用户故事时必须同时说明，完成的标准是什么，以及如何测试（这就要求用户故事必须可测试，事实上这也是用户故事的六大特征之一，这些写在背面的讨论里）另外，客户一半都不是专业人员，很难完成验证工作，所以理想情况下，可以建立一个用户团队，用户团队里的专业人员编写验收测试

用户故事的六大特征

 1 独立  Independent
 2 可讨论 Negotiable
 3 有价值 Valuable to Users
 4 可估计的 Estimaatable
 5 小的 Small
 6 可测试的 Testable

 

这6点的英文单词首字母构成一个简称叫INVEST

假设现在开发一个酒店房间的网上销售系统，他的用户故事有哪些呢？咱们先说史诗故事（意思是顶层的宏观的故事，它通常可以细分很多小故事）：

 1 酒店可以发布当天空房信息
 2 用户可以订购当天空房
 3 用户可以预定房间

好了，没有了，暂时就这么多，在规划史诗故事时，是不说明实现方式的，我们没有说明我们到底会怎么实现这些用户故事，是写一个web网站嘛？还是写一个手机apps，这年头iphone，android有多火我们也是知道的,这些要在之后决定的，早期是不能决定这些的，否则会限制思路，使得产品僵化，难以改变

现在由用户决定开发哪一个故事，在scrum里，我们把这样的人成为product owner，他拥有生杀大权，由权利决定故事的优先级，以及是否要停止当前的spint，好了，扯远了

假设我们要开发用户订购，那么我们把1，3要扔到一边去，不做开发的东西都不理他们，为了叙述的方便，下面用空房代替当天空房

那么，让我们细化这个用户故事，开始欢乐吧，let' begin

2 用户可以订购当天空房
 2.1 用户选择空房
 2.2 用户确认订购
 2.3 用户退订

 2 用户可以订购当天空房
 2.1 用户选择空房
 2.1.1 用户从空房列表选择
 2.1.2 用户搜索满足条件的空房 （用户可能是残疾，对卫生间有特定要求也是可以的嘛 －－！）
 2.1.3 查看空房详细情况
 2.2 用户确认订购
 2.2.1 用户确认
 2.2.2 支付
 2.2.2.1 网银支付
 2.2.2.2 预付款会员卡支付
 2.2.3 更新空房列表（空房数量－1，或者直接从空房列表删除）
 2.3 用户退订
 2.3.1 用户确认退订
 2.3.2  更新空房列表

以上过程只是一个根据常识推导出来的一个细化过程，真正的这种用户故事确认，需要用户和开发团队进行头脑风暴，然后确认，我觉得大多数产品做不好的一个原因就是缺少了这样的一个过程，由于想的太少，进行了太多的假设，导致开发出来的软件产品僵化，不易修改，例如根本没想过用户是残疾人，可能有自己特殊的需要，他就是要一个不带马桶的卫生间（当然了，这是我臆想的，但是个性化的需求是一定存在的）所以对他来说搜索一定比一个一个查看要更方便

以上列出来的都只是用户故事的卡片，讨论和验证我都还没说明，路漫漫兮啊：）