敏捷需求管理篇｜如何从0-1写好一个用户故事

作者：Iris Xu，云智慧 企业效能 部。

敏捷需求管理

传统的需求是一个比较笼统的概念，即产品改进需要的集合。敏捷需求则通过对传统需求的细化分层，管理不同颗粒度的需求。本文通过对敏捷需求管理概念解析，详细解读如何写好用户故事，以提高业务人员与开发人员对需求理解的一致性，面向业务价值进行交付。

敏捷需求的分层管理

如下图所示，敏捷中需求通常被分为史诗、特性、用户故事三大类别，逐层往下，粒度越来越小。需求直到被分解至用户故事时，才能放入Scrum迭代。

• 史诗：由多个较小的故事组成的史诗。

• 特性：一组相关的故事，有价值的单方向功能集合。

• 用户故事：独立的较小用户的价值交付单元。有可能不足以单独发布。

用户故事与Bug缺陷、验收标准以及任务进一步关联。任务一般由研发团队拆解，可分为前端、后端、测试任务。除此之外，企业技术团队还会做一些技术优化或技术债务的偿还，这类需求则可以被称作技术故事。另一方面，当企业需要做管理实践，如知识分享或员工技能的培训时，这类需求也可以添加至迭代中。

需求四要素

正常情况下我们在描述一个需求时需根据4W法则，即 Who、When、What、Why。根据上述延伸出来了需求的四要素包含用户、场景、任务、成果。

用户故事的重要性

为什么要写用户故事

用户故事的好处在于可以让业务人员和开发人员在理解同一件事时可以处在同一纬度。主要有以下三大优点：

1. 提高合作效率：业务人员和开发人员通过面对面的沟通，提高了沟通合作效率。

2. 保证理解一致性： 业务人员和开发人员通过对需求面对面直接拆解、讨论，更容易对需求理解达成一致，减少认知偏差。

3. 减少 风险 ： 用户故事通过提高团队合作效率，保证业务人员与开发人员对需求理解的一致性从而降低了由缺乏沟通导致的技术风险、成本风险等。

如下图所示，不同的角色会站在自己的层次上，默认别人也应该知道，往往造成需求理解的偏差和遗漏。

用户故事的价值

用户故事的价值主要包含以下五方面：

1. 强调口头沟通而非书面沟通

2. 用户和开发人员都可以理解

3. 故事大小适合做 计划

4. 适用于迭代开发

5. 鼓励推迟细节

如何写好用户故事

用户故事的概念

用户故事是敏捷软件开发中的一种轻量级的需求分析方法。（user story）是从用户的角度来描述用户渴望得到的功能，是一个对用户或客户有价值的功能点的简单描述。有以下三方面组成：

1. 一份故事的书面描述，用于做计划和提示

2. 有关故事的对话，有助于充实故事的细节

3. 传递和记录故事细节的测试，用来判定故事是否完成

用户故事的写法

写好一个用户故事应遵循3C原则，即当把需求主题写在卡片（Card）后，通过交流（Conversation）澄清需求的细节，并作为确认（Confirmation）信息记录下来。用户故事完成后产品经理应从业务的角度定义故事的验收标准，确保故事被正确、完整的实现。

1. 三段式

初学者可采用三段式来编写用户故事，即每一个Story只针对一个用户角色来描述，关注用户的业务目标，可迫使需求分析人员从用户的角度进行思考，使用用户的语言来描述需求。熟练掌握Story之后可以采用更简洁的方式，如用户可以做什么操作，用户希望系统提供什么功能等。

2. 分析方法

具体可以分为以下步骤：

• 识别用户角色：应尽可能定义“人”而不是“系统类”角色。 为能影响项目成败的“用户”定义角色；

• 分析业务流程 ：业务流程是指用户跟被实现系统之间的交互流程，不包括系统内部各部件之间的交互流程；

• 提取Story：根据用户可以感知的层次，从交互步骤中提取出一个个Story；

• 整理Story：Story太大，则需要进一步分割；Story太小，则可以跟其它Story进行合并。

用户故事INVET原则

• 独立性（Independent） ：要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

• 可协商性（Negotiable） ： 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

• 有价值（Valuable） ： 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

• 可估算性（Estimable） ：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

• 短小（Small） ： 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

• 可测试性（Testable） ：一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

如何写出更好的用户故事

• 从目标故事开始：思考每个用户角色，确定与软件进行交互的目标；

• 纵切蛋糕：每个故事都能提供一定的端到端功能；

• 编写封闭的故事：随着故事的实现完成，一个有意义的目标随之完成；

• 约束卡片：那些必须遵守而不需要直接实现的故事卡；

• 根据实现时间来确定故事规模：写出不同层级的故事；

• 不要过早涉及用户界面；

• 需求不止故事：用户故事并非适用于所有系统；

• 故事中包括用户角色：通过想象真实的、具象的用户，开发出满足用户需求的软件；

• 为一个用户编写故事：增加用户故事可读性；

• 用主动语态；

• 客户编写；

• 不用给故事卡片编号；

• 不要忘记目的：故事卡的主要目的是提示人们讨论该故事。

开源福利

云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件，零编码即可实现符合自己业务需求的炫酷可视化大屏。 同时，飞鱼也提供了灵活的拓展能力，支持组件开发、自定义函数与全局事件等配置， 面向复杂需求场景能够保证高效开发与交付。

点击下方地址链接，欢迎大家给 FlyFish 点赞送 Star。参与组件开发，更有万元现金等你来拿。

GitHub 地址： https://github.com/CloudWise-OpenSource/FlyFish

Gitee 地址：https://gitee.com/CloudWise/fly-fish

万元现金活动： http://bbs.aiops.cloudwise.com/t/Activity