Znalezienie firmy, która w 2022 roku nie ma żadnych doświadczeń związanych z praktycznym wykorzystaniem zwinnych metod w budowaniu rozwiązań cyfrowych, jest niezwykle trudne. Dyrektorzy departamentów IT od lat z powodzeniem eksperymentują z metodami, takimi jak Scrum czy Kanban, w ramach swoich obszarów. Chociaż adaptacja zwinnego podejścia w technologii szybko przynosi wymierne korzyści, to najczęściej okazuje się, że zespoły wciąż mierzą się z licznymi ograniczeniami.
Jako przykład można podać utrzymanie klasycznego procesu wytwórczego i bramek decyzyjnych, nieadekwatny i przestarzały model budżetowania, brak dialogu między technologią a produktami (silosy funkcjonalne) czy wirtualną strukturę organizacyjną, która nie odpowiada liniom raportowania w zespołach wielofunkcyjnych.
Coraz bardziej widocznym trendem, który odpowiada na te wyzwania, jest zwinna transformacja całej organizacji, która nierozerwalnie wiąże się z przedefiniowaniem większości aspektów funkcjonowania jednostki. Aby przejść efektywnie przez proces zmiany i zrealizować postawione cele transformacji, należy przedsięwziąć wiele działań obejmujących m.in.: zaprojektowanie nowej struktury organizacyjnej, przemodelowanie procesów wewnętrznych, kreowanie świadomych zmian kulturowych oraz wykorzystanie nowoczesnych rozwiązań technologicznych, na których skupiamy się w tym artykule.
Dzisiejsze firmy wytwarzające oprogramowanie możemy śmiało porównać do fabryk, które angażują często setki osób (programistów, inżynierów oprogramowania, architektów itd.) w produkcję rozwiązań IT. Zmuszone są one optymalizować procesy SDLC (Software Delivery Lifecycle), w celu uzyskania jak najwyższej wydajności i jakości, ale również odpowiadają tym samym na coraz trudniejszą sytuację związaną z pozyskiwaniem ekspertów. Tutaj kluczową rolę odgrywa podejście DevOps.
Artur Kożuch, Manager, Agile & Digital Transformation Leader
Prawdziwie, wielofunkcyjne zespoły
Regularnie obserwujemy, że zwinne zespoły zbudowane jedynie w ramach obszaru IT płynnie poruszają się w wydarzeniach Scrum (Scrumevents), mają przewidywalną prędkość (velocity), perfekcyjnie rozumieją zwinne wartości, a samoorganizację mają zapisaną w swoim DNA. Niestety, bardzo często podczas głębszej analizy okazuje się, że całościowy proces wytwórczy nie jest efektywny. Najczęściej wynika to z faktu, że Właściciel Produktu (Product Owner) jest osobą pochodzącą ze świata technologii, która świetnie rozumie budowany produkt od strony technicznej, ale nie posiada budżetu, wizji, jest odcięta od klienta końcowego oraz nie ma pełnej decyzyjności. Nawet jeżeli zespół posiada Właściciela Produktu, który ma takie cechy i możliwości, to często funkcje związane z zarządzaniem produktem, wycenami czy marketingiem są ulokowane w ramach innych obszarów firmy.
Osiągnięcie prawdziwej zwinności jest możliwe, kiedy pracując w modelu BizDevOps, maksymalnie skrócimy dystans pomiędzy kompetencjami biznesowymi oraz technologicznymi. Dlatego podczas zwinnej transformacji niezwykle istotne jest, aby w sposób optymalny zaprojektować naszą docelową strukturę organizacyjną, szczegółowo analizując kompetencje osób, które powinny pracować razem.
Korzyści z posiadania funkcji biznesowych, operacyjnych i technologicznych w ramach jednego zespołu przewyższają koszty wprowadzenia takiej zmiany i przejawiają się m.in. w: zorientowaniu na wspólnych celach, wspólnej odpowiedzialności, ciągłym walidowaniu potrzeb użytkownika, regularnym zbieraniu informacji zwrotnej (feedback), szybkiej wymianie wiedzy, sprawnym podejmowaniu decyzji, elastyczności we wprowadzaniu usprawnień czy też większej przestrzeni na innowacje i eksperymenty.
DevOps rozumiane jest jako wiele praktyk lub kultura pracy, mająca na celu usprawnienie współpracy zespołu deweloperskiego (Development) oraz utrzymaniowego (Operations). Największą popularność zyskały takie praktyki jak CI (Continuous Integration) i CD (Continuous Delivery lub Continuous Deployment), które skupiają się na automatyzacji i powtarzalności kluczowych elementów procesu wytwórczego.
Arkadiusz Kamrowski, Enterprise Architect, DevSecOps Architect and Transformation Leader
Od monolitycznego rdzenia po mikroserwisy i usługi
Jednocześnie ze zwinną transformacją części biznesowej organizacji ewoluować musi również architektura i technologia. Wiele firm rozpoczyna od pojedynczych, monolitycznych systemów wspierających kluczowe procesy i produkty firmy. Architektura tego typu sprawdza się doskonale w przypadku małych organizacji, wąskich dziedzinowo oraz realizujących małe projekty, które nie wymagają częstych zmian.
Wyzwanie dla tego typu architektury pojawiają się w chwili, gdy rośnie liczba procesów i produktów, które system ma obsługiwać. Wiąże się to z coraz większą liczbą zespołów równolegle pracujących na bazie danego systemu, jak również dynamicznie go zmieniających do potrzeb biznesowych. W takiej sytuacji pojawia się często konieczność częstego zatrzymywania systemu na potrzeby wdrożeń nowych funkcji, co bezpośrednio ogranicza ciągłość biznesową, sam system staje się też wąskim gardłem, którego potencjalna awaria znacząco wpływa na działanie całej bądź znacznej części organizacji.
W tej sytuacji z pomocą przychodzi architektura oparta na modelu usługowym, w szczególności na mikroserwisach. Ma on wiele zalet, dla których warto rozważyć go w swojej organizacji, zwłaszcza wtedy, gdy planujemy szybki rozwój.
Mikroserwisy to również wysoka wydajność i skalowalność, bo każdy dobrze zaprojektowany komponent możemy uruchamiać w wielu niezależnych instancjach zgodnie z potrzebami biznesowymi. Skuteczność zastosowania tego wzorca architektonicznego wynika jednak w dużej mierze z odpowiednio zaprojektowanej architektury i zakresu funkcjonalnego każdej z usług, co umożliwi dalszy, dynamiczny rozwój i kontrolę długu technologicznego.
Ale nie jest to model pozbawiony wad. Przede wszystkim jest znacznie bardziej skomplikowany i złożony pod kątem architektury, trudniejszy w kontroli komunikacji i transakcyjności, analizie potencjalnych problemów, czy zapewnieniu wydajności i wymaganego poziomu bezpieczeństwa, potrzebuje też znacznie wyższych kompetencji. Zmiany ogólne, takie jak dostosowanie do regulacji czy aktualizacja technologii, stanowić potrafią nie lada wyzwanie.
Ma on jednak także wiele zalet, dla których warto rozważyć jego wdrożenie w swojej organizacji. Jest bardzo elastyczny pod względem doboru technologii, a wprowadzane zmiany nie wymagają zatrzymania firmy i są często niedostrzegalne przez użytkownika końcowego.
Korzyści z posiadania funkcji biznesowych, operacyjnych i technologicznych w ramach jednego zespołu przewyższają koszty wprowadzenia takiej zmiany i przejawiają się m.in. w: zorientowaniu na wspólnych celach, wspólnej odpowiedzialności, ciągłym walidowaniu potrzeb użytkownika, regularnym zbieraniu informacji zwrotnej (feedback), szybkiej wymianie wiedzy, sprawnym podejmowaniu decyzji, elastyczności we wprowadzaniu usprawnień czy też większej przestrzeni na innowacje i eksperymenty.
Automatyzacja dostarczania oprogramowania
Dzisiejsze firmy wytwarzające oprogramowanie możemy śmiało porównać do fabryk, które angażują często setki osób (programistów, inżynierów oprogramowania, architektów itd.) w produkcję rozwiązań IT. Zmuszone są one optymalizować procesy SDLC (Software Delivery Lifecycle), w celu uzyskania jak najwyższej wydajności i jakości, ale również odpowiadają tym samym na coraz trudniejszą sytuację związaną z pozyskiwaniem ekspertów.
Tutaj kluczową rolę odgrywa podejście DevOps, rozumiane jako szereg praktyk lub kultura pracy, mająca na celu usprawnienie współpracy zespołu deweloperskiego (Development) oraz utrzymaniowego (Operations). Największą popularność zyskały takie praktyki jak CI (Continuous Integration) i CD (Continuous Delivery lub Continuous Deployment), które skupiają się na automatyzacji i powtarzalności podstawowych elementów procesu wytwórczego.
Ostatnio coraz popularniejsze staje się też podejście DevSecOps, będące swoistym uzupełnieniem DevOps o aspekt bezpieczeństwa (Security), pozwalające na kompleksową weryfikację dostarczanego rozwiązania, optymalizując przy tym współpracę, wzajemne zrozumienie i wymianę informacji pomiędzy zespołami utrzymaniowymi, deweloperskimi i bezpieczeństwem.
Bardzo ważną rolę odgrywają dostępne narzędzia wspierające automatyzację całego procesu, których rynek dostarcza obecnie bardzo dużo. To m.in. orkiestracja, testy SAST, DAST, zarządzanie artefaktami czy statyczna analiza kodu. Kluczowy jest jednak taki ich dobór, aby zanadto nie skomplikować procesu, a zarazem zapewnić jego uniwersalność i kompleksowość, zgodnie z technologiami wykorzystywanymi wewnątrz organizacji.
Infrastruktura oparta na cloud computingu i kontenerach
Ostatnim, nie mniej ważnym tematem jest zastosowanie możliwości chmury obliczeniowej (cloud computing) w obszarze infrastruktury jako alternatywy dla powszechnie używanych rozwiązań on-premise. Nieodzownymi zaletami rozwiązań chmurowych jest ich elastyczność, możliwość automatycznego skalowania i prostota, pozwalające praktycznie każdemu tworzyć własne aplikacje, a firmom na skupienie się na najważniejszych działaniach, przekazując część prac związanych z utrzymaniem w ręce dostawców rozwiązań chmurowych. W zależności od zakresu odpowiedzialności, jaką chcemy powierzyć dostawcy chmurowemu, skorzystać możemy z rozwiązań typu IaaS (Infrastructure as a Service), PaaS (Platform as a Service) lub SaaS (Software as a Service).
Warto również wspomnieć o konteneryzacji, która w sposób szczególny wspiera skalowalność, przenośność (portability), wydajność i separację poszczególnych instancji. Kontenery doskonale współpracują w środowisku chmurowym, niezależnie od dostawcy, dzięki czemu ich migracja ze środowiska jednego dostawcy do innego jest ćwiczeniem wyjątkowo prostym oraz chroni organizację przed uzależnieniem się od konkretnego dostawcy (vendor lock-in).
Podsumowując, na zwinność i odporność biznesową organizacji składa się wiele czynników. Począwszy od czysto organizacyjnych i kulturowych, po technologiczne, które skutecznie zastosowane, coraz częściej stanowią o dynamice i możliwościach rozwoju firmy. Aby przetrwać i nadal szybko się rozwijać, musimy pamiętać o każdym elemencie, a technologię traktować jako szansę i wsparcie, a nie zbędny koszt.
Artur Kożuch, Manager, Agile & Digital Transformation Leader
Arkadiusz Kamrowski, Enterprise Architect, DevSecOps Architect and Transformation Leader