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

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

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