您在Scrum中驗證了多少次任務？

Question

在我們的Scrum板上，任務從「待辦事項」開始，進入「進行中」，當您完成任務時，他們在「完成」之前轉到「驗證」。 「驗證」列是指完成任務後，其他人可以查看它，對其進行測試並對其進行評論。

這已被證明錯誤的幫助，更好的代碼等

要誰也有類似做法的人：後開發商已經解決的意見/錯誤，你再次驗證它，或者你假設的問題已解決並將任務移至「完成」？

我希望這是明確的，並希望聽到你的想法。

Answer 1

這個問題不是特定於Scrum，我也看到了敏捷過程之外的這個問題。

答案原來是：它取決於驗證中提出的問題。如果有小問題提出，並且負責的開發人員足夠高級，那麼請相信他第一次解決問題。但是如果進行驗證的人認爲這些項目太複雜，或者Scrum Master缺乏信任讓開發人員第二次正確使用這些項目的信心，那麼您將該項目移回到進行中。

你不打擾檢查錯誤的一個很好的例子是一個簡單的錯字。當存在許多相互依賴的邊界條件時，您將再次檢查的一個很好的例子是邊界條件中的誤差。

Answer 2

在我的期限中，bug的修復有50-75％的機會引入新的bug，特別是如果代碼沒有覆蓋測試用例。我肯定會再次驗證它。

Answer 3

從不假設問題被解決，直到它是獨立的（即不是由誰修理它的人）驗證。

Answer 4

我們沒有驗證列。一項任務正在進行中，直至已執行和測試。一個未經測試的任務不能完成，爲什麼其他人應該測試它，向程序員報告，然後程序員必須修復它？這隻會增加工作流程的延遲。程序員應該測試自己的代碼，儘可能編寫單元測試，並儘可能將其集成到應用程序中，並在此處測試它作爲自然工作流的一部分。這樣他就會發現自己的錯誤，並可以立即修復它們。當他將任務設置爲完成時，他不僅確信完成了任務，而且確保任務無缺陷。

好的，我們都知道，那意味着很少。有時候錯誤會在很晚以後發現，但這些錯誤並不是那麼明顯，通常它們的修復將成爲它自己的一項任務。

Answer 5

在我參與的項目中（敏捷和非敏捷），錯誤修復總是由其他人驗證。通常會引入新的錯誤，因此需要對修復進行一些探索。我甚至看到一些在構建中被遺忘的調試代碼 - 一切正常，但是額外的文件從無處出現。

它也有可能是開發者沒有找到所有錯誤的路徑，或者錯誤報告太不清楚以至於開發者做出了錯誤的修復 - 例如，如果某些東西被誤解了，並且正確的功能被報告爲一個錯誤。

爲了確保它們完成後仍然保持完好，修復測試也應該添加到您的自動化測試中，否則一些令人尷尬的角落錯誤將在幾個月後重新出現。