用户故事地图是在需求讨论过程中互动性更强的更直观的表达需求内容的一种方法。它不仅能够提升团队的协同效率，增加需求理解的一致性，而且能够有效地梳理和清晰地展示需求的层次结构，同时保持在需求拆分过程中的全景图。
用户故事地图避免了哪些坑？
极大降低了项目延期的风险
确定了合理的交付模式，提升了用户满意度
提升了需求讨论的效率
确定了较客观的发布计划，避免了过度承诺
用户故事地图的执行过程
需求先期讨论
业务方和研发在一起对需求进行了先期的沟通和讨论，此时的需求还是比较模糊的。
需求反讲，澄清和明确需求
1. 看板墙上先贴出主干流程（紫色卡片）；
2. 研发人员将所理解的业务需求以故事描述的形式写在黄色卡片上；
3. 研发贴卡片的时候，会讲述需求给业务方听。业务方对需求进行补充和澄清。有时和研发会有争议，则重新进行讨论。
（需求反讲时，研发和业务方的讨论）
确定交付方式
此项目有10个主要的需求模块，隶属法务下面不同的业务部门，相对独立。存在两种交付方式，第一种是做完一个交付一个；第二种是每个需求模块均先实现一些最基本功能，再整体逐步细化。考虑到法务合同管理数据量大，人工处理和分析效率很低，是目前业务方的突出痛点，亟待解决。因此，团队采取第一种交付方式并将此业务需求模块提到高优先级实现。之后的需求模块综合考虑延迟成本、研发周期和需求的清晰度等因素分批实现。
确定优先级
按照已经确定的交付方式，团队成员将故事卡片重新排列，按照优先级和交付顺序分为不同的层次。每张卡片都按照类别和层次进行编号。
（按照交付模式重新排列后的故事地图）
估算
选取一个故事卡片作为基准（故事点数为1），其他用户故事参照基准进行估算。最后估算出整体故事点数为108个故事点。
（估算故事点）
确定发布计划
依据研发的实际生产效率和故事总点数，按照2周一迭代的周期，确定了9个迭代，交付期4.5个月。
用户故事地图要点总结
为什么要使用用户故事地图进行需求反讲？
研发开始也有些不理解，已经和业务方谈过需求了，没有必要再花时间了。作为敏捷教练这个时候一定要努力地进行引导。采用用户故事地图的形式，各方的参与度都非常高，并且研发在头脑中经过重新梳理再讲出来后，会发现很多地方与业务方的期望是不相符的。在这个过程中，业务方也会碰发出一些新的想法或者补充一些细节。因为很多内容有了更新，当整个用户故事地图完成后，我发现研发将故事卡片很认真地收集起来了。
按照业务需要（交付方式）而不是功能确定优先级
从研发的角度，往往喜欢单纯的从功能的角度确定优先级。但实际上先交付什么后交付什么完全是依据业务方的业务需要，这和某个具体功能的重要性有时并不一致。业务需要决定了交付方式，交付方式确定了业务需求的实现顺序。
磨刀不误砍柴工
用户故事地图的讨论历时4小时，团队成员做得很认真。业务方也反馈第一次花这么长时间进行需求讨论。和仓促开工导致的返工相比，这个时间花得很划算。
全局观的呈现
用户故事地图是一张业务全景图，能够将业务流程和相互之间的依赖很直观地展示出来。每个研发也清楚地知道自己在地图中的位置。
有助于确定合理的发布计划
用户故事地图讨论之前的进度预估感性成分多一些，往往偏于乐观（3个月）。而之后的发布计划是建立在交付模式和估算的基础上的，相对客观准确（4.5个月）。这样很大程度上避免了由于过度承诺导致的项目延期的风险。
本文作者：王新 敏捷教练，来源：京东信息化+（ID：JD_ITPLUS）
粤公网安备 44010602010970