主要是對於第三章《外科手術隊伍》的閱讀感想。
當然一開始看的時候並不了解這章中的外科手術隊伍是什麼意思，只知道本章強調精幹隊伍的重要性，後來再一次閱讀便有所收穫和了解。
我們都知道醫學上外科手術隊伍是乙個團隊，這個團隊的人員每個人都有自己的任務以及責任，各司其職，分工明確。因此在軟體專案團隊中也是如此。
而且外科手術隊伍不會出現做手術時有人在那站著看，或者只幹些端茶送水的活的人，因此在專案團隊中，減少不必要的人員很關鍵。
1、這裡的「外科手術隊伍」主要是由外科醫生、副手、管理員、編輯、兩個秘書、程式職員、工具維護人員、測試人員和語言專家組成，只有十個人的精幹團隊，有各自的分工。對比與軟體專案開發中，精幹的10人團隊比一般的500人的團隊要更好。主要是因為在該小組中，最好的和最差的表現在生產率上平均為10:1；在執行速度和空間上具有 5:1 的驚人差異！
簡言之，$20,000/年的程式設計師的生產率可能是$10,000/年程式設計師的十倍。如果乙個 200 人的專案中，有 25 個最能幹和最有開發經驗的專案經理，那麼開除剩下的 175 名程式設計師讓專案經理來程式設計開發。
2、對於真正意義上的大型系統，小型精幹的隊伍太慢了。
同樣有兩年經驗而且在受到同樣的培訓的情況下，優秀的專業程式設計師的工作效率是較差程式設計師的十倍。
3、實際上，絕大多數大型程式設計系統的經驗顯示出，一擁而上的開發方法是高成本、速度緩慢、不充分的，開發出的產品無法進行概念上的整合。
4、一位首席程式設計師、類似於外科手術隊伍的團隊架構提供了一種方法——既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。
閱讀筆記 人月神話02
人月神話 主要討論的便是人和月之間的關係。並且怎樣處理系統開發的預估，正如作者所說 在眾多軟體專案中，缺乏合理時間進度是造成專案滯後的最重要原因。首先，我們對估算技術缺乏有效的研究。過於樂觀 第二，我們採用的估算技術隱含的假設人和月可以互換，錯誤的將進度與工作量相互混淆 第三，由於對自己的估算缺乏信...
《人月神話》閱讀筆記02
在專案完成過程中，一定要準確書寫專案工作手冊，這便利於日後的管理和維護，若工作人員對硬體或軟體的某一部分存在疑問，通過檢視工作手冊，即可快速解決問題。在講到工程專案中的管理問題時，文中提到三點建議，第一，小型專案中產品負責人和技術主管最好是同一人 第二，產品負責人作為總指揮，技術主管充當左右手的管理...
人月神話閱讀筆記02
繼續人月神話的閱讀。在書中，作者提到了關於外科手術式的隊伍。這點是我剛開始稍微有點不理解的。我們都知道，在現代的開發中，一般不會有個人開發的情況，畢竟乙個人不會將事情做得那麼全面，無論他是多麼的強大，個人能力是多麼的突出，他仍然會在一些情況下出現各種各樣的問題，所以，我們一般的都是採用的多人參與開發...