這甘A賽減少 Relearning？

Oct. 12 23:00~ Oct. 13 00:18


M. Jwo (應該是先生) 對於 Teddy 胡說八道的『消除浪費 (3)：Relearning』有點建言：

M. Jwo ：自動化測試等無法減少 relearning 的時間才對。

Teddy：您說『這不是肯德基 自動化測試等無法減少 relearning 的時間才對』，可否說明原因？


M. Jwo ：自動化測試甚至TDD等不是減少relearning，而是減少未來bug的發生。因為測試對裡面的細節不會描述，不然重構就無法發生。如果說自動化測試想要減少relearning，不如寫code的時候命名好一點，讓看到程式碼就能知道寫什麼，讓程式碼就是文件，比起測試部份更好。問題是這些都要回去看程式。真的想要減少除了pair programming以外，比如google實行的變形的方式，必須由supervisor才能commit code這些方法我覺得更好，不但有技術傳承更達到code review的功能。

***

除了虛構的路人甲以外，終於有一個真正的路人對 Teddy 唬爛的內容看不過去了（也許早就有很多...XD），剛好利用這個機會寫一篇文章也好（快沒內容可寫）。

基本上 M. Jwo 的講法 Teddy 完全同意，『寫code的時候命名好一點』，『pair programming』都可以減少 relearning 時間（最後那點關於 google 的作法 Teddy 不了就不加評論）。

大部分的鄉民可能會認為『測試』就是為了『找 bugs』。知道 TDD 的人會說『TDD 是一種設計，不是測試』。不管自動化測試，TDD 的『原意』或是『主要目的』是什麼，Teddy 認為其結果（或是副作用？！）是可以達到減少 relearning 的效果。

想像一下，如果你寫了一個 method X，但是沒有為這個 method 寫 unit tests。一個月後，有人回報你的系統有一個 bug，你花了 5 個小時才找到，原來這個 bug 發生在 method X 中。你『重新學習（重新發現）』到這個 method X 的行為有問題。如果當時有利用自動化測試將這個 method 的『正常行為』記錄下來，而且有頻繁的執行這些自動化測試案例，那麼當問題發生時，便可立即發現（假設你的測試案例可以測出問題），減低『重新學習』的時間。

***

用白話文解釋，有一個人（小明），從小不學無術，到處做壞事，從 16 歲開始就不斷地進出監獄，卻一直沒有學會教訓。一直到小明 50 歲的時候，遇到一個義工，在這位義工不間斷的勸說與教導之下，小明最後終於改邪歸正。此時小明語重心長的說了一句：

小明：如果早點認識你（義工） 我的人生就不同了。

小明就好比是『一支沒有測試案例的程式』，發生了 bugs 卻渾然不知要如何改正，從何改正。即使是坐牢（程式當機）的時候有點苦悶，但是出獄（重新開機）之後又固態復發（期待下一次的當機？！）。


喋喋不休的義工，好比自動化測試案例，當行為偏差的時候可以立即示警，以便即時改正。想一想，小明花了幾十年的時間才學習/重新學習到正常的行為，這當然是一種浪費。

（Teddy 內心獨白：這個例子有點牽強...一時想不出更好的比方）

***

每一個自動化測試案例都紀錄著『程式正常行為的某個執行路徑』，從這個角度來看，逐一去執行測試案例便可逐一的了解程式的（片段）行為，可以跟 code reading 互相搭配服用。
 
依據 Michael C. Feathers 在 『Working Effectively with Legacy Code』的講法，『Legacy code is simply code without tests』。為什麼大家都怕維護別人的系統？因為別人做的東西無法了解啊，就算設計的再好（套用一堆偉大的 patterns），程式的名子取的再棒（Kent Back 附身），只要沒有測試案例，難保改一行產生 N 個 bugs。

