（Photo by Veri Ivanova from Unsplash）

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

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

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

例行性事務

在一個組織內，我們比較容易可事先預知的，不外乎像是，例行性的各式會議、個人預先排定了的年休假、政府公告的國定節慶假日、預先排定的教育訓練、公差活動等。這些活動所佔據開發團隊成員的時間，我們可以既快速又準確地計算出來，然後將原始的衝刺容量先直接扣除掉這一部份的 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 對這些問題的解決之道，藥方為何。

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