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.


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.


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.


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.


Czy pracujesz w zespole dopasowanym do strumienia?

Odpowiedz na następujące pytania, aby ustalić, czy Twój zespół jest zespołem dopasowanym do strumienia:

Czy celem Twojego zespołu jest ciągłe wydawanie nowych funkcji?
Dojrzałe zespoły wydają produkty wiele razy w tygodniu, a w niektórych przypadkach wiele razy dziennie. Aby tego dokonać, dojrzałe zespoły powinny korzystać z ciągłej integracji i ciągłego dostarczania (CI/CD).

Czy Twój zespół jest w stanie szybko zmienić sposób działania w oparciu o informacje zwrotne (klienta lub wewnętrzne) dotyczące ostatnich modyfikacji?
Często najlepiej jest stosować eksperymentalne podejście do ewolucji produktu. Dojrzałe procesy DevOps obejmują zautomatyzowane testy zapewniające wysoką jakość dostarczanego kodu. Jednak eksperymentowanie nie powinno ograniczać się do testów jednostek czy testów akceptacyjnych. Możesz zadbać o to, by produkty zapewniały klientom największą wartość, korzystając z flag funkcji do automatyzacji przekazywania produktów do określonego podzbioru użytkowników, tworzenia wersji alfa i beta wydań w celu pozyskiwania oraz pomiaru opinii i zachowań użytkowników, a także ciągłego otrzymywania wysokiej jakości informacji zwrotnych poprzez komentarze, zgłoszenia wsparcia i fora społeczności.

Czy Twój zespół przekazuje pracę innym zespołom jedynie w minimalnym stopniu?
Powinno się to sprawdzać pod dwoma względami. Zespół powinien być samowystarczalny, a w pracy powinni brać udział bezpośredni współpracownicy, aby zagwarantować szybką dostawę. Poza zakresem pracy, minimalne przekazywanie obowiązków może także przybierać formę zautomatyzowanych procesów. Automatyzacja cyklu prac programistycznych daje pewność, że realizacja zadań odbywa się bezproblemowo, niezależnie od tego, czy następnym krokiem jest działanie takie jak zautomatyzowany test, scalenie z głównym projektem, czy też kontakt z rzeczywistym człowiekiem.

Dostajesz dodatkowe punkty, jeśli odpowiesz twierdząco na kolejne pytania...
Czy Twój zespół ma czas na zajęcie się zmianami dotyczącymi jakości kodu („dług technologiczny”), aby zapewnić bezpieczeństwo i łatwość zmian?
Dojrzałe zespoły posługują się metodami tworzenia oprogramowania opartego o gałąź główną i praktykami CI/CD w celu utrzymania bazy kodu. Planowanie zdolności produkcyjnych powinno obejmować czas poświęcony na rozwiązanie problemu długu technologicznego. Ponadto projektom o dużej skali, które dotyczą podstawowych problemów związanych z infrastrukturą lub platformą, należy poświęcić tyle samo uwagi, co tworzeniu funkcji.

Czy Twój zespół jest oceniany na podstawie właściwych wskaźników?
Oprócz prędkości, z jaką Twój zespół dostarcza produkty, przy pomiarze jego skuteczności należy również uwzględnić wskaźniki kondycji i jakości technicznej.

Jeśli chodzi o ostatnie pytanie dotyczące mierzenia skuteczności, w przypadku zespołów DevOps tradycyjnie uwzględnia się cztery kluczowe wskaźniki firmy DevOps Research and Assessment (DORA):

  • Częstotliwość wdrażania — jak często organizacja pomyślnie wydaje kod do etapu produkcyjnego
  • Czas wdrażania zmian — ile czasu zajmuje przejście od zatwierdzenia kodu do etapu produkcyjnego
  • Wskaźnik błędnych zmian — procent wdrożeń, które powodują błąd w produkcji
  • Czas przywrócenia usługi — jak długo zajmuje organizacji przywrócenie usług po awarii w wersji produkcyjnej

W Atlassian okryliśmy, że oprócz tych wskaźników określonych przez DORA wysokowydajne zespoły dopasowane do strumienia monitorują również następujące atrybuty:

  • Zrównoważony zespół — Twój zespół ma zróżnicowany zestaw umiejętności i perspektyw
  • Pełnoetatowy właściciel — pełnoetatowy właściciel dba o to, aby główny zespół i uczestnicy obejmujący różne funkcje wiedzieli, komu zadawać pytania i jak podejmować decyzje związane z projektami należącymi do zespołu
  • Powszechne zrozumienie — istnieje powszechne zrozumienie wymagań oraz definicji wartości i wskaźników skuteczności
  • Koncentracja na wartości i wskaźnikach — Twój zespół ma główne cele, zgodnie z którymi realizowane są zadania, aby skutecznie wydawać projekty
  • Weryfikacja koncepcji — dysponowanie prawdziwym artefaktem pozwalającym porównywać i testować założenia pomaga zespołowi w ciągłej iteracji i doskonaleniu
  • Zarządzanie zależnościami w celu utrzymania prędkości — zrozumienie zarządzanych zależności pozwala ograniczyć czynniki hamujące i pomaga zespołowi utrzymać odpowiednią prędkość pracy

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.

Ian Buchanan
Ian Buchanan

Ian Buchanan is a Principal Solutions Engineer for DevOps at Atlassian where he focuses on the emerging DevOps community and the application of Jira, Bitbucket, and Bamboo for better continuous integration and continuous delivery. While Ian Buchanan has broad and deep experience with both Java and .NET, he is best known as a champion of lean and agile practices in large enterprises.

During his career, he has successfully managed enterprise software development tools in all phases of their lifecycle, from cradle to grave. He has driven organization-wide process improvement with results of greater productivity, higher quality, and improved customer satisfaction. He has built multi-national agile teams that value self-direction and self-organization. When not speaking or coding, you are likely to find Ian indulging his passions in parsers, meta-programming, and domain-specific languages.


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

Warsztaty symulacyjne

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up