更多云场景实践研究案例，点击这里：
【云场景实践研究合集】联合不是简单的加法，而是无限的生态，谁会是下一个独角兽
本文为大家分享了新光互联线借助阿里云RDC研发模式互联网转型实践之路，并实现了从需求管理，到多团队协作，到缺陷管理以及自动化部署等全流程的无缝衔接，且借助RDC的敏捷管理工具，让敏捷协作更为高效。
本文为大家分享了新光互联线借助阿里云RDC研发模式互联网转型实践之路，并实现了从需求管理，到多团队协作，到缺陷管理以及自动化部署等全流程的无缝衔接，且借助RDC的敏捷管理工具，让敏捷协作更为高效。
采用的阿里云产品
阿里云云效（RDC）
为什么使用阿里云
阿里巴巴内部的AOne系统开放出来的云效（RDC），能够系统化地与开发、缺陷管理以及数据化管理进行打通并结合在一起。对于初创公司而言，往往没有能力自己实现像RDC这样的产品，所以可以借助阿里云的RDC实现同样的功能。
关于新光互联无线
新光集团是一家集实业、地产、投资、金融、互联网、能源和旅游等多元业务于一体的产融结合的生态投资集团。目前旗下有1家上市公司，40多家全资子公司及控股公司，近百家参股公司，资产规模近千亿。新光互联是新光集团旗下负责互联网业务相关的子公司。
面临的挑战
新光集团在接触RDC之前是使用的传统研发方式，但是单是一种产品业务线，如兔波波算下来就已经达到十几个项目组，总共四五十个项目成员了。而面对众多的业务，之前的做法相对比较传统，就是“一个萝卜一个坑”，每个成员负责固定的项目，这样就相当于同时有十几个项目组向前走。整个研发管理的复杂度就会大大提升，那么对于项目的进度和风险的把控以及资源的分配工作都需要管理人员花费大量的时间来进行信息收集和数据同步。
在最早的时候，新光集团在软件系统上做法与很多的创业公司一样：在代码管理方面使用GitLab，需求管理和Bug管理使用JIRA，团队内部的文档共享使用Confluence的Wiki功能。当时新光无线团队采用的还是手动在本地进行打包的方式，而后面随着业务的增多，也逐渐开始使用Jenkins实现简单的持续集成。
GitLab、JIRA以及Jenkins都是相对独立的系统，新光无线团队从最开始一路走来，对于这一点的体会也非常深刻：虽然这些子系统都能够把自己分内的事情做的很好，但是这么多独立的系统却是无法整体进行打通的，这也是令人非常苦恼的一件事情。所以，在后来新光无线技术团队也开始尝试地去通过整合来解决问题，新光无线团队内部的开发的一套无线研发支撑系统——无线船坞。无线船坞中提供了：用于实现持续集成的打包中心；集成了JIRA的Bug中心；代码检测中心；无线知识库；团队自己开发的用于承载产品文档的简单Web服务的产品原型中心；线上数据的监控的线上数据中心；而后来发现虽然无线船坞这个工具集搭建起来了，但还是会遇到前面出现的问题，也就是无法将这些工具系统化，无法打破各个工具的边缘将它们整合到一起。所以新光无线团队非常希望有这样的一个能够打通研发全流程的工具或者系统，可以实现研发流程的记录、监控和反馈以及在最后项目完成的时候进行数据分析。
为什么选择阿里云
RDS-项目管理
（1）在还没有使用RDC的时候是如何管理需求的呢？通常情况都是产品经理使用Excel制作一个需求列表，将需求一条一条地列出来，如果中间有改版就还需要再发一次，用最新的覆盖老的。而这样的过程的弊端是很明显的。首先，沟通的效率会非常低，传播效率也会非常低；其次，经常会因为传播不到位，导致大家手中的文档版本不同，导致信息同步不到位。而在使用了RDC之后，就可以将需求系统化，这也是帮助最大的部分。因为无论是需求管理或者是任务管理，市面上有很多的工具都在做，但是能够与研发和缺陷管理都紧密地结合在一起的却基本上找不到除了RDC以外的工具或者系统。RDC的需求管理比线下的管理要更加高效，同时需求的到达也会更加快捷。
（2）在还没有使用RDC的时候，最开始使用的是甘特图来分解任务和安排时间，在墙上钉一个软木板，之后多个个项目都在上面，有时候需求任务多的时候，这个软木板上基本密密麻麻贴满了便签纸。如果只有一个项目，很容易地就能够看到任务的分配以及进展情况，但是一旦项目变多，很多的东西都需要往软木板上贴，这样就很难看到每一个项目的具体进度情况了。所以任务的管理非常需要一个电子化、在线化的方式，而RDC就能够提供这样的功能。首先电子看板能够明确显示出每个任务分配给了谁以及每个任务的完成状态如何，包括任务相应的完成时间等信息都是有详细记录的，在电子看板中能够很容易地体现出来。
（3）在早期，需求方提出需求，产品经理整理好需求之后就开始交给开发人员，开发人员将需求分解成为相应的任务，并在开发过程中形成一系列的版本，也就是迭代，按部就班地进行实现，最终部署上线。这样的整个研发流程基本上都是通过线下的实现的，而且没有进行完整的串联。而在使用RDC工具之后，研发流程的本质是没有变化的，也就是说使用RDC并不会为研发过程带来革命性的变革，但是从项目管理的层面上讲，RDC为研发提供了一个很好的工具帮助团队对于研发的全流程实现更细粒度的、更加全面的监控和跟踪、记录以及最后的分析。
RDC—开发管理
RDC的优势在于它能够系统化地与开发、缺陷管理以及数据化管理进行打通并结合在一起。最早新光互联在做研发的时候比较简单，就是直接开发写代码，之后交给QA进行测试，再之后上线部署就完成了。但是实际上，研发所需要追求的不仅仅是完成工作和实现功能，其实这是远远不够的，但是效率和质量往往存在一定的矛盾，那么如何实现效率和质量的平衡就需要更加深入地思考。目前，新光互联所希望实现的就是首先保证质量。RDC在这方面的功能非常强大，因为RDC是基于阿里内部比较成熟的AOne开放出来的，所以借助RDC的整套开发过程也会非常灵活。在开发阶段可以配置各种自动化测试，这些自动化测试并不需要人工进行干预，而且配置也非常灵活。除此之外，开发阶段的持续交付也是非常成熟的。另外，在测试阶段，除了人工的测试之外，还有很多自动化的测试可以接入进来，甚至最后从测试到上线的持续交付也是自动的。
RDC—缺陷管理
在早期之前的时候，新光互联测试用例也是由QA团队使用Excel编写维护的，与之前的需求等做法一样，都是线下的方式，每人一份传来传去，出现的问题也与前面所提到的相同，到达率不够高，并且更新率也不够高，拿到一份测试用例所需要花费的时间也比较长，所以想要获取最新的测试用例所需要的成本也是比较高的。而通过RDC的在线化电子化的管理，测试用例管理和缺陷管理的问题也就迎刃而解的，团队中每个人都可以很方便地拿到最新的测试用例。同样的Bug管理也很相似，这部分与JIRA很像，而且工作项都可以进行配置。
RDC是个好工具
RDC可以用于项目研发全流程的管理，它是由阿里巴巴内部的AOne系统开放出来的。新光无线团队接触RDC这款工具之后，
实现了从需求管理，到多团队协作，到缺陷管理以及自动化部署等全流程的无缝衔接，并借助RDC的敏捷管理工具，让敏捷协作更为高效。
关于新光互联的更多实践详情：
500强上市公司：研发模式互联网转型实践
原文发布日期：2017-09-18
云栖社区场景研究小组成员：董黎明，仲浩。
