Jak za pośrednictwem DevOps poprawić elastyczność i efektywność pracy zespołów projektowych?
Przez ostanie kilka lat obserwowałem wiele zespołów programistycznych, a także złożonych organizacji, w których IT było jednym z elementów systemu wartości biznesowej dostarczanej dla klientów końcowych. Każda z tych organizacji borykała się z typowymi problemami związanymi z długim czasem dostarczania zmian, stosunkowo dużą ilością błędów, a także zaniepokojeniem interesariuszy projektu związanym z brakiem elastyczności w dostosowywaniu systemu na każdym z etapów cyklu życia (ze względu na zmieniające się priorytety i otoczenie biznesowej).
Obserwacje te skłoniły mnie do poszukiwania rozwiązania i tak właśnie napotkałem DevOps jako metodykę i fundament dla IT i Biznesu. DevOps (a miejscami DevSecOps) może stanowić fundament do wdrażanie innych rozwiązań organizacyjno-procesowych nastawionych na poszczególne lokalne obszary lub zakresy odpowiedzialności.
Utrzymanie rozwiązań informatycznych, rozwój oprogramowania i tworzenie nowych systemów można zorganizować na wiele różnych sposobów. Na rynku IT mamy dostępny zróżnicowany wachlarz ram procesowych i metodyk zarządzania, które z powodzeniem można wykorzystać do tego celu. Jednakże większość odnosi się do specyficznych obszarów lub kroków cyklu życia, a niewiele rozpatruje tę kwestię z perspektywy holistycznego podejścia. Kierunki rozwoju, które zostały wyznaczone przez transformację cyfrową, chmury obliczeniowe, zarządzanie danymi i sztuczną inteligencje zmuszają zespoły do ciągłego wdrażania usprawnień na polach technologicznych, jakościowych, a także optymalizacji kosztów i poprawy efektywności.
Tempo pracy, a także rosnące wymagania biznesowe zmuszają zespoły do zmiany myślenia o sposobach wytwarzania rozwiązań. Niejednokrotnie zauważyć można wielość metodyk zwinnych lub tradycyjnych, które na koniec dnia i tak kończą się podobnymi problemami na poziomie operacyjnym lub zarządzania zespołami. Dlatego też budowa efektywnego IT i utrzymanie dobrych relacji partnerskich z właścicielami systemów stawia nowe wyzwania w obszarze optymalizacji modeli pracy i efektywności kosztowej. Zmiana ta nie może skutkować tylko punktowym wprowadzeniem usprawnienia w obszarze lokalnym, a raczej skupić się powinna na globalnym spojrzeniu na problem i stworzeniu takich struktur organizacyjnych i procesowych, aby możliwe były płynne dostosowywanie się do zmieniających się oczekiwań biznesowych, jak i nowych możliwości pojawiających się na runku.
DevOps jest jednym z lepszych rozwiązań procesowo-organizacyjnych, które z powodzeniem można wykorzystać do budowania fundamentu do dalszych usprawnień i wdrażania metodyk zwinnych lub ich połączenia z tradycyjnym podejście do zarządzania projektami i kontraktami. Model, o którym mowa skupia się na stworzeniu prostej, lecz efektywnej komunikacji pomiędzy poszczególnymi etapami wytwarzania i utrzymywania aplikacji, a także daje podwaliny do ciągłego wdrażania usprawnień i eksperymentowania z różnymi metodykami zwinnymi, które są bardzo popularne w IT. Rozwiązanie to koncentruje się na stworzeniu organizacji, która będzie samowystarczalna pod kątem zarządczym i efektywna w obszarach komunikacyjnych. Zakłada jednocześnie, że zespoły składają się z profesjonalistów odpowiednio wykwalifikowanych, nad którymi nie trzeba nakładać wielu poziomów kontroli, a raczej doprowadzać do sytuacji, w której poszczególni członkowie zespołów mogą uzyskiwać szybkie sprzężenia zwrotne od innych osób, a także ściśle z nimi współpracować.
Zmiana, o której mowa nie będzie prosta i trywialna a sam okres je wdrożenia może zając od kilku tygodni do kilku miesięcy. Pierwsze efekty widoczne są już po kilku tygodniach od rozpoczęcia modernizacji, dzięki czemu obie strony intresariuszy (zespół i decydenci) mają możliwość przekonania się w krótkim czasie, że decyzja podjęta przez nich była słuszna i potrzebna dla całej organizacji.
Wdrożenie rozwiązania jest możliwe do przeprowadzenia w trzech stosunkowo prostych krokach, które będą wymagały odpowiedniej dyscypliny i otwartości od całego zaangażowanego zespołu.
Trzy kroki do nowej rzeczywistości
Krok 1. Przepływ pracy, myślenie globalne, a nie lokalne
Całość powinna skupiać się na rozpoznaniu poszczególnych strumieni wartości biznesowych, które są obsługiwane w zakresie IT od wstępnej definicji wymagań biznesowych aż po operacyjne utrzymanie rozwiązania i dostarczanie wartości do klientów w formie usługi.
W wyniku przeprowadzenia analizy strumieni wartości powstać powinny przepływy pracy z podziałem na poszczególne kluczowe czynności lub działy dla wszystkich zidentyfikowanych typów operacji realizowanych przez te działy. Przepływ prac zawsze powinien wykonywany być tylko w jednym kierunku (z lewej do prawej), co wprowadza możliwość jednoznacznego monitorowania wąskich gardeł w procesie, a także identyfikowania obszarów do usprawnień.
Praca realizowane na pośrednich etapach flow realizowana jest zgodnie z przyjętymi w organizacji standardami, dążąc jednocześnie do minimalizacji WiP, czyli pracy w trakcie, która prowadzona jest równolegle przez tę samą osobę lub grupę zasobów - minimalizujemy równoległość i wielowątkowość. Wykazano również, że odgórne procesowe ograniczenie produkcji w toku do minimum przyspiesza przepływ pracy, ponieważ minimalizuje wielozadaniowość i przełączenie kontekstu.
Usprawnienie komunikacji i przepływu związane jest także ze zmniejszenie "hand-offów" pomiędzy zespołami, tak aby kolejne etapy pracy były wykonywane bez zakłóceń i dodatkowych dużych nakładów na analizę poprzednio wykonanych produktów lub tez poszerzanie wiedzy. Konieczne jest wprowadzenie usprawnień do procesu przekazywania informacji, aby nabyta wiedzy stanowiła podwaliny do dalszej pracy a jej brak lub niepełne informacje nie powinny stanowić blokera w realizacji kolejnego zadania. Tutaj kluczowej jest zaznaczenie istotności realizowanych zadań w taki sposób, aby kolejne etapy w wyniku braku lub niepoprawnej informacji (lub też jej błędnej interpretacji) nie generowały zgłoszeń o wykrytych wadach, które po przeprowadzonej analizie okazują się poprawnie działającym rozwiązaniem.
Całość procesu zakłada przekazywanie do kolejnego etapu produktów pozbawionych wad lub takich, w których to wady nie zostały zidentyfikowane. W chwili wykrycia wady powinna zostać ona naprawiona lokalnie w ramach aktualnie realizowanego etapu pracy.
Optymalizacje realizowane na tym poziomie muszą skupiać się na globalnych zmianach i poprawianiu przepływu pracy. Konieczne jest wdrożenie działań, którym podstawowym celem będzie identyfikowanie i usuwanie ograniczeń i marnotrawstw. Ograniczenia mogą stanowić wąskie garda w przepływach pracy, organizacji poszczególnych etapów czy też wpływać na powstawanie błędów wytwórczych (np. założenia technologiczne lub architektoniczne). Marnotrawstwa natomiast związane są z nadprodukcją, nadjakością, ręcznie wykonywanymi operacjami, heroicznymi pracami w godzinach nocnych lub też ciągłym zmienianiu kontekstu. Realizacja jakikolwiek usprawnień nie powinna być skoncentrowana na małych lokalnych zmian, ponieważ może doprowadzić do negatywnych skutków dla globalnego procesu i degradacji czasów realizacji lub też pogorszenia jakości. Każdą zmianę procesu należy rozpatrywać globalnie i analizować jej skutku dla całości przepływy.
Realizacja pracy w tym kroku powinna być oparta o poniższe trzy podstawowe zasady
1. Praca powinna przepływać tylko w jednym kierunku
2. Nie jest dopuszczalne przenoszenie wad rozwiązania do kolejnego kroku (o ile są zidentyfikowane)
3. Ciągłe poszukiwanie działań zmierzających do usprawnienia przepływu pracy.
Krok 2. Pętla zwrotna
Jest to chyba jeden z trudniejszych etapów, ponieważ po pierwszych sukcesach i euforii dochodzimy do zadań, które zmuszają nas do nagminnego doprowadzania do występowania "szybkich niepowodzeń" - tzn. ciągłego dostarczania rozwiązania do testów i weryfikacji jakościowej tylko po to, aby uzyskać potwierdzenie o zidentyfikowanych wadach lub niejasnościach. Za każdym razem, gdy wprowadzane są czynniki związane z kontrolą jakości i koniecznością przyjęcia krytyki (niejednokrotnie konstruktywnej), konieczne jest rozpatrywanie aspektów dot. budowania świadomości zespołu i motywacji. Z jednej strony sam DevOps jest obszarem procesowym, lecz człowiek i odpowiednia komunikacja w zespole, a także pomiędzy zespołami stanowi krytyczne ogniwo, które nie może zawieść. Dlatego też na tym i kolejnym etapie bardzo ważną rolę odgrywa także kadra zarządzająca i odpowiednie przeprowadzenie poszczególnych zespołów przez kryzysy, które wystąpią na pewno.
Pętla zwrotna to nie są tylko zadania w obszarze testowania oprogramowania, to także wszelkiego typu działania weryfikacyjne w zakresie dokumentacji projektu, specyfikacji zmian, a także wyników przeprowadzenia czynności administracyjnych i operatorskich w ramach wdrażania zmian na nowe i kolejne środowiska. Dlatego też kluczowe jest wprowadzenie kultury cyklicznego przekazywania wniosków, rekomendacji i wspólnego definiowania potencjalnych obszarów do usprawnień. Pętla zwrotna powinna zostać zastosowana jako podstawowe narzędzie komunikacyjne pomiędzy zespołami, bez względu na to, czy są to administratorzy i developerzy, testerzy i deweloperzy czy co rzadsze, lecz bardzo konieczne developerzy i analitycy/przedstawicieiele biznesu. Odpowiednie moderowanie i facylitacja umożliwi konstruktywne podeście do przedstawianego problemu przy jednoczesnej atmosferze ciągłego doskonalenia i dążenia do usprawniania procesów na poziomie globalnym.
Krok 3: Ciągłe eksperymentowanie i nauka
Ostatni krok ma na celu stworzenie kultury ciągłego uczenia się i eksperymentowania w organizacji. Dojrzałe zespoły dostarczające zmiany IT muszą mieć miejsce do tego, aby eksperymentować, wdrażać nowe rozwiązania techniczne w celu poprawienie jakości i efektywności pracy.
Ciągłe uczenie i eksperymentowanie powinno być zatwierdzone i wdrożone w organizację poprzez instytucjonalizację usprawnienia codziennej pracy. Ulepszanie tego, co się robi i za pomocą jakich technik powinno być częścią codziennego myślenia i wezwania do działania. Jednocześnie realizacja tych usprawnień powinna także dążyć do przekształcanie lokalnych odkryć w globalne ulepszenia.
Etap ten często wykształca liderów niosących w organizacji kulturę uczenia się i usprawniania wszystkich czynności dnia codziennego. Jest mało prawdopodobnym, aby uczenie się na poziomie całej organizacji stało się powszechne, chyba ze zostanie ono usankcjonowane i zilustrowane przez przywódców i liderów niosących przykład z zespołów lokalnych.
Podsumowanie
Wdrożenie do organizacji metodyki pracy DevOps może przynieść wiele dobrego na styku z klientem biznesowym, a także w zakresie budowania tożsamości zespołów biorących udział w poszczególnych procesach rozwoju i utrzymania oprogramowania. Realizacja tej zmiany nie jest prosta, choć podział na trzy powyższe kroki wydaje się banalny, to zawsze jak przy każdej zmianie organizacyjnej konieczne jest zwrócenie uwagi na:1. ludzi i zespoły, w których funkcjonują
2. procesy i procedury, jakie obowiązują
3. narzędzia i technologie wykorzystywane.
Nie jest możliwe zaadaptowanie DevOps do naszej organizacji bez krytycznego spojrzenia i pokory w codziennym działaniu. Technokratyczne podejście może, nawet przy najlepszych chęciach, doprowadzić do buntu zespołu i totalnego wywrócenia dotychczasowych dokonań. Dlatego też tak ważnym jest dojrzałe spojrzenie na zmianę i odpowiednie przeprowadzenie jej w organizacji w modelu Top-Down i Bottom-Up.
Literatura:
Podstawowe założenia, o których napisałem w tym artykule, zostały rozszerzone w dwóch poniższych publikacjach (oczywiście jest wiele różnych pozycji książkowych, które warto przeczytaj, jednak ja polecam na start te dwie):1. The DevOps Handbook: : How to Create World-Class Agility, Reliability, and Security in Technology Organizations
2. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 5th Anniversary Edition
Autor:
Cezary Brzozowski