OK，敏捷哈。不爭論什麼是敏捷。我們來看一些現象，然後你來告訴我，你有沒有遇到過這些問題。

沒人提真正的Feedback

每個迭代結束之後，我都會做Showcase。但是從Showcase上收集到最多的，就是UI的問題，字型太小之類的。每個Release釋出之後，專案都會部署一個試用版本。但就是不見真正的使用者來“試用”，就更別提Feedback了。敏捷不是強調Feedback嗎？客戶（Customer）時間不夠，同時他們也不是終端使用者，提不出足夠有深度的Feedback。而終端使用者呢，壓根就沒興趣。

架構咋弄啊

每個迭代都要被催著出東西，哪裡有時間弄架構哦。一開始就一個勁的加功能。前幾個迭代大家都很Happy，功能出來的特別快。後來就越來越慢了，團隊情緒也很差。

客戶說沒有不是Must Have的

事情實在太多了，做不完呀。那讓客戶來排優先順序吧，把哪些是Must Have的找出來。但是客戶說了，這些都很重要，沒有這個Feature，或者那個Feature系統就壓根沒有用處。

路漫漫其修遠兮，我到底在往哪走

團隊的成員越來越多地在抱怨，天天做Story。但是這些Story都是幹什麼用的呢？這做一點，那做一點，根本就整合不到一個Vision裡去。客戶說，我給了你Vision啊，你看這個Feature那個Feature，這些要做的東西就是我們的Vision啊（心裡還在犯嘀咕呢，你們幹活的吵什麼吵）。

這些問題都有一個相同的最終根源。我們先來看最明顯的Feedback問題。為什麼客戶和終端使用者都不提Feedback？因為不關他們的事！做Showcase不過就是在眼前晃兩下，有深度的Feedback不是那麼容易及時地想到的。而Release又有多少是真正部署到產品環境的？終端使用者一方面還用這舊的系統，天天忙著四腳朝天的，哪裡有時間來試用我們的新系統呢？無論你是設定了一個測試機在他的桌子旁邊，還是一天三次的發Email提醒。只要你的系統不是完成他工作必須的一部分，他就不會理你。

為什麼Release出來的系統不能部署到Production環境呢？這不是很奇怪嗎。是的，確實很奇怪。但是，假如你是客戶，你被你的組織委任了一個替換現有系統的差事。現有的系統有100個功能，完全開發完這些功能可能需要兩年。但是，每三個月都有一次績效考核。你會不會希望每三個月，就讓領導看到你都弄出了點了啥？於是你找到了一個號稱可以做敏捷開發的外包公司，要求他們每三個月給你出一個版本。但是這個版本能真正上Production麼？不能！現有系統有100個功能，那麼多使用者在用呢。你三個月弄出來的系統怎麼替換這麼大一個系統啊？一個“成熟的企業”，對於一個這樣系統的GO OR NOT GO MEETING都要開三個月呢。

也許你要說，我們是真正的Green Field開發，徹底重頭寫的。那麼有你開發的系統之前，這家企業是怎麼運作的？至少有一個Paper Process吧。沒有電子系統，人們就用紙筆，各種單據來工作唄。IT系統不過是Paper Process的自動化而已。再說了，這年頭還真沒幾個請得起我們，而且現在還沒有一個IT系統的，需要從Paper Process開始的？

除非你做的是非常有創新性的企業開發。通過創新性的IT系統，開發新的業務。比如通過新的交易應用來輔助新的Margin Loan產品的市場投放。大部分時間來說，我們都是被引入進來“替換”現有的Paper Process，或者現有的遺留應用的。

假設我們要替換的就是一個有100個功能的遺留應用，我們是怎麼來“玩”敏捷的呢？基本上來說，我們假設了一個溫室的環境。在這個環境裡，你可以假設你做的是Green Field的開發。把100個功能，分成多個Release，每個Release又分成多個Iteration。在每個Release之後都會發佈一個Pilot版本給測試使用者試用。這樣就可以迭代式地新增Feature，直到最後能夠替換原有的系統。從我的經驗看來，正是這種做法，部分導致了以上問題（甚至有些情況下是根源）。前面已經提到了，這樣會導致缺少來自終端使用者的，真正的Feedback。其次，由於少了一個Feature都無法替換舊的系統，客戶很難做出優先順序的正確選擇。以替換舊的系統為目的，所有的Feature都是Must Have。同時這樣會導致每個Release缺乏明確的，唯一的Goal。經常是這個Feature做一些，那個Feature做一些，Team會覺得沒有明確的目標。

如果我們不以替換舊的系統為目標？那麼應該以什麼為目標？這個時候你可以去看看Eric Evan的Strategic Design。他說，你應該想想What drives you to spend million dollars on this project in the first place（你為什麼在最開始要在這個專案上決定花上一百萬美元）。這個背後一定是原因的。基於對這個原因的理解，我們可以選定一定的Feature來實現。然後就開始實現，然後把實現部署了讓所有的使用者去用。用這種策略，而不是前面那種策略，這樣就逼著我們去做很多事情。而我相信這些事情，很有可能就有助於解決前面四個問題。特別是，其中的架構問題。為什麼呢？架構是什麼？架構就是對問題的一種分解方式。怎麼樣才能迫使我們去思考架構問題呢？在現有的系統上打個洞，然後挖掉一塊，圍一道牆，裡面再把新的Feature做出來。沒有對系統整體的瞭解，沒有對模組的分解，沒有對模組之間耦合依賴關係的分析，是不可能做到這些的。這樣就迫使我們做出一個低耦合高內聚的架構！

把這種策略做到極致就是之前我說過的持續部署才是王道。不但每個Release都和舊的系統整合起來，然後真正的部署。甚至，我們可以做到每個迭代都部署。在Fred George描述的團隊裡，甚至都沒有迭代。一個Feature開發出來就立馬被部署了。