l

2014年10月31日 星期五

你適合當ScrumMaster嗎?

Oct. 30 21:40~22:05

image

 

最近Teddy因為工作的關係比較常到南港軟體園區。從南港展覽館走到南港軟體園區,需要過一個馬路。Teddy猜想每天等著過這個馬路的行人,應該有幾千人次吧。假設保守估計有3000人次,每次平均等待紅綠燈的時間是30秒,一天就浪費了3000*30=90000秒=1500分鐘=25小時。一年算280個工作天,就浪費了7000小時。

每次在這裡等著過馬路的時候,Teddy就在想:「為什麼捷運站不在南軟設一個出口,這樣不是可以減少很多等待的時間浪費嗎?」

***

「誰適合當ScrumMaster?」這個問題Teddy被問過沒有上百次也有幾十次。這個問題真的不好回答,因為公司文化、團隊組成、專案特性、個人特質、個性、意願、專業能力、經歷、人脈關係等,都會影響挑選ScrumMaster的因素。有時候對的人,放到不對的場合,也是白搭。

先不管其他條件,如果鄉民們經過上面這張照片所在的路口,也跟Teddy有類似的疑問,這種人就初步具備當ScrumMaster的條件,尋找持續改善的機會挑眉質疑

***

友藏內心獨白:最好是那麼簡單。

2014年10月30日 星期四

團隊決定做多久

Oct. 29 20:33~21:08

image

 

昨天提到〈PO決定優先權〉,今天談一下團隊決定需要多久的時間來完成story。在某次【Scrum敏捷方法實作班】中,有一位學員問Teddy…

學員:PO(Product Owner)是不是可以不用參加sprint planning meeting part 2?

Teddy:對啊。

學員:可是如果採用你的建議,用task累積的時間來估算團隊在這個sprint可以挑選多少story,那麼PO就被迫參加sprint planning part 2啊。

Teddy:啊?為什麼呢?如果PO有事不參加sprint planning part 2,他在part 1解釋完需求的內容之後就可以離開了。只要團隊在切割task的時候有問題可以找到PO就可以了。

學員:可是這個sprint可以做多少story要等到sprint planning part 2才知道啊。

Teddy:如果採用「團隊可用總時數減去task累積預估工時」的方法來估算,的確是要等到sprint planning part 2之後才知道這個sprint可完成story的數量。

學員:這就是問題啊,我們的PO想知道這個sprint完成多少story。

Teddy:那就在sprint planning part 2之後通知他不就好了。

學員:可是PO會有意見啊。

Teddy:有意見?你的意思是說PO對於團隊每個sprint完成story的數量有意見?

學員:對啊,如果PO覺得團隊預估可完成的story數量太少,他會「強烈建議」團隊在多選幾個story。

Teddy:這樣啊…那我猜測你們團隊一定很討厭Scrum。

學員:你怎麼知道?!

***

在Scrum框架下,PO決定需求的優先順序,團隊決定工作所需的時間。在〈PO決定優先權〉提到團隊不應該自行幫PO決定優先順序,同樣地PO也不能幫團隊決定施工所需的時間,否則就跟現行一般專案管理方式類似,由專案經理指定每項工作所需完成的時間,團隊成員只能聽命行事。如此一來,只是披上Scrum的皮,行傳統專案管理之實。相信應該沒有團隊會喜歡這種形式的「Scrum」吧!

***

友藏內心獨白:權責相符是很重要的。

2014年10月29日 星期三

PO決定優先權

Oct. 28 07:24~08:15

螢幕截圖 2014-10-28 08.12.06

 

有一個朋友問Teddy關於Scrum的問題…

朋友:在sprint進行中,如果遇到bug該怎麼辦?

Teddy:如果這個bug是因為這個sprint的開發活動所導致的結果,當然就直接解掉。如果是之前sprint所遺留下來的,而且不修正會妨礙到團隊完成這個sprint所安排的story,則還是要修掉。又或者是這個bug很小,也可以隨手修掉。但如果這是之前sprint所遺留的bug,而且需要花費一段時間才能處理好,我會建議把這個bug放入product backlog裡面,讓PO(Product Owner)來安排修bug的時間。

