JIRA带来的管理思路.docx

JIRA带来的管理思路.docx

《JIRA带来的管理思路.docx》由会员分享，可在线阅读，更多相关《JIRA带来的管理思路.docx（9页珍藏版）》请在冰豆网上搜索。

JIRA带来的管理思路

JIRA带来的管理思路

刚刚开始用Jira的时候，只是觉得这是一个方便的bug管理系统，可以将在测试过程中所发现的bug录入、分配给开发人员。

之后开始在公司内使用，之前也曾经想尝试使用bugzilla。

在D的建议之下，又因我用过Jira，因此一拍即合，开始使用了。

因起初只是使用者，因而并未有站在一个管理者的角度上来看JIRA在项目管理中的作用和意义。

因此今日再看时，已发现由于出发角度的错误而出现的很多偏差，导致的此时的问题。

没办法有效的管理bug，没办法有效的让所有人及时添加bug，没办法让所有人方便看到当前有哪些bug。

因为太乱了，模块划分乱、版本划分乱、处理者乱，处理流程乱。

当这些问题出现后，才发现之前的错误。

这些为什么没有在开始使用时就理解和计划实施呢！

现在来看JIRA，这是一个项目管理的很好辅助工具，将所有项目开发、运作过程中的所有task、bug、创意、改善意见都可以融汇进入这个系统。

可以在第一时间将这些问题指派而责任人进行处理。

而想用JIRA来做好BUG管理和项目管理，有这几个重点要做好！

1.定义模块

   模块反应了问题出现因素的范围。

所发现的问题、所需要进行的任务、改善意见的指向、创意所应用的范围。

2.定义里程碑

   问题、任务、意见、创意都需要分配在某一时段进行处理，时段可以是时间为单位的，周、日、时、分，也可以是里程碑，alpha/beta/closebeta/openbeta。

如果所有的事情都可以以这两种单位计量的非常清晰，那么首先可以称赞的一点是，你的负责心已经体现出来了，你知道在什么时间该做什么事，同时，你让你的战友们知道，他们应该在什么时候做什么事！

3.定义全局处理流程

   第1点和第2点，是你在为这个项目管理做的基础准备，有了第1点和第2点，那说明你在其中的工作，但这并不表明这个系统就可以运作起来。

要运作起来，就必须你和你的战友们都可以在处理JIRA上的所有事务时的处理流程。

   建立：

建立一个issue。

什么样的东西应该建立在JIRA中，我得到的经验是，所有的工作任务、所有的bug（开发过程中的，A与B之前的，A与C之前的，B与C之前，所有、所有），不单是测试小组所发现的一些黑盒测试的bug，开发过程中的也不遗漏。

这样，你可以看到这个项目在动的，每天所有人都在发现问题，解决问题。

   分配：

问题要给能解决问题的人，问题要给理解这个问题的人。

程序上问题你给了一个商备人员，那你不对了；程序的问题你给了程序，可以程序不明白你说的是什么，那也是你不对了。

要降低沟通过程中的风险，建立问题者，想清楚，这个问题要由谁来处理，要告诉他什么信息。

你在没有告诉清楚这些信息的时候，你对这个问题还是最大责任者。

   开始：

开始是指接收到这个issue后的处理手段之一，因为还有拒绝这种可能。

开始处理这个问题，在向所有人声明一件事情，这个问题我开始着手处理了，我会按着计划和需求来完成这个事务。

那么，开始做这件事的人，你要很坦诚的向自己说，我知道这个事务是什么，我知道要怎么去处理，我知道要在这个时间内怎么处理。

你开始接受这项事务，是你对于分配给你这个事务的人的一个回应。

这时事务的责任在你的身上。

用你的职业精神来处理这个事务吧。

   解决：

整个的处理过程统称为解决。

虽然有可能出现解决不了、或者在解决的过程中需要其它人来帮忙，也可能需要很多的讨论和会议，这都是解决的过程，在这个过程中，把你做过的事情，对于这个Issue相关的资料，信息版本，记录下来。

让别人知道，你是用什么方法来解决的，你这种解决方法是不是很安全，还有没有其它更优化的方法。

   关闭：

解决完一个事务后，通常这种事务的责任转移到分配人的头上，分配人要处理的事情是，这个事务是否如需求、计划所完成，完成质量是否符合要求。

在通过验证后，这一个问题需要你的关闭。

