产品团队管理-统一研发环境，提效研发过程

（我本来计划将研发环境和管理流程分开来讲的，最后还是放在一起便于理解。）

软件研发最重要的场景就是在有限的时间和资源下把需求落地为产品/项目，也就是研发和项目管理，毫无疑问，这个阶段的主角是开发人员。

是不是应该多思考下怎么面向开发人员来优化整个研发过程和项目管理流程？

本文将介绍如何通过优化开发环境搭建、代码管理来提高研发过程中开发人员效率，并通过持续集成和交付让开发中的问题更早暴露，通过合理的测试反馈工具让开发人员更早定位和解决问题。

说到团队的研发和项目管理的实践，就逃不开先要说一下笔者所在公司研发和项目管理中的工具作为背景：

即时交流和协作：QQ

办公信息平台:诺明

代码管理：SVN

Jar管理：Nexus

项目管理：Redmine

持续集成：Jenkins、ansible

切入正题，本篇分享涵盖的是在研发过程和项目管理流程，以及当中在DevOps上做的一些努力去优化开发人员的体验，就试着从各个环节总结一下：

研发环境的搭建：包括如何kick off新开发者，如何搭建日常开发环境

代码的管理：包括源码管理，Code Review和组织公共库

需求在研发中的生命周期管理：包括功能需求清单，功能需求定义和其中的开发任务项分配和状态管理

项目进度的管理：包括如何通过Redmine有效的执行敏捷开发

研发阶段的产品测试和反馈：包括在产品测试和反馈中的一些经验和工具分享

持续集成和持续发布：包括如何针对Web, Android和iOS分别搭建持续集成和发布

一、研发环境的搭建

如何让团队新的开发者尽快上手

对新的开发人员，一般都会有开账号，装系统，配环境，跑代码这些过程，我自己发现每次都低估这些工作的耗时，以前就发现有时候不小心就一两天过去了还没跑起来代码，一两周还没搞清楚目前产品的功能，我总结了几点加快这个进度的方法：

1.加快账户开通和权限分配的速度

笔者公司的帐号包括OA，svn，nexus，redmine，ftp，jenkins，Sonar。这些系统的用户管理和权限无非基本都是通过数据库或者xml进行管理，那么是否可以梳理规则然后通过自动化来实现呢？

整理各系统，角色、权限对应的sql表和字段或xml键值对

开发同步小程序，建立OA同步至其他系统的相应场景(创建、禁用、密码修改、职位调整等等)

2.加快开发IDE环境搭建的速度

同一产品部门或同一工种日常所使用研发IDE环境，基本都是一样的，难道要每一个新入职的同事如果都自行去确认IDE，下载和安装？我们可以统一研发所需使用的IDE组件和版本组装成一键安装包。

收集研发IDE工具及版本。如svn，Eclipse、maven、ant、xshell及其他

统一组件安装目录。如：D:/develop

编写环境插入bat文件

编写环境检查，开发指引文件，开发标准规范配置说明

通过Winrar创建自解压包，自动安装相应软件，执行bat配置环境变量

(注：环境插入的bat文件，部分windows系统版本无法插入，需手动添加)

3.加快能让代码跑起来的速度

有很多可以加速的环节，一个比较重要的就是自动构建代码，就是指开发人员checkout代码后通过简单的构建脚本就能完成代码依赖安装，代码编译，单元测试运行，也就是我们常说的跑起来。以Web为例，可以通过maven的pom完成依赖的安装、代码的构建和版本提交，这也是持续集成的基础。

4.对产品功能需求和目前进度的了解

保持尽量清晰的需求定义，新的开发人员可以通过浏览产品的需求文档来了解产品功能。

可以知道以前每个版本都做了什么功能，未来有什么功能正在排期中：

如何方便开发人员进行日常开发调试

目前对于Web开发来说，一般构建的过程中代码都会进行环境文件DLL/SO,CDN地址等替换、CSS Sprite生成等等操作，造成配置切换很不方便，我们采取的解决方法是在web的maven构建流程中分不同的Build Target，自动构建切换至对应环境配置，连接对应数据库，方便Web开发人员调试。

