上個月 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 »
5 日有一則「女老師失控狂呼巴掌 3歲童雙頰瘀血腫脹」的新聞，提到幼兒在強調早期療育的幼稚園遭到女老師甩巴掌致兩頰紅腫瘀青，園長帶著女老師登門道歉並跪求原諒，而女老師也表示辭職，家長心軟暫不提告，但孩童幼小心靈所造成的傷害，似乎再多道歉也難以撫平。
同人看到這則新聞，覺得對老師而言，情緒的控制實在很重要。否則老師的情緒失控很容易對孩子的成長，造成難以磨滅的陰影是難以事後彌補的。就像新聞中提到小孩當初被打，怕得不敢掉眼淚，而且也開始出現打人的偏差行為，可知老師情緒失控的行為對小孩影響有多大。
「師者，所以傳道、授業、解惑者也」但如果在教導學生過程中，沒有將自己的情緒處理好，所傳的道或授的業是否會造成更大的偏差，使得學生產生更大的困惑呢？我想這恐怕是必然的結果，老師負面情緒的言教、身教、乃至於境教，也只會提供情緒的負面示範而使學生行為造成偏差。 Read the rest of this entry »
最近同人在開發資料剖析的程式時，碰到一個很奇怪的現象。我使用 map 容器來存放剖析資料的結果，然而卻發現以原先新增資料所用的相同鍵值，竟然會找不到該筆資料。但我的測試程式顯示容器中所存放的鍵值與資料，其內容是正確的，但為什麼用相同鍵值去找，結果竟然回傳查無資料呢？原來問題就出在以字元串列常數當索引鍵值。 Read the rest of this entry »
上個禮拜在噗浪河道上看到馬總統抱怨「好人沒好報」的新聞，提到馬以南爆料說馬英九在寫給她的 email 提到「做了好多好多事，卻還要被罵！」的心路歷程，最後一句話是「哼！好人沒好報」，她看了以後回信給馬英九「放心啦，好人一定有好報，只是時候未到」。
同人看到這則新聞的第一個反應是，總統在救災過程中受到批評，心裡面會產生一些情緒是人之常情。因此透過 email 中將這些情緒發洩出來，跟家人訴訴苦以免情緒積壓而損害身心健康，我認為是很自然的一件事。只不過，馬大姐把這些用來宣洩情緒的對話，在公開場合中公開，似乎只會為她的弟弟帶來麻煩，顯然她又失言了！
不過，除了馬以南的失言之外，同人認為這則新聞更重要的意義是，讓我們看到領導者應該如何面對批評。在現實上，領導者所碰到的難處是，不管領導者碰到問題怎麼做，他都很難做到沒有人批評。因此想要成為優秀的領導者，其實無須太在意外界的批評，而是應該將這些批評轉化成更積極正向的領導作為。
就像在《領導的黃金法則》中，作者約翰‧麥斯威爾提到「當你後面被踢一腳，你知道你已超越在前」。 Read the rest of this entry »
最近我們住的大樓很不寧靜。樓下施工裝修好幾個月，最近聽說因為變更設計要延長施工期間。同人在大樓公布欄看到公告，說工期要延長到十一月底才結束，並且要在這幾天要進行噪音施工的工程，為期三天，時間從早上九點半到十一點半，下午則是從二點到五點。
但沒想到第二天，不到八點半同人和老婆就聽到電鑽和榔頭敲打的聲音了。這個時間出現這些聲音，會干擾女兒的睡眠而影響她的正常發育與成長，這實在令我們十分困擾。 Read the rest of this entry »
台北捷運木柵內湖線又發生系統異常。同人昨天晚上搭捷運，我一向習慣坐第一節車箱。列車才自中山國中站離站沒多久，就看到前面不遠處有一台列車停在那裡，隨車人員連忙打開控制箱將列車停止。等前面列車駛離之後，才將列車停靠至松山機場站，並請大家下車。然後，在廣播中播放因為系統異常而導致全線停駛的訊息，並且請大家改搭其它交通工具。
到了候車大廳，站務人員表示請趕時間的乘客可以直接出站。同人看到排隊處理悠遊卡出站手續的人實在太多，於是同人聽從站務人員的建議直接出站，而沒有處理悠遊卡的出站手續。但這樣一來，不能用悠遊卡坐公車，身上又沒零錢，只能期望捷運站的免費接駁公車。但沒想到花了一個小時等捷運接駁車，卻都還坐不到內湖線的接駁公車，發現捷運公司的免費接駁車的調度，還真是離譜。 Read the rest of this entry »
Kenming Wang 在〈寫好使用案例 (Use Case) 有什麼好處？〉中提到寫好使用案例的好處。文章提到有位其中一位較為資深的程式開發人員在他在工研院授課時表示感覺不到寫好使用案例有什麼好處。這問題讓他思考許久後回答，他認為寫好使用案例最直接的關鍵是，影響整個專案開發流程的節奏。
這篇文章分享他對寫好使用案例對專案好處的看法，他總結使用案例的好處是族繁不及備載。並提到越大規模的專案，更能感受到開發節奏的順暢度。再加上 “漸進循環 (incremental and iteration)” 的開發模式，會越形容易謀和在系統開發期間，人與事的種種。
不過，Kenming Wang 在文章最後提到以上的論述不能說服那位程式開發人員，因為程式設計人員多半以局部或個別的角度來看系統開發，所以使用案例寫得好不好，對他們沒差。只有像專案經理或軟體架構師以專案整個全局來看時，才會有明顯的感受。
但他認為不需要去說服那位程式開發人員，並引述 Martin Fowler 在《UML Distilled》一書中曾經說過的：「你只能強迫新手們這麼做。過了幾年後，他們會突然恍然大悟，然後腦袋彷彿重生！」這句話來說明他對這位程式開發人員意見的看法。
同人看 Kenming Wang 這篇文章覺得怪怪的，倒不是不贊同他對寫好使用案例好處的觀點，而是覺得強迫新手去做我們認為有價值的東西是很危險的。 Read the rest of this entry »
今年五月，同人在家樂福買了一台 DVD Player。為了滿足讓女兒看巧虎的需求，我選了一個號稱絕不挑片、以及認為品質穩定的品牌，但沒想到看了不到一個月，有一天老婆告訴我：DVD Player 故障了。
才買沒多久的 DVD Player 怎麼會故障了呢？同人檢查了 DVD Player 和電視，發現電視接上 DVD Player 時，螢幕一直跳動，不過好像隱約看到 DVD Player 的歡迎畫面，設定鍵好像也有作用，只不過螢幕跳動得太厲害，看不清楚也沒辦法進行設定。
為了確定是電視或是 DVD Player 的問題，我到了妻舅家中，用他家的電視來測試，發現他家的電視機收不到 DVD Player 的輸入訊號。看起來應該是 DVD Player 的問題，於是等到周末假日才到家樂福將機器送修。
不過，第一次送修店員測試表示沒問題，我以為是訊號線有問題，但回到家換一條訊號線測試卻發現，和先前在妻舅家測試的情況一樣，電視機收不到 DVD Player 的輸入訊號，於是我將 DVD Player 連同訊號線再一次地到家樂福送修。後來同人才發現，原來店員之前測試接的是 DVD Player 的色差輸出，但我在家裡接的是一般電視的視訊輸出。在店員確認機器的問題後，在維修單上註明 TV Video out 無影像輸出後送回原廠修理。
等了幾個禮拜，家樂福通知我們機器修好了，但當我在本週日把機器帶回家安裝後，還是發現螢幕上出現跳動的畫面。讓人懷疑機器是不是根本就沒有修理？但打了電話問家樂福，他們表示也不清楚廠商維修機器的狀況，我們不想再浪費時間作無謂等待，於是禮拜一再到家樂福把機器送修。
然而，家樂福的店員測試機器卻看來正常 Read the rest of this entry »
本文於 2009/07/22 經 ZDNet Taiwan 部落格文章專區轉載。
在 facebook 看到舜平學長提到「求快求彈性忽略系統文件的後果，找了兩個小時的BUG」讓同人想寫一篇文章來談談系統開發的彈性。
舜平學長說求快求彈性，忽略系統文件重要性的後果就是使用者說沒空寫文件，如果這時我們也沒有將系統重要資訊記錄下來，那麼就算是自己也會因為時間一久而逐漸淡忘這些資訊，結果使得系統的維護變得更加困難。
雖然以上的現象在台灣是開發者經常碰到的問題，但那是否代表系統開發追求速度與彈性，就必然犧牲文件與流程呢？同人認為這樣看就太過簡化了，系統開發的彈性並不是忽略系統文件與流程，而是只重視有實質效益的一切事物，當然包括文件與流程。 Read the rest of this entry »
