如果说在敏捷开发过程中，有一样东西贯穿SCRUM始终，我觉得就是用户故事：从计划会上对故事分解开始、开发过程中对故事进行编码测试、每天对所做故事的讨论、对已完成故事的评审、到单次循环最后对故事回顾和改进，然后又回归循环。这本Mike Cohn的《用户故事》就是这样一本描述用户故事贯穿敏捷开发始终的书。
  我原来是用C++写项目的开发人员，对瀑布模型有很深的体会，原来的瀑布模型开发前会做详细的需求设计，然后开发人员根据像“新华字典”这么厚的需求规格说明来指导开发软件，照理说这么清晰的红字、黑字文档，需求应该是很清晰了，但是现实是，最后开发出来的东西，往往和客户想要的相去甚远；于是有Mike Cohn提出了3C原则 ，需求列在贴纸上，描述应该是有大小限制、可以讨论、可以和需求方确认的。我们在开发过程中强调沟通而不是详细的纸质文档；于是一个好的故事就不得不具有5大特点：独立的（I）、可讨论的（N）、有价值的（V）、可估算的（V）、适当小的（S）、和可测试的（T），正是用户故事的这些特点，让敏捷成为了一个按照客户价值驱动的，保持固定周期，快速迭代以适应用户快速变化需求的高质量开发模型。
  用户故事帮助大家进行需求调研。福特曾说过：“如果你要问客户他有什么需求，他会告诉你他要一匹很快的马”。VUCA时代，很多客户的需求根本就不清晰，客户可能自己都不清楚自己要什么，那么如何去洞察客户的需求呢？Mike Cohn通过“航海家网站”开发，引出了一个用户需求调研模型来帮助大家解决这个问题。首先理清客户或用户角色，这里我们要区分客户和用户的需求还要学会用故事工作坊（workshop）画原型。其次，整理角色，将目的和操作相同的人归类去重，然后整合并提炼角色，形成正对每一个角色的故事描述，最后加上虚拟用户和极端用户，形成“用户画像”，画出故事原型。这是一个典型的影响地图的运用，先确定Why从客户或用户的价值目标出发，去发现归纳出WHO，然后再是这些角色要做什么WHAT，最后才是我们怎么去做HOW；所以用户故事是从用户的价值驱动出发，去写出每个用户的故事。
  用户故事帮助大家提升开发效率。用户故事被排序放到Product Backlog，Sprint Backlog里面，按照Scrum的框架结构，在团队的工作中流动，Scrum使用丰田TPS看板拉式原理，结合理想工作时进行故事估算，让PO按照投资回报率进行优先级调整，最后进行开发。整个过程保证了按照客户价值优先级来开发，运用新一代时间管理《搞定》一书的原理来高效开发，看板可以帮助发现流中的瓶颈，优化提升流动速度，从而加速开发；迭代燃尽图和故事燃尽图跟踪故事开发的进度，提前发现项目风险，短期的迭代方便大家迅速调整，适应变化。通过短期迭代调整，适度大小纵切故事的估算、优化价值流来提升开发效率。
  用户故事帮助大家提升产品质量；速度和质量在敏捷开发里面并不矛盾，敏捷开发强调质量内嵌，通过将测试用例写入用户故事中，然后便于开发人员使用TDD、ATDD等技术来提升编码质量，而快速迭代和客户的持续变更，会导致缺陷的增加，我们需要开发、测试的合作，通过对用户故事的纵切，提早发现架构的缺陷，持续不断地写自动化测试脚本，每天的增量构建、集成和频繁的自动化测试，将bug率降低在了客户信任的范围。用户故事编写的灵活性，也同样适合客户的功能性需求；因此，用户故事可以确定客户的验收条件，从而保障了后续开发过程的产品质量。
  关于用户故事建模的心得；在我第一次读到用户故事建模的时候，比较惊叹于这种需求调研方式，于是在团队中大力推行，但后来发现团队使用得并不多，大家更趋向于按照传统的故事获取方式，及找到PO或客户代表，一条一条的记下需求，然后提交美工出UI，再找客户确认；采用这种方式，最后项目交付还是没有问题；我私下访谈过团队成员觉得那种方式更好，大家觉得这种方式更直接，更符合团队和客户的工作习惯，因此我更坚信只要价值观不变，保持客户的沟通和反馈，而采用不同的工具和达到的效果没有太大区别，如果工具更适合自己，大家更愿意用。
  需求、设计、成本、时间、团队、人员在变，不变的是变化，问题不是变化本身，而是我们如何去应对变化，Mike Cohn的用户故事这本书，教会了我们如何用故事去撬动客户的需求，但不能仅限于书，敏捷本身就是为变化而身，知识和工具也要去适应环境的变化；用敏捷的思维去适应变化，从而为客户创造更好的价值，为团队带来更高的绩效。