如雲隨之

08/09
今天來說說，我上班以來，從自我學習的東西

人月神說(The Mythical Man-Month)
是由「IBM 360系統之父」佛瑞德·布魯克斯（Fred Brooks）在1975年所出版的一本書
裡面談論有關程式開發管理的相關課題。
 
裡面提到了一個經過了30年，程式開發界還是常常遇到的現象，也就是「人月神話」
 
舉個例子來說，若是鴻x在中國的公司，富x康
1萬人，一個月，可以產出5萬台NB
某月月中，客戶追加，半個月內要增加5萬台的產量，這時主管們該怎辦呢？
很簡單，把人數增加至2萬人，就只需要半個月就可以產出5萬台NB(不要跟我說因為跳樓，所以不可能)
 
所以，同理可證？
一個程式專案開發，5人需要2個月
開發1個月之後，發覺時程落後了
為了能讓專案如期完成，那麼，把開發人員增加到10人(這裡給個前提，那10人程式能力相同)
是否可以縮短開發時間為1個月呢？
 
答案是不可能的
作者提到：「使用人月必須要在人力與工時可以互換的狀況下。而且要當工作可以切割、投入工作的人不用溝通，人力與工時才能互換。」
 
程式專案的開發，是有其連續性、是需要溝通的
在程式開發中途投入新人，就需要額外的溝通時間與教育時間
其公式是：團隊內部交流公式：n(n - 1) / 2
 
所以囉，作者提出一個結論：時程已經落後的軟體專案中增加人手，只會讓它更加落後
要避免這個情況的方法，就要有良好的時程規劃，考慮所有的因素。而且程式人員要有勇氣不要妥協，堅持自己預估的時程
 
作者也提出程式設計師會遭遇到的問題
1. 過於樂觀，假設是一切都會進行的很順利
這也常常發生在我身上，看這問題第一直覺很簡單，可是沒有想到一個bug，就可以花上一天時間也無法解決。然後就延遲了後面本來假設可以順利進行的部分。
 
2. 單一程式和專案系統認知不夠
程式設計師對單一程式的開發一定駕輕就熟
而要開發一個專案系統時，複雜度就會上升
因為不只只注意本身這支程式就好，也必須注意到是否會跟其他程式相配合、衝突
不要認為那些是SA系統分析師(System Analyst)的工作
 
一個有sense的程式設計師，不應該只專注於眼前的單一程式
應該從宏觀的角度，從高處來看這個專案
對於當前開發、往後維護才能更為輕易
 
一個專案開發有三大層面
需求分析、系統分析、系統設計
我希望我能慢慢跨足的前2項，從幕後走到幕前
跟那些女性式使用者們好好的溝通一下XD