目前分類:Estimation (7)

瀏覽方式: 標題列表 簡短摘要
 
敏捷評估是否就比傳統評估方法準確很多嗎? 這是很多人的疑問. 我想沒有所以一種方法是萬能的, 重點在於你知不知道他的原理, 以及使用的背景 (context) 為何.
 
因此, 簡單把兩者做了一些比較, 希望幫助大家, 可以更瞭解兩者的不同. 
 
 

kojenchieh 發表在 痞客邦 留言(0) 人氣()

敏捷最重要的事情, 就是及早交付價值給客戶.  可是, 那評估對客戶的價值是什麼? 我們真的需要做這個事情嗎?
 
之所以會這樣問, 是因為大家都知道 estimation 常常很不準, 每次一開始花了很多時間去做, 可是一執行後往往偏差的十分離譜, 因此很多人很討厭評估.
 
estimation  
 

kojenchieh 發表在 痞客邦 留言(0) 人氣()

不少團隊在執行 Scrum 時, 常常無法在 sprint 內完成原先規劃的東西, 因此他們想拋棄 Scrum, 轉向 Kanban 的陣營, 這是對的嗎? Sprint 是不好的嗎? 讓我們來聊聊這個問題.

 

1280px-Scrum_process.svg  


很多人之所以無法在 sprint 內完成原先規劃的東西, 不外乎有以下主要原因:

kojenchieh 發表在 痞客邦 留言(0) 人氣()

大家在做估算(estimation)時, 最就要的是要有人跟你討論, 問問看他們對你的結果是不是有意見, 他們可能會想到一些你沒注意的面向, 讓你的估算變得比較準確.

這個道理, 其實已經有很多估算的方法採用. 例如Delphi Method. 便是這個概念的始祖. 但是今天我不是要講這個方法, 如果你對 delphi method 有興趣, 可以去看下面這篇文章, 寫得十分詳細.
http://wiki.mbalib.com/zh-tw/%E5%BE%B7%E5%B0%94%E8%8F%B2%E6%B3%95

我要談的是 playing poker, 敏捷社群常用的一種評估方式. Agile 很多方法並不是新創, 但是常常會把它改的更好玩, 更簡易, playing poker 便是如此. 它也是利用了眾人的智慧, 來評估這些功能需要多時間完成. 因此在使用 playing poker 時, 有幾件事情要特別注意的:

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Wiki中對Playing Poker的介紹

http://en.wikipedia.org/wiki/Planning_poker

Planning poker是以共識為主的評估方法. 在軟體開發上, 來評估工作的effort和相關的size.

它通常在agile軟體開發方法中被使用到, 特別是Extreme Programming.

這個方法是由James Grenning在2002時所提出來的( http://renaissancesoftware.net/papers/14-papers/44-planing-poker.html). 後來由Mike Cohn在Agile Estimating and Planning一書中發揚光大.

在Planning Poker中, 是由一堆數字的牌所組成的. 通常他們是依費式數列來產生的:0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Playing Poker二三事

Agile團隊中進行release planning時, 常拿playing poker來進行estimation. 最近在一次workshop中, 我們得到以下的經驗

1. Playing poker不只只是做評估而已. 因為在這過程中, 若是大家所評估的數字有差距, 需要釐清之間的差距. 這時候便是一個機會, 可以讓大家對需求做個探討.

2. 若是要挑選一個User story來當起始點, 我們覺得能挑一個size/effort是中間大小的user story是比較好的. 若是一開始挑最小的, 接下來會遇到的問題, 是當你遇到很多很大的的user story, 你不容易講出這些大的user story, 到底他的size/effort是這個最小的user story的幾倍

3. 當你的user story 的story point值很大時, 13, 20 or 無限大時, 這個user story是需要在進一步拆解, 或是做feasibility study. 否則這些這麼大的評估, 對整體來說可能意義不大.

4. 需要不同角色的人來加入, 否則你容易遺漏某個面向的工作, 這樣才能讓你的評估比較正確.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

很多人對於什麼是 Story point 不是很了解, 這是剛好有篇文章介紹.
 
Show Relative Points  
 

首先, 在 Mike Cohn 所撰寫 "Agile Estimation and Planning" 書上, 你可以看到他有這樣的描述:

 

kojenchieh 發表在 痞客邦 留言(0) 人氣()

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