| 软件管理的开发治理 |
|
文章来源：名易软件 行业发展，例如Agile，和目前向动态语言发展的趋势1，生成了维护对关键的开发过程的管理控制的新挑战。这混合了维护开发治理所需的已经成熟的功能集合2。ScottW.Ambler和PerKroll在最近的关于“Bestpracticesforleandevelopmentgovernance”3的三部分系列文章中应对了这些挑战，覆盖了组织要实现关于敏捷的开发计划的治理所需的概念：原则和组织、过程和度量，及角色和策略。 本文将延伸他们的讨论，分析管理层能够用于在这些变化的时代使 虽然本讨论延伸并详细说明了Ambler和Kroll最近的系列，但是不打算讨论Agile或者更“正规”的方法的优缺点。如果有，那么这些方法可以是从软件管理角度的补充，更确切地说，在这里，为治理而描述的KPI一般可以应用于软件开发过程。 治理不仅仅是管理 AlbertEinstein曾经说过“只有我们指向概念所谈到的对象4，以及将概念分配给这些对象所依据的规则时，概念才有意义。”在这个精神下，我想要定义一组涉及与治理相关的管理角色和职责的公共的术语。通过这样做，我希望避免疏忽地将“治理”和“管理”，以及“管理层”和“经理”之间的混淆。 开发治理是管理的职责，但是管理的职责远远超过治理。管理的角色是使团队了解关于团队计划、项目状态和轨道，以及问题识别和解决的及时切准确的信息。从治理的角度看，这转化为确保遵循组织的治理计划，理想的情况下，按照以理想且强制的方式促进对团队的计划的形式。 管理通常服务于两种人：团队和客户。管理对团队运作的关注可以被认为是对内的，监督管理负责的人员和运作。对此添加了一组对外的职责：与上级和商业对手的 实现与一个或其它这几类人之间的成功是困难的工作，在为团队和客户提供充足支持的时候，平衡二者的需求确实令人畏缩。对于这些人，管理还必须增加将治理计划加入交付和执行的挑战。 区分“管理层”和“经理”会更复杂。软件行业已经长期应用在组织图中将“经理”放在“程序设计人员”和“软件质量保证分析人员”之上的层次。 最近的趋势混淆了这些区别。什么是经理？一个定义是，不仅负责软件项目执行的某个方面，而且还负责项目的成功的结果，并拥有与实现此结果相适合的权威的人。以前这意味着 这是一个健康的征兆，软件开发团体正拥抱着从使团队具有及时的信息以及在他们的任务中取胜所需的过程洞察的其他规程中得来的经验。对于个别开发人员和质量保证分析人员来说，经验是相当清楚的：在您的名片上可能不是“经理”，但是您可能是开发管理中关键的部分。 治理三元组 随着软件行业的成熟，术语“治理”、“法规遵循”和“ * *法规遵循（Compliance）是根据标准对工作产品和过程的评估。 *治理（Governance）是施加管理控制来加强支持法规遵循的实践，并校正未遵循法规的实践的行为。 通过分开梳理这三个术语，并且给每个术语一个具体的范围和含义，我们能够从图1中获得静态的表示，并且使之运转，如图2中所示。当看起来像动态过程时，很清晰的是，治理三元组的每个组件都供给另一个组件，告知遵循标准的管理和执行的接收者，以便采取适当的行动。 期望的结果是为了促进组织的成熟，达到操作效率的增加的层次，以及创建可以使内部和外部 缺少了法规遵循报告，该循环就打破了。大量无效地实施管理，并且项目目标和 要使得这个动态的过程工作，法规遵循报告是必要的，令管理层可以对开发过程进行观察。当团队用标准来评估法规遵循时，他们复得了管理罗盘，并能够带着实现所期望的结果的更大信心来绘制前进的航向。他们获得了评估管理工作的影响的能力，以便可以考察二者的 关键的性能指示器 一些非常聪明的人——从LordKelvin到W.EdwardsDeming到PhilipB.Crosby——以这样的想法为生，一个人不可能管理不能度量的东西，过程KPI是当今他们的学说的应用。 某些开发标准，例如可证实的结束和检查点，可以是法规和审计遵循的需求。对这些标准的遵循证明了团队的完整性，以及管理变更和负责地执行的能力。但它可能没有确实地对团队生产力或者软件工作产品的可度量的质量的增加做出贡献。 KPIs一般分为两类：过程和工作产品。过程KPIs允许管理层处理开发过程中的可变性，以便可以理解、管理，并最终容纳此变化的根本原因和伴随的风险。这个评估过程是正在进行的管理活动，并且有利于完成并维护可预测的，可重复的过程。 考虑相对于 过程KPI的细节与过程本身相关，并且为此，必须稍微了解开发方法、实践和规程。然而，过程拥有跨方法边界应用的某些一般的特征。也许您拥有带有强组件倾向的软件工厂，或者也许您对服务于业务单元部门的开发竖井垂直地分层。也许您正使用瀑布开发方法，或者您已经采用Agile。不论您为开发设置的什么过程，该过程拥有离散的过程。这些过程有希望由 过程KPI 过程KPI基于上面介绍的一般特征，并且分为两个部分：易变率和容积。 过程KPI的接受者一般是那些负责了解并优化过程的人，以及负责随着时间监控趋势，产生了关于过程遵循（非遵循）的洞察8。从开发治理立场上讲，过程KPI对管理程序设计活动的人来说更有效且可诉，对负责质量保证的人来说没那么有效且可诉。若是真的，那么一般的理由是质量保证没察觉自己会影响开发方法，或者命令对它的变更，这是功能规程的传统分离，“12尺的砖墙是用程序设计人员和QA之间的剃刀线盖成的”在行业中仍旧普遍。在较进步的开发文化中，开发人员和质量保证合伙人更积极地参与测试方法和法规遵循，建立对要应用的标准的一致同意，并且用过程KPI实现更多结果。然而，不论是传统的或是进步的，对易变率和容积的理解是评估软件项目的基础。 易变率KPI 随着过程从开始到结束，它经受着特定量的易变率。易变率度量着完成目标过程中波动的数量和比率。易变率一般有两种度量方式：预计的和实际的。预计的易变率表明了完成任务、里程碑，或项目中所出现的总波动的估计量，然而实际的易变率度量了实际出现的波动。从管理的立场出发，易变率是熟悉的概念，与同样包含了“预算对实际”的概念的项目计划实践相关联。 当管理层了解了预计的对实际的易变率时，就能够评估与计划的差异，并且设法控制正要脱离控制的项目。从根本上，这是个治理问题：评估对标准的遵循——预计的项目易变率曲线——从而使管理层适当地使团队完成成功的项目成果。如果您想要完成标准的，可预测的过程，那么就致力于那些过程的易变率的评估和管理。这对软件维护活动尤其正确，它们经常比新的开发更容易地遵循已建立的模式。 易变率的一个杰出的量度是单位时间的总变更，以及该量度随着时间的趋势的整体评估。有各种各样的方法来度量总变更：代码行（linesofcode，LOC），修正、确定的故障、感到满意的增强请求，等等。团队应该在安排一个或其它的方法之前，讨论相对于他们的手段和方法的这些选择，并且应该随着他们能力的提高，以及 容积KPI 容积KPI说明了在开发中生成的逻辑或其它相关工件的总量。在一些组织中，逻辑的容积可能有关联性的想法已经引起争论，有时候会受到某种程度的怀疑，甚至轻视。然而，“容积”的基本思想对三种软件开发规程来说是重要的：项目预测、质量保证，和程序设计。 影响维护成本的重要因素是正被讨论的代码基数的大小。一般确实是比起较小的代码基数，大型的代码基数要用更多的人来维护制度上的 这种KPI可以为项目预测增加好处，因为它允许软件 容积还对质量保证很重要，由于软件产品的大小是缺陷密度比率的分母。随着时间观察容积的趋势，显示出了关于缺陷密度的一些细小区别，并且帮助加强对这种KPI的洞察。举例来说，在质量保证有机会发现并进入与新代码有关的缺陷之前，产品的容积可能在一小段时间内快速扩展，这将产生表面上减少缺陷密度的影响，因此掩饰了一个事实，实际的情况可能需要增加测试脚本或测试自动化来 程序设计人员易于对容积有相当本能的反应，但是一般看不到代码基数大小的整体变更趋势，例如，趋势可能是耗时的，并且很难得到并看出。但程序设计人员的内脏检查非常有意义，并且直入问题的心脏。程序设计人员知道什么时候他们将处理肿胀的代码，并且意识到——经常强烈地——对项目的负面影响。在这种情况下，就像缺陷密度是程序设计效率的追溯的量度一样，程序设计人员可能直观地将容积应用于软件设计的效率的追溯的量度。当程序设计人员看到时，容积的快速，未预期的增长是糟糕设计的暗示。它们揭示了一米宽一寸深的，不鼓励可测性或可维护性，以及一般会破坏设计雅致的技术栈。 容积的典型量度包括LOC、SLOC、ELOC、语句、分号、方法数、类数和文件数。行业一般支持一种或另一种LOC作为大小的指示，如根据每LOC的缺陷计算的几乎不变的缺陷密度所示。 因为一些人将容积认为是引起争议的量度，有时候组织陷入争论，什么容积量度是“最好的”。在一定程度上，如果您根本没有度量容积，那么详述此争论就没有意义。几乎没有什么软件量度是伟大的，但是许多（像LOC）是好的，重要的是增强管理的治理能力，以及团队对他们工作的重要维度的可见性，KPI可以并将随着时间改进。 通常，推荐在同样的基础上评估易变率和容积。如果您根据LOC中的随时间变更的总量度量易变率，那么您会希望也根据LOC中随时间的净变更度量容积。 工作产品KPI 有许多可以用于评估软件工作产品（不论是组件、子系统、服务，或应用程序）的质量和完整性的工具。这些工具的选择和使用形成了组织治理计划的主要部分。 通常，这些工具向静态（源代码）或动态（运行时）环境应用一组规则。当引入治理计划时，违反规则的行为一般都确定为对项目 当引起管理层的注意时，来自这些工具的输出就成为了工作产品KPI。关于这些工具的问题是，他们是被设计用来由个别开发人员使用的，还是在运行时环境中（在该环境中按照不规律的频率执行评估，并且结果不保留）使用的。为了参与治理计划，这通常意味着将工具和一致的框架相集成，进行分析和报告。 承认了厂商，例如SourceIQ已经跨接了工具和管理报告之间的间隔，让我们来分析可以快速并积极影响开发治理的工作产品KPI：编码规则、语言规则，和复杂性。 编码规则 组织出于最佳的理由采用编码规则。按照公共的规则开发的代码在团队成员之间更易接受和维护，更容易在大型组织中分享，并且在维护中更节约成本，特别是当转给不是原始工作一部分的团队时。 不幸的是，经常出现的情况是，团队中的个人随着时间有选择的应用并侵蚀这些规则。在没有工作产品KPI的情况下，在管理层无意识的情况下，出现了代码基数的退化。因此，当新的团队成员艰难地符合速度时，同行审查难以达到不可行的程度，或者维护成本上升，根本原因是对试图修正问题的管理层不可见。 思想上的重要转变出现于 语言规则 语言规则类似于编码规则，但是一般来自于开发组织之外，而不是从内部。举例来说，SunMicrosystems发布了一组 随着工具，例如这些工具并入治理计划，在今天的行业中，软件工具正经历快速的变更和演进是毫无意义的。 复杂性 上面提到的工作产品评估一般是性质上的，复杂性分析形成了强大工作产品KPI的基础。甚至超过编码规则，复杂性分析是在您的系统中确定最有 从IBMRational?工具中获得KPI 组织根据表示为KPI的 这可能类似于一点小跳跃，但让我们抛开某个历史的包袱。一些人将Rational套件视为工具的集合：开发人员使用IBMRationalClearCase?，质量保证团队使用IBMRationalClearQuest?，等等。但是Rational基础架构远不止一组工具。它是一组集成工具，包含了关于关键开发过程的事实和事务的宝藏，并且可以对于根据标准的法规遵循报告进行挖掘和分析。 Rational基础架构是获得有效治理所需的管理KPI，以及确保前面提到的动态治理三元组仍旧完整，有快速的响应，并且跨团队（不论是本国的、境外的，或全球分布的）有效，的基础。有了统一变更管理（UnifiedChangeManagement，UCM），该基础架构甚至更强大，而其洞察力甚至更集中。 |