軟體開發中的英雄主義

上個月的一場軟體工程研討會中，南亞科技資訊部課經理曾鴻志在臺上跟聽眾分享軟體開發所面臨的英雄主義問題，以及導入軟體工程的經驗；演講結束他一走下臺，就有多位科技製造業的資訊主管趨前交換訊息，感同身受地討論企業開發軟體所面臨的痛。

失敗、延期、功能不符預期，是軟體開發專案常見的情況，這不只臺灣，全世界都是如此。Standish Group追蹤調查這個議題10年了，得到的答案還是令人驚訝：近3成的軟體專案都以宣告失敗收場，而成功結案的軟體專案，比例只有2成至3成。其他的呢？有的超出預算，有的延遲結案，有的更是必須刪減功能，才能符合上線時間與預算的要求。

開發軟體有這麼難嗎？即便是一個人也有辦法寫出程式，在早期資訊系統單純的時代，確實是一個人從頭做到尾，交出的程式能正確運作就行，文件記錄也就不必了，因為都在開發者的腦子裏，這就是曾鴻志所說的英雄主義。

資訊系統越來越複雜之後，軟體開發工作益顯龐大，需要多人參與分工。然而，人一多問題就來了，因為溝通不容易。就像一幅諷刺軟體開發的漫畫所描繪的，客戶描述他們需要一個有著三層木板的鞦韆，但專案管理者所理解的是一個有著一層木板的鞦韆（一層顯然比較符合常理），而系統顧問所描述的是放著舒服單人沙發的鞦韆。在這過程中，沒留下任何記錄，因而客戶花了大筆錢，但最後才發現，他們可能只需要一個用輪胎皮做成的鞦韆即可。

那麼，可否借助行之有年的工程建造經驗，把軟體開發視為工程一般進行？像是建築這樣的工程，先釐清客戶的喜好與需求，接著設計建築物的結構，畫出藍圖，最後由各個施工團隊照圖施工。軟體工程的觀念於之成型，不過，有了軟體工程並不能解決所有問題，因為軟體開發的變動因素比起其他工程高許多。就需求來說，臺灣的偉大工程雪山隧道，即便是歷經14年克服千辛萬苦才開通，但需求都不會變──就是打通北宜高路線上的隧道。然而軟體專業原先所訂的需求，到了要結案前可能就已經不符時局所需了。

因此，即便軟體工程是搶救軟體專案頻頻失敗的良方，但可不是萬靈丹。然而，有許多人確實是把軟體工程視為萬靈丹，將軟體工程的方法論推到至高無上的地位，就因為軟體工程是印度軟體代工產業興起的關鍵因素之一，於是要找出路的臺灣就這麼颳起了CMMI認證風潮。如此則不免陷入軟體工程方法論的迷思中：為了提升軟體開發效率就要拿CMMI認證嗎？一旦陷入為拿證照而考證照的局面，就與軟體工程的初衷偏離了。對於軟體公司及企業資訊部門來說，軟體工程不是研究項目，而是要實際協助改善軟體開發流程、品質及良率，然而，非得要軟體工程不可嗎？非得遵循主流的方法論不可嗎？請見本期封面故事深入的分析報導。