,
4 minuty czytania
Wiedza jest cenna, ale jej prawdziwa moc tkwi w tym, jak ją wykorzystujemy. W Freyr Digital znaliśmy DevOps, związane z nim praktyki i to, jak mógłby przekształcić naszą organizację w wydajną potęgę w rozwoju produktów – zdolną do dostarczania wysokiej jakości produktów i rozwiązań naszym klientom z branży nauk przyrodniczych. Rozpoczynając naszą podróż, położyliśmy solidne fundamenty, ale aby naprawdę stać się potęgą w rozwoju, wiedzieliśmy, że musimy przyjąć bardziej strategiczne i adaptacyjne podejście.
Główne wyzwanie w przekształceniu wiedzy w działanie polega na wiedzy, kiedy podjąć właściwe kroki. Ponieważ działania wpływają na wiele osób w organizacji, robienie właściwych rzeczy we właściwym czasie zależy od naszej pozycji jako organizacji, naszych obecnych procesów i praktyk oraz umiejętności i zdolności naszych pracowników.
To był punkt zwrotny w naszej transformacji. Jako portfolio dostawców oprogramowania specjalizujących się w niestandardowych rozwiązaniach, mieliśmy oddany zespół, który wkładał dodatkowy wysiłek w dostarczanie wyników. Dostrzegliśmy jednak możliwość poprawy jakości, zwiększenia produktywności i przyspieszenia przekształcania wymagań biznesowych w gotowe produkty. Zamiast skupiać się na poprawkach w ostatniej chwili, dążyliśmy do przejścia od reaktywnego rozwiązywania problemów do proaktywnej innowacji, budując skalowalne, wysoce efektywne rozwiązania.
Mieliśmy wizję tego, gdzie chcemy być – jak chcemy pracować, rozwijać, testować, wdrażać i wydawać oprogramowanie. Wiedzieliśmy jednak, że osiągnięcie tych celów wymaga przemyślanej strategii, ciągłego uczenia się i zaangażowania w doskonalenie.
Przechodząc do dnia dzisiejszego: w ciągu ostatniego roku zrealizowaliśmy ponad 100 wydań z niemal zerową liczbą błędów wdrożeniowych i osiągnęliśmy niemal pełną automatyzację we wprowadzaniu zmian. Ponadto odnotowaliśmy znaczny postęp w przychodach, stworzyliśmy bardziej elastyczne i zwinne zespoły oraz ogólnie zbliżyliśmy się do naszej wizji stania się potęgą w dziedzinie produktów, rozwiązań i usług oprogramowania. Chociaż zawsze jest więcej do osiągnięcia, jesteśmy przekonani, że położyliśmy solidne fundamenty i jesteśmy gotowi przyspieszyć.
Idąc naprzód, poświęcamy chwilę na refleksję nad naszą transformacją – co zadziałało, co nie, i jakie lekcje wyciągnęliśmy. Dzieląc się naszą podróżą, mamy nadzieję wesprzeć innych, którzy mierzą się z podobnymi zmianami.
Ta seria blogów ma głównie charakter empiryczny, dzieląc się tym, co zrobiliśmy, jednocześnie łącząc nasze działania z najlepszymi praktykami i zaleceniami z różnych źródeł DevOps i Agile.
Robienie właściwych rzeczy we właściwym czasie
Jednym z kluczowych aspektów naszej transformacji było zidentyfikowanie właściwych działań we właściwym czasie. Przy wielu możliwych inicjatywach potrzebowaliśmy ustrukturyzowanego podejścia, aby zapewnić znaczący postęp.
Patrząc wstecz, możemy pogrupować te działania w trzy kategorie: Narzędzia i Procesy, Architektura Oprogramowania oraz Ludzie. Te kategorie są ze sobą ściśle powiązane, a zmiany w jednej wpływają na pozostałe. Jednakże możliwe było stopniowe wprowadzanie zmian w każdej kategorii i mierzenie postępów w realizacji naszych ogólnych celów.
Inicjatywy w tych kategoriach często były od siebie zależne. Zmiany w jednym obszarze otwierały możliwości dalszych usprawnień w innym.
Pierwsze Kroki
Aby stworzyć solidne podstawy, skupiliśmy się na trzech kluczowych inicjatywach:
- Integracja naszych baz kodu źródłowego z SonarQube w celu uzyskania metryk jakości kodu.
- Przeniesienie wszystkich zespołów do wspólnego narzędzia do zarządzania wymaganiami, kodem źródłowym i planami testów – w naszym przypadku, Azure DevOps.
- Strukturyzowanie zespołów z jasno określonymi obowiązkami w celu zwiększenia odpowiedzialności i poczucia własności.
Te trzy inicjatywy dały nam wgląd w:
- Wykonywana praca (wymagania i zadania).
- Jakość kodu (metryki SonarQube).
- Zaangażowane osoby (obowiązki zespołu).
Wśród nich, najbardziej wymagające było określenie jasnych obowiązków zespołu. Początkowo struktury zespołów były płynne, a ludzie przemieszczali się między projektami w zależności od potrzeb. Przejście na dedykowane zespoły z wyraźnymi obszarami funkcjonalnymi było niezbędnym krokiem, choć skomplikowanym przez naszą istniejącą architekturę produktu, która nie była w pełni zaprojektowana do wspierania jasnej odpowiedzialności.
Rola architektury oprogramowania
Szybko zdaliśmy sobie sprawę, że architektura produktu jest jednym z najbardziej krytycznych obszarów wymagających zmian. Modułowa architektura była kluczowa dla umożliwienia niezależnym zespołom przejęcia odpowiedzialności za swoją pracę. Bez tego nasze wysiłki na rzecz budowania odpowiedzialności zespołowej miały ograniczony wpływ.
Przebudowa naszego portfolio była złożonym procesem. Obejmowała ona pełne przejście do chmury i rozpoczęcie budowania aplikacji natywnych dla chmury z wykorzystaniem architektury mikroserwisów. Temat ten zostanie omówiony w przyszłym poście. Kluczowym wnioskiem jest jednak to, że zmiany są stopniowe, a niektóre kroki muszą poprzedzać inne, aby odblokować korzyści i dalszy postęp.
Metryki i ciągłe doskonalenie
Po rozpoczęciu prac nad rearchitekturą (trwające przedsięwzięcie) skupiliśmy się na monitorowaniu wskaźników i wyznaczaniu celów:
- Metryki jakości kodu w SonarQube.
- Metryki integracji kodu w Azure DevOps.
- Metryki przepustowości dla poszczególnych zespołów.
- Wdrożenie usług natywnych dla chmury.
Te cele nie były sztywnymi nakazami, lecz celami przewodnimi, które miały pomóc zespołom skoordynować swoje działania.
Wspieranie ludzi
Dzięki wdrożonym metrykom stało się oczywiste, że zespoły potrzebują wsparcia, aby osiągnąć te cele. Na przykład, choć ustalenie celów dla pokrycia testami jednostkowymi i automatyzacji testów API było proste, ich osiągnięcie stanowiło wyzwanie, zwłaszcza w przypadku starszego kodu, który nie został zaprojektowany z myślą o testowalności.
Aby temu zaradzić, my:
- Wyznaczyć niższe cele dla starszego kodu.
- Zorganizowano warsztaty i praktyczne szkolenia z zakresu pisania wysokiej jakości testów jednostkowych oraz projektowania kodu podatnego na testowanie.
- Udzieliliśmy wskazówek dotyczących tworzenia stubów do testowania API.
- Przeprowadzono przeglądy testów jednostkowych przez starszych architektów.
Trójkąt Narzędzi, Architektury i Ludzi
Dobrym przykładem wzajemnego oddziaływania tych kategorii było zarządzanie kodem i repozytorium. Integracja z SonarQube, co stanowiło ulepszenie narzędzi, ujawniła niskie pokrycie testami jednostkowymi, co wskazywało na problemy architektoniczne ograniczające testowalność. Ulepszenia w architekturze i umiejętnościach zespołu doprowadziły do lepszej jakości testów jednostkowych, ale nie były one regularnie wykonywane z powodu złych praktyk rozgałęziania (branching). Rozwiązaliśmy ten problem, standaryzując strategie rozgałęziania i zapewniając regularną integrację kodu z główną gałęzią, co umożliwiło uruchamianie wszystkich testów przez potoki CI.
Właściwa kolejność zmian
Jednym z podejść do transformacji jest bezkrytyczne wdrażanie najlepszych praktyk. Chociaż może to przynieść korzyści, wyniki często nie uzasadniają wysiłku, co prowadzi do frustracji.
Przyjęliśmy inne podejście, oparte na zasadzie przepływu: analizę procesu End-to-End, identyfikację wąskich gardeł i ich stopniowe eliminowanie.
Każde ulepszenie ujawniało nowe wąskie gardła, wymagające dalszych działań. Nie była to gra w „uderz kreta”, lecz celowy proces robienia właściwych rzeczy we właściwym czasie.
Na przykład, nakazanie pokrycia testami jednostkowymi bez poprawy projektu kodu doprowadziłoby do frustracji i „teatru pokrycia” (powierzchownych testów pisanych tylko po to, by spełnić metryki). Zajmując się najpierw architekturą i umiejętnościami, zapewniliśmy znaczący postęp.
Perspektywy
Prawdziwa transformacja to nie jednorazowa, duża zmiana, lecz inteligentne, dobrze zaplanowane decyzje, które napędzają ciągły postęp. Z radością dzielimy się naszym doświadczeniem i wiedzą, aby pomóc innym znaleźć własną drogę do skalowalnych i znaczących zmian.
W nadchodzących blogach z tej serii – DevOps dla Zwycięstwa – omówimy każdą fazę naszej transformacji w Trójkącie DevOps – Narzędzia, Architektura i Ludzie – która pomogła nam osiągnąć trwały wpływ.
