第九章 處理程式的錯誤 (1)
摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 9 Handling Bugs
在我們採用Kanban之前, 我們使用傳統的方式來對待程式的錯誤(bugs). 測試人員在開發周期的最後, 才開始進行system test, 並且記錄到bug tracking system中. 最後才進行測試的時間 = Final System Test time + Bug fixing time
通常bug tracking system內紀錄了好幾百條bugs, 並且每周需要朝開會議, 來分析錯誤狀況, 決定優先順序, 並且指派給開發人員. 這個過程還蠻無聊, 沒有效率的, 重點是大家都需要參加.
在Kanban中我們持續進行system test, 而不是在開發後期才做測試, 也就是週期性地每隔一段時間就進行system test. 一開始的時候測試人員很反對, 認為這樣很花時間並且很沒有效率.
事實上這是一種錯覺, 因為當你加上解bug的時間, 你就會發現之前的做法是非常沒有效率的.
[註: 這個bug fixing time通常會花很長很長的時間]
週期性進行測試的時間 = 每次(System Test time + bug fixing time)的總和.
[註: 因為週期性進行測試, 整體測試時間有變長, 但是修復錯誤時間的總和遠比最後才測試所需的時間少]
此外, 另一個關鍵的因素是測試自動化. 我們雖然沒有對所有東西進行測試自動化, 但是我們會盡我們所能地將測試給自動化. 因為回歸測試會進行很多次, 若我們能多些自動化, 會幫我們省下一些時間.
因為我們在feature team內有專職的測試人員, 所以通常我們都知道這個錯誤要指派給哪個開發人員. 如果真的不知道, 可以先給開發人員的組長, 讓他指派給適當的人選.
所以開發人員和測試人員會坐在一起, 一起討論和解決這個錯誤. 可以讓我們沒有交接的問題, 也不會有太多延遲, 更不用花太多時間在tracking system上的往返. 因此有以下好處:
立即修復錯誤
現在當測試人員找到錯誤時, 我們不會把它紀錄到bug tracking system. 取而代之地, 我們針對這個錯誤貼一張粉紅色的便利貼到白板上, 並且告訴開發人員要去解決它.
(1) 在早期發現和修復錯誤, 會比在晚期更有效率.
(2) 面對面的溝通, 會比文件上(指在bug tracking system上的往返)的溝通更有效率
(3) 開發和測試人員可以在對方身上學習到更多事情
(4) 較少時間花在處理大量的錯誤清單, 因為每次的量不至於太多
為什麼我們要限制bug tracking system中錯誤的個數
以前我們沒有用Kanban時, 大約有幾百個錯誤在tracking system中. 現在我們限制個數在30個. 以下是我們處理的流程:
當我們找到錯誤時, 會問這是否會阻擋我們的測試或是開發?
(1) 會
就立即增加一張便利貼到白板, 要求開發人員要馬上處理, 不要把它放到待處理的事項中.
(2) 不會
會不會比目前tracking system 中其他30 個還重要?
(a) 會
加入到tracking system中, 並且將最不重要的那個移走
(b) 不會
我們會忽略這個錯誤.
以這樣的方式, 我們可以將精神放在重要的錯誤上面, 不會造成太多管理上的負擔
視覺化找到的錯誤
在第八章中, 我們將Next Ten Features這欄位拆成平行的兩個子欄位, 一個是給原先的features, 另一個是tech stories來放. 現在再增加一個平行子欄位: Next Five Bugs. 我們會用紅色簽字筆來描寫便利貼的內容, 讓人家一看到就知道這一一個修復錯誤的工作項目.
這些用紅色簽字筆寫的便利貼, 不會比粉紅色的便利貼(就是前面說要立即處理的錯誤)重要. 但是它們也算重要的錯誤, 所以會放在Next Five Bugs欄位中等待處理.
當feature team有空時, 他們便要討論要從Next Ten Features, Next five Tech Stories和Next Five Bugs中, 去挑選一個工作來處理.
限制bug tracking system中錯誤的個數, 可以帶來許多好處. 雖然錯誤的列表很短, 但是這些東西能很快被處理, 而不會擺上好幾個月. 如果這些錯誤無法被處理, 一開始我們就會誠實以對, 而不是讓人家有錯誤的期待.
或許這而不是很理想的處理方式, 但是我們還是會持續改進, 讓錯誤的處理狀態可以容易被視覺化.
留言列表
