Square-Cal 3.0 版要在2.0 版上市后的10 個月發布，項目經理Mickey 與上司Kim 討論后
決定：他們將為項目組成員提供私人辦公室、最新型的計算機以及免費的碳酸飲料，并且要
求開發者在前8 個月按照預先設計好的接口各自開發、8 個月之后進行可視化鎖定，在最后
兩個月中完成系統集成。一個完美的計劃。
項目組成員各自做著自己的工作，而隨著可視化鎖定日期的來臨，他們開始進行代碼集成。
他們在可視化鎖定最終截止日期前一天的下午2 點開始工作，但很快發現程序不能編譯，更
不用說運行了。代碼在編譯時有數十個錯誤，而似乎每處理一個錯誤就會產生10 個以上的
新錯誤。他們一直干到午夜也沒有結果，只好決定第二天再說。
但測試發現問題的速度遠比開發人員解決問題的速度快，處理系統這部分的錯誤經常會導致
系統其他部分的問題。項目超期了，項目組成員在巨大的壓力下工作，士氣逐漸低落。最后，
整個軟件開發過程花了15 個月的時間，公司錯過了最佳的發布日期，市場份額也從第二位
下降到第四位。
生動的教材
看到上面的那段話，你有什么感想？我只覺得如有芒刺在背：在我主持開發的一個證券業務
系統中，幾乎完全相同的故事就發生在我們的身上。在項目開始時，我們有近乎完美的計劃；
到最后，我們的項目拖延了50%的時間，讓客戶極其不滿。你呢？難道你對這個故事沒有
似曾相識的感覺嗎？
這是《快速軟件開發：有效控制與完成進度計劃》中研究的第一個案例。在McConnell 的這
本軟件工程書籍里，這樣生動的案例共有數十個。通過這些案例，以及無數準確而有說服力
的統計數據，作者把“軟件工程”用一種精確的語言描述出來。在這里，軟件工程不是玄不
可及的空談，而是每天都發生在你身邊的故事。
作者在前言中這樣寫道：
項目客戶和項目經理對開發速度過慢的第一個反應經常是加大項目計劃進度的壓力，讓開發
人員超時工作。截至1995 年，有75%的大型項目和將近100%的超大型項目計劃進度壓力過
重，將近60%的開發人員說他們感到工作壓力在增加。美國的開發人員每周工作時間是48~50
小時，甚至更多。許多人認為工作負擔過重。
在這樣的環境中，軟件開發人員的總體工作滿意度在過去15 年中大幅度下降就不足為奇了。
項目的進度計劃依靠對開發人員工作的拼命擠壓來完成，導致開發人員工作負擔過重，他們
很自然會告訴他們的朋友與家人：這一領域毫無樂趣可言。
顯然這一領域還是有樂趣的。我們大多數人以前都從事過這樣的工作，因而我們并不茍同編
寫軟件只是為獲得報酬的說法。當然，在開發過程中的討論會上確實會有一些不愉快的事情
發生，但是這些不愉快大多會與快速開發的話題密切相關。
是該在軟件開發人員與項目進度這個海洋中設置一道堤壩了。本書中，我試圖樹立一個堤壩
標桿，確保大海那邊的狂潮不致大亂開發人員的正常工作。
讀者大可不必迷惑于本書的名字。所有的軟件工程方法，其最終目的無非是在保證產品質量
的前提下提高開發速度。這本書的主旨就是從軟件工程學的角度來加速軟件開發的過程。所
以，你完全可以放心的把“快速軟件開發”理解為“有效的軟件開發”或“實用軟件工程方
法”，沒有問題。
另一方面，由于本書優美的格式和豐富的內容（不要著急，我還會專門介紹這些），以及作
（譯）者認真負責的態度和幽默詼諧的語言，我認為它完全可以并且應該成為一本傳統軟件
工程（同樣不要著急，我會在后面解釋這個詞）方面的高級教材。
按照作者的說法，本書面向的讀者是團隊領導人、項目經理和程序開發人員。在閱讀本書之
前，讀者應該具有軟件工程方面的基礎知識。
傳統軟件工程的經典
首先應該解釋一下“傳統軟件工程”這個詞。必須聲明，這個詞并未正式出現在任何科技文
獻中，乃是我憑著自己對軟件工程的一點理解生造出來的，也沒有非常嚴格的定義。在這里，
“傳統軟件工程”是指1968 年德國NATO 會議之后產生的、以瀑布模型和結構化分析及設計
為代表的一系列軟件工程方法，其主要特征是強調生命周期前期的需求分析，不鼓勵后期的
需求變化。與之相對的，則是2001 年2 月“敏捷軟件開發聯盟”成立之后出現的各種敏捷
開發方法。它們的主要特征是不做過多的前期分析，鼓勵需求變化，甚至主動擁抱變化。其
代表性的方法就是著名的XP（極限編程）[Bec, 00]。
我也是一個程序員�？催^了不少的編程書籍，迄今為止對我的編程能力和思想影響最大的，
當屬《設計模式》[GoF, 95]。不夸張的說，一本《設計模式》，讓我的編程能力在兩個月內
提高了整整一個檔次。為什么會有這樣的奇效？Vlissides 教授曾經說過，設計模式的作用有
兩點：
1. 用一種相似的格式記錄所有人的經驗，方便后來人閱讀和理解。
2. 為開發者提供通用的詞匯表，方便開發者之間的交流。
從這樣的角度來看，《快速軟件開發》這本書中非常重要的兩個部分可以叫做“軟件工程模
式”（最佳實踐）和“軟件工程反模式”（典型錯誤）。盡管它們面對的是軟件工程領域而非
程序設計領域，但是它們同樣起著這兩點作用，對于軟件工程人員具有同樣重要的指導意義。
在本書的第三部分中，作者用了160 多個頁碼來介紹傳統軟件工程方法中的27 條“模式”。
在以往的軟件工程專著中，我曾經看到過這些方法中的一部分。但是作者不但將這些久經實
踐驗證的方法歸納整理起來，并且用一種統一的格式來描述它們：首先是效果，包括縮短進
度的潛力、可視性的改善、對風險的影響、一次成功的可能性、長期成功的可能性5 項量化
指標；然后是實施該方法主要的風險；最后總結該方法與其他方法的相互影響和必須作出的
權衡。只要有這樣一張表，軟件工程師就可以在一分鐘之內評估出一種方法是否適用于自己
的項目，并決定是否采用該種方法。
來看一個例子（摘自第28 章，“外包”）:
外包就是把軟件開發承包給第三方廠商而不是在公司內部開發。承包方在特定的領域有著較
豐富的經驗，能夠在給定的時間內投入足夠的開發人員，并且備有一個大的程序庫可提供重
用源碼。由于上述因素，公司可以很快完成一個新項目。在一些情況下，外包能夠節約開發
成本。
效果
*** 縮短原定進度的潛力：極好
*** 過程可視性的改善：無
*** 對項目進度風險的影響：增大風險
*** 一次成功的可能性：大
*** 長期成功的可能性：很大
主要風險
*** 把專業知識擴散到其他公司去
*** 失去對進一步開發的控制
*** 泄露機密信息
*** 丟失進度可視性和對進度的控制
主要的相互影響和權衡
文章來源于領測軟件測試網 http://www.kjueaiud.com/