對比敏捷方法與工程方法之間的差異，能幫助我們更好地理解【敏捷開發】：

敏捷型方法是“面向人的”而非“面向過程的”。
工程型方法的目標是定義一個過程，不管什么人使用這個過程，都能得到大致相同的結果；而敏捷型方法則認為，沒有任何過程能代替開發組的技能，過程所起的作用是對開發組的工作提供支持。

作為雪鳥會議最重要的產物，“敏捷軟件開發宣言”（Manifesto for Agile Software Development，常被稱為“敏捷宣言”）從一開始就建立在對比的基礎上。

讓我們追根溯源，從源頭理解【敏捷開發】

敏捷宣言的全文如下：

顯然，這里的四個“高于”，以及“更好的軟件開發方法”，對比的參照物都是傳統的軟件工程方法。

敏捷在中國傳播的過程中，第二組對比“工作的軟件高于詳盡的文檔”效果最直觀，也最容易被接納。

很多企業長期苦于軟件質量不佳、交付進度無法保障、客戶需求把握不準等問題，而傳統的軟件工程方法要求的文檔對于這些問題幫助往往并不明顯。

然而一旦在項目進展過程中能獲得可工作的軟件，尤其是，如果用可工作的軟件向客戶征求反饋，那么客戶改變或增加需求的可能性就會不可避免地提高。

客戶經常自己并不完全清楚軟件應該具備什么功能以及應該如何運作。當他們看到并試用真實的軟件時，模糊的想法會變得更加清晰，新的想法會被催生出來，他們就會要求改變或增加需求。

這些變化對于軟件本身是好事，但對于開發軟件的企業則未必，因為變化幾乎必然會帶來工作量的增加。

敏捷宣言的起草者們清晰地認識到了這個問題，他們倡導的價值觀是避免以甲方乙方的姿態摳合同細節和糾結于復雜的變更管理流程，建立包含技術和業務的一體團隊，超越單個項目、單個合同的極限，在長期的合作中建立共贏關系。這就是“客戶合作高于合同談判”的含義。

同時，開發軟件的團隊自身需要構建的能力也有所不同。傳統軟件工程以嚴格遵循預定計劃為目標，由此延伸出了一整套能力、實踐和工具。一旦認識到需求的變化是常態而非異常，計劃的頻繁調整也就不可避免，此時傳統軟件工程的能力、實踐和工具反而可能成為阻礙。

以項目管理中常用的工具甘特圖為例，其中的計劃排期做得越細密，需求變化時調整起來就會越麻煩。因此，如果軟件團隊希望在可工作的軟件基礎上與客戶建立合作而非談判的關系，就必須具備快速調整響應變化的能力。敏捷宣言的第四組對比“響應變化高于遵循計劃”，很大程度上是對軟件團隊的能力要求。

在敏捷宣言的起草者們看來，這種響應變化的能力固然可以借助合適的流程和工具有所加強，但最重要的還是一線軟件開發者自身的能力和意愿。團隊的能力最終取決于團隊中每個人的能力以及人與人之間豐富而微妙的互動，流程和工具只能輔助，無法替代優秀的個人與默契的團隊。

“個體和互動高于流程和工具”這一組價值觀對比或許是敏捷宣言中最不直觀、最難理解的一組，卻也是敏捷的倡導者們認同最深、時時念茲在茲的一組。

內容摘自《敏捷中國史話》，作者 @熊節

《敏捷中國史話》用生動、翔實的語言，輔以情景描述，循序漸進地講解了敏捷軟件開發在中國的發展歷程。從敏捷的發展背景，到世紀之交的中國軟件業的發展狀況、敏捷的傳入、敏捷的低谷以及敏捷實踐者為敏捷發展所做的艱苦奮斗，還介紹了敏捷在通信行業和互聯網企業的實施狀況、敏捷軟件開發的發展和Scrum的流行。

本書既適合廣大的敏捷方法的愛好者閱讀，也適合對軟件開發方法發展歷程和對中國敏捷技術普及歷史感興趣的人員閱讀。