最近幾年，科學技術急速發展。軟件的復雜性和CPU處理速度也呈指數增長，而不是線性上升。這種增長率的變化導致的連鎖反應，增加了市場的波動，這反過來又要求企業能夠快速適應消費者的需求。行動緩慢的龐然大物被普遍認為是缺乏競爭力的，在交付新特性方面也存在更大的風險，這已經是“老生常談”或是過時的問題了。

這也為敏捷開發方法的興起做出了貢獻，例如極限編程（XP），SCRUM，功能驅動開發等。這些方法都力求降低變更成本，并把風險最小化。這些都是通過實踐中的應用來實現的，比如：

• 快速迭代計劃和開發周期，適度權衡并促進最有價值的功能盡快交付。
• 持續性的系統測試，通過在開發過程的早期階段發現并修復產品缺陷，來保障軟件的高質量及穩定性。
• 為參與項目的各個團體引入開放式的溝通渠道，從而保證最終目標一致性。

SCRUM 迭代圖

當然這不同于傳統的管理理論，傳統方法通常：

• 變更必須通過嚴格的審批流程進行監管
• 分級的企業組織結構，是建立規則的最佳方式
• 加強管控力度可以提高質量
• 企業組織結構嚴謹、穩定
• 員工只是企業組織這個“機器”上的一個“齒輪”
• 將問題細分為一個個任務，然后分配資源加以解決
• 項目和風險通過復雜的前期規劃（也常被稱為大需求），基本是可預見的、可管理的

瀑布過程圖

此外，對于那些擁有成熟開發流程的企業組織，往往都是經過較長一段時間的實際經驗積累（成功的或失敗的）建立起來的。

與傳統的管理方法相比，也難怪高管們在實施敏捷方法時會遇到管理不夠正式，混亂，無計劃性等問題 。某些時候，他們甚至會鼓勵工程師們不顧日程安排，按照他們的想法開發來脫離管理。

這是因為大多數敏捷實踐都沒能夠徹底解決軟件項目的管理層面；即人、流程及技術。相反，他們往往更加注重編碼、測試和功能交付等方法上面。

所以，如果我們想要把敏捷的概念應用到軟件項目的管理層面，這也是軟件開發變革自然要經過的一步，我們就必須回答以下問題：

• 當應用于傳統項目管理方法的時候，什么樣的敏捷、精益或簡約的原則是有意義的？
• 如何把這些原則真正應用到項目管理中？
• 當將應用敏捷方法應用于傳統項目管理時，有什么障礙或有哪些常見問題是需要注意的？