Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
使用計畫紙牌來做時間規劃
估算是一項團體活動, 每個團隊成員通常都要參加所有故事的估算, 為什麼大家都要參加呢?
# 在規劃的時候, 我們通常都不知道誰要負責實作故事中的哪個部份
# 每個故事要求好幾人參加, 並且要包括不同類型專長的人(使用者介面設計, 程式撰寫, 測試等等)
# 為了要能提供一個估算值, 團隊成員必須要對故事的內容, 有一定程度的了解. 藉由要求每個人去估算每個項目, 我們可確保每個團隊成員知道每個項目是什麼. 此外在sprint中, 也會增加大家相互幫忙的機率. 同時也增加重要的問題提早浮現的可能性.
# 在要求每個人對一個故事評估時, 我們常發現對同一個故事, 可能有兩個人的估算結果相差很大, 像這樣的狀況我們應該儘早發現, 並儘早討論.
如果你要求對團隊提供一個評估的結果, 通常來說最了解故事的人會第一個發言. 不過不幸的, 這通常會嚴重影響其他人的估算
這裡有一個很棒的方式可以去避免這件事 - 它叫做計畫紙牌(Planning Poker) (我記得是由Mike Cohn所創造出來的)
每個人都會拿到如上圖中的13張卡片, 每當在估算一個故事時, 每個成員選擇一張卡片, 來表示他的時間估算(以故事點數方式來表示), 並且把它的正面朝下放在桌子上. 所有的成員都放完以後, 桌上的紙牌在同時掀開. 這個方法要求每個成員要自行思考, 而不是依賴別人估算的結果
如果有兩個估算之間有很大的差異, 這時候團隊需要討論這之間的差異, 試圖讓大家對這故事的內容去達成共識. 他們可能會做一些任務拆解, 然後再重新估算. 這樣的事情會反覆進行, 直到這個估算收斂到一致. 也就是所有的估算對這個故事是差不多的.
還有一件重要的事情, 那就是提醒所有成員, 他們是要對這個故事中所有的工作做評估, 不是只是對"他們自己"負責的部份做估算. 測試人員不能只是估算測試的工作而已.
要注意到, 這裡的數字順序不是線性的. 例如在40和100之間是沒有任何數字, 為什麼會這樣呢?
這是因為, 一旦時間估算的值比較大的時候, 很難很準確, 這樣可避免對於估算精確度產生錯誤的印象. 例如, 如果一個故事被估算後, 大約是20個故事點數, 那他到底應該是20, 還是18, 還是21, 這都並不重要. 重要的是我們知道它是一個很大的故事, 很難被估算的很準. 所以20只是一個大約的估算.
那需要更準確的估算嗎? 要就要把故事拆解成更小的故事, 然後去評估那些故事.
此外, 你不能玩那種5 + 2 = 7哪種把戲. 要嘛就是5, 要嘛就是8, 沒有7這種事
有些卡片比較特殊:
# 0 = "這個故事已經完成了" 或是 "這個故事沒什麼, 只要幾分鐘就能搞定"
# ? = "我一點概念都沒有, 沒有主意"
# 咖啡杯 = "我已經太累了, 先休息一下吧"
釐清故事內容
當團隊會自豪地在sprint展示會議中, 展示一個新的功能, 最糟糕的事是產品負責人皺著眉頭, 並說: "是的,看起來不錯, 但是那不是我要的"
你如何確認產品負責人和團隊有相同的認知呢? 或是團隊中每個人對故事有相同的理解呢? 嗯, 你可能不確定. 但是有一些簡單的方式, 可以幫忙找出最明顯的誤解. 最簡單的方式就是確保故事中, 所有的欄位都被填寫.(或是更具體地說, 對於對於那些有高優先順序, 需要在這個sprint中完成的故事, 都需要填寫)
範例1:
團隊和產品負責人對於sprint的計畫很滿意, 打算結束會議. 這時候scrum master問說: "等一下, 這裡有個"增加使用者"的故事還沒有估算時間, 讓我們來評估吧! 經過幾次計畫紙牌投票, 團隊同意它的故事點數是20. 這時候產品負責人站起來, 大聲說道: "什...什...什麼?" 在經過幾分鐘的爭吵, 最後發現是團隊誤解了故事的範圍, 他們認為這只是要"提供一個漂亮的使用者介面, 來增加, 移除, 刪除, 和搜尋使用者", 但是產品負責人認為它只是"手動透過SQL指令去增加使用者到資料庫中", 所以他們再評估一次, 給了這個故事5個故事點數.
範例2:
團隊和產品負責人對於sprint的計畫很滿意, 打算結束會議. 這時候scrum master問說:"等一下, 這裡有個"增加使用者"的故事還沒有說他要如何展示?" 在一陣七嘴八舌之後, 某個人站起來說: "嗯, 首先我們登入網站, 然後...", 這時候產品負責人打斷說: "登入網站?" 不, 不, 不, 這個功能並不包含在這網站裡面, 應該只要給有技術背景的管理者一些簡單的SQL, 它就能夠執行了.
故事中"如何展示"的描述, 可以(最好應該)非常精簡! 否則你就沒辦法準時結束sprint規劃會議. 基本上, 它應該是非常平鋪簡單的敘述, 來描述如何手動執行最典型的測試流程. "先做這個, 然後那個, 最後再確認這個"
我發現, 這種簡單的敘述, 往往可以發現到, 團隊對故事嚴重的誤解. 這種事早點發現會比較好, 不是嗎?
留言列表
