第一篇 用户故事地图的由来
2019-12-25
来源：火星人陈勇
第一章 史前时代的用户故事
用户故事的出现
条目化的用户故事，可以说是敏捷开发的必然产物。
在瀑布模型的时代，人们可以拿到完整的需求，因此整个需求结构，层次都是清晰的。而且只有在项目的后期才需要检查是否所有需求都已经被开发出来了，因此条目化的驱动力不大。
但是在敏捷开发的时代，人们改为一步一步地受到单个用户需求，而且持续发布也使得需求被逐个完成。这就使得人们迫切需要把需求进行条目化，从而理解到底哪些需求是这个迭代要发布的，哪一些需求可以在更晚的时候出现。
不过，最初的条目化的用户故事缺少结构和层次，因此只适合使用Excel或者传统看板来管理。
史诗故事与用户故事
但是，随着大型产品也逐渐开始使用敏捷开发，人们发现单一层次的用户故事很难表达需求与需求之间的关系。
用户故事的数量也显得有些过于庞大。如果每个故事规模是5天，一个10人的团队每年工作250天，将可以完成500个用户故事。用单维度视图（比如Excel表）管理500个故事及其关系是一个繁重的工作。
这就催生了一种简单的需求分层的方式，那就是太大的故事，需要拆分为小的用户故事；而规模小且互相相关的多个用户故事，又可以合并组成一个更大的史诗故事。
但是几乎业界从来没有出现过定义清晰的两者界限。也就是说人们都知道，史诗故事大，用户故事小，但是至于两者界限，从来都没人说清楚。这导致即使两个敏捷大师，拆分完的两层故事也不（天）尽（差）相（地）同（别）。
工具与体系中的需求分层结构
在各厂商生产的敏捷开发管理工具中，由于他们面向的客户群都是较大型的产品和团队（因此才具备足够的购买力），所以都设计了一些需求分层结构；而企业级的敏捷开发框架如SAFe，基于相同的原因，也都设计了自己的需求分层结构。而且大家的设计方案都不止两层，而是三层。
这些需求分层结构，各自使用了自己的一些词汇，看上去都有道理，但是互相无法说服对方。而且从字面上用户也很难判断到底哪一家更加合理，即使同一家所使用的词汇，词汇与词汇之间的界限也都是模糊的。因此经常看到，工具的使用者在使用工具多年以后，仍然没有启用其中的某些层次，尤其是较大的第一层次。
下面就是常见的工具与体系中的需求，分层结构及其名称：
这些词汇中的一些，比如史诗故事和用户故事，本来就不属于传统软件工程领域，因此人们借来之后可以随意解释。同时这些词汇也无法望文生义，即使已经从事软件需求分析多年的从业者，只要是第一次接触，也难以得到一个直观和正确的定义。
分层结构外观
在不同的工具或体系中，外观大致如下：
作为市场占有率最高的工具之一，Jira的两层需求结构还是使用率比较高的。不过一般的团队，都拿不准怎样正确使用，甚至有的团队，直接把项目当作史诗故事。在我咨询和培训过敏捷开发企业中，50%以上正在或曾经使用Jira，但没有一家启用了最大的层次Initialtive；对Epic和Story的划分也没有明确定义，甚至有人直接把Epic作为项目使用。
第二章 用户故事地图
用户故事地图
上图是在各大搜索引擎网站占据榜首地位的用户故事地图示例。
用户故事地图把需求分为三层：第一层也就是最上面的橙色的四个，是最高的层次，表达了最宏观层面的需求结构；第二层也就是蓝色的部分，是中等规模的需求结构；下面的黄色背景的部分，则是最具体的用户故事
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
