CSDN博客

img tom255

蠢人的黃金 (软件工程,快速开发)

发表于2001/5/24 13:53:00  913人阅读

 

微軟如何滿足客戶需求 視窗縮放
蠢人的黃金 加入書架 加入書籤 上一章 下一章 


加入書架
加入書籤
上一章
下一章

軟體的問題之所以持續存在,部分是由於某些常見的不良習慣誘惑所致。在1840年代晚期到1850年代早期,美國加州興起淘金熱,很多一心挖金礦的人都被蠢人的黃金──黃鐵礦(iron pyrite)──欺騙過。黃鐵礦容易剝落、質脆不堅,而且沒有價值。有經驗的礦工知道真的黃金是柔韌而可塑的,而且在壓力之下絕不斷裂。五十多年來,軟體開發人員常常在自己那蠢人黃金的誘惑之下屈服。他們因循於有缺陷的做事方式,因為依照習慣比較容易,但是這不過是蠢人的黃金,他們做出來的軟體容易剝落、質脆不堅,而且沒有價值。

搬運石塊


讓我們回到比加州淘金熱更久遠的以前,假定您是在古代埃及,正在建造金字塔。您的任務是搬運無數的巨石塊,從十公里外的河邊搬到金字塔的工地,如圖2-1所示。您有二十位工人,要在一百天之內完成。1


圖2-1您可以把軟體專案當成一塊巨石來思考。您可以一天推動一點,每天都比昨天更接近目標,您也可以做某些使移動速度加快的事情,用比較少的時間走完同樣的路程。

您被允許使用任何您喜歡的方法搬運石塊到目的地。您必須讓石塊每天平均移動一百公尺,或者是想辦法讓石塊移動所需的時間縮短。

有些小隊會立刻開始推石塊(時間緊迫嘛),試著用蠻力推動它。對付小的石塊這種方法或許有效,但是對付躺在沙漠中的巨石,這種方法就算推得動,也絕對不會快。如果每天前進十公尺,這個用盡全力的速度也許令人滿意,但事實是每天落後九十公尺的進度。「有進步」並不代表「有足夠的進步」。

聰明的團隊不會直接跳下去用蠻力推動巨石。除非是很小的石塊,他們知道凡事在動手做之前必須花時間做好計畫。分析過他們的任務之後,他們可能會決定先砍幾棵樹做成滾輪,如圖2-2所示。他們的計畫也許要花一兩天的時間,但有很大的可能性他們會加速巨石的移動。


圖2-2 論是移動巨石或創造電腦軟體,聰明的團隊總在行動之前做好計畫,讓往後的工作既快速又有效率。2

萬一旁邊沒有樹木怎麼辦?團隊得花上幾天的跋涉去河的上游找尋可用的木材?這幾天的投資是值得的,特別是用蠻力而只能做到實質的要求的一小部分時。

聰明的團隊在搬運巨石時,還會想到舖平道路。他們會想建好平坦的道路,而不要在沙地上推動巨石。這是個好主意,特別是有不只一塊巨石要搬運時。

更聰明的團隊也許一開始時採用滾輪木與平坦路的方法,不久後就發現滾輪木的數量有限,以致每隔一分鐘就得停下來將最後面那根滾輪木搬到最前方,但如果有多幾條滾輪木,而且讓一小部分的人專職把滾輪木往前搬,就可以避免巨石走走停停,而比較容易維持動力。

團隊隨後可能發現,推動巨石的人數受限於巨石的寬度,於是製作了一副馬具,讓一部分的人在前方推,其他的人在後面推,如圖2-3所示,這麼一來就有比較多的人可以加入,每個人的的負擔就比較輕,這樣不但速度較快,也比較容易維持體力。


圖2-3聰明的團隊不斷尋求更有效率的工作方式

石塊與軟體3


移動巨石和軟體有什麼關連呢?移動巨石是寫程式的比喻。如果您在100天之內要完成軟體專案,您是每天做百分之一的程式碼,還是設法讓寫程式的速度加快呢?撰寫程式碼的工作比搬運石塊要抽象得多,而且在專案的初期,進度是很難測定的。軟體專案很怕 「最後一分鐘症候群」,也就是團隊在一開始時沒覺察到時間的急迫性,初期浪費了太多時間,直到最後才以奮不顧身的瘋狂態度拼命趕工。把您的軟體專案想像成搬運巨石,很明顯您不可能期望最後才趕工的專案竟然可以成功。每一天,專案經理都必須自問:「我們今天的工作是否把軟體推進了一天的進度?如果沒有,我們是否把剩餘工作所需的時間減少了一天?」

