„Najlepsze zespoły programistyczne nigdy nie koncentrują się ani na szybkości, ani na stabilności. Zawsze poprawiają jedno i drugie, bo obie te wartości wzmacniają się nawzajem” – mówił w trakcie CIONET Community Event poświęconego metrykom w IT Jez Humble, który w Google Cloud zajmuje się inżynierią niezawodności.

Jez jest w Polsce doskonale znany jako autor takich książek jak „Metoda Lean Enterprise”, „DevOps” czy „Ciągłe dostarczanie oprogramowania”. W trakcie pasjonującego wystąpienia przekonał nas, że te trzy wielkie zagadnienia łącznie decydują o doskonałości w programowaniu, wskazał jej zasadnicze cztery miary i wskazał sposoby na ich poprawę. Nie były to przy tym uwagi mocno osadzone w praktyce - Jez przedstawił bowiem wnioski z badań, jakie prowadził od sześciu lat wraz z dr. Nicole Forsgren. Miały one przybliżyć odpowiedź na pytanie, jak budować zespoły o wysokiej efektywności.

W trakcie prac udało im się ustalić:

• jak mierzyć efektywność zarówno dostarczania (development), jak i utrzymania (operation) software’u, a w efekcie jak ją podnosić;
• jak mierzyć kulturę organizacyjna i jak ją poprawiać.

Mierzenie wydajności developmentu

Na początku Jez zaznaczył, że podejście do kwestii pomiaru efektywności prac programistycznych całkowicie zmieniło się na przestrzeni ostatnich lat. „Przez długi czas utrzymywało się przekonanie, że efektywność programowania w ogóle się nie liczy. Zmiana nastąpiła wraz z pojawieniem się digital natives. Nagle efektywność programowania nabrała znaczenia.”

Wyniki badań prowadzonych przez Jeza i Nicole jasno pokazują, dlaczego efektywność jest ważna. „Najlepsi w kategoriach efektywności programiści dwa razy częściej niż pozostali osiągali lub przekraczali cele stawiane przez firmę, wśród nich także cele czysto komercyjne, na przykład zyskowność, produktywność czy udział w rynku oraz niekomercyjne, a więc takie jak satysfakcja klienta, jakość i ilość dostarczanych produktów czy zdolność realizacji misji firmy.”

Autorzy badań sprawdzili, czym odróżniają się od innych najbardziej efektywni pracownicy. W efekcie udało się wskazać cztery metryki z dwóch kategorii istotne zarówno na etapach dostarczania, jak i utrzymania software’u:

• Metryki istotne dla szybkości:
  • częstotliwość wypuszczania produktów,
  • czas od złożenia zamówienia do otrzymania produktu (lead time),
• Metryki istotne dla stabilności:
  • współczynnik awarii przy zmianach,
  • czas potrzebny do przywrócenia działania po awarii.

Z badań przeprowadzonych wśród kilku tysięcy firm (różnej wielkości i z różnych sektorów) z całego świata wynika, że najlepsze zespoły są w stanie nawet kilka razy dziennie udostępniać nowe wersje kodu, po zgłoszeniu konieczności zmian w ciągu jednego dnia kierują nowy kod na produkcję, przywracają działanie w ciągu godziny od wystąpienia przestoju, zaś współczynnik awaryjności zmyka się w przedziale 0-15%. „Po drugiej strony skali mamy zespoły, w których prace ciągną się miesiącami, bo mają duże kolejki dużych projektów oddawanych według zaplanowanej kolejności, bez względu na priorytet. Kiedy dochodzi do awarii w środowisku produkcyjnym, uporanie się z usterka może zając kilka tygodni, a współczynnika awaryjności sięga od 46 do 60%.”

Struktura i kultura organizacji decyduje o sukcesie programistów

