问题描述
作为一个软件公司的产品负责人，我负责的项目使用Azure DevOps来管理我们的需求。团队由3名开发人员和我作为产品负责人/兼职开发人员组成。默认情况下，Azure DevOps为Bug和Product Backlog Items提供以下状态值：New、Approved、Committed、Done。对于我作为产品负责人来说，这些状态值不足以跟踪需求/需求项的整个生命周期，因为我缺少以下概述：
– 客户尚未批准的报价
– 已发布到集成环境但尚未获得批准的需求/需求项/bug
– 已获得批准的需求/需求项/bug
– 已发布到生产环境的需求/需求项/bug
简而言之，Azure DevOps中的状态值只覆盖了需求项生命周期的一部分。我阅读了一些关于如何解决这个问题的方法，例如：
– 引入额外的状态值（有人劝阻我选择这个选项）
– 使用标签
– 使用区域路径
– 使用自定义字段
我强烈认为我不是唯一面临这个问题的人。根据您的经验，您会推荐什么解决方案？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在Azure DevOps中，可以通过添加额外的工作项状态来跟踪需求的整个生命周期。以下是一种可能的状态流程：
1. New: 需求刚加入需求池，需要进一步定义。
2. Design/Analysis: 需求的业务和技术需求得到明确。Bug得到调查。团队进行需求梳理会议。客户需要批准。
3. Estimated: 团队提供了足够的估算以开始工作。
4. Ready: 客户批准了范围和估算，并可以根据团队的方便开始工作。
5. Active: 团队正在积极开发或测试需求。
6. QA Complete: QA团队根据验收标准验证了工作项。
7. In User Acceptance Testing: 客户可以开始使用新功能。
8. Approved for Release: 客户希望进行生产部署。
9. Released: 团队已部署并客户确认已发布。
可以根据团队的工作流程为这些状态命名。可以根据需要自定义这些状态的名称。在Azure DevOps的需求池中，可以通过配置看板来添加列以表示这些状态。Azure DevOps会跟踪这些列的分配情况，并在工作项历史记录中记录。因此，请为这些列提供有意义的名称和描述。
方案2
Azure DevOps中似乎缺少客户批准的功能。IBM的Rational Team Concert为其工作项提供了一个“批准”功能，这很好。对于Azure DevOps，可以通过配置需求池的看板来添加列以表示这些批准。Azure DevOps会跟踪这些列的分配情况，并在工作项历史记录中记录。因此，请为这些列提供有意义的名称和描述。
如果工作项状态、看板列和任务工作项无法捕捉您的流程的细微差别，您可以使用标签和工作项查询来捕捉其他非标准或特殊情况。
综上所述：
– 添加工作项状态以捕捉需求生命周期的主要阶段。
– 配置需求池的看板以添加超出工作项状态所能表示的列。
– 在进行诸如模型、UML图或其他设计文档的工作时，考虑在相关需求下添加任务工作项。
– 对于其他非标准或特殊情况，可以使用标签和工作项查询。
以上是一些解决方案，您可以根据团队的需求和工作流程选择适合您的方法。