二、代码管理

首先最重要的就是代码必须用源码管理工具，我们一直用的SVN。代码的查看和管理都在SVN服务器上，可以查看代码，code review，合并分支，打版本tag之类的。

有两点我觉得需要关注的：

1.怎么让开发人员高效的使用第三方库

项目开发的过程中去抽象公共组件，使用第三方库或开发工具都可以提高开发效率，但需要做好模块和版本管理，有时候碰到一个开发人员引入了一个不合理的依赖，或者学习成本陡峭的组件，每个参与开发人员都要增加学习成本。这个一般都是根据不同的技术栈有相应的一套工具可以使用，在java开发上我们使用的是Nexus来管理， iOS、Android上面也有自己习惯的选择，需要加新的组件或者替换正在使用的通过专家小组评审讨论之后加入，以免发生重复或者后期的分歧。

2.如何做新功能开发的代码管理

只要多人开发，而且多功能并行开发都避免不了要考虑如何管理代码。一般有Brunch和Trunk开发两种。

三、需求在研发中的生命周期管理

对于开发人员来说，开发工作一般是围绕着具体的功能需求进行的，而“清晰的需求定义”就是研发的主要输入，由负责的PM来主导需求(User Story)的状态更新，本节以一个功能需求(User Story)为例，先上一个时序图来说明单个功能在研发中的生命周期是什么样的：

从功能需求(User Story)的时间线上可以看出来其分为下面几个状态：

可以划分为需求确认，需求开发，需求测试和上线三个阶段：

1.需求确认

对于需求文档的编写和确认，不同团队方式不一样，我的理解是包括功能需求的前置条件和后置条件，用户流程和规则，完整的产品交互原型，评审确认的设计稿。

2.需求开发

在需求定义清晰后，开发前需要整个开发团队的参与确认任务的分配。任务分配的原则就是将功能需求对应的任务按树形结构分解，敏捷开发里的学名是“Work Breakdown Structure (WBS)”，保证其中每个任务都是可以开发，并且是可以测试的。

具体到其中一个单独的任务项(Task)，里面会有它所属的功能需求(User Story)，当前的状态，优先级，任务指派的开发者，任务所属的产品线，一个简单的任务描述的，所属的里程碑，预计开发时间和结束时间，任务当前的状态和进度等等。

从上文中“需求在研发中的生命周期”的时序图上可以看出其对应的任务的生命周期是如何管理的，包括前端和后台之间的任务协作是如何完成的，简单来总结的话Task有下面几种状态：

开发人员主要负责的就是开发的同时更新自己任务的状态，状态蛮多，如果开发需要每次登录redmine来改也确实蛮累，在实践的过程中我们可以引入一些优化的方法：

为Redmine自定义一些SVN hooks来更新状态。通过自定义SVN提交语法，让SVN提交能自动更新在Redmine相应的版本更新上。

参考资料：SVN提交后自动更新Redmine版本库

Server端接口文档自动生成。在需求定义里可以将规则和逻辑写的很清楚，但在前端和服务端协作开发的过程中，如果服务端没有文档可能会经常被前端打断，询问接口具体参数的名称或参数类型，也是比较烦的事情，可以考虑用工具来统一管理和自动生成文档，我们使用的“”。

开发中的持续集成和交付。这个后面会专门来讲如何操作，具体的意义就是开发人员提交代码之后，在服务器上进行自动构建和发布，这样一方面每次提交都做Sonar检查，有单元测试的做单元测试，降低代码最后集成的时候出现问题的风险，另一方面让PM可以尽早的接触到成品，尽早进行反馈。

3.需求测试和上线

当单个功能需求下面对应的所有任务都开发完成后，由PM进行测试和反馈，在确认与PRD一致后可以由PM更新为“待测试(Wait fortest)”。这里“待测试(Wait for test)”的意义就是该功能需求可以在发布到测试服务器(Test Server)，由业务及测试团队参与测试。当测试没有问题后，如果是Web功能则根据上线计划上线到Production Server；如果是Native App，则按照版本计划，可能需要固定时间发布或者等待几个功能完成后一起发布上架（部分公司可能会有灰度发布的过程）。

