用户故事的操作指南
2012-01-21
怎么编写一个用户故事？怎么确定项目的用户角色？怎么收集用户故事？在不能直接接触用户的情况下我们怎么做？怎么确定一个用户故事是否完成？一个好的用户故事有些什么特征？怎么估算用户故事？怎么确定发布计划和迭代计划？怎么监控故事完成的速率？敏捷大师Mike Cohn在这本书中详细阐述了解决这些问题的办法，并指出了开发人员和客户团队的职责，下面是个人对这些问题的一个总结：
一、用户故事特征
1、独立的。对于相互依赖的故事，指出可以采用以下处理方式：1）将相互依赖的故事合并为一个故事；2）考虑其它的划分方法；3）在故事卡上标明依赖关系。
2、可讨论的。用户故事应该只包含一两句话，用来提醒开发人员和客户沟通，并且包含一些注释，用于标明在沟通中亟待解决的问题。
3、对用户或客户有价值的。为了保证每个故事对用户或客户都是有价值的，最好由客户来编写故事。
4、可估计的。如果缺少领域知识导致不可估计，需要和客户沟通，如果缺少专业知识，则可以把故事拆分出一个调研故事，最好将调研故事和原始故事放在不同的迭代中。
5、小的。需要注意对大的故事需要拆分，而太小的故事则需要合并。
6、可测试的。尽量采用自动化测试。
二、用户角色建模
通过把客户和开发人员聚集到一个房间中，通过头脑风暴，列出初始的用户角色集合，然后整理最初的角色集合，通过整合角色和提炼角色，最终确定出使用软件的角色。Mike Cohn还提出两个额外的技术：虚拟人物和极端人物。
三、收集用户故事
Mike Cohn使用“拖网”来描述收集需求的过程，指出：1、不同大小的网用来捕获不同大小的需求；2、需求会像鱼一样，会成长，也可能会死亡；3、不可能捕获到所有的需求。并指出故事只要够用就行，但应该在早期尝试编写可以编写的故事，即使许多故事还停留在很笼统的阶段。然后Mike Cohn提出了一些收集需求的方法：
1、用户访谈。要求尽可能访问真实用户，在提问时尽量采用开放式问题和背景无关的问题。
2、问卷调查。反馈太慢，因此不适合作为主要方法，可以作为补充。
3、观察。有条件的话可以观察用户使用软件的情况。
4、故事编写共组坊。把开发人员、用户、产品客户和其他所有有帮助的人叫到一起，编写故事，要求故事尽量多，不需要注重质量。
四、用户代理
Mike Cohn指出使用不同角色担当用户代理会存在的问题。指出设立客户团队需要优先考虑实际客户，而如果没有实际客户，则需要由一个或多个用户代理，建立客户团队有三步：
1、邀请真实用户加入；
2、在客户团队中确定一位“项目负责人”或“一把手”；
3、确定项目成功必须得关键因素。
五、验收测试
在写代码之前写测试，并且要求由客户来定义测试，并提出测试应该作为开发环节的一部分，而不是在编码完成后。Mike Cohn还提出可以使用集成测试框架使验收测试自动化。
六、优秀用户故事的准则
1、从目标故事开始；
2、采用切蛋糕的方式，把大的故事分解；
3、编写封闭的故事；
4、对必须要遵守而不需要直接实现的故事，使用卡片约束；
5、根据实现时间来确定故事规模，越远的故事精确度越低；
6、不要过早涉及用户界面；
7、有些需求并不是故事；
8、在故事里包括用户角色；
9、只为一个用户编写；
10、以主动语态编写；
11、由客户编写；
12、向故事卡编号说“不”；
13、不要忘记意图。
七、估算用户故事
1、以团队估算。因为：1）还不确定团队中谁负责完成这个故事；2）团队决定的估算比个人估算更有用。但需要注意，没有必要让所有人在卡上写下完全一样的估算。
2、使用三角测量，用于对比估算结果，帮助团队验证他们没有逐渐改变一个故事点的含义。
3、使用故事点。一个故事点指没有打扰的情况下一个理想日的工作，使用故事点使估算更简单，并且使估算有了很好的依据。
另外需要注意：
1、你的团队的故事点和我的团队的故事点是不一样的；
2、一个故事（可能是一个史诗故事）分解成一些小故事后，这些小故事估算的总和不需要与开始那个故事或史诗故事的故事一致；
3、类似地，一个故事分解成一些任务，这些任务估算的总和不需要与故事的估算相等。
八、发布计划
首先确定发布日期，Mike Cohn建议使用一个日期范围，而不要用一个确定的日期。
其次需要确定发布哪些功能（必须有的、应该有的、可以有的和这次不会有的），并对用户故事排列优先级，优先级应该受到故事实现的成本的影响，需要注意以下情况：
1、 混合优先级：需要拆分；
2、 高风险故事：提倡先做“油水”最多的部分；
3、 根据架构需要安排优先级：开发人员应该帮助客户意思到那些可以推迟实现，但越晚实现成本越高的故事。
最后选择迭代长度，通常为1至四周。团队的速率可以参考历史数据，如果没有历史数据，可以考虑执行一轮迭代作为参考，如果也不可行，则只有采用猜测，大多采用一轮迭代三分之一到一半的开发日作为速率。然后就可以预计工时（项目需要的理想日，除以速率，为预计工时）。
九、迭代计划
首先讨论故事，客户从最高优先级的故事开始读给开发人员听，开发人员提问，直到开发人员充分理解故事，能够将故事拆分为任务。但需要注意没有必要理解故事的所有细节。
然后我们就开始分解任务，将故事拆分为任务可以让故事被多个开发人员并发处理，并且故事是对用户或者客户有价值的功能描述，并不是开发人员的待办事项，因此分解后更能让开发人员了解具体的工作。拆分任务的时候需要注意：
1、如果故事中某个任务特别难估算，则最好将这个任务从故事的其它任务中分离出来；
2、如果一个故事的任务可以很容易的分给多个开发人员，则分割他们；
3、如果有必要让客户了解故事中某一部分的完成情况，则可以把这部分拿出来作为一个任务。
接下就需要分担职责，每个任务最好只关联一个人，确保在迭代期间完成任务是他的职责。但同时确保在迭代期间完成任务又是所有团队人员的职责，所以如果在一个任务无法完成时，需要考虑作出调整。
最后就需要开发人员作出完成任务的承诺，确保一个迭代的任务在迭代周期内能够顺利完成。
十、测量并监控速率
测量速率是为了确定在后面的迭代中放入多少故事点的任务，同时根据速率对后面的故事做出调整。Mike Cohn提出不用实际小时作为速率，而采用估算的故事点作为速率。
在项目的进行过程中，可以对计划速率和实际速率做出比较，尽早发现问题。也可以采用迭代的燃尽图，标识任务的完成情况。
Mike Cohn也提出可以考虑在任务的白板上写下开发人员自己对任务剩余小时数的估算，方便对任务完成情况的跟踪。
接下来，Mike Cohn还将故事和IEEE 830、用例和场景做了对比，并讲述了用户故事的优势和用户故事的不良征兆，加深对用户故事的理解，并简单介绍了用户故事在scrum中得使用和一些其他话题。
在最后，Mike Cohn通过一个完整的实例展示了用户故事的实际使用。
查字典图书网
