這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤？〉、〈如何在系統異常前發現錯誤？（下）〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。
前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。
雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。 Read the rest of this entry »
本文係投稿於 CNet / ZDNet Taiwan 的初稿，並分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。
軟體專案團隊在專案開發的過程中，常會面臨許多問題，例如需求的不斷變化、資源的短缺、時間的急迫性、以及技術的難以掌握等。這些事件雖然都將直接影響專案的產出與品質，並且會令開發者會感到相當困擾，但只要存在希望，問題都還是可以有解決之道的。然而，在什麼情況下，專案發生了什麼事會讓開發者完全失去希望，並且感到他的世界相當悲慘呢？
相信許多人都會同意，總要等到專案驗收前，才發現程式品質有問題是一件很令人沮喪的事情。 Read the rest of this entry »
一般而言，軟體測試是為了提高軟體的品質，而因應軟體開發的不同進展，開發者常會採用不同的測試方法來控制軟體產出的品質。然而，前一陣子，James O. Coplien 提出軟體開發是宗教信仰驅動的產業卻指出了對軟體測試的質疑。
首先，Coplien 提到了做不做測試驅動開發（TDD，test-drivern development）或是驗收測試是一個錯誤的問題，因為軟體開發應關注在品質上，測試所能涵蓋到的品質問題只是片斷而零散的，它是在軟體產業中所知當中，最沒有效率的方法。
然後，Coplien 用「宗教信仰」來批評 TDD 的追隨者，認為他們是盲目的而未加以審慎地思考它可能並不是最佳的實踐方法，同時對於任何的批評也會招致他們的情緒反應，他指出這已經變成一個宗教信仰的問題了。
Coplien 認為要用系統工程的角度來思考問題，也就是如何用最有成本效率的方式把工作做好，而新時代的敏捷運動卻一貫地脫離這些實務。他認為表面上加緊進行簡單的設計看起來很好，但一旦將這些設計放在一起卻會看到它們彼此是片斷而零散的。
不過，Coplien 的觀點在軟體開發社群中卻引來了不少的批評，有人提到對自己親身體驗到的成功所懷有的熱情是不應該與教條主義或宗教信仰混為一談的，更有人認為 Coplien 的觀點缺少事實根據，並且他的主張是懷有個人偏見的。〈软件开发社区“宗教信仰”之争风波未息〉總結這些批評提到：
Coplien 的核心觀點並沒有問題，只是選用了錯誤的論據進行了錯誤的證明。這也提醒我們要以冷靜理性的態度對待問題，否則便有可能在遠離一個極端的同時，走向另一個極端。
同人認為這個宗教信仰之爭是沒有意義的，甚至會覺得 Coplien 對軟體測試的批評讓我覺得很困惑，他想要表達的是什麼？他說要關注於思考而不要對新技術或熱門詞彙亦步亦趨，這個我同意，但從他的文章看起來，他似乎也不由自主地建立了另一個宗教信仰。
特別是「做 TDD，還是驗收測試？」這個問題更令我疑惑，這兩者明明是不同層面的問題，拿來比較有何意義呢？我不認為它是如 Coplien 所說的偽命題，相信應該還有更深的一層意義。
於是，同人換個角度來思考問題，驗收測試與 TDD 有何不同？一個是由客戶端來驗證軟體是否符合他們的品質要求，另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地，這個問題的重點並不在測試，而是「開發者應該自己驗證程式，還是該仰賴客戶來幫你找程式缺陷？」。換言之，就是我們常聽到的一句話：品質是檢驗出來的，還是設計出來的？ Read the rest of this entry »
之前我都會把我在網誌的文章轉貼在台科大 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 甚鉅，不可輕忽。
在軟體開發過程中，工具雖然不足以取代人力，但有效地使用適用的開發工具，卻可以讓我們軟體開發得到加分的效果。
不過，在企求開發工具為我們加分之前，我們必須要思考如何才能先拿到基本分數。 Read the rest of this entry »
關於 software review，在看了喲哪桑學長對我的文章所寫的回應後，發現學長對我想要表達的意思有些誤解。學長提到：
我個人不是很同意依照形式的多寡來分類review, technical review, peer review, etc. 雖然我對那種分類法的感覺不好, 我也建議少這樣說, 但的確有些人是這樣用的.
而我的原文是這麼說的：
對於一個開發流程未慣例化的組織而言（即未達 CMMI ML2），推行 review 可能會遭受極大的反彈；而對於一個開發流程未針對現況做回饋控制的組織而言（即未達 CMMI ML3），review 的推行可能比較徧向形式審查而較少的技術審查或 peer review。
其實我要討論的重點並不在於 software review 形式的多寡，事實上，我文中提到的形式和學長所說的形式並不是同一件事。徧向形式審查的意思是審查的要點在於看工作產出有沒有遵照開發組織規章或專案計劃所規定的文件規範及慣例，對於工作的內容卻無法做到實質上的審查；而所謂的技術審查或 peer review 則是除了工作產出的形式是否符合規定外，審查的重點更會擺在工作產出的實質內容，我常稱這種審查叫做實質審查，用來和形式審查區隔開來。
Read the rest of this entry »
喲哪桑學長在〈Review vs. Inspection — 亂談軟體工程的正名運動〉中對〈創造 software review 的需求〉有所回應，他提道:
沒有壞就不要修，本是西洋古老的諺語。只不過，我還是會擔心，等到壞了，修也來不及囉！
我可以理解學長的 concern，但以 problem-solving 的角度來看問題，第一步一定要先弄清楚問題是什麼。再來問這是誰的問題，在問題擁有者並不想解決問題時，貿然要對方改變只會招致埋怨而對問題沒有任何的助益。
Read the rest of this entry »
哈米尼思對〈工具在 software inspection 所扮演的角色〉提出看法，他提道：
曾經在書上看過這樣的例子 software inspection 演變成 另外一種型式的專案批鬥大會
由於專案的壓力使然，會使得PM也許會對某些工程師的工作產出提出意見，進而產生批鬥
當然，我並不是反對 software inspection ，而是在做這件事的同時，需要明確的規劃和目標設定
如同文中提到的「反思」，是正向看待問題並思考，進而產生好的循環
回過頭來，還是在於公司或組織是不是有建立適當的文化和訓練，並且這項投資要能夠被管理階層所認同，講來講去~ 還是管理上的問題啊
批鬥大會其實是專案衝突的一種形式，當專案團隊成員有感受到彼此意見分歧、對方干擾的行為及產生負面情緒時，就會展開團隊的衝突過程[1]。雖然衝突太多會對團隊的決策共識及接受度有負面的影響，但如果團隊完全沒有衝突，大家想法相同，團隊內呈現一言堂的現象，會導致決策品質的低落。適度的衝突，可混合不同的意見或建設性的批評，藉由不同觀點的了解，和有創造力的選擇自由，而增加決策品質[2]。所以說，批鬥大會不見得是壞事，當問題發生，早期發現早期治療才是最根本的問題解決之道，避免批鬥並沒有解決問題，卻代表了我們只是讓問題延後發生的駝鳥心態。在解決問題的過程中，就算是相互對立，但只要清楚對立的目的是為了解決問題而非相互攻訐，在態度上可以相互尊重，在言詞上避免用言語攻擊或迴避問題[3]，這樣的溝通與對立的目的是要剌激團體正向思考，以促進問題有效解決的良性循環。
附註：在Chui-Wen Chiu’s Note: 〈程式碼檢驗〉看到：
基本上我蠻認同程式碼檢驗這個步驟，不過這個步驟不應該是由人來作，更不應該全部交由一個人來作，而是交由一套工具來處理，如此可以省去不必要的人力支出，而且也可以將 Knowledge 分享給 Team 的每一個人。
站在節省人力支出的立場，用工具幫我們檢驗程式碼的想法看起來好像不錯，如果這樣做可以維持程式碼品質而降低人力的花費，當然是最好的選擇，但程式開發的價值首重創意性思考，但工具卻只能預先設好檢驗的規則，在已設定的規則範圍之外，還是有很多 defect 是會被工具忽略掉，但這些 defect 是不應該被忽略的，因為等到讓它們擴散就麻煩大了。因此把程式碼檢驗的工作，交由一套工具來處理，對於改善軟體品質而言，其實是不夠的。
亦即在檢驗程式碼的工作，工具並不能取代人力的，工具最多只能站在輔助的地位，因為審查程式碼並不是 routine job，這個工作需要的是程式實作的專業知識與技巧，要用人的肉眼直接來逐行檢驗，不能由工具代勞。
鳥毅想要說服主管推行 review 的計劃，喲哪桑學長提了一些建議可以供鳥毅參考，不過我認為要說服主管不是一件簡單的事，如果沒有樣學長那樣的辯才無礙，反應敏捷，可能很難畢其功於一役，不過這個 argument 倒讓我想起了丹娜左哈爾的服務型領導者的概念，也就是仰賴機會與才能不如創造內在需求。
記得在多年前在做李國光老師所教授的策略知識管理課程的期末專題報告，題目是某科學園區的實務社群時，過程中學到一個重要的觀念，就是推行任何的計劃，與其告訴別人他需要什麼東西，不如創造他的需求。這真是一個 key point，對於工程技術背景出身的我而言，向來習慣先提出解決方案，結果常常費盡了唇舌，卻還沒有辦法讓人家採納我們的意見，甚至造成許多不必要的誤會。因為我們不知道對方真正的需求，卻天真地以為我們的解決方案可解決一切問題，我們所做的只不過是誘導對方採納我們的意見而已。
Read the rest of this entry »
