l

2012年7月31日 星期二

馬蓋先與敏捷精神

July 31 15:40~16:50

image

 

講到馬蓋先,年輕一輩的人可能不知道,但是想當年(1986)「百戰天龍」這個影集在台視播出時,可是非常、非常、非常、的轟動。說真的過了那麼久的時間,Teddy對於影集的內容只剩下非常片段的模糊記憶。最近因緣際會之下,又看了幾集,突然有種感覺:馬蓋先的做事方法,不正是敏捷精神嗎?

話說在某一集中,美國某個地底研究中心發生爆炸,大量強酸溶液溢出,眼看著就要汙染當地的地下水源。此時馬蓋先適時地出現,準備深入地底救出被圍困的人,並且要排除強酸污染的危機。場景停留在馬蓋先正準備從地面管道鑽入地底時:

安全人員:你就這樣空著雙手下去,什麼設備也不帶?

馬蓋先:重點不是我帶了什麼,而是一路上我可以撿到什麼

***

馬蓋先要解決的問題,都是一些常人無法處裡的「疑難雜症」,因此,無法用傳統「擬定計畫」、「實施計畫」的步驟來解決問題。只能且戰且走,隨機應變。影集中的馬蓋先,有著豐富的物理與化學知識,能文能武,上山下海都難不倒他。有了這樣的能力,外加一隻瑞士刀以及一綑膠帶,自然可以應付各種突發狀況。

以上所描述的能力,其實跟敏捷方法,尤其是XP,所希望開發人員或是開發團隊具備的能力,是很相近的。傳統軟體開發的思維,特別是在台灣那種工廠代工式的思維,總是希望只要能夠隨便找到「大量的一般人」,然後一直加班、一直加班,就可以生出東西來。為了讓這些不用太花腦筋的一般人可以做出東西,所以要很強調規劃、書面文件、控管等等的。

這幾年敏捷方法比較流行了,有些團隊或公司想說「那我們也來趕個流行,也導入敏捷方法好了」。好啊,那怎麼導入?啊,聽說Scrum很簡單就可以上手,哪就來導入Scrum好了。

三個月後…

啊,怎麼導入Scrum之後,原本軟體開發遇到的問題都沒有解決啊。還是抓不住使用者真正的需求、系統分析做不好、軟體架構不會設計、寫出來的程式bug一大堆。我看還是改回傳統的「爆肝流程 加班流程」好了,這個最不花腦筋。

***

組織與團隊要能夠變得敏捷,人員的挑選、訓練、帶領是很重要的一環。一艘快要沉的船,不會因為導入Scrum就自動浮出水面。如同馬蓋先有著豐富的物理與化學知識,敏捷團隊開發人員,也要有著很強的專業能力,否則很難成功。

軟體專案所牽涉到的專業能力很多,舉凡需求分析、系統分析、系統設計、程式撰寫、測試、整合、維護等等,都算。這些能力,在沒有導入Scrum之前,就應該要好好培養了。Scrum只是一個開頭,讓團隊可以檢視自己缺少什麼,並依據現況訂出各方人馬都可以接受的改善行動,並持續加以修正。

***

看到這邊鄉民們可能會問,那要怎麼變成馬蓋先啊?答案很簡單:

  1. 每天按時收看搞笑談軟工。
  2. 買一本《笑談軟體工程:敏捷開發法的逆襲》回家仔細閱讀。
  3. 報名Scrum敏捷方法實作班
  4. 報名Design Patterns這樣學就會了

以上藥方按時服用,大概就可以變成1/3個馬蓋先,成效也算不錯了。

***

友藏內心獨白:應該沒有人想變成老皮或是賈大頓吧。

2012年7月30日 星期一

工商服務:Design Patterns一日體驗券

July 0 11:30~23:36

螢幕快照 2012-07-29 下午11.35.36

 

