您會使用錯誤跟蹤器來跟蹤最初的需求開發嗎？

Question

想象一下，我將每個需求作爲我的錯誤追蹤器中的一項功能。這會是一個好主意嗎？有更好的工具嗎？

Answer 1

我會說這絕對是一個好主意，因爲您可以很容易地跟蹤後來的需求和想法。您還可以輕鬆跟蹤您的進度，時間估計，花費的時間等。

Answer 2

這就是我和很多人所做的。將規格說成是錯誤，然後在完成功能時解決錯誤。

它是評估解決錯誤與添加新功能的相對優先級的好方法。在某種程度上，一個空的項目已經有了很多的bug，因爲它不會做什麼！

Answer 3

Bugtracking就是關閉條目。產品/需求管理是關於讓他們活着。

順便說一句 - 一些錯誤跟蹤系統支持需求管理，但這不是一回事。

Answer 4

一般來說，我認爲使用這樣的跟蹤系統來管理項目效果很好。

重要的部分是，你想把可操作的項目放到你的數據庫中 - 如果這個需求不直接轉化爲你想要實現的代碼/高級設計，那麼只列出需求是沒有幫助的。所以，對於一個需求，我可能會輸入一個問題來將需求分解成要素，產生新的記錄來實現這些要素。

Answer 5

我們這樣做 - 我們將Marketing Requirements Document(MRD)開發的Work Breakdown Structure (WBS)轉移到bug跟蹤器中。然後，我們可以跟蹤/監測個別工作項目的進展情況。缺點是你有兩個潛在的需求定義，但對於像我們這樣的小團隊來說，這並不是問題。

我們曾嘗試過一次只跟蹤錯誤跟蹤器，但當我們需要將它交給外部用戶和/或非技術用戶時，我們很難重新構建完整的文檔。

Answer 6

這取決於您的需求跟蹤需求可能有多複雜。完整的需求跟蹤系統將支持多個級別的子需求，並可能與其他項目管理工具集成。如果項目簡單並且您的需求不那麼複雜，那麼您可以輕鬆使用錯誤跟蹤器。

Answer 7

Bug Tracker是針對缺陷，包括文檔。跟蹤需求文檔中的缺陷對於跟蹤軟件缺陷來說同樣重要。越早發現缺陷就越便宜。

對於最初的功能需求，我只會生成一個單獨的跟蹤器，如購物清單。由於它們已被列入清單，請覈對該項目。

我對inital soapbox表示歉意，但很多人忘記文檔也可能有缺陷，而不僅僅是軟件。