Jez bardzo stanowczo podkreślił, że metryki szybkościowe muszą być silnie powiązane ze stabilnościowymi. „Jeśli miałbym wskazać jedną rzecz, którą chciałbym, żebyście zapamiętali z tej prezentacji, to byłoby to: najlepsze zespoły nigdy nie koncentrują się ani na szybkości, ani na stabilności. Zawsze poprawiają jedno i drugie, bo obie te wartości wzmacniają się nawzajem. To układ połączony.”

Te metryki są dodatkowo skorelowane z dostępnością. Jez zwrócił uwagę na ten czynnik dopiero w ostatnich dwóch latach, kiedy udało się stwierdzić, że najlepsi programiści i specjaliści utrzymania potrafią zapewnić nawet 3,5 x wyższą dostępność.

Warto zauważyć, że informacje do badań były zbierane na poziomie zespołów, a nie całych przedsiębiorstw. „Ze zgromadzonych danych widać, że wewnątrz korporacji są zespoły o bardzo wysokiej efektywności, są też średnie i słabe. Pod tym względem wielkie firmy są bardzo silnie zróżnicowane. Jednak i wielkich organizacjach poddanych silnym regulacjom można znaleźć bardzo wydajne zespoły, jak i w startupach można natknąć się na zespoły o słabej efektywności.”

W swoich pracach Jez sporo miejsca poświęca procesom, które sprawiają, że słabe zespoły się doskonalą i podnoszą efektywność aż do wysokiego poziomu na skali. Prowadzone analizy pozwoliły wskazać cztery czynniki na poziomie struktury i kultury organizacji, które umożliwiają taką ewolucję:

• dostarczanie w trybie ciągłym,
• „szczupłe” zarządzanie i rozwój produktów,
• kultura nastawiona na wypełnianie misji przy zapewnieniu bezpieczeństwa psychologicznego,
• autonomiczne zespoły łączące różne funkcje.

Dostarczanie musi być nudne

Jez dokładniej przyjrzał się kwestii dostarczania w trybie ciągłym. Wskazał kilkanaście praktyk, które pozwalają osiągnąć taką sprawność w budowie kodu, m.in. automatyzację testów i testowanie ciągłe, automatyzację wdrożeń, kontrolę wersji, zarządzanie poprawkami w bazach danych czy decyzyjność zespołu. „W dostarczaniu ciągłym chodzi o to, żeby dostarczać w sposób przewidywalny i wręcz nudny. Dostarczanie software’u na produkcję powinno być zajęciem nudnym, o małym ryzyku, które można wykonać w dowolnym czasie, a więc także w normalnych godzinach biurowych.”

Jest to zasada prosta i znana od lat, jednak jej wprowadzenie wcale nie jest łatwe i wiele organizacji ciągle nie potrafi tego zrobić. Ale przykład tych, którzy potrafili w ten sposób ustawić proces dostarczania – tu Jez wskazał bank HSBC oraz projekt amerykańskiej administracji federalnej dotyczący platformy usługowej dla armii – dowodzą, że jest to możliwe do osiągnięcia w każdej organizacji, bez względu na jej wielkość czy dotyczące jej wymagania regulacyjne.

Wprowadzenie praktyk ciągłego dostarczania ogranicza kłopoty przy wdrożeniu i zmęczenie zespołu – przekonywał Jez. Prowadzi też do podniesienia kultury organizacyjnej, a ta znowu przekłada się tak na efektywność działu developmentu, jak i całej organizacji.

Bezpieczeństwo wbudowane w programowanie

Jez zwracał uwagę, że obecnie poprawa efektywności dostarczania oprogramowania nie jest możliwa bez uwzględnienia kwestii bezpieczeństwa na wczesnym etapie prac programistycznych. „Zwykle dział developmentu coś buduje i przekazuje to dalej do przetestowania. W kolejnych etapach produkt trafia do działu bezpieczeństwa, żeby zbadać istnienia ewentualnych zagrożeń. To, co powinieneś zrobić, to dać programistom narzędzia i zdolność do wbudowania jakości bezpośrednio w produkt, zamiast przekazywać problem do rozwiązania w kolejnych etapach. Tu w gruncie rzeczy chodzi o budowanie zwrotnych pętli informacyjnych. Programiści powinni móc od razu wykryć problem, a nie czekać tygodniami albo i miesiącami na wyniki testów.”

