软件管理的开发治理

申请免费试用、咨询电话：400-8352-114

    行业发展，例如 Agile，和目前向动态语言发展的趋势 1 ，生成了维护对关键的开发过程的管理控制的新挑战。这混合了维护开发治理所需的已经成熟的功能集合 2 。Scott W. Ambler 和 Per Kroll 在最近的关于“Best practices for lean development governance” 3 的三部分系列文章中应对了这些挑战，覆盖了组织要实现关于敏捷的开发计划的治理所需的概念：原则和组织、过程和度量，及角色和策略。

    本文将延伸他们的讨论，分析管理层能够用于在这些变化的时代使团队工作的具体量度的最佳实践，以及通过应用这些实践，如何利用 IBM? Rational? 基础架构来促进被赠与的利益。我专注于这些最佳实践的子集，详细说明管理层可以用于计划和支持开发治理的方法和指南。焦点在于源自 Rational 基础架构的，洞察并发挥关于开发过程的管理控制的关键性能指示器（key performance indicators，KPIs）。

    虽然本讨论延伸并详细说明了 Ambler 和 Kroll 最近的系列，但是不打算讨论 Agile 或者更“正规”的方法的优缺点。如果有，那么这些方法可以是从软件管理角度的补充，更确切地说，在这里，为治理而描述的 KPI 一般可以应用于软件开发过程。

    治理不仅仅是管理

    Albert Einstein 曾经说过“只有我们指向概念所谈到的对象 4 ，以及将概念分配给这些对象所依据的规则时，概念才有意义。”在这个精神下，我想要定义一组涉及与治理相关的管理角色和职责的公共的术语。通过这样做，我希望避免疏忽地将“治理”和“管理”，以及“管理层”和“经理”之间的混淆。

    开发治理是管理的职责，但是管理的职责远远超过治理。管理的角色是使团队了解关于团队计划、项目状态和轨道，以及问题识别和解决的及时切准确的信息。从治理的角度看，这转化为确保遵循组织的治理计划，理想的情况下，按照以理想且强制的方式促进对团队的计划的形式。

    管理通常服务于两种人：团队和客户。管理对团队运作的关注可以被认为是对内的，监督管理负责的人员和运作。对此添加了一组对外的职责：与上级和商业对手的沟通、资源分配和计划、预算，及预测。

    实现与一个或其它这几类人之间的成功是困难的工作，在为团队和客户提供充足支持的时候，平衡二者的需求确实令人畏缩。对于这些人，管理还必须增加将治理计划加入交付和执行的挑战。

    区分“管理层”和“经理”会更复杂。软件行业已经长期应用在组织图中将“经理”放在“程序设计人员”和“软件质量保证分析人员”之上的层次。

    最近的趋势混淆了这些区别。什么是经理？一个定义是，不仅负责软件项目执行的某个方面，而且还负责项目的成功的结果，并拥有与实现此结果相适合的权威的人。以前这意味着项目经理、开发经理、QA 经理、发布工程经理，等等。但在现今的环境中，并随着运动，例如 Agile 的促进，执行和结果之间的连接不断地直接向开发人员、质量保证分析人员，和其它知识分子扩展。

    这是一个健康的征兆，软件开发团体正拥抱着从使团队具有及时的信息以及在他们的任务中取胜所需的过程洞察的其他规程中得来的经验。对于个别开发人员和质量保证分析人员来说，经验是相当清楚的：在您的名片上可能不是“经理”，但是您可能是开发管理中关键的部分。

    治理三元组

    随着软件行业的成熟，术语“治理”、“法规遵循”和“标准”正日益承担显著的角色。这些术语有具体的力量和含义，但只有在软件开发过程中所有受到影响的部分都很好地理解了这种力量和含义时，它们才是有用的。为了将这些术语概念化，要建立基本的框架，就考虑图 1 中显示的栈。

图 1：治理三元组

