Model kompetencyjny i budowanie zespołów w DevOps

Tradycyjny model budowania organizacji

Zacznijmy od porównania modelu tradycyjnego z podejściem DevOps. W dużych firmach o ugruntowanej pozycji rynkowej wciąż dominuje model silosowy, w skład którego wchodzą różne grupy pracowników:

• Grupa architektów oprogramowania, którzy tworzą wizję, jej poszczególne elementy i planują interakcje między nimi.
• Developerzy, których zadaniem jest implementowanie proponowanych przez architektów funkcjonalności, w miarę możliwości zgodnie z ich wizją.
• Testerzy, którzy testują rozwiązania wypracowane przez zespół developerski i jeśli zachodzi taka konieczność, odsyłają rozwiązania do dalszych prac i poprawek.
• Leader zespołu, którego zadaniem jest podjęcie decyzji, czy przetestowane i poprawione rozwiązanie może zostać wdrożone na produkcję.
• Zespół operacyjny (Operations), który po decyzji leadera przeprowadza wdrożenie danego produktu lub funkcjonalności.

W wielu przypadkach tradycyjne podejście oznacza brak elastyczności. Projekty i wdrożenia przeciągają się na długie miesiące – często zdarza się, że nawet gdy developerzy szybciej skończą pisanie danego rozwiązania, wciąż potrzebne są tygodnie testów i poprawek. W rezultacie wynik mocno odbiega od pierwotnej wizji architektów. Każde przekazanie procesu do innego zespołu oznacza utratę informacji i wymaga osobnego planowania, priorytetyzowania, koordynowania i weryfikacji. Prowadzi to do opóźnień i nierzadko konfliktów między zespołami.

Organizacje o wysokiej przepustowości

High-performing organizations, czyli wydajne organizacje o wysokiej przepustowości, to zupełne przeciwieństwo modelu tradycyjnego. Zamiast przekazywania projektu między zespołami, całość procesów realizowana jest w obrębie jednego teamu, który jest w stanie szybko i elastycznie reagować na zmiany. Oczywiście zespół DevOps wciąż kieruje się wizją architektury rozwiązania, wynikającą z celów biznesowych projektu, nie ma jednak odrębnego teamu, który tę wizję projektuje. Rola architekta istnieje po prostu w zespole DevOps. Architektem może być jeden z najbardziej doświadczonych developerów, który dba o to, aby projektowane rozwiązanie było zgodne z tym, co ustalono z osobami o podobnej roli. W zespole nie ma też odrębnej grupy testerów. Zamiast tego w teamie znajdują się osoby realizujące inne role, ale również potrafiące testować funkcjonalności. Mogą one na każdym etapie pokazywać innym, jak testować rozwiązanie zanim jeszcze ono powstanie. W takim zespole naturalnie wybrana zostaje osoba ponosząca odpowiedzialność za poprawne wdrożenie usługi. Podsumowując, cały zespół DevOps tworzy i jest odpowiedzialny za tzw. pipeline, czyli wszystkie czynności prowadzące do zrealizowania wdrożenia. Zazwyczaj elementem wspierającym pracę zespołu DevOps jest środowisko chmurowe.

Większość organizacji, które wdrożyły DevOps w swoich strukturach, zdecydowanie potwierdza, że zmiana podejścia skróciła czas wdrożenia nowych usług i funkcjonalności. To, co w strukturze silosowej trwa miesiące, DevOps jest w stanie skrócić do nawet kilku czy kilkunastu godzin przede wszystkim dlatego, że w dużej mierze wyeliminowany jest etap przekazywania prac do innych zespołów.

Kluczowe cechy zespołu DevOps

Aby w pełni wykorzystać możliwości, które daje podejście DevOps, kluczowe jest zbudowanie zespołu posiadającego odpowiednie kompetencje. Najczęściej pożądane to:

1. kompetencje techniczne:
   - umiejętność projektowania architektury systemu;
   - optymalizacja wartości biznesowej;
   - analiza biznesowa;
   - testowanie;
   - programowanie;
   - Continuous Delivery;
   - security, czyli testy bezpieczeństwa i ryzyka;
   - infrastruktura i jej budowanie.
2. kompetencje miękkie:
   - odwaga do podjęcia proaktywnego działania, eksperymentowania, a nawet ponoszenia porażek;
   - umiejętność pracy w zespole w zróżnicowanym środowisku;
   - przywództwo DevOps’owe – ciągłe przypominanie celu, którym jest jak najszybsze i jak najlepsze dostarczenie wartości dla klienta końcowego;
   - Continuous Improvement, czyli ciągłe doskonalenie i uczenie się na błędach.