換個角度來看，如果鄉民們交接到一個有完整測試案例的系統，你新增了一個功能，跑了全部的測試案例，發現沒有問題，於是你『大膽假設』你沒有把系統改壞。所以，如果你沒有時間，你就不需要去立即被迫去『學習』這個系統的程式碼（延遲決定）。也就是說你可以暫時完全排除 relearning 的需要，這樣應該也算是有給它『減少 relearning 時間』的啦。

結論

阿貶內心獨白：自動化測試有沒有減少 relearning 的時間...有那麼嚴重嗎？！趕快放我出來先。

***

友藏內心獨白：感謝 M. Jwo 激發 Teddy 另一個瞎掰靈感。

消除浪費 (4)：Handoffs

Oct. 10 22:39~23:40

『七浪費』之四：Handoffs，英翻中的解釋是『交接』。為什麼交接是一種浪費？舉個例子，有點年紀的鄉民們，應該都知道一種叫做『喝水傳話』的遊戲，玩遊戲的人排成一排，主持人先把謎底（通常是一句話）告訴第一人，然後這個人嘴裡要含著一大口水，頭朝上把剛剛主持人告訴他的那句話傳給第二個人，依此類推一直傳下去。通常最後一個人所聽到的內容和原本的那句話早已差了十萬八千里了。

一件工作，轉過一手之後，所剩下來的知識若能有原本的 50% 就算是很不錯了，所以，如果這件工作轉了 5 手，那麼就只剩下 3% 的知識：

第一手 50% -> 第二手 25% -> 第三手 12%-> 第四手 6%-> 第五手 3%

知道的東西越來越少，就需要花更多的時間才能把事情做好，所以交接是一種浪費的行為。

***

『交接』，從另外一個角度來看，又可以稱為：把『屎虧（不想去碰的工作）』丟給別人去做。相信大部分的鄉民都有把工作交接的別人，或是從別人那裡獲得交接工作的經驗，通常這種經驗都很差。

交接者內心獨白：我已經使盡渾身解數把知道的告訴你了，沒學到算你笨。

被交接者內心獨白：東西這麼多，交接時間那麼短，你又講的這麼籠統，我怎麼可能學得會。一定是存心想要留一手不告訴我。（Teddy 補充：套句學弟常常說的話，『學長又沒交接給我！』）


一件工作丟來丟去，經驗傳承下去的比例也就越來越少，所以接到『屎虧』的人就要花更多時間去完成這件工作，這種經驗流失與需要耗費額外時間（包含把工作交接給別人所花的時間）才能完成工作當然也是一種浪費。

***

那麼，要如何減少交接的浪費呢？書上提了幾個方法：

• 降低交接的次數（Teddy 內心獨白：這不是廢話嗎...XD）。
• 組織 design-build 團隊（就是 Scrum 所說的 cross-functional teams）。關於這一點 Christopher Alexander 早就提出類似的建議，請參考 Teddy 另一篇『Architect-Builder』。
• 使用『寬頻』溝通方法。盡可能用面對面溝通（face-to-face）取代文件式溝通。（Teddy 內心獨白：Apple 聽到您的心聲，所以開發了 FaceTime。眾鄉民們還不趕快乖乖掏錢去買一隻 iPhone 4。）
• 儘早且頻繁地釋出部份（先期）作品以便於獲得回饋。這句話 Teddy 要解釋一下，原文比較長：『Release partial or preliminary work for consideration and feedback--as soon as possible and as often as practical.』假設團隊中有 programmers 和 testers，如果 programmers 『自認為』程式已經做完了，所以把程式交給 testers 去測試（這就是一種『交接』）。但是如果在開發的過程中，programmers 從來都沒有跟 testers 討論過，那麼經過交接之後，testers 很可能不知道要如何測試，或是說無法測出真正的問題，甚至會測錯（都算浪費）。如果 programmers 在開發的過程便可以和 testers 討論，那麼便可以減少這樣的問題。

最後補充一點， Teddy 認為用來減少 relearning 的 agile practices，像是 pair programming 或 collective ownership 也都可以減少 handoffs 所造成的浪費。

*** 

