為何Google這類巨頭會認為敏捷開發原則是廢話？

敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在過去8年裡，我一直工作於“Agile”開發小組，所以讓我用敏捷開發原則來告訴你事實，或許你會明白為什麼那些在像Google這樣巨頭公司工作的開發者會認為敏捷開發是廢話。

（題圖來自：academyone.com）

1.及早並持續的交付有價值軟體來滿足客戶需求的優先順序是最高的。

“我的客戶一直由其他業務部門接洽，我從未見過我的客戶，我不知道他們是做什麼的。”這是現如今大多數公司的真實寫照。

2.歡迎需求變更，即便是在開發的後期。為了客戶的競爭優勢。

沒有人願意接受改變需求。這就是第二個敏捷原則，普遍被厭惡的一個。

3.頻繁交付軟體，傾向於較短時間跨度。

部分公司在這方面做的很好，但是大多數團隊無法很好的掌控敏捷時間的尺度。交付時間表通常是基於大的更新，而大更新不屬於敏捷。

4.業務人員與開發者的繫結模式一直貫穿專案始末。

開發者和業務人員一起工作是罕見的，大多數公司都會有一箇中間人來促進這種關係，然後效果是不理想的。開發者需要直接對話的應該是直接使用程式的人，而不是他們的經理。現實生活中的需求往往是由幾個個層次以外的人來決定，而不是直接從使用者到開發者那來的。

5.激發個體的鬥志，以他們為核心建立專案——大多數人都不知道這表達了什麼。

這意味著低水平的員工對軟體有最好的注意，並且他們積極的去解決問題。專案圍繞這些慾望來構造，而這也了直接影響公司的底線。

5a.為他們提供所需的環境和支援，輔以信任，從而達成目標。

這是關於開發者的，你曾經有過這樣的工作環境嗎？你所需要的工具、訪問許可權和配件都有。或許不用多說什麼了，不是嗎？

6.不論團隊內外，傳遞資訊效果最好、效率也最高的方式是面對面交談。

這句話的意思是告訴我不能用IM和郵件來交流嗎？如果團隊的成員分散於各地呢？我改進現有軟體的最有效方法是站在某人後面看他使用。然而在大多數公司中，你做不到這樣，即便你知道客戶是誰。他們也是忙的無暇顧你，也有可能是其他原因。現如今的人際交往不再像從前那樣。不是嗎？

7.可工作的軟體是進度的首要度量標準。

我們所在測量的都是類似於缺陷率、工作時間等事情，幾乎從來沒測量過這些事項：顧客得到可工作的功能了嗎？我們釋出了多少個可工作的功能？這些功能是大、中還是小的？沒人知道。

8.敏捷過程倡導可持續開發。負責人、開發者和使用者要能夠共同維持其步調穩定延續。

這意味著每個人每週都要花30個小時在開發上，還需要花10個小時管理自己和工作負載、與他人溝通等等。這樣才能保證這種做法持續下去。更多公司所做的是不定時的加班，有的則是經常加班。這是不可持續的。敏捷模式很少進入這樣的緊急模式，而你則是經常性的。

9.堅持不懈的追求技術卓越和良好設計，增強敏捷能力。

在我看來這是對原則1和7的正確權衡。

10.以簡潔為本，極力減少不必要的工作量。

坦白來講，大多數團隊並沒在這上面花費足夠多的時間，我們最終不僅複雜了軟體，也複雜了開發習慣、複雜了程式碼，這減緩了維護和新開發。

11.最好的架構、需求和設計出自自組織的團隊。

團隊是由管理層組織的，幾乎沒有他們自己的事。不過這只是一個企業文化的問題，並很難被克服。有時在初創公司和小公司你可以發揚這種原則並讓其工作，但是在大多數大公司，還是算了吧。

12.團隊定期地反思如何能提高成效，並以此調整自身的舉止表現。

這更多地算是一種常見的績效考核形式，沒有我們真正想要的層面。敏捷想要的是“作為一個團隊，一起坐下來看看我們做了什麼，如何在下一次做的更好”。然而實際上所發生的是個人主觀上的計算和測量，基於這些團隊幾乎得不到任何實際的改進。

所以說敏捷是廢話，因為沒有人會推崇這些原則來工作，不過他們仍然在說其所做的是敏捷，這是非常讓人沮喪的。

敏捷方法存在很多廢話，但是同樣的廢話也會存在於新的軟體開發中，從物件導向到面向服務的體系結構等等。一個真正的敏捷方法不適用於緊急狀況，更多的是為了產品創新。如果作為準備，他可以改變整個組織，Salesforce從2007年就開始使用Scrum，這使它們能夠建立一個可預測的釋出週期。並因此而建立越來越多令人印象深刻的功能和產品。

需要明確的是，敏捷方法不是良方，有能力的人、勤奮、專注和自律造就優秀的軟體開發。