敏捷品質管理:笨蛋!問題不在是否能做到「零瑕疵」,而是在「看待瑕疵的態度」


    日前於敏捷課堂上,有學員問到,應不應把瑕疵(以下簡稱 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 在裏頭,導致日後維護作業上的困擾。


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

    相關文章: