2015-04-28

需求怎麼估? - Animal Point Workshop Part II - 實際動手玩

需求怎麼估? - Animal Point Workshop

前情提要

需求怎麼估?  - Animal Point Workshop Part I - 估需求前必須知道的事


Previously 我們討論了估需求前必須知道的事
提到了
三個基本原則 : 
  • 相對比較 絕對評估 簡單
  • 小任務 大任務 容易掌握
  • 使用 Planning Poker 來估

點注意事項:
  • Who : 做事的人一起
  • When : 被分派任務就估
  • What : 評估時請考慮複雜度重複性風險

現在就要帶大家來體驗一下Animal Point Workshop
















遊戲故事的假設是這樣的:
今天你們是個動物園管理團隊,要評估幫動物們洗澡的複雜度。
團隊裡角色只有兩種
1.     Product Owner
Product Owner(PO)要解釋有關動物洗澡的任何需求,所以當團隊翻出新的動物牌卡時,PO要天馬行空地描述需求,假若Team Member對於需求有任何的疑問,PO要解答團隊的疑惑。(但要注意的是,PO不要主動地引導,for example:我覺得不是這樣)
2.     Team Members
Team Members 則是實際要幫動物們洗澡的員工,他們必須一起評估每個動物洗澡的需求複雜度。過程中若是對需求不清楚則是要趕快找PO確認細節。

圖為PO解釋需求中





















Step 1 : 比較大小
注意事項:團隊成員輪流出動物牌卡,一次只能移動一張卡 (翻新圖卡或挪動現有圖卡)
步驟:
          (1) Member A隨機抽一張新牌卡,PO解釋新牌卡的需求。
          (2) Member B隨機抽一張新牌卡,PO解釋新牌卡的需求。Member B要比較現有牌卡的複雜度,小的擺左邊,大的擺右邊。挪動時請向Team說明理由。
          (3) Member C 可以選擇以下兩種方式
                   i. 抽新卡如同步驟(2)
                   ii. 挪動現有牌卡。挪動時請向Team說明理由。

          (4) 重複步驟(2)或是步驟(3)直到全部的牌卡都抽出以及大家都同意現在的排序。

結束這個步驟之後,會得到一串經過排序的牌卡






Step 2:校正基準
兩套校正的方法

(1) 歷史基準
由於SCRUM裡評估的Story Point都是相對的,所以每個Sprint 或是每個Release估出來的數值無法拿來比較。這邊採用歷史基準的原因就是想要讓每一次的評估都可以校正為統一的標準。
所以校正的方式是拿出過去評估的需求,首先要評估這個需求可以插在剛剛排序完卡列中的哪個位置?
For example:
假設小黑熊在過去評估的複雜度為8點,將他放置在現有排序中,則小黑熊8點就是這次的基準參考點。







(2) 定義最小
若是不想採用歷史基準或是沒有歷史資料,那就就這次的需求來估算吧。上一集有提到原則二:小任務估算比較有信心、比較精準。所以我們可以拿目前最小的需求來估算點數。
For example:
假設這次團隊所排序最小的需求是幫天竺鼠洗澡,經過Planning Poker的過程估出複雜度為3點,那麼這次的需求複雜度就是由3點起跳。









Step 3 : 評估程度
注意事項:
團隊成員輪流出點數,一次只能更動一個點數
若相鄰多張圖卡皆評估為相同點數,請將該點數放置在最左邊的圖卡
步驟:
          (1) Member A檢視桌上的排序,依照基準比例,挑選合適的一張點數放置在任何一張牌卡上。
          (2) Member B可以選擇以下兩種方式
                     i. 放上新點數如同步驟(1)
                     ii.挪動現有點數
          (3) 重複步驟(1)或是步驟(2)直到大家都同意現在的估算。


結束這個步驟之後,會得到評估後的結果






Recap一下Animal Point Workshop的執行步驟:

  • Step 1:比較大小
  • Step 2:校正基準
  • Step 3:評估程度

心得

在玩Workshop的過程中,有的團隊有面臨到意見不合的衝突,但是經由充分的討論以及一再地向PO確認需求,最後總是能達成共識。也有PO根本不知道這張卡的需求為何?所以團隊很有共識地給予那張卡一張問號,代表PO要先回去搞清楚,是不是很符合現況呢XD












