产品
协作&沟通
看板
思维导图
在线文档
企业微信集成
规划&跟踪
敏捷需求规划
迭代计划&跟踪
缺陷跟踪管理
测试计划&用例
任务&工时管理
构建&交付
代码集成
持续集成&交付
应用&扩展
T魔方
第三方集成
解决方案
轻量协作
敏捷研发
DevOps持续交付
客户案例
支持
在线帮助
上手视频
帮助文档
使用手册
新鲜Show
服务支持
客户服务
小微扶持
合作伙伴
95716
中文
中文
English
Beta
登录
注册
行业案例
black;乐信集团;从艰难出发到全局突破，乐信的敏捷研发之路
扫一扫分享此案例
扫一扫分享此案例
扫一扫分享此案例
从13年成立到17年纳斯达克上市，年轻的科技金融公司乐信在互联网金融的赛道上快速成长。截至2019第一季度，乐信注册用户数超过4220万，旗下拥有 __!!#ff9900 分期乐、桔子理财!!__ 等多款知名产品，打造了集电商智能风险管理、信息中介服务为一体的金融科技生态。<br/> “互联网＋金融”的特色给乐信带来了更多研发管理上的挑战，今天我们有幸邀请到 __!!#ff9900 乐信质量管理中心的胡其丽女士!!__ 来到TAPD思享汇的现场，为大家讲述乐信打造高效研发模式的探索。 ## 一、敏捷：时不我待，艰难出发<br/> <br/> !!#ff9900 __大家下午好，我是来自乐信研发管理部质量管理中心的胡其丽，很高兴能够受邀来参加TAPD思享汇。__!! 乐信是一家年轻的公司，但其实跟腾讯TAPD已经是老朋友了。实现质量和效率的共赢是我们追求的方向，接下来我会为大家介绍乐信是如何打造乐信特色研发模式的。我们的敏捷实践，需要从一次艰难的变革开始讲起。 <br/> ### 1.产品与开发之争：要不要固定发布时间？ <br/> 最初，乐信是7x24小时可以进行发布。这是业务部门期望的状态，却也是开发人员的噩梦。每次上线需求或发布应用就会有告警，开发负责人经常紧张得睡不着觉。 !!#ff9900 __为了降低故障率，开发团队决定改用单周迭代开发的形式，把发布时间固定在周二和周四。__!! <br/> 当然，产品和业务团队肯定不会同意这个决策，我们遭到四五个业务团队的反对。他们在讨论会上直接表明了态度：“业务要发展，你们开发跟不上是你们自己的事情，你们一定要支持我们快速的响应用户和快速的业务发展。周二和周四发布，那是不可能的事情。” <br/> 万幸，我们研发vp、研发负责人扛住了压力。最后老板决定让我们进行这次尝试。这就是乐信敏捷探索的艰难出发，虽然艰难但是最终证明有效。从这次尝试开始到现在大概有三年的时间，我们还在沿用敏捷迭代的方式，这个痛我们算是挺过来了。当然，我们之所以坚决进行这次尝试，和我们的业务特色和发展状态有直接的关系。接下来我就向大家介绍乐信敏捷探索的现实背景。 <br/> ###2、变革背景：乐信的成长烦恼 <br/> 乐信是一家快速成长的金融科技公司，但和所有初创公司一样，乐信也有自己成长的烦恼。我们的烦恼和自己所处的赛道有关，也和我们过快的成长速度有关。了解自身的特点，才能找到最合适的解决方案。 <br/> #### （一）业务烦恼：产品复杂，协调困难<br/> <br/> 作为一家金融科技公司，乐信的业务同时包含了互联网和金融两个方面。我们的研发环节主要有三个特点： __①链路较长：__ 从前端首页的浏览到生成订单的过程中，涉及到风控规则，以及外部接口，整体链路较长。 __②逻辑复杂：__ 业务会涉及到借款，还款以及风控等方面，在研发的每一个阶段和流程当中，逻辑复杂程度高。 __③跨团队较多：__ 因为涉及到业务方、平台方、资金方、风控方技术等方面，所以会经常出现跨团队合作的项目。 <br/> #### （二）团队扩张：让人欢喜让人忧 <br/> 乐信的团队经历了一个迅速壮大的过程。2015年6月乐信的产品加研发只有近百人，到今天四年间有了七倍的增长。团队扩张是把双刃剑，如何实现这么多人协同作战，是提升公司效能的难题。 <br/> ### 3、解题思路：打造敏捷文化和理念 <br/> 打造敏捷不是靠一两个制度就能实现的。研发需要一定的文化作为背景，而我们也打造了乐信自己的研发文化理念。  在乐信的文化理念里，敏捷和质量是原则，管理和工程实际是支撑，最终目标是实现效率和质量的共赢。 !!#ff9900 原则是敏捷：!! 因为我们要快速响应市场和用户，也让用户给与我们反馈。 !!#ff9900 质量是底线：!! 作为一家金融科技公司，质量是我们在研发管理过程当中最重要的一环，是不可以被突破的底线。 在管理实践中，我们会有一些创新的实践，比如产品会用到一些分析的方法和手段。再比如精益看板、故事墙、电子或物理看板等等方法，用它们去让价值的流动可视化。工程实践部分有持续构建、持续集成，自动化测试、服务架构、流水线部署等等一系列实践的方法。 <br/> ###4、工具支撑：工欲善其事，必先利其器 <br/> !!#ff9900 其实我们坚持采用单周迭代的另一个原因，是我们引入了TAPD作为研发管理的工具。从这个层面来看，TAPD也是乐信敏捷之旅的开始。!! 从前，乐信用的还是比较原始的协同方式。需求的来往沟通，其实都是用邮件来进行。后来我们在TAPD的协助下，我们打通了研发中的信息同步难题。 以及开头讲到的单周迭代发布模式。我们当时改用单周迭代开发，因为产品侧还做不到双周发布。到今天，在TAPD的帮助下大多数的团队已经可以进行双周迭代的方式，团队之间的协作难题已经被大大解决了。  除了沟通效率和迭代计划之外，TAPD平台在乐信的实践中还有更为丰富的支持和帮助。我们下面就为大家展示，乐信的敏捷实践是怎样一步步打通的。 ## 二、敏捷实践：六个维度，逐一突破 <br/> 在进行了一系列准备工作后，我们就需要从全局的层面规划乐信整个的研发模式，逐步去化解我们在研发环节中遇到的痛点。 !!#ff9900 乐信的实践中，有六个非常关键的维度，分别是：组织、过程、架构、工具、基础设施和度量。!!  ### 1、组织：打破部门墙，聚焦价值流动 <br/> ####（一）部门墙：该打破的是要打破的 <br/> !!#ff9900 我们首先要承认在工作中，一些技术问题其实是由组织结构带来的。!! 比如早期的乐信团队里，研发和产品同在一个部门下面，所以产品侧的需求天天来找项目经理要排期，理由可能是这个需求非常紧急，或者是老板要求一定要上线。总之，这种抢占资源的方式一直存在着。 组织合作中有一些部门墙导致合作不顺畅。基于这个原因，我们的组织架构从早期的资源共享式变成为以业务为导向，这种闭环式建立了面向由产品而非项目的跨职能的组织模式，为后续我们的敏捷和价值拉动做好准备。到2016年，我们将组织调整成以业务团队为导向，将公共资源池变成了以闭环的方式去走敏捷。组织架构的调整，为我们打造乐信研发模式和实践敏捷带来了一个很好的开端。  ####（二）资源效率：以更快的速度到达用户 <br/> 如果把开发当做一种资源，最初我们最大化的去使用资源，每个开发人员每天要排满需求，可真正值得考虑的问题是我们的需求能否以最快的速度到达用户和市场。  !!#ff9900 敏捷讲究的是用户价值，是需求以最快的速度到达用户。!! 所以组织架构的调整，让我们从早期的只关注开发资源，变成了现在这种聚焦在流动效率上面。现在如果我们想做一个项目，我们会最大化的拉动这个用户的需求或者说用户的价值，让这个价值以最快的速度去面向市场。  从早期聚焦资源效率，到现在关注流动效率的聚焦。现在的乐信聚焦在用户价值以及用户需求上面。这对我们来说是一次重要的组织架构调整，带动了我们做事的方式和方法。 !!#ff9900 TAPD在这个过程中提供了很多的支持，让这种价值的流动变得可视化。非常清楚地呈现出研发瓶颈在哪儿以及应该如何调整。企业的资源应该让价值的流动更快一些，从这个看板、故事墙这些工具中上面就可以看出。!! <br/> ###2、过程：理顺管理流程，善用工具支撑 <br/> 过程跟这个流程有些不同，这里说的过程更偏轻流程和工具的结合。!!#ff9900 把控过程，既包括研发流程化质量管理的过程，也包括运营流程化管理的过程。!! 乐信将这两者打通，将前端的研发管理过程作为价值是输入到给到用户，而用户这边持续反馈，让我们得以不断地去优化和去迭代产品。  当然，如果仅仅有流程还不够的，提升研发效能还需要工具和系统上的支持。我们把研发管理过程中去镶嵌我们的流程。里面也镶嵌相应的工具，这对企业研发效来说是一个极大的提升。 !!#ff9900 在过程中，我们的需求和项目管理都是承载在TAPD上。针对金融产品研发，我们还会采用极为严苛的定制流程。!!  在每个流程的节点，我们都会在TAPD上去设置对应的一个准入检查和评审的checklist。因为每一个过程，输入不可以影响到后面的一个；作为下一方的输入，输出的结果也不可以影响到下一方的输入。所以在每一个节点，我们都会在TAPD上做这种准入和准出的规则设置。 <br/> ###3、架构：搭建稳定环境，减少资源消耗 <br/> 在微服务化了之后，我们发现了研发过程中特别多的问题。 !!#ff9900 其中研发方面，最大的问题就是开发测试环境。!! 环境搭建的耗时大于开发时间，而测试定位、定位环境的耗时又大于项目测试的时间。对运维来说，因为每个项目部署都意味着全套服务，所以资源消耗和维护的成本会非常大。  我们的解决方案是基于环境出发的。 !!#ff9900 我们搭建了一个公共稳定环境，它其实就是生产环境的一个镜像。每一次更新代码、更新服务，我们只拉取更新的服务到项目环境上面。!! 那如果没有更新服务，我们拉取和调用的还是这个stable环境，也就不需要去做全套的部署和维护的工作。  ###4、工具：打破信息壁垒，串联研发过程 <br/> 早期的时候，从研发到发布的过程中每个系统或工具都是割裂的一个信息孤岛。所以到17、18年的时候，乐信开始着手解决这个问题。从TAPD开始，串联需求到发布的整个全流程的一体化。我们做了一个乐效系统，来管理我们整个研发过程。  当时，我们的工具很多，每一个工具和系统都给乐效系统提供API接口，把我们的过程和管理都镶嵌在乐效系统当中。从一开始的版本规划、版本质检测试管理、版本发布和发布观察其实是一体化的。尤其是在版本质检当中，我们把质量管理镶嵌在其中。 !!#ff9900 这里会有一定的质量阀值的设置，必须要达到一定的标准，比如：单侧的覆盖率、静态代码检查的阻断率等待。!! 我们会在每一个节点去根据不同的业务团队的特色设置相应的阀值。在进行管理时，每一个业务都是自定义化去实现的，所以每月走的是同样的系统，但是在过程当中会有一些个性化定制的地方，这也可以使我们在整个研发管理的过程当中，尽量做到 !!#ff9900 __“质量流程化，流程系统化”__!! 的概念。 <br/> ###5、基础建设：联结开发运维，提升工作效率 <br/> 在基础建设方面，乐信的运维开发和运维团队的组织架构是割裂的。这种情况导致脚本运维和手工运维常常陷入低效的困境。为了解决我们运维内部的矛盾，后来我们做了一个叫galaxy的一个平台，由运维、 开发去提供这种Paas的服务，提升基础层面的工作效率。 <br/> ###6、度量：明确评估标准，提升合作满意度 <br/> 接下来到度量的部分。 在早期，我们对度量这一块其实没有一个明确的标准，即使有也是比较零散的。后面我们建立了一个PCB，也就是过程能力的一个基线，主要含有这个三大模块和一个加减分的指标、质量指标、技术指标以及团队满意度。  !!#ff9900 敏捷讲究的最终是人，所以我们最看重的是人跟人之间在合作中是否满意。!! 合理的加减分标准，可以鼓励团队去做一些优秀的实践，同时让不足之处得到监督和修正。我们的PCB中很多的数据是由TAPD开放api的接口，然后才能够实现的。所以需要感谢TAPD对乐信研发管理提供的强大支持。 ##三、展望：打造乐信DevOps模式 <br/> 乐信对未来的研发管理有不小的一个愿景，包括目前我们正在去做的一些事情， 就是打造属于乐信的DevOps的一个模式，TAPD在模式中属于项目管理微服务和持续集成部分。  关于如何去实践乐信的DevOps，我们主要是有一些自己的一些原则，或者说心得： __①价值和理念的先行：__ 价值驱动理念可以保证方向的这个正确性和路径的合理性。 __②从小做起，逐步突破：__ 一开始不要把盘子铺得过大，用小步快跑的方式，一点一点去做起。 __③痛苦的事情有效解决：__ 要清楚现阶段最痛苦的事情是什么。着力解决那些对用户或者业务团队来说最痛苦的地方。 __④用户价值拉动，而非事务拉动：__ 要把交付用户价值放在首位。 这四点是我们落地DevOps时的基础原则，每个团队在不同的阶段，都会有不同的痛点。 今天的乐信在研发管理上依旧有改善的空间，我们会朝着高效的方向继续努力。 <br/> ##结语 <br/> !!#ff9900 TAPD也是乐信敏捷之旅的开始。!! 非常感谢TAPD这样优秀的工具，为乐信提供了如此强大的研发管理支持。乐信和TAPD都在朝着提升研发效能的方向努力，未来希望我们能够有更大的碰撞，收获更耀眼的火花。
