熊貓克里斯

在開發活動中，有一些差錯或是不正確的假設，因而產生瑕疵（defect）。

如何處理這些瑕疵，是維持專案健康的重要因素。

瑕疵管理夠讓一些阻礙專案開發的問題浮上檯面。

你可以在沒有工具的情況下處理軟體瑕疵，但卻不能沒有一個適當的處理流程。

 

問題描述

瑕疵  信心  軟體品質

沒有好的瑕疵追蹤流程，就很難對應用程式有信心，而且絕對會影響軟體的整體品質。

 

瑕疵的類型

• 被遺忘的瑕疵：曾經處理過，但未將它關閉
• 不完整的瑕疵：資訊不完整
• 無效的瑕疵：與既有的瑕疵重複，或與應用程式的版本不符
• 功能需求：實際上並非瑕疵，而是功能需求

 

被遺忘的瑕疵

被遺忘的瑕疵指的是之前已經登錄至管理系統，但一直都是未解決的狀態。

象徵意義

• 團隊或用戶沒有興趣使用這個軟體，不再去更新瑕疵的狀態
• 軟體設計的很難用
• 開發團隊覺得更新瑕疵狀態已經沒有任何意義
• 團隊的文化已經瑕疵是為次等工作，不需由他們來處理

當瑕疵被遺忘，表示團隊的瑕疵追蹤系統或管理流程出了問題。

 

瑕疵資訊不完整

無論新或舊的瑕疵，它們的用處在於本身所包含的資訊。

例如：瑕疵報告上可能只有幾個字：無法登入系統或無法列印。

盡可能提供更多資訊，如果當下不寫清楚，很多東西很快就忘記了。

在專案初期的開發、測試，和發行階段通常不太明顯，等過一些時間之後，它就會無聲無息地嚴重危害開發效率。

 

無效的瑕疵

最讓團隊感到挫折的莫過於做白工。

造成無效瑕疵的原因

• 兩個人登錄了相同的瑕疵
• 版本是舊的，提報的瑕疵自然是針對舊的版本，無法重現瑕疵（ghost）

 

功能需求

應用程式應該提供卻沒有提供的功能，其實是功能需求，只是以瑕疵的面貌呈現。

例如：儲存鈕沒有傳送電子信箱給客戶進行確認，或找不到可以列印發票的地方。

這些功能需求的瑕疵往往會引發專案範圍和時程的爭執。

它們往往變成被遺忘的瑕疵。

 

瑕疵分級

雖然有將瑕疵記錄下來，但如果團隊沒有立即處理，心想：『下一的版本發行之前再來處理吧！』

這種心態往往就是形成棕地專案的主要原因。

分級前先了解每一個瑕疵的三件事：

• 夠對它做什麼？不能做什麼？
• 該由誰去做？
• 他有多重要？

初次檢視瑕疵時，目標是要決定將它關閉，還是指派給開發團隊或測試團隊。

 

關閉

無效的瑕疵才能被關閉，或者在無意中解決掉的瑕疵，也順便將它關閉，可以省下不少功夫。

 

指派給開發團隊

可以輕易重現瑕疵，而且測試團隊或是使用者確認是個有效瑕疵，此時可以指派給開發團隊處理。

 

指派給測試團隊

反之，需要進一步了解瑕疵狀況，指派給測試團隊，進行重現的步驟，或釐清不符合功能需求的地方。

邀請測試人員與用戶參與，對釐清問題非常有幫助。

 

注意事項

瑕疵擱置得越久，可用的線索就越少，越難重現問題。

與瑕疵有關的程式已經被大幅修改，但你不知道。

原作者是最能重現瑕疵問題的人。

若要將問題交給其他成員處理，記得加註你目前已經做了哪些處理。

已經想盡辦法，結果仍無法重現某個瑕疵，不妨就將它關閉吧。

 

規劃工作

開發新功能和修正瑕疵的工作通常都是同時進行的。

一開始進行瑕疵分析時，就讓整個專案團隊一起參與。

在與測試人員和用戶溝通時，同時包含新功能與既有瑕疵的相關問題。（避免認為程式開發的工作非常零碎不集中）

 

處理瑕疵清單

避免染上『等我們有空再回來處理』的心態，從頭到尾連續處理瑕疵。

設定里程碑，用以提升士氣，讓團隊看到自己處理瑕疵的努力，是有意義的。

朔造團隊文化，積極處理瑕疵，就能提升軟體品質。

 

維持動力

讓同一組人專門負責處理瑕疵分析，久了士氣便會漸漸低落。

定期將換瑕疵修正和功能開發的團隊成員，試著每隔一段時間互換一下工作。

