使用JIRA和Jenkins进行项目管理.docx

使用JIRA和Jenkins进行项目管理.docx

《使用JIRA和Jenkins进行项目管理.docx》由会员分享，可在线阅读，更多相关《使用JIRA和Jenkins进行项目管理.docx（25页珍藏版）》请在冰豆网上搜索。

使用JIRA和Jenkins进行项目管理

使用JIRA和Jenkins进行项目管理

（仅供参考）

1使用JIRA进行项目跟踪管理

1.1JIRA项目管理流程

1.1.1概述

项目的软件开发流程主要围绕实现一个个业务功能需求和非功能需求的需求分析、设计、开发、测试、发布验收，而参与人员最多的开发和测试环节是流程最容易出问题的环节，为有效使用JIRA进行项目管理，我们设计了以需求为主导的JIRA表单和流程（如下图）。

对应于软件过程的管理流程，本项目JIRA对应设置了以下的IssueType（问题类型）和3大管理流程：

【说明】

⏹【需求单】：

在需求分析、概要设计、详细设计阶段，将产生对一个需求的具体描述和实现设计描述交付到开发阶段，在JIRA中，体现为一份需求单，这些交付件全部作为需求单的附件，需求单的来源包括：

-需求阶段的原始需求，以一个业务功能为一份需求，通常在一周左右可以开发完成，例如“用户新增和查询功能”；

-系统优化和变更：

如果一些变更无法对应一份原始需求，需要创建一份新的需求单

⏹【子任务单】在开发阶段，一份需求往往需要三四天甚至长得多的时间才能完成，开发完成后也存在不断的优化和改进，因此，围绕需求在JIRA上设置了以下的管理跟踪对象子任务单（SubIssueType）

-开发任务单：

程序员拿到需求后，组长应该协调开发人员将需求分解为开发任务，在JIRA上创建任务单；

-设计问题单：

程序员拿到需求中的设计进行评估时，如果发现设计文档或者需求有bug，应该记录在案以便协调设计小组完善，在JIRA上创建设计问题单；

-变更单

但设计和需求人员需要对已经提交的需求和设计提交变更时，例如增加一个字段、变更原型样式、变更接口方法，均需要提交变更单；

-评审BUG单

主要是开发组长或者结对开发程序员在评审BUG时，将评审的BUG记录为评审BUG；

-测试BUG单

主要针对前期开发阶段的冒烟测试，测试人员对已经实现的功能进行测试，保证流程能够跑得通，如果发现BUG则创建测试BUG单；

⏹【测试问题单】

-主要针对无法对应到一份需求产生的BUG

⏹流程设置说明

-根据参与者、小组分工，设置以下流程

-需求跟踪流程

参与人员包括需求分析员、设计者、开发组长、程序员、测试组长、测试员、用户参与，只与需求单关联，但目前其他用户参与的流程主要由开发组长完成。

-任务跟踪流程

主要是开发组长和程序员两级人员参与，与开发任务单、设计问题单、变更单、评审BUG单，便于开发小组进行状态监控，部分单尽管涉及到设计人员，但为降低流程协调工作量，均由开发人员在面对面解决后对流程进行操作

-BUG跟踪流程

主要是测试人员和开发组间的流程跟踪。

详细的流程图如下：

1.1.2需求跟踪流程

【流程重点说明】

-开发人员必须在接受到任务后点击“开始处理”，以便跟踪哪些任务正在处理中；任务完成后点击“完成”；

-小组长在代码评审后，使用JIRA的批量流程操作功能，将完成开发的进行发布，在JIRA上点击“发布测试”；

-测试部分分为两个环节：

冒烟测试和集成测试；

-冒烟测试对应流程中的单元验收测试，在开发人员本机上或者该小组的服务器上每日构建后进行测试；测试通过后应立即进行JIRA“验收通过”操作；

-冒烟测试通过后，开发小组协调发布人员，进行各小组的代码集成，开发小组长在集成完成后，对相应的需求批量进行JIRA“完成集成”操作。

-集成测试，在冒烟测试后完成，一般每周发布一个版本到测试服务器给测试组进行集成测试；集成测试通过应立即执行JIRA“测试通过”该单据关闭；

-对于关闭的单，如再次发现问题可重新打开；

1.1.3任务跟踪流程

主要是开发组长和程序员两级人员参与，与开发任务单、设计问题单、变更单、评审BUG单进行关联，便于开发小组进行状态监控，部分单尽管涉及到设计人员，但为降低流程协调工作量，均由开发人员在面对面解决后对流程进行操作。

【流程重点说明】

-主要的流程由程序员完成；

-开发小组长一般情况进行整系统和阶段性代码的review，然后批量进行“完成代码评审”和“批量关闭”操作。

1.1.4BUG跟踪流程

-

2JIRA工作指引手册

3开发组长工作指引

3.1发布管理

目标：

-建立发布基线：

每周1和3检查所有的需求、BUG，保证所有的任务、BUG被关联到合适的发布测试版本；

-监控发布基线：

每天与小组成员交流，检查和review下一个发布版本中包括的所有需求、BUG是否如实反映了实际的状态；

-调整发布计划：

在发布前一两天，检查发布基线的内容是否能够保证按计划进行，如果不能则重新调整这些任务的发布版本；

步骤：

3.1.1版本基础库维护：

在浏览项目界面，在版本下可以看到所有规划的版本号，在开发阶段以Branches-v[yyyymmdd]命名版本号，yyyymmdd代表发布的日期，如果某个发布版本由于延迟而需要修改版本号，需要修改对应的版本号，以便与实际相符合。

维护项目的版本，请点击“管理项目”

在versions中，点击Manage链接

在以下界面中，进行版本“新增”、“删除”或发布功能”Release”：

3.1.2将问题单（Issue）关联到版本：

本功能确保所有的需求、BUG均被关联到合适的版本中，以便每一次发布时发布内容是清晰和反映实际情况：

⏹对未规划的问题单关联到版本：

点击“未规划”链接

在以下未规划列表中，点击“批量改变：

所有xx问题”：

选择需要规划到一个版本的所有需求或者BUG等问题单，点击下一步：

**注意：

一次只能规划一个版本，所以，选择的这些问题单必须在一个版本发布

选择编辑问题，并点击下一步

选择对应的版本号：

仔细确认本次批量操作：

3.1.3将已发布版本中重新打开/退回的问题关联到待发布版本中

在发布前，检查之前所有发布版本，如果发现有任何处理重新打开或者退回返工的需求或者BUG，将其关联到待发布的合适版本（允许一个问题关联多个版本）；

3.1.4检查问题单-版本关联的正确性：

⏹一般通过以下3类操作

-通过版本路线链接进入问题列表，反复检查每个版本的内容，使用以上方式批量调整问题单版本号，直至所有问题被正确关联：

-通过检查最新，点击浏览项目页面的“最新新增”、“最近更新”链接

检查以下列是否设置正确：

-通过模块链接来保证，点击浏览项目页面的“模块名”

一般情况，发布都是以一个模块为整体发布，通过交叉检查模块也可以保证发布的正确性。

-通过“所有需求”、“所有BUG”链接进入需求和BUG列表检查各个版本是否正确设置。

3.2任务分配管理

目标：

-保证所有问题单被分配到正确的责任人

-保证每个人的任务不被遗漏

-更正错误的分配

在JIRA系统中，任何问题单被创建时，责任人都被设置为任务创建人，开发组长应该每天检查任务责任人是否分配正确，一般可以通过以下操作：

3.2.1检查所有的问题单责任人是否分配正确：

-通过预设置的任何过滤器（例如，开发组长最常用的链接是通过版本号、“最近新增”、“最近更新”进入问题列表），进入问题单列表，并按照人员或者最后更新时间排序，逐个人员对比检查：

3.2.2检查每个人的问题单是否被遗漏：

-点击每个人员姓名进入该成员的所有需求和BUG，检查这些问题是否都属于该成员

3.2.3更正错误的分配

进入问题单编辑界面，重点修正以下字段：

3.3设计问题跟踪

由于设计和开发属于两个不同哦小组，因此经常出现以下问题：

-设计错误，导致开发无法进行

-本模块依赖的数据、接口没有被提供，使得开发无法进行

-程序员不喜欢交流由于这些设计问题导致任务被延误并作为任务无限延长的理由

-跟踪不及时将导致设计、开发小组、开发人员扯皮，任务计划被搁置无法保证

目标：

-所有的设计问题被跟踪

-开发组长/设计组长能通过JIRA协调设计问题及时得到解决

3.3.1所有的设计问题被跟踪

开发组长应在每日例会上了解所有成员任务的阻碍，并检查这些阻碍、以及开发成员和设计人员通过邮件、口头交涉的问题被JIRA正确记录。

如下图，开发组长可以通过JIRA首页的“所有设计问题”、或者进入单条需求单查看其包含所有的设计问题：

⏹“所有设计问题”对应的结果：

⏹单条需求单对应的设计问题（图示

标志的为设计问题）：

3.3.2开发组长协调设计问题及时得到解决

通过以上查找到的设计问题，开发组长可以导出一份打印的Excel与程序员、设计组长review，保证这些问题及时被解决，且流程被正确执行（对应状态列）：

3.4任务进度管理

目标：

-跟踪进度：

跟踪所有的需求和任务、BUG的原估算时间、已花费时间、剩余时间、逾期时间（即计划完成时间）在JIRA上得到如实反馈；

