本文为林伟丹老师线上分享《拉动价值，持续改进——平安精益敏捷转型之旅》实录，后附与学员的互动问答。
编辑：麦思博 Cynthia
一、背景介绍
先简单介绍一下公司的背景。平安集团已经是一家体量很大的综合金融服务集团，目前在世界五百强企业里排第39位，在福布斯世界2000强里排第16位，平安科技的定位是平安集团的创新孵化器和高科技引擎，平安科技在IDC FinTech全球排名是第38位,是前50位中唯一上榜的国内企业。
我们的故事将从2011年开始展开。2011年之前平安的研发过程管理还是一个非常标准化、规范化的严谨的体系；从2011年起有一些变化和变革开始发生，本文将回顾这7年的历程，每一年都会有一个敏捷的主题、有持续演进的方法，以及一些相配套的推广策略和举措。
从上图中可以得到一个信息：敏捷转型的过程其实也是一个迭代式、实验性、基于反馈驱动持续优化持续完善的过程，也就是说敏捷转型的过程本身，也需要用敏捷的方式来推进。
2011 ——元年
2011年是我们开始敏捷转型的第一年，我们称之为“敏捷元年”，万事开头难，这是一个新的开始。
这一年，我们开始构建了平安的第一个、第二个特性团队，并且在渠道侧的业务里开始做一些尝试。通常我们会选择渠道类的、互联网类的系统研发团队来做敏捷的试点，因为他们的系统特点更适合业务的拉动。
背景
平安做了很多年CMMI（包括项目管理体系用PMI），构建了一套标准化、规范化的体系，有一级、二级、三级、四级的流程图，输入输出每个角色分工明确，步骤清晰，输入输出定义得非常仔细，同时整个管理方式也是基于过程的管理，比如我们内部实行的过程和产品的质量管理。总之，就是有严谨的过程体系，确保所有团队都按照这套体系来执行。
那时平安的开发版本周期大概是2个月，这两个月不是串行的，中间有一个交叠、并行的阶段。比如两个月里前一个月做开发，第二个月做测试，那么在前一个版本做测试的时候，后面一个版本就开始做开发，所以这两段是交叠在一起的。这样的方式会带来一些问题：比如开发人员会不太专注，要处理这个版本的开发需求，同时还要修复上个版本的缺陷，有时候甚至会变成恶性循环，开发无法在开发阶段保证质量。
变化的开始是基于一些外力的驱动，整个互联网的转型，已经可以慢慢地看到这种趋势，平安本身也受到BAT等互联网公司很大的冲击，平安集团的高层有非常强的危机意识，我们必须主动求变，我们的竞争对手其实就是BAT，如果不主动求变，我们可能就会被他们所颠覆。
在2011年，我们发起了几件事情：
首先，我们开始倡导一种更灵活的开发过程体系。不再是用同样一套标准化、规范化的流程来要求整个公司几千个开发人员的开发行为，而是希望更灵活、更多样化，鼓励大家适当地定制适合自己的开发过程。
同时，我们开始探索如何提升整个过程的效率。我们发起了一个项目，叫“提升开发过程效率百日行动”，就是用100天的时间必须把整个流程的效率提升。
为了达成这个目标，我们采取了很多措施。
比如评审，我们会挨个检查看每个评审是否必要，哪些人参加，用什么样的评审方式，怎样提高评审的效果和效率。
比如文档，哪些文档是需要保留的，哪些文档是过程性、沟通性的文档，不需要做太多强制性的要求。
比如工具，如何在移交部署这些工具上做到更大程度的半自动化或自动化，来提升过程的效率。
同时在这一年，我们开始启动了敏捷开发的尝试，我们做了两个项目，后面会简单分享这两个项目的情况。
实践案例
第一个项目是网上销售保险的系统，这是一个渠道侧的系统，利用互联网作为销售渠道来销售传统的保险产品。这个项目不管是业务方还是IT方，都希望能够尝试一些跟传统不同的开发过程管理方式，以应对市场的挑战。这个市场的挑战很大程度上可能就来自阿里，因为阿里也在做同样的业务，大家觉得如果按原来的方式我们很难在竞争中立足，所以需要尝试一些新的方式。
这个团队可以说是平安的首个特性团队，所谓feature team就是这个团队拥有能够完成某个完整的业务特性的所有技能和职能。团队也开始用一些简单的可视化的方法，比如上图是他们当时的看板，尽管从现在专业的角度来看这个看板显得比较初级，但这并不妨碍这种方式非常大地帮助整个团队提升了沟通和协作的效率。大家每天都会聚在一起基于透明的信息分享进展、讨论解决问题。
实施效果
这个项目的试点大概进行了半年，试点的效果非常好，效率提升了、质量也得到了保证，如图所示：
上线周期从2个月缩短到两周；
外部合作伙伴接入的周期从3个月缩短为1.5个月；
车险网销需求开发产能提升30%；
版本测试周期压缩一半，生产问题减少70%。
我们还同时启动了另一个团队的试点，当时叫P2P，这个概念大家都很熟悉，那个项目团队做完敏捷试点之后第二年从平安科技独立出来，发展成为今天的陆金所，陆金所是目前国内最大的独角兽之一，估值相当高。
关键要素
2011年的试点之所以能取得这样立竿见影的效果，我们把它总结成几个基本的要素，看起来很简单，但往往最简单的原则如果善加应用起到的效果是非常显著的。
与客户紧密协作，我们希望业务、IT围绕一个目标组建同一个团队“one team one dream”，而不是各有各的目标，各自为政。
可视化。我们采取了简单的方式，让各种信息透明，构建了整个团队包括业务方和IT方相互信任的基础。
面对面沟通。这是一种最有效、传递信息损耗最少、效果最好的沟通方式。
加快反馈速度。这种反馈速度的提升不仅体现在业务上，我们更快地见到价值，更快获取到用户的反馈，基于这些反馈来迭代完善产品设计。也体现在质量上，我们会更早地获取质量的反馈，比如持续集成构建失败，我们会以更小的代价，更早期地、更低风险地去修复这些问题。
批量的减少——灵活应对fast feedback。我们基于迭代的方式限定了在同样的迭代时间窗口内批量是有一定约束的，小的批量保证了我们可以以更快的速度交付价值。
2012——起跑
接下来到了2012年，这一年我们还是继续尝试和探索精益敏捷开发的模式，跟2011年相比不同之处在于：
第一，扩大了试点的范围，希望从不同的场景、从更多样性的系统团队里去验证这种新的模式是否有效。
第二，我们开始选择一些核心的金融业务系统，看看这种方式是否能行。
实践案例
先分享一个保险交易系统的案例。上图是当时这个团队使用的看板，基本具备了一个看板系统应该有的要素，可以看到有些地方颜色不太一样，比如有一些红色、黄色的小纸片，从视觉效果上来讲红色、黄色一般都是代表需要关注的内容，所以通常来说，要么就是这个用户故事卡片遇到了阻碍，我们需要消除这个阻碍事情才能向前推进；要么就是某个程序缺陷我们还没有修复的。
同时还看到看板里有几个大的×，这是团队用来约束在制品，约束并行进行工作的一种方式，打×的空间是不能往上放卡片的，卡片只能放在没有打×的地方，这就限制了并行进行工作的数量，从而可以缩短每个卡片交付的时间，同时能促进上游下游之间的相互协作，尽快地让工作完成，而不是一厢情愿的推入更多的卡片。
实施效果
这是一个比较常见的度量分析工具——累计流图，我们可以从三个角度来看：横向地看，图中标记的黄色横向区间是表示每一个需求从进入看板系统到出去（可能是发布上线或者验收完成）所历经的时间，可以看到这个团队的周期大概是3周，横坐标的刻度每一个刻度点大概是一周，3周的时间其实对于一个传统的保险业务系统来讲，已经是非常快的交付速度了。
除了横向地看lead time，就是周期时间之外，我们也可以看两条线之间纵向的距离，这代表WIP——在制品的多少。
还可以从第三个角度去看它的斜率，就是横轴纵轴之外的斜的方向，代表整个团队的工作速率，或吞吐量，就是单位时间团队能够完成多少个需求。这个图表达的信息非常丰富。
上图中有四叠卡片，项目做完之后，项目经理想了一个方式：把所有的需求和任务卡片分成四类卡片，分别代表原始需求开发完成的、原始需求没有被开发的、后来新增的需求、技术任务。
我记得比较清楚的是，当时我们去向CIO汇报敏捷的进展，整个汇报过程里其他的他都没记住，唯独对这一页印象非常深刻。印象深刻的地方在于原来这个项目一开始提出的需求有40%是没有价值、不需要被实现的。这一点对大家的触动也非常大，非常直接地体现了敏捷开发、敏捷项目管理的指导思想是以价值为导向。我们总是确保价值最高的需求能够优先被实现，价值不高的需求会被排在后面甚至永远都不需要被实现。
关键要素
这一年，我们将范围扩大到核心业务系统的敏捷试点也取得了比较好的预期效果， 总结2012年敏捷转型的几个关键要素：
建立思维方式：延迟决策，和快速流动；这是两件事情：一是尽可能地推迟决策点，是不是一定要做这个需求？这个需求要做成什么样子？排期排在这个版本做还是下个版本？决策尽可能地晚，以保持更多的灵活性；二是一旦进入整个研发过程，进入看板系统，我们希望它快速流动，尽可能快地交付到用户手里。
交付价值胜过交付范围；项目是否成功的衡量标准更多以价值为导向，从价值视角来看，就算是一丝不苟把原来所有的给定范围100%实现，在这个上下文中也没有太大的意义，因为其中40%的需求是没有价值的，就算上线之后也没有人使用，或者实际用户并不需要这些功能。
通过约束限制在制品数量来拉动系统；在小批量的前提下才能实现拉动。
通过看板实现阻碍和问题的可视化。在看板上用红色和黄色标记需要关注的、需要升级的、需要优先被处理的问题，一旦这些问题被解决，流动就会非常顺畅，流动效率会非常高，价值可以更快交付到用户手里，我们能更快地得到用户的反馈，产品迭代响应能力会更强。
2013 ——推广
经过前两年敏捷试点的经验积累，2013年我们开始正儿八经地在组织级、公司层面推广和推进新的方法和新的变化。
实践案例
首先我们构建了一套平安的敏捷方法体系，当时取名为“敏捷2.0”。这套方法体系主要是基于Scrum、精益看板、极限编程（特别是持续集成）相关的一些内建质量的实践。基于精益和敏捷这种高度兼容的价值观和原则，我们兼收并蓄，将不同的实践应用到团队的工作过程中去。
接下来是培养大家的技能，我们组织了很多场培训。上图展示的是看板方法的培训，我们有非常专业的沙盘模拟道具，可以从中体验基于看板的拉动式的开发管理过程。
敏捷中心还设计了敏捷成熟度的模型，从多个维度包括业务、团队、过程、技术等方面来评价一个团队的成熟度级别，并且跟公司本身的荣誉体系集成，表彰成熟度级别高的敏捷团队，给他们一些激励，让他们成为标杆，起到示范作用，让更多团队效仿，从而带动公司敏捷氛围的形成和敏捷行为模式的建立。
这件事情本质上是在拉动团队的行为，倡导一些好的行为方式，实际效果也非常好，大家都主动地向更高层次的级别改进和进化，从各个角度想办法提升，包括IT和业务的协作、看板的设计、改进机制的建立、技术实践的优化等。
还采取了一些措施促进这些优秀实践在整个组织层面的沉淀、传播和分享。我们把这些实践组成一条知识的走线，不强制每个实践每个团队都必须采用，而是把精力放在发现好的实践，一旦有好的实践，把它总结出来通过走线传播出去，其他团队如果觉得好用，对其有帮助和借鉴作用，就从这条走线上拉下来为我所用。我做了很多这样的事情。
上图展示的是一个活动“看板大巡游”，活动的形式是：可以自愿报名，报名后每个团队出一个人参加活动，有一个教练举着旗子，像导游一样带着每个团队的代表到各个团队的现场去观摩和评价每个团队的看板，从中互相学习，看板巡游完一圈之后大家回到一个教室或者空间，集体讨论和分享觉得哪个地方好、哪个地方可以借鉴、回去之后怎样根据学到的东西改善自己的看板设计或者流程，从而起到好的看板实践相互分享的效果。
实施效果
2013年推广的结果：80%的团队应用敏捷和精益开发的方法，大家都基于自己的团队特点、系统架构以及实际管理诉求去设计和演进自己的看板系统、敏捷的实施方式。从上图可以看到没有任何一个团队的看板是长得一样的，我们鼓励百花齐放，做出个性化的符合需要的看板系统。
关键要素
总结几个关键要素：
采用渐进式的推进变革的方法，基于现状可以不去变革现有的职衔、分工、流程，而是用一些可视化的方式更高效地识别整个流程里的痛点和阻碍，持续改进提升整个系统的效率，这种方式的好处是尽可能减小变革的阻力。
鼓励百花齐放，激发团队的创造力。看板是很讲求流程的，包括规则。每个环节从doing到done，要符合什么样的DOD，从每个环节的done到下个环节的doing，要设计一些什么样的挑选规则，或者协作规则，其纪律性和流程性很强。但不同以往CMMI的流程管理方式，这种流程规则的演进是完全基于团队自身的需要，由团队共同决定和演绎的，而不是一套统一的流程适用于所有的团队。
不陷于方法门派之争，实用至上。一开始大家对这些敏捷方法理解得也不是很透彻，在没有理解透彻的情况下难免会产生很多困惑，比如方法和方法之间是不是不可兼容的，是不是有一些冲突的地方，能不能集成在一起……会有很多疑问。但后来随着大家理解的深入、功力的加深，这种问题慢慢地就减少了，大家最后达成共识：不管用什么样的方法、工具都是为了解决用户的痛点，都是为了帮助用户达到他希望达到的目标。所以可能我们口袋里有很多好东西，像哆啦A梦一样有百宝箱，有很多武器，我们需要从目标出发，怎样帮业务实现他的目标，怎样帮业务解决他实际的痛点，然后考虑用不同的武器，或组合武器来解决这个问题或实现目标。这样想思路就清晰了。
2014 ——深化
基于2013年推广的成果，2014年继续深化这些敏捷的变革，比如在大型的金融项目里怎样用敏捷的方式来管理；比如我们怎样促进这种持续的协作式的改进，都是我们要去攻克的问题。
实践案例
分享一个案例：2014年我们做了一个大型的创新性的金融项目——做一个直销银行。在2014年这还是一个比较前卫的事情，国内还很少有银行真正实现直销的方式。所谓直销银行就是说，不用去实体的银行柜面，通过虚拟的方式就可以开户、存钱转账、买理财产品、管理财富。
我是以教练的身份出现在这个项目中的，当时面临的困难非常多：
第一，整个业务的模式是创新性的，虽然国外已经有了一些比较成熟的应用，但国内还没有，大家都处于摸索中，到底怎么做这件事，需求处于高度不确定性状态。
第二，技术架构、技术方案也是完全不确定的。比如作为一个创新性的银行系统跟传统的核心银行系统，账户有什么关系、要不要打通、是用一个账户还是另外有一个子账户……这些问题都不明确。
第三，项目的时间非常紧张。老板的老板向他的老板做了承诺，这个项目一定要在3个月内上线，无论如何，这个时间不可协商，但需求的量非常大、不确定性非常高。
第四，团队情况比较复杂，先说研发这边大概有30个人，其中28个是外包人员，只有2个是内部的，这2个内部的人中还有一个是从别的部门借过来的项目经理，另外那个是SA，做需求分析的，相对比较懂业务。
上面4个问题还不是最困难的地方，最大的问题在于：我去的时候发现整个项目完全没有进展，推动不了，但时间在一天一天地流失，离3个月的时间底线越来越接近。
那大家都在干嘛呢？业务的同事有些是从机构抽调到这个项目组来的，他们每天晚上都在加班加点地写需求、写文档，文档写了很多，但过去一问他们都说这些需求不靠谱，过两天一定要变，现在压根想不清楚后面要做些什么东西，但IT要求一定要写，需求不写出来IT不开工，所以只好硬着头皮写了。
这是一个典型的传统项目管理甲乙方对峙的形态，相互不信任，整个项目推进非常困难。我们开始采用一些不一样的方式，希望能在这样大型的项目里用敏捷的方式确保项目成功。
上图看起来场面很宏大，实际上是为了把IT和业务拉到一起更高效地推进项目，所以找了一个新的场地，有一整排桌子都是空的，正好借这些桌子以用户故事地图的方法梳理整个项目需求。
大家的工作方式就像workshop（工作坊）一样，每天有些时间是大家聚在一起研讨，在桌子前面三三两两地讨论，卡片可以合并、增加、删除。另外一些时间大家领任务然后各干各的，比如有人去做市场分析，有人去研究竞品，有人去设计静态demo，或者交互稿，有人去电子工具里做一些记录和整理。
我们将目光拉回桌子本身，可以看到有黄色、蓝色、绿色等不同颜色的卡片，这代表了几种不同粒度不同大小的需求，我们总共大概用了240张卡片，来梳理和分析整个项目的整体需求。
在这个过程里，IT和业务双方构建了一个非常好的协作机制，沟通效率非常高，确保了整个团队所有参加工作坊的同学都完整地了解了我们的愿景、实施的整体进程，包括需求风险、技术可行性，信息得到了高度共识和一致理解。
在讨论相对稳定之后，大家会把这些信息上墙，把它们都贴到墙上，这面墙就在工作区的旁边，随时可以查阅，可视化的效果非常好。另一个层面来说，领导尤其是业务领导也时不时地会到IT的工作场来看，所以大家可以基于透明化的信息，一起沟通项目的进展情况，包括有哪些问题需要升级，怎样更快地实现业务目标。
把之前那张图中绿色的卡片抽走，绿色的卡片相当于story-用户故事，把蓝色卡片留下，蓝色卡片相当于feature，feature是相对来讲用户产品更完整、更具有可发布市场的价值，把它留下用来安排迭代和版本规划。
我们划分每两周做一个迭代，每个迭代都必须要达到一个业务目标。横向的每一行都是一个迭代，比如第一个迭代，最左边的卡片上标注了它的业务目标：信用卡用户要能够存钱转账且购买两个理财产品。实际上我们可以做到两周之后，不需要三个月，就可以发布第一个所谓的MVP版本。
同时很重要的一点，是在这4个迭代的下方还有很多卡片，这些卡片是什么意思呢？我们跟业务经过充分的沟通，大家从思维上达成一致：一定要确保3个月之后这个项目成功上线，所以那些具有核心价值的功能一定要实现，但其他一些辅助性、支撑性、锦上添花的功能可以协商，如果时间来不及可以在后面的版本再继续优化，如果时间来得及可以多做一点。
对关联方的管理，我们也用了一些可视化的实践。在平安做项目最困难的一点是涉及到很多的专业公司，因为综合金融互相交错，一个项目可能得十个公司配合才能做成功。
我们也用这样的方式，每个黄色的卡片代表一个关联方，跟关联方对接的状态，比如需求是否谈好、有没有连调等我们都会通过可视化方式跟踪，所以大家每天也会看看关联方管理的白板，如果某些地方还有风险，还有未解决的依赖，抓紧时间去解决。
团队还建立了一块大型的分层看板墙。这里体现出很多专业的管理方法，比如横向泳道来约束并行进行的需求的数量，比如做了需求的分层，每个需求的前端、后端、iOS、Android，会区分不同的任务卡片，先分层后面再合在一起做验收。
这样整个流程更加清晰，比如在前面会有一个选择队列，在图的左上角可以看到4个小格，我们会填上这4个小格，当后面的开发过程中有空余的开发能力的时候，会从这个选择队列里拉出一个新的需求来做，同时，把整个流程过程中的排队、阻碍拥堵可视化出来。
从上图可以明显地看到，测试环节中有很多排队和积压，在下方也堆积了很多的内容，这都是有状况的，当时是因为在银行搭建一个新的环境非常困难，这阻碍了很多卡片的往后流转，看板的可视化对该问题的解决起到了很好的效果，业务高层过来看了几次之后帮忙在银行内部协调，这些环境问题最终得到解决。
整个团队会基于这样一面看板墙来开站会，每天早上花少许时间同步，哪些卡片存在阻碍，需要哪些人提供什么帮助。
实施效果
该项目的实施效果非常显著：我们按时达到了项目预期的目标，3个月后项目首个版本发布内测。4个月后正式推向市场，1年后用户量突破500万，2015年获评“中国最佳直销银行”大奖。
关键要素
从该项目提炼出敏捷项目管理区别于传统项目管理的一些特点或范式：
确保按时交付。
区分核心功能与次要功能，确保核心功能高价值、按时交付。
细节范围可以协商。
绝不牺牲质量。牺牲质量的坑后面要花更大的代价来填。
呵护业务与IT的互信。
上图中右边的图是传统项目管理方法与敏捷项目管理方法的区别。图中展现得很清晰：
左边是传统项目管理方法，会固定范围，基于范围分解WBS，然后估算工时、资源和成本。时间一般很难改变，团队也很难增加预算，所以最后往往牺牲的是中间的质量。因为质量很难被外界观测到，这是我们不希望看到的。
在敏捷的项目管理中，我们会固定时间、有节奏地迭代交付，轻易不改变迭代的节奏，固定成本最主要是团队的资源和构成，我们会构建一个稳定的团队，而不是临时召之即来做完即走的团队，我们不希望质量妥协，中间的质量是必须保证的，唯一可以协商的是需求的范围和细节。
实践案例
再看一个持续改进的案例。这个团队做了8次迭代，每个迭代都在持续演进，其管理流程我们在看板上也能直观地看到。本文会截取其中两三个看板图片来进行说明和演示。
上图是一个中间的迭代，相比于前面一页的看板图片我们能够发现，在看板的上方多了一个箭头状的黄色的卡片，它是在可视化我们的完成标准，比如开发从doing到done需要符合一些什么样的标准，团队会形成一个规则，并且把它可视化出来。
右边的看板是下一个迭代，同样可以看到看板最上方有红色的两个方框，上面是一个数字，是团队约定的这个环节的WIP在制品的数量约束。
下一个迭代左边这个图片可以看到在左半部分有一个红色圈起来的地方，把需求分成了几个区域，仔细看里面写了+n、+1、+0等标志，就是说团队会设计一个风险预警的机制，比如对每个卡片会有一个预期的完成时间，到预期完成时间的前一天就会把卡片放到+1的区域；到了计划完成时间当天，就会把卡片放到+0的区域；一旦延期了就会把卡片放到最上方的区域，这时团队就会有相应的规则，比如必须马上加班来解决这种延期造成的风险。
右边这张图能看到更多的变化，比如有一个区块叫做技术验收，对于非需求类的卡片，业务不验收，开发的技术leader会去验收以确保这些技术卡片的产出质量也是过关的。
前面说的是第7个迭代，上图是最后一个迭代的看板样例，可以看到又有一些新的变化，比如在看板最上面有一条横向的泳道，是用来做应急处理的，有点像马路上最右边的应急车道，应急车道上的任务必须全力以赴确保快速紧急交付，并且不受看板大的WIP的约束。
实施效果
该团队的实施效果从效率和质量上来衡量都有非常明显的优化：需求的实现周期有明显的缩短，STG缺陷密度也有显著下降。
关键要素
从中可以总结出：我们要持续不断地去改进，从整体价值流全流程的视角发现并消除浪费，提升整个系统的运作效率。
2015 ——延伸
2015年我们把敏捷实践扩展到更前端，用一些精益的方法来探索产品设计业务需求的管理。
实践案例
这是一块更加端到端的看板，起点和终点都比之前展示的看板更广，它的起点是idea，创意一出现就会进入这个看板，最右侧看板的终点是ROI投入产出的回顾，做完之后基于之前的埋点、运营数据去回顾和检视需求的真正价值，从而发现产品的优化机会。
上图是业务人员使用的看板，不是IT的看板，一个端到端的看板示例，在这个业务使用的看板上IT的工作被缩成倒置第二列，就是实施，实施这一列是IT团队的处理过程，其他环节都是业务用来跟踪整个需求端到端的全流程的。
开发和测试过程的协作也更加敏捷，我们会推广投入产出比更高的、基于API、基于接口这一层的自动化测试，然后开发与测试并行工作，开发在开始编码之前会设置好接口，跟测试达成一致，然后开发编码、测试写自动化测试用例脚本，开发编码完成之后，测试的冒烟性的用例就开始运行，来检测开发的质量，所以开发测试可以做到并行工作。
实施效果
这时会衡量整个端到端的周期时间，从方法上讲，原来是相对比较窄的“系统前置时间”，而上图所展示的是“客户前置时间”，是一个更端到端的、从创意到投产是否能更顺畅更快的交付价值。
关键要素
总结几点关键要素：
整体优化，全局思考，系统思考，而不是只关注局部。
更关注形成整个价值闭环，不光考虑中间的研发部分，而是希望基于价值驱动产品本身的快速迭代和优化。
内建质量。只有在开发的同时保证质量，才能确保整体运作效率的良好。
2016 ——神兵
2016年的主题是神兵，神兵是我们一个工具平台的名称，寓意很厉害的专家、很厉害的兵器。
首先从流程优化上来讲，我们把工作的高度和视野进一步拓宽，不光关注研发本身，不光关注开发测试活动，而是关注到整个公司各个领域的流程，比如运营、法务、基础架构、产品、安全等方面。我们发现，很大程度上阻碍开发效率的往往不在开发过程本身，而在于外围的配套机制，所以我们花了很多精力去优化这些配套流程。
实施效果
上图展示了2016年我们梳理出来的TOP10，就是效率最低、时间消耗最大的10个流程，它们可能包含各个方面，比如合同签批、公共平台接入、移交部署、环境搭建、防火墙开通，甚至包括外包入场等等流程，每个流程我们都着力去改善，并且取得了不错的成绩。
有一个量化的计算，整个公司的整体运作效率提升了17%。采取的方法也借鉴了很多精益的价值流分析的思路，比如什么地方存在等待，能否消除这些等待；什么地方的作业时间太长，能不能用自动化的方式来取代手工作业；什么地方有返工，怎样采取措施去减少返工；什么地方的流程环节可以并行，来加快流转速度，这都是我们考虑的着眼点。
关键要素
我们会建模整个端到端的流程，持续不断地改进优化一切低效与浪费的环节，同时我们也认识到要慎用流程，因为流程一旦增加很难被删掉。
神兵wizard
基于前面这么多年的探索和经验积累，我们把我们的研发过程管理经验、敏捷和精益管理思路承载到我们的工具平台——神兵wizard。
在这个电子工具里同样可以像物理看板一样直观的可视化流程、工作项、分工、阻碍，如上图展示的是怎样去管理阻碍，当卡片被标记为阻碍的时候是不能被挪动的，只有阻碍消除了卡片才能往下游方向流动。
基于电子工具可以非常轻松地分析和管理周期时间，比如累计流图、故事周期分布图、周期时间运行图都可以通过工具自动产出。
也可以基于电子工具构建线上反馈闭环，加入社交化功能让大家更喜欢用这个工具，协作效率更高。
每天的站会可以结合大尺寸、多点触摸的屏幕，在上面轻松地运用物理看板，同时做到很好的数据积累，可拖拽、可录入、可做很多基本操作。
工具本身也做到可以实现比较强的适应性，作为一个看板工具来讲适应性是必须的，因为我们希望团队基于自己的特点去演进他的工作管理流程，所以工具本身要支持这种适应性的演进。
实施效果
大部分团队到后期都实现了两周的迭代交付，部分团队可以做到一周甚至更短时间的版本交付周期。
在平安有一个指标叫30天的需求实现率，就是说每个需求从提交给IT到发布上线记录下一个时间，然后看100个需求里有多少个需求周期是在30天之内的，我们达到了85%以上的实现率。后来觉得这个指标已经体现不出来大家新的进步了，又加了一个2周需求实现率，现在2周需求实现率超过60%，生产缺陷也有显著下降，线上缺陷密度下降了37%。
关键要素
总结几个要素：希望通过轻量的流程、极致的操作体验、更强的自动化能力、包括构建在云端的一些能力，通过这种完整的多层次的质量保证体系，通过智能化的数据预警和分析来实现对整个开发过程的良好支撑。
2017 ——方法+
2017年我们开始思考提炼和抽取平安的方法，并为之取名“平安敏捷方法+”。
上图是“平安敏捷方法+”的简单示意，简单解读一下这个方法体系。
从外向内看，最上面的屋顶代表了平安作为金融属性的大型企业在质量和安全控制上的一些管理体系，左边是精益敏捷的思想，右边是平安的一些组织架构的设计，下方是工具支撑。
再看中间区域，从上下左右四个方向来阐释和解读平安的敏捷方法论。左边是怎么鼓励创新、怎么用低成本的方式来验证假设、怎么做到精益创业、怎么激发更多创意、激发员工内在创造性；
右边更偏现在热门的DevOps，怎么做到开发运维的一体化、怎么把敏捷开发的思想实践延伸到运维领域，构建一个端到端的快速的持续交付体系。
上方需要把视角从小团队扩展到大的产品线甚至是整个企业级的视角，怎么在企业级构建一整套的敏捷管理体系、机制让大家协同目标一起提升；
下方是一些工程技术实践的支撑，比如实例化需求、专项测试技术、DevOps的技术实践等都在这个领域。
我们是从上下左右四个方向来构建我们的核心敏捷方法论。
回顾
回顾一下我们在敏捷转型路上的一些关键的经验和教训。
系统思考。要从全局的角度来思考怎样改善系统，而不是站在局部的视角。
更关注人，在做好事情的同时更注重发挥每一个员工的创造性，激发内在驱动力。
要基于痛点驱动，更多地利用数据构建改进的闭环。
持续改进，改进的脚步永不停歇。没有最好只有更好。
也有一些值得借鉴的教训：
聚焦，控制推广节奏。在时机没成熟的情况下不加以控制，过快地铺开会造成很多预先没有想到的问题。
更早引入全价值流分析思路。如果早一点做这些事情，我们可以更早地从中受益，提升整个体系的运作效率。
更重视改变管理者的思维方式。因为管理者的思维方式决定了管理的整个系统运作的健康程度和状态，改变非常不容易，需要花更多时间去做这件事情。
Q & A
@杨朋：拉动价值，拉动式开发区别于传统的push方式，对工程师个体而言，拉动得越快意味着可能承担得越多，需要付出的时间和精力越大，请问：对工程师而言，拉动价值的原动力是什么？平安的敏捷转型是如何解决对一线工程师的即时激励问题的？
答：其实看板系统设计的初衷，正是为了解决上游盲目向下游传递工作、导致下游工作负荷超出实际承受能力的问题。看板基于实际的开发容量，来平衡需求的输入量。这样做的好处显而易见，需求的流动更顺畅，流转的周期时间缩短。对个体工程师而言，工作更加专注，避免在多个并行工作中来回切换；同时，更快得到自己做的东西的价值反馈，成就感也会更强。
@赵爽：用户故事的估算怎么进行？
答:基于轻量的相对估算法，我们先确定1个规模较小的需求，定义为1个点，其他的需求跟这个卡片做对比。采用斐波纳契数列，1，2，3，5，8，……
@小甚：刚才提到节奏太快铺开不好，您说的太快，有什么表现？
答:敏捷是一种能力的体现，需要积累；它不是一套可快速复制的流程。当时我们在一个大型的项目群，很多个项目同时全面导入敏捷，但又缺乏足够的教练支持，反而造成了一些负面的声音。
@阿牛：如何说服老板招DevOps的工程师
答：回到目标本身。我们为什么要招DevOps工程师？这件事能解决研发管理中的什么痛点、有多痛？预期为企业带来什么样的收益？
@三曹长河月：关联方管理看板的具体内容及关联情况能够介绍一下。
答:这是一个针对关联依赖的可视化风险管理的做法，对于关联系统，可以定义几个状态，例如 关联需求沟通、接口定义、需求排期、开发联调，在卡片上面可视化这几个状态，每搞定一个，打一个勾。
@itker：敏捷不应只是开发的事情，可能会涉及到业务、产品经理、合作方等方方面面，如果这些角色不能很好的配合，很难做到真正的敏捷，尤其是有大公司病的大公司，请问平安是如何做到真正敏捷的？
@MyOwnSoul @叶国栋：作为乙方，如何说服甲方（业务方）一起参与敏捷体系，纯粹的Agile Dev瓶颈还是在业务需求那里？@杨朋：E2E的整体实施敏捷，才可能获得我们期望的效果，局部的敏捷对整体作用有限，现实中很多情形下我们能影响甲方参与和配合的又有限，所以，在on-premise交付模式下的敏捷实施难度和挑战很大，平安的敏捷转型有遇到这个麻烦吗？
答：是的。平安很多交付类研发工作，需求方在一个公司（如寿险、银行、证券），实施方在另一个公司（平安科技），建立端到端的敏捷协作尤为困难。我们花了很多力气，来建立业务与IT双方的信任关系，比较好用的方法例如Quick start，以协作式workshop的方式来启动和规划项目；看板也是有效果的方法，它最大程度上透明了IT的工作状况，很多信任问题主要来源于信息的不透明。
我总结过“敏捷如何提升IT业务互信”三步曲，先营造信任环境，从“找茬”“挑刺”开始转变为积极协同改善合作；再夯实信任基础，业务对IT持续稳定交付能力的信心得到持续增强；进而升华信任关系，IT与业务融为一起，每个人对产品都有很强Ownership。每个步骤的具体改善策略，我共享一个图片。
@李钊：极限编程在敏捷实践中的地位如何？是必不可少，锦上添花还是可有可无？
答:极限编程里有十多个实践，可以分为3类：团队管理、技术管理、技术习惯。很多原则与Scrum等方法是完全相通的，技术实践中，最有效的实践是持续集成，几乎是敏捷开发所必须的，TDD和结对编程可以有选择的使用。
@叶国栋：敏捷项目和供应商是如何结算的？
答：这个问题没有标准的答案。敏捷项目管理的基石在于构建甲乙方的信任关系，共同以价值为导向，快速迭代，基于反馈驱动产品优化。具体的合同形式上，通常会在总包合同（对甲方有利）和T&M（对乙方有利）之间取得一个平衡，例如：基于SOW承诺甚至罚则的T&M结算协议；分期签署合同；合同中界定关键业务目标而不要陷入需求细节。
@大白：迭代交付并不是越快越好，应该根据需求的实现难易度和团队人员不同层次能力的现状而定。这样理解对吧？
答:首先要区分业务场景，对于高度不确定的场景，迭代越快越好，是为了更快的获取用户和市场反馈，我们可以有更多的实验机会，从而离成功更近；而对于相对确定性的场景，或者质量安全非常高的场景，则不是越快越好。其次，快是一种能力，能力达不到，太快只会出问题，我们要持续构建这种能力。
@黄威：平安精益敏捷的实践初衷是什么？银行金融机构力求核心保持稳定，有新业务驱动科技转型DevOps么？目前为止实践的成效如何？可以在金融机构推广了么？
答：初衷是应对市场的快速变化，应对来自BAT向传统行业渗透的强势冲击，平安的危机意识很强，主动求变。相信精益-敏捷的思想、实践，已经是一个必然趋势，我们接触过很多的金融机构，都在谈论敏捷、DevOps，不是要不要的问题，而是怎么做好的问题。
@王绪强_Frank：DevOps落地从哪里入手做比较好？
答:好问题，DevOps的概念涉及很广，包含文化、工具、自动化、度量等多个方面。如果要我说基本的事情是哪些，我建议是：1、逐步构建各个环节的自动化能力；2、促进不同角色之间的相互协作，更高效的协同；3、持续的去衡量这些变化产生的效果和积极影。
@歪猴：敏捷到底是怎么做的？和常规的开发模式有什么区别，能带来什么样的效率，敏捷适用于什么样的企业？
答：本质上可以从2个方面看：从人的角度，激发知识工作者的创造性和内在驱动力；从事的角度，应对不确定性环境，建立“实验-反馈”的新的工作模式。敏捷适用于知识工作及不确定性环境。
@邱良军：敏捷开发真的不需要项目经理吗？
答：这种说法过于理想主义。平安有专职项目经理，腾讯、百度、阿里也都有。当然，“项目”的内涵正在发生变化，传统意义上的项目，以在给定时间、给定成本内完成给定范围作为成功标准；敏捷项目是否成功，更多的需要从业务价值角度来衡量。
@Lydia：精益的实践除了看板还有哪些？
答：精益是一套了不起的思想体系，已经在各行各业实践取得成功，也包括在产品开发、软件开发的场景下。精益提倡系统思考，分析端到端的整个价值流，从中发现浪费和低效、排队和等待，持续的加以改善。看板是价值流的可视化呈现，在这个基础上我们可以综合运用多种实践，例如可视化、WIP约束、需求分层、累积流图、每日站会、需求梳理、定期回顾等。
@阿兔阿兔 @歪猴 ：平安业务和金融相关，对质量要求是很高的，资金不能出一点错，平安怎么做到敏捷又高质量的，会在质量保证上做一些什么工作？大约会花多大成本（或者说耗费的时间比例）？
答：在敏捷实践中，效率和质量绝对不是一个非此既彼的关系，而是互相促进。没有质量内建，效率不可能有本质的提升。我们从流程、工具同时着力，例如流程上严格管控版本出口标准，固化质量问题回朔机制；工具上构建全自动化部署流水线、及自动化质量保障体系。2017年上半年，整个平安科技6000+人研发规模，IT重大故障发生0起，创造了历史最佳记录。
@金婷：敏捷里面的度量一般都怎么做，涉及哪些项？
@Lemon Hong：同问度量的问题，另外还有敏捷里面，怎么做个人的绩效考核
答：从度量的作用上，我们区分KPI与过程度量，前者是外向性的、关注整体绩效；后者驱动团队的自我持续改进。需要特别小心的是，避免把局部在、过程性的指标作为KPI，尤其是带有考核用途的KPI。从度量的维度，我们归为质量、效率、价值、可持续性4个方面来看。
个人绩效考核是有意思的话题，如果你是用KPI管理知识工作，一个建议原则是，KPI只能分解到团队，不要分解到个人（整体并不等于局部之和）。个人的考核，更多的是看这些方面：个人在多大程度上完成了有挑战性的工作目标；个人的行为表现在多大程度上匹配公司的价值观；个人对团队的贡献及对其他团队成员提供的帮助。
@小勤：1.敏捷开发过程真的不需要文档吗？哪些文档是必须的？2.质量管理人员（过程改进人员），如何保证敏捷项目的质量？3.平安的敏捷流程中，都有哪些文档产生？
答：1&3、显然理解有误。系统级文档是必须的（如架构文档），要长期保留并维护；过程性文档是一次性在，取决于沟通需要。敏捷更鼓励个体之间的交流和互动，更倾向于轻量的需求方法（如用户故事）。
2、敏捷项目的质量，不是由外来的SQA来保证，也不是由中心型组织制定的流程来保证，我们强调Build-in Quality（内建质量），由团队自己来保证，每一个开发人员的代码质量自己也要先保证。具体保证的方法，涉及团队快速反馈流程、工作规则、技术实践等多个层面。
@赵爽：敏捷中用户故事估算的时候是否把测试估算进来，还有就是估算的标准平安是怎么评估出来的？
答：用户故事的估算使用轻量的相对估算法，需要把测试的代价考虑进来。具体估算标准由每个团队自己决定，纵向可比，团队可以持续观测并提升自身的产能；不同团队间，横向不可比。当然，对于规模化敏捷的场景，研发同一产品在多个团队，可能会使用同样的一个用户故事基准点，以便进行整体规划和协同。