W jaki sposób Agile i DevOps są ze sobą powiązane?

W jednym narożniku mamy certyfikowanego Scrum Mastera, przez znajomych nazywanego Ekstremalnym programistą, a przez swoje dzieci LeSS SAFe DAD — Agile!

W drugim narożniku prawdziwa maszyna napędowa kultury Lean, zawodnik, który ciągle dostarcza swoją infrastrukturę jako kod, jego lewa pięść nosi imię „Dev”, a prawa „Ops” — przed Państwem DevOps!

Choć posuwam się tutaj do skrajności, chwytliwe hasełka na temat Agile i DevOps mogą tworzyć wrażenie, że są co całkowicie różne koncepcje. Zamieszaniu nie pomaga fakt, że obydwa pojęcia wydają się wymykać definicjom, nawet przy posługiwaniu się ich własnym żargonem i sloganami. Metodyka Agile jest starsza, zatem może jej towarzyszyć mniej niejasności, jednak z pewnością wśród ludzi powszechna jest frustracja związana z funkcjonowaniem niezliczonych definicji DevOps. Brak definicji doprowadził do powstania powszechnych uogólnień.

Nie da się zaprzeczyć historycznym powiązaniom między DevOps i Agile. Gdy na konferencji Agile2008 Conference Patrick DuBois i Andrew Clay Schafer spotkali się podczas sesji poświęconej infrastrukturze Agile, narodziło się połączenie DevOps. Choć Patrick ukuł termin „DevOps” już później, na konferencji Agile Conference nadal upamiętnia się to wydarzenie odrębnym blokiem tematycznym DevOps. Sięgnijmy jednak nieco głębiej poza ramy historyczne i przyjrzyjmy się praktycznym powiązaniom między Agile i DevOps, jakie można dostrzec pod powierzchnią metodyki Scrum i ciągłego dostarczania.

W niektórych zespołach Scrum wyznacza różnicę między ciągłą, frustrującą walką a produktywną, satysfakcjonującą pracą zespołową. W innych Scrum pozwala zastąpić politykę i nadmierne zaangażowanie obiektywnością i skupieniem. Metodykę tę można traktować również jak dogmat. Gdy ograniczenia związane z działalnością lub sama praca wymagają odmiennego podejścia, zespół Agile wykorzysta zasady leżące u podstaw metodyki Scrum, przeanalizuje swoje praktyki i dostosuje je odpowiednio tak, aby były bardziej efektywne. Jest to szczególnie istotne w sytuacji, gdy metodykę Scrum stosuje się poza kontekstem tworzenia oprogramowania.

Członkowie społeczności DevOps posiadający doświadczenie z metodykami Agile potwierdzają, że Scrum jest przydatnym narzędziem do śledzenia zaplanowanych prac. Niektóre prace w zakresie eksploatacji, takie jak wydanie dużej zmiany systemu, przeprowadzenie migracji między centrami danych lub przeprowadzenie uaktualnień systemu, można zaplanować. Jednak większość prac w tym obszarze, na przykład skoki wydajności, przestoje w działaniu systemu czy naruszenia bezpieczeństwa, wiąże się z nieplanowanymi zdarzeniami. Wymagają one natychmiastowej reakcji. Nie można czekać na ustalenie priorytetu pozycji w backlogu ani na kolejną sesję planowania sprintu. W związku z tym wiele zespołów, które zdecydowały się wdrożyć podejście DevOps, wychodzi poza metodykę Scrum, skłaniając się w stronę metodyki Kanban. Umożliwia to śledzenie obu rodzajów prac i pomaga zrozumieć wzajemne relacje między nimi. Bywa również, że zespoły przyjmują podejście hybrydowe nazywane często Scrumban lub Kanplan (Kanban z backlogiem).

