JIRA项目执行与管理方案

一.项目流程

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、BugFix、JUnit、数据库脚本编写等任何与技术实现相关的任务。

1.6  测试阶段:

1)   测试LEAD根据测试计划,在JIRA里需求Issue之下,建立一个或若干个测试Task,Issue类型选择为该需求Issue的Sub-Task,并指派给相应的测试人员。

2)   测试Task可以包括测试用例编写、测试执行、测试数据准备等。

3)   测试人员在测试阶段发现BUG后,在JIRA里相应项目下,创建一个BUG,Issue类型为BUG,并指派给相应的开发人员。

4)   测试人员需要将BUG链接到需求Issue,链接类型选择relatesto。

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状态变为InProgress;

3) 当该TASK完成以后,经办人点击“关闭问题“,解决类型选择”完成“并点击”关闭问题“。TASK状态变为Closed。

4) 如果有需要,可以点击“重新开启问题“按钮,TASK状态变为Reopened。

1.2  需求New Feature:

1) 建立后为OPEN状态;

2) 当这个需求研发团队开始进行设计以后,经办人点击“开始处理“,将New Feature状态变为InProgress;

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移动到SprintBoard的In Progress列,状态对应InProgress/Resolved。

3) 当某个Task完成之后,由该Task的经办人将该Task移动到SprintBoard的Done列,状态对应Closed。

2.2  Epic&Story:

1) 建立后为OPEN状态;

2) 当Story下有Sub-task变为In Progress时,则由经办人把该Story拖到Board的InProgress列;

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点击CompleteSprint来结束这个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)   MilestoneIssue的定时检查

5)   BUG数量、分布、关闭情况

 

 

2.   敏捷模式:

2.1  Confluence项目目录下的文档检查:

1)   Sprint计划

2)   需求原型等相关文档

3)   Sprint回顾会总结

4)   上线计划

2.2  JIRA Agile检查:

1)   BurndownChart

2)   SprintReport:未完成的Issue

3)   SprintReport:加入/移除的Issue

4)   EpicReport

5)   BUG数量、分布、关闭情况

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页