过年期间拿回老家几本书，大家都忙着看电视节目的时候，找个角落翻起这本《用户故事与敏捷方法》
如果你想确定你的产品应该做什么？
如果你想知道怎样跟他人沟通你的思路？
那么你适合阅读一下这本书
整本书分为四大部分，分别从怎么构建故事、如何评估任务、基于用户故事一些扩张话题，以及最后通过一个案例来复盘前面章节学到的内容，下面我就从我个人比较感兴趣的角度尝试谈谈这本书内容
身为产品经理我经常需要处理不同参与者的需求，项目经理关注进度、研发工程师追求技术架构、测试人员重视质量、设计师关注体验、用户想要可用的系统
我是奔着学习“用户故事”这个方法，尝试解决身边遇到的问题
下面我就通过故事的特征、收集故事的方法、用户代理、切分故事、故事不是什么、故事的优劣势几个方面聊聊这本书
故事的特征
故事用于讨论，这句话是你首先需要记住的一个特点，整个故事鼓励的是后续相关参与者共同讨论，逐步细化。不鼓励开始阶段详细的分析每一个细节，除此之外每个故事要相对独立，从对用户有价值的角度来讲故事，每一个故事都通过使用用户听懂的语言编写，最好有用户自己编写，最后多人参与讨论，使故事大小适中，并且可以通过测试进行故事完成情况的验收
收集故事的方法
之前听过很多需求收集方法强调引导、补货需求的方法，这本书把收集故事的方式，形象的比喻成“拖网渔船捕捞鱼”的形式来收集需求，不同大小的网用来捕获不同大小的需求，通过大网捕获大需求形成对软件的整体感觉，通过小网捕获需求逐步完善系统。把需求比喻成鱼的另一个含义还有鱼会长大类似于需求单位变更，也会死亡类似于需求的过期，还有一点就是肯定会有漏网之鱼以及打捞过程中的一些废弃物都是错误需求的形象比喻
用户代理
需求分析找到严格意义上的实际用户做调研是可遇不可求的，我们平时接触更多的是一些客户经理、领域专家、流程规划岗、培训师和市场销售人员等，这些某种程度上都是用户代理，或多或少都会有些个人偏见，在需求调研过程中应该识别出每个角色的特点，某种程度他们代表产品的不同角度，尽最大可能挖掘每个角色提供信息的有效内容，虽然每种用户代理都有各自的缺点，但自己猜测用户需求带了的问题更多
切分故事
切分故事的目的是便于迭代开发，所以在没讨论每个故事具体细节前，无法估计切分后的故事是否会在一个迭代中完成，这就要保证切分后的故事在某种程度上是自成一体的完整故事。书中把这种情况形象的比喻成切蛋糕，首先通过完整的故事看到系统地轮廓，有时候可以写一些史诗故事用于整体故事结构的占位，后续通过切分后的小故事，在每一轮上线都能提供一个可用的功能
故事不是什么
书中拿出一个章节重点讲了一些我们常用的需求分析方法，类比了一下用户故事、用例、软件需求和交互设计场景之间的区别。
不像软件需求和用例，用户故事不是分析的结果，而是进行分析的工具，用户故事是基于我们事先无法全面完整的把系统描述清楚，我们只能大概的知道一个可供后续讨论的方向，用户故事也没有交互设计那么具体，用户故事更强调的是完整性、可讨论和易交流
故事的优劣势
用户故事便于口头沟通，容易被各种角色理解，整体的故事适合做系统规划，拆分后的故事适合迭代开发，用户故事鼓励延迟沟通故事细节，支持随机应变的开发，拥抱各种角色的参与，但面对大型项目组织故事的难度较大，面对大量需求时，故事不如用例等其他形式更利于整理收集，通过其他形式的方式来补充用户故事方法的短板是正确的方式
用户故事是产品经理在需求管理过程中一件好使的工具，但需要你不断的学习、理解、实践，最终通过自己的理解掌握这一工具对于产品需求管理的价值
二零一八年二月十九日于鸡西
