谈用户故事地图(11.25)

我应该已经由很多年不谈scrum敏捷研发和项目过程管理，由于最近开始看devops成熟度模型的敏捷开发管理过程域，实际上核心仍然事scrum敏捷管理的内容，因此需要对这方面的内容做下重新回顾。特别是看到的用户故事地图，而实际原来在我们实践scrum敏捷方法论的时候并没有太用到。

原来我们谈的就是用户故事，product backlog和sprint backlog，先形成产品backlog，同时评估优先级和功能点复杂度，然后将不同的用户故事分配到具体的sprint backlog里面形成当前的迭代版本。将用户故事进一步细化为不同的工作任务项，将工作任务下达到具体的人员执行。在整个过程中基于backlog列表形成从需求到开发到测试的完整端到端跟踪和验证。

用户故事本身就是业务需求的实现，因为围绕用户故事的管理实现完整的业务价值交付。

对于用户故事地图建议大家可以参考下网上的这两篇文章

https://www.jianshu.com/p/5def007ae399

http://www.woshipm.com/pd/270289.html

当我们看到这些用户故事地图的时候，我们发现这种地图方式很好的解决原来backlog清单的单维度问题，形成了一种二维的可视化视图结构。 将具体的用户故事内容很好的呈现在一个二维坐标体系里面，其中一个坐标是业务活动和任务，一个坐标是具体的迭代版本。

同时我们对用户故事本身也形成了完整的层次结构，即业务活动-》业务任务-》用户故事点

对于用户故事点，我们可以看到也叫最小化用户故事，而这个在我们多年前实施scrum敏捷方法论的时候并没有这样去管理，往往用户故事点还是偏粗，而是在任务安排上对用户故事点进行了细化。而在新的模式下可以看到用户故事点更加细化，是一个最小的功能实现点。

最小化用户故事点也可能不能独立交付，但是这不影响我们细化到最小化用户故事点进行管理。这种最小化用户故事点真正解决了我们原来遇到的两个问题，即对于同一个用户故事，用户故事本身不能再进行细分的， 但是用户故事本身有包括了很多扩展边界，或者说用户故事本身又含了扩展业务规则逻辑，而这些在新用户故事视图模式下都可以进行可视化呈现，并分配到不同的迭代版本进行管理。

比如对一个简单的发送邮件用户故事，我们就会存在很多的小用户故事点，比如支持发送附件，支持发送图片都是扩展故事点，而对于发生时候需要校验邮箱有效性可能就是扩展的业务规则点。这些我们都需要进行管理并跟进优先级安排到不同的迭代版本去实现。

对于用户故事的形成，在上面一篇文章链接里面有专门将到构建用户故事地图的8个步骤。在用户故事地图里面有一个关键行，即一级用户故事，它们组成了用户故事地图上的行走的骨骼（the walking skeleton）部分。而对于一级用户故事，我们也可以看到，正是我们原来在sprint backlog里面管理到的用户故事粒度。

而在一级用户故事上面，还有一层即user activities用户业务活动层，而这层实际上也相当关键，通过这层我们可以将我们的用户故事真正和实际的业务场景，业务流程和活动关联起来。通过这种图也可以很清晰的看到我们实现的用户故事究竟体现在哪个业务流程或业务场景中。

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

1. 自顶向下： 从业务场景和流程分解入手，先梳理定义清楚业务活动，再细分一级用户故事。

2. 自底向上： 先头脑风暴形成一级用户故事，然后再向上抽象归类形成业务活动层。

就这两种方法来说，自顶向下分析可以确保更加完整无缺漏，而自底向上方法往往则更加快速和敏捷。具体采用哪种方法进行需要根据项目团队实际情况来综合考虑。

在形成了业务活动和一级用户故事后，剩下就是对一级用户故事进一步拆分为最小化用户故事，最小化用户故事是否作为任务直接下达需要看我们研发项目任务管理的粗细度情况，在这里并没有明确的标准和要求。如果跟踪管理的细，持续集成过程也高效快速，那么就可以到最小化用户故事，否则就到一级用户故事。

实际上在一级用户故事的拆分上，还可以借鉴我们原来用例建模的经验， 将最小化用户故事分为三类故事场景，即核心用户故事，扩展故事点，业务规则逻辑故事点并分别进行管理。其中对于核心用户故事点优先级最高，必须在第一个迭代周期实现，扩展故事和规则故事点也必须要依托核心故事点而存在。

对于具体用户故事视图的详细示例，可以进一步参考上面的文章链接。

而对于我们的backlog项目，我们实际建议还是管理到最小化的用户故事点，同时将用户故事点做为任务项来管理和跟踪，同时也基于最小化用户故事点来编写相应的测试用例点，只有这种方法我们整个跟踪才能够达到根据细粒度和敏捷，同时也确保关键扩展点和规则不遗漏。

在这种方式下唯一需要注意的就是最小化用户故事点要确认是否一定是可以独立交付的最小单位，这个问题我也还在进一步思考中，因为基于不同的业务需求和场景，往往需要多个最小化用户故事点打包交付往往才真正能够体现用户价值。但是最小化用户故事点本身又是可以独立进行开发和测试的单位。所以在这里需要我们在进行迭代版本规划的时候考虑到故事点的关联依赖性特征。