【网易中台实践】云信业务中台的敏捷开发

我一直从事云信业务中台的后端开发工作。云信的业务发展迅速，产品的需求层出不穷，团队成员不断壮大。如何快速满足产品需求，同时保证线上系统的稳定迭代，以及小团队如何协同？接下来我会从开发规范、开发流程、项目管理、如何敏捷等方面讲述一些我的心路历程，以供参考。

开发规范

云信业务中台团队由最开始的2人，发展到最多时6人。前期阶段只关注需求如何快速迭代上线，没有过多关注代码规范。随着代码数量增加，逐渐发现迭代和维护的难度越来越大，每位程序员都有自己的编码习惯，十几万行的系统代码，看起来就像一堆“屎山”。此时，必须引入代码规范，让写代码和读代码的程序员都能够心情愉悦。

代码规范，直接借鉴的《阿里巴巴java开发手册》，手册里详细制定了编码、异常日志、单元测试、安全规约、MYSQL数据库、工程结构等的相关规范，大家可以网上下载阅读。

有了规范，大家如何有效地执行？

统一IDE代码模板

约定了IDEA/Eclipse IDE代码的统一模板，新建类、方法，格式化全部统一。避免不同的开发同学使用不同的模板带来的差异化，以及增加merge的成本。可以使用eclipse-java-google-style模板。在提交代码时使用Alibaba Java Coding Guidelines插件，对不符合规范的代码进行提醒，修改后再提交。

分支管理

最开始，团队使用的SVN来管理源码，随着git的流行，后来全部切换到git。针对分支开发，制定了以下规范：

分支的定义（master、develop、release、hotfix、feature），不同分支会有不同的权限。

checkout、merge request流程，merge时还可以做一次code review；

提测、上线流程，不同阶段使用不同的分支测试和发布，上线完成后打tag，方便回滚；

统一工具与框架

对于业务中使用到的公共工具类和方法，统一抽象和封装到二方库，比如JedisUtil、httpClient、日期格式的转换、文件读写导出等。所有系统统一框架和版本，比如spring、spring boot，mybatis、dubbo、MQ等，让开发同学能将主要精力放在业务模块的开发上。

注释和文档

让程序员既要写得一手好代码，又要写得一手好文档，并且保证代码和文档的同步，面对时间紧、需求多的情况下，实现起来不现实。那如何做到文档与代码同步？作为程序员，简单直接的方法的就是写好注释。在类、方法、属性前加上适当的注释，对于难以解释的代码加上必要的注释。Controller层的api可以使用spring-swagger来保持同步，减少因修改代码而维护文档的成本。

如何做到敏捷？

敏捷这个词早在90年代初就提出了，据统计，2018年90%的软件开发都采用了敏捷开发。下面这段话很好的解释了什么是敏捷？

敏捷开发（agile development）是非常流行的软件开发方法，敏捷开发的核心是迭代开发，

迭代开发其实就是"重复开发"。它将开发过程拆分成多个小周期，即一次"大开发"变成多次"小开发"，每次小开发都是同样的流程。

其实这里所谓的同样的流程，就是传统的瀑布开发模式，包括几个重要的环节。我在实际的开发过程中，主要有以下几个重要的里程碑节点：

需求评审

我们的需求主要来源于产品经理，产品经理通过给开发、测试讲解本次版本的需求背景、详细说明、完成后的效果，让相关同学理解需求。同时，开发评估需求的合理性、可行性，可以对需求有所调整。这个环节必不可少。当然，需求也可以来自开发，测试，也需要与相关人员沟通。

设计评审

这里的设计评审，不是视觉和交互评审，是技术实现的设计评审。

如果本次迭代的需求在技术方案上需要评估，则需要对详细设计做一个评估，避免开发过程或上线后造成缺陷和遗漏。如果只是常规迭代，则可以省略这一步。

编码

实现本次迭代的需求

测试用例评审

测试用例和编码应该是同步的，对测试写的用例进行评估，可能会发现测试遗漏点，并将其补充完整。

发布计划评审

如果本次迭代涉及的变更复杂或需要跨部门合作，有前后依赖的关系，需要写一个发布计划，写清楚上线的时间、步骤、注意事项，以免造成上线混乱。同时，要有发布失败的回滚方案。

上线

按照发布计划，进行系统的发布上线。

复盘

如果本次迭代有发生重大失误，造成发布失败或发布后引起严重的线上问题，则需要产品、测试、开发等相关同学一起复盘本次迭代，总结经验，避免下次再发生同样的事情。

