學長提到他和同事在工作上觀念的不同而引起爭執；他希望同事能夠思考流程如何改善，讓工作更有效率與品質。但同事則認為本來工作就是這樣做的，她並沒辦法改變什麼。結果兩人因為觀念不同而發生了言語衝突。文章的最後學長提到：

工作中充滿無奈與挑戰，或許是我的口才不好，下次要來學學勁哥跟畢姐，才能說服同事，多思考一起改善流程。不要整天都在救火，不僅沒效率、又沒效益，老闆也認為你在瞎忙。

看了學長的文章和後面的討論，同人覺得學長與同事的糾紛，真正的問題應該不在工作上的爭執，而是彼此語言差異產生的溝通障礙。雖然表面上雙方是因為在工作上的觀念不同而爭執，但存在雙方溝通的根本問題卻是因為顯著的語言差異。雙方使用不同的言語表達了彼此對工作重點的認知不一樣，但卻沒有討論彼此共同要解決問題的目標是什麼，只是各自表述對解決問題的理解，但這些理解只是手段而非目標，雙方自然會因為彼此想法歧異太大而無法溝通。

學長認為他的觀念沒有錯，領公司的一份薪水，應該多思考來發揮創造力，想想看如何改進工作效率與效益。他說下次要壓抑住快要抓狂的情緒，想辦法改善他的口才來說服同事。但同人認為在這種狀況下，口才根本派不上用場，而是要把心擺在正確的地方，才能弄清楚問題到底是什麼，以及它是否必須要被解決。

學長的技術背景讓他喜歡幫人解決問題，但他的同事依賴經驗卻不認為有什麼問題需要解決，依我看這才是造成雙方爭執最大的原因。學長認為同事面對工作流程的效率不夠好，應該積極思考問題的關鍵，而不是得過且過，用「本來就這樣」的藉口來搪塞。他以為公司是一個團隊，團隊中的成員不應該只懂埋頭苦幹，而是要多加思考來創造更高的價值。

然而或許學長的同事認為流程不需要改善，或是認為不值得在這上面花費時間和心力，或許是認為他有其它更重要的工作要做。其實團隊不可能只有存在一種特質的人，而且必須具備必要的多樣性才能發揮團隊的綜效，解決複雜的問題。

換句話說，團隊不可以只有會思考的人，也不可以只有會埋頭苦幹的人，而是必須同時具備思考和埋頭苦幹特質的人，缺一不可。因此，學長強調自己「正確」的觀念來導引同事思考，想要教他的同事解決不是問題的問題，彼此之間，是因為彼此用的語言不一樣而產生溝通障礙。

學長和他同事的語言如何不同？學長認為工作應該要重視思考和創意，要用更好的方式來完成工作，他說的是「求真」和「求美」的語言；而他的同事則認為在工作上，流程的改變對她而言沒有什麼意義，她說的是「求善」的語言。兩個人說的語言不同，並沒有誰對誰錯，只是訴求的方向不一樣，但執意要以一方的觀念來評論另外一方，只會變成各說各話而陷入「鷄同鴨講」的困境。

面對語言差異產生的溝通障礙，同人認為應該先處理關係，再解決問題。一般而言，溝通過程的緊張關係是因為彼此之間缺乏尊重與信任，當然也就不能相互理解彼此的差異。當溝通出現彼此意見分歧的時候，我們通常會強調自己觀點的正確性，藉以突顯他人觀點的錯誤。但如果以客觀的立場來看待雙方的觀點，每個人的觀點都有正確的訴求，但另一方面，很可能部分觀點會有不正確的地方。

其實不同觀念的歧見是為了發展更為一致性的觀點，而不是讓我們堅持己見而要求別人改變想法。所以不同觀點之間需要進行對話，以共同分享彼此的意義。我們應該尊重和我們抱持不同的觀點的人，並相信雙方可以盡最大的努力以達到「求同存異」，甚至是「聚同化異」，而不是運用口才來批評對方的錯誤。

對話除了尊重以外，暫緩確定性的想法也是很重要的一件事。這樣我們才能意識個體差異的存在，進而停止爭辯而進行反思，以尋求改進觀念的可能性。暫緩並非放棄自己價值判斷的主張，而是嘗試以思考的可能性取代堅持的確定性；先不要預設對錯，想一想對方可能也有值得參考的觀點，而自己疏漏了什麼。

對話的目的是為了與他人建立互相信賴的關係，希望從知己解彼開始，與他人共創雙贏，然後再進一步的達到統合綜效。因此，要化解語言差異的溝通障礙，同人首推對話這個有效的省思工具。

您三番兩次到本人的部落格，表達您對本人文章〈從海砂屋陰影學到的教訓〉的見解。這些見解和其它房屋仲介的說辭沒有差別，但這些都是本人曾經詢問過政府機構、律師、建築師之後，認為是錯誤的觀念。這讓人高度懷疑您是房屋仲介的從業人員，為了公司的利益而發表一些似是而非的觀點。果然，前一陣子有網友說他要與ＸＸ房屋仲介公司談和解，但ＸＸ房屋要求他把在我部落格的文章留言撤下，才願意和他談和解。這位網友希望我能夠幫忙，並告訴我海砂屋的誤解應該就是ＸＸ房屋的公關。

如果這位網友說得是正確的，這只會讓我愈來愈討厭ＸＸ房屋。我可以理解房仲業者有自己的利益要維護，幫網友撤下留言也是沒問題的，因為我很清楚這是和解必然的條件，我希望網友能夠圓滿解決問題，當然會幫他撤留言。只是暗地隱藏房仲業者公關的身份，為了維護自己公司的利益，一方面壓迫消費者，另一方面用似是而非的說法反駁我的文章觀點，想必這才是代表是ＸＸ房屋公司的企業文化吧。

您上一次再次對本人回應一連串的留言，本人覺得很困擾，讓我已經將您列為需要審核留言的黑名單。這兩天又再次留言執意要來這邊繼續踢館。我實在是懶得理您，寫這篇公開信的目的是希望你不要再來這邊打筆仗了（不是說不打筆仗嗎？），否則我只好公布ＸＸ房屋的真實名字，讓大家看到ＸＸ房屋是否表裡如一、還是說的比做的還好聽，到時就沒有人可以教我撤下來嘍！

本人寫〈從海砂屋陰影學到的教訓〉只有一個目的，就是幫助購屋者認識海砂屋的陷阱，進而學會保障自身的權益。經歷過海砂屋的陷阱，我深深知道仲介業者會包裝好的詞句來讓消費者誤觸海砂屋的陷阱，那些說法都是沒有根據的。

好比說海砂屋與氯離子含量偏高的房子不一樣（事實上海砂屋就是氯離子含量偏高建築物的簡稱）、海砂屋有新舊兩套不同認定標準或沒有國家標準（事實上那只是仲介自我感覺良好所定的標準，依照目前的國家標準，建築物的氯離子含量只要超過 0.3 kg/m^3 就是海砂屋）、買方要為自己簽下同意接受氯離子 0.3 ~ 0.6 kg/m^3 的合約負責（簽約要負責任，但誤導買方簽下不公平契約，誰要負的責任比較大呢？）、海砂屋的爭議，跟房屋仲介者無關，那是買方與賣方的問題（事實上房仲業者未盡告知義務，或傳達錯誤的資訊，必須要負法律責任）。

以上這些都不是事實而是卸責推諉之辭，我非常清楚因為親身經驗過，但爭論氯離子含量介於新舊標準的建築物是不是適合居住，根本就不是重點，而是如果消費者不想買海砂房，應該先進行房屋檢測，等到檢驗結果沒問題才簽約，而且不要相信仲介的片面說詞，也不要相信他們找來的專家，因為他們與房屋交易成不成功存在利害關係。這才是我文章真正訴求的重點。

