JAZZ团队的敏捷与DevOps实践之路

个人简介 顾明，IBM软件开发实验室高级软件工程师。杨敏强，IBM软件集团Rational资深技术顾问，从事软件研发管理相关方法以及支撑工具的推广和实施工作。

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 各位InfoQ的读者们，大家好。我现在在QCon北京2014大会的现场，今天十分高兴能邀请到IBM软件开发实验室的高级软件工程师顾明和IBM软件集团Rational资深技术顾问杨敏强接受我们的采访。那么首先请先介绍一下JAZZ团队的背景，尤其是在2005年成立JAZZ团队开始开发这次项目的时候，当时设立的目标是什么？包括这个项目是为了解决什么目标而发起的？

顾明：首先JAZZ团队从2005年开始是一个内部项目，它主要是为了解决在生命周期中不同的角色之间协作的问题。举个例子来说，我们之前使用了不同的工具，再集成起来有各种各样的问题，导致项目开发的过程中，人员协作起来非常困难。JAZZ这个项目产生就是为了解决这种问题而诞生的，可以去让你的项目开发、产品开发更加透明，人员之间更具有协作性，使整个产品开发的流程更加平滑，加速我们的开发效率和质量。

   

2. 敏捷开发的落实其实是一个个性化很强的过程，不同的团队不能用一套工具或者流程来达到最佳的效果，它跟团队的背景、团队成员的多少，还有开发能力、企业文化都有关系。JAZZ团队一开始是如何根据自身的特点来制订最适合自己的最佳实践？

顾明：这个问题是这样的，JAZZ团队起初绝大多数成员是由Eclipse项目过来的，不同的国家和区域都有他的团队，所以他首先要选择一个分布式的敏捷的开发流程，选择是Eclipse Way这种开发流程。那么随着时间的演进，它会加入一些我们流行的，比如像Scrum这种敏捷开发流程中的一些精髓的东西，然后包括它自己也在随之改善一些我们觉得不太合适的流程。

   

3. 你们每次变化背后的考量或者驱动力是什么，能不能举几个例子？

顾明：举个简单的例子，就是我们现在的一个迭代的周期是四周，但是我们开始并不是这样的，我们最开始的时候迭代周期是六周，然后我们觉得这个这个迭代周期时间太长了，我们交付的频率不足以给用户带来更快的体验，所以我们后来把这个交付周期改为三周。改为三周交付虽然快了，但是有一个问题，因为我们有一周是测试周，也就说我们只有两周时间去做开发，那么在完成某一些比较大的功能的时候，我们就觉得这个时间太短了，所以现在调整为四周一个迭代。这说明什么问题呢？适合一个团队的过程才是最好的过程，我们遇到的问题就是如果我们觉得这个过程，或者我们有一些过程中的一些部分，我们觉得用的不舒服了，不太合适了，我们就会改进它，改进到适合我们的情况为止。

   

4. 那么在团队成员，比如新增一些人，或者是走掉一些人，这个对敏捷的开发方法和文化是会产生影响的。JAZZ团队有没有什么机制来引导这个变化？

顾明：在JAZZ团队里边，我们会有一些最佳实践来做这种人员，比如说人员流失，或者是加入新的人员到团队这种情况。比方说，我们如果有新人加入到团队里边，我们会有一个School，在Wiki上面有一个School，让这个新人去Follow这个School的每一个课程。当他走完这个School的这个所有过程之后，他会对我们团队非常了解，而且是一个合格的贡献者了。当然流失也有，就是我们会把相应的，比如每个人所做的一些工作一些知识总结出来，也是放到Wiki里面，或者是我们写成一些教程，我们放在一个JAZZ.net这么一个库里边，这样帮助我们如果一个人流失之后，他的知识还是留在Team里面的。

还有你刚才问的一个问题就是Team文化，我想简单的举另外几个例子来说明一下，比如说在一个Team里面，可能会有不同时区的不同国家的这些团队成员，那么这些团队成员，我们那时候开会，我们每天会有一个Scrum meeting，我们当然会选一个时间，因为我们跨时区的，我们会选一些时区，在工作时间重合的这么一个时间去开这个会，比如说美国人的下午和我们早晨。那么我们开会不是说为了去更新一下我们这个今天所做的事情，而是只说我们遇到了问题做一下讨论。所以呢，可能不同的Team有不同的文化，我们也是构建了很多JAZZ团队的文化。

