2012年6月15日 星期五

沒有搭配工具與方法的敏捷式開發?(Running Agile without specific methodology and Tools ? )

太極
軟體開發也許就像練太極拳一樣,最後的境界就是無招勝有招,但是在達到這個境界之前,我們一般人還是得先找位大師加入個門派拜師學藝,按照其心法與招式來好好練功,但是師父領進門修行在個人,所以在這段期間一定會遭遇挫折,會遇到瓶頸,你會懷疑,可能也會灰心,不過也就是痛過才更容易對那些心法有所領悟,也才有辦法跨越,這是沒有任何捷徑的,除非你是萬中無一的練武奇才。


而Agile與Scrum,對我來說就像心法與功法,舉例來說我們公司說我們是採用Agile(敏捷式開發門派),主要依循的是Scrum與XP,不過套句Ken Schwaber 的話來說:

Scrum不是一個方法學,它是一個框架(Framework) 。

也就是說Scrum不像CMMI和PMP有很清楚的規範和SOP,他只有一個建議的運行準則,以及靠著實戰中不斷累積的經驗分享,這也是Scrum 的強處和痛苦的地方,就是你被迫需要根據你的團隊特殊的狀況,來進行調整,不是像拿到一本武功秘笈,照表操課就就會練成絕世武功,而且走火入魔的機率還很大~:P


此外通常在採用Agile與實行Scrum,根據許多前輩的經驗通常還會再搭配一些methodlogy和機制,例如TDD[1]、Build Automation、CI [2]、pair programming...等。這時候就有幾個問題出現了,到底是因為你要採用Agile才需要搭配這些methodlogy?還是這些本來就是軟體開發專案就該採用的方法?如果我今天不是採用Agile還需要使用這些方法嘛?

這幾個問題讓我想到,剛好在前一陣子ptt Soft_job版有個網友轉貼他的Blog"[心得] 為什麼軟體開發者需要在意軟體品質指標",引起熱烈的討論(戰的很厲害), 從一開始在討論為什麼要注意軟體品質,到後來戰火一路延燒,論戰的內容大略如下:
  • Test Case的定以與必要性
  • Unit Test是否有其必要性與功用
  • Test Automation(自動化測試)到底有啥益處
  • 到最常見的,寫程式都來不及了幹嘛要用TDD
也讓很多高手前輩浮出水面來討論(我承認我很孬,又怕戰,所以就沒在上面加入筆戰討論),我只敢在這邊小聲的說說自己的想法,個人覺得這些機制和方法就像一個保護傘,你不用他當然還是有可能順利的完成案子(而且就我的經驗,可能都是一些一兩個人開發的小案子),你用了當然也不能就保證你的案子就不會失敗,但是至少大大了提高勝率與降低失敗的風險,此話怎講!?

舉例來說,現在很難想像一間軟體公司沒有使用版本控管系統(不管是SVN、Git、Hg...等),沒有issue tracking 系統,但是對於那種一兩個人開發的小專案,的確可能不需要版本控管,反正都存在你電腦裡,最多用時間分檔案資料夾;也可能不需要所謂issue tracking 系統,一切就靠email往來記錄;如果你一時興起要重構程式,就直接改,反正也不用跟其他人co-work.....所以當你小的時候,人少的時候,你的確什麼方法都不用考慮也可以過的好好,只要能交出東西就好。但是隨著系統越來越龐大,參與的人越來越多,你敢不用版本控管系統嘛?你能沒有issue tracking 系統嘛?再沒有寫足夠的unit test的狀況下,你敢任意重構系統嘛?或去改別人的Bug嘛?(通常只會越改越多Bug,越補越大洞)。

一般專案開發是如此,採用Agile更是如此,因為你會遇到更常變更的需求,更頻繁的Release和Demo,一旦當你release的頻率越來越頻繁,你不加入CI以及Test Automation的機制,我想你應該就會越聽到以下的抱怨,引自"程式設計師最常說的藉口":

第 20 名:這很奇怪喔。
第 19 名:以前從來不會這樣啊! (有做版本控管嘛?有用CI做Regression testing嘛?)
第 18 名:昨天明明會動的啊!     (有做版本控管嘛?有用CI做Regression testing嘛?)
第 17 名:怎麼可能~
第 16 名:這一定是機器的問題。 (有用放在CI上Build過然後deploy到測試環境嘛?)
第 15 名:你到底是打了什麼才讓程式當掉的?(請記錄在Issue Tracking,補入Test Case)
第 14 名:一定是你的資料有問題。
第 13 名:我已經好幾個禮拜沒碰那一段程式了。
第 12 名:你一定是用到舊版了。 (有做版本控管嘛?有用CI做Regression testing嘛?)
第 11 名:一定是巧合!為什麼這種壞運氣只讓你碰上。
第 10 名:我不可能什麼功能都測試到吧,有 bug 是正常的! (這倒是真的~XD)
第 9 名:這個不可能是那個的原始碼!
第 8 名:這程式應該是會動的,只是我寫好後還沒做測試。 (有用放在CI上Build過嘛!?)
第 7 名:可惡!一定有人改了我的程式。 (有做版本控管嘛?)
第 6 名:你有檢查過你的電腦有沒有病毒嗎?
第 5 名:儘管這功能還不能動啦,你覺得他如何?
第 4 名:在你的系統不能用那一個版本的程式啦!
第 3 名:你幹嘛要那樣操作,都是你的問題。(請記錄在Issue Tracking,補入Test Case)
第 2 名:程式發生問題時你在哪裡?
第 1 名:在我的機器明明就可以動啊!(有用放在CI上Build過然後deploy到測試環境嘛?)

說真的很多風險和愚蠢的Bug都是不應該發生,是可以被避免的。

不過話說回來很多時候也不是工程師不做,而是不知道可以這樣做,或是不知道這樣做的好處,如果上頭又只是出張嘴說,好我們今天要推行TDD,但是沒有配套的工具和教育訓練,當然工程師一定會反彈,因為可能會增加他的工作量。

剛好這幾天在找資料,看到一篇文章"Bootstrapping an agile project with continuous deployment using cloudbees",裡面有一個26min的影片,看完後除了深深佩服Henrik Kniberg [3] 行雲流水般的Coding能力外,最感到興趣的就是他Demo的那套系統" CloudBees",這套系統許多的開發流程會需要用到的工具都整合在一起了,有興趣的人可以進去看一下影片,並且可以試著去了解這些工具如何幫助到自己的日常開發。


 Source:collabNet
 

如果覺得有用,或是有幫助,就可以試著在自己的公司與組織內導入這些系統和機制,自己當第一個願意嘗試的人,分享給大家,很多時候不要只是會抱怨環境和組織有多爛,都沒有人願意改變和嘗試,因為你也是這個環境和組織的一份子 ,你罵這個環境或組織爛,也就是罵到自己~:P


Reference:
[1] TDD - Test-driven development
[2] CI - Continuous Integration and Delivery
[3] Henrik Kniberg, Scrum and XP from the Trenches的作者

Update [2012.06.20] 覺得這個影片也很具代表性
張貼留言