因此我不瞭解署名「海砂屋的誤解」的您，來這邊來反駁氯離子含量介於新舊標準的建築物不是海砂屋、或是氯離子偏高的建築物有何意義？這裡是我的部落格，我只是分享本人不慎買到海砂屋，而後成功解約的經驗。或許基於您的立場，並不希望我分享我的「小蝦米對大鯨魚」的經驗，但請弄清楚來我的部落格滅火或是為房仲業的價值觀宣傳是沒有用的，我沒有那麼多閒功夫來跟您們打筆戰，更何況這種躲在網路暱稱之後不友善的留言，恕難奉陪！

至於閣下指教說我法學素養如此不足，本人不予置評。我雖然不是學法律的，也很清楚法律講求的是事實和邏輯，而不是像您這種自我感覺良好的宣稱。您說「買方既然不想買所謂氯離子偏高的房屋，就應該在簽約時對 0.3~0.6 的約定數據提出異議」我想你是看不懂法院判決書中什麼是雙方無異議項目，而且也不了解不想買和不知道該提出異議是兩回事。

就像當時本人被仲介誤導簽下錯誤意思表示的合約時，我也不知道買方可以針對合約的錯誤提出異議，直到深入理解後才知道該如何主張，但那不代表其他的買方在打官司之前都做足功課呀！其實您會犯這種邏輯繆誤我一點也不意外，早在您說海砂屋目前沒有國家標準的時候，我就知道您的邏輯思維能力實在有待加強的。

最後順帶提到，如果您真的是在ＸＸ房屋公司服務，請您去問問您們公司的法務，是不是曾經有位曾經打過海砂屋訴訟得到勝訴的律師，目前是台北市議會的議員，告訴過你們在房屋交易的定型化契約有關海砂屋的條款這樣寫是沒有用的，還是你們只會拿它來蒙蔽不知情的消費者呢？

本人會保留一點餘地給您以及您所服務的公司，但也請您尊重不同價值觀的訴求。我個人並不是不能夠接受不同的觀點，只是孟子曰：「不得於心，勿求其氣」、「詖辭知其所蔽，淫辭知其所陷，邪辭知其所離，遁辭知其所窮」。您的留言已經不是單純的言語不中聽，而是看到您思想盲點、言辭反覆、片面與閃躲，加上您不敢公開您的身份，躲在網路暱稱的保護傘後面，這已經不值得我浪費時間跟您互動了。如果在我寫完這封信之後，您依然還是執迷不悟，使人不堪其擾，那可就別怪我不客氣，希勿自誤。

劇情介紹

這齣電視劇是描述繡月寫信給監獄受刑人的故事。小時候，她曾經被人鎖在倉庫裡面，因此能夠很深刻地體會到在黑暗中內心渴望光明的感受。她希望讓監獄受刑人知道在外界也會有人關心他們的存在，但她的丈夫金湖卻不是很認同她的作法。

金湖在農會上班，他認為傳達愛心很好，但應該要顧慮到照顧家人以及自己孕婦的身份應該不要讓自己太勞累了。但每次丈夫總是無法說服她停下寫信給受刑人的筆，繡月承諾她會兼顧家庭的責任卻每天都寫信到三更半夜，使他的先生很不能諒解她的做法。

繡月當時正在與一審宣判死刑的死刑犯唐友彬通信，他很訝異竟然會有和他亳無關係的陌生人寫信來關心他。繡月的關心讓他開始認真地思考問題，然後向監獄主管申請到監獄工廠工作，希望以他的能力賺取微薄的工資，然後買了二十五張郵票寄給繡月，希望繡月能夠寫更多的信給他。

繡月在信中提到他沒有讀過很多講大道理的書，因此如果在她寫的信當中看到有道理的話，那一定就是她在圖書館看到一些對他有幫助的句子而抄下來。這段話讓唐友彬在受審的路程中，特別去注意到他從前未曾注意過的圖書館。

什麼是生命的意義？繡月受到小時候開導過她的神父感召，在信中告訴唐友彬生命的價值不在它的結果而在於過程。如果把生命看成是一條從開頭到達終點的直線，就會覺得很難面對死亡。但如果把每一個生命從長短不同的線段看成大小不同的圓；代表生命是沒有終止的，而是一次又一次的學習過程。那麼我們就可以比較坦然地面對生命的課題。

繡月寄給唐友彬一盆盆栽，希望他從悉心照料這一株生命的過程中，重塑他對生命的觀點。唐友彬每天認真的澆水並看著盆栽的成長，對於生命似乎也慢慢發現和以往不同的體會與認識。

唐友彬想念故鄉的老母，並且渴望吃到她所煮的豬肝麪線。他婉拒了獄友們的餞行，將這些錢請託繡月買一個金手鐲替他送交他的母親，因為這一生中他從不曾送給母親任何一件禮物，這是他唯一也是最後的禮物。唐友彬也希望繡月能夠代替他嚐一嚐母親煮的豬肝麪線。母親收到繡月轉送的金手鐲時，流下了歡喜的眼淚，而她也嚐到了不知如何用筆墨形容，卻覺得是他吃過最好吃的豬肝麪線。

繡月從唐友彬的母親那裡知道他國小很喜歡畫畫，也很有繪畫的天分。她希望他能夠重拾畫筆，從繪畫中找回對生命的熱情。恰好這時農會舉辦了繪畫比賽，主題是最懷念的人，她鼓勵唐友彬將對母親的思念及情感變成一幅美麗的作品來參加比賽。唐友彬畫了母親的素描，寄給繡月讓她代表到農會參加比賽。

結果唐友彬的作品得到比賽首獎，但公布比賽結果的時候不巧繡月早產住院而沒辦法寫信告訴他。此時唐友彬死刑三審定讞，突然沒有收到繡月的信，讓他非常沮喪。還好繡月的先生金湖在女兒睡前講《幸福王子》的故事，女兒提醒他媽媽寫信給死刑犯也是幫助別人。受到女兒的感召，讓他提筆寫信通知唐友彬得到繪畫比賽首獎，以及繡月住院的消息。唐友彬在收到信之後，才又重新燃起生命的動力。

唐友彬在被槍決前，請求典獄官幫他寄出最後一封信，以及妥善照料繡月送給他的盆栽。在信中他向繡月表示，望著盆栽穿出氣窗他終於想通了；雖然繡月沒辦法救他的性命，但她卻救了他的靈魂。他很想見見繡月一面，但最感到遺憾的是他的母親，也希望繡月能幫他多照顧她。繡月帶著繪畫比賽單位將唐友彬的原畫作翻成的玻璃製品，去慰問唐友彬的母親，得知兒子畫了她的畫像而拿到繪畫比賽首獎，母親又悲又喜地抱著玻璃畫像掉淚。

雖然金湖對繡月把心思放在寫信給受刑人有許多怨言，也因為兒子的到來，使得家庭重拾喜悅。加上女兒單純而善良並且感染母親行善的行動，他終於也認清了繡月為受刑人寫信其實也是一種生命的激盪與撫慰。最後終於接納老婆而讓他留有為受刑人寫信的時間與空間了。

心得與感想

這是一部很感人的電視劇，但同人覺得最令我感動的地方並不在劇中人物的宗教情懷，而是他們如何如實地面對自己的心靈，用以體驗自己的人生。在一般人的眼裡，寫信給受刑人的行為誠然是一件很不容易的事，尤其要一直持續下去更是困難。然而從這齣戲看到女主角並非想傳達什麼觀念要教導犯錯的人，而是曾經體會過被囚禁在黑暗角落的恐懼與痛苦，以及渴望外面有人能夠了解自己的存在，希望能藉由寫信來傳達同理心的關懷與撫慰他們孤寂的心靈。

