内容


Rational Edge

度量项目的健康性,第 3 部分

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Rational Edge

敬请期待该系列的后续内容。

此内容是该系列的一部分:Rational Edge

敬请期待该系列的后续内容。

measurements illustration这个系列的第1部分介绍了作为评估项目性能机制的度量法的概念,我描述了一些在先启阶段能够帮助您评估项目性能状况的详细度量法。这个系列的第2部分考虑了在精化和构建阶段,评估和指导工作中方法的使用。在这个系列的第3部分,也是最后一部分中,我谈到了产品化阶段的度量方法,这篇文章重点描述了将开发解决方案配置到“生产”环境中。同样的,产品化阶段的度量方法主要关注的是评估发布就绪情况和将这个项目包装成一个整体。

这篇文章结尾讨论的是管理嵌入在计划中的项目方法——从一个交叉项目的角度评估项目性能状况和价值。计划中的项目一定是相连的,一个项目中的问题会威胁到整体项目的成功。尽早定位问题的所在可以使它们尽早地被处理,也就潜在地挽救了这个计划。

产品化阶段

当大多数开发工作已经完成,产品化阶段的主要目标就是将解决方案配置到它指定的用户端中去。这包括一系列不同种类的工作:

  • 所有功能最终的确认。
  • 处理掉所有在部署工作前需要解决的问题。
  • “生产”环境中最终产品的安装和配置工作,包括可能需要的任何数据的迁移。对于许多系统,数据转换和最终将应用软件置入“生产”是非常复杂的问题,需要引起高度重视;在有些情况下,问题可能足够复杂以至于要用一个单独的项目来处理开发问题。在这些情况下,“开发”项目将它的解决方案部署到一个由这个开发项目管理的运行开发环境中去。在支持24X7消费者访问的工作间,通常制定有一个平行的“转换”环境。当这个应用软件准备好要部署到生产环境中,用户就将准备访问这个系统。
  • 用户的培训。只有非常少的系统是如此地直观和简单,以至于它们的用户不需要培训就能够使用。用户直接访问的系统,在用户首次访问这个新系统时必须提供一些方法来引导用户大体浏览一个指南。培训可能还包括与新系统相呼应的业务流程变化的介绍。
  • 支持人员的培训。就像机器一样,系统必须维护。在产品化阶段,这个项目可能需要将新系统于原有的其他系统进行整合。

非常值得注意的是,产品化阶段您完全不应该实现新的特性或者方案。如果您实现了,那您简直是愚弄了自己,让自己相信自己已经退出了构建阶段。在产品化阶段,唯一的焦点应该是准备好解决方案,然后对它进行部署。

当这个解决方案已经成功地部署,维护和支持也已经交付给了将在正在运行的基础上支持和维护这个解决方案的团队时,产品化阶段就算结束了。

产品化阶段中的度量方法

产品化阶段中的度量方法主要强调的是部署的系统适应性。这意味着强调的是测试覆盖率和缺陷级别,包括缺陷发现和缺陷关闭率之间的关系。为了决定部署的适应性您需要考虑到事情包括:

  • 部署的适应性。质量度量,包括性能、可量测性,以及可支持性度量,另外还有传统的缺陷度量。
  • 采用度量。 尤其是关于实际使用这个解决方案人的数量,着眼于回答“有足够多的人使用这个版本,并知道它是否能满足会议质量的要求?”这样的问题。
  • 用户满意度。 这实际上是通过用报告缺陷来度量的,通过这个缺陷报告来判断是否这个缺陷是一个“导致系统停用”缺陷(换句话说,它们认为这个缺陷十分严重,以至于这个解决方案在部署之前需要被处理掉)。

度量什么

为了收集信息来评估发布就绪情况,您需要测试。当然,所有类型的测试应该贯穿整个项目。现在的分歧在于,您的重点转移到测试这个系统的各种特性是否在发布的可接受极限内。产品化阶段的测试提供了原始数据,根据这些数据分析人员将告诉您,您是否已经为发布准备就绪。您至少需要测试这些条目:

  • 所有的“强制性”需求
  • 所有的需求都要与性能和可量测性极限相关
  • 所有的需求都要与可用性极限相关
  • 所有的需求都要与可支持性相关——一旦发布,将影响这个系统将为之服务并支持它的事情。

换句话说, 任何影响这个系统可发布性的事物都要被测试,主要的需求要详细说明度量方法的可接受范围。所有的“强制性”需求(为了最低限度地接受,系统“必须”满足的需求)应该已经定义好可接受范围,对“应该拥有”的需求(系统“应该”满足的需求,但是如果没有满足,系统仍然能够满足最低限度地接受标准)定义可接受范围也是很有益处的。如果有一些最小化的性能或者可量测性目标必须要满足,那么它们需要详细说明。

当测试场景时,俘获“通过/不通过”的方法实际上就足够了,但是对于与性能和可量测性相关的需求,需要实际指标。由于趋势重要性,您需要搜集一系列可观测性数据。比如:

  • 系统能够支持的并发的用户数,显示了当用户数增加时应答次数是怎样变化的。您将需要模拟整个用户社区事务处理的混合场景,从而提供一个精确的画面,这些事务处理将会被随机打乱来确保测试执行本身对结果并没有偏见。
  • 系统的可量测性,显示了平均事务处理和用户混合情况下应答次数的变化,但是数据的存储总量是变化的。许多系统不仅对事务处理的工作量很敏感,对数据的容量也很敏感。
  • 在实时系统中,数据传输的速度和容量以及事件的时间选择对度量来说同样是十分重要的。

分析趋势和评估测试结果

为需求建立度量目标是很好的习惯,最小限度要定义性能需求。在绝大多数情况下都应该建立一个度量目标,并有一系列的可接受性,对于需求的满足也只有最低限度的要求标准。对于提供的每一个被满足的需求都要有测试用例。当这些测试用例被执行后,需要对测试结果进行分析以确保所有实际结果都在可接受值范围之内。如果值超越了可接受范围或者未能达到最低接受标准就会导致缺陷,这些缺陷必须在部署解决方案之前处理完毕。

应该分析测试数据的趋势来评估这些值,通常在可接受范围之内的情况下,最终是否会偏离而超出范围。抽样数据的数量以及用户符合应该增加到度量极限的范围之外,看看在性能或者应答次数变得不可接受之前,系统的负载量极限是多少。

测试产生的结果不在可接受范围内就会导致缺陷被归档,从而使因此而发生的结果一直被追溯到结束。

影响可发布性的其它事项

度量系统的“可支持性”是很难量化但又是不可缺少的。通常通过一个您与支持人员共同讨论的定性评估来完成。支持人员包括维护系统的人和将保持系统运行的 IT 操作人员。

您需要评估的事情包括:

  • 移交活动的状态:“测试部署”(如果适应的话包括数据转换)已经执行了吗?
  • 用户拥有什么样的使用经验?这些用户有足够的信心来接受这个新系统吗?
  • 支持人员作好了承接支持这个系统的准备了吗?他们有支持这个解决方案的必要技术吗?为了确保备份和恢复(包括故障恢复)计划的有效性,对它们进行了更新和测试吗?
  • 如果这个解决方案需要在不止一个系统上部署,它是否足够简单来确保可验证的可重复性。

当我们考虑可发布性问题时,这些因素很容易被忽视。这个领域中的问题需要在这个项目的早期就确定技术问题,同时潜在的需求也应该捕获作为需求。这里的重点是确保先前确定的问题已经被满意地处理掉。

结束产品化阶段:回顾性评估

