引言
对于一个用户需求，产品、开发和测试对这个需求的理解完全不一样，最终交付的产品根本不是用户想要的，这种情况在实际开发中非常普遍。
用户故事也是一种将需求可视化的工具，它通过将需求拆分成一个一个的用户故事，来组织软件开发。每一个用户故事都是软件开发过程中相关角色沟通的媒介，所以用户故事也是一种通过合作沟通的方式来理解用户需求的工具。
软件开发是团队项目
随着软件系统的规模越来越庞大，软件开发过程中的分工越来越明细，靠单兵作战来实现复杂系统越来越不现实。在企业中，无论是合同项目还是自有产品，通常采用项目管理模式，成立专门的项目组(Team),进行具体的研发工作。项目组通常由多种角色的成员构成，角色对应的职责如下：
(1)项目经理
项目的主要责任人，对项目的进度和质量负有主要责任。项目经理主要负责项目的日常管理，如计划制订、任务跟踪、沟通协调、团队建设、需求分析、技术审核等
(2)产品经理
一般自有产品才会配备产品经理，主要负责市场调研、产品策划、撰写产品的需求、跟踪产品的实现、协助市场人员进行产品的营销、获取用户反馈、产品的改进等
(3)架构师
主要负责系统的总体设计、详细设计，撰写设计文档。
(4)软件工程师
完成需求分析、软件功能的开发和单元测试及相关文档的撰写。
(5)测试工程师
编写测试用例，制订并执行测试计划，进行集成测试和系统测试。
上面只是列举了一个项目组通常具有的角色，每个项目的大小和类型不尽相同，项目对技术能力的要求及项目成员水平也各不相同，要根据自己的际情况来安排，团队协作是个老生常谈的话题，但真正做到高效协作并非易事。
什么是用户故事？
用户故事之所以叫“故事”，是因为它是用来“讲”，而不是用来“写”的。它从用户的角度来讲述如何使用软件的功能，带来怎样的收益。整个软件团队通过讲用户故事，让大家获得对软件产品的一致理解，然后共同创造出更符合用户需求的产品。
如何"讲"好用户故事
就像上面提到的，用户故事是用来“讲”的，而不只是“写”的。上面的例子中，如果这个不讨论用户故事，你能知道【立即显示】是输入 1 个字、 2 个字，还是有光标就能显示呢？因此，“讲故事”是本课时的核心观点，用户故事的关键就是“讲”。那么，怎样才能“讲”好用户故事呢？
1、聚焦全景
软件开发最终交付给用户的是一个可以工作的软件，这就需要先实现一个一个单独的功能。因此，我们需要将一个大需求进行合理拆分，拆分后的需求就称为“用户故事”。
2、3C原则
3C 原则是在由 Ron Jeffries（罗恩·杰弗里斯） 等人在《极限编程实施》一书中提出的。3C 原则描述的是为了更有效的使用用户故事进行需求分析时应该遵循的原则：
卡片（Card）：在卡片上写下所期望的软件特性。
交谈（Conversation）：聚在一起对要开发的软件进行深入讨论。
确认（Confirmation）：对完成的特性进行确认。
1. 卡片（Card）
卡片是用户故事的载体，用来记录用户想要的每一个产品特性，上图中的每一个用户故事卡片都对此有所体现。
通过这种方式，可以很容易地组织这些卡片，比如通过拖拽的方式选择本次迭代需要交付的用户故事，排列用户故事的优先级等。
2. 交谈（Conversation）
创建好卡片后，我们并不是直接将卡片甩给团队中的其他角色。而是请相关人员围绕卡片中的用户故事进行讨论。在讨论过程中：
每个参与者都可以通过提问来表达自己的疑惑，其他参与者则可以帮助解答。如果在某个问题上有分歧，则所有参与人员共同讨论决定。
除了使用创建好的卡片之外，还可以借助像思维导图、流程图、原型图等有助于理解的可视化工具，避免参与人员通过手势对着空气挥舞。
讨论中所涉及的问题都需要进行标记、并在事后进行修正整理。
总之，交谈的目的是让所有参与者对用户故事达成一致的理解，并一起努力找到解决问题的最佳方案。就像看到旅行照片一样，团队成员当看到这张卡片时就能回忆起当时讨论的细节。
3. 确认（Confirmation）
现在，团队成员已经对用户故事达成了一致，这时就需要考虑如何判断这个用户故事是否已经完成开发，也就是明确验收条件。
一般情况下，当开发完成后需要通过单元测试、SIT 测试、UAT 测试，通过测试后该用户故事才算完成。剩下的就是根据业务需要随时发布该功能到生产环境中，完成最终的用户交付。
3、故事模板
现在你了解了讲好用户故事需要注意的几个方面，但作为软件从业人员来说，这还不够。相对于产品和市场人员来说，很多开发人员不知道如何去讲用户故事，也不习惯讲用户故事。这时，你需要使用用户故事模板，这样就能够对卡片上的内容有一个指引，方便讨论。如下图所示：
为了达到更好的讨论效果，这里罗列几个讨论清单：
- 讨论用户角色。 不要单纯地将所有使用软件的人抽象为“用户”，要更加具体，比如企业用户还是个人用户，个人用户又可以根据年龄、性别进行细分。每一个用户群体对软件的诉求是不一样的。
- 讨论要做的功能。 不要只讨论用户能够看得见摸得着的界面功能，也要考虑界面后所调用的后台服务，其他服务与服务之间的调用关系、服务调用时的鉴权功能等也需要考虑。因为这些才是软件可工作的基础。
- 讨论该功能的价值。 讨论为什么用户需要这个功能。提问也是一门艺术，可以通过 5 Why 提问法，多问几个为什么，就可以发现隐藏在背后的真正原因。
- 讨论异常情况。 讨论可能出现的异常情况，以及出现异常后的解决方案。
- 讨论开发周期。 讨论用户故事什么时间完成开发，什么时间完成测试，什么时间最终交付给用户......为这些时间点提供一个预估的计划表。
用户故事及用户故事地图，很多企业的研发团队中都有使用。就像开头提到的那样，软件开发是一个团队项目，在团队中沟通协调是至关重要的。
总结
团队协作一直是贯穿于软件研发全流程，一套高效协同的工具或方法论，可以有效的提高研发效率、保障交付的质量，用户故事在现如今软件迭代速度越来越快的今天，是一个值得一试的工具。