友藏內心獨白：國慶日還沒休息，夠意思了吧。

消除浪費 (3)：Relearning

Oct. 09 22:20~23:41

今日談談『七武器 七浪費』之三：Relearning，也可以稱為『rework』。如果一次就能做好，就不需要『rework』，所以 『第二次（或以上）』的 work 當然就是一種浪費。但是為什麼不直接說 rework，而要咬文嚼字的說 relearning？

由於軟體開發事實上就是一種『學習新知的過程』，因此減少重新學習已知的知識，就可以減少浪費，所以特別用 relearning 來強調『軟體開發實為學習新識』的特質。例如，團隊中有老鳥跟菜鳥，菜鳥被分配到開發『用 Java NIO 實做非同步檔案讀寫』的某項功能。老鳥對於此功能的技術十分熟練，但是被分配到該工作的卻是菜鳥。於是：

• 菜鳥先花了一整天搞懂什麼是 Java NIO。
• 菜鳥再花一天實做非同步檔案讀寫與撰寫單元測試。
• Tester 花了兩小時測出菜鳥所寫的程式有 5 個 bugs。
• 菜鳥解了其中的 3 個 bugs，另外 2 個看不出來問題再哪裡。
• 菜鳥請老鳥幫忙做 code review，老鳥只花了 10 分鐘就找出 8 個 bugs (原本尚未解的 2 個  bugs 外加 6 個 tester 沒測出來的 bugs)。
• 菜鳥將這 8 個 bugs 解完。
• 經過這一番過程，菜鳥獲得 10 點經驗值，菜鳥一級升級為菜鳥二級。

以上整個過程花了 6 個工作天，如果可以縮短學習的時間，便可減少時程的浪費。

***

大量的 relearning 對於軟體開發是一件『很傷』的事情，但是卻很難完全避免 relearning。團隊中幾乎不可能每一個人的知識與經驗都相同（如果能夠找『博格人』來開發軟體就太好了... 什麼，不知道博格人是什麼？來人啊，拖出去...看...Star Trek），因為『派工（分工）』的關係，又不可能把每件工作都交給最懂該工作的人來實做，因此便會造成 relearning 的現象。

另外，人是很『健忘的』，以前做過的事，曾經發生過的問題，日子一久，經常會忘記，因此相同的問題可能一再的發生，這也是 relearning（此時如果能找到『曾子』來開發軟體就好了，因為論語有紀載：『曾子不貳過』，這種人才找來寫程式最好）。

***

光知道 relearning 是一種浪費，那麼要如何減少 relearning 造成的浪費，這就傷腦筋了。請鄉民們想一下，有沒有哪一個 agile practices 是可以減少 relearning？知道答案的人，請將答案寫在明信片上，來信請寄『台北郵政 5408 號信箱』，前五名答對者本節目將提供神秘小禮物... XD

其實很多 agile practices 都和減少 relearning 有關，例如：

• 自動化測試：將程式正常行為的『知識』紀錄在自動化測試程式中，當自己或別人不小心產生 bugs 時（破壞程式正常行為），能夠透過紀錄下來的知識立即發現問題（就是這些自動化測試案例），如此便可減少  relearning 所花的時間（可參考 『需求分析書中最重要的資訊是什麼？』這篇）。
• 採用 Design by Contract 或是 assertion。理由類似自動化測試，這些技術在 runtime 都可自動驗證程式的行為是否符合原本的預期。
• Pair programming：師徒制是傳遞知識最好的方法之一，雖然過程辛苦了點。

族繁不及備載，請各自發揮。

***

友藏內心獨白：程式設計師徵人條件：具有博格人和曾子的性格。


 

消除浪費 (2)：Extra Features

Oct. 06 22:27~23:46

