线上分享实录|平安7年精益敏捷转型之路

导读：平安做为互联网金融的领跑者，目前有超过40个APP，传统业务全面互联网化。可以成功转型与敏捷密不可分，平安科技更是整个集团敏捷转型的领头羊。
2011年，敏捷开发试点项目大获成功以后，平安科技驶入敏捷推广的加速车道。
2012年试点范围扩大到10个团队，引入Scrum、看板(Kanban)、持续集成等流行的敏捷方法。
2013年“开启敏捷2.0”，在组织架构上成立“敏捷中心”，整合业界优秀实践，造成平安科技本身的敏捷开发方法体系和敏捷成熟度评价体系。
2014年，敏捷开发覆盖到公司大约80%的开发团队，并开始探索互联网产品的敏捷开发模式。
2015年“迈向持续交付”，从研发过程的敏捷，向上下游扩展，引入精益创业(Lean
Startup)、DevOps等新的方法，打造端到端的反馈闭环。
2016年启动持续交付支撑工具链的建设，致力于打造“精、轻、快”的持续交付一体化平台与解决方案。
从2013年到2015年，公司总体的30天需求实现率从24%
提高到80%；产品研发周期从以往的6个月缩短到3个月之内。此外，更灵活的响应变化、稳定的版本质量、更高的团队产能、持续改进的习惯，都逐步显现出来。

本次分享将经过真实的案例，分享平安科技全面敏捷模式如何在小团队、大项目，乃至整个组织的实践和落地。

文章来源：公众号msup

背景介绍

先简单介绍一下公司的背景。上图中左侧的高楼是平安金融中心，这是深圳最高的楼，118层。曾几什么时候，咱们听到“平安”的时候只能联想到保险或歌星，现在咱们能够骄傲地说，咱们是作金融互联网的高科技企业。

2016年平安在世界五百强企业里排41，这个成绩和平安互联网+综合金融的转型战略是分不开的。平安如今已经有了40多个APP，近3.5亿的互联网用户，这个数字还在快速增长。

与之适应的产品策略和管理思路也在全面互联网化。咱们从以前的关注能卖多少钱，到如今关注能为用户创造多大的价值，这偏偏都是敏捷所倡导的也是互联网须要的。

上图是咱们从2011年到如今的转型路线图。

从2011年开始咱们成立了第一个 feature team；2012年引入看板方法进行可视化管理；2013年是很是重要的一年，咱们成立了敏捷中心推行敏捷2.0，也就是scrum+看板+极限编程的方法，聘请了大量的敏捷教练，也组织了不少场培训，开始全面推行敏捷。

2014年开始将敏捷实践推广到大型项目，平安是国内第一个引入LeSS（大型敏捷框架）的企业；2015年开始向敏捷的上下游拓展，引入了精益创业和持续集成、持续交付的方法；2016年，咱们开始本身研发一个持续交付的工具——神兵，同时经过工具来获取一些过程数据，并进行价值流分析以提高企业的效能。

2011 元年

2011年是咱们开始敏捷转型的第一年。通常改变老是有缘由的，我业余时间学了些心理学和教练技术，个人老师常说“不够痛就不会动”。有的痛是切实感觉到的，有的是对将来的焦虑。

平安敏捷转型的出发因素不少仍是来自于互联网，当时互联网巨头纷纷涉足金融和保险，淘宝的保险频道都已经上线了。马明哲还说BAT才是平安真正的对手。

显然，以前的标准化、规范化的研发管理模式已经不适应当前变化的互联网环境了，咱们更须要一种灵活多变的多元化的管理思路来更高效地作事情。

从上图左右侧的对比能够看到：2011年以前咱们强调的是管理的标准化和规范化，当时还经过了CMMI的三级评审。2011年开始推行敏捷以后，咱们开始倡导开发模式的灵活化多元化，应用不一样的管理模式来应对不一样的场景。

咱们还开展了一个叫“百日行动”的活动，就是用一百天去提高效率，具体作了这么几件事：

