标签：
用户故事如何划分？如何落实到工作中？
用户故事的INVEST原则我是非常赞成的。（搜索了一个相关的说明，http://duweizhong.blogbus.com/logs/112151436.html）
但是要做到INVEST，实际上还是很不容易的。我接触到的常见问题是
1、不知道如何划分，无从下手
2、不知道划分的是否合适，是否满足INVEST原则
3、划分好后，如何跟踪story的进度
实际上这也是我刚接触敏捷时遇到的问题，这些问题，我个人的体会是“按照一些优秀实践的分享，自己亲自参与并实践一次，问题则迎刃而解。否则大部分情况都是盲人摸象。”
先说一下，软件行业常以代码行作为工作量评估，但是具体进度安排却是天数来管理，两者间的转换是存在偏差的，在IBM提供的敏捷培训中，其工作量评估全部是以天数进行的，一方面比较好估算（以你的能力，你估计多少天能完成？），另一方面更便于进度管理。
以下是我在上述问题的解决经历：
1、story划分的标准：“作为一个用户，我期望xx解决我的xx问题”。实际上如果做过需求分析的人，会发现这个非常像用例图，第一步分析用户是谁，第二步为用户解决什么问题。做到这一步其实不算困难，但也不算成功，因为做完这个划分后，经常会发现story太大了，看不清楚内部是如何实现的，分工和跟踪都不合适。这是因为不符合INVEST原则。（如果没有发现上面这个问题，我个人觉得下面的分析可以不用看了）
2、如果一个story超过15人天的工作量，其实这个story还是不合适的。但是我从事的行业软件来说，为用户提供一个完整的功能往往需要多个系统的合作而成，因此第一步缩小story的方法是分清系统间的依赖关系，story不应该跨系统。即便如此，对于核心调度系统来说，其流程是非常复杂的，中间涉及非常多的状态变化，这个不跨系统的story依然庞大（举个例子，我重构的核心系统A，一个上层系统的命令，需要A与各个接口系统经过27条消息交互才能完成）。为此，我第二步缩小story的方法，是分清系统内部状态间的依赖关系，story不跨状态。经过这两步的压缩，story已经足够小（我个人的实践效果还不够好，大概是35人天，但是因为行业软件的验证要求很严格，大约有15人天的验证工作），但是交付上则会出现困难，它是否可以交付？另外分工也是问题，因为是团队协作完成的，光有这个story还不足以安排分工。
3、无法交付的story不如不做，因此划分story必须确定它的交付标准。上述问题中，我按状态来划分story，因此我对story的希望是“完成xx接口系统的设置，进入到下一个状态”。如何验证我的story是否可以交付了？很简单，日志记录进入下一个状态即可。（很多人都会纠结在交付验证上，实际上只要PO认可就行，另外互联网软件一般难以确定交付标准，其根据自身情况，进行了一些新的实践分享，附上我了解到的百度的story分享，http://blog.csdn.net/jamesf1982/article/details/44757585）
4、如何分工，如何跟踪？因为一个story一般是团队一起完成的，无法避免需要进行分工。此处IBM的敏捷教练提供了一个实践分享：划分task。task的要求是某个输入产生的某个输出，完成一个task不能超过5人天。从划分task的目的上来看，实际上更像是分解成更小的story（实际上我一直是这么觉得的）。轻量级的task同样要求是可交付的，独立的。在我的实践中，我将一条消息处理作为一个可交付的task，消息处理的结果作为task的输出，一般1-2人天就可以完成。（提示：task一般是一条消息处理或一个接口函数）
经过上述的分享，基本上story划分已经不再成为困难。另外有一个小分享是：整个story的划分是一个非常耗时的过程，大部分情况下，是统一团队一起来划分，大家集思广益，确保story划分得到团队的认可。但是对于非常复杂的功能或特性来说，这个划分往往难以在一次会议上完成，极其容易引起团队的反感。针对这种情况，一般我作为PO，会与各个需求方沟通确认（很耗时，但是只影响PO一个人），提前将重要价值的story以及task进行初步划分，在会议上进行引导，减少会议上的耗时（一般控制在一小时内，这个对PO的能力要求很高 ，重要价值的story不能遗漏，且交付标准需要非常有把握，能快速解决统一团队的疑问）。
标签：
原文地址：http://blog.csdn.net/jamesf1982/article/details/45459361
