关于敏捷开发:敏捷需求管理篇｜如何从01写好一个用户故事

作者：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-…

Gitee 地址：https://gitee.com/CloudWise/f…

万元现金流动： http://bbs.aiops.cloudwise.co…

微信扫描辨认下方二维码，备注【飞鱼】退出 AIOps 社区飞鱼开发者交换群，与 FlyFish 我的项目 PMC 面对面交换～