Posted by: jim yeh in 品質文化, 問題解決, 寫作, 專案管理, 思考, 生活感觸, 職場, 設計原則, 軟體審查, 開發流程, 領導
在 1/9 在新竹舉辦的敏捷開發方法分享會，當同人分享到 XP Refactoring 實務的經驗時，台下有一位聽者剛好也是我目前的同事提出一個問題：該由誰來決定何時應該重構的問題。同人當時回應重構多半發生在軟體架構的設計上，一般開發應用程式的程式員通常比較不太會有機會重構。在專案每天早會上，團隊各個成員會報告他們目前進行的工作狀態，當同人發現他們遇到架構面上的問題，我便會著手進行架構的重構以避免系統發生疊床架屋的現象。
同事好奇重構的決定是否有客觀的標準，同人表示這部分多半還是個人主觀的經驗居多。在同事後來開車載我回台北的路上，我們再次談到決定重構的時機。同事覺得重構的時機似乎不是一件容易掌握的事，同人進一步地解釋，當時我們在應用程式的開發沒有太多重構的機會最主要的原因，是因為在架構上力求簡潔而單純的設計概念，使得應用程式的開發已經變得很簡單，實在不太需要運用重構用來增加設計的彈性。
趁這個機會，同人向同事強調架構的彈性不應該以需求不得改變為前提，而是要能夠因應「有限度」的變化而發展而不斷地調整及演進。也就是好的架構並非從恒久不變的核心來出發，而是要先去識別出問題的輪廓才找得到適用的核心。同人經常在軟體開發的實務中看到，人們花費了太多的心力來堅持不變的核心，到最後才會發現原來問題是出在自己對問題假設錯誤。
那麼，在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。 Read the rest of this entry »
MaoYang 兄看到我分享〈技術經理的教練角色〉之後，他在噗浪河道上回應他對我文章觀點的看法。他說：
我常在做的 『教練』 工作大部分是在講一些基礎的東西與衍生的技術, 但是倒沒有想過要將團隊變成 『一致性』 , 試想, 你身為經理確發現實作的工程師缺乏某些觀念時, 你不得不著急,但是這種狀況出來的時候, 產品也開始出現許多問題, 這是技術經理面臨最大的挑戰。但是當技術經理開始當 『教練』 已經離開工程師角色一段時間, 這又是另一個挑戰
同人很高興 MaoYang 能夠針對這個主題提出討論。對於他所提到的問題，我常看到的是技術經理不能因材施教，所以究竟來看也是身為教練本身指導的彈性不足，也是多樣性的問題，尤其在軟體開發專案更為常見。
而且有時候工程師不是不懂那些概念，而是他們碰到一些技術經理不重視或忽略的問題，但如果沒辦法幫他們解決那些問題，如何讓他們接受那些觀念。教練就只會流於說教的自說自話。 Read the rest of this entry »
在噗浪的河道上看到 MaoYang 兄提到技術經理做好教練角色的困難。他說：
技術經理有時候要扮演 『教練』 的角色, 這時候要將正確的觀念傳遞, 這是有點困難的, 因為往往會被自己的極限所限制, 想起了一位朋友,他是長笛老師, 他說他知道那個音要如何如何才是完美的, 但是他確無法示範出來
對於 MaoYang 兄的觀點，通達人認為 MaoYang 的朋友應該要學如何示範，不然就不是個夠格的老師。這代表了技術經理應該要學習如何正確示範，否則就不能算是個好教練。MaoYang 兄進一步解釋他對技術經理擔任教練角色的觀察：
在公司內部, 技術經理當 『教練』 並不是明定的工作, 但是當團隊的程度良莠不齊的時候, 技術經理帶頭出來當 『教練』 , 是不得不的, 但是技術經理有時當管理職太久, 要把許多實作交代清楚, 這是當技術經理累人的地方
以上的解釋，通達人認為他同意當「教練」並不是技術經理明定的工作，但為了要避免身為技術經理的時間都被部屬瓜分了，較佳的方案還是當教練，讓部屬有成長的機會和空間。另外，有一位噗友 Daniel Li 也認為，身為技術領導者，給部屬魚吃不如教他如何釣魚。因為總是有一天，他們會離開教練單飛，就像教小孩走路；我們不可能一直挨著他隨時扶著他，只能教他方法、鼓勵或強迫他嘗試，並獎勵或誇大他的小成功。
在觀念上，以上的討論已經將技術經理擔任教練的動機及基本觀念，詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事，事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題，可以從兩方面來探討，一個是技術經理要教練的東西為何，另一個則是技術經理擔任教練的目的為何。 Read the rest of this entry »
前一陣子在河道上，看到 Zulu 分享〈好人從政的理由〉，引起同人的興趣，就和他討論了這個話題。
Zulu 的文章提到蘇格拉底和格勞孔的對話。蘇格拉底說，沒有人願意甘願當統治者去糾正別人的惡，因為在統治發布命令的時候，並不是為了統治者，而是為了被治理的對象。所以我們想要讓有人願意擔任這種工作時，必須給予他名或利，如果他不願意，就給予懲罰。
格勞孔不大明白蘇格拉底提到用懲罰來當做報酬的道理何在。蘇格拉底說，懲罰可以使最優秀的人來領導人民，他們視貪圖名利為可恥。因此，好人不肯為了名利當官。他們不肯因擔任治理工作公開領取報酬，而被當成佣人，更不肯假公濟私，暗中舞弊，被人當作小偷。名譽也打動不了他們，因為他們並沒有野心。於是要他們同意當官，就只能用懲罰來強制了。
蘇格拉底提到大家看不起那些沒有受到強迫，就自己想要當官的人。但最大的懲罰莫過於，自己不去管人，卻被更壞的人管了。他認為好人最怕這種懲罰，所以勉強出來。他們不是為了自己的榮華富貴，而是迫不得已，實在找不到比他們更好，或同樣好的人來擔當這個責任。
蘇格拉底以為，假如全國都是好人，大家會爭著不當官，就像現在大家爭著當官一樣熱烈。這樣就可以清楚看到，一個真正的統治者追求的不是他自己的利益，而是被統治者的利益。所以聰明人寧可服從他人，也不願要他人服從自己。
以上有關「好人從政」的觀點，同人一開始沒有看得很清楚，以為與中國人的傳統觀念是相違背的。我想到〈論語述而篇〉的一段對話： 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 »
Posted by: jim yeh in 分析設計建模, 利害關係人, 問題解決, 寫作, 專案風險, 思考, 溝通, 生活感觸, 組織, 職場, 領導
Kenming Wang 在〈寫好使用案例 (Use Case) 有什麼好處？〉中提到寫好使用案例的好處。文章提到有位其中一位較為資深的程式開發人員在他在工研院授課時表示感覺不到寫好使用案例有什麼好處。這問題讓他思考許久後回答，他認為寫好使用案例最直接的關鍵是，影響整個專案開發流程的節奏。
這篇文章分享他對寫好使用案例對專案好處的看法，他總結使用案例的好處是族繁不及備載。並提到越大規模的專案，更能感受到開發節奏的順暢度。再加上 『漸進循環 (incremental and iteration)』 的開發模式，會越形容易謀和在系統開發期間，人與事的種種。
不過，Kenming Wang 在文章最後提到以上的論述不能說服那位程式開發人員，因為程式設計人員多半以局部或個別的角度來看系統開發，所以使用案例寫得好不好，對他們沒差。只有像專案經理或軟體架構師以專案整個全局來看時，才會有明顯的感受。
但他認為不需要去說服那位程式開發人員，並引述 Martin Fowler 在《UML Distilled》一書中曾經說過的：「你只能強迫新手們這麼做。過了幾年後，他們會突然恍然大悟，然後腦袋彷彿重生！」這句話來說明他對這位程式開發人員意見的看法。
同人看 Kenming Wang 這篇文章覺得怪怪的，倒不是不贊同他對寫好使用案例好處的觀點，而是覺得強迫新手去做我們認為有價值的東西是很危險的。 Read the rest of this entry »
世界愈複雜，我們就更需要簡單。簡單讓我們看清楚事物的脈絡，掌握重點，以協助做出選擇，並在適當時機採取行動。然而，簡單其實是困難的，因為要做到簡單，意味著我們必須清楚事物的全貎，行動必須要更有原則。尤其是在複雜多變的環境當中，簡單不能只靠直覺，而是有紀律的思考與行動。
那麼，用有紀律的思考與行動，以做到簡單，我們該怎麼做呢？前一陣子，同人閱讀了《越簡單越有力量》，我覺得這本書的觀念與方法，剛好可以提供我們複雜世界簡單之道的思考方向與指引。 Read the rest of this entry »
