日前於敏捷課堂上，有學員問到，應不應把瑕疵（以下簡稱 bug ）列為用戶故事來處理？

這個問題，其實可以分為好幾個層次來探討，我們就先從根源來談起吧！

瑕疵該發生嗎？是理所當然的嗎？

在估算一件任務所需的時間之時，大多數的人都會對主管或客戶這樣說，「X 天可以完成，另外，解 bug 還需要 Y 天」。這樣的說法，在邏輯上其實是有很大問題的，為什麼呢？

首先，所謂「完成」的定義到底是什麼？既是「完成」，為何還有 bug？

其次，我們請這樣說話的人換個位子，讓他當主管或客戶的角色，然後讓他的部屬或是承包商對他說同一句話，你覺得他還會接受這種說法嗎？如果不會，那為什麼他可以對自己的主管或客戶這樣報告時程呢？

當主管交辦你任務，或客戶花錢請你完成一件任務的時候，不會有人會允許你用有瑕疵的成果交差，不是嗎？你也許會不以為然地反駁，「我們的產品都馬還有一大堆 bug 沒解決就出貨，誰說不能帶著瑕疵交差的？」

我必須說，會這樣認為的人，是既不夠道德又不夠專業的！

試想一下，你也是某些產品的消費者之一，當你從口袋掏出辛苦血汗錢，滿心歡喜地購買了心目中的完美產品，之後卻陸續發現一堆 bug，此時你心中的感受如何？

「己所不欲，勿施於人」，自己不希望遭受這樣的待遇，就別這樣對待你的客戶或用戶。就算「零瑕疵」很難達成，我們仍舊應以此為高標準自我要求。我們應該這樣想，做不到其實是自己能力的不足，能這樣不斷地「反求諸己」，才會成為一個夠專業的工作者。如此，工作成果的品質才有可能愈來愈好，不會隨著泛泛大眾向下沉淪。

那些市場上帶著一堆 bug 出貨的產品，說到底，都是一種「不得已的妥協」，並非是「應該的」，更不該被視為是「正常的」！

當我們說出「還要額外 Y 天來解 bug」時，意思其實是，「我們一定會製造出 bug，而且我們還可以預估是哪一種 bug，所以我們知道還需要多少時間去解決它。」你不覺得，這樣的邏輯是很可笑的嗎？如果真是這樣，那為什麼還要分「完成任務」和「解 bug」兩種時間估算呢？

好，如果你認為，那個「Y 天」只是預留的時間 buffer，是用來「以防萬一」的，那就更好笑了，為什麼你在不知道會產生什麼樣貌 bug 的情況下，卻能預知預留 Y 天就夠用了呢？

因此，無論你怎麼解釋，只要講出「還要額外 Y 天來解 bug」這樣的話，都是不合乎邏輯的！

瑕疵可以放任多久再處理？

如果你能真的把「零瑕疵」當成嚴以律己的高標準，我相信，你定無法容忍任何 bug 的存在，定會在第一時間就「立刻」消滅 bug。如果有人會放任 bug 擺在那兒好幾天，甚至是好幾週、或好幾個月的，我敢肯定的說，那個人絕對是團隊中的大 bug！

道理很簡單，因為，被此人放生的那些 bug，其實一直都在暗中干擾或阻礙他人的工作，並且，還會不斷地釋放煙霧彈，混淆他人除錯的視聽。此外，此人所放生的 bug 愈多，這些 bug 累積起來的負面效應會指數型增長，最後會導致整個團隊的工作成果品質失控，客戶只好「被迫妥協」，接受帶有大量 bug 的產品出貨，結果，傷害用戶、傷害客戶，也傷害了團隊自己！

若是團隊能把「零瑕疵」當成品質要求的目標，那麼，團隊肯定會在第一時間就把 bug 消滅，不讓它們有任何作亂的機會。況且，在第一時間就去調查 bug，團隊的記憶通常都還很鮮明，解起 bug 來，速度當然就快得多，團隊效能自然會很高。

過去我曾經帶領過一個五人左右的研發團隊，開發一個需在電子郵件伺服器上運行的應用程式，因此，對於此應用程式的可靠度和效能，要求都非常地高。在八個月的專案開發期間，我的團隊恪守上述心法，「解 bug」先於「開發新功能」，竟可做到「待解的總 bug 數量」常態性地守在十五條以下，且極少有 bug 能存活超過一週。

儘管我們也沒有真的做到「零瑕疵」，但因為我們堅守此心法，故而團隊解 bug 的速度其快無比，專案成果的品質奇佳。更重要的是，團隊也因此變得更有自信，士氣更為高昂，加班變少，生活與工作也變得更加地平衡。

瑕疵該以用戶故事紀錄、跟催嗎？

談到這裡，相信聰明有智慧的你，已可了解，「看待 bug 的態度」才是一個專案品質管理的重點，而不是如何記錄和跟催那些 bug，更不是你用了什麼 bug 管理系統。如果團隊能堅守上述心法，那麼，很多時候根本就不需要紀錄和跟催 bug，因為 bug 往往在幾分鐘內就被解決掉了，根本就還來不及被登錄呢！

既然如此，那為什麼我們還要浪費時間去紀錄、跟催一大堆 bug 呢？

敏捷方法所力推的，就是「不斷提升團隊效能」，若團隊能落實上述心法，隨時且即時控管好工作成果品質，不就可以省下大量紀錄、跟催、討論 bug 所需的時間了嗎？這不就是提升團隊效能最好的方法之一嗎？

也許你會繼續說，「有些 bug 的真因真的很難抓，真的需要比較長的時間啊？」OK，我同意，的確會有這種案例，但我絕對不會同意，團隊落實上述心法後，這樣的 bug 還會很多。

對於這種 bug，我的建議是，直接把本來宣稱「已完工」的相關用戶故事，改回「未完工的狀態」，並重新安排進衝刺（Sprint）執行即可。因為，這些用戶故事確實是「未完工」，只是從前「誤以為完工」了啊！

若該 bug 較緊急嚴重的話，也可直接把那些相關「未完工」用戶故事，插隊到現行衝刺來優先處理，也無需把 bug 畫蛇添足地定義為一個新的用戶故事。

如果一時之間，團隊還無法確認最終的解決方案應該為何，那麼，團隊可以用一些簡易快速的 work-around 先「止血」，也不需浪費時間為這 work-around 寫個用戶故事，畢竟這只是短暫的應急措施，需要很快速做完，也需要在很快的將來把它給移除掉。

不過，為了跟催、產出最終的正確解決方案，這時最好就寫張用戶故事，並註記此用戶故事完成後，需一併將相關 work-around 移除，以免出貨時留下一大堆莫名其妙的 work-around 在裏頭，導致日後維護作業上的困擾。

至此，我們可以說，落實專案品質管理心法，是提升專案團隊效能的關鍵，最終能有效激勵專案團隊的士氣，這一連串的蝴蝶效應，實不可不慎呢！

全文授權轉載自威廉網紙的敏捷品質管理：笨蛋！問題不在是否能做到「零瑕疵」，而是在「看待瑕疵的態度」