Udostępnij!

Rozmawiają Dariusz Korzun – Business Development Director Altkom Akademia i Arkadiusz Gałecki – Trener wiodący ITIL®, DevOps, Lean IT

DK: Dzień dobry, witam na spotkaniu poświęconym DevOps. Goszczę dzisiaj Arkadiusza Gałeckiego, który jest trenerem wiodącym w zakresie ITIL i DevOps Lean IT w Altkom Akademii.

AG: Dzień dobry, witam wszystkich.

DK: Mam, Arku, na sam początek, zanim przejdziemy do tematu naszego spotkania, takie pytanie – jak to wygląda z Twojej praktyki, czy admini lubią deweloperów?

AG: Zasadniczo admini nie lubią deweloperów, ani deweloperzy nie lubią adminów – i tego musimy się trzymać. Natomiast nowe spojrzenie czy nowe otwarcie na rynek IT i potrzeby biznesu wymusiły zarówno na deweloperach, jak i adminach, polubienie się – czyli spowodowanie, że zostaje zburzony ten mur, który narastał od lat i został przeniesiony jeszcze za czasów ITIL 2, w ramach dostarczania usług czy też budowy organizacji silosowej.

DK: Ja tak sobie myślę o firmie, która sprzedaje jakieś produkty masowego użytku – czy w takich firmach są programiści?

AG: Jak najbardziej. Deweloperzy bardzo często tworzą działy, które będą odpowiadały za współtworzenie produktów i usług, czyli tworzą tak zwane zespoły kros-funkcjonalne, które de facto odpowiadają za te produkty od początku do końca. Co więcej, biznes jest driverem wszelkiego rodzaju wymagań w kontekście wartości, którą ma otrzymać klient. Zauważmy, że ten biznes jest zarówno z jednej strony supplierem, który dostarcza wymagania do procesu, a z drugiej strony jest odbiorcą wartości. Można powiedzieć szerzej – następuje w takim obszarze, przy kros-funkcjonalnym podejściu, współtworzenie wartości zarówno przez klienta, dostawcę i poddostawców dostawcy usług.

DK: Wyobrażam sobie, że jestem tym właścicielem biznesowym, mam pomysł na to co powinno być zrealizowane, co pomoże mi w tym by sprzedawać lepiej usługi bądź produkty? Z drugiej strony mam tych geeków technicznych – to są deweloperzy, to są jeszcze do tego administratorzy, operatorzy IT. Rozumiem, że oni powinni dostarczyć mi produkt, którego ja oczekuję bym mógł realizować swoją pracę, ale żeby mogli mi dostarczyć ten produkt w sytuacji kiedy jednak nie do końca muszą się kochać, dobrze byłoby im dać jakieś wskazówki. Czy DevOps jest taką wskazówką?

AG: Bardzo, bym powiedział, dobrze zadane pytanie. Jeżeli chcielibyśmy odnieść się do DevOpsa czy do tej wskazówki, to najpierw musimy sobie odpowiedzieć na pytanie czym on w ogóle jest. Zasadniczo DevOps możemy identyfikować jako dwa podstawowe elementy czy dwa światy. Jeden świat – „DevOps to kultura” – czyli sprawienie w organizacji, że te dwie strony o których mówiłeś wcześniej, zaczynają ze sobą współpracować i wspólnie tworzyć produkty i usługi, a drugi obszar to tak naprawdę „DevOps to czas”. Czyli te strony, które się nie lubiły, muszą wykorzystać różnego rodzaju narzędzia, które pozwolą im szybko reagować na Twoje potrzeby jako właściciela biznesowego i w miarę szybko dostarczać Ci w krótkich cyklach, nie dłuższych niż dwa tygodnie, do miesiąca, konkretną funkcjonalność czy rozwiązanie, które z punktu widzenia Ciebie jako właściciela biznesowego przyniesie Ci wartość i pozwoli Ci zarabiać pieniądze.

DK: Powiedziałeś o dwóch elementach. Pierwszy element to jest kultura organizacyjna, kultura pracy, a drugi to są narzędzia, które wykorzystują zespoły do tego by dostarczyć produkt czy rozwiązanie, tak?

