2013北京考察之旅Day1-A台北艋舺到北京東直門

Feb. 13 20:57~21:41

2013年10月到北京考察9天，早上6點多從家裡出發，第一次搭車行走在五楊高架道路上，這個高度還真是有點恐怖。

 

到達桃園機場第二航廈，有的候機室還附設圖書，有的被裝扮成郵政主題候機室，還滿有創意的。

 

搭早上8:50長榮班機飛往北京，這是Teddy第一次到中國大陸，以前搭長榮機上的餐點都還不錯，但是這次吃的雞肉飯不好吃。

 

到達北京機場，看飛機的航線圖要先往北飛，果然是不能直接跨過台灣海峽啊。

 

到達機場之後，要先搭接駁車轉到入境大廳。入境之前有一個辦理 呆胞 台胞證加簽的窗口，人還不少。話說這個台胞證加簽的動線也設計得太爛了，其他事情不說，居然規定要用「黑色原子筆」填寫資料。原子筆Teddy和Kay身上各帶了一支，問題是都是藍色的筆，有人出門帶黑色原子筆的嗎？現在有提供黑色原子筆，印象中只有一支，而且被固定在櫃檯最右方和膠水放在一起，好幾個人要擠在一小塊區域去拿原子筆或是膠水，真的是有夠給他…。

 

這還沒完，加簽一次台胞證要付50元人民幣，拿給對方100元，對方居然說：「沒錢找，自己看著辦」。這什麼態度？在台灣的銀行換到的人民幣都是100元的鈔票，去哪生50元給你？而且現場也沒有兌換機啊。還好和Kay的台胞證一起付，解決找錢的問題（PS：辦理加簽的時候不能兩個人一起辦，要各辦各的，所以付錢的時候才會遇到找錢的問題）。

***

辦好台胞證要入關的時候，突然傻掉…「本國人、外國人」通道，這…照理講，既然是「出國」應該是走「外國人」通道入關，可是外國人通道排隊的人還不少，而且排到最後會不會被趕到「本國人」通道？正在猶豫的時候，看到不少老外不想排隊也跑去排「本國人」通道，就放心地也一起去排「本國人」通道了。

北京機場很大，入境之後領完行李跑去搭機場快軌（快捷）到北京市東直門。原本是要買北京的一卡通（類似台北市的悠遊卡），可是機場櫃檯居然沒賣，也不說哪裡可以買。這…再次無言。

買完票之後一位大陸同胞一直纏著Teddy要我把收據給他，說他要報帳。不給，還說要用10元人民幣買。還是不理他，搭車去。

***

到了東直門，終於在地鐵站內的服務台買到一卡通，可以到處「優遊」了。

***

友藏內心獨白：對岸同胞的服務態度真的有待改善。

練拳不練功，到老一場空

Feb. 14 11:24~12:35

 

有些書，每讀一次都會有不同的體驗。最近重讀Alexander的《The Timeless Way of Building》和Kent Beck《Extreme Programming Explained, 2nd》，從Alexander的「Quality、Gate、Way」對應到Beck的「Value、Principle、Practice」，突然想通了「練拳不練功，到老一場空」這句話的意思。

網路與行動計算時代，資訊發達，每天光是從Facebook接收到的動態資訊，就快要把人的感官與認知能力給淹死。一大堆酷炫、熱門的新技術語詞彙，不停打著大家的臉，也增加了大家的焦慮感。噯呀，這麼多東西，到底哪一天才學得完啊。

有了「Value、Principle、Practice」這種框架，把不同層次的知識稍微加以分類，可以發現大部分的資訊內容都屬於Practice層次，也就是「拳法招式」。屬於「內功心法」（Value、Principle）的相對不多（有些人也不願意將苦學的內功心法公開），而且較難修練。Practice不是不重要，但如果只是光顧著到處搜刮Practice，你的時間將全部被它們佔據，反倒沒有心思來淬鍊與思考Practice背後的Principle或是Value。

這樣講可能太抽象了，舉個例子。相信很多人都遇過那種「教得很好的老師，一聽就懂」以及那種「教得很爛的老師，只會照書念」。兩者的差別在於前者已經學透了知識背後的Value和Principle，因此可以靈活運用不同的例子、比喻或教法（Practice）來幫助學習。後者則是死讀書，只看到Practice，因此也只能按照字面的意義逐字地把書的內容唸給學生聽。

***

