jim yeh on 十二月 19th, 2007

沒有時程的預估,專案就無從管理;而依照筆者在實務上的觀察中發現,問題的核心並不在時程無法正確預估,而是在於對時程的預估抱持太過樂觀的想法,因而對專案進行了無效的管理。

Continue reading about 軟體專案的樂觀主義

     
jim yeh on 五月 23rd, 2007

一個有紀律的開發者必須不斷地專注在面對「現實」,認清問題,用「目前最合適」的解決方法來解決。「現實」代表解答問題的目標是顯而易見的,所以我們可以輕易地寫程式來驗證目標是否真的可以達到;而「目前最合適」則代表我們馬上可以把設計實作出來,並且用先前的驗證程式驗證出來,這就是設計的紀律的具體呈現。

Continue reading about 好的設計源自於紀律

     
jim yeh on 四月 20th, 2007

喲哪桑的「摩托車日記」清楚地道出藉由問對問題來找出適當的度量方法,在讚嘆學長的罕譬而喻之餘,也想到了同人當年度蜜月遊蘇州的一段經歷,剛好可以來說明「專案」的度量,來看看和學長的摩托車日記有何不同?

Continue reading about 旅行與軟體度量

     
jim yeh on 四月 14th, 2007

章子怡為軟體度量代言告訴我們軟體度量的 Gilb’s law,任何事物,只要它需要度量就會有方法可以量,只不過我們需要在度量成本與準確度做取捨。不過,最近在閱讀 Berkun 所寫的《專案管理之美學》時,書中對專案經理處於「流程與目標的混淆」現象的提醒也很值得讓我們注意: 有些處在這種情況下的 PM,會訴諸於量化一些不需要量化的事物。由於不確定該做什麼,或者害怕去做最需要做的事,他們會以次要事情占據時間。當 PM 與專案之間隔閡變大時,把注意力放在不必要的圖表、資料表、查核清單、以及報告的情形就會增加。PM 在某一時刻開始相信資料流程就是專案,這是有可能的。他們把焦點擺在不重要而容易做的事情上(試算表或報告),而不是重要而難做的事情上(程式設計成果或進度)。他們也許會自欺說,如果照著特定程序執行,然後把查核清單上的事做好,專案就可以保證成功(或者比較嘲諷地說,任何會發生的失敗,技術上都不是他們的錯)。

Continue reading about 軟體度量與數字陷阱

     
jim yeh on 三月 28th, 2007

之前我都會把我在網誌的文章轉貼在台科大 94EMBA 班網,其中〈有關「Stakeholder Management」的後續討論〉這篇文章林序學長回應: 木金兄果然厲害,拜讀所談,獲益斐淺. 小弟補充一點如下: 最新的 CMMI v1.2 版裡已將籌獲流程獨立出來,成為 CMMI-ACQ,即Acqusition 採購流程管理。與原來的開發流程 CMMI-DEV、以及新的CMMI-SVC 服務流程,合成所謂的互補薈集 (Three Complementary Constellations)。 CMMI-DEV 對於資訊系統/軟體開發流程提供了管理、度量及監控的指引,CMMI-ACQ 促使委外籌獲單位居於清楚認知及決策領導的地位。CMMI-SVC的重點則在於提供組織內部及外部客戶服務的參考模式。 看起來 CMMI 的標準,也在朝向提昇 StakeHolder 的參與在努力。 外包單位不可以自外於整個專案,CMMI-ACQ 與 CMMI-DEV 的流程互相對應,共同面對整個專案的成敗。 誠如學長所言,外包單位不可自外於整個專案,外包管理做不好,輕者績效不彰,重者損兵折將,其影響 stakeholder management 甚鉅,不可輕忽。 附記:上週六才發現,林序學長和喲哪桑學長早就認識,人際網絡真是四處連結的網路呀!

Continue reading about 學長對 Stakeholder management 的補充