zhang_qxian的专栏

如何创建用户故事地图 用户任务是构建故事地图的基本模块 使用目标层级的概念，可以帮助汇总小任务或分解大任务。隐喻：石头，砸成小石头后仍是石头 故事地图通过从左到右的叙事流来组织。补充细节 探索替代故事。细节、替代、变化和异常都成故事地图的主体。保持流动。 提取故事地图的主干。高层故事。活动组成故事地图的主干。 使用切分来识别和特定结果相关的所有任务和细节。此时活动卡片不要移动。 概念总结： 任务是描述人们做什么事情的动词短语 任务有不同的目标层级 故事地图中的任务被布置在从左到右的叙事主线

对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。需求其实很可能是一个假想，那么唯一可行的做法是验证想法是否具备可行性。验证的方法很多，比如和客户、用户深入交谈，观察他们目前做事的行动，不断和他们反馈，用手绘线框图（Axure）和高保真模型实现解决方案的具象化，并以此和客户/用户进行沟通。通过原型和用户测试来验证产品方案是否真的有用，有价值，并能够质疑用户所说的内容，然后在开发过程中学习（Scrum），迭代乃至最终发布。必须要始终记得，交付给客户/用户的是可用产品。 基于验证的学习循环：开发-（最小可

计划，为了更少的开发 故事地图帮助大型组织建立共识。贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。 大型用户故事地图解析：1、故事地图的主干在顶部；2、地图要涵盖整个发布计划；地图要涵盖贯穿多个用户和系统的叙事主线。 提前发现可能造成损失的潜在风险是好事而不是坏事 需求范围并没有蔓延，而是我们对需求的理解更深刻了。 要做的事情太多，如何排定优先级？聚焦于系统外的预期成果来决定系统内需要什么功能！！聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向【针

两个最重要的认识： 使用用户故事的目的不是为了写出更好的用户故事 产品开发的目的不是开发出产品。 使用用户故事的目的是最终达成共识，而达成共识最高效的方式就是面对面，借助于可视化手段来讨论，并用卡片、照片或者视频等做好备忘，以便于后续能够回忆起当时讨论的场景。不要试图去写完美的文档，不同的人对同一段文字的理解可能有天壤之别。如果从更高的层面上来讲，你的工作是改变世界（或多或少），因此软件本身并不是重点。重点在于outcome，即软件本身给用户带来了什么样好的改变。对于软件来说，想要开发的功能，总比.