还有一个，我们会有一套工作的轮转机制，怎么讲？就是在JAZZ团队里边，我们有一些人去做维护工作，一些人去做开发——就是开发新功能，那么去做开发新功能的大家都知道，我们去写一些Code去完成一些功能，一些Feature，但是那些去做维护的人，他们就需要做改缺陷，还有我们去监控一些论坛上的问题，我们去回答问题，以及我们监控Build，比如说Build出错了之后，他去追查其中的原因，以及还有我们跟客户，Support人员解决他们的问题。那么这些工作，我们都是一个轮转的方式，可能我今天做这个工作，可能我下一个迭代我可能就做另一工作，这样大家都是一个公平、平等的这么一个工作环境。

   

5. 下一个问题是有关DevOps，它其实涉及到开发的思路去解决运维的问题。能不能介绍一下您对DevOps的理解？

顾明：这个问题我来回答。因为DevOps实际上是IBM Rational这边给客户推荐的一套软件交付思想，同时我们的JAZZ团队也在饯行这个思想。那这个思想到底是什么？它的一个核心就是以用户为导向的软件交付。不是以客户，是以用户，我们说是要强调用户的体验和需求，这是第一点，怎么去落地这个用户体验来指导软件交付呢？实际上我们是从两点来着手，第一点是强调跨部门的整合，因为我们要去整合我们的业务部门，整合我们的开发部门，我们的运维部门，整合包含了流程的整合，工具的整合；第二个是自动化，我们如果要通过自动化的手段去解决的事情一定要用自动化，因为人是容易出错的，而且人是花时间的，通过这两点来真正达到我们软件的交付速度和质量，这是我们谈的DevOps的一个定义。那它和敏捷的区别是什么？它实际是扩了，敏捷在开发领域的一些最佳实践，把它运用到了运维，这是第一点。第二点我们在前端，还通过一些流程和思想去知道怎么样去获取用户的反馈，并持续改进，它是在敏捷的基础上做了一个扩展，这是我们对DevOps的理解。

   

6. 能不能介绍一下一开始JAZZ团队为什么要推行DevOps？

顾明：首先是这样的，JAZZ团队是一个敏捷的开发流程，它产生的发布是越来越快了，这样的话，每一个发布产生了之后，我们的运维团队需要部署在各种环境，需要把这个部件构建在各种环境里边，这样他会感觉到有很大压力。为什么？这个事情做得非常频繁，而且工作量非常大，而且容易出错，我们如果用传统的脚本，或者是我们的手工部署，这是非常容易出错的，而且在不同的环境里边，其实这些机器，或者说是这种配置是非常复杂的，而且在后台会有多个环境，所以从他们心中内部就有一个意愿去推进DevOps。那么去用我们的自动化部署的这些工具，然后跟我们现有的开发结合起来，然后把我们的这个运维和开发测试紧密的结合起来。

   

7. 最后一个问题想问一下，现在JAZZ团队的DevOps的推进情况是怎么样的？

顾明：从2012年开始，运维团队在做DevOps的推进。然后13年公司收购UrbanCode之后，他们现在已经把UrbanCode集成在这里边了。UrbanCode能够做我们运维环境的管理，以及我们自动化脚本、自动化升级、或者是自动化环境部署这些事情。举个例子来说，我们一个insertion结束之后，我们出一个Build；出一个Build之后，这个Build会被推送到我们的运维团队那里去，他可以看到这个Build，他可以从中选择一个环境，然后去执行一个定义好的这么一套流程，这可能包括升级、或者包括部署一个新的环境，那么他只需要简单的几个操作，甚至可以自动化的去完成这些操作，那么不同的环境就可以部署好了，这样极大的简化了他的工作量，还有出现问题的这种几率，现在是这样的。还有一个，就是我们在JazzHub上边会有一个，就是让用户体验，或者它是一个云平台Bluemix，让用户在Jazz上面体验最新版本的RDC，那么DevOps实施之后呢，其实运维人员可以更频繁的去部署我们的JazzHub，还有我们的自己的开发环境，做频繁的新功能，客户可以更加及时的去反馈市场的信息，比如说他们一些觉得有需要改进的地方，或者是认为他们觉得那个地方好，可以更频繁的进行改进，这样整个生命周期就运转起来，可以更加加速我们这个产品的去往更好的方向发展。我理解是这样的。

InfoQ：十分感谢两位接受我们的采访。