jim yeh on 三月 28th, 2007

面對變革,組織轉型及改造是企業賴以生存的有效途徑;然而,本書作者丹娜‧左哈爾(Danah Zohar)卻提醒我們小心「轉型的謊言」,他認為大部分的轉型計劃由企業領導階層擬定,希望進一步控制市場或員工,視轉型為打擊對手的進階手段。而這些企業領導遵循著僅知的方法晉陞至領導階層,但實際上自己卻畏懼改變,所以轉型實質上不會有太多根本基礎的改變。 因此丹娜指出了任何改變都要有意義的關鍵,也就是說改變的人應該瞭解問題所在、必須瞭解為何需要改變。「改變」和「意義」這兩個概念必須要連結在一起,也就是瞭解企業本身的「身為」(Being)及「作為」(Doing);同時她也強調沒有速成的轉型,真正的轉型須從企業本身意義思考,核心價值、組織管理、人力技術及相關的基礎建設都必須作根本而徹底的重新創造,將會是一條長遠而漫長的道路,而透過新科學-「量子思維」的概念運用在企業管理上,可以帶來更具有創造性的作法。 身為資訊科技專業人員的我,由於我也是具有理工的背景,對於如何將科學的認知運用在商業領域上,一直都有相當濃厚的興趣。而量子物理學一直都是我感興趣的領域,它比較像我所相信的「新時代」 (New Age)的思維-「未來是不可預測的,存在的意義是讓我們參與、體驗並共同創造自己的實相及我們所認識的世界」。而這本書的觀點不謀而合地直指這真理的核心,同時也帶給我許多關於組織管理的一些創見及對於過去工作經驗的自我省思,可說是獲益良多。

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 的補充

     
jim yeh on 三月 27th, 2007

在〈石頭閒語:類別繼承、介面宣告與模組混成(mix-in)〉,石頭成提到他的學習經驗: 當年在學 Java 時,我便感覺到介面宣告規避了鑽石繼承問題,卻無助於提高程式碼再用性。 Java 的介面宣告,只是規避而非解決鑽石繼承問題。……在動態語言中,雖然多數都採用單一繼承機制,卻又毫不死板,憑藉著動態性提供繼承機制以外的程式碼再用方式。 Ruby 的混成(mix-in)機制就是一個聰明的例子。這個概念也開始被程序員應用於其他語言之中,例如我嘗試於 JavaScript 和 PHP 中實踐混成概念 (PHP 實踐 mix-in 概念之可行性)。 我對所謂的 mix-in 並不熟悉,於是循線看了〈PHP 實踐 mix-in 概念之可行性〉,我發現石頭成所用的實作方式,類似 GOF Design pattern 的 State pattern,利用多型介面與自委託(self-delegate)技巧,可以讓物件同時具有多種型別的行為能力,甚至還可以動態改變物件的型別。 如此看來,石頭成對 Java 介面的負面觀感其實是出自於對 Java 介面使用的誤解。提高程式碼的再用以 Java 技術而言,不是只能靠繼承而已,繼承的誤用只會造成程式碼的僵化與脆弱而已,而實作介面來面對多重繼承的問題,那並沒有比誤用繼承高明到那裡!Java 或其它採用靜態型別的物件導向程式語言,解決一個實體有多種型別的問題,不是靠繼承樹或重覆實作介面,而是利用組合(Composite)角色子型別(Role subtype),即所謂的角色塑模(Dealing with roles),介面的使用是用來除耦-讓設計與實作分開而不是用來當成類別多重繼承的替代方案。

Continue reading about 物件導向繼承與程式碼的再用

     
jim yeh on 三月 26th, 2007

在軟體開發過程中,工具雖然不足以取代人力,但有效地使用適用的開發工具,卻可以讓我們軟體開發得到加分的效果。 不過,在企求開發工具為我們加分之前,我們必須要思考如何才能先拿到基本分數。

Continue reading about 善用工具為軟體品質加分

     
jim yeh on 三月 25th, 2007

最近 William 君公布了他即將在四月份告別單身生活的喜訊。這真是一個好消息,一直以來,看他的文章令人受益良多,在此恭喜他,希望 William 夫婦賢伉儷琴瑟和鳴。 William 君結婚的日子,可是相當漂亮的黃道吉日耶。

