Podobnie jak wiele podejść i koncepcji, które zawitały do kraju nad Wisłą po tym, jak zdobyły popularność gdzie indziej (ale jeszcze nie okrzepły), również idea DevOps bywa interpretowana na różne sposoby i „wdrażana” niczym Scrum. W efekcie mamy do czynienia z rezultatami, które gdzieś tam ocierają się o początkowe założenia, ale w zasadzie nikt nie wie jak bardzo. W omawianym przypadku warto sięgnąć po popularną książkę „Projekt Feniks”, która traktuje właśnie o tym, jak działać zgodnie z modelem DevOps, przy czym znowuż nie jest to jakaś kompletna wykładnia.

Co wyróżnia świeżo powoływane zespoły DevOps? Ano to, że w założeniu mają w sobie łączyć zarówno działania związane z projektowaniem i rozwojem koncepcji dostarczanego oprogramowania, jak i te działania operacyjne, które sprawiają, że produkt jest zbudowany, a następnie utrzymywany. Przy czym mamy w teorii zapisane dążenie do utrzymania pewnego balansu, gdzie żadna ze stron nie powinna być traktowana lepiej bądź gorzej, mniej lub bardziej po macoszemu.

Mówiąc wprost, potrzeby analityczne, nie tylko cudownie nie znikają, ani nie „rozmazują” się na inne role. Często może być wręcz przeciwnie, bo w zasadzie na każdym z tych kroków potrzebny jest udział „dyżurnego” analityka, odpowiedzialnego za całą koncepcję rozwiązania, filtrującego czy też systematyzującego informacje biznesowe.

Oczywiście, jak ktoś spojrzy sobie na schemat tejże koncepcji, to wygląda ona jak przykład doskonałego sprzężenia zwrotnego, w którym to, co sobie zaplanujemy, wykonamy, przetestujemy i przekażemy interesariuszom, wywołuje informacje zwrotne, które pozwalają jeszcze lepiej planować i realizować kolejne idee. Brzmi pięknie…

…gdzie zatem poletko do dyskusji?

Weźmy sobie na ten przykład różnice w interpretacji owej koncepcji w stosunku do poszczególnych ról w zespole. Troszkę podobnie jak ma to miejsce w „samoorganizujących” się zespołach Scrumowych, również i w przypadku DevOps suma umiejętności i kompetencji przedstawicieli grupy przekłada się na zdolność zarówno do opracowania założeń produktu, jak też jego dostarczenia i zapewnienia dalszej żywotności.

Co nie oznacza wcale rezygnacji z potrzeby utrzymania osobnych ról z jasno wyznaczonymi zadaniami. Krótko mówiąc, mamy tutaj nadal do czynienia z pewną układanką do wykonania, gdzie brak jednego elementu lub brak dbałości o odpowiednią liczbę bądź jakość powoduje, że cały misterny plan… no już wiecie sami, dokąd zmierza.

Istnieje jednak tendencja do kreowania czy też poszukiwania „one man army”, czyli osób ogarniających w założeniu przynajmniej kilka grup kompetencji i to najlepiej na tym samym poziomie. Czyli już nie tylko mowa o zespole działającym w filozofii DevOps, ale o schodzeniu na poziom jednostki. Tutaj mruga do nas wcześniej wspomniany Scrum, który już to poniekąd przerabiał…

Stąd mocno nasuwa mi się skojarzenie z piłką nożną. Zauważoną analogię omówię na przykładzie gry „Football Manager”, bo w bardzo czytelny sposób obrazuje umiejętności zawodników. Wynika z nich jasno, że określony piłkarz jest predestynowany, by grać na pozycji prawego obrońcy bądź wysuniętego prawego obrońcy, ewentualnie od biedy może zagrać na lewej obronie (np. jeśli nominalny zawodnik doznał kontuzji). Jednak już absolutnie nie zrobimy z niego wyborowego napastnika czy też bramkarza.

Dobrze naoliwiona maszyna

Menadżerowie nie dysponują co prawda tak konkretną informacją, ale role zespołowe i główne zadania, które z nich wynikają, są dosyć łatwe do identyfikacji i potwierdzenia wzajemnych zależności. Cały czas mówimy tutaj o tworzeniu dobrze naoliwionej maszyny w postaci interdyscyplinarnego zespołu kompetencji. Sami piewcy idei DevOps, w tym firmy, które cały stos swoich produktów podpierają wsparciem właśnie tego modelu pracy, zdają się zauważać te wyzwania, które wiążą się z jego „wdrożeniem”. Podkreślają chociażby, że „DevOps to nie zadanie dla jednej osoby. To zadanie dla wszystkich” (Robert Krohn, kierownik ds. inżynierii w Atlassian). Co się zaś tyczy owych zespołów budowanych w kulturze DevOps, to „wszyscy członkowie zespołu DevOps muszą znać cały strumień wartości — od koncepcji, przez programowanie po środowisko użytkownika końcowego”.

Trzymając się tego założenia, widać nacisk na słowo „wartość”, słowo jakże często wnoszone na oficjalne sztandary, by potem szybko je sprowadzić do wypuszczania kolejnych nie do końca udanych iteracji. Nie ma również mowy o tym, by oznaczało to wzmożoną czy też bardziej pożądaną wielozadaniowość. Krótko mówiąc analityk, przykładowo, nie wchodzi „w paradę” programiście, a specjalista od UX-a nie zajmuje się również scenariuszami testowymi, zaś architekt rozwiązania nie układa kierownikowi projektu harmonogramu.

Model DevOps dodatkowo kładzie nacisk na monitorowanie i ciągłą poprawę. Mówimy więc tutaj o kulturze regularnego przekazywania informacji zwrotnej i to w takim tempie, aby można było odpowiednio szybko zareagować, zmienić strategię czy też założenia projektu. Bez tego ten model w zasadzie nie żyje. Co nie mniej istotne, potrzebne są też odpowiednie role, które to wszystko koordynują, szczególnie, że koncepcja DevOps zakłada współpracę między poszczególnymi zespołami, swoją drogą również tworzonymi w duchu DevOps.

Paweł Cyzman Paweł Cyzman  

Autor jest starszym analitykiem biznesowym w firmie Kruk.