内容


通过度量进行有效的管理

Comments

illustration

无论是对于经验丰富的还是经验不多的项目经理们来说管理软件开发都是非常难的,并且获得准确的项目进展的测量是一个永恒的挑战。通常,当项目经理依靠团队成员所提供的状态数据时,他们得到的结果是不一致、不准确和难以比较的。此外,贯穿于项目,执行官、责任经理和客户也许会要求以各种格式的包含被选定数据的状态报告。绝大多数情况是,团队发现他们将要花费比开发方案更多的时间来产生状态的报告。

一个有效的、自动化的软件项目度量程序能够帮助项目经理应对这些挑战。它能够使项目经理在多个项目域中评估项目进展、在开发周期的早期发现问题,并且通过排除冗长的报告任务提高团队的生产力。

在这篇文章中,我们将讨论使用这样一个度量程序的好处,并且识别相关的最佳实践和能够支持它的工具。贯穿这篇文章,我们将展示对于执行官和项目经理的样例视图,这些视图都是通过 IBM 软件开发平台中的工具自动产生的。

作为有效管理工具的度量

度量是一个有效的管理工具,因为它提供了决策者所需要的信息以准确的监视对于公司和组织目标、进度和在执行官和项目经理级别上的质量以及根据计划的项目执行情况的关键问题。度量也提供了经理需要回答正确问题的信息 - 并且基于目标的信息作出正确的决定。

2003 年 一月的 Rational Edge文章" 在 Rational 统一过程中的实践度量"详细的说明的度量的好处,同时我们也发现了一些新的好处。作为经理,度量将帮助我们做下面的事情:

  • 有效的沟通和改进可见性。 度量支持跨于组织所有级别的涉众之间的沟通。目标的度量也可以减少不明确性。度量提供了一种有效的方法以在供应者和他们的客户之间沟通状态。
  • 尽早的发现和更正问题。 度量可以帮助积极的管理项目。它允许我们在开发周期的早期发现并管理潜在的问题。问题发现的越晚将越难管理,并且要花费更对的成本来修复问题。使用度量,经理不必等待问题的出现;相反,他们能够预期并快速的解决问题。
  • 作出关键的权衡。在一个域中的决定常常会影响其他的域。度量能够帮助我们客观的评定影响,以便经理能够作出合理的权衡决策,从而最好的符合项目的目标。
  • 跟踪特定的项目目标。度量能够帮助回答特定的问题,比如:“项目是按时间计划进行的吗?”或者“质量有所改进吗?”或者“系统准备好交付了吗?” 通过跟踪项目计划的实际测量情况,项目经理能够针对项目和组织的目标评估项目的进展情况。
  • 管理风险。 风险管理是一个广被接受的最佳实践,它包括在项目周期中尽早的识别和分析风险。较晚的发现风险将使处理风险更加困难,并要花费更多的成本来处理风险。通过使用高质量的客观数据,项目经理能够获得对风险区域的可见性,比如需求的蔓延。通过度量和监视需求的变更,他们能够确定一个风险是否被减轻了。
  • 辩护和证明决策。 经理必须有效的辩护和证明他们的决策。在基于经理根据主观或者客观数据的决定之间做一个选择,大多数情况下应该选择客观的数据。度量提供了客观的历史执行或者趋势数据,比如当前的执行数据。它也提供了有关时间、项目、发布和其他方面的视角。这允许决策者理解度量结果,并决定采取适当的动作。
  • 计划未来的项目。 在项目计划中,经理必须设定现实的目标和时间计划,而没有提及预算。对过去的项目记录时间期限和花费提供了为相似项目经理需要的预计时间表和成本的数据。

度量和过程

已被多次证明:成功的开发软件的公司和团队都会遵循一个可重复和可度量的过程。在 IBM Rational,我们也发现这些公司和团队如何关联开发过程到度量。成功的组织应该做下面的事情:

  • 首先要建立一个基础过程。
  • 使用基础过程的通过度量产品的方法。
  • 遵循基础过程以确保度量方法有效。
  • 通过自动化改进度量方法的质量,并产生更多的目标结果。
  • 在过程中识别使用工具的度量点,这些度量点能够被转化成为测度或者可跟踪的度量属性。

在与许多公司的工作中,我们也识别出了有关度量的共同问题和过程,并且帮助经理找到解决方案。

  • 在一些组织中,软件开发过程是严格的,而度量相对于过程来说是第二位的。如果你需要一个新的度量,你首先需要更新或者改变你的过程。你能够通过裁剪过程和直接将使用工具的度量点合并到过程中来解决这个问题。你能够通过部署开发工具使这些度量点的访问更加容易(见图 1)。自动化的工具使定义你能够收集的东西更加容易以。
  • 有时度量并不反映实际的工作。如果组织能够跟踪仅仅是项目预算和时间计划,这是一个问题。在这种情况下,花费在一个任务上的金钱或者时间数量可能不会反映实际被执行的工作。例如,你可能知道你花费了 X 数量的美元开发代码,但是你不知道实际有多少代码被开发了。你不能仅仅通过任务的时间表和花费来测量生产力。通过修改你的过程以包括对额外项目产物的度量,比如需求、用例设计对象、代码、测试用例、缺陷等等,你就能够得到关于你实际花费了多少时间和金钱以及你的项目进展如何的更加准确的视图。

使用如图 1 所示的自动化工具能够帮助你度量软件过程的关键组件,并提供对度量点的方便的访问。

图1: IBM 软件开发平台中对度量有用的工具
Figure 1: Tools in IBM Rational Software Development Platform that are useful for measurement
Figure 1: Tools in IBM Rational Software Development Platform that are useful for measurement

关键的管理测度和视图

你应该如何修改你的过程和你应该测量什么呢?我们通常会问这些问题。而通常我们的答案是“它依靠”。首先,它依靠你在软件开发周期的哪里。如果你正在做迭代开发,什么是你想在细化阶段测量的将与什么是你想在构建阶段测量的是不同的。它也依赖于你在组织中的职位。如果你是一个部门经理,你可能希望看到与一个项目经理不同的信息。你可能对改进生产力感兴趣,而项目经理将会对在会议中被提议的时间计划和产品缺陷数的减少感兴趣。

关键是要知道你的信息需要,然后设计你的测量方法。你能够通过组织、项目、团队目标和风险来定义这些需要。因此,你将希望对你的测量进行分类以使他们对相应的用户更容易理解。作为一个例子,在本文中我们将基于如图 1 所示的 IBM 软件开发平台的能力来组织管理测量的方法。

IBM 软件开发平台

一个丰富的工具集、被证明的最佳实践和专业的服务,IBM 软件开发平台将帮助团队构建、集成、扩展、现代化和部署软件以及基于软件的系统。使用 IBM Rational 统一过程(RUP),作为一个基础,平台自动化和集成了软件变更和资产,以便团队能够更好的利用他们的软件开发能力。

IBM 软件开发平台跨越了所有的软件开发领域:

  • 过程和项目管理。 经理能够对每一个项目计划并实施测量,并确保跨越企业的过程的一致性。
  • 需求和分析。 通过使经理理解和管理贯穿软件开发周期的业务和需求的演进自动化工具帮助你减少风险。
  • 设计和构建。 当构建业务应用。软件产品和系统时,团队能够最大化他们的生产力。
  • 软件质量。 团队能够增加对项目的预知性,并通过在开发周期中尽早的发现缺陷来确保质量,缺陷越早的被发现,解决起来就越容易。
  • 软件配置管理。包括安全的管理软件变更和资产工具的平台,对整体开发周期提供可跟踪性。

让我们来看一些管理测量的例子,你能够使用 IBM 软件开放平台来实现每一个区域。这些例子是使用 IBM Rational ® ProjectConsole ,一个 IBM Rational 团队统一平台的组件,生成的。 IBM Rational 团队统一平台的组件本身也是 IBM 软件开发平台中的一个组件。

Rational ProjectConsole 自动化的报告项目的状态,提供一系列自动化的收集代理,定制的报告和一个图形化的仪表盘,它允许你自定义度量的视图并执行根源分析。

测量项目管理和过程

一个成功的度量系统必须是足够灵活的以满足组织的信息要求。度量需求从对于在 C 级别上的执行官(CTO, CIO, CEO 等)或者部门经理级别的视图与在项目经理级别上的详细视图是不同的。

执行官通常需要高级别的信息。比如,负责一系列的项目挥着产品的部门经理确定每一个项目的状态和关键的进度测度。一个绿-黄-红的可视化的状态指示器能够提供这种高级别的表示。在图 2 中的样例视图中对一个项目列表显示了被 Rational ProjectConsole 生成的信息。它包括:

  • 状态: 基于计算值的整个项目的状态与已知的极限进行比较。实际的计算值是组织或者项目特定的。
  • 打开状态的高优先级的变更请求: 当前打开状态的高优先级的变更请求数量。在这个例子中,这是量度作为一个被需要的信息被识别。
  • Glidepath: 被验证的缺陷的数量 VS. 预计验证的缺陷数量。在计划一个发布版本时,项目识别出了团队计划在发布版本中修复的缺陷的数量。这个度量显示针对目标的进展。
  • 测试覆盖率:代码被测试过的百分比。
  • 将要验证的变更请求:剩下有多少工作要执行。
图 2: 一系列项目的执行官视图
Figure 2: Executive view for a list of projects
Figure 2: Executive view for a list of projects

图 3 显示了另一个使用一个项目健康的可视化(绿-黄-红)状态指示器的执行官视图。执行官也能够点击项目名称来查看每一个项目的二级详细的状态信息(图 4)。

图 3: 一个部门状态报告的执行官视图
Figure 3: Executive view of a division status report
Figure 3: Executive view of a division status report

在项目的级别上,对于全面的状态报告典型的重要区域是:

  • 项目管理:成本、时间表、风险、人员分配等等。
  • 过程:标准、一致性、生产力目标等。
  • 需求与分析: 满足需求、变动和用例开发的进展。
  • 设计与构建: 业务、设计和数据库模型的完成和变更情况;代码开发情况。
  • 软件质量: 单元测试进展、系统测试进展、测试覆盖率。
  • 软件配置管理: 缺陷和变更请求跟踪、基线进度、活动管理。
  • 工程支持:工具开发,软件开发环境支持。
  • 操作:硬件的可用行。

图 4 显示一个项目经理的样例视图。

图 4: 对于所有区域的项目经理的高级状态报告
Figure 4: Project manager's high-level status report for all areas
Figure 4: Project manager's high-level status report for all areas

经理可以选择进入到图 5 显示的区域中来收集更多的与下面的项目管理分类相关的状态信息:

  • 突出部分和问题:为了识别、分析和跟踪动作条目和问题。
  • 计划和时间表: 为了监视 项目计划和时间表,并根据计划跟踪进度(随时间推移完成的工作)。一个有用的时间表指示器是时间表执行索引(SPI),如图 6 所示。如果 SPI 大于一,项目是比计划超前的。如果 SPI 小于一表示项目落后于计划。
  • 成本和盈利值: 为了维护对整个项目周期开销的控制。一个有用的成本指示器是成本执行索引(CPI),如图 6 所示, CPI 是被计算出来的。如果 CPI 大于一,表明项目超出预算了。如果 CPI 小于一,表明项目在预算之内。
  • 人员安排: 作为项目动力和士气的指示器,为了监视项目成员的添加和消耗。当新人被要求加速项目进度时,在人员上的急剧增加能够减慢项目的进度。对于好的团队成员的低消耗时成功的信号。高度的变化可以指示在士气或者动机上的问题;对于项目经理来说它是一个警告的信号。
  • 风险: 为了持续识别、分析和跟踪危险项目成功的风险。积极的风险管理增加了项目成功的机会。
  • 遵循: 为了跟踪遵循标准或者过程改进目标的情况。
  • 客户满意度: 为了确保客户需求被满足。

项目经理可以挑选出这个列表中需要的监视的类别。

图 5: 项目管理状态报告
Figure 5: Project management status report
Figure 5: Project management status report
图 6: 成本执行索引(CPI)和时间计划执行索引(SPI)
Figure 6: Cost Performance Index (CPI) and Schedule Performance Index (SPI).
Figure 6: Cost Performance Index (CPI) and Schedule Performance Index (SPI).

图 7 显示了根据计划的进度。自动化的项目计划让你识别任务并分配计划的完成时间。使用 IBM Rational ProjectConsole ,你能够跟踪在你的项目计划中的任务的进展。

图 7: 任务进展 — 计划的任务 VS. 任务的完成
Figure 7: Task progress  —  planned tasks versus tasks complete.
Figure 7: Task progress — planned tasks versus tasks complete.

在过程领域中,项目经理可能希望得到关于下面的更进一步的状态信息:

  • 突出部分和问题: 为了识别、分析和跟踪动作条目和问题。
  • 计划和时间表: 为了监视 项目计划和时间表,并根据计划跟踪进度(随时间推移完成的工作)。
  • 成本和盈利值: 为了维护对整个项目周期开销的控制。一个有用的成本指示器是成本执行索引(CPI),如图 6 所示, CPI 是被计算出来的。如果 CPI 大于一,表明项目超出预算了。如果 CPI 小于一,表明项目在预算之内。
  • 人员安排:为了监视项目成员的添加和消耗。
  • 风险: 为了持续识别、分析和跟踪危险项目成功的风险。积极的风险管理增加了项目成功的机会。
  • 遵循:为了跟踪遵循标准或者过程改进目标的情况。
  • 缺陷包含:在特定的时间周期或者发布中,为了监视被发现和修复缺陷。这个测量可以当作测试效力的指示器。
  • 缺陷遗漏: 为了测量已发布版本中的缺陷数量。这个测量可以指示在软件开发过程中的问题。
  • 废弃和返工:为了监视对于软件基线的变更数量。在一个健康的项目中,这个趋势应该是减少的或者稳定的。增加返工是维护要求和成本增加的信号。图 9 显示了代码行的废弃。然而,废弃和返工不仅限于代码;他们也会从设计的变更所导致,并且能够在设计模型中被监视。
  • 生产力: 为了监视基础过程是否在改进生产力。

图 8 显示对于过程的高级别的绿-黄-红的状态报告。

图 8: 过程领域的状态报告
Figure 8: Status report for process area
Figure 8: Status report for process area
图 9: 废弃 — 通过被删除的代码行数进行测量
Figure 9: Scrap — measured by lines of code deleted
Figure 9: Scrap — measured by lines of code deleted

测量需求和分析

需求和分析包括理解问题领域,捕获和管理演进的需求,建模用户交互和在整个项目周期内合并涉众的反馈。好的需求与分析实践能够帮助项目降低风险。

在需求与分析中监视和测量的领域包括:

  • 突出部分和问题: 在需求与分析中的动作条目和风险降低。
  • 计划和时间表: 计划 VS. 根据时间表开发的实际需求或者用例。
  • 成本和利润值: .对需求和分析的预算跟踪。
  • 需求复审: 需求和涉众复审的进度。
  • 用例复审: 用例和涉众复审的进度。
  • 检查: 需求确认。
  • 需求变化: 变更需求会影响时间进度和成本。见图 13 详细的了解这个测量。

一个对于项目经理的高级别视图能够位每一个领域显示绿-黄-红的指示器,如图 10 所示。

图 10: 对于需求和分析的高级别状态视图
Figure 10: High-level status view for requirements and analysis
Figure 10: High-level status view for requirements and analysis

其他的详细视图,比如在图 11 中的需求总结和在图 12 中的用例总结(他们都是从 IBM Rational RequisitePro 提炼出来的),能够提供关于需求和分析开发的进展。

图 11: 需求总结视图
Figure 11: Requirements summary view
Figure 11: Requirements summary view
图 12: 用例总结视图
Figure 12: Use-case summary view
Figure 12: Use-case summary view
图 13: 需求变动 — 通过修改的数量进行测量
Figure 13: Requirements churn (volatility) — measured by number of revisions
Figure 13: Requirements churn (volatility) — measured by number of revisions

测量设计和构建

设计和构建包括建立建构和模型设计、模型驱动的开发、软件编码、修改缺陷和相应增强请求以及组件的测试。

在设计和构建中需要监视的领月包括:

  • 突出部分和问题: 动作条目和风险降低。
  • 计划和时间表: 被计划的设计元素或者源代码 VS. 根据时间表实际的设计元素或者源代码。
  • 人员安排: 开发人员中附加和消耗。在大规模的项目中这个测度是重要的。
  • 成本和利润值: 花费和预算跟踪。
  • 设计模型完成率: 你的架构和设计模型的完成情况,或者设计模型的进展(趋势)。见图 15, 理想的情况是根据计划的值进行比较。
  • 完成量: 代码开发的趋势显示了开发的进展(见图 16)。理想的情况是,根据被计划的值比较实际被开发的代码以确定还有多少工作需要做。
  • 软件检查:同级评审检查可以发现在产品中缺陷、不一致性和影响软件质量和性能的问题点。
  • 需求变化: 变更需求将会影响交付的时间表并增加软件返工和成本。
  • 打开状态的问题和创建时间: 打开状态问题报告的数量,帮助确定是否人员是足够的。

图 14 显示了对于一个项目经理的高级别的、绿-黄-红的设计和构建的状态视图

图 14: 设计和构建的高级别的状态视图
Figure 14: Design and construction high-level status view
Figure 14: Design and construction high-level status view
图 15: 通过被开发的类测量设计模型的完成情况
Figure 15: Design model completeness measured by classes developed
Figure 15: Design model completeness measured by classes developed
图 16: 被开发的源代码行总数的趋势
图 16: 被开发的源代码行总数的趋势
图 16: 被开发的源代码行总数的趋势

测量软件质量

确保软件质量包括测试功能、可靠性和性能。它也包括跟踪所有你所做的测试工作,并确保对目标发布应用中的所有被需求的功能的测试覆盖率。

对于软件质量,应该监视的领域包括:

  • 突出部分和问题: 动作条目、问题和风险降低。
  • 计划和时间表: 被计划的测试用例 VS.根据时间表的实际测试结果
  • 人员安排: 在测试团队中的人员增加和削减。
  • 成本和利润值: 预算跟踪。
  • 单元测试: 被计划。执行。通过和失败的测试数量以确定进度。
  • 系统测试: 被计划、执行、通过和失败的测试数量(见图 18 和 图 19)。
  • 性能测试: 吞吐量或者相应时间。
  • 缺陷: 对客户报告的缺陷或者所有缺陷的跟踪(见图 21)。

对于软件质量,一个项目经理查看象图 17 中的一个高级别的绿-黄-红的状态报告。

图 17: 对于软件质量的高级别状态视图
Figure 17: High-level status view for software quality
Figure 17: High-level status view for software quality
图 18: 测试状态(趋势表)
图 18: 测试状态(趋势表)
图 18: 测试状态(趋势表)
图 19: 迭代的测试状态
Figure 19: Test status by iteration
Figure 19: Test status by iteration
图 20: 缺陷跟踪 — 客户报告的缺陷
Figure 20: Defect tracking — customer reported defects
Figure 20: Defect tracking — customer reported defects
图 21: 严格的缺陷跟踪
Figure 21: Defect tracking by severity
Figure 21: Defect tracking by severity

测量软件配置管理

软件配置管理包括捕获、控制和管理软件的变更和资产。这包括在软件资产管理中的缺陷和变更跟踪。

在软件配置管理中,应该监视的领域包括:

  • 突出部分和问题: 动作条目和风险降低,这通常对一个项目的所有领域都是必要的。
  • 计划和时间表: 被计划开发的源代码 VS. 实际根据时间表开发的源代码。
  • 人员安排: 在配置管理人员中的增添和减少。
  • 成本和利润值: 预算跟踪。
  • 缺陷状态: 目标缺陷的状态。
  • 增强状态: 开发下的特性的状态。
  • 构建状态: 构建准备就绪。
  • 代码变动:在被配置的或者被基线化的软件中被添加、修改和删除的代码行的数量(见图 23)。这个测度显示了构建和发布版本的就绪情况。增加变动表明发布版本是“没有就绪的”。

图 22 显示了高级别的、项目经理的、对于配置管理领域的状态视图。

图 22: 高级别的软件配置管理状态的视图
Figure 22: High-level view of software configuration management status
Figure 22: High-level view of software configuration management status
图 23: 被配置的软件代码的变动
Figure 23: Configured software code churn
Figure 23: Configured software code churn

总结

对于经理们来说,度量提供了对项目进度评估、演进项目质量的洞察力和用于目标决定的数据。虽然它不能担保一个项目的成功,但是度量可以帮助决策者通过积极的方法来管理软件项目中与生具来的关键问题。

我们已经提供了度量视图的许多样例,但是成功的关键不是实现本文中显示的所有度量。评估你的项目和组织,识别你的涉众需要,识别测度和指示器以确保你能够满足那些需求,并实施一个不会打扰项目的自动化的度量程序,这个度量程序将提供你所需要作出关键决策的客观信息。

想了解关于 IBM 软件开发平台的更多信息,见 IBM 网站
想了解关于 IBM Rational ProjectConsole的更多信息,见 IBM Team Unifying Platform 页面

参考引用

Doug Ishigaki 和 Cheryl Jones, " Rational 统一过程中的实践性的度量。" Rational Edge, 2003 年 1 月。

John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean, 和 Fred Hall, Practical Software Measurement: Objective Information for Decision Makers. Addison-Wesley, 2002.

Philippe Kruchten, The Rational Unified Process: An Introduction, Second Edition. Addison-Wesley, 2000.

IBM Rational 统一过程2003.06.12. IBM, 2004.

Practical Software and Systems Measurement Web site (includes the PSM Insight tool): http://www.psmsc.com.

ISO/IEC 15939 Software Measurement Process. International Organization for Standardization, 2002.

Software Engineering Institute, "Capability Maturity Model ® Integrated (CMMI(sm)) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, Version 1.1 Staged Representation." Carnegie Mellon University, March 2002.

Walker Royce, Software Project Management: A Unified Framework. Addison-Wesley, 1998.


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=53548
ArticleTitle=通过度量进行有效的管理
publish-date=06012004