2015-09-05

快速相對估算的熱身賽 – 進階的動物洗澡Workshop

快速相對估算的熱身賽 進階的動物洗澡Workshop



這星期讓Team Member們體驗了一下快速相對估算,之前就已經用動物洗澡來做過範例了,這次換個方式,讓他們體驗一下更真實的案例。

這次我把整個團隊納入一起估算的行列,所以總共加起來有11個人,算是個稍大的團隊,我其實也想試試這麼多人的情況之下,估算會不會無聊。

今天我擔任PO,跟Team說我們在Sprint1的任務就是要幫以下三隻動物洗澡:
1. 大金剛
          

        這隻大金剛有超乎常人的智慧,能夠領軍所有猴群、猩猩軍團等。他是動物園的大明星,平常有個工作是要跟民眾互動,所以需求是:
    (1) 不能有體臭
    (2) 不能有跳蚤
2. 北極熊

        不愛乾淨、但溫和的北極熊平常也是要跟民眾搭肩拍照,所以需求是:
    (1) 毛色要潔白無瑕
    (2) 熊爪不能抓傷人
3. 河馬
    

    河馬的特色就是下顎非常有力,所以他的工作是讓民眾參觀他的大牙齒
    所以需求是:
    (1) 牙齒要保持乾淨

OK 需求出來了,接下來要讓大家討論Sprint1 要完成這些需求的話,需要做什麼?所以我們透過Scrum Planning Part I的討論,產生了故事卡。
例如:
    (1) 讓動物們吃會睡覺的,讓牠們睡著。
    (2) 透過擠肛門的方式讓金剛不要有體臭 (感謝群眾智慧啊)
    (3) 對北極熊塗上白色油漆
    等等


故事出來了,接下來我們就要對這些故事做快速相對估算囉

Step 1 : 比較大小
我將剛剛的故事放置在桌上,Team Member們要先排隊成一個上台的順序,第一個Team Member隨手抽一張故事,將他貼在白板上,然後去排到隊伍的最後,第二個Member隨手抽一張故事,比較這張故事與白板故事的複雜程度。簡單的擺左邊;困難的擺右邊。然後繼續去排到隊伍的最後。第三個Member先評估白板上的順序是否認同,如果認同就抽下一張故事,如果不認同就改變順序。總之一次一個人僅能做一個動作。如此輪流下去直到大家都達成共識:目前的排序就是大家認可的排序。


Step 2 : 校正基準
如果是新專案,那就將最左邊的故事定義為1點吧。如果過去已經做過不少東西,那就可以拿過來當作一個基準。

Step 3 : 評估程度
我們利用費氏數列的點數卡來做複雜的評估,費氏數列的好處是方便快速分類。1,2,3,5,8,13,20,40,100等等。當複雜度為40時,你不會在意他是39還是41
就算點數小,你保守一點選擇下一級損失也不大。
接著就如同Step1,大家輪流上來給點數。


經過這個動物洗澡的熱身,相信Team Member們對快速估算應該開始有感覺了,對於真實的Project估算來說,就會比較熟悉了。
不過我自己的感想是10幾個人來估真的有點枯燥喔,會有人被晾在一旁,嗯~要再想一下Solution





2015-08-04

[講師] 教導公司暑期實習生 Unit-Testing & TDD Introduction (1)

很榮幸在7月底幫公司的暑期實習生上了一堂課
Unit testing & TDD Introduction

由於Target Audience都是學生
姑且猜測他們寫code經驗比較不足
所以這次就安排了Unit-Testing的基礎課程以及讓他們實作練習的Coding Dojo

今天安排了整整4小時的課程
所以我把課程切分成三部分 : 
1. 聽課
2. 實作
3. 小組報告

課程一開始 我先放個Why TDD的影片
這招是跟Daniel學的
在開頭放影片 讓準時進來的學生不無聊
讓遲到的學生就算沒看到也沒損失XD

接著我讓他們從以下四個問題挑一個來回答


然後就來玩群眾智慧的遊戲了
我請他們隨機配對
兩兩分享一下彼此的答案
然後請兩人協調出這2張答案的分數
兩張答案要共享7
簡言之就是兩者相加要等於7
最後交換手上的故事
繼續下一個配對


今天總共讓學員們隨機配對3
此時大家手上的故事應該就有3次分數的總和了




這活動的目的是為了讓他們自己決定誰的故事值得分享
分數最高的四位 也順便成為了各組小組長

沒想到大家都還蠻客氣的
3 run的總和下來 最高分才12
不過不可否認的
透過群眾智慧選出的這幾位小組長
表現上確實很有潛力喔~

分好小組之後
便開始介紹今天的主題
也透過一些簡單的實作練習讓各組建立下一堂課的實作環境

安裝nunit (unit test framework)
寫出第一個unit test project
執行第一個unit test

