您好、欢迎来到现金彩票网!
当前位置:红彩会 > 分派优先级 >

Rational ClearQuest 简介及变更管理的项目实践

发布时间:2019-05-27 12:59 来源:未知 编辑:admin

  developerWorks 中国 正在向 IBM Developer 过渡。 我们将为您呈现一个全新的界面和更新的主题领域,并一如既往地提供您希望获得的精彩内容。

  下载更多的IBM 软件试用版,并加入IBM 软件下载与技术交流群组,参与在线. 企业变更管理(ECM)系统介绍

  企业变更管理实践跟踪系统是设计用来提供一个统一的产品变更管理资源系统。基本上我们把变更分为缺陷和需求变更两种类型。文中的变更如无特定说明代表两种类型。系统确保所有开发小组遵守一个通用的工作流程来进行缺陷和需求变更管理。它提供了一套通用的术语、协定和流程。

  在此我们介绍的 ECM 系统的基本功能和产品体现的对于变更管理的理念。文中没有对系统所具有的所有功能进行描述,也没有对系统的部署进行描述,主要描述了系统的版本信息、变更的定义、系统用户的角色和规则、变更状态和处理流程。

  系统提供用户操作记录功能,记录所有用户操作信息,包括时间、操作人、变更状态以及内容的变化。此功能可以方便变更的参与人了解变更状态变化的历史信息。同时系统提供后台日志功能,支持 LDAP 用户认证集成方式。

  在多点部署的情况下,不同地域的开发人员可以使用相同的数据集,一个数据集可以是一个规则集和与其关联的用户。系统支持根据组织结构和用途的不同支持多数据集部署。

  在满足变更的协作管理的基础上,如何能够让不同的用户查询的需要关心的变更数据显得尤为重要。系统提供强大查询功能来满足不同人员对变更的管理。系统提供以任意属性查询我们关心的变更。例如,以产品或版本为分类查询变更来获得特定时间段内未解决变更的数量、新提交的变更的数量、解决的变更的数量;了解产品缺陷或变更的状态和开发计划之间的匹配关系。

  系统支持公共查询来共享常用查询给其他用户的功能。用户可以自定义查询并保存在系统中,方便以后使用。系统支持根据变更标识(变更的一个特定属性,唯一标识一个变更)和文本快速查找一个变更。

  单独的产品可以由于关联关系组织进一个产品包中。每个产品可以含有多个功能,每个产品也可以对应多个版本。同一产品的多个版本之间可以有功能的不同。每个版本和特定的发布日期关联,此日期是由产品经理确定。技术支持组可以基于此信息,与用户交流关于特定功能或者特定缺陷修复的交付日期。

  每个操作对应的状态为,提交的、分配的、已解决的、已验证的、被拒绝的、推迟处理的和重复与其他变更的等状态。

  质量保证人员主要进行变更的提交、验证和拒绝等操作。变更的创建一般由质量保证人员进行但不限于质保人员。系统把变更创建权限赋予了系统中的所有人员。

  每当系统中的用户对变更执行任何操作,系统会通过邮件通知变更相关人。相关人可以是上述用户角色中的任意一种,他们是和此项变更相关的质量保证人员、开发人员和项目经理。通过邮件通知或者主动查询我们可以进行不同用户见的的协作。

  通常开发版本仅为开发团队可见,一个版本对应很多的开发版本。例如产品 A 1.1.0 版本的开发版本可以从 1.1.0.1 开始标记,一直到产品发布的版本,例如 1.1.0.100。

  目标版本(Target Version),即变更需要解决的目标版本,通常需要为目标版本设定发布时间,系统通过比较当前时间和目标版本发布时间,来避免变更被分配到已经发布的版本上。如果当前时间晚于目标版本发布时间,则此变更不能被分配到这个目标版本上。

  如图 3 所示,用户在创建变更的时候首先提交“发现变更版本”以及“发现变更的开发版本”的信息。项目经理根据严重程度评定变更级别,评定变更优先级。并确定“目标版本”。对于复杂的,不确定风险的变更,可以通过经理会议讨论确定“目标版本”。当开发人员在解决问题后需要更新“变更解决版本”和“变更解决的开发版本”。最后质量保证人员在相应的版本上验证变更,若验证成功结束变更,若验证失败,则需要拒绝此修改或解决方案,需要对变更进行重新分配,继续变更的管理。

  项目经理在分配变更时,需要在变更系统中确定严重级别。但是仅依靠严重级别不足以决定需要在哪个目标版本上解决变更。通常还需要结合解决成本,引发新问题的风险来综合评定变更的优先级。优先级不一定会记录在变更系统中。但是无论有没有在系统中记录优先级的信息,项目经理都需要做到心中有数,为合理分配变更提供重要依据。

  如图 4 所示,是一个如何判定优先级的原则的示例。纵轴表示变更的严重程度,高(严重级别 1,2)低(严重级别 3,4)。横轴表示解决成本大小,引发新问题的风险高低。

  对于图中优先级 1 的变更,由于解决变更需要的资源少,而且引发新问题的风险较低。所以可以立即解决。对于优先级 2 的变更,虽然严重级别高,用户影响也较大。原则上需要尽快解决。但是当产品处于发布前期,为了避免引发严重的新问题,从而影响产品正常发布时间,这些变更是可以考虑被推迟到下个发布中去解决。

  基于不同的产品开发策略,一种被选的方式是早前发布的版本中发现的变更,在后续的所有计划版本中解决。另一种方式是基于对变更的风险、严重级别这个进行判断。下面的案例分析作具体的说明。

  通过以上的文章,我们初步了解了产品缺陷管理的工具,流程以及一些理论知识。在这一章里,我们将结合自己的一些工作经验,着重分享一些产品缺陷管理中的一些常用的实践。ECM 系统仅仅是一个变更管理的工具。只有将它系统,有效并充分的利用到现实的工作中,它才能够成为增强团队凝聚力,降低管理成本以及提升产品质量的法宝。

  大型软件项目的开发,通常是由不同的项目组所构成。而各个项目组之间通常会有相互交互的关系。特别是那些存在依赖关系的项目组。如果各个项目组之间使用不同的缺陷管理标准,那将会在实际的工作过程中引入更多的培训成本,更多的交流成本以及更多的管理成本。所以,为了解决这个问题,我们需要一个简单的并且标准的缺陷严重程度定义。在标准的缺陷严重程度定义引入之前,我们通常会遇到这样的问题。在同一个团队中内部,我们的缺陷严重程度有十级不同的定义,一级为最高,十级为最低。在现实的工作过程中,我们发现由于级数太多,大部分的经理很难将相近级数所代表的意义分清,导致个人对伊缺陷严重性的级数认定个不相同。这种不同将会在缺陷修复的资源调配上产生不小的影响,于是会出现我们花费很多资源在影响较小的缺陷上,却没有能够修复更严重的问题。另外,将十级不同定义的缺陷标准归纳整理本身就不是一项非常高效的活动。在另外一个不同的团队中,如果遵循另外一套缺陷严重程度标准,那么当这两个团队共同开发某项功能的时候,便会出现由于标准的不同而产生的误解,大大降低工作效率并增加管理以及交流成本。于是简单并且标准的缺陷严重程度定义便显得给为重要了。我们的实践是将多级的标准的缺陷严重程度定义简化为最少的四个级别以及两个附加属性:

  客户属性:缺陷还是隶属于以上的级别,但是由于它是客户发现的问题,于是会对客户的工作产生影响,在下一个版本发布的时候,应该及时修复。

  阻碍属性:缺陷还是隶属于以上的级别,但是由于它的阻碍属性,会影响到某些功能的使用或者会阻碍的测试的进行,需要立即处理

  通过一段时间的实践,我们发现在团队内部,新的缺陷严重程度定义的标准,统一了经理们对于缺陷的认知,并且大大的简化了他们定级以及分派的活动。在团队和团队的合作中,新的缺陷严重程度定义的标准使合作开发的缺陷管理更为清晰,易于传递以及复制,并大幅降低了交流的成本。

  对于一个大型产品来说,明确产品发布时必须修复缺陷的定义并不容易。每一个人都有自己的评判标准。于是如何让大家能够认可同一种标准并有效的进行沟通是缺陷管理的一种挑战。这里我们分享以下我们针对这种挑战的一些做法。首先要设定缺陷修复优先级以及修复目标。由于任何产品开发的目标都是服务于客户。于是缺陷管理中客户缺陷的属性便成为了另一个面向客户的缺陷严重级的指标。不管发布的产品中还有多少缺陷需要修复,所有客户发现的缺陷永远是属于高优先级的。当我们明确这个优先级以后,设定修复目标就变得简单了。其次要定义客户缺陷最后接受的时限。由于客户问题的上报是不用时间控制的偶然事件。于是在每一个发布的周期里,我们需要另外定义一个客户缺陷最后接受的时限,在这个时限前报告的问题我们将要求在在这次发布的周期中修复,对于那些上报时间超出了规定时限的缺陷,我们将定义在下一个发布周期中修复。对于特别严重的客户缺陷,我们会以单独缺陷修复包的形式发布,而不会囊括在这次的发布中。这是因为如果没有客户缺陷最后接受的时限,发布的时间会被客户问题所打乱从而无法在规定的时间里发布产品。基于以上的想法,以下是我们的做法:

  在主要版本发布的计划中,规定在缺陷最后接受的时限前,所有客户提交的优先级为一级以及二级的缺陷必须修复。对于非客户报告的缺陷,所有一级缺陷必须修复。二级以及三级缺陷用于预先设定的质量计划来控制。

  在小版本发布的时候,规定在缺陷最后接受的时限前,所有客户提交的优先级为一级以及二级的缺陷必须修复,另外,所有非客户报告一级缺陷必须修复。为了更好的控制工作量,在小版本上报告的非客户提交的二级以及三级缺陷将会顺延到下一个主要版本发布前进行修复。

  图为如何决定目标版本的流程,由于升级版本由于开发周期相对较短,通常只针对严重性高地变更解决。主版本上发现的变更,通常不会在升级版本中解决,如果用户影响大,严重级别高地变更,需要通过经理会议通过后,方可在升级版本中解决。

  面向对象甚至是面向服务的软件开发理念其中一项优点是能够更好的重复利用已经开发的软件功能而不是对同一功能在不同环境中的应用进行重复而且低效的开发。大型软件的开发更是如此。于是,在大型软件中,我们会将不同团队开发的功能模块整合到软件里来实现类似的功能,这种低成本的集成似乎很有效,但它也会引入以下相互依赖的问题。这里我们着重描述对于缺陷依赖关系的处理以及对应在 ECM 里的一些实践。首先,这些实践是基于我们对以上所述的缺陷严重程度的统一定义以及产品发布必须修复缺陷定义的操作。如果缺乏以上的定义,这些操作将无法落到实处。以下是我们的做法:

  确定产品的依赖关系。我们会通过现有的依赖管理工具 Clearing House 以及 ECM 中定义出所有其他产品和主产品的依赖关系,不仅仅是依赖的信息,包括各个依赖产品的负责人,发布信息以及支持信息都会在工具中体现。

  明确依赖关系负责人以及其职责。我们需要定义出每个依赖产品接口的责任人,他将是 ECM 系统中依赖产品相关缺陷的负责人。他负责定义缺陷的归属以及对于依赖产品的交流。也就是说当他查明这是一个依赖产品的缺陷,他来负责在 ECM 系统中将缺陷克隆到依赖产品相应的项目中并跟踪依赖产品的修复情况。

  设定缺陷修复时间要求。由于主产品和依赖产品各自有自己的发布周期,所以如果没有一个明确的缺陷修复时间要求,很有可能引来产品的缺陷的修复会由于依赖产品发布周期的不同从而被拖延。于是最终给主产品带来风险。为了应对这种风险,当我们在复制缺陷到依赖产品中时应明确给出主产品定义的缺陷修复时间要求。如果这种要求和依赖产品发布周期冲突,这种问题必须被及时地反馈到产品的管理者做出决断。通常情况下如果冲突无法解决,依赖产品将被要求提供单独缺陷修复包。

  相信大家都有这样的认知,客户提交的缺陷是高优先级的缺陷,需要我们及时的处理。但是这些缺陷又是很难预知的。然而,对于任何一个大型产品的开发,产品发布本身是由一系列的计划组成的。从而,把随时可以发生的客户提交的缺陷很好的集成到有计划的产品开发中去便是一个不小的挑战。对于 ECM 系统来说,我们可以利用它来辅助我们很好地进行客户提交的缺陷和产品开发的集成,但是我们最需要的却是一个管理的方法论而并不是软件工具本身。这里是我们对于客户问题的处理流程的一些实践。

  当客户提交的缺陷袭来时,最基本的问题是:它的影响力有多大?我们什么时候需要修复它?在产品的哪一个发布时发布?是否需要发布给用户修复包?而当你能够回答这些为题时便同时定义出了修复的范围。当让,对于每一个缺陷的个体,我们可能会根据其特殊情况来用不同的方式处理,但是,总体的原则是:对于客户提交的缺陷,在下一个最近的产品发布时需要包含对它的修复。对于要求修复包的客户提供发布包。

  基于以上的原则,当客户提交的缺陷报到 ECM 系统里时,缺陷的分配人便需要定义出它的修复时间,基本上我们使用下一个最近的产品发布的日期来定义它,当然,我们也需要考虑到下一个最近产品是否来得及包括这个修复。这里我们便会利用客户缺陷最后接受的时限来确定,如果超过了这个时限,我们则必须将他计划到下下一个软件发布的周期中。

  我们常常遇到这样的情况。大型软件产品的一个主要版本发布不仅仅是一次。通常我们会在两个主要版本发布的期间进行小版本以及合并修复包的发布。为了更好的控制小版本以及修复包的范围以及针对性,开发团队会根据不同的需求建立不同的源代码分支,因此如何将客户提交的缺陷和不同代码分支联系起来也是一个通常遇见的问题。不过基于以上定义的修复原则,我们通常要求工程师在修复缺陷时,将修复的代码合并到以后发布版本所有的分支中。这样就会避免同一问题在不同的分支中出现。关于 ECM 系统在这里的使用。我们要求工程师在 ECM 的缺陷记录中除了描述缺陷的修复的方法,更重要的是在哪些分支中进行了合并。它将能够帮助质量保证人员在不同的分支中对它进行验证。

  为了保证相同的缺陷不会在不同的软件发布版本中出现。对于质量保证人员,进行客户提交的缺陷修复验证也是一项具有挑战的活动。同样,基于定义修复原则,质量保证人员需要在缺陷发现版本及以后所有发布的新版本中进行验证。从而,在 ECM 系统中,当质量保证人员发现客户提交的缺陷已经被修复后,需要仔细审核开发人员的纪录,审视这个缺陷是否已经合并在所有发布的新版本中。如果没有发现相关纪录,这个缺陷的修复将被拒绝并发回到开发工程师那里重新修复或更新。如果有相关纪录,质量保证人员需要在不同分支最新的开发版本上进行验证并记录自己验证的版本信息。在所有验证完全前保持缺陷的修复状态,只有当所有验证完全后才去将状态改为验证状态。

  在客户提交的缺陷处理流程中,ECM 系统可以起到非常好的辅助作用。但是,明确的缺陷修复原则定义以及修复计划的确认才是这个流程的关键。另外,对于开发以及质量保证人员的培训令其明确原则从而提升意识,也是这个流程中极其重要的一环。

http://m3-ctech.com/fenpaiyouxianji/340.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有