软件管理的开发治理

 行业发展，例如 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：治理三元组

原文转自：http://www.ltesting.net