Często organizacje zakładają, że to twarde umiejętności decydują o sukcesie zespołu DevOps. Oczywiście są one istotne, aby osiągnąć maksymalną wydajność. Im jednak bardziej dojrzała organizacja, tym większą uwagę zwraca na umiejętności miękkie. To one są trudniejsze do przyswojenia i to one nierzadko decydują o sukcesie bądź porażce projektu.

Skąd wiadomo, że zespół DevOps działa efektywnie?

Organizacja, która podejście DevOps wdrożyła poprawnie, to zwykle organizacja o wysokim poziomie dojrzałości. Gdy mówimy, że zespół DevOps jest skuteczny i działa efektywnie, oznacza to, że:

• Wszyscy członkowie zespołu rozumieją podejście DevOps i przynajmniej na podstawowym poziomie opanowali dwanaście wyżej wymienionych cech – osiem kompetencji twardych i cztery miękkie. Nieważne czy dana osoba jest programistą, administratorem, czy testerem – powinna przynajmniej na podstawowym poziomie rozumieć wszystkie elementy składowe modelu.
• Każdy członek zespołu jest dodatkowo ekspertem w swojej macierzystej dziedzinie i jest w stanie skutecznie proponować i wdrażać najlepsze rozwiązania, które leżą w jego obszarze kompetencji.
  Umiejętnością, która cechuje najlepszych leaderów i rekruterów jest zbudowanie takiego zespołu, w którym ludzie ze swoimi profilami i charakterami doskonale uzupełniają się na różnych warstwach. I to właśnie jest największym wyzwaniem budowania nowoczesnych zespołów i jednocześnie kluczem do budowania organizacji o dużej przepustowości.

Problemy organizacji zmierzających w stronę podejścia DevOps

Jak już wspomniano, są różne poziomy dojrzałości organizacji. Każda organizacja, która chce się rozwijać, prędzej czy później napotyka problemy. Im bardziej rozwinięta organizacja, tym problemy są bardziej złożone i trudniejsze do rozwiązania. Zaczyna się zwykle od stosunkowo prostych kwestii – np. tworzenie środowisk zajmuje zespołowi zbyt dużo czasu. Gdy ten problem uda się rozwiązać, okazuje się, że problematyczny jest sprawny deployment kodu, który zespół wcześniej przeprowadzał manualnie, a wraz z rozwojem firmy chce możliwie najbardziej go zautomatyzować. Na kolejnych etapach pojawiają się trudności z wdrożeniem i utrzymaniem testów czy tzw. zabetonowana architektura – przez to, że zespoły pracują w silosach niezależnie od siebie, większe zmiany nie mogą być wdrażane zwinnie, tylko zbiorczo, w sposób monolityczny. Im bardziej zaawansowane problemy dotykają organizację, tym szybciej rośnie świadomość potrzeby zmiany. Zmienia się kultura organizacji i coraz bardziej dostrzegana jest potrzeba wprowadzenia wysokiej przepustowości, czyli wdrożenia podejścia DevOps. Dodatkowo im problemy są bardziej zaawansowane, tym szybciej leaderzy zauważają potrzebę kształtowania kompetencji miękkich – najczęściej problemy wymagające zmiany mindsetu są znacznie trudniejsze do rozwiązania, niż problemy wynikające z technicznych braków.

Podsumowanie

Pamiętajmy przede wszystkim, że wbrew powszechnym opiniom, DevOps to nie nazwa zespołu. To podejście, sposób prowadzenia firmy, który zakłada, że zespoły składają się z ludzi mających szerokie kompetencje we wszystkich wymaganych obszarach, a jednocześnie będących ekspertami w swojej dziedzinie. Tylko takie zespoły są w stanie zwinnie tworzyć dopasowane rozwiązania. W przeciwieństwie do rozwiązań silosowych, organizacje DevOps nie zamykają się na zmiany, są elastyczne i potrafią zagospodarować procesy na najwyższym poziomie i bez opóźnień. Rolą leaderów jest więc albo znalezienie odpowiednich osób, albo próba przeorganizowania struktury z silosowej do DevOps.

Wpis został zrealizowany na podstawie webinaru "Model kompetencyjny ludzi i budowanie zespołów w DevOps".