如何在Agile/Scrum專案中處理Bugs
Coping with Bugs on an Agile/Scrum Project
http://www.infoq.com/news/2009/07/coping-with-bugs
Jul 15, 2009
Posted by Mark Levison
一個經常被問到的問題是: 在Scrum中如何去處理bugs? 應該要把他們放到產品的backlog中? 還是只是一個單獨的bug list? 如果他們是在產品的backlog, 是要由產品負責人指定優先順序, 還是他們自動就是最重要的項目? 還是應該另外有一個bug fixing的Sprint?
在Pascal Maugeri的團隊, 即使他們已經改進Dod(Defintion Of Done)的定義, 並且加入"適當的測試/單元測試", 他們仍然在sprint完後發現bug. 他詢問要如何解決這個問題.
George Dinwiddie, Agile的教練, 建議在回顧會議中提出這個問題.
Mark Levison 建議"我開始問他們為什麼當發現時, 無法在這個sprint中修復完畢? 我的重點是要減少發現和修復問題的時間. 如果我們發現在sprint中一個故事的bug, 產品負責人不應該接受它已經做完. 此外, 越早發現應該會越容易去修復, 因為開發團隊那時候比較記得他們寫的程式是什麼"
Jim Schiel, CST with Artisan Consulting 只是把他們的bug放到產品backlog中, 並且由產品負責人來決定優先順序. - "除非它是很容易去修復, 在這種狀況下, 你可以直接在sprint規劃會議中決定解法, 然後在sprint過程中執行這個解法"
Bruce Kantelis說這些都是和團隊所發展的文化有關: "我們把defect分類. P1, 會阻擋使用者工作的, 馬上立即處理, 並且盡快發佈patch 或 hot fix. 其它的defect則當成是要做的故事, 被放在下一個sprint的working list中. 隨著時間的演進, 團隊會體認到, 有沒有質量的行為, 會影響他們的工作以及被中斷的狀況"
Mike Cohn提醒我們, 在sprint中, 找到的bug時最好的處理方法是, 大聲嚷嚷讓團隊知道, 並且描述出了什麼問題. 或者是用一張卡片來描述他, 並且放到牆壁上. 但是若是在sprint完後發現bug, 他建議最好是加到產品的backlog, 讓產品負責人去排定優先順序. 許多團隊仍然有使用bug tracking system去紀錄bug, 他認為是可以繼續使用的. 在這樣狀況下, 他認為bug是放在分開的bug backlog, 也就是use stories有一個backlog, bug 有一個backlog. 產品負責人各自在backlog上排定優先順序.
Kevlin Henney 對這樣的方法有點爭議, 好像是把bug視為一個具有負的值的功能(通常你做完一個功能, 會得到一些分數. 在此若有一個bug, 便會扣一些分數), 以下是他的想法:
If defects are viewed as features with negative value, they become managed as if they were features. Development groups store up prioritized repositories of bugs, treat bugs as user stories, outsource the fixing of bugs, and so on. While each of those can be a useful technique or perspective in dealing with a project in transition or crisis, it is not a long-term view that should be encouraged. After all, as the "Manifesto for Agile Software Development" says, "Working software is the primary measure of progress." It is a little disingenuous to pass off a feature with known defects as complete and working — "Yes, it's done... but there are a few bugs."
留言列表