培養團隊成員『修正瑕疵，人人有責』的觀念。

首要的任務應該是正確地修正瑕疵，減少瑕疵數量只是次要目標。

特別難應付的，就切成更小單位來處理。

不要勉強，每次只挑團隊能應付的問題來處理，只要有進展，無論多少都是好的。

 

處理無效的瑕疵

• 它根本不是應用程式的問題
• 對系統功能有所誤解
• 內容根本就是錯誤的

不只要先確認瑕疵是否存在，還得花時間證明它的確是個無效的瑕疵。

無效瑕疵的成立條件（符合其一即可）

• 應用程式並沒有出現瑕疵報告中所描述的行為。
• 瑕疵報告中隊對於應用程式該有的功能描述不正確。
• 此瑕疵報告所描述的細節和另一份報告重複。

無論什麼原因造成無效的瑕疵，都要把它背後的邏輯寫下來。

將每次學到的經驗保留下來，可供目前或將來的團隊成員參考（學習型公司 learing company）

 

瑕疵 vs. 功能

古老的爭議

• 開發團隊說：『那不是 bug，因為我們是根據當時所得到的資訊來設計的』。
• PM、QA、用戶說：『那不是我們想要或需要的，因此它是 bug』。

建立應用程式的目的是滿足用戶的需要，如果有不符合他們需要的地方，就必須加以處理，無論你叫它瑕疵還是功能都一樣。

是瑕疵還是功能也許沒有定論，但最終都是待處理的工作項目。

與其討論是瑕疵還是功能需求的細微差異，不如請用戶坐下來一起解決工作項目的優先順序來得有效。

就可以依照緊急程度來安排各瑕疵和功能需求的優先順序。

 

挑戰既有想法：以數字來代表優先順序

傳統上，通常是以『高、中、低』之類的名稱來指定。

再提報問題時，人們往往會傾向於指定較高的優先順序，結果都是一堆『緊急、急』。

試著用數字表示，或是列出清單由上到下排序。

像這樣一個既能了解專案工作排序方式。又能夠協助估計專案時程的用戶，在團隊遇到有關時程的重大決策時，將會是一個很棒的盟友。

 

剖析瑕疵報告

瑕疵報告的內容可能會不夠清楚或完整，導致需要頻繁確認問題。

這種頻繁確認的情況通常不是技術問題，而是溝通問題。

 

挑戰既有想法：別害怕當面溝通

盡量避免使用非即時的溝通工具（Email）。

當面或電話討論，可以讓討論的內容更深入問題核心。

面對面論通常比 Email 往返所花的時間少的多。

 

理想的瑕疵報告應具備的特徵

• 簡明扼要
• 清楚
• 完整
• 具建設性
• 已關閉

 

簡明扼要

摘要只是瑕疵報告的其中一部分，因此，它必須簡短、切中要旨。

在簡報或會議場合，簡短的摘要對於雙方的溝通會很有幫助。

 

清楚

清楚往往和簡明扼要互相抵觸。

對那些無法提供足夠資訊的簡短摘要，你可以試著進一步描述實際狀況。

以摘要『游標切換順序』為例，改成『編輯客戶資料時，離開地址欄位之後的游標切換順序不正確』。

描述瑕疵的細節時務必明確，不可含混不清。

 

完整

『魔鬼藏在細節裡』這句話似乎是專門為瑕疵報告量身定作的。

細節描述是瑕疵報告最重要的部分。

其中最重要的資訊

• 重現瑕疵的步驟（操作步驟）
• 問題出現時的現況描述（錯誤對話框、商業邏輯描述：縣市下拉選單，選擇台中，鄉鎮區內容沒有跟著動）

輔助的補充資料

• 螢幕截圖
• 錯誤訊息（堆疊追蹤，Log）

瑕疵處理完畢，報告應該要包含下列資訊：

• 重現瑕疵的步驟
• 重現瑕疵所需之任何補充資料或檔案
• 錯誤行為的描述
• 應有之正確行為的描述
• 修正瑕疵的過程中所採取的動作

 

具建設性

瑕疵報告的用處，並不只是單純紀錄 bug 及其處理過程。

如果能夠對它進行統計分析，也可能從中獲得一些極具參考價值的資訊。

先做好瑕疵分類：把性質相似的瑕疵加以分組，從『輕微UI問題』到『當機』。

可分析的資訊

• 應用程式的問題領域
• 程式碼的脆弱程度
• 程式碼變動
• 瑕疵修正率

 

已關閉

你的最終目標，就是要將瑕疵關閉。

可能是關閉的原因

• 已經修正完成
• 重複提出
• 內容不正確
• 無法重現問題

