還記得剛開始留意職業棒球比賽的時候,心中一直有個疑問。有些球隊名將如雲,陣容一字排開,要強投有強投,有強打有強打,有些球隊號稱「黃金打線」還不夠,甚至還有「鑽石打線」的存在,可是,很多時候,這些名將組成的球隊,最後卻無法贏得聯盟的冠軍。有些時候,往往贏得聯盟冠軍的球隊,陣中不見得有那麼多的名球員,但是,他們能一步又一步地贏得每一個重要的勝利,最後得到冠軍。這當然有點違背一個剛接觸棒球比賽者的「常識」。為什麼球隊中的每個球員,個人能力和技巧都比較好,最後卻無法贏得冠軍呢?

當然,隨著對棒球比賽的了解愈來愈深,才慢慢明白球賽的勝負影響因素甚多,球員的個人素質只是其中一環,其中舉凡戰術的運用、團隊的合作、球員間的默契、等等,都會左右球賽的勝敗結果。當然,將名球員們聚集在同一隊,某種程度可以提高獲勝的機會,但是,像是名球員間的檯面下的私下較勁,或彼此間結下心結、不願意服從教練的戰術指示等等因素,也都會產生無法評估的化學效應,影響到球隊在球場上的表現。所以說,這還真是一個複雜的問題。

黃金組合的團隊未必是最佳拍檔
當我開始正式進入軟體開發這個行業時,也有類似的錯覺。那時以為,開發軟體,如果能找到一群程式設計技巧高超的程式設計師,組成一個團隊,那麼這個團隊肯定是最強的團隊,也能開發出最好品質的軟體。

沒過多久,就在一個機緣之下參加了一個開發團隊,那時在這個團隊中的成員,每一個在當時來看,都有很好的程式設計技巧(當然,我是例外),各自也都有一些不錯的個人作品或系統。當然,那時也對這個團隊寄予厚望,期待在這個團隊成員的共同合作努力下,開發出卓越的軟體。

不過,這就跟聚集了一群個人技巧高超的球員,就預期球員一定能奪得冠軍頭銜的想法一樣,最後這樣的期待並沒有發生。若是在現在回想起當時的往事,或許可以試著進行一些解釋及說明。

在當時的這個團隊,或許的確組成了一些擅長程式設計的設計者,但是,有一個很大的問題是,成員過去都是依照自己的喜好,自己決定軟體該有什麼功能,開發時也沒有既定的時程表,單純依據自己可用的時間來投入,往往也就沒有既定的開發進度及時程表。

更重要的一點,大伙都缺乏有組織、有系統和其他人共同開發的經驗,對於在軟體開發的過程中,如何建立相同的目標、如何分工、如何溝通,其實都沒有太多的實際的體驗。

這種情況,就好像聚集了一群武林高手,但是這些高手只擅長於江湖上的爭鬥,大多數情況都是一對一的較勁,頂多也只是以一敵十的場面。可是,現在要將這些武林高手用於兩軍交戰的戰陣之中,倘若想要克敵致勝,就不是單憑個人武技的強弱。舉凡戰略運用是否得宜、所佈陣形的優劣、將士們的士氣高低與否,都會影響到一場戰役最後的成敗結果。

程式設計就像是個人的武藝,而軟體開發的目的,則是要打贏一場戰役。

就跟棒球比賽一樣,明星球員們的球技雖然夠好,但也不等同於贏球的保證,想要贏球,需要更多條件的配合。

高手們在協同開發作業上遇到的問題
以前看棒球比賽的時候,常聽球評提到「觀念」。這邊的觀念像是什麼呢?好比守備補位的觀念,當某一名野手因為打者擊出球,而進行守備的移動時,其他的野手便有可能要補上他所空出來的位置,以使守備不致於出現防守上的漏洞。

又好比跑壘的觀念,當打者擊出球之後,所有壘上的跑者及打者本身,要正確的依據壘上的情況、每位跑者的速度、以及球被擊出的距離、可能的落點位置,決定究竟要如何跑壘。因此除了技術之外,球員所具備的這些「觀念」都會深深地左右棒球比賽的勝負。

回想起,當時那個由武林高手們(當時說是武林高手,現在想起來,也可以說是初生之犢不畏虎啊)所組成的團隊,最後沒有獲得成功的關鍵因素,可能還是在於大家缺乏開發軟體的重要觀念。可以說,武林高手們只懂單打獨鬥,缺乏戰陣中作戰的各種觀念。

缺乏什麼樣的觀念呢?

讓我來舉一些例子吧。首先,像是開發範圍(scope)的管理。在當時,雖然有人統籌管理所要開發產品的範圍,規範究竟應該包括那些功能,但是這個人不僅本身就是參與開發的人,而且,在開發的過程中,還會隨著他的喜好,持續添加功能。

這樣的情況,或許在個人依自己的興趣、在沒有既定的時程的條件下來開發軟體時,不會構成太大的問題,實際上,也有一些很好的軟體是以這種形式而產生的。

但是這種模式,對於一個團隊要在既定的期限內完成一個軟體產品而言,一個持續在演化的規格目標、不僅讓所有成員難以掌握真正要開發的產物究竟為何,對於最終真正期限的評估,也始終無法準確或逼近。那麼,原訂該上市的時間,自然也就一拖再拖。

有經驗的開發者會懂得適度的削減開發範圍,來滿足產品上市的需要,但是在這個例子裡,反而是開發團隊自己不斷的擴大開發規模,使得產品遲遲無法完成。

這就是一個很簡單的觀念,在開發的時候,要讓需求、規格盡量保持不變,甚至在時間有限時、而期限又不允許更動時,還要適度將那些較不優先的功能自開發範圍中削除。欠缺這個觀念,即使程式設計技巧再好,也可能讓軟體開發的工作無法順利完成。

軟體本身本來就會有版本上的演化、功能上的持續加強。但是,在當時,開發團隊一心只想做出心目中最完美的那一個終極版本,所以,為了做出這個終極的版本,不斷持續修改它、加強它,但是最後的結果是,始終都沒有足夠穩定的第一個版本問世,一直都在持續的建構當中。

這又是另一個很簡單的觀念,許多有經驗的開發者會知道,可以設定一個遠大的目標,但是,要先做出一個功能不那麼強、但是足夠穩定、能夠正常運作的第一個版本,接著再以這個版本為基礎,持續地演化及改進。

有時候,你會需要有這麼一個版本讓所有的人(包括客戶、使用者、產品經理、出錢的大老闆)清楚看到一個可以運作的系統,他們會對系統應該要是什麼樣的面貌更有概念,才更知道軟體功能該如何調整。

又好比不要輕易的重新再造輪子。在這個例子中,許多重要的元件,開發團隊都決定自己重新設計、開發,而不是沿用既有的程式庫或應用程式框架。這樣不僅曠日廢時,而且重新再造的輪子也會需要時間的歷練來達到穩定。倘若有這樣子的觀念,就會知道應該要挑選適當的現成輪子,而不是事事都要嘗試自己來過。

Coding只是開發過程中的一部份工作
把程式設計等同於軟體開發,當然是很大的誤解。除了程式設計之外,軟體開發中涉及更多的層面。而其中,是否擁有正確的軟體開發觀念,絕對影響到是否能更順利地開發出有品質的軟體。

專欄作者


熱門新聞

Advertisement