适用团队人数：
产品——2
前端——3
后端——4
客户端——4
一、角色职责及产出物
产品经理
职责
1.需求沟通：与需求方沟通，对需求的价值及可行性做判断及把控，设计出合理的解决方案
2.产品原型及文档：根据需求进行原型设计，与需求方沟通明确需求双方确认无误后给到UI进行高保真设计，撰写产品需求文档
3.发起需求评审会，将需求移交给开发和测试
4.项目中与各方沟通：对内对外的各方面沟通工作，与项目经理配合，确保各方可平滑协作，面对需求变更及时给出合理解决方案，与项目经理和需求方沟通是否调整上线计划，更新需求文档，确保顺利上线
5.核对测试用例：保证测试用例与产品设计一致
6.产品验收：测试完成后，产品和需求方进行验收。确保产品与设计预期一致流程走通。验收完成后可上线
7.阶段性复盘及规划：能根据实际内外情况，对产品方向进行复盘及必要的调整，保证产品总体朝着正确的方向发展
产出物
-原型图
-需求文档
项目经理
职责
1.对项目团队进行有效的管理和协调，与技术、产品沟通，明确项目需求，负责组织项目每个sprint前的任务划分、明确开发人员的任务分配和工时；参与完成项目开发和部署实施（包括需求调研评审开发部署上线验收等）
2.跟踪项目进度，对各个环节进行把关，协调项目组成员之间的合作，确保项目目标的实现，领导项目团队准时、优质地完成全部工作
3.与需求方沟通，有效控制客户需求，并即时反馈阶段性成果（排期邮件+上线通知邮件），与需求方共同解决和协调项目开发过程中遇到的所有问题；
4.开发过程中如遇新增需求或需求变更,项目经理需要跟产品经理和需求方了解需求,且同项目组成员（开发、QA）商量是否影响排期，如影响排期需跟需求方协商优先级，最后决定是重新排期或需求后置。如需重新排期，邮件通知相关人员。
5.了解测试结果,根据测试的bug的严重程度来判断是否重新更改开发计划。
6.阶段性项目总结，根据项目类型合理制定项目计划
产出物
-排期邮件——包含需求概述、关键时间节点、对应开发、上线时间
-上线邮件
-需求拆分后建入TB
设计师
职责
1.根据产品需求原型做出高保真设计图
2.配合开发提供设计素材
3.设计文件更新及时同步到相关人员
4.跟踪开发设计还原度、交互还原度
产出物
高保真UI图
PS.还原度先修改优先级高的，若改还原度时间与最终与上线时间冲突时，以上线为重；剩余还原度留在下期修改。
开发负责人
各端各一个负责人
前端：缺位
后端：龙文
客户端：林建
职责：
1.技术方案制定
2.开发人员安排
3.制定开发规约
语言：命名、注释、代码组织；防范措施、测试
开发
职责
1.开发规约——由负责人制定，开发执行
2.项目文档说明，如模块说明、项目架构、所用技术
3.实现需求，改bug通知QA
4.离职人员交接文档
产出物
-程序
-文档
n交接文档
n工程说明文档——谁建项目谁写，参与者补充（目前项目待健全文档）
大概结构、整体流程、运行环境、涉及技术、注意事项、特殊配置等
n接口文档
•规约——负责人写，开发遵守
语言：命名、注释、代码组织；防范措施、测试
测试负责人
职责
1.了解需求，协助产品完善细节及特殊场景假设，从需求会议明确本期项目质量标准并根据需求写测试用例
2.测试阶段：bug分级和指派，2周以上迭代项目，测试过程中发测试报告，明确开发质量以及项目bug修改进度
3.上线测试：主流程复查；p1及以上bug重新验证；确认最后代码修改时间；结合项目本期质量要求标准，对正常项目核对上线检查单
4.线上Bug反馈收集，根据紧急程度指派开发修改并进行回归测试
产出物
-测试用例
-测试报告
《测试报告》内容：
1．包含下述主要评价指标——按人员对应
2．包含本期遗留bug说明（个数／等级／描述／处理建议：转下期／延期／建议需求变更等）
3．包含本期质量综合评估，后期风险警告
二、项目流程
A.普通项目流程
产品设计——UI设计——开发——测试（包括还原度）——产品验收——上线
阶段性产物
-产品设计：原型图
产品经理将原型与需求方核对过后发给UI制图
-UI设计——高保真图
传zeplin和源文件传TB并告知相关人
-需求评审会——需求文档、项目排期、任务划分
-项目排期关键时间节点（需求简述、前后端联调时间、测试用例时间、提测时间、验收时间、上线时间）
项目排期表邮件发送给相关人@项目经理
-提测前——测试用例
与产品经理核对修改测试用例，发给相关开发自测
B.敏捷开发流程
固定1周或2周一个迭代周期，固定上线时间为每周四。需求划分后，从需求池中选出优先级高的需求，剩余的在需求池中放下个版本迭代；如遇紧急需求或优先级更高的需求，原先的需求顺移到下个需求周期上线。其他流程与普通流程一致
C.特殊流程
如遇需求不确定、上线日期固定、需求频繁变更、没有产品经理、单次应用不再维护的需求等情况，请负责人发挥人格魅力和无穷智慧具体情况具体分析，需求方过于强势建议请示领导出面= =
三、过程指标
1.功能缺陷率＝功能bug数／原代码行数／1000（SLOC）优秀：0-3‰；一般：3-10‰；待改进：10‰以上
对迭代版本来说，本期缺陷率＝新增的bug数/新增+修改+删除代码行数
2.缺陷密度＝缺陷数／测试用例数（当前版本执行的用例总数＋基线用例数）
3.返修率（re-open）＝ 返修bug总数／有效bug数
4.bug收敛率＝本轮测试新增bug数／当前未修复bug总数
5.测试阶段提交次数：版本驳回率（版本提交后测试问题过多，每走一个功能点就出现多个问题等，严重影响测试效率；提交后无法按流程进行测试，排除两小时仍没有解决）
p.s.一味以单个指标度量对质量会有反效果，应综合考虑。且繁琐的文档和会议可能会打断开发人员的思路，客观上延长项目开发周期，提高了出错量。
缺陷分级说明：
（注：缺陷分级以影响程度为首要考虑。修复难易程度作为参考。缺陷分级评定建议：测试为主。少数不确定的和产品经理／项目经理／需求方协商。）
p0（很少）－－无论处于哪个阶段，尽可能马上修复
影响当前他人工作进展的；影响占比1%以上用户使用的；
如：用户数据丢失或破坏；系统崩溃死机；模块无法启动或异常退出；严重数值计算或跳转逻辑错误；功能设计与需求严重不符；系统测试阶段导致无法继续测试的错误
p1－－最后一轮测试前要求全部解决。如线上存在，则尽快修复解决
如：功能未实现，功能错误，系统刷新错误，数据通讯错误，轻微的数值计算错误，系统所提供的功能或服务受明显的影响，操作界面错误，数据窗口内列名定义含义一致性，边界条件下错误，提示信息错误，长时间操作无进度提示，系统未优化（性能问题），光标或点击事件定位错误
p2－－上线前要求解决。但不因此修复重新上线
少数场景会出现的异常处理，小概率偶现的p1问题
如：界面格式等不规范，辅助说明描述不清楚，操作时未给用户提示，可输入区域和只读区域没有明显的区分标志，个别不影响产品理解的错别字，文字排列不整齐等一些小问题
p3－－细节优化；或只出现一次，反复探索未复现的bug等
四、管理工具——TeamBition使用规范
a)项目经理根据需求拆分成任务模块建到任务列表中并指派给对应开发
b)开发人员根据工作将任务移动到【开发中】，完成后移动到【测试中】
c)测试阶段，测试在【Bug列表】写明bug并指派给开发
d)开发或产品认为是无效bug的，在评论中说明情况，并回指给测试
e)开发修复bug后转指派给测试人员。测试验证后勾掉
f)上线检查中测试人员把任务移动到【待上线】。上线后勾掉完成
PS.
1.进入测试阶段，开发人员需保持TB页面打开，查看bug状态更新提示
2.如有指派错误，该开发有责任确认这个bug修复情况。转指派或主动告知测试
3.所有人员发现线上bug或收集到bug统一反馈给测试，由测试指派给该功能开发人员，如遇bug非该开发问题，则再转指派给对应的人并告知测试