朋友:可是團隊(開發人員)不是要負責產品的品質嗎?遇到bug不修卻丟回product backlog裡面讓PO來決定何時修bug,這不是把品質的責任交給PO來負責?

Teddy:團隊的確是要負責產品的品質,但是如果在sprint進行中發現之前開發活動所遺留下來的的bug,這種修bug的要求(request)稱為失效要求(failure demand)。失效要求也會耗費團隊的開發時間,如果團隊成員自行決定要處理失效要求,則原本PO所排定的story優先順序就被打亂了。很可能PO認為修正這個bug的優先權很低,可以暫時不理它,但團隊卻急著修它而忽略原本排定的story。換句話說,團隊幫PO決定了優先順序。

***

友藏內心獨白:不要越俎代庖。

2014年10月28日 星期二

如何辨識GoF Design Patterns的使用?

Oct. 27 07:59~09:00

螢幕截圖 2014-10-27 20.59.09

 

上禮拜上完【設計模式這樣學就會了:入門實作班】,每次上課的時候,Teddy都會了解一下學員想在這門課中學到什麼,一個經常聽到的期待就是:「如何辨別一個設計是否採用GoF的某個design patterns?」

這個問題可能有很多種方法,比較抽象一點的說法是「從pattern要解決的問題來判斷」,另外一種說法則是從辨識pattern的特徵開始。例如:

  • 如果你懷疑某個設計是不是Template Method,你就要問自己,template method定義在哪一個super class裡面?又有哪些primitive operation提供給subclass重新定義?
  • 如果是Facade,你要能夠回答Facade所隱藏的子系統是哪一個?Facade提供的介面在哪裡?
  • 如果是State,那些是和狀態有關的行為,這些行為被配置到那些concrete state物件上面?
  • 如果是Observer,擁有狀態的Subject是誰?
  • 如果是Adapter,則誰是Adaptee?Target介面又是什麼?
  • 如果是Abstract Factory,則由它所產生的一組產品物件在哪裡?這些產品物件有不同平台的不同實作嗎?
  • 如果是Strategy,你能夠找出一組可以彼此互相替代的演算法物件嗎?

***

在不同的班次中,經常會有學員問Teddy:「某某設計算不算是Facade?」Teddy通常會反問:「如果這個設計是一個Facade,請問它擋在哪個子系統的大門前?」如果找不到任何被這個設計所隱藏的子系統,應該就不能算是一個Facade。如果可以找到,則進一步問:「Facade定義了那些介面?」鄉民們可以自行練習看看,對於判斷某個設計是否套用某個pattern應該會有幫助。

***

友藏內心獨白:問對問題很重要。

2014年10月27日 星期一

頻率不對怎麼談?

Oct. 01 09:43~10:50

image

 

Teddy寫了〈不是我不教,是你不肯學〉之後,有鄉民向Teddy抱怨…

鄉民:我看是因為你聽到別人沒有意願參加你的課程,你就不想回答對方問題吧。

對於求知與學習Teddy有三點看法:

  1. 有人想學習的知識Teddy剛好知道,Teddy很樂意分享自身的學習經驗,告訴對方有哪些資料可參考。無論是在「搞笑談軟工部落格」或Teddy所撰寫的書籍中,都儘量在自己記憶所及的範圍內提供參考資料來源,讓有心想學的人可以追朔源頭。這一點不用Teddy自己解釋,「搞笑談軟工部落格」上面有一千多篇文章,Teddy也寫了兩本書,證據很多。
  2. 對於想學習卻沒時間自己看書,或是想要在短時間快速吸收新知的人,如果這個主題Teddy剛好也有開課,當然會建議對方來上課。做生意的人,對自己的產品很有信心,客戶也有需要,理當大力介紹,何錯之有?介紹之後你不想來上課也沒關係,只要雙方頻率對的上,還是有很多話題可聊。參加C. C. Agile活動的常客中,有好幾位從來都沒有上過Teddy的課,因為頻率相通,大家一樣有聊不完的話題。
  3. 對於不想花時間學習也不願意深入思考,只希望三言兩語就可以問出複雜問題的答案的人,因為Teddy個人能力不足與資源有限(要限制WIP),無能也沒辦法花太多時間在這種人身上。精實開發說要「消除浪費」,這一類的人無法在短時間內瞭解你的想法,也不想自修看書,花費時間在他身上只是產生更多的「半成品庫存」,此為軟體開發人員之大忌。所以只好等某一天雙方頻率一致之後,再續前緣。

