Rational Edge:精益开发治理的最佳实践

【IT168技术文档】IT 治理计划的目标是建立责任、权力和沟通链，授权人们支持全面的企业目标和策略。您通过平衡 IT 投资中的风险和回报、设立有效的过程和实践、为部门确定方向和目标，并且确定人们在部门中扮演的角色来进行上面的工作。开发治理是 IT 治理的重要子集，它的范围包括软件和系统开发项目的控制。

    传统的治理常常集中在争取用明确的方式管理并指导开发项目团队的命令及控制策略。虽然在某些情况下，传统的治理是有效的策略，但是对于许多组织来说，此方法类似于群养小猫 —— 您将在治理工作上投入许多精力，但在实际中收获甚微。精益治理着重于不明显地激励团队成员的协作策略。举例来说，传统的制定编码指南的方法是创建它们，并且通过形式化的检查来实施。精益的方法是与您的程序设计人员协作的制定指南，说明为什么采用指南是重要的，并且提供工具和支持，使得那些指南的遵循对开发人员是尽可能简单的。这种精益治理的方法类似于leading（引导）小猫，如果您抓住一片生鱼，那么小猫将会跟随您到任何您想去的地方。

  本文阐述我们推荐的治理现代软件开发工作的方法。我们出于许多原因而介绍此方法：

1. 我们在使用现有的 IT 治理方法时的经验 —— 例如，Control Objectives for Information-Related Technology（CobiT）和项目管理协会（Project Management Institute，PMI）的 Organizational Project Management Maturity Model（OPM-3）—— 是，这些传统的方法对于许多组织来说，在实践中常常太繁重了，虽然这些方法提供了很多建议。
2. 越来越多的项目团队在使用软件开发的敏捷方法， ¹ 并且这些项目团队必须得到有效的治理。
3. 我们相信许多非敏捷的团队可以得益于本文中介绍的更协作的方法。
4. 我们相信那些已经采用上面列出的传统框架，或类似的框架的组织，仍旧可以得益于对它们的治理开发项目的方法的“松绑”。

介绍最佳实践

    图 1 分类并例举了精益治理的实践之间的关系，表 1 以字母表的顺序对每个关系进行概括。（本系列的 3 篇文章将详细探究每一种实践。）

图 1：精益软件开发治理的实践。

表 1. 精益开发治理实践的概述，此处按字母表罗列。

