上個月 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 »
早上在 News 98 聽到陳鳳馨評論吳德榮提前退休的新聞事件，她提到吳德榮說：「人們理盲又濫情，說也沒用」對此，她表示人們理盲又濫情她同意，但吳德榮自己何嘗不是理盲又濫情呢？然而，聽完陳鳳馨的評論反而讓人更困惑，或許同人應該好好思考一下，弄清楚到底是誰理盲又濫情。 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 »
本文於 2009/07/22 經 ZDNet Taiwan 部落格文章專區轉載。
在 facebook 看到舜平學長提到「求快求彈性忽略系統文件的後果，找了兩個小時的BUG」讓同人想寫一篇文章來談談系統開發的彈性。
舜平學長說求快求彈性，忽略系統文件重要性的後果就是使用者說沒空寫文件，如果這時我們也沒有將系統重要資訊記錄下來，那麼就算是自己也會因為時間一久而逐漸淡忘這些資訊，結果使得系統的維護變得更加困難。
雖然以上的現象在台灣是開發者經常碰到的問題，但那是否代表系統開發追求速度與彈性，就必然犧牲文件與流程呢？同人認為這樣看就太過簡化了，系統開發的彈性並不是忽略系統文件與流程，而是只重視有實質效益的一切事物，當然包括文件與流程。 Read the rest of this entry »
世界愈複雜，我們就更需要簡單。簡單讓我們看清楚事物的脈絡，掌握重點，以協助做出選擇，並在適當時機採取行動。然而，簡單其實是困難的，因為要做到簡單，意味著我們必須清楚事物的全貎，行動必須要更有原則。尤其是在複雜多變的環境當中，簡單不能只靠直覺，而是有紀律的思考與行動。
朋友在 MSN 上問我用 vb.net 和 c++ 開發程式有沒有很大的不同，因為她的主管要她加入一個使用 vc++ 開發系統的專案。她很怕接下這個任務會很難上手，但主管告訴他用不同的程式語言，只是工具的差異而已，她只需要依主管給的程式範例照著做就沒有問題。朋友不大相信主管的說法，於是想聽聽我的意見。
同人直覺感到不妥，並非因為朋友並不諳 c/c++ 這種程式語言，加上它與 vb 之間，存在根本的程式語言差異。我認為比較嚴重的問題還是溝通過程出現不精確的語言，這代表她們公司的品質文化，對解決專案的問題是沒有效果的。
學習 c++ 當然並不輕鬆，尤其如果沒有 c 語言基礎的話，學起來更是會格外吃力。因為 c++ 語言特性與 vb 的差異很大。比如 c/c++ 特有的指標，就很容易讓初學者混淆，如果觀念不清楚，常會讓程式產生記憶體衝突甚至是當在不明所以的地方。但程式語言或是程式設計的技術，這些都還可以藉由學習成長，對於積極進取、追求自我成長的開發者而言，這些並非是大問題。
誠如我在 facebook 的好友，也是以前在點空間聚會有一面之緣的仁傑兄，看到我對這件事情的分享，他建議：
If you want to encourage her, you can said that. Let her have a confidence to do it.But you have to keep coaching, monitoring and reviewing her codes.
然而，這件事情我覺得讓人擔心的並不是朋友的能力夠不夠。我注意到的是她們公司的品質文化，品質文化的問題並不在技術，它多半不會是專案成敗的關鍵，而是專案管理者的態度。 Read the rest of this entry »
這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈軟體開發的難處 SA該如何解決？〉、〈為何SA很難落實簡單設計〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。
今(09)年初，應中山大學資管系主任鄭炳強教授的邀請，到他們學校做了一場演講。由於筆者與鄭教授原先並不認識，是透過台科大資管系主任李國光教授聯絡到筆者，因此，鄭教授邀請我在演講前先與他碰面、共進午餐，並且藉這個機會交流彼此在軟體工程方面的心得。
在那次午餐約會中，我們聊到了系統分析專業這個議題。鄭教授表示欣賞筆者寫的〈展現系統分析專業的七種能力〉，還曾在課堂上向他的學生推薦這篇文章…與鄭教授交流互動的過程中，也讓筆者得到不少收穫，回到台北後，一直想找機會分享這些收穫。
由於我一直想找機會回應那篇文章的讀者意見，也就是ZDNet讀者對於那篇文章的前半段〈怎樣才是專業的 SA？〉的一些留言，筆者發現這次行程的收穫，正好可以讓這篇文章有一個很好的起點。 Read the rest of this entry »
