多么持久？
软件开发行业在不断地彻底改造自己，拆用老的思想和方法，并将它们转换为一些新的，不同的，且有希望更好一点的东西。这种流直接影响了可以设置的标准、可以施加的管理控制，以及可以实现的治理。
举例来说，许多组织热切地希望从动态语言，例如 Ruby 和 PHP 中获得好处。但是许多这些同样的组织不能接受伴随他们认为是“作家，发布”的开发过程的风险，该过程缺少伴随传统语言在编译和连接阶段的更结构化的检查点，以及关于那些步骤的工具。
有时候退回一步，评估优先权，并询问问题是有帮助的：什么是真正要紧的？在和许多开发组织一起分析了该问题之后，SourceIQ 得到了相当出乎意料的回答，它与我们在软件开发行业中看到的波动相关。
在我给出答案之前，让我们来看看事物是如何波动的。软件工具相当快速地波动，厂商每年发布主要的新更新，有时候甚至更快。程序设计语言波动的少一些，每七到十年主要变化一次。形成 KPI 的知识基础的软件量度波动的更缓慢，许多回溯到二十到三十年前。
但是从经验出发，我们已经发现了软件开发最持久的资产是组织生成的实际的源代码本身。一旦创建了，它可能就要经受看上去不停的维护。但是代码的夕阳看来很少到来。60 年代做主机 IT 开发的公司仍旧在原始的逻辑上运行核心系统。
需求、软件设计，甚至测试脚本与代码比较有相对短的预期寿命。虽然重要，但是它们似乎很快就过时了，失修或停用，并且报废了。但是代码不仅是耐用的，它甚至可以获得一再构建于系统中的隐匿的质量，即使很久以后，它不再被任何东西参考！
本讨论绝不是说拿开应该应用于需求定义、设计，和测试的精确和审查等级。如果有什么的话，来自这些规程的工件可能得益于像代码那样在长期过程中是完整的。
但是从纯实际的立场出发，代码的持久特性强调了开发治理计划的优先权。程序设计人员将来往于项目中。代码可能转移到不同的大陆上。它运行的平台将变更。办公大楼上的公司名称甚至可能变更，但是代码将以违背信念的方式持久下去。因此，管理层对项目的代码基数、起源和当前状态，及根据有意义的 KPI 的核心集合的评估了解的越多，团队将在调整代码基数以满足未来的需求方面得到更多的授权。
我如何开始？
如果您拥有 IBM Rational 基础架构，一个开发治理的需求，并且您正渴望开始一些管理 KPI，那么要做的第一件事情是开始询问一些问题。已经有什么标准了？缺少什么标准？标准的遵循对开发组织来说是优先的吗？如果您有外包或境外合伙人，那么您的标准是他们的服务等级协议的一部分吗？
如果治理将受到变更管理基础架构的促进，并且以变更管理基础架构为基础，那么您将想要标准使用模型。这些模式适当地处于或跨越项目和团队了吗？
另一组问题与管理 KPI 的受者相关。虽然量度没什么新的，但是一些人可能需要更新他们对 KPI 的理解，以及那些 KPI 与完成开发治理之间的相关性。构建一致并共享的理解的最佳方法是涉及所有受到开发治理影响的接受者：架构师、开发人员、质量保证分析人员、发布工程师，也许甚至有业务单位联络人。当人们开始讨论并彼此问问题时，他们开始与结果有利害关系了，并且取得了成功执行治理计划的所有权。
最后，治理是管理功能，反对不得不停在某处。谁负责治理？谁是有责任的？负责实施治理、按标准实现，并且评估法规遵循的人有权与工作功能的执行相适合吗？
随着标准开始成型，着重于将要在开发团队间共振的量度和 KPI 的小的核心集合，提供上级管理洞察，可以在短期内采用并理解。本文介绍了用大部分团队完成了该工作的一个集合。您的团队可能有其自己的复杂性，或者细微差异，并且可能需要不同的东西，但“less is more”的指导原则仍旧可用。
一旦您到达了最初的标准集，就是时候计划实现了。除非管理 KPI 对强制的法规遵循来说是完整的，否则它们需要一点提升来帮助它们获得牵引力。最好的方法是确保 KPI 向管理接受者提供价值，并且确保很快发现好处。一旦管理层开始使用过程 KPI 来通过过程和审计跟踪回顾来向前获得可溯性，并且当软件项目转移到运行时更低的维护成本，改进的健壮性的状态时，结果就实现了。
文章来源于领测软件测试网 https://www.ltesting.net/
