搬運石塊

讓我們回到比加州淘金熱更久遠的以前，假定您是在古代埃及，正在建造金字塔。您的任務是搬運無數的巨石塊，從十公里外的河邊搬到金字塔的工地，如圖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%的專案最後被取消了。在這些專案被取消的時候，它們全部都超出預算，而且陷入抓蟲、測試、除蟲的無窮迴圈中，所有的努力都是無效的工作。這些專案被取消的理由是，品質的低下已被認為是無藥可救，不如放棄。

原文转自：http://www.ltesting.net