暫緩處理的瑕疵，請不要跟待處理的瑕疵混在一起。

停止『盡快把問題丟出去，踢皮球就沒事』的想法。

任何尚未解決的瑕疵都應該是為整個團隊的責任，應盡一切努力盡快（且正確地）解決它。

公開承認自己有錯，需要真正的謙虛和勇氣，而面對錯誤要能迅速反應並加以修正，則需要更成熟的心態。

 

灌輸品質文化

你敢說從來都不曾因為趕時程的緣故，而犧牲程式碼的品質嗎？

你是否不只一次看到某人（甚至自己）寫的程式碼有問題時這樣想：『我現在沒有辦法處理這個問題，還是先做個註記，等將來有空再處理』？

你是否曾與用戶多次溝通，卻在還沒完成釐清某些功能的細節之前就放棄溝通，而以自己推測的想法去實作，同時希望不會有人發現？

當你覺得『必須』這麼做的時候，就等於放棄對品質的堅持了。

 

對品質的承諾最起碼要做到

• 總是盡可能做到最佳品質
• 不使用次佳的解決辦法，甚至不允許程式碼有瑕疵
• 主動並持續尋找改善程式碼的方法

開發人員、管理階層、用戶、品保團隊

請記住，開發團隊只是整個專案團隊的一部份

 

零瑕疵

大部分的專案團隊都認為，只要是軟體就一定有瑕疵。

但這樣的想法有點問題，如果你相信程式至少有一個瑕疵，那麼兩個、五個、二十個瑕疵也沒什麼大不了？

一旦接受瑕疵必然存在的想法，就很容易養成先放著，晚點再來處理的習慣。

最理想的情況是，能夠消除瑕疵所產生的全部風險，而要達成這個目標，你必須把待處理瑕疵的數量降到零。

零瑕疵看起來是不可能的任務，但如果團隊每天都以此為目標而積極處理問題，其實並非不可能做到。

零瑕疵的目標不是要我們第一次就寫出完美的程式碼，而是讓團隊把品質擺在第一位。

軟體瑕疵是每個開發人員最優先處理的工作項。

立即處理瑕疵並不代表手邊的所有工作都得立即停止，開發人員可以等到他覺得適當的時機，在進行工作切換。

 

達成零瑕疵

零瑕疵是整體文化的一部份，也是團隊日常工作的基本原則。

一般的認知，開發人員的主要任務就是要開發新功能，因此潛意識裡，他們會將修正瑕疵當成次要的工作。

每天的站立會議（standup meetings）報告瑕疵，讓所有團隊成員瞭解並及時處理瑕疵的重要性。

在零瑕疵環境下工作的團隊不僅對品質更有信心，也能夠將這份對品質的堅持擴散至其他工作領域。

 

減輕利害關係人的恐懼與疑慮

龐大的待處理瑕疵數量是足以令專案失敗的巨大風險。

瑕疵應被視為個人對團隊的侮辱，洗刷的唯一辦法，就是徹底解決瑕疵，讓它永遠不再出現。

當你把瑕疵當一回事，就能夠得到用戶的善意回應。

 

使用瑕疵追蹤系統

不要把焦點侷限在利用工具來記錄瑕疵。你應該說明如何利用該系統來分析應用程式的問題領域。

能夠利用瑕疵追蹤系統來搜集有用的資訊，只能算是完成了一半的工作。

真正有幫助的，是從系統挖掘對專案團隊有參考價值的資訊。

 

瑕疵統計報表

趨勢資料

模組與版本號碼。

依模組統計趨勢

X軸：日期（每日或月份），Y軸：待處理的瑕疵數量。

例如：某個模組的瑕疵數量如果呈現穩定上升的趨勢，可能代表程式碼已經複雜到難以修改或維護了。

也可以統計瑕疵被標記為不處理的平均次數，若這個數值呈現上升趨勢，可能意味著專案團隊對於品質和零瑕疵的堅持正逐漸減弱。

瑕疵資料的趨勢並沒有什麼固定的因應動作，這些資訊應該只是用來輔助決策的制定。

 

發行備註

發行備註：提供有關此次發行版本的一些變更說明。

將你的瑕疵跟特定的發行版本連結起來，你可以在瑕疵報告增加一個欄位，讓登陸瑕疵的人可以指定其對應的發行版本。

 

總結

解決待處理的瑕疵後，就要依照零瑕疵的原則來處理問題。

屬於功能需求的瑕疵，應當讓用戶來安排其優先序，確保需求不遺漏，也讓用戶感受到有認真回應他們的需求。

運用瑕疵系統資訊來找出與開發工作有關的趨勢變化。