产品&研发&测试在敏捷各环节的职责

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/kaka1121/article/details/89187863

 PM：产品经理

 RD：开发

 FE：前端开发

 QA：测试

TTL：tech team leader   产品负责人、研发负责人、测试负责人

规范|角色	PM（含UE）	RD（含FE）	QA	备注
迭代、项目开始前	项目启动一个月前需要PM给出ppt或者word介绍项目方向，规划等，供相关RDQA知道项目目标；	参与PM的规划会、或认真研读PM产出的规划文档；
	迭代启动的前一周，迭代的story已经在PM内部审核通过，并已经告知了相关的RDQA。 审核通过后再告知RDQA存在两个问题 Story拆分不合理； Story与现有架构设计不一致； 建议:与ＴＴＬ，ＱＡ根据现有架构进行拆分story	项目，迭代启动前给出建议（非必选）
	需求技术评审之前，PM内部把迭代的内容内部review通过，确保需求在业务上互相不冲突，关联顺序合理。
	需要上下游配合的需求， PM找上下游团队PM协调配合好团队的资源；如果没有协调成功，story不进入迭代。
需求进入RDQA评审前	Story已经录入需求管理系统，且描述完整。包含背景，内容，意义和验收点，涉及前端的需求最好有UE图，如没有UE图也尽量绘图描述。验收条件由PM给出，QA后续完善。本迭代需求已经确认后，PM需提前准备下一迭代需求，并准备后补开发需求。	如有技术优化和过程改进的需求，录入需求管理系统，并和PM讨论后，一并进入评审
迭代启动会，需求评审   是否在评审之前的拆分的时候就已经明确下来分支。如果一次评审没通过反复评审浪费时间与敏捷精神不符；	对于Story中没有明确描述的细节（如提示信息、弹出浮层效果等），RD+FE可以结合实现需要，提出改进建议，PM调整story卡片内容（1天内完成）；	评审中提出对PM提供Story的异议；遇到不完整，过于简单的story，如果1天内，PM未完成完善，可以拒绝本迭代完成；（标准：描述完整：包含背景，内容，意义和系统表现，涉及前端的需求最好有UE图，如没有UE图也尽量绘图描述。）		评估和设计时需要考虑0 bug chekclist的内容。
	PM统一接口并负责管理（含其他业务PM，及RDQA发起的需求）；	即使是自发的需求，也需评审，告知PM
	迭代开始后不许插入新story，特别紧急的情况，需要PM说明紧急的原因，（如“不做该Story的影响范围和导致的损失”），然后发起和RDQA一起评估，选择是否将其他story延后来保证紧急需求；	对合理的紧急需求尽量想办法响应；对于不合理的紧急需求进行果断拒绝
		完成开发估点，明确交付测试团队时间	完成测试估点，明确测试用例交付RD团队时间，明确测试完成时间，明确阶段性提交story时间避免批量提交积压	估点和排期是两个概念，对于新人同样的点数下， 允许考虑熟练因素有排期差异；每轮迭代的团队速率是本轮迭代所有卡片的估点取和；     团队的速率是统计本轮迭代的所有Story、Task、Bug的估点总和。     除了PM提供的需求Story，RD、FE、QA可以根据项目自身的需要，每迭代增加一些调研、性能优化卡片，以解决一些技术负债，防止出现大规模的影响系统稳定性和性能的问题；此类卡片的点数，要算到团队的迭代交付中。
		全团队统一估点基准，不能局限于自身的经验和技术来做出判断；Story的估点，是对Story复杂程度的衡量，不应考虑当前Story的负责RD是否对这个模块很熟悉，或是不熟悉，应该仅从模块分解后的复杂度入手考虑； 迭代启动会之前对上次迭代估点进行分析。对估点过大或过小的story分析其原因。	迭代启动会上，估点完毕+验收条件补充完毕，由QA负责将本迭代的所有需求卡片的状态更新（需求池转待开发），迭代第一天完成
		建议一个RD一次只认领一个卡片，对于有多角色共同实现的Story，可以通过Story拆分为task解决。可以考虑前端、后端的联调，与外部系统的联调等影响复杂度的因素，对估点进行适当的调整； 建立story　Owner制度。负责人对拆分的task进度整体负责
	对于复杂的Story（点数>8），可以通过Story拆分，将点数尽量控制在8点之内，以避免卡片太大出现跨迭代的现象；
