使用JIRA和Jenkins进行项目管理

1、使用JIRA和Jenkins进行项目管理（仅供参考）1 使用JIRA4行项目跟踪管理1.1 JIRA项目管理流程1.1.1概述项目的软件开发流程主要围绕实现一个个业务功能需求和非功能需求的需 求分析、设计、开发、测试、发布验收，而参与人员最多的开发和测试环节是流 程最容易出问题的环节，为有效使用 JIRA进行项目管理，我们设计了以需求为 主导的JIRA表单和流程（如下图）。对应于软件过程的管理流程，本项目 JIRA对应设置了以下的lssueType（问题类 型）和3大管理流程：软件开发流程需求分析组需求分析需求分析组概要设计需求分析组详细设计代码开发JIRA管理单据需求单子任务-变更单子任务-

2、开发任务单需求单、原型、ER图、详细设计彳 子任务-设计问题单子任务-评审BUG单JIRA管理流程需求管理 流程需求分析组4 代码评审任务管理 流程程序开发日构建冒烟测试用户子任务-测试BUG单r对应一个需求的 BUG对应系统或多个需求的 BUG测试问题单测试管理 流程用户验收测试【说明】【需求单】：在需求分析、概要设计、详细设计阶段，将产生对一个需 求的具体描述和实现设计描述交付到开发阶段，在 JIRA中，体现为一份 需求单，这些交付件全部作为需求单的附件，需求单的来源包括： 需求阶段的原始需求，以一个业务功能为一份需求，通常在一周左 右可以开发完成，例如“用户新增和查询功能”； 系统优化和

3、变更：如果一些变更无法对应一份原始需求，需要创建 一份新的需求单【子任务单】在开发阶段，一份需求往往需要三四天甚至长得多的时间 才能完成，开发完成后也存在不断的优化和改进， 因此，围绕需求在 JIRA 上设置了以下的管理跟踪对象子任务单 (SubIssueType)开发任务单：程序员拿到需求后， 组长应该协调开发人员将需求分解为开发任务， 在JIRA上创建任务单；设计问题单： 程序员拿到需求中的设计进行评估时，如果发现设计文档或者需求 有bug，应该记录在案以便协调设计小组完善，在 JIRA上创建设计 问题单； 变更单 但设计和需求人员需要对已经提交的需求和设计提交变更时，例如 增加一个字段、

4、变更原型样式、变更接口方法，均需要提交变更单； 评审 BUG 单主要是开发组长或者结对开发程序员在评审 BUG时，将评审的BUG 记录为评审 BUG；测试BUG单 主要针对前期开发阶段的冒烟测试，测试人员对已经实现的功能进 行测试，保证流程能够跑得通，如果发现 BUG则创建测试BUG单；【测试问题单】 主要针对无法对应到一份需求产生的 BUG流程设置说明根据参与者、小组分工，设置以下流程 需求跟踪流程 参与人员包括需求分析员、设计者、开发组长、程序员、测试组长、 测试员、用户参与，只与需求单关联，但目前其他用户参与的流程 主要由开发组长完成。任务跟踪流程 主要是开发组长和程序员两级人员参与，与

5、开发任务单、设计问题 单、变更单、评审BUG单，便于开发小组进行状态监控，部分单尽 管涉及到设计人员，但为降低流程协调工作量，均由开发人员在面 对面解决后对流程进行操作BUG跟踪流程主要是测试人员和开发组间的流程跟踪。详细的流程图如下：1.1.2 需求跟踪流程流程重点说明】 开发人员必须在接受到任务后点击“开始处理”，以便跟踪哪些任 务正在处理中；任务完成后点击“完成”；小组长在代码评审后，使用JIRA的批量流程操作功能，将完成开发 的进行发布，在JIRA上点击“发布测试”； 测试部分分为两个环节：冒烟测试和集成测试；冒烟测试对应流程中的单元验收测试，在开发人员本机上或者该小 组的服务器上每日

6、构建后进行测试； 测试通过后应立即进行JIRA“验 收通过”操作； 冒烟测试通过后，开发小组协调发布人员，进行各小组的代码集成， 开发小组长在集成完成后，对相应的需求批量进行JIRA “完成集成”操作。集成测试，在冒烟测试后完成，一般每周发布一个版本到测试服务 器给测试组进行集成测试；集成测试通过应立即执行JIRA “测试通过”该单据关闭；对于关闭的单，如再次发现问题可重新打开；1.1.3 任务跟踪流程 主要是开发组长和程序员两级人员参与，与开发任务单、设计问题单、变更单、评审BUG单进行关联，便于开发小组进行状态监控，部分单尽管涉及到设 计人员，但为降低流程协调工作量， 均由开发人员在面对面

