而Agile與Scrum,對我來說就像心法與功法,舉例來說我們公司說我們是採用Agile(敏捷式開發門派),主要依循的是Scrum與XP,不過套句Ken Schwaber 的話來說:
也就是說Scrum不像CMMI和PMP有很清楚的規範和SOP,他只有一個建議的運行準則,以及靠著實戰中不斷累積的經驗分享,這也是Scrum 的強處和痛苦的地方,就是你被迫需要根據你的團隊特殊的狀況,來進行調整,不是像拿到一本武功秘笈,照表操課就就會練成絕世武功,而且走火入魔的機率還很大~:PScrum不是一個方法學,它是一個框架(Framework) 。
此外通常在採用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] 覺得這個影片也很具代表性
沒有留言 :
張貼留言