第一，看文档有哪些是必要的，哪些是不须要的。咱们把文档分为系统级和过程级两类。系统级的文档要增强，好比架构文档；过程级的文档要弱化，好比周报日报，这些只是为了沟通，实时性很强，彻底能够经过面对面的沟通来取代。

第二，缩短签报的审批链。平安如今有一百多万人，审批链很长也很复杂，咱们会分析每个环节的经过率，若是这个经过率长时间以来一直是100%，那这个环节就应该是能够去掉的。

第三，讨论怎么开会更高效。

第四，搭建部署流水线。尝试将代码从手工移交变成自动化移交。

分享一个车险网销平台的案例。咱们拿这个项目来作第一个敏捷试点项目。这是一个小团队，这个平台要作的功能是实如今互联网上卖车险。

这是咱们第一个特性团队的照片，这个团队包括产品经理、先后端开发、测试等各个角色，这样的一个全功能团队可以实现端到端的交付。

当时进入特性团队的种子成员都是通过挑选的，咱们会选择一些乐于接受新思想、愿意寻求改变的人，随着这样的实践他们后来都成长为平安的骨干人才。

上图是咱们特性团队的第一个看板，虽然不够美观，可是已经有一些样子。

经过敏捷实践和落地，咱们达到了如下的效果：
上线周期从两个月缩短到两周；
外部合做伙伴接入的周期从3个月缩短为1.5个月；
产能提高30%；
版本测试周期压缩一半，生产问题减小70%。

咱们的组织在最初尝试导入敏捷的时候作了三件事：

第一，创建全功能团队，经过面对面的协做改善沟通。业务方表明最好也可以加入到这个团队中去，这样可以及时给团队答疑并提供反馈。
第二，经过看板可视化进度，今早发现问题消除瓶颈。
第三，把需求拆小拆细，以便可以尽快交付尽早获得反馈，从而下降风险、灵活应对变化。
第四，最重要的是人，须要有一些可以接受敏捷思想的人去作这样的一些改变。

2012 起跑

第一个试点项目取得成效以后，咱们开始逐步深化咱们的看板实践。上图是一个寿险的支持项目，这个看板系统比以前的原型看板漂亮多了，从图中还能够看到它与原型看板的区别：

首先，有了测试就绪、验收就绪的等待队列；
第二，卡片上有贴owner的照片；
第三，右下角有一个燃尽图；
第四，图中打红叉的部分是作了一个WIP的限制，就是说这个队列不能有太多的卡片，卡片不能贴到那个禁止的区域里。

说到转型时度量也很是关键。上图是一个累计流图，纵坐标是Story Point，粉色的线是启动开发的故事点数，深绿色的线是用户验收完成的故事点数，这两条线的宽度对应到横坐标大概是三周的时间，就是说这个需求的lead time，从启动开发到用户验证大概须要三周的时间来完成。

经过改进这个看板实践，咱们能够看到：因为中途发现了优先级更高的需求，因此有40%的原始需求被舍弃了。从传统项目管理的强调交付范围转化为交付价值，这是互联网的要求。由于如今的社会充满了不肯定性，咱们也很难从一开始就把范围肯定并保证后面不发生变化。

咱们须要拥有灵活应对变化的能力，要保证团队一直在交付高优先级、高价值的任务。同时咱们也不但愿这个范围无限蔓延致使同窗们每天加班，质量降低。因此当有一个高优先级的任务要加进来的时候，咱们就会挤掉一个同等工做量的低优先级任务。这就是为何上图中左下角中途增长的40%优先级更高的需求，右上角又挤掉了一样多的需求。

总结一下咱们2012年敏捷转型的几个关键要素：
延迟决策，让它快速流动；
交付价值赛过交付范围；
经过约束限制在制品数量来拉动系统；
经过看板实现阻碍和问题的可视化。

2013 推广

经过前面两年的积累，咱们取得了一些成果，2013年进入关键性的一年，这一年咱们成立了敏捷中心推广敏捷2.0。那时主要主打的是三种方法：看板、Scrum、持续集成。咱们提供三天的训练营打包培训，有不少团队成员加入进来参加这样的培训。

上图是咱们的学员在玩看板沙盘游戏。这是一个从国外引进的很是经典的游戏，可以帮助咱们体会看板方法的精髓。如今这个培训一直持续在作，也收到了很好的效果。