Pod wieloma względami kluczem do tak szerokiego przyjęcia metodyki Scrum jest brak zalecanych w niej rozwiązań technicznych. Uproszczone praktyki w zakresie zarządzania, na jakich opiera się Scrum, często stanowią dla zespołu ogromną odmianę. Tam, gdzie kiedyś konkurowały ze sobą priorytety narzucane przez różne źródła, teraz jest jeden zestaw priorytetów w backlogu. A obszary, które do tej pory tonęły pod napływem zbyt dużej liczby prac w toku, teraz zostały objęte planem zamkniętym w ramach czasowych o sprawdzonej wykonalności. Takie połączenie może oznaczać dla zespołu przejście na nowy poziom produktywności. Jednak zespół może mieć też poczucie, że brak rozwiązań technicznych, takich jak przeglądy kodu, zautomatyzowane testy akceptacyjne czy ciągła integracja, ogranicza jego możliwości.

Inne procesy powstałe na gruncie Agile, takie jak programowanie ekstremalne, cechuje silne przekonanie na temat znaczenia rozwiązań technicznych we wspieraniu zdolności zespołu do utrzymywania stałego tempa, a także zwiększaniu przejrzystości i zapewnianiu kadrze kierowniczej i interesariuszom lepszego wglądu. Niektóre zespoły Scrum uciekają się do wprowadzania zadań technicznych do backlogu. Choć takie postępowanie dobrze wpisuje się w wytyczne metodyki Scrum, szybko napotyka praktyczny problem polegający na niewłaściwym podejściu product ownera do funkcji. Jeśli product owner nie dysponuje wysoce rozwiniętymi kompetencjami technicznymi, może nie być w stanie ocenić kosztów/korzyści wynikających z rozwiązań technicznych. Product ownerowi jest jeszcze trudniej, gdy zadania techniczne rozciągają się na obszar eksploatacji związany z niezawodnością, wydajnością i bezpieczeństwem.

W Atlassian zauważyliśmy, że w odniesieniu do obsługiwanych przez nas produktów pomaga wyznaczenie dwóch różnych ról. Nasi product ownerzy dobrze rozumieją funkcje, jakich potrzebują użytkownicy, ale mniej sprawnie radzą sobie z oceną tych funkcji w kontekście możliwości niefunkcjonalnych, takich jak wydajność, niezawodność czy bezpieczeństwo. W związku z tym niektóre produkty SaaS w Atlassian mają również właściciela usługi, czyli osobę odpowiedzialną za ustalanie priorytetów w zakresie tych możliwości niefunkcjonalnych. Od czasu do czasu obydwaj właściciele muszą pójść na kompromis, jednak w większości przypadków prace mogą realizować niezależne zespoły. Być może nie jest to jedyny sposób na „zwiększenie ilości informacji zwrotnych” od zespołów operacyjnych, ale ułatwia przezwyciężenie częstego wśród product ownerów uprzedzenia do funkcji. Takie podejście, oparte na dwóch właścicielach, nie jest jedyną ścieżką prowadzącą do DevOps. Istotne jest traktowanie tych niefunkcjonalnych cech jako „funkcji” i możliwość ich zaplanowania oraz nadania im priorytetów tak samo, jak w przypadku dowolnej funkcjonalnej historyjki użytkownika.

Ostatecznie żaden z argumentów wysuwanych przez krytyków metodyki Scrum nie jest związany nieodłącznie z nią samą. Podobnie jak wszystkie inne metodyki Agile Scrum ma wbudowany mechanizm „doskonalenia procesów” nazywany retrospektywami. W związku z tym istnieją uzasadnione podstawy, aby sądzić, że niektóre zespoły Scrum będą czerpać z koncepcji DevOps jako źródła inspiracji, wykorzystując przy tym retrospektywę właściwą dla Scrum jako okazję do skorygowania działań i ukierunkowania ich w stronę kultury DevOps. Warto jednak uzmysłowić sobie, że większość zespołów potrzebuje zastrzyku pomysłów z zewnątrz. Dopóki DevOps nie stanie się kulturą mainstreamową (nauczaną może nawet już w szkole), nie będzie organicznym rezultatem wdrożenia metodyki Scrum. To, czy zespół zaangażuje trenera Agile lub DevOps, będzie prawdopodobnie nieistotne, o ile ta osoba nie będzie w stanie wnieść doświadczenia w dziedzinie automatyzacji dotyczącej kompilowania, testowania i wdrażania oprogramowania.

