Cześć, dzisiaj wyjątkowo nie o chmurach, ale o DevOps. Ten artykuł to zapis części podcastu dotyczącego “DevOps” w którym uczestniczyłem. Chciałem podziękować Mateuszowi Bogolubow z devmentor.pl za zaproszenie i wspólną rozmowę.
Podczas rozmowy czekały mnie bardzo ciekawe pytania, na które starałem się odpowiedzieć, najlepiej jak potrafiłem. Ostatecznie wyszedł bardzo konkretny materiał, mówiący co jest DevOps i od czego pochodzi. Rozmawialiśmy o tym, czy DevOps to kultura, czy może metodyka pracy, o jego silnych i słabych stronach. Mówiliśmy o tym, jak zacząć przygodę z DevOps od jakich umiejętności. Jakie narzędzia warto znać i oczywiście co wspólnego ma DevOps z Agile.
Fragment rozmowy znajdziesz poniżej, a cały podcast możecie znaleźć na:
- YouTube – Wprowadzenie do DevOps | Pierwsze kroki w IT #55 [ IT podcast ] – YouTube
- Spotify – Wprowadzenie do DevOps – Pierwsze kroki w IT | Podcast on Spotify
- Google Podcast – Pierwsze kroki w IT – Wprowadzenie do DevOps (google.com)
- Apple Podcast – Pierwsze kroki w IT: Wprowadzenie do DevOps on Apple Podcasts
- devmentor.pl – Wprowadzenie do DevOps – devmentor.pl
Czy Agile ma coś wspólnego z DevOps?
Ok więc Agile i DevOps różnią się od siebie, ale nie wykluczają się wzajemnie.
○ Agile, czyli zwinne podejście do zarządzania projektami i tworzenia oprogramowania, pomaga zespołom dostarczać wartość klientom szybciej. Zamiast tworzyć jedno wielkie wdrożenie, zespoły Agile dostarczają pracę w niewielkich, ale użytecznych częściach.
○ Tradycyjne Kaskadowe podejście do zarządzania projektami – Waterfall, wymuszało bardzo długi czas oczekiwania na gotowy produkt. Założenie było takie, że gdy 1 zespół zakończył pracę, to przekazywał ją innemu zespołowi, wszystko odbywało się według wcześniej ustalonego harmonogramu. Niestety często zmieniające się warunki i założenia powodowały wydłużenie czasu realizacji i drastycznie zwiększały koszty niektórych projektów, doprowadzało to do zamykania projektów, zanim zostały ukończone.
○ Odpowiedzią na te problemy było właśnie zwinne podejście do zarządzania projektami. Metodykę Agile można w skrócie opisać jako podejście, którego celem jest utrzymanie produktywności i dostarczanie produktu w warunkach stale zmieniających się potrzeb.
○ To nie jest tak, że waterfall się nigdzie nie sprawdza, bo tak nie jest. Każde podejście ma swoje plusy i minusy. Waterfall sprawdza się tam, gdzie wymagania pozostają stałe, gdzie nie wprowadza się zmian, albo wprowadza się ich mało, ponieważ wprowadzenie zmian jest bardzo kosztowne. Ok, czyli gdzie się może sprawdzić? No np. mogłoby przy produkcji samochodu albo jakiejś innej linii produkcyjnej. Jak wspomniałem wcześniej, tam, gdzie wstępne założenia się nie zmieniają.
○ Świat IT bardzo szybko się zmienia. Sposób myślenia w metodyce Agile, trochę się do tego dostosowuje, polega na szybkim reagowaniu na zmiany, na błędy. Jest skoncentrowany na elastyczności i dostosowywaniu się do potrzeb i oczekiwań klienta, a nie realizacji sztywno wyznaczonych planów. Czyli bardzo upraszczając, szybkie reagowanie na zmiany. Dla mnie to takie logiczne podejście do rozwiązywania problemów, które zostało opisane. Czyli takie nastawienie, by pracować lepiej, bardziej efektywnie, nastawienie na stały rozwój i równoczesne ograniczanie ryzyka przez otrzymywani feedbacku i upewnianie się, czy podążamy w dobrym kierunku. Przynajmniej ja to tak rozumiem. Jeśli ktoś chciałby się dowiedzieć więcej o Agile, to w 2001 powstał Manifest Agile (manifest zwinnego wytwarzania oprogramowania), czyli deklaracja wspólnych zasad dla zwinnych metod tworzenia oprogramowania. Ja nie chciałbym się teraz w to zagłębiać, bo mogłoby nam dnia zabraknąć. Ważne, że jest coś takiego i jeśli ktoś chciałby zgłębić temat agile, to powinien od tego zacząć. Tutaj mogę też polecić chyba jeden z twoich podcastów, w których bardziej skupiłeś się na scrumie i zwinnym podejściu: Czy Agile to Scrum? O różnicy, sposobie myślenia i wdrażaniu | PKwIT #44 [ IT podcast ]
○ Jeśli chodzi o podejście do klienta, to Agile nastawia się na częsty kontakt z klientem i dostarczanie mu wartości. Czyli klient widzi pracę, z każdym spotkaniem, co 2- 3 tygodnie widzi postęp i otrzymuje coś wartościowego. Istotne jest to, że ma on zawsze wpływ na to, co się dzieje. Na każdym etapie ma wpływ na produkt, który dostarczamy. Dzięki temu ta współpraca idzie dobrze. Klient chętnie współpracuje, mówi o tym, czego potrzebuje. W gruncie rzeczy może się okazać, że końcowy produkt będzie inny od tego, o którym rozmawialiśmy na początku, ale klient będzie szczęśliwy, bo otrzyma to, czego naprawdę potrzebuje.
○ Zespoły pracujące zwinnie zazwyczaj realizują mniejsze zadania, które potrafią szybciej skończyć. Zwiększa się przejrzystość tego, co ktoś realizuje, na jakim jest etapie i zmniejsza się liczba pracy w toku, takich rozpoczętych zadań, ale nie zakończonych. Widzimy dokładnie, co nas blokuje i możemy szybko na to reagować.
Podsumowanie dotyczące Agile i DevOps
○ Zarówno DevOps, jak i Agile umożliwiają przyspieszenie dostarczania końcowego produktu. Co ważne, nie musisz wybierać pomiędzy metodyką DevOps a Agile — możesz korzystać z obu. Możesz pracować w metodologii DevOps i wybrać to, czego jeszcze potrzebujesz, np. scrum jest przydatny do śledzenia zaplanowanych prac jak aktualizacje, migracje itp. Czasem występują nieprzewidziane sytuacje jak naruszenie bezpieczeństwa, no i to nie może czekać sobie w backlogu na kolejną sesję planowania, więc lepiej się sprawdzi metodyka kanban. Zespoły czasem używają hybrydy różnych metod do pracy, po prostu tego, co się sprawdza.
○ Silną stroną metodyki Agile jest organizowanie pracy, jak wspomniałem wcześniej, na przykład za pomocą narzędzi Scrum i Kanban. Z kolei metodyka DevOps ma większy zasięg i umożliwia dostarczanie oprogramowania szybciej i w bardziej niezawodny sposób, kładzie duży nacisk na automatyzację procesów i szybkim dostarczaniu informacji zwrotnej.
Więcej informacji dotyczących DevOps
Jeśli jesteś ciekaw co było dalej, to cały podcast możesz zobaczyć na YouTube. Przygotuj się na solidną dawkę wiedzy bo podcast trwa prawie godzinę.
Jeśli podobał Ci się podcast, to mam dobrą wiadomość w najbliższym czasie będę brał udział w kolejnym podcaście tym razem na temat Dockera. Więcej informacji już wkrótce.