在出现不符合的情况，你不能关闭这个issue，你要提供更多信息，更多资料，方便他再来解决。

   重开：

对于bug，出现重现的情况是常见的，这时不要让JIRA上有更多的垃圾信息，也方便开发人员找到问题原因，你需要重开这个bug，并附上相关的信息。

4.每日的统计与清理

   管理项目要盯，每日的盯是少不了的，看全局的issue数量、关闭情况、进行情况、所剩未解决的数量。

你可以有的放矢的去针对这些问题来看。

也可以看到，谁的问题比较多，谁的进度比较慢。

因为什么问题将影响进度，因为什么问题将影响产品品质。

   你也有责任要清理一些问题，这种情况出现在，你没有让所有战友都可以很好的使用这个系统。

清理的另一意义是理，有一些问题，你可能要在这一阶段放弃，那需要理到某一个其它时段，这个问题需要换由其它人再进行继续的处理等等。

5.阶段的统计与整理

   阶段，这么划分吧，每周3/2这样两个阶段，这是除了第4点所说的之外的最小阶段吧。

以它就是周、版本计划阶段、版本大的阶段划分这样的划分情况。

   通过阶段内的完成情况，你可以看到谁处理的问题太多了，谁少一些，谁的难度高一些、谁的能力不足、谁不负责任。

哪个部门做得不足，哪一模块需要更多人帮忙。

如果说日为单位是盯的话，那么阶段来统计与整理，就是盯之后的分析与解决方案。

6.最大力度的使用过滤器

   Jira提供了较多的查询条件可供个人创建过滤器和与团队分享过滤器。

同时还可以自定义自己的主页，相信自定义主页这个功能在google上你已经感受过了。

同样这些过滤器可以变为你的主页中的一部分，把你最需要关注的issue都呈现在你每日的第一位置。

JIRA，是一个工具，是改变你原始管理思维的一个突破。

如果你要用的话，请记住，Jira不是你一个人会用就行了，是一个团队、一个系统。

否则他运转不起来，就算转起来了，也有出现更大问题的时候。

现在我面对的就是出现这个大问题的时候。

希望通过这样的一处整理思路的过程，让公司的JIRA系统可以快速恢复起他应有的作用。

Bug指标在JIRA中的实现

JudyShen

JIRA是澳大利亚Atlassian公司开发的一款不错的商业问题跟踪工具，包括bug、需求变更、评审记录等均可以在这个软件中进行管理。

我们在统计bug数据时，经常需要对bug参照一些指标进行统计分析。

本文介绍一些常用bug指标在JIRA中的实现。

1        Bug分布

l        Bug严重级别

在项目测试中，我们不能仅仅用“bug总数”作为评价项目出错程度的唯一指标。

因为不同bug严重程度是不相同的，较为严重的bug带来的影响远远大于一般bug，所以，我们引入“bug严重级别”指标，用来标定bug的严重程度。

现在公司是分6个级别（Blocker、Critical、Major、Minor、Trivial、Enhancement）。

这个指标的用途是用于对bug按严重程度进行分类汇总。

管理者可以很清楚的得知整个项目中，不同严重级别的bug分别占有bug总数的百分比。

计算公式为：

严重级别＝各个级别的bug数/bug总数。

在JIRA中，bug严重性分布图如下图所示：

标识bug的状态，从上到下分别为：

Resolved、Closed、Reopened。

标识bug的严重性，从上到下，分别为Bloker、Critical、Major、Minor、Trivial。

l        Bug类别

Bug类别用来描述bug的内容类别，比如功能、性能、界面等。

这个指标可以帮助我们分析，在所有的bug中，哪些类型的bug比较多，应该值得关注，并且在后续的开发工作中，加强对类似问题的审核；在后续的测试工作中，加强对类似bug的测试力度，最大程度的在源头减少类似错误的发生。

计算公式为：

bug类别＝各种bug类型的bug数/bug总数。

在JIRA中，bug类别图和问题类型图类似，这里以问题类型图为例，如下所示：

2        Bug修复率（bug修改成功率）

Bug修复率，也可以称为“bug修改成功率”，它能够反映bug责任人修复bug的效果，可以作为对开发人员的考核指标之一，同时可以督促开发人员认真执行单元测试。

计算公式为：

bug修复率＝（已解决的bug数）/bug总数。

在JIRA中，可以查看到每个解决版本的bug处理情况，如下图所示：

3        Bug修复工作量

