用户故事定位 - Agile307/agile GitHub Wiki
English Name: User Story Positioning
用户故事定位，在识别故事的开始就试图把用户故事的内容存放到长期存放的地方，直接定位到表达系统功能合适的地方，减少复制和搬移。这就是定位的含义。
为什么要定位用户故事？
用户故事自1998年出世以来，其组织方式一直在演变，刚开始放入到单列表的Backlog中，后来加入Theme、Epic，组成双列表或者树形，见用户故事历史。但其面临的困难不仅没有解决，而且随着其大面积更深度的应用，困难更多了，见用户故事的困难。
在大系统长期开发维护中，在既有功能上修改扩展是经常发生的事情，有些功能上线后马上被要求修改升级，有些功能上线了2个月发现不合适需要修改，有些功能上线了1年后因为业务变化需要增强，等等。如果当初书写的故事小纸片找不到了，那么对照线上实际功能和源代码，总是能够完成修改升级的，但往往会有这样的抱怨“前面没有留下任何文档，搞定这些费了我的洪荒之力”。 但是如果这些功能对应的用户故事能够被查找，那么就至少能让新的开发有所借鉴，了解当初的故事是什么样的，有什么验收条件，进而能提升修改升级的效率。
用户故事得到定位，就能方便查找；其上下左右的关系得到表示，就能便于理解其位置，进而更好的判断在哪里修改新增或者删除。 用户故事定位，不仅仅在于表达单个迭代里的少数故事，更重要的是表达系统持续演进下的整体故事群。
新出现的用户故事地图方法解决了大系统长期开发维护的需求问题吗？ 没有。 而用户故事地图方法虽然部分解决了故事之间关系展现的困难，但没有解决故事长时间存放以备未来修改升级的需要，见用户故事地图中说明的缺点。
用户故事定位方法并不是来源于[用户故事地图]]，虽然时间顺序上，故事地图方法发布更早。用户故事定位方法提供了[[故事图]]+[故事树来更好更全面的展现故事之间关系。
用户故事定位是什么？
用户故事定位的定位是什么？
用户故事定位是利用多种工具组合，直接定位故事到长期位置的敏捷需求表达方法。同时高效的支持短期和长期的系统功能新建和升级修改。用户故事定位方法仍然使用产品待办列表来表达优先级，使用泳道图来表达故事之间的关系，能够替代用户故事地图方法，有更清晰直观的表现力。
核心做法摘要
- 使用Wiki来书写用户故事的内容，从功能树根部采用多层次文档结构，层层递进，形成系统功能树，将用户故事放置到系统功能树的恰当位置；如果史诗的初次定位不清晰，那么就从史诗开始，同样从史诗到故事采用多层文档，层层递进，到用户故事。
- 使用条目化管理工具来管理用户故事的开发测试等活动
- 使用泳道图来分析获得用户故事
- 采用内置于用户故事内容中的迭代标识来识别迭代中用户故事，也称为故事切片，不因为用户故事在不同迭代开发而切分它。
用户故事定位关键环节
下文将对以上内容一一展开。
如何识别用户故事？
- 识别用户
- 识别其它系统
- 分析用户的需要，识别史诗（Epic）
- 针对史诗（Epic）绘制故事图 ，将多个用户和相关系统设置为泳道
- 在泳道中识别用户故事和系统故事
首先识别用户
Rules:
- In the user story tree, User story's scope is not covered by another user story.
- User story has a suitable and short title.
例子1-Email客户端
模仿用户故事地图中的经典Email用户故事，采用用户故事定位方式，见Email用户故事