l

2012年12月31日 星期一

2012年終心得:堅持

Dec. 19 00:00~01:02

image

 

故事一:完成不可能的任務XD

今天是2012年12月31日,鄉民們看到這篇文章的時候Teddy人剛好在國外「考察新興市場」。在一年前的某一天,Teddy決定在2012年這一年之間,每天都要在部落格上發表一篇文章。一年過去了,Teddy總算不辱使命,完成了這個任務(有幾次一天之內還發表了兩篇熱戀)。

剛開始的前三個月,真的還有點小痛苦。有時候就是腦袋空空,呆坐在電腦前面1、2個小時卻一個字也擠不出來。怎麼辦?涼拌,還是要寫啊。生命會找到出這句話真的沒錯,堅持下去之後,慢慢地,每天發布一篇部落格文章這件事,似乎變成了日常生活的一部分。習慣之後,每天完成這件任務的困難度也就降低了。但這並不是說Teddy每天花在寫部落格的時間變短了,基本上寫一篇文章所花的時間從構思到完成,至少都需要1~2個小時的時間,但是心理層面對於每天都必須要做這件事情的反抗度逐漸降低(翻成白話文就是說:認命了挑眉質疑)。

先幫自己按個讚很棒

***

故事二:Certified ScrumMaster課程

今年12月初由國外講師在台北舉辦的Certified ScrumMaster課程,在報名截止前一週,其實還沒有達到開課人數。原本Teddy是想要放棄了,但是想到授課的國外講師Emerson Mills願意不遠千里從美國跑來台灣開課,如果這次沒有開成,人家可能就不想要經營台灣市場了。日後想要上這門課的鄉民們,只好到國外去上課,費用又更貴。不然就只能去參加Teddy本人不是很推薦的「其他課程」。就在Teddy很掙扎的時候,當天晚上Teddy去參加 C. C. Agile聚會,有熱心的鄉民們知道狀況之後當場發起團報,但是就算是加上團報的四個人還是不夠…Orz。隔天Teddy心想:就差一小步,還是要努力一下不應該輕易放棄。於是Teddy又當起了「直銷業務」,直接聯繫了幾位有在導入Scrum的朋友,在半哄半騙的情況下,最後超過了最低開課人數,讓課程順利的舉辦。

事後Teddy覺得滿開心的,倒不只是因為課開成了這件事情,而是:

  • Emerson Mills上的Certified ScrumMaster課程真的教得很棒,就算是Teddy在2009年已經上過Bas的Certified ScrumMaster課程,上完兩天的課之後還是覺得學習到不少東西。
  • 有幾位來上Certified ScrumMaster課程的學員之前已經上過Teddy教的Scrum敏捷方法實作班。原本Teddy會擔心這些學員只是因為給Teddy面子來上課,但是實際上完課程之後,Teddy發現這兩門課所切入的角度剛好可以互補。也就是說,學員的錢沒有白花啦熱戀

以上不是要打廣告,Teddy想表達的是,在快開不成課的當下,放棄是最容易的選擇(但卻未必是最好的選擇)。Teddy可以冠冕堂皇的用以下理由安慰自己:「經濟不好,兩天定價40,000塊台幣的課在台灣沒市場啦」。一念之差,最後的結果當然是完全不一樣。

結論就是:覺得對的事情,要竭盡所能的堅持下去。在尚未盡全力之前,不要輕言放棄。

***

友藏內心獨白:2013還要繼續每天寫一篇嗎目瞪口呆

2012年12月30日 星期日

2009冬遊日本京都Day2-C平安神宮

Nov. 27 07:37~07:55

離開二條城之後吃完午餐來到平安神宮,此時已是下午兩點半。

螢幕快照 2012-11-27 上午7.39.23

螢幕快照 2012-11-27 上午7.40.46

 

看一下地圖,平安神的花園很漂亮,雖然要收費但是值得一看。

螢幕快照 2012-11-27 上午7.45.18

螢幕快照 2012-11-27 上午7.40.57

 

不知為何這裡會有一列日本最古的電車。

螢幕快照 2012-11-27 上午7.41.09

螢幕快照 2012-11-27 上午7.41.16

進入花園之中,更有一種時空凝結的感覺,非常的安詳。

螢幕快照 2012-11-27 上午7.41.29

螢幕快照 2012-11-27 上午7.41.46

螢幕快照 2012-11-27 上午7.42.03

螢幕快照 2012-11-27 上午7.42.13

螢幕快照 2012-11-27 上午7.42.22

螢幕快照 2012-11-27 上午7.43.14

