《人月神話》讀書筆記之四

本週繼續閱讀《人月神話》，本週度過的部分是第十章和第十一章（「提綱挈領」和「未雨綢繆」），如下是對該兩章的感想。
1、提綱挈領

提綱挈領一章描述的是經理與文件的關係。做者一開始便給文件作了定性：文檔的某些部分包含和表達了一些管理方面的工做，其準備工做是集中考慮並使各類討論意見明朗化的時刻，其跟蹤維護是項目監督和預警的機制。

做者經過「計算機產品的文檔」、「大學科系的文檔」和「軟件項目的文檔」，來闡明文檔如何展開上述工做。

咱們能夠看到，全部的文檔都包含的項目是如下幾個：目標、機構分類、技術要求、時間表、預算。這幾項幾乎包含了一個工程中全部的管理要素。

文檔的必要性在於它的三個具體角色：書面決策、溝通渠道和數據基礎與檢查列表。第一項使得工做規範化、工做目標清晰化（目標、機構分類、技術要求），第二項使得決策被團隊成員所知曉，而第三項則可讓經理對項目所處的狀態有一個大體的瞭解（時間表、預算）。

 

2、未雨綢繆

未雨綢繆的英文是「Plan to Throw One Away」，所以這個中文翻譯不太恰當。實際上這一章講的是，應該實行實驗性開發，而且隨時作好丟棄本來成果的準備，而不是把第一次開發所得的產品提交給客戶去使用。

實際上對於大多數項目，第一次開發的系統頗有多是太大、太慢或者是難以使用的，且新的技術和概念的產生極可能使已有的系統開發出來就已通過時。解決辦法簡單粗暴——從零開始，設計一個更靈巧、方便、小巧的系統。可是實際上，在開發以前，這些問題是沒法獲得解決的，畢竟項目經理不能未卜先知。

所以，這個問題變成了「是否拋棄原型，亦或將原型直接發佈給客戶？」，對此，做者的結論是「爲捨棄（變動）而計劃，不管什麼時候，都必定要這樣作」。

如何變動計劃系統呢？做者描述的很少，而惟一被強調的一點是：使用高級語言和自文檔技術，以減小變動引發的錯誤。

變動引發的問題，最大的一點就是BUG，而維護系統、修復BUG的過程，被做者形象地稱做是「前進兩步，後退一步」，由於維護系統消除BUG之時，會以20-50%的概率引進新的BUG。而解決方式則是，使用能消除、至少是能指明反作用的程序設計方法，且儘量使用較少的人員和接口。