Automatyzacja testów może być sposobem na skrócenie pętli z informacją zwrotną. „Zasadniczą metryką, która określa naszą zdolność w tym zakresie jest czas od zlecenia do produktu [lead time]. Jest on trudny do zmierzenia i wiele organizacji w ogóle tego nie robi. Na początek warto sobie postawić pytanie: jak długo w mojej organizacji zmiana produktu ograniczająca się tylko do jednej linii kodu.”

Lead time nie tylko jest jedną z czterech najważniejszych metryk efektywności wymienionych przez Jeza na początku. „Organizacje, które osiągają w niej dobre wyniki, nieźle radzą sobie także z kolejną główną miarą, czyli czasem potrzebnym do przywrócenia działania po awarii, a zwykle także z dostępnością usług.”

Znaczenie metryki dotyczącej czasu przywrócenia rośne wraz z liczbą ataków, które zdaniem Jeza, są nieuniknione. „Będziesz na nie narażony. Nie sposób tego uniknąć, ale to nie znaczy, że nie powinieneś podejmować wysiłku, aby zapobiec zagrożeniu. Musisz po prostu zaakceptować fakt, że porażki nie da się uniknąć. Pytanie brzmi: jak szybko będziesz w stanie znaleźć podatność i ją załatać.”

Badania dowodzą, że potrzebną szybkość reakcji można budować włączając bezpieczeństwo w proces developmentu. „Wymaga to zmiany roli działu bezpieczeństwa, który nie może już pilnować bezpieczeństwa na końcu procesu produkcji, ale musi pomóc developmentowi wbudować bezpieczeństwo w produkt. Można do tego wykorzystać testy bezpieczeństwa uwzględniane w różnych etapach procesu wytwórczego, korzystanie z zaufanych i zatwierdzonych do użycia bibliotek, udostępnianie dodatkowych narzędzi.”

Autonomiczne zespoły przynoszą zmianę w programowaniu

Jez podkreślił znaczenie architektury w budowaniu efektywności developmentu. Architektury nie można przy tym sprowadzać do kwestii wyborów technologicznych. Dotyczy ona także sposobu organizacji procesów. Jez postawił pięć pytań ważnych w kontekście efektywności zespołów programistycznych, ich zdolności do dostarczania w trybie ciągłym:

• Czy zespół może dokonać dużych poprawek do sytemu bez uzyskania pozwolenia z innych działów?
• Czy zespół jest w stanie wykonać tę pracę bez szczegółowych konsultacji i skoordynowania z innymi działami?
• Czy zespół może przygotować i wdrożyć potrzebne rozwiązanie niezależnie od systemów powiązanych?
• Czy zespół jest w stanie przetestować swój system bez angażowania całego zewnętrznego środowiska testowego?
• Czy zespół może przeprowadzić konieczne wdrożenie w normalnych godzinach pracy, jeśli nie wprowadza to istotnych niedogodności?

Twierdzące odpowiedzi na te pytania są powiązane ze strukturą organizacyjną i architekturą korporacyjną, a nie z konkretnymi technologiami. Z punktu widzenia efektywności prac programistów nie ma znaczenia, czy pracują oni na mainframe’ach czy na mikrousługach – stwierdził Jez.

A skoro to nie wykorzystywane technologie, ale struktura i architektura silnie przekładają się na efektywność procesu dostarczania oprogramowania, warto sprawdzić, jak wygląda nasze porównanie z innymi organizacjami. Na stronie cloud.gogle.com/devops można znaleźć wyniki badań, przedstawionych przez Jeza wraz ankietą, która pozwoli dokonać porównania w czterech metrykach istotnych dla szybkości i stabilności developmentu.