David Ko的學習之旅

 
敏捷評估是否就比傳統評估方法準確很多嗎? 這是很多人的疑問. 我想沒有所以一種方法是萬能的, 重點在於你知不知道他的原理, 以及使用的背景 (context) 為何.

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

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

很多人之所以無法在 sprint 內完成原先規劃的東西, 不外乎有以下主要原因:
1. 不知如何切割 user story
這裡是能力問題, 通常是大家沒有能力, 不知道如何把 user story 切的小小的, 讓它可以放到一個 sprint 中完成. 因此這不是 sprint 的問題, 而是大家不會切.
2. 有些 user story 的特性是不容易在一個 sprint 內完成
老實說, 有些 story 確實不容易切, 像是 installation 或是 migration, 這些東西不容易拆解, 或者是拆解的代價太大. 在這種狀況下如果我們硬是套用 sprint, 變成是為做而做, 這樣反而讓團隊效率變差. 
3. 評估老是不準
正確來說評估並沒有所謂的單一數字的答案, 也就是說評估的答案需要伴隨著機率, 例如: 如果你說 2 天做完, 那它的成功的機率是 80%; 如果給你 5 天的話, 那做完的機率可能就是 95%. 可是通常老闆並不會這麼想, 老是叫你給個標準答案, 當然是只有錯的份. 
另外一件更糟的事, 就是在早期資訊不充足下, 就要叫你給個答案, 這也是另一個不準的原因, 沒人可以在資訊不夠的狀況下, 能夠有準確率很高的 estimation.
還有啦, 通常會估不準, 另一個原因可能是東西太大了, 也就是第一點的問題沒能力解決, 導致伴隨評估也沒有辦法準.
因此根據以上幾種原因, 用 sprint 來規範哪些東西要在這時間內做完, 往往是失敗收場的狀況居多, 並且也容易導致團隊對 scrum or sprint 失去信心. 
如果我們把 sprint 想成只是週期性檢查多了多少, 以及有個時間檢討以前做的事情, 這會比較健康. 會比強迫大家一定要在 sprint 做完有意義多了. 所以不管用不用 sprint, 我會建議以下事情仍然要繼續進行:
1. 持續交付
即使有些東西在一個 sprint 內做不完, 但是你還是要保持持續交付一些項目, 讓團隊能夠及早得到一些回饋, 也讓相關利害關係人能夠安心. 而不是通通擠到最後才交卷.
2. 建立調整和回饋的迴圈
在 scrum sprint 中會進行規劃會議和回顧會議, 讓我們可以根據上個 sprint 的結果, 來挑整自己的腳步, 使得我們更接近想要達到的目標.
3. 持續精煉需求
需求這件事情需要持續條理的, 也就是說你除了看這個 sprint 的需求外, 你必須也看看下幾個 sprint 的需求, 對他們做些整理, 可能是做些分析, 或者是把它們拆解成更小的項目. 這樣你才能知道短期的未來有什麼風險; 並且也讓之後真的要處理時, 不至於連一點 idea 都沒有.
所以重點不是 sprint, 而是該做的事情要做, 該有的能力還是培養 ….

大家在做估算(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 時, 有幾件事情要特別注意的:

Wiki中對Playing Poker的介紹
http://en.wikipedia.org/wiki/Planning_poker
Planning poker是以共識為主的評估方法. 在軟體開發上, 來評估工作的effort和相關的size.

Playing Poker二三事
Agile團隊中進行release planning時, 常拿playing poker來進行estimation. 最近在一次workshop中, 我們得到以下的經驗
1. Playing poker不只只是做評估而已. 因為在這過程中, 若是大家所評估的數字有差距, 需要釐清之間的差距. 這時候便是一個機會, 可以讓大家對需求做個探討.

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