[轉貼] 軟體專案

[Obb (不開心的基因)]

http://stupid77.com/?p=882

因緣際會在開發同事B的桌上看到一本書《人月神話》(The Mythical Man-Month)，第一
個反應(恕我孤陋寡聞.)，怎麼一個軟體開發進度管控的人會看這種”神話”故事呢？好
奇的拿起來翻閱了一下，我才知道這是一本暢銷了近三十年的書籍，講的就是軟體開發的
管理，活靈活現的，讓我一讀不可收拾…

我不是來推薦圖書的，因為過去幾年工作下來，除了主導過幾個軟體開發專案外，還有一
些管理上有待釐清的疑慮，正如先前跟一位軟體開發幾十年的前輩洽談之後，他也表示，
軟體開發雖然有幾十年的歷史，但仍舊是一個新興的產業，很多管理上的規範，仍舊沒有
一個標準，大家都是根據一些經驗，自己找出一條管理的路…

為什麼說軟體專案管理大不易呢？因為它具備了幾種特性，複雜性(complexity)、一致性
(conformity)、易變性(changability)、不可見性(invisibility)…

我想先表達一個觀點，我非常認同作者Frederick P. Brooks, Jr.所說的一句話，也是本
書的重要觀點，「在一個時程落後的軟體專案增加人手，只會讓它更加落後….」，分享
一下我過去帶領軟體開發的心得來對比《人月神話》一書的觀點吧…

我認為在軟體專案開發的過程中，第一個問題就是開發需求一再變動，而這個變動產生自
從頭到尾沒有很清楚的知道想要做的是什麼東西，因為一般企業普遍面臨著時間、資金的
壓力，經營成本不小，又有不少的競爭對手，因此一般都是先作再說，但這就造就了，開
發的過程需要變更需求，因為過程中原本預想的實現方式，也許時間過高，也許成本過高
，也許根本就做不到，而這是一種致命的傷害，輕則開發進度落後，重則做出一個四不像
的軟體產品，因此作者提到所謂的第二系統效應，以及需求規劃與溝通的重要性，他認為
一個軟體專案的開發，其實前期規劃的時間應為整個時程的1/3，而真正寫程式的時間其
實只有1/6…

第二點，溝通與進度掌控的重要性，延續上述的概念，規劃的時間至少是整個專案時程的
1/3，就是要把概念跟其他部門溝通清楚，並且跟每個開發的工程師也溝通清楚，甚至在
開發的過程中都需要不斷的跟進溝通，作者引用了聖經啟示錄中巴別塔的故事，因為所有
餐與建築巴別塔的人員彼此間語言不同無法溝通導致了失敗，突顯了溝通的重要性，經常
開發上一個小細節沒有溝通清楚，導致了南轅北轍的結果，這不僅浪費時間，也導致開發
成本的增加，所以除了溝通之外，隨時要掌控即時的開發進度，作者提到，「為什麼專案
會落後一年，因為每次落後一天」，就是如此的無關痛癢造成的，其實同樣的，李開復先
生在其《世界因你不同》一書中，也專章提到利用白板做為研發溝通工作的重要性…

第三點，或許這點有些爭議，至少對於公司的管理層，因為軟體專案的開發是一個團隊的
工作，團隊的合作很重要，團隊每個人各司其職，但他們必須對於這個專案整體都了解，
如果他沒有通盤了解整個專案的目的與邏輯，很可能他完成的程式是無法使用的，這就如
同外科手術一樣，然而，站在公司的立場，總是希望公司的商業機密越少人知道越好，這
必須要突破，或者找出一個折衷的方式，不然專案成果將跌破大家的眼鏡…

第四點，軟體測試以及系統商品化的整合過程，較有經驗的工程師懂得幫自己預留較多的
測試時間，因為軟體開發本身具有較高的不確定性，然而，如果公司所給的專案開發時間
有限，那麼測試以及整合的時間也受到壓迫，最終導致一個不穩定、不好用的軟體系統商
品，這點作者就提到寫程式的時間容易估算，但是除錯(debug)是個大學問，而除錯以及
軟體整合的過程，經常是造成整個專案延誤的主因，所以作者說，依據他的經驗，除錯以
及系統整合測試的時間應該安排一半的專案時間，因為這是軟體專案過程中，最難也最耗
時的部份，而這點對於不懂軟體開發的人來說，非常不可思議…

最後一點，開發工程師的素質以及人數，這也是本書《人月神話》的主要觀點，軟體專案
開發一般以「多少人、幾個月」的方式來評估成本，但是軟體開發並不像種田一樣，加越
多人進來進度就越快，相反的因為人越多溝通成本越大，更可能導致一個已經延誤的專案
，進度更慢，這是因為軟體開發是一種腦力智慧，中途換工程師或者新增工程師，往往需
要不少時間來熟悉溝通，因而導致了時間的延誤，再者，工程師的素質也有很大的差別，
作者就提到一個熟手甚至比十個生手還堪用，這也是軟體開發的一大特性，而這也就是作
者質疑以「人月」來評估軟體開發成本的一大弊端…

其實，進度延誤應該是經常會發生的事情，我想不盲目加人是個關鍵，更重要的是大家坐
下來檢討進度落後之因，透過分析找出趕上進度的方式，是否有哪些功能規劃有缺失，或
者是工程師對於需求的掌控度有落差，這才是根本的解決之道…

閱讀了《人月神話》之後，我又想到了一個更有趣的課題，軟體開發過程有苦有樂，而為
何我們所生活的世界中，卻有越來越多免費的open source誕生呢？甚至這些open source
更是多半走在科技產業的最前端，如果這些專案不是這樣的非營利團體來進行，而是在某
個知名的軟體公司之內，又將是什麼情況呢？








--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 120.28.107.74
→ PhoenixSu:只用1/6時間coding出來的東西....別再迷信專案管理了
→ PhoenixSu:也許可以改善一些事，但不是萬能也不是完美的
推 digitalking:很多主管真的認為人加的越多，進度越快，很難溝通
→ Obb:對阿。人越多..協調的成本越大
推 twk:1/6? 那指代表除錯要花 coding 3倍的時間吧~
→ juriolegend:那只代表離下次需求變更到需要翻掉重寫的期限只剩1/6!