第二堂課是要玩codind dojo
Dojo是道場的意思
是一個能夠練習武功的地方
所以coding dojo就是個能夠讓大家安心練習寫程式的地方


今天coding dojo進行的方式是 Randori
各組同一時間只有一台電腦能寫code
各組組員輪流上台寫程式
圖片來源 : httppt.slideshare.netviniciusa1r3sapresentao-coding-dojo-em-10-minutos

各小組會有以下角色:
分別區分成 駕駛區及觀眾席




駕駛區裡坐著:
Driver : 實際下手Coding
Navigator: 可與Driver討論或提供方向
觀眾席裡就是坐著觀眾
Audience: 台下觀眾,不能介入coding

5分鐘一到,角色是會輪替的
如此一直輪替直到活動結束

今天實作的題目是:
網球計分系統

這題目看似簡單,其中卻藏了一些邏輯危機喔
真的蠻適合當作Coding Dojo Kata (練習的套路)

各小組在進行Coding Dojo
我就在各組間走動觀察

 一開始大家都還沒有進入狀況
所以20分鐘後 我中斷了Coding Dojo
請他們反省跟討論接下來的策略
接著 Coding Dojo繼續進行
很明顯地有一組已經知道怎麼玩了
開始按部就班地建立Test Case


其他組則還是在為了通過第一個測試而努力



他們的問題在於忘了Baby Step




於是我要求他們盡可能先通過第一個測試
不要想太多
不要帶太多情境
先求通過第一個測試之後再Refactor



其實TDD雖說先寫測試
但也不是先寫測試這麼地膚淺
他的一個價值在於Focus on 需求
小步小步地完成需求
所以先寫出第一個陽春版的測試並不丟臉
但同學們就是想太多了
想要一次全包
這不就又回到前面介紹的Integration Test了嗎?



最後請各小組上台Demo以及分享他們的經驗
我相信他們一定也有感受到衝擊
希望能在他們心中埋下一顆TDD的種子



下一集我們再來介紹如何寫出第一個TDD !!!

2015-07-28

Visual Studio 2015 的 Refactor 轉移到 Quick Action中囉

因為要教課的關係
今天裝了Visual Studio Community 2015來玩玩

赫然發現之前2013的Refactor的功能不見了



結果是Visual Studio Community 2015把 Refactor 的功能移到 Quick Action

怎麼使用Quick Action執行Refactor呢?
例如我們想要Refactor 以下這段邏輯
跟以前一樣 先反白要抽出來的邏輯
按下右鍵 -> Quick Actions


有沒有看到熟悉的Extract Method阿~


邏輯已經被抽出來成一個新的Method了


來把它 Rename 一下吧

2015-07-17

CSM Test 成為一個認證的Scrum Master

前一陣子上完了Daniel的課
拖到了最近去考了CSM (Certified ScrumMaster®)
很高興終於成為了一個合格的Scrum Master

記錄一下答錯的題目

當PO沒空參與Sprint的結果是?
[Ans]做出來的Product將不會符合預期

我原本以為沒有PO 就沒有人可以確認需求
這樣做出來的東西就是Developer寫爽的 所以才認為該中止這個Sprint
不過不符合預期果然更貼切

PO跟Scrum Master可以為同一人嗎?
[Ans]不可以 他們角色衝突

兩者的角色跟功能性雖然不同 但是有衝突嗎? 有點懷疑

Olivia宣稱她想到一個solution可以解決現在的問題
而且她很想要馬上執行
在Scrum這種需求鎖定的Sprint 該怎麼處理呢?
[Ans] 開一個另外的會議討論 (不要占用Daily Scrum的時間)

其實答案很合理 正常我們也都會這麼做
(我怎麼答錯了呢~ 自以為這是陷阱題阿XD)
PO的職責
[Ans] 決定合適的Release Date

我一直以為要做多久是Team決定的耶~
這題算是英文不好 我誤以為(A)是在說成功的Product必要組成

在Daily Scrum中PO這個角色:
[Ans] PO參加Daily Scrum是Team規定的

好怪? 有點不太理解這個答案
在Daily Scrum中哪個角色表達有碰到障礙
[Ans] Team

這題英文不好 我誤以為是誰要溝通排除障礙

每個Sprint結束要產出什麼?
[Ans] Potentially shippable product increment

這題是我記錯定義了 我一直以為Potentially這個是指有可能要做的所有功能
真是不用功

2015-06-29

社群分享 在瀑布底下玩Scrum


今天很高興被AgileCommunity.tw邀請來跟各位分享一下我們Team的Practice

身在一個大型軟體公司稍微傳統的部門下也是能夠玩SCRUM的
這場sharing將會和大家分享我們在瀑布底下碰到問題之後
如何採用一些SCRUM的Practice以及Tool的協助來幫助我們解決問題

內容包括:
Team Member的緊密配合
如何以JIRA視覺化我們的工作狀態
如何改善Standup Meeting的效率
如何在每次的Sprint結束後都能更進步 - Retrospective Meeting