上禮拜四有一位鄉民來信問詢問「Design Patterns這樣學就會了:入門實作班」課程的問題,因為這門三天的課程總價比較高一點,該鄉民想知道是否可以先將課程內容大致的投影片提供給他參考,讓他作為是否報名的決定。

雖然在上課當日Teddy會提供上課內容講義與練習程式碼範例,但是並無法提供上課電子檔給學員,所以也沒有辦法將教材先寄給該位鄉民先審閱之後再決定是否報名。Teddy非常能夠理解這位鄉民的考量,因為Teddy自己也曾經花錢去上過很貴的課,但是課程結束之後卻覺得沒有值回票價的感覺。為了減輕鄉民們的疑慮與負擔,於是Teddy提供三個建議給該鄉民參考。

  1. 電話溝通:Teddy公司的電話是 02-8772-4686,如果鄉民們對於課程內容有任何的問題,歡迎來電洽詢。
  2. 面對面溝通:Teddy的公司在「臺北市忠孝東路三段48號2樓216室」,位於台北科技大學育成中心之內(忠孝新生捷運站三號出口)。鄉民們也可跟Teddy約時間到公司,Teddy可以當場打開本課程的投影片並為鄉民們解說課程內容與進行方式。
  3. 一日體驗券:Teddy在課程報名網頁中(請按這裡)增加了「一日體驗券」的票種。如果鄉民們不放心一次購買完整課程,可選擇先購買 NT$ 8000 7000 元的一日體驗券。上完第一日課程之後如果覺得有需要,可以選擇負擔早鳥票的差價以NT$ 15000的金額續購後兩日的課程。補充說明一下,一日體驗券沒有限額,有需要的鄉民們請自行服用XD。報名「8/15-16日Scrum敏捷方法實作班」的鄉民們便具備Scrum之友的身分,可以購買Scrum之友的票種。如果Scrum之友購買一日體驗券之後還想繼續上後兩天的課程,只要補繳Scrum之友票價20500減7000的差價(13500)就可以了。

***

當初開這門課的時候,Teddy就抱持著「只要有一個人報名,就算是賠錢也一定要開課」的決心。目前還真的有一位公司遠在高雄的鄉民報名並且完成繳費,沒意外的話這門課是開定了。

有人問Teddy,為什麼外面有些人開的課程,每班50個人,平均每個小時只要收NT 500,而Teddy開的課程,卻要NT 1000左右?

答案很簡單:

  • 師資與教材內容優良:這一點有點老王賣瓜的嫌疑XD。因為Teddy目前開的課程都是由Teddy本人親自擔任講師,所開的課程,包含已經公開報名的Scrum與Design Pattern,還有正在籌備中的Exception Handling Design and Refactoring與Agile Practices:Configuration Management, Testing, and Continuous Integration,都是Teddy有多年理論與實戰經驗才敢開課。
  • 小班教學與分組活動:因為Teddy開的課程屬於小班制(10人以上,20-25人以內)且有很多分組活動或實際練習,每一組都會安排一位有實戰經驗的助教協助帶領活動或是實作的進行。
  • 課後服務:Teddy認為課程也是一種產品,也應該提供售後服務。當課程結束之後,學員們可以加入專屬的Facebook課程社群,有問題可透過課程社群發問,會有專人提供服務。

Teddy個人是希望既然學員付錢來上課,Teddy就有責任要讓學員們在離開教室之前,就能夠掌握課程的重點。翻成白話文就是:希望當場就能夠學會如果一班收個50個人,當然學費可以減半,但是課程進行方式就只能變成傳統的那種講師在台上講,學員坐在台下聽,基本上是不太可能安排實作活動或是練習。

Teddy曾經試過,用傳統的方式來教Design Pattern,一班大概20個人(也算是小班制,但沒有分組練習)。雖然Teddy使出渾身解數,但是因為沒有當場練習,根據Teddy的觀察,當場可以進入狀況而且立刻聽懂的人可能只有1/3。課程結束之後,有另外1/3下課之後會找機會自己稍微練習一下,最後約有1/3是抱持放棄的心態。所以這次Teddy才會將課程設計為「實作班」的形式,希望真正有心想學好Design Pattern的人,花費一次的時間,便可學會。

