敏捷产品管理之 Story

上篇我跟大家详细介绍了产品 Backlog，它是敏捷团队管理开发过程的核心，所有的活动和交付物都围绕产品 Backlog来进行。一个完整的 产品 Backlog = 估点的用户故事（User Story, 之后统称为 Story ）+ 优先级 + 验收标准。那为什么 Story 是作为描述产品 Backlog 最好的形式？我们又如何编写有效并且粒度合适的 Story 来帮助团队成员在理解需求上达成一致，共同决策呢？本篇我就带着你从理解 Story 开始，经过建模、搜集、编写、估算，让“一张卡片”发挥出它的洪荒之力，快速挖掘需求，理解需求。

一 为什么要用 User Story ？

软件需求是一个沟通问题。在现实开发的过程中，最常见的一个问题就是一旦有一方（业务或开发）占主导地位，沟通就会出现问题，项目不管是速度还是质量都会受损。这个时候我们就需要有一个协同工作的方式，让两方共同承担资源分配的责任。那这种协同工具必须具备的特点是团队任何角色都可以很好的理解，并且能清楚的站在用户的角度。另一个方面是我们没有办法在最开始就完美的规划出项目中所有的需求，我们需要定期获得反馈信息在作出下一步的判断，没有包罗万象的决定，我们需要一边收集信息，一边不断频繁迭代一个个小的需求。而 User Story 完美的解决了这两个问题。它具有以下特点：
强调对话，而不是文档
可以同时被所有相关人员理解
大小适合做计划
鼓励推迟考虑细节（即 Story 也可以迭代）

二 User Story 是什么？

User Story 描述了对用户、系统或者软件购买者有价值的功能。一般由三部分组成：卡片（Card）、对话（Co