Close

Topologie zespołów

Jak cztery podstawowe topologie wpływają na transformację DevOps.

Ian Buchanan

Główny inżynier ds. rozwiązań

Opracowanie redakcyjne: Shana Vu

Dowiedz się więcej o zaletach zespołów dopasowanych do strumienia oraz o tym, jak współpracują one z zespołami platformowymi, zespołami ds. podsystemów i zespołami wspierającymi, aby dostarczać wartość klientom.

Wprowadzenie do topologii zespołów


Zespoły inżynierskie muszą działać szybciej niż kiedykolwiek wcześniej, aby zapewnić wartość swoim klientom. Rozwój chmury, SaaS i zawsze dostępnych usług oznacza, że klienci oczekują nowych funkcji, mniejszej liczby błędów i dostępności na poziomie 99,99% (lub więcej).

Aby sprostać tym wymaganiom, organizacje stosują praktyki Agile, a ostatnio także praktyki DevOps, które dają możliwość szybszego wprowadzania produktów na rynek/skrócenia czasu wdrażania, poprawy częstotliwości wdrażania, doskonalenia kultury zespołowej oraz pogłębiania współpracy między zespołami i działami.

Wdrożenie praktyk DevOps nie jest łatwe. Na szczęście książka Team Topologies proponuje odkrywcze sposoby na włączenie DevOps w strukturę swojej firmy, wskazując między innymi, jakie typy zespołów mogą okazać się najskuteczniejsze. Ta książka stanowi punkt wyjścia dla podejścia do zespołów, jakie prezentuje Atlassian. Zamiast powtarzać zawarte w niej wnioski, chcemy podzielić się własną perspektywą na temat typów zespołów.

Pierwszym krokiem w kierunku transformacji DevOps jest identyfikacja aktualnej struktury organizacyjnej. Jednak w każdej współczesnej firmie istnieje wiele różnych typów zespołów, a w niektórych przypadkach pojedyncze zespoły przejmują wiele ról i obowiązków. Ten brak spójności sprawia, że kierownictwu trudno jest zwizualizować pełny krajobraz organizacyjny i odpowiedzieć na takie pytania jak:

poznaj rozwiązanie

Narzędzia DevOps dla całego zespołu

materiały pokrewne

Tworzenie kultury DevOps

  • Czy dysponujemy odpowiednimi zespołami?
  • Czy w pewnych obszarach są luki, których nie wypełnia żaden zespół?
  • Czy zespoły mają zapewnioną niezbędną równowagę między autonomią a wsparciem ze strony innych zespołów?

Kierownicy ds. programowania i operacji mogą dokładniej ustalić, czy dysponują odpowiednimi zespołami, jeśli spojrzą na organizację przez pryzmat topologii zespołów. Zalecamy ograniczenie liczby wariantów zespołów do czterech podstawowych kategorii, które są bardziej przystępne zarówno dla wyższego kierownictwa, jak i dla samych członków zespołu:

  • Zespół dopasowany do strumienia
  • Zespół platformowy
  • Zespół ds. skomplikowanego podsystemu
  • Zespół wspierający

Należy pamiętać, że te typy zespołów przybierają różne formy w zależności od wielkości i dojrzałości firmy. Często najlepszym wyjściem jest połączenie więcej niż jednego rodzaju zespołu lub przekształcenie zespołu w inny.

Zespół dopasowany do strumienia

Zespoły dopasowane do strumienia koncentrują się na jednym, znaczącym strumieniu pracy. Może to być pojedynczy produkt lub usługa, pojedynczy zestaw funkcji czy też pojedyncza podróż lub persona użytkownika. Zespół ma możliwość budowania i dostarczania wartości dla klienta lub użytkownika tak szybko, bezpiecznie i niezależnie, jak to możliwe, bez konieczności przekazywania części pracy innym zespołom.

Ponieważ zespoły dopasowane do strumienia pracują nad pełnym spektrum dostarczania, z konieczności działają one bliżej klienta i zazwyczaj korzystają już z metodyki Agile. Ten zespół uwzględnia opinie klientów w cyklach tworzenia oprogramowania, jednocześnie utrzymując jego wersję produkcyjną.

Podczas gdy zespoły dostosowane do strumienia są powszechnie spotykane w firmach programistycznych, inne organizacje mogą być bardziej zaznajomione ze strukturami zespołów zorganizowanych według funkcji (np. oddzielne zespoły ds. inżynierii, projektowania, kontroli jakości), a nie strumienia dostaw.

Ponieważ zespoły dopasowane do strumienia są najczęstszym typem zespołu w organizacjach, to w odniesieniu do nich definiowana jest rola innych zespołów. Zespoły dostosowane do strumienia powinny regularnie kontaktować się z zespołami, z którymi współpracują (zespoły ds. skomplikowanego podsystemu, wspierające i platformowe) w celu ciągłej poprawy szybkości dostarczania i jakości swoich produktów oraz usług.


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.

Zespół platformowy

Zespoły platformowe umożliwiają zespołom dopasowanym do strumienia realizowanie zadań przy znacznej autonomii. O ile zespół dopasowany do strumienia zachowuje pełną kontrolę nad tworzeniem, utrzymywaniem i naprawianiem aplikacji na etapie produkcyjnym, zespół platformowy zapewnia wewnętrzne usługi, z których może korzystać zespół dopasowany do strumienia.

