l

2014年11月28日 星期五

此時不寫更待何時

Nov. 27 00:15~01:07

螢幕截圖 2014-11-27 00.57.49

 

上禮拜收到出版社編輯寄來的信,告知Teddy的兩本書《笑談軟體工程:敏捷開發法的逆襲》與《笑談軟體工程:例外處理設計的逆襲》都要再刷。信中編輯小姐順便逼問Teddy,說好的《設計模式的逆襲》何時要動手寫?

2013年10月Teddy動手寫第二本書《笑談軟體工程:例外處理設計的逆襲》的當下,偷偷立下了一個心願,希望往後每年都可以出版一本新書。原本年底都是Teddy「農閒」的季節,但今年因為接到一個 大單 敏捷開發導入顧問案,花了很多時間在客戶端,忙到連寫部落格的時間都快擠不出來了,實在很難排入寫書的行程。

收到編輯小姐的信之後,又想起每年寫一本書的心願,於是最近利用晚上的時間稍微整理一下寫書的題材。有三個主題可以寫書,分別是:

  • Scrum FAQs:把Teddy這幾年開課、當顧問、教書以及看書所收集到有關導入Scrum常見的問題,整理成一本書。雖然素材都有了,但因為要列出所有Scrum常見問題,需要花費不少的整理功夫。在時間有限的當下似乎不太可行,於是想到把範圍縮小一點,誕生了第二個主題;
  • ScrumMaster的逆襲:把焦點放在ScrumMaster身上。根據Teddy的經驗,扣除高層主管是否支持的因素,很多Scrum導入失敗的原因是因為沒有找到或是培養一位適任的ScrumMaster。所以針對如何扮演好ScrumMaster的工作來討論,對於有心採用Scrum的鄉民們應該會有立即的幫助。
  • 設計模式的逆襲:最後一個主題就是談了好久的設計模式。書中除了介紹GoF的23個設計模式,Teddy主要還想介紹Alexander的模式理論以及如何應用這個理論來解決設計的問題。同樣遇到範圍太大時間太少的困擾。

幾經思考,還是決定先寫《設計模式的逆襲》,不過可能把這本書分成上、下兩冊,上冊介紹模式的起源、Alexander的模式理論、如何自己動手寫(整理)模式、模式與軟體架構設計、物件導向設計原理,最後介紹5~8個常見的GoF設計模式。下冊再繼續介紹其他沒講完的GoF設計模式,如果有時間順便談一下Java 8的functional programming對於GoF設計模式實作方式的影響。

不過也有可能上冊只談模式起與與Alexander的模式理論與應用,下冊再談GoF的23個模式。到時候要看情況再決定,總之希望明年(2015)可以出版上冊。

***

根據以前的經驗,就算知道要寫什麼,而且素材大致上都有了,寫完一本書還是需要至少300小時的時間。這兩天開始動手寫第一篇〈設計模式簡史〉,因為只有很片段的時間,所以這一篇只完成了30%。相較以往整天有空寫書的模式,一天平均可以完成2篇,利用片段時間的進度真的很慢。但是,最近Teddy慢慢體會一件事,「時間是擠出來的」。如果想完成一件事,一定有辦法找出時間。以往就是自己意志不堅,或是因為習慣的緣故,總是要等到「很空閒」的時候才願意逼自己寫書。其實就好像寫部落格一樣,每天就算只有一小時,累積一年應該也有辦法寫出一本書。每天就算8小時都有空,一年都不動手,還是什麼東西都沒有。

***

友藏內心獨白:就是決心和意志力的問題。

2014年11月27日 星期四

不明白你的不明白

Nov. 26 21:00~21:26

image

 

朋友:我可以問你一個Scrum的問題嗎?

Teddy:可以啊。

朋友:如何讓sprint planning meeting的估算更準確?

Teddy:估算更準確是什麼意思?

朋友:是這樣啦,我們現在sprint planning meeting的估算,基本上是交由團隊中對那項工作最有經驗的人的人來決定。但即使是這樣,估算出來的時間經常與實際花費的時間相差很多。

Teddy:估算不是應該由全體團隊成員一起完成的嗎?

朋友:這我知道,我們也試過。但除了讓整個估算過程曠日廢時之外,最後估算出來的時間也沒有比較準確啊。後來為了節省時間,我們就請團隊中最有經驗的人做代表,直接寫出預估值。

Teddy:你知道在Scrum裡面估算的目的是什麼嗎?

朋友:我知道啊,就是要做計劃之前要先預估啊。

Teddy:嗯,你這樣說也沒錯,先有預估值然後才能inspect和adapt。不過我認為估算只是一種手段,最主要目的是讓團隊成員透過估算進行溝通,以便更清楚理解需求以及工作的範圍。

朋友:這我知道啊,溝通嘛,我們有在溝通啊。資深人員估算完畢之後,會告訴其他人估算的理由,大家也會一起討論。

Teddy:所以你不認為你們現在這種「溝通」模式有任何問題?

朋友:沒有問題啊,這樣子溝通的速度很快、很有效率,花費時間很短。

