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

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

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