另外還有一點是移動巨石和軟體相似的,就是不論您做過多少規劃,有一天您總得開始用力推石頭,也就是說,您必須寫程式。除非是很小的專案,寫程式總是有多得數不清的細節工作,多到很容易被您低估。

寫了再改的開發方式

與準備充分再開始動工相反的是寫了再改的開發方式,也就是不把重心放在準備滾輪木和舖平道路,而直接開始寫程式,這是軟體界比較常見的問題。有75%的軟體開發團隊開始做專案的方式是直接把自己撞向巨石,企圖用蠻力推動它。像這樣直接動手寫程式,而不先做好軟體的規劃和設計,我們稱之為「寫了再改」的開發方式(code-and-fix development)。團隊會這麼做的原因,有時候是因為開發人員太心急,想早日動工,有時候是主管或顧客急於看到具體的進度。

寫了再改的開發方式,就像純用蠻力推動巨石一樣,它的問題是開始的時候快,但不代表最後能早日完成,反而是懂得運用較好的開發方式的團隊,能夠將整體的生產力提升到更高的層次,最後將專案有效率地做完。他們先做好奠基的工作,把滾輪木墊在巨石之下,把道路整治順暢,準備好將大家的力量團結起來。相反地,寫了再改的團隊雖然開始得早,但這樣的蠻幹是很難持久的,通常很快就會造成千百個瑕疵。有些研究發現40%到80%的專案預算都被用在修改同一專案早期製造的瑕疵。

從圖2-4可以看出來,寫了再改式的團隊,其生產力會隨著時間而消蝕。專案剛開始時,只有一點點(或是沒有)的努力是投資在規劃和程序管理方面,少量的努力是無效的工作,但大部分是投入在寫程式。隨著專案的時程推進,修改瑕疵所佔的比例逐步增加。到了專案快結束的時候,團隊絕大部分的時間是花在修改自己早期所製造的瑕疵。4


圖2-4寫了再改的專案如果幸運的話,待修的瑕疵並不多,生產力降低但仍可維持住。而倒楣的專案所有的努力都被無效的工作、來不及的規劃和程序管理所消秏殆盡(摘自:《軟體專案求生手冊》馬康尼著,1988年)。

如圖2-4所示,寫了再改的專案中,幸運的因為瑕疵少,仍然可以勉強將進度向前推進而到達終點,而倒楣的專案則所有的努力都秏費在規劃與程序管理,以及修改先前的瑕疵,完全無法把程式的進度推前一步了。

這個悲慘的景象絕對不誇張。有幾項研究指出,軟體開發專案中,有25%的專案最後被取消了。在這些專案被取消的時候,它們全部都超出預算,而且陷入抓蟲、測試、除蟲的無窮迴圈中,所有的努力都是無效的工作。這些專案被取消的理由是,品質的低下已被認為是無藥可救,不如放棄。

諷刺的是,這些失敗的專案最後卻做了與成功的專案一樣多的規劃和程序管理。失敗的專案仍然得做瑕疵追蹤,來管理所有被發現的錯蟲。期限將至時,他們必須更小心地評估自己的軟體,隨著期限壓力的增加,他們每週重新評估,有時候甚至每天重新評估。他們花時間在穩住各方對本專案的期望,設法讓大家相信本專案能夠如期完成。他們必須實施程式品質標準,在加入一段新程式以前,確保不致傷害到整個軟體。由於這些工作都太遲了些,所以真正的效益是有限的。和失敗的專案比較起來,有效率的組織所採用的進行方式是截然不同的──事實上,專案如果一開始就走對的話,以上所述的失敗專案末期所做的事情,可能根本不需要。

如同圖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

正確的創新必須應用在合適的專案,並搭配合適的訓練,對它的期望也必須切合實際,作為長期策略的話,這樣做就會有非常好的效果。但是創新並不是變魔術,也不是容易的事。銀子彈也是一種蠢人的黃金,因為它有著一步登天的錯誤態度,經常為短期目標而採用,沒有合適的訓練,也沒有任何風險管理。就像黃鐵礦一樣,有經驗的管理者和軟體開發人員應該懂得不被它愚弄。

軟體並不軟

