• 角色和职责
• 政策和标准
• 结束语
• 注释

在本系列三部分文章的 第 1 部分 中，我们介绍了精益软件开发治理，并且描述了精益治理的使命和原则，以及一个个项目的成功所需的组织和项目涉众的协作。在 第 2 部分 中，我们着重于围绕精益开发治理中使用的必要过程和度量的实践。在此，第 3 部分中，我们将分析角色和职责，以及精益软件开发治理需要采用的角色和职责，以及政策和标准。

对于“角色和职责”，我们的意思是定义谁有权力执行某些任务，人力资源部门如何支持这些职责，以及团队组织怎样必须支持并向 IT 架构增加价值。对于“政策和标准”，我们的意思是定义支持跨软件开发工作的一致操作的方针，特别针对 Integrated Lifecycle Environment、IT 资产的管理，以及松散耦合架构的使用，从而允许对演进的商业需求的支持中的快速变更。

角色和职责

敏捷软件开发的首要价值是“过程和工具之上的个人和交互” 1 ，我们在该框架中已经采用的价值。当提到开发治理时，我们的经验是类似的 —— 焦点应该在于令 IT 专业人员能够促进他们之间的有效的协作，而不是试图控制或直接管理他们。此类别中的实践着重于在弄清谁负责、谁有权力，以及对谁负责的同时进行开发。这些实践是：

促进自组织团队

• 将人力资源政策与 IT 价值相结合
• 将团队结构与架构相结合

促进自组织团队

“自组织的团队”有权力选择在它操作的治理结构范围之内执行的工作，并且它以所选择的方式承担工作责任。这是供人分享的决策制定方法，通过此方法，每个人都有机会提供输入，并听取决策制定过程。自组织团队的重要方面是：

• 团队选择其自己的工作。在迭代的开始，团队共同地从已排列优先级的工作项目列表中选择工作项目。工作项目列表包括项目涉众所定义并划分优先级的需求，并且将实际的商业需求与团队执行所依据的内容相结合。
• 个人选择他们自己的工作。个人授权从迭代的工作项目中选择他们自己的工作。员工因各种各样的理由选择任务。举例来说：a) 因为他们擅长，并且知道他们可以有效地工作，b) 因为他们想要获得某些事情方面的更多经验，并且希望通过与某人工作，通过这样的经历提高他们的技能集，或者 c) 仅仅因为他们知道该工作需要完成，并了解轮到他们做了。注意，项目经理可能总是建议某人应该考虑选择什么工作，特别是如果他们希望个人完善他们的技能集。
• 团队决定如何执行工作。团队决定做手边工作和所需的相关工作的一版策略。如果需要，做这项工作的人会在及时（just-in-time，JIT）的基础上进行更详细的计划。高层次、长期的计划最初由团队在项目的一开始制定出来，然后由项目经理在适当时演进。
• 每个人承诺负责工作。团队承诺完成迭代末尾商定的工作，而个人承诺进行他们说要完成的工作。
• 团队有规律的协作。要确保工作完成，并且充分利用了所有适当的团队技能，团队必须通过例会有效地协调工作。
• 经理仍旧是负责任的。虽然团队负有集体的职责，但是最终职责和相关的决策权属于经理。与此同时，经理应该只有在需要时插手并声称权力，这应该很少发生。团队负责计划并执行工作，经理负责沟通计划并与团队之外的团体协调。

好处

对于此实践有许多好处：

• 改进的软件经济。因为团队成员对自己的工作可以控制，所以动机更大，形成了增长的生产力。
• 改进的决策制定。决策在组织结构的恰当地方作出，因为团队有职责且有权力完成工作。
• 改进的质量。来自广大关注人士的贡献形成了更好质量的计划、架构，和最后产品。
• 更少的出错机会。自组织的团队一般需要个人之间较少的工作产品的转换，和更多的沟通，这减少了将缺陷引入产品的机会。
• 增加个人技能的更多的机会。个人有更多的机会从事他们不熟悉的活动，因此提高了他们的技能集和全面的生产力。