由于这里讲的是单个功能需求的研发周期，而测试和上线更多是在整个项目这个范围 上来讨论，所以针对测试和上线的部分在后面持续集成和发布的部分会来细说。

四、项目进度的管理

顺着上面的思路，当你有单个需求研发的流程后，整个项目的管理就是管理所有的需求，安排优先级和迭代计划，然后对所有需求进行同样的研发流程管理。敏捷开发里把一个迭代周期称为一个Sprint，每个Sprint做一次产品发布，然后回顾Sprint内的问题，规划下一个Sprint的开发任务，如下图：

笔者公司的的实践并非Scrum，但比较接近，我们的迭代比较频繁，通常每周至少都往Production上做一次同步。项目的进度管理推荐参考Scrum的实践里的三个Meeting：

Sprint Planning Meeting：从整个产品的Product Backlogs里一起规划出下一个Sprint要完成的功能，可能对应着很多团队的需求评审会

Daily Standup Meeting：在一个Sprint里每天和开发人员一起回顾昨天的开发进度，讨论碰到的问题和确认当天的工作计划，其实对应着为开发人员诟病的项目日报

Sprint Review Meeting：在一个Sprint结束回顾项目进度，问题和下一个Sprint的计划，一般对应着PM要做的项目周报

在这三个Meeting上PM会和开发人员或者产品负责人进行接触，如果这里体验不好就会影响项目的管理。其实我们试点的优化方案也比较简单，就是通过项目管理工具Redmine去实现的功能需求和开发任务的“看板”：

关于redmine的实践后面我单独写一篇文档来介绍。

五、研发阶段的产品测试和反馈

产品发布到测试渠道后的反馈

当产品发布到测试渠道就是希望在正式发布前得到业务和测试团队的反馈，对比开发人员的测试反馈，业务和测试团队的反馈会更专业、清晰、充分，这些反馈需要通过相应的工具来进行管理：

·我们使用的BUG反馈工具是禅道，可以明确缺陷的类型，等级，可记录具体的场景并添加贴图，并有指派和BUG跟进报表等相关功能。需要了解的可以百度“禅道”（我并没有收他们的广告费）。

六、持续集成和持续发布

Native App因本身业务和市场占有的需求，一个重要的痛点就是不停迭代业务、发测试版、进行测试，但对于移动app来讲之前每次打包都需要打断开发人员，等待编译，改文件名加版本号，上传等一系列繁琐的过程，然后还经常因为客户没有装最新版而造成沟通时间的浪费，所以早期我们就开始着手建立持续集成和持续发布体系来避免这些问题。

一个完善的持续集成应该包括代码提交后的构建->部署->测试->发布几个阶段，两张图对比应用持续集成和持续集成之后的研发过程：

然后这张图是我们目前实现的持续集成过程：

自动构建

Jenkins支持定期检测SVN代码更新，会在代码提交成功后能在持续集成服务端(CI Server)触发相应的Server，Web，iOS或android端的自动构建。

持续部署

部署分为客户端部署和服务端部署两种，就是构建以后要把可运行的代码发布到相应的服务器和手机端。

持续测试

分为单元测试和集成测试，理论上来说能在持续集成的过程中执行测试，是对产品质量极大的提升，不过对团队的规模和时间要求比较高，一般还是按自己的实际情况来，非长期维护产品慎用，建议做产出分析。

持续交付

持续集成后的持续发布是我们主要需要解决的痛点，发布的对象分别是给开发和测试人员的Dev版，给测试团队的Test版和给最终线上用户的Production版，发布的渠道又分为Web端和Mobile端，需要分别来考虑：

将发布的dev,test和production分为三个不同的服务器：

Dev服务器由Jenkins检测来触发，每次代码提交都会触发构建，然后Redmine发邮件给相关负责人，同时集成新版本到Dev上。

对于Test服务器就是当有新功能测试完成，准备上线的时候，就先同步到Test服务器上，通知测试团队下载测试。

生产的正常的流程就是当测试通过之后，按照确认要上线的功能进行发布。

如果你觉得文章能给你带来帮助，请关注我的公众号并帮忙转发!