為何Google這類巨頭會認為敏捷開發原則是廢話？
英文原文：Why do some developers at strong companies like Google consider Agile development to be nonsense?
這是一個來自 Quora 的問題。Rocket 程序員 Jasmine Adamson 在文中表達了敏捷開發原則是廢話的觀點，他覺得現實生活中沒有什么人會推崇這些原則來工作，不過他們仍然在說其所做的是敏捷，這是非常讓人沮喪的。
以下為譯文：
敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在過去 8 年里，我一直工作于“Agile”開發小組，所以讓我用敏捷開發原則來告訴你事實，或許你會明白為什么那些在像 Google 這樣巨頭公司工作的開發者會認為敏捷開發是廢話。
1. 及早并持續的交付有價值軟件來滿足客戶需求的優先級是最高的
“我的客戶一直由其他業務部門接洽，我從未見過我的客戶，我不知道他們是做什么的。”這是現如今大多數公司的真實寫照。
2. 歡迎需求變更，即便是在開發的后期。為了客戶的競爭優勢
沒有人愿意接受改變需求。這就是第二個敏捷原則，普遍被厭惡的一個。
3. 頻繁交付軟件，傾向于較短時間跨度
部分公司在這方面做的很好，但是大多數團隊無法很好的掌控敏捷時間的尺度。交付時間表通常是基于大的更新，而大更新不屬于敏捷。
4. 業務人員與開發者的綁定模式一直貫穿項目始末
開發者和業務人員一起工作是罕見的，大多數公司都會有一個中間人來促進這種關系，然后效果是不理想的。開發者需要直接對話的應該是直接使用程序的人，而不是他們的經理。現實生活中的需求往往是由幾個個層次以外的人來決定，而不是直接從用戶到開發者那來的。
5. 激發個體的斗志，以他們為核心創建項目——大多數人都不知道這表達了什么。
這意味著低水平的員工對軟件有最好的注意，并且他們積極的去解決問題。項目圍繞這些欲望來構造，而這也了直接影響公司的底線。
5a.為他們提供所需的環境和支援，輔以信任，從而達成目標。
這是關于開發者的，你曾經有過這樣的工作環境嗎？你所需要的工具、訪問權限和配件都有。或許不用多說什么了，不是嗎？
6. 不論團隊內外，傳遞信息效果最好、效率也最高的方式是面對面交談。
這句話的意思是告訴我不能用 IM 和郵件來交流嗎？如果團隊的成員分散于各地呢？我改進現有軟件的最有效方法是站在某人后面看他使用。然而在大多數公司中，你做不到這樣，即便你知道客戶是 誰。他們也是忙的無暇顧你，也有可能是其他原因。現如今的人際交往不再像從前那樣。不是嗎？
7. 可工作的軟件是進度的首要度量標準
我們所在測量的都是類似于缺陷率、工作時間等事情，幾乎從來沒測量過這些事項：顧客得到可工作的功能了嗎？我們發布了多少個可工作的功能？這些功能是大、中還是小的？沒人知道。
8. 敏捷過程倡導可持續開發。負責人、開發者和用戶要能夠共同維持其步調穩定延續。
這意味著每個人每周都要花 30 個小時在開發上，還需要花 10 個小時管理自己和工作負載、與他人溝通等等。這樣才能保證這種做法持續下去。更多公司所做的是不定時的加班，有的則是經常加班。這是不可持續的。敏捷模式很少進入這樣的緊急模式，而你則是經常性的。
9. 堅持不懈的追求技術卓越和良好設計，增強敏捷能力。
在我看來這是對原則 1 和 7 的正確權衡。
10. 以簡潔為本，極力減少不必要的工作量
坦白來講，大多數團隊并沒在這上面花費足夠多的時間，我們最終不僅復雜了軟件，也復雜了開發習慣、復雜了代碼，這減緩了維護和新開發。
11. 最好的架構、需求和設計出自自組織的團隊
團隊是由管理層組織的，幾乎沒有他們自己的事。不過這只是一個企業文化的問題，并很難被克服。有時在初創公司和小公司你可以發揚這種原則并讓其工作，但是在大多數大公司，還是算了吧。
12. 團隊定期地反思如何能提高成效，并以此調整自身的舉止表現。
這更多地算是一種常見的績效考核形式，沒有我們真正想要的層面。敏捷想要的是“作為一個團隊，一起坐下來看看我們做了什么，如何在下一次做的更好”。然而實際上所發生的是個人主觀上的計算和測量，基于這些團隊幾乎得不到任何實際的改進。
所以說敏捷是廢話，因為沒有人會推崇這些原則來工作，不過他們仍然在說其所做的是敏捷，這是非常讓人沮喪的。
敏捷方法存在很多廢話，但是同樣的廢話也會存在于新的軟件開發中，從面向對象到面向服務的體系結構等等。一個真正的敏捷方法不適用于緊急狀況， 更多的是為了產品創新。如果作為準備，他可以改變整個組織，Salesforce 從 2007 年就開始使用 Scrum，這使它們能夠創建一個可預測的發布周期。并因此而創建越來越多令人印象深刻的功能和產品。
需要明確的是，敏捷方法不是良方，有能力的人、勤奮、專注和自律造就優秀的軟件開發。