人月神話閱讀筆記02
外科手術隊伍
最好的和最差的表現在生產率上平均為10:1，在執行速度和空間上具有5:1的驚人差異！簡言之，$20,000/年的程式設計師的生產率可能是￥10,000/年程式設計師的10倍。得出的結論很簡單：如果乙個200 人的專案中，有25 個最能幹和最有開發經驗的專案經理，那麼開除剩下的175 名程式設計師，讓專案經理來程式設計開發。所以說有經驗的程式設計師才是最廉價的勞動力啊。harlan mills 的提議提供了乙個嶄新的、創造性的解決方案2，3。mills 建議大型專案的每乙個部分由乙個團隊解決，但是該隊伍以類似外科手術的方式組建，而並非一擁而上。也就是說，同每個成員擷取問題某個部分的做法相反，由乙個人來進行問題的分解，其他人給予他所需要的支援，以提高效率和生產力。 有時候民主和平等也許並非是最好的選擇：因為首先在人在智力上、能力上就並不平等。外科手術式的團隊其實是延續了早期英雄式的程式設計風格：主要的程式設計師決定了專案的大部分內容，而其他人則成為他的副手，幫助他完成各項細節性的工作。
對於企業管理資訊系統軟體開發和大型作業系統的開發有一些差異，跟業務相關密切的資訊系統會更加強調需求的重要性，需求分析也是系統分析的重要內容。因此在這種情況下一般會劃分出專門的需求分析人員這種角色，或者說將需求和總體設計合併為系統分析員角色，當我們理清楚了業務架構和技術架構後，後續實現階段就變得簡單。
對於隊伍如何運作的問題，外科醫生和副手是核心保證高度的概念完整性，跟傳統按生命週期階段來分角色的團隊相比，我們可以看到乙個顯著的差別就是流水線式的溝通方式朝扁平的匯流排式溝通方式轉化。這種方式溝通更加高效，同時概念完整性更加容易保證，當出現衝突的時候外科醫生具有絕對的權威。
一位首席程式設計師、類似於外科手術隊伍的團隊架構提供了一種方法—既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。
擴建過程的成功依賴於這樣乙個事實，即每個部分的概念完整性得到了徹底的提高—決定設計的人員是原來的七分之一或更少。所以，可以讓200人去解決問題，而僅僅需要協調20個人，即那些「外科醫生」的思路。
對於協調的問題，還是需要使用分解的技術。在這裡，可以認為整個系統必須具備概念上的完整性，要有乙個系統結構師從上至下地進行所有的設計。要使工作易於管理，必須清晰地劃分體系結構設計和實現之間的界線，系統結構師必須一絲不苟地專注於體系結構。總的說來，上述的角色分工和技術是可行的，在實際工作中，具有非常高的效率。
這裡所講到的重點就是體系結構設計師要抽取出來組成核心設計團隊，其他人員是實現人員，這樣溝通的範圍將限制到到這20個人的核心團隊中，以保證高度的概念完整性，大大的提高溝通效率。
閱讀筆記 人月神話02
人月神話 主要討論的便是人和月之間的關係。並且怎樣處理系統開發的預估，正如作者所說 在眾多軟體專案中，缺乏合理時間進度是造成專案滯後的最重要原因。首先，我們對估算技術缺乏有效的研究。過於樂觀 第二，我們採用的估算技術隱含的假設人和月可以互換，錯誤的將進度與工作量相互混淆 第三，由於對自己的估算缺乏信...
《人月神話》閱讀筆記02
在專案完成過程中，一定要準確書寫專案工作手冊，這便利於日後的管理和維護，若工作人員對硬體或軟體的某一部分存在疑問，通過檢視工作手冊，即可快速解決問題。在講到工程專案中的管理問題時，文中提到三點建議，第一，小型專案中產品負責人和技術主管最好是同一人 第二，產品負責人作為總指揮，技術主管充當左右手的管理...
人月神話閱讀筆記02
繼續人月神話的閱讀。在書中，作者提到了關於外科手術式的隊伍。這點是我剛開始稍微有點不理解的。我們都知道，在現代的開發中，一般不會有個人開發的情況，畢竟乙個人不會將事情做得那麼全面，無論他是多麼的強大，個人能力是多麼的突出，他仍然會在一些情況下出現各種各樣的問題，所以，我們一般的都是採用的多人參與開發...