戴上腳鐐去賽跑

March 01 10:35~11:58

 

有一陣子Teddy很熱衷於issue tracking system，把每一個sprint中團隊所找到的bugs或是issues都打到issue tracking system中，並且詳細敘述產生bugs的步驟與發生問題的畫面，以便於開發人員日後要修改bugs時有所依據。實施了一陣子之後Teddy覺得有點不對勁，那裡不對勁？

• 有時候要很詳細地把一個bug打入issue tracking system中可能要花15-30分鐘，但是搞不好修這個bug還不用10分鐘，到底是要把這個bug打到系統中還是直接找人修掉比較合適呢？
• 當issue tracking system裡面有5個bugs的時候，開發團隊可能會有一種想要趕快把這些bugs修完的動力。但是，如果issue tracking system裡面有50個，甚至是500個bugs呢，還有人會去關心這些bugs嗎？

後來Teddy忘了是看了那本書還是那篇文章，提到「一個好的敏捷團隊根本不需要使用issue tracking system」這樣的「邪說」。什麼，軟工的書不是都有介紹開發軟體應該要使用issue tracking system的嗎，為什麼有人會建議敏捷團隊不需要使用issue tracking system？

這當然又牽涉到「叔叔有練過，小朋友不要學」的這句老話。那篇文章的作者認為，一個好的敏捷團隊會有很低的bug rate（或是應該要朝向這個目標邁進），一旦在sprint當中發現任何bug就立刻改掉，所以根本不需要用一個「系統」來追蹤這些bugs。況且一旦使用了issue tracking system之後，團隊會有一種「找到問題只要把它打入系統就沒事了，反正以後有時間再慢慢處理就好了」的心態。至於這個「以後」是什麼時候，大概是未來從來不會發生的某個時間點吧。所以搞到最後的結果就是bugs/issues越積越多，變成一座垃圾山…XD。

Teddy讀了這篇文章之後也覺得滿有道理的，在Scrum的框架中，已經有Daily Scrum讓開發人員回報問題，還有平常開發軟體的活動中只要一發現bugs就要想辦法立即處理。Sprint Demo和Retrpspective Meeting也都可以討論bugs或是issues。所以回歸到敏捷宣言的第一條：

Individuals and interactions over processes and tools

不久之後Teddy就把原本幫團隊導入的issue tracking system給廢棄不用了。

***

看到這邊鄉民們一定會問，那不用issue tracking system發現了bugs或是暫時無法處裡的issues該怎麼辦？很簡單：

• 在每個sprint開發過程中，只要有人發現bug，就要想辦法在這個sprint把發現的bug解掉。
• 如果發現的bug或是issue牽涉因素太廣，修復時間太長，則把這個bug打到product backlog中，排定優先順序，留待之後的sprint來修復。如果這是一個很嚴重的bug/issue，通常下個sprint就會被挑進來施工，所以也不會在product backlog中停留太久。如果真的在product backlog中停留太久，那麼就代表這的bug/issue不是那麼重要或是不太急迫，所以也可以放心地繼續擺在product backlog中（當然還有一個可能就是Product Owner太混，這邊就不討論了…XD）。

自從拿掉了issue tracking system之後，Teddy覺得團隊的開發反而變得更順暢。一旦有人發現任何bug，就會馬上用MSN或是Skype通知所有專案中的開發人員，並徵求大家去「認養 認領」這個bug。在大部分的情況，這種模式運作得很好，而且發現的bugs也都被妥善地處裡。

***

所謂盡信書不如無書，雖然軟工的書告訴大家要使用issue tracking system，但是並沒有說明一個敏捷團隊應該如何使用或是看待issue tracking system。Teddy自己也是費了一番功夫才找到一個自己認為合適的方法。如果當初Teddy還「傻傻地執迷不悟」繼續把所有發現的bugs都打到issue tracking system，那麼Teddy勢必要把自己「寶貴的時間…XD」拿來做一些CP值不是很高的事情（輸入詳細的bugs發生步驟與擷取畫面），反而沒有時間把心思花在如何改善開發流程上面。這種感覺就好像先把自己腿上綁上腳鐐再去跟人家賽跑一樣。要跑贏，很難。

看到這邊鄉民們不要以為Teddy完全反對使用issue tracking system，這樣的系統還是有存在的必要。像是公司裡面QA部門測試鄉民們所開發的軟體時，就必須要把發現的問題詳細的打到issue tracking system，這樣子開發團隊才知道有那些問題需要處裡。前面Teddy所說不需要使用issue tracking system是指在同一個Scrum團隊中，而不是指跨部門的合作，這一點不要搞錯了，否則絕世武功練一練不小心又要走火入魔了。

***

友藏內心獨白：遇到問題時，應該思考這個問題是不是真的是一個問題。