Close

团队拓扑

四大基本拓扑如何影响 DevOps 转型。

Ian Buchanan

首席解决方案工程师

投稿:Shana Vu

了解流对齐团队的优势,以及他们如何与平台团队、子系统团队合作,以及如何使团队能够为客户创造价值。

团队拓扑简介


工程团队需要比以往更快地行动起来,为客户创造价值。云、SaaS 和始终在线的服务的兴起意味着客户期望获得新功能、更少的缺陷以及 99.99%(或更高)的正常运行时间。

为了跟上这些需求的步伐,组织采用了敏捷开发实践,最近还采用了 DevOps 实践,这有助于缩短上市时间/提前期、改善部署频率、改善团队文化并增强团队/部门之间的协作。

虽然采用 DevOps 实践说起来容易做起来难,但《团队拓扑》一书提供了组织将 DevOps 构建到公司中的各种高见,包括哪种类型的团队可能最有效。该书为 Atlassian 如何看待团队提供了一个起点。我们不想重述他们的发现,而是想分享我们对团队类型的看法。

实现 DevOps 转型的第一步是确定现有的组织结构。但是,在当今任何一家公司,都有许多不同的团队类型。在某些情况下,单个团队承担着多种角色和职责。这种杂乱无章使得领导层很难看清整个组织格局,也难以回答类似以下问题的疑问:

查看解决方案

适用于整个团队的 DevOps 工具

相关资料

构建 DevOps 文化

  • 我们是否有合适的团队?
  • 我们是否在某些没有任何团队处理的领域缺乏能力?
  • 团队在自主权和其他团队的支持之间是否已实现必要的平衡?

开发和运营主管可以通过团队拓扑的视角审视他们的组织,从而更好地了解是否已有合适的团队。我们建议将团队变化的数量减少到四大基本团队拓扑,这些拓扑对于高层管理层和实际团队成员自己来说都很容易理解:

  • 流对齐团队
  • 平台团队
  • 复杂子系统团队
  • 助力团队

请注意,这些团队类型会根据公司的规模和成熟度采取不同的形式。实际上,组合多种类型的团队,或者将一个团队转变为另一个团队,通常是最好的方法。

流对齐团队

流对齐团队专注于单一、有影响力的工作流。它可以是单个产品或服务、单个功能集、单个用户过程或单个用户角色。该团队有能力尽可能快速、安全和独立地为客户或用户创造和交付价值,而无需将部分工作交给其他团队来完成。

由于流对齐团队的工作涉及全方位交付,因此他们必须更接近客户,而且通常已经实现敏捷。该团队会将客户反馈纳入开发周期,同时维护生产环节的软件。

虽然流对齐团队在很多软件公司中十分常见,但其他组织可能更熟悉按职能组织的团队结构(即独立的工程、设计、QA 团队),而不是交付流。

由于流对齐团队是组织中最常见的团队类型,因此其他团队的角色均是相对于流对齐团队来定义的。流对齐团队应定期联系以下支持团队(复杂子系统、助力和平台团队),以不断提高产品和服务的交付速度和质量。


Stream-aligned teams focus on a single, impactful stream of work. It can be a single product or service, a single set of features, a single user journey, or a single user persona. The team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.

Because stream-aligned teams work on the full spectrum of delivery, they are, by necessity, closer to the customer and usually already agile. This team incorporates customer feedback in development cycles, while maintaining software in production. 

While stream-aligned teams are common at many software companies, other organizations may be more familiar with team structures organized by function (i.e. separate teams for engineering, design, QA), rather than the delivery stream. 

Since the stream-aligned team is the most common team type in organizations, the role of other teams is defined relative to stream-aligned teams. Stream-aligned teams should regularly reach out to the following supporting teams (complicated subsystem, enabling, and platform) to continuously improve the speed of delivery and quality of their products and services.

平台团队

平台团队使流对齐团队能够高度自主地交付工作。虽然流对齐团队仍对生产环节的构建、运行和修复应用具有完全所有权,但平台团队会提供流对齐团队可以使用的内部服务。