咱们说2013是敏捷推广最红火的一年，这一年，咱们还作了一件很是重要的事：成熟度的评估。

上图是一个成熟度评估模型的一部分，左边能够看到一级二级（后面还有三级）。这是一个在整个公司范围内发起的活动，由敏捷中心去推行，成立专家小组给团队评级，而后在全公司公布结果。这个在当时无形中成为了一个团队的KPI，但当时达到三级的只有四个团队，二级的几十个团队，其余团队大部分还处于一级。到2014年的时候，平安科技有4000多人100多个分组，80%的团队都引入了敏捷方法。

上图中这个活动叫看板大巡游，主要是由教练带队，他们像导游同样举着旗子带领你们一站一站地看过去。每一个团队设计的看板都不同，咱们会考虑美观、实用等方面去给各个看板打分、写评语。而后一块儿讨论有哪些好的地方值得你们学习，最后还会有评比和颁奖。

这是巩固得很是好的一个实践，实施的效果是80%的团队都应用敏捷和看板，并且这么多年在平安可以很好地落地并延续。敏捷在IT领域的看板方法在刚问世时也会有一些争议，可是仍是被不少公司所采用。由于即便是在各个公司文化、管理风格迥异的环境下，看板方法做为一个渐进式的变革方法仍是比较容易切入进去的。

也就是说，它提供了一个更加平滑的路径，可以最大限度地减小敏捷转型带来的阵痛。其实基于现状以及实用至上，这是我在平安科技甚至在整个平安集团可以看到的，一向执行下来的思想和策略。

我看到过一些自上而下的激进变革的例子，到最后有一些是打回原形的，员工对此产生了诸多的误解；也有一些自下而上的变革，通常这样的变革发起者都是比较超前的员工，企业没跟上最后致使员工心灰意冷离职，变革也草草收场。相比之下，我更欣赏平安这种温和的演进策略，可以更持久更有效。

2014 深化

2014年是咱们敏捷深化的一年，基于前几年的成果逐步把敏捷扩展到更大型的项目里来。咱们第一个大型的试点项目是作一个直销银行，这个项目有几十我的的研发团队，其中还有大量的外包，困难也不少。

敏捷转型以前的场景是业务拼命地加班写文档，他们也知道写了要被推翻，可是开发说了没有文档就不能干活，双方的互信度很是低经常僵持不下，后来有人提出来讲：我们不是有敏捷教练吗？

咱们敏捷教练的团队leader林伟丹（平安科技敏捷中心资深经理、Wizard产品商业化总监）、著名的精益敏捷教练吴穹博士都加入了这个项目，咨询顾问带团队作了一个Quick Start，Quick Start也是平安坚持得很是好的一个实践，通常小型项目的时间是大概1-2天，像这样大型的项目可能须要一周时间。

咱们把Quick Start方法总结成36计，再加上引导技术、沙盘演练提炼成两天的工做坊，经过这个工做坊也培养了不少Quick Start的引导师，这个工做坊在平安也是很受欢迎的。

须要全部的决策角色（特别是能拍板的人）都参加到Quick Start工做坊，这样能快速地把业务需求梳理成开发可以去作的迭代计划。达成的效果就是但愿会议结束后立刻就能开始去迭代、可以持续交付一些可见到的东西。

上图咱们在Quick Start以后梳理出来的一个四层的故事墙，从主题到Epic到Feature到Story，看起来仍是蛮壮观的，贴了满满的一面墙。

由于会涉及到多个Scrum team的协做，上图是一个Scrum team的看板，把迭代计划放到上面，最左边大的卡片是用户故事，右边小点的卡片是任务。咱们后面也作了一些改进：用不一样颜色的卡片来标示用户故事和任务，还特别用红色的卡片标示风险。

咱们还有一个专门的看板，用来管理大型项目之间的关联和依赖。蓝色卡片是业务模块、黄色卡片是关联系统。里面会有不少具体的检查点，每一个作完以后就用打钩的方式跟踪风险，上图右边的五角星是标示一些风险大的地方。