Prawidłowo egzekwowana dyscyplina ciągłego dostarczania (CD) pomaga ograniczyć prace w toku, a automatyzacja wdrożeń ułatwia znoszenie ograniczeń. W ten sposób, dzięki ciągłemu dostarczaniu, zespoły programistyczne mogą dostarczać oprogramowanie częściej i wyższej jakości, eliminując konieczność wyboru między jednym a drugim. Jednak podobnie jak zespoły, które koncentrują się wyłącznie na metodyce Scrum, mogą stracić szerszy kontekst podejścia Agile, tak zespoły, które koncentrują się wyłącznie na ciągłym dostarczaniu, mogą stracić szerszy kontekst DevOps.

Praktyka ciągłego dostarczania nie rozwiązuje w sposób bezpośredni problemów z komunikacją między firmą i zespołem programistycznym. Jeśli w firmie stosuje się roczny cykl planowania oparty na budżecie, wówczas zespół wdrażający do produkcji każdy commit może czekać nawet kilka miesięcy na reakcję firmy. Aż nazbyt często te reakcje mają charakter zmian skokowych, takich jak anulowanie projektu lub, co gorsza, podwojenie liczeności zespołu projektowego (ponieważ duży napływ nowych ludzi zakłóca pracę).

Według modelu Agile Fluency pierwszym poziomem biegłości jest „koncentracja na wartości”. Na tym poziomie zespół skupia się na przejrzystości i koordynacji. Bez tej biegłości ciągłe dostarczanie może z łatwością przerodzić się w nieskończony cykl usprawnień technicznych, które nie przynoszą firmie żadnych wymiernych korzyści. Zespół może dobrze sobie radzić z szybkim dostarczaniem z wysoką jakością, jednak tylko w przypadku produktów, które niosą niewielką korzyść dla użytkowników końcowych lub firmy. Nawet jeśli wielu użytkowników wyraża pozytywną opinię, ocena małej korzyści może być możliwa wyłącznie na poziomie większego portfolio firmy. Bez tak istotnej biegłości trudno odpowiednio zrównoważyć rozwiązania techniczne z funkcjami. Jest to szczególnie ważne w przypadku zespołu pracującego na przestarzałej bazie kodu, który może nie dysponować zautomatyzowanymi testami lub projektem przystosowanym do częstych wdrożeń. W przestarzałym kontekście transformacja w kierunku ciągłego dostarczania może potrwać wiele lat. Zatem znacznie ważniejsza jest możliwość wykazania korzyści biznesowych.

DevOps to coś więcej niż tylko automatyzacja pipeline'u wdrażania. Jak zauważył John Allspaw, w DevOps chodzi o „pracowników operacyjnych, którzy myślą jak programiści, i programistów, którzy myślą jak pracownicy operacyjni”. Rozwijając tę myśl, Gene Kim objaśnia pojęcie „trzech dróg” stanowiących zasady DevOps:

Ciągłe dostarczanie (CD) koncentruje się na pierwszej drodze: automatyzacji przepływu z zespołu programistycznego do operacyjnego. Automatyzacja odgrywa oczywistą rolę w przyspieszaniu działania systemu wdrażania. Jednak w myśleniu systemowym chodzi o coś więcej niż tylko automatyzację.

Praktyką charakterystyczną dla drugiej drogi jest „noszenie pagerów przez programistów”. Choć dosłowne używanie pagerów może nie być konieczne, oznacza to angażowanie programistów w kwestie operacyjne. Dzięki temu programistom łatwiej zrozumieć konsekwencje podejmowanych przez nich decyzji. W ten sposób można na przykład zachęcić programistów do umieszczania komunikatów dziennika w bardziej przystępnych miejscach i nadawania im bardziej znaczącej treści. Nie chodzi tylko o samą świadomość. Programiści wnoszą również swoje wewnętrzne rozumienie systemu do prac związanych z identyfikowaniem błędów, aby można było szybciej znajdować i wdrażać rozwiązania.