螢幕快照 2012-11-27 上午7.42.42

螢幕快照 2012-11-27 上午7.43.39

螢幕快照 2012-11-27 上午7.43.55

螢幕快照 2012-11-27 上午7.44.18

 

要是沒有工作人員細心的照顧與維護,庭園也不可能維持的這麼好啊。真是辛苦了。

螢幕快照 2012-11-27 上午7.44.37

螢幕快照 2012-11-27 上午7.44.45

 

在這裡待了70分鐘左右,離開前再看一眼。

螢幕快照 2012-11-27 上午7.45.47

***

友藏內心獨白:還好有花錢入內參觀庭園。

2012年12月29日 星期六

2009冬遊日本京都Day2-B二條城

Nov. 27 19:03~19:27

離開京都御所之後來到二條城,由下面這張地圖可以看出來,城中建築物不多,綠地倒是很多。

螢幕快照 2012-11-27 上午7.03.47

螢幕快照 2012-11-27 上午7.04.14

螢幕快照 2012-11-27 上午7.05.34

 

二條城中的「二之丸御殿」是可入內參觀的重點,但是無法拍照,只能拍一張放在外面的雨傘架。這個可上鎖的雨傘架還是第一次看到耶,當時覺得很新奇。

螢幕快照 2012-11-27 上午7.12.50

 

離開「二之丸御殿」之後,接下來就是參觀庭園與建築。

螢幕快照 2012-11-27 上午7.06.55

螢幕快照 2012-11-27 上午7.05.59

螢幕快照 2012-11-27 上午7.06.13

 

二條城是有護城河的。

螢幕快照 2012-11-27 上午7.07.15

 

螢幕快照 2012-11-27 上午7.07.41

 

變成黃色的草皮,看起來也別有一番風味啊。

螢幕快照 2012-11-27 上午7.07.55

螢幕快照 2012-11-27 上午7.08.02

螢幕快照 2012-11-27 上午7.08.15

 

往上爬可到城牆頂端。

螢幕快照 2012-11-27 上午7.08.40

 

從城牆往下望。

螢幕快照 2012-11-27 上午7.08.47

螢幕快照 2012-11-27 上午7.08.57

螢幕快照 2012-11-27 上午7.09.19

一個小池塘,池內的水非常清澈,感覺時空好像停止似的。

螢幕快照 2012-11-27 上午7.09.57

螢幕快照 2012-11-27 上午7.10.16

 

這應該是銀杏的落葉,鋪滿草皮。

螢幕快照 2012-11-27 上午7.10.33

 

二條城占地廣大,在裏頭散散步感覺還不錯。

***

友藏內心獨白:怎麼來到這裡又想到一休和尚和大將軍啊 挑眉質疑

2012年12月28日 星期五

導入Scrum三部曲

Dec. 18 22:27~23:33

image

最近收到一封email,寄信者自稱是《笑談軟體工程》的讀者,在此以C先生稱呼之。對方邀請Teddy到他們公司去「聊一聊」,抱持著認識朋友的心態,Teddy也沒多問什麼,就赴約了。

本來Teddy想說C先生大概是工程師之類的背景,頂多就是找三五好友跟Teddy閒扯淡。到了對方公司才發現原來C先生是資訊部門的協理,他帶著Teddy去找他們部門的副總,最後包含一位副總、兩位協理,一共有10位同仁來和Teddy「聊一聊」 。

***

副總:我們買了10幾本你的書給同仁看喔。

Teddy:非常感謝,不過寫書賺不到什麼錢,我要買兩本才可以喝一杯星巴克的飲料啊 XD(Teddy手上剛好拿著一杯星巴的抹茶拿鐵)。

C先生:Teddy你的書真的寫的很好,看了之後會重新燃起一股熱情,而且內容很好笑。

Teddy內心獨白:真的有那麼好笑嗎熱戀

***

