software management

1. 人月神話
軟體專案管理之道
2019.06 閱讀筆記

2. 如何評估軟體開發投入？
• 人月(man-month or person-month)指的是「一個人要花
幾個月」才能完成軟體開發的單位，通常用來評估一件軟
體專案的大小，也是目前許多外包軟體的計價方式。
• 本書作者認為，用人月來衡量工作規模大小是危險的，使
用的前提必須是在人力與工時可以互換的情況之下。只有
當工作可被切分，且投入工作的人彼此不需要溝通，人力
和工時的互換才算成立。
• 以成本會計為基礎的時程預估技術，使我們誤把工作量和
專案進度混為一談，人月是個危險並很容易就遭誤解的迷
思，因為它假設人力和工時可以互換。

3. 開會的目的與技巧
• 同一個小組的不同窗口定期開會，不用再花時間
教那些搞不清楚狀況的人
• 這個小組的每個人都跟結果息息相關，沒有人是
顧問的腳色，每個人都須做出切身的承諾
• 當問題浮上檯面，將同時由內外正反不同觀點來
尋求解決方案
• 正式的書面提案使問題得到重視，迫使決策的進
行，避免會議的內容前後矛盾
• 將最後的決定權明確授權給首席系統架構設計師
，使妥協和延宕得以避免

4. 作者管理大型軟體專案的經驗
• 把工作切分給更多人做，會造成額外的溝通代價。透過人
力配置和專業分工來減少溝通量。
• 規劃軟體開發專案的文件，只有把事情真正寫下來，遺漏
和矛盾之處才會顯露出來，並導引出更多細節的決定，同
時也能將決策傳達給他人
• 形成一個利於改變的組織，分派給每個人的工作必須要讓
他學習到新東西，好讓整個團隊的實力保有技術上的彈性
• 在大型專案中，每個小組傾向為了自己的目標，只追求局
部的最佳化，而不會思考給客戶的整體效果
• 專案要成功，人的品質以及人的組織與管理，遠遠比他們
所運用的工具或技術來得重要

5. 軟體測試與監控
• 獨立的產品測試小組，負責檢查軟硬體是否符合規格，每
個團隊都應該具備一個這樣的獨立技術稽核小組，以確保
其公正性。
• 軟體維護必須搭配更多系統測試，理論上，每修正一個錯
誤之後，都應該將之前的所有測試案例(test case)通通拿
來測一遍，以確保修正錯誤的過程中沒有破壞到原有的正
常功能，要做到像這樣完整的迴歸測試(regression test)，
付出的成本是相當高的。
• 計畫監控小組是一個值得投入的配置，它將提醒大家留意
容易疏忽的落後時程，並指出其中關鍵性的部分，這相當
於是一個能夠幫助軟體專案避免釀成大災難的早期預警系
統。

6. 產品定義清楚是核心本質
• 把產品定義清楚是非常關鍵的工作，有太
多太多的失敗都源自於自始至終都搞不清
楚要做的是什麼東西。
• 詳細的功能定義、詳細的規格說明，規範
良好的防錯設施與錯誤處理技術，都有助
於減少系統錯誤的可能性。

7. 創造活動的本質
• 將概念的構造設計成型
• 以具體的介質(medium)加以實作
• 透過實際上的運用，與使用者進行互動

8. 名言佳句
• 為什麼專案會落後一年？因為每次落後一
天。
• How does a project get to be a year late?
…One day at a time.
• 在一個時程已經落後的軟體專案中增加人
手，只會讓它更加落後。
• Adding manpower to a late software
project makes it later.