###### tags: `讀書會筆記`
# 人月神話：Chapter 17-19

## 第17章 再論沒有銀彈

針對讀者在第16章-沒有銀彈提出的意見，作者在本章節做出回應與分享。同樣重點少少QQ，以PM的角度來說可以應用的範圍也不多。

## 第18章 <人月神話>的主張：是真是假？

主要做前面1-15章的摘要整理，我就不列了XD，直接由第19章說明歷時20年這些觀念的變化。

## 第19章 <人月神話>二十年

主要講述哪些觀念歷時20年之後仍然適用、或需被淘汰：

* **概念整體性**
1. 建立前後連貫的介面
2. 由架構設計師負責整體概念的一致性
3. 將架構獨立於實作(implementation)與實現(realization)之外
4. 子系統間的界線需可明確定義，可將架構設計師的工作再細分

**=> 討論：智金輸出的模型通常可以優化原始作業流程中的其中一個環節，專案以人力節省的效益為多，針對比較成熟的專案未來是否考慮可以改善整體作業流程，而非優化一小塊而已？(當然這不在智金的守備範圍XD，而需要業管來做)**

* **避免過度設計**
1. 為廣大的使用者群做設計，但需要在不同類型的使用者中做出權衡
2. 功能容易過度膨脹
解法=>定義使用者群、讓架構師去猜測使用者群各項屬性的頻率

* **瀑布模型是錯誤的，須採用漸進式開發模型**
1. 瀑布模型假設專案只會從頭到尾將流程過一遍，代表錯誤全部都只會發生在實現階段，所以錯誤的修正工作都可以只安排在模組測試和系統測試的過程；另一個謬誤是假設人們可以一次性建構出整個系統，能在所有實驗設計、大部分程式編寫、許多模組測試完成後，結合所有城市片段來進行整合性的系統測試
2. 實際上，任何東西在進入時現階段並寫出程式碼前，需反覆經過多個從架構到實作的循環週期
3. 漸進式開發模型，先建立輪詢迴圈(polling loop)，每個功能都用最簡化的方式讓他運作，再回頭過來從第一個模組開始細緻化，必要時也須面臨從頭修改最初的驅動迴圈，甚至是模組介面；優點是可以很早開始進行使用者測試、可採取有多少錢就做多少事的策略

* **資訊隱藏，而非公開給所有人**
1. 之前作者認為全部程式設計師都要了解全部的構想，每人手上都有一份專案工作手冊的副本
2. 反觀現在，作者更認同Parnas的主張，認為模組需要被良好的介面封裝(encapsulate)起來，模組內部是程式設計師私有的，不應公開，而現今常用OOP物件導向程式設計來落實資訊隱藏
* 模組定義為一個軟體實體，只能透過特定操作方法來存取
* 模組改成成抽象資料型別，衍生出許多物件(object)，也提供統一模組介面的思考與界定
* 透過繼承(inheritance)，使類別得以透過他在類別階層中的父類別來具備預設的特定屬性

* **人力與工時並非線性關係，人月是神話**
1. 當規劃時間比最佳時間多或少都會導致成本增加，當規劃時間比最佳時間少3/4，幾乎沒有專案能成功
2. 對一個時程已經落後的專案，增加人手會耗費更多成本，但專案"未必"會拖更久
3. 若要新增人力進來專案，短期內必定有負面影響，且須花時間事先思考人力該如何投入、訓練、配合工具支援，並將所有人的工作重新分割

**=> 討論：除了因業管因素而延宕的專案，是否有因智金本身因素，如模型開發時間比想像中多而延宕的專案，當時怎麼解決？是否有新增人手？**

* **其他：用人、授權、套裝軟體**
1. 用人的智慧、如何留住人才、彈性組織
2. 往下授權，提供團隊自由與權利