***

話說回來,課程貴不貴這件事,並不能單純依據「平均每小時收多少錢」來判斷。如果一門課講的都是廢話,就算是免費的,這種課不但不「便宜」,而且很貴。為什麼?因為它浪費了學員們寶貴的時間啊。古人有云:千金難買寸光陰。浪費時間去聽沒有意義的課程,就算課程本身免費,「寸光陰」卻是無價。

一個小時1000元左右的課貴不貴?以Design Pattern來說,Teddy從1997年自學至今,也是因為開發了幾十個專案,讀了幾十本的書和papers,也才有膽量敢出來開課(因為誤人子弟是要下18層地獄滴…Orz)。對於有心想學好Design Pattern的鄉民,Teddy認為這樣的收費應該算是 很便宜 合理的價位(絕對不是暴利啊…XD)。而且應該說是聽到賺到,省了很多自己慢慢摸索的時間(千金難買寸光陰啊XD)。

其實Teddy也不知道這樣的思考模式與課程安排方式,在台灣這種凡事講求cost down的風氣下,能不能生存下來。如果鄉民們下次發現Teddy開了單價比較便宜的「非實作班」,也不要太過驚訝。套句現在很流行的Lean Startup(精實創業)的術語,這叫做Pivot(山不轉路轉…Orz)。

***

友藏內心獨白:下次開課前要記得要先辦個主題演講。

2012年7月29日 星期日

2010冬遊日本關西Day8-回台灣

July 29 11:43~12:25

今天要回台灣了,早上6點先到路上逛一逛,欣賞一下京都的街景。

01

 

02

03

04

05

 

06

07

08

09

 

天空好藍

10

 

11

12

 

在七點整趕回旅館吃早餐。

13

 

離開旅館來到京都車站,準備搭車到關西機場搭飛機。

14

15

 

到機場了。

16

17

18

19

20

上飛機。

22

 

吃飯。

21

 

到桃園機場。

23

 

***

友藏內心獨白:玩八天好像太少了XD。

2012年7月28日 星期六

2010冬遊日本關西Day7-E清水寺賞夜楓

July 28 10:00~10:51

離開咖啡廳之後快步走回清水寺,夜間打燈的感覺真的不一樣,和白天相比,判若兩寺。雖然來夜間參拜的人潮眾多,但因為夜色的緣故,與日間相比多了一份寧靜。

01

02

03

04

 

京都12月初的夜晚還真有點冷,如果逛到肚子餓,路邊有熱騰騰的湯麵可以吃。

05

06

 

排隊舀水喝,排隊的人潮比白天少了許多。沒想到舀水的勺子還有紫外線消毒的設備耶,好猛XD。

07

08

 

夜晚的蠟燭…不對,是京都塔,看起來像是一根小小的蠟燭。

09

 

打燈之後,楓葉看起來好像變得更紅了。

10

11

12

肚子有點餓了,吃碗麵先,順便暖暖身子。

13

 

時間差不多了,準備離開清水寺。再看幾張照片。

15

16

 

清水寺門口賣票的,晚上8:20左右,人已經少很多了。

18

17

 

商店街也沒什麼人。

19

20

21

 

商店街人是少了,但是公車人好多啊…Orz。

22

 

晚上九點半回到了旅館,隔天睡醒之後就要回台灣啦。

23

***

友藏內心獨白:下回來看夜櫻吧XD。

2012年7月27日 星期五

除錯的態度

July 26 20:51~22:00

image