Continue reading about 黃道吉日與良辰吉時

     
jim yeh on 三月 22nd, 2007

哈米尼斯對我在〈對專案假設的看法〉回應說: 我文中所提的這一個假設「專案執行的過程中,兩方所簽屬的任何文件,皆屬有效文件」,這樣的說法並不是說客戶不能改變Scope(事實上我做過的案子很少有驗收時的規格會和合約完全一樣的),而是為改變提供一個正式的法源,至少不要在驗收時落人口實說變更Scope的程序是有問題而被卡來卡去。 其實我並不反對用合約或其它經雙方簽署相關文件來提供變更的正式法源,但合約或其它經雙方簽署的相關文件並不能算是專案假設,它們是一種會對專案成果發生影響的約束。所以用專案管理的專業術語來說,應該稱它們為專案限制而非專案假設。雖然合約條款或經雙方簽署的文件內容,這些限制其背後都會有相對的假設,但真正要有效地解決專案問題,應該是去識別問題背後的假設,並進一步地去管理它們;而非一味地運用根據假設所發展出來的限制來約束專案成果。因為後者的做法會讓人看不見問題背後的問題,以致於對失去問題焦點。 哈米尼斯隨後在他的網誌發表了〈專案管理:再論「專案假設」〉來闡述他對專案假設的看法,他認為: 如果把做專案當做是我們寫證明題,而證明的過程就好像是專案執行和驗證,在被驗證之前,其實我們甚至都可以說這一個題目(專案)都不是真的。當用這樣的角度在看時,把專案假設當做是一種專案的限制,我是認為並無不可。 但我認為,可不可以「用做專案來比擬解證明題」,其實是取決於專案所要處理的問題而定。如果專案的決策是屬於結構化(structured decision)的,亦即對問題有良好的定義、變動性很小、不確定性很低、過去有處理過類似問題的經驗及問題困難度不高,那麼做專案就相當於解證明題一樣:一切可以照著預先所規畫的來做,專案的假設就像證明題的已知不會改變,當然可以把做專案來比擬解證明題一樣;但往往軟體專案的決策多半都屬於半結構化(semi-structured decision)甚至是非結構化(unstructured decision)的,它們沒辦法像解證明題一樣那麼簡單,在過程中我們會發現原先建立的專案假設會隨著專案的變動而變得不再成立,將會對專案的成果造成某些影響。因此,在整個專案生命週期中,我們必須要注意假設所衍生出來的不確定因素,以防止或減輕它們對專案所造成的衝擊,否則對於專案要解決的問題就很有可能會發生此題無解的窘境。

Continue reading about 評論「專案假設」的相關討論

     
jim yeh on 三月 22nd, 2007

關於 software review,在看了喲哪桑學長對我的文章所寫的回應後,發現學長對我想要表達的意思有些誤解。學長提到: 我個人不是很同意依照形式的多寡來分類review, technical review, peer review, etc. 雖然我對那種分類法的感覺不好, 我也建議少這樣說, 但的確有些人是這樣用的. 而我的原文是這麼說的: 對於一個開發流程未慣例化的組織而言(即未達 CMMI ML2),推行 review 可能會遭受極大的反彈;而對於一個開發流程未針對現況做回饋控制的組織而言(即未達 CMMI ML3),review 的推行可能比較徧向形式審查而較少的技術審查或 peer review。 其實我要討論的重點並不在於 software review 形式的多寡,事實上,我文中提到的形式和學長所說的形式並不是同一件事。徧向形式審查的意思是審查的要點在於看工作產出有沒有遵照開發組織規章或專案計劃所規定的文件規範及慣例,對於工作的內容卻無法做到實質上的審查;而所謂的技術審查或 peer review 則是除了工作產出的形式是否符合規定外,審查的重點更會擺在工作產出的實質內容,我常稱這種審查叫做實質審查,用來和形式審查區隔開來。

Continue reading about Software review 與軟體品質文化

     

