敏捷开发中应该使用那些敏捷工具(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.ltesting.net