按照这个瀑布模式进行迭代，觉得步骤是不是有点多？太浪费时间?和所谓的敏捷相违背？但实际是，多少实践经验告诉我，这些流程避免不了。比如没有需求评审，开发完成了，发现效果不是产品想要的。没有测试评审，开发有修改的地方，测试没有测试到，导致测试遗漏。

除了这些重要的里程碑，其实还有一些关键节点，比如视觉、交互评审，产品走查，冒烟测试，预发布验证等。

根据敏捷开发的价格观和十二条原则，我们团队做了如下调整：

少开会

让产品、测试、开发尽量坐在一起，如果有任何问题，直接使用面对面交流的方式，解决问题。避免使用邮件、即时通讯软件带来的信息滞后。如果要开会，可以使用站会的形式，简洁沟通。如果必须开会，则尽量控制开会时间，说重点和问题，高效解决。

控制迭代节奏

每次迭代主要解决优先级最高或比较紧急的需求，控制一次迭代的周期在2~3周，从而达到不断可持续的交付。

定期复盘

针对一段时间内，系统出现的问题，流程的问题等进行复盘和总结。技术实现上，如果用合理的方案快速实现。流程上，如何优化，才能更高效。

如何用好敏捷，打造高效团队，以上均是本人工作实践总结，纯属个人见解，如有疑问，欢迎拍砖。

【网易中台实践】云信业务中台的敏捷开发相关推荐

所有的中台都是业务中台
2019年中台的概念如火如荼,在日常的技术交流中,假如不提一些"中台"的字眼,就觉得自己已经落伍了.那什么是中台呢?2019年涌现了很多中台,比如业务中台.数据中台.技术中台.移动 ...
中后台管理信息系统通用原型方案、业务中台管理系统、业务中台架构、管理信息系统、订单管理、客户管理、货源管理、财务管理、客服管理、营销管理、办公申请、协作管理、CMS、OA、CRM、ERP、Axure
本作品是一套通用型的中后台信息系统原型方案,可以快速扩展并输出标准美观的中后台产品原型,极大的提升输出效率和节省协作成本.方案中提供了几十套不同风格和结构的系统框架,并涵盖了大量的常用组件和通用页面模 ...
业务中台管理系统、业务中台架构、接口类服务、模型类服务、界面类服务、组件类服务、服务架构、中后台、服务审核、AI服务、位置服务、行业场景服务、企业中台、接口配置、模型配置、数据处理、结构化数据、数据源
业务中台管理系统.业务中台架构.接口类服务.模型类服务.界面类服务.组件类服务.服务架构.中后台.服务审核.AI服务.位置服务.行业场景服务.企业中台.接口配置.模型配置.数据处理.结构化数据.数据源 ...
中小型城市商业银行数字化转型实践(四)业务中台建设思路和路径
19下半年开始业务中台的建设成为热点,网上各种文章介绍业务中台的建设的经验和教训,有吹捧的,把业务中台视为企业数字化转型的救命稻草,有黑的,通过一些失败的案例,把业务中台建设视为企业数字化转型的毒药. ...
企业中台最佳实践--阿里业务中台最佳实践(八)
00 一切业务数据化,一切数据业务化. "中台"概念这几年非常火,特别是阿里.腾讯.百度.京东等互联网公司最近频繁的基于中台调整组织架构,把"中台"的热度又上升 ...
企业中台最佳实践--阿里巴巴业务中台(二)
01 阿里业务中台架构图图1 :阿里业务中台架构基础设施服务,即IAAS层,提供硬件底层支持. 基础服务层,即PAAS层,包括分布式服务框架.分布式数据库.分布式消息.分布式存储.分布式事务.实时 ...
中台实践：数据中台构建五步法
陈新宇罗家鹰江威邓通读完需要 24 分钟速读仅需 8 分钟云徙科技国内领先的数字中台服务商,以"业务数据"双中台为核心技术,驱动企业数字化转型,助力业务持续增长.公 ...
从阿里前端工程化中台实践，看中台建设的舍与得
作者|朱华军(阿大) 出品|InfoQ&阿里巴巴新零售淘系技术部导读:随着前端技术不断从 Web 延伸至各种"端",大前端的概念早已成为业内共识.伴随着大前端的发展,与之 ...
我是如何在一家独角兽公司做业务中台、数据中台的？8页ppt详解中台建设实践！...
点击"技术领导力"关注∆ 每天早上8:30推送概述中台这个词火爆挺久了.但从阿里 2015 年提出并开始实施,发展到目前为止,并没有「标准化」:换句话说,它跟「人工智能」,「 ...

【网易中台实践】云信业务中台的敏捷开发

【网易中台实践】云信业务中台的敏捷开发相关推荐

最新文章

热门文章