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

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

程序员

• 需求澄清前，要提前阅读需求，这样需求澄清才有意义，才能提出有意义的问题。
• 先搞清楚需求，再进行开发，不然做完了又得重新做。
• 在开发过程中，遇到不清楚的，找产品经理确认清楚，再继续开发。
• 开发功能之前，要进行技术评审，包括技术方案、接口设计等。
• 接口的字段及含义，要录入接口文档。
• 数据库字段的增删、数据结构的变化、业务逻辑的变化，都需要思考是否会影响历史数据。
  如果会影响历史数据，要如何处理历史数据。
• 做单元测试，保证单元测试覆盖率。
• CodeReview，做代码评审，保证代码的质量。
• 修改别人的代码之前，可以先跟原来的开发人员交流。
• 参加测试用例评审前，尽量提前查看测试用例。
• 程序员开发后，在转测之前，可以对着测试用例进行自测。
• 上线之前，准备好版本相关的脚本，并评审。
• 记录生产问题，并写清楚问题原因以及解决方案。
• 如果开发人员充足，最好每个功能模块都有一个第二负责人。这样第一负责人休假/离职后也能接手。
• 不要埋头苦干，独立思考后仍不能解决问题，要及时把问题抛出，向其他同事请教。
• 开发进度缓慢，项目进度有风险时，要及时上报，让上级协调资源，或者其他开发人员帮忙分担。
  有风险不可怕，可怕的是不及时暴露风险。
• 测试完成以后，如果再次修改代码，需要通知测试进行回归测试。
• 发版当天，修改代码要谨慎，需要截图发到工作群，开发人员一起review。

产品经理

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

测试

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

开会

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

沟通

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