JIRA带来的管理思路

1、JIRA带来的管理思路刚刚开始用Jira的时候，只是觉得这是一个方便的bug管理系统，可以将在测试过程中所发现的bug录入、分配给开发人员。之后开始在公司内使用，之前也曾经想尝试使用bugzilla。在D的建议之下，又因我用过Jira，因此一拍即合，开始使用了。因起初只是使用者，因而并未有站在一个管理者的角度上来看JIRA在项目管理中的作用和意义。因此今日再看时，已发现由于出发角度的错误而出现的很多偏差，导致的此时的问题。没办法有效的管理bug，没办法有效的让所有人及时添加bug，没办法让所有人方便看到当前有哪些bug。因为太乱了，模块划分乱、版本划分乱、处理者乱，处理流程乱。当这些问题出现后，才发现之前的错误。这些为什么没有在开始使用时就理解和计划实施呢！现在来看JIRA，这是一个项目管理的很好辅助工具，将所有项目开发、运作过程中的所有task 、 bug、创意、改善意见都可以融汇进入这个系统。可以在第一时间将这些问题指派而责任人进行处理。而想用JIRA来做好BUG管理和项目管理，有这几个重点要做好！1.定义模块 模块反应了问题出现因素的范围。所发现的问题、所需要进行的任务、改善意见

2、的指向、创意所应用的范围。2.定义里程碑 问题、任务、意见、创意都需要分配在某一时段进行处理，时段可以是时间为单位的，周、日、时、分，也可以是里程碑，alpha/beta/close beta/open beta。如果所有的事情都可以以这两种单位计量的非常清晰，那么首先可以称赞的一点是，你的负责心已经体现出来了，你知道在什么时间该做什么事，同时，你让你的战友们知道，他们应该在什么时候做什么事！3.定义全局处理流程 第1点和第2点，是你在为这个项目管理做的基础准备，有了第1点和第2点，那说明你在其中的工作，但这并不表明这个系统就可以运作起来。要运作起来，就必须你和你的战友们都可以在处理JIRA上的所有事务时的处理流程。 建立：建立一个issue。什么样的东西应该建立在JIRA中，我得到的经验是，所有的工作任务、所有的bug（开发过程中的，A与B之前的，A与C之前 的，B与C之前，所有、所有），不单是测试小组所发现的一些黑盒测试的bug，开发过程中的也不遗漏。这样，你可以看到这个项目在动的，每天所有人都在发 现问题，解决问题。 分配：问题要给能解决问题的人，问题要给理解这个问题的人。程序上

3、问题你给了一个商备人员，那你不对了；程序的问题你给了程序，可以程序不明白你说的是什 么，那也是你不对了。要降低沟通过程中的风险，建立问题者，想清楚，这个问题要由谁来处理，要告诉他什么信息。你在没有告诉清楚这些信息的时候，你对这个 问题还是最大责任者。 开始：开始是指接收到这个issue后的处理手段之一，因为还有拒绝这种可能。开始处理这个问题，在向所有人声明一件事情，这个问题我开始着手处理了，我 会按着计划和需求来完成这个事务。那么，开始做这件事的人，你要很坦诚的向自己说，我知道这个事务是什么，我知道要怎么去处理，我知道要在这个时间内怎么 处理。你开始接受这项事务，是你对于分配给你这个事务的人的一个回应。这时事务的责任在你的身上。用你的职业精神来处理这个事务吧。 解决：整个的处理过程统称为解决。虽然有可能出现解决不了、或者在解决的过程中需要其它人来帮忙，也可能需要很多的讨论和会议，这都是解决的过程，在这个 过程中，把你做过的事情，对于这个Issue相关的资料，信息版本，记录下来。让别人知道，你是用什么方法来解决的，你这种解决方法是不是很安全，还有没 有其它更优化的方法。 关闭：解决完一个

4、事务后，通常这种事务的责任转移到分配人的头上，分配人要处理的事情是，这个事务是否如需求、计划所完成，完成质量是否符合要求。在通过 验证后，这一个问题需要你的关闭。在出现不符合的情况，你不能关闭这个issue，你要提供更多信息，更多资料，方便他再来解决。 重开：对于bug，出现重现的情况是常见的，这时不要让JIRA上有更多的垃圾信息，也方便开发人员找到问题原因，你需要重开这个bug，并附上相关的信息。4.每日的统计与清理 管理项目要盯，每日的盯是少不了的，看全局的issue数量、关闭情况、进行情况、所剩未解决的数量。你可以有的放矢的去针对这些问题来看。也可以看到，谁的问题比较多，谁的进度比较慢。因为什么问题将影响进度，因为什么问题将影响产品品质。 你也有责任要清理一些问题，这种情况出现在，你没有让所有战友都可以很好的使用这个系统。清理的另一意义是理，有一些问题，你可能要在这一阶段放弃，那需要理到某一个其它时段，这个问题需要换由其它人再进行继续的处理等等。5.阶段的统计与整理 阶段，这么划分吧，每周3/2这样两个阶段，这是除了第4点所说的之外的最小阶段吧。以它就是周、版本计划阶段、版本大的

