规划项目 (CMMI)
规划项目的预期结果是：制定一份包括范围、时间表、预算、风险管理计划，以及所有利益干系人的承诺和审批的计划。 就项目计划达成一致之后，您需要经历分析、设计、开发、测试和最终交付过程。
采用迭代开发方法可以减少风险。 通过迭代，您能够在每次迭代结束时演示完成了一部分的产品，并根据演示时收集的反馈行事。 因此，该计划勾画了整体蓝图，并且可以在每次迭代开始之前进行评审和完善。
主题内容
收集要求并对要求进行建模
创建渐进式产品要求
输入和编辑产品要求
估计产品要求
指派迭代的产品要求
规划测试
修改产品要求
收集要求并对要求进行建模
此活动是与业务利益干系人、潜在用户和行业专家讨论系统功用的过程。 了解业务环境非常重要。 如果要求您撰写一份警察申请，了解警察专业术语、程序和规则会很有裨益。
UML 模型是用于表示和考虑复杂关系的有用工具。 可以在 Visual Studio 中绘制这些模型，并将其链接到其他文档和 Team Foundation 工作项。 有关更多信息，请参见用户需求建模。
在整个项目中，将对要求模型进行更新和完善。 在每次执行迭代时，向与该迭代相关的模型方面添加更多详细信息。 可以根据模型派生验证测试。
有关更多信息，请参见Developing Customer Requirements和基于模型开发测试。
创建渐进式产品要求
从客户处收集的要求不能直接适用于计划渐进式开发目的。 例如，为了阐明用户网上购物的过程，您可能需要编写一系列详细步骤：客户浏览目录，将商品添加到购物车中，结算购物车中的商品，提供地址并付款；仓库安排交付等。 这些步骤或等效活动图并非是渐进式要求。
相反，您的系统的第一个渐进式要求可能仅提供一件待售商品，仅交付到一个地址，并且仅进行一次具有支付服务的测试交易。 第二个渐进式要求可能会提供含有一个简单列表的目录。 后续渐进式要求可能会添加对购买的商品进行礼品包装或请求由不同供应商提供的目录的选项。 某些渐进式要求可能与服务质量相关，例如，处理 1,000 名客户（而不是仅限一名客户）的功能。
换言之，早期渐进式要求应执行主要的端对端用例，然后在整个过程中逐步添加功能。
如果您使用的是现有产品，其原则仍然相同，但是您需要从现有功能入手。 如果您对现有产品的内部设计并不熟悉，可能很难估计更新成本。 应大胆估计早期更改的成本。
有关更多信息，请参见制定要求。
输入和编辑产品要求
在 Team Foundation 中将渐进式产品要求记录为要求工作项，并将要求类型设置为“功能”。 在 团队资源管理器可以创建要求工作项。如果您需要同时创建多个工作项，可使用"产品要求"查询的 Office Excel 视图。 有关更多信息，请参见在连接到 Team Foundation Server 的 Microsoft Excel 和 Microsoft Project 中工作和使用工作项的树列表执行自顶向下的规划（在 Excel 中）。
估计产品要求
开发团队应当对开发每个产品要求所需的工作进行估计。 应在工作项的“初始估计”字段中输入估计值（以小时为单位）。
在项目早期阶段，您只需进行粗略估计。
将较大的产品要求划分为多个较小的产品要求。 理想情况下，每个产品要求只需要几天的开发时间。
指派迭代的产品要求
业务利益干系人代表和开发团队应通力协作，以便指派迭代的产品要求。 产品要求往往在会议中进行指派，您可以在会议中共享或展示“产品要求”查询的 Office Excel 视图。
使用以下信息完成指派：
要求优先级。 请参见下一小节中的“说明”。
估计成本。 在给定团队成员数和迭代长度的情况下，每次迭代只能包含固定数目的小时时间来用于开发。 此外，其中的很多时间将用于迭代规划以及其他不与开发直接相关的任务。
产品要求之间的依赖关系。 在一系列渐进式要求中，必须首先处理最简单的要求，然后才能在同一领域进行改进。
您可以通过指定各种信息定义工作项中的要求，如下图所示：
.png "要求工作项窗体")
.gif "Ee461521.collapse_all(zh-cn,VS.110).gif")
有关优先级设置的一些准则
存在许多需要设置优先级的详细方案。 在考虑迭代规划时，我们将查看其中的某些方案。 现在，我们在项目级别纳入了一些有助于管理风险和充分利用附加价值的准则。
优先考虑最简单的端对端方案。
尽可能在项目早期计划实现简单的端对端方案。 然后，为此方案的不同部分添加更多功能。 此做法可确保尽早尝试主要平台功能和主要要求理念。
相比之下，不要根据体系结构划分计划。 先后完成数据库、业务逻辑和用户界面的计划可能需要大量返工才能使各个部分最终融为一体。 同样，不建议进行水平拆分，例如，{销售组件；仓库组件；付款组件}。 水平拆分可能会生成一个卓尔不凡的网上销售系统，但可能没有时间来为企业寻求从客户身上赢取利润的方法。 仅当完整组件实属可选加载项时，才能在后续迭代中计划这些组件。
优先考虑技术风险。
如果方案包括具有技术风险的元素，请在早期计划中开发此元素。 应对风险采取“尽早失败”方法。 如果无法实现某一功能，您需要在项目早期了解这一状况，以便可以取消此功能或用备选方法取而代之。 因此，请在早期迭代中优先考虑具有技术风险的要求。
优先考虑可减少不确定性的因素。
业务利益干系人将无法确定某些要求。 很难预测哪些产品行为在业务环境中的性能最佳。 请优先考虑可能会减少不确定性的工作。 开发可供用户体验且相对较简单的方案版本往往可以实现这一目的。 将完整方案推迟到后续迭代中，可以在后续迭代中考虑上述体验的结果。
优先考虑价值较高的要求。
如有可能，请尝试为每个方案建立“推迟机会成本”功能。 使用这些方法确定可为客户尽早创造更多潜在价值的要求。 请在早期迭代中优先考虑这些要求。 这使您能够选择尽早发布部分产品。
组合多人通用方案。
如果您具有用于两名或多名人员的方案，请将这些方案组合在一起。 按照需要方案的人数对这些方案进行分级。 在早期迭代中优先考虑适用于较多人数的方案。
对人员进行分级。
这些人员代表细分市场或用户群体。 营销人员或企业所有者应能够根据要交付的实用程序或细分市场的价值阐明此类细分市场或群体的优先级。 如果可以按优先级对细分市场或用户群体进行分级，请按级别列出每个细分市场的人员，以此来显示优先级。 确定级别最高的人员所对应的方案，并在计划的早期迭代中优先考虑这些方案。
一般而言，我们需要优先考虑降低风险，因为可能失败。 我们需要优先考虑通用功能，因为我们可能需要此功能，且此功能不大可能会发生更改。 我们需要优先考虑更有价值的要求。 通过优先考虑为满足任意人员的要求所需要的所有方案，我们需要面向部分人员尽早发布产品。
规划测试
对每项要求所估计的工作必须包括对此要求进行测试（通过手动方式或创建自动测试）所需的工作。
在将产品要求视为已完成之前，必须将每项产品要求链接到一组测试用例工作项以便共同表明已符合此要求，并且必须通过这些测试。
当创建或修改产品要求时，必须更新相应测试计划。
修改产品要求
请在每次迭代之前重新访问此活动，以考虑修改后的要求和新要求、修改后的优先级以及修改后的估计值。 前几次迭代中的修改内容将相对较多。
在经过前几次迭代之后，开发团队成员将提高所做估计的信心。 开发团队成员应浏览下一次或下两次迭代的估计，并修改为这些迭代指派的要求的“初始估计”字段。