azure devops扩展组件安装

大家好，我是若江冰。今天我们聊一聊如何使用 hd box 来高效的规划和管理需求。 在进入正题前，我们先简单回顾一下敏捷开发和 debux。 如果想直接进入实操演示，部分的小伙伴可以跳转到下一章节。 在之前的视频中，我曾经介绍过 doubles 是因为敏捷开发的新企业而产生的，而 square 是一个非常经典的敏捷模型。我之前也介绍过 square 加 doubles 结合的工作模型， 有兴趣的同学可以点击下方的链接观看。在接下来的几期视频中，我会根据这个工作模型来介绍 ichy debux 在不同环节中的应用。那么就让我们从这个模型的第一步需求管理开始吧。现在我们看到的是 ichy debux 的页面，在这里 我已经新建了一个 hello fire ug 的项目，让我们点击进入项目。我们可以看到 hdabox 主要包含五大功能，其中 box 是一组敏捷工具，它可以帮助我们计划和跟踪所有工作。我们主要使用其中的 backlog 来进行需求的管理和规划。 backlog 也称为积压工作。在 isodebox 之中，需求管理的实质就是维护 backlog 列表中的工作项的内容以及它的优先址。在 backlog 界面中，工作项有三种类型长篇故事特性和积压工作项。 这里虽然说的是三个类型，但是通常情况下他们是有隶属关系的。概括起来就是这家工作项隶属于特性，特性隶属于长篇故事。长篇故事是一个总的目标，是由一系列相关联的特性组成的更大的交付，比如完 网站的建设、改进应用的用户体验等。特性指的是可交付的软件功能或组建，相当于我们常见的 loadmap。 例如网站建设可以划分为外部版本开发、移动端适配等。 积压工作项指的是非常具体的工作项，它一般包含了产品积压、工作项和 bug 两种类型，我们一般统称它为 pbi。 在实质的工作过程中，我们通常以 pbi 为单位来分配任务。长篇故事和特性的划分 实际上没有特定的标准，比如我们刚刚提到的网站建设，完全可以用规划、设计、开发等里程碑的维度来划分我们的特性，只需要团队内部达成一致即可。 工作项类型之间的关系也不是绝对的，比如说积压工作项也可以直接作为长篇故事的纸质，甚至有时候团队都不使用长篇故事和特性，直接使用积压工作项。 接下去我们通过案例来介绍一下工作项类型的使用。首先我们看第一个案例建设 failg 官网。我们的目标是建设网站，所以我们的长篇故事就是 failg 社区的官方网站建设。然后 我们将长篇故事拆分为静态网站、多端适配、网站、数据知识编辑、社交媒体记录四个特性。这四个特性其实非常完美的呈现了我们网站建设的思路和迭代计划。最后， 在每一个特性下，我们需要拆分出更加具体的工作项，比如多端适配，这个特性我们会包含 pad 端的适配、手机端的适配等。刚刚我们提到过，长篇故事和特性的划分并没有特定的标准，所以接下去让我们看一下第二个案例 ittybox 系列视频的更新。首先， 长篇故事，也就是我们的目标是 itabox 探索系列二零二三年度的周根计划。其次，虽然我们设计的目标是周根，但是实际入职来说，可能是多期一起入职，所以我们的特性按照每个月来进行设计。 最后，每个特性下的工作项可以设计成对应视频的主题。从上述的案例来看，三个工作项类型本质上只是为了帮助大家更好的规划需求，严格意义上来说并没有一个统一的标准，大家完全可以根据团队本身的习惯自由的使用。 最后，我们来看看 bug log 的常用功能。通常情况下，团队成员主要关注的是积压工作项列表，也就是我们常说的 pbi 列表。让我们选择积压工作项类型进入积压工作项列表。我们可以点击右上 上角的视图选项，隐藏工作项的层次结构。隐藏后，长篇故事和特性都会被隐藏掉。同时，我们可以点击设置按钮，设置工作项类型的导航级别。当我们取消对长篇故事和特性的勾选后，工作项类型的下拉框就会隐藏掉对应的类型。 我们可以点击新增工作项按钮，快速的添加 ppi。 大家可以看到，这里的工作项有两种类型可以选择，我们也可以点击列选项，根据我们的实际需要，自由的定义列表需要显示的内容以及每列的排序。 最后，我们可以按住 shift 键批量选中 pbi， 进行批量的编辑，比如批量分配 pbi 给某人、批量删除等，也可以通过上下拖动的方式改变 pbi 的优先级，非常的便捷。好了，以上就是本期的全 内容，欢迎大家在评论区留言讨论，一键三连加关注，我们下次见哦！