沒有搭配工具與方法的敏捷式開發？(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] 覺得這個影片也很具代表性