开发期间（综述）	重视项目中RDQA发出的报警或问题邮件，参与一起协商解决问题	遇到不符预期的外部依赖，相关负责人或接口人，应提前发出邮件周知项目组所有成员，以便跟进解决或调整排期。
	过程中发现的需求问题，PM及时跟进，并更新Story卡片（一天内）	尽量在需求评审中发现需求问题，在项目过程中才发现的需求问题，在与PM沟通时，能够根据当前的业务场景，给出自己的建议，有的放矢的进行讨论，而不是简单的抛问题；
	遇到和QA看法不一致的bug，和RDQA裁决是否修改需求；	不得抵触bug，私自要求QA不发bug；遇到和QA看法不一致的bug，由PM裁决是否修改，不得直接否定bug；	遇到任何可能是问题的都一律发bug，严格按照bug管理规范填写bug的各个字段；对于不知bug具体负责人的情况，需求bug填写PM负责人，代码bug填写RD负责人；
	对RD的minishow给出明确的接受或拒绝结论	RD在交付之前根据QA提供的冒烟case（什么时候提供，包含在验收标准？）进行minishow； show给PM（截屏，或者视频）和QA（现场）	对RD的minishow给出明确的接受或拒绝结论； 并记录showcase的次数和失败的百分比；
	ReviewQA的测试用例并反馈建议	ReviewQA的测试用例并反馈建议	产出测试用例供PM、RD review和参考；PMRD可对测试用例的质量作出判断和打分，反馈给RD负责人，RD负责人定期反馈出来；小组负责人可根据结论做相应的奖励和惩罚。	质量分级测试，对于AB级别的story，提供RD冒烟测试case，供RD自测，RD自测冒烟通过后，QA测试；对于C级别的story，提供测试用例，RD自测，QA不测；D级别的storyRD自测，QA不干涉；所有测试用例都发给RDPM review。分级过程在PM写完验收条件后由PMQARD共同确定参与
	PM小范围补充完善Story，需确保RDQA知晓，并修改Story卡片，不得私自修改内容	复杂story产出详细设计，供RD架构师评审，评审后更新设计，不得以项目紧急为由省略设计文档；	评审详细设计，根据详设拟定相应的测试方案；
		遇到本迭代不能完成的story，不得发布的跨迭代需求，需新建一个跨迭代分支，将本迭代不发布Story的代码统一提交到此分支；	违反的发S0P0 bug	见sheet"Bug提交规范" 需要注意bug的完整性，包含岗位说明，重现步骤，预期结果和实际结果的差异。避免直接写“ xx页面'经常'报错，xx页面无法操作，xx页面偶尔报错等内容。”应该是XX用户，在XX环境下XX方式登录，点击XX，XX，XXX，出现报错页面，报错内容XXX“ 避免重复bug，如一个页面五个字段没做校验报一个bug，说明有5个字段有问题，如果RD修复时候，只修复了3个字段，reopen该bug，说明哪些没有验证通过； 再如一个基础指标错误，导致十张报表错误，报一个bug说明原因，如实在不好判断，也可发多个bug，RD可协商保留一个bug，其他bug标记为duplicated；凡是做了此操作的的，多个bug算作一个，同样，如果修复后，多个bug只要任何一个bug修复不完整，需要reopen无标记dup的bug。
		紧急上线需将上线的代码提交到上一次上线的分支中用以测试、上线；并同步提交到主干，保证主干的一致性。
		对于估点大于等于3点的Story，指定Code Reviewer（包括FE），代码提交时写明是谁review通过（要求必须要review结论）；代码嵌套深度超过10的代码reviewer需要打回；	用SNV钩子控制注释内容，QA抽查注释质量并记录。 工具Feedboy发现代码嵌套超过10时会发邮件报警，届时相关QA需记录bug，责任人由代码提交人和reviewer共同承担；	SVN注释规范见sheet “SVN注释规范”
		每完成一个Story，RD需根据Story的验收条件进行自测，并在负责Story中，发表评论：CR: ***，self-test Pass；如果本Story不需要CR，则添加评论：self-test Pass。然后将Story的状态置为“待测试”；	QA可根据自己的判断，下结论自测充分等级，提供自测评分给QA负责人，QA负责人定期发布结论；小组负责人根据结论可做响应的奖励或惩罚。	自测完成后提测，同时挪动卡片到待测试；不及时挪卡的可算作提测延期；
		新增代码超过20行时，单测行增量覆盖率不低于50%目前的平均值已经是60%可以70%，即产品代码与单测代码要同步提交；如每迭代，有三次违规，由小组负责人确定惩罚措施，并邮件出来发送小组成员，抄送RD，QA经理。	QA配置工具，在每次提交代码时通过Jenkins监控，如果未达到要求，发送邮件通知全组；对于三次不达标的情况，要求RD参与手工测试；	如果连续两次出现未达标情况，项目组迭代回顾会将进行case study，需个人做出解释和说明，并在学习相关的UT&IT知识后，进行组内分享；
Story测试	及时响应需要PM介入的项目问题	对于需要延期修复的bug，或者认为可不修复的bug，需要和PM，QA协商；	提测后的story如有不完整的情况，发bug；不擅自接受RD延期完善，或者下个迭代完成的解释；	QA有发现bug不报bug的情况，算违反项目流程，影响KPI，页面上有些展示例如易用性之类的
		bug修复后自测，自测完成后挪卡到待测试；	对待测试的bug卡及时验收，验收成功的挪到已解决，验收不成功的及时挪回待开发，并记录reopen的次数到相应的字段；	针对加入的紧急需求，QA在保证原有上线story功能正确的基础上，保证紧急需求的基本功能点的正确性，异常情况和分支不做保证。
迭代、项目验收期	在QA的回归测试环境内做迭代story验收	确定上线的分支，并冻结代码；只能修复回归测试中发现的小问题，避免大面积的代码改动；	回归测试，对迭代内的story进行最后的验收；同时提供测试环境给PM做验收；
	和RD及时沟通验收问题，看是否有必要调整上线的时间；	对于大的问题做评估，影响上线的问题需及时告知PM	和RD及时沟通回归发现的问题，如影响到上线需要和PM进行沟通，调整上线的时间；
		提供上线步骤和上线checklist的签字文件给QA；	上线步骤进行review，如有问题，打回让RD重新进行修改；检查是否完成了上线checklist。	上线cheklist海燕负责更新
	PM根据测试报告确定是否正常上线	review测试报告，了解项目情况	产出测试报告供PMRD参考
上线、上线后	线上验证	线上验证	QA发出上线验证checklist，保证PM和RD针对功能点进行线上验证（上线当天完成）；
	项目回顾总结，对于紧急需求变更做casestudy，防止类似事件发生；	项目回顾总结，提交的Story，出现大于等于2个bug时，项目组迭代总结会进行CR的case study，针对出现问题的Story，集体进行CR，并review相关知识；	项目总结，提供项目的过程数据；包括bug量，bug率，reopen率；showcase失败率；自测充分率；注释达标；开发效率等数据，迭代内修改代码量和点数的比率等数据；对于不及时发bug，漏发bug的情况作casestudy；
	项目总结回顾会：对项目的整体情况开会总结，避免做的差的问题后续继续犯，分享好的经验供后续发扬光大；专业的态度对待回顾会，对事不对人的提出问题和解决方案；