朋友:對了,你不要管我怎麼溝通,我是要問你怎樣估算才可以更準確。

Teddy:啊,我剛剛出門燒開水忘了關。我回家關瓦斯先挑眉質疑

***

如果「你不知道你不知道」,就無從改善起。當別人讓你知道,你卻「不肯明白你的不明白」,那也只能說機緣未到,十六年後又是絕情谷再相見了。

***

友藏內心獨白:又是一個還沒「守」就要「離」的狀況。

2014年11月26日 星期三

推遲承諾

Nov. 25 16:11~16:57

image

 

上禮拜在北科上課的時候,Teddy跟同學提到精實開發的七個原則,其中有一條是defer commitment(推遲承諾),又稱為decide as late as possible。這個原則在不同的敏捷方法,例如XP、Scrum、Kanban,都看的到。

***

Kanban
Kanban方法可以把整個價值流分成三段,開發團隊可以控制的部分用Kanban方法來管理工作流,開發團隊不能控制的部分,可分為上游(upstream)與下游(downstream)。假設上游是stakeholder的需求,從Kanban的角度來看,當需求的價值尚未明確之前,不需要急著把工作「拉入」到Kanban系統當中。但是一但工作拉入之後,就要儘快完成。這就是一種推遲承諾的例子。

螢幕截圖 2014-11-25 16.25.48

 

Kanban方法沒有iteration,因此若是採取JIT(Just in Time)的方式,當需求要被實作的時候再來分析採解它,這也是一種推遲承諾的表現。

***

Scrum
Scrum的推遲承諾最明顯表現在product backlog上面,只要足夠1~2個sprint工作所需的product backlog item(PBI)都經過討論、估算、撰寫驗收條件就可以了,其他的PBI可以等到即將被挑選出來實作之前再來討論。

螢幕截圖 2014-11-25 16.37.04

***

XP

接下來要舉的例子其實在敏捷方法中都適用,只是XP更強調,就是TDD。先寫一個會失敗的測試案例,然後撰寫足夠讓這個測試案例通過的production code,然後再透過refactoring改善設計。不需要事先花很多設計功夫,透過一連串有紀律的小步驟就可以讓軟體品質維持在一個可接受的範圍內。這種做法,當然也是推遲承諾的表現。

***

敏捷開發不是要「騙選票」,不需要七早八早承諾一堆作不到的「支票」。與其亂改路名、亂發津貼,還不如等真正需要的時候再承諾。

***

友藏內心獨白:選票先騙到再說,不是有人說政見又不一定要兌現嗎挑眉質疑

2014年11月25日 星期二

第一次當ScrumMaster

Nov. 25 09:23~10:21

image

 

有朋友問Teddy:「你第一次當ScrumMaster的時候是怎麼做好這個角色?」回想當時Teddy對於Scrum的了解,主要來自於讀了Henrik Kniberg所寫的《Scrum and XP from the Trenches》這本書。在這之前Teddy很早就接觸了XP,也累積了十幾年的軟體開發經驗。讀了Kniberg的書之後覺得Scrum很有道理,看起來也簡單,在因緣際會之下就帶了第一個Scrum團隊。

哪知開始採用Scrum之後很多Kniberg書上沒提到的問題才一一浮現。到底是因為自己對於Scrum了解不多所以無法解決這些問題,還是這些問題Scrum根本沒有規範要靠常識來判斷,當時Teddy並不清楚。身邊又沒有人可以問,怎麼辦?很簡單,閱讀實踐

當時Teddy的辦公桌上隨時擺了十幾本敏捷開發與Scrum的書,剛開始擔任ScrumMaster除了同時協助團隊開發軟體架構雛型之外,只要有時間就讀這些書。過了至少一年,才敢說對於Scrum框架慢慢比較有把握。

***

開始實踐Scrum至今也有六年多的時間,接觸敏捷開發的時間更久,超過15年,是不是該學的都學會了?學習也是一種持續改善的過程,只有更好,沒有最好。有時候學到一個程度會志得意滿,以為自己很強、很行、很牛、很神,這時候更應該眼界放遠一點,看更多的書,接觸更多的人,才會發現其實自己還有很大的成長空間。

網路上許多鄉民很喜歡用「守、破、離」這三個層次來說明學習一件新知或是技能的三種階段。Teddy很認同學習會經歷這三種不同的階段,但很可惜很多人還沒「守」,就已經要「破」、要「離」了。過往的經驗有時是助力,但如果現況的context與過往經驗差異太大,經驗反倒可能成為阻力。

從全世界的角度來看,真正堪稱大師、大神的人並不多。就算經過一萬小時的練習也頂多勉強算是「專家」而已。「子曰:朝聞道,夕死可矣。」如果「聞道」那麼簡單,就不該輕言生死。

***

友藏內心獨白:先去少林寺掃地三年再說。

2014年11月24日 星期一

產品負責人與團隊的互動(下)

Nov. 20 20:15~23:15

image

 

