jim yeh on 一月 19th, 2010

在軟體開發的過程中,有沒有方法可以避免我們浪費心力在無謂的堅持上,然後用比較簡單而又有效率的方式來完成我們的工作呢?經過與同事上面的對話,同人想到運用到我在分享會中所提到的觀念與實務,可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來,也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。

Continue reading about 掌握設計演進的節奏

     
jim yeh on 十月 26th, 2009

這篇文章是投稿 ZDNet Taiwan 的文章原稿,由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤?〉、〈如何在系統異常前發現錯誤?(下)〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯,內容可能與 ZDNet Taiwan 約略有所不同。 前一陣子有兩個與資訊系統失常有關,而且眾所矚目的新聞事件,也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜,在系統上線之後才發現系統無法正常運作,造成系統使用者的困擾,同時也會讓人對系統可靠度與穩定度失去信心,而增加系統的失敗成本。 雖然平心而論,想要事前預料系統可能發生的問題,並加以預防或因應其實並不容易,因為開發系統,尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前,就能夠發現問題並採取適當的行動來解決它,應該就能減少系統的失敗成本。因此,看到戴爾與台北捷運內湖線的重大系統異常,讓筆者想探討如何在系統失敗前發現錯誤,以避免系統失敗的巨大損失。

Continue reading about 如何在系統失敗前發現錯誤

     
jim yeh on 二月 4th, 2008

對於開發者而言,總是要到驗收前才發現程式有問題可真是可怕的夢魘呀。然而,這樣的現象為什麼老是一而再,再而三地發生,到底是什麼地方出了問題呢?

Continue reading about 總是要到驗收前才發現程式有問題?

     
jim yeh on 十一月 16th, 2007

驗收測試與 TDD 有何不同?一個是由客戶端來驗證軟體是否符合他們的品質要求,另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地,「做 TDD,還是驗收測試?」的重點並不在測試,而是「開發者應該自己驗證程式,還是該仰賴客戶來幫你找程式缺陷?」。換言之,就是我們常聽到的一句話:品質是檢驗出來的,還是設計出來的?

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 三月 26th, 2007

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

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 所扮演的角色