使用GQM 实现治理目标共16页文档.docx
《使用GQM 实现治理目标共16页文档.docx》由会员分享，可在线阅读，更多相关《使用GQM 实现治理目标共16页文档.docx（13页珍藏版）》请在冰点文库上搜索。
使用GQM实现治理目标共16页文档
使用GQM实现治理目标
RogerDunn,CEO,SourceIQ,Inc.
RogerN.Dunn是SourceIQ公司（一个致力于交付来自于IBMRational基础架构的管理标准的高级IBM商业伙伴）的创立者和CEO。
他拥有二十五年的领导团队进行ISV和IT软件开发项目的经验。
简介：
阅读目标问题矩阵方法（Goal-Question-MetricApproach，GQM）如何提供一种方法，这种方法对于整个团队，或者个体的团队成员来说，使他们更好的理解他们在成功的软件开发中所扮演的角色。
本文来自于TheRationalEdge。
标记本文！
发布日期：
2008年4月15日
级别：
初级
其他语言版本：
英文
访问情况186次浏览
建议:
中国有句古老的谚语，“千里之行始于足下”。
1当在软件项目规划中起航时，我不想在第一步就遇到绊脚石。
我想要项目规划能够在控制之中并取得成功，以避免另外一个著名的格言：
“如果你不知道你要去哪里，那么你可能会走向任何一条路。
”2
问题矩阵方法（Goal-Question-MetricApproach，GQM）3是一个强大的工具，它能够使您有信心和指导方向的迈出第一步。
GQM帮助我们为管理模型建立框架，这是通过将最初的关注点放在我们想要实现的目标矩阵上实现的。
在本文中，我将从两个方面展示GQM。
第一个方面是，GQM应用于什么？
我将讨论应用GQM的四个阶段：
（1）建立目标；
（2）定义问题；（3）识别矩阵;（4）设置行动模型
第二个方面是，我们能够从已经应用了GQM的角色中学习到什么？
我将解释阵势世界的GQM场景，针对于IT执行管理层、项目经理、架构师、开发经理和软件质量经理。
我将通过再次的探索和调查得出结论，GQM如何能够更好的帮助我们定义我们的第一步，以及后续的事情；它实际上如何能够帮助扮演不同角色和不同方面的知识工作者，以找到他们的共同点，使他们相互支持，以促进开发治理和IT结果。
应用GQM
多数人知道GQM是因为VictorBasili博士的思想，VictorBasili博士想为问题的解决和头脑风暴创建一个概念的框架。
GQM方法并不只限于软件开发，或者IT治理，或者甚至是技术问题的解决，尽管它给了自己一个非常好的技术环境。
基本上，GQM提供了一个框架来帮助您理解您的目标是否已被实现。
您可以提出您的目标指令的问题，您可以建立验证问题答案的度量方法。
GQM是灵活的，它被设计用来指导我们的认识上的潜力。
在本文中展示的GQM是基于几年前SourceIQ所指导的过程成果相关涉众的访谈内容的。
这些GQM集合是典型的和有代表性的，但他们并不是完全没有遗漏的。
一旦您得到了基本的思想，您将能够针对您的场景创建属于您自己的GQM。
阶段1:
建立目标
定义和澄清目标是关于所需要的，因此使用目标开始GQM是很自然的和直接了当的任务。
它也是会给开发组织带来切实的利益。
目标澄清方向，并展现出企业将要走的路线，包括治理、质量、会议计划和预算，或者也包括客户满意度。
阶段2:
定义评估目标进展的问题
一旦我们在概念的层面定义了目标，之后我们将展示必须是可以回答的具有操作性的问题，以确定进展或者目标的实现。
目标和为目标服务的问题典型地是我们在组织中所执行地角色的功能。
也就是说，他们是基于每个知识工作者类型的兴趣和技能领域的。
当不同角色的人参与到GQM时，他们的目标和问题第一眼看上去可能是不相关的。
例如，CIO想要驱动创新，包括成本和业务单元之间的沟通。
项目经理可能想改进对于未来新的和维护开发活动的估计。
QA经理可能关心特定的目标和与软件质量和过程稳定性相关的问题。
然而，当我们进入到GQM的第三阶段，我们也许会非常惊讶了解到哪些对于开发治理表面上不相关的目标，却能够在公用的度量模型中。
阶段3:
识别支持回答问题的矩阵
一旦您理解了需要评估目标的问题，之后我们将使用特定的必要矩阵来组织问题的答案的方法建立度量模型。
通过经验的观察和与客户一起工作的经验，我们发现对于不同的方面和视角，为不同知识类型的工作者建立的目标和问题通常是不同的。
一个典型的结果是GQM开发一个公共的理解，使用公共的度量模型，进一步这个模型直接连接到软件开发的非常人性化的本质：
我们的过程有多么融合？
我们的项目复杂度如何？
有多少工作者能够在新的复杂的有很多部分组成的系统中能够胜任？
软件工作产品的质量是否符合工程标准，具有需要的生产环境稳定性？
阶段4:
设置行动度量模型
一旦我们应用了GQM并到达了支持我们需要的度量模型，我们就要准备设置行动模型了。
在"软件管理的开发治理"中4,我们讨论过IBM®Rational®基础架构在应对遵循报告上自动化收集和软件分析矩阵所扮演的角色。
GQM帮助我们将焦点集中于我们需要实现的目标上；Rational为我们提供了交付这些矩阵的平台。
换句话说，使用GQM决定您将度量什么，以及这些度量目标实现程度的方法。
在您的Rational基础架构中将此方法应用于您的开发过程的实际情况，并且开始度量！
通过角色应用GQM
GQM通常被认为是一个自上而下的方法，它建议执行管理层角色是我们的开始点。
但是驱动者，或者潜在的驱动者，对于变化来说通常以项目为中心。
这就意味着项目级的目标是非常理想的GQM分析开始点。
分析能够向上扩展到一个项目如何为公司的长期目标服务，或者向下扩展到项目如何影响个体团队成员的工作。
我将在本文的结论部分对它稍加解释。
实际上，自上而下应该可以很理想的符合由底至上的组织结构，这个方法将来自于执行管理层、适当的工程标准以及来自开发和质量保证层面的质量标准转化成了组织的目标和质量的命令。
我非常坚信GQM不应该被认为仅仅是自上而下的框架，有时它被作为了这个方法的限制。
实际上，GQM不仅仅能够从组织的阶梯结构发起，它也能从组织中的单一角色发起－包括抵制使用GQM方法进行目标分析的组织。
也就是说，它对组织中所有的角色不是强制性的，虽然所有的角色都使用这个方法是理想的状况。
任何一个个体或者团队都可以采用QGM，无论他们是什么角色，即便其他人并不使用这个方法，您也将从中受益。
注释：
一些团队比其他团队更需要GQM。
对于整体使用这个新方法的组织来说，可以以最需要使用该方法的团队为开始点，不要一下子全面铺开，要逐渐的向整个组织实施此方法。
从上之下与从底至上融合的结果能够带来想法上的和谐，或者导致列车的失事；通常是在中间的某个地方结束。
让我们来了解一下GQM与哪些开发组织中的不同角色有关。
IT执行管理层
IT执行管理层典型地是报告给一个业务部分的CIO。
这个层面的目标集中于保持和吸引客户的方法，在没有牺牲基础能力的前提下更具竞争力，并降低成本的方法。
这里由4个例子，它们在SourceIQ中是最典型的。
G:
对客户创新交付的增强。
Q:
我们需要对从软件维护到新的开发的转移进行资源与预算上重新分配吗？
M:
生产环境的代码量。
快速的增长或者膨胀的代码导致了维护成本的急剧上升。
这将消耗更多的人来处理现有应用的问题解决和新特性开发。
包含维护成本，并通过反向跟踪在逻辑上产生的代码增量。
关系到了下面的架构师的目标。
M:
生产环境的代码复杂度。
随着时间的迁移，系统实现与复杂度将共存，因为修改问题和添加新功能将会增加代码量。
执行管理层在复杂度上的关注将影响团队的行为，这可以通过将改进的和可维护的代码作为优先级来实现。
这将导致更低的TCO，并为创新节约了预算和人力。
G:
通过改进交付和增加透明度，改进与业务部门的关系。
Q:
我们如何能改进交付和增加透明度，以及与业务部门在目标进展上的沟通？
M:
生产环境的代码量。
通过沟通对于业务关键应用的逻辑资产量，这些资产的增长率和当前的维护和增强活动的关系，IT将能够通过实际的，基于现实的方法与客户进行沟通。
业务部门将了解到IT部门对于他们业务扩展的工作支持和结果。
M:
软件开发活动的挥发性
支持业务逻辑的可视化将显示出IT正在对业务部门的需求、增强和维护工作做着积极的响应。
G:
为更精确的预算预测获得基线
Q:
实际需要的工作如何能够完成，将被评估的里程碑如何被应用到未来的工作中？
M:
软件开发活动的量级和挥发性
与过去工作相关联的度量量级和挥发性形成了未来类似实现规模的基线。
假设对于开发人力的技能集和领域专家保持相对稳定，应用在上的技术也没有巨大的变化，包含在您的软件配置管理系统中的处理信息能够被用来生成对未来工作的清晰的一致的基线。
基线的信息越多，管理层应该也能看见根据应用生命周期管理上的基线的可度量的改进（培训、测试自动化、持续集成、敏捷方法、降低需求误解、动态语言的使用，等等。
）
G:
从开发的合作伙伴获得高层的明确标准/性能指标
Q:
我的合作伙伴如何满足我的组织的标准呢？
对于其他的合作伙伴又如何呢？
M:
挥发性、复杂性、语言规则遵循、编码指南。
管理外部的开发需要面对更大的挑战。
是否存在足够的服务级别约定（SLA）标准呢？
工作活动是否符合公司的标准（复杂度和其他规定），计划的发布时间符合标准吗？
是否存在有效的技能移交？
对于项目或者任务的类型，合作伙伴是否具备合格的能力？
使用矩阵进行比较能够驱动管理层与合作伙伴的关系，并驱动更好的交付。
项目经理
典型的项目经理面对从他的项目的日常细节被解放出来的问题。
与此同时，项目经理为生成环境的质量目标，以及满足众多的计划时间点为烦心。
这些关注被新引进的生产模式更加扩大化了，比如，敏捷开发方法与全球化分布式团队的结合－这些显示快速的导致了更加痛苦的场景。
项目经理需要的是一致的使用模型，团队改进的模式，以及支持采用新目标的度量模型。
G:
确保稳定性、可预测性的开发过程来满足计划的里程碑。
Q:
我的项目是否按照计划的轨迹前进，计划的里程碑都能实现吗？
M:
软件项目开发工作的挥发性（分支、流、统一变更管理（UCM）活动）。
项目经理的工作通过在项目的关键点上转化的成果和效率被度量。
在IBMRationalUnifiedProcess®（RUP®）中，项目经理敏锐的观察在精化向构建转化中发生的事情；用更传统的术语说，从设计到编码阶段。
当一个项目在计划的轨迹上时，项目开发活动的挥发性也在被度量，在项目计划期间，这种挥发性沿着计划的路径到达稳定的发布点。
如果项目背离了计划，这种不一致将会很容易被发现，这将告诉项目经理应用航向修正来确保项目回到应有的轨迹上。
G:
维护适当的人力分配以满足计划的里程碑
Q:
我的全球化团队适合我的项目吗？
这些团队成员能够高效的工作以实现项目目标吗？
M:
软件项目开发工作的挥发性（分支、流、统一变更管理（UCM）活动）。
为了满足项目的进度要求，项目经理必须维护开放和有效的在团队成员之间的沟通，理解合适人员需要进行调整。
这在一个小的团队可能是容易的，但对于个全球化分布的团队，就会比较难。
项目经理能够根据SCM系统评估每个个体、工作组的贡献，并决定现在的人员分配和任务分配是否合理。
这种评估理想情况下是根据项目计划和开发方法进行的（轻量级还是重量级）。
G:
在项目完成时，交付到生产环境的代码要满足组织的质量目标
Q:
开发的每个阶段的工作都符合这个目标吗？
M:
复杂度、语言规则遵循、编码指南。
通过监控这些因素，项目经理能够建立起在质量经理与项目经理之间的更有效的工作关系。
这种关系在开发过程中识别上游的质量问题是至关重要的。
这使得修改问题更加容易并且节省成本，以至于项目的整体质量符合生产环境的质量标准。
架构师
迭代开发方法典型地将架构师作为项目的开发点，辅助开发团队完成需求阶段，并进行早期的少量编码。
切记，这不仅仅对您的项目是事实，所有通常都是这样的。
对于架构师的需要是跨项目的，这就意味着对你给您的软对开发编码是，架构师可能在其他项目的启始阶段中忙碌着。
架构师所需要的是对所有项目的一些可视化的级别，以确保对整体目标的把握，以满足公司级别的目标。
如果每一个开发团队都指定自己的方向，那势必将造成混乱局面。
G:
当项目从精化阶段向构建阶段过渡时，确保架构构建被适当的应用。
Q:
项目团队的技术选择满足架构目标吗（组件化、面向服务的体系架构（SOA），框架，等等）?
M:
类型、复杂度的逻辑工作的量级
当项目从精化（设计）阶段过渡到构建（编码）阶段时，架构师就可以离开这个项目了，通常是因为他们被调到了其他项目中，或者其他的原因是现在是编码团队工作的时间了。
为了生成更加健壮和可维护的系统，可能会发生团队从架构原则中迷失了。
设计规则被忘记，接口被破坏，技术被随意使用。
通过检测在开发中产生的逻辑工件的数量级，架构师能够获得深度和准确的并开发人员使用的开发模式的情况，从而更好的控制和调整团队回到正确的道路上。
复杂度也能够生成对于设计和设计到代码的转换的效率的深度观察。
G:
确保组织使用了适当的技术。
Q:
什么样的开发技术正在被使用？
开发的实际成果与计划相符吗？
M:
生产环境中按类型划分的逻辑工件的量级和挥发性
公司采用他们认为最适合实现成功的在项的技术，这些技术将确保项目能够在人员和预算的范围内交付成功的系统。
通过检测与生产系统的逻辑矩阵，架构师能够决定是否应该作出决策。
例如，他也许想看看高端的开发方法产生了大量的代码，需要很多高级的开发专家，并且需要而外的团队进行维护。
通过参与基于实际情况的讨论，架构师能够帮助指导组织根据目标选择技术、动态语言、申明性语言、设计模式、框架和其他的构建，以帮助团队、执行管理层和经理们实现他们的目标。
开发经理
开发经理，或者开发主管，是艰苦的工作。
他们是有才能的，这意味着他们工作时间更长。
我所见过的所有的开发经理都表示出开发使开发团队完成工作的困难，同时他们需要管理由于在团队中的高频率加班所导致的组织级的低效，在离岸团队更是如此。
经验缺乏的初级开发人员需要与高级的开发人员配对工作来产生最大化的生产力。
因为初级的团队成员的进步，开发经理有更多的时间来改进他们负责的代码。
G:
最大化所有团队贡献者的生产力。
Q:
开发人员能够完成分配给他们的任务吗，或者他们遇到障碍了吗？
M:
由个体或者工作组产生的项目工件的量级
开发经理的一个最大的挑战是帮助开发人员克服障碍。
当人们在工作中遇到问题时，他们通常绝口不提，这通常是人的本性。
当然多数的开发人员不想让开发经理觉得他不能够完成分配的任务。
有时因为任务分配的不合理，开发人员也会延迟交付。
无论是什么原因导致的，很多人为的倾向将会影响开发人员的生产力，并影响项目的成功。
开发经理能够监控与任务分配和方法相关的开发人员的贡献－在候补区，或者不同的地方。
当开发人员在一个任务上遇到困难时，开发经理以积极和有建设性的方式进行干预，并帮助开发人员克服困难。
G:
为初级的开发人员建立导师机制
Q:
哪些开发人员需要在什么领域的帮助？
M:
复杂度、语言规则、编码指南
开发经理负责帮助初级开发人员找到资深的高级开发人员作为他的导师。
通过检测初级开发人员根据组织标准的工作，开发经理能够知道谁需要导师，需要哪方面的导师。
开发经理可以将有经验的高级开发人员与初级的开发人员进行配对工作，让初级开发人员学到更多的经验。
G:
通过对高风险的代码进行同行审查降低实现风险
Q:
什么样的模块最可能包含错误，尤其是那些在测试中难以发现的错误，或者最难理解和维护的错误？
M:
复杂度、语言规则、编码指南
同行审查是一个共享实现知识的强大的工具，它能够使系统代码更加强壮和可维护。
因为系统在范围和规模上不断的增长，这使得模块的审查也变得日益困难。
矩阵能够查明这些模块：
（a）测试没有覆盖到的模块，（b）容易出错的模块，（c）语言提供商导致的失败执行的模块，（d）花费大量时间去维护的模块。
软件质量经理
经过证明，GQA方法带来的一个好处是面向质量保证（QA）团队的。
作为软件开发生命周期中其他角色的伙伴，提高QA的效率，GQM将度量模型的权利放在了QA的手上。
GQM能够帮助质量成为每一个开发阶段的部分，不仅仅是在开发的末期。
QA人员理解这个，但开发人员和架构师通常不理解。
基于GQM的问题和答案能够引入新的构建以支持质量目标，带来更少的缺陷和更加流畅的开发过程。
G:
为QA报告维护一致的基线。
Q:
给定的发布有多大（输入以计算缺陷密度）？
M:
量级
。
更有见识的QA能够看出一个发布的规模，这将使缺陷密度变更更加有用。
规模典型地用代码行（LOC）表示；考虑使用代码行，因为代码行矩阵能够最好地表达真实地逻辑量级。
当使用代码行时，重要地是仅仅计算实现了逻辑那些工件。
对于不同的测试策略（例如，Java™对比JavaServerPages（JSP）），区别不同类型的工件是非常有用的。
其他的规模计算方法包括程序、声明和功能点数量。
G:
改进QA效率，并通过避免无保证的测试来节省成本
Q:
当前的开发与最初的测试一致吗?
M:
挥发性
测试软件是非常耗时和昂贵的，尤其是，当软件系统不断的扩大，复杂度不断增加。
挥发性帮助QA经理理解是否一个发布对于一个适当的测试的点来说是稳定的。
G:
在维护开发治理上成为开发的更有效的伙伴。
Q:
提交用于测试的发布符合被建立的开发标准吗？
M:
复杂度、语言规则、编码指南
QA在实现开发治理中扮演了一个完整的角色。
它是一个发布是否符合开发标准的最后一关。
QA在开发上的责任非常清楚，就是要将质量构建到软件系统中。
通过应用根据开发标准的“可信的，却又验证”模型，QA能够实现有价值和适当审计的功能。
结论
GQM可以作为无价的助手来帮助您在软件矩阵程序中迈出第一步。
无论对于治理、软件质量，或者过程改进，基于目标定义矩阵程序将确保您工作的价值，并使您迈出万里长征的第一步。
让我们通过澄清两个关键问题来结束本文。
GQM真的使自上而下的吗？
核心矩阵定义真的是自底向上的吗？
当公司尽力采用新事物时，通常都存在一定程度在组织级别上的抵触。
我们不想变更。
如果他们认为一些新的自上而下的管理模式被强制的推行到他们，一些人感到不安，甚至是惊讶。
Basili使用GQM的方法是授权个体和他们的同事，无论他们在组织的高层、底层或者中层。
我们所有人都有与我们的角色相关的目标。
了解过程和其他角色的目标将使我们从其他角色中学习到很多通用的东西。
15年前，JeffAlger发布了一个有用的分类，被称为“中心、外围和校准”。
其思想使通过关注熟悉的事情开始，然后从舒适区走出来，探索新的想法和概念，并且最终重新校准他们的观点。
迭代之上的迭代导致了世界视角的扩展。
使用GQM，我们基于我们的角色，或者中心，定义了目标。
我们每个人都基于我们的中心表达目标。
例如，开始时，我们也许分离的看待我们的目标，而不是从一个大的整体视角，就像图1显示的。
图1:
首先，团队角色是彼此孤立的
当GQM实践的进展，我们也了解到了其他的组织目标。
更加理解外围的问题，然后重新审视组织中我们周围的紧邻，如图2所示。
这些目标的结合展示了真正的组织目标，因此使用GQM方法从全局来考虑组织的目标是非常重要的。
图2:
理解外围问题，是角色之间更加紧密的细作
最后，过程既不是严格的自上而下的，也不是自底而上的，它们可以结合使用通过定义良好的标准来支持治理的目标。
考虑GQM在“Bestpracticesforleandevelopmentgovernance”中所陈述的实践：
迭代、采用和持续改进。
当注重实效的质量人员使用GQM来推动一个简单的矩阵程序时，可以非常有信心和有指导方向的走出关键的第一步。
注释
老子的谚语,道家
被LewisCarroll引用
的多句名言，参见ExperienceFactory（Basili和Rombach）athttp:
//cs.umd.edu/~basili/publications/technical/T86.pdf
"Developmentgovernanceforsoftwaremanagement:
UsingIBMRationaltoolstoassessprocessvariabilityandstandardscompliance"（Dunn）,RationalEdge,October2007。
"Bestpracticesforleandevelopment"（KrollandAmbler）,RationalEdge,June/July/August2007。
参考资料
参与论坛讨论。
您可以参阅本文在develperWorks全球网站上的英文原文。
现在开办了一个特别为RationalEdge的文章创办的新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。
阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。
单击这里开始。
全球Rational用户组社区
关于作者
RogerN.Dunn是SourceIQ公司（一个致力于交付来自于IBMRational基础架构的管理标准的高级IBM商业伙伴）的创立者和CEO。
他拥有二十五年的领导团队进行ISV和IT软件开发项目的经验。
希望以上资料对你有所帮助，附励志名言3条：
1、常自认为是福薄的人，任何不好的事情发生都合情合理，有这样平常心态，将会战胜很多困难。
2、君子之交淡如水，要有好脾气和仁义广结好缘，多结识良友，那是积蓄无形资产。
很多成功就是来源于无形资产。
3、一棵大树经过一场雨之后倒了下来，原来是根基短浅。
我们做任何事都要打好基础，才能坚固不倒。
升级会员 