愿景

各岗位相互配合，相互约束，尽量将问题前置，减少 bug，及时复盘，提升团队成员水平。

岗位规约

产品岗

理解需求本质，对需求的优先级要有准确的评估，控制两到三周一个迭代，敏捷开发。
需求文档原型细致全面，涉及到规则或多个场景时需要举例说明。
改动需求及时同步到开发人员，必要时进行投屏宣讲。
每周与业务方同步迭代内容和预计开发时间、上线时间。
需求评审之后，要求开发人员进行需求反讲，必要时进行二轮需求评审。
需求提测或测试结束之后，需要进行至少一轮的产品验收
需求提测或测试结束之后及时与业务方进行培训和测试环境试用
与开发人员确定开发周期，及时跟进开发过程，纠正业务偏差。

开发岗

测试用例及时同步到开发岗同事，开发人员需要根据测试用例自测，并对测试用例进行评审，查漏补缺，互相完善各自的工作。产品同事也需要对测试用例进行阅览，检查用例是否完善，是否符合产品设计。
开发人员提测时，要在对应的测试环境上自测一遍，确保功能无低级错误后再进行状态流转。
善于质疑需求，怀疑业务场景的合理性。如遇到在开发阶段需求有前后矛盾或者解决方案特别麻烦的时候，需要去考虑业务场景是否合理，开发方向是否正确，并及时的与产品和同事沟通，避免钻牛角尖，不要去盲目实现需求。
需求的实现方案一般会有多种，每一种方案都有利弊。当开发人员出现困扰时，一定要找产品或其他同事进行及时讨论，规避业务和技术风险。
开发人员需要具备系统的**全局视野，需要整体了解业务，不限于自负责的模块本身。测试人员如果要测试某功能时，要知道如何在系统上造数据。对于后端人员，还要求能在数据库表里写 SQL 造数据。
开发结束之后，互相Review代码并交叉测试。

测试岗

每个迭代输出测试用例并及时同步开发人员。
迭代上线之后发送邮件到相关业务方，标题为 YYYYMMDD 上线版本内容。
迭代结束之后需要进行缺陷统计，例如每个开发人员的 bug 数，重新打开数量等。

TAPD 规约

测试人员提交 bug 需要标注明确错误和复现条件，并配截图
如发现不是 bug，比如业务如此设计，流转拒绝，并添加评论
是本人的 bug，修改后，在测试环境自测通过，改为已解决，添加评论并写明原因+已自测截图，流转给测试。
不是本人的 bug，添加评论并写明原因，修改“处理人”为对应的开发人员，并口头告知对应开发人员
需求提测时，需要在测试环境自测通过，添加评论写明自测过用例的哪些范围，然后流转给测试
bug 修复人为多个开发时，比如开发 A、B，开发 A 改完 bug，添加评论已改完 XX 问题并写明原因和已自测截图，开发 A 将处理人改为开发 B，bug 状态不改还是“新”。开发 B 改完添加评论已改完 XX 已自测截图，流转为已解决给测试
bug 只能有测试人员关闭

团队建设

如下时间周期会视实际情况进行调整：

每隔 2 周进行迭代复盘。每周二下午，产品发起，成员参与。1~2h
每月第一周周四晚上进行技术分享会，全员都可发起。内容不限于专业技术，可以是某些插件、精品软件的分享、一次故障排查过程分享等。1~2h
每人制定季度自我成长计划，协助完成，并全员监督。