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

（我原本计划将研发环境和管理流程分开来说的，最后仍是放在一块儿便于理解。）

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

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

 

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

 

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

• 即时交流和协做：QQ
• 办公信息平台:诺明
• 代码管理：SVN
• Jar管理：Nexus
• 项目管理：Redmine
• 持续集成：Jenkins、ansible

 

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

 

• 研发环境的搭建：包括如何kick off新开发者，如何搭建平常开发环境
• 代码的管理：包括源码管理，Code Review和组织公共库
• 需求在研发中的生命周期管理：包括功能需求清单，功能需求定义和其中的开发任务项分配和状态管理
• 项目进度的管理：包括如何经过Redmine有效的执行敏捷开发
• 研发阶段的产品测试和反馈：包括在产品测试和反馈中的一些经验和工具分享
• 持续集成和持续发布：包括如何针对Web, Android和iOS分别搭建持续集成和发布

 

1、研发环境的搭建

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

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

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开发人员调试。

 

2、代码管理

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

有两点我以为须要关注的：

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

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

 

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

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

传送门：SVN版本管理

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

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

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

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

PM建立后协做编写需求文档(New) ->     需求确认(Confirmed) ->         开发中(In Progress) ->             待测试(Wait for test) ->                 已完成,能够上线(Finished) ->                     完成,能够关闭(Closed)

 

1. 需求确认

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

2. 需求开发

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

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

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

新建 ->     开发中 ->         待代码复查(目前仅junior developer须要被code review) ->             待测试 ->                 反馈 ->                     完成(能够上线) ->                         关闭(上线之后能够关闭)

 

开发人员主要负责的就是开发的同时更新本身任务的状态，状态蛮多，若是开发须要每次登陆redmine来改也确实蛮累，在实践的过程当中咱们能够引入一些优化的方法：

 

• 为Redmine自定义一些SVN hooks来更新状态。经过自定义SVN提交语法，让SVN提交能自动更新在Redmine相应的版本更新上。
  • 参考资料：SVN提交后自动更新Redmine版本库
    
• Server端接口文档自动生成。在需求定义里能够将规则和逻辑写的很清楚，但在前端和服务端协做开发的过程当中，若是服务端没有文档可能会常常被前端打断，询问接口具体参数的名称或参数类型，也是比较烦的事情，能够考虑用工具来统一管理和自动生成文档，咱们使用的""。
• 开发中的持续集成和交付。这个后面会专门来说如何操做，具体的意义就是开发人员提交代码以后，在服务器上进行自动构建和发布，这样一方面每次提交都作Sonar检查，有单元测试的作单元测试，下降代码最后集成的时候出现问题的风险，另外一方面让PM能够尽早的接触到成品，尽早进行反馈。

3. 需求测试和上线

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

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

4、项目进度的管理

顺着上面的思路，当你有单个需求研发的流程后，整个项目的管理就是管理全部的需求，安排优先级和迭代计划，而后对全部需求进行一样的研发流程管理。敏捷开发里把一个迭代周期称为一个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的实践后面我单独写一篇文档来介绍。

 

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

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

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

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

6、持续集成和持续发布

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服务器上，通知测试团队下载测试。
• 生产的正常的流程就是当测试经过以后，按照确认要上线的功能进行发布。