我一直从事云信业务中台的后端开发工作。云信的业务发展迅速，产品的需求层出不穷，团队成员不断壮大。如何快速满足产品需求，同时保证线上系统的稳定迭代，以及小团队如何协同？接下来我会从开发规范、开发流程、项目管理、如何敏捷等方面讲述一些我的心路历程，以供参考。
开发规范
云信业务中台团队由最开始的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周，从而达到不断可持续的交付。
定期复盘
针对一段时间内，系统出现的问题，流程的问题等进行复盘和总结。技术实现上，如果用合理的方案快速实现。流程上，如何优化，才能更高效。
如何用好敏捷，打造高效团队，以上均是本人工作实践总结，纯属个人见解，如有疑问，欢迎拍砖。
