軟體開發：一場寧靜革命

| | | | | | 1則回應

    

怎麼會有如此可怕的馬路？！然而在真實世界裡，有個領域正是如此--那就是「軟體開發」。根據Standish Group CHAOS 2000的統計，軟體開發專案的成功機率為24％，剩下的76％都以失敗告終。換句話說，在這個令人咋舌的專業世界裡，烈士們一直用大量的鮮血換取少數的成功。

軟體開發真的這麼驚心動魄、死亡枕藉嗎？是的，許多投入這個領域的人都有很多失敗故事，以及少數極為珍貴的成功案例。這些存活下來的英雄們都已鍛鍊成可以隨時分泌腎上腺素，與培養出視死如歸的涅盤精神。

事實上，軟體開發並不像起義那麼可怕；不過兩者間倒有個微妙的共通點--都在「推翻不良舊體制，建立美好新體制」。革命烈士們都知道自己正在創造歷史，但很多投身軟體開發領域的勇士們並不瞭解自己也正走在這條路上；幸好已經有成功部隊把康莊大道展示在大家面前了。

瀑布與水車

軟體開發之所以常常失敗，最大癥結在於「體制」，也就是「開發流程的設計與推動」。這個關鍵往往沒有受到重視，等到最後問題爆發出來時，代價就是浪費大量的人力與金錢成本。

按照常態，軟體開發專案的流程大致可區分為「需求」、「分析」、「程式撰寫」、「整合」、「測試」等階段，整個開發團隊也是按照這個流程組合而成，所有工作循序進行。這種最常見的模式被稱為「瀑布式(Waterfall)」流程法，也就是前一個步驟完成後，再把結果導入下一個步驟，依此類推直到產生最後結果。

這種傳統方法的特色是職責分明、各行其事，但同時也是缺點所在。因為這種單向流動模式少了各階層間的溝通與回饋設計，也缺少彈性應變機制，一旦發生失誤、需求臨時改變或流程出現問題時，就會使整個流程大亂，輕則成員彼此指責，重則重起爐灶。這就是軟體開發成功率只有24%的最大關鍵，結果導致人力資源浪費、成本膨脹及客戶關係惡化。

既然傳統的軟體開發體制漏洞百出，那該如何改進？我建議顛覆慣用的單向式流程，把瀑布的最終結果導回源頭，成為一個往復式的圓圈（Cycle），使整個流程具備回饋與檢驗機制。當然，僅將瀑布改成循環水車，不代表革命已經成功，還需要配合各階層的革新作法。

我們將這種革新的循環式流程，以及藉此發展出的一整套完整作業模式，稱為RUP（Rational Unified Process）。RUP是一份包含四百萬字、累積多年實際經驗所提煉出來的最大共識（或公約數）、由上千位軟體開發人員所共同完成的標準化作業準則，堪稱為「最佳典範」（Best Practice）。RUP的目標是希望藉由一套最佳化的軟體開發作業流程，提升投資報酬率（ROI）。

  繼續閱讀： RUP觀念>>