jim yeh on 五月 8th, 2009

在台灣,品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外,以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」,讓開發人員認為品質是品質部門的責任,而品質部門則認為提昇品質不是他們的責任,以為最多只能做到知道產品有問題,而不知道如何改善它們,只能退回到開發人員那邊來解決。

Continue reading about 聚餐也談品質流程

     
jim yeh on 一月 9th, 2009

如果穩定的程式真的是偶然的,程式的穩定似乎只能依賴運氣而不是人為努力,事情真的是這樣嗎?其實這位噗友太過強調環境變化的隨機性,卻忽略了適應環境變化,程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的,雖然演化的過程是偶然、但其最後結果卻是必然。換句話說,穩定的程式是偶然下的必然。

Continue reading about 穩定的程式是偶然?

     
jim yeh on 八月 13th, 2008

新政府團隊似乎想要在就職典禮的活動上,改變舊制以發揮新創意,營造出耳目一新的感覺。但實際上卻反而把問題複雜化,造成一團混亂。這讓筆者想到在軟體開發過程中,也經常出現同樣的情況。改革的困難正是考驗著領導者的領導能力,他應該如何領導團隊來進行成功的改革呢?

Continue reading about 新官上任三把火

     
jim yeh on 五月 23rd, 2008

這一陣子再次看到這篇文章時,突然覺得應該將它在網誌中登出來,以明確呈現出個人對這個主題的看法。不過,同人想在登出這篇文章之前先提出我最近對軟體開發角色定位所體會到的兩個觀點。

Continue reading about 軟體開發角色的一篇評論

     
jim yeh on 三月 11th, 2008

在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。但至於要如何增進良好設計架構的產能呢?

Continue reading about 專案時間不足,如何達成不可能的任務

     
jim yeh on 二月 4th, 2008

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

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

     
jim yeh on 十一月 16th, 2007

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

Continue reading about 品質是檢驗出來的,還是設計出來的?

     
jim yeh on 十月 5th, 2007

本文係投稿於 CNet / ZDNet Taiwan 的初稿,並分為上下兩篇文章刊出,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 在日常生活上,我們常會發現從不同觀點中體會出一致性的道理,如同專案管理與易經,我們可以從專案管理的觀念與方法中,常會發現它們與易經的觀念是相通的。尤其在軟體開發團隊中,不管是在問題的解決上或對團隊成員的管理上,都與易經有不謀而合的地方。 其實專案所談的不外乎談人與事,而軟體與其它類型的專案並沒有特殊的差異。因此,我們可以普遍性地說,表面上專案管理與易經看起來各自呈現出不同的風貎,但本質上它們的背後其實存在著共通的一致性的道理。 為什麼會有這種巧合呢?易經所探討的是事物變化的道理,而專案本身就是企業在面臨環境變化的挑戰所應運而生的一種概念。在變化無常的環境中,變是唯一不變的真理,正因為如此,企業要因應環境的十倍速變化,端賴於在專案管理過程中,了解變化的道理來達成專案使命,以滿足企業的實際需求。 所以專案管理和易經的哲理自然是會相通的。換句話說,專案管理雖然是基於專案需要,依照西方的管理理論所發展出來管理概念與方法,但它必然會符合易經的基本原理。 所以,對於專案管理者而言,如果能善用易經哲理,可讓他們在重要概念上具備理解掌握變化原則的能力,同時培養在管理上以簡御繁的技巧。易經的觀念並不複雜,雖然它是探討事物變化的道理,但事物變化的本質是簡易的,是可以被掌握的,事物會遵循著不變的自然法則而改變,而非沒有章法的改變。這就是所謂的易之三義-變易、簡易與不易的道理。

Continue reading about 專案管理與易經生活

     
jim yeh on 十月 2nd, 2007

參與大型軟體專案的管理常常會面臨任務分工與協同合作的問題,這些問題常常會很複雜,充滿了許多不確定的因素。因此,有關於「如何分工與合作才能讓專案的進行更順利」的這類議題,對於專案管理者而言,就是非常重要的課題。 最近,我從同事的 MSN 的暱稱中看到一段文字:「合作分工與分工合作,那一個比較好?」。我覺得很好奇,於是在 MSN 上問他認為這兩者有何不同。他提道: 這兩者有很大的不同喲,分工合作是分工後再合作,合作分工是合作後再分工。分工後再合作會有個大問題,就是分工後的每一個單位,沒有整合的觀念。而合作後分工則是則是先有完整的構架,再分單位,分別執行。 同事舉了一個我倆都參與過的專案,說明分工合作的容易發生的缺失,他認為分工前要先確認整體結構清楚,才能開始分工,彼此單位間介面才會清楚,不會缺東漏西,再來疊床架屋。因此,他認為合作分工比較好,最好團隊成員能夠在一開始先一起工作再決定如何分工。 同人覺得同事談的是很有趣的整合議題,同事則認為分工合作與合作分工是有意思的中文造字。不過,我進一步思考到合作分工在實際操作上有可能會遇到一些限制,於是我探詢同事的看法,提出了一個問題: 那有沒有需要先分工才能合作的情況呢? 同事提到分工合作或合作分工是一種工作的方式,他認為所有事都是可以在這兩種方式中擇一處理。顯然他誤會了我想要表達的意思了,我向他解釋,提出這個問題並非要質疑他的看法,而是對他的觀點感到好奇,假設合作分工是比較好的做法,那對於各種不同專案的複雜問題,合作分工有沒有可能會遇到要先分工才有辦法合作的情形,如果有,那要怎麼處理呢?這才是我真正想要探索的問題。

Continue reading about 合作分工與分工合作

     
jim yeh on 九月 21st, 2007

「SOA 不只是技術」,是我們常聽到的一句話;然而,SOA 是否與技術無關呢?近日同人看到在 InfoQ 中文站有一篇文章,主題是〈SOA重在技术还是业务?〉,提到了網路上對此議題的相關討論,並表達了該篇文章的看法。 該篇文章引用《An Architectural look at SOA》中的一張圖(如下圖)來說明架構的技術觀點,並認為 SOA 畢竟是一種架構風格,與任何架構性工作一樣,架構者必須先想清楚架構性目標為何,並在作出技術上的選擇後,必須回頭重新審視架構上的決策。在技術、平台等全部到位之後,總有它們自身的一套架構、功能和限制。 該篇文章的結論是,技術是重要的,因為不管是 SOA 或任何專案的設計中,都不可能忽視技術。但對技術的定位而言,該篇文章卻認為,技術應該放在第二位,業務才是第一位的,對此,該篇文章留下了讓讀者思考的空間。

Continue reading about 技術在 SOA 是次要的嗎?