我們已經明確了敏捷的價值，接下來我們應該將它們實際應用到項目管理中。

• 簡單化： “一切都應該盡可能簡單，而不是更簡單。” [1] 這似乎是顯而易見的，但往往很多時候我們發現自己在努力增加更多的產品功能。項目經理必須有勇氣去拒絕那些沒有在需求中明確提到的任務或交付件。

• 擁抱變更： 變更總是不可避免的，擁抱變更也是敏捷開發項目的一部分。許多因素會導致項目的變更。項目干系人對需求的理解可能會隨著軟件的研發和演示產生變更，或者根據市場調整做出必要的改變。非常重要的一點是，項目經理必須時刻做好準備并擁抱敏捷項目各種千變萬化的情況。

• 為下一階段做好準備： 如果軟件交付無法隨著時間持續保持交付可靠性，交付工作仍可能會被認為是失敗的。引述Alistair Cockburn的話，“當你在玩軟件開發這個游戲時，你的另一個目標應該是安裝下一個要玩的游戲”. [2] 這種“下一個游戲”可以指代任何事物，可以是一個重大版本的發布工作，也可以是對當前版本中某個操作的簡化工作。

• 增量開發：傳統型的項目經理往往期望在項目最開始的時候就獲得所有內容。這也是為什么傳統型項目往往有冗長的需求階段，在此期間，項目經理會徒勞地嘗試創建一個全方位的，完善的項目計劃。而使用敏捷過程，我們可以從項目的一小部分先開始，或者首先開發一個大的框架模型，然后根據項目干系人的反饋，逐步增量開發。

• 價值最大化：也許這是一種斷言，但仍然應該去實現。當項目干系人將資源投入到項目中，他們當然希望能夠實現價值最大化。項目經理應當確保及時交付，并實現交付價值最大化。

• 目標交付件：在生成交付件時，項目經理應當檢查：

• 1. 交付件包含了項目干系人期望的價值
• 2. 能夠識別交付件的交付對象及創建緣由
• 3. 能夠識別交付件的交付目的和目標人員

以下原則同樣適用于對現有交付件的變更。

• 報表： 不同人員想要看到的信息也會不同。項目經理應當為特定人員，提供有針對性地報表。這些數據范圍可以來源于甘特圖，燃盡圖，和完成速率報表等。

• 反饋延時最小化： 當交付件完成后，項目經理會希望盡量減少從項目干系人方面的反饋延時。通過與項目干系人密切合作，分析并理解客戶的需求，這樣才能構造并規劃眾多的反饋意見。

• 切記，可執行軟件的交付是首要目標 ： 同樣，這似乎是顯而易見的，但我們仍要強調說明。我們的首要目標是將可執行的軟件交付給項目干系人。交付時沒有多余的文檔，模型或者其他交付件。任何其他不能直接為交付工作帶來貢獻的活動都應當被仔細檢查。

• 考慮可維護性： 每個交付件將來都需要進行必要的維護。維護中伴隨的維護代價風險，必須和交付件本身的價值保持平衡。

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

·         [2] http://crystALMethodologies.org