在〈產品負責人與團隊的互動(上)〉提到PO(Product Owner)和團隊的互動,除了在sprint進行中可以隨時釐清需求以外,當團隊完成一個story的時候,也可以立即找PO來驗收這個story,不必等review meeting的時候才看。這樣的好處是,如果PO看完story覺得有需要修改的地方,團隊還有時間可以調整。另外,依據Scrum的定義,story必須要「做完(Done)」才可以在sprint review中展示。誰來決定做完?當然是PO。

看到這邊鄉民們可能會想,如果PO在sprint進行中已經把story都驗收完畢,還需要開sprint review會議嗎?Sprint review除了PO以外,最主要還是希望stakeholder,包含公司內部的主管、行銷、業務部門,以及公司外部的潛在客戶與使用者,可以一起參與並獲得他們的回饋。收集到這些回饋意見之後,調整後續產品方向。所以sprint review除了展示完成的功能以外,最主要還是要收集回饋意見並調整產品方向,並不是拿來做為是否驗收的場合。

***

另外一項讓PO與團隊持續互動的活動就是Product Backlog Refinement Workshop,又稱為Product Backlog Grooming。藉由持續梳理product backlog的內容,PO和團隊一起確保下一個sprint所要實作的story符合definition of ready的條件(請參考〈Definition of Ready—可以開工了嗎?〉)。

這個活動的時間占sprint的5%~10%,有三種常見的舉辦方式。第一種是在sprint進行到一半的時候舉辦,第二種是經常性的舉辦,例如有需要的時候就在Daily Scrum之後花個30分鐘左右討論一下。最後一種是在Sprint Review(或是Retrospective)之後舉辦。

***

再次強調一次,Scrum Team包含PO、Team、ScrumMaster。PO是「內人」,不是「外人」,理當緊密合作啊。

***

友藏內心獨白:如果是內人就很好「喬」了。

2014年11月23日 星期日

2014北海道考察之旅Day2-C黑岳山登頂

Nov. 13 22:02~22:34

準備開始爬黑岳,在登山口有一個登記點,自己填上登山時間、國籍與連絡電話。這個登山步道非常特別,布滿大大小小的石頭,反而比較像河道而不是步道,有一種溯溪而上的感覺。

螢幕截圖 2014-11-13 22.03.09螢幕截圖 2014-11-13 22.03.19螢幕截圖 2014-11-13 22.03.26螢幕截圖 2014-11-13 22.03.33螢幕截圖 2014-11-13 22.03.40螢幕截圖 2014-11-13 22.04.15螢幕截圖 2014-11-13 22.04.28螢幕截圖 2014-11-13 22.04.50螢幕截圖 2014-11-13 22.05.06

 

離黑岳峰頂還有1.5公里,這個距離如果是平地30分鐘就可以走完,但是今天這個情況不知道要爬多久啊。

螢幕截圖 2014-11-13 22.05.30

 

雖然不時下著綿綿細雨又有濃霧,不過沿途的風景很漂亮,空氣又好,如果不趕時間慢慢爬還蠻舒服的。爬了約800公尺之後,耶,怎麼下雨變成下雪了啊。

螢幕截圖 2014-11-13 22.06.00螢幕截圖 2014-11-13 22.11.07螢幕截圖 2014-11-13 22.11.33螢幕截圖 2014-11-13 22.11.43螢幕截圖 2014-11-13 22.11.54螢幕截圖 2014-11-13 22.12.12

 

有種漫步在雲端的感覺。

螢幕截圖 2014-11-13 22.15.06螢幕截圖 2014-11-13 22.17.36螢幕截圖 2014-11-13 22.18.09螢幕截圖 2014-11-13 22.18.19螢幕截圖 2014-11-13 22.18.30螢幕截圖 2014-11-13 22.18.40螢幕截圖 2014-11-13 22.18.47螢幕截圖 2014-11-13 22.18.56螢幕截圖 2014-11-13 22.19.12螢幕截圖 2014-11-13 22.19.18螢幕截圖 2014-11-13 22.19.35螢幕截圖 2014-11-13 22.20.07

 

雪越下越大,賞楓變成賞雪,也是不錯啦。

螢幕截圖 2014-11-13 22.23.43螢幕截圖 2014-11-13 22.24.23螢幕截圖 2014-11-13 22.24.44螢幕截圖 2014-11-13 22.25.20螢幕截圖 2014-11-13 22.25.53螢幕截圖 2014-11-13 22.26.21

 

終於在下午1:10登上標高1984公尺的黑岳山頂,不過山頂風超強的,而且光禿禿一片。快速拍幾張照片之後就準備下山了。

螢幕截圖 2014-11-13 22.26.46螢幕截圖 2014-11-13 22.26.55螢幕截圖 2014-11-13 22.28.25螢幕截圖 2014-11-13 22.28.36螢幕截圖 2014-11-13 22.28.54螢幕截圖 2014-11-13 22.29.09螢幕截圖 2014-11-13 22.29.20螢幕截圖 2014-11-13 22.29.29螢幕截圖 2014-11-13 22.29.43

***

友藏內心獨白:登山的目的就是為了下山不要告訴別人