讓敏捷工具在敏捷開發中發揮高效做用

敏捷軟件開發毫不再是一個新名詞了，但理解仍是時時有誤差。敏捷宣言中的第一條「個體和互動高於流程和工具」，有人就誤讀爲「有了溝通，一切都迎刃而解」 ，所以花費大量精力整頓團隊合做，卻輕視了工具（技術）。其實宣言中的意思只是想強調我的和溝通更重要而已。

實際上，既然是軟件開發，在所不免得面臨工具的選擇，並且不少優秀軟件實踐離開強有力的工具支持都玩不轉。在現在的軟件開發世界中，工具（這裏談的是軟件工具）層出不窮，數不勝數，那麼到底該怎麼去選擇適合的工具呢？

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

爲了不沒必要要的麻煩，文中儘可能用開源軟件做爲介紹，但這並非說我排斥商業軟件，偏偏相反，在不少時候，只有商業軟件才提供了你須要的功能（固然大部分狀況下開源軟件會很快迎頭遇上）。

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

聊到軟件開發中的工具，通常都會提到這個術語「應用程序生命週期管理（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時，就是這麼來的，不少時候過多的討論其優缺點反而是浪費時間，不如多花點時間多試試。

● 實施敏捷也離不開組織的支持，特別大型企業涉及到的人不少（可能水平不一），這時候推進者就必須用專業的手段創建一個持續漸進的工具引入過程，這樣會使得實施更容易些。

● 嘮叨這麼多，實際上也只是講到一些皮毛，還有不少東西須要咱們繼續研究下去。

 

來源：程序員