使用GQM 实现治理目标

使用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基础架构中将此方法应用于您的开发过程的实际情况，并且开始度量！通过角色应用GQMGQM通常被认为是一个自上而下的方法，它建议执行管理层角色是我们的开始点。但是驱动者，或者潜在的驱动者，对于变化来说通常以项目为中心。这就意味着项目级的目标是非常理想的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:类型、复杂度的逻辑工作的量级当项目从精化（设计）阶段过渡到构建（编码）阶段时，架构师就可以离开这个项目了，通常是因为他们被调到了其他项