（Photo by Agê Barros on Unsplash）

在上一篇文章敏捷方法的成功密技（十二之一）：Scrum 如何精準估算用戶故事的點數？中，我們談到了精準估算用戶故事點數的兩種現象，這一篇文章，我們就要來繼續談談「低估難度」的狀況以及 Scrum 對這些問題的解決之道，藥方為何。

三. 低估難度

「低估了其難度」則往往是負責該工作的個人，可能是因為個人能力的不足，或是因為過於草率輕浮的心態，而低估了該工作的複雜度與難度。例如，許多本來就應該要做的相關的測試驗證細節工作，根本就沒有被好好地思考，詳盡地規劃進來，以至於該員提出過於樂觀的時程估算（完成用戶故事所需的心力／點數）。

這樣的結果，就經常會造成專案在執行過程當中，爆出巨量的 issue！團隊中最常聽到的就是「沒有想到」、「漏掉了」這種說詞。然後，團隊就只能疲於奔命地去擦自己的屁股，去解決這些自己造成的巨量 issue，下場也就往往是需要不斷地加班，原本規劃的工作，時程也被嚴重地排擠！

Scrum 的藥方

針對「人是需要適度休息」的部份，Scrum 的藥方很簡單，就是「上班專注、下班守住」！上班時間內，盡可能地專注，自己有困難做不好，沒關係，還有 Scrum 團隊一起幫你盯著你自己，因為大家都坐在同一個辦公空間內工作，也就是所謂的「共同辦公（co-location）」，誰在做啥，一清二楚，一目了然！

上班專注了 8 個小時，自然會精疲力乏，所以 Scrum 非常不鼓勵「加班」這件事。不單是因為「加班」往往是「工作效率不彰」或是「不良工作規劃」的一種表徵現象，「加班」更會有「殺傷工作熱忱」的嚴重副作用！

針對「中斷、干擾」，Scrum 的藥方是，設立一位 Scrum Master 這個「防火牆」！之前的系列文章「敏捷方法的成功密技（六）：Scrum Master 並非你想像的那般卑賤！」一文當中，我們談過 Scrum Master  的職責，這裡就不再贅述。當然，這個防火牆的角色一點也不好當！有的時候，一個小小的 Scrum Master 其實是很難擋得住從高階長官來的中斷和干擾的。

為了不讓擔任 Scrum Master 的這個夥伴，長期又孤獨地面對自團隊外攻向團隊的各種「中斷、干擾」砲火，繼而意外陣亡，有另外一個方法可以稍微緩解這種憂慮，那就是「大家輪流當防火牆」！

開發團隊成員大家各自輪值一週「防火牆」，或是一整個衝刺的「防火牆」都可以，這樣一來，外界也就不容易對單一的 Scrum Master 產生偏見和成見，認為這個 Scrum Master 老是找他們的麻煩，阻礙他們跟團隊內部的個別成員溝通了。

針對「誤判形勢」這部份，Scrum 設計了「每日立會（Daily Scrum）」來解決。每天一早，固定時間、地點，每一位發團隊成員在 Scrum Master 的引導之下，向「開發團隊」陳述說明「昨日的進度、今日的計畫、障礙為何」，這樣也就不太可能還會有工作掉在地上，沒有人去負責關照它們了！

針對「低估難度」的部份，Scrum 設計了一個非常不錯的解決之道，也就是「三人行必有我師」的道理！

Scrum 充分地運用了團隊的整體力量，以 Scrum Master 引導開發團隊，共同和 Product Owner（產品負責人）「一起」來「討論」和「釐清」所有的用戶故事，以減少任何對需求可能造成的誤解。然後，在評估每一個用戶故事所需點數的時候，「全體」的開發團隊成員（實做者）都得「一起」參與，貢獻觀點、經驗，以及創意。

這麼一來，一個用戶故事的討論，不論是從最外層的使用者界面、到中下層的軟硬體架構設計層面，以及測試人員的各面向測試需求，都可以被集思廣益地，更為廣泛地照顧到。如此，就能大幅地減少「誤判形勢」和「低估難度」的機率了。

透過 Scrum 的種種制度流程設計，產品開發以及專案管理所會遭遇的種種問題，就能得到相當程度的「緩解」，去除掉一些不該發生的問題和現象之後，我們才有可能對「時程估算」（用戶故事點數估算）這件事，能有所掌握。

然後，我們才能把即將開始的衝刺的容量，扣除掉例行性事務所佔時間，剩餘的可用衝刺容量，再依據過去這個團隊的歷史紀錄經驗，打個專注度的折扣（例如，70％，也就是所謂的「開發團隊 Focus Factor」），最後的這個衝刺容量，才是開發團隊真正能用，而且最為精準的「預估值」！

原文轉貼自：威廉網紙（原文連結）