摘要：在Work like Alibaba案例实战系列第二期9月14日的直播中，新光互联无线团队负责人陈联柯为大家分享了如何借助RDC，实现从需求管理，到多团队协作，到缺陷管理以及自动化部署等全流程的无缝衔接，并借助RDC的敏捷管理工具，让敏捷协作更为高效。精彩不容错过！

直播回顾视频地址：

本文内容根据演讲嘉宾视频分享以及PPT整理而成。 本次的分享主要分为以下4个部分： 一、新光集团简介 二、传统的研发方式 三、RDC是个好工具 四、RDC数据化管理 一、新光集团简介 新光集团是一家集实业、地产、投资、金融、互联网、能源和旅游等多元业务于一体的产融结合的生态投资集团。目前旗下有1家上市公司，40多家全资子公司及控股公司，近百家参股公司，资产规模近千亿。新光互联是新光集团旗下负责互联网业务相关的子公司。 二、传统的研发方式 接下来首先介绍新光集团在接触RDC之前所使用的传统研发方式，这里以新光集团旗下的兔波波业务为例。从下图中可以看到兔波波的业务主要分为四个部分，其中兔波波的整个业务线主要可以分为三大块：众包、门店和车配，而这里的“数据”指的是在兔波波内部专门针对于其他三个业务所做的数据收集、分析相关的工作。 兔波波的众包业务与现在市面上比较常见的达达、美团以及饿了么的配送业务非常相似。在兔波波的众包业务里面存在很多角色，包括发单的商家、送单的骑手以及城市服务商、运营人员等的管理方，而且目前这部分也在扩展驿站和闪送的相关业务。以上所提到的这些其实都属于不同的业务形态，目前仅与众包相关的业务就已经有5个项目组在跟进。 门店相关业务其实与菜鸟驿站很类似，也就是各个社区中都会有很多的门店，比如水果店或者小百货商店，这些门店原本都是在社区中独立运营的店铺，当这些店铺加盟到兔波波之后就可以通过收发快递的方式帮助自己吸引客流，同时自己门店中的货物也可以通过众包系统进行配送，并通过车配系统帮助门店进货。所以对于门店这部分也有很多项目组在跟进，为门店店主提供了手机端的快递管理助手、PC端的管理系统，为城市服务商提供了运营管理系统，并为顾客提供的可以实现在线寄件的兔波波微信公众号等服务，而在兔波波微信公众号中也能够提供众包业务中的闪送服务。 第三部分是车配业务，这部分所做的工作是针对城市内部的次干线进行物流配送。车配业务将和门店业务结合起来赋能门店的物流。车配业务也涉及了很多方面，需要为不同的角色比如司机、管理人员以及运营人员提供各自所需要使用的手机应用程序等软件系统。 对于数据业务部分而言，其包括了对于上述兔波波三大业务的数据分析，这部分需要将数据做成报表并及时向老板汇报，从而帮助管理层更好地做出决策。除此之外，还会涉及到对于自己产品的数据分析，比如在应用上线之后，需要采集运行情况的监控数据，并进行相应的版本管理以及应用的灰度发布等。 单是兔波波这样的一个业务线算下来就已经达到十几个项目组，总共四五十个项目成员了。而面对这么多的业务，之前的做法相对比较传统，就是“一个萝卜一个坑”，每个成员负责固定的项目，这样就相当于同时有十几个项目组向前走。从研发资源的把控和安排的角度来讲，整个研发管理的复杂度就会大大提升。如果业务比较简单，只有一两个项目团队，那么使用传统的方式进行管理是完全没有问题的，但是目前单是兔波波这一条业务线就有十几个项目组同时开展工作，那么对于项目的进度和风险的把控以及资源的分配工作都需要管理人员花费大量的时间来进行信息收集和数据同步。所以在面对如此之多的问题的时候，项目的研发管理就会变得令人头疼。 在最早的时候，新光集团在软件系统上做法与很多的创业公司一样：在代码管理方面使用GitLab，需求管理和Bug管理使用JIRA，团队内部的文档共享使用Confluence的Wiki功能。在最开始的时候，新光无线团队采用的还是手动在本地进行打包的方式，而后面随着业务的增多，也逐渐开始使用Jenkins实现简单的持续集成。 而上述的GitLab、JIRA以及Jenkins都是相对独立的系统，新光无线团队从最开始一路走来，对于这一点的体会也非常深刻：虽然这些子系统都能够把自己分内的事情做的很好，但是这么多独立的系统却是无法整体进行打通的，这也是令人非常苦恼的一件事情。所以，在后来新光无线技术团队也开始尝试地去通过整合来解决问题，如下图所示的是新光无线团队内部的开发的一套无线研发支撑系统——无线船坞，图中所展示的是第一个版本。可以看到，无线船坞中提供了：用于实现持续集成的打包中心，这部分是基于Jenkins进行二次开发实现的，能够使得持续集成更加简单和高效；集成了JIRA的Bug中心；代码检测中心，这部分是目前自动化测试的一个尝试，期望能够将整个产品的质量把控前移到开发阶段，所以在这部分也实现了对于静态代码的检测；无线知识库，这部分其实是团队自己搭建的博客系统；团队自己开发的用于承载产品文档的简单Web服务的产品原型中心；希望通过在线化的方式把多个业务的接口协议统一起来的接口协议；实现了对于线上数据的监控的线上数据中心；基于Confluence开发的团队系统。 通过团队的努力，无线船坞中的每个子系统都还不错，并且因为这些子系统都是基于第三方、开源的比较成熟的工具或者系统实现的，所以很容易在原有的基础上搭建出比较好用的工具集合。而后来发现虽然无线船坞这个工具集搭建起来了，但还是会遇到前面出现的问题，也就是无法将这些工具系统化，无法打破各个工具的边缘将它们整合到一起。打包中心和代码检测都是基于Jenkins实现的，可以很容易的整合，但是Bug管理中心与产品原型甚至是接口的文档却是很难统一到一起的。虽然无线船坞提供了统一的入口，但还是需要进入到各自的子系统中。除此之外，还有最关键的一点就是虽然无线船坞集成了如此之多的工具，但是这些工具还是独立地在运行，这样就导致它们所产生的最具价值的数据无法进行整合和分析，所以虽然已经很努力地去实现了，但是无线船坞还远远没有达到最初所预想的将整个研发流程从需求分析到开发、测试、再到上线有机地串接到一起，比如在需求提出之后，判断到底哪些需求可以排进项目中去，并将开发的完成情况等有机地串接在一起。所以新光无线团队非常希望有这样的一个能够打通研发全流程的工具或者系统，可以实现研发流程的记录、监控和反馈以及在最后项目完成的时候进行数据分析。 三、RDC是个好工具 后来经过一位阿里巴巴的同事的推荐，新光无线团队开始接触RDC这款工具。RDC可以用于项目研发全流程的管理，它是由阿里巴巴内部的AOne系统开放出来的。接下来这部分将与大家分享新光无线团队在使用RDC过程中的一些收获。 初识RDC 目前阿里云的服务已经相对比较成熟了，像新光集团这样初创型的公司所使用也基本上都是阿里云的服务器，除此之外也使用了很多阿里云所提供的服务，所以总体而言对阿里云并不陌生。但是因为阿里云所提供的功能种类非常多，如下图所示的菜单中就已经大概有上百项的服务了，而RDC服务就在这样的一个角落里，如果不是有同事推荐其实是很难知道的。而且目前RDC还处于公测当中，所以阿里云也还没有大规模地向外推广，所以新光无线团队当时能够接触到RDC还是比较幸运的。 磕磕碰碰上手 新光无线团队在了解RDC之后马上就开始了试用，而在一开始的试用过程中，可以说是磕磕碰碰地上手的，因为单单RDC自己的功能就已经非常多，非常强大了，并且它又集成在阿里云上面，而阿里云本身的产品又非常丰富，所以在刚开始使用RDC的时候非常不习惯。因为当点到产品与服务菜单，阿里云所有的服务一下子都跳出来了，但是当时并不了解这些服务与RDC究竟有什么关系，所以在一开始，新光无线团队有一种无从下手的感觉。但是在后来使用的过程中，团队慢慢地开始摸索出了RDC的使用套路，也逐渐地习惯了RDC的使用。 RDC是个好工具—综述 如下图所示，整个RDC主要包含几部分内容：第一部分就是最上面的“我的”、“项目”和“服务”等这几大类目。下图中左侧是与此时所选中的类目所对应的菜单，“服务”类目中则列举出来目前企业中所有可以使用的功能。图中右上角则是一些常用功能的入口，包括设置、添加项目以及添加企业等。图中中间部分是显示区域和操作区域。在几大类目里面，“项目”部分是使用频率最高的，这是因为RDC本身就是研发协同工具，所以如果想要发挥出RDC最大的价值，那么肯定是需要被大型的研发团队一起使用的，后面的分享也会主要围绕“项目”这部分进行。 RDC是个好工具—我的 “我的”类目部分的菜单包括工作台、应用、代码、分支、实验室和设置等。无论是个人开发者还是企业开发团队，工作台中展示的都是与个人相关的内容，这部分使用的频率也比较高。当进入“我的”部分之后主要看到的就是工作台中的内容；应用模块则是一份代码构建之后的产物；代码、分支部分主要是对自己的代码进行管理；代码模块主要做的是代码库相关的权限管理；分支模块则是管理个人相关的所有代码；实验室是用于做自动化构建和自动化测试相关的内容的；设置则管理的是与个人相关的设置，比如可以设置开启哪些功能。 如下左侧图片所示，在“项目”部分，新光无线团队在RDC上一共有13个项目在运行。而如下右侧图片所示的是针对于某一项目的详情展示，在项目详情页面的左侧有很多的菜单功能可以使用。 在“服务”部分，之前也提到了包括了整个企业可以使用的功能和产品，每个功能都可以点进入查看和开通。 前面比较粗粒度地分享了RDC的组成部分，接下来会从项目的角度出发，按照项目管理、缺陷管理以及研发管理这三个方面进行介绍。如下图中所示的绿色框中的任务、需求、迭代、风险以及图表都是与具体项目管理相关的，缺陷和测试用例是与缺陷管理相关的，分支、实验室、应用以及流水线都是与研发管理相关的。 RDC是个好工具—项目管理 首先从项目管理说起，如下图所示的是新光无线团队在RDC中的一个项目的需求，这里就是一个需求池。回想一下，在还没有使用RDC的时候是如何管理需求的呢？通常情况都是产品经理使用Excel制作一个需求列表，将需求一条一条地列出来，然后产品经理之间需要拿到这些文档发来发去内部之间进行共享和修改。产品、开发、测试以及运维之间沟通需求的时候一样需要传递这些Word或者Excel文档，如果中间有改版就还需要再发一次，用最新的覆盖老的。 而这样的过程的弊端是很明显的。首先，沟通的效率会非常低，传播效率也会非常低；其次，经常会因为传播不到位，导致大家手中的文档版本不同，导致信息同步不到位。而在使用了RDC之后，就可以将需求系统化，这也是帮助最大的部分。因为无论是需求管理或者是任务管理，市面上有很多的工具都在做，但是能够与研发和缺陷管理都紧密地结合在一起的却基本上找不到除了RDC以外的工具或者系统。上图中中间部分就是RDC中的需求池，新提出需求可以向里面录入，但是至于需求什么时候开发都在这里进行管理，所以RDC的需求管理比线下的管理要更加高效，同时需求的到达也会更加快捷。 如下图所示的是项目管理中任务页面，这里管理的是基于产品的需求所进行的开发，也就是将需求拆解成相应的任务。比如在还没有使用RDC的时候，最开始使用的是甘特图来分解任务和安排时间，也就是如下左侧图片所示的在墙上钉一个软木板，之后好几个项目都在上面，有时候需求任务多的时候，这个软木板上基本密密麻麻贴满了便签纸。 同样的，如果这时候只有一个项目，很容易地就能够看到任务的分配以及进展情况，但是一旦项目多了之后，很多的东西都需要往软木板上贴，这样就很难看到每一个项目的具体进度情况了。所以任务的管理非常需要一个电子化、在线化的方式，而RDC就能够提供这样的功能。首先电子看板能够明确显示出每个任务分配给了谁以及每个任务的完成状态如何，包括任务相应的完成时间等信息都是有详细记录的，在电子看板中能够很容易地体现出来。 如下图所示的是RDC项目管理模块的迭代部分，其实迭代这部分就与线下的版本是很相似的。如下图所示的迭代部分存在着两个版本，从1.0.1到1.1.0版本。 如下图所示的是RDC项目管理模块的风险部分。虽然大家都讨厌风险，但是在整个项目的研发过程中，风险又必然会出现。如果通过线下方式去管理风险，大家一般要么会在笔记本上进行记录，要么会在桌子或者显示器前面提一张便签纸，而通过这种线下方式去管理风险的问题与之前所提到的需求管理以及后面将会提到的Bug管理中出现的问题是非常相似的，就是当项目工作量多的时候，风险数量也会增多。所以到底有哪些风险，其中哪些风险已经解决掉了，每个风险的危险度是什么样的，这些是很难通过线下的方式把相对比较多的风险管理起来的。而RDC中所提供的风险管理和需求很像，也是以电子化、在线化的方式对风险进行管理，可以可视化地展示出风险的内容、等级、相关责任人以及解决所需要花费的时间等，这样就能够帮助团队很好地控制风险。 对于项目管理而言，在还没有使用RDC的传统方式下，需求方提出需求，产品经理整理好需求之后就开始交给开发人员，开发人员将需求分解成为相应的任务，并在开发过程中形成一系列的版本，也就是迭代，按部就班地进行实现，最终部署上线。这样的整个研发流程基本上都是通过线下的实现的，而且没有进行完整的串联。 而在使用RDC工具之后，研发流程的本质是没有变化的，也就是说使用RDC并不会为研发过程带来革命性的变革，但是从项目管理的层面上讲，RDC为研发提供了一个很好的工具帮助团队对于研发的全流程实现更细粒度的、更加全面的监控和跟踪、记录以及最后的分析。从需求的产生方，包括运营、用户以及老板他们的需求提出来之后，经过产品的整理放到RDC的需求池里面，之后产品经理以及业务方会对于需求进行优先级评定，排好优先级的需求经过开发的分解形成不同的任务，这些任务就是对于需求的具体实现，这部分也有相应的工时的估算，并且会将任务放入到相应的迭代里面去。 在没有使用RDC之前，一个版本就是一个迭代，在使用了RDC之后就开始尝试进行双迭代，也就是同时运行两个迭代。比如有些产品更新的比较快，可能就会制定两周一次迭代，但是有时候会出现用户反馈的紧急需求，这样就可能把两周一次的迭代版本打断掉，插入一个一周的版本，这样就可能出现两周的版本和一周的版本同时在运行的情况，这两个迭代上线的时间肯定是错开的，但是研发这部分却可能同时有两个迭代在运行。有了RDC这个工具，整个过程下来之后是有记录、可跟踪的，相对而言整个研发流程就会比较清晰。而风险管理则贯穿了整个研发过程，从需求提出开始到应用上线，都可以通过RDC实现全流程的风险监控。其实风险和需求一样，一旦产生了就需要马上暴露出来并指定好处理的责任人。总之，对于项目管理而言，这样的一套研发流程是非常清晰和高效的。 使用RDC进行项目管理的整体流程总结 1.将需求写入需求池。 2.管理需求详情。这里的需求详情比较简单，其实可以向其中添加图片以及交互稿地址。之后开发人员只需要看这个地方就可以了。 3.将需求拆解成任务，通过任务看板可以检查每个任务的状态、分配情况以及完成进度。 4.在任务下面可以新建子任务。其实，大部分的任务是和需求绑定在一起的，也是根据需求拆分的。在RDC中的任务下面可以新建子任务或者子需求。 5.进行开发的迭代。 6.管理迭代详情。如下图所示，比如对于1.0.1这个迭代而言，目前已经添加了这么多的任务进来，而在研发过程中很可能会发生需求和任务的变动，比如有一个紧急的需求需要插进来，这样就可以从图中右边将需求添加进来，同时根据时间和人力的情况判断是否需要添加人员或者增加时间，也可以将优先级比较低的任务先剔除出去，放到下一个迭代中实现，这样就可以非常方便灵活地实现迭代管理。 7.查看风险列表。对于每个风险，在这里都可以都指派跟踪人或者解决者。 8.管理风险详情。在这里可以指派相应的人员，定义风险等级，划分风险对应的模块，并且管理处理该风险所需要的时间以及进度情况。 9.项目管理的图表功能。项目管理部分还提供了图表功能，也就是把之前的需求、任务、缺陷以及风险以图形化的方式进行展示。 10.添加新图表。这里可以设置新添加的图表样式、添加的对象以及图表的指标，让这些维度的管理可以更加直观地体现出来。 RDC是个好工具—开发管理 前面主要分享了使用RDC进行项目方面的管理，其实目前市场上也有很多的工具正在做项目管理方面的事情，而RDC的优势在于它能够系统化地与开发、缺陷管理以及数据化管理进行打通并结合在一起。接下来就简单地分享RDC在开发方面的使用。最早新光互联在做研发的时候比较简单，就是直接开发写代码，之后交给QA进行测试，再之后上线部署就完成了。但是实际上，研发所需要追求的不仅仅是完成工作和实现功能，其实这是远远不够的，还需要更加关注所做出来的东西的质量如何、产品是否稳定以及产品能否抵抗得住压力，同时还需要关注整个团队的研发效率，是否能够用尽量少的人以及尽量少的时间做尽量多的事情。但是效率和质量往往存在一定的矛盾，那么如何实现效率和质量的平衡就需要更加深入地思考。 目前，新光互联所希望实现的就是首先保证质量。在使用RDC之前，新光互联团队也在尝试地实现这样的事情，包括之前开发无线船坞系统也是希望最大程度地保证产品的质量。在最开始产品质量是交给测试进行保障的，而现在希望把质量保证的点尽量向前提，能够在开发阶段就可以保证产品的质量，所以会在开发阶段就引入自动化的测试，包括单元测试、压力测试以及兼容性测试等，并且会实现静态代码的扫描和监测，所以前一天提交完代码，第二天就可以知道所提交的代码质量如何以及有哪里需要修改，修改完之前的代码再去写新的代码，这样就可以尽量地保证已经提交上去的代码的质量。总而言之，就是将整体的质量保障前移，而不会将质量保障的压力全部积压在测试阶段，导致因为时间不够而匆忙上线，进而引起线上故障甚至是事故。 RDC在这方面的功能非常强大，因为RDC是基于阿里内部比较成熟的AOne开放出来的，所以借助RDC的整套开发过程也会非常灵活。在开发阶段可以配置各种自动化测试，这些自动化测试并不需要人工进行干预，而且配置也非常灵活。除此之外，开发阶段的持续交付也是非常成熟的。另外，在测试阶段，除了人工的测试之外，还有很多自动化的测试可以接入进来，甚至最后从测试到上线的持续交付也是自动的。 任何可以做的持续集成和自动化测试都可以通过实验室和流水线进行有机的结合。所谓的流水线就是将各个功能节点把所需要做的事情按照自己的需求组合在一起，比如希望在代码提交到Git的时候触发一个检测，如果没有通过代码规范就将代码打回来，直到检测通过才可以继续下一步。当代码提交之后还可以配入压力测试、性能测试或者兼容性测试，也就是说在整个研发过程当中可以通过流水线向研发流程中部署各种点，当流水线流到相应的点的时候就会触发相应的功能，执行完成之后继续向下走，这样就能够把整个流程自动化地串到一起。而对于初创公司而言，往往没有能力自己实现像RDC这样的产品，所以可以借助阿里云的RDC实现同样的功能。 RDC是个好工具—缺陷管理 接下来分享缺陷管理，这部分主要包括了两部分，第一部分主要是测试用例，第二部分是Bug管理。之前的时候，测试用例也是由QA团队使用Excel编写维护的，与之前的需求等做法一样，都是线下的方式，每人一份传来传去，出现的问题也与前面所提到的相同，到达率不够高，并且更新率也不够高，拿到一份测试用例所需要花费的时间也比较长，所以想要获取最新的测试用例所需要的成本也是比较高的。而通过RDC的在线化电子化的管理，测试用例管理和缺陷管理的问题也就迎刃而解的，团队中每个人都可以很方便地拿到最新的测试用例。如下图所示的就是测试用例库，同样的Bug管理也很相似，这部分与JIRA很像，而且工作项都可以进行配置。 如下图所示的是针对整个项目的设置，这里包括了对于项目的基本信息、名称、成员以及权限的管理，项目开通的服务和功能以及里程碑管理和工作项的配置。 四、RDC的数据化管理 上面分享了新光互联团队在使用RDC工具进行项目管理、研发管理以及缺陷管理方面的经验以及收获。接下来简单地分享RDC的数据化管理。 数据化管理也是RDC区别于市面上的各种项目管理工具的地方，这里的数据化管理不是针对于某一个项目的，而是针对整个团队、公司以及大型企业内部所有项目的多维度、多角度的数据分析。这部分在RDC的功能中叫做度量，而目前RDC开放出来的功能还不是非常全面，所以度量的范围和维度还相对比较少，之后开放出更多维度之后就能够做一些更加全面、深入和细致的数据分析。其实只有经过分析和处理的数据才能发挥出自己最大的价值。而在传统的研发过程中，数据往往会分散到各个子系统中，而子系统之间是没有打通的，所以研发过程产生的数据就无法发挥出整合之后的价值。而借助RDC的能力将数据整合到一起进行更加全面的分析，就可以发挥出更大的价值。 数据管理部分包括研发、应用质量以及项目质量这三个方面。在研发方面包括需求、缺陷以及发布相关的数据，这里展示的是整个团队的粗粒度的宏观数据。 下图展现的是缺陷趋势变化。这里能够将整个团队的十几个项目的总体缺陷情况通过数据分析以图表的形式非常清楚地体现出来。在没有使用RDC之前，数据的收集是非常麻烦的，需要从十几个项目中拿到数据再进行整合，之后再去进行分析。当有了RDC之后，通过数据分析预测缺陷趋势变化就变得轻而易举了。 下图所示的是项目质量数据页面，这里展示了各个项目的总体进度和整体效率，而这些数据在RDC的度量中都能够很全面地体现出来。