聊了一陣子之後,Teddy發現原來C先生的公司剛開始自行嘗試導入Scrum,有一個小團隊已經試過幾個sprint了。他們現在有一個重要的計畫也準備採用Scrum,所以希望能從Teddy這邊 問到一些「情報」。在兩個小時的聊天過程中,對方問了很多問題,至於是什麼問題這不是重點。重點是,Teddy強烈建議他們,如果要在重要的計畫採行Scrum,而他們自己本身又沒有相關的經驗,那麼最好能夠:

  1. 上Scrum課程。在專案開始之前,讓團隊成員全部上Scrum課程。上課的目的除了讓成員了解Scrum框架之外,最重要的目的是要幫大家「洗腦」。依據Teddy的經驗,很多導入Scrum的團隊,就是因為「洗腦」不徹底,或是根本沒有「洗腦」,而將Scrum搞得跟傳統的專案進行方式沒什麼不同。結果不用說,當然是賠了夫人又折兵,失敗收場。
  2. 請顧問協助導入幾個sprint。上完課之後大概知道Scrum長的是圓的還是扁的,但是執行專案的時候,還是有很多狀況會發生。此時如果有顧問協助導入,可以少走很多不必要的冤枉路,不但幫公司節省人力成本,還可以讓產品早點讓上市。
  3. 上單元測試與持續整合課程。團隊成員熟悉Scrum框架之後,接下來就要著手提升團隊成員的技術能力與產品品質。Teddy認為每個Scrum團隊至少應該要採行自動化測試持續整合這兩個實務做法,而大部分的團隊並不知道如何落實自動化測試與持續整合。所以,這也算是一個「洗腦」的課程。要不要上,當然要啊熱戀

***

這三帖藥方服用之後,如果團隊之間有很棒的Scrum Master,應該就有能力可以朝向持續改善的目標前進。如果覺得團隊體質還不是很健全,則可以繼續請顧問協助提升團隊的能力。

最後Teddy跟對方強調一個重點:你們可以不找Teddy來上課或協助導入,但是以你們的情況,還是要找人來上課以及協助導入會比較「保險」。

***

友藏內心獨白:會後居然有一位與會者說他在10幾年前見過Teddy,這也太巧了吧不要告訴別人

2012年12月27日 星期四

Story與Task的估算單位為什麼不同?

Dec. 17 22:16~23:30

螢幕快照 2012-12-17 下午11.04.56

圖片來源:Google Map

經常有鄉民會問Teddy一個問題:為什麼在Scrum中,估算story(需求)要採用story point這種沒有單位的「相對大小」估算方法,而估算task(工作)卻是用小時為單位?

這個問題Teddy在《如何估算 story point?》與《Story point 為何沒有單位:相對論篇》裡面有討論過。這幾天想到一個更容易理解的例子,在此介紹給鄉民參考看看。

估算相對距離

用所謂的「相對大小」來估算需求,有一個前提是假設人類對於估算相對數據比估算絕對數據來的擅長。舉個例子,請參考上面這張地圖,請問台北到上海的直線距離有幾公分?台北到東京的直線距離有幾公分?台北到青海的直線距離有幾公分?相信鄉民們很難答得出來。

現在換一個方式來問:假設我們把台北到上海的直線距離訂為1,請為台北到東京的直線距離應該訂為多少?台北到青海的直線距離應該訂為多少。

鄉民內心獨白:我哪知道啊?

現在大家來「推理一下」,從地圖上看起來,台北到東京的直線距離大概是台北到上海的3倍再多一點點,至於台北到青海的直線距離大概是台北到上海的4倍左右。這就是story point相對大小的概念:

  • 台北到上海:Story point 1
  • 台北到東京:Story point 3
  • 台北到青海:Story point 4

用小時來估算到達目的地所需時間

既然story的大小是用story point這種相對值來估算,那為什麼task的時間估算要採用小時哩?答案很簡單,舉剛剛估算距離的例子。台北到上海、台北到東京、台北到青海的相對距離,不管是誰來估,基本上估出來的相對數值不會相差太大。但是,等到真正要從台北出發,來到這三個地點的時候(真正實作某個story的時候),所採用的交通方式認領工作者個能力與合作模式)將會影響實際到達的時間。舉個例子,雖然台北到青海的距離是台北到上海的4倍,但是假設鄉民A搭飛機從台北到青海,花了6個小時,但是鄉民B搭船從台北到上海,也是花了6個小時。另外鄉民C更神勇,游泳從台北到東京,花了2個月挑眉質疑。所以,一個story的大小,並不必然與完成這個story所需的時間成正比,而是與完成這個story的人(更精確地來講,應該是完成這個story的團隊)有關。

Velocity

看到這邊鄉民們可能會想:如果story point只代表相對大小,而完成每個story所需時間最後又是用小時來估算(把這個story的所有task的時間加總,就是完成這個story所需的時間),那…要怎麼知道專案多久才可以做完啊?關於這個問題請參考《Scrum 是什麼(18):到底為什麼要估算Story Point哩?》與《我在第二次Certified ScrumMaster課程學到的事(4)》。

***

友藏內心獨白:距離的例子好像比割草要來的好耶。