上個月 24 日應 MaoYang 兄之邀，分享我在敏捷開發的實戰經驗。這場分享會還找來了 David Ko 兄分享他在公司導入 scrum 開發管理方法的經驗，同人則負責分享我之前在專案中推行 extreme programming 工程實務的經驗。分享會在台北市電腦公會舉行，看到現場互動氣氛的熱絡，以及會後學員們給予不少正面的評價，感覺大家收穫都不少。其實包括我自己在分享會結束之後也產生了一些想法，倒是想藉由此文章分享我的分享會後心得。
同人很喜歡 David Ko 兄提到愛因斯坦為 Insanity 這個字所下的定義：「Doing the same thing over and over again and expecting different results」我認為這個定義很貼切地描寫許多人在軟體開發過程所展現的心態；過去做過行不通的做法，卻認為在今天可以行得通，結果讓人一直瘋狂或是不斷地精神錯亂。
但為什麼人們要盲目地做些行不通的事呢？ Read the rest of this entry »
這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤？〉、〈如何在系統異常前發現錯誤？（下）〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。
前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。
雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。 Read the rest of this entry »
本文於 2009/07/22 經 ZDNet Taiwan 部落格文章專區轉載。
在 facebook 看到舜平學長提到「求快求彈性忽略系統文件的後果，找了兩個小時的BUG」讓同人想寫一篇文章來談談系統開發的彈性。
舜平學長說求快求彈性，忽略系統文件重要性的後果就是使用者說沒空寫文件，如果這時我們也沒有將系統重要資訊記錄下來，那麼就算是自己也會因為時間一久而逐漸淡忘這些資訊，結果使得系統的維護變得更加困難。
雖然以上的現象在台灣是開發者經常碰到的問題，但那是否代表系統開發追求速度與彈性，就必然犧牲文件與流程呢？同人認為這樣看就太過簡化了，系統開發的彈性並不是忽略系統文件與流程，而是只重視有實質效益的一切事物，當然包括文件與流程。 Read the rest of this entry »
本周一同人在新公司 on board，公司事先訂好餐廳為我舉行迎新聚餐。在這場聚餐當中的一道菜，讓大家開啟談論品質流程的話題。 Read the rest of this entry »
最近同人看到有一則噗浪提到「一個穩定的程式並非必然，而是偶然」在此噗浪的回應中，發送這則噗浪的噗友表達他對程式穩定性的看法。
先問自己一個問題，一個程式有幾個 Bugs？如果是不可數，那～～它的穩定是相對非絕對，所以穩定不是絕對的，也不是必然的。
同人覺得這位噗友的觀點很有趣，於是加入這則噗浪的討論。我問如果最開始的程式都是穩定的，那麼是什麼原因讓後來的程式變得不穩定？對這個問題，一些噗友提出了他們的看法，其中有一位噗友回應「是我的機器弄好的程式，跑到別人機器就不穩定了」，發送此則噗浪的噗友認為還蠻接近實際的情形。
他提到 Bugs 在自己的機器沒產生，在別人那邊可能會產生，問題可能是因為自己的機器有 Bugs，而不是別人的機器，他說假設機器不會出問題是會有副作用的。
那麼為什麼不在應用系統要運作的目標環境下直接開發程式呢？因為，嚴格來說，開發者不可能有完全一致的環境，因此開發者只能假設環境是不會改變。但實際上，在不同的機器上、甚至在相同的機器上，不同的時間可能也會出現難以預料到的變化，結果使得程式變得不穩定。
這位噗友認為，當我們愈信任一個系統，其實可能是一個災難，因此程式的穩定非絕對而是偶然，它是由一連串的偶然所累積而成的。同人發現這個觀點讓人很難反駁，在我過去程式開發的經驗中，並不乏遇到原來運作正常的程式，在不同時空環境出現問題的現象。正如同這位噗友提到的，作業系統與程式語言它們本身也都是程式，很難確保它們不會出問題。
相信很多人都曾遇到過，程式發生失常通常只因為一個令人難以捉摸的小錯誤，因此似乎真的可以說「穩定的程式是偶然的」。不過，如果穩定的程式真的是偶然的，程式的穩定就只能依賴運氣而不是人為努力，事情真的是這樣嗎？其實這位噗友太過強調環境變化的隨機性，卻忽略了適應環境變化，程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的，雖然演化的過程是偶然、但其最後結果卻是必然。換句話說，穩定的程式是偶然下的必然。 Read the rest of this entry »
本篇文章是投稿 ZDNet 的文章原稿，並以〈新官上任三把火〉與〈新官上任三把火(下): 建立團隊的創新文化〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。
新政府能否為台灣開創新局還有待觀察。但從馬蕭辦公室與府院籌辦五二○就職典禮，卻出現許多的問題，加上當天的慶典南北奔波，被稱為有史來最複雜的就職典禮看來；新政府團隊似乎想要在就職典禮的活動上，改變舊制以發揮新創意，營造出耳目一新的感覺。但實際上卻反而把問題複雜化，造成一團混亂。這讓筆者想到在軟體開發過程中，也經常出現同樣的情況。
許多主導專案改變的領導者總是新官上任三把火，認為專案應該要進行改變以展現出自己的決心與魄力，因此要求團隊改變開發流程。然而，專案時間與資源的限制多半很難讓團隊有足夠的時間來調適或熟悉改變後的開發流程，結果總是令專案團隊倍感艱辛。
改革的困難正是考驗著領導者的領導能力，他更需要懂得如何讓團隊發揮創意與執行力來實現改革的目標。領導者應該如何領導團隊來進行成功的改革呢？筆者認為從領導者的價值觀、流程方法的改變、以及團隊的創新文化這三方面來看，我們可以從中體會到專案成功改變的箇中三昧，以助於掌握改革重點，有效地組織資源來幫助團隊實現改革目標。 Read the rest of this entry »
最近在寫 ZDNet 專欄文章的時候，找到過去同人在點空間討論區回應克明兄的一篇文章，主題是討論有關系統分析與設計人員的角色與定位。克明克認為系統分析與設計人員是著重系統內部的分析與設計，而系統外部的需求分析應該是由專屬的需求分析人員來負責。
他提到一般軟體公司對系統分析人員的角色定位太過模糊，應該正確地將系統外部的需求分析與系統內部的結構分析作區分，需求分析由 RA 負責；結構分析由 SA 負責。如此，才能界定與釐清系統內與外的工作。
如此的軟體開發角色定位，乍看之下似乎權責分明，但實際上按照這種方式進行軟體開發卻常會面臨一些問題。這篇文章就是同人在點空間討論區提出的看法，後來經過克明兄的請求，我也以那篇文章的內容登在克明兄的網誌中當作對他文章的迴響。
而這一陣子再次看到這篇文章時，突然覺得應該將它在網誌中登出來，以明確呈現出個人對這個主題的看法。不過，同人想在登出這篇文章之前先提出我最近對軟體開發角色定位所體會到的兩個觀點。 Read the rest of this entry »
本文係投稿於 CNet / ZDNet Taiwan 的初稿，並分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。
軟體專案開發常常會面臨時間不足的問題，尤其在台灣，Price on Cost更是不容易達到的理想，迫於現實，開發者只能硬著頭皮上陣去執行不可能的任務。但最後的結果卻常常是賠了夫人又折兵。即使透過不斷地加班，任務依舊還是無法完成，而且還會造成團隊士氣低彌，使得開發者缺乏工作的成就感與滿意度，甚至使專案開發人力大量流失。
其實大多的軟體開發者都期望專案能爭取到足夠的開發時間，不希望他們的青春浪費在無意義且永無休止的加班上。然而，軟體開發的現實就是如此殘酷，受到開發組織的營運面影響，通常專案總是很難爭取到足夠而充裕的開發時間。專案常會受限於市場競爭壓力的考量，為了爭取專案的機會常常會不得不遷就營運觀點而放棄工程與技術的堅持，因而使得專案無法爭取到合理的開發時間。
在台灣，軟體的定價通常是由市場供需機制所決定的，而不見得可以考量到軟體開發的成本。當市場競爭愈激烈時，軟體的價格就相對地會降低。開發者為了獲利，於是就必須想辦法降低開發成本，才能獲取相當的利潤，於是軟體的品質就會受到影響，因為軟體價格實在太低了，開發者只好捨棄一些可以增進或維持軟體品質的作業。結果軟體品質就會變成時間允許才能夠達到的一個理想，而現實通常是「時間總是不夠」。
當軟體專案把軟體價格當做專案成本估算的基礎時，這樣軟體開發就會沒辦法重視專業，只能讓外行（市場因素）領導內行（研發設計專業），軟體開發者的痛苦夢魘於是從此開始。
所以，Price on Cost 的理想是很難達到的，現實就是這樣，專案就是難以爭取到足夠的充裕時間。但這樣要如何才能達到專案不可能的任務呢？從筆者在工作上的觀察中發現，不少的管理者會將這個問題焦點放在團隊生產力上，以提昇軟體的開發效率來縮短開發時間。不過，實際上卻不見軟體開發成果獲得到顯著地提昇。
通常，管理者會希望軟體開發者加班或是增派開發人力，來提昇軟體開發的生產力。軟體開發每日的總工時增加了，照理說應該是可以增加軟體開發的效率，但卻也因此引發出新的問題，也就是軟體開發出錯的機率也會隨每日工作時數或開發人力增加而增加，反而降低了軟體開發的效能。
為什麼會這樣呢？綜歸一句話，增加了生產力卻讓軟體開發變得更複雜，使得團隊無法有效整合、發揮綜效。 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 »
