內部開發團隊問題跟蹤

Question

我們有一個標準的問題跟蹤系統，以跟蹤最終用戶和項目管理角度的缺陷/增強。但是，我們還需要跟蹤內部團隊的缺陷，這些缺陷可能包括重構代碼的某些部分或更改應用程序中最終用戶沒有任何交互作用的內容。

在同一跟蹤系統中最好跟蹤這些缺陷和增強功能嗎？我對此的保留是，看到用戶缺陷的項目經理會被這些內部請求所困惑，並且會引起不必要的關注。我們是否僅僅爲內部團隊使用而建立另一個缺陷跟蹤系統？

Answer 1

更少的系統（幾乎）總是更好，除非您享受額外的管理工作，以消除編碼時間。

我喜歡Pivotal Tracker分離出來的方式，以避免您所說的混淆，並保持對客戶的關注。用戶缺陷是「錯誤」，沒有明顯客戶利益的內部項目是「雜事」，並且在許多視圖中不顯示，因爲它們不提供客戶價值（沒有用戶故事與它）。

因此，我認爲大多數問題追蹤者都有辦法打破問題類型，我會單獨從bug中分離出「償還技術債務」問題。

您可能還想考慮爲什麼你要着手項目經理不知道的任務。您可能只需要以更清楚的方式來重新說明這些任務需要完成的原因。因此，而不是「重構用戶身份驗證」可能是「增加用戶登錄系統的可維護性」，或任務的任何基本目標。

很顯然，每項技術任務都需要提供商業價值並思考它究竟傳達了什麼（除了「我的代碼更優雅」之外）可能是一個很好的練習。