我的場次被安排在第二場

所以先來聽聽第一場的David怎麼介紹SCRUM

我擷取幾張有趣的部分


敏捷大師們
沒有他們就沒有今天的敏捷
要感謝它們的努力阿~


最強的人不見得是能生存下來的人
但能生存下來的人 一定是最能適應改變的~
我們要有能夠因應改變的能力
所以不要再一直說需求,環境一直變了 因為這些一直在變
我們該改變自己 讓自己能夠適應變化



瀑布式的缺點就是需求到最後才會發現不是User要的
SCRUM的優點就是每個Sprint都能再Review一次需求到底是不是User要的


但是SCRUM的缺點就是沒有工程實踐
才會讓人覺得很難run 沒有效
我覺得真的很有道理 但是SCRUM提供了一個很好的Process
接下來就是團隊的努力了 如果團隊覺得真的需要幾個Practice把事情做好
那我們就把Practice補上吧



成功者會養成開始的習慣
所以聽到什麼 看到什麼 就開始做吧
從自己開始做起


SCRUM真的只是個Framework而已
他建議我們該做什麼 但沒有說要怎麼做
我認為我們應該要先採用Retrospective蒐集一下團隊的想法
當團隊覺得哪邊有問題的時候 SCRUM是否能解決問題?
然後自己想出Practice

了解它 調整它

第二場 - 在瀑布底下玩Scrum

這場我跟大家分享我們Team的Practice

[Team Member的緊密配合]
Group Design
SCRUM的Team很講求跨功能 在我們公司因為分工明確很難達成這一點
但我們透過Group Design 把大家集合在一起討論 設計 思考
透過群體智慧的力量 把Spec確認清楚
基本上我認為這還蠻符合SCRUM大家一起努力打拼的精神

[如何以JIRA視覺化我們的工作狀態]
原本JIRA是一套Bug的tracking system 但我們發現他還有agile board可以用
所以我們就拿來管理開發的工作項目
將我們傳統每個人要填寫的WBS 轉而填到JIRA的ISSUE上
Board仍是沿用我們以前傳統白板的Column
但是我這次新增一個Column - Pending
無論什麼原因 只要你的task是被卡住的 你就放到Pending這個Column
用意是 希望被卡住的東西提早被團隊看到
這樣才能幫忙處理

執行上則是讓Member從過去的便裡貼轉變成JIRA的ISSUE
導入之後的效果蠻不錯的 專案進度公開透明
大家都清楚每個人的進度
甚至還有member反應說 現在他可以知道哪邊稍微落後 他可以主動幫忙

以前的白板便利貼

現在轉變成JIRA上的Board



[如何改善Daily Scrum的效率]
我們團隊是個30人的大團隊
原本的Daily Scrum希望大家怎麼報告呢?

  • 昨天做了什麼?
  • 今天預計要做什麼?
  • 有沒有阻礙?

但是這類型的報告在30人團隊上實行會是個惡夢

SCRUM:用一半的時間做兩倍的事的作者Jeff Sutherland也強調
他覺得理想的方式應該是

團員們圍在一起討論戰術的景象 !!!




所以我們導入JIRA之後 在Daily Scrum的方式就變成了重點報告
我們變成針對Task討論 而不是每個人的進度報告

我們的遊戲規則是這樣
訂一個更新時間 e.g. 中午12:00
我就以這個時間當作分界點 去JIRA上抓每個Column的數據
然後在Daily Scrum前寄出通知信 通知member今天的情況
以及等下那些task要報告

這邊也加入視覺化的效果
列紅字的代表這個task有delay
列黑字的雖然沒有delay
但是他被放到Pending或是新增加到To Do的
也會拿出來討論

我們的白板從滿滿的便利貼,轉而填上目前專案的總體進度資訊;Daily Scrum也更著重於概述需要幫忙的項目並尋求協助。

如此這麼實行下來 Daily Scrum變得更有效率
專案資訊也更透明化
當然Member也能再透過JIRA看到更detail的資訊

[如何在每次的Sprint結束後都能更進步 - Retrospective Meeting]
如果你們還沒導入SCRUM
那我推薦第一個要實行的項目就是Retrospective Meeting了

透過Retrospective Meeting先蒐集大家的想法
我覺得一個重點在於
要大家真的覺得痛 覺得有問題了
我們再來討論要導入什麼Solution來解決

先有問題 再有Solution會比起你硬推Process來的有效喔

最後我跟大家分享幾點心得



從現在開始從自己開始做起吧

樂於分享才會教學相長
一切都以“win-win”的角度切入 要讓member覺得這是對他有幫助的
他才會接受

最後是真的有問題才是有問題 不要硬推 導入注定失敗
如果大家都覺得沒問題 只有你覺得有問題 是誰的問題?


最後送給大家一句話



其實還有更好的作法 只是你還不知道而已