时间戳

首页 > 解决方案 > Azure Boards，如何使用每个工作项类型？

azure - Azure Boards，如何使用每个工作项类型？

问题描述

哪个是最专业的选项，哪个是最通用的选项？选项：任务/史诗/功能/产品待办事项项目

冲刺将具有以下优先级列表： 选项：项目/发布/子冲刺/工作项

标签： azureazure-devopsazure-boards

解决方案

有一个计划层次结构，它取决于您为项目选择的过程。

基本的：

  Epic                 <- Portfolio backlog
  |
  +- Issue             <- Product Backlog  <-+
     |                                       |- Sprint Backlog
     +- Task                               <-+

Scrum：

  Epic                 <-+
  |                      |- Portfolio Backlog
  +- Feature           <-+
     |
     +- PBI            <- Product backlog  <-+
        |                                    |- Sprint Backlog
        +- Task                            <-+

敏捷：

  Epic                 <-+
  |                      |- Portfolio Backlog
  +- Feature           <-+
     |
     +- User Story     <- Product backlog  <-+
        |                                    |- Sprint Backlog
        +- Task                            <-+

CMMI：

  Epic                 <-+
  |                      |- Portfolio Backlog
  +- Feature           <-+
     |
     +- Requirement    <- Product backlog  <-+
        |                                    |- Sprint Backlog
        +- Task                            <-+

Bug 工作项可以与 PBI/用户故事/需求/问题处于同一级别，也可以在任务级别。这可以在

一般来说，您会在投资组合级别计划非常大的想法，但请确保将这些想法细化到 PBI/用户故事/需求/问题的级别。这些是我们在 Scrum 中称为 Product Backlog 的有序（我不喜欢优先这个词）列表。

然后在 sprint 级别选择一个或多个 PBI/用户故事/需求/问题，将它们分配给 Sprint 迭代，并可选择将它们分解为任务。我倾向于不再使用任务板，而是依赖产品待办事项级别的板视图。

Azure DevOps 中不存在“发布”的逻辑概念。您可以选择创建子迭代来添加概念，但那是您自己的解释。您还可以在工作项上使用标签来表示版本，或者将自定义字段添加到任何工作项以指示目标版本。您甚至可以添加一个自定义工作项类型，您可以将其称为“发布”，并将其他工作项关联到它。

Azure DevOps 中的“发布”中心代表了增量（生成的工件）向最终用户提供的技术流程。Azure DevOps 假定您想要进行某种形式的持续集成和发布。当您这样做时，“发布”的概念变得更具技术性，并且在计划方面不再有意义。

当您沿着定制路线走下去时，您会很快发现 Azure DevOps 的可配置性有多大，但您必须为您的用户提供您自己的流程指南。可以通过许多不同的方式添加概念，每种方式都有其优点或缺点。

看：

推荐阅读