琴瑟和鸣--SCRUM中“讲”好用户故事

在大多数软件产品研发团队中，一开始做敏捷转型，往往先引入SCRUM框架，过了一段时间，如果团队把框架运转的较顺畅了，你就会发现好像还有些地方不完整。有哪些地方不完整呢？

SCRUM是敏捷开发中流行的开发框架，能够很好解决产品团队迭代过程敏捷化的问题。但是，从软件产品研发全价值链角度来考虑，团队迭代过程敏捷化了，也需要前面产品需求的敏捷化。只有产品需求和迭代过程都实现了敏捷化，才能更大发挥敏捷方法在软件产品研发过程中的效用。

怎样实现产品需求的敏捷化呢？用户故事。

用户故事由1996年Kent Beck在极限编程中提出概念，2004年Mike Cohn把用户故事的方法系统化。用户故事的出现应对了产品需求敏捷化的问题，也是精益敏捷团队产品需求敏捷化应该进行的第一步。

用户故事，顾名思义，是关于用户的故事。在敏捷开发中，如何用好用户故事一直是个较难的话题，大家一开始使用时，往往会忽略了故事是“讲”出来的这一关键点。那么，在SCRUM迭代研发过程中“讲”好用户故事有哪些作用呢？

1. 需求获取时讲故事获取真实需求

讲故事的方式对于用户来说易于接受和理解，易于产品经理与用户在业务层面进行需求信息的详尽沟通，能够促进更容易获取到用户真实的需求。

作为产品经理，在这个阶段应该避免把解决方案和用户需求混成一谈，在需求获取阶段与用户大谈解决方案，会导致用户的真实需求信息被扭曲，会放大我们对用户价值判定的偏离。对用户进行引导式解决方案的带入，应该在较全面获取到用户真实需求后的某个时间点。

2. 需求分析时讲故事提炼需求

需求分析的时候需要相关干系人集思广益共同进行需求的整理，用户故事的交谈讨论方式便于相关干系人以价值为导向，在业务层面达成大家对需求分析的共识，从而形成产品功能需求。

3. 需求定义时讲故事探索需求（非功能需求和技术类需求）

需求定义的时候开发人员广泛介入，讲故事的方式能够让开发人员易于理解功能需求从而进一步探索并形成非功能需求；讲故事的方式也能够让产品经理更容易从价值层面理解技术需求。

4. 需求沟通（交底）时讲故事达成一致

讲故事能够同步大家的沟通方式和思考维度，用户故事的经典三段式描述使大家沟通方式简单，用户》价值》操作的递进式思考，使大家的思考维度一致，从而促进团队中各种角色真正的一致理解需求。

5. 产品Backlog梳理时讲故事进行估算排序

团队通过对用户故事估算排序时进行的几轮讨论，通过彼此讲述和隐性学习，能够更加细化用户故事的描述和验收标准，从而促进整个团队对于需求的理解更加深入地达成一致。

6. 迭代计划时讲故事进行澄清

迭代计划会上PO对用户故事的讲述澄清，能够进一步降低需求的不可预测性，与团队的速率匹配后，能够增加团队迭代计划的精准度。

7. 迭代进行中讲故事进行调整

迭代中不同角色（产品、开发、测试等）持续的讨论能够促进用户故事描述的需求本身及其验收标准不断细化；用户故事间相对优先级的讨论判定，使团队在迭代中遇到外来紧急需求或者事件时，能够保证在交付最有价值的前提下对原有迭代计划做出适应性调整。

8. 需求验证时讲故事进行内部验收

开发一旦自己认为完成了满足用户故事验收标准的工作，可以马上召集产品、测试对所完成的工作进行内部的讲解演示。开发对故事讲解演示，产品和测试人员参与验证，一方面能够使团队整体的迭代交付风险前移，另一方面能够促进团队对于用户需求的深入理解，从而更有效率地实现故事的交付验证。

9. 用户反馈时讲故事进行价值验证

用户故事的独立性、场景化的定义和交付，使用户的体验更完整，更容易提出反馈和团队进行沟通，从而能够促进可工作软件的价值性验证。反馈的容易减少了产品团队与用户的反馈环长度，增加了单位时间内产品团队与用户之间的反馈频次，最终缩短了产品版本的上市周期。

敏捷宣言中，个体与互动高于流程和工具。其实，用户故事的讲故事正是很好地体现了“互动”，所以，要想用好用户故事，我们先从“讲“故事开始吧！