l

2012年3月1日 星期四

戴上腳鐐去賽跑

March 01 10:35~11:58

image

 

有一陣子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團隊中,而不是指跨部門的合作,這一點不要搞錯了,否則絕世武功練一練不小心又要走火入魔了。

***

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

2 則留言:

  1. 中肯,感覺有太多型式上的東西把效率變低了
    而且人性很大的成份是依賴於工具
    反而使小事變得複雜了

    如果有必要作很久,或不確定的東西
    我認為可以放到issue tracking的系統
    但實際上來說,作紀錄是很OK的
    但不用正式到那種地步,還要很正規寫得很完整
    真的要寫得很完整的,應該都是大問題

    issue tracking應該是必要的,但是不是以他為核心:左手只是輔助(無誤)

    回覆刪除
  2. 個人覺得issue track system,是把事情發生的前因後果記錄下來,為什麼會有這個bug?,當初的設計是怎麼想的?為什麼要這樣解?

    回覆刪除