实践	描述
使过程适应团队	由于团队在大小、分布、目标、关键性、监督的需求，以及成员技能上各有不同，所以一个过程大小不能适用所有的。您必须裁减过程，使之满足团队的确切需求。此外，必须估计过程并让过程随时间演进，从而满足您的组织的不断变更的需求。
结合 HR 政策和 IT 价值	与非技术人员相比，雇佣、保留，和提升技术人员需要不同的策略。 您需要建立适合您的技术人员的智慧的具体激励/奖励，从而确保及时的交付，以及其他关键的成就，例如，关于新技术的再培训。
结合团队结构和架构	您的项目团队的组织应该反应出正在构建的将团队活动流水化的预期系统架构的结构。举例来说，分布的团队非常适合构建分区的架构，而集中的团队常常熟练于构建集中的架构。
业务驱动的项目规划	您应该投资那些很好地结合了商业方向、回报可确定的价值，并且与企业的优先次序相匹配的项目。该方法暗指较少地关注“冷技术”，而更多地关注业务的支持。
持续的改进	您应该争取在项目过程中，而不是最后，确定并遵循您了解到的经验性活动。举例来说，在每次迭代末尾的快速回顾及在关键里程碑的更详细的回顾是随项目的进展而进行改进的直接了当的方法。
持续的项目监控	度量的自动收集使您能监控项目，并因此识别出潜在的问题，以便您可以与项目团队密切协作，从而更早地解决问题。您还将在最初需要辨别出要收集的度量的最小集合。
内嵌的法规遵循	最好是将法规遵循构建在日常的过程中，替代经常导致不必要的支出的单独的法规遵循过程。自动化是关键的。
灵活的架构	面向服务的、基于组件的，或面向对象的，并且实现了通用的架构上的和设计模式的架构有助于更高层次的一致性、复用、增强性，和适用性。
集成的生命周期环境	您应该争取尽可能多地将“重体力工作”自动化 —— 例如度量收集和系统构建。在整个生命周期中，您的工具和过程应该有效的配合。项目开始时，创立工具集的初始投资可以在整个项目中的削减的工作中赢得重大的利益。
迭代的开发	软件交付的迭代方法允许软件组件的逐步开发和发布，同时减少整个的失败风险，并且提供用最少的重复工作的损失时间来进行细微调整和修正的能力。
实干的治理团体	有效的治理团体专注于以节省成本且及时的方式运行开发团队。它们一般有小部分核心职员，以及来自受治理组织的大部分成员代表。
基于风险的里程碑	您希望在生命周期的早期减少项目的风险，特别是商业和技术风险。您通过将整个项目划分为团队为之努力的若干里程碑来达到此目的。每个里程碑的目标是处理一个或多个风险，例如，Rational Unified Process（RUP）中的 Lifecycle Architecture（LCA）里程碑，它要求在构建开始之前通过工作代码证明您的架构。
场景驱动的开发	在不了解局部的情况下，不能确定整体，而在不了解整体的情况下，不能详细确定局部。通过采用场景驱动的方法，您可以了解人们如何实际地使用系统，从而令您构建满足他们实际需要的东西。
自组织的团队	计划工作的最佳人选是自己去做的人。IT 专业人员应该被看作是可以决定他们自己的工作策略的有才能的人。当接受了一些训练和指导之后，他们就可以在已确定的范围内，例如迭代边界，计划他们的工作。
简单且相关联的度量	您应该尽可能地将度量的收集自动化，将所收集的度量的数量最小化，并且知道您为什么收集它们。
阶段性的计划交付	作为相关项目集合的计划（Program），应该随时间增量地进行。取代阻止发布来等待子项目，每个个别的子项目必须签订预先确定的发布日期。如果错过了子项目，就跳到下一个版本，把对计划的客户的影响最小化。
有价值的 IT 资产	指南，例如编程指南或数据库设计惯例，和可复用的资产，例如框架和组件，如果察觉它们是对开发人员增加价值的，那么就采用。您希望让开发人员尽可能容易地遵循，并且更重要的是利用您团队的 IT 基础架构。

    本文余下的部分将介绍 a) 实干的治理团体的使命和原则，以及阶段性的计划交付，和 b) 涉及业务驱动的项目管道和场景驱动的开发的组织和会议。（本系列文章的第 2 和第 3 部分将介绍上面提到的余下的最佳实践。）

    对于提出的每种最佳实践，讨论它的益处、所涉及的权衡（也就是，为了维持该实践的运作，必须满足组织中的什么需求）、反模式（也就是，与该实践相反的是什么行为，以及什么行为会威胁到它的实现或打消它的好处），和默认推荐（也就是，为了在组织中建立该实践所要采取的最少步骤）。

使命和原则

    此类中的实践提供了明确的方向和基础原则来鼓励正确的行为。这些实践是：

• 实干的治理团体
• 阶段性的计划交付

实干的治理团体

    治理计划不会自己运行，而是由称为治理团体的小组来执行。治理团体组织和管理自身的方式是您的治理计划的总的效率的关键的决定因素。实干的治理团体着重于首先让 IT 专业人员能够工作，其次控制和管理他们。它通过以下方式来进行：

• 创造人们可以有效工作的环境。
• 促进具体情况的策略、程序，和实践。
• 向团队提供他们所需的资源，包括与商业项目涉众。
• 向背离预期标准的团队提供指导、支持，和顾问咨询。

好处

    该实践有两个主要的好处：

1. 它促进有效治理的展开。如果您将组织的治理计划制定得令 IT 团队很容易且令人期望，那么 IT 团队将更可能遵守。
2. 它令治理是可实施的。治理只是一个架子，除非人们逐步执行并在组织中实施过程和政策来帮助组织达到其目标。

权衡

    有许多与该实践相关的权衡：

• 需要对商家的支持。您的治理计划必须反映商家的需求。要确保这一点，商业项目涉众必须积极参与治理团体。实干的治理团体不能只由 IT 人员组成。
• 需要持续的投资。治理团体必须得到充分投资，而且由于治理是典型的长期责任，所以有需要一直投资。
• 将控制留给执行团体。虽然实干的治理团体着重于团队的运作，但是他们仍旧有责任指导团队并确保他们在允许的标准内运行。

反模式

    以下反模式与治理团体相关：

• 为了治理而治理。也称为“官僚胡作非为”，这种治理团体着重于确保开发团队在适当的时间生成适当的文档。此方法不能让商业更好地运作。
• 通过治理来控制。这是着重于控制和指导开发团队，而不是使他们运作的治理团体。您知道的，当治理团队花费大量时间编制让团队遵守的发令、程序，和/或政策时，会出现这种情况。

推荐的默认做法

    创建小型的中心团队，常常称为治理权限中心，它拥有对 IT 和适当的商业单位的虚线回报结构。

1