搜索
JIRA使用规范——IP-guard项目1.规范总则1)收到问题必须2天内回应2)还没开始处理的问题，要设置下次跟进时间，到期后必须在2天内回应3)正在进行中的问题，每周至少更新一次4)问题处理之前，要选择开始执行，并写预计时间5)问题处理过程中，每天要写工作日志6)问题处理完成，要选择执行完成，分配给后续经办人7)问题完成要及时关闭2.总体流程3.创建问题1)项目与问题类型所有跟产品IP-guard程序相关的技术类问题，都要提交到JIRA上，“IP-guard”项目或“IP-guard需求建议”项目。“IP-guard”项目包含旧版本JIRA中的“IP-guardV3”、“加密项目”和“功能测试”。项目：IP-guard需求建议（问题类型含：需求建议）代理商、客户、内部员工对IP-guard产品功能的建议、想法，都提交到“IP-guard需求建议”项目。由产品小组进行评审并回复。确认会实现的，则由产品小组按条目增加到“IP-guard”项目中。项目：IP-guard（问题类型含：BUG、测试、新功能、改进、任务）BUG：代理商、客户、公司内部发现的BUG，或者是怀疑是BUG的问题。通常由售后技术支持提交。新功能：新功能的开发项目。由产品小组或具体问题负责人创建问题。改进：对已有功能改进的开发项目。由产品小组或具体问题负责人创建问题。客户定制：专门为某客户定制的功能。通常由技术支持提交。测试：开发人员提交程序给测试人员测试。通常由开发人员提交。注意，如果某版本仅为了解决另一个已提交的BUG、新功能或改进类的问题，则不需要专门提交测试任务。任务：除了以上几种类型之外的问题。注意每个问题仅提交一个BUG。如果一个客户有多个BUG需要同时处理，可提交在一起。但是BUG和需求建议不可放在一起。每个测试任务仅提交一个版本。如果仅为了修复此版本出的后续同类型版本，可提交在一起，每次修改必须改版本号。如果一个待测试的版本仅解决了一个BUG，并且此BUG已经提交过。这种情况下，开发人员不需要新建测试任务，只把版本的修改情况写在之前提交的问题上。如果一个待测试的版本解决了几个BUG，这些BUG已经提交过。这种情况下，开发人员需要提交一个测试任务，列明所有解决的问题和处理方法，并提供原始问题的链接。在所有原始问题上也要写上问题原因及处理方法。2)主题一般模式为：[模块名]-[问题情况]。例：客户端-复制大量文件出现漏记客户端-正式版3.53.3227.0测试OEM-CYB需要替换自己的数字签名如果不能判断模块名，也可以不写。3)负责人经办人：现在需要处理此问题的人。所有经办人：选择处理此问题的所有负责人，通常当前经办人也要写上，否则当他转交给其他负责人之后，他将收不到邮件通知。一般包含处理此问题的开发、测试和技术支持人员。抄送：选择需要知道此问题的相关人员。客户端的问题要抄送何幸辉和李见明、控制台问题抄送关浩清、服务器问题抄送程超和江振标。经办人和所有经办人的区别：经办人是现在需要处理这个问题的人。所有经办人是过去、现在、将来需要处理这个问题的人。所有经办人和抄送的区别：所有经办人是对此问题要做事的人，抄送是只要知道有这个问题的人。比如说，有个新功能，由匡军开发，林显通测试，麦谦娜跟客户联系。现在是开发阶段，则经办人为匡军，所有经办人为匡军、林显通、麦谦娜。抄送何幸辉、李见明、何环、贺芳、李红平。开发完成到测试阶段，则分配给林显通，此时经办人为林显通，所有经办人仍为匡军、林显通、麦谦娜。比如说，客户反映了一个加密的BUG，需要测试。麦谦娜提交了问题，分配给何环，目的是希望何环安排人员测试问题，真正是由谁来测试还不知道，所以此时所有经办人中不填。何环安排张静测试此问题，则重新分配问题给张静，并且所有经办人中加上张静，抄送自己。张静测试完发现确实有问题需要客户端修改。如果张静不知道是哪位开发人员来处理，就分配给甘勇，抄送李见明。如果张静知道是由叶志昌来处理，就分配给叶志昌，所有经办人加上叶志昌，并抄送甘勇、李见明。叶志昌修改完成需要再测试就直接分配给张静。在邮件通知方面，所有经办人与抄送没有区别。分开这两种人，是因为这两种人对问题的关注度是不一样的。在主页左边最下方，有个“与我有关的问题”的列表。就是“所有经办人中包含我”的问题。比如说，张静测了一个版本，存在问题，分配给开发。这个时候对张静来说，“分配给我的问题”中就没有这个问题了。如果她想再补充备注，想再找回这个问题的链接就不好找了。如果“所有经办人”中写了张静，那她就容易在“与我有关的问题”中找到。4)优先级重要：产品不稳定，经常崩溃；核心功能无法使用；会导致操作系统或其他软件无法使用，影响客户的正常工作。一般：部份功能在某些情况下不能生效。次要：某个小功能无法使用，界面设计存在缺陷、凌乱或不友好。5)问题详情提交问题时需要填写问题的详细情况，如客户名、使用版本、OEM、环境、具体操作等。在其他平台有相关信息的要给出链接。如SVN上的文件、共享目录放的文件、CRM的问题ID等。如果问题很紧急，需要什么时间内完成，也要写下来。如果待测试的版本修复了多个问题，每个问题必须有个序号，并且序号不重复。如果一个问题下提交了多个BUG或者测试出多个BUG，则每个BUG必须有个序号，并且序号从不重复。6)附件图片类的附件可以直接上传。需求文档、设计文档、测试用例、使用说明等文档，放在SVN上，JIRA上只提供链接。从客户或代理商取得的数据，放在共享目录\\192.168.1.1\release\techsupport\CRM\，JIRA上只提供链接。7)工作时间原工作时间：计划处理此问题需要花费的工作时间。一般只有“新功能”和“改进”类型的问题，由项目负责人估计工作时间。剩余时间。在创建问题的时候不填。8)到期日到期日即为下次跟进时间，必填项。只有当前经办人和问题报告人可以修改此日期。经办人在到期日那天必须写备注说明问题的最新进展，并把到期日调整到下一次跟进日期。“更多操作”-“EditIssue”。注意，只写备注是不会自动更改到期日的，需要人为指定下一次的到期日。并且不能只修改到期日但不写备注。创建问题时，或者把问题分配给别人处理时，到期日必须设为两个工作日后。例如：3月13日创建问题，则到期日设为3月15日。收到问题后，两天内必须做出回应。即在到期日那天之前必须做出回应，如果问题还无法确定计划开始时间，则到期日为下次考虑计划的日期。例如：3月15日收到一个问题。但是3月工作已满，则到期日调整为4月1日，并写备注“本月无时间，下个月考虑”。到了4月1日，再考虑当月是否能安排，如果还不能，就又把过期日调整为5月1日，并写备注“4月也没时间，5月考虑”。如果确定了哪天开始处理问题，则到期日设为问题开始处理日期。例如：到了5月1日，能安排上在月中处理，就把过期日改开始处理的那一天，5月15日，并写备注“15号开始处理”。问题开始处理之后，到期日设为下个阶段跟进日期。比如说，到了15日，开始做了，估计要三天做完，到期日设为问题完成日期5月17日，并写备注“开始处理，计划17日完成”。如果问题处理的时间超过1周，必须划分细小阶段，至少一周更新一次。比如说，某个功能要10周时间完成，可分为5天写代码，2天自测，3天联调三个阶段。到期日则为5月17日（开始写代码），5月22日（写完代码），5月25日（完成自测），5月28日（完成联调）。建议订阅过滤器：“分配给我的问题（已到期）”，每天定时发送邮件，则每天能收到邮件通知，哪些问题今天需要跟进。4.分配问题如果收到一个问题不应该是自己处理的，不能放着不管，必须分配给合适的处理者。否则真正的处理者将不知道有这样一个问题需要处理。或者由于其他原因转给其他人处理，都要分配给对应的人。“分配”和“更新问题”都可以改变当前经办人。不同之处在于，重新分配可以修改所有经办人、抄送、到期日等。例1：测试人员测试完毕，需要开发人员解决，则重新分配给开发人员。如果开发人员觉得测试不完整，需要再增加某项测试，则要再重新分配给测试人员。如果此时不分配的话，测试人员在“分配给我的问题”中将看不到此问题，不知道还有这个问题需要处理。就算当时会有邮件，但过后有可能忘记。如果开发人员很关心此问题，担心分配给别人后自己找不到此问题，可以不分配。但是必须定期主动向测试人员询问进度。例2：技术支持提交问题给测试人员，测试人员没重现，需要向客户咨询更多环境问题，此时应该把问题分配给技术支持人员。如果没有分配，就必须定期主动向技术支持询问进展。5.开始进行开始进行，表示我开始处理这个问题了。点了“开始进行”之后，问题的状态就从Open变成InProgress。一般情况下，每个人的“分配给我的问题”都不只一个。比如说，有10件事情需要做，但是一个人同一时间只能做一到两件事情。在真正在做的事情上点“开始进行”，则别人可以看出，哪些事情是已经在做的，哪些事情是还没开始做的。选择“开始进行”。此时要填写“原预估时间”和“剩余时间”。原预估时间，即估计自己完成这项工作需要多少时间，比如说2天，4小时等。如果打开此页面时“原预估时间”里有值，则应该用原值加上自己估计的时间之和来填写。剩余时间填写预计还要多少时间完成，跟计划时间一样。仅指自己本次的计划时间。例如：一个问题开发阶段，开发人员估计开发时间为3天，他在“开始进行”的操作时，原预估时间显示为空，此处填了3天。开发完成给测试人员，测试人员估计要2天测试时间，那他在“开始进行”操作的时候，原预估时间显示为3天，加上自己估计要2天，则要把3天改为5天，剩余时间填自己估计的2天。6.工作记录有的问题不能在一天之内处理完，此时每天都必须记录工作日志。耗费时间：写今天花了多少小时多少分钟处理此问题。大部份时间是不需要细到分钟。不过此字段默认单位为分钟，如果忘了写单位，就会当成是分钟。开始日期：从什么时候开始处理此问题。剩余时间：估计还要多久能完成。工作描述：用一两句话描述一下进展，比如说这天做了些什么事情，遇到什么问题，完成了百分之几，进展是否顺利，能否按时完成等等。比如说，开始执行时，填写预估时间是3天，然后今天用了一天时间处理这个问题，进展跟计划的一样，剩下的还要2天。剩余时间可以用默认的“自动调整”。然后第二天，又工作了一天，但是因为遇到一些困难，结果只做了一半事情，剩下的工作可能还要一天半才能完成，此时剩余时间就要选择“设置为一天半(1d4h)”。7.停止进行停止进行，表示问题处理了一部份，但因为某些原因暂时停止处理。点“停止进行”，状态就会从InProgress变成Suspended。比如说在做A事情的时候，做到一半，有个更紧急的事情B要马上处理。此时就应该把A事情点击“停止进行”，把B事情点击“开始进行”。8.处理完成当一个人对一个问题中，自己要处理的部份处理完了，需要转交给下一个人处理，此时要点击“处理完成”，并指定后续的经办人。此时状态会从InProgress变成Open。注意，这种情况不要使用“分配”，“分配”不会改变问题状态。例如，一个问题，A开始处理时，点了“开始进行”，问题状态变成InProgress。后来A做完了，要交给B做下一步，如果用的是“分配”而不是“处理完成”，那么，分配给B之后，问题状态仍然是InProgress。但是对于B来说，他根本还没有处理这个事情，但是别人看到状态已经是InProgress，就会误以为他有在处理。所以问题转交给别人的时候，要注意用“处理完成”把状态恢复成Open。选择“处理完成”时，也要填写工作日志。如果之前从来没填过工作日志，则写所有工作时间。如果之前有写过工作日志，则此处只写上一次写日志之后到现在所花的时间。另外还要把剩余时间选择设置为0。9.解决问题当一个问题有内测版、或特别版解决，并且测试通过，但是此修改还没有加到发布版。此时可以点解决问题。10.关闭问题关闭问题，表示问题处理完成。通常由提交者关闭。以下几种情况可以关闭问题：1)当BUG或新功能已加到发布版2)当BUG或新功能不需要加到发布版，有