Teddy還沒有能力可以告訴鄉民們要如何修練Value、Principle，只能提醒大家「Value、Principle、Practice」的差別，不要「偏食」光顧著「練拳」（修練Practice）而不「練功」（修練背後的Principle、Value）。當然也不能只「練功」而不「練拳」，這樣就變成只會打嘴砲，「說得一口好程式」的那種「顧人怨」的人。

Teddy在2001年讀了XP第一版，2005年讀了XP第二版，後來學了RUP、PSP、Scrum、Lean、Kanban，再回頭看了XP第二版，驚覺Scrum、Lean、Kanban的實務做法，也許名稱不同或是實施方式不同，但背後許多觀念與XP其實是相通的。光從實務做法去比較，這些方法有些差異很大。從背後的Value、Principle去觀察，相似性就遠大於差異性（不知道Kent Beck有沒有偷偷去讀精實開發的書XD）。

***

對照XP第一版與第二版，Principle部分被改寫了很多。以前一直沒搞懂XP第二版為什麼要特別強調「Value、Principle、Practice」這三種層次的關係，一直覺得XP的Principle過於抽象沒什麼意義。那是當時還沒學到Scrum、Lean、Kanban這些方法，因此只能把XP的Principle對應到XP的Practice，自然覺得這種「抽象化」的意義不大。舉個物件導向設計的例子，如果每個介面（interface）都只有一種實作（implementation），你就會開始懷疑抽離介面與實作的必要性。

依據Alexander的看法，Principle（Gate）是一種「模式語言」（Pattern Language），從這個角度來看，把XP的14個Principle看成是一種「敏捷方法模式語言」（A Pattern Language for Agile Methods），這樣就講得通了。既然是「敏捷方法模式語言」，就可以用這個「模式語言」（也許需再加上其他模式）來描述Scrum、Lean或是Kanban了。而Practice則是實踐各種敏捷方法的解法（solution）之一罷了。

Teddy內心獨白：我想通了，但鄉民卻被弄糊塗了。

***

練拳不練功，到老一場空

練功不輕鬆，到老養生終

練功真的不輕鬆啊。

***

友藏內心獨白：只是要開發個軟體，需要搞到那麼麻煩嗎。

問題就是機會

Feb. 14 10:28~11:10

 

這幾天花了點時間重讀Kent Beck的《Extreme Programming Explained, 2nd》，書中提到Opportunity這個原則（XP有14個原則）：

Learn to see problems as opportunities for change. （試著將問題看成改變的機會）

這個道理其實很簡單，很多人也都知道，但認真去面對問題，並把問題視為改變（改善）機會的人，還真的不多。尤其是在工作流程中牽涉到「人」的問題，就更不容易。在大公司裡面，官僚於各自為政的風氣盛行，有些很簡單的問題卻硬是要搞好久，卻還不一定可以解決。有些人漸漸養成「眼不見為淨」的「老僧入定」功力，有些人的「太極拳」打得愈來越好。真正想做事而看不下去的人，有辦法就自己跳出來創業或是找新的工作，再不然就是只能每天抱怨但對於現狀卻無能為力。

***

去年11月份Erica去上海參加了「User Friendly 2013」研討會，聽到了一個名詞叫做「Design Challenge（設計挑戰）」。觀念很簡單，就是把使用者在執行某項工作所遭遇到的問題（problem）改寫成問句，這個問句就變成「設計挑戰」。例如，在一個線上購物系統中，存在這樣一個設計挑戰：「購物者要如何方便地找到他所想要買的產品？」。

今天不是要解釋「設計挑戰」的內涵，Teddy覺得「設計挑戰」這個名字取得很好，「挑戰」就是一種「機會」，藉由把「問題」轉換為「設計挑戰」，也就把人的思考從負面的「遇到問題好煩」轉化成Kent Beck所說的「試著將問題看成改變的機會」，這是一樣的道理。

***

昨天睡前讀了「千田琢哉」的《兩分鐘有幹勁》，書中也提到類似的看法：

機會隱藏在大部分人逃避的難題中

把難題變成機會與挑戰，就算是最後沒有解決問題，也可在解題的過程中讓自己變聰明。

***

友藏內心獨白：腦袋不用會生鏽。

談談XP（2下）：Principle

Feb. 13 15:47~17:40

 

今天介紹剩下的5個XP原則：

