? ? ? ? 早就聽說過這本書的大名了。在課上的時候老師就推薦我們去看這本書，這可是軟件書中的戰斗機，但是很慚愧，一直沒有去了解這本書，甚至有時候碰到這本書，只是感覺很熟悉的樣子，但是還是不知道到里面說的是啥。有一種疑問，老師怎么會推薦我們去看小說呢？人 月 神 話 這不是一些傳說嗎？直到去了解了這本書的內容之后，才發現根本不是這樣的，這是軟件開發人員必讀書目之一。因為這是一個程序員成長為大牛的必經之路，也是一個好的項目成功完成的必須了解的歷程。《人月神話》被評價為，“將技術書寫成散文集，把經驗教訓和經歷背景等一一道來”。這本書的名字并不是人類和月球之間的神話故事，而是軟件工程的一些迷思，人月是一個人一個月的人力單位。

? ? 通過本書我對進度安排和Brooks提出這個定律特別的感興趣，因為從未想到過編程竟然是這樣的。

??? 一．軟件工程的時間分配

??? 作者提出軟件工程中各個項目的比例應該如下：

??? 1/3 planning

??? 1/6 coding

??? 1/4 component test and early system test

1/4 system test, all components in hand

即關于進度安排，1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。

出乎我的意料，本來以為編程時間應該成為軟件開發中最耗時的部分，事實上卻是相反的，編程時間被分配了最少的時間。軟件項目團隊被建議，使用三分之一的時間對項目進行各種規劃、設計，實際的編程時間并不是主要時間部分，余下一半時間被用來進行各種測試，檢測、排除軟件中的各種問題。這也許就是現實中軟件工程和我們平時小打小鬧寫程序最大的區別，規范的規劃、操作，配套的文檔，嚴謹全面的測試階段，科學的時間任務管理。即使我們在現實中做不到那么專業，較早學到這些意識也是很好的。

??? 二．任務落后難道增加勞力不對嗎？

??? Brooks提出一個定律：

??? “給一個進度落后的軟件項目團隊中增援更多的人力，只會將進度拖后更多”

這個觀點完全顛覆了我的觀點，在之前我一直認為，對一個項目或者工程來講，如果落后了我們可以按照建筑上蓋房子的方式來完成我們的工程，可以增加一個一小隊，從而人多力量大，眾人拾材火焰高啊，必定會比原來的人進度快一些。但是看完Brooks這個定律后真的不再這么認為了，因為在項目開始后的一段時間內，這些參與開發的人雖然進程落后但是已經對項目比較熟悉了，如果現在在引入新的人，勢必會是老的員工培訓新的員工這樣會使老員工的時間減少，同時新的員工了解這個項目還得花時間，如果分配給員工任務后，員工還需要在這個基礎上再次適應，這樣必定會增加開發的時間。

在我讀這本書之前從未想到過完成項目的時間分配竟然是這樣，編程占得時間是最少的，也從未認識到增加人數并不能使一個進度落后的軟件項目按時或者提前完成。在讀到這里是真的讓我耳目一新，有種豁然開朗的感覺，雖然沒有編過大的項目也沒有按著上面的時間來安排自己的程序，但是，深度思考確實讓我對這個話題深感興趣。

轉載于:https://www.cnblogs.com/zhaochenguang/p/8505355.html

總結

以上是生活随笔為你收集整理的《人月神话》---1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。