作為敏捷軟件開發的綱領性文件，《敏捷宣言》全文有著緊密的內在聯系，全文都很重要。不過但凡幾句話放在一起，對于特定的環境、特定的讀者，總有個優先級可排。對于中國軟件業大多數企業、大多數從業者，《敏捷宣言》里哪一句是最重要、最需要認真對待的？

我看到有些搞敏捷的同行弄得很玄虛，說《敏捷宣言》不止是中間的這四句，一定要把上下那幾句話也拉上一起看。我覺得吧，這話雖然形式邏輯上沒什么錯，但是呢，這本來就是一個宣言性質的文本，作者非?？桃獾匕堰@四句話工工整整擺在正中間，重點在哪里、強調什么，是很明顯的事。非要說“不能只看中間四句話”，這個說好聽點叫眉毛胡子一把抓分不清主次，說難聽點就叫裝x，不值得提倡。

那么中間四句話里面，對于中國的同行，哪一句更重要呢？我認為，在討論軟件開發方法的時候，首先得把軟件順利地開發出來，而這件看起來很基本的事，對于國內很多同行來說都還有很多挑戰。所以我的觀點，在中國這個行業普遍水平上，應該首先關注《敏捷宣言》的第二句：

可工作的軟件 重于 面面俱到的文檔

因為當你真正開始關注“可工作的軟件”，你才能真正理解，敏捷的若干實踐，為什么是今天這個樣，應該關注什么要點。比如說，需求應該怎么拆解？站在“可工作的軟件”這個角度，答案就會很清晰：不能按照“誰來開發”拆，應該按照“給用戶提供什么價值”來拆。因為只有用戶能用、能創造價值的功能，才是“可工作的軟件”。于是很自然地，一個單體Web應用上硬拆出什么前端需求后端需求，甚至恨不得還拆出個數據庫需求，這就是反敏捷的瞎搞。正確的需求拆解方法，一定是“縱切蛋糕”，每一個需求單元拆得再小，也是能夠獨立發布、獨立創造價值的。

既然需求單元長成這樣了，項目管理應該關注什么要點？從“可工作的軟件”的角度出發，項目管理要管的就一定是如何把小塊的需求流動起來，盡快、盡可能頻繁地把小塊需求交付給用戶去使用，因為這才是每周、每天的工作真正體現為“可工作的軟件”。把軟件開發的各個階段（分析、設計、開發、測試）拆開一段做完再做下一段，天天盯著人員工作量是否飽滿，放在“可工作的軟件”這個視角下一看就是很明顯的錯誤做法。正如我經常問的那個問題：當“項目進度60%”的時候如果馬上把項目停下，你能得到什么？是已經具備60%功能、能夠實現60%用戶價值的可工作的軟件嗎？還是只有一堆文檔沒有任何軟件可用？這個問題，就是《敏捷宣言》第二句最直觀的表現形式。

既然項目是以這種方式運作，軟件的變更應該如何進行？很明顯，你就不能指望一塊代碼寫完測好以后就再也不去動它。你就得接受這個現實：功能是一點一點加上去的，代碼是不斷反復修改的，并且任何人都有可能修改任何一塊代碼——如果沒有“集體代碼所有制”，如果劃分代碼責任田，每人負責一塊代碼，那么需求的“縱切蛋糕”就會變成一句廢話，并且項目管理也無法開展，因為整個項目的進展無可避免地就會綁死在最瓶頸的那塊代碼、那個人。

既然已經確定代碼要反復修改、大家都能改，那么軟件的質量要如何保障？答案是清晰且唯一的：不可能靠人肉回歸測試來保障質量，必須依賴全面、可靠、快速的自動化測試來構建軟件質量的安全網。測試部的小姑娘可以忍受每兩周做一次人肉回歸測試，但是再縮短周期就是人類極限了。（這也解釋了為什么國內大多數敏捷團隊最多能做到每兩周一次發布，無法再縮短發布周期。）只有基于全面、可靠、快速的自動化測試開展持續集成，才有可能保證被反復修改的軟件一直處于可工作的狀態。并且也只有具備了全面、可靠、快速的自動化測試，程序員才有勇氣不斷重構代碼，保障軟件的內部質量處于良好的、允許反復修改的狀態。

如上所述，只要抓住了《敏捷宣言》的第二句，對于需求管理、項目管理、配置管理、質量保證這4項軟件開發的基礎能力，應該怎么做都是一目了然的。敏捷有沒有做對，只要拿“可工作的軟件”為準繩來量一下，基本上是清清楚楚的。應該怎么去改進，答案也是明明白白的。當然了，難免有一些人、一些組織，總想繞著圈子走，不去碰那些最核心、最根本的能力問題。這些人和組織繞了半天圈子以后，你會發現，哎，他們真的就得到了一堆面面俱到的文檔，而“可工作的軟件”，還是老樣子。這就叫求仁得仁。