還有一種蠢人的黃金,就是誤以為軟體是軟的,應該很容易。原本硬體被稱作是「硬」體,是因為它不容易改變,軟體的「軟」,是指它容易改變。而事實上,電腦剛開始被發展出來時,軟體的確很容易改變。但是軟體系統已經進展到非常複雜,把軟體的「軟」字當成容易改變的觀念,已經完全過時了。

有幾項研究發現,需求的改變──企圖利用軟體「容易改變」的特性──是造成專案成本超支和時程延誤的最普遍因素。這也是專案被取消的主要原因之一,有些情況下,需求的改變會把專案的穩定性大幅破壞,以致專案根本無法完成。

讓我們舉個簡單的例子來說明軟體並不像人們想像的那麼「軟」。假設您的任務是設計一個能印五種報表的系統,但最後需求變成十種報表。您必須考慮的彈性──「軟」的程度──有下面幾項:

  • 最多十種報表嗎?會不會又再增加?
  • 將來的報表和最初設計的五種報表差異有多大?9
  • 每一種報表都要列印出來嗎?
  • 所有的報表都是一律以固定的順序印出嗎?
  • 應該允許使用者對報表能做什麼程度的修改?
  • 使用者可否定義自己的報表?
  • 報表會需要翻譯成另一種語言嗎?

不論軟體在設計時多麼小心、多麼高明,總會有一部分是不能改變的。如果只看報表的系統,當軟體修改時,以下的幾個地方可能會變成固定(硬)的:

  • 定義不只十種報表。10
  • 定義與原始五種報表不同的新報表。
  • 列印其中一部分的報表。
  • 照使用者定義的順序印表。
  • 允許使用者修改報表。
  • 允許使用者定義自己的新報表。
  • 將報表翻譯成另一種拉丁語系的語言。
  • 將報表翻譯成另一種非拉丁字母的語言,也許是從右到左的。11

非常有趣,我在完全不知道報表的實質內容、用什麼系統列印、資料如何產生,僅知道「五種報表變成十種」,就可以問出這麼一大堆「軟體之軟,軟何如」的問題,而且都是很一般性的問題。

開發人員應該把軟體做得愈軟愈好,這種說法聽起來很不錯,但是軟體的完全彈性就意味著要用無限多種變數,這是要付出代價的。如果使用者只是要五種固定的標準報表,固定把它們全部印出,每次一律以固定的順序、不變的語言,開發人員實在不必要把系統設計到允許使用者自定報表的彈性程度,這樣的高彈性軟體成本可能是標準固定式的100倍到1000倍,而使用者真正需要的只是基本功能的那一部分。使用者(包括顧客和管理者)有責任協助軟體開發人員精確的定義出本系統的彈性程度。

軟體彈性的成本是預存的備用款,限制軟體的彈性,可以節省下這筆錢,但是彈性若是不夠,通常會導致日後花費多到不成比例的成本。這是一個軟體工程上很困難的判斷:如何衡量已知的現時需求和可能的未來需求,然後決定本軟體究竟應該有多「軟」。

從蠢人的黃金中獲得的教訓

總結以上的探討,我們可以得出以下幾點非常明白的軟體方面的事實:

  • 軟體專案的成功與否,不是看早期的程式進度而定。
  • 即使您的軟體不是那麼攸關重大,您也不能為了降低成本或縮短時程而允許產品瑕疵。對於大部分的軟體而言,重點應該放在減少瑕疵,這樣成本和時間就會自然跟著下降。12
  • 銀子彈對專案的健康有很大的傷害,雖然軟體業的發展歷程似乎不斷宣稱新技術會有多進步。
  • 虛有其表的程序改善運動是另一種特別具有傷害性的銀子彈,因為它悄悄地侵蝕了將來真正想改善組織的企圖心。
  • 雖然軟體有個軟字,它事實上並不軟,除非您在一開始就為它預先設計好足夠的彈性,而這是很昂貴的。

軟體業已有五十年的發展歷程,其中的經驗讓我們學習到以上的事實,而我在後面的章節會詳細說明,最聰明的人和組織會把這些教訓謹記在心。在失敗的組織裡,人們不斷被蠢人的黃金愚弄,反而看不見事實真相。學著抗拒──並且持續地抗拒──蠢人黃金的誘惑,是軟體業必須學習的首要功課之一,這是建立真正專業的軟體工程的第一步。

微軟如何滿足客戶需求 視窗縮放
蠢人的黃金 加入書架 加入書籤 上一章 下一章 
0 0

相关博文

我的热门文章

img
取 消
img