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

Question

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

Sprint 将优先列出以下内容:选项:项目/发布/子冲刺/工作项目

Answer 1

计划层次结构取决于您为项目选择的流程。

基本:

  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 中称为“产品待办事项列表”。

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

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

Azure DevOps 中的“发布”中心代表增量(生成的工件)提供给最终用户所需的技术流程。 Azure DevOps 假设您想要进行某种形式的持续集成和发布。当您这样做时，“发布”的概念变得更加技术性，并且在规划方面不再有多大意义。

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

参见:

• Basic Workflow
• Scrum Process Workflow
• Agile Process Workflow
• CMMI Process Workflow
• Show bugs on backlogs and boards