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

2008-04-09 04:09:08来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

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

搬運石塊


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

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

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

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

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

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

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

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

石塊與軟體3


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

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

寫了再改的開發方式

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

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

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

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:ERP初阶(三):MRP基本原理

下一篇:CMM—软件产业发展的必由之路