7、解决后对流程进行操 作。【流程重点说明】主要的流程由程序员完成；开发小组长一般情况进行整系统和阶段性代码的review，然后批量进行“完成代码评审”和“批量关闭”操作。1.1.4 BUG跟踪流程2 JIRA工作指引手册3 开发组长工作指引3.1 发布管理目标：建立发布基线：每周1和3检查所有的需求、BUG,保证所有的任务、 BUG被关联到合适的发布测试版本； 监控发布基线：每天与小组成员交流，检查和 review 下一个发布版本中 包括的所有需求、BUG是否如实反映了实际的状态； 调整发布计划：在发布前一两天，检查发布基线的内容是否能够保证按 计划进行，如果不能则重新调整这些任务的发布版本；步

8、骤：3.1.1 版本基础库维护： 在浏览项目界面，在版本下可以看到所有规划的版本号，在开发阶段以Branches-vyyyymmdd命名版本号，yyyymmdd代表发布的日期，如果某个发布版本由于延迟而需要修改版本号，需要修改对应的版 本号，以便与实际相符合。维护项目的版本，请点击“管理项目” 在 versi ons中，点击 Man age 链接 在以下界面中，进行版本“新增”、“删除”或发布功能 ”Release”：3.1.2将问题单（Issue关联到版本：本功能确保所有的需求、BUG均被关联到合适的版本中，以便每一次发 布时发布内容是清晰和反映实际情况： 对未规划的问题单关联到版本： 点击

9、“未规划” 链接在以下未规划列表中，点击“批量改变：所有xx问题”：选择需要规划到一个版本的所有需求或者BUG等问题单，点击下一步：*注意：一次只能规划一个版本，所以，选择的这些问题单必须在一个版本发布选择编辑问题，并点击下一步 选择对应的版本号：仔细确认本次批量操作：3.1.3将已发布版本中重新打开/退回的问题关联到待发布版本中 在发布前，检查之前所有发布版本，如果发现有任何处理重新打开或者退回返工的需求或者BUG,将其关联到待发布的合适版本（允许一个问 题关联多个版本）；3.1.4检查问题单-版本关联的正确性：一般通过以下3类操作通过版本路线链接进入问题列表，反复检查每个版本的内容，使用

10、以上方式批量调整问题单版本号，直至所有问题被正确关联：刚帝! C9fi4EiJ18l1Eff通过检查最新，点击浏览项目页面的“最新新增” 链接T HI- CBDJIRFFSff 1? ir rigmwwwQ hb!如!:呷2 ；旳I Q话T既 ManchE曲朋1配aft Uh貢询OFT31Jtmi到粧Q &aichfiS qi HE弓1033财1 /W冉刚iSBPWBffT、叶阳aCTffTiUliMM壯土 ULMB 14 lift“最近更新”检查以下列是否设置正确：通过模块链接来保证，点击浏览项目页面的“模块名” 一般情况，发布都是以一个模块为整体发布，通过交叉检查模块也 可以保证发布的正确

11、性。通过“所有需求”、“所有 BUG”链接进入需求和BUG列表检查各 个版本是否正确设置。3.2任务分配管理目标：保证所有问题单被分配到正确的责任人保证每个人的任务不被遗漏更正错误的分配在JIRA系统中，任何问题单被创建时，责任人都被设置为任务创建人，开发组 长应该每天检查任务责任人是否分配正确，一般可以通过以下操作：3.2.1检查所有的问题单责任人是否分配正确：通过预设置的任何过滤器（例如，开发组长最常用的链接是通过版本号、“最 近新增”、“最近更新”进入问题列表），进入问题单列表，并按照人员或 者最后更新时间排序，逐个人员对比检查：322检查每个人的问题单是否被遗漏：点击每个人员姓名进入该

12、成员的所有需求和BUG检查这些问题是否都属于该成员3.2.3更正错误的分配进入问题单编辑界面，重点修正以下字段：3.3设计问题跟踪由于设计和开发属于两个不同哦小组，因此经常出现以下问题：设计错误，导致开发无法进行本模块依赖的数据、接口没有被提供，使得开发无法进行程序员不喜欢交流由于这些设计问题导致任务被延误并作为任务无限延长 的理由跟踪不及时将导致设计、开发小组、开发人员扯皮，任务计划被搁置无法保 证目标：所有的设计问题被跟踪开发组长/设计组长能通过JIRA协调设计问题及时得到解决3.3.1所有的设计问题被跟踪开发组长应在每日例会上了解所有成员任务的阻碍，并检查这些阻碍、以及开发成员和设计人员