• Redundancy（冗餘）：這個字經常在「容錯設計」中看到，容錯系統透過冗餘來容忍系統中的缺陷（fault），使得缺陷被引發之後系統仍然可以繼續正常運作。軟體開發是一種很複雜的活動，很多環節都可能會出錯，因此不能依靠「銀子彈（特效藥）」來解決所有的問題，只能透過多種不同的方法讓系統處於一個可以接受的健康狀態。例如，XP對付bug的實務做法，就有pair programming、continuous integration、sitting together、real customer involvement、daily deployment這麼多種，這就反映了冗餘原則。
• Failure（失敗）：失敗不是不好的結果嗎，為什麼XP會把失敗列為15個原則之一？仔細回想每個人成長的的過程，其實都有過從失敗中學習的經驗。學走路和騎腳踏車，幾乎每個人都有跌倒的經驗，應該沒有父母要求小孩子學走路或學騎自行車「不准」跌倒吧？學說話也是，小朋友不害怕失敗，所以只要有適當的環境可以很快學會一種語言。大人就不一樣，好面子，怕丟臉、出糗，不敢開口，就不容易學會新的語言。

失敗是一個選項，也是一種學習的過程，更是面對變化與未知最好的武器，也是獲得回饋的一種手段。個人與團隊想要變得更敏捷，就要不害怕失敗、失敗趁早、從失敗中學習。

• Quality（品質）：關於品質有一個很重要的慣念以及常見的迷思：「犧牲品質可以增加開發速度」，這是錯誤的觀念。專案不會因為接受低品質的軟體而進行得比較快，也不會因為要求高品質而進行得比較慢。要求高品質的軟體通常會導致較快的產品交付，反之則導致延後且不可預期的交付時程（這個觀念Bob大叔在《Clean Code》也有提到）。

如果光談到速度與成本，品質好像只是個與「經濟」相關的因素，但品質與人性也有關。如果一直開發出被客戶罵到臭頭的軟體，開發人員的士氣一定非常低落。虧欠太多「技術債」的產品，也沒人想接手開發，甚至想要逃離負責的開發團隊。

既然品質不可妥協，而開發時程與成本（主要是人力）在XP裡面基本上是固定的因素，所以XP選擇了調整範圍（scope）。基本上Scrum也是採取相同策略，把時程、成本固定，而讓交付範圍（產品功能的多寡）保持彈性。

追求高品質是一個過程，如果你知道如何達到高品質，但現況的限制讓你無法立即施實所有改善品質的策略，可以在考量現況的情況下儘量提供高品質的產品，日後再安排時間來提升品質。例如，明天就要交貨但臨時發現bug。你知道一個完美的解法，但需要花三天的時間，緩不濟急。怎麼辦？先想一個quick-and-dirty的解法讓明天系統可以上線，之後再來償還「技術債」。

• Baby Steps（小步驟）：改變都是痛苦的，一次變動太多可能會越改越糟糕，引發改變的理想過於遠大但時間和資源卻過於不足。按部就班的小步驟改變比較容易控制，就算失敗要重來付出的代價與風險也相對較低。這個原則和Alexander所說的「piecemeal growth（逐步成長）」是相同的道理。

「小步驟」原則在XP中處處可見，TDD的步驟就是典型的例子，寫一個會失敗的測試案例，然後用最簡單的方式實作程式碼讓測試案例通過，功能完成之後再套用重構（另外一種小步驟改善技巧）來改進設計品質。

「小步驟」也呼應「改善」、「Flow」與「失敗」這些原則，和「精實開發」的「小批量多樣化生產」也有異曲同工之妙。

• Accepted Responsibility（承擔責任）：責任不是被指派或是硬塞到開發人員身上，而是必須要每個人自己去接受與承擔（突然想到〈QBQ之正面思考〉這一篇文章）。在XP裡面，做事的人負責估算時間，開發story的人也同時負責設計、實作、測試它。

Scrum也有類似的作法反映這個原則，像是PO、ScrumMaster、Team的責任分擔，還有組織「自我管理團隊」。

***

友藏內心獨白：XP的14個原則比青年守則還要多2條。

談談XP（2中）：Principle

Feb. 13 13:40~15:11

 

今天繼續介紹XP的第5~9個原則：