Zespoły platformowe tworzą możliwości, z których mogą korzystać liczne zespoły dopasowane do strumienia, z niewielkim narzutem. Optymalizując produkt, zespoły platformowe minimalizują zasoby i obciążenie intelektualne zespołu dopasowanego do strumienia. Jest to również korzystne dla użytkowników końcowych, ponieważ zespoły platformowe mogą tworzyć spójne środowisko, które obejmuje różne doświadczenia użytkowników lub produkty.

W Atlassian zespoły platformowe tworzą usługi wykorzystywane przez wszystkie nasze produkty (takie jak zarządzanie tożsamościami), a ich zadaniem jest dostarczanie dokumentacji, wsparcia i konsultacji zespołom dopasowanym do strumienia.


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.

Zespół ds. skomplikowanego podsystemu

Zespół ds. skomplikowanego podsystemu odpowiada za tworzenie i utrzymanie części systemu, która zależy od konkretnych umiejętności i wiedzy. Większość członków zespołu musi być specjalistami w określonym obszarze wiedzy, aby móc rozumieć i wprowadzać zmiany w podsystemie.

Zadaniem tego zespołu jest zmniejszenie obciążenia zespołów dopasowanych do strumienia pracujących na systemach, które obejmują dany podsystem lub z niego korzystają. Dzięki fachowej wiedzy i umiejętnościom zespołu ds. skomplikowanego podsystemu zespoły dostosowane do strumienia nie muszą rozwijać umiejętności w obszarach zbyt skomplikowanych jak na ich codzienną pracę. Członkowie takiego zespołu mogą posiadać specjalistyczną wiedzę w zakresie niektórych mikrousług (np. rozliczeniowych), algorytmów, a nawet sztucznej inteligencji.

Częstym błędem jest umieszczanie specjalistów w każdym zespole dopasowanym do strumienia, który korzysta z określonego podsystemu. Chociaż może się to wydawać efektywne, ostatecznie jest nieopłacalne i wykracza poza zakres prac zespołu dostosowanego do strumienia.


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. 

Zespół wspierający

Zespoły dopasowane do strumienia znajdują się pod ciągłą presją, aby szybko dostarczać rozwiązania i reagować na zmiany, co sprawia, że ich członkom trudno jest znaleźć czas na analizy, uczenie się i ćwiczenie nowych umiejętności.

Zespół wspierający, składający się ze specjalistów w danej dziedzinie technicznej (lub produktowej), pomaga wypełnić tę lukę w zakresie umiejętności. Zespoły te koncentrują się na badaniach i eksperymentach, aby móc przedstawiać merytoryczne sugestie dotyczące narzędzi, modeli i ekosystemów, które mają wpływ na dostępny zestaw narzędzi.

Dzięki temu zespoły dopasowane do strumienia zyskują czas na zdobywanie i rozwijanie umiejętności bez oddalania się od podstawowych celów. Zadaniem zespołu wspierającego jest przede wszystkim zwiększenie autonomii zespołów dopasowanych do strumienia poprzez poprawę ich umiejętności, przy czym koncentruje się on na problemach, a nie na rozwiązaniach.

Jeśli zespół wspierający dobrze wykonuje swoją pracę, po kilku tygodniach wspierany przez niego zespół nie powinien już potrzebować pomocy. Nigdy nie powinien być trwale zależny od zespołu wspierającego.


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

 

Wnioski…

W DevOps chodzi nie tyle o cel, co o drogę, polegającą na ciągłym doskonaleniu narzędzi, kultury zespołowej i praktyk. Jeśli dopiero zaczynasz przygodę z DevOps, na początek postaw sobie za cel dostarczanie klientom wartości. W miarę rozwijania się dodaj automatyzację narzędzi i procesów. A gdy wreszcie gdy Twój zespół stanie się komórką zaawansowanych praktyków, sięgnij po narzędzie, jakim jest wgląd, aby monitorować, mierzyć i doskonalić właściwe rzeczy.


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 jest głównym inżynierem ds. rozwiązań DevOps w firmie Atlassian, skupiającym się na rozwijającej się społeczności DevOps oraz stosowaniu systemów Jira, Bitbucket i Bamboo w celu usprawniania ciągłej integracji oraz ciągłego dostarczania. Ian Buchanan ma szerokie i bogate doświadczenie zarówno w dziedzinie technologii Java, jak i .NET, ale najbardziej znany jest jako mistrz praktyk Lean i Agile w dużych przedsiębiorstwach.

W trakcie swojej kariery z powodzeniem zarządzał narzędziami do tworzenia oprogramowania dla przedsiębiorstw we wszystkich fazach ich cyklu życia — od początku aż do końca. Udało mu się doprowadzić do usprawnienia procesów w całej organizacji, czego efektem jest większa produktywność, wyższa jakość i większe zadowolenie klientów. Tworzył międzynarodowe zespoły Agile, które cenią sobie samorozwój i samodzielną organizację. Kiedy nie wygłasza prelekcji ani nie programuje, Ian oddaje się swoim pasjom związanym z parserami, metaprogramowaniem i językami dziedzinowymi.


Udostępnij ten artykuł
Następny temat

Zalecane lektury

Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.

Ilustracja DevOps

Społeczność DevOps

Ilustracja DevOps

Ścieżka szkoleniowa DevOps

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up