連續寫了好幾天的跨界開發,好像快演變成本土劇那種拖戲的劇情,所以今天要換個主題,談一個除錯(debugging)的觀念。以前Teddy還在帶team的時候,經常有人會找Teddy一起幫忙除錯(pair debugging)。基本上合作除錯時Teddy會要求:

  • 請對方說明一下錯誤訊息與錯誤現況,如果可以找出可讓此錯誤重複出現的操作模式更好。
  • 請對方解釋一下可能出錯的程式邏輯,包含系統架構(模組與模組之間的互動關係)或是一起看一下某段程式碼的內容。
  • 如果有測試案例,則跑一下這些測試案例,看看結果如何。
  • 請對方猜測可能發生錯誤的原因。

接下來Teddy會以一個第三者的角度,用問答的方式來詢問對方問題,例如:

  • 這個API這樣子使用對嗎?它的傳回值是什麼意思?如果是null會怎樣?
  • 這個物件是由誰來負責初始化的?會不會根本就初始化失敗但是卻沒人發現?
  • 如果網路斷線,這段程式可以立刻知道嗎?還是會卡在這個method上面?
  • …(一直問下去,等到問不下去的時候通常bug也快找出來了)

這種除錯的方式看起來很簡單,沒錯,是很簡單,只要一直問問題就好了。但是,實際上問到後來經常會搞到問答的雙方火氣很大。為什麼?

***

被問者內心獨白:這個問題的答案明明就很明顯啊,用膝蓋想就知道這段程式是OK的,有什麼好問的?一直問一些無聊的問題,簡直在浪費我的時間啊。我這根本是「請鬼拿藥單」啊!

發問者內心獨白:這些程式又不是我寫的,你沒有辦法說服我這段程式真的沒問題,我又如何可以排除心中的疑問呢?話說回來,我是來幫忙除錯的耶,你還不合作一點,這樣我要怎麼幫忙?

***

在除錯的過程中,或者是廣義的來講,在寫程式的過程中,如果心中有任何疑惑,千萬不要用「猜的」,或是「抱持著在公堂之上大膽假設一下應該不犯法」的這種想法。因為,通常只要是鄉民們心中不確定而又想要偷懶打混的情況下所寫出來的程式,幾乎都會出錯。所以在《The Pragmatic Programmer》這本書中的第97頁,作者建議鄉民們在除錯的時候,要抱持著「Don’t Assume It---Prove It」。除錯的時候不要用「我認為…」,請證明給Teddy看。

鄉民甲:什麼,除個錯還要做證明題喔,那「拎杯(我)」不要寫程式了(摔滑鼠)。

謎之音:鼠在人在,鼠亡人亡XD。

這裡所說的證明不是用數學的方法來證明,最簡單的方法就是寫一隻單元測試程式,來確認自己的假設是對的就可以了。大體而言,就算鄉民們在開發軟體的時候有寫單元測試,但是,既然出現錯誤,而單元測試又全部通過,就代表這個錯誤沒有被現存的單元測試給找出來(這一句是廢話XD)。所以,翻成白話文的意思就是說,單元測試寫得不夠多。既然如此,就利用除錯的機會,順便 補血 補寫一下單元測試,這也是補寫測試最好的時間點。

為什麼除錯是補寫測試最好的時間點?因為,bug是一種很奇妙的東西。今天就算鄉民們寫了幾千、幾萬行的程式,你的老闆都覺得這是理所當然的,鄉民們也得不到任何的稱讚。但是,只要鄉民們解了一個bug,尤其是那種「看起來很棘手的bug」,在老闆的眼中,馬上變成大紅人。也由於bug具備某種神祕與不可測的性質,所以也很難預估需要多久的時間才修的好。所以,此時不藉機補寫測試更待何時。

***

嘴砲雖然厲害,但是光靠嘴砲是無法解bug滴。請用測試案例說服你的夥伴,不要用嘴砲打他XD。

***

友藏內心獨白:跨界系列再寫下去Teddy就要從人間界跨到靈界啦 嚎啕大哭