产品化阶段的结束也是这个项目的结束。这个结束的演变也已经完成,解决方案也已经部署到它的用户环境中去,这个方案已经移交给了生产支持或者下一个项目。一旦解决方案被部署好,这时就应该回想,考虑什么运行很好,什么应该运行得更好,以及什么运行很差。这通常由这个项目的参与者们之间的讨论来引导的,由独立的主持者引导。这个部分的目标不是确定过失,而是确定将来项目中需要改进的区域。在引导这个核查性评估中您应该鼓励人们反思他们所遵循的过程,确定什么运行良好以及需要改善的其它任何事物。要尽可能的达到平衡。比如:

  • 同时强调好的和不好的
  • 公开且公正地对待已经完成和没有完成的
  • 公开且公正地对待已经完成和没有完成的

我们都需要从错误和成功中学习,因此不要忽略地毯下的错误——如果您要随着时间不断改善您项目的成功,那么公开且公正地对待什么正在进行以及什么没有进行是十分重要的。不要过分强调确定过失,而要关注需要怎样做才能使下一个项目做得更好。您应该努力创建一个学习的文化氛围,而为了改善的尝试将会得到回报。

为下一个演变或者项目做准备的过程中,您应该对下一次应该有什么变更提出建议,做出决定并将它付诸于行动。学习经验并与其他人相互交流这些经验,从而使其他项目团队能够对您的经验有所益处。这样说起来似乎是显而易见的,但是我观察到即使是迭代,阶段以及项目评审可以被管理,也会导致很不满意的频率,行为中很少有长期的变化会在同一个组织中的不同项目中产生。我们很容易将项目中的问题归咎于个人或者独特的事件,但是我的经验是绝大多数问题是系统的,它们会一直重复直到根本的原因被解决。

当项目是一个较大的计划的一部分时,这显得尤为重要。通常一个大计划的所有项目都遵循相同的(或者十分相似)过程,如果这个项目的问题是由监测过程和风险的相关过程或者相关度量方法引起的,就应该尽可能早地解决掉这些问题,从而防治在这个计划的其它项目中重复相同的问题。

度量嵌入在计划中的项目

既然我们已经在三篇文章中涉及到一个迭代软件开发项目的必要阶段中测量项目性能的方法,现在就让我们考虑一下更多的上下文关系。通常,我们必须管理潜入在一个较大计划中的项目,它们需要从一个交叉项目的角度评估项目的性能状况和直到交付。包含在这个计划中的项目都紧密相连,一个项目中的问题就能威胁整个计划的成功。尽早发现这些问题可以尽早进行处理,从而潜在地保护了这个计划。

一个计划就是由以并列方式管理的一组相关项目组成的。计划通常包括许多正在进行的工作。不同种类计划的例子包括:

  • 战略计划,在这个计划中,项目可以共享显示和目标
  • 业务生命周期计划,在这个计划中,项目可以共享预算和资源,但是可能在远景和目标中有所不同
  • 基础设施计划,在这个计划中,项目指定和部署了许多其它项目可以使用的支持性技术,从而导致标准的共享
  • 研究与开发计划,在这个计划中,项目共享评估标准
  • 合作计划,在这个计划中,项目跨越了合作的组织

这仅仅是许多不同种类计划的样例,通常还有一些包含不同方面的变种。记住一个计划非常重要的一点是,它组织项目并重点强调详细而精确的战略业务结果的交付。真正的计划与重点强调组织的能力中一个步骤变化交付的较大项目是不同的,它可以依次影响到这个业务的所有方面,包括业务过程、财政结构,以及信息技术。

能够从合作计划中获得利益的不同种类项目的例子包括:

  • 构建软件的开发项目
  • 培训这个系统用户的项目
  • 为这个新系统升级服务器和基础设施的项目
  • 培训支持人员的项目

由于在这些项目中执行的工作类型差别很大,因此为每一个拥有一个单独的项目是很有意义的,但是为了使这个商业价值能够被交付,所有的项目都要成功,所以还需要一个计划来管理整个的工作。

将项目组织到计划中去

将项目组织到计划中同时会带来一些新的问题。有时候需要附加的管理工作,从而使以协调的方式执行项目比所有的项目都单个执行的好处要大得多。在一个计划中,项目通常是共享目标的,并有共同的过程,至少它们将会共享里程碑,度量方法以及检查标准。

