开发在需求宣讲后，需要理解并拆分需求，及时跟产品沟通并督促 产品更新需求；
开发前期需求需要完全了解，非自己开发部分也需要大概了解；
开发完成后需要重新核对一遍需求，有些需求变更才不会漏掉；
开发需要测试部署时，要提供完整的部署信息（包括：环境、服务、分支）和部署说明（本次部署的目的）；
开发在设计评审阶段，可以让测试一起参加了解；
开发不允许私自修改或优化代码但没有告知测试，很容易导致测试漏测；
开发bug原则上需要日清，紧急和严重问题非特殊情况必须日清；
开发提测前，需要将全流程都跑通（执行冒烟测试用例）才能提交测试，不能只是每个开发模块开发完成，独自模块自测完成后就算提测；
涉及到迭代开发的所有人员都需要清楚每个迭代的节点时间（提测时间、预生产时间、上线时间）；
开发身上的bug，如果需要流转到其他开发，需要备注下一个开发需要帮忙做的事情，然后私下再通知对应开发帮忙排查问题；
开发解决bug后，需要备注出现问题的原因和影响范围，方便测试回归验证；
开发提测，需要有提测说明和影响范围说明（开发全功能提测后，发现有不影响主流程的问题，正在修复，也可以写到提测说明中）；
开发不能私下接需求，产品新增或修改需求，需要测试也评估后才能决定是否新增/修改；
开发提测后，可以多对自己的代码和本次迭代流程进行测试，在测试发现问题前先消灭掉（建议）；
最好是能前紧后松，不要所有东西都堆积到后面来处理，导致后面发布风险；
开发过程中碰到有2个小时内自己都解决不了的问题，要向上寻求帮助，不要耗上一天或者半天的时间；
群里或者私聊的时候，有看到消息开始处理了要通知一声让对方了解情况，所有消息都最好能稍微回复/反馈；
测试提测问题单，如有描述多个问题场景，要所有场景都处理才算修复，修改好的问题自己要先核对正确了再提测，不要反复浪费时间；
上预生产，上生产，负责人要提前做好脚本和配置的工作，同时要核对下预生产和生产是否跟测试环境有差别，提前规避因为此类问题导致上预生产/生产的时候才发现问题，耗费时间；
问题修复及时更新状态给测试，所有问题到测试手中都必须是已解决的，同时要区分延期，不处理，已处理。已处理代表是有修改内容，不处理和延期必须要跟测试和产品沟通确定ok才能改成这类状态，非缺陷的请备注好原因通知测试重新验证；
多版本同时在测试环境的时候，要注意不要版本之间混杂在一起；
多个需求在同个版本上线，各负责人合并代码，上线等各个节点需要互相通知，保证最后合并后的分支包含各部分内容，同时同一个版本打tag前最好使用相同分支号，这样打包部署才不会混乱；