2012年7月26日 星期四

Scrum框架下的跨界開發(8):寫到這邊突然想到Pattern Languages

July 25 22:33~July 26 00:21

螢幕快照 2012-07-25 下午10.50.21

 

先說明一下,本集內容有點玄,看不懂為正常現象(迷之音:文「玄」慎入,請勿越級打怪XD)。

話說跨界開發這件事寫到第八集,Teddy突然想到Christopher Alexander的pattern languages理論。先解釋一下上面這張圖,和昨天畫的那張圖很像,只是有些地方稍微修改一下。先解釋一下幾個名詞:

  • World:真實世界,也就是問題發生的地方。有問題,就代表有需求,所以才會有人說「需要為發明之母」。例如,鄉民們要開發甚麼ERP系統、汽車控制系統、體重控制軟體、雲端殺豬系統。這些系統都是因為要解決真實世界的某些問題而產生的,也就是說這些系統的「需求」發生在真實世界。
  • Machine:開發軟體以解決某個發生在真實世界的問題,就相當於製造一台「機器」。所以,這個Machine就是所謂的Solution。事實上,Teddy可以大膽說,鄉民們在學校或是工作中所受的訓練,絕大多數都屬於Solution的範疇,只有一小部分與Problem有關。例如,OOAD,A的部分(分析)是屬於Problem,其餘D的部分(設計),以及後來的實作、測試、寫手冊等等,都屬於Solution的範圍。再舉敏捷實務做法為例子,什麼持續整合、單元測試、pair programming、建構管理、shared code、測試驅動開發,這一些全部都是Solution。更別提程式語言、演算法、資料結構,當然也是Solution。
  • Application Domain:真實世界很大,而你所製作出來的機器很小…Orz。你的機器與真實世界相關的這個部分,就稱為Application Domain(應用領域)。例如,鄉民們可能有聽說過,某人是在負責銀行業、保險業、物流業、IC設計業等等。這些不同的「業別」,就可視為不同的Application Domain。看到這邊鄉民們可能會為:幹嘛分什麼Application Domain?很簡單,因為真實世界太大,而鄉民們(工程師)又太渺小,不可能做出一個可以解決全世界問題的機器出來。所以才要把世界切成不同的Application Domain,這樣問題變得比較小,而鄉民們才有辦法可以把機器給造出來。

World與Machine之間的箭頭,Machine的建造需要從World獲得需求。而隨著Machine的建造,應用到World中,則可以讓鄉民們更清楚的了解需求。

由上圖可以看的出來,很明顯的World和Machine各是一個孤島,要把World所發生的問題,轉成一個Machine,這中間的過程有一個很大的鴻溝,因此需要一座橋樑,讓這兩個孤島上的人,可以互相往來。這是從World到Machine的「跨界」。World的內部和Machine的內部也存在著跨界的問題,關於Machine內部的跨界問題Teddy在《Scrum框架下的跨界開發(2)》曾經提過,這邊就不在重複。

現在的問題是,「誰」,或者是「什麼東東」,可以扮演這個Bridge的角色?想到這個問題,Teddy的腦海中浮出兩個答案:

  • 流程:不管是傳統的結構化分析與設計、後來的物件導向分析與設計、RUP、敏捷方法(例如Scrum),都是在告訴鄉民們,如何從A—>D的過程。也就是從分析(What to do。要做什麼東東,也就是把問題搞清楚)到設計(How to do。問題清楚了,那接下來要怎麼做,解決方案是什麼。)所以,流程本身是一個很好的Bridge。
  • :10幾年前Teddy剛開始接專案的時候,從需求分析、系統設計、實作、測試、寫手冊、到客戶端裝機,全部都是一個人包辦。所以,人也是一種很好的Bridge。

***

寫到這邊和pattern languages有何關係?Teddy想到當初Alexander發明pattern languages的出發點,其實跟上面這「流程」和「人」有很密切的關係。話說Alexander觀察到,在農業社會,絕大多數的人所居住的房子,其實都是自己蓋的。古時候沒有什麼「建設公司」幫忙蓋集合住宅,也沒有政府提供合宜住宅。再加上大部分的人口都是務農,也沒多餘的錢請人家蓋房子。所以,要房子嗎?好,爸爸蓋給你XD。

但是,現代工業社會因為強調所謂的「效率」,因此產生了「專業分工」以便於大量生產。所以,建商出現了,仲介出現了,原本人類具有的蓋房子能力,也因為專業分工的緣故而消失殆盡。

在此Teddy先插花一下,專業分工的這個觀念很重要,因為,傳統上大家都認為專業分工是很好的。但是請注意到Scrum的cross-functional team,以及XP的pair programming與shared code,其實多多少少存在著打破專業分工的精神。

簡而言之,Alexander希望人們可以重拾以往「具備自己蓋房子」的能力,而他所提出的方法就是pattern languages。鄉民們還記得pattern的最簡單的定義是什麼嗎?

A pattern is a proven solution to a recurring problem in a specific context.

一個模式是在特定領域中,針對一個重複發生的問題,已被證明有用的解決方案。

Pattern包含了problem和solution,所以一個pattern就是一個什麼?想到了沒?

每一個pattern就是一個小小的bridge,可以解決一個小問題。一堆相關的pattern,就形成一個pattern language,可以解決一個較大的問題。

***

Alexander在他的書中說過,pattern is a process and a thing。這個觀念Teddy在《Pattern是個雙面人(上)》和《Pattern是個雙面人(下)》有解釋過。Teddy認為Alexander當初要解決的問題,基本上就是一個「跨界」的問題:讓沒有具備建築能力的廣大鄉民們,能夠在學習pattern之後,具備這樣的能力。這不是跨界是什麼?不只跨界,還跨很大哩。

鄉民甲:我以前是水電工,去了鋸匠之後,我現在是建築師XD。

Teddy:這也是一種跨界喔。

***

寫到這邊Teddy自己也不知道在寫些什麼…Orz。最後一個重點,為什麼繼Scrum課程之後,Teddy要在8/25開「Design Patterns這樣學就會了:入門實作班」這門課?Design Patterns不是寫寫程式,或是買本書看一下就懂了嗎?10幾年前Teddy剛學Design Patterns的時候,Teddy只是把Design Pattern看成是一種高深的物件導向設計招式。但是讀了Alexander的書之後,慢慢覺得pattern與pattern language方法其實是一種很好的分析問題工具,可以幫助工程師們把困難的問題經過pattern的訓練,深刻了解問題的本質。

但是,為什麼要深刻了解問題的本質?每天跟派大星一樣爽爽地過日子不是很好?!答案很簡單,因為要成為一個更好的工程師。聽起來很無聊,但是Teddy認為,這是一個很重要的能力。曾經有人問Kent Back,XP的做法是否會排斥能力很強,但是可能不喜歡跟其他人合作的人。Kent Beck說:什麼叫做很強的人?從他的角度來看,能夠讓你的同事把原本認為很難的問題,經過你的協助之後,馬上開竅,具備解決問題的能力。這種人才是Kent Beck所認為的很強的人,而非自己很強但卻不管別人死活的那一種人

Teddy認為Alexander的pattern language方法可以協助工程師們變成Kent Beck所說的那種很強的人。但是,此方法有點抽象,直接學習可能會死人XD。其實是怕說開這樣的課應該沒人來上。所以Teddy只好循序漸進,先從比較實用的Design Pattern開始教起,在課程中慢慢灌輸一些Alexander最原始提出pattern的想法。

難道課名叫做「Design Patterns這樣學就會了」是一種幌子,實際上是要在課堂上傳授邪教?

想太多,來了就知道。

***

友藏內心獨白:怎麼本篇又被置入性行銷啦XD。