結論

導入SCRUM 或是Planning Poker的方法進入團隊是道門檻,而今天筆者介紹的Animal Point Workshop有個好處:簡單。越簡單的東西才越容易導入到團隊裡。相信經過這個Workshop的練習能夠讓團員們體會相對估算的精神;幫助他們熟習一起估算的方式;在討論中達成共識。大家一起估就能消除個人主觀的因素。整個團隊估出來的東西才會比較客觀。

另一方面,這種簡單的相對估算,可以幫助團隊快速地區分需求複雜度,團員們不用再苦惱到底怎麼估才能估出一個精準的工時,對公司跟團隊都是一種”win-win situation”喔。

參考資料
估算需求複雜度(2)Dog Point Game
A Fast Story Point Estimation Process

需求怎麼估? - Animal Point Workshop Part I - 估需求前必須知道的事

需求怎麼估? - Animal Point Workshop



2015.04.24 星期五
我很榮幸在Agile Meetup新竹場分享這個Topic


























其實這場Topic的靈感是來自於91學長上次的Dog Point Workshop
http://www.codedata.com.tw/social-coding/estimation-with-dog-point-game/
只是我這次有調整了一下講課內容以及workshop的流程

這邊就先整理一下今天的內容吧

今天這場sharing 主要分兩個部分
上半場主講估需求前必須知道的事
下半場就讓大家來玩Animal Point Workshop

來先談談估需求前必須知道的事吧

在任何的軟體開發流程中,需求估算永遠不會消失。
或許很多朋友認為估需求是相當困難且痛苦的一件事,或許很多朋友把大量時間花在冗長的估算上但始終也估不準。
今天這堂課將則是引導出需求估算的另一種方向 - 相對估算
課程將會以Workshop的方式進行,用一個有趣的案例,讓學員們實際操作,體會相對估算的精神。

首先 我請大家先思考一下
目前自己的團隊中對於估需求這件事是否遇到什麼問題?















主要的想法是要解決問題前
至少要知道問題是什麼吧

於是我就請學員們分組討論
5分鐘後請每組挑出三個最重要的問題來分享
以下是學員們的分享:

  • 估不準
  • 照著被訂好的deadline估
  • 每個Sprint的工作量不一
  • 總是被分派到類似的任務
  • 需求不明確
  • 需求超出能力
  • 團隊對工時有落差
  • 範圍太廣很難估

或許今天的內容無法解決他們的問題
但是釐清問題就是解決問題的一大步了

接下來就進入主題了

I. 估需求前必須知道的基本原則

  • 相對比較 比 絕對評估 簡單
  • 小任務 比 大任務 容易掌握
  • 使用 Planning Poker 來估

原則一 : 相對比較絕對評估 簡單
我請大家進入一個情境 : 假設今天你要爬樓梯
請問大家這24層樓的大樓以及101登高賽分別要爬多久?




要很快地回答要爬多久其實有點困難
但是要比較兩者之間的難易度就簡單多了

我們不知道每一棟高樓實際要爬多久
但是知道彼此的相對關係

所以估相對關係真的比較簡單


原則二 :  使用 Planning Poker 來估
我一樣請大家進入一個情境 : 假設今天你要評估肌肉痠痛的程度
一樣是爬樓梯
面對1層樓、3層樓或5層樓甚至是40層樓應該是不一樣的痠痛程度吧!
那我們如何很快地評估肌肉的痠痛程度?
其實可以參考費氏數列 (Successione di Fibonacci in wiki)
















費氏數列的特性是越後面的數字,差距越大。
當數字小的時候,你感覺得到差距


















可是當數字大的時候,你卻分不出誰大誰小,反正都很痛苦就是



















所以費氏數列很完美地詮釋了需求越大,不確定性越大的特性。
我們可以利用這個特性來對需求快速的分類
這邊呼應了原則一,我們對於評估實際的數值感到困難,但評估彼此的相對比例會簡單很多。
當數字小時,即使保守點取較大數,也不會造成太大的影響
當數字大時,不用糾結於40或是41的差別

而Planning Poker正是使用類似費氏數列的數字牌卡
所以這邊推薦大家使用Planning Poker














II. 評估時的注意事項

Who - 誰來估?

























