项目管理
通过阅读 MSF for CMMI Process Improvement 指南的“项目管理”一节，可以更好地了解如何管理、计划和协调对软件产品的开发和维护。 有关 CMMI 的更多信息，请参见 CMMI 背景信息。
在 CMMI 中，项目管理的过程区域分组包括项目规划、项目监视与控制、供应商协议管理、集成项目管理、风险管理和量化项目管理。 除量化项目管理之外，所有这些分组都是模型级别 2 或 3 的一部分。 量化项目管理是模型级别 4 的活动，它反映了成熟度较高的组织如何使用定量的、统计上防御性的目标数据来做出管理决定，以及如何使用这些数据来控制项目以获得成功的可预测结果。
这些项目管理活动表示花费在增值工程活动上的经济成本。 对于管理风险、协调成功的工程工作以及适当地设置客户期望，这些活动是必需的并且很重要。 不过，应将这些活动所耗费的工作量减到最小。正 所谓“积少成多”，这是我们要记住的。 使用较小的批处理可降低复杂性和协调成本。 在定义和调整过程定义时需要记住，应在满足项目的风险配置文件要求的同时尽可能地减少项目管理活动。
迭代开发
Team Foundation 与 MSF for CMMI 过程模板结合使用可支持迭代工作。 迭代开发通过在整个项目中按照设置的时间间隔交付可演示的且经过测试的软件来管理风险。
.png "后续迭代")
项目时间表按照一系列迭代的形式组织，这些迭代通常为四到六周的时间。 每个迭代结束时都会演示可用的且经过测试的软件。 有关更多信息，请参见创建和修改区域和迭代。
项目计划说明在每次迭代中开发的功能要求。 项目计划是在迭代 0 中制定的，并且在每次迭代开始时都要回顾项目计划。 可以通过几种方式查看项目计划，如通过项目面板。 有关更多信息，请参见要求 (CMMI)和“项目”面板 (CMMI)。
每个迭代计划说明该迭代期间将执行的任务。 大部分任务都是为了满足为该迭代计划的功能要求而需要执行的开发和测试工作。 可以通过进度面板来查看迭代计划。 有关更多信息，请参见任务 (CMMI)和“进度”面板 (CMMI)。
迭代工作不会自动管理风险。 若要将风险降到最低，您必须以增量方式安排项目计划。 早期迭代应提供一个“端到端薄片”，即产品的最重要行为的最简单版本。 然后在后面的迭代中添加更多功能。
相比之下，如果将一个购物网站项目一分为三，分别安排购物网站的所有销售部分、所有仓库系统和所有支付系统，则没有多大用处。 此计划的风险在于：虽然构建了一个吸引人的功能全面的销售网站，但这个网站没有办法为企业从客户那里赚钱。 此计划没有采用增量方式迭代。
增量开发具有以下优点：
满足实际要求。 利益干系人有机会试用产品，从而总是能够改进他们提出的要求。
调整体系结构。 允许开发团队发现并解决其平台上出现的任何难题或针对其设计的潜在改进。
确保结果。 利益干系人清楚，即使项目资源中途撤离，前面的开销也没有白费。 这同样适用因发现开发估算过于乐观而必须舍弃不太重要的功能的情况。
有关如何按照适当的格式表示增量开发的要求的更多信息，请参见制定要求。
较长周期和较短周期
项目和迭代不是软件开发的唯一循环部分。 例如，在一个迭代中，团队成员启动并完成任务，然后签入代码。 生成系统连续生成或在夜间生成产品。 团队每天对迭代任务的进度进行简单检查。
.png "签入、每日生成、迭代、项目、程序")
大型项目
需要团队执行一系列迭代的项目可能是某个大型项目或程序的一部分。 一个大型项目会有几个团队并行开展工作。 通常，每个团队包含 4 到 16 个成员。
为每个团队打开一个单独的版本控制分支。 每当迭代结束时，每个团队应与主分支集成。 有关更多信息，请参见分支和合并。
保留主分支以供集成和测试。 生成计算机应在集成后执行一套完整的测试。
为每个团队指派一个区域，以便能够轻松地将其工作项与其他团队的工作项分开。 有关更多信息，请参见创建和修改区域和迭代。
团队可以共享一系列集成，但并不总是需要这样做。 如果这些团队未同步集成，则每个团队的迭代名称必须有自己的前缀。
本节内容
项目周期：启动项目、收集要求、制定项目计划、将项目计划分成多个迭代以及交付发布。 管理风险并管理对计划所做的更改。 |
|
迭代周期：检查和更新要求、计划用于实现要求的任务以及管理发生的问题。 |