围绕最终交付物，而不是角色，组织软件交付活动：持续交付与跨功能团队

在实施持续交付的过程中，我们很容易聚焦于自动化和工具，因为作为起点，它们通常是最容易做的。然而，持续交付的成功实现，还依赖于根据最终交付物而对组织结构所做的优化。对于持续交付来说，最大的障碍是依据角色和分层结构来组织团队，而非业务上的最终交付物（即产品或服务）。

为了解决开发团队、测试团队和运维团队之间的“筒仓”，Devops运动应运产生。那么，这些“筒仓”为什么会存在呢？Gartner的Coleen Young说过下面这段话，直接切入这个问题的核心：

事实上，每个IT组织一定会面临一个必然引起组织结构彻底改变的流程改造。传统IT服务的交付和组织模式以有效性为代价，达到了高效性。在过去，计算能力非常昂贵，资源稀缺的时候，将人员利用率和资产的生命周期成本最大化是合理的。这种面向资源的业务流程最终会导致功能壁垒。优化后的基于流程的组织在横向上侧重于各自环节的产出，而不是在全局上最终交付物的产量。

“筒仓”产生的根本原因在于计算资源的历史费用和发布过程的高成本。而批量单位的大小与交接成本之间有直接关系。这在Economic Lot Size 方程式上已经体现了，这个方程式是来处理交易成本（transaction cost）将一个工作块交付给下一环节（如从开发到测试）和持有成本（不交给下游的成本）之间的平衡。这在Donald Reinertsen的书《产品开发流程的原则》中有讨论，如下图所示：

持续交付：减少交易成本

在大型机时代，发布一个版本的交易成本较小。之后，当我们进入客户端/服务器架构的时代，以及后来基于网页的软件系统，每次发布的交易成本就变得越来越高了，甚至在总成本中占首位。而这就驱使我们进行批量开发，从而导致了我们今天看到的“筒仓”。

然而，持续交付传递了一种信息，即现在有很多工具、模式和实践，可以大幅度地降低发布的交易成本，使得持有成本占到交付总成本的大头。

这样的话，形成组织壁垒的根因就不复存在了。而且，由于壁垒会导致低质量的软件，生产环境的稳定性差，以及发布的次数越来越少。因此，对于那些关键业务的项目团队来说，更有必要消除这些问题。

跨功能团队：为了最终交付物而做优化

筒仓的替代物是跨功能团队。正如Young建议的那样，在跨功能团队中，我们对最终交付物或者交货时间做优化。通过实现持续交付的那些实践，可以将交易成本降到可忽略不计的水平。然后，通过限制在制品数量这种方式来实现小批量生产，并设法让这些小批量功能在尽可能短的时间里发布给用户，或者至少能够做到“可以发布给用户”的水平。

跨功能团队并不是一个新概念，但人们常常低估了它的重要性。对于减少交货时间（lead-time）来说，跨功能团队是一个至关重要的因素。因为，功能交付的延期在很多时候是由于沟通开销引起的。如果参与某产品（或服务）的所有人都能够在一起工作，那么在写代码之前，开发人员就可以直接把测试人员叫来，给他展示已做好的功能，以便能够得到快速反馈。而测试人员和开发人员可以一起合作创建功能验收测试，开发人员也可以与DBA一起讨论数据库结构的变更，还可以与基础设施专家一起讨论基础架构上的一些平衡点。

这不但会让软件交付更快，而且会有更多的乐趣。当然，我们最终会得到高质量的软件、低风险的发布，以及从客户那儿得到更快速的响应。在Amazon做出“组成面向服务架构的跨功能团队”这一决定时，这些因素都是其认为的关键收益。

对于“跨功能团队”，常常会听到这样几种的反对声音。一是当所在的组织要遵从某些法案，如萨班斯－奥克斯利法案，或支付卡行业数据安全标准（PCI-DSS，全称为Payment Card Industry Data Security Standard）时，需要做到责任隔离。实际上，在跨功能团队里，能够更高效地实现责任分离，正如我在最近为 Cutter IT Journal的一篇文章提到的。

另一个反对的声音是当创建跨功能团队，并实现持续交付时，会有附加成本。的确如此，这意味着你只会在那些处于战略地位的核心服务组合上投入这种附加成本。此时，通过产品的快速上市、从用户那里学习并快速迭代，以及避免开发没有用的功能（这是软件开发中产生浪费的最大来源）得到通常数倍于这种附加成本的回报。——当然，在“筒仓”引起的问题当中，有一部分问题是可以通过更好的管理手段来缓解的。比如，确保在这些“筒仓”中，资源负荷不过重，人员在各筒仓间轮换，以鼓励协作和理解。

如何走向跨功能模式的组织？

如果你的IT组织不大，比如还不到30人，那么你可以一下就转变成跨功能模式。然而，在大型组织中，正如《持续交付》中的所有事情一样，这应该是个迭代且增量的过程。

从一个试点项目开始。首先，确保你能收集整个项目周期中的总成本和总收入，以及其它相关度量项，比如周期时间(cycle time)以及每个发布版本所交付的增量价值。整个团队要对该服务的SLA（服务等级协议，Service-Level Agreement）负责。而且，更为重要的是，对自己依赖的基础设施，能够做到自服务，包括测试环境和生产环境在内，从而不必为了硬件准备这样的工作而等上几天或几星期。应该给该团队一些时间来实现持续交付，并且聚焦于交付一个最低可行的产品（minimum viable product），然后根据从用户那儿反馈的真实数据进行快速迭代。

有分布式团队的大型组织更应该转向“跨功能团队”这个目标。而关键在于：确保不是依据角色不同而组织团队。对于“持续交付高质量软件”来说，没有什么能比让开发团队在一个国家、测试团队在另一个国家，而运维团队在其它国家的伤害更大啦。

最后，团队应该首先关注于，通过分解成最低可行的产品集并测试，以验证其所做出的业务假设。而一旦失败，就很容易进行调整。

原文来自《持续交付》, 更多关于“持续交付”的内容请访问 http://www.continuousdelivery.info。