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

而对于这两层的构建，实际上也是存在两种方法可以考虑。

自顶向下：从业务场景和流程分解入手，先梳理清楚业务活动，再细分一级用户故事。
自底向上：先头脑风暴形成一级用户故事，然后再向上抽象归类形成业务活动层。

就这两种方法来说，自顶向下分析可以确保更加完整无缺漏，而自底向上方法往往则更加快速和敏捷。具体采用哪种方法进行需要根据项目团队实际情况来综合考虑。
在形成了业务活动和一级用户故事后，剩下就是对一级用户故事进一步拆分为最小化用户故事，最小化用户故事是否作为任务直接下达需要看我们研发项目任务管理的粗细度情况，在这里并没有明确的标准和要求。如果跟踪管理的细，持续集成过程也高效快速，那么就可以到最小化用户故事，否则就到一级用户故事。
实际上在一级用户故事的拆分上，还可以借鉴我们原来用例建模的经验，将最小化用户故事分为三类故事场景，即核心用户故事，扩展故事点，业务规则逻辑故事点并分别进行管理。其中对于核心用户故事点优先级最高，必须在第一个迭代周期实现，扩展故事和规则故事点也必须要依托核心故事点而存在。
而对于我们的backlog项目，我们实际建议还是管理到最小化的用户故事点，同时将用户故事点作为任务项来管理和跟踪，同时也基于最小化用户故事点来编写相应的测试用例点，只有这种方法我们整个跟踪才能够达到根据细粒度和敏捷，同时也确保关键扩展点和规则不遗漏。
在这种方式下唯一需要注意的就是最小化用户故事点要确认是否一定是可以独立交付的最小单位，这个问题我也还在进一步思考中，因为基于不同的业务需求和场景，往往需要多个最小化用户故事点打包交付往往才真正能够体现用户价值。但是最小化用户故事点本身又是可以独立进行开发和测试的单位。所以在这里需要我们在进行迭代版本规划的时候考虑到故事点的关联依赖性特征。
从业务活动到用户故事的简单举例

对于用户故事一定会涉及到用户故事地图的构建，要看到当前用户故事地图的构建上可以明确的体现出迭代版本规划，业务活动和用户任务等几个关键内容。而实际上迭代里面的用户故事已经是拆分到最小粒度的用户故事点，或者叫用户可以理解的业务功能点。这个业务功能点可以是我们在需求分析里面常说的基本流，也可以是扩展流或某条业务规则。
业务流程-》业务活动-》用户任务-》用户功能点
以上即构成了整个用户故事地图的层级，也更加容易从用户故事点追溯回具体的业务流程和业务场景。我们可以举例来详细看下整个过程：
第一级：业务流程到业务活动
对于出差我们当前是需要首先提交出差申请单，出差申请审批通过后才能够预定机票和进行报销。因此对于出差报销流程可以分为三个业务活动。