marktsen
這樣的速食者，試圖幾句話就打發了自己或者讀者那漉漉的飢腸。
閱讀這些文字給我帶來的收穫是：面對《人月神話》，除了表示五體投地的誠服，你既不能做正面言論（那是多餘），也不能做負面言論（那是找事）。
這是一本可怕的書。
我大概花了三周的時間來細讀這本書——也許很多人會說我應該花更多的時候或者讀更多遍——不過，這不是重點。我在書中印證和找尋思想，並為這本書寫下了數百個注釋。最終我很遺憾我讀了電子版本，因而注釋被寫在了文件中而不是書頁上。如果不是這樣，我將沒有任何方法扼制自己購買這本書的衝動。
下面的文字分成兩個主要的部分。一部分是如何讀這本書，如果你已經讀得很好，那可以跳過去，這是留給別人的。另一部分，則是討論那個著名的命題：沒有銀彈——似乎，不討論這個命題的話，連感想都不成其為感想，淪為空談了。
＝＝＝＝＝
一、《人月神話》的結構及其與組織
＝＝＝＝＝
我對《人月神話》的內容結構做了一些分析，大概如下：
章
內容說明
問題域
1
說明「程式
(program)
」不是「產品
(prodouct)
」，更不是「專案
(project)
」。說明程式設計師的心理與情緒因素——這是很重要的乙個話題。
2
專案的發起、評審與預估（錯誤的設定專案週期是最大的錯誤）。
「人月問題」：週期不因為人力投入而變短，事實上它可能更糟糕。
專案定義
3
十個人與幾百人面臨的問題是不同的。
團隊建設
4~5
從設計階段開始，即致力於獲得和維護概念的完整性。
團隊管理
- 方向與決策
6
專案過程中的一般性方法。
團隊管理
- 一般性方法
7
專案組織過程中的溝通問題。
團隊管理
- 溝通問題
8~10
編碼過程中的關鍵問題：
－專案複雜程度與需要編碼的資料呈指數級關係，反過來，減少編碼可降低系統複雜性
－資料的表現形式是程式設計的根本
－文件是必須且重要的，但往往不被關注（主要強調重要性）
編碼11
承認變更，承認從需求和設計期就開始的變化。
為應付變化而實現的原型系統。
專案定義
- 需求不確定
12
工具帶來效能。
13
強調測試，以提公升品質和保障專案目標。
專案管理
- 檢測/回顧
14
專案控制：進度與里程碑
專案管理
- 控制
15
文件：專案過程文件，包括定義、設計與實現（主要強調方法）
專案管理
- 文件化
16,17
沒有銀彈、再論沒有銀彈
18,19
前十五章的回顧（不包括「銀彈」的話題）
20
二十年後對上述命題的回顧（包括對銀彈現象的進一步解釋）
正如brooks
說到的，在幾十年之後的今天，這本書裡的現象或者觀點已經為整個行業所認知——無論是從實踐中的感受，還是從類似《人月神話》這樣的書籍中去獲知。其中大多數命題與結論，都在這幾十年的開發實施中被印證過，所以它們（我指的是這些命題與結論）備受關注。
我只重述
brooks
所講述到的兩點。我重述它們的原因，是認為它們還被關注得不夠：通過設計來獲得系統的一致性，以及更好的文件。
在brooks
的討論中，不但要「獲得」系統的一致性，還是盡力去保障它。
brooks
認為「獲得和保障」它的角色是並不是同乙個人：前者是結構師（第3～
4章所論），後者是專案經理（第
5章所論）。對於這兩個角色（或相似的角色），在第
7章「大型程式設計專案的組織架構」中，
brooks
提出：要麼產品負責人任總指揮，技術主管充當其左右手；或者反之。
brooks
認為前者更適於大型專案，後者更適於（相對）小型的專案。
在人月神話中對這兩個角色的用詞與我們現在（至少是翻譯過來的）用詞略有點不一致。事實上書中的產品負責人相當於現在的專案經理，而技術主管相當於技術經理（至少參與系統設計或直接由架構師擔任）。
brooks
並沒有低估（或錯誤認識）系統一致性和文件的重要性。但除了這兩點未被足夠重視之外，我想前十五章的內容不必再複述了。如果你不能理解我為什麼不再複述，那可能你需要更多的工程經驗或者理論基礎。除非你決心認為大師的一切都必須被象聖經一樣地重述，但那只是你個人的信仰，或者喜好。
下一節==>>
殺不死的人狼 我讀《人月神話》（一）
2007年03月12日 03 08 00 前言 marktsen 這樣的速食者，試圖幾句話就打發了自己或者讀者那漉漉的飢腸。閱讀這些文字給我帶來的收穫是 面對 人月神話 除了表示五體投地的誠服，你既不能做正面言論 那是多餘 也不能做負面言論 那是找事 這是一本可怕的書。我大概花了三周的時間來細讀這本...
讀《人月神話》
翻開扉頁，購書日期 2003.2.10。實在汗顏，且此類書，我的案頭還有許多。在兩周中抽出時間，翻看完了這本傳說中的經典。總的感覺，收穫並不多，雖說有些東西並未能完全理解，但大多在作者看來是未來的東西，已早成為現實。大致看來，沒有什麼新的概念。於是，也談不上讀後感，只是把看的過程中的筆記重新寫一遍，...
讀《人月神話》
為什麼中國的程式設計師總是在不斷學習新的開發工具 鑽研程式 而不能逐步提公升自己的視野 思維和經驗？摘自序 所謂人月 man month 是軟體開發中工作量的度量，然而它卻不是線性的，10個人10個月可以完成的工作，很多情況下100個人並不能在1個月完成。以下是我的理解與摘抄 斜體是摘抄 當人數增多...