使用JIRA和Jenkins进行项目管理
(仅供参考)
1 使用JIRA进行项目跟踪管理
1.1 JIRA项目管理流程
1.1.1 概述
项目的软件开发流程主要围绕实现一个个业务功能需求和非功能需求的需求分析、设计、开发、测试、发布验收，而参与人员最多的开发和测试环节是流程最容易出问题的环节，为有效使用JIRA进行项目管理，我们设计了以需求为主导的JIRA表单和流程（如下图）。
对应于软件过程的管理流程，本项目JIRA对应设置了以下的IssueType（问题类型）和3大管理流程：
软件开发流程需求分析组需求分析JIRA管理单据JIRA管理流程需求分析组概要设计需求单、原型、ER图、详细设计需求单需求管理流程需求分析组详细设计代码开发需求分析组程序开发代码评审子任务-变更单 子任务-开发任务单子任务-设计问题单子任务-评审BUG单日构建冒烟测试子任务-测试BUG单对应一个需求的BUG对应系统或多个需求的BUG任务管理流程需求分析组测试测试管理流程用户用户验收测试测试问题单【说明】
? 【需求单】：在需求分析、概要设计、详细设计阶段，将产生对一个需
求的具体描述和实现设计描述交付到开发阶段，在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.4 BUG跟踪流程
2 JIRA工作指引手册 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问题”：