繼續人月神話的閱讀。
在書中，作者提到了關於外科手術式的隊伍。這點是我剛開始稍微有點不理解的。我們都知道，在現代的開發中，一般不會有個人開發的情況，畢竟乙個人不會將事情做得那麼全面，無論他是多麼的強大，個人能力是多麼的突出，他仍然會在一些情況下出現各種各樣的問題，所以，我們一般的都是採用的多人參與開發，最少的都是2個人，像我們進行完的雙人的結對開發，還有現在進行著的多人的團隊開發。這樣做的原因一是因為受到我們現在開發專案的大小的限制，還有我們人員的限制，使得我們必須這樣，更重要的是，現在的開發中需要這樣的簡單的小型的精幹的團隊，因為這樣去開發的時候會覺得開發效率更加的高，但是，隨著專案的發展，會需要越來越多的功能和人員，這樣就逐漸形成了外科型的隊伍。
記得在當時閱讀《構建之法》的時候，我們看到過關於一些團隊模式的介紹。在我深入讀這本書的時候，發現，對於本書中所說的隊伍，還是有很大的優勢的。在書中，作者提到的是這樣的：大型專案應該分為若干部分，每個部分，由乙個外科手術式的團隊完成開發，在每個團隊中，只有一兩個人主要負責開發設計工作，其他人負責「外科醫生」的協助工作，所有不一致的觀點由「外科醫生」負責統一，通過這種人員的專業化分工實現高效開發。 這點是讓我能夠恍然大悟的事情。我本來一直是認為這種模式是乙個不好的模式，沒想到在作者的筆下通過案例分析，很好的給我們指點了迷津。這讓我想到以後的工作，是不是大多數都是這樣模式，在我們進行一項工作的時候，我們就會進行這樣分配，為了進行工作的充分的資源利用。
像是我們現在的團隊，也是要盡量去向這個模式去靠近，因為我覺的，我們當前的團隊在開發的時候很具有盲目性，在開發的過程中沒很是容易做一些超過自己工作之外的事情，當其他人在去做同樣的事情之後，發現這樣的事情已經被人做了，因此就不會再繼續去做這個事情，這樣會形成乙個團隊的惰性，對於整個團隊的發展是很不利的。因此，我們需要貼近於這中狀態，就像是老師說的那樣，乙個大腿可以抱，但是要抱得有意義。
閱讀筆記 人月神話02
人月神話 主要討論的便是人和月之間的關係。並且怎樣處理系統開發的預估，正如作者所說 在眾多軟體專案中，缺乏合理時間進度是造成專案滯後的最重要原因。首先，我們對估算技術缺乏有效的研究。過於樂觀 第二，我們採用的估算技術隱含的假設人和月可以互換，錯誤的將進度與工作量相互混淆 第三，由於對自己的估算缺乏信...
《人月神話》閱讀筆記02
在專案完成過程中，一定要準確書寫專案工作手冊，這便利於日後的管理和維護，若工作人員對硬體或軟體的某一部分存在疑問，通過檢視工作手冊，即可快速解決問題。在講到工程專案中的管理問題時，文中提到三點建議，第一，小型專案中產品負責人和技術主管最好是同一人 第二，產品負責人作為總指揮，技術主管充當左右手的管理...
人月神話閱讀筆記02
在軟體工程學習過程中，老師會時不時向我們提起一些關於軟體工程的著作。在軟體領域，很少能有像 人月神話 一樣具有深遠的影響力。本書作者布魯克斯為人們管理複雜專案提供了頗具洞察力的和獨到的見解，意味深遠。我選擇了一本 人月神話 40周年紀念版 來閱讀，希望能有所收穫。巴比倫在希伯來語中意思是 變亂 如果...