議題追蹤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

編號

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

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

標題

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

內容敘述

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

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

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

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

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

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

狀態

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

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

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

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

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

優先程度與嚴重程度

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

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

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