JIRA项目执行与管理方案

1、.JIRA 项目执行与管理方案Ver1.01/10.一.项目流程1.瀑布模式：1.1 需求管理：1)由产品经理提出确认需要做的需求，然后在JIRA 里，在自己团队的产品线产品项目下，建立一个需求Issue ，指派给团队的开发LEAD 。2) 瀑布模式下，建立需求的 Issue 类型，选择 New Feature 。3) 产品需要为需求编写 PRD ，并上传到 Confluence 自己项目团队的空间目录下。同时将PRD 文档的链接地址，填到需求Issue 的描述里。1.2 项目计划：1) 需求评审后，项目团队进行项目计划。2) 项目计划会上，决定项目的若干个Milestone ，由 PMO 为

2、每个 Milestone在 JIRA 上该项目下建立类型为Milestone的 Issue ，并指派给该项目的项目经理。3)项目计划完成后，由 PO 或者项目经理放到Confluence自己项目团队的空间目录下。1.3 技术设计：1) 产品研发团队在过完需求 PRD 评审 / 沟通会议以后， 研发团队需要完成技术相关设计，文档放到 Confluence 自己项目团队的空间目录下。2)开发 LEAD 把技术设计文档的链接地址添加至需求Issue 的描述里。3) 技术设计需要经过技术评审会议， 评审会议结果放到 Confluence 自己项目团队的空间目录下。1.4 测试设计：2/10.1) 产品

3、研发团队在过完需求 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) 测试

4、 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 测试之前， 研发团队上线负责人需要编写一份上线计划，文档放到

5、 Confluence自己项目团队的空间目录下，并把文档链接地址添加至需求 Issue 的描述里。3/10.2) 研发团队上线负责人， 在 JIRA 里需求 Issue 之下，建立一个上线 Task，Issue类型选择为该需求 Issue 的 Sub-T ask ，并指派给上线负责人本人。2. 敏捷模式：2.1 需求管理：1) 由产品经理 PO 或者 Scrum Master 在 JIRA 的 Agile 里，为自己的敏捷团队建立一个AgileBoard ， Board 类型选择Scrum ，并为 Board选择自己所在的项目。2)由产品经理 PO 提出确定需要做的需求，然后在JIRA 里自己

6、的项目下，建立需求 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 文档的链

7、接地址，填到需求Issue 的描述里；或者直接在较小的Story 描述里写清需求。7)需求的一些文档或者是原型图、交互等设计图材料，需 要PO放到Confluence自己项目团队的空间目录下。2.2 Sprint Planning：4/10.1) 每个 Sprint 开始前，团队进行 Sprint 计划会议。2)PO 或者 SM 在 Scrum Board里，为团队建立一个新的Sprint 。3)在计划会上，团队确定这个Sprint的开始时间和结束时间，以及所有该Sprint要完成的Story ，由 PO 或者 SM 把相应的这些Story 拖进该 Sprint 。4) 团队成员根据这些 St

8、ory 需求，拆解出完成这个 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) 如果出现需求变动，则由整个团队进行沟通协调，按照优先级做出决

9、定。并且按照决定，由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回顾会。5/10.2) 在回顾会上， 团队成员们需要总结 Sprin

10、t 中出现的问题， 并转化成 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 ） 建

11、立后为OPEN 状态；2 ） 当开始进行该TASK 后，经办人点击“开始处理“，将TASK 状态变为InProgress ；3 ） 当该 TASK 完成以后，经办人点击“关闭问题“，解决类型选择”完成“并点击”关闭问题“。TASK 状态变为 Closed 。4 ） 如果有需要， 可以点击 “重新开启问题“按钮，TASK 状态变为Reopened。1.2 需求 New Feature：1 ） 建立后为OPEN 状态；2 ） 当这个需求研发团队开始进行设计以后，经办人点击 “开始处理“， 将 New6/10.Feature状态变为 In Progress；3 ） 当该 NewFeature下的包括

12、开发、测试等所有子任务都完成，并且需求成功上线后，经办人点击“关闭问题“，解决类型选择”完成“并点击”关闭问题“。 New Feature状态变为Closed 。1.3 BUG ：1 ） 发现人员建立BUG 后，指派给相关的开发人员，指定其为BUG 的经办人，此时 BUG 为 OPEN 状态；2 ） 当经办人开发人员解决了该BUG 并在测试环境自行检查通过后，点击“解决问题“，选择合适的解决类型（Fixed,Wont Fix, Duplicate, CannotReproduce），并点击”解决“，将BUG 状态变为Resolved ；3 ） BUG 状态变为Resolved后， BUG 的报

13、告人对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 移动到 SprintBoard的 In Progress列，

14、状态对应In Progress/Resolved。7/10.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 都

15、变为 Done 时，则表示该Epic 完成，由经办人修改 Epic 状态为 Closed 。2.3 BUG ：1)发现人员建立BUG 后，指派给相关的开发人员，指定其为BUG 的经办人，此时 BUG 为 OPEN 状态；2) 当经办人开发人员解决了该BUG 并在测试环境自行检查通过后，点击“解决问题“，选择合适的解决类型（Fixed, Won t Fix, Duplicate, CannotReproduce），并点击”解决“，将BUG 状态变为Resolved ，同时可以在“描述”里填写合适的解决原因；3)BUG 状态变为Resolved后， BUG 的报告人对BUG 进行 Verify工作

16、。如果验证后发现BUG 已经被解决，则报告人点击“关闭问题”将BUG 变为CLOSED 状态；如果验证后发现BUG 依然存在，则报告人点击”重新开启问题“，将BUG 状态变为REOPENED 。2.4 Sprint ：8/10.1 ） Sprint指定开始时间和结束时间。2 ） Sprint从开始时间开始。3 ） 当 Sprint 结束后，由 PO 或者 SM 点击 Complete Sprint来结束这个Sprint 。4 ） 结束后的Sprint无法重新打开。5 ） 如果已经结束的Sprint有未来得及完成的Story和 Task，可以放到下个Sprint继续进行。三 . 项目管理1. 瀑布模式：1.1 Confluence项目目录下的文档检查：1) PRD2) 项目计划3) 技术设计4) 技术评审结果5) 测试计划6) 测试用例7) 上线计划1.2 JIRA 上的项目相关Issue 检查：1) 需求 Issue 类型与状态2) 开发 Task 类型与状态3) 测试 Tas