這齣戲並沒有宣揚什麼大道理，而是用平凡的生活意境來體驗生命。即使是嚴肅的生命課題：為什麼人世間要有生死？牧師也只是帶著繡月到菜園，讓她看到植物在大自然發展自己的生命，隨著春夏秋冬逐漸生長茁壯成熟乃至淍零，並周而復始地經歷重生與再次發展生命。人的生命也是一樣，生死只是發展生命的過程而非結果，我們不斷地從這個過程讓生命得到演化而更成熟。

繡月告訴金湖，只有經歷過才會理解處在黑暗中的人的痛苦，體會到這一點，她的信就沒辦法不寫下去。在旁人的眼底可能會覺得幫助別人很好，但應該考慮自己的能力。不過同人在這齣戲倒是體會到，繡月寫信給受刑人，與其說幫助受刑人不如說是為了幫助自己。為了完成在心靈深處本我的實現，也就是榮格心理學所說的個體化的過程。因此，從這戲我們也可以看到榮格主張的「心靈實相」；心靈所期望的是生命的體驗與表達，而非道德觀上的批判或理解。

是的，每一個人都是獨立的個體，我們都是用獨特的生命去表達出不凡的心靈實相。不同的生命體，我們無法依據個人的理性或喜好來批判對錯的結論，因為我們不見得可以意識到不同生命個體所面對的生命難題，或許等到我們碰到時會比當事人更加狼狽而不堪。

從這齣戲小人物平凡的對話可以看見許多不凡的生命智慧，然而帶給同人最大省思的是讓我思索一個問題：我們應該為了幫助別人而忽略家庭嗎？看完這齣戲讓我有不一樣的觀點：幫助他人也許是為了實現心靈的心理意義，或許家人可以適度地了解與溝通來認識其中的真相，進而試著走入家人的心靈世界。那麼問題可能就自然迎刃而解了，因為我們的心靈通常會投射在家人身上，他的問題很可能是就是我的問題。

如同繡月的女兒深受她父親《幸福王子》的故事，深受啟發也在學校體驗到助人的快樂，並且提醒父親媽媽也是在幫助受刑人。金湖最後終於也開始走進老婆的心靈世界，寫信通知唐友彬得獎，並給予繡月足夠的空間做他自己。這除了是有子萬事足之外，也是體會到了快樂的助人才會帶來全家的「幸福」呀。

故事是這樣的，午餐的時候我們從牛頓談到蘋果。也許是最近看榮格自傳的啟發，我想到蘋果本身含有戰爭的原型意含，當然蘋果所代表的原型意涵，也包括了同事甲當時提到「亞當夏娃偷嘗禁果」的原罪。我提到希臘神話故事「金蘋果」由三位女神爭奪一顆蘋果而最後導致特洛依戰爭。當時在場的同事，有很多都沒聽過金蘋果的神話故事，同事甲打趣地說：金蘋果沒聽過，他只知道金瓶梅。

這時候同人發現金蘋果與金瓶梅之間，可能存在某一種關聯性，它們都與女神維納斯有關，然後我提出我的想法。我想到金蘋果是三位女神，包括代表權貴的天后希拉、戰功榮耀的智慧女神雅典娜、以及象徵愛與美麗的美神維娜斯。我又曾經在電台節目聽到張曼娟專訪侯文詠談到他的著作，也就是《私房閱讀金瓶梅–沒有神的所在》提到他閱讀《金瓶梅》的心得。

侯文詠提到潘金蓮在《金瓶梅》所扮演的角色在東方文化是蕩婦，但對照到西方文化，其實潘金蓮就像維娜斯女神一樣，只是為了追求屬於她的愛情與幸福。因此他很為潘金蓮叫屈，認為加諸在她身上其實只是東方傳統文化對女性進行不公平待遇的道德批判，這其實只是一種偏見。

同人引述候文詠的觀點並不是代表我認為潘金蓮不是蕩婦，雖然我在價值觀上與侯文詠的看法是一致的。我只是想表達世界上存在不同文化評斷事物的差異；對於同樣的一個現象，東方認為是一種罪惡，而西方卻認為那是自然的人性，無須大肆批判。

我認為文化差異是我們可以觀察到的客觀事實，而沒有文化優劣對錯的問題。但有些同事似乎不這樣想，同事乙反駁說：潘金蓮本來就是蕩婦，這那有文化差異的問題；甲同事則說：那麼差勁的文化，把蕩婦視為正常現象，難怪他們的文化會逐漸式微而没落。

他們的議論讓我看到一個很有趣的現象：人們經常忙著對事物進行主觀價值的堅持，卻忘懷開放自己的胸襟，讓自己去嘗試對事物所不了解的地方進行來龍去脈的瞭解，以認識自己認知事物的侷限與偏見。同事乙及同事甲並沒有聽過金蘋果的故事，也似乎不能體會候文詠提到的觀點。我想，或許他們並不想深入理解，只想捍衛看起來像是道聽塗說的觀念，而他們把它當做不可違逆的傳統價值。

當然，他們的想法其實沒有什麼錯，只是沒有自知之明讓我覺得很不可思議。尤其是同事甲，在我澄清我的觀點只是要指出東西方文化看女性有明顯不同的道德標準，這是一個客觀事實。而他們的反應卻明顯表達出對潘金蓮角色的道德批判，同時暗示東方文化比西方文化更文明。

然而同事甲卻一再地否認他的道德批判，但他的行為就是用他喜歡的價值觀來評斷另一種價值觀，他的「道德批判」卻已經成為大家客觀觀察到的一項明顯事實。有趣的是，當這項事實經由同人提出來之後，同事甲又責怪我應該要把他不懂的東西都交待清楚，還說我沒有定義清楚我們的問題。我發現我已經陷入沒有意義的爭辯了，再加上同事甲意識不到他的邏輯問題；把他聽不懂我的定義與我沒有定義混為一談，我實在不想浪費生命在沒有意義的爭論，只好結束這令人不愉快的討論。

同人本來只是想很隨興地分享在閒聊過程中的想法，卻沒想到變成一場沒有意義的爭論。我知道是我搞錯談話對象了，對那些只能談到事物表相層面的人，本來就不應該期望他們懂得你在說什麼，反正他們閒聊的目的只是打發時間罷了，知識分享與交流並不是他們的目的。所以浪費時間爭論是沒有意義的，這時候我還是閉上我的嘴巴比較好。

不過，這段談話也讓我看清楚了一件事，其實不管是西方的女神，或是東方的蕩婦，都只是文化的一種意向，我們看到它是一種原型，也就是代表這地球上一群人的集體意識。當這樣的文化意向對我們產生意義，我們的命運就會受到它的牽引。

侯文詠指出他對道德批判的懷疑，這會讓我們留有省思的空間。然而對喜歡對號入座或是自以為是的人們來說，他們是看不到自己的愚昧的。但千萬不要期望改變他們，否則蘋果帶來的戰爭原型，是很難不受其牽連的呀！

假如上面的話是成立的，那麼代表只要徹底重構系統就不會造成「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」嗎？如果是這樣，那 XP 根本就不需要 Refactoring 這個實務來改善程式的結構，因為你都徹底重構程式，程式結構變差的情況是根本不可能發生。

而且依照本人 20 年來軟體開發的經驗，我還不沒有看到有程式一開始就寫得很好，到後來可以不用改變架構而符合新需求的。倒是隨著對問題的更清楚，或是程式需求的變化，讓程式必須重構的現象時常履見不鮮！

所以如果自以為自己博覽群書，很懂得TDD的實務。也不要忘了用心思考，以免自己對TDD的最佳實務的認知，不小心犯了根本上的邏輯繆誤？

