在 Azure Boards 中使用功能成熟度模型集成 (CMMI) 过程规划项目
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018
规划项目的预期结果是一个计划，包括范围、计划、预算、风险管理计划和所有利益干系人的承诺和批准。 通过商定的项目计划，你需要通过分析、设计、开发、测试和最终交付进行。
可以使用迭代开发方法来降低风险。 迭代使你可以在每次迭代结束时演示一个部分工作的产品，并处理来自该演示的反馈。 因此，该计划提供整体形状，并在每次迭代开始时进行评审和优化。
收集和建模要求
此活动涉及与业务利益干系人、潜在用户和主题专家讨论系统应执行的操作。 了解业务上下文非常重要。 如果你被要求为警察编写申请，这有助于了解他们的行话、程序和规则。
UML 模型是一种有用的工具，可用于表达和思考复杂的关系。 可以在Visual Studio中绘制它们，并将其链接到其他文档和 Team Foundation 工作项。 有关详细信息，请参阅用户需求建模。
在整个项目中更新和优化要求模型。 随着每次迭代的临近，请向与该迭代相关的模型的各个方面添加更多详细信息。 从模型中，可以派生验证测试。
创建增量产品要求
从客户收集这些要求并不直接适用于计划增量开发。 例如，若要阐明用户从网站购买内容时的过程，你可能已编写了详细的一系列步骤：客户浏览目录、将项目添加到购物车、签出购物车、供应地址和付款。 然后，仓库计划交付，过程继续。 这些步骤或等效的活动关系图不是增量要求。
相反，系统的第一个增量只能提供一个项目以供销售，只交付给一个地址，并使用付款服务仅运行测试事务。 第二个增量可能提供包含简单列表的目录。 以后的增量可以添加包装购买或请求不同供应商提供的目录的礼品选项。 某些增量可能与服务质量有关，例如处理 1，000 个客户的能力，而不是只处理一个。
换句话说，早期增量应执行端到端的主要用例，并在整个过程中逐步添加功能。
如果处理现有产品，但从现有功能开始，则原则是相同的。 如果你不熟悉其内部设计，则更新成本可能难以估计。 对之前的变化的估计，这值得自由。
有关详细信息，请参阅 开发要求。
输入和编辑产品要求
将增量产品要求记录为 Team Foundation 中的要求工作项，并将要求类型设置为功能。 可以使用 Web 门户或团队资源管理器创建 积压要求 。 如果要同时创建多个工作项，可以使用Excel。
估计产品要求
开发团队应估计开发每个产品要求所需的工作。 应在工作项的“原始估计”字段中以小时为单位输入估计值。
在项目中的早期，需要一个粗略的估计值。
将大型产品要求分解为较小的产品。 理想情况下，每个产品要求只需要几天的开发时间。
将产品要求分配给迭代
业务利益干系人和开发团队的代表应共同努力，为迭代分配产品要求。 通常，在会议中分配要求，在其中共享或投影产品要求查询的Office Excel视图。
工作分配是使用以下信息片段完成的：
要求优先级。 请参阅以下小节中的说明。
估计成本。 给定团队成员的数量和迭代的长度，每个迭代仅具有可用于开发的固定小时数。 此外，大量这些小时将用于迭代规划和不直接涉及开发的其他任务。
产品要求之间的依赖关系。 在一系列增量要求中，必须先处理最简单的要求，然后才能在同一区域中进行增强。
可以通过指定各种信息来定义工作项中的要求，如下图所示：
有关优先顺序的一些准则
许多详细方案用于优先顺序。 在考虑迭代规划时，我们将检查其中一些方案。 目前，在项目级别，我们提供了一些指南，这些准则可能有助于管理风险并优化附加值。
确定最低端到端方案的优先级。
旨在尽可能早地在项目中实现端到端方案。 稍后，向方案的不同部分添加更多功能。 这种做法可确保提前尝试平台的主要功能以及要求中的主要理念。
相比之下，不要根据体系结构划分计划。 完成数据库的计划，然后是业务逻辑，然后用户界面可能需要大量返工才能在最后集成部件。 同样，不建议水平拆分，例如 {sales component、 warehouse component， payment component} 。 它可能会产生一个美妙的系统在网上销售，但运行时间不足之前，企业有一种从客户那里获得资金的手段。 仅当完整组件是真正的可选加载项时，才能计划后续迭代。
确定技术风险的优先级。
提前制定技术风险元素。 采取“提前失败”方法来承担风险。 如果无法完成某些操作，你希望在项目中早期知道此风险，以便可以取消或替换为替代方法。 因此，将技术风险要求优先于早期迭代。
确定不确定性的优先级。
业务利益干系人不确定某些要求。 很难预测哪些产品行为在业务环境中效果最佳。 确定可能降低不确定性的工作的优先级。 通常可以通过开发更简单版本的方案来实现这种风险降低，用户可以使用该版本进行试验。 将完整方案推迟到以后的迭代，在这些迭代中可以考虑这些试验的结果。
确定高价值要求优先级。
如果可能，请尝试为每个方案建立机会延迟函数。 使用这些函数来确定可能更早为客户带来更多价值的要求。 将这些要求确定为早期迭代的优先级。 此优先顺序可能会购买提前发布部分产品的选项
多个角色通用的组方案。
如果方案具有两个或多个角色的实用工具，可将这些方案组合在一起。 按需要方案的人员数对它们进行排名。 将应用于更多角色的方案确定为早期迭代的优先级。
排名角色。
角色表示市场细分市场或用户组。 营销人员或业务所有者可以根据要交付的实用工具或细分市场的价值来表达此类细分或组的优先级。 如果细分或用户组可以按优先级排名，则通过按排名列出每个细分段的角色来显示此排名。 确定排名最高的角色的方案，并将这些方案确定为计划中的早期迭代的优先级。
一般情况下，由于故障的可能性，优先降低风险。 设置常见功能的优先级，因为它可能需要且不太可能更改。 我们希望确定更有价值的要求。 我们希望通过优先考虑满足任何角色需求所需的所有方案，使产品早期发布到角色子集的选项。
计划测试
每个要求的工作估算必须包括手动测试要求或创建自动化测试所需的工作量。
在考虑完成之前，每个产品要求都必须链接到一组测试用例工作项，这些工作项共同演示了该要求是否已满足，并且测试必须通过。
创建或修改产品要求时，必须更新相应的测试计划。
修订产品要求
在每次迭代之前重新访问此活动，以考虑修订的新要求、修订的优先级和修订的估计值。 前几次迭代中将有更多修订。
在前几次迭代之后，开发团队的成员将更有信心估计。 它们应浏览下一次或两次迭代的估计值，并修改分配给这些迭代的要求的原始估计字段。