[Weinberg - Quality Software Management][Book 4][Ch 12] 流程原則

個人看書喜歡跳來跳去，這次直接跳到第四冊啦！

軟體工程大師溫伯格在談軟體管理學的前三本書，內容主要都是在導引如何建置優良的軟體開發，直到第四本書他開始談要如何在一個發展規模龐大組織及舊環境的體制下，我們該如何進行變革。

第十二章講述的是流程原則，目的在於用方法論來克服人的惰性，關鍵在於任何環節都需要被掌握，然後怎樣的情況算是有所掌握，以下是摘要：

Note：

• 專案中的每樣東西必須是顯而易見的，包含程式碼、計畫、需求、設計、測試計劃、測試結果、進展、所有的書面資料...
• 當你發現任何一件成果看不到，或"無法接受檢驗"，一定要停掉那件事情，並開始進行矯正。要避免"吉米是唯一知道那裏面有什麼東西的人"這類情況，先派人協助吉米，然後請吉米把事情記載於文中，如果吉米拒絕，就拿掉他。看不見的事情絕對不會安頓下來。
• 通過獨立審查前，沒有一樣東西是真實的。
• 你不做評量的東西，絕對會不受你控制。
• 不要讓評量使得團隊負擔變重；不要讓評量在本質上變成一種目的；不要進行你不評估與採取行動的評量；一定要讓評量的數量變少，可能加入一種就要刪掉一種。一定要讓評量保持簡單；一定要使評量變成每一個人的責任；一定要堅持開始就作評量；一定要找到某件方法去評量，不然就換掉你的評量者；一定要挑選有意義的事情來評量(例如Lines of code就是沒有意義)；一定要定期檢視評量；一定要把評量當作是那些需要你注意之前的指標；一定至少指派一名專人進行評量，兩個人更好；一定要編列評量預算；一定要用原始(primary)評量而不用解釋性(interpreted)的評量。
• 產品原則：如果你不必滿足需求，管理就毫無問題。
• 產品可能是程式，但程式不是產品。
• 不要讓每件事情都等到軟體完成了再去做。一定要把產品的每個部份(交付成果、輔助文件)都放入計畫中，也要放入作為計畫源頭的流程描述中。一定要盡早開始產品的每個部分。
• 回饋已連續方式進行。模型的各部份不能太大(否則回應緩慢)，而且各部分必須穩定(否則回應不可預期)。穩定性原則涵蓋這兩項需求：流程的每一部分都必須是可以受控制的系統。
• 穩定性原則說明測試不是一個階段，而是每個階段內建之控制流程的一部分。

延伸閱讀：

• 溫柏格的軟體管理學，第一卷，第七章，把穩軟體的方向
• 溫柏格的軟體管理學，第三卷，第九章