上图是一个比较完整的分层看板，右边每一个人都有两张照片，并且只能有两张照片，这是为了不一我的手头同时有多个并行任务、须要频繁切换任务而致使效率下降的状况，咱们鼓励你们先作完一个任务再去领下一个，这样有助于任务快速流动提高效率。最左下方有一大堆卡片，这些都是被舍弃的需求。

上图是咱们30多我的参加的每日站会。咱们可以保证在15分钟内完成，每一个人在上面移动卡片。这面墙仍是蛮大的可以将全部的用户故事、任务都展现出来。

这个直销银行的项目从最开始业务和开发的互相不信任、集体焦灼的状态，到后面启动Quick Start，并取得惊人的成绩：
三个月以后首个版本发布能够内测；
四个月以后直销银行产品正式推向市场；
发布一年以后，用户量突破五百万，并得到中国最佳直销银行的大奖。
这个大型项目的敏捷试点也是至关成功的。

2015 延伸

2015年以前的不少实践都是在帮助咱们把事情作对作好，主要是在解决域方面，而咱们面对的问题是其实咱们不知道什么是对的事情，问题域须要咱们用精益创业和设计思惟的思想来解决。因此，从2014年起咱们开始往敏捷的上游拓展，创建上图这样的产品侧看板，同时咱们引入了一些精益创业的实践。

上图是业务侧看板的一个实例。有澄清、评估、排期，排期就是进入了开发的迭代计划，这个看板到如今产品经理还在用。

咱们也但愿可以往敏捷的下游——持续交付拓展。想要交付得快自动化是不可缺乏的，咱们要去持续验证。自动化测试方面，其实要分层的，而接口测试是比较容易作的，我这边的团队更倾向于由开发把自动化的接口测试写好，甚至把这个部分定义到DoD（Definition of Done）里，以便可以快速地去测试。

原来都是评估从需求准备好到交付的时间，如今咱们能够去评估从创意到投产的lead time，前置时间。上图中纵坐标是天数，从图中能够看出2015年9月到2016年是有显著下降的，也就是说从有了初步想法到最后上线的周期在快速缩短。

这是咱们2015年实践敏捷的一些感悟和关键要素：
总体优化赛过局部优化；
造成有价值的闭环；
强调内建质量。

2016 神兵

2016年，咱们研发管理部开发了一个可以实现：从需求管理到自动化测试到自动部署、持续集成还有一些静态扫描持续交付的工具链——神兵。咱们也能够经过神兵获取不少的数据作价值流的分析。固然这个数据不只是从神兵获取，还从公司不少系统里获取。

咱们在IT领域的能力提高以后，将改进的方向扩展到了更多的领域，好比运营管理、财务管理、行政管理、法务管理、安全等方面，分析这些过程当中的等待返工和浪费，并试图作出优化，缩短lead time。

咱们找到了top 10，也就是最须要改进的十项来进行改善，并取得了明显的效果，好比合同签署、新建子系统、公共平台的接入、移交部署，都有了百分之十几到三十几的提高，公司总体的流程效率提高了14%。

2016年的关键要素：
实现了端到端的价值流建模；
持续不断地消除浪费；
慎用“流程”
这里值得强调的是：不少时候咱们发现漏洞的直觉反应是加一个流程去防范这样的漏洞，这样作的结果是致使流程愈来愈臃肿，组织效率愈来愈低下。

转型心得

回顾一下咱们在敏捷转型路上的一些心得体会。

首先，系统思考。当咱们发现问题的时候，不要像西医同样只针对问题治病，而要从整个系统的角度去考虑，优化整个环节中可能的各个部分。
其次，发挥人的创造性和主观能动性很是重要。
第三，痛点驱动，数据闭环。痛点驱动，经过数据去发现改进的点，而后度量改进的效果。
最后，持续改进，永远在路上。
像平安这样的体量可以作到这样的变革是很不容易的，可能中小型企业的改变相对容易一些，咱们经历了这么长时间的尝试和实践，后面可能就能够少走一些弯路，也许进展会更快一些。

团队如今的敏捷实践

最后分享一下团队如今的敏捷实践。