結果，後來同人在 Facebook 的 Scrum community in Taiwan 看到 Steven 做了以下的回應：

先說件簡單易明的事情，其實我很不喜歡閣下把 TDD 放到 "精神" 層次，卻忘記了基本步驟。

之前的討論根本連事實層次都被忽略，根本談不上是什麼多少年的經驗或者如何用心思考，連 TDD 的最基本步驟也忘記，TDD 的基本步，不是閣下做多少年工作就可以把人家的定義去改變的，我也不明白為何有 20 年工作經驗就可以把 "Refactoring" 說成 "並不必然是 TDD 的必要的步驟"，這不是邏輯問題，更不是有過什麼開發經驗然後用心思考就可以改變的事情，這是就算對軟體開發的認知不夠閣下那麼 "全面" 的都能看出的謬誤，如果閣下這樣就認為是因為說不過閣下就建議多看書本，本人深表遺憾。

我是來討論問題的，我沒有興趣去傷害閣下感情，好好閱讀書本，只是反映 TDD 三個步驟是什麼根本不存在爭議，更沒有 "好好閱讀什麼書或文章才能跟我討論" 的意思，我還未自大得要別人看過多少書才可以討論問題，亦正如討論問題我也不用跟別人說我有多少年工作經驗一樣，而且本人是衷心認為多讀書是有益的（不管是閣下還是什麼人），多讀書亦不是為上來辯論的，不過閣下如果感到有所不悅的，我就先行道歉，還是希望冷靜一點討論問題。

而簡單的例子也是思辦的過程的一部份，一方面是簡單易明地討論問題，另一方面是如果連簡單的例子也說不通，又怎麼能去談更複雜的問題呢？

上面提到："那XP根本就不需要 refactoring 這個實務來改善程式的結構，因為你都徹底重構程式，程式結構變差的情況是根本不可能發生。"

不如冷靜一點再讀讀這句子，"XP 不需要 Refactoring 是因為徹式地進行 Refactoring"，我就看不明白這是什麼邏輯，一邊說不需要，另一邊說徹底地進行。

這裡的問題是軟件是會改變的，可能是新增功能，也可能發現有其他問題，每次帶來的變更其實都需要進行重構的。所以說 XP 不需要 Refactoring 也不正確。

世上的確沒有一寫就好的代碼，而且世界是會變的，Refactoring 就是避免以後的更改越來越困難。把 "徹底地進行重構" 理解成 "XP 不需要重構這實踐" 完全沒有邏輯可言。

我也沒有反對不用改變程式架構就能滿足新需求，亦沒有否定 Refactoring 的重要性，只不過我還是建議新的功能以 TDD 方式進行開發，有測試、有代碼、然後進行重構的。

在足夠測試覆蓋下進行重構是可使系統在不斷演進及需求不斷改變之下，使架構或設計仍然處於可以維護的狀態，相反我指出的是，如果程式架構和設計越來越難維護，是重構的力度不足夠。

前面還提到："但重構的目的為何？就重構的定義在不改變功能的情況下改善程式結構，以增加程式碼的彈性以利未來增加或改變功能。因此如同那第三步所言，為了去掉重覆性而重構。"

如果重構只是為了去掉重覆性，那 TDD 的第三步不如叫 "Remove Duplication" 好了，無可否認代碼重覆是很常見的問題，但把這裡的重構限制成消除代碼其實會局限系統的將來發展，而且到了 TDD 的第三步，系統是應該有足夠的測試去覆蓋系統，重構的力度沒理由只局限於新增功能和現有程式的重覆。

我就相信閣下是 Refactoring 的專家，也應該會知道一些 Refactoring 的模式是完全相反的，例如 "Pull Up Method" 和 "Push Down Method"，更是需要觀察當時的情況來作決定，而沒有一面倒那個才是好的模式，我實在不明白為何要把 TDD 的 Refactoring 局限到只做 "去掉重覆性"。

這是實務上會發生的事情，消除代碼重覆以外的重構還是會發生的，如果只是單單只是 "消除重覆"，這會是另一個我認為進行重構不夠徹底的事情。

上面已經不單單是用心思考，而是由理論到實踐都可以看得到的事情。

跟討論 Refactoring 和 TDD 觀點以外的聲音，就引用 Chet Henderickson 的說法，全部都是我錯好了，現在可以解決問題嗎？

看了 Steven 的回應，同人當下的反應是不想浪費時間與心力與他周旋下去，但後來想到或許是因為 1/9 敏捷開發分享會我要分享實施 XP 的經驗與心得，也許這是一個巧妙的同步事件。我可以趁這個機會，導正對 XP 或是 Agile 的一些錯誤觀念。

例如敏捷開發並不是教條式的照本宣科，開發者要懂得變通最重要的是用心思考，而非把必要的思考都看成精神層面的問題，這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應，但一些詞句有略為做過一番修飾，以清楚表達我對測試驅動開發步驟的看法。

呵呵，Steven Mak 的回應很有趣，把別人說成錯的不代表自己就是對的。這跟他先前面對觀點的差異就要人好好的看書的行為是如出一轍，但問題是要別人好好看書也不代表說這句話的人書看得比別人廣泛或是深入。更何況，看很多書是一回事，有沒有讀懂書中作者所傳達的意思又是另外一回事。從 Steven 喜歡用斷章取義的方式解讀我的觀點，以抽取他想要的意義來看，恐怕他看書的目的只是揀選他要的部分，沒有弄懂作者想要傳達的意思的可能性可能居多吧！

對了，我忘了 Steven 的中文可能不夠好，沒辦法弄懂我所表達的意思。如果是這樣，他其實大可以告訴我，我不會叫他去好好地學中文，或是嘲笑他那麼簡單的句子都看不懂，而是想辦法要怎麼表達才會讓他了解我的想法。省去他猜錯我的意思，而顯露出他並沒用心體會或是根本不想思考別人的觀點的窘態。

當然，以上的假設可能是不成立的，他的中文其實很好。但如果是這樣，他的邏輯思維能力真的要加強，因為思考為什麼是最基本的能力，不是什麼經神層次。

記得去年同人應邀到中山大學演講，有機會與鄭炳強教授在餐敍之中交流軟體開發的觀念。他特別強調軟體工程最重要的不是 know how，而是 know why。因為遇到不同需要而要採用適當的方法，唯有具備 know why 的能力才能做到。以 Steven 那麼重視看書來增加知識的態度來看，他應該也很重視軟體工程的學界權威的看法吧？可是如果鄭教授看到 Steven 把 know why 的思維定位成精神層次，我想也很可能會令他很搖頭吧！

回歸正題，Robert C. Martin 在《敏捷軟體開發》這本書（林昆穎，吳京子，2005）中提到測試驅動開發法，他說：

所有的產出的程式碼都是為了讓失敗的單元測試通過而編寫的。首先，我們先寫一個單元測試案例，由於它所要測試的功能並不存在，所以它不會通過，然後我們再編寫程式碼，使得測試案例通過。

編寫測試案例與程式碼之間的反覆來回非常快速。只花費一會兒的功夫。測試案例與程式碼一起演進，而測試案例會比程式碼更早一點。

結果，一組非常完整的測試案例隨著程式碼一起增長，這些測試可讓程式員檢驗程式是否正常運作。如果有一組小搭檔做了些小修改，他們可執行這些測試案例，以確保修改並未對程式碼造成任何破壞。這會極有利於進行重整。

咦，堂堂一位敏捷開發大師級人物，怎麼他也沒提到 TDD 要重構，只說可以有助於未來的重構，難道他也擅改了 TDD 的步驟了嗎？讓我們看另外一本書。點空間的朱子傑和陳盈學翻譯的《The object primer 3/e 中文版－靈活模型驅動開發與UML2》中有更具體說明TDD的步驟，而且還附了流程圖（有興趣自己買書來看）。

