在王建民老師的建議下，我大概瞭解了一下《人月神話》這本書。在看這本書之前，和其他人一樣以為是一本神話色彩的書籍。知道看了之後才知道是一本有關軟體的書籍。

   Brooks博士為人們管理複雜專案提供了最具洞察力的見解，既有很多發人深省的觀點，又有大量軟體工程的實踐。本書內容來自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的專案管理經驗，該專案堪稱軟體開發專案管理的典範。

   人月神話（英語：The mythical man-month）：這部分講述人力（man）和時間（month）並不體現線性關係。指出以大量人員和較短的時間，並不能縮短軟體的開發進度。一窩蜂的作業方式無助於軟體生產，且會製造麻煩，產生出更差的軟體。向進度落後的專案追加人力，只會使進度更加落後。因為新進的人員需要時間瞭解整個專案，而增加額外的溝通消耗。軟體開發的多少人蔘與和完成時間不成正比，過多的人蔘與並不一定能縮短開發時間。如戰爭，部隊多，人多並不是關鍵，更多需要武器的先進，戰術，兵多後方便的補給就得多。如是參與軟體開發的人增加，軟體的花費將提高，剛參加這需要時間瞭解專案，給軟體管理帶來了不協調。

       人月神話的核心法則：概念完整性和架構師。Brooks認為，一個整潔、優雅的變成產 暑期讀書筆記&影視劇點評精選讀書筆記 影視劇點評 書評 舞臺藝術點評 讀後感 品必須向它的每位使用者提供一個條理分明的概念模型，這個模型描述了應用，實現應用的方法以及用來指明操作和各種引數的使用者介面使用策略。概念的完整性是易用性中最重要的因素。而架構師，則是負責保證產品所有方面的概念完整性的，架構師設計的是能夠讓使用者理解產品概念的模型，這包括所有的功能的詳細說明以及呼叫和控制的方法。它就像電影的導演一樣。 

      外科手術團隊。在接受相同的訓練、同樣都是兩年資歷的情況下，優秀專業程式設計師的生產力要比差勁的程式設計師好上十倍。短小精悍團隊是最棒的——儘可能用最少的人。兩人團隊，其中一人當領導者，這通常是最佳的用人方式。以短小精悍團隊開發真正大的系統就太慢了。絕大多數大型軟體系統的經驗顯示，使用一堆人蠻幹的方式最耗成本、最慢、最沒有效率，做出來的系統在概念上也最不完整。軟體編碼實現過程中，需要不是人多，而是少而精的優秀程式設計師，編碼員。所以整體程式設計師的素質很重要，有必要培訓提高他們的素質。

     軟體系統可能是人類創造中最錯綜複雜的事物，往往一個很小的功能，其實也需要開發人員的架構設計方面的完善，對其它模組的影響及擴充套件,以及程式碼編寫工作。使用者在前臺可能看到的只是幾個文字，實際是中開發人員日夜奮戰的結果。很多時候，客戶的需求修改，在他們眼裡看起來是如此地Easy,可他們卻忽視了很多他們看不到的因素---當然，這不是說怪我們的客戶。我只是覺得，只有大家彼此溝 通，彼此理解，才會做出精品來。

我覺得學姐寫的非常棒！