Scrum,敏捷,專案管理,PMP,領導統御,甘特圖,排程軟體

    敏捷方法的成功密技(十二之一):Scrum 如何精準估算用戶故事的點數?



    在上一篇文章《敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?》當中,我們談到了怎麼將點數/心力(PointEffort)大小不一的各個用戶故事,依照用戶故事的優先級先後,排進衝刺Sprint)內去實做。也談到了如何拆解肥大的用戶故事為數個小故事,以便能繼續將該衝刺的剩餘空檔也能盡量地塞滿,以最佳化該衝刺的負載規劃。

    可是,這些作法都必須奠基於「夠精準的用戶故事點數估算」這個前提之下才有意義!那麼,實務上,我們到底應該怎麼來估算用戶故事的點數,才能稱上「夠精準」呢?

    在上篇文章當中,我們假設一個工作天的 8 個小時,全部都可以被運用在產品開發的相關工作上,也就是所謂的「理想日」,但是,事實上這是不可能發生的完美狀態!之所以會這樣假設,那是因為要簡化「最佳化衝刺負載容量」這個議題的討論!現在,我們得回歸現實,務實地來看看,一個「理想日」,實際上被運用在產品開發相關工作上的比例,到底是有多少?

    例行性事務

    在一個組織內,我們比較容易可事先預知的,不外乎像是,例行性的各式會議、個人預先排定了的年休假、政府公告的國定節慶假日、預先排定的教育訓練、公差活動等。這些活動所佔據開發團隊成員的時間,我們可以既快速又準確地計算出來,然後將原始的衝刺容量先直接扣除掉這一部份的 overhead,剩下的衝刺容量才是「有機會」被「完全」運用在產品開發工作的部份。

    之所以說「有機會」,是因為,除了上述的顯性因子之外,還有三大隱性因子,會不知不覺地吃掉開發團隊的時間,而且讓開發團隊在估算用戶故事所需心力(點數)的時候,難有警覺!

    一. 休息、中斷、干擾

    理想上,我們當然會希望開發團隊的每個人,都能夠 100% 地專注在工作上,但事實上,人的專注度是有限的,是需要經常有些 break,跟同事聊聊天、打打屁、滑滑手機,放鬆調節一下,這樣才不會把對工作的熱情疲乏掉的。更何況,職場上最常遭遇到的,也是團隊合作所無可避免的,亦即他人對你的「中斷」和「干擾」,而你也會對他人做必要的「中斷」和「干擾」,以利工作的進行!

    然而,不論是你自己需要的 break,或是來自他人的「中斷」和「干擾」,這部份往往是開發團隊在估算「完成用戶故事所需的心力(點數)」之時,最常被低估,甚或是完全被忽略掉的一環,不可不慎!

    此外,職場上我們經常遇到的時程延宕問題,其實有很大一部分的原因,是因為真正實做那個工作的人「誤判了形勢」或是「低估了難度」!

    二. 誤判形勢

    這部份往往是團隊成員溝通上的誤解,或是態度上的問題。例如,你以為別人會撿起來做的事,其實根本就沒有人去做!整個專案的必要工作範疇(Scope),常常掉得滿地都是,沒有人照顧負責!更糟的情況就是,大家都不想負責的一些「屎缺」工作,一直被推來推去,推到最後連時間都被推沒了。

    最明顯常見的一個例子就是,一條會讓設備隨機當機的 issue(或是 bug)的 owner,在瑕疵跟催系統(Bug Tracking System)上被轉來轉去,三不五時就換一個人,但是 issue 本身就是沒有被解決,甚至是毫無進展可言!

    之所以會發生這種情形的原因,很多時候是因為,issue 的現任 owner 怕自己的 KPI 難看(掛太久又解決不掉),在草率地分析一下 issue 的狀況之後,甚至是連「分析」的動作都沒有做,就說這條 issue 不是屬於自己的範疇,然後就把 issue 轉出去給下一個冤大頭!然而,這條 issue 在這個 owner 身上,其實可能早就已經掛了很多天了,一直到被 PM QA 盯催,才出此下策的!

    再來看看那下一位被人莫名其妙地掛了這條 issue 的冤大頭,他/她也可能又是在好幾天之後才發現這件事的,然後又是一陣轉出 issue 的輪迴,又浪費掉好幾天的時間,可是 issue 本身卻依然是毫無進展!

    下篇文章,我們就繼續來談談「低估難度」的狀況以及 Scrum 對這些問題的解決之道,藥方為何。

    待續


    圖片來源:www.goubiq.com

    相關文章: