【转】Azure DevOps —— Azure Board 之 长篇故事、特性、用户情景（故事）的用法应用场景
前提
我以前在之前的文章里大概介绍了 Azure Board 的基本使用，可以回看《Azure Board 的基本使用》。如果你想使用 Azure Board 来安排工作的话，请提前了解《敏捷开发》的相关知识。
作者将使用 “Agile” 作为项目的模板，不明白的先阅读《Azure DevOps 的工作流进程的区别》。
使用 Backlog 来做计划
什么是 Backlog？这是敏捷开发中的一个概念，通俗地说就是需求积压池。
产品负责人（PO）或项目经理需要把要做的事情预先的在 Backlog 中记录下来。在敏捷中需要把每一个功能单独的写出来，而不是传统的文档模式。
在 Azure Board 中，记录需求有三种类型：长篇故事（Epic）、特性（Feature） 和 用户故事/情景（User Story），而他们的结构一般都是父子关系，即 长篇故事 （需要完成的需求）-> 特性（将该需求分成几个阶段完成） -> 情景（描述具体到 角色-操作-效果）->WorkItem（具体实现）。接下来我将以 “一个找工作的网站” 来作为例子，顺便也会提及一些敏捷开发的知识来做需求管理。
长篇故事（Epic）
通俗地说，长篇故事只记录，这个 模块（搜索模块）要做的事情，比如：“企业可以搜索简历”。很多时候，这只是在立项时的一种大想法，记录这个系统的一些主要功能，并不涉及具体需求。这里的核心思想是：“我打算做…这样的功能”，或者“我需要一个...的模块”。
如果说你想要做这样的功能，那你得说出这个功能的商业价值，比如有这样的功能的话，能帮客户或者公司赚多少钱等等，所以在敏捷开发中，在最前期的可行性分析里，会有个投票机制，来确定这功能有没有必要做，在什么时候做。毕竟你会有很多的想法，比如：“用户可以搜索企业”，或者 “用户可以搜索其他人的简历” 等等，也许在这个项目的初期阶段，相比较而言 “用户可以搜索公司” 这样的需求可能就不显得那么有价值了。
通过这样的方式，公司可以规划出在一定时间内的产品价值，如果总是做一些市场价值不高的功能，那必然离失败又更近一步。
特性（Feature）
特性一般在项目中表示里程碑，将长篇故事中的事情分成几个步骤完成。也就是当前 Epic 要完成的大致内容。
比如上面的例子 “企业可以搜索简历” ，你需要再稍微细化到具体点的内容，怎样搜索？比如：通过搜索框输入关键字，可以通过省市区，可以通过行业等等。特性主要体现的是 从哪些方面才能完成这个长篇故事。
在 Azure Board 中添加特性，和上面的操作步骤差不多
在列表中
选择一个长篇故事，点击前面的 “+” 号
注意弹框的提示，输入标题，按 “Ctrl + S” 保存或 “Ctrl + Enter” 保存并关闭。
在板中
如果还没有特性
会在下方多出一个层的文本框，很明显这就是标题，输入完回车即可。
如果有特性，点击奖杯可以展开
数字是告诉你 完成/总共
用户故事（User Story）
在敏捷开发中，使用用户故事来体现真正的需求，由于故事一般是由客户或PO来写，所以体现的是基于用户本身的痛点和真实的需求，这样避免了 曾经的做出来不是客户想要的 尴尬局面。用户故事体现的是 我们怎样开始做 这个需求。
比如刚才的例子：通过行业来搜索简历。那故事里就要写清楚行业有哪些，如何展现，用户如何操作，怎样的布局和配色等等。这样就完全涉及到细节上，因为是真正的要开始开发了。
回到 Azure Board 中，和添加特性的方式一样
在特性前面点击 “+” 号
在板中，你需要先切换成 “特性”
用户故事的写法，有一个规范格式
这种规范，基本告诉了程序员，什么角色做这个操作，大概是怎样的操作，为什么要这样做。同样也会告诉客户或者PO或者写用户故事的人，这样的需求有没有必要。
总结
我们已经明白了长篇故事（Epic）、特性（Feature）和用户情景/故事（User Story）在 Azure Board 中的用法以及如何进行管理，同时也大致了解了敏捷开发是怎么回事，以及如何写用户故事的标题。
长篇故事 （模块：需要完成的需求）-> 特性（阶段：将该需求分成几个阶段完成） -> 情景（功能：描述具体到 角色-操作-效果）->WorkItem（代码：具体实现）
下面的图是我在公司里的真实案例，这样各位同学应该更有概念了。
总结
以上是生活随笔为你收集整理的【转】Azure DevOps —— Azure Board 之 长篇故事、特性、用户情景（故事）的用法应用场景的全部内容，希望文章能够帮你解决所遇到的问题。
- 上一篇： 美债规模逼近27万亿美元，新一轮债务扩张
- 下一篇： plus 什么是mybais_谈谈自己用