***

別人的頻率和你不一樣是誰的錯?沒什麼對錯,就是「頻率不同」這個事實。別人不一定比較厲害,你也不一定比較差,但「頻率不同」就是搭不上話,硬要在這種情況下問出個所以然來,如果別人選擇不繼續回應就戴上個「不想上你的課或沒有買你的書所以你就不願意回答」這頂帽子,那未免太小看別人了。

平常Teddy上課是不准學員使用筆電與手機等3C產品,就是希望學員能夠專心,活在當下。有一次Teddy在上課的時候,有一位學員三不五時用手機跟朋友傳訊息。Teddy提醒了他,但這位學員還是不改,後來Teddy告訴他:「你如果再玩手機,我就要請你離開,課程費用我全額退費給你。」不是所有的事情都可以用錢解決,你來上課繳了錢沒錯,但別人也繳了錢,你的行為影響了別人或講師,這就不對。這種錢,Teddy不賺也罷。

還有一次有一位上過Scrum課程的學員在C. C. Agile問了Teddy一個例外處理的問題,這個問題有一個簡單但不完整的答案,也有一個完整但需要花一段時間解釋的答案。Teddy不想只是為了打發對方而提供簡單但不完整的答案,也沒辦法在C. C. Agile場合把完整的答案講完,只好請對方去看Teddy寫的書,因為整個思考過程Teddy在書中交代得非常清楚。如果事後提問者要解讀成「因為沒有來上例外處理課程所以Teddy就不想回答」那也沒辦法。你不可能討好所有的人,正所謂「物以類聚」,和你頻率相同的人自然會留下來甚至日後成為好朋友。頻率不同的人自然會去尋找符合他自己頻率的地方,此為正常現象,請安心服用。

上個月有一位報名上課的學員在開課前2~3天來信告知臨時有事無法參加。這位學員也很乾脆地告訴Teddy說他不要求退費,只要把發票寄給他就可以了。看到信之後Teddy非常感動,但就算對方不要求退費,Teddy還是把課程費用一毛不扣的全部退還。開課賺錢只是讓泰迪軟體可以持續經營下去的一種手段,除此之外也希望學員們可以透過Teddy為媒介,感受與了解軟體開發活動的各種樂趣。如果只是為了賺錢,還有其他比經營泰迪軟體更輕鬆且安穩的賺錢的方法。

***

這種事,講多了好像在幫自己宣傳。不說,遇到頻率不對的人,心裡又覺得很悶。怪就怪Teddy修養不夠,還沒到達「本來無一物,何處惹塵埃」的五蘊皆空境界。讓鄉民見笑了,繼續修練去。

***

友藏內心獨白:調整頻率之前可能要先檢查天線有沒有壞掉。

2014年10月26日 星期日

2014京都考察之旅Day10-B上賀茂神社

Oct. 24 22:37~23:05

沿著鴨川繼續騎,來到了上賀茂神社,一映入眼簾的是一株盛開的齊王櫻,很多遊客以它為背景拍照。

螢幕截圖 2014-10-24 22.39.25螢幕截圖 2014-10-24 22.39.55螢幕截圖 2014-10-24 22.40.04螢幕截圖 2014-10-24 22.40.19螢幕截圖 2014-10-24 22.40.29螢幕截圖 2014-10-24 22.40.38螢幕截圖 2014-10-24 22.39.41

 

繼續往前走,當天剛好有人在此舉行婚禮。

螢幕截圖 2014-10-24 22.42.47螢幕截圖 2014-10-24 22.43.11螢幕截圖 2014-10-24 22.43.18螢幕截圖 2014-10-24 22.43.25螢幕截圖 2014-10-24 22.45.48螢幕截圖 2014-10-24 22.46.08螢幕截圖 2014-10-24 22.43.42

 

繼續賞花、賞屋、賞流水。

螢幕截圖 2014-10-24 22.46.02螢幕截圖 2014-10-24 22.46.30螢幕截圖 2014-10-24 22.46.46螢幕截圖 2014-10-24 22.47.23螢幕截圖 2014-10-24 22.47.37螢幕截圖 2014-10-24 22.48.00螢幕截圖 2014-10-24 22.48.13螢幕截圖 2014-10-24 22.48.25螢幕截圖 2014-10-24 22.48.39螢幕截圖 2014-10-24 22.48.53螢幕截圖 2014-10-24 22.50.50螢幕截圖 2014-10-24 22.51.02螢幕截圖 2014-10-24 22.51.28螢幕截圖 2014-10-24 22.51.48螢幕截圖 2014-10-24 22.59.56

 

離開前買了一份如下圖右方的糯米零食,買的人還不少,不過吃起來覺得還好,沒有特別好吃。

螢幕截圖 2014-10-24 23.02.47螢幕截圖 2014-10-24 23.01.17螢幕截圖 2014-10-24 23.00.56

***

友藏內心獨白:看不完的櫻花。

2014年10月25日 星期六

2014京都考察之旅Day10-A松崎疏水 & 半木之道

Sep. 18 21:45~22:35

今天要騎自行車到上賀茂與下鴨神社逛逛,早上先搭公車到高野川和賀茂川合流附近租借自行車。一台車租一天只要500日圓,應該算很便宜。但是,自行車是中國製造的便宜車種,車子不太好騎,還是台北的UBike完勝。

螢幕截圖 2014-09-18 21.47.48螢幕截圖 2014-09-18 21.47.59螢幕截圖 2014-09-18 21.48.43螢幕截圖 2014-09-18 21.49.17螢幕截圖 2014-09-18 21.50.37螢幕截圖 2014-09-18 21.50.48

 

借到車之後先騎到河邊,順著河岸逆流而上。先騎到一個叫做松崎疏水的地方,沿路很多地方都有櫻花,非常漂亮。

螢幕截圖 2014-09-18 21.57.38螢幕截圖 2014-09-18 21.58.27螢幕截圖 2014-09-18 21.58.36螢幕截圖 2014-09-18 21.58.57螢幕截圖 2014-09-18 22.05.31螢幕截圖 2014-09-18 22.05.44螢幕截圖 2014-09-18 21.58.48

 

繼續往前騎,來到京都植物園附近的鴨川,看到一顆石頭寫著半木之道。今天這裡有市集,有許多賣吃的攤販,人潮眾多。這裡種了很多櫻花,正是盛開之時,難怪會選在這裡擺攤。

螢幕截圖 2014-09-18 22.07.35螢幕截圖 2014-09-18 22.07.50螢幕截圖 2014-09-18 22.08.01螢幕截圖 2014-09-18 22.08.15螢幕截圖 2014-09-18 22.08.36螢幕截圖 2014-09-18 22.08.50螢幕截圖 2014-09-18 22.08.24螢幕截圖 2014-09-18 22.08.58螢幕截圖 2014-09-18 22.09.20螢幕截圖 2014-09-18 22.09.07螢幕截圖 2014-09-18 22.09.34螢幕截圖 2014-09-18 22.10.01螢幕截圖 2014-09-18 22.10.15螢幕截圖 2014-09-18 22.10.37螢幕截圖 2014-09-18 22.10.53螢幕截圖 2014-09-18 22.11.02螢幕截圖 2014-09-18 22.11.22螢幕截圖 2014-09-18 22.12.02螢幕截圖 2014-09-18 22.12.12螢幕截圖 2014-09-18 22.12.52螢幕截圖 2014-09-18 22.43.11螢幕截圖 2014-09-18 22.12.35

 

買了點吃的,因為半木之道人太多了,繼續往前騎了一小段,找了個有椅子且人少一點又可以賞櫻的地方休息一下順便吃東西。附近剛好有一群年輕男女正在聯誼的樣子,還有媽媽帶小朋友出來野餐。

螢幕截圖 2014-09-18 22.13.06螢幕截圖 2014-09-18 22.13.14螢幕截圖 2014-09-18 22.49.39螢幕截圖 2014-09-18 22.13.22螢幕截圖 2014-09-18 22.49.29螢幕截圖 2014-09-18 22.49.50螢幕截圖 2014-09-18 22.49.20

***

友藏內心獨白:沒想到鴨川沿岸櫻花如此之多。