【腾讯敏捷转型No.6】如何打造称手的敏捷工具

在很多公司，决定采用敏捷之后，都会从晨会开始，因为很多人觉得敏捷其它模块都很难学习，就先从最简单的晨会开始，试行简单的方法会不会有奇效，抱着这个想法，奇迹是不会发生的。

很多人不知道的是，许多公司都是从晨会中结束敏捷转型的，虽然开好晨会不简单，而且也有Know-how。

工具和管理方法实现价值最大化

大家会有一个问题：老布，既然只做晨会不行，那做敏捷有没有其他衡量指标呢？

我可以很肯定的回答你：有，如果有且只有一个的话，衡量团队的敏捷指标就是一个月内该团队写给自己团队的代码占总代码中的百分比。

为了解决团队目前工作质量或工作效率的问题而开发的一些工具的代码，占据所有代码的百分比，就是团队的敏捷指标。敏捷的本质是寻找价值，妨碍团队高效寻找价值的障碍都是“问题”，所以需要利用管理方法和工具来解决问题。通过不断发现团队的短板，用管理方法调整或者编写工具来解决短板，从而释放团队每个成员空间，实现个人价值最大化。

假设人工发布的时间需要2个小时，每四次发布有1次要回滚，每周发布一次，请问团队中谁愿意反复做这件事？再假设发布从每周改为每周两次呢？你会发现，这样的团队成员压力都很大，容易犯错，这里就是一个短板。所以团队很有必要花费两周的时间开发一个自动发布的系统，将以往每次发布两小时改为成两分钟而且支持回滚。

这部分的代码就是团队写给团队自己的代码，我们希望持续通过编写代码来改进团队短板。

（图一：腾讯敏捷工具模块）

如图一，为了发展敏捷研发，经过多年的建设，终于构建这么多工具来支撑敏捷实践。包括CE（Customer Engagement）、需求管理、代码管理、测试过程管理、发布管理、缺陷跟踪管理、持续集成管理、项目过程管理、任务管理等。

很多人会有误解，认为鹅厂规模这么大，人数这么多，随便挤出一些人都可以完善这些工具。其实这些工具的早期版本都不是专门团队来完成的，而是业务团队根据自己的需要逐步开发完善的。

例如，自动发布模块，就是网站业务团队最先做的，因为相比较公司内其他业务，网站业务的自动发布比较容易实现，按照版本发布到Server上，就可以对外提供服务了。在当时，绝大多数的客户端业务的自动发布就没有那么容易实现了，但是当网站业务团队的自动发布实践取得效果后，有了标杆，其它业务团队都敢于尝试了。

很快有团队将自动发布进化为灰度发布工具，自从有了灰度发布工具，很多团队就发现巨大的好处。在没有使用灰度发布工具前，当时的业务经常需要切换上线，为了不影响客户，都需要在凌晨四点左右完成切换。那时候，我还特意买了一个睡袋，在切换上线的时候，前一天晚上10点睡觉，凌晨3点起来操作脚本停掉旧版，然后编译，启动新版。观察一个小时的日志，看看业务是否正常运作。如果不正常就赶紧干掉新版，回复旧版，等第二天白天修改问题之后，晚上再次切换上线。

自从有了灰度发布后，可以在白天黑夜随时发布上线，逐步切换一小部分用户使用新版本，如果有任何问题，就可以立即切换所有用户用回旧版。同时开始查找问题，等修改调整好了以后，再次切换一小部分用户试用，然后持续观察用户的表现和反馈，直至成功所有用户成功切换使用新版本。

每个业务都会挑选合适自己的重要工具进行开发，取得一定成效后，公司就鼓励大家互相分享工具，经过三年时间“发酵”，这些工具已经逐步完备，最终腾讯公司敏捷实践的效率在这些工具的支撑下越来越高。

很多学员会问我，老布你有没有好的工具直接推荐给我们用啊？我认为，因为每个团队的性质不一样，用的工具和脚上穿的鞋子一样，别人穿着很舒服，但是不一定适合你，只有合适才是最好的。

所以我始终建议团队根据自己切身情况开发的工具是最好的，但是现在大家比十年前的我们幸福多了，现在Github上有很多Open Source工程，都是用来加强敏捷实践的工具（如图二）。

 （图二：开源敏捷实践工具）   

所以现在大家只需要找到一个合适的好工具，觉得适合自己团队就持续使用，发现问题就自己动手修改，这样的工具才是最适合团队所在的行业、业务和团队特点的，效率才是最高的。

【案例】CPD检查你的代码

十年前，我和我的团队想做静态代码扫描的时候，当时只能使用价格昂贵的Pclint工具，非常郁闷的是它只能扫描C语言的代码，C++代码暂时还不支持。当时我们通过缺陷审计，发现一个现象——很多程序员每日提交到SVN的代码占比相当高，都是从其他代码里Copy-paste过来的，根本没有修改，直接编译运行了。只要功能正常，就提交。在面向对象语言的时候，Code高度抽象，就算只有5行代码都可能新建了某个对象然后这个对象初始化的代码里还启动一个线程池，被Copy的代码在某个地方关闭了线程池。他们在抄代码的时候根本没有分析清楚，所以这样的代码隐患非常大。

于是我的团队使用静态扫描功能就最先开发了一个“CPD”功能（Copy-Paste·Detector）。每天晚上把当天提交的代码以人为单位进行分析，第二天早上8点前会有一封邮件发送给所有人，邮件标题为《TOP10·CPD·Programmer》，邮件的内容是人名、CPD率、上榜时长。把昨天的代码里Copy-Paste后并不修改源代码，CPD率Top10的人列出来，提醒他们当天必须把代码逐行检查调整后再提交。如果有人连续两天上榜，就会额外有一份邮件发送给那个人的直属Leader，请他帮助解决这个entity，通过这个简单的方式，团队千行Bug率大大下降。CPD工具的原理说出来简单得不能再简单，但是效果非常好，所以建议敏捷工具根据需要自己开发，这样才是称手的敏捷工具。

*本文由老布原创，转载请联系授权。