1. 快速地加入一段測試，基本上只要能夠測試一段程式碼即可，此時你的測試結果會是失敗的。
2. 執行你的測試，一般是全部的測試套件（test suite）。有時候為了速度上的考量，你可能只決定執行這一部分的測試。目的是確認新的測試結果確實是失敗的。
3. 更新你的功能程式碼，使得測試可以通過。
4. 再次執行你的程式。
5. 如果測試還是失敗，再執行步驟3。
6. 如果通過測試，便重新開始（此時若有重複的程式碼，你便需要重構你的設計）

上面的步驟有提到重構，但也提到重構的前提是如果有重覆的程式碼才要重構。那如果沒有重覆程式碼，那還需要重構嗎？還是如 Steven 所說，去除重覆的程式碼的重構還是不夠徹底的重構？

答案很顯而易見，TDD的步驟本來就沒有規定一定要重構。事實上，重構對有經驗的開發者就是像吃飯或喝水般如此直覺，在開發程式的過程中，諸如像改變函數或變數的名字讓它們變得有意義或容易了解，一段重覆被呼叫的程式碼把它們提取成函數或類別。他們經常無意識地去重構，但有意識地面對他們開發過程所遇到的問題，諸如程式碼的重覆或不易了解等問題，而不是漫無目的的為重構而重構。

是以在開發功能的程式碼，因為編程手法的熟練，重覆碼根本就不存在，難道還需要一個重構的 process 嗎？由此可知，Steven 的徹底重構之說，其實就是邏輯上所謂的以偏概全，用部分的事實擴大到全面性的觀點。但真相是 TDD 未必要進行重構，除非你需要它。所以這當然是邏輯的問題，其實從我指出他邏輯的矛盾之後，他的反應更顯出欠缺邏輯的思辨能力。

不如冷靜一點再讀讀這句子，"XP 不需要 Refactoring 是因為徹式地進行 Refactoring"，我就看不明白這是什麼邏輯，一邊說不需要，另一邊說徹底地進行。

Steven 上面的質疑乍看來似乎有道理，但仔細看看，原來他把時間的因素拿掉了，有偷換觀念的嫌疑。我原先的說法是說因為先前徹底地重構，所以未來就不需要重構了，被他偷換成一邊說不需要，另一邊說徹底進行。

照他原來的邏輯，如果先前徹底重構的程式碼到後來還需要再次重構，那原來的重構還能叫徹底重構嗎？我們常看到有些人會在問題發生的時候，會說因為別人寫的程式碼出問題，是因為沒有徹底的重構，但在明眼人的眼中，這種說法可以用台語說「出一支嘴」！要嘛有徹底重構先見之明的人，你就再一開始就告訴大家什麼叫做徹底的重構，保證以後不會出問題，省得以後出了問題再說重構不夠徹底，後見之明說重構不夠徹底，這種說法誰都會說但卻根本做不到！

更何況重構的方法有好幾種，決定該怎麼重構的時間還沒到，如何徹底重構？或許有人會想依據未來的預測來徹底重構，但這樣想的人大概忘了敏捷方法是不進行預測的，只有因應現實而改變。

蘇格拉底說：「事情的好壞不重要，重要的是你的想法和看法。」本來針對事情來討論是一件好事，目的是為了思考彼此之間的差異點而獲得成長。無奈 Steven 一開始為了捍衛他的觀點，就針對和他觀點不同觀點的人，拼命強調同人說 TDD 不必然需要 Refactoring 的觀念是錯的，叫我要多看書暗示我不夠用功，其實這樣的行為模式突顯他面對意見紛歧沒有反省思辨的能力。

至於同人提出邏輯思辨的想法就叫做精神層面的說法，同人只能說這其實表現出 Steven 自以為是的「自我感覺良好」，運用修辭技巧閃來閃去還是難逃嚴謹的邏輯批判。他要表演這些同人其實沒什麼意見，他可以繼續活在他的象牙塔之中。但對於同人而言，我的收穫只是多看到一個負面教材，這對我 1/9 敏捷開發分享會的聽眾和閱讀我文章的讀者來說可是一大貢獻呀。Steven 說他不小心傷害我的感情；呵呵，少來了，不禮貌與不尊重的行為代表他不夠理性，只是顯出他的無理而已。

…here’s what we do: we drive development with automated test, a style of development called Test-Driven Development(TDD). In Test Driven Development:
* Write new code only if an automated test has failed
* Eliminate duplication
……

The two rules imply an oder to the tasks of programming.
1. Red – Write a little test that doesn’t work …
2. Green – Make the test work quickly…
3. Refactor – Eliminate all of the duplication….

Red/green/refactor – the TDD mantra

在這段敘述中，Kent 認為 Red/green/refactor 是 TDD 的三字箴言，是 TDD 這個 practice 重要的工作。

所以 Steven 才會強調在做 TDD 時，"測試是第一步"，"Refactoring 本身是 TDD 三步之中其中必要的一步"

假如正如 David Ko 所說，測試與 Refactoring 是 TDD 很重要的一環，而來強調 TDD 不應該忽略 Refactoring 的工作，這樣的觀點我可以接受，但同人隨後又看到 Steven 的說法，覺得他自以為是的論點讓我很遺憾。

本人從來沒有指出 TDD 是測試 Practice，亦沒有認為測試是 TDD 的目的。

上面的 "功能" 指代碼的內容規格，寫測試時候就是思考新功能的行為，用測試用例的方式去表達出來。就正如：

AssertEquals(3, add(1,2))

那麼簡單，已經是對 add() 作出規範，投入兩個參數，輸出一個數字作結果，並規範了新 fn 的名字是 "add"。寫這句 Assert 時候就應該思考到 add 有兩個參數，投入 1 和 2 就會得 3 這個數字。

重構是 TDD 其中一步，不存在混淆點，再者，沒有測試覆蓋下的根本不能說成重構；另一方面，先寫代碼後補測試是很痛苦的事情。

如果像閣下文中說：「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」，我則認為是在進行 TDD 時候沒有徹底去重構系統。

我建議閣下好好閱讀 TDD 的書本，Refactoring 是 TDD 必需的步驟，由 Kent Beck 到 Robert Martin 以至其他不太有名的 TDD 書本作者，都指出 TDD 的第三步是重構，而不是 "Refactoring 並不必然是 TDD 的必要的步驟。"

看到「我建議閣下好好閱讀 TDD 的書本」這種不尊重不同觀點的說法，同人根本就不想浪費時間來跟對方爭論。即使耐著性子仔細看他的論點，像那些「沒有測試覆蓋下的根本不能說成重構；另一方面，先寫代碼後補測試是很痛苦的事情。」、「如果像閣下文中說：『系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護』，我則認為是在進行 TDD 時候沒有徹底去重構系統。」等說法，更讓同人懷疑他對 TDD 的認知，其實是過於偏向理念化而不夠切合實際。

不過，對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法，同人倒是覺得有探討的必要。以下分享我在 Facebook 的 Scrum Community in Taiwan 回應 David Ko 的觀點，這些觀點應該可以解釋為什麼測試開發不需要徹底重構；其實重構並不是問題，而是到底什麼叫做徹底？而且如果 TDD 可以徹底重構，那麼代表一開始就可以讓設計一次到位，那寫好的測試程式以後也用不著了，不正是多此一舉？
—————————————————————————————————
柯兄，

