内容
- 介绍最佳实践
- 使命和原则
- 组织和会议
- 即将到来的下个月...
- 注释
IT 治理计划的目标是建立责任、权力和沟通链，授权人们支持全面的企业目标和策略。您通过平衡 IT 投资中的风险和回报、设立有效的过程和实践、为部门确定方向和目标，并且确定人们在部门中扮演的角色来进行上面的工作。开发治理是
IT 治理的重要子集，它的范围包括软件和系统开发项目的控制。这个由 3 部分组成的系列文章的重点是支持精益开发治理的实践。
传统的治理常常集中在争取用明确的方式管理并指导开发项目团队的命令及控制策略。虽然在某些情况下，传统的治理是有效的策略，但是对于许多组织来说，此方法类似于群养小猫
—— 您将在治理工作上投入许多精力，但在实际中收获甚微。精益治理着重于不明显地激励团队成员的协作策略。举例来说，传统的制定编码指南的方法是创建它们，并且通过形式化的检查来实施。精益的方法是与您的程序设计人员协作的制定指南，说明为什么采用指南是重要的，并且提供工具和支持，使得那些指南的遵循对开发人员是尽可能简单的。这种精益治理的方法类似于leading（引导）小猫，如果您抓住一片生鱼，那么小猫将会跟随您到任何您想去的地方。
本文是将要阐述我们推荐的治理现代软件开发工作的方法的系列的 3 篇文章中的第 1 篇。我们出于许多原因而介绍此方法：
1.我们在使用现有的 IT 治理方法时的经验 —— 例如，Control Objectives for
Information-Related Technology（CobiT）和项目管理协会（Project
Management Institute，PMI）的 Organizational Project Management
Maturity Model（OPM-3）—— 是，这些传统的方法对于许多组织来说，在实践中常常太繁重了，虽然这些方法提供了很多建议。
2.越来越多的项目团队在使用软件开发的敏捷方法， 1 并且这些项目团队必须得到有效的治理。
3.我们相信许多非敏捷的团队可以得益于本文中介绍的更协作的方法。
4.我们相信那些已经采用上面列出的传统框架，或类似的框架的组织，仍旧可以得益于对它们的治理开发项目的方法的“松绑”。
第 1 篇文章的第 1 部分，将介绍精益治理的使命和原则，以及一个个项目的成功所需的组织和项目涉众的协作。第
2 和第 3 部分将分别介绍过程及度量，角色/职责，和政策/标准。
介绍最佳实践
图 1 分类并例举了精益治理的实践之间的关系，表 1 以字母表的顺序对每个关系进行概括。（本系列的 3
篇文章将详细探究每一种实践。）
图 1：精益软件开发治理的实践。
表 1. 精益开发治理实践的概述，此处按字母表罗列。
|
实践 |
描述 |
|
使过程适应团队 |
由于团队在大小、分布、目标、关键性、监督的需求，以及成员技能上各有不同，所以一个过程大小不能适用所有的。您必须裁减过程，使之满足团队的确切需求。此外，必须估计过程并让过程随时间演进，从而满足您的组织的不断变更的需求。 |
|
结合 HR 政策和 IT 价值 |
与非技术人员相比，雇佣、保留，和提升技术人员需要不同的策略。 您需要建立适合您的技术人员的智慧的具体激励/奖励，从而确保及时的交付，以及其他关键的成就，例如，关于新技术的再培训。 |
|
结合团队结构和架构 |
您的项目团队的组织应该反应出正在构建的将团队活动流水化的预期系统架构的结构。举例来说，分布的团队非常适合构建分区的架构，而集中的团队常常熟练于构建集中的架构。 |
|
业务驱动的项目规划 |
您应该投资那些很好地结合了商业方向、回报可确定的价值，并且与企业的优先次序相匹配的项目。该方法暗指较少地关注“冷技术”，而更多地关注业务的支持。 |
|
持续的改进 |
您应该争取在项目过程中，而不是最后，确定并遵循您了解到的经验性活动。举例来说，在每次迭代末尾的快速回顾及在关键里程碑的更详细的回顾是随项目的进展而进行改进的直接了当的方法。 |
|
持续的项目监控 |
度量的自动收集使您能监控项目，并因此识别出潜在的问题，以便您可以与项目团队密切协作，从而更早地解决问题。您还将在最初需要辨别出要收集的度量的最小集合。 |
|
内嵌的法规遵循 |
最好是将法规遵循构建在日常的过程中，替代经常导致不必要的支出的单独的法规遵循过程。自动化是关键的。 |
|
灵活的架构 |
面向服务的、基于组件的，或面向对象的，并且实现了通用的架构上的和设计模式的架构有助于更高层次的一致性、复用、增强性，和适用性。 |
|
集成的生命周期环境 |
您应该争取尽可能多地将“重体力工作”自动化 —— 例如度量收集和系统构建。在整个生命周期中，您的工具和过程应该有效的配合。项目开始时，创立工具集的初始投资可以在整个项目中的削减的工作中赢得重大的利益。 |
|
迭代的开发 |
软件交付的迭代方法允许软件组件的逐步开发和发布，同时减少整个的失败风险，并且提供用最少的重复工作的损失时间来进行细微调整和修正的能力。 |
|
实干的治理团体 |
有效的治理团体专注于以节省成本且及时的方式运行开发团队。它们一般有小部分核心职员，以及来自受治理组织的大部分成员代表。 |
|
基于风险的里程碑 |
您希望在生命周期的早期减少项目的风险，特别是商业和技术风险。您通过将整个项目划分为团队为之努力的若干里程碑来达到此目的。每个里程碑的目标是处理一个或多个风险，例如，Rational
Unified Process（RUP）中的 Lifecycle Architecture（LCA）里程碑，它要求在构建开始之前通过工作代码证明您的架构。 |
|
场景驱动的开发 |
在不了解局部的情况下，不能确定整体，而在不了解整体的情况下，不能详细确定局部。通过采用场景驱动的方法，您可以了解人们如何实际地使用系统，从而令您构建满足他们实际需要的东西。 |
|
自组织的团队 |
计划工作的最佳人选是自己去做的人。IT 专业人员应该被看作是可以决定他们自己的工作策略的有才能的人。当接受了一些训练和指导之后，他们就可以在已确定的范围内，例如迭代边界，计划他们的工作。 |
|
简单且相关联的度量 |
您应该尽可能地将度量的收集自动化，将所收集的度量的数量最小化，并且知道您为什么收集它们。 |
|
阶段性的计划交付 |
作为相关项目集合的计划（Program），应该随时间增量地进行。取代阻止发布来等待子项目，每个个别的子项目必须签订预先确定的发布日期。如果错过了子项目，就跳到下一个版本，把对计划的客户的影响最小化。 |
|
有价值的 IT 资产 |
指南，例如编程指南或数据库设计惯例，和可复用的资产，例如框架和组件，如果察觉它们是对开发人员增加价值的，那么就采用。您希望让开发人员尽可能容易地遵循，并且更重要的是利用您团队的
IT 基础架构。 |
本文余下的部分将介绍 a) 实干的治理团体的使命和原则，以及阶段性的计划交付，和
b) 涉及业务驱动的项目管道和场景驱动的开发的组织和会议。（本系列文章的第 2 和第 3 部分将介绍上面提到的余下的最佳实践。）
对于提出的每种最佳实践，讨论它的益处、所涉及的权衡（也就是，为了维持该实践的运作，必须满足组织中的什么需求）、反模式（也就是，与该实践相反的是什么行为，以及什么行为会威胁到它的实现或打消它的好处），和默认推荐（也就是，为了在组织中建立该实践所要采取的最少步骤）。
使命和原则
此类中的实践提供了明确的方向和基础原则来鼓励正确的行为。这些实践是：
实干的治理团体
治理计划不会自己运行，而是由称为治理团体的小组来执行。治理团体组织和管理自身的方式是您的治理计划的总的效率的关键的决定因素。实干的治理团体着重于首先让
IT 专业人员能够工作，其次控制和管理他们。它通过以下方式来进行：
- 创造人们可以有效工作的环境。
- 促进具体情况的策略、程序，和实践。
- 向团队提供他们所需的资源，包括与商业项目涉众。
- 向背离预期标准的团队提供指导、支持，和顾问咨询。
好处
该实践有两个主要的好处：
- 它促进有效治理的展开。如果您将组织的治理计划制定得令 IT 团队很容易且令人期望，那么 IT 团队将更可能遵守
- 它令治理是可实施的。治理只是一个架子，除非人们逐步执行并在组织中实施过程和政策来帮助组织达到其目标。
权衡
有许多与该实践相关的权衡
- 需要对商家的支持。您的治理计划必须反映商家的需求。要确保这一点，商业项目涉众必须积极参与治理团体。实干的治理团体不能只由
IT 人员组成。
- 需要持续的投资。治理团体必须得到充分投资，而且由于治理是典型的长期责任，所以有需要一直投资。
- 将控制留给执行团体。虽然实干的治理团体着重于团队的运作，但是他们仍旧有责任指导团队并确保他们在允许的标准内运行。
反模式
以下反模式与治理团体相关：
- 为了治理而治理。也称为“官僚胡作非为”，这种治理团体着重于确保开发团队在适当的时间生成适当的文档。此方法不能让商业更好地运作。
- 通过治理来控制。这是着重于控制和指导开发团队，而不是使他们运作的治理团体。您知道的，当治理团队花费大量时间编制让团队遵守的发令、程序，和/或政策时，会出现这种情况
推荐的默认做
创建小型的中心团队，常常称为治理权限中心，它拥有对 IT 和适当的商业单位的虚线回报结构
阶段性的计划交付
平均的 IT 项目越来越小。平均较小的项目会有更成功的项目成果， 2 参见图 1，并且证明是更有生产力的。与此同时，综合的商业过程需要复杂度不断增加的
IT 系统集合的支持。这意味着交付主要的商业价值需要以公共使命为中心的一组项目的协同执行，并且经常需要资源、技术、架构，和时间线的协调。这通过计划管理来完成
有效的计划管理向商家交付增量的价值，它知道如何筹备/安排计划，以便计划中所有项目的子集围绕一组核心的商业目标而协同工作。这一般需要将较大的目标分为子目标，将项目映射为根据这些子目标进行交付。计划将推动相关的项目集合的资源分配和管理，尽可能早地交付相关的商业目标或子目标，这叫做阶段的计划交付，如图
2 所示。
图 2：阶段的计划交付意思是将计划中的项目分成小组，这样每个项目小组可以尽可能早地交付增量的价值。本图摘自
Kurt Bittner 和 Ian Spence 的书籍 Managing Iterative Software
Development Projects，Addison-Wesley Professional：2006
年。
一旦定义了计划阶段，就通过控制项目对该阶段中的项目进行管理，和通常的 RUP 项目有同样的阶段，如图
3 所示。
控制项目管理集成，并且提供集中于风险和变化的减少的管理里程碑。通过对所有项目的总的评估来评估控制项目。然而，要评估整体计划的风险预测，您不能简单地将每个项目的风险预测汇集起来，您还需要确保与跨项目集成相关的风险已经得到了处理。在提供计划中个别项目的执行的灵活性的同时，控制项目的用途是让计划协同执行。在此，迭代扮演了基础的角色，因为它们提供了稳定的参照点，从而令计划中的项目可以跨项目集成，并且证实有意义。
图 3. 通过控制项目管理计划阶段，通过这个方式可以有效地管理风险的减少和价值的生成。该图摘自
Kurt Bittner 和 Ian Spence 的书籍 Managing Iterative Software
Development Projects，Addison-Wesley Professional：2006
年。
好处
阶段的计划交付，特别是在利用控制项目时，提供许多好处：
- 着重于商业目标上的有效执行。通过根据商业目标将项目分组，并且将它们作为计划进行管理，我们可以根据主要的商业目标更有效地交付。
- 许多相关部分的协同发布。通过一组着重于风险和变化的减少，以及价值生成的里程碑，控制项目向我们提供定义明确的计划的治理里程碑。
- 增加的价值的交付。将潜在的非常大的计划进行划分可以围绕商业子目标增量地交付价值。通过用迭代的开发技术来管理计划中的项目，可以按照需要部署演进的能力。
- 提高的效率。项目的半独立的执行令各种项目中的有效开发能够进行，因为它提供尽可能多的策略上的灵活性，因而实现了更高的生产力。然而，我们需要可视的控制点来进行个别的项目表现和总体的计划的评估。可以在每个迭代的末尾，利用基于事实的评估来对个别项目的表现进行评估，假设这些项目使用了迭代的开发。
权衡
对于有效的阶段的计划交付有两个重要的权衡
- 增加协调。执行计划需要协调，这需要资源和知识。
- 延迟的风险。当没有管理好时，计划可能会导致进行最慢的项目来决定发布。在最坏的情况下，这会导致大部分项目团队等待公司的“更大好处”，但事实是这常常是对公司有害的。技巧是进行充分的监督，当给定的项目不能继续时重新确定您的计划范围，这样您仍旧可以在早期交付一些商业价值。
反模式
以下的反模式与通过商业价值管理项目管道相关：
- Slowest drum beat（最慢的打鼓声）。计划中最慢的项目决定整个工作的速度。有效的计划被看作是一列火车
—— 火车在特定时间离开车站，而不论上面有没有项目。
推荐的默认做法
我们推荐由控制项目管理的较小的计划根据 RUP 的四个阶段运行，其中有松散耦合的个别项目，每个都依据
RUP 的迭代方法。
组织和会议
此分类中的实践指导确定适当的组织结构和形式的报告机制，以和正确的项目涉众关注正确的层次。这些实践是：
业务驱动的项目规划
IT 项目的需求总是大于可用的资源，这迫使我们在管道中对潜在的项目排列优先次序，并且优化所选的项目，以结合我们的策略。一个好的治理解决方案应该将开发投资的商业价值最大化，并且确保与商业目标的战略上的结合，而我们需要一种完成这件事的机制。可以利用计分卡和其他项目组合管理策略来有效地实现，其中根据一组反映出战略结合及商业价值的确定的参数来评估每个项目。
应该注意的是，计分卡是商业价值的模型，而所有模型都有它们的局限性。这意味着您可能有时候发现分数较低的项目应该比分数较高的项目优先，迫使手工进行阻止，但还是在这种情况下，计分卡促使关于策略和商业价值的讨论，展现出为什么该模型在一些少有的情况下是不完美的。
好处
通过商业价值管理项目管道带来以下好处：
- 聚集在商业价值之上。管道管理促使组织商定商业策略，以及什么参数推动最大的商业价值。举例来说，考虑这些问题：您的
IT 组织应该将新的商业机会的支持、正在进行的商业过程的成本效率的提高，或更快速的组织成长划分优先级吗？这些问题促使围绕集中于战略结合及商业价值的项目的资金投入的讨论。
- 提高 ROI。选择最佳地混合了风险、价值回报和策略结合的项目，推动更高的整体
ROI。计分卡还为整个 IT 部分结合策略，并最大化商业价值提供强大的沟通和动力机制。如果您想让您的项目得到投资，那么您需要确保它很好地结合了对于商家最重要的东西。
- 提高透明度。在许多组织中，投资决策如何制定是一个迷。依据商业价值的管道管理可以以开放且透明的方式进行，这样提高了可见性，并建立了信任。
权衡
当根据商业价值管理项目管道时要考虑的权衡包括
- 策略及价值清晰度。管道管理迫使您确定推动投资的内容应该是什么。这很难，并且迫使您通过“大胆地摸索”来确定您的策略“需要是”什么，将要是什么。
- 放弃控制。过程更加客观且开放，并且要求每个项目都能联系它的商业价值。这可能不会要求每个人，特别是那些安于现状的人。
- 频率。管道管理需要在常规的基础上进行，例如每周或每月，以便不延迟项目。这需要实质的投资来使工作有效。
反模式
以下反模式与项目管道的管理相关联
- 主观的项目得分。如果项目选择成为主观的，且每个项目都不同，并且如果决策不是可追溯或可防御的，那么您就有一个工作得很糟糕得计分过程。（也许您的计分卡很难用，要求太多的主观性，或者在没有恰当的监督和透明性的情况下完成计分。）
- 实施的计分卡。我们已经看到过许多这样的情况，计分卡在书面上效果不错，但在实际中，它们优先考虑了错误的项目。过分强调问题，以至于“受宠的项目”排在顶部，或者仅仅错过对项目计分以获得您期望的政治上的回答，由于上述原因造成了这种情况。您需要校准您的计分卡，直到它正确为止。
- 项目组合负担。如果管理管道的过程是非常墨守陈规的，并且/或者增加了重大的项目计划的延时，那么计分的值可能不会促成障碍。
推荐的默认做法
我们推荐您关注的计分卡中参数要少于五个，并且推荐您将计分作为关于优先化的商业讨论的辅助，而不是严格的度量
Scenario-Driven Development（场景驱动的开发）
在通过控制项目的阶段性计划交付实践之下，我们讨论了，综合的商业过程需要不断复杂的 IT 系统集合的支持，以及较小的项目比较大的项目更有效且有更高的成功率。我们可以将分为一组较小部件的
IT 系统看成一个系统，其中每个部件都被开发成其自身的一个系统，如图 4 所示。这种配置称为“复合系统”，其中各个部件是由个别项目开发的个别的应用程序。
在不了解局部的情况下，不能确定整体，而在不了解整体的情况下，不能确定局部。风险是我们不了解局部如何影响整个解决方案，而且我们将陷入构建不能结合在一起的局部。因此我们需要应用一种能让我们将整体和局部紧密地结合在一起的技术。我们通过在所有层次上应用用例来实现这一点?/p>
- 通过用例场景来确定并不断使用需求 —— 也就是，展示局部需要如何协作来完成全系统的用例。
- 以同样的方式确定并不断使用架构和接口。
- 用例场景还推动系统级集成和测试场景，并确保局部交付整个系统中关键的端到端的用例。
图 4：在复合系统中，部件是由个别项目开发的个别的应用程序。
如今，我们在 IBM 软件集团中非常成功地应用了该技术。我们通过数百个团队来开发数百个应用程序，而客户同时使用许多我们的产品。在过去的几年里，我们为了那个推动局部更好地集成的整体解决方案，越来越关注端到端的业务场景（有时候称为未成熟的思路）。我们已经发现这使我们将资源优先化，这样这些资源为我们的客户增加最大的价值?/p>
好处
使用复合系统思考的场景驱动的开发带来了许多好处：
- 关注商业能力的交付。它让每个项目都着重于它们的部分是如何向组织交付商业价值。
- 许多可动部分之间的更好的集成。它让开发不同应用程序的项目着重于应用程序之间的良好集成。关注集成是至关重要的，因为商业价值主要是通过端到端的业务场景进行交付，而不是由它们自己通过个别的部分进行交付。
- 提供控制机制。控制机制确保团队交付商业价值。此外，这种基于场景的方法帮助消除能力间的差距，并且可以确定不一致性和缺少进展的区域。
权衡
有两个与场景驱动开发相关的重要权衡
- 商业和技术视角。此实践需要总体的商业和技术视野，而并非所有组织都处于可以提供该视野的足够的成熟度水平上。
- 企业级协调。此实践基于协调不同部分的开发的能力，而并非所有组织都有拥有在这么大规模中进行协调的能力。
反模式
以下反模式与场景驱动的开发相关联
- 个人的视角。商业场景只从人脑中不精确地获取，而从不分享或编制文档。端到端的商业场景从不联接，因此决不要根据它们进行交付
- IT 驱动的业务。虽然 IT 的角色是支持业务，但在此反模式中反过来了。当没有确定商业过程或没有使用商业过程来推动增量的
IT 能力时，就会发生这种事。
- 象牙塔式的商业模型。开发了商业过程，但 IT 项目没有有效地利用它们来推动增量的
IT 能力。
- 竖井式的项目。每个项目都尽力交付商业价值，但端到端的商业过程之间没有联接，项目之间没有协调。
推荐的默认做
获取关键的商业过程，并用它们来推动并协调 IT 投资。
注释
1.Scott Ambler 在 2007 年 3 月为 Dr. Dobb's Journal（www.ddj.com）进行了
Agile Adoption Survey，69％ 的被调查者所在的组织已经采用了一种或多种敏捷技术，另外有
7％ 的人觉得他们所在的组织会在一年内采用。DDJ 2007 年 8 月刊上介绍该调查。
2.Standish Group 的 Chaos Report v 3（2003）证明失败率随项目大小的增加而增加。 | 
