创建软件产品和系统的公司的员工经常问我：“我们如何在不实际更改组织的情况下更改我们的组织？” 当然，他们不使用那些实际的单词（至少不是一直都使用），但这就是含义。 他们希望最大程度地减少发布软件所涉及的工作量和风险，但是他们意识到，这要求整个组织范围内的（文化和技术上的）变化，因为它们并不总是具有影响力。
他们经常遇到的文化障碍是，传统的开发和运营团队往往会孤军奋战，从而限制了团队之间的沟通量，直到软件发布为止。 （这种交流通常仅限于问题跟踪系统中的一系列通知。）成长中的软件企业必须变得更加协作，否则它们将不复存在。 由于云计算的出现，软件行业正朝着这个方向变化（比某些人预期的要快得多），这使得计算资源的稀缺性和业务需求减少了。 不断发展的公司将淘汰那些不会倒闭的公司。
开发人员可以从操作中学到很多，操作可以从开发人员中学到很多。 本系列文章致力于探索将操作思维方式应用于开发（反之亦然）的实际用途，以及将软件产品视为可以以比以往任何时候都更高的敏捷性和频率提供的整体实体。
正如本系列的介绍性文章所强调的那样，跨组织边界的协作是敏捷DevOps的基础之一。 本文讨论了如何建立跨职能团队和扩展交付团队成员的技能，是如何增强协作并打破阻止软件连续交付的传统障碍的方法。
跨职能团队由整个软件交付周期中的专家组成，例如运营工程师，数据库管理员（DBA），测试人员，开发人员和分析师。 跨职能团队中的每个人都将代码贡献到版本控制存储库中。 例如，运营工程师以代码的形式贡献基础架构和配置； DBA将数据定义语言（DDL），数据建模语言（DML）和数据集作为代码提供； 分析人员以代码的形式提供需求； 开发人员提供应用程序代码和配置； 测试人员将测试作为代码进行。
对于由习惯于在基于矩阵的服务型组织中工作的人员组成的新跨职能团队，可能需要一些时间来熟悉跨职能团队的工作。 通常，团队中个人的技能范围更狭窄，需要扩展。 在这种情况下，在最初的试点项目中，可以邀请组织中的专家（例如安全专家）为跨职能团队成员提供建议。 顾问不是跨职能团队的成员，他们也不提供测试或代码。 他们的目的是扩展跨职能团队成员的技能。 随着业务的扩展，团队将减少对顾问的依赖。
跨职能团队的每个成员都负责交付过程。 团队中的任何人都可以修改软件系统的任何部分。 相应的反模式是孤立的团队，其中的开发，测试和操作具有自己的脚本和流程，并不属于同一团队。
因此，跨职能团队由来自负责开发和交付软件系统的所有学科的人员组成。 交付团队不是将每个学科视为单独的集中式服务组织，而是成为关键的组织结构。 团队以专用的方式协同工作，以一致地交付软件，而团队之间在整个组织中进行交流时没有固有的时间障碍。 考虑由（至少）业务分析师，客户代表，DBA，开发人员，项目经理以及质量保证（QA）和发布工程师组成的每个团队。 通过跨职能团队，您可以减少“这不是我的工作”综合症和其他“壁垒”，这些“壁垒”会扼杀物理位置内和跨物理位置的团队之间的沟通。
一段时间后，您会发现技能集通常会演变为功能更完善的工程师/分析师，他们开始做的不只是软件交付过程的一部分。 例如，程序员可以创建DDL和DML脚本。 或者，业务分析师在验收测试脚本（例如Cucumber）中定义他们的要求，以便所有更改都根据客户的要求通过自动测试进行。 每个团队成员都知道他或她需要编写测试，编写脚本，版本（请参阅“ Agile DevOps：对所有内容进行版本化 ”），并使他们所做的所有事情成为连续系统的一部分（请参见“ Agile DevOps：持续交付平台 ”）。 所有源工件都是这种情况：应用程序代码，配置，基础结构和数据。 当团队成员变得更加精通技能并消除孤岛时，沟通将得到改善，而旧软件组织中的瓶颈也将消除。
组成完整软件系统的所有内容都是脚本（即程序）或自动化测试。 组成软件系统的所有内容都经过版本控制，并且所有内容都被集成到持续交付管道中。 这样，当任何成员提供的任何内容都被签入版本控制存储库时，它将使用版本化配置创建整个软件系统-包括环境，数据库和软件应用程序/服务。 系统的每个组件均已版本化，没有例外。 跨职能团队的成员100％致力于该项目，与其他项目无关。 这种方法增强了沟通并减少了任何过程瓶颈。
在组织中进行文化变革是采用DevOps的最重要要素。 除非发生这种情况，否则没有其他重要的事情发生。 本节讨论了过渡到跨职能团队并与之有效运作的高级方法。
几乎一次尝试更改大型组织的尝试几乎肯定会失败。 首选方法是从一个小规模的试点项目开始，该试点项目可以在较短的时间内（理想情况下，不超过90天）为生产带来商业价值。 试点项目应该具有战略意义，而不是很少更新的应用程序并提供最小的业务价值。 这个新团队将是一个跨职能的团队，每个成员都将完全致力于该项目。 （他们将不会从事其他项目。）开发软件系统所需的每个角色（操作，应用程序开发人员，数据库，测试人员等）都将成为该跨职能团队的一部分。
为了在有效沟通的小型团队中工作，您需要拆除整体架构。 具有许多其他紧密耦合的从属系统的体系结构很脆弱，并且使更改变得极为困难。 这并不意味着您并没有在构建大型系统。 这意味着这些系统可以松散地耦合为通过简单协议进行通信的服务。
一旦证明一个项目成功，就可以扩展到更多项目。 这些其他项目将有来自第一个试点项目的团队成员，他们将分享他们的知识，并且每个人都是新团队的100％成员。 在这些项目成功之后，您将使随后的试点团队增加一倍或两倍，直到所有战略项目都在新模式下运行。
由于所有服务团队都很小（不超过10人）且独立，因此您可能想知道哪些组织职能是集中的。 尽管每个组织都不同，但拥有采用DevOps和连续交付原则的团队的人，集中的功能要么是开发其余软件交付团队使用的平台服务的功能，要么是执行系统监视（应用程序，网络，安全性，等等）。 也可能有发布协调员，治理和管理人员，但是这些集中式团队都不应该执行会增加跨职能团队的等待时间的活动（换句话说，集中式团队提供的服务完全是自我的） -服务）。 通常，在这些组织中，服务交付团队（由程序员，操作，数据库，测试人员等组成）随时待命（通常在团队成员之间轮换），并负责解决生产问题。
在构建软件交付系统时，只有自动更改才能运行软件交付，团队中的任何人（成员不超过8至10个）都可以将更改部署到生产环境（或任何其他环境）。 作为开发人员（基础结构代码，应用程序代码，分析人员脚本等等），您的最终客户是实际用户，而不是传统的运营团队，因此鼓励了非常快速的反馈循环。
DevOps的主要功能之一是，团队成员永远不需要跨职能团队之外的其他团队成员来执行活动，这是交付过程的一部分。 一切都必须是自助的。 任何团队成员都应具有将软件交付生产的能力（请参阅“ 构建，运行！侧边栏”）。 当团队成员设计软件交付系统中的任何功能时，他们需要考虑如何开发该功能，以便可以在不涉及提交票证，发送电子邮件或使用其他通信机制的交付管道等待时间的情况下使用它。 （这些工具仍经常用于包含DevOps和持续交付的团队。但是在交付管道的背景下，它们是自动化的。）
由于总体原则是将所有内部服务都转向自助服务模型，因此应用了某些特定模式，到目前为止，本系列以一种或另一种方式涵盖了这些特定模式。 表1中描述了这些模式中最重要的模式。
developerWorks 敏捷转换提供新闻，讨论和培训，以帮助您和您的组织在敏捷开发原则上建立基础。
从本文中您了解到，有效的DevOps的关键之一是打破孤岛，并创建可以将其软件部署到生产中的跨职能团队。 采购和交付周期长的组织将发展或破产。 在大型组织中，发展可能需要时间，并且需要改变组织文化。
在本系列的最后一篇文章中，您将学习如何创建DevOps仪表板—开发和运营团队可以实时监视的软件系统状态的全面视图。
翻译自: https://www.ibm.com/developerworks/opensource/library/a-devops9/index.html
相关资源：筒仓设计软件