敏捷開發中應該使用那些敏捷工具

　　敏捷軟件開發絕不再是一個新名詞了，但理解還是時時有偏差。敏捷宣言中的第一條“個體和互動高于流程和工具”，有人就誤讀為“有了溝通，一切都迎刃而解” ，因此花費大量精力整頓團隊合作，卻輕視了工具(技術)。其實宣言中的意思只是想強調個人和溝通更重要而已。

　　實際上，既然是軟件開發，在所難免得面臨工具的選擇，而且很多優秀軟件實踐離開強有力的工具支持都玩不轉。在如今的軟件開發世界中，工具(這里談的是軟件工具)層出不窮，數不勝數，那么到底該怎么去選擇適合的工具呢?

　　本文將根據我十幾年的企業級軟件開發經驗給出一點建議，和大家一起來探討敏捷和工具(特別是在企業實施中的工具)這個話題。

　　為了避免不必要的麻煩，文中盡量用開源軟件作為介紹，但這并不是說我排斥商業軟件，恰恰相反，在很多時候，只有商業軟件才提供了你需要的功能(當然大部分情況下開源軟件會很快迎頭趕上)。

　　背景知識：應用程序生命周期管理

　　聊到軟件開發中的工具，一般都會提到這個術語“應用程序生命周期管理(Application Lifecycle Management ，ALM)” ，說句老實話，有點爛，誰都想把自己往上靠，誰都有自己的一套說法，圖1為我心中貫穿企業開發項目全程的ALM全局觀。

　　圖1中列出了ALM中的各個子系統，以及我略有研究的相對應工具的名稱，讓我們一起先來簡單地過一遍整個過程。

　　圖1 開發項目中應用程序生命周期管理及其工具

　　產品開發始于一定的需求，需求有好幾個層次，從產品需求到項目需求，進而產生出用戶故事(User Story)， 然后團隊會分解出任務(Task)。團隊開發者利用IDE(如Eclipse)去完成相應的代碼，單元測試完成后，再推送到代碼庫(git)，這些和軟件配置管理(Software Configuration Management，SCM)相關。

　　構建系統會從代碼庫中獲取最新的代碼，進行編譯、打包、功能測試和系統測試，可以設置在質量系統中顯示一些相關信息，如果一切順利，甚至能直接上傳到在線系統更新上線。此外不管是開發中還是運行中一般還都會有一個缺陷管理系統。

　　BugZilla大家應該很熟悉了，用Redmine的人少一些，但它實際上是一個非常靈活的項目管理系統，國內也有越來越多的公司在使用了，Nexus是一個Java軟件包的管理工具，需要和Maven結合使用，Sonar是一個Java項目的質量控制工具，它集成了如單元測試、覆蓋率、靜態質量檢查等內容。為什么任務管理下的Redmine有紅叉呢?我們稍后會解釋。

　　限于篇幅，本文只會談到其中的一部分工具。作為參考，可以閱讀Manning出版社的新書《Agile ALM》，它對SCM、單元測試、功能測試等話題進行了更深入的探討。

　　敏捷中有些工具是必需的

　　如果你說敏捷實施大半年了，但持續集成 (Continuous Integration，CI)服務器卻還沒有架起來，那我實在是不曉得你都在敏捷些啥東西了。無論你究竟“信仰”哪種敏捷，產品開發各個方面的自動化(Automation)和持續集成都必不可少。要了解持續集成，可以看看Martin Fowler的文章，可謂白皮書級別的經典，有中文翻譯版。

　　使用CI就一定會用到CI服務器，可選的有很多，其中Jenkins是現在最流行的一個，而且架設起來也很方便。它是從Hudson繼承而來(自從2011年5月Oracle決定把Hudson捐獻給Eclipse組織，兩者的關系和將來的發展方向也可能帶來更多變數)。

　　在Jenkins構建服務器中，可以定義任務(在Jenkins中叫job)，以完成一些構建步驟(如簽出代碼、編譯、各種類型的測試、打包等)，它有極豐富的插件(plugin)資源作為支撐，可以來集成產品軟件開發的各個要素，它把你所需要的一切都自動化起來。

　　圖2 Jenkins項目自己的Jenkins構建服務器

　　在Jenkins構建服務器的首頁，每個任務還都有一個天氣圖標表示其狀態，非常直觀，例如“太陽”就代表著一切正常(至少從構建結果來看)。它是產品項目開發的晴雨表，項目狀態是否正常一目了然。不管是對Jenkins不了解還是想提高，我強烈推薦閱讀John Ferguson Smart的Jenkins開源書：Jenkins: The Definitive Guide。

　　對敏捷來說，并沒有“CI服務器要還是不要”一說，它就是必須的，一定要好好地實施?；诔掷m集成再往前走，就是持續交付(Continuous Delivery)了，這也是敏捷的一個新熱點，其中加入了很多新元素(如自動化驗收測試、持續部署等)。

　　別讓工具牽著鼻子走

　　工具很重要，但會不會有些誤區呢?當然有，我們一起來看個我經常碰到的一個例子。

　　講到敏捷實施一直都會提到白板(Whiteboard)的使用，先得提醒大家，它也是一個“工具” ，白板的其中一種用法叫任務白板，主要是提供給團隊使用的。

　　圖3 每日例會用的任務白板(圖來自《硝煙中的Scrum和XP 》一書)

　　圖3就是常見的任務白板，團隊的需求，一般是用戶故事(User Story)，被放在最左邊一欄“NOT CHECKED OUT”，作為團隊一個迭代的輸入，然后分解成任務(Task)用報事貼(俗稱黃貼)貼在白板上“CHECKED OUT”那一欄，并簽上自己的名字，就算是領任務啦。當做完了一個任務就把它(黃貼)挪到下一欄“DONE!:o)”，代表做完了，最右邊一般還會留出部分空間，用來記錄進度條和注意事項來提醒團隊一些重要的事情。

　　如果說Jenkins構建服務器是產品開發的晴雨表，那么任務白板就是團隊開發的晴雨表。

　　一般一大早在每日的站立會議(Daily Standup Meeting)上，整個團隊所有人都會圍在白板前，分享所負責任務的進度，順便挪動一下任務到相應的狀態欄，用這種方式能夠減少很多不必要的匯報型會議，而且團隊成員也能很快地了解開發的整體狀況。相信如果某個黃貼在白板上連著三天都沒動，團隊里一定會有人站出來幫忙的。(沒有?!那還是先組織他們參加團隊合作的培訓吧。)

原文轉自：http://www.kjueaiud.com