在 Azure Boards 中管理项目活动
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018
若要充分利用 MSF 进行 CMMI 过程改进，应将项目组织成一系列迭代，通常长达 4 到 8 周。 此组织可帮助你降低项目的风险，这些风险源于转移要求和实施成本。 迭代项目结构是满足 CMMI 风险管理要求的重要贡献。
项目开始时
项目启动
启动包括定义项目愿景，其中说明用户在项目发布产品时可以执行的操作。
它还包括设置团队、基础结构和其他资源并确定开发过程。
有关详细信息，请参阅 Project 启动。
初始项目规划
项目规划包括以下活动：
详细分析要求，使你能够形成计划。 此分析可能包括使用要求模型、情节提要和其他工具来帮助设想工作系统。
设计系统的总体设计或体系结构。 如果此设计涉及在团队成员不熟悉的平台上工作，则必须有一段时间才能进行试验。 在前面的迭代中，开发速度会很慢。
将要求强制转换为可以估计其开发的一组增量产品要求。 一般要求与产品要求之间的差异非常重要，此活动非常重要。 有关详细信息，请参阅 开发要求。
对迭代进行产品要求的初始分配。
设置发布日期。
计划模型和要求模型将在整个项目中重新审视和优化。 迭代开发的一部分是允许改进早期演示工作软件的要求。
初始项目规划是在迭代 0 中完成的。
有关详细信息，请参阅 “规划项目”。
探索现有产品
项目的目标是更新已存在的产品。 在这种情况下，如果团队不熟悉该产品，则浏览代码是迭代 0 的活动。 后续迭代中的每个开发任务还将涉及了解特定区域的代码并跟踪更改代码的后果。
有关详细信息，请参阅可视化代码。
项目期间
该计划经过审查，并在整个项目中更改。
与项目计划相关的多个活动在项目中定期完成，通常在迭代结束时完成。
验证
向客户或业务利益干系人演示在迭代过程中开发的软件。 如果可行，请将其发布到它们，以便他们可以对其进行试验，或在实际上下文中将其用于某个程度。
在足够间隔后，安排会议以查看用户反馈。 反馈应用于生成更改请求。
风险管理
查看潜在不良事件的概率和影响，并采取措施降低风险。 有关详细信息，请参阅 “管理风险”。
更改管理
可以使用更改请求工作项来记录业务利益干系人所说明的要求中的更改。 它们可能源于业务上下文的变化，也源于产品的早期版本的演示和试用。 应欢迎这些更改，因为它们提高了产品对其业务目的的适用性。 此效果是增量开发目标的一部分。
某些项目团队在请求更改时调整产品要求工作项，而无需使用单独的工作项。 但更改请求工作项的优点是，在项目的后面部分，可以查看所做的更改的数量和性质。 可以使用该信息来改进未来的流程或体系结构。
更改请求应用作产品计划评审的输入。
有关详细信息，请参阅 管理更改。
产品计划评审
在计划每次迭代之前保留产品计划评审。 项目计划将产品要求分配给迭代。
该计划将因以下两个主要原因而更改：
要求的变化。
开发人员做出的估计更改。 随着项目的进展，开发团队可以更可靠地估计实现未来功能所需的工作。 在某些情况下，某些功能可能已推迟到以前的迭代中，这会向计划添加一个功能。
在以后的迭代中，这两种类型的更改变得不那么频繁。
修改从中派生产品要求的要求模型。
修改对迭代的要求分配。 与初始规划活动一样，业务利益干系人提供优先级、开发团队提供估计值，会议与迭代之间的功能杂乱无章。
有关详细信息，请参阅 “规划项目”。
产品主要发行版之前
部署产品所涉及的活动因产品类型而异，此处不处理。
在软件开发的后续迭代方面，请考虑以下几点：
排除对设计的重大更改，以避免出现意外的问题。
引发会审会议中的更改和 bug 的条形图。 建议的更改和 bug 修复应被拒绝，除非它们对产品的可用性和适用性产生重大影响。
投入资源来增加测试覆盖范围并执行手动测试。