本文轉自：http://blog.itpub.net/13770856/viewspace-237874
最近在敏捷中國發起了一場關於瀑布vs敏捷的討論，論者紛紜。雖然爭得熱鬧，但我個人認爲，這樣一個題目對於瀑布模型而言，本身就是不公平的。這樣的一種比較，就好像拿現在的好萊塢大片去與上個世紀六七十年代的電影比電影特效，顯然，現在的中等水平的電影特效，就完全能夠超過《星球大戰》的巔峯水平了。瀑布方式本身就是軟件工程理論還處於草創階段的產物，如何能與糅合了大量實踐與工程理論的敏捷方式相比呢？
我很贊同O6Z的方式，採取追本溯源的方式，先找到各自的源頭，所謂“正本清源”，在瞭解各自產生的背景和目的後，方談得上對這兩者之間的客觀比價。不弄清楚這些，就先爭論誰是誰非，結局只會造成敏捷的粉絲們與反對者兩大陣營的“掐架”了。
說道瀑布模型的來源，O6Z說瀑布模型不是首先被作爲一種正面模型被提出的，而是是作爲一種失敗的模型被提出的，這倒是讓我這個瀑布模型的無知者有些驚詫了。不管正確與否，我們必須承認的一個事實是，瀑布模型在過去的數十年曾經風光無限，按說，存在即是真理，我不認爲能一棍子打死，因爲出現了例如螺旋型、 RUP以及敏捷，就使得瀑布一無是處了，這不是科學的方法。
實際上，O6Z提到的幾點認識非常好的概括了瀑布模型的適用場景。事實必須承認，瀑布模型已經逐漸離開歷史舞臺，但誰都不能否認瀑布模型其實開創了軟件工程的一個時代，科學合理地將軟件開發劃分爲需求、設計、編碼和測試等多個階段，解決了工程化的問題。尤其是目前採用的一些重型開發模式，例如RUP，實際上仍然可以看作是演化版的瀑布模型。
坦白說，我是敏捷方法的支持者，但我始終認爲，無論哪種方法，都沒有絕對的好和絕對的壞，而必須因地制宜，因人而異。瀑布模型由於其過程的不可回溯性，自然決定了它無法應對需求的變化，對軟件開發過程無法及時反饋與修改，或者說對於應對變化的成本較大。然而，如果對於一個團隊，假設團隊成員都是一些順從、忠誠與誠懇地人，他們具有非常強的編碼能力，習慣按照標準與規範作事，但他們卻缺乏天馬行空般的想象能力，以及那種獨立與自組織的意識與能力，那麼你認爲在這樣的團隊推行敏捷還會有好的結果嗎？或許說，這種團隊是否過於假象化了，有這樣的團隊嗎？事實上，這樣的團隊不僅有，而且太多，甚至完全超過了那種敏捷團隊的數量。尤其是在軟件外包領域，那種軟件工廠培養的代碼工人，實際上很難按照敏捷的方式做事。這個時候，採用瀑布模型可能會是比敏捷更好的模式（不過，像這樣的團隊，我更傾向於將快速原型法和RUP結合。）
這就引出我一直在思考的問題，那就是傳統的軟件模型（不僅是瀑布模型，也包括螺旋和RUP），他們的組織架構可以認爲是基於角色化的層次組織架構。在這樣的團隊中，各種角色各司其職，處理技術與管理的任務，例如PM、SA、BC、SE、CM、QA等。這樣的團隊更像是一臺機器，各個零部件能夠有條不紊的協作，他們共同遵守一些標準、流程。每個人都明確自己的職責，但如果要求他們獨立爲自己分配任務，或者跨角色執行工作，就有些勉爲其難了。誠然，這已經是一種相對較爲落後的組織方式，或者是一種僵化的運作模式。但現實是這樣的團隊仍然存在，如果不能從根底裏改變軟件人才的培養模式，仍然會有許多所謂的“代碼工人”出現，這樣的一些人總是處於金字塔的塔基，人數衆多，生產力受到的約束也最大。這一角色天生是與敏捷開發水土不服的。
至於敏捷團隊，我認爲它就是一種去角色化的扁平組織架構，雖然它也有類似於PM之類的角色，但更傾向於團隊成員之間的平等。例如在Scrum中，就將團隊定義爲一個角色，在這樣的一個角色裏，成員既是設計師，又是編程人員；既是UI設計者，又是測試人員和數據庫專家。同時，他們能夠自組織自己的團隊，分析需求的實現，瞭解並安排進度。他們之中，即不允許墨守陳規，做老老實實的“遵循者”，也不允許那些總是突發奇想，不切實際的“牛仔程序員”。
假定已經存在這樣的兩個團隊，如果讓他們的開發模式互換，會得到怎樣的結果？大家可以想象。
所以我的意見是，即使你是一個狂熱的敏捷支持者，或者執着的敏捷佈道者，在你推行敏捷方法的時候，還需要認真分析你要面對的團隊，以及團隊的人。很多時候，人才是最重要的。就像之前提到的電影比較，如果比較特技，自然是現在的電影水平更勝一籌，但爲何許多翻拍電影卻會遭遇票房滑鐵盧呢？除了源於人們的一種懷舊情愫之外，恐怕演員的演技是其中最重要的。須知，《羅馬假日》或許是可以複製的，但世界上卻只有一個奧黛麗·赫本，她纔是獨一無二，無可替代的。軟件工程何嘗不是如此呢？