我们已经明确了敏捷的价值，接下来我们应该将它们实际应用到项目管理中。

• 简单化： “一切都应该尽可能简单，而不是更简单。” [1] 这似乎是显而易见的，但往往很多时候我们发现自己在努力增加更多的产品功能。项目经理必须有勇气去拒绝那些没有在需求中明确提到的任务或交付件。

• 拥抱变更： 变更总是不可避免的，拥抱变更也是敏捷开发项目的一部分。许多因素会导致项目的变更。项目干系人对需求的理解可能会随着软件的研发和演示产生变更，或者根据市场调整做出必要的改变。非常重要的一点是，项目经理必须时刻做好准备并拥抱敏捷项目各种千变万化的情况。

• 为下一阶段做好准备： 如果软件交付无法随着时间持续保持交付可靠性，交付工作仍可能会被认为是失败的。引述Alistair Cockburn的话，“当你在玩软件开发这个游戏时，你的另一个目标应该是安装下一个要玩的游戏”. [2] 这种“下一个游戏”可以指代任何事物，可以是一个重大版本的发布工作，也可以是对当前版本中某个操作的简化工作。

• 增量开发：传统型的项目经理往往期望在项目最开始的时候就获得所有内容。这也是为什么传统型项目往往有冗长的需求阶段，在此期间，项目经理会徒劳地尝试创建一个全方位的，完善的项目计划。而使用敏捷过程，我们可以从项目的一小部分先开始，或者首先开发一个大的框架模型，然后根据项目干系人的反馈，逐步增量开发。

• 价值最大化：也许这是一种断言，但仍然应该去实现。当项目干系人将资源投入到项目中，他们当然希望能够实现价值最大化。项目经理应当确保及时交付，并实现交付价值最大化。

• 目标交付件：在生成交付件时，项目经理应当检查：

• 1. 交付件包含了项目干系人期望的价值
• 2. 能够识别交付件的交付对象及创建缘由
• 3. 能够识别交付件的交付目的和目标人员

以下原则同样适用于对现有交付件的变更。

• 报表： 不同人员想要看到的信息也会不同。项目经理应当为特定人员，提供有针对性地报表。这些数据范围可以来源于甘特图，燃尽图，和完成速率报表等。

• 反馈延时最小化： 当交付件完成后，项目经理会希望尽量减少从项目干系人方面的反馈延时。通过与项目干系人密切合作，分析并理解客户的需求，这样才能构造并规划众多的反馈意见。

• 切记，可执行软件的交付是首要目标 ： 同样，这似乎是显而易见的，但我们仍要强调说明。我们的首要目标是将可执行的软件交付给项目干系人。交付时没有多余的文档，模型或者其他交付件。任何其他不能直接为交付工作带来贡献的活动都应当被仔细检查。

• 考虑可维护性： 每个交付件将来都需要进行必要的维护。维护中伴随的维护代价风险，必须和交付件本身的价值保持平衡。

·         [1] Albert Einstein, US (German-born) physicist (1879-1955)

·         [2] http://crystALMethodologies.org