JIRA项目执行与管理方案.doc

《JIRA项目执行与管理方案.doc》由会员分享，可在线阅读，更多相关《JIRA项目执行与管理方案.doc（11页珍藏版）》请在装配图网上搜索。

JIRA项目执行与管理方案 Ver1.0 一. 项目流程 1. 瀑布模式： 1.1 需求管理： 1) 由产品经理提出确认需要做的需求，然后在JIRA里，在自己团队的产品线产品项目下，建立一个需求Issue，指派给团队的开发LEAD。 2) 瀑布模式下，建立需求的Issue类型，选择New Feature。 3) 产品需要为需求编写PRD，并上传到Confluence自己项目团队的空间目录下。同时将PRD文档的链接地址，填到需求Issue的描述里。 1.2 项目计划： 1) 需求评审后，项目团队进行项目计划。 2) 项目计划会上，决定项目的若干个Milestone，由PMO为每个Milestone在JIRA上该项目下建立类型为Milestone的Issue，并指派给该项目的项目经理。 3) 项目计划完成后，由PO或者项目经理放到Confluence自己项目团队的空间目录下。 1.3 技术设计： 1) 产品研发团队在过完需求PRD评审/沟通会议以后，研发团队需要完成技术相关设计，文档放到Confluence自己项目团队的空间目录下。 2) 开发LEAD把技术设计文档的链接地址添加至需求Issue的描述里。 3) 技术设计需要经过技术评审会议，评审会议结果放到Confluence自己项目团队的空间目录下。 1.4 测试设计： 1) 产品研发团队在过完需求PRD评审/沟通会议以后，测试团队需要完成测试相关的测试计划、测试用例等，文档放到Confluence自己项目团队的空间目录下。 2) 测试LEAD把测试相关文档的链接地址添加至需求Issue的描述里。 1.5 开发阶段： 1) 开发LEAD根据技术设计，在JIRA里需求Issue之下，建立一个或若干个研发Task，Issue类型选择为该需求Issue的Sub-Task，并指派给相应的开发人员。 2) 研发Task可以包括Coding、Bug Fix、JUnit、数据库脚本编写等任何与技术实现相关的任务。 1.6 测试阶段： 1) 测试LEAD根据测试计划，在JIRA里需求Issue之下，建立一个或若干个测试Task，Issue类型选择为该需求Issue的Sub-Task，并指派给相应的测试人员。 2) 测试Task可以包括测试用例编写、测试执行、测试数据准备等。 3) 测试人员在测试阶段发现BUG后，在JIRA里相应项目下，创建一个BUG，Issue类型为BUG，并指派给相应的开发人员。 4) 测试人员需要将BUG链接到需求Issue，链接类型选择relates to。 1.7 发布上线： 1) 在需求上SIT测试之前，研发团队上线负责人需要编写一份上线计划，文档放到Confluence自己项目团队的空间目录下，并把文档链接地址添加至需求Issue的描述里。 2) 研发团队上线负责人，在JIRA里需求Issue之下，建立一个上线Task，Issue类型选择为该需求Issue的Sub-Task，并指派给上线负责人本人。 2. 敏捷模式： 2.1 需求管理： 1) 由产品经理PO或者Scrum Master在JIRA的Agile里，为自己的敏捷团队建立一个Agile Board，Board类型选择Scrum，并为Board选择自己所在的项目。 2) 由产品经理PO提出确定需要做的需求，然后在JIRA里自己的项目下，建立需求Issue，指派给PO。 3) 如果需求比较小，则建立需求的Issue类型选择Story。 4) 如果需求比较大，甚至于无法在一个Sprint内完成，则将该需求建立需求Issue，的类型选择Epic。然后在此Epic下建立若干个小需求Issue，类型为Story。 5) 需求Issue建立完成后，Issue会自动出现在Scrum Board下，Plan里的Backlog下，并根据优先级从高到低，从上往下排列这些Story。 6) PO可以根据需要，选择为需求编写PRD，并上传到Confluence自己项目团队的空间目录下。同时将PRD文档的链接地址，填到需求Issue的描述里；或者直接在较小的Story描述里写清需求。 7) 需求的一些文档或者是原型图、交互等设计图材料，需要PO放到Confluence自己项目团队的空间目录下。 2.2 Sprint Planning： 1) 每个Sprint开始前，团队进行Sprint计划会议。 2) PO或者SM在Scrum Board里，为团队建立一个新的Sprint。 3) 在计划会上，团队确定这个Sprint的开始时间和结束时间，以及所有该Sprint要完成的Story，由PO或者SM把相应的这些Story拖进该Sprint。 4) 团队成员根据这些Story需求，拆解出完成这个Story所需要的开发、测试等TASK，并由PO或者SM建立这些Task，Issue类型为相应Story下的Sub-task，指派给相应的开发、测试人员。 5) PO需要把项目整体Sprint计划写进Confluence自己项目团队的空间目录下（比如7.28前分为几个Sprint，每个Sprint要完成的目标）。 2.3 Sprint阶段： 1) 团队成员需要每天需要定时进行Daily Scrum站立会，沟通整个Sprint的Story和Task的进展。 2) 如果出现需求变动，则由整个团队进行沟通协调，按照优先级做出决定。并且按照决定，由PO或者SM在JIRA里，对Sprint里的Story和Task进行变动。 3) 团队成员在Sprint阶段过程中，负责维护自己所负责的Story和Task的状态。 4) 测试人员在Sprint阶段发现BUG后，在JIRA里相应项目下，创建一个BUG，Issue类型为BUG，并指派给相应的开发人员。 5) 测试人员需要将BUG链接到相应的Story，链接类型选择relates to。 2.4 Sprint结束： 1) 每个Sprint结束后，整个团队需要进行Sprint回顾会。 2) 在回顾会上，团队成员们需要总结Sprint中出现的问题，并转化成Action。由SM或者PO记录到Confluence上相应的项目目录下，跟进实施改进。 2.5 发布上线： 1) 如果一个Sprint中有Story需要发布上线，则PO在计划会上为该Story建立一个上线Task，指派给上线负责人。 2) 在Story上SIT测试之前，团队上线负责人需要编写一份上线计划，文档放到Confluence自己项目团队的空间目录下，并利用Sprint的Linked pages功能把文档链接关联至相应的Sprint。 二. 项目流转 1. 瀑布模式： 1.1 开发&测试Task： 1） 建立后为OPEN状态； 2） 当开始进行该TASK后，经办人点击“开始处理“，将TASK状态变为In Progress； 3） 当该TASK完成以后，经办人点击“关闭问题“，解决类型选择”完成“并点击”关闭问题“。TASK状态变为Closed。 4） 如果有需要，可以点击“重新开启问题“按钮，TASK状态变为Reopened。 1.2 需求New Feature： 1） 建立后为OPEN状态； 2） 当这个需求研发团队开始进行设计以后，经办人点击“开始处理“，将New Feature状态变为In Progress； 3） 当该New Feature下的包括开发、测试等所有子任务都完成，并且需求成功上线后，经办人点击“关闭问题“，解决类型选择”完成“并点击”关闭问题“。New Feature状态变为Closed。 1.3 BUG： 1） 发现人员建立BUG后，指派给相关的开发人员，指定其为BUG的经办人，此时BUG为OPEN状态； 2） 当经办人开发人员解决了该BUG并在测试环境自行检查通过后，点击“解决问题“，选择合适的解决类型（Fixed, Won’t Fix, Duplicate, Cannot Reproduce），并点击”解决“，将BUG状态变为Resolved； 3） BUG状态变为Resolved后，BUG的报告人对BUG进行Verify工作。如果验证后发现BUG已经被解决，则报告人点击“关闭问题”将BUG变为CLOSED状态；如果验证后发现BUG依然存在，则报告人点击”重新开启问题“，将BUG状态变为REOPENED。 2. 敏捷模式： 2.1 开发&测试Task： 1） 建立后为OPEN状态，当TASK所在的Sprint开始后，TASK会自动出现在Sprint Board的To Do列，状态对应Open/Reopen。 2） 当某个Task开始进行之后，由该Task的经办人，将该Task移动到Sprint Board的In Progress列，状态对应In Progress/Resolved。 3） 当某个Task完成之后，由该Task的经办人将该Task移动到Sprint Board的Done列，状态对应Closed。 2.2 Epic&Story： 1） 建立后为OPEN状态； 2） 当Story下有Sub-task变为In Progress时，则由经办人把该Story拖到Board的In Progress列； 3） 当Story下所有的Sub-task都变为Done时，则表示该Story完成，由经办人把该Story拖进Done列； 4） 当Epic下的所有Story都变为Done时，则表示该Epic完成，由经办人修改Epic状态为Closed。 2.3 BUG： 1) 发现人员建立BUG后，指派给相关的开发人员，指定其为BUG的经办人，此时BUG为OPEN状态； 2) 当经办人开发人员解决了该BUG并在测试环境自行检查通过后，点击“解决问题“，选择合适的解决类型（Fixed, Won’t Fix, Duplicate, Cannot Reproduce），并点击”解决“，将BUG状态变为Resolved，同时可以在“描述”里填写合适的解决原因； 3) BUG状态变为Resolved后，BUG的报告人对BUG进行Verify工作。如果验证后发现BUG已经被解决，则报告人点击“关闭问题”将BUG变为CLOSED状态；如果验证后发现BUG依然存在，则报告人点击”重新开启问题“，将BUG状态变为REOPENED。 2.4 Sprint： 1） Sprint指定开始时间和结束时间。 2） Sprint从开始时间开始。 3） 当Sprint结束后，由PO或者SM点击Complete Sprint来结束这个Sprint。 4） 结束后的Sprint无法重新打开。 5） 如果已经结束的Sprint有未来得及完成的Story和Task，可以放到下个Sprint继续进行。 三. 项目管理 1. 瀑布模式： 1.1 Confluence项目目录下的文档检查： 1) PRD 2) 项目计划 3) 技术设计 4) 技术评审结果 5) 测试计划 6) 测试用例 7) 上线计划 1.2 JIRA上的项目相关Issue检查： 1) 需求Issue类型与状态 2) 开发Task类型与状态 3) 测试Task类型与状态 4) Milestone Issue的定时检查 5) BUG数量、分布、关闭情况 2. 敏捷模式： 2.1 Confluence项目目录下的文档检查： 1) Sprint计划 2) 需求原型等相关文档 3) Sprint 回顾会总结 4) 上线计划 2.2 JIRA Agile检查： 1) Burndown Chart 2) Sprint Report：未完成的Issue 3) Sprint Report：加入/移除的Issue 4) Epic Report 5) BUG数量、分布、关闭情况