諷刺的是，這些失敗的專案最後卻做了與成功的專案一樣多的規劃和程序管理。失敗的專案仍然得做瑕疵追蹤，來管理所有被發現的錯蟲。期限將至時，他們必須更小心地評估自己的軟體，隨著期限壓力的增加，他們每週重新評估，有時候甚至每天重新評估。他們花時間在穩住各方對本專案的期望，設法讓大家相信本專案能夠如期完成。他們必須實施程式品質標準，在加入一段新程式以前，確保不致傷害到整個軟體。由於這些工作都太遲了些，所以真正的效益是有限的。和失敗的專案比較起來，有效率的組織所採用的進行方式是截然不同的──事實上，專案如果一開始就走對的話，以上所述的失敗專案末期所做的事情，可能根本不需要。
如同圖2-5所揭示的，最聰明的組織──能用最少的成本、最短的時間，做出最可靠的軟體──花在寫程式的資源，其實佔總預算的比例並不甚高。最不聰明的組織，把所有的預算都花在寫程式，和改掉自己所寫的程式中的錯蟲。他們的總成本是偏高的，因為他們沒有為加強工作效率而奠立基礎（關於這一點，在 第七章5 中有更詳細的說明）。
寫了再改的開發方式之所以繼續被人運用，是因為它有兩點很吸引人。第一，它能讓團隊很快地表現出專案有進展的跡象──他們第一天就能把巨石推進十公尺，而有效率的團隊還在砍樹製造滾輪木，準備道路好讓日後的移動順暢，巨石根本沒有任何移動。如果主管和顧客不夠聰明，不明白成功的軟體開發本身的動態性──而大部分的老闆確是如此，這時候寫了再改的開發方式看起來真是不錯，因為專案會很快開始有進度。寫了再改的開發方式吸引人的第二個原因是，它不需要任何訓練。在軟體業，軟體工程方面的平均訓練支出是很低的，因此把寫了再改的開發方式當作第一個選擇是非常普遍的。乍看之下它是多麼誘人，但它是蠢人的黃金，而有經驗的軟體開發人員知道，它是沒有價值的。
圖2-5進步的軟體開發方式在初期要投入比較多的努力，而避免掉專案後期大量而不必要的工作。
勿採用寫了再改的開發方式
專案一開始進行就可看得見某些結果，這一點非常誘人，這就是為什麼不斷有顧客和管理者掉進寫了再改的陷阱裡。專案的利害關係人若是想左右開發方式，大都會在專案剛開始的時候。如圖2-6所示，寫了再改的開發方式的確在初期顯現出比較好的進度，但是優異的專案暫時看不見有形的進度。
當顧客或主管想看程式執行的實況，優異的專案沒辦法示範給他們看。最能說服顧客和老闆們採用進步的軟體開發方式的時機，是寫了再改的專案即將結束的時候，圖2-6清楚顯示每個人都深陷痛苦之中。6
圖2-6如果顧客和老闆們堅持要看程式執行的實況，就很難說服他們應該採用進步的軟體開發方式。
強調品質
您或許以為既然開發員可以花少一點的時間在測試和產品評估，那麼時間表就可以縮減了。傾向寫了再改的人會說，那是當然的。但是軟體業的經驗卻顯示，正好相反。企圖以品質交換成本的團隊，最後反而得付出更大的成本和更長的時間。
如圖2-7所示，在軟體推出之前清除95%瑕疵的專案，是最有生產力的，他們花在修改程式的總時間最少。要想在推出前清除超過95%的瑕疵，就得花額外的時間，來改善品質。推出前瑕疵修正率低於95%者，其實應該早一點清除產品的瑕疵，會比較有效率。大約有75%的軟體專案，其推出前瑕疵修正率低於95%。對於這些專案，為了趕時間而犧牲品質是另一種蠢人的黃金。很不幸的，在充滿動態的軟體開發中，這種現象已不是新聞了。IBM在二十年前就發現，專案小組若是把重心放在縮短時程表而非創造高品質，將來就會有更大的機會發生成本超出和時間延誤。強調品質、願意追求低的瑕疵率，這樣的專案其實是花最少時間、而有最高生產力的。
圖2-7在曲線的頂點，就是既有低瑕疵率、又能花最少的時間的專案。大部分的專案其實可以採用早日修正瑕疵的方式來縮短時程表（資料來源：Jones, 《Applied Software Measurement: Assuring Productivity and Quality, 》2nd ed., 1997）。
7
有些蠢人的黃金是銀子彈
新的科技和方法論常會伴隨著誇張的「號稱功效」，也就是所謂的「銀子彈」（silver bullets），因為它們本意是要一舉消滅低生產力的現象。數十年來，軟體業經歷過多次的「銀子彈」：1960年代的線上即時交易的程式（on-line programming）、1970年代的第三代程式語言（third-generation language）、1980年代運用人工智慧科技製造的電腦輔助軟體工程（CASE tools， Computer-Added Software Engineering），1990年代流行的物件導向程式語言（object-oriented programming），都曾經號稱保證能大幅提高軟體的生產力。
假定搬運巨石的團隊一開始時使用的是不顧一切的蠻力。幾天之後團隊領導人就發現照這種緩慢的進度，是無法在期限前完成的。很幸運地，他聽說有一種奇妙的動物，名叫大象，體重超過成人的兩百倍，而且力大無窮。於是團隊領導人計畫組狩獵隊遠征，捉一頭大象來幫忙推這巨石。三個星期的跋山涉水，狩獵隊好不容易帶著捕獲的大象回來了。他們連忙把馬具套牢在這奇妙的巨獸身上，準備好鞭子督促牠。所有的人都屏息以待，看大象如何快速地移動巨石，也許能比期限提早完成呢！他們睜大眼睛仔細看，的確，大象拉動巨石的速朗O比人類快多了，可以說是前所未有，但是慢著，牠，突然地，揚起後腿蹬壞馬具又踩死兩個人，然後溜之大吉，從此再也沒有人看到牠，如圖2-8的情景。團隊感到失望：「也許我們在利用大象之前，應該多花點時間學會如何駕馭牠。」他們又浪費了20%的時間期待大象，失去了兩位組員，而沒有向目標前進一分一毫。簡單地說，這就是「銀子彈」症候群。
圖2-8銀子彈的創新經常讓人大失所望
大象的比喻，比您所想像的還要接近事實。羅伯特．葛拉斯（Robert L. Glass）在《失控的軟體》（Software Runaways）一書中比較十六個有問題的專案。其中就有四個專案期望運用銀子彈的創新，來獲得績效大幅提升，結果他們的企圖全都失敗了。
有一種比較特別的「銀子彈」，那是為了整體組織的程序改良而想出來的。有些組織採用一些流行又漂亮的管理名詞，來實施組織改良──整體品質管理（TQM，Total Quality Management）、QFD、軟體成熟度模型、零缺點、六項總和、持續地改進（Continuous Improvement）、統計程序控制（Statistical Process Control）。只要運用得當，這些都是很有價值的好方法，也就是說，要專注於實質層面而非徒具形式。有些組織每十二個月就來個新運動，好似唸唸企業管理潮流術語就可以把品質與生產力改善四倍一樣，這類的組織有個特別的地獄等著他們，就是低生產力。在幾年的流行術語管理（MBB，Management By Buzzword）之後，員工大都對管理階層的組織改良運動抱持嘲諷的態度，使得開發方式更難逃脫寫了再改的陷阱。8
正確的創新必須應用在合適的專案，並搭配合適的訓練，對它的期望也必須切合實際，作為長期策略的話，這樣做就會有非常好的效果。但是創新並不是變魔術，也不是容易的事。銀子彈也是一種蠢人的黃金，因為它有著一步登天的錯誤態度，經常為短期目標而採用，沒有合適的訓練，也沒有任何風險管理。就像黃鐵礦一樣，有經驗的管理者和軟體開發人員應該懂得不被它愚弄。
軟體並不軟
文章来源于领测软件测试网 https://www.ltesting.net/
