軟體開發專案常以人月來衡量工作量，這種度量暗示著人手和時間是可以互換的。這種「人多力量大」的想法是一種一廂情願的虛妄神話，布魯克斯法則：向滯後的軟體專案追加人手會使得進度更遲緩
概念完整性。乙個整潔、優雅的程式設計產品必須向它的每個使用者提供乙個條理分明的概念模型，這個模型描述了應用、實現應用的方法以及用來指明操作和各種引數的使用者介面使用策略。使用者所感受到的產品概念完整性是易用性中最重要的因素。
結構師。結構師負責產品所有方面的概念完整性，開發用於向使用者解釋使用的產品概念模型，概念模型包括所有功能的詳細說明以及呼叫和控制的方法。結構師是這些模型的所有者，同時也是使用者的**。在不可避免地對功能、效能、規模、成本和進度進行平衡時，卓有成效地體現使用者的利益。
將體系結構和設計實現、物理實現相分離。為了使結構師的關鍵任務更加可行，有必要將使用者所感知的產品定義——體系結構，與它的實現相分離。體系結構和實現的劃分在各個設計任務中形成了清晰的邊界，邊界兩邊都有大量的工作。
體系結構的遞迴。對於大型系統，即使所有實現方面的內容都被分離出去，乙個人也無法完成所有的體系結構工作。所以，有必要由一位主結構師把系統分解成子系統，系統邊界應該劃分在使子系統間介面最小化和最容易嚴格定義的地方。每個部分擁有自己的結構師，他必須就體系結構向主結構師匯報。顯然，這個過程可以根據需要重複遞迴地進行。
史前時代的焦油坑吞噬了成千上萬個力大無窮的巨獸，今天的大型軟體專案則令無數龐大的開發團隊陷入無從逃脫的窘境。軟體程式按其規模和目標的不同，對開放過程的要求也有極大的不同，這給軟體開放這一職業帶來無窮樂趣，同時也是這一行業苦惱的根源。雖然優秀的程式設計師的工作效率往往數倍於平庸的程式設計師，但若是缺乏合理的配置，優秀的成員未必能構成優秀的團隊。大型軟體開發專案的團隊需要和外科手術組一樣妥善分工，各司其職協調配合。人們在第乙個系統成功完成後，往往會在開發後續的第二個系統時犯冒進的錯誤。第二個系統經常成為過度設計或畫蛇添足的犧牲品。要避免這種錯誤，必須在第二個系統開發時審慎地考查技術環境的變化，廣泛進行交流和溝通，聆聽各方面的建議，確立嚴謹的估算和規劃。 架構設計通常由核心設計小組完成，將設計概念傳達到整個開發團隊是貫徹概念完整性的必然要求。以system 360的開發經驗為例，要貫徹概念完整性，需要在團隊中保持良好順暢的溝通和交流，採用形式化定義等技術來確保概念被精確地定義和傳達。獨立的測試小組是系統質量的良好保證。如果缺乏良好有效的溝通和協作，成員間難以有效的配合，團隊專案的目標就無法實現。清晰的工作文件，明確的組織結構，合理的職責分配，都是大型軟體專案最終成功的保證。 最大化資源利用率，減少不必要的資源占用，合理規劃，使軟體系統在資源有限的情況下依然保證了良好的效能，從而實現良好的可伸縮性和健壯性，這能體現軟體開發人員精湛的設計技巧。巧妙的資料結構往往能大幅度地儉省資源耗費，提高系統執行的效能。變化是永恆的，使用者的需求和期望在變化，開發者對使用者需求的理解在變化，適用的技術也在變化，故而最佳的解決策略也可隨之變化。軟體開發團隊應靈活地配置人力和資源，適應開發過程中的種種問題。程式的複雜性、使用者需求的不確定性、軟硬體技術環境的發展等因素導致了軟體維護工作並非總是能夠百分之百地獲得回報。
《人月神話》讀後感03 人月神話
本書第一章提到，過去幾十年的大型系統開發猶如乙個焦油坑，很多大型和強壯的動物在其中劇烈掙扎。各種問題糾結在一起，團隊的行動越來越慢。他們大多開發出了可執行的系統，但只有極少數的專案滿足了目標。究其原因，首先，我們對估算技術缺乏有效的研究，總是假設 一切都將運作良好 但事實往往不是這樣，在我們程式設計...
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...