如何提高团队项目的开发质量、开发效率。
程序员
- 需求澄清前，要提前阅读需求，这样需求澄清才有意义，才能提出有意义的问题。
- 先搞清楚需求，再进行开发，不然做完了又得重新做。
- 在开发过程中，遇到不清楚的，找产品经理确认清楚，再继续开发。
- 开发功能之前，要进行技术评审，包括技术方案、接口设计等。
- 接口的字段及含义，要录入接口文档。
- 数据库字段的增删、数据结构的变化、业务逻辑的变化，都需要思考是否会影响历史数据。
如果会影响历史数据，要如何处理历史数据。 - 做单元测试，保证单元测试覆盖率。
- CodeReview，做代码评审，保证代码的质量。
- 修改别人的代码之前，可以先跟原来的开发人员交流。
- 参加测试用例评审前，尽量提前查看测试用例。
- 程序员开发后，在转测之前，可以对着测试用例进行自测。
- 上线之前，准备好版本相关的脚本，并评审。
- 记录生产问题，并写清楚问题原因以及解决方案。
- 如果开发人员充足，最好每个功能模块都有一个第二负责人。这样第一负责人休假/离职后也能接手。
- 不要埋头苦干，独立思考后仍不能解决问题，要及时把问题抛出，向其他同事请教。
- 开发进度缓慢，项目进度有风险时，要及时上报，让上级协调资源，或者其他开发人员帮忙分担。
有风险不可怕，可怕的是不及时暴露风险。 - 测试完成以后，如果再次修改代码，需要通知测试进行回归测试。
- 发版当天，修改代码要谨慎，需要截图发到工作群，开发人员一起review。
产品经理
- 不要跟甲方、业务方盲目承诺，随意定期。
- 需求要分优先级。紧急的需求先做。
- 需求要做拆分。不要一次迭代就做一大堆功能。
- 需求澄清，提前两天通知。
- 需求澄清，逻辑比较复杂的功能、系统内没有做过的功能，最好先和开发人员提前沟通，能不能做，怎么做。
- 需求澄清，提前将文档发出来。这样团队成员有更多的时间去思考需求，提出问题。
- 需求澄清，要讲清楚需求背景，为什么要做这个需求。梳理清楚需求的前因后果，从用户的角度出来。
- 需求澄清后，跟对应研发确认是否能听懂，并让研发反过来讲解给产品听
- 需求文档，术语必须清晰，与页面文字一致，加上双引号。比如 "一级菜单"--"二级菜单"--"标题"。
- 需求文档，关键的信息和细节必须加粗，标红。
- 需求文档，及时上传服务器。
需求文档不止给是当前的同事看的，团队成员离职后接手的人也能更好地理解需求。 - 需求变更，尽量减少。
- 确定了一个版本的需求后，进行需求封锁。
需求封锁后，不得随意在版本中新增/变更需求。非紧急需求放到下一个版本进行。 - 发版的前两天，不要再进行需求变更。
- 需求变更，必须在群里同时通知研发和测试，不能只通知其中一个。
- 每个月或者每个季度，同步需求规划。
- 拒绝甲方/业务方的不合理需求。
测试
- 测试同学，应该在开发阶段就准备测试的脚本，这样就不用担心测试阶段时间不够。
- 测试用例，在开发转测的前两天进行评审。
- 测试用例，评审后要上传到服务器上。
- 多注意边界条件。
- 自动化测试。
- 提高测试用例覆盖率。
- 生产问题要及时跟进。
开会
- 开会不要开太久。
会议不要超过一小时。太长的会议不会有人听的。
白天开会，晚上干活。最终会影响项目的质量。 - 开会要提前预约，咨询同事是否有空，如果是线下会议，要提前订好会议室。
- 开会只拉相关的负责人，不要拉所有人，不要浪费别人的时间。
- 开会时，主持人要检查人员是否到齐，及时通知入会。
沟通
- 通知事项要通知到位。开发、测试、产品、负责人，这几个人都要通知。
- 沟通，直接找相关的负责人，不要间接传达信息。
- 沟通，简单扼要。能一句话说完的事，不要说两句话。
- 沟通时，除了可以说话，还可以用肢体动作、写字、画图等。