我想在點空間，您應該曾看到我與某些只談理論忽略實際的顧問級大師論戰吧？即使當時我和他私下交情還不錯，但看到他用簡單的例子把軟體開發化約成不需要研究 how，或系統分析不需要懂領域知識的觀念，就不得不告訴他，他對軟體開發的認知是不夠全面的。這次對 TDD 實務的分歧點，我想也是差不多的情況。

只不過我不喜歡"我建議閣下好好閱讀 TDD 的書本"這樣的說法，在實務上我看過太多空談理論而不懂思辨問題的人，這種自以為是的論調讓我不想浪費時間回應他，但以下針對柯兄所提來說說我的看法。

單就字面來看，測試是第一步，重構是最後一步，看起來是沒錯，但問題是為什麼呢？測試先行我想應無疑義，我文章也談了很多，在此不再多說。但重構的目的為何？就重構的定義在不改變功能的情況下改善程式結構，以增加程式碼的彈性以利未來增加或改變功能。因此如同那第三步所言，為了去掉重覆性而重構。

但為什麼需要去掉重覆性呢？答案不外乎兩種，一種是日後重覆性造成程式維護的困難與增加錯誤機率，另一種是程式員擔心發生以上的現象或是因為個人對程式設計的信仰所致。

第一種狀況的重構是合理的，因為開發者是針對現實來解決問題；第二種狀況的重構很常見卻不見得是應該被鼔勵的做法，因為開發者是針對理想或信仰來行動，卻不見得符合實際的需要。但這兩種狀況都可以用重覆程式碼的壞味道的概念來合理化重構的行動，所以重構是正確的行動嗎？答案是視情況而定。

一些 TDD 的書籍或教本所舉得例子都很簡單，使得每一步驟都顯得理所當然。但真實的專案真的是這樣嗎？但個人當初在導入 XP 實務的時候，所遇到的困難，都沒辦法從那些書中得到答案，而是要親身體驗；書中教你的 what 其實需要你實施後的 how 及 why，才能更為全面把那些實務做到好。

最後，提一提測試涵蓋面的問題。在我還沒實施 TDD 的時候，當時我很肯定 TDD 的方法，但我想到的問題是測試程式要寫到什麼程度。但等到我開始實施 TDD 的時候，才發現測試程式的涵蓋面根本就不是問題，而是你需要 test driven 幫你做什麼。如果問題具體而明確，那那會有涵蓋面或不涵蓋面的問題？這時，才了解 Peter Ho 及盈學兄當年在點空間說過 TDD 不是測試而是設計的手法。還有那三句擺在我心中的經典名言：

Without refactoring, there is no room for plugging in new functionality to adapt the coming force.

Without testing, we couldn’t know where the edge is.

Without integration, the spark of life will die out.

一點淺見，供參考，但我絕不會叫別人好好閱讀什麼書或文章才能跟我討論…

我常在做的 "教練" 工作大部分是在講一些基礎的東西與衍生的技術, 但是倒沒有想過要將團隊變成 "一致性" , 試想, 你身為經理確發現實作的工程師缺乏某些觀念時, 你不得不著急,但是這種狀況出來的時候, 產品也開始出現許多問題, 這是技術經理面臨最大的挑戰。但是當技術經理開始當 "教練" 已經離開工程師角色一段時間, 這又是另一個挑戰

同人很高興 MaoYang 能夠針對這個主題提出討論。對於他所提到的問題，我常看到的是技術經理不能因材施教，所以究竟來看也是身為教練本身指導的彈性不足，也是多樣性的問題，尤其在軟體開發專案更為常見。

而且有時候工程師不是不懂那些概念，而是他們碰到一些技術經理不重視或忽略的問題，但如果沒辦法幫他們解決那些問題，如何讓他們接受那些觀念。教練就只會流於說教的自說自話。所以是管理能力的不足而非技術，也是我文章著墨於領導觀點重於技術觀點的主要原因。

對於領導，MaoYang 認為最好的領導是當顧問而不是教練；他提到工程師可以自己發現問題，來請教 "顧問" ，當然如果工程師都看不到問題，那麼就另當別論。MaoYang 還提到他很欣賞上次 David Ko 在敏捷開發分享會提到的經驗；團隊主動提出要使用 Scrum，這時候身為經理的 David 只要做順水推舟的工作即可。

不過同人倒是認為，David Ko 的經驗是可遇不可求的。同人的經驗顯示，在台灣的軟體開發機構，是很少經營者有願意改變的胸襟與勇氣，即使有些老闆在口頭上說改革，但骨子裡卻是很畏懼改變而使所謂的改革只是流於表相化。

MaoYang 提到他在職場現實看到的一個現象；他說我在文中提到教練最好可以不給答案，而是提出問題讓工程師去思考。但是他在現實職場看到的是一堆人在揣摩老闆在想什麼？要怎麼做，老闆才會滿意？因此有時候他反而不太喜歡這樣的領導模式。同人覺得 MaoYang 這段說到重點了，但為什麼會形成這樣的企業文化呢？

MaoYang 說他覺得在中國人的企業都會有這種問題，這是為什麼 "雍正王朝" 被列為某些企業的管理教材。在雍正王朝裡面一堆這種範例，沒有正確答案，正確答案在主子的腦袋裡面。 這種文化要改，可能是領導者的腦袋要先改。

然後 MaoYang 還分享後來他想到他說技術經理下來當教練是不得不，意思是說理論上應該不用走到這一步，問題出在當初找人時，沒有嚴格把關，沒有找到對的人。他還提到 《Peopleware》 裡面也有講要如何 interview 工程師，所以《從 A 到 A+》裡面也有講企業要成功，要找到對的人。所以他認為技術經理當教練的徵兆對一家公司其實是不太好的，技術經理應該去看前瞻的東西，而不是當一名 "教練"。

其實同人很同意找到對的人來做事的想法，但事實上這卻是不容易做到的，尤其是軟體開發工作的專案，更難以找到對的人來做事。這種困難包括兩種情境，一種是找不到合適的人才來執行任務，另一種是把真正的人才放到不正確的任務上。

第一種情境雖然很常看到，但經常也可能是技術經理沒辦法慧眼識英雄或因材施教，而使好的人才淪為的犧牲品。在這種情狀下，其實問題不在找不到人才而是經理人本身領導或管理的問題。寫到這裡，我想到溫伯格在《第一級評量》講的一句話：沒有不好的士兵，只有不會帶兵的將領。

所以技術經理當教練如果對公司是不好的徵兆，問題應該還是出在領導上，誠如同人過去發表過的文章所講的：強將手下無弱兵，但也不會有強將。沒有辦法訓練培養人才的教練，還是因為技術經理不諳教練之道呀！

技術經理有時候要扮演 "教練" 的角色, 這時候要將正確的觀念傳遞, 這是有點困難的, 因為往往會被自己的極限所限制, 想起了一位朋友,他是長笛老師, 他說他知道那個音要如何如何才是完美的, 但是他確無法示範出來

對於 MaoYang 兄的觀點，通達人認為 MaoYang 的朋友應該要學如何示範，不然就不是個夠格的老師。這代表了技術經理應該要學習如何正確示範，否則就不能算是個好教練。MaoYang 兄進一步解釋他對技術經理擔任教練角色的觀察：

在公司內部, 技術經理當 "教練" 並不是明定的工作, 但是當團隊的程度良莠不齊的時候, 技術經理帶頭出來當 "教練" , 是不得不的, 但是技術經理有時當管理職太久, 要把許多實作交代清楚, 這是當技術經理累人的地方

以上的解釋，通達人認為他同意當「教練」並不是技術經理明定的工作，但為了要避免身為技術經理的時間都被部屬瓜分了，較佳的方案還是當教練，讓部屬有成長的機會和空間。另外，有一位噗友 Daniel Li 也認為，身為技術領導者，給部屬魚吃不如教他如何釣魚。因為總是有一天，他們會離開教練單飛，就像教小孩走路；我們不可能一直挨著他隨時扶著他，只能教他方法、鼓勵或強迫他嘗試，並獎勵或誇大他的小成功。