Extra Features （多餘的功能）是軟體開發七種浪費行為中，最嚴重的一種浪費。為什麼？道理很簡單，如果某項功能連寫都不需要寫，那就不會因為要開發該功能而產生『Partially Done Work，Relearning，Handoffs，Task Switching，Delays，Defects』這些浪費的行為了。與其做出客戶暫時不需要的功能，而日後需要『時時勤拂拭，勿使惹塵埃』（開發與維護這些功能使其正常工作），還不如採取『本來無一物，何處惹塵埃』的策略，不是省事多了。

路人甲：那乾脆什麼都不做，不是最好。

Teddy ：我也想什麼都不做啊，可是到了這種極端，你的銀行帳戶也會跟著『本來無一物，何處惹塵埃』。畢竟鄉民們大概都還是屬於俗世中人，尚未修煉到不食人間煙火的境界，所以『該做的，還是要做』。至於哪些是該做的，哪些是不該做的，就要靠各位的『智慧』去判斷了..XD。

***

舉個例子，Teddy 最近看到 Kay 買了 iPhone 4，覺的好心動，不由自主的便稍微研究了幾款智慧型手機，包括 HTC Desire，HTC Desire HD，HTC Desire ，Nokia N8...，每一款都好想買。於是，Teddy 心中的小惡魔就不斷地找理由說服 Teddy，『智慧型手機好棒，可以為你的生活帶來極大的便利，趕快買一隻，趕快買一隻』

在激情過後，Teddy 發現不管是那一款手機，目前暫時都不需要，先用 Kay 的 iPhone 4 就好了。Teddy 想起『住左邊，住右邊』這齣連續劇，裡面有一句對白，『公家有，用公家，公家沒有用朋友』，這樣最省的啦。如果 Teddy 當時衝動之下跑去買了不需要的手機（Extra Features），那就是大大的浪費了（Teddy 內心獨白：如果口袋夠深的話，好想給它浪費一下...XD）。這種情況在逛大買場的時候也常常發生，就算是事先寫好了購物清單，一不小心還是買了不必要的東西回家。

***

各位鄉民以前求學的時候，或多或少都有受到傳統軟體開發方法的洗腦，認為軟體專案事前的（需求）分析做的越多越好，系統要很有彈性，以便應付日後未知的新增需求（請參考『你的軟體架構有多軟』），搞得這些做軟體的人好像『算命師』一樣，要能預測未來。這種『過於彈性的軟體架構』或是程式設計師基於『追求使用最新技術的爽度所幻想出來的需求』，就好像你的下一隻智慧型手機，下一雙高跟鞋，下一件衣服，下一台 3D 電視，下一個女朋友，下一  XXX 一樣，過早投資，通常都是一種浪費。


問題來了，古人有云，要『未雨綢繆』，難道事先準備有錯嗎？不是都說『有備無患』，怎麼現在『綢繆』和『有備』都變成一種浪費啦，那是不是說每天只要躺著在家裡睡覺就可以當選啦。食神 軟工，我真是猜不透你啊！


長話短說，把握幾個 agile 精神：

• 最高境界：本來無一物，何處惹塵埃。不需要的功能，就不要做。
• 撐到最後一刻逼不得已時再做決定。問氣象局一個禮拜後的天氣，準確度可能只有 50%。若是問『今天』的天氣，準確度可能有 90%。如果問『昨天』的天氣，準確度就有 100% 啦。所以，愈晚做決定，通常比較不會出錯。這就是為什麼人人都可以當『事後諸葛亮』的原因。
• 採用演進式設計。
• 創造支援『逐步成長 』的開發流程，開發環境，與軟體架構。
• 對於已經開發完成的功能，要『時時勤拂拭，勿使惹塵埃』。這跟養小孩一樣，要嘛就不生，既然生了，不管長相如何，身體是否健康，都要好好照顧。

講完收功。

友藏內心獨白：以上所言，不適用於『老子就是錢多，就是要促進消費，你咬我啊』這種類型的人。

消除浪費 (1)：Partially Done Work

Oct. 05 22:21~23:28

