解開軟體專案10個不能說的秘密
透過工具的管控，不但可以監控開發各階段的品質，還可以讓過程攤在陽光下，降低失敗風險

▼ ADVERTISEMENT ▼

▲ ADVERTISEMENT ▲

當一個軟體專案成立，無論使用者或者開發端，都是懷抱既期待又怕受傷害的心態。而且使用者、專案經理、開發者及高階主管各有各的煩惱與不安。然而，軟體專案成敗的影響因素包括人、流程與工具，無法提供一帖見效的良方。不過，雖然工具不是銀彈，但透過自動化的機制，在應用程式生命周期的各階段，強化管控的能力，並讓過程攤在陽光下，確實可以降低失敗的風險。

使用者的心聲

為什麼開發出來的系統和當初談的差那麼多？

許多專案其實在一開始就註定失敗，原因在於根本搞錯方向。一個專案應該花多少時間分析需求呢？根據《人月神話》作者Frederick P. Brooks的經驗法則，軟體專案的時程，應該1/3用在規畫、1/6寫程式、1/2的時間測試，如果要訂出詳盡且充實的規格，甚至需要再延長分析與設計的時間。

使用者的描述往往是模糊不清的，例如我要一部車、跑得很快、四個門。就這樣的描述，不同團隊開發出來的結果，彼此就有天壤之別。而且，根據分析機構的數據，系統上線以後發現問題，修補的成本是需求分析階段的100倍。上述問題都是系統分析師的責任，也就是幫助使用者釐清需求。以車子為例，他必須定義出什麼顏色的車？幾人座？快是多快？好又是怎麼個好法？……等。

雖然，隨著RUP、XP等方法論的不同，需求分析的手法各異，不過最終的精神，是希望開發出符合使用者期待的系統。因此需求管理工具的重點，就是透過需求列表、使用情境圖、流程圖甚至搭配使用者介面，力求減少模糊地帶，確認使用者與分析師之間的認知沒有落差。

為什麼我覺得自己好像是IT單位的測試人員？

臺灣的開發團隊多數沒有編制專責測試單位是事實。在小團隊開發、人員有限的情況下，開發者兼任測試工作，其實情有可原。但所謂的「測試」，通常是指功能操作一遍，只要沒有出現錯誤訊息，而且資料正確就算過關，這種粗糙的手法，品質堪慮。

如果專案時程緊迫，第一個被犧牲的時程就是測試，於是原來就非常原始而草率的測試，可能再被壓縮成只要編譯過關，「看起來」、「好像」沒問題就交卷了。於是客戶成了驗證品質的白老鼠，當然會引發如雪片般的抱怨。

現在有許多大型的專案，尤其是政府標案，會要求提供測試報告，甚至不信任系統開發商的測試報告，而委由專業的測試單位負責驗收，以書面的驗收報告作為結案與否的依據。

當然，不是每個專案都負擔得起第三方測試單位的驗收成本，但已經有越來越多的企業，要求IT單位，提供專案的「健康報告」，甚至專案要求將單元測試及測試案例納入結案交付的項目。在有圖有真相的要求下，可以避免用戶淪為開發單位編制外的測試人員。

廠商說3個月完成，會不會是第3個月才開始動工？

這種情況在小型開發商中屢見不鮮，當委外廠商有多個專案在進行時，難保不會調配人力，先去支援時程緊迫的專案。同樣的情形也會發生在系統開發商將專案再發包給小廠商的時候，這是黑箱式委外的風險。衍生的問題不只是牽涉到系統能否準時上線，急就章的開發流程，交付的品質同樣令人質疑。

針對這種弊端，工具有辦法解決部分問題，現在許多版本控管軟體，支援多據點開發的機制，企業可以要求外包廠商把程式碼儲存在客戶端，程式碼的簽出／入可以設定權限並留下記錄。此外，透過Web化的專案管理介面，隨時瀏覽專案的開發與測試進度、臭蟲數量及修復的比例，所有專案完成度的指標一目了然。透明化的監督方式，對業主是一種保障。

開發者的痛苦