AG: Tak, te narzędzia zasadniczo przekładają się na czas. Chodzi o tak zwane velocity zespołu i velocity organizacji. Chodzi o przetwarzanie zmian, które zostają dostarczone na produkcję, a te zmiany przynoszą nam konkretną wartość. I teraz im więcej tych zmian jest zaabsorbowanych przez zespół w konkretnym odcinku czasu, tym szybciej zespół jest w stanie dostarczyć konkretne rozwiązanie czy wartość dla swojego klienta. Dlatego DevOps wymaga tego abyśmy odpowiednio zaprojektowali flow, który będzie odpowiadał za dostarczanie produktów i usług, wyeliminowali wszelkiego rodzaju nieefektywności, czyli działania w procesie, które nie dają wartości. Bo gdy patrzymy na proces, powinniśmy dostrzegać trzy rodzaje działań – dające wartość, niedające wartości i te, które nie dają wartości, ale bez nich proces nie zadziała. A wszystkie te, które nie dają wartości, powinny zostać wyeliminowane i one są tak zwanymi waste’ami.

DK: Gdybyś miał to podsumować w jednym czy dwóch zdaniach – po co nam DevOps?

AG: Po to żebyśmy mogli przyśpieszyć, żebyśmy szybciej dostarczali produkty i usługi dla naszych klientów żeby byli bardziej zadowoleni.

DK: Dla kogo jest DevOps?

AG: Dla wszystkich. Przede wszystkim dla biznesu. Kiedy na rynku pojawił się Agile, biznes odzyskał zaufanie do developmentu. Zaczęli wspólnie pracować i robić wszystko aby dostarczać coraz więcej zmian, coraz więcej produktów i usług. Natomiast mimowolnie pozostawiono z tyłu eksploatację – czyli tych administratorów, którzy na co dzień walczyli z utrzymaniem różnego rodzaju środowisk. Dopiero w momencie kiedy pojawił się DevOps, biznes odzyskał zaufanie i dzisiaj nie dostrzega się już różnicy między biznesem, developmentem, a eksploatacją, czyli utrzymaniem bo traktuje się to wszystko jako jedną organizację czy jeden organizm, który wspólnie dostarcza produkty i usługi gdzie product owner to biznes, zespół to, można powiedzieć, wszyscy w organizacji, wszyscy, którzy byliby niezbędni do wytworzenia produktu czy usługi, no i z boku stoi jeszcze taki strażnik, policjant, który tu nazywa się wprost scrum masterem i odpowiada za to żeby wspierać organizację i eliminować wszelkiego rodzaju kłody spod nóg zespołowi, organizacji i product ownerowi w kontekście dostarczenia produktu czy usługi do właścicieli biznesowych czyli biznesowych odbiorców.

DK: Chciałbym to zobrazować na przykładzie człowieka, który jest jednoosobowym DevOpsem – potrafi coś zaprogramować, potrafi uruchomić serwer, potrafi wdrożyć to oprogramowanie, które napisał. Co będę robił DevOpsowego w tej mojej pracy codziennej?

AG: Przede wszystkim, to patrząc ze strony rozwoju, to będę wytwarzał produkty i usługi, patrząc ze strony operacji, będę je utrzymywał, pozwoli mi to na przyspieszenie dostarczania produktów i usług, bo z jednej strony zachowam velocity po tej stronie biznesowo-rozwojowej, czyli będę w stanie przetwarzać bardzo dużą ilość zmian bo je rozumiem, ale pod kątem późniejszego utrzymania, po to żeby na produkcji zapewnić tak zwaną stability czyli stabilność środowisk produkcyjnych. Zauważmy, że z jednej strony będąc deweloperem chcę bardzo dużo programować, a z drugiej strony patrząc na to od strony utrzymania chciałbym żeby było jak najmniej zmian, żeby środowiska były stabilne. Będąc jednocześnie zarówno deweloperem, jak i osobą odpowiedzialną za eksploatację, przetworzę bardzo dużą ilość zmian, ale zrobię tow sposób bezpieczny, stabilny dla eksploatacji…

DK: Bo mam nad tym kontrolę, bo jestem tą osobą, która to robi.

