如何提高团队项目的开发质量/效率

如何提高团队项目的开发质量、开发效率。

程序员

• 完成大于完美。
• 不要埋头苦干，独立思考后仍不能解决问题，要及时把问题抛出，向其他同事请教。
• 开发进度缓慢，项目进度有风险时，要及时上报，让上级协调资源，或者其他开发人员帮忙分担。
  有风险不可怕，可怕的是不及时暴露风险。
• 需求并不是做得越多越好，要做有价值的需求。
  如果每个迭代要做的功能一大堆，没有时间自测，做完出一大堆问题，那还不如少做点，做好点。
• 程序员一定要会砍需求。
  做不完的需求，一定要跟产品协商，部分需求能否放到下一个版本。
  有时，产品一句话，程序员就能少加几天班。
• 程序员评估需求，最好是留一些缓冲时间Buffer。
  风险和质量，往往是由于时间不够而导致的。
  比如半天的功能，评估为一天。因为工作中经常要开会，或者有些乱七八糟的事情，不留Buffer，会增加风险，降低质量。
• 需求澄清前，要提前阅读需求，这样需求澄清才有意义，才能提出有意义的问题。
• 先搞清楚需求，再进行开发，不然做完了又得重新做。
• 在开发过程中，遇到不清楚的，找产品经理确认清楚，再继续开发。
• 开发功能之前，要进行技术评审，包括技术方案、接口设计等。
  有时，资深程序员帮忙指点一下，能少走好多弯路，少浪费很多时间。
• 接口的字段及含义，要录入接口文档。
• 数据库字段的增删、数据结构的变化、业务逻辑的变化，都需要思考是否会影响历史数据。
  如果会影响历史数据，要如何处理历史数据。
• 做单元测试，保证单元测试覆盖率。
• CodeReview，做代码评审，保证代码的质量。
• 修改别人的代码之前，可以先跟原来的开发人员交流。
• 参加测试用例评审前，尽量提前查看测试用例。
• 程序员开发后，在转测之前，可以对优先级高的测试用例进行冒烟测试，也就是对着测试用例进行自测。
• 上线之前，准备好版本相关的脚本，并评审。
• 记录生产问题，并写清楚问题原因以及解决方案。
• 如果开发人员充足，最好每个功能模块都有一个第二负责人。这样第一负责人休假/离职后也能接手。
• 测试完成以后，如果再次修改代码，需要通知测试进行回归测试。

产品经理

• 不要跟甲方、业务方盲目承诺，随意定期。
• 需求要分优先级。紧急的需求先做。
• 需求要做拆分。不要一次迭代就做一大堆功能。
  做了不一定有人用，先做一个简易版的出来，听取用户反馈，再逐步迭代。
• 需求澄清，提前两天通知。
• 需求澄清，逻辑比较复杂的功能、系统内没有做过的功能，最好先和开发人员提前沟通，能不能做，怎么做。
• 需求澄清，提前将文档发出来。这样团队成员有更多的时间去思考需求，提出问题。
• 需求澄清，要讲清楚需求背景，为什么要做这个需求。梳理清楚需求的前因后果，从用户的角度出来。
• 需求澄清后，跟对应研发确认是否能听懂，并让研发反过来讲解给产品听
• 需求文档，最重要的是，写清楚哪些是新增的功能，哪些是修改的功能，哪些是已有的功能。
• 需求文档，术语必须清晰，与页面文字一致，加上双引号。比如 "一级菜单"--"二级菜单"--"标题"。
• 需求文档，要写清楚菜单/路径。不然别人看了文档，都不知道需求相关的功能是在系统的哪个地方。
• 需求文档，关键的信息和细节必须加粗，标红。
• 需求文档，及时上传服务器。
  需求文档不止给是当前的同事看的，团队成员离职后接手的人也能更好地理解需求。
• 需求变更，尽量减少。
• 确定了一个版本的需求后，进行需求封锁。
  需求封锁后，不得随意在版本中新增/变更需求。非紧急需求放到下一个版本进行。
• 发版的前两天，不要再进行需求变更。
• 需求变更，必须在群里同时通知研发和测试，不能只通知其中一个。
• 每个月或者每个季度，同步需求规划。
• 拒绝甲方/业务方的不合理需求。

提测

• 研发在冒烟测试之后，再提测。
• 提测可以showCase。当着测试的面，把整体的流程走一遍。
  有些研发，做完的功能，连主流程都跑不通，测试根本没法测。
• 提测后，冒烟不通过的，测试可以打回。

测试

• 测试同学，应该在开发阶段就准备测试的脚本，这样就不用担心测试阶段时间不够。
• 测试用例，在开发转测的前两天进行评审。
• 测试用例，评审后要上传到服务器上。
• 多注意边界条件。
• 自动化测试。
• 提高测试用例覆盖率。
• 生产问题要及时跟进。

倒排需求

• 倒排需求，本身就是有风险的。
• 倒排需求，对质量是一种极大的伤害。
• 倒排需求，风险应该由业务方自行承担。
  倒排需求，压榨了研发和测试的时间，加班加点，最后风险反而要由研发和测试承担，天理何在？
  倒排需求，不管是需求延期、线上问题，都应该由业务方负责，如果业务方不负责，那谁答应倒排需求就由谁负责。
  风险应该在倒排需求时，就跟业务方说清楚。

并行需求

• 尽可能减少并行需求。同时做两件事情，往往会顾此失彼。

开会

• 开会不要开太久。
  会议不要超过一小时。太长的会议不会有人听的。
  白天开会，晚上干活。最终会影响项目的质量。
• 开会要提前预约，咨询同事是否有空，如果是线下会议，要提前订好会议室。
• 开会只拉相关的负责人，不要拉所有人，不要浪费别人的时间。
• 开会时，主持人要检查人员是否到齐，及时通知入会。

沟通

• 通知事项要通知到位，相关人员全部同步。开发、测试、产品、负责人，这几个人都要通知。
• 沟通，要说重点。不相关的话别说。
• 沟通，直接找相关的负责人，不要间接传达信息。
• 沟通，简单扼要。能一句话说完的事，不要说两句话。
• 沟通时，除了可以说话，还可以用肢体动作、写字、画图等。

发版

• 发版当天，修改代码要谨慎，需要截图发到工作群，开发人员一起review。
• 发布评审checkList：包括相关的服务清单，服务的发版顺序，版本更新内容，sql脚本。动态配置。接口权限、菜单权限、回滚sql、回滚tag等。
• 发版需要提供回滚策略：假如发版后出现问题，需要进行回滚。
  提前准备好回滚的sql，包括各个sql脚本的回滚语句。
  git需要打tag，一旦需要回滚，直接用tag回滚。