錯誤與增強與新功能的對比

Question

在計劃和優先考慮發行版中包含的內容時，您是否區分錯誤，功能增強功能和新功能？

例如，不要錯誤總是優先 - 你對新功能的工作之前解決所有已知的錯誤？您是否使用正式系統比較您的積壓中每次更改的成本與價值？如果是這樣，你是否使用相同的公式比較錯誤和功能？商業軟件與開源軟件還是企業內部軟件不同？

編輯：一些很好的回覆 - 謝謝。雖然我有一種先入爲主的觀點，即您需要對錯誤，功能和增強功能進行相同的處理，並根據每項成本/好處來選擇工作，但我認爲現實情況取決於您的情況。

Answer 1

這種選擇被稱爲分流，從急診部門，他們必須決定誰得到治療（有時，不幸的是，誰的生活和死亡）醫院的術語。

與所有業務決策，這是一個成本/效益問題。修復錯誤或添加功能有什麼好處？它會花費什麼（包括不做其他事情的機會成本）？

挑選那些以最低成本獲得最大收益的產品。你的目標是最大的降價。資源是有限的，慾望不是，資本主義的長期問題:-)

修復一個只有一個客戶經歷過的錯誤是毫無意義的，這個客戶永遠不會拋棄更多的重複業務，如果這意味着一個功能可以銷售數百個同時丟棄副本。

對於它的價值，我們的公司有要求的變化，客戶基本上可以投票選出他們希望在我們的產品的未來版本，看看有什麼數據庫。在數據庫中實際創建這些請求的更改僅限於銷售人員，因爲我們不希望所有類型的請求都顯示出來，而沒有經過評估和與客戶討論至少一點點。

此外，我們會定期與我們的最大客戶（產生的收入）進行比較，以確定應添加哪些功能（他們也可以自由提出自己的需求，也可以輸入數據庫 - 顯然投票權力取決於收入）。

這是我們的錯誤系統完全分離，雖然常常錯誤是提出這實際上是新的功能需求，他們正在跨運到新功能的數據庫。有可能這種情況甚至可能發生在被認爲影響較小或有適當解決方法的實際錯誤上。

Answer 2

我喜歡認爲，在所有情況下，錯誤修復應該總是在增強功能和新功能之前出現。即使特定的錯誤並沒有像開發人員那樣困擾你，但當你的小錯誤彈出時，某個地方的某個人正在毀掉他們的一天。

Answer 3

我們總是看看修復bug的成本與其造成的問題。有時候，每個錯誤都進行了適當的分類，造成根源，然後修復，這是不值得的。次特定的增強或新功能

大量被資助或至少強烈推薦由大/良好的客戶出現，這樣也影響的事項。

Answer 4

區分，是的。

錯誤優先，是的。

所有關鍵/正常優先級和以上錯誤首先，是的。

是的，80/20規則。

不，錯誤和功能必須區別對待，因爲它們的權重是不同的。

是的，所有商業，開源和內部應用程序都有自己的辦法。

作爲一個例子，FogBugz使用基於證據的調度，並且是我所知道的使用該公式的唯一管理/跟蹤器。

希望有幫助！

Answer 5

我們問我們的用戶。 我們有一個利基產品和一個小用戶羣。

嚴重的是，用戶組正在付費維護或考慮購買。

所以我們問他們他們想要什麼。

他們建議修復，要求提供新功能。

我們告訴他們關於發展的路線圖：因爲我們想要對產品做的事情， 由於時代變化，設計思路。法規變更。

如果每個客戶都說「我們真的需要功能X」，那麼它會接下來。

如果他們說「你們需要修復我在那裏點擊的錯誤，那麼它不會做錯誤：」然後那個錯誤得到修復。

商業軟件：與客戶投票的變化。 當然，我們會根據建議選擇他們的選擇：公司有其他想法的東西。

Answer 6

你必須從錯誤的角度來看它。展示瓶塞的缺陷始終是首要任務。如果人們無法登錄或者無法輸入或調整關鍵數據等，那麼這些數據必須優先於所有內容。

重要性較低的錯誤可以根據需要進行處理。我們可能會延遲修復一個bug，因爲我們知道我們正在爲下一週的增強工作做好準備。然後，錯誤修復將與增強功能一起進行。如果它很小，我們可能會延遲修復這個bug，並且計劃的增強將很快完成代碼。主要的增強可能會優先於修復界面上的一些拼寫錯誤。客戶可能會告訴我們，這個其他項目更加關鍵，並且在修復這個bug之前做到這一點（我們的軟件是客戶高度定製的）。這一切都取決於錯過的影響以及現有的計劃和企業政治，一旦你超過了展會的限制。一個困擾大客戶的錯誤可能會被優先考慮，即使它對開發者來說似乎很小。如果CEO現在想要修復它，與其餘工作量相比似乎並不重要，它現在已經得到修復。

Answer 7

對於錯誤，這非常簡單：如果您要修復它，請先修復它，然後再編寫更多代碼。爲什麼？您添加的代碼越多，現有的錯誤就越難找到。

如果您對錯誤從未被修復的想法沒有問題，可以通過所有方式對它進行分類並添加功能。

Answer 8

錯誤？我們沒有錯誤。他們是無證的功能。

對於我們來說，選擇總是基於商業決策，作爲開發者，除了提供我的意見之外，我沒有任何意見。通常情況下，功能會勝過bug，因爲增加功能「出現」到業務領域，例如正在取得進展，而我一年前可能修復的錯誤仍然存​​在，因爲業務部門只想看到「進度」。如果允許，分類很好，但在企業環境中常常會出現明顯的結果，而不是功能。

Answer 9

有一件事迄今爲止沒有提到bug的嚴重性。如果這個bug的嚴重程度很高（比如崩潰，無法通過持續時間測試，並且肯定取決於您使用的是哪種應用程序），那麼在添加新功能之前，您應該首先修復它。

Answer 10

The Joel Test: 12 Steps to Better Code的第5點提出了一個引人注目的論點（在我看來），在編寫新代碼之前修復錯誤是一個好主意。