AG: Dokładnie tak, a wspomagają mnie tutaj konkretne narzędzia, pryncypia i trzy drogi DevOpsowe. Bo to co jest najważniejsze w tym kontekście to jest nic innego jak automatyzacja, to jest automatyzowanie flow, który przechodzi od lewej do prawej, w kolejnym kroku wyeliminowanie nieefektywności czy waste’ów, czyli Lean. W kolejnym kroku dochodzi nam kultura, czyli wprowadzenie zmiany kulturowej i zupełnie innego modelu pracy. Dalej musimy się mierzyć, więc zmierzymy. DevOps zwykle mierzymy całościowo, nie w jakichś drobnych aspektach. Zmierzymy więc z jednej strony velocity, czyli prędkość zespołu, czyli zmian przekazywanych, jak i zmierzymy stabilność. Ale musimy jeszcze pamiętać o aspekcie wiedzy, więc zbudujemy ekosystem do share’owania wiedzy i informacji i do zarządzania wiedzą, a na to wszystko nałożymy jeszcze trzy drogi devOpsowe. Pierwsza droga, która nazywa się flow, czyli od lewej do prawej i tutaj wykorzystamy Lean i teorię ograniczeń. Druga droga to pętla zwrotna, czyli ciągłe monitorowanie i ciągły feedback, feedback, który będzie nam dostarczał informacji zwrotnej w ramach całego flow. A trzecia droga to już eksperymentowanie i uczenie się – czyli co będziemy robić? Będziemy podejmować ryzyko po to żeby się uczyć. Co więcej, będziemy pozwalać ludziom na błędy i nie będziemy ich karać po to żeby budować odpowiednio wiedzę i żeby więcej takie błędy się nie pojawiały. I tak moglibyśmy bardzo szybko scharakteryzować DevOps w kontekście „kultura i czas”.

DK: Brzmi to trochę skomplikowanie…

AG: Bo jest tego dużo, tak naprawdę.

DK: A czy tego da się nauczyć, czy to trzeba przeżyć przez miesiące lub lata w firmie?

AG: Wszystkiego da się nauczyć, ale potrzebujemy pewnej podstawy szkoleniowej, można by powiedzieć takiej podstawy edukacyjnej, drogowskazu, który pokaże nam jakie dobre praktyki składają się na DevOpsa, w którym kierunku powinniśmy zmierzać. Jeżeli przejdziemy przez tę podróż edukacyjną w kontekście różnego rodzaju dobrych praktyk i metodologii, które wskażą nam jak ten DevOps działa i jak możemy to stosować w organizacji, to gdzieś tam dalej kolejnym krokiem będzie nabycie już praktyki.

DK: Proszę, powiedz mi, czy według Ciebie osoby, które pracują jako administratorzy oraz osoby, które pracują jako programiści, czy te osoby powinny razem przychodzić na szkolenia czy powinny być te szkolenia bardziej rozdzielone – szkolenie DevOps dla administratorów i szkolenie DevOps dla programistów?

AG: Nie możemy tego traktować jak osobnych bytów, zarówno programistów jak i administratorów. Musimy na to patrzeć bardziej kros-funkcjonalnie czy holistycznie. Jeżeli mówimy o DevOpsie, mówimy o całej organizacji, począwszy od przedstawicieli biznesu, aż do operacji na samym dole – zatem na takie szkolenia powinni przychodzić deweloperzy, powinni przychodzić ludzie z eksploatacji, również ludzie z biznesu, szczególnie product ownerowie czy scrum masterowie. Co więcej, na takie szkolenia powinni się wybrać architekci, powinny się wybrać osoby odpowiadające za bezpieczeństwo, powinni się wybrać również analitycy…

DK: Czyli właściwie wszyscy zaangażowani w proces dostarczania produktu.

AG: Otóż to. Jeżeli patrzymy na dostarczanie produktu czy usługi, to jednym z kluczowych elementów po tym jak zrozumiemy głos klienta, jest nic innego jak engagement, czyli zaangażowanie. I teraz to zaangażowanie powinno występować w obrębie wszystkich stakeholderów, interesantów, którzy występują w organizacji.

DK: Ma to sens. Jak wszyscy będą mieli ten słownik, którym jest DevOps, to zapewne tak.

