第6周讀書筆記——讀《人月神話》有感

第六週讀書筆記——讀《人月神話》有感

形象化，這是我翻開這本書的第一感覺。做者花了大力氣來想出一些形象的比喻來闡述項目中的一些問題，讓不一樣資歷的讀者都能有所收穫。一開始書就將軟件危機比喻成「焦油坑」。使咱們生動形象地感覺到「軟件危機」的恐怖，就像史前巨獸在焦油坑中掙扎的慘狀，再一次說明了軟件開發的過程絕非坦途，而是坎坷不斷。

因爲做者的關係，這本書對於一個項目管理人員可能會有更大的收穫。即使如此，對於軟件開發方面的小白我來講，仍是有必定借鑑意義的。

人月神話，什麼是「人月」？那是一個用來估計工做量單位，大體跟舊時工人出工的「工數」一致。Brooks認爲，使用這種方法計量是有失偏頗的，由於1人工做1個月的效率並不等於（實際上遠有誤差）30我的幹一天的效率，只有當一份可分解且各部分不須要交互時才大體相等。而我認爲可能不止於此，由於有些想法須要時間的醞釀，有些環節比較依賴於試錯（好比說煉丹？）。可是一個較大的軟件必然須要一個較短的工期，因此說集體的配合是必不可少的。這時候首先須要保證設計概念的完整性，不管是怎樣的軟件，最好由同一個團隊主導，有一個清晰明確的模型和目的，以後全部人在這樣的框架下努力，也就是「一以貫之」。若是有創新、改變，也應該與基本的概念相吻合，實現團體的協力。然而須要注意的是，客戶的需求老是瞬息萬變的，就連開發軟件的團隊的思考都有可能隔三差五翻新。所以憑空思考極可能致使無用功，所以一份公共的框架文檔是必須的，一旦發現有抵觸的地方，就應該防微杜漸，若是用書中的說法，就是「外科手術式」的開發隊伍。其實以前我對項目很難有一個具體的規劃，可是一旦記錄下來以後，就顯得比較豐滿了。若是再對項目有所改動的話，內心也會不自覺地謹慎起來，不斷地提醒本身要當心。這也是項目文檔的另外一個做用，讓項目正式化，讓每一個參與者有一種儀式感。

有了一個好的綱領是成功的一半，但這還不夠，還要考慮到團隊合做中「人」的問題。團隊合做首要問題就是交流，Brooks舉了聖經中最偉大的爛尾工程——巴別塔爲例子，告訴咱們不能交流的團隊終將分崩離析。那麼咱們應該如何解決這個問題？我以爲如下幾點是不錯的選擇：第一點，須要團隊有一個共同的想法（目的），這樣的團隊在處理問題時可以避免在根本上發生衝突。第二，團隊成員之間應該以儘量多的形式進行交流，這看起來就是一句廢話，然而實際的項目中，許多人每每爲了追求我的的進度而埋頭苦幹，忽視了交流；或者是呆板的按期交流讓人倒胃口，不想開口說話。因此說不管是非正式仍是正式，是簡要的技術陳述仍是共享的工做手冊，都是可行的交流方式，並且這樣能夠有效避免人員缺失所帶來的嚴重技術斷檔。之前和別人和寫程序的時候也遇到過這樣的問題，各自負責各自的部分，到了整合的時候一旦有一我的缺席，整個組的進度就都停滯了，並且都是對此有心無力。

縱然是大師寫的東西，書上的某些東西也有過期之嫌。好比說書中的一些例子，這些例子可能對幾十年的讀者來講是很好理解的，可是對於現今的咱們來講又有些陳舊和難懂了。還有書中提到的「削足適履」一章，主要解決的是存儲空間的問題，可是就如今來講通常規模的軟件已經能夠忽略掉這樣的問題了，不須要像幾十年前同樣很是拘泥於空間問題。總的來講仍是獲益匪淺，讓我從管理層面從新認識了一遍軟件開發的過程，之後看問題應當會更全面些吧。