自底向上考虑图 1 中的术语：

    * 标准（Standards）是度量工作产品和过程所依据的基准。开发组织一般都拥有标准，尽管它们的表达是正式或非正式的。规章的需求还可能需要标准和标准运作过程。

    * 法规遵循（Compliance）是根据标准对工作产品和过程的评估。

    * 治理（Governance）是施加管理控制来加强支持法规遵循的实践，并校正未遵循法规的实践的行为。

    通过分开梳理这三个术语，并且给每个术语一个具体的范围和含义，我们能够从图 1 中获得静态的表示，并且使之运转，如图 2 中所示。当看起来像动态过程时，很清晰的是，治理三元组的每个组件都供给另一个组件，告知遵循标准的管理和执行的接收者，以便采取适当的行动。

图 2：治理三元组的每个组件都供给另一个组件

    期望的结果是为了促进组织的成熟，达到操作效率的增加的层次，以及创建可以使内部和外部审计人员审查的标准化的，可预测的过程。

    牢记我在前面部分中提到的对结果的强调，通过支持对标准的遵循，以及纠正非法规遵循，在治理中加入“支配”，并实施适当的控制是管理的工作。

    缺少了法规遵循报告，该循环就打破了。大量无效地实施管理，并且项目目标和团队的成功受到危害。标准失去了他们的生命力和上下文，因缺乏熟悉或故意地避免，团队忽视了标准。当管理试图实施控制时，有时候团队会将工作视为幼稚，或甚至反复无常的，并且没有机制来评估影响是好的，坏的，或无关紧要的。就像古老的谚语说的那样，如果您不知道打算去哪里，那么什么方向都行。

    要使得这个动态的过程工作，法规遵循报告是必要的，令管理层可以对开发过程进行观察。当团队用标准来评估法规遵循时，他们复得了管理罗盘，并能够带着实现所期望的结果的更大信心来绘制前进的航向。他们获得了评估管理工作的影响的能力，以便可以考察二者的风险和好处。他们从那种混乱，英雄驱动的团队，动态经历 Capability Maturity Model? Integration (CMMI) 6 成熟度级别为 1 的组织，转到成熟度级别为 3 及更高 7 的更稳定，可预测，基于标准的结果。

    关键的性能指示器

    一些非常聪明的人 —— 从 Lord Kelvin 到 W. Edwards Deming 到 Philip B. Crosby —— 以这样的想法为生，一个人不可能管理不能度量的东西，过程 KPI 是当今他们的学说的应用。

    某些开发标准，例如可证实的结束和检查点，可以是法规和审计遵循的需求。对这些标准的遵循证明了团队的完整性，以及管理变更和负责地执行的能力。但它可能没有确实地对团队生产力或者软件工作产品的可度量的质量的增加做出贡献。

因此，在不减少更面向程序的审计标准的重要性或必要性的情况下，让我们考虑团队可以用来本质上增强开发过程的项目标准。总的来说，这些标准作为 KPI，在实现团队的结果。

    KPIs 一般分为两类：过程和工作产品。过程 KPIs 允许管理层处理开发过程中的可变性，以便可以理解、管理，并最终容纳此变化的根本原因和伴随的风险。这个评估过程是正在进行的管理活动，并且有利于完成并维护可预测的，可重复的过程。

