平安科技于彩荣谈为何保险行业的IT团队需要敏捷化

个人简介 于彩荣，平安科技健康险养老险开发部，分组经理，平安Scrum Master。于彩荣,2004年毕业后加入中国平安,一直从事保险软件开发工作,历任开发工程师、事件响应工程师、系统分析师、分组经理.2011年开始了解敏捷，2012年带领团队实施敏捷,是平安科技首批敏捷试点团队.目前是敏捷和精益的粉丝.致力于打造高绩效的软件开发团队,让软件开发工程师更加有趣的工作。于彩荣,西北工业大学研究生毕业.工作之余喜欢读书、旅游.看着女儿一天天长大是目前生活中最大的乐趣.

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

   

1. 欢迎来到QCon的采访现场，今天我们有幸请到了平安科技的于彩荣老师。首先请于彩荣老师给大家做个自我介绍吧。

于彩荣：我是于彩荣，平安科技的一个IT团队的一个管理者。原来是个管理者，现在正在努力的成为一个比较合格的Scrum Master。

   

2. 一般一说到敏捷，大家都会觉得敏捷更适用于小型团队、小型项目。那么对于平安科技这样一个很大型的金融企业，为什么会采用敏捷来实施一些管理的方法？

于彩荣：我觉得这个问题问的非常棒。很多人也都在问说，你看所有的敏捷大会上，都是很多的互联网公司的人在参加，为什么平安的人也会参加？而且在有些敏捷大会上，我们甚至公司会组团来参加。这个我想更多的是得益于我们公司高层的眼光，有远见的眼光。我们公司的敏捷是自上而下的，是公司的高层认为，我们将来可能会面临这种交付的压力，还有快速实现需求的压力，那么虽然我们现在这种压力还不是很迫切，但是我们可以去尝试它，去更早的去做一些准备。所以我们公司是自上而下的，但是更加令人更加让我觉得幸运的是，虽然是一个自上而下的敏捷的推动过程，但是高层给予了我们这些试点团队更大的自由度和更大的灵活度，我们可以按照自己的方式去尝试，而不是告诉你必须要一二三四五六七这样的去尝试，所以这点我觉得是非常幸运的。然后刚才提到说，敏捷可能更适合于小型团队、小型项目，前几天我参加了一个Scrum认证的一个培训，那么我觉得这点上可能有不同的理解。曾经有一个汽车设计的团队，他们用敏捷的方式来完成了他们的项目，那我想既然在汽车设计行业可以用敏捷，那么可能不是小型项目、小型团队才适合敏捷，大型的项目也可以去用敏捷。我们平安作为一个金融IT，我们也是属于IT业的，主要业务也是做软件的，那么肯定它也可以适用于敏捷。

   

3. 那么在实施敏捷之前，咱们的团队里面有哪些问题需要亟待来解决？

于彩荣：在实施敏捷之前，我们这个团队可能跟其他金融IT团队有一点不同是，我们是做过一个保险销售系统，然后我们跟电商有了更多的合作。电商他们是互联网行业的，他们有各种各样更高的要求，那么我们在跟他们合作的过程中，他们也对我们提出了更高的要求，比如是说为了提升我们的客户体验，那么我们要求保险公司在跟电商合作的过程中，你们要去尽量去提供跟电商一样的服务时间，比如说电商都是7×24，但是保险公司迄今为止还没有真正的7×24，但是他要求我们要去提供更长时间的服务，更好的服务。再比如说我们在跟电商合作的过程中，因为他们是渠道方，具有更大的话语权，那么按照谁的方式来开发，什么时候去做联合的系统测试，什么时候去发布，什么时候去销售，我们都要去配合我们合作伙伴的这种节奏或者是步调，那么在这个过程中我们就感受到了这种实现的压力，快速交付的压力。然后最后一点，也就是说我们保险行业本身的竞争也是很激烈，不仅我们平安在去跟电商合作，其他的保险公司也在合作，那么在这种竞争的时候，如果我们不去考虑一些商务上的因素，纯粹从IT的角度来考虑，那么在系统对接的过程中，谁的系统先跟合作伙伴对接上，谁就可能抢占先机，所以我们是遇到了这样的压力，所以我们在开始想说传统的办法已经不能解决我们的问题，那么我们需要去寻找更好的办法，那么敏捷就进入了我们的视野。

   

4. 那么我们针对这些问题我们选取了哪些敏捷实践来解决它

于彩荣：我们在敏捷实施的过程中，大概使用了几种实践，第一个就是看板，第二个就是Scrum，同时我们引入了持续集成，可能在将来，我们还会去尝试做ATTD，单流开发等等。

   

5. 针对这些特定的情况，因为我知道其实使用完全属于标准的这些敏捷时间，可能并不是特别适用于一些特定的情况，那么我们是不是有针对特定的情况做了一些比较有意思的调整呢？

于彩荣：我觉得这个想法是非常准确的，就像我本次那个分享的话题也是这样子，我的话题是问题驱动结合实际，我觉得结合实际很重要，为什么呢？我们认为敏捷其实是一种变革，只要是变革，它就会有阻力，它就有可能会失败，那么我们怎么样能让这种变革去提高它的成功性，那这里边我觉得就需要结合实际。举一个比较具体的例子，就是很多敏捷团队都在做持续集成，那么大部分团队的持续集成都是说，你作为一个开发人员，你需要去写单元测试，但是很多团队都说单元测试案例实在是太难写了，为什么呢？是因为我们的代码现状，逼得我们没办法去做这样的事情，一个Service五百行，里边有十个if else，请问大家怎么写出单元测试案例来？如果我们为了去写这个单元测试案例而去写单元测试案例，那不是我们的目标。所以在遇到这个，我们公司也，我们这个团队也遇到了这样的问题，那我们是怎么去解决的呢？我们去接受了这种现状，我们的代码分层真的不是那么好，我们编程人员的技术也没有达到那么高的水平上，我们要去接受这种现实，那么我通常会跟大家举一个例子是说，我们要去抢占一个山头，那么我们有没有必要把通往山顶的路上的所有石头全部干掉？我们觉得没有必要，因为我们的目标是抢占山头，而不是干掉所有的绊脚石，所以在这个单元测试的问题上，我们最后就是放弃掉了，我们不去写单元测试了，我们改为写集成测试，因为它更简单，更能满足我们对于持续集成的这种要求。

   

6. 这种方法调整，那我们在实施敏捷的这个过程中，我们是遇到了一些什么阻碍，我们是怎么解决这些阻碍的？

于彩荣：在实施敏捷的过程中，其实我们会遇到很多的阻碍，这也是为什么我在我分享的话题里边的第一个关键词叫问题驱动。我想大家在实施敏捷的时候没有必要一下子就做得那么完美，我们可以去先实施起来，然后发现问题，解决问题，从而去最后达到一个比较完美的境界。我们在敏捷试点的过程中也遇到了很多的问题，比如说我举一个我们团队自己面临的一个实际上的问题，就是我们发现在开每日站会的时候，不是作为一个团队来关注他，而是每个人讲完了自己的事情之后不太去关注别人讲什么，那我说这不是每日站会的初衷，每日站会的初衷是要去关注我们团队的进展，然后我们就去问我们的团队成员说，为什么别人讲的时候你不去听？然后大家告诉我说不是我不想听，而是我听不懂，我们就在想，为什么他会听不懂呢？那最后的原因可能是说，我们的迭代启动会的方式不好，没有让大家去把这些要做的事情去搞明白，所以在站会上别人讲的东西他听不懂，所以解决这个问题的方式就是我们要去调整我们的迭代起动会的组织形式，当这个形式转变了之后，我们发现这个问题就被解决掉了，这是我们团队层遇到的问题，当然我们也发现到了组织架构层面的问题，我们在实施敏捷的过程中，我们是说一定要打造一个跨职能的团队，那最起码的就是，你要有开发和测试的人员的融合，就是不再像以前开发团队、测试团队，然后我们是希望说把开发测试人员都放在一个团队里，不要再去区分开发和测试，但是在我们平安科技，我们原来的组织架构是，开发部门是一个部门，然后测试团队又属于另外一个部门，两个部门有自己不同的KPI，那么我们这个团队在做敏捷实践过程中，我们就发现我们跟测试人员经常不能达成一个一致的目标，这就阻碍了我们敏捷的前进的脚步。然后这个就比较幸运的是说，我们公司是自上而下的推动，然后发现这个问题了之后，高层领导非常有魄力，我们就在今年年初在组织架构层面做了一个调整，把所有的测试部门打散，把不同的测试团队回归到不同的开发部门里去，那么大家成为了一个部门的成员，那么目标自然就一致了，那么很多问题就不再是问题了。

InfoQ：感谢于彩荣老师接受我们采访。