做网站下载,开发一款游戏软件需要多少钱,python 采集 wordpress,做网站菜单背景图片前提
我以前在之前的文章里大概介绍了 Azure Board 的基本使用#xff0c;可以回看《Azure Board 的基本使用》。如果你想使用 Azure Board 来安排工作的话#xff0c;请提前了解《敏捷开发》的相关知识。
作者将使用 “Agile” 作为项目的模板#xff0c;不明白的先阅读《…前提
我以前在之前的文章里大概介绍了 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代码具体实现
下面的图是我在公司里的真实案例这样各位同学应该更有概念了。