平台团队负责创建可供众多流对齐团队使用的功能,而且开销很小。通过优化产品,平台团队可以最大限度地减少流对齐团队的资源和认知负担。这也使最终用户受益,因为平台团队可以创建跨越不同用户体验或产品的一致体验。

在 Atlassian,平台团队负责构建我们所有产品(例如身份管理)使用的服务,并为流对齐团队提供相关文档、支持和咨询。


Platform teams enable stream-aligned teams to deliver work with substantial autonomy. While the stream-aligned team maintains full ownership of building, running, and fixing an application in production, the platform team provides internal services that the stream-aligned team can use.

Platform teams create capabilities that can be used by numerous stream-aligned teams, with little overhead. By optimizing a product, platform teams minimize resources and cognitive loads of the stream-aligned team. This also benefits end-users too, since platform teams can create a cohesive experience that spans across different user experiences or products.

Here at Atlassian, platform teams build services used by all of our products (like identity management) and are expected to provide documentation, support, and consultation for stream-aligned teams.

复杂子系统团队

复杂子系统团队会根据特定技能和知识负责构建和维护系统的一部分。大多数团队成员必须是特定知识领域的专家才能理解和更改子系统。

该团队的目标是为那些在包含或使用子系统的系统中工作的流对齐团队减少负担。借助复杂子系统团队的专业知识和能力,流对齐团队不必在对于其日常工作来说过于复杂的领域培养能力。该团队的团队成员可能具有某些微服务(例如开票服务)、算法甚至人工智能方面的专业知识。

一个易犯的错误是在每个使用子系统的流对齐团队中安插专家。虽然这可能看起来很有效,但最终并不具有成本效益,而且也超出了流对齐团队范围。


A complicated-subsystem team is responsible for building and maintaining a part of the system that depends on specific skills and knowledge. Most team members must be specialists in a particular area of knowledge to understand and make changes to the subsystem.

The goal of this team is to reduce the load of stream-aligned teams who work on systems that include or use the subsystem. With the complicated-subsystem team’s expertise and capabilities, stream-aligned teams don’t have to build capabilities in areas too complicated for their daily work. Team members from this team may have specialized knowledge in certain microservices (i.e. a billing service), algorithms, or even artificial intelligence. 

A common pitfall is to embed specialists in every stream-aligned team who uses the subsystem. While this may seem efficient, it’s ultimately not cost-effective and out of scope for a stream-aligned team. 

助力团队

流对齐团队不断承受着快速交付和响应更改的压力,因此很难有时间研究、学习和磨炼新技能。

由既定技术(或产品)领域的专家组成的助力团队可帮助弥合这一能力差距。这些团队专注于研究和实验,就影响工具堆栈的工具、框架和生态系统选择提出明智的建议。

此举可让流对齐团队有时间获取能力并就此提升,而无需将时间浪费在偏离其主要目标的事务上。助力团队主要致力于通过专注于问题而非解决方案来提升流对齐团队的能力,从而提高其自主性。

如果助力团队的工作完成出色,那么它所协助的团队应在大约几周后便不再需要其帮助。助力团队不必处理长久依赖性。


Stream-aligned teams are under constant pressure to deliver and respond to change quickly, making it challenging to find time for researching, learning, and practicing new skills.

An enabling team composed of specialists in a given technical (or product) domain help bridge this capability gap. These teams focus on research and experimentation to make informed suggestions about tooling, frameworks, and ecosystem choices that affect the tool stack.

This gives stream-aligned teams time to acquire and evolve capabilities without taking time away from their primary goals. The enabling team seeks to primarily increase the autonomy of stream-aligned teams by growing their capabilities with a focus on problems, rather than solutions.

If an enabling team does its job well, the team it assists should no longer need help after a few weeks or so. The enabling team should never work on a permanent dependency.

Are you a stream-aligned team?


The following questions should be asked to determine if you have a stream-aligned team:

Does your team aim to produce a steady flow of features?
Mature teams release multiple times per week, and in some cases, multiple times per day. In pursuit of this goal, mature teams should use continuous integration and continuous delivery (CI/CD) to ship features frequently.

