在開發中的測試活動裡,測試工作找出了有問題的瑕疵,而在專案進行過程中,如何記錄這些瑕疵、以及追蹤它們被處理的狀態,一般來說,被稱為「瑕疵追蹤(defect tracking)」。

廣義來說,瑕疵追蹤也是屬於特定類型的議題追蹤,只不過它所追蹤的議題項目,都是屬於產品的瑕疵。

而在專案管理裡,所追蹤的項目,則可能是任何類型的待辦項目,像是一個需要被完成的功能、需要被回答的問題、……等等。

關於工作事項溝通、記錄與追蹤,現行的各種方式

在軟體開發專案裡,持續充斥了許多需要被完成的工作事項,但是這些事項都是怎麼被溝通、記錄、還有追蹤處理的情況呢?即使議題追蹤是個很典型的活動,甚至議題追蹤系統或服務,也是極為普遍而且有著多樣化的選擇,但是,在軟體開發工作裡,還是很常看到許多人不使用議題追蹤系統來追蹤專案中的待辦工作,包括測試後所找出的軟體瑕疵。

所以我們可以看到,有些人用電子郵件來告訴其他人需要被完成需求或是被解決的問題,也可能是利用電話或是傳訊軟體,但是這類的溝通工具本質上並不適合做議題追蹤,因為你很難輕易的將所有待處理的事項統整在一起,獲得全貌。

當專案中這些待完成的工作,散落在電子郵件、對話記錄、甚至是一通電話後的全無記錄,還能有多少人記住究竟還有什麼事情應該要做呢?

是否也有過類似的經驗,當你突然想起了一件應該要完成的工作,卻記不得關於這個工作的細節資訊時,接著就是開始翻箱倒櫃的搜尋電子郵件信箱、對話記錄。

議題追蹤是個很基本的活兒,但是也很無奈的還是有很多人並沒有做好。

另一方面,我們也可以看到,有些開發團隊即使運用了議題追蹤系統,來追蹤專案中需要被處理的議題,但是,也沒有善用,以致於效果打了折扣。

現今議題追蹤系統繁多,各有各自的設計及功能,但整個議題追蹤的中心思想都是共通的,只要把握基本的觀念,就可以為專案帶來很大的幫助。

議題追蹤系統所用的重要資料欄位

一項專案管理中的議題,或是軟體測試後找出的瑕疵,概念上,應該具備什麼樣的結構呢?

無論你使用那一個議題追蹤系統,描述一項議題或瑕疵,大抵上都會有這幾個資料欄位:編號、標題、內容描述、狀態、被指派的人員、優先程度(Priority)、嚴重程度(Severity)。

編號

編號通常都是議題追蹤系統自動產生。它的最大作用,是讓專案參與的人員在溝通時,可以更輕易的表示,究竟在討論的是那一個議題。

例如,我們可能會說:「#90、#103和#125 必須在這個星期被解決」,這麼一來,只要依據這些號碼再到系統裡察看,即可知道對應的議題究竟是那些。

標題

當你想要送出一個新的議題,讓它進到被追蹤管理的流程中時,你得用一個簡單扼要的標題來描述它,以便使其他人都能輕易的了解這個議題概略的內容。

內容敘述

而「內容描述」則是關於這個議題的細節性資訊,如果這個議題是一個待完成的新需求,那麼在「內容描述」部份,就會是關於這個需求的規格及參考資料,例如相關的 wireframe,或是美術設計的圖檔。

如果這個議題是個瑕疵,那麼「內容描述」中的資訊,就應該包括了這個瑕疵發生的前提,像是作業系統版本、重現此瑕疵的操作步驟、甚至是錯誤畫面。

大多的議題追蹤系統,允許你持續補充「內容描述」中的資訊,這讓你得以持續記錄處理這個議題時的想法、獲得的新資訊、或是中間產物。

總之,你應該盡可能的持續記錄處理的歷程。我們的同事,甚至會將群組通訊軟體裡的討論內容,持續張貼到議題追蹤的內容裡來。這有很多好處,一來所有和這個議題相關的重要討論,都能繼續以這個議題為中心,被妥善的記錄;二來,即使這個議題被處理完成了,日後遇到類似或是相關的議題時,也能便利的在議題追蹤系統中,找到重要的參考資訊。

當中還有個很常見到的問題,那就是在同一個議題裡,同時描述了多個議題。就像在一次的測試之後,測試人員將整個批次的測試結果,全部在同一個議題裡輸入了。這樣貪圖便利的情況還普遍的,但這樣不利實質的追蹤及指派處理。

因為,這裡頭事實上是含有多個問題,卻被混雜在一起了,沒有辦法將裡頭的事項,個別指派給不同的人處理,也沒辦法獨立追蹤其個別的狀態。因此,此處的基本原則是:一個議題編號,只記錄一個議題的內容。

狀態

「狀態」是指這個議題被處理的狀態,通常,我們會用「狀態」來描述一個議題,或者是瑕疵的生命週期。

以瑕疵的追蹤來舉例,當找到一個程式臭蟲時,回報者將它輸入至系統裡,那麼它的狀態就會是「新的(New)」。接著,負責指派處理人員的負責人,會將它指派給應該要處理的人員,此時它的狀態就會進到「已指派(Assigned)」,而當要處理的人員開始處理時,它的狀態就應該被設至「開啟(Open)」。當處理人員「自認」修正好此問題時,即可將其狀態改至「已修正(Fixed)」。

這邊可能會有個誤解,就是當一個瑕疵被標示為「已修正」時,並不代表它的確被修正,是否真的修正了,需要測試人員進行複測。因此,當測試人員進行複測後,也認為的確修了,他便可將狀態標示為「已檢驗(Verified)」,等到他認為程式臭蟲的確不存在時,便可將其狀態標示為「已關閉(Closed)」。

不過,先前已關閉的瑕疵,也可能「再度被開啟(Reopen)」,因為,之後還是有可能發現問題仍然存在,在「再度被開啟」之後,又會回到「已指派」的狀態,繼續正常的處理流程。

這些狀態基本上就是我們用以追蹤每個議題的基礎,例如搜尋所有未關閉的議題,即可明白尚有多少待辦事宜。

優先程度與嚴重程度

「優先程度」代表被指派人員在處理所有待處理工作時,究竟應該先處理那些項目。原則上,應處理優先程度最高者,這使得處理人員在面對多個待辦事項時,對於處理它們的順序得以有所依據。而「嚴重程度」則代表這個議題究竟有多嚴重。要特別注意的是,嚴重不必然意謂著優先,優先程度代表規畫者的計畫安排,因此可能存在很嚴重、但不優先的項目。

使用議題追蹤系統時,要正確依據處理每個議題的情況,正確、即時標示每個議題的狀態。更重要的是,所有在專案過程中需要被完成的事項,都應一律送進此系統中追蹤,否則最後仍然憑藉其他途徑溝通,則此系統之使用則如同虛設。

最難的部分,往往在產生工作的管理階層人員,而處理人員應有堅持只處理在此系統中的工作,讓管理人員也養成習慣並享受到好處,便能建立起工作慣性。

作者簡介


Advertisement

更多 iThome相關內容