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

作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践
今天谈下用户故事地图和敏捷项目管理方面的内容，由于最近1年我们基于DevOps成熟度模型对我们的研发过程管理进行持续改进，里面也包括了敏捷研发管理方面的内容，同时也包括了敏捷研发管理和DevOps的集成。
用户故事和用户故事地图
由于最近开始看devops成熟度模型的敏捷开发管理过程域，实际上核心仍然是scrum敏捷管理的内容，因此需要对这方面的内容做下重新回顾。特别是看到的用户故事地图，而实际原来在我们实践scrum敏捷方法论的时候并没有太用到。
原来我们谈的就是用户故事， product backlog和sprint backlog ，先形成产品backlog ，同时评估优先级和功能点复杂度，然后将不同的用户故事分配到具体的sprint backlog里面形成当前的迭代版本。将用户故事进一步细化为不同的工作任务项，将工作任务下达到具体的人员执行。在整个过程中基于backlog列表形成从需求到开发到测试的完整端到端跟踪和验证。
用户故事本身就是业务需求的实现，围绕用户故事的管理实现完整的业务价值交付。
对于用户故事地图建议大家可以参考下网上的这两篇文章

【那些年向前冲|从用户故事地图到Scrum敏捷研发管理】当我们看到这些用户故事地图的时候，我们发现这种地图方式很好的解决原来backlog清单的单维度问题，形成了一种二维的可视化视图结构。将具体的用户故事内容很好的呈现在一个二维坐标体系里面，其中一个坐标是业务活动和任务，一个坐标是具体的迭代版本。
同时我们对用户故事本身也形成了完整的层次结构，即：
业务活动-》业务任务-》用户故事点
对于用户故事点，我们可以看到也叫最小化用户故事，而这个在我们多年前实施scrum敏捷方法论的时候并没有这样去管理，往往用户故事点还是偏粗，而是在任务安排上对用户故事点进行了细化。而在新的模式下可以看到用户故事点更加细化，是一个最小的功能实现点。
最小化用户故事点也可能不能独立交付，但是这不影响我们细化到最小化用户故事点进行管理。这种最小化用户故事点真正解决了我们原来遇到的两个问题，即对于同一个用户故事，用户故事本身不能再进行细分的，但是用户故事本身又包括了很多扩展边界，或者说用户故事本身包含了扩展业务规则逻辑，而这些在新用户故事视图模式下都可以进行可视化呈现，并分配到不同的迭代版本进行管理。
比如对一个简单的发送邮件用户故事，我们就会存在很多的小用户故事点，比如支持发送附件，支持发送图片都是扩展故事点，而对于发生时候需要校验邮箱有效性可能就是扩展的业务规则点。这些我们都需要进行管理并跟进优先级安排到不同的迭代版本去实现。
对于用户故事的形成，在上面一篇文章链接里面有专门讲到构建用户故事地图的8个步骤。在用户故事地图里面有一个关键行，即一级用户故事，它们组成了用户故事地图上的行走的骨骼（the walking skeleton）部分。而对于一级用户故事，我们也可以看到，正是我们原来在sprint backlog里面管理到的用户故事粒度。
而在一级用户故事上面，还有一层即user activities用户业务活动层，而这层实际上也相当关键，通过这层我们可以将我们的用户故事真正和实际的业务场景，业务流程和活动关联起来。通过这种图也可以很清晰的看到我们实现的用户故事究竟体现在哪个业务流程或业务场景中。