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開發出來就立馬被部署了。