《人月神話》書摘

Chap 1 焦油坑

• 最後出現的錯誤往往最難纏。程式設計宛如掉入焦油坑一般越陷越深，完整的軟體系統產品，可能是開發程式時間的九倍之多，程式寫完並不代表軟體開發完成，期間的測試與系統整合才是苦難的開始。


• 寫程式的樂趣在於創造新的事物。但在達到完美的境界之前，有一段苦難需要度過，先把工作作成功，才有機會得到更多實質上的權力。

Chap 2 人月神話

• 過渡樂觀看待軟體開發，忽略的溝通與介面的時間複雜度，往往是專案延後的首要原因


• 人力跟工時是不可互換的，也就是說，如果一個人可以五天完成，不代表五個人可以在一天完成。越多人要花越多時間溝通


• 系統測試的時間往往被忽略，在成熟的專案規劃，系統測試的時間往往超過一半甚至更多，但往往被忽略。寫程式的時間反而容易估算，只佔1/6而已。卻往往誤解為為是專案的大部分時間。


• 就像七分熟的牛排，需要的時間是固定的，如果加大火力，只會等到一邊焦掉、另一邊不熟的結果。該有多少時間，專案經理必須堅守立場，不該過渡配合壓榨團隊，這只會造成品質低落的惡性循環。

Chap3 外科手術團隊

• 精兵政策，程式設計師的好壞之間差異很大，最好和最差的生產力是10:1，年薪兩萬元的程式設計師，產能可能是年薪一萬元程式設計師的十倍


• 越多人進行專案，將導致更長的時間拖延，採用精兵政策，一個首席程式設計師(chief programmer)，搭配一個小型輔助團隊來幫他加速產能，才是最好的方法，就像外科手術的過程一樣，有主治醫師負責主刀，其餘人員都是協助他處理相關的庶務與加速工作進行，而不是去搶走首席的風采。

Chap 4 專制、民主與系統設計：

• 將架構設計獨立於實做以外是取得整體性強而有力的方法


• 架構旨在說明做什麼，而實做則是說明如何作。


• 先讓架構師把產品架構設計好，在交由實做人員進行，在架構的限制之下，實做仍有創意發揮的空間，而且會更有效率。就像蓋房子一樣，先畫好設計圖，再找施工團隊。


• 人力切割為架構設計、實做和實現三部分。這並不意謂會花更多的時間。由經驗可知剛好相反，整個系統的設計不但進行的更快，而且花在測試的時間會比較少，垂直分工將大幅減輕水平分工所產生的負擔，其結果也將大幅簡化溝通。

 

待續.....Fin~