-调整剩余时间和逾期时间，使得任务进度与现实一致；

3.4.1跟踪进度

开发组长应重点跟踪版本号链接来跟踪未发布测试或者未集成的需求单；

-如下，点击一个即将发布的版本：

-进入以下界面

【说明】

✧逾期：

密切注意逾期日期是否能够保证，如果无法保证，重新调整；

✧状态：

在发布前，能够发布的需求或者BUG必须为“测试验收”状态，在集成测试前，所有的需求或者BUG必须为“待测试验收”状态。

如果部分问题由于各种原因被延迟，必须重新规划到下一个版本。

✧原估算时间、花费时间：

确保估算时间被正确设置（小组长主导、与程序员沟通和达成共识）、花费时间反馈必须正确（取决于程序员是否正确填写了工作日志）；

✧影响的版本：

保证其发布版本是争取的；

3.4.2调整剩余时间和逾期时间，使得任务进度与现实一致；

对任何一个需求或者BUG单，通过编辑需求或者BUG单，调整剩余时间和逾期日期，如下图：

4程序员工作指引

4.1检查个人任务

程序员登录系统后，在首页可以看到以下部分的过滤器:

-分配给我的任务：

责任人为当前用户的所有未关闭需求、BUG等所有问题单；

-开放的问题：

所有分配给我的问题；

4.2开始处理问题单（包括需求/BUG/子任务等）

-点击打开“已分配的”或“退回返工”问题单，如下图

-在可选工作流程区域：

点击“开始处理”，问题单状态调整为“处理中”；（**此步骤经常被程序员忽略）；

-下载相应的附件，阅读所有的需求、详细设计、原型、数据库E/R图等；

-如果设计有问题，点击“创建”子任务，选择“子任务-设计问题”，点击下一步：

-如果该需求无法完成，与开发组长协商，达成共识后点击“退回重新分配”，并输入备注；

-如果需要记录部分与设计组或者其他人员交流的信息，点击“写备注”，记录在案；

4.3填写工作记录，反馈实时进度

-在处理任务过程中，程序员需要通过记录工作日志，及时反馈任务使用的时间

-如图，点击“工作日志”区域的“完成记录工作”链接：

*所有的工时记录不要记录在子任务上，全部记录到需求单上

4.4完成处理问题单（包括需求/BUG/子任务等）

-打开相应的问题单，在可选工作流程区域：

点击“完成”链接；

5测试组长工作指引

目标：

-了解所有待测试需求、BUG的分配情况

-保证所有BUG被正确分配

-保证测试流程被正确执行

5.1需求测试分配管理

操作步骤：

-测试组长可以通过JIRA首页以下链接“待测试的需求”查看待测试的内容：

如下图，待测试的需求状态为“待测试验收”-对应冒烟测试，“待集成测试”-对应集成发布测试

-分配测试人员：

进入“待测试的需求”列表，检查测试者是否分配正确。

如果不正确，可以通过模块排序等方式批量一次分配一个测试人员多个需求：

1）选择批量改变：

“所有xx问题”

如下图，选择对应的多个需求单：

2）如下图，选择编辑问题，点击“下一步”

3）如下图：

选择对应的测试者，点击下一步，在下一个界面再点击“确认”操作；

5.2测试BUG、子任务-测试BUG分配管理

略，通过首页“待测试BUG”进入待测试的BUG列表，其他步骤与需求测试分配管理一致，参考上一小节；

5.3测试状态监控管理

如下图，检查所有“待测试的需求”和“待测试的BUG”，并与测试人员交流长期没有被进行流程操作而一直出现在该列表中的BUG或者需求。

敦促测试人员在测试通过后点击“验收通过”或者“测试通过”流程；

6测试人员工作指引

6.1检查个人任务

通过首页以下链接进入个人待测试的所有问题：

6.2完成需求测试

打开对应的需求单：

✧发现BUG时，如上图点击创建子任务，选择问题类型为“子任务-测试BUG”，点击下一步：

✧需求测试验收通过后，在可选工作流程区域点击验收通过，或者退回返工；

7使用Jenkins进行项目代码集成和健康检查管理

使用Jenkins在本项目的目标是：

1）保证提交的代码在Jenkins上是能够通过编译和自动化测试的；

2）提供代码检查报告，辅助发现代码的测试覆盖度、代码级错误、代码格式问题；

3）提供每次自动编译的最新代码库变化，并与JIRA的需求\BUG进行链接集成

7.1项目自动化编译、代码检查和单元测试

7.2监控代码库的更新状态

7.3项目代码问题检查

7.3.1代码编译不通过

7.3.2单元测试不通过

7.3.3单元测试覆盖度检查

7.3.4代码质量检查[findbugs]

7.3.5代码格式检查[checkstyle]