这是我辅导的一个叫伺客的团队，作在线云客服项目。咱们会有一个这样的做战室，全部的角色都坐在一块儿，包括产品经理、先后端开发、测试等，你们可以很方便地沟通，效率也有了很大的提高。从图中能够看到这个项目室的四周也有不少的看板。

随着如今团队的扩张，不少异地的小伙伴加入，好比成都、深圳等，咱们的看板也从本来的物理看板换成了电子看板，由于咱们有神兵的支持，因此咱们能够把全部的任务、需求、缺陷、测试用例等都放到神兵的系统里，每日站会改成站在触摸屏的电子看板前展开。

我对这个看板作了个小小的改动，把咱们的DoR、DoD以及一些站会的提醒写成卡片贴到触摸屏的四周。下面还有一个屏幕来作CI监控，以及一个Sonar的扫描。

我还编了一些口诀来帮助你们记住咱们的敏捷实践：
自治团队轮值表
开会严守时间盒
需求准入实例化
任务拆细两天工
开发单侧接口测
前端后端需并行
内建质量都有责
CI失败立刻修
代码review面对面
技术债务日日清

咱们是一个自组织团队，在平安科技有不少人复用的状况，这是很难避免的，想找一个专职的Scrum master更是难上加难，因此咱们就让你们轮流担任Scrum master，主持各类会议，有一个轮值表贴在墙壁上。

开会的时候，包括需求的梳理和澄清都要严守时间，一个需求的澄清不能超过15分钟。若是有不少不清楚的、团队提出质疑的地方，就须要先hold住回去弄清楚了再回来说。

咱们但愿需求准入实例化场景化，让你们能有一个统一的语言清晰地理解。

还有任务的拆细，必定要保证这个任务在两天的时间里可以完成；开发人员要负责单元测试和接口测试，先后端是并行工做的；内建质量每一个人都要负起责任来；一旦有CI失败立刻要有人去修复。

由于咱们你们都是坐在一块儿的，面对面沟通很是方便，包括代码review。咱们有Sonar扫码监控还有哪些技术债务，随时发现随时修复，咱们也预留了一些时间去解决这些技术债务。

Q&A：

Q：如何上线快，风险小?

A：作互联网的都有这样的诉求，但愿快速上线。肯定MVP（最小可行的产品）。如何去定义一个最小的可行产品，快速地开发快速地上线，而后获得验证？埋点也很重要，咱们要去分析用户的行为，由于咱们会有不少假设，必定要经过真实的用户去验证这些假设是否正确。

Q：有些老板或者管理者思惟固化不肯意改变，如何让他们接受你的提议？

A：如今应该不太会有说为了作敏捷而作敏捷了。咱们必定要告诉管理者敏捷可以解决什么样的问题、可以带来什么样的好处，这样才有可能会引起一些改变。固有思惟每一个人都会有，特别是老板，可是咱们要相信他们既然能坐在这个位置上，应该是有不少成功经验的累积，那些成功经验可能就是基于他以往的一些方法，咱们如今是提出一个新的方法，他没有尝试过，因此有一些顾虑和担忧也是正常的。

做为敏捷教练，咱们不少时候都是基于痛点去切入的。

首先要深刻团队、深刻企业了解真实的需求和想要解决的问题。

而后看看已有的实践哪些能够逐步引入并取得成效，用小成果来巩固这些实践。

同时领导可以看获得的度量指标也是不可少的，要让高层可以看获得这个方法带来的改变，让他信任咱们，继而再扩大实践的范围。

Q：对于跨业务线协做有没有好的方法+工具？敏捷强调的是每一个人都是主人翁，但对于国内的公司环境是广泛非扁平管理，敏捷的理论与实际应用是有差别的，怎么看待这个问题？

A：跨业务线的方法和工具仍是不少的，主要看你们的需求，若是全部人都在一块儿办公，有一个物理的看板也是不错的，若是在不一样的地方就须要一些在线的工具来支持。还有就是咱们是否是多团队协做的状况，有不少大型的敏捷框架，好比LeSS、SAFe、scrum of scrums均可以用来解决协做的问题。

