治理不仅仅是管理
Albert Einstein 曾经说过“只有我们指向概念所谈到的对象，以及将概念分配给这些对象所依据的规则时，概念才有意义。”在这个精神下，我想要定义一组涉及与治理相关的管理角色和职责的公共的术语。通过这样做，我希望避免疏忽地将“治理”和“管理”，以及“管理层”和“经理”之间的混淆。
开发治理是管理的职责，但是管理的职责远远超过治理。管理的角色是使团队了解关于团队计划、项目状态和轨道，以及问题识别和解决的及时切准确的信息。从治理的角度看，这转化为确保遵循组织的治理计划，理想的情况下，按照以理想且强制的方式促进对团队的计划的形式。
管理通常服务于两种人：团队和客户。管理对团队运作的关注可以被认为是对内的，监督管理负责的人员和运作。对此添加了一组对外的职责：与上级和商业对手的沟通、资源分配和计划、预算，及预测。
实现与一个或其它这几类人之间的成功是困难的工作，在为团队和客户提供充足支持的时候，平衡二者的需求确实令人畏缩。对于这些人，管理还必须增加将治理计划加入交付和执行的挑战。
区分“管理层”和“经理”会更复杂。软件行业已经长期应用在组织图中将“经理”放在“程序设计人员”和“软件质量保证分析人员”之上的层次。
最近的趋势混淆了这些区别。什么是经理?一个定义是，不仅负责软件项目执行的某个方面，而且还负责项目的成功的结果，并拥有与实现此结果相适合的权威的人。以前这意味着项目经理、开发经理、QA 经理、发布工程经理，等等。但在现今的环境中，并随着运动，例如 Agile 的促进，执行和结果之间的连接不断地直接向开发人员、质量保证分析人员，和其它知识分子扩展。
这是一个健康的征兆，软件开发团体正拥抱着从使团队具有及时的信息以及在他们的任务中取胜所需的过程洞察的其他规程中得来的经验 5 。对于个别开发人员和质量保证分析人员来说，经验是相当清楚的：在您的名片上可能不是“经理”，但是您可能是开发管理中关键的部分。
治理三元组
随着软件行业的成熟，术语“治理”、“法规遵循”和“标准”正日益承担显著的角色。这些术语有具体的力量和含义，但只有在软件开发过程中所有受到影响的部分都很好地理解了这种力量和含义时，它们才是有用的。为了将这些术语概念化，要建立基本的框架，就考虑图 1 中显示的栈。
图 1：治理三元组
自底向上考虑图 1 中的术语：
通过分开梳理这三个术语，并且给每个术语一个具体的范围和含义，我们能够从图 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 方法相反的潜伏期和延迟时间。
关注此文的读者还看过：