在觀念上，以上的討論已經將技術經理擔任教練的動機及基本觀念，詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事，事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題，可以從兩方面來探討，一個是技術經理要教練的東西為何，另一個則是技術經理擔任教練的目的為何。

技術經理應該要教導他的團隊成員什麼東西呢？MaoYang 的長笛老師朋友說知道什麼才是完美音符，但自己卻不知道怎麼示範，然而如果技術經理知道如何示範他所知道的完美，那麼是否他就能夠傳遞正確的觀念了呢？答案並非如此，因為在這個地方存在一個陷阱；對於藝術而言，或許追求完美是有所意義，但在技術的領域中，完美真的是那麼絕對而必須去追求嗎？

在科技的領域中，我們通常找不到真正的完美。站在解決問題的角度來看，以前被認為是完美的方法，也許在今天會無法解決我們面對的問題。換言之，很多表面上看起來相似的問題，但在問題的本質上卻是全然是完全不同的，而且人們通常沒有辦法一眼認清它們，而是要深入研究後才能知道如何找到適合的方法來解決問題。這其實也是技術開發工作最困難的地方，很多問題很難找到最佳的解法，而只能基於現實用最適解來處理它們。

所以對於逐漸不再接觸技術的管理者而言，他們過去以為的完美是否到了今天還是那麼如此絕對呢？答案未必見得。就像溫伯格評論「成熟度」是偏頗字眼的道理一樣；所謂完美通常是基於個人信仰的價值判斷，這只是基於個人的感情需要，而非專案的真正需要。

因此，技術經理應該要教導他的團隊成員的東西，不應該是他已經知道的東西，而是他還不知道的東西，這樣他的團隊才能不被自己的所知有限而限制住。但如何可以做到呢？同人認為好的教練不會給答案，而是提出關鍵的問題教人們去思考，使人們在困惑產生學習的動機，以及有勇氣質疑權威與傳統上以為的理所當然。這樣才能增進團隊成員解決問題的能力，提供答案不會讓他們得到成長，只會造成依賴而削弱他們的力量。

至於技術經理擔任教練的目的為何，MaoYang 說當團隊的程度良莠不齊的時候，技術經理才不得不帶頭出來當 "教練"。那是否意味著技術經理當教練是為了讓團隊素質可以齊一化呢？但如果答案是肯定的，那代表在團隊的多樣性會慢慢消失而由—致性來取代，那麼喪失一致性的代價是否值得。但如果答案是否定的，那麼技術經理擔任教練的目的終究為何呢？

對同人的這個疑問，通達人認為在保有多樣性的同時，也必須注意—致性。因為一致性是合作的基礎，就像足球隊隊員們都須熟練基本技巧「控球」和「傳球」，才能在實際比賽中透過一系列交互傳球得分。通達人說的沒錯，但在實務上，同人經常看見技術經理會犧牲團隊成員的多樣性來增加一致性。

比如說運用制度或規章來抑制團隊成員的行為，不希望成員面對問題採取不一樣的想法與做法，但這通常是因為技術經理的管理彈性不足，才會對團隊成員處處設限。因為依據「必要多樣性法則」，系統的行為會由系統最有彈性的部分來掌控，如果技術經理的彈性不足，那麼團隊的多樣性將會造成他在管理上的困難。因此他必須設法降低多樣性才有辦法管理好他的團隊，但如此一來也等於抑制成員的創意，常會使得問題的解決更加困難。

當然團隊合作需要一致性，但技術經理當教練當拿一致性來取代多樣性卻不見得是明智的。就拿所謂的基本動作來說好了，很多人都忽略了基本動作需要以成員背景能力與組織文化為前提。因為如果不考量專案臨時與獨特的特性，你可以找到適合的人依據某種方法來訓練，但專案的特性讓你找不到適合的人來達到目的。

因此對專案而言，基本動作是夠用就好，但何謂夠用，正考驗著經理人面對現實的勇氣與智慧；縱使團隊的一致性可以降低管理的困難度。但一致性不是技術經理當教練的目的，只是用來達成最終目的－提昇團隊績效的手段之一。因此，如果解決專案問題的需要更高的團隊多樣性，恐怕如何提昇管理的彈性，才是技術經理成為好教練的關鍵因素吧！

經過一個月來的使用，這台 FE3000 用起來還蠻順手，直到最近因為無法透過 USB 連接線輸出照片，才發現 USB 的連接埠故障。老婆到總代理元佑實業要求維修，才發現 OLYMPUS 這個世界名牌數位相機的維修服務，竟是如此糟糕而令人失望。

同人聽到老婆告訴我客服要求我們付錢才能維修，這實在令人感到不可思議。老婆轉述客服的話說，連接埠的故障是因為人為操作錯誤造成，因為連接埠上的接頭凹陷下去，他們認為正常操作絕不會出現這樣的狀況。

老婆當然不能接受客服的說法，但客服說完卻忙著處理另一位客戶的大發雷霆；因為他送修的機器沒修好而吵著要找元佑的總經理處理問題。這時候，輪到另一位女性的客服人員來處理老婆的問題，她還是說這是人為操作不當，如果是按照正常的操作，USB 拔插 10 次都不會有問題。

老婆聽到客服人員這樣說，立即反應說：「這是什麼爛照像機，USB 只能使用 10 次，我以前用過其它廠牌的機型都沒有這樣的問題！」客服人員這時表示請老婆不要生氣，但她還是堅持修理 USB 連結埠故障必須要收費，要不然就只能買讀卡機來處理相片的輸出。老婆因為帶著還不到三歲的女兒，沒辦法也不想花太大的精神找對方理論，只好悻悻然地帶著相機回家。

聽到老婆送修數位相機的過程，實在讓同人覺得這個名牌數位相機維修服務真是離譜。在台灣的今天，竟然還有如此缺乏品質意識的公司，真是令人匪夷所思。

OLYMPUS 的 FE3000 並不是我們家所使用的第一台數位相機，過去我們用過很多其它廠牌的數位相機，而且也經常利用數位相機所附的 USB 界面來進行照片的影像輸出，從來也沒發生過 USB 連結埠那麼不堪使用的問題。

如果真如客服說是因為人為操作不當而造成損壞，那麼什麼樣的操作會造成這種問題呢？老婆轉述客服說可能是接頭方向對錯了，我聽到客服人員這樣說倒是想請對方表演如何將 USB 接頭反接給我看！事實上，這台相機的 USB 插槽有防止反接的缺口設計，根本就不可能發生將 USB 傳輸線反接的現象。

如果使用者不可能將 USB 傳輸線接反，再加上我們並非第一次使用 USB 的傳輸界面，對我們而言，連結 USB 傳輸線是那麼單純而簡單的步驟，我們應該不可能會弄錯而導致 USB 連結埠的損壞。如此看來，USB 連結埠的損壞的原因根本就並非人為操作不當，而是機器本身的設計不良或是構件本身的瑕疵。

所謂設計不良是指使用者在正常操作下會造成機件故障的比率。換言之，就像客服人員說得 USB 傳輸線正常拔插 10 次也不會故障。假如她說的沒錯，那麼就代表這台數位相機的 USB 傳輸線拔插的設計，只能保證正常使用拔插 10 次不會導致連結埠的損壞。因此站在使用者的觀點來看，這種設計當然是設計不良。

然而以常理來推論，實在很難讓人相信 OLYMPUS 的 USB 連結埠會設計成只能拔插 10 次而已。這樣看來，如果 USB 連結埠損害的原因不是因為設計不良，那麼就是 USB 連結埠構件本身的瑕疵，才會如此不堪使用。而那位客服人員如此缺乏 common sense 的說辭，不是想掩飾產品品質不良的真相，就是想要推拖維修的責任而刁難顧客。

這種罔顧客戶權益的行為，是客服人員的素質太差，還是因為元佑本身的企業文化所致？有網友告訴同人，在網路上元佑的相機維修，早就劣跡斑斑了。聽過老婆跟元佑接觸的經驗，再看看到網路上的文章、以及一些網友的經驗，讓人相信除了客服人員的問題之外，更嚴重的問題是他們的企業文化根本不重視「服務品質」這回事；對於客戶的維修需求，能夠推掉一件就賺一件，如果推不掉就再來修。換句話說，就是會吵的孩子才有糖吃。

一件商品在正常使用之下，在保固期內廠商竟然會拒負保固服務的責任。在這近幾年來，同人還是第一次意識到台灣會發生這樣的現象。不過有趣的是，有朋友認為消費者碰到這種情形不應該生氣。而是要怪自己沒有看清楚服務條款，以免因為憤怒而喪失理智，但同人認為這樣的想法反而會助長劣質服務的氣焰。

因此，相機的保固問題自然有法律來保障我們的權益，但除此之外，我們仍舊可以將不愉快的相機維修經驗，用來降低其他消費者因為資訊不對稱而增加的交易成本，以自然淘汰不良的服務品質。希望透過這篇文章的分享，也能夠讓更多人了解，數位相機除了品牌形象與功能外，不要忽略了售後的維修服務呀。

網路上其它有關元佑維修的討論：

數位相機不防水

戰勝元佑的例子

同人很喜歡 David Ko 兄提到愛因斯坦為 Insanity 這個字所下的定義：「Doing the same thing over and over again and expecting different results」我認為這個定義很貼切地描寫許多人在軟體開發過程所展現的心態；過去做過行不通的做法，卻認為在今天可以行得通，結果讓人一直瘋狂或是不斷地精神錯亂。

但為什麼人們要盲目地做些行不通的事呢？其實以同人這麼多年軟體開發的經驗來看，他們不見得是意識不到這些做法行不通，而是可能因為害怕與恐懼，讓他們不敢嘗試新的方法來解決問題。

縱使無法解決問題的挫折是令人沮喪的，但如果要放棄過去習慣的做法來開發系統，他們更會茫然不知所措，擔心因此對現況失去掌控能力。於是明知過去的做法有問題，但更害怕失去它就會一無所有，於是只好將它緊緊地捉在手上，並期待這一次會有奇蹟出現，改寫過去失敗的命運。

不過如果人們理性一點，都會意識到要改變命運不應該期待奇蹟，而是需要「勇氣」讓我們改變心智模式，然後採用有效的方法來解決問題。在這方面，同人覺得比較幸運的是我常碰到好主管，能夠支持我想要把事情做好的想法。

記得過去的主管 Y.L. Liu 曾經告訴過我的話：「如果過去這樣做行不通，那今天就應該嘗試不一樣的做法」即使改變必然會遭遇到阻礙，然而當我們勇於面對阻礙而因應問題時，才能促使我們打破過去的習慣來進行有紀律地思考與行動，進而更有效地解決問題。

紀律，也就是 discipline 這個字。它的意義並不是做我們過去熟悉的事，而是熟悉了解問題是什麼，並加以解決問題的過程。如同我過去的文章所強調的，軟體開發不只是工程，或是工藝，而是解決問題的過程。敏捷開發其實並非依賴制式的軟體開發流程或方法，而是基於重要價值觀與原則發展出來的實務，而最重要的價值觀就是為了思考如何「解決問題」，至於使用流程方法都只是手段而不是目的。

然而，根據同人的經驗，想要軟體開發過程運用以上的觀念，我認為最困難的是對專案目標的混淆。在這次的分享會之中，同人也發現有些 PMP 背景的朋友，他們很關心如何準確預估專案的範圍、時程與資源，因此希望了解敏捷開發如何來解決這樣的問題。但其實敏捷開發方法根本不需要做精確的預估，因為改變是無法預估的。所以它強調的是反應變化的能力，而不去為預期或抑制變化做太多的努力。

或許有人會把精確的專案預估，看成是專案成功的重要目標之一。但以同人這位 PMP 對專案管理的認知來看，精確預估並非專案的目標，而是達成降低專案風險目標的手段之一。或許用這種手段來蓋房子，或生產看得到、摸得著，可以明確度量的產品可以做得很好，但用它來開發軟體卻不見得可以行得通。

我們應該改變對軟體開發專案的傳統思維；假如軟體開發的本質，就是難以精確預估，那麼我們就不該將力氣浪費在預測上，而是應該用來進行對專案更有效益的事情上。但這不代表敏捷開發方式不做規劃，而是規劃的重點不在精確地預測未來，而是用來定義專案的基準線；利用每一次的反覆過程的回饋，用來改善或調整後續的計劃，以增進我們回應變化的能力。

因此，使用敏捷開發我們不需要具細彌遺地預測未來的改變，只需集中心力面對今天所發生的問題。換句話說，開發者也不需要一份不會變更的功能需求清單，而是了解專案目前所要解決的實際問題，進而運用(adopt)思考及創意、調適(adapt)方法然後再熟練(adept)所需要的技能來解決問題。

那麼，以上敏捷開發的思維是否打破專案管理的基本觀念？同人從不認為如此。依照 PMBOK 的專案管理知識領域與流程本來就支援管理改變的做法，問題只在於管理者是否掌握住變更管理的重要原則並熟練它們：

首先、必須確認改變對專案有正面效益；

其次、必須確認影響變更的因素已發生；

最後、最重要的是管理變更。（PMI，2000）

我們看到這些原則不但並不違背敏捷開發的思維，同時兩者是相通並且相輔相成的。的確，對於軟體專案而言，改變意味著增加軟體開發的風險，但害怕專案風險的心態，也代表你的團隊面對風險只能迴避它們以確保安全，但你所獲取的利潤也相對變得較低（DeMarco & Lister，2007）。於是你必須辛苦地在市場上試圖降低軟體價格來與對手競爭，除非你能夠勇敢地面對挑戰，選擇快速回應變化才會創造機會，為專案產生更大的正面效益。

那麼對於環境或需求的變化，軟體開發團隊要如何快速回應呢？依據同人的經驗，大規模的事先設計（BDUF，Big Design Up-Front）通常無法立即迅速地反應變化，而且常常會造成過度的工程化（over engineering）的問題。而依賴開發組織導入某些流程、工具或方法論其實也並非成功的關鍵。我認為只有增進團隊溝通與合作，讓團隊能為面對問題而共同努力，才能夠快速地回應變化。

或許有人會認為詳盡的文件可以增進溝通，但實際上它的成效不高而且常常要人們花費很多的心力，除非你發現它真的有幫助，否則你應該只需要寫必要的文件。雖然工具或方法論可以增進開發的效率，但它們也會讓工作變得艱難。因為無法被替除的工作，它們是更具備知識密集的特性，需要更有才幹的人來完成任務（DeMarco & Lister，2007）。所以在導入任何工具或方法論之前，你應該提醒自己，敏捷開發是以人為基礎，面對的是現實而非理想。

誠如 David Ko 在分享會中說得好，任何方法的導入如果最後變成政令宣導時，那就非常不妙了。同人則以為快速回應的關鍵不在於遵循方法論的做法，而在於面對專案的現實問題，讓團隊共同因應問題而改變。David Ko 提出了很多他的專案所導入的做法，同時分享他感受到團隊成員自動自發的喜悅，也讓同人希望能夠見賢思齊。