考虑相对于 CMMI，展开与开发过程相关的标准范围，并且令管理层注意到提升对这些标准的遵循的关联性和可见性，是从成熟度级别为 2 的“受管理的过程”转化到 成熟度级别为 3 的“定义的过程”的关键成分。随着转化为分别与 成熟度级别为 4 和 5 相关联的“数量上的管理”和“最佳化”状态，过程 KPIs 增加了关联性和效用。

    过程 KPI 的细节与过程本身相关，并且为此，必须稍微了解开发方法、实践和规程。然而，过程拥有跨方法边界应用的某些一般的特征。也许您拥有带有强组件倾向的软件工厂，或者也许您对服务于业务单元部门的开发竖井垂直地分层。也许您正使用瀑布开发方法，或者您已经采用 Agile。不论您为开发设置的什么过程，该过程拥有离散的过程。这些过程有希望由团队很好地定义，并且广泛地了解，但是甚至是成熟度级别为 1 的组织都在勉强追求过程。此外，过程拥有确定定义的特征。它们拥有输入、输出，和检查点，否则将其置于一个 CTO 的更多彩的语言中，它们会有“gazintas、gazoutas，和 ga-whaaaaat”?

    过程 KPI

    过程 KPI 基于上面介绍的一般特征，并且分为两个部分：易变率和容积。

    过程 KPI 的接受者一般是那些负责了解并优化过程的人，以及负责随着时间监控趋势，产生了关于过程遵循（非遵循）的洞察 8 。从开发治理立场上讲，过程 KPI 对管理程序设计活动的人来说更有效且可诉，对负责质量保证的人来说没那么有效且可诉。若是真的，那么一般的理由是质量保证没察觉自己会影响开发方法，或者命令对它的变更，这是功能规程的传统分离，“12 尺的砖墙是用程序设计人员和 QA 之间的剃刀线盖成的”在行业中仍旧普遍。在较进步的开发文化中，开发人员和质量保证合伙人更积极地参与测试方法和法规遵循，建立对要应用的标准的一致同意，并且用过程 KPI 实现更多结果。然而，不论是传统的或是进步的，对易变率和容积的理解是评估软件项目的基础。

    易变率 KPI

    随着过程从开始到结束，它经受着特定量的易变率。易变率度量着完成目标过程中波动的数量和比率。易变率一般有两种度量方式：预计的和实际的。预计的易变率表明了完成任务、里程碑，或项目中所出现的总波动的估计量，然而实际的易变率度量了实际出现的波动。从管理的立场出发，易变率是熟悉的概念，与同样包含了“预算对实际”的概念的项目计划实践相关联。

    当管理层了解了预计的对实际的易变率时，就能够评估与计划的差异，并且设法控制正要脱离控制的项目。从根本上，这是个治理问题：评估对标准的遵循 —— 预计的项目易变率曲线 —— 从而使管理层适当地使团队完成成功的项目成果。如果您想要完成标准的，可预测的过程，那么就致力于那些过程的易变率的评估和管理。这对软件维护活动尤其正确，它们经常比新的开发更容易地遵循已建立的模式。

    易变率的一个杰出的量度是单位时间的总变更，以及该量度随着时间的趋势的整体评估。有各种各样的方法来度量总变更：代码行（lines of code，LOC），修正、确定的故障、感到满意的增强请求，等等。团队应该在安排一个或其它的方法之前，讨论相对于他们的手段和方法的这些选择，并且应该随着他们能力的提高，以及新技术和方法的可用，虚心地演进该量度。作为起始点，对跨项目阶段的单位时间内变更的总 LOC 的简单度量将绘制出项目的轨道，并展示出项目是否达到了与成功地在完成日期着陆相适合的“下滑轨道”。甚至成熟的开发组织都经常会发现，在对易变率 KPI 的首次观察中，他们的过程遭受着偷偷通过同行审查，以及质量保证审查的未预期且未报告的“迟的破坏（late-breaking）”变更，或者发现他们的过程包含与期望的 Agile 方法相反的潜伏期和延迟时间。

    容积 KPI

    容积 KPI 说明了在开发中生成的逻辑或其它相关工件的总量。在一些组织中，逻辑的容积可能有关联性的想法已经引起争论，有时候会受到某种程度的怀疑，甚至轻视。然而，“容积”的基本思想对三种软件开发规程来说是重要的：项目预测、质量保证，和程序设计。

    影响维护成本的重要因素是正被讨论的代码基数的大小。一般确实是比起较小的代码基数，大型的代码基数要用更多的人来维护制度上的存储并且保持最新。人们可能争论维护工作是否与代码基数的大小线性相关，而事实上对此问题的回答可能是因素的功能，包括软件设计方法、组件化的程度、资源技能水平、集中对分布的团队，以及外包或境外人员的使用。然而，对于您的管理层要明确维护团队的大小和组成与团队所维护的项目的大小和组成之间的关联的最好方法是开始度量并应用容积 KPI。

