[承上篇]
三. 低估難度
「低估了其難度」則往往是負責該工作的個人,可能是因為個人能力的不足,或是因為過於草率輕浮的心態,而低估了該工作的複雜度與難度。例如,許多本來就應該要做的相關的測試驗證細節工作,根本就沒有被好好地思考,詳盡地規劃進來,以至於該員提出過於樂觀的時程估算(完成用戶故事所需的心力/點數)。
這樣的結果,就經常會造成專案在執行過程當中,爆出巨量的 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」),最後的這個衝刺容量,才是開發團隊真正能用,而且最為精準的「預估值」!
圖片來源:www.goubiq.com
相關文章: