有為者亦若是，還是為賦新詞強說愁？

| | | | | | 1則回應

    

上次看你寫『怎樣不被後浪推』一文 真有共鳴，因為要學的東西太多了。

我們公司接的大多是政府標案，所以多半用的是按部就班又很嚴謹的瀑布式開發，我們實際上在運用時，其實遇到問題還蠻多的。

公司最近來了一個新的顧問，他說自從google、web 2.0出名後，現在又冒出什麼敏捷開發，建議我們可以往這方面思考。

我不是本科系出身，所以對這方面比較陌生。這種新的開發方式，好像不加緊努力學學，可能就會沒頂在知識浪潮中（胸中燃起一股「有為者亦若是」的慷慨激昂！...其實是公司美眉問我時答不出來很糗啦）請問一下，這到底是什麼東西，是不是該學一下呢？

很上進、也很想敏捷的開發人員

很上進、也很想敏捷的開發人員你好，

我記得我小時候看過一個笑話，台灣人跟美國人參加考試。題目是12點到1點之間，什麼時候時針跟分針會剛好疊在一起，美國人看到題目就開始脫下手錶轉指針，台灣人則是開始拿起筆來算答案。

台灣人別的不會，看考試題目背答案這絕對是一流的。所以每當人家提到，哪種舊的開發方法不好，就把書上的答案背出來唸一唸。『少年不識愁滋味，為賦新詞強說愁。』很多人在媒體報導或是書本裡頭，看到了很多新的開發方法，雖然不見得知道這裡面描述的優劣點是什麼，不過最少跟著大師複誦總是會的。

當我們在考慮要採用什麼樣的開發方式時，很多人會聽聽專家學者，以及業界大師的看法。或者就直接採用最流行的作法。然而大師說的真的就可以套用在你所要開發的專案上嗎？這就是一個很好的問題了。

每種開發方法一定有他原本打算解決的問題，以及背後對於問題的假設。然而對很多人來說，他們常常只會看到現在大師們的說法，而不是仔細去想想這個開發模式到底適不適用。

流行本身並不需要任何道理，只要大師說了就算，有人拿香跟著拜，沒有多久就會有信眾出現。而流行的開發方法經過大師加持之後，身價馬上就大不相同。於是乎，就會有許多信眾，不管自己手頭上到底擁有什麼樣的專案，馬上起義來歸。

大師所開示的開發方法，就像是一件經過美麗達人加持過的比基尼泳衣一樣。如果穿在性感美女身上，當然可以展露美女們曼妙的身材。可是好看的衣服，並不是每個人穿都好看；如果你要一個中年胖肚男子穿上比基尼泳衣，對每個人的眼睛，在視覺上不知會造成多大的折磨。

穿著是否適宜，會跟著你的身份、場合不同而有所不同。軟體開發流程也是一樣，當我們要挑選時，最重要的一件事，就是要跟你專案的特性相配合。有點年紀的開發方式不見得就是不好的開發方式，其實重點應該在於跟你所要做的專案是否配合。

當我們手上有一個新的系統要開發，到底該採取什麼樣的開發方式呢？我想，這就必需要從不同的角度針對不同開發方式的特點進行比較。因為不同的開發模式，其實背後有不同的假設。你要選擇使用什麼樣的開發方法時，得要先搞懂他們背後的假設。

這幾年關於敏捷式開發（agile software development）的相關討論還蠻盛行的。就像在幾年前UML(Unified Modeling Language)當道時，蠻多人也跟著當時的流行，採用OOAD(Object Oriented Analysis and Design)，採用RUP(Rational Unified Process)來開發系統一樣。我們會看到各式各樣評論以往開發模式不好，採用新模式會好得多的論述。

在我個人看來，很多都流於為賦新詞強說愁。特別是批評舊方法不好的人，有蠻多根本就沒有用過waterfall的方式開發過多少大型專案。只是因為書上寫了，就跟著無病呻吟。反正你要找理由來埋怨現在的日子過得不夠好，總可以找到一些理由來抱怨。

比如說阿扁就會埋怨，為什麼兩蔣時代大家都不去查國務機要費，現在開始拿放大鏡在看阿扁的國務機要費的經費核銷一樣。明明就是阿扁的幕僚不會做假帳，上台時沒有找到夠多、夠好、夠聽話的人頭，想要便宜行事，就唬弄阿扁說，用新的做假帳方式就可以搞定了。還自己訂了一個國務機要費的管理辦法，等到事情爆發了，就把問題怪罪到媒體上。

我個人在此不會解釋各種不同開發模式的細節，這種東西你上google查就可以找到一堆了（不過你要是一點都不懂，看了我的解說恐怕也會霧煞煞）。我反倒會從不一樣的角度來看這個問題。

我想在你比較新舊不同的開發模式之前，最好先了解一下他們基礎的假設有什麼不一樣。這在你決定要採用那種方式開發時，就會蠻重要的。

首先要問的是，決定需求的人，會在專案進行的期間陪在你身旁進行開發嗎？

決定需求的人是否在專案進行的過程中全程參與開發

不管你採用那種agile method，決定需求的人需要跟開發團隊在同一個地點一起工作，如果requirement有任何問題，需 要即時可以確認開發的方向，這是這類型的開發方式，最基本的假設。

因為不管是extreme programming，或是走RUP的開發模式，都是iterative的開發方式。而iterative的開發方式，就是需要決定需求的人，在專案進行的過程中，不斷地把他們的意見回饋給你。讓你可以將新的需求，安排到下個iteration來完成。這樣一來，你的軟體才有可能在不同的iteration之中，不斷地演進，慢慢趨近使用者真正的需求。

然而，如果你做的是政府標案，那這樣的可能性就很低了。因為客戶通常還有他本身的業務要負責，所以比較沒有辦法派人全力投入在這個專案之中。所以通常我們是在開發公司內部運作的系統，或是開發公司自有商品時，才會考慮採用iterative式或是agile software development的方式。因為這個時候你可以派人在專案進行的過程中即時確認需求。

當你要考慮你的開發模式是否需要改變，採用新的方法是否會獲利時，要考慮的就是決定需求的人是否可以在專案進行的過程中即時確認需求。如果你問一個關於需求問題，可能還要經過一個複雜的公文流程，經過幾個禮拜才會回應給你，我想你就把iterative跟agile這些名詞給忘了吧。因為這些對你來說都不合用。

第二個問題是跟錢有關。第二個重點在於，是否有經費可以支持頻繁改版的開發費用。

是否有經費可以支持頻繁改版的開發費用

如果你要採取iterative 或是agile software development的方式，這兩種模式的優點，都建立在你的系統經過了各個不同的iteration的洗禮，各方面都會變得越來越好。所以，如果你做的是scope原先已經確定的專案的話，像是政府的標案的話，其實你開發的總價，在簽約時就已經定下來了，你再多做幾個iteration，你拿到的錢又不會變多，這時就表示任何對於品質的追求，其實都不會獲得來自客戶的獎勵。這種時候，我們的重點就會在於怎麼樣用最短的時間，最精簡的人力，做出一個客戶願意驗收的系統。而不是一個我們覺得最恰當最好的系統。

當提供經費的單位，跟負責開發的單位，彼此的利益沒有站在同一個陣線時，這時候其實就不要再想說要用什麼iterative式的開發模式，因為雙方的出發點是完全不同的，那也就是為什麼，在我們一般常見的狀況下，waterfall的開發方式還是大行其道的關係。

如果你的公司像Google一樣有錢，你當然可以頻繁改版，改到盡善盡美、淋漓盡致、地老天荒。

第三個重點在於，需求是否明確。

需求是否明確

如果需求非常不明確，那採用waterfall的方式去開發，一定會帶來很多困擾。因為這就有可能會不斷地有各式各樣需求變更的狀況發生。這種狀況底下，採用比較light weight的agile method會比較適合。

如果你的專案是公司自有產品的開發，這時候，就可以視狀況採取iterative 的開發方式。因為公司其實會付出各個版本的開發費用，決定需求的 domain expert 又能時時即刻確認需求，那agile method就應該是最適合的。運用的好的話，這種方法將會帶來好幾倍的生產力。

結語

目前流行的這幾種方法，適當的應用的話，確實可以縮短軟體開發時間，降低軟體開發的風險，讓生產力達到倍數的成長。

對於全天下從事軟體開發的人來說，這些方法當然具有致命的吸引力。然而，要修練葵花寶典，最困難的還是在第一關。要是捨不得揮刀自宮，後面全都是白搭。選擇開發模式也是一樣。如果你做的是政府標案，採用agile的開發模式這件事就先把它忘掉吧。

不要看到別的名家因為寫出淒美動人情感懇切的優美詞句，就為賦新詞強說愁。要嘛，你就轟轟烈烈地談場戀愛，等到真的『此情無計可消除，才下眉頭，卻上心頭』的時候，你自然就會文思泉湧；要嘛，就是打消當詞人的念頭。

也就是說，如果你真的對新的開發模式有興趣，那就要換個專案團隊，做做不同的專案。政府標案不太可能有機會讓你這樣搞。等到你真的下去做了，你的體會就會是很實在的東西。書上搔不到的癢處，你才會有所體會。書上誇大其詞的部份，也才有辦法體認到。有很多所謂的好處，其實是言過其實。就像我們在觀賞成人影片上所看到的招數一樣，實際上應用起來，並不見得可以造成相同的效果。不過在你沒有實地去做之前，看起來最少大家都心情亢奮，熱血上衝，自然就會覺得很不錯。

要是你沒有更換團隊的打算，想要繼續待在現在團隊裡面，那就不要想太多。成人影片看看就好，不用真的去實驗這些花招。不要明明是個中年啤酒肚男子，卻還是整天想著要穿比基尼。雖然電視台可能還是會派出SNG車轉播，但那段新聞的瞬間收視率可能會掉下來吧。

獨孤木