这种 KPI 可以为项目预测增加好处，因为它允许软件团队来沟通，概括地说，响应客户需求的团队的效率和生产力、增加请求，和软件缺陷。在依据软件开发的客户投资的模型的环境中，例如许多公司的 IT 部门，容积 KPI 可以作为有价值的可视化工具在同样的页面上从字面上加入软件团队及其业务单元副本。

    容积还对质量保证很重要，由于软件产品的大小是缺陷密度比率的分母。随着时间观察容积的趋势，显示出了关于缺陷密度的一些细小区别，并且帮助加强对这种 KPI 的洞察。举例来说，在质量保证有机会发现并进入与新代码有关的缺陷之前，产品的容积可能在一小段时间内快速扩展，这将产生表面上减少缺陷密度的影响，因此掩饰了一个事实，实际的情况可能需要增加测试脚本或测试自动化来审计新的代码。类似的情况出现在当重构代码，将代码基数分为更谨慎地合理的程序或组件集合的时候。当整体代码大小下降时，缺陷密度上升，看起来好像整体的质量水平更糟糕了，既使代码基数已经转移到改进的可维护性和较多的代码覆盖的地方。通过监控容积 KPI，以及缺陷密度，质量保证可以观察这些重要的趋势，从而计划。

    程序设计人员易于对容积有相当本能的反应，但是一般看不到代码基数大小的整体变更趋势，例如，趋势可能是耗时的，并且很难得到并看出。但程序设计人员的内脏检查非常有意义，并且直入问题的心脏。程序设计人员知道什么时候他们将处理肿胀的代码，并且意识到 —— 经常强烈地 —— 对项目的负面影响。在这种情况下，就像缺陷密度是程序设计效率的追溯的量度一样，程序设计人员可能直观地将容积应用于软件设计的效率的追溯的量度。当程序设计人员看到时，容积的快速，未预期的增长是糟糕设计的暗示。它们揭示了一米宽一寸深的，不鼓励可测性或可维护性，以及一般会破坏设计雅致的技术栈。

    容积的典型量度包括 LOC、SLOC、ELOC、语句、分号、方法数、类数和文件数。行业一般支持一种或另一种 LOC 作为大小的指示，如根据每 LOC 的缺陷计算的几乎不变的缺陷密度所示。

    因为一些人将容积认为是引起争议的量度，有时候组织陷入争论，什么容积量度是“最好的”。在一定程度上，如果您根本没有度量容积，那么详述此争论就没有意义。几乎没有什么软件量度是伟大的，但是许多（像 LOC）是好的，重要的是增强管理的治理能力，以及团队对他们工作的重要维度的可见性，KPI 可以并将随着时间改进。

    通常，推荐在同样的基础上评估易变率和容积。如果您根据 LOC 中的随时间变更的总量度量易变率，那么您会希望也根据 LOC 中随时间的净变更度量容积。

    工作产品 KPI

    有许多可以用于评估软件工作产品（不论是组件、子系统、服务，或应用程序）的质量和完整性的工具。这些工具的选择和使用形成了组织治理计划的主要部分。

    通常，这些工具向静态（源代码）或动态（运行时）环境应用一组规则。当引入治理计划时，违反规则的行为一般都确定为对项目标准的违规行为。乍一看，这可能听起来有点苛刻，在缺少对一线希望的偏移的情况下过分强调负面。但是存在一个实际的理由：测试违规行为相对容易，但是不同于缺少违规行为，测试遵循要难得多。这个治理主题有时候会引起争论，含糊地听起来有哲学的，像“好的仅仅是缺少邪恶吗？”虽然对其的回答有一点困难，但是肯定的是工具可以找出确实邪恶的安全性漏洞、复杂的代码，和性能瓶颈。

    当引起管理层的注意时，来自这些工具的输出就成为了工作产品 KPI。关于这些工具的问题是，他们是被设计用来由个别开发人员使用的，还是在运行时环境中（在该环境中按照不规律的频率执行评估，并且结果不保留）使用的。为了参与治理计划，这通常意味着将工具和一致的框架相集成，进行分析和报告。

    承认了厂商，例如 SourceIQ 已经跨接了工具和管理报告之间的间隔，让我们来分析可以快速并积极影响开发治理的工作产品 KPI： 编码规则、语言规则，和复杂性。

    编码规则

    组织出于最佳的理由采用编码规则。按照公共的规则开发的代码在团队成员之间更易接受和维护，更容易在大型组织中分享，并且在维护中更节约成本，特别是当转给不是原始工作一部分的团队时。

    不幸的是，经常出现的情况是，团队中的个人随着时间有选择的应用并侵蚀这些规则。在没有工作产品 KPI 的情况下，在管理层无意识的情况下，出现了代码基数的退化。因此，当新的团队成员艰难地符合速度时，同行审查难以达到不可行的程度，或者维护成本上升，根本原因是对试图修正问题的管理层不可见。

思想上的重要转变出现于团队成员看出了他们对同事的职责，并且加入了另每个人的工作更简单的编码规则。有许多可以用于自定义组织的特殊编码规则的工具和脚本。当这些工具加入到治理环境中时，管理层就能够在增加的法规遵循方向上轻推开发组织。在途中，可能有一些挫折，但它是健康的事情，因为它可以进一步改善规则。累积影响倾向于非常积极，团队成员能够共享代码，在团队中调试，并且概括地了解彼此的工作。

    语言规则

    语言规则类似于编码规则，但是一般来自于开发组织之外，而不是从内部。举例来说，Sun Microsystems 发布了一组 Java 语言 9 的编码约定。商业和开源工具可以自动地根据语言厂商的规则评估代码，一般使用令调整规则使其满足开发治理计划的需求很容易，的规则引擎和语法检查。在某些情况下，语言厂商的规则相当良好，并且可能只影响到代码的表示或维护的某个小方面。然而，在其他情况下，代码中违反规则的表现可以是一个红色的标记，即使编译器让其通过，在运行时也会严重地出错。

    随着工具，例如这些工具并入治理计划，在今天的行业中，软件工具正经历快速的变更和演进是毫无意义的。IBM? 最近收购了 Watchfire，强调了可以查明安全弱点的工具之间的成熟度，并且考虑与开发目标和审查需求相关的这类工作产品 KPI 的关系对您来说是有意义的。重要的事情是保持行业趋势的优势，并且消息灵通。

    复杂性

    上面提到的工作产品评估一般是性质上的，复杂性分析形成了强大工作产品 KPI 的基础。甚至超过编码规则，复杂性分析是在您的系统中确定最有风险的，更容易出错的，最困难且维护成本最高的代码的基础。许多组织没有成功地利用这一关键量度，因为它被认为是，对已经有负担的开发团队来说是太花费时间或太困难了。但是随着源自管理量度的自动化系统的到来，例如 SourceIQ，管理层现在可以将复杂性作为至关重要的维度加入到开发治理计划中。

    从 IBM Rational ? 工具中获得 KPI

    组织根据表示为 KPI 的标准评估，利用他们的 Rational 基础架构实现与那些标准相关的真正的法规遵循报告。

这可能类似于一点小跳跃，但让我们抛开某个历史的包袱。一些人将 Rational 套件视为工具的集合：开发人员使用 IBM Rational ClearCase?，质量保证团队使用 IBM Rational ClearQuest?，等等。但是 Rational 基础架构远不止一组工具。它是一组集成工具，包含了关于关键开发过程的事实和事务的宝藏，并且可以对于根据标准的法规遵循报告进行挖掘和分析。

    Rational 基础架构是获得有效治理所需的管理 KPI，以及确保前面提到的动态治理三元组仍旧完整，有快速的响应，并且跨团队（不论是本国的、境外的，或全球分布的）有效，的基础。有了统一变更管理（Unified Change Management，UCM），该基础架构甚至更强大，而其洞察力甚至更集中。

    Rational 套件的三个成员提供了您需要的所有基础：ClearQuest、ClearCase 和 IBM Rational Build Forge?。

ClearQuest 提供关于评估过程 KPI（允许对开发过程的端点的治理）所需的增强的请求和缺陷的事实和事务的编年存储库：输入的请求和输出的审查。很明显存在 ClearQuest 的替代方案，但是它拥有关于 UCM 的特别优势，如下所述。

    ClearCase 是编年的存储库，可以从其中获得不同时间的过程和工作产品的状态。有了 UCM，ClearCase 增加了治理价值，发现了用于许多外部审计所需的变更的永不改变的存储库的想法。下一个部分中将探究该存储库的非凡价值，读者当然要熟悉关于 ClearCase 的配置选项，例如 UCM 和多站点 10 。

    ClearQuest 启用的 UCM 是向开发治理计划授权牵引力的理想配置。不论您的开发方法是 Agile 或是瀑布的，这个技术减少了将开发过程标准化的困难，并且提供通过变更顺序、编码，和测试表示变更的事务的至关重要的环境。

虽然 ClearQuest 和 ClearCase 提供了数据和环境，但是 Build Forge 是自动地生成法规遵循报告的工具。由于许多组织每晚构建或连续的集成，这解决了法规遵循报告频率和周期性的问题，并且令管理者更敏感地处理违规行为的情况。

  多么持久？

    软件开发行业在不断地彻底改造自己，拆用老的思想和方法，并将它们转换为一些新的，不同的，且有希望更好一点的东西。这种流直接影响了可以设置的标准、可以施加的管理控制，以及可以实现的治理。

    举例来说，许多组织热切地希望从动态语言，例如 Ruby 和 PHP 中获得好处。但是许多这些同样的组织不能接受伴随他们认为是“作家，发布”的开发过程的风险，该过程缺少伴随传统语言在编译和连接阶段的更结构化的检查点，以及关于那些步骤的工具。

    有时候退回一步，评估优先权，并询问问题是有帮助的：什么是真正要紧的？在和许多开发组织一起分析了该问题之后，SourceIQ 得到了相当出乎意料的回答，它与我们在软件开发行业中看到的波动相关。

    在我给出答案之前，让我们来看看事物是如何波动的。软件工具相当快速地波动，厂商每年发布主要的新更新，有时候甚至更快。程序设计语言波动的少一些，每七到十年主要变化一次。形成 KPI 的知识基础的软件量度波动的更缓慢，许多回溯到二十到三十年前。

    但是从经验出发，我们已经发现了软件开发最持久的资产是组织生成的实际的源代码本身。一旦创建了，它可能就要经受看上去不停的维护。但是代码的夕阳看来很少到来。60 年代做主机 IT 开发的公司仍旧在原始的逻辑上运行核心系统。

    需求、软件设计，甚至测试脚本与代码比较有相对短的预期寿命。虽然重要，但是它们似乎很快就过时了，失修或停用，并且报废了。但是代码不仅是耐用的，它甚至可以获得一再构建于系统中的隐匿的质量，即使很久以后，它不再被任何东西参考！

    本讨论绝不是说拿开应该应用于需求定义、设计，和测试的精确和审查等级。如果有什么的话，来自这些规程的工件可能得益于像代码那样在长期过程中是完整的。

    但是从纯实际的立场出发，代码的持久特性强调了开发治理计划的优先权。程序设计人员将来往于项目中。代码可能转移到不同的大陆上。它运行的平台将变更。办公大楼上的公司名称甚至可能变更，但是代码将以违背信念的方式持久下去。因此，管理层对项目的代码基数、起源和当前状态，及根据有意义的 KPI 的核心集合的评估了解的越多，团队将在调整代码基数以满足未来的需求方面得到更多的授权。

    我如何开始？

    如果您拥有 IBM Rational 基础架构，一个开发治理的需求，并且您正渴望开始一些管理 KPI，那么要做的第一件事情是开始询问一些问题。已经有什么标准了？缺少什么标准？标准的遵循对开发组织来说是优先的吗？如果您有外包或境外合伙人，那么您的标准是他们的服务等级协议的一部分吗？

    如果治理将受到变更管理基础架构的促进，并且以变更管理基础架构为基础，那么您将想要标准使用模型。这些模式适当地处于或跨越项目和团队了吗？

    另一组问题与管理 KPI 的受者相关。虽然量度没什么新的，但是一些人可能需要更新他们对 KPI 的理解，以及那些 KPI 与完成开发治理之间的相关性。构建一致并共享的理解的最佳方法是涉及所有受到开发治理影响的接受者：架构师、开发人员、质量保证分析人员、发布工程师，也许甚至有业务单位联络人。当人们开始讨论并彼此问问题时，他们开始与结果有利害关系了，并且取得了成功执行治理计划的所有权。

    最后，治理是管理功能，反对不得不停在某处。谁负责治理？谁是有责任的？负责实施治理、按标准实现，并且评估法规遵循的人有权与工作功能的执行相适合吗？

    随着标准开始成型，着重于将要在开发团队间共振的量度和 KPI 的小的核心集合，提供上级管理洞察，可以在短期内采用并理解。本文介绍了用大部分团队完成了该工作的一个集合。您的团队可能有其自己的复杂性，或者细微差异，并且可能需要不同的东西，但“less is more”的指导原则仍旧可用。

    一旦您到达了最初的标准集，就是时候计划实现了。除非管理 KPI 对强制的法规遵循来说是完整的，否则它们需要一点提升来帮助它们获得牵引力。最好的方法是确保 KPI 向管理接受者提供价值，并且确保很快发现好处。一旦管理层开始使用过程 KPI 来通过过程和审计跟踪回顾来向前获得可溯性，并且当软件项目转移到运行时更低的维护成本，改进的健壮性的状态时，结果就实现了。

在项目接着项目，或者团队并团队的基础上进行实现。尝试项目和代码一致的企业跨度的计划的组织倾向于不超越他们自己的官僚权力，并且因此在工作中受挫。通过向先遣团队授权来强调项目的成功的更精益的方法更可能产生热情和成功，并且增加了培育开发人员的好处，他们会将所学到的有价值的经验传到下一个项目中。

    最后，记住利用您的 Rational 基础架构。管理 KPI 通常不出自于开发者 IDE 或者在书架上接尘土的工具。它们出自于坚固的基础架构组件，像 Rational，这些组件安全，可以进行外部的详细审计，并且给出一致的答案。

    注释

1. 要了解更多关于动态语言的信息，请参见 The Rational Edge 的 2007 年 6、7，和 8 月刊中 Gary Pollice 的文章。

2. 参见 Scott Ambler 在 Dr. Dobb's Journal 的 11 月刊中的治理专栏，看看关于 Agile 方法如何为治理提供更大的机会的讨论。

3. Scott W. Ambler 和 Per Kroll 的“Best practices for lean development governance”出自 2007 年 6、7，和 8 月出版的 The Rational Edge 系列。

4. “Obituary for Ernst Mach”，1916 年 3 月 14 日，Collected Papers of Albert Einstein（CPAE），6:26。

5. 举例来说：Total Quality Management（TQM），就像由 International Organization for Standardization（ISO）定义的一样，在制造业、政府，和服务行业中广泛使用，ISO 16949（Quality Management Systems: Automotive）。

6. Carnegie Mellon、Capability Maturity Model、CMM，和 CMMI 是由卡内基梅隆大学在 U.S. Patent and Trademark Office 注册的。在本文中，对于 CMM 的参考一般理解为为开发应用 CMMI，版本 1.2，由卡内基梅隆的 Software Engineering Institute 于 2006 年 8 月公布。

7. CMMI 用于能力等级特征的环境中。也许值得注意的是，作者同意其他人（Hillel Glazer、Mike Konrad、James Over），Agile 和 CMMI 不是对立的方法。

8. 要采用 Gary Pollice （“Does Process Matter?” The Rational Edge，2006 年 8 月）的工作，本讨论的重点更倾向于企业过程而不是团队过程，但适用于他介绍的微过程下的该光谱。

9. http://java.sun.com/docs/codeconv/

10. Software Configuration Management Strategies and IBM Rational ClearCase: A Practical Introduction（2nd Edition），作者 David E. Bellagio 和 Tom J. Milligan，是用于标准化 ClearCase 的使用并获得开发治理中最大利益的，用于了解和构建的有价值的指导。(csai)