最近開始閱讀《人月神話》，讀到“外科手術(shù)隊”章節(jié)，我就明白了這本書能如此受青睞的原因。
人月理論是不能應(yīng)用于項目計劃的，人數(shù)和時間并不是成簡單的反比：人數(shù)的增加，則意味著不同思維的增加和交流的增加，當(dāng)這一切默默的糾纏在一起后，項目就漸漸沉入沼澤。
傳統(tǒng)的項目計劃和任務(wù)分配方式，是將一個系統(tǒng)分為多個子系統(tǒng)，將每一個子系統(tǒng)的設(shè)計和編碼分配給其中的一個或者幾個programer。這種模式下我看到的現(xiàn)象是，一個無比混亂的組合，沒有一個人擁有這個組合的完整的概念，包括main-programer；每一個programer只是隨機(jī)（雖然他們都經(jīng)過認(rèn)真的思考，并有可能選擇了最佳的位置）的將子系統(tǒng)插入到這個組合之中，唯一的期望是子系統(tǒng)可以工作。
我想這一景象很多人會心有感觸，這一傳統(tǒng)的模式還是很普遍的，因為我就身在其中。
外科手術(shù)隊是這樣一種模式：一個或者兩個主刀醫(yī)師，main-programer或者framework-designer，負(fù)責(zé)定義整個系統(tǒng)的概念、約束和控制流，并將他們的工作成果交給programer去實現(xiàn)。就好比建筑師統(tǒng)一設(shè)計好了藍(lán)圖，然后由建筑隊負(fù)責(zé)施工。試想如果建筑隊里面的每一個家伙都興趣盎然的給建筑的某一部分進(jìn)行自己獨(dú)有的設(shè)計和實現(xiàn)，并為了組合而相互妥協(xié)，那最終建成的東西將會是何物？
想必多數(shù)人對外科手術(shù)隊模式的反映是：“所有的樂趣都被main-programer和framework-designer剝奪了”，“programer豈不是淪為coder，毫無前途可言”。但其實不是，外科手術(shù)隊并沒有外包那么夸張，主刀醫(yī)師只是定義了整個系統(tǒng)的概念、約束和控制流，但是并不出設(shè)計文檔之類有關(guān)實現(xiàn)的東西，并且任務(wù)仍舊以子系統(tǒng)（已經(jīng)被定義和約束）的形式分配，因此programer能在指定的約束下進(jìn)行創(chuàng)造和實現(xiàn)。
有關(guān)外科手術(shù)隊模式，我有過類似的經(jīng)驗。一個little-demo，3人的合作，我提取了其中所需要的所有的類，并為每一個類指定了接口，以及安置位置，也就是概念、約束和控制流。我擁有整個系統(tǒng)的完整的概念，但是我沒有任何實現(xiàn)，我可以把它的每個子系統(tǒng)交給任何人實現(xiàn)，因為我清楚一切都能工作，不能工作又是誰的責(zé)任。每個programer可以選擇任何實現(xiàn)方式，并在實現(xiàn)方式上進(jìn)行設(shè)計。
OK，有關(guān)《人月神話》的內(nèi)容暫時先這么多吧。

PS：另一個考慮的事情，是重構(gòu)。似乎沒有多少項目組，會在自己的項目計劃中為重構(gòu)保留時間，理由多半是進(jìn)度和成本···但問題的嚴(yán)重性在于，傳統(tǒng)的項目計劃模式（非外科手術(shù)隊模式），所組合出來的系統(tǒng)，本身就缺陷冗雜，如果沒有適時的重構(gòu)，病情只會越來越嚴(yán)重。因此我期望的模式是，為項目計劃保留重構(gòu)的時間，當(dāng)項目版本進(jìn)行到一定程度，大多數(shù)組員都認(rèn)為系統(tǒng)需要重構(gòu)的時候，就給出一個重構(gòu)的版本周期，全員投入到重構(gòu)當(dāng)中。
重構(gòu)會影響進(jìn)度和成本，卻沒有多少證據(jù)證明這個論斷：因為人們在嘗試有益的事情之前，都直覺上的拒絕在重構(gòu)上浪費(fèi)時間，這只是一種只能看到短期利益的目光罷了——設(shè)計和編碼并不是系統(tǒng)開發(fā)的全部！

再PS：老久沒有更新BLOG了，結(jié)果排名之類的反而又升了一點····無語