根据以前项目的bug修复工作量的统计分析，可以得到不同严重性级别的bug及其对应的修改工作量。

例如，经过统计分析得知，严重性为“Major”的bug，通常需要6人时的修复工作量。

通过这个数据，可以粗略的估计，处理项目中未处理的bug需要的工作量（仅包括处理工作量，不含测试人员验证的工作量）。

得到这个数据，主要是为了便于管理者根据项目的实际情况制定或调整项目计划。

在JIRA中，可以使用以下三条曲线来描述：

时间跟踪报告、开发者工作量报告、版本工作量报告。

但是要实现登记修复工作量这项功能，需要开发人员执行两个动作：

1.上执行bug的ResolveIssue流程2.进入另一个页面执行工作日志登记。

3.1   时间跟踪报告

这个报告，显示了项目的时间跟踪详细情况。

其中，

显示实际花费时间与初始估算时间的比例

显示这个版本的问题与进度计划相比是超前、推迟，或者按计划进行。

显示每个bug详细的工作量记录。

3.2   开发者工作量报告

这个报告显示了开发者当前的工作量的详细情况——显示了每个项目的未解决的已分配问题的数量和剩余的工作量。

3.3   版本工作量报告

这个报告显示了指定的版本的当前工作量详细情况——显示了每个用户的未解决问题的数量和剩余工作量。

4        Bug预计修复完成时间

在“bug修复工作量”中，我们考虑的是bug修改实际所需的工作量，但是没有考虑到项目开发所处阶段、人员分配等实际情况。

在这个指标中，项目管理者希望能知道bug计划完成修复所需的时间。

为了实现这个目标，我们可以根据bug的优先级，估计bug计划修复完成的时间。

方法是：

测试人员/bug分配人根据项目的实际情况，设置bug的优先级。

每个优先级对应一个解决期限。

例如，优先级P1的bug，必须在4小时内处理完毕，P4的bug可以在5工作日内处理完毕。

通过这个约定，可以根据每个bug的分配时间（不是提交时间），计算得出项目剩下的bug的预期解决时间。

在JIRA登记bug时，可以指定预期解决时间，但是没有功能可以快速的找到某个版本bug预计能改完的日期。

但是使用以下变通的办法后，可以查看到Bug预计修复完成时间。

步骤：

1．在过滤器中，设置你想查看的某个版本或者某个严重性或开发人员的值

2．执行查询

3．在查询结果中，点击“逾期”列，对“逾期”进行排序。

此时，列表中的第一行就是你所关系bug的预计修复完成时间。

另外，你也可以通过过滤器，查询逾期指定时间的bug。

5        小结

所有这些指标的综合运用，能够比较全面的从量化的角度来描述一个项目中开发和测试工作的实际情况。

PM、开发组长和测试组长可以选择对自己项目有用的统计指标，跟踪这些数据，以便及时跟踪和调整项目开发和测试，更好的管理项目。

使用 JIRA 搭建企业问题跟踪系统 （Judy Shen ）

发表时间:

2006-05-1716:

37

JIRA 是澳大利亚 Atlassian 公司开发的一款不错的商业问题跟踪工具，可以对各种类型的问题进行跟踪管理，包括缺陷、需求变更、评审记录等。

笔者在进行缺陷跟踪工具的选型时，曾经试用了JIRA 一段时间，个人感觉很不错。

笔者结合试用过程中碰到的问题和个人体会，将试用记录进行了整理。

本文主要介绍 JIRA 的个性化定制，介绍如何根据公司实际需求对 JIRA 进行定制，适用于管理员。

至于说 JIRA 的基本使用方法，和普通的缺陷跟踪工具类似，本文不做重点介绍。

您可在 JIRA 官方网站  上了解到 JIRA 更为详细的信息。

一、背景 

在试用 JIRA 前，公司使用 Bugzilla 作为缺陷跟踪工具。

在使用初期，Bugzilla 确实发挥了一定的作用，但随着公司强化项目管理的需要， Bugzilla 开始不够用了。

项目组使用 Bugzilla 时，存在几个问题：

1. 项目组需要对不同类型的问题进行记录，如任务分配、评审所发现的问题、需求变更记录，缺陷等。

虽然可以在 Bugzilla中也可以将这些各种类型的问题当作缺陷记录，但是这会混淆缺陷跟踪流程，因为这些不同类型的问题的处理流程是不一样的，但是 Bugzilla 中无法在系统中定制多个问题跟踪流程。