AG: Zapewne tak. Jeżeli będziemy wszyscy rozmawiać jednym językiem, organizacja będzie działała szybciej i będzie działała lepiej. Dlatego tutaj w to szkolenie powinni się zaangażować wszyscy żeby zrozumieć przynajmniej ten fundament, tę podstawę DevOpsa, po to żeby można było potem ewentualnie dalej się rozwijać w konkretnych kierunkach.

DK: Widziałem, że szkoleń jest bardzo dużo, na różnych poziomach. Chciałem zadać pytanie na temat symulacji – pojawia się taka oferta, która odbiega może od standardu szkolenia gdzie siedzimy na sali, oglądamy prezentację, uczymy się, powtarzamy, tylko to praktyczna praca. Ta symulacja nazywa się The Phoenix Project. Czy możesz powiedzieć coś więcej na ten temat?

AG: Oczywiście. To super rozwiązanie, które pozwala nam zrozumieć co to jest DevOps. Dlaczego w ogóle pozwala nam zrozumieć? Ponieważ w sposób praktyczny wykorzystujemy dobrodziejstwa DevOpsa, czyli pracujemy w kros-funkcjonalnych zespołach, które przechodzą bardzo mocno przez biznes, dotykają bardzo mocno ITIL-a…

DK: Przepraszam, że się tak wtrącam, ale czy to oznacza, że jeśli wybierzemy sobie tę część praktyczną, czyli The Phoenix Project, to wszyscy razem powinniśmy pójść na tę symulację?

AG: Oczywiście, jak najbardziej. O ile mówiąc o DevOpsie, ten DevOps zakorzenił się już w świecie IT, eksploatacja, ludzie odpowiedzialni za bezpieczeństwo i wszyscy inni, którzy pracują w IT, mają świadomość jak to działa, to biznes może bardzo wiele skorzystać i nauczyć się na takim spotkaniu czy symulacji gdzie te dobrodziejstwa DevOpsowe wykorzystywane są w ramach dostarczania produktów i usług. Co więcej, symulacja pozwala nam na realizację bardzo wielu różnego rodzaju projektów pod kontrolą podejść zwinnych aby jak najszybciej dostarczyć produkty. I tutaj biznes jest bardzo mocno zaangażowany. Działania IT są uzależnione od działań biznesowych i w drugą stronę, żebyśmy byli w stanie utrzymać odpowiednie poziomy kosztów, żebyśmy byli w stanie dostarczyć wartość klientowi i żeby ten klient był zadowolony, wszyscy muszą współpracować razem. Pamiętajmy o jednym – musimy wspólnie eliminować po drodze różnego rodzaju ograniczenia, które się pojawiają. Musimy z nimi walczyć, czyli cały czas działamy pod presją czasu…

DK: I wszyscy powinniśmy je rozumieć.

AG: Dokładnie. Wszyscy są bardzo mocno zaangażowani.

DK: Wszystkie osoby w firmie, które zajmują się pracą nad wartością tej firmy, bo tak to rozumiem, czyli zarówno osoby, które przygotowują produkty do sprzedaży, jak i osoby, które przygotowują systemy do obsługi sprzedaży oraz produkcji tej oferty, wszystkie te osoby dbają o wartość, którą niesie firma i wszystkie te osoby powinny zrozumieć jak wygląda współpraca i dostarczanie wartości. DevOps jest takim rozwiązaniem.

AG: Dokładnie tak.

DK: Czyli wszyscy powinniśmy pójść na takie szkolenie, jak współpracować razem?

AG: Dokładnie tak. Chodzi o to żebyśmy wszyscy to rozumieli i, co więcej, mówili jednym językiem w kontekście tego, że w organizacji występuje wiele łańcuchów wartości, które pomagają ustalić jeden główny cel każdej organizacji, czyli zarabiać pieniądze.

DK: I tym optymistycznym akcentem chciałbym zakończyć. Dziękuję za nasze dzisiejsze spotkanie, zapraszam na kolejne.

AG: Ja również.

DK: Mam nadzieję, że już niedługo, mamy jeszcze parę tematów w zanadrzu do opisania i omówienia. Do zobaczenia.

AG: Do zobaczenia, dziękuję.