Trzecia droga zakłada przeprowadzanie eksperymentów przyrostowych w systemie jako całości, a nie tylko w formie zmian w aplikacji w miarę postępów pipeline'u. Innymi słowy, można stosunkowo łatwo dostrzec, ile trwa automatyzacja, i wykorzystać coraz bardziej zaawansowaną infrastrukturę do jej usprawnienia. Trudniej zrozumieć opóźnienia związane z przekazywaniem zadań między rolami i organizacjami. Oznacza to, że zespoły „przeprowadzają weryfikacje i wprowadzają korekty” na poziomie całego przepływu pracy związanego z dostarczaniem, poszukując możliwości udoskonalenia współpracy międzyludzkiej. W związku z tym ciągłe dostarczanie wymaga wyrobienia nawyku dostosowywania i ulepszania. Jeśli zespół nie zastanawia się nad tym, jak zwiększyć efektywność, a następnie skorygować i dostosować swój sposób działania do innych czynników, proces ciągłego dostarczania także nie będzie się rozwijał. Zespół musi mieć poczucie, że ma możliwość rozwiązywania własnych problemów.

W Scrum każda retrospektywa jest okazją do doskonalenia praktyk i narzędzi. Jeśli jednak zespół nie wykorzystuje tych możliwości do rozwiązywania krótkoterminowych i długoterminowych problemów technicznych, będą one czekać, aż product owner umieści zadania CD w backlogu, co nigdy nie nastąpi.

Scrum odwołuje się przede wszystkim do tej zasady Agile, która głosi: „Uwzględniaj zmieniające się wymagania, nawet na późnym etapie rozwoju. Procesy Agile wykorzystują zmiany w celu zapewnienia klientowi przewagi konkurencyjnej”.

Z kolei ciągłe dostarczanie odwołuje się przede wszystkim do zasady Agile, która głosi: „Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu dostarczaniu wartościowego oprogramowania”.

Oznacza to, że w podejściu Agile chodzi bardziej o uwzględnianie przychodzących i wychodzących zmian niż o wydarzenia, takie jak spotkania stand-up czy planowanie sprintów. Manifest Agile zawiera także 10 innych zasad. Należy jednak traktować je jako całość zamiast podejmowania prób wyboru części z nich. Razem te zasady odzwierciedlają podejście do zmiany wspólne dla Agile i DevOps.

Ci ludzie tkwią w miejscu, próbując obsługiwać delikatne systemy, które jednocześnie są najważniejsze dla firmy. A ponieważ są najważniejsze dla firmy, są także obszarami, w których potrzeba zmian jest najpilniejsza. W związku z tym ta właściwa metodyce Agile koncepcja uwzględniania zmiany nie oznacza wyłącznie „zmiany dla samej potrzeby wprowadzenia zmian”. Chodzi o to, aby zespół programistyczny wziął odpowiedzialność za jakość wprowadzanych przez siebie zmian, przy jednoczesnej poprawie ogólnych możliwości dostarczania korzyści biznesowych. Ten nacisk na korzyść biznesową jest kolejnym aspektem wspólnym dla Agile i DevOps.

Wreszcie ani metodyka Agile ani DevOps nie są celami biznesowymi same w sobie. Są jedynie ruchami kulturowymi, które poprzez zastosowanie lepszych środków mogą zainspirować Twoją organizację do osiągania celów. Agile i DevOps przynoszą lepsze rezultaty, jeśli zastosuje się je w połączeniu, a nie zestawi jako przeciwieństwa. Sztuka unikania konfrontacji między tymi dwoma ideami polega na zrozumieniu głębszych wartości i zasad, na których się opierają. Krótkie, ale zawężone definicje prowadzą do myślenia jednowymiarowego. Teraz, gdy już wiesz, że Agile to coś więcej niż Scrum, a DevOps to nie tylko ciągłe dostarczanie, możesz wypróbować połączenie Agile i DevOps, które ma ogromny potencjał.