• Improvement（改善）：改善是一個通往「完美（perfect）」的過程，在軟體開發領域，「完美」是動詞，不是形容詞。世間不存在「完美的開發流程」、「完美的設計」、「完美的公司」、「完美的團隊」、以及「完美的客戶」，但我們可以努力「完善（改善）」我們的「開發流程」、「設計」、「公司」、「團隊」、以及「客戶」。改善並不是等待一切就緒才開始行動，而是儘快找到一個開始點，然後立即開始改善行動。這個觀念類似Scrum所說的「inspect and adopt（檢驗與調適）」，請參考〈捨我其誰之我不知道要做多久〉與〈專案需求一直變動要如何開始第一個Sprint之做就對了〉。
• Diversity（多樣性）：多樣性不只對生物界很重要，對軟體開發也很重要。開發團隊成員如果每個人都很類似，雖然相處下來可能會很容易，沒什麼重大衝突，但卻可能無法形成高效團隊。大家都知道「近親繁殖」會產生有缺陷的後代，團隊同樣需要不同技能、背景、經驗、看法的成員。雖然可能會因為多樣性產生衝突（conflict），但應該把這種衝突看成是改善機會而不是當作問題。XP的Whole Team實務做法反映了多樣性這個原則，Scrum的cross-functional team（跨職能團隊）也反映這個原則。XP和Scrum的各種規劃會議也反映了多樣性，此外Scrum的retrospective meeting（自省會議）可以用來解決多樣性團隊可能引發的衝突（迷之音：這是在介紹XP還是Scrum啊…）。
• Reflection（反思）：有人說：「什麼是笨？笨就是用相同的做法，卻期待有產生不同的結果。」古人云：「吾日三省吾身」，好的團隊也要經常反省做事的方法，以謀求改善之道。XP的pair programming（結隊編程）與continuous integration（持續整合）就是一種呼應反思原則的實務做法。Scrum的retrospective meeting當然更是一種反思活動。

光是反思而沒有行動也是白搭，因此XP的反思一定伴隨著行動。Pair programming同時具備反思（code review）以及修正（revise），持續整合也是具備檢查與修正（當發生broken build要及時修復）。Scrum的retrospective meeting也有人建議要針對討論改善項目列出行動方案。

節錄自網路。

• Flow（流、流動、流暢）：讓軟體開發所有的活動同時持續地穩定流動（迷之音：怎麼有種精實開發的fu）。為了要達到「貨（工作項目）暢其流」的目的，不能像傳統開發方法把工作項目切割得太大塊（big chunk），例如12~24個月才釋出軟體，或是花三個月做需求分析，再花三個月做架構設計。XP的Weekly Cycle、Continuous Integration、Daily Deployment等實務做法都反映了Flow這個原則。
• Opportunity（機會）：古人云：「聞過則喜」，如果能夠抱持著把問題視為改善機會的心態，則團隊將會變得很不同。如何把問題變成機會？例如，沒辦法為產品做出長期規劃！沒關係，把產品開發拆成幾個釋出版本，先規劃第一個釋出版本。開發人員寫出的程式bug太多！沒關係，試著用結隊編程。有時候你沒辦法選擇自己、團隊、公司、或客戶，現況就是現況。現況並不完美，好的流程或是開發方法可以把問題暴露出來。將問題視為機會，才有可能跳脫18層地獄。不想面對問題，只想逃避，永遠還是在這18層地獄裡面輪迴，無法轉世投胎。

***

友藏內心獨白：止於至善。

談談XP（2上）：Principle

Feb. 13 10:45~12:15

 

XP列出了14個Principle（原則），數量將近是Value的3倍（XP有五個Value）。藉由這些原則，可以引導出實務做法（Practice）。今天先介紹前4個原則：

• Humanity（人性）：軟體是「人」寫出來的（迷之音：真的嗎？），所有開發方法都不應背離人性考量，否則終將難以持久。要求員工犧牲個人與家庭生活來滿足工作進度，長期來看這是違反人性的作法。把人當成「CPU」來使用，可以在不同專案之間隨意調配，而且希望每顆CPU都可以多工，最好可以「超頻工作」，這也是違反人性。

Kent Beck在書中提到，好的開發人員有以下五項人性面的需求：

