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

　　有時候團隊坐得比較分散，或者有人喜歡流行的在家辦公方式，這時可能會開始使用一些圖形化的電子白板來管理團隊任務，大家對著屏幕介紹進度，效果似乎還不錯，其他人(包括經理們)也非常高興，因為他們可以隨時從網上了解到團隊的進度了。慢慢地，面對面的時間看起來也可以節省下來，只要窩在座位上點點鼠標，挪挪電子黃貼(如果支持漂亮的拖拉就更好了)就已經足夠了。

　　這是敏捷的好實踐嗎?

　　是否嗅到了一點怪味道?它就是我想談的工具帶來的誤區，電子白板會削減團隊之間的溝通，降低團隊的透明度，違背了敏捷重視人和團隊的原則。如果你的團隊成員不經常去更新電子白板上的任務時間，慢慢地你看到的都是不太準確的信息了。有人可能說我們還是面對著電子白板開每日站立會議呀，那我希望你有個很大的屏幕吧(否則這樣子效果會更差)。

　　那為什么沒說它不對呢，因為在一些場合下，它還是有作用的。關鍵是團隊要能充分認識到它的局限性，因此我極力反對在團隊組建初期用電子白板，可以等團隊充分領會到敏捷中人與人溝通的重要性后再引入。

　　這也是在圖1中特意用紅叉提醒不要用Redmine來管理任務(這個白板功能的插件也很差，因為沒人用)。

　　所以要了解你的需求，不要讓一些工具牽著鼻子走，要了解敏捷實施的目的，否則出了問題還以為工具不到位，拼命要更強的功能，結果陷入大誤區。

　　有些工具會帶來意想不到的好處

　　傳統的敏捷著述中通常會提到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時，就是這么來的，很多時候過多的討論其優缺點反而是浪費時間，不如多花點時間多試試。

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

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