2. 项目管理者无法记录缺陷的预期修复完成时间; 

3. 项目管理者不能批量分配、编辑缺陷; 

4. 无法记录开发人员处理缺陷所花的工作量，并且所花工作量缺少对比; 

5. 开发人员无法快速、直观的清楚分配给自己的缺陷，对于正在进行处理的缺陷也没有很直观的表现; 

6. 测试人员不知道缺陷修复预期对应的版本，导致缺陷回归时范围不清晰; 

7. 不方便升级，升级成本大; 

8. 其它细节问题，如界面不友好，用户无法上传附件等。

二、介绍 

跟踪并管理在项目过程中呈现出来的问题（如缺陷、新特性、需求变更、 QA 审计问题等）是项目管理很重要的任务，但是很少有团队能做的很好。

 JIRA 虽然是一个问题跟踪系统，但是只要稍加改造，便可以成为一个项目管理软件。

是一个问题跟踪和项目管理应用系统，目的是为了让跟踪和管理在项目过程中呈现出来的问题变得简单。

JIRA 具有以下特性：

1. 管理缺陷，新特性、任务、改进或者其他任何问题; 

2. 干净和强大的用户界面方便商业或技术用户理解; 

3. 工作流定制; 

4. 全文搜索和强大的过滤器（可定制的，可保存的，可共享的，可预定的过滤器）; 

5. 可定制的工作台和实时统计; 

6. 企业级的权限和安全控制; 

7. 方便的扩展及与其他系统集成（包括 email 、 RSS 、 Excel 、 XML 和源码控制工具）; 

8. 非常高的通知选项配置; 

9. 可以在几乎所有硬件、操作系统和数据库平台下运行; 

JIRA 可以根据你的需要提供所需要的信息。

下面以缺陷为例，介绍各个角色成员在 Jira 中可以获得的信息和可以做的事情。

... ...

系统的权限分配如下：

1.项目经理：

 Assigner ＋ Developers ＋ jira-users 

2.模块负责人（缺陷分配人员）：

 Assigner ＋ Developers ＋ jira-users 

3.开发人员：

 Developers ＋ jira-users 

4.测试人员：

 Testers ＋ jira-users 

5.项目组其他人员（如 SCM ）：

 jira-users 

6.项目外其他人员：

 Anyone 

7．设置项目的 Default Assignee 

系统默认是分配给项目负责人，即项目经理。

可以根据需要选择默认为模块负责人。

设置步骤如下：

1） 在 Project 页面下的“ Components ”部分，在“ select assignees for components ”处，点击“ Select ”链接，进入“ Select Component Assignee ”界面; 

2） 选择模块的默认分配人。

8．创建版本 

9．选择邮件通知方案 

设置步骤如下：

1） 选择“管理”－“ Projects ”－“ Projects ”，进入“ Project ：

项目名”界面; 

2） 在“ Notification Scheme ”部分，点击“ select scheme ”链接，在进入的页面中选择需要的邮件通知方案。

10．设置系统邮件发件人 

默认是使用 mail server 中设置的邮件地址。

可以根据项目需要为每个项目设置不同的邮件发件人。

设置步骤如下：

1） 选择“管理”－“ Projects ”－“ Projects ”，进入“ Project ：

项目名”界面; 

2） 在“ Mail Configuration ”部分，点击“ edit configuration ”链接，在进入的页面中输入本项目的系统邮件发件人。

完成上述步骤后，就可以进行问题（如缺陷、需求变更等）登记了。

六、 制度要求 

1．某个项目的分配人员，在分配缺陷时，需要执行编辑缺陷操作，在编辑页面输入预期解决日期、原估算工作量，修改分配人。

也可以在分配缺陷时，修改缺陷的其他属性。

2. 只有第二次分配（不需要输入预期工作量时），才可以使用“分配”按钮进行快速分配。

3．如果需要将某个缺陷抄送给某人，则使用 watch 功能，增加一个 watch 人。

4．开发人员接受缺陷，在“可选工作流程”部分点击“接受本缺陷”链接; 

5．开发人员解决缺陷后，在“可选工作流程”部分点击“解决缺陷”链接; 

6．开发人员每次处理缺陷时，都需要在“操作”部分的“工作日志”栏，点击“完成记录工作”链接，填写“花费时间”、“工作描述”。

按照上述的步骤，可以使用 Jira 建立起公司的问题跟踪管理系统。

完整内容参见如下URL: