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