你累了嗎?來聽個故事好嗎?
照片裡的主人翁是個小力士,這個祕密被邪惡老爸發現了之後,規定他一分鐘之內要搬10包尿布!但是實際上小力士只能搬2包。
請問各位如果你是小力士,作何感想?
小力士:實際搬的人又不是你! 真是OOXX
這種情境總是一再上演阿!所以誰要來估?當然是有做事的人才來估。而且要大家一起評估,估出來的結果才會客觀;大家也會達成共識;團隊也有參與感。

所以誰來估?
由做事的人一起評估

When – 何時估?
還沒分派任務前估


原因是將個人因素降低,估出來的結果才會比較客觀。

What – 評估因素
我們在評估這個需求時,可以就這三個角度來思考 :

  • 複雜度
  • 重複性
  • 風險

這邊是參考之前讀的一本書:
Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools, & Tips

小結
為何推薦大家採用這套相對估算方法?

  • 簡單
  • 客觀評估
  • 達成共識
  • 自我承諾


簡單
越簡單的東西才越容易導入到團隊裡。尤其要改變大家平常的工作習慣,必須想辦法簡單到無縫接軌,或是讓團員們有感覺到好處。才容易導入成功。

客觀評估
大家一起估,就能消除個人主觀的因素。整個團隊估出來的東西才會比較客觀。或許你會問,那估錯怎麼辦?那就下次改進囉!我們也可以利用每次的Retrospective Meeting修正一下估錯的因素。

達成共識
大家一起估的東西,才會達成共識。

自我承諾
我一直都認為自己開出去的支票,比起被別人assign,總是會更想努力地兌現。而這套方法是Member大家一起估的東西,等於是自己承諾的份量,他們肯定會想辦法完成的。

下一篇就來談談Animal Point Workshop怎麼玩喔
需求怎麼估? - Animal Point Workshop Part II - 實際動手玩

參考資料:
估算需求複雜度(1)Story Point 與 Planning Poker

2015-04-14

[瀑布底下玩SCRUM] CM的Retrospective Meeting經驗談


最近趁著 I6Sprint結束,打鐵趁熱地在部門內辦一場 Retrospective meeting。算算日子轉到 CM Team也已經 9個多月了,從 6.0 SP3 I2開始推動 Retrospective meeting,至今也已經舉辦過4場。但過去的方式都是傳統式的ㄧ個ㄧ個地表達意見,雖然還算open-minded,但是有時候仍會被前面講過的idea影響,有些同仁則是反映都是那幾個人在發表。

所以這一次我特意換成外界SCRUM愛玩的那一套便利貼Feedback法,事前先請同仁就I6這個Sprint先想一下以下三個主題:
1. Good
2. Should be improved 
3. New

當天會議的流程如下:
1. 回顧上個Retrospective Meeting Result
2. 報告這個Sprint的相關統計資訊
3. Brainstorming for good (5 minutes)
4. 大家輪流上台貼便利貼及說明
5. Brainstorming for improved(10 minutes)
6. 大家輪流上台貼便利貼及說明
7. Brainstorming for new (5 minutes)
8. 大家輪流上台貼便利貼及說明
9. 分類 improved & new的便利貼
10. improved & new中選出3項下個sprintaction item
11. 討論解決方案

這次我特別將good, improved, new 分成三個部分來分開討論
用意是希望同仁們可以更focus on目前的topic

或許是這套方法引發大家源源不絕的想法吧?
或許是大家對團隊很多期待吧?

還滿開心看見當天同仁們滔滔不絕地發表看法,不過也讓會議時間到了2小時仍是無法結束,所以很可惜最後並沒有跑到投票與討論solution的流程。
會議結束後我把黑板上的便利貼拍下來,後續會整理成文件以便下次使用。(Post-Mortem Meeting還能拿來用)

幾點心得分享
1.     時間還是必須要控制,實在run太久了。
2.     這次的方式的確激發出大量意見,大家也都在台上侃侃而談,我覺得效果不錯。
3.     最後還是沒能跟QA一起舉行是有點可惜。
4.     聽到同事們支持與稱讚這次Sprint推行的方法其實還蠻有成就感的,原本還擔心會造成大家的負擔,不過就結果論來看,從”win-win”的角度切入真的比較容易推行喔。