敏捷軟件開發絕不再是一個新名詞了，但理解還是時時有偏差。敏捷宣言中的第一條“個體和互動高於流程和工具”，有人就誤讀為“有了溝通，一切都迎刃而解” ，因此花費大量精力整頓團隊合作，卻輕視了工具（技術）。其實宣言中的意思只是想強調個人和溝通更重要而已。
實際上，既然是軟件開發，在所難免得面臨工具的選擇，而且很多優秀軟件實踐離開強有力的工具支持都玩不轉。在如今的軟件開發世界中，工具（這里談的是軟件工具）層出不窮，數不勝數，那么到底該怎么去選擇適合的工具呢？
本文將根據我十幾年的企業級軟件開發經驗給出一點建議，和大家一起來探討敏捷和工具（特別是在企業實施中的工具）這個話題。
為了避免不必要的麻煩，文中盡量用開源軟件作為介紹，但這並不是說我排斥商業軟件，恰恰相反，在很多時候，只有商業軟件才提供了你需要的功能（當然大部分情況下開源軟件會很快迎頭趕上）。
背景知識：應用程序生命周期管理
聊到軟件開發中的工具，一般都會提到這個術語“應用程序生命周期管理（Application Lifecycle Management ，ALM）” ，說句老實話，有點爛，誰都想把自己往上靠，誰都有自己的一套說法，圖1為我心中貫穿企業開發項目全程的ALM全局觀。
圖1中列出了ALM中的各個子系統，以及我略有研究的相對應工具的名稱，讓我們一起先來簡單地過一遍整個過程。
圖1 開發項目中應用程序生命周期管理及其工具
產品開發始於一定的需求，需求有好幾個層次，從產品需求到項目需求，進而產生出用戶故事（User Story）， 然后團隊會分解出任務（Task）。團隊開發者利用IDE（如Eclipse）去完成相應的代碼，單元測試完成后，再推送到代碼庫（git），這些和軟件配置管理（Software Configuration Management，SCM）相關。
構建系統會從代碼庫中獲取最新的代碼，進行編譯、打包、功能測試和系統測試，可以設置在質量系統中顯示一些相關信息，如果一切順利，甚至能直接上傳到在線系統更新上線。此外不管是開發中還是運行中一般還都會有一個缺陷管理系統。
BugZilla大家應該很熟悉了，用Redmine的人少一些，國內也有越來越多的公司在使用leangoo，很好用的一個敏捷協作軟件，在線的高效看板協作。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服務器要還是不要”一說，它就是必須的，一定要好好地實施。基於持續集成再往前走，就是持續交付（Continuous Delivery）了，這也是敏捷的一個新熱點，其中加入了很多新元素（如自動化驗收測試、持續部署等）。
別讓工具牽着鼻子走
工具很重要，但會不會有些誤區呢？當然有，我們一起來看個我經常碰到的一個例子。
講到敏捷實施一直都會提到白板（Whiteboard）的使用，先得提醒大家，它也是一個“工具” （現在可以用leangoo，在線看板），白板的其中一種用法叫任務白板，主要是提供給團隊使用的。
圖3 每日例會用的任務白板（圖來自《硝煙中的Scrum和XP 》一書）
圖3就是常見的任務白板，團隊的需求，一般是用戶故事（User Story），被放在最左邊一欄“NOT CHECKED OUT”，作為團隊一個迭代的輸入，然后分解成任務（Task）用報事貼（俗稱黃貼）貼在白板上“CHECKED OUT”那一欄，並簽上自己的名字，就算是領任務啦。當做完了一個任務就把它（黃貼）挪到下一欄“DONE！:o)”，代表做完了，最右邊一般還會留出部分空間，用來記錄進度條和注意事項來提醒團隊一些重要的事情。
如果說Jenkins構建服務器是產品開發的晴雨表，那么任務白板就是團隊開發的晴雨表。
一般一大早在每日的站立會議（Daily Standup Meeting）上，整個團隊所有人都會圍在白板前，分享所負責任務的進度，順便挪動一下任務到相應的狀態欄，用這種方式能夠減少很多不必要的匯報型會議，而且團隊成員也能很快地了解開發的整體狀況。相信如果某個黃貼在白板上連着三天都沒動，團隊里一定會有人站出來幫忙的。（沒有？！那還是先組織他們參加團隊合作的培訓吧。）
有時候團隊坐得比較分散，或者有人喜歡流行的在家辦公方式，這時可能會開始使用一些圖形化的電子白板來管理團隊任務，大家對着屏幕介紹進度，效果似乎還不錯，其他人（包括經理們）也非常高興，因為他們可以隨時從網上了解到團隊的進度了。慢慢地，面對面的時間看起來也可以節省下來，只要窩在座位上點點鼠標，挪挪電子黃貼（如果支持漂亮的拖拉就更好了）就已經足夠了。
這是敏捷的好實踐嗎？
是否嗅到了一點怪味道？它就是我想談的工具帶來的誤區，電子白板會削減團隊之間的溝通，降低團隊的透明度，違背了敏捷重視人和團隊的原則。如果你的團隊成員不經常去更新電子白板上的任務時間，慢慢地你看到的都是不太准確的信息了。有人可能說我們還是面對着電子白板開每日站立會議呀，那我希望你有個很大的屏幕吧，這樣效果更好。
那為什么沒說它不對呢，因為在一些場合下，它還是有作用的。關鍵是團隊要能充分認識到它的局限性，因此我極力反對在團隊組建初期用電子白板，可以等團隊充分領會到敏捷中人與人溝通的重要性后再引入。
這也是在圖1中特意用紅叉提醒不要用Redmine來管理任務（Redmine這個白板功能的插件很差，不如用leangoo）。
所以要了解你的需求，不要讓一些工具牽着鼻子走，要了解敏捷實施的目的，否則出了問題還以為工具不到位，拼命要更強的功能，結果陷入大誤區。
有些工具會帶來意想不到的好處
傳統的敏捷著述中通常會提到CI的部分，然而工具的運用並不限於此，例如我在實際項目中用到的Gerrit，它非常契合敏捷的宗旨，也給我們帶來了意想不到的好處。
代碼審閱是一個不錯的敏捷開發實踐，讓人非常頭疼的是實施。大企業中通常是制定出一大堆相關的規范和流程來指導代碼審閱。我聽說好多公司都會把代碼打印出來，進行走讀，這可真是累啊。這種方式會給人不信任的感覺，而且應該是挺浪費時間的。
結對編程（Pair Programming）也是非常好的一種代碼審閱的方式，值得好好地學一學，只是我對它並不太感冒，體會是在大企業實行結對編程的難度很大，當然如果能找到合適的推動者，那還是可以嘗試嘗試的。
那看看開源社區是怎么解決這個問題的呢，使用的又是什么工具呢？Google的Android系統是現在非常熱門的開源項目，它的代碼審閱（包括貢獻者的代碼）使用的是Gerrit，非常棒的東西，在自己的企業中架設起來也非常方便，我一用就愛上它了。
Gerrit是一個基於Web的代碼評審和項目管理的工具，面向基於Git版本控制系統的項目，所以如果你沒用git（干嘛不用呢），就沒法用Gerrit了，接下來來看看在Gerrit中怎么實施代碼評審的。
● 首先開發者（貢獻者）的代碼變更通過 git 命令被推送（push）到Gerrit管理下的Git 版本庫，推送的提交轉化為一個一個的代碼審核任務（見圖4）。
● 代碼審核者可以通過Web界面查看審核任務、代碼變更，通過Web界面做出通過代碼審核（Review）或者拒絕（Reject）等決定。
● 測試者（一般可以設定為CI服務器執行）可以通過訪問來獲取（fetch）代碼變更進行相應測試，如果測試通過，就可以把這個評審任務設置為校驗通過（Verified）。
● 最后經過了審核（Review）和校驗（Verified）的代碼變更可以通過Gerrit界面中提交動作合並到版本庫的對應分支。
相比代碼走讀，它的好處在於，審閱動作發生在向主干提交代碼前，可以只看變更的部分顯得很貼心，網上隨時隨地審閱起來也很方便，這也是有別於結對編程的一個好處。
任何人都可以審閱提交的代碼，整個團隊的代碼都一目了然，審閱起來更方便，非常符合開放、透明的敏捷精神。使用之后能夠顯著提高代碼質量，甚至於等到習慣了以后，代碼不被審閱一下，都覺得實在是不好意思提交代碼到主干上去。
Gerrit中，通過特定分支，任何審核任務的代碼變更都能訪問，所以如果需要細看或是合並到本地都異常方便。
Gerrit剛開始實施可能會有點不習慣，畢竟整個工作流有所變化，因此實施時需要通盤考慮。
如上只是近期我特別喜歡的一個工具，其實類似的工具還有許許多多，這不過是滄海一粟而已。
總結
水能載舟，也能覆舟，工具和敏捷的關系亦如此，下面我給出幾點建議：
● 積極嘗試新工具，如今的軟件開發世界中，工具層出不窮，要不斷與時俱進，了解最新動向和如何用有效的工具去輔助敏捷的實施，在自己的軟件開發環境中去嘗試和了解這些工具，嘗試這一點很重要，不要只看說明或戴有色眼睛去看待這些工具，應該通過實踐摸索找到最適合你的選擇。
● 人總是第一位的，要了解你的團隊，了解他們的需求，有些時候甚至可以為了團隊，冒險一下采用新技術、新工具，這樣可以提高團隊的凝聚力（敏捷要素之一）。我待過的一些部門推動Git時，就是這么來的，很多時候過多的討論其優缺點反而是浪費時間，不如多花點時間多試試。
● 實施敏捷也離不開組織的支持，特別大型企業涉及到的人很多（可能水平不一），這時候推動者就必須用專業的手段建立一個持續漸進的工具引入過程，這樣會使得實施更容易些。
● 嘮叨這么多，實際上也只是講到一些皮毛，還有很多東西需要我們繼續研究下去。
來源：程序員