• Basic safety（基本安全性）：免於挨餓、受傷。害怕失去工作、低薪、爆肝都違反了這一點需求。
• Accomplishment（成就感）：有機會對團隊、公司、社會貢獻一己之長。做到一半夭折的產品、打死不釋出的軟體、釋出之後沒人用的軟體，都傷害了這一點需求。
• Belonging（歸屬感）：對於身屬於某個團體感到驕傲而且對於團體的目標能有所貢獻。如果公司或團隊一直在破壞環境、製造出產生82億次駭客攻擊事件的APP、申請身分證6個小時才能辦好，搞到「日月無光、人神共怒」，走在路上不敢跟別人說你是哪家公司的員工，就傷害了這一點需求。
• Growth（成長）：可以增長自己的技能與視野。在同一家公司工作10年，回頭一看卻只有一年的工作經驗，然後重複9次；名為開發軟體但做事卻都不動腦筋；一直用相同的方法做事卻期待能出現不同的結果；不願意花錢培訓員工。以上做法，都傷害了開發人員對於自我成長的需求。
• Intimacy（親密性）：和團隊成員可以打成一片，彼此了解彼此的想法。人力派遣、把人當成「resource pool」裏頭可以隨意支配的資源、分工不合作，每個人只專注於自己手邊的工作，傷害了這一點需求。
• Economics（經濟因素）：軟體既然是由人所開發，只要是人就要領錢，有人得為軟體開發的一切活動買單。因此，軟體開發不能忽略經濟因素。如何在有限的資源內做出最好、最合適顧客的產品，也是開發人員需要思考的議題。確定軟體開發活動滿足商業價值、目標、需要，而不是「爽到開發人員，痛苦到客戶」。

從經濟因素引導出敏捷開發所謂的value-driven（價值驅動）做法（請參考〈計畫驅動 vs. 價值驅動〉），以及敏捷合約的pay-per-use，用多少買多少精神。另外像是incremental design（增量設計）或是精實開發所提到的「消除浪費」（請參考〈只有一位開發人員的專案也需要了解如何消除七種浪費〉）也都算是符合經濟原則的實務做法。

• Mutual Benefit（互利）：雖說「吃虧就是占便宜」，但是在正常情況下人都不想吃虧。任何合作關係，如果不是合作的雙方或多方都可以互助互利，則合作關係很難持久。舉個例子，傳統要求開發人員寫一大堆分析、設計文件的作法，得利者主要是公司老闆（因為一直壓榨員工，怕員工跑掉程式沒人看得懂），或客戶（因為付很少錢且時程很趕，怕外包商隨便設計日後無法接手）。開發人員並沒有獲益，反而需要額外花很多功夫來撰寫這些「無用的文件」。XP的做法則是：透過自動化測試幫助今日的開發人員做出正確的設計、幫助日後的開發人員容易維護系統、也幫助客戶可以獲得bug比較少的系統。一舉三得。
• Self-Similarity（自我相似）：大自然的許多設計都具備自我相似性，一旦發現好的設計，便想盡辦法重複使用。相同的原則可適用於軟體開發，例如，XP的開發步驟建議先寫一個失敗的單元測試再寫程式碼想辦法讓單元測試通過。將此規模放大到每一個開發週期，可以為story寫失敗的驗收測試，然後再撰寫程式想辦法讓story通過驗收測試。持續整合也具有自我相似性，在開發人員的規模，整合自己本機端的程式。將程式碼送交到版控系統之後，整合版控系統上（團隊層次）當下片刻的程式。下班之後的每日建構（daily build）整合一日之內團隊所開發程式。每個開發週期所建構的「潛在可釋出產品增量」整合這個開發週期團隊所開發程式。產品釋出之前所做的建構，整合這個釋出版本所包含的程式。

***

以前沒留意，重新整理一次XP的Value、Principle，發現有很多和Scrum、Lean（精實開發）的觀念其實是重疊的啊，只不過不同的人用不同的語言來解釋相同的「特質」罷了。難怪Alexander要說：「Quality Without A Name」啊。

***

友藏內心獨白：雖說Quality Without A Name，結果還是要記一大堆Name。

2012緬甸考察之旅Day11-A仰光街道與碼頭，回台北

Feb. 12 22:04~22:33

今天就要搭機回台灣，結束11天的緬甸之旅。早上吃完早餐約7點左右利用回國前的一點時間到仰光街頭閒逛。

 

遇到一家電腦店。

 

住宿的旅館離河邊很近，往河邊方向閒逛。經過一間寺廟以及熱鬧的市集，沒多久就來到河邊（出海口）。

 

早晨的陽光灑在寬廣的河面上，讓人有點分不清是日出還是日落，好漂亮。

***

回旅館之後辦好退房。

 

搭計程車到仰光國際機場。

 

到仰光國際機場，幾乎都是要回台北的人。班好登機手續之後入關，整個候機室空空蕩蕩的，旅客相對顯得很少。

 

搭上飛機，順利回到台北。

***

友藏內心獨白：還蠻好玩的。