喲哪桑學長在〈Review vs. Inspection — 亂談軟體工程的正名運動〉中對〈創造 software review 的需求〉有所回應,他提道: 沒有壞就不要修,本是西洋古老的諺語。只不過,我還是會擔心,等到壞了,修也來不及囉! 我可以理解學長的 concern,但以 problem-solving 的角度來看問題,第一步一定要先弄清楚問題是什麼。再來問這是誰的問題,在問題擁有者並不想解決問題時,貿然要對方改變只會招致埋怨而對問題沒有任何的助益。

Continue reading about 評論喲哪桑對〈創造 software review 的需求〉的回應

     
jim yeh on 三月 20th, 2007

哈米尼思對〈工具在 software inspection 所扮演的角色〉提出看法,他提道: 曾經在書上看過這樣的例子 software inspection 演變成 另外一種型式的專案批鬥大會 由於專案的壓力使然,會使得PM也許會對某些工程師的工作產出提出意見,進而產生批鬥 當然,我並不是反對 software inspection ,而是在做這件事的同時,需要明確的規劃和目標設定 如同文中提到的「反思」,是正向看待問題並思考,進而產生好的循環 回過頭來,還是在於公司或組織是不是有建立適當的文化和訓練,並且這項投資要能夠被管理階層所認同,講來講去~ 還是管理上的問題啊 批鬥大會其實是專案衝突的一種形式,當專案團隊成員有感受到彼此意見分歧、對方干擾的行為及產生負面情緒時,就會展開團隊的衝突過程[1]。雖然衝突太多會對團隊的決策共識及接受度有負面的影響,但如果團隊完全沒有衝突,大家想法相同,團隊內呈現一言堂的現象,會導致決策品質的低落。適度的衝突,可混合不同的意見或建設性的批評,藉由不同觀點的了解,和有創造力的選擇自由,而增加決策品質[2]。 所以說,批鬥大會不見得是壞事,當問題發生,早期發現早期治療才是最根本的問題解決之道,避免批鬥並沒有解決問題,卻代表了我們只是讓問題延後發生的駝鳥心態。在解決問題的過程中,就算是相互對立,但只要清楚對立的目的是為了解決問題而非相互攻訐,在態度上可以相互尊重,在言詞上避免用言語攻擊或迴避問題[3],這樣的溝通與對立的目的是要剌激團體正向思考,以促進問題有效解決的良性循環。 附註   H. Barki and J. Hartwick(2004), Conceptualizing the construct of interpersonal conflict. The International Journal of Conflict Management,Vol. 15, No.3, pp. 216-244[↩] 蘇麗玉(2005),系統開發人員與使用者在資訊系統發展過程中之衝突與系統績效之探討-以銀行業為例,銘傳大學資訊管理學系碩士論文。[↩]面對重要且困難的溝通與解決令人失望的問題可參考《關鍵對話》與《關鍵對立》兩本書[↩]

Continue reading about 衝突與 software inspection

     
jim yeh on 三月 16th, 2007

在Chui-Wen Chiu’s Note: 〈程式碼檢驗〉看到: 基本上我蠻認同程式碼檢驗這個步驟,不過這個步驟不應該是由人來作,更不應該全部交由一個人來作,而是交由一套工具來處理,如此可以省去不必要的人力支出,而且也可以將 Knowledge 分享給 Team 的每一個人。 站在節省人力支出的立場,用工具幫我們檢驗程式碼的想法看起來好像不錯,如果這樣做可以維持程式碼品質而降低人力的花費,當然是最好的選擇,但程式開發的價值首重創意性思考,但工具卻只能預先設好檢驗的規則,在已設定的規則範圍之外,還是有很多 defect 是會被工具忽略掉,但這些 defect 是不應該被忽略的,因為等到讓它們擴散就麻煩大了。因此把程式碼檢驗的工作,交由一套工具來處理,對於改善軟體品質而言,其實是不夠的。 亦即在檢驗程式碼的工作,工具並不能取代人力的,工具最多只能站在輔助的地位,因為審查程式碼並不是 routine job,這個工作需要的是程式實作的專業知識與技巧,要用人的肉眼直接來逐行檢驗,不能由工具代勞。

Continue reading about 工具在 software inspection 所扮演的角色