13、通过邮件、口头交涉的问题被 JIRA正确记录。如下图，开发组长可以通过JIRA首页的“所有设计问题”、或者进入单条需求 单查看其包含所有的设计问题：“所有设计问题”对应的结果：单条需求单对应的设计问题（图示 1标志的为设计问题）：3.3.2开发组长协调设计问题及时得到解决通过以上查找到的设计问题，开发组长可以导出一份打印的Exce I与程序员、设计组长review，保证这些问题及时被解决，且流程被正确执行（对应状态列）：3.4任务进度管理目标：跟踪进度：跟踪所有的需求和任务、BUG的原估算时间、已花费时间、剩余 时间、逾期时间（即计划完成时间）在JIRA上得到如实反馈；调整剩余时间和逾期时间，

14、使得任务进度与现实一致；3.4.1跟踪进度开发组长应重点跟踪版本号链接来跟踪未发布测试或者未集成的需求单；如下，点击一个即将发布的版本：申 印画: C EtDMl 目开芨 friT I4r cnr-n,t*i-i*-u-帕吕* HI 耐.號科昭rr 祜ft仔咖口血弋BOriE jfldt雪勿日申jgp乃oiflltiA骨命朋劉上Q 鮭也、ii01 StbEhYMIHEI：t14科b Ehd甬邨0（刨1MIfflt*E虫HM3Pgtill QraiEhsznraniS进入以下界面【说明】逾期：密切注意逾期日期是否能够保证，如果无法保证，重新调整；状态：在发布前，能够发布的需求或者 BUG必须为“

15、测试验收”状态，在集 成测试前，所有的需求或者BUG必须为“待测试验收”状态。如果部分问题 由于各种原因被延迟，必须重新规划到下一个版本。原估算时间、花费时间：确保估算时间被正确设置（小组长主导、与程序员 沟通和达成共识）、花费时间反馈必须正确（取决于程序员是否正确填写了 工作日志）；影响的版本：保证其发布版本是争取的；342调整剩余时间和逾期时间，使得任务进度与现实一致；对任何一个需求或者BUG单，通过编辑需求或者BUG单，调整剩余时间和 逾期日期，如下图：4 程序员工作指引4.1检查个人任务程序员登录系统后，在首页可以看到以下部分的过滤器：分配给我的任务：责任人为当前用户的所有未关闭需求、

16、BUG等所有问题单; 开放的问题：所有分配给我的问题；4.2开始处理问题单（包括需求/BUG/子任务等）点击打开“已分配的”或“退回返工”问题单，如下图vjsr cgcTJiEKiiG 启？tu 迪a*r tt 4竝创 HIM- t 9ifl|SIt S 無肯& 22ft MiA： utttfrWwr-t 1* MT W-1-att-FriTM TrKlidll嘉蟲！ OH-nln-QD盃计J 口白金世储丹Ct畑N =i n g忖無:斗菱:弗as匕骨：WK*対色1的电韧:1*0*1ft在可选工作流程区域：点击 “开始处理”，问题单状态调整为“处理中”； （打开相应的问题单，在可选工作流程区域：

17、点击“完成”链接;5 测试组长工作指引目标：了解所有待测试需求、BUG的分配情况保证所有BUG被正确分配保证测试流程被正确执行5.1需求测试分配管理此步骤经常被程序员忽略）；下载相应的附件，阅读所有的需求、详细设计、原型、数据库E/R图等；如果设计有问题，点击“创建”子任务，选择“子任务-设计问题”，点击下馳子任舟闻進J；一知A如果该需求无法完成，与开发组长协商，达成共识后点击“退回重新分配” 并输入备注；如果需要记录部分与设计组或者其他人员交流的信息，点击“写备注”，记4.3填写工作记录，反馈实时进度在处理任务过程中，程序员需要通过记录工作日志，及时反馈任务使用的时 间拠一L：HIH 占:J

18、：!SfiJ；國f呛再十芒护欝开轴王二丰受吿人：王一圣鱗;oMljtL侗程 LlUffits盂点瓷Et畫MR。z*：q 常瀟m二:一 rBCTASMMGR Sg | f “fBMfladft T* m：H Jt iQj.： .无羯响族蔼；无TknelracL囲古居寸冃未知就和姐11廿:甘駅殛二t辞确件机-I-專.上喪予塁逊主抵问強二虫奋注：im 婕口 CMwen tn I5BU&4I(5F gE L A DB 1 -:生汕匚養IP*“1 mw Worked：卫 1勺吉说iJit雰UW璘 I ffH操作步骤：测试组长可以通过JIRA首页以下链接“待测试的需求”查看待测试的内容： 如下图，待测试的需求状态为“待测试验收”-对应冒烟测试，“待集成测试”- 对应集成发布测试分配测试人员：进入“待测试的需求”列表，检查测试者是否分配正确。如果不正确，可以通过模块排序等方式批量一次分配一个测试人员多个需 求：1）选择批量改变：“所有xx问题” 如下图，选择对应的多个需求单：2）如下图，选择编辑问题，点击“下一步”3）如下图：选择对应的测试者，点击下一步，在下一个界面