一千萬個為什麽

搜索

看板,搬回物品?或者你如何管理錯誤?

考慮到你有一個通過看板的功能,開發人員已經完成了它的工作,它已經被納入質量保證大綱,並且開發人員開始了新的工作。

質量檢查未能通過該項目。

怎麽辦?因為它已滿,您無法將其移回到開發流中。您無法將其移動到部署中,因為它無法正常工作。

它在哪裏?還是一路走到左邊去獲得高優先級的批準任務,進行分析以提取並添加任何細節,然後讓開發人員從那裏拉入?假設你的流程如下所示:

Backlog -> Start -> Analysis -> Dev -> QA -> Deployment -> Done

最佳答案

由於看板規則之一是明確制定策略,因此您應該明確流程中的“QA”階段意味著什麽以及它涵蓋哪些活動。常見方法之一是,這個階段包括測試和修復錯誤,這意味著在功能處於QA階段時,處理代碼是完全正常的,即修復錯誤。

當然,你也可以選擇一種獨立的方法,除非功能經過充分測試,並且決定是否好或不是代碼更改。但請註意,這種方法基本上會妨礙流程,因為您在測試/錯誤修復階段創建了正式的,可能是多個交接點。

因此,我的第一個建議是將您的QA階段視為涵蓋測試和錯誤修復的階段,這基本上會導致將索引卡移動到任何地方的問題都無關緊要。

另外,由於基本上你應該首先處理接近完成的特性,團隊成員應該首先處理它們在被測試的特性中所具有的任何缺陷,然後才轉向新特性。

註意:我不一定認為我們發現錯誤的功能應該被自動阻止。如果這是很常見的情況,我不會那樣做。如果過度使用阻滯劑,他們不再有那麽多的價值。另外,問題在於:當你只需要在那裏安裝幾個bug時,你是否真的需要將它視為緊急情況並聚集在一個功能上?

其他想法來處理這個問題:

  • 您可能會考慮移回卡片,但我個人不推薦。它只是增加了很多麻煩。你可以制定政策,在這種情況下你可以違反限制(如Siddhi所建議的),但我仍然認為它引入的混亂不值得你獲得的價值。

  • 您可能“停放”功能,未通過測試。你可能有專門的子列放置這些功能,所以每個人都知道他們需要修復bug。此外,您可以決定這些功能是否計入您的極限。 我在這裏寫了更多關於這種方法的文章

  • 您可能顯示測試狀態,例如測試開始,測試通過,測試失敗,並附加視覺信號,並將索引卡保存在QA列中。你可以得到與移動卡片相同的信息,但它不會給電路板帶來混亂。 我在此提及並描述了這種方法

  • 您可能使用其他信息散熱器處理錯誤,通常不是完整的看板。然後,再次,您將索引卡保留在QA階段,但您可以獨立處理錯誤。 Joakim Sunden分享整潔方法來處理這些任務

無論哪種方式,我的建議是從最簡單可行的方法開始,似乎可行。您可能既不想也不需要復雜的工具來解決問題,因此第一個想法是以一種使問題不存在的方式來定義過程。

順便說一下:質量保證來自質量保證,而不僅僅是質量保證階段的測試或QC(質量控制)。 請閱讀此處

轉載註明原文: 看板,搬回物品?或者你如何管理錯誤?