5、阶段划分这样的划分情况。 通过阶段内的完成情况，你可以看到谁处理的问题太多了，谁少一些，谁的难度高一些、谁的能力不足、谁不负责任。哪个部门做得不足，哪一模块需要更多人帮忙。如果说日为单位是盯的话，那么阶段来统计与整理，就是盯之后的分析与解决方案。6.最大力度的使用过滤器 Jira提供了较多的查询条件可供个人创建过滤器和与团队分享过滤器。同时还可以自定义自己的主页，相信自定义主页这个功能在google上你已经感受过了。同样这些过滤器可以变为你的主页中的一部分，把你最需要关注的issue都呈现在你每日的第一位置。JIRA，是一个工具，是改变你原始管理思维的一个突破。如果你要用的话，请记住，Jira不是你一个人会用就行了，是一个团队、一个系统。否则他运转不起来，就算转起来了，也有出现更大问题的时候。现在我面对的就是出现这个大问题的时候。希望通过这样的一处整理思路的过程，让公司的JIRA系统可以快速恢复起他应有的作用。Bug指标在JIRA中的实现Judy ShenJIRA是澳大利亚Atlassian公司开发的一款不错的商业问题跟踪工具，包括bug、需求变更、评审记录等均可以在这个软件中进行管理

6、。我们在统计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的内容类别，比如功能、性能、界面等。这个指标可以帮助我

7、们分析，在所有的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需要的工作量（仅包括处理工作量，不含测试人员验证的工作量）。得到这个数据，主要是为了便于管理者根据项

8、目的实际情况制定或调整项目计划。在JIRA中，可以使用以下三条曲线来描述：时间跟踪报告、开发者工作量报告、版本工作量报告。但是要实现登记修复工作量这项功能，需要开发人员执行两个动作：1.上执行bug的Resolve Issue流程2.进入另一个页面执行工作日志登记。3.1 时间跟踪报告这个报告，显示了项目的时间跟踪详细情况。其中，显示实际花费时间与初始估算时间的比例显示这个版本的问题与进度计划相比是超前、推迟，或者按计划进行。显示每个bug详细的工作量记录。3.2 开发者工作量报告这个报告显示了开发者当前的工作量的详细情况显示了每个项目的未解决的已分配问题的数量和剩余的工作量。3.3 版本工作量报告这个报告显示了指定的版本的当前工作量详细情况显示了每个用户的未解决问题的数量和剩余工作量。4 Bug预计修复完成时间在“bug修复工作量”中，我们考虑的是bug修改实际所需的工作量，但是没有考虑到项目开发所处阶段、人员分配等实际情况。在这个指标中，项目管理者希望能知道bug计划完成修复所需的时间。为了实现这个目标，我们可以根据bug的优先级，估计bug计划修复完成的时间。方法是：测试人员/b

9、ug分配人根据项目的实际情况，设置bug的优先级。每个优先级对应一个解决期限。例如，优先级P1的bug，必须在4小时内处理完毕，P4的bug可以在5工作日内处理完毕。通过这个约定，可以根据每个bug的分配时间（不是提交时间），计算得出项目剩下的bug的预期解决时间。在JIRA登记bug时，可以指定预期解决时间，但是没有功能可以快速的找到某个版本bug预计能改完的日期。但是使用以下变通的办法后，可以查看到Bug预计修复完成时间。步骤：1 在过滤器中，设置你想查看的某个版本或者某个严重性或开发人员的值2 执行查询3 在查询结果中，点击“逾期”列，对“逾期”进行排序。此时，列表中的第一行就是你所关系bug的预计修复完成时间。另外，你也可以通过过滤器，查询逾期指定时间的bug。5 小结所有这些指标的综合运用，能够比较全面的从量化的角度来描述一个项目中开发和测试工作的实际情况。PM、开发组长和测试组长可以选择对自己项目有用的统计指标，跟踪这些数据，以便及时跟踪和调整项目开发和测试，更好的管理项目。使用JIRA搭建企业问题跟踪系统(JudyShen) 发表时间: 2006-05-17 16:37 JIRA是澳大利亚Atlassian公司开发的一款不错的商业问题跟踪工具，可以对各种类型的问题进行跟踪管理，包括缺陷、需求变更、评审记录等。笔者在进行缺陷跟踪工具的选型时，曾经试用了JIRA一段时间，个人感觉很不错。笔者结合试用过程中碰到的问题和个人体会，将试用记录进行了整理。本文

《JIRA带来的管理思路》由会员hs****ma分享，可在线阅读，更多相关《JIRA带来的管理思路》请在金锄头文库上搜索。