在『軟體庫存』這一篇，Teddy 提到可以藉由降低軟體庫存來改善軟體開發流程。這裡面的想法其實是來自於 Implementing Lean Software Development: From Concept to Cash 這本書。該書將『Toyota Production System (TPS)』所提到藉由減少七種不必要的浪費來提昇產品品質的精神，套用到軟體開發中，用以降低開發成本並且改善軟體品質。


這七種浪費分別是 (括號為 TPS 中所採用的名稱)，分七次逐一說明：

1. Partially Done Work (In-Process Inventory)
2. Extra Features (Over-Production)
3. Relearning (Extra Processing)
4. Handoffs (Transportation)
5. Task Switching (Motion)
6. Delays (Waiting)
7. Defects (Defects)

Partially Done Work 

東西沒做完，這些半成品無法出貨給客戶，只能放在家裡，時間一久可能會有發霉的疑慮。屬於這類的例子有『尚未被實做的需求文件，尚未 check-in 的程式碼，尚未被測試的程式碼，尚未被佈署的程式碼』。Partially Done Work 是一件很可怕的東西，首先，它會讓開發團隊有一種『進度正常甚至超前』的錯覺。


程式設計師們：我們功能都寫好了啊（其實還沒完整測試，所以只能算『半成品』）。


專案經理：好開心，好開心，每個人的工作都做好了。

經過  N 天之後，專案截止日期快到了。

專案經理：騙肖ㄟ，系統連安裝都有問題，是誰說做好的？（Teddy 內心獨白：胃潰瘍又發作了。）

***

其次，這種半成品數量太多，時間一久，開發團隊都忘了系統中哪些東西是可以用的，哪些是半成品。到時候整個系統要整合起來，又是一大問題。再者，東西放太久沒用是會『壞掉』的，沒錯，軟體或文件也會臭酸（路人甲：那放在冰箱不就好了...）。

例如，以傳統的軟體開發方式，撰寫程式之前，一定要先做『需求分析』，然後產出一本厚厚的『需求分析書』（路人甲：人家的需求分析書怎麼只有薄薄的幾張 A4 紙，而且還是用 double spaces  排版過的...XD）。假設這本分析書是用 use cases 格式撰寫，裡面包含 100 個 use cases，此時這本分析書就是『尚未被實做的需求文件』，屬於 Partially Done Work 的一種。假設開發團隊每一個 iteration (兩週) 可以實做完成 3 個 use cases ，經過半年後也才完成 36 個 use cases。剩下的 64 個 use cases，經過這半年後，還有多少是屬於『值得信賴』的 use cases 呢（不需要修改依然有效）？

開發過軟體的人應該都知道，『需求一直在變』是軟體專案唯一不變的真理，所以，從這個角度來看，『太早把需求寫完』並不是一件好事，因為太早寫完之後如果沒有足夠的資源能在短時間內實做完成，那麼這些沒實做完的需求，放久之後是會『壞掉』滴（feedback loop 太長，時間拖太久）。

東西放著讓它壞掉，你說這是不是一種浪費？

所以，在 Scrum 中，希望開發團隊要為每一項 task 與每一個 story 定義完成條件 (the definition of done)，以避免這種 Partially Done Work 的現象，這就是一種消除浪費的手段。

***

友藏內心獨白：有沒有數位冰箱可以存放尚未實做完成的文件和程式碼？

0 與 1 的距離

Oct. 04 20:17~23:42

幾年前 XP (eXtreme Programming) 正在流行的時候，其中一個經常被問到的問題：導入 XP 是不是一定要全盤採用 XP 的 12 的 practices（the planning game, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, coding standards）？


在當年，軟體開發團隊掛上 XP 可是很酷的一件事，所以，有些團隊可能不了解 XP 到底是什麼，只是隨便寫寫 test case 或是做做 refactoring 就宣稱『我們團隊採用 XP』，感覺走在時代尖端。為了刷掉這些名不符實的團隊，XP 的虔誠信徒會告訴你：『要買就要買整套的，缺一不可』（Teddy 內心獨白：這還真不容易，感覺有點像是在收集小丸子文具組... 救人啊，怎麼 Teddy 拿到的都是『野口』！）。但是，務實派的人會說：『只拿對你有幫助的就可以了（就算是拿到『野口』也 OK）』。此時 XP 的虔誠信徒會說：『這不是肯德基 如果不全盤採用，就不要對別人說你是 華山派 XP 的門下弟子』。

這種『派系之爭』的歷史一再重演，這幾年 Scrum 竄起，很多人又想跟 Scrum 沾上邊。因此，Scrum 大師們怕大家沒事往自己臉上貼金，或是利用這個噱頭到處騙錢，信口開河說自己或是團隊擁有 Scrum 的經驗，因此也要時時提醒，哪些情況是真正符合 Scrum 的精神，哪些是濫竽充數。


Teddy 曾經因為這種『血統之爭議（正港的 Scrum 或是冒牌的 Scrum）』 困擾了一陣子，為什麼呢？因為咱們寶島台灣，要找到一家公司可以完完全全，徹徹底底的實踐『理想中的 Scrum』相信是不太容易滴（也許用一雙手可以數的完），那麼其他廣大開發軟體的人，難道就因為『無法達到理想的條件』不可以親近 Scrum 嗎？

舉個例子，一個 5~6 人的小公司，準備開發 iPhone 軟體，他們可以找人扮演 Scrum Master，開發團隊成員也沒問題，但是沒有『專門的 Product Owner』 。怎麼辦？最後決定由最有經驗的人 (扮演 Scrum Master 的那個人) 同時扮演 Product Owner。完了，Scrum 的書上說，Scrum Master 和 Product Owner 不可以是同一個人啊？那怎麼辦？

再舉個例子，在 Scrum 中『績效考核』是以看『整個團隊』的績效，而不是看個人。但是，如果公司打考績的時候，你跑去跟老闆說：『因為我們採用 Scrum，所以每個團隊成員的考績都一樣』，Teddy 相信首先陣亡的人應該是你。


再來，Scrum 的目的希望能營造出一個『自我管理的團隊』... 理想很好，但是這些『刁民（team members）』跟牛一樣，進一步退兩步，要維持好不容易已經改善的一點點現況都很難了，別談什麼自我管理。

最後，雖然 Scrum 沒有硬性規定『不可以加班』，不過 agile methods 的精神應該都還是以『不加班為原則』。光是這一點全台灣可能 95% 以上的『高科技』公司就不符合了，那不是沒搞頭了。

***

實際上，日子還是要過下去。不完美的環境，並不能阻止我們追求更好的工作方法與生活品質。舉個例子，Teddy 住在『艋舺』一棟 30 幾年的四層樓老公寓，Teddy 到國外旅行時，看到法國，瑞士，日本，美國的超優生活環境，回國之後難道要把自己家裡『炸掉』重蓋（不可能，因為口袋不夠深，而且不合法）或是繼續『苟且偷生』不做任何改變？在這兩個極端的選擇當中，還是有其他的選項。

• 老屋拉皮。
• 重新油漆。
• 更新照明。
• 種花。
• 掛畫。
• 貼明星海報 ... XD。

Teddy 之前介紹過的 『The Quality Without A Name (QWAN)』這個概念，導入 agile methods，CMMI 也罷，要追求的是軟體開發的 QWAN。認清自己的現況，了解軟體開發的 QWAN（軟體開發的本質），兩者相減就是自己可以努力的空間。


改善的過程並不是 0 或 1 的問題（要嘛什麼都不做，要做就一步到位），而是 0 慢慢地，慢慢地往 1 靠攏的過程。0 與 1 之間，還是有很廣大發揮的空間。

***

友藏內心獨白：那一天才能夠爬到 1 的那一端？

傳福音

Oct. 01 19:12~20:04


今天搭 307 公車的時候，坐在 Teddy  身旁的陌生人 A 君，在公車快到了華中橋時突然開口。


A 君：請問這公車有到車站嗎？

Teddy：有。

在反射性的回答『有』之後，Teddy  心想由於 307 公車有經過『台北車站』和『板橋車站』，因此好心的 Teddy 就問 A 君。

Teddy：你是要到『台北車站』嗎？


A 君：對啊，到台北車站轉搭捷運到龍山寺。

身為『艋舺』在地人的 Teddy，忍不住告訴 A 君。


Teddy：你要到龍山寺，在西門町下車搭捷運比較快，不用到台北車站。

A 君：在西門町下車喔，那要搭那一線捷運？

Teddy：板南線。
 
A 君：到站的時候你可以告訴我嗎？

Teddy：好啊，我也要去西門站。

A 君：你該不會也要去龍山寺？

Teddy：沒那麼巧啦。

過度熱心的 Teddy 不小心開啟了 A 君的話匣子。


A 君：你是學生，還在唸書吧？

Teddy：沒有啦，早就畢業了。

A 君：結婚了嗎？

Teddy：沒有。


A 君：你有信仰嗎？

Teddy：沒有。


A 君：我是信基督教的，有人跟你傳過福音嗎？

Teddy：沒有（此時心中出現三條線）。


A 君：沒有？

Teddy：應該說，我沒有興趣。


A 君：我告訴你，耶穌（還是上帝，Teddy 有點忘了）就像空氣一樣，到處存在，隨時都可以取用，幫助你。

Teddy：點頭傻笑...


A 君：我以前曾經在大陸工作，遇到搶匪拿刀，拿槍搶劫，差點沒命。後來是靠禱告，把自己交給上帝，才渡過難關。

Teddy：點頭傻笑...


之後 A 君又繼續他的傳福音工作，Teddy 繼續點頭傻笑（因為 Teddy 坐在公車最後面靠窗的位置，想跑也跑不掉啊！）。

轉眼間公車已經到了『西藏路口』，前面停了一輛 62 路公車，此時 Teddy 靈機一動。

Teddy：如果你是要去『龍山寺』，可以在下一站『萬大路口』下車，轉搭前面的 62 路公車，這樣比較快。或是可以走路，大概 800 公尺左右。


A 君：喔，那我走一下路好了，順便看看路上有沒有賣水果的。

Teddy：（內心獨白） YES。

***

Teddy 講上面這個故事不是要取笑 A 君，事實上 Teddy 還滿佩服他的。年輕的時候，Teddy 對於這種『侵略式 』或是說『主動式』傳福音的人的確有點反感，直到有一次 Teddy 在跟指導教授聊天時，指導教授說：『其實要去推廣 Scrum (或是其他軟工實務作法)，就好像是傳教一樣，你自己認為有好東西要告訴別人，希望別人也能受益，但是想想看如果你在路上遠遠看到摩門教徒，你的第一個反應一定是趕快繞路逃開，以免他們來煩你』。

啊，說得真是太對了。其實人都是活在習慣中，對於未知與陌生的環境都多多少少都會有點『不安』或是『排斥』感，要打破這種『慣性定律』是很難的。A 君信基督教，他相信這是很好的，所以想把『福音』傳給 Teddy，而 Teddy 的內心卻是抱持著『我不需要，不要煩我』的心態。相同的，Teddy 相信 Scrum 與軟工，也想把這種『福音』傳給身邊的人，但卻也是困難重重。


洪蘭在她的書中說過，當年她要去美國留學時，她爸爸告訴她：『妳到國外，對當地人而言就是外國人，被人家歧視，受委屈是理所當然的，不要怨天尤人，要靠自己努力證明給別人看』（大意大概是這樣）。改變現況，從來都不是一件容易的事，別人不接受，抗拒，搞破壞，都是正常的。所以在公司內要嘗試導入 Scrum （或是任何新制度）的人，最好要有『傳教士』的精神，傳福音沒什麼好氣餒的，永遠保持正面的力量。


西門站，陽光普照，嘴角一抹微笑。

***

友藏內心獨白：不要變成『電視名嘴』，光說不練。