Ch9 地盡其利，物盡其用Ten Pounds in a Five-Pound Sack
一、空間就是金錢
空間與時間的trade-off取捨。
軟體系統的大小對使用者的成本負擔影響非常大，軟體開發人員必須設定空間大小的目標(size target)，進而控制程式大小、發展節省空間的技術。
二、程式大小的控制
對專案管理者而言，程式大小的控制一部分是屬於技術上的工作，另一部分是屬於管理上的工作，必須研究使用者及他們的應用情形，據以決定開發出來的系統該有多大，接下來就要細分出子系統，每個子系統也都要設定出空間大小的目標。
作者所遇到困難所學到的
第一個教訓是：必須做好整體空間規劃(Total size budget)，這不單包括了常駐空間規劃(resident-space budget)，背後跟這些有連帶關係的存取動作也應該一併納入考量。
第二個教訓是在規定每個模組的大小之前，先精確定義出這個模組該做的事。
第三個教訓是，如果團隊夠大，溝通通常是一個很大的問題，且每個人未達自己的目標，只求局部上的最佳化，應該是要以最終呈現給客戶的整體效果為主，兼顧系統的整體觀點與使用者導向的設計。
三、節省空間的技術
第一種是重疊(overlay)使用記憶體。即動態載入，只有在需要的時候，才將副程式載入記憶統中。
第二種是在空間與時間上做取捨。對同一個函式而言，能用的空間越多，執行速度越快。
四、資料的呈現方式(資料結構)是程式設計的本質
更棒的技巧則是要靠創新。又小、又快、又好的程式幾乎都源自於策略上的突破，而非技巧上的取巧。當程式設計師為了空間不足而苦惱時，有時從程式碼中跳脫，回頭省思自己所用的資料結構是一種好方法。
Ch10 文件假說 The Documentary Hypothesis
一、假說
假說本來是沒有理論根據的，只是一種推測，建立假說之後所要做的事情就是去驗證它。本章藉由比較其他領域的管理工作，歸納出管理文件的共通性，來驗證文件假說。
在成堆的書面資料中，有一小部分關鍵性的文件記錄著任何專案管理的核心工作，這類文件本身可用來檢查列表、狀態監控，而這些工作是身為管理者最重要的工具，為了讓思考集中並言之有物。
二、規劃電腦產品的文件
開發一個電腦產品有以下關鍵文件是需要準備的：
a.目標b.產品規格c.時程d.預算e.組織編制圖f.場地配置g.預估、預測、定價
為了進行市場預測，必須先有初步的性能描述並估計定價，根據市場預測，就可以得到市場需求量的估計值，需求量估計值搭配產品的零件數量，就可以計算出製造成本，據此就可推算出平攤到開發階段的平均單位成本與固定成本，而平均單位成本又可用來推算定價。
三、規劃軟體開發專案的文件
任何管理工作所關心的都是人、事、時、地、物、錢。
Conway定律：「從事系統設計的組織所設計出來的系統將會像是組織溝通結構的翻版。」
四、為何要有正式文件？
第一，把決策寫下來是最基本的事情，才能引導出更多細節的決定。
第二，文件有傳達決策給他人的作用。
文件提供管理者一個資料庫和檢查列表，由於管理者的基本工作就是要保持組織裡每一個人都朝著同一個方向前進，所以每天的主要工作應是溝通，寫文件可以大大減輕管理者的溝通負擔。
管理者的工作就是制訂計畫，然後實現它，但唯有將計畫寫下來，整個開發工作才能精確的推動與溝通。這些文件廣泛的涵蓋面與關鍵地位如果在一開始就能被明瞭，文件便形成是一種友善的工具，可以更方便確立出要走的方向。
CH 11 失敗為成功之母Plan to Throw One Away
‧一個成功且永續經營的組織，勢必是學習型組織。
‧使組織利於改變->建立代理人的機制(輪調職位)。
‧要形成一個利於改變的組織，比設計一個利於改變的系統還要難，分派給每個人的工作必須能夠讓他學習到新的東西，好讓整個團隊的實力保有技術上的彈性。
‧像是貝爾電話實驗室，就廢除了所有的工作頭銜，每個專業員工都算是「技術人員的一份子」。
‧又如IBM建立了一個雙梯式(daul ladder)晉升結構，左右對稱的職位在制度上的位階是平等的。
CH 12 神兵利器Sharp Tools
‧身為專案經理，必須建立起一套運作哲學，一方面不但要配置資源以建立共同工具，同時也必須認知到特殊化工具的需要，不吝於他所帶領的團隊建立屬於他們自己的工具。
‧程式庫與程式的管制
第一，是控制，也就是將程式的一份副本歸管理者擁有，只有他有權認可這份程式的異動；
第二，是將程式的整合與交付(release)從局部自由區域(playpen)裡予以正式區隔(formal separation)出來並演進(progression)。
沒有留言:
張貼留言