为了区分项目迭代里程碑和阶段末尾,我将介绍“阶段”这个的概念。在工作中,一个阶段就是对一个项目演进的计划——是用来管理一个协调的工作,使其向一些共同的结果发展。计划阶段与项目之间的关系如图1所示。

Diagram of relationship between program stages and projects.

Diagram of relationship between program stages and projects.

图1:计划阶段与项目之间的关系

在组织的能力内,每一个阶段代表着一个递增量变化。阶段的末尾提供了一个主要的检验点,计划结果在这个检验点可以根据预期的结果来评估。

阶段可以用来对相关的项目进行分类,如图2所示。

Diagram of related projects grouped according to stages.

Diagram of related projects grouped according to stages.

图2:利用计划的阶段对共享目标的项目进行分类

正如一个软件开发项目的进展,这些阶段也可以交迭,由于它们都是一个更大合作式计划的增量交付产品的一部分,因此它们是建立在其它项目和共享目标基础上的。因为大多数计划都是生命周期较长的(有些可以持续几十年),因而一个计划中有许多无限量的阶段。

图3显示了在一个被控制项目管理的阶段中,其中的工作将如何被组织起来。注意对于这个控制项目的阶段,有时候是如何比它管理的相应阶段晚一些结束的。这样能使由被管理项目产生的结果累积到控制项目。

Diagram of how a stage can be governed by a control project.

Diagram of how a stage can be governed by a control project.

图3——利用控制项目来管理计划阶段

在实践中阶段是如何被管理的?控制项目通过发现作为一个整体的阶段的整个发展目标和想要的结果,创建或者升级这个阶段中所有项目共享的整个构架来推进这个阶段的。由于稳定了这个构架,这个阶段中的附加项目就会被控制项目启动并检查。每个阶段都有它自己的为了管理而用的控制项目。

度量计划阶段

由于每个阶段都是独立于其它阶段的,它们能够并且应该可以分别管理。控制项目为这个阶段提供了一个有用的控制和管理方法,在这篇和前面两篇文章中讨论的相同的项目度量方法也适用于一个计划阶段的控制项目管理。控制项目作为一个项目进展贯穿于相同的生命周期——它贯穿于 IBM® Rational® Unified Process (RUP®) 生命周期的所有的四个阶段。

然而,控制项目与常见的项目是不同的,在常见项目中这个阶段的绝大多数实际工作发生在伴随有控制项目的子项目中。因此控制项目的管理需要从这个阶段的子项目中巩固和累积度量方法。比如,来自子项目的风险和问题需要从控制项目的风险和问题中整理而来。其它项目性能的度量方法可以从这个阶段度进展的角度,用类似的方法来积累。

总结

RUP 的产品化阶段强调的是对它指定用户的解决方案最终交付的问题。产品化阶段的项目性能测试强调的是质量和发布准备,不仅包括代码的准备,也包括用户社区接受发布以及支持发布的支持组织的准备。在项目完成的基础上,检查整个项目来确定下一次哪些应该做得更好是十分重要的。整个项目采取的度量方法将有助于检查工作的进行,正如它们在整个流程中对项目的利益。

有时需要不止一个的项目来交付想要的商业价值,一个计划对于确保两个或者更多项目间成功合作是一个有用的管理机制。由于计划的生命周期通常较长(它们能够持续几年或者几十年),它会习惯性地将它们分为几个阶段,或者针对一个商业价值的特殊交付的时间段。控制项目对于一个阶段的协调项目是很有用的机制。引入这个控制项目还能够使来自子项目的结果累积到计划的水平。

进一步阅读

这篇文章是从在由 Kurt Bittner 和 Ian Spence 合著的 Managing Iterative Software Development Projects 中最初的材料中摘取的,由 Addison-Wesley 于2006年出版。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=240425
ArticleTitle=Rational Edge: 度量项目的健康性,第 3 部分
publish-date=07162007