通過GreenHopper處理Scrum中的錯誤

Question

我們正在重新組織我們團隊的工作流程，其中一個關鍵決策是使用Scrum流程，並在Jira和Greenhopper的幫助下提供。

我已閱讀過各種Scrum指南，Greenhopper的文檔，並開始在我們團隊中實施Scrum流程。經過一些修正和改變後，它大多好，但有一件事情不讓我睡得很好：錯誤。

Different解決方案是proposeddevelopers，但我仍然無法在這裏找到我的方式。

在我們的工作流程的任何問題，住在4種狀態：打開 - >測試 - >解決 - >關閉

當開發商很滿意他的代碼，他把問題測試狀態，並自動分配給QA領導。 QA驗證問題，如果一切都是ok問題變成已解決。如果不是 - 再打開。在已解決狀態執行代碼審查，並且如果代碼是安全的，最佳的並且符合開發的結構，則問題變爲關閉。如果開發者做了某事錯了 - 再打開。

這裏棘手的部分是重新啓用的問題（故事），因爲在同一時間錯誤上調，其中土地產品積壓 - 而非短跑積壓，並且由於Scrum的路開發商可以」不需要處理衝突積壓的問題，但同時故事不能關閉，因爲代碼有問題或寫得不好。

所以，問題是：如果一個故事被關閉了，即使它有一些與之相關的bug，並且這些bug計劃在更多sprint中被修復？

或故事不能被關閉，直到所有相關的錯誤都被修復，這意味着如果衝刺完成了，但並非所有錯誤都是針對故事修復的，故事仍然打開，從完成的衝刺中排除並移動到下一個衝刺，所以它的故事點不會在完成衝刺中被燒燬？

Answer 1

在發生類似情況時，我們發現的一個關鍵事件是我們的故事中缺少（或缺陷）的是「完成定義」（DoD）。如果你有明確的「完成」標準，那麼當故事完成時（符合國防部），那麼它是完整的，當然這個訣竅就是如何定義一個好的定義，這個定義不是太模糊，確保高質量，每個人都同意，實際上是可行的。對我而言，這也不是一次練習，我們會在每次回顧中不斷重新審視它，以確保它們仍然相關並根據需要進行更改。關於建立一個好的國防部的想法嘗試Google，有很多很好的練習小組可以做定義它（如this one）。

至於什麼時候漏洞通過完成我會說他們應該反饋到產品待辦事項列表，並按照正常優先順序。在衝刺期間出現的與衝刺工作相關的錯誤應該在衝刺中修復（避免管理員/文書工作！）。還記得很多錯誤（或者錯誤數量越來越多）通常意味着質量有問題，也許還有更大的問題需要處理（可能要完成的壓力太大了？）。

總結一下，看看獲得一個堅實的國防部（鼓勵質量超過數量）並不斷改進它，放慢速度，做得更好，而不是更多的「有缺陷」，當出現錯誤時，將它們反饋回積壓產品並讓PO儘快優先考慮。

作爲一個方面說明，我們發現，當涉及到處理大量的錯誤時，像Kanban這樣的更精益的方法比我們的Scrum流程的每週2次迭代方法工作得更好。

希望這會幫助嗎？