軟體開發不是光靠程式設計

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

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

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

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

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

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

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

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

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

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

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

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

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

缺乏什麼樣的觀念呢？

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

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

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

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

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

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

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

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

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

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