敏捷强调每一个人都是主人翁，而国内的环境大可能是非扁平的管理，我以前还蛮理想主义的，对这个问题也有纠结的时候。我当时有顾虑：这样的环境是否是可以支持咱们作一些敏捷的实践呢？事实证实其实也是有很多事情能够作的。

虽然咱们在组织架构上很难说作到扁平，也不像国外那样比较宽松的管理方式，可是其实咱们在一些小的环境里是能够作得很好的，好比我带的这个伺客团队，你们在一块儿就很是融洽，咱们也没有什么层级概念。虽然有些人仍是偏向management contorl的方式，可是其实也会慢慢被影响。

咱们也提供了不少教练和引导技术去帮助这些管理者，包括我曾在部门推行的管理3.0和读书会等，这些先进的理念你们也很容易接受。

Q:敏捷团队有效性衡量指标除了需求完成率、发布速率等，还有什么别的具体的指标么？

A：说到度量实际上是一个很大的话题，需求完成率、发布速率等是一些指标。咱们但愿经过度量达成什么样的目的？得先明确这个目的再来肯定要度量什么。

好比咱们但愿流动效率更高，那咱们就须要知道需求从开始想法到启动开发到完成须要的时间大概是多少、每一个环节耗时多少。而后借用价值流分析很是有用的一些工具来帮助作一些改进。好比咱们可能从一个需求产出到发布须要三个月的时间，但实际工做在这个需求上的时间可能只有五天不到，那咱们能够算一个百分比，而后想怎么可以让它加快流动，随之而来的就会有不少方法和策略能够用上了。

Q：主要是敏捷跑得快了，质量好确定是前提，不能妥协，可是感受敏捷和DevOpS在应用中或多或少有点削弱了测试，对此您怎么看？

A：确实质量是不能妥协的，我发如今我们国内作互联网都仍是偏向糙快猛的方式，尽快地先上线再说，但实际上质量是一个很大的成本。

敏捷和DevOps实际上应该是增强测试，更多的自动化。而现实状况是你们都在分析计算ROI、急着去赶某个时间点，有的时候可能确实会弱化了测试，这并非咱们但愿看到的。

开发和测试在融合，咱们也但愿业务、产品经理、开发、测试可以在一块儿把需求实例化，而后经过ATDD在整个过程当中保证质量。质量不是测出来的，而是在需求产生的时候、代码构建的时候就须要保证的。

Q：理论和实践有距离，现实也会有误差，不少团队中专职测试人员或多或少都有在减小。如今平安开发人员必须作单元测试吧？还有专门的系统功能测试团队吗？

A：咱们会有一些专职的测试，但不是说越多越好，有的时候专职测试多了咱们反而容易产生依赖。咱们更倾向于让开发团队作好自测，作好自动化接口测试，就是说必要的测试都是由开发这边保证、质量也是由开发这边保证，咱们逐步但愿培养每一个人都能是多面手。

单元测试是确定要的。专门的团队负责系统功能测试比较少，多数是和开发在一块儿的，非功能性测试会有一些，好比压力测试、安全测试会有专门的人来负责。

Q：如何转型成为一个敏捷教练？
A：首先，要看一下本身是否是一个愿意持续学习的人，是否是一个有开放心态的人，是否是一个愿意去帮助别人的人。这是一个很好的基础，若是具有这个基础就能够逐步地去学习一些敏捷的实践。

其次，我以为有一些好的团队可以让你体会到敏捷的好处，好比我曾经在Autodesk的时候就很幸运地带一个特别优秀的团队，你们很乐意去尝试各类实践并承担各类工做，包括咱们也作了ATDD、以及一些看板的实践，你们都可以感觉到它的好处，包括我本身。

第三，作一个敏捷教练我对这些实践是深信不疑的，我相信它们能给团队给你们带来好处，而后我会去读不少的书、和社区里的小伙伴交流、参加一些大会听听其余公司是怎么用敏捷来作各类实践的。

最后有当敏捷教练的机会必定要尝试，若是发现还有些技能不足，再想办法弥补。

推荐书籍：http://www.scrumchina.com/res...