Is your team quick to change direction based on feedback (customer or internal) from the latest changes?
It’s often best to use an experimental approach to product evolution. Mature DevOps processes include automated testing to ensure quality code shipments. Yet experimentation goes beyond simple unit or acceptance tests. You can ensure that your products deliver the most value to customers by using feature flags to automate roll-outs to a subset of users, alpha and beta releases to solicit and measure user feedback and behavior, and qualitative continuous feedback via comments, support tickets, and community forums.

Does your team have minimal hand-offs of work to other teams?
This should be true in two ways. Your team should be self-contained and work should happen with immediate teammates to ensure fast delivery. Beyond work scope, minimal hand-offs can also take the form of automated processes. Automating your development cycle ensures that moving things along is a seamless process, regardless if the next step is an action like an automated test or merge to main, or an actual human.

Bonus points if….
Does your team have time to address code quality changes (a.k.a. “tech debt”) to ensure changes are safe and easy? 
Mature teams rely on trunk-based development and CI/CD practices to maintain their codebase. Capacity planning should include dedicated time to address tech debt. Plus, large-scale projects that address underlying infrastructure or platform issues should receive as much attention as feature development.

Is your team evaluated by the right metrics?
Beyond how fast your team ships, it should also consider team-health and technical quality metrics in their measures of success.

Regarding the last question around measurement, DevOps teams have traditionally considered the four key DevOps Research and Assessment (DORA) metrics in their definition of “success”:

  • Deployment frequency - How often an organization successfully releases to production
  • Lead time for changes - The amount of time it takes a commit to get into production
  • Change failure rate - The percentage of deployments that cause a failure in production
  • Time to restore service - How long it takes an organization to recover from a failure in production

In addition to these metrics specified by DORA, Atlassian found that high-performing, stream-aligned teams also monitor these attributes

  • Balanced team -  Your team has a diverse set of skills and perspectives 
  • Full-time owner - A full-time owner ensures that the nuclear team and cross-functional participants know who to ask questions to and how to make decisions related to projects owned by the team 
  • Shared understanding - There is a shared understanding of the requirements, along with the definition for values and metrics for success
  • A focus on value and metrics -  Your team has north stars that guide which tasks to tackle in order to move projects to release  
  • Proof-of-concept - Having a real artifact to spar and test assumptions with helps a team constantly iterate and improve 
  • Managed dependencies to maintain velocity - Understanding managed dependencies keeps blockers at bay and helps the team maintain velocity

 

总之......

DevOps 不是目标,而是不断改进工具、团队文化和实践的过程。如果您不熟悉 DevOps,请首先将目标定为:为客户创造价值。熟练后,将自动化注入到工具和流程中。最后,当您的团队成为高级从业人员时,还应纳入可观察性,以确保您对适当的事项进行监控、衡量和改进。


DevOps is not a destination, but a journey of constant improvement of tools, team culture, and practices. If you’re new to DevOps, start by orienting your goals to deliver value to customers. As you mature, add automation to your tools and processes. And finally, when your team becomes advanced practitioners, incorporate observability to ensure you’re monitoring, measuring, and improving on the right things.

Ian Buchanan
Ian Buchanan

Ian Buchanan 是 Atlassian 的 DevOps 首席解决方案工程师,他专注于新兴的 DevOps 社区以及 Jira、Bitbucket 和 Bamboo 的应用,以实现更好的持续集成和持续交付。虽然 Ian Buchanan 在 Java 和 .NET 领域拥有丰富而深厚的经验,但他最广为人知的身份则是在大型企业内采取精益和敏捷实践的拥护者。

在他的职业生涯中,他自始至终成功管理了处在各个生命周期阶段的所有企业软件开发工具。他曾推动组织范围的流程改善,提高工作效率、产品质量和客户满意度。他建立了多个重视自我导向和自我管理的跨国敏捷团队。不说话或编码的时候,Ian 总是沉迷于解析器、元编程和特定于领域的各种语言。


分享这篇文章
下一个主题

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

Devops 示意图

DevOps 社区

Devops 示意图

模拟研讨会

地图插图

免费试用

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up