“至今为止，我们觉得敏捷在研发中心已经成为了一种文化了。”崔航表示。
8月8日，主题为“新技术下的IT管理和能力提升最佳实践”的“第三届国际最佳实践管理联盟中国年会”在北京召开，来自IT、通讯、金融、互联网等行业的CIO/CTO及IT管理者约200人参加了本次年会。
中国民航信息网络股份有限公司研发中心资深质量保证工程师崔航在演讲中详细介绍了就中国航信的敏捷应用，并分享了自己对于敏捷实践的心得。
中国航信集团是我国航空运输旅游信息的专门服务提供商，目前公司有6000多人，全国有60多个分子公司。对于什么是大型复杂系统，在中国航信，首先是指开发周期2年以上的系统，而且团队规模一般都超过40人以上。比如民航旅客服务系统、机场立岗系统、机场行李处理系统，这个都叫大型复杂系统。
中国民航信息网络股份有限公司研发中心资深质量保证工程师 崔航 分享大型敏捷开发应用实践
由于全国所有的航空公司都是中国航信的客户，但是他们分布在全国，如果只是总部研发，根本支持不了，因此中国航信通过全国各地分子公司的研发团队提供个性化版本的支持。这些大型复杂系统基本上都是分布式联合开发。
据介绍，2011年12月中国航信聘请惠普公司咨询团队启动了敏捷咨询项目，2012年4月，建成了开发流程，2012年的9月就开始第一次大批量、大规模的推广，到2013年，已经有了45个项目、445个人开始加入敏捷开发的队伍。
2014年中国航信第一次召开了敏捷总结大会，大家都觉得敏捷实施的效果不错。
从2011年12月引入，到现在基本上已经5年多了，在这5年的过程中既有成功，也有一些挫折，但最终的效果不错。从流程上看，2013年之前中国航信的敏捷主要是做推广，到了2014年、2015年，发现如果只是过程的话，没有办法最大程度发挥敏捷实施的价值，还是需要跟上工具、平台，这样才能真正的能够持续集成、持续交付，所以在2014、2015年开始，重点建设敏捷开发的工具平台。
以前做项目反馈比较慢，遇到问题解决起来也比较麻烦，自从实施敏捷以后，我觉得基本上不再像以前了，基本上可以不空谈了，大家的质量意识、工作效率都有很大的提升，尤其中国航信还实施了最佳软件工程的方法，都对我们团队的无论是个人能力、团队能力有很大的提升。
具体来说，通过敏捷实施以后，第一，统一版本规划，使得定制版本的维护相对容易很多。第二，统一的管理平台，减少了异地或跨部门沟通的困难。第三，统一的质量要求、技术要求，避免了后期才会发现的因为配置不同或者代码质量很差而引起的一些返工，实现了持续交付，提高了客户满意度。
以下为崔航演讲实录：
谢谢主持人！我是第一次参加国际最佳实践的年会，心情非常激动，感谢孙振鹏先生给我们公司这个机会，让我站在这里跟大家一起分享我们在敏捷事件方面的一些经验、教训。
我今天分享的主题主要是对于大型复杂系统，尤其是多团队联合开发的时候我们如何适应敏捷的。
其实对于我们公司来说，跟互联网企业不太一样，我们是传统的IT企业，刚才前面说了我们是民航的，在民航方面我们公司主要做的都是大型复杂的系统，其实如果按照敏捷的理念来说，可能不是特别适用。但随着互联网的发展，对客户的一些需要，如果我们还是按照以前瀑布式的模型来做项目的话，其实已经不太适应了，所以我们开始在2012年敏捷了。
刚才听了前两位演讲嘉宾演讲，内容都非常精彩，在讲主题之前先对我们公司做一个简单的介绍。我们是中国民航信息集团公司，有30多年历史，我们的前身是民航总局下面的计算机信息中心，是在1978年就成立了，我们集团公司正式成立是2002年，其实是在2001年的时候就已经在香港上市了。我们就是航空运输旅游信息专门的服务提供商，我们公司从之前的计算机信息中心不到100人的规模，经过这么多年发展已经达到了6000多人，并且有60多个分子公司。
在座各位应该经常坐飞机吧，大家有没有用什么软件去查这个航班信息？就是我们集团公司下面一个子公司的产品。TravelSky是我们公司的名字。
说一下我个人的信息，我是2005年开始质量工作的，我来自于航信总部的研发中心，我个人工作经历与研发管理体系的建设是跟航信息息相关的。在2005年的时候航信通过了ISO9000认证，实施项目管理，当时我刚好有幸加入了这个团队。2011年的时候我们通过了CMMI L3的评估，当时我作为五人评估组重要成员之一。这个阶段我们相当于是航信主要做的项目开发的规范化，大家也知道我们来源是央企民航的信息中心，当时其实大家不太会做项目，只是说去维护信息系统就好了。但是在这个阶段我们发现，你要是不会开发规范，越来越没有办法满足市场需要、客户需要。
到了2012年我们开始引入了敏捷，因为从2010年开始行业发展特别快，连带其实我们传统的这些IT行业对于客户的需求都是需要快速响应的，不是说CMMI不好，过程过重，所以我们2012年引入了敏捷开发，希望能够快速交付。
2013年我们公司就成立了PMO（项目管理办公室），为什么之前没有？2013年以前都是大型主机，经过这几年的评估，主机系统越来越不能满足民航业的发展了，我们现在旅客的增长量非常快，我们现在信息系统如果仍然用大机，在五年之后绝对满足不了，所以我们在2013年立项，要进行新一代旅客服务信息系统的建设，这个项目国家投资18亿，是特别特别大的项目，说要成立一个PMO，当时我也有幸加入了这个PMO，主要是负责质量管理、质量保证等工作。
到了第三阶段，我们引入了集成产品研发的过程，为什么呢？因为在之前我们都是在做系统，后来发现只是做系统或者只是响应客户的需要不能满足公司自身的发展，所以我们现在逐步要去做产品。做产品我们当时就引入IBM的IPO集成产品研发过程，我们进行了一年的咨询，经过整理，其实也是结合了快10年的过程的积累，最后发布了一个产品体系的白皮书。
下面进入主题，敏捷在我们公司是怎么开始实施的。2011年12月的时候我们开始启动了一个咨询项目，当时聘请的是惠普的一个咨询团队，孙先生应该知道，当时有幸聘请了郑力、徐毅都是目前很资深的敏捷教练，专门到航信来给我们实施敏捷。到了2012年4月，通过这个咨询团队我们建成了开发流程，在2012年的9月就开始第一次大批量、大规模的推广，一直到2013年我们已经有了45个项目、445个人开始加入敏捷开发的队伍了。
如图，这两个大家可能很奇怪这是什么东西？这其实是我们公司自己设计的一个认证，是敏捷成熟度的认证。我们2012年开始试点推广，2013年实行了一年，我们要看效果怎么样，所以我们制定了一个成熟度等级评价方法，就是检验所有的实施敏捷的团队，他们到底成熟度达到了什么水平。我们应该分成了三级，其中这三级都是有三项标准，还有三项，因为我们刚开始只有三项最佳的敏捷实践。因为有些团队一开始就上来了，但是后来又觉得不太适用，中途中断了，所以我们看他的成熟度还有敏捷持续的时间。
定量的指标其实是由度量指标和敏捷实践指标两部分组成的，包括自动编译、自动构建的频率、代码评审、分支覆盖率等等，包括客户演示，我们都是一些客观的数据去看。敏捷实践主要是，我们进行项目管理，也是有一系列的指标，通过打分的机制看它实施的情况怎么样。对于三项敏捷实践其中还有一个是持续集成，还有客户参与的效果，最终会给每个团队进行评价。
到了2014年第一次召开了敏捷总结大会，当时给所有的这些能够得到三级敏捷成熟度团队，由我们公司中心领导专门去给他们颁奖，并且在这个会上我们还有幸邀请了比如说阿里资深的敏捷教练，包括又把郑力请回来给我们去讲一下，因为事隔两年了敏捷的发展有变化。我们在这个大会挺成功的，大家都觉得敏捷实施的效果还是不错的。至今为止，我们觉得敏捷在我们研发中心都已经成为了一种文化了。
最后总结一下，其实我们的敏捷实施从2011年12月引入，到现在基本上已经5年多了，在这5年的过程中时间其实不短了，我前面介绍的可能还OK，但其实这个过程我们自己也很有体会，有很多很多的一些挫折，但最终的效果不错，后面会跟大家分享一下敏捷给我们带来的收获。2013年之前我们是做推广，主要是一些敏捷的理论、方法，手把手的去教他们，到了2014年、2015年，我们发现如果只是过程的话，其实没有办法最大的发挥敏捷实施的价值，所以最后发现还是需要跟上工具、平台，这样才能真正的能够持续集成、持续交付，所以在2014、2015年开始我们重点是建设敏捷开发的工具平台。这个是我们的一个发展过程。
下来就是以大型复杂系统多团队为例讲讲我们怎么实行敏捷的。
在我们公司什么叫大型复杂系统？ 首先开发周期肯定是2年以上的，而且团队规模一般都超过40人以上。举个例子来说，民航旅客服务系统、机场立岗系统、机场行李处理系统，这个都叫成大型复杂系统。全中国所有的航空公司都是我们公司的客户，但是他们公司总部、分部，分布在全国，如果只是总部研发我们根本支持不了，我们在全国各地都有分子公司，并且也有一定的研发团队，尤其是做那种航空公司的个性化版本，所以我们这些系统基本上都是分布式开发，都是联合开发，主要是让重庆、广州、上海这种大的研发中心跟着总部一块做这种联合开发的，所以我们把这种都叫复杂系统团队开发。
这个大型复杂系统大家可能都有一些共识，最大的问题就是，因为人员比较多，而且大家都不在一起工作，大家会质疑敏捷：不是说一定要面对面的沟通吗？这是宣言的一部分，包括我们的价值观。但是我们实际情况，尤其是传统大型IT公司是根本做不到的，但是我们怎么办呢？但是这些问题还是得解决，因为有了距离，尤其现在，之前我们都遇到过，这种沟通不便，协调起来特别特别的困难。还有最主要的一点，就是第四点，技术实践。因为当时我们各个分子公司的研发团队大家的技术标准、质量标准都不太一样，还有包括环境配置。一做集成的时候发现糟了，全都是Bug，甚至跑不通，这样导致了多次的多轮返工，这些都是一些问题，所以我们觉得敏捷有可能能够解决这些问题。
所以我们首先有一个大型复杂系统的团队，下面有一个管理框架，在座的大型企业可能都是这么做的，有四个层次，协作、管理、决策、支撑，我们公司的特点主要集中在这里。还有我们所有的团队里边会有一个主责团队和其他协同团队，主责团队一定是负责整个项目的产品规划、架构设计，到最后包括整个系统的集成测试、UAT测试、投产上线，都是由主责团队小组全权负责的。其他的无论你分布在哪里，OK，没有关系，你还是各自的可以实施敏捷，我们是多团队同步迭代的方式去做。还有一个特点，在支持这块，我们为了解决跨团队、跨地域、沟通协作的困难，或者技术标准、质量标准不同的问题，我们要求统一平台、统一制度、统一度量，避免刚才说的问题。
对于多团队同步开发的问题，仍然是每个小团队采用的是这种方式，2—4周一个迭代，在这个迭代过程中你的开发测试，按照你自己的规划进行就可以了，我们有可能跟其他的公司或者互联网公司不太相同的，就是我们需求这块，我们需求分析是没有放在迭代里头的，因为我们刚才也说了，我们是协同开发的，这个需求必须是经过主责团队统一规划出来的，我们叫PRD文档，就是产品需求文档，我们有KC的概念，这个KC就是说，对于这个系统来说是大的功能点，这个规划必须主责团队来去做，把他会分解成不同的UC，就是一个个需求，这个是在分发给各个分支的协作团队，由他们做需求分析。这个需求分析完了以后，他是需要反馈给我们整个主责团队他们要去做评审。这个过程有可能稍微长一点，不太适用放在迭代里面，所以我们把这块是分出去的。
具体迭代主要是设计测试开发，大家可能会说你这样不是有点像瀑布型的，大家就在等。其实不是，跟以前最大的区别就是，我们的这个需求不是说把所有的需求都分析完了以后才去做，而是说按照我们小的产品版本的规划，拿出来一部分，可以开始做了，这部分需求分析完以后马上就进入迭代开发的过程。同时，在开发团队做迭代开发的时候，我们这边同步的产品经理再去做剩余的需求。
还有一点，各个团队虽然是各自的迭代，但是都必须符合我们整个的版本规划，所以我们叫同步迭代开发，因为最终它的交付，我们这块的交付有可能也是跟别的敏捷不太一样，直接交付给客户，我们不是，我们这个迭代出来的版本是一个可集成测试版本，不是直接交给客户的，因为这个也是跟我们系统的安全性包括集成性的特点有关系的，这也是一个比较大的差别，就是我们可集成的这种测试版本以后，由主责团队进行版本测试，最后再给客户交付。这就是敏捷的这一部分。
下面说一下工具的部分。其实我们认为，敏捷最佳实践我们运用比较好、也认为最有效的就是持续集成，因为尤其是多团队开发的时候，这个持续集成是非常非常关键的。我们的持续集成平台的关键功能包括这些，我们会有统一的原代码配置库，对于一个大的复杂系统项目，所有的团队它的代码配置库必须是一个，就是目前都是在我们总部研发的，这样的话可以随时获取这种系统里要集成的最新代码。第二，我们要求必须每个团队每天提交代码，并且能够自动构建，这个代码必须可以自动编译，而且可以编译通过的。第三，需要实现功能单元测试，必须自动化，因为它需要快。我们在每次提交代码以后，根据我们平台的设置会自动的去启发这个静态代码扫描，包括自动执行单元测试，最后才是做自动的构建。
最后，问题应该是自动反馈的，不是靠人去看有问题，而是在持续集成过程中随时发现问题、随时就要反馈给相关的提交人员，让他们及时处理，这样才能保证每天提交的代码放在服务器上都是一个可编译的版本。这个就是我们持续交付的平台建设，主要包括六大功能模块，第一个是任务分解，我们用的是这个工具，尤其是对于异地开发的分布式模式，大家把任务都放在这个平台上，任务进展、任务工作情况都是透明的，大家都可以看。还有电子看板的跟踪，以前我们都是大白板去贴小纸条，那个也是不会的，在开会的时候面对面沟通效果比较好，最大的问题是不便于度量，因为都是一个一个小纸条，最后还是得拿下来一个一个去更新数据，比较麻烦，而且比较慢，所以我们最后应用电子看板进行跟踪。
原代码指的主要是静态代码，我们开发人员每次提交以后必须得先经过静态代码扫描，再做单元测试，然后才可以去做自动的构建。
我们要求代码的质量必须是统一的标准，尤其是对于分团队开发，所以我们会有代码传送，因为是异地，以前无论是QQ开视频的效果都不是特别好，所以我们引用了FishEye这种工具，大家把代码拿下去之后直接评审，你的意见及时反馈，开发人员看到以后也及时修改，一整套是我们基于交付平台的。
最后说一下敏捷对我们的帮助是什么，自从实施敏捷以后，大概5年多的时间，因为我觉得我们基本上不再像以前做项目反馈比较慢，遇到问题解决起来也比较麻烦，现在基本上可以不空谈了，大家的质量意识、工作效率都有很大的提升，尤其我们还实施了最佳的软件工程的方法，都对我们团队的无论是个人能力、团队能力有很大的提升。
刚才前面提到了大规模项目有5个问题，我们基本上有4个问题得到了一定程度的解决，我们通过敏捷实施以后统一版本规划这样使得定制版本的维护就会相对容易一些。第二，统一的管理平台，我们一定程度上减少了异地或者是跨部门这种沟通的困难。第三，我们有统一的质量要求、技术要求，这样避免了一些后期才会发现的因为配置不同或者代码质量很差而引起的一些返工。因为我们实施敏捷以后基本上可以做到持续的交付，避免了我们以前航空公司的客户老是抱怨说，你们这个航信开发太慢，还不如找外包呢，现在基本上满意度已经提高了很多。
前面有可能没有感觉，这是一些数据可以说一下。从产品质量来说，我们这个产品比较宽泛，不是说最后交付的产品，指工作产品。从缺陷密度、故障率、缺陷泄漏率我们连续3年，因为我们实施敏捷以后就开始度量，从2013年开始度量，以后连续3年我们都是在持续降低的。
静态代码质量，我们也是在2013年刚刚引入唢呐这种扫描工具，当时其实我们的编码规则基本上引用的就是Google、微软的规则。当时一扫吓了一跳，我们大多数项目都在D级和E级，差别差，因为一共分为5级最低就是E级，我们大多数项目在D级和E级，经过3年以后我们现在基本上90%以上的项目都在C级以上了，有大概20%的项目都已经能保持在A级。
开发过程，我们在实施敏捷之前基本上没有自动化测试，这几年不断的建设，当然这都是有成本的，大家可以看，我们增长到了24%，虽然不多，但其实对于我们来说已经是一个很大的进步了。
还有单元测试分支覆盖率，当时也是我们的开发团队在代码质量意识上还是挺弱的，后来实施敏捷以后我们从0增长到了大概30%，这是一个平均数，我们有的团队做的特别好的都已经达到了80%，还有55%的团队已经真的是能够实现每日提交代码并自动构建了。
对于交付效率，我现在从实施敏捷已经开始，当然这个数据已经是去年的了，我们可以实现每月去给客户演示，达到平均1.33次了，这个在以前都是不可想象得。并且每个系统每月都能投产一次新版本了，大家可能觉得你这个敏捷每个月才投产一次是不是慢一点，因为我们公司还是跟那个不太一样，因为我们的安全性要求还是非常高的，因为民航所有的信息系统，大家的订票、离港都是公司来维护，不敢出一点错，对于我们来说已经是很大的进步了。
最后说一点体会，其实主要还是三个，如果实施敏捷的话，大家一定要说你的目标是什么，目标千万不是你要实施敏捷，而是说你到底要解决什么问题，是不是能够通过实施敏捷来解决，所以这个目标的设定是非常重要的。第二，实施过程当中，经过5年多，我们后来发现，其实我们在2014年的时候，其实花了很大的成本去建设工具平台，是因为发现到了2014年我们在实施过程中遇到了瓶颈，大家说我都做了，我都采用了什么，也都怎么样了，但是好像这个效率没有特别大的提升，所以我们当时觉得，尤其是对于那种异地来说，你没办法解决这种沟通问题，所以我们觉得敏捷实施有效性，工具和流程的建设还是非常重要的，就是你要继续想往深里做的话。第三，这个有可能不是说工具流程能够解决的，就是团队，每一个敏捷的开发团队的管理者是非常重要的，他必须有自己敏捷的理念才能够真正的把这个团队带好，真正的去实施敏捷。
我们举一个例子就是，我们有一个团队，刚才我提到我们单元测试覆盖率达到80%，就是因为我们的SM非常棒，他是一门心思觉得敏捷非常好，他会要把他所实施的敏捷实践真正的运用起来，目标就是要提升他们代码的质量，还有团队的使用效率。但是有的团队，到目前为止我们还有的团队处在一级的水平，就是我们自己的能力成熟度，那就跟他的SM还是有很大的关系的。
最后的变化，每个企业特点不同、业务特点不同，你的文化也是不一样的，我觉得敏捷实施还是要因地制宜，我们刚开始就是相当于照搬惠普那一套在2013年的时候也是遇到了很多问题，最后我们会去做一些优化、改良，然后去适应我们自己的特点，最后才比较能够顺利的实施。
我今天的分享就到这里。谢谢大家！
