做好輕量級開發的先決條件

許多團隊的開發流程，看似井井有條、制度完整，但流程中所規畫的活動，無法在開發參與者的進行下，達到它應有的效用。很容易讓程式人產生一種負面的印象──開發流程的活動不過是表面文章、敷衍了事、徒做虛功。也讓許多開發者，對於開發流程的活動敬而遠之。

不認同徒具形式的流程，許多團隊轉向輕量級方法論
因此，在光譜的另一邊，也有一類團隊，盡可能地裁減所需的開發流程活動。這樣子的團隊，多半是以程式人為主的團隊，對他們來說，程式撰寫以外的工作幾乎都會被歸類為「額外負擔（Overhead）」，就像我們很常見到的，程式人視紙上作業為額外負擔，因為文件的內容往往不能直接轉換成為程式碼，而且有時候甚至和程式碼的產出一點關係都沒有。

對他們來說，開發想要更有效率，就要盡可能減少額外負擔。當然，文件的撰寫肯定是他們首先要打倒的萬惡罪魁，非到萬不得已、山窮水盡的局面，絕對不撰寫任何文件。

我甚至看過有些團隊的管理者，認為版本管理活動，是一種額外負擔，因此，雖然他們也建置版本管理伺服器，但是，開發者並不利用它進行版本管理的活動。這某種程度算是管理者體貼開發者的一份心意，因為管理者希望讓程式人專心撰寫程式碼，盡量避免其他活動干擾到這最主要的工作。

對這類的管理者來說，追求制度不過只是形式上的表面功夫，事實上，裡子更勝於面子，產品應該以更有效的方式開發。為了達成這目的，應該盡量摒除各種額外負擔。

尤其近來輕量級的開發方法大行其道，這更讓這類團隊找到一個依靠，當中有許多人宣稱他們自己是輕量級的開發方法，因為他們摒除了許多開發流程所帶來的額外負擔，所以他們認為自己的開發方式輕盈無比。

XP有12項準則，不能只選甜頭，忽略苦差事
我曾經聽過不只一位朋友說過類似的話：「我們採取的開發方法是XP（eXtreme Programming），我們的釋出周期很短、需求也變更得很頻繁、甚至沒有太詳細的需求記錄文件，幾乎不做細部設計。」這看起來，應該算是誤解了XP，而且只從XP挑一些對程式人來說，是「甜頭」的東西出來實行。

怎麼說呢？XP有12項施行準則，其中有許多準則是互為支持的。例如，倘若你希望小版本的持續釋出（也就是說，需求能夠變更得很頻繁），你得強化單元測試及重構。因為當你的需求變更頻繁時，自然造成程式碼的變更頻繁，倘若沒有足夠的單元測試做為後盾，那麼變更頻繁的程式碼，勢必經常地造成副作用，對程式的穩定度造成很大的衝擊。同樣的，倘若沒有持續地重構，那麼程式碼最後也會形成疊床架屋的情況。

小版本持續釋出是甜頭，因為需求的提供者，可以很快看到自己所許下的願望被實現。允許需求變更頻繁也是甜頭，因為這使得需求提供者，能更快地反饋他對開發產物的修正意見。

但是，許多號稱是採XP開發方法的團隊，都不做單元測試，他們也不持續重構，因為這兩個工作都是苦差事。單元測試的確是苦差事，在XP強調「測試先行」的情況下，還沒撰寫程式碼之前，就得先寫好測試案例，而且每個程式碼單元，都應該搭配相對的測試案例。要程式人養成撰寫這類案例的習慣，簡直比要他們寫文件還要命。

重構也是苦差事，不僅許多程式人不具備重構的技巧，即使具備重構的能力，也抱持著「做好的事，何必再改變」的心態，對於整理程式碼漸漸產生的遺毒，始終興趣缺缺。像單元測試及重構這類工作，在許多人的認知裡，都是對程式人的某種「額外負擔」。

所以，許多團隊其實是柿子挑軟的吃，他們的眼裡只看到可以抄捷徑的地方，卻沒有在意，這些輕量級的開發方法，之所以能抄捷徑，是因為有其他的配套。

好比，XP之所以允許對需求的描繪盡量精簡，是因為施行準則中有一則是要求客戶駐點，也就是說，客戶和開發團隊位在同一個地點，因此，客戶能夠很快看到系統的面貌及行為，也能夠面對面和開發團隊溝通，減少了所需的文件。

倘若沒有客戶駐點的條件配合，那麼過於精簡的需求描述方式，就會產生極大的危機，因為開發團隊對於需求產生誤解的機會就會大增。

徒具形式的開發流程可怕，半吊子的輕量級開發也很兇險
徒具形式的開發流程固然可怕，但半吊子的輕量級開發，也是兇險異常。這樣子的開發，表面上似乎提升了效率，但是，骨子裡付出許多隱形的額外負擔。例如，節省了撰寫需求規格文件的時間，卻沒有搭配客戶駐點，使得開發團隊不能準確地捕捉客戶需求，因此，時常在開發完成後，客戶才發現不合預期，引發更多的修改請求，白白浪費開發的力氣。

又例如，允許頻繁的變更，但又無單元測試及重構的活動與之相對應，因而導致修改程式的副作用頻繁發生、品質也降低，程式碼架構也漸漸趨向疊床架屋。表面上，開發團隊節省了一些功夫，但是無形中可能損失更多。

有些開發團隊由於成員中的程式人技巧高超，所以即使缺乏某些相對應的配套活動，整體的衝擊有可能不那麼大，顯現出來的負面效應也不明顯。但這不意謂著抽掉這些活動，對所有的團隊來說都是適宜的。

若要略去輕量級開發的某些活動，必須有其他條件配合
開發流程是用來輔助開發團隊邁向完成目標的一個工具。開發流程中的活動，某種程度來說，算是一種額外的成本，但也是投資，我們希望投入一些力氣，使得開發的整體成本降低，品質也維持。

理想的情況下，這個額外的成本，自然希望能夠降到最低，但又能維持整體成本最低、品質不變（或變得更好）。輕量級的開發，便是希望能夠降低投入的成本。

降低因為開發流程活動而造成的損耗，大方向是對的。但是，究竟能節省那些活動，必須根據所面臨的環境、開發的標的物、以及限制條件（包括人力的多寡、素質）決定。

當開發團隊決定採取較為輕量化的開發時，最好先對一般較為重量級的開發方法有基礎的認識。因為所有開發方法的發明及設計，都有動機，而開發方法中的活動安排，也都有原因。你在輕量的開發方法下，之所以能夠略去某些活動，必須是因為有其他的條件或是輔助的活動可以相對應，才不致於引發問題。

開發團隊在選用一個開發的流程時，無論輕重與否，都應該根據目前所處的環境及目標，設定開發流程所應具備的條件。例如，開發流程究竟要不要管理需求的變更？你必須知道，若要管理需求變更，究竟會付出的代價以及好處。倘若決定不管理需求變更，那麼可以省掉多少力氣？又會增加多少潛在的風險？而這些風險以專案的環境及條件，是否可以降低或是接受……

我想表達的是，省掉一些功夫，必須是因為知道有某種因素存在，所以可以省去；或者，我們知道某些資源的缺乏（例如時間、人力），也意識到可能會有的風險，但是判斷這風險是在可以接受的情況下，所以決定省去。絕對不能在不知道究竟會引發多少負面效果的情況下，貿然地取捷徑。

作者簡介─王建興
	清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。