那些年向前冲|从用户故事地图到Scrum敏捷研发管理( 三 ) 作者：人月神话

1.2 暂存报销单
1.3 对暂存报销单进行修改
1.4 提交审批报销单
2. 审批
3. 付款
对于新建差旅报销单你可以理解为一个用户任务，这个用户任务里面实际上本身又可以拆分为很多更加细粒度的用户故事点。比如对于新建差旅报销单。
1. 申请单填写 --》对应业务活动
1.1 新建差旅报销单 --》对应用户任务
1.1.1 新建基本差旅报销单
1.1.2 支持报销到具体项目
1.1.3 支持预定酒店，机票费用自动导入
1.1.4 支持项目预算校验
1.1.5 支持部门间的费用分摊
1.1.6 支持借款核销
1.1.7 支持报销申请时候附件上传
1.1.8 支持发票自动识别和导入
那么以上就是一个完整的用户任务下的细分故事点。那么这些故事点就需要我们安排到不同的迭代版本。迭代版本的安排重点是根据需求的优先级进行，其次需要考虑需求之间本身相互的依赖性。
基于以上思考，我们可以将以上功能安排到三个迭代版本去完成。

迭代1：完成基本功能，报销到项目，项目预算校验，接口核销
迭代2：完成机票酒店预定自动导入，部门间的费用分配
迭代3：完成附件上传功能，发票自动识别

以上即完成了一个完整的用户故事地图从业务流程到业务活动，用户任务，用户故事点到迭代版本任务安排的分解。通过这种方式将所有的业务活动点都进行分解即形成了一个完整的用户故事地图。这个用户故事地图可以看到就是我们整个迭代产品版本规划，后续的敏捷项目管理需求和任务的录入完全可以基于该用户故事地图分解的需求和故事点进行全流程管理和端到端跟踪。
对于业务活动往往会对应到我们实际业务系统中的菜单功能，而对应用户任务可能是菜单功能粒度，也可以是菜单功能中按钮级的粒度，这个需要根据实际情况来确定。
敏捷项目管理

在前面讲用户故事地图和用户故事的时候，我们可以看到如何形成详细的用户故事点，并将用户故事点规划到不同的迭代版本的一个初步方法。对于用户故事点，我们需要注意以下两点：

其一：每个独立的用户故事点必须要做到完全可独立验证
其二：故事点能够追溯回具体的业务功能和业务场景和业务流程

在用户故事地图这个关键的步骤做完后，我们实际上得到了一个关键的内容，即：
条目化需求-》对应到独立故事点
我们可以看到整个条目化需求也是我们后续进行敏捷项目管理的要给核心内容，整个需求的端到端跟踪和管理，敏捷项目管理，计划和任务的跟踪全部都需要根据条目化需求展开。
这个条目化需求如何呈现？
即我们经常谈到的Scrum里面提到比较多的两个内容，即Product Backlog和Spring Backlog
对应产品清单和迭代清单可以分开，即产品清单重点是列出所有的用户故事点，整理清楚前面我们谈到的用户故事地图的核心内容。将具体的用户故事点规划到具体的迭代清单中。
在产品清单中我们可以只对用户故事点，给出一个故事功能和场景，优先级的描述即可。对应其它熟悉项往往并不需要在Product Backlog里面详细展开。
当我们规划清楚迭代版本后，我们就需要对迭代版本建立详细的Spring Backlog迭代清单。
在原来的整个Scrum敏捷项目计划和任务管理里面，我们看到需要对于用户故事进一步在迭代清单中进行任务拆分，一个用户故事点又拆分为多个任务，可能是开发也拆分为多个任务，也可能是拆分为开发，测试等多个任务。而实际上我们看到：
当前用户故事点的粒度足够细的时候，我们的迭代版本清单中不用再进行到任务的拆分，而是通过一行到底的全流程跟踪方式。这样往往更加清晰和可视化。这种一行到底的全流程跟踪，再配合我们实际的Scrum看板基本就能够很好的完成相关跟踪工作。