权衡

该实践需要组织的成熟度和人们之间的协作的文化。因此，有许多与该实践相关的权衡：

• 您需要负责且成熟的团队成员。首先团队成员必须有能力自组织，这指的是他们必须愿意对他们的决策负责，并且成熟地接受他们仍旧需要做保持项目正轨的“不那么令人兴奋”的任务。
• 您必须相信团队。项目经理将为团队提供较少的日常指导，而提供较多的高层指导。
• 项目经理更像教练或领导。这对于一些传统的项目经理来说会很困难，他们觉得经理工作的一部分就是将团队推向可能的最高的生产力级别，或者激励一些个人取得巨大的成就。长期以来，这些工作通常证明总体上对团队来说是反生产力的。
• 经理仍旧负责全部的工作。某人仍旧需要确保需要完成的每件事都完成了，例如任意所需的文档实现规章方针并遵循之前商定的进度或成本估计。

反模式

以下反模式与团队组织相关：

• 没有权力的职责。团队被告知负责交付系统，但没有受权执行关键任务或制定关键决策。举例来说，被告知要以敏捷的方式开发关键任务的应用程序的团队被迫与非常不敏捷的坚持只有他们可以开发数据库的数据管理团队，和坚持在开始任何测试之前要有全面的需求文档的测试团队一起工作。“敏捷的”团队实际上残废了，因为团队成员没有权力让所需的数据专业人员和测试人员以反映出如何完成剩余工作的方式执行工作。
• 像孩子一样对待成人。善意的项目经理用详细的项目计划强迫高收入、受过良好教育的专业人员。根本的假设是这些专业人员不能自己确定最佳做法，尽管他们有能力做实际工作。虽然项目经理可能最终负责计划，但是他们还可能负责与做实际工作的人一起制定计划。
• 从众。一致同意的决策常常形成最小公分母，每个人都同意的低质量的决策，但不能使工作有效完成。自组织不是基于一致同意的方法。有时候个人不同意一个决策但会选择顺从团队的愿望，而这可能是错误。经理有时必须考虑少数人的意见，而有时确信大多数人，给不流行的方法一个成功的机会。有效的经理不总是需要一致同意，尽管的确不是要排除的东西。
• 来自无政府状态的混乱。当团队得到决定每件事的自由时，他们经常做出不反映总策略的决策。自组织团队的概念不意味着无政府状态。自组织依靠优秀的项目经理的指导来调节。它还受到组织标准、基础架构，和外部规则的调节。“自组织”不意味着您有全部的自由做您想做的事情。

推荐的默认做法

当项目团队看到适合有效地实现他们负责的项目结果时，他们必须有权组织他们自己、他们的工作环境，和他们整体的方法。任何对团队设置的约束条件，例如组织指导，必须在项目过程中的适当时候向团队介绍，并与他们商讨。

将HR政策与IT价值相结合

有效的软件开发依赖于有动机在团队环境中有效协作的有才能的个人。为了使之行之有效，您需要确保 HR 关注，例如，员工积极性和报酬、事业道路，和职责与 IT 组织的价值良好结合。

对协作的关注改变了您奖励和度量人的方式。与其只测量个人的生产力，不如度量个人向团队提供的价值有多少。最有价值的团队成员常常花费其大量的时间指导其他的团队成员，这是一个增加价值的活动，需要反映在综合评定中。

有效的开发需要一群将彼此视为同伴的人之间的紧密协作。在一些组织中，从开发人员到架构师的工作晋升，举例来说，将您最高的技术才能从日常的开发移动到可能不太接近现实的分离的架构团队。在有效的开发组织中，这些专门且有经验的人还作为指导者和技术领导，这要求他们与更多初级的人们并肩工作。

在上面的实例中，HR 体系需要鼓励实现 IT 价值的适当行为，并且确保团队成员间的有效协作。

好处

将HR政策与IT价值相结合带来许多好处：

• 改进的软件经济。好的软件由有动机且有才能的人构建而成。您的 HR 政策对确保您拥有有动机且有才能的人，并且确保补偿和奖励反映出公认的价值，是至关重要的。
• 改进动机并增加员工保留。当一些事情是公认的、有报酬的，且受到支持的，人们就有动机做那些事情。这也导致员工摩擦的减少。

权衡

有许多与将 HR 政策与 IT 价值相结合相关的重要权衡：

• 愿意变更HR政策。HR 部门负责许多不同组织单位的 HR 政策。调整 HR 政策，使之适应单个部分的特定需求是挑战的且需要投资。还有要考虑的法律因素，这可能在每个国家都不同。然而，对 HR 政策的变更通过更有效的 IT 组织大大地获利。
• 投资技术的事业道路。要得到高技术才能的人，您一般需要确保提供吸引人的技术的事业道路，不强迫人们选择他们不感兴趣或不适合的管理事业道路，或者强迫最高才能的人事业停滞。向 IT 专业人员提供可行的事业道路是不小的投资。
• 愿意改变行为来吸引最高才能的人。软件工程师的动机经常不同于其他工作种类。奖励，例如允许雇员锻炼技能或开发真正令人兴奋的革新产品，对于他们来说比传统的好处要多。要吸引高才能的人，值得考虑您想要吸引什么类型的软件工程师，并且改变您的行为来吸引目标。

反模式

以下反模式是相关的：

• 将 IT 像其他商业部分一样对待。HR 政策需要适应每个目标雇员组的有动机的需求。由于软件工程师的动机可能不同于其他开发人员的动机，所以了解所有差距，并调整 HR 政策来解决那些差距是很重要的。应该注意的是对于可以进行的变更有法律约束，而这些约束可能在每个国家都不同。
• 不提供个人的灵活性。甚至在 IT 中，所有的个人不都是由同样的推动力推动。要反映这些，您应该提供各种各样的诱因以及团队目标，并让雇员选择哪个计划最适合个人目标和环境。

推荐的默认做法

确保 IT 和 HR 经理参加关于如何更好地将 HR 政策与 IT 价值相结合的正在进行的讨论。

将团队结构与架构相结合

Melvin Conway 于 60 年代后期确定的 Conway 法则告诉我们任意一个软件都反映出制造它的团队的组织结构。这是因为人们会以反映他们组织形式的方式工作。换句话说，分散的团队可能用分散的架构生成系统。项目团队的组织结构中的优点和弱点都将不可避免地反映在他们生成的结果系统中，这意味着，如果您想要努力完成有效的 IT 架构，那么您需要有有效的 IT 组织结构。

实例：

• 地理驱动的架构。地理上分布的组织应该考虑将每个主要的组件（框架、数据库、应用程序，……）的所有权分配给单独位置的企业架构。举例来说，印度的团队可能拥有数据仓库，瑞士的团队可能拥有许多应用程序，而美国的基础架构团队可能拥有安全框架。通过组织地理分布的组件所有权，您减少了沟通的障碍。
• 质量驱动的组织。如果您想要达到系统中的高层次质量，那么您需要在开发团队中加入质量专业人员，迭代地审查并对进行的工作给出建议（因此，减少沟通时间，并减少通过文档的信息丢失的机会）。注意，您仍旧可以拥有在外部验证项目团队的工作的独立测试团队，但是大部分质量专业人员会在团队中。如果质量对您的组织来说是次要的，但您需要说明您达到特定质量水平的文档证据，那么仅仅审查开发团队的工作的外部质量团队可能足够了。
• 可用性驱动的组织。如果您的系统主要关注可用性，那么您应该组织团队，使他们靠近最终用户，以便他们可以很容易地获得最终用户的反馈。您还应该在项目团队中安插可用性工程师。
• 复用驱动的组织。如果复用 —— 也许基于组件技术或基于服务的技术 —— 是关键因素，那么您应该让拥有并支持那些可复用性架构要素的团队可以帮助将组件与其他项目集成。

好处

将组织结构与您期望的架构结合的主要好处是：

通过使开发团队尽可能容易地使用该架构，来将您的开发工作流线化

为更短的迭代提供机会（因此减少项目风险）

减少团队之间传递、审查、返工等等的无止境的循环

改进团队的整体沟通

权衡

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

• 自相矛盾的架构重点。有时候，一个架构的重点，例如安全性，会激励您选择一种架构策略，而同等重要的重点，例如分布，将激励您选择完全不同的组织策略。就像您需要进行架构的权衡一样，您也需要做组织的权衡。
• 企业限制。您的组织很久以前就决定采用集中的数据架构和数据管理团队，但现在正用遍及世界的开发团队开发分散的系统。幸运的是，组织结构都不是石头雕成的，您可以选择商讨更好地反映您目前需求的新的结构。
• 架构不是唯一的因素。当确定组织结构时，必须考虑许多因素，不仅是架构。这些包括职员的可用性、可适应的法规和雇用法律、个人性格、文化，甚至一些像办公室空间的可用性那样的基本因素。

反模式

以下反模式与此实践相关：

• 一种组织策略适应所有。就像系统有不同的底层架构一样，团队有不同的整体组织结构。举例来说，一个开发团队可能同驻一个房间，并与项目涉众密切合作，然而另一个开发团队可能地理上分布于许多位置。即使这些团队都为同一个组织工作，而每个团队处于不同的情况下，从事不同的系统，并且采用不同的方式。通过设法对所有团队强制采用一个组织结构，您可能将一些（即使不是全部）项目置于风险之中，由于组织/架构的不和谐。
• 组织抑制架构。在不考虑系统的真实需求的情况下，您的组织结构用于为该系统调整架构方法。举例来说，因为您拥有集中的数据管理团队，所以您强迫所有的系统使用集中的数据存储，即使一些应用程序使用跨各种地点分布的许多数据存储更有意义。为了将相对直截了当的管理工作流水化，此决定潜在地增加了开发和操作成本，更不要提整体的技术风险。
• 架构抑制组织。在不考虑非架构关注的情况下，一个或多个系统的架构用于调整您的 IT 组织方法。举例来说，您的组织已经购买、安装，并运行分布式结构的关键任务的 CRM 系统。现在您希望通过将您的 IT 部门集中在一个地点来减少 IT 成本，但 CRM 系统的灵活架构妨碍您这样做。

推荐的默认做法

您应该用负责每个主要组件的交叉功能的团队默认组织您的架构。或者您的公司可以选择在开始时，有许多供选择的“基础”团队结构，然后允许团队自组织（参见自组织团队实践）开发满足他们特定情况的结构。

政策和标准

此类实践描述了支持开发中所涉及的各种各样的团体之间一致运作的专门指南。敏捷软件开发的最终要的价值是“在过程和工具之上的个人和交互”，这不是指您完全没有过程和工具，它只是说它们没有人和人一起工作所采用的方式那样重要。通过精益的治理方法，您的组织将采用能使开发人员有效协作，激励他们开发并复用现有的基础结构和资产，并进行高质量的工作的工具和政策。围绕政策

标准的实践是：

• 集成的生命周期环境
• 有价值的 IT 资产
• 灵活的架构
• 集成的生命周期环境

软件开发依赖于由于不同的时区或工作时间而在时间上分隔的，以及在不同地点开发的空间分隔的团队成员之间的热情协作。协作也会因为许多开发工作的大小而变得困难，这些工作可能需要管理大规模交互的有效机制。这就需要管理监督和必要的记帐来确保法规遵循。

构建集成的生命周期环境是为了以最低的可能成本，使上面的工作可以进行，并为大多数（即使不是所有的）其他的治理实践提供基础架构。集成的生命周期环境的关键组件包括：

• 软件配置管理（Software configuration management，SCM）。大多数项目都有上千各可动部件，每个部件多经常出现新的版本，而理想的情况下，每天都需要将它们集成到工作应用程序上许多次。这需要紧密集成的配置管理、变更管理，和构建管理能力。SCM 构成了集成的生命周期环境的主脊梁。
• 设计和构建。有效地开发代码需要强大的 IDE。设计和构架能力使您可以管理复杂的代码，而开发人员测试能力确保代码是高质量的。与 SCM 的紧密集成对管理变更并进行频繁构建是至关重要的。
• 测试和质量保证。随着应用程序越来越成为关键任务，对改进的质量，可依赖性、性能、稳定性、用户体验，和功能的需求也在增长。功能和性能测试工具正好是干这个的。除了与 SCM 和设计与构造环境的紧密集成之外，将测试和质量保证环境与操作及系统管理环境紧密集成，从而确保操作环境中的恰当的质量属性，也是至关重要的。
• 过程、项目和项目组合管理。集成到其余的生命周期环境中的过程帮助提供一致性，并且通过允许我们从过去的经验中学习来提高效率和生产力。项目组合管理能力帮助确保投资恰当的项目，适当地执行项目，并且提供适当的度量标准来确保有效的监督。与生命周期环境的紧密集成使治理无痛进行，可以将寻常的任务 —— 包括度量标准收集和分析 —— 自动化，来避免开销。这种风格的管理还包括“内嵌的法规遵循”（如本系列第 2 部分中所介绍的），其中法规遵循所需的过程无缝地集成到了开发过程中，并自动生成了所需的报告。

业务和需求分析：要增加商业价值，应用程序开发需要在很好地了解了目前和目标商业过程，并且共享地了解了演进的需求的情况下进行。与生命周期环境的紧密集成是现今商业环境快速发展的必要。

好处

良好的治理解决方案应该设法确保以节省成本的方式将所开发的东西与公司的策略相结合。集成的生命周期环境提供许多与治理相关的好处：

• 有效地实现了治理实践。集成的生命周期环境简化了所有的或者大部分识别出的治理实践的实现，特别是考虑复杂性时，例如大部分开发组织面临的分布开发、法规遵循的需求，以及大规模开发。
• 降低所有权的总成本（Total Cost of Ownership，TCO）。集成的工具环境通过减少与个人工具集合相关的支持和注册成本，通过减少升级、培训，和在组织中调用人员的成本来降低 TCO。
• 协作。特别是当团队在地理上分布，并且/或者做大规模开发工作的一部分时，协作成为有效开发的主要推动者。集成的生命周期环境可以在这些情况下大大地简化有效的协作。
• 无痛治理。通过将寻常的记帐，例如谁变更了什么，和度量标准集合及分析，例如质量或成本度量标准，自动化，一旦建立了适当的环境，集成的生命周期环境就使治理成为相当无痛的。
  实践推动者。集成的生命周期环境启用或促进了介绍的许多其他的实践，包括迭代开发、简单和相关的度量标准，及灵活的架构。

权衡

部署集成的生命周期环境有许多权衡：

• 更丰富的技能。从拥有稀疏特点的应用程序的环境中转移到集成的生命周期环境需要投入额外的技能来使用新的环境。
  初期投资。还要对学习生命周期环境做初期投资。
• 连续的现代化。工具老化了，您需要升级它们，从而追赶改进的且曾经演进的技术。由于集成的生命周期环境包括许多紧密集成的应用程序，所以您需要谨慎地监控，什么时候升级什么工具，从而确保您不破坏集成。这可以通过将升级的一致性问题推给提供连续更新的生命周期环境的厂商来解决。

反模式

以下反模式应该避免：

粗制滥造的工具集。您的业务是构建集成的工具环境，或应用程序吗？厂商们花数亿在集成的开发环境上，而如果您没有财富，那么风险是您将永远不能配得上软件行业中的工具提供商的专业的经验，即使当您使用“免费的”开源工具时。
推荐的默认做法

我们推荐默认使用 IBM? Rational? 软件开发平台。

有价值的 IT 资产

“IT 资产”是组织期望 IT 专业人员在日常工作中应用的软件组件、服务、模板、企业模型、参考架构、实例、模式、指导，或标准。“有价值的 IT 资产”是 IT 专业人员实际想要应用的资产，一般因为它被看作十分高质量并且与手头的任务有关。换句话说，IT 专业人员利用对他们可用的 IT 资产，因为那些资产能够实际地使他们增加生产力。他们遵照企业架构和适当的参考架构，因为那些资产能节省他们的时间，他们的系统调用现有的服务，并且他们利用现有的技术基础架构，这都是因为复用这些东西比重新构建更容易。
理想地说，IT 专业人员遵照企业的标准和指南，因为帮助他们将工作流水化，不是因为被迫避免通不过审查。确实，一些标准是必须按照法律来遵守的实践，在这种情况下，IT 专业人员没有选择的余地。幸运的是，大多数法律标准经常有重大的余地，为您的组织提供以将对 IT 专业人员的意义最大化（或者将一致性的痛苦最小化）的方式实现这些标准的机会。

好处

支持有价值的 IT 资产有许多好处：

• 增加的一致性。遵照公共的指南，例如编码标准和建模指南，并应用公共的模式增加 IT 生成的工作产品的整体一致性。这反过来导致支持和维护成本的减少。愿意遵照的指南将被应用。
• 增加的效率。技术资产复用的增加使您通过普通功能的标准化来增加整体的效率。遵照一致的指导可以使您将不增加价值的活动标准化，并因此关注新的机会。
• 改进投入市场的时间。增加复用、一致性，和效率导致投入市场的时间减少了，因此提高了您组织的竞争力。
• 改善的沟通。工作产品一致性的增加、模式提供的公共词汇，以及公共的企业架构帮助促进 IT 专业人员之间的沟通。这反过来帮助将您整体的 IT 工作流水化，并减少了导致错误传达的过失的机会。
• 减少的治理成本。当 IT 专业人员愿意在常规的基础上应用有价值的 IT 资产时，整体的治理成本减少了，因为不需要投入很多来强迫并验证那些资产的使用。

权衡

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

• 投资于质量。人们重视 IT 资产，因为它们高质量，并且可应用于他们想要完成的东西。高质量不是偶然产生的，而是通过艰苦工作或有效采购的投资而产生。
• 质量花费得更多。创建可复用的资产，或者书写简洁的指南，比创建具体项目的资产要花费的更多。您必须采用不因为创建这些资产而惩罚团队的资金策略。
• 投资于资产支持。要有效地应用 IT 资产，人们需要帮助。资产必须很容易找到，并且必须有人能帮助了解并应用资产。
• 投资于资产演进。在不继续投资的情况下，所有的 IT 资产都将随着时间丧失元气。举例来说，如果开发人员目前使用 Java 5 的话，Java 1.1 的编码标准价值不大。如果团队真正需要的是简单、轻量级用例的模板的话，形式的详细的用例的模板将减慢开发团队，或者被团队忽视。
• 减少的自由。当 IT 资产可用，并且准备由 IT 专业人员应用时，对于开发人员来说，摆脱企业的方向是很困难的。许多开发人员希望有自由为他们的系统选择最适当的持久性策略，他们不想被命令使用什么现有的数据库。
• 需要达成共识。必须对 IT 资产是有价值的达成共识。举例来说，Java 编码标准应该由您的组织中一组尊敬的领导来编写和支持。其他人也会评审并评论，进一步改进该编码标准。可能不是每个人都同意 Java 编码标准中的所有建议，但他们应该认可代码一致性的重要性，并且欣然地同意遵照。

反模式

以下反模式与有价值的 IT 资产相关：

• 强迫的指导。高级 IT 管理层声称所有的 IT 专业人员多必须遵照一组公共的标准和指导方针，然后进行严格的审查过程以确保法规遵循。虽然这会形成上面所指出的许多好处，但经常会增加实施成本。
• 公然的可复用。技术资产，例如组件、服务，或您的整个 IT 基础架构，的所有者都公开声明可以复用它们。有一些东西直到成功复用后才是可复用的，不是因为有人说它是可复用的。开发人员不愿意复用资产，除非它们是高质量的并且可应用于手头的任务。
• 象牙塔资产。“象牙塔资产”在给余下的 IT 使用之前都是完美，或近乎完美的。有一个实例是花费几个月完成的非常详细的企业数据模型，处理开发团队所需的安全性的所有可能的方面的安全性框架，或者一组十分精练的需求和设计工件的文档模板。象牙塔资产经常提供得太迟了，对其预期的受众不能产生价值，或者有太多的冗余，在实践中没有用。
• 抑制复用的计划。有许多您可以刺激 IT 专业人员不复用现有资产得方式。举例来说，通过代码行数（lines-of-code，LOC）来度量会刺激他们写新的代码来代替现有的代码。为了对资产的维护和支持投资，指示他们复用资产，会刺激他们只书写针对他们需求的，对他们来说不昂贵的东西。

推荐的默认做法

我们推荐 IT 部门维护主要的开发语言的编码标准、希望在系统中促进的公共模式库、技术基础架构关键方面的参考架构，和企业架构的版本描述。还应该有人支持、演进，并购买或收获这些有价值的 IT 资产。无论在什么可能的情况下，我们推荐您购买而不是构建 IT 资产，特别是如果您能够轻易买到满足您需求的东西，从而将维护负担留给其他人。

灵活的架构

精益软件开发治理的一个目标是在您的业务中实现灵活性和响应性，而在您组织并演进 IT 系统的方式中要求灵活性和响应性。精益治理可以由灵活的架构来实现，因为它们使开发团队对业务的变更的需求进行有效地反应。目前对于架构的最灵活的方法是通过开放计算和面向服务。

开放计算包括三个主要的组件：

• 开放的标准。通过使用对 API、协议，和数据及文件格式的开放的，公布的规范，标准相互促进。
• 开放的架构。良好的架构能使我们构建出松散耦合的，灵活，可重构的解决方案。面向服务的体系结构（Service-oriented architecture，SOA）就是开放且灵活的架构风格的一个实例，它还在提供商业过程和软件能力之间的紧密耦合上占有优势，从而确保战略联合。

开源的软件（Open source software，OSS）。OSS 工具对于利用团体开发和协作推动革新是至关重要的。

SOA 构建于开放计算之上，它允许系统由与所支持的商业过程紧密连接的一组松散耦合的服务动态组成。这为 IT 资产和商业需求之间提供了很好的联合，同时还交付了敏捷商业所需的灵活性和响应性。

还应该提到的是虽然 SOA 有明显的好处，但是它的确增加了治理过程的复杂度，因为从垂直的竖井转移到 SOA 需要我们在投资、服务水平协议（service-level agreements，SLAs）管理，和需求管理方面，管理商业单元和 IT 资产之间的多到多的关系。

IBM Software Group 是其中一个最近已经转换了在其产品之下的架构的组织。在过去，IBM 的软件产品构建于专有的硬件、操作系统，和应用组件之上。IBM Software Group 已经广泛地采用了标准和开源成果，并且加入了 SOA。这已经形成了革新，并且显出了我们提供集成解决方案的能力，它向我们和我们的客户提供了增加的灵活性和响应性。举例来说，最近启用的产品 IBM WebSphere? Service Registry and Repository 不到一年就开发出来了，并且客户反映很好，而在过去这可能会花费我们几年时间。

好处

灵活的架构带来许多好处：

• 支持发展的商业需求。快速发展的商业与成为商业日益关键的部分的 IT 的结合给 IT 带来了很大压力，要求 IT 快速发展。灵活的架构为保证这种事的发生而提供技术基础。
• 减少投入市场的时间。由于可复用的组件/服务是松散耦合的，所以灵活的架构可以使您更快速地用它们装配应用程序。这使得复用应用得更广泛，从而大大地减少了投入市场的时间。
• 改善 ROI 并降低 TCO。通过改善复用，并使应用程序的装配更简单，您可以降低整体的开发成本。对行业标准的依赖还确保了满足您需求的多种产品的可用性，相对于专利技术解决方案，使价格保持较低。
• 减少技术风险。由于灵活的架构日益依赖行业标准，它们减少了您对任一厂商的依赖性。这为您增加了操作上的自由。

权衡

部署灵活的架构有许多权衡：

• 需要投资。灵活的架构不是免费的。您需要投资于技能、技术和从现今的资产到未来的松散耦合的资产的转换。要实现复用的承诺，您还需要投资于作为整体架构一部分的实例的参考架构。
• 需要演进。灵活的架构需要与技术和标准一起发展。这需要对技能和技术投资。
• 需要质量。灵活的架构简化了复用，但复用更强调质量。没有足够的质量，您的可复用组件将需要比复用所节省下来的更多的维护和支持开销。

反模式

以下是与灵活的架构相关的反模式：

• 烟囱架构。采用垂直的或烟囱架构会减少复用和商业灵活性。就像技术已经将商业和商业机会的范围提升到整个世界（参见 Thomas Friedman 的 The World is Flat: A Brief History of the 21st Century）一样，我们的架构需要适应社会网络的最新模式（举例来说，Web 2.0）和允许 24x7 操作的分布及大量外包的商业模型。
• 专利技术。虽然您可以用专利技术构建灵活的架构，但是它生成了厂商的禁闭，减少了未来的来源获取的灵活性，并且可能导致更高的所有权总成本。结论：随着技术发展超过了专利解决方案，您就落后了。
• 决不确定一个技术。选择一种技术很难，部分因为不论您做出什么选择，到了明天都不是最佳的。然而，决不确定更糟糕，因为您需要决定演进。

推荐的默认做法

我们默认推荐面向服务的体系结构、新兴的架构、开源的技术，例如 Eclipse，和标准，例如那些与 Java 2 Enterprise Edition（J2EE）、Object Management Group（OMG），和 Institute of Electrical and Electronics Engineers， Inc.（IEEE）相关的标准。

结束语

每个 IT 组织都有开发治理计划，但该计划可能不明确并且可能不非常有效。在过去，开发治理的传统的方法类似于群养小猫 —— 管理层会做很多提供方向的工作，但开发人员会按照自己的协定行事。这些传统的开发治理方法没有效果，因为开发人员是知识分子，他们不能在指挥控制的方式下很好地工作。要让治理计划有效，它必须反映出它所应用的实际环境，并且一提到管理，那么主要的因素就是所涉及的人。

有效的治理不是关于指挥命令的，而是着重于通过协作和支持的技术来实现。这类似于引导小猫，并且证明激励人们做正确的事情，比试图强迫他们这样做更有效。在本系列文章中，我们概括地介绍了一组反映出现代软件开发现实的精益开发治理的实践。这些实践显示出如何将治理嵌入您的工具、过程，和开发指导中，从而令人们尽可能容易地做正确的事情。它们是审视开发治理的新途径，反映出现代的开发方法，例如精益软件开发、IBM Rational Unified Process?（RUP?）、极限编程（Extreme Programming，XP）、动态系统开发方法（Dynamic Systems Development Method，DSDM），和 Scrum。开发治理只是整个 IT 治理领域中的一部分，但是重要的一部分。敬请关注。

注释

1.敏捷软件开发的价值写在 www.agilemanifesto.org 中