Dlaczego zwinny Developer jest lepszy od zwykłego?

Czym się różni “zwinny Developer” od “zwykłego” i dlaczego ten pierwszy jest na wagę złota? Co sprawia, że coraz więcej i więcej potrzeba ludzi, którzy potrafią szybko dostarczyć wartościowe oprogramowanie? Zastanówmy się też, które firmy będą potrzebowały szybko wytwarzanych skomplikowanych systemów i dlaczego prawie wszystkie?

 

Według Billa Gatesa w przyszłości zostaną tylko dwa rodzaje firm: te, które działają przez Internet oraz te, które zbankrutują. Nie wątpię, że istnieją branże, które świetnie sobie poradzą bez przejścia w tryb online, lecz nie dotyczy to większości (albo przynajmniej dużej części). Jeśli się z tym nie zgadzacie, spróbujcie przypomnieć sobie, kiedy ostatnio chodziliście do placówki bankowej żeby zlecić przelew krajowy. A może znaleźliście sobie mieszkanie na wynajem lub hotel na wycieczkę całkowicie pomijając internetowe portale nieruchomości? Może zamawiacie pizzę i taksówki wyłącznie dzwoniąc przez telefon? Nawet wtedy pracownik firmy obsługuje wasze zamówienie używając jakiejś aplikacji i czasami nawet nie jest w tym samym mieście. Więc – Internet.

Do czego to wszystko mówię? Bo w czasie dzisiejszym prawie każdy biznes potrzebuje oprogramowania, inaczej nie przetrwa. Banki, firmy ubezpieczeniowe i budujące/sprzedające nieruchomości, wszelkie firmy z branż rozrywkowych, usługowych, gastronomicznych i tak dalej. Wszystkie potrzebują oprogramowania. I to oprogramowania, z którego będą korzystały setki, tysiące, a czasem i miliony ludzi. Oprogramowania, które musi spełniać bardzo konkretne wymagania co do jakości.

Strona z nieruchomościami nie może sobie pozwolić, żeby ogłoszenia nieoczekiwanie znikały. Dostawca jedzenia nie może funkcjonować z wolno działającą aplikacją. Bank nie może narażać pieniędzy swoich klientów na zagrożenie cyberatakami, nie może też “gubić” pieniędzy w rozliczeniach. Firma, które ma złe oprogramowanie, straci klientów na korzyść konkurencji, która ma dobre.

Zostaną dwa rodzaje firm: te, które mają dobre oprogramowanie, i te, które zbankrutują.

Ok, ale jak to wszystko ma się do Scruma? Większość istniejących biznesów potrzebuje oprogramowania. Skoro potrzebują oprogramowania, to też potrzebują Developerów, którzy te aplikacje wytworzą. I jak już się przekonaliśmy, to musi być dobre oprogramowanie. Dodajmy do tego drugi aspekt: jeżeli mamy gwarancję, że dostaniemy doskonale zrobioną aplikację za 5 lat, ale konkurenci dostaną wystarczająco dobrą za pół roku, to ta perfekcyjna jakość jest na nic, bo nie nadążymy za rynkiem.

Poza jakością, ważne jest, żeby oprogramowanie tworzyło się w miarę szybko. Dzisiejszy świat zmienia się błyskawicznie i żaden biznes nie może pozwolić sobie na czekanie kilku lat. Za te parę lat rynek będzie już zupełnie inny, a to, co dziś jest nowinką, będzie już przestarzałe. No dobrze, ale gdzie tu Scrum?

Tworzenie oprogramowania jest skomplikowanym, trudno przewidywalnym procesem. W czasach waterfallowych powszechne były sytuacje, gdzie wykres z deadline’ami musiał być zmieniany codziennie, wszystko wymagało 3 razy więcej czasu niż się spodziewało, a ponad 80% projektów ponosiło klęskę. Dlaczego? Spójrzmy na rzeczywistość tworzenia oprogramowania. Dla większości ludzi pisanie kodu to czarna magia. Programistami zazwyczaj zostają osoby z pasją do tej czarnej magii, którzy mocno temu dziełu się poświęcają, ale kosztem innych rzeczy, na których niekoniecznie się znają. Klient musi zdefiniować wymagania co do oprogramowania, które chce uzyskać, ale on z kolei nie zna się na programowaniu (patrz: czarna magia). Developerzy muszą stworzyć aplikację do rozwiązania problemów biznesu, którego zbyt głęboko nie rozumieją. Klientom trudno zrozumieć perspektywę programistów i na odwrót.

To tak jak człowiek, który mówi tylko po japońsku musi dogadać się z  innym, który mówi tylko po islandzku. Prócz tego jest Delievery Manager, który nie zna żadnego z tych dwóch języków i ciągle wymaga, żeby mówiło się szybciej.

To pierwszy duży problem, a jest jeszcze drugi. Powiedzmy, że mamy 5-10 bardzo kompetentnych budowniczych. Mimo, że są dobrzy w wykonaniu swoich typowych zadań jak układanie cegieł, konstruowanie deskowań, wylewanie betonu i tak dalej, nie dadzą rady sami zbudować czegoś na kształt Empire State Building lub mostu przez Wisłę. Trzeba tych budowniczych o wiele więcej – być może setki, a nie dziesiątki. Ale nadal sami nie zbudują tak dużego projektu. Musi być jakiś plan, koordynacja, rozumienie zależności jednych komponentów lub zespołów od drugich. Wiele firm potrzebuje właśnie dużych, złożonych systemów informatycznych, które rozwiążą skomplikowane problemy biznesowe. A to wymaga dużej ilości programistów, którzy będą działać w skoordynowany sposób.

Jak już ustaliliśmy, programiści zazwyczaj nie wiedzą o tych problemach biznesowych za dużo. Ich interesuje pisanie kodu, refaktoring, nowe frameworki, itp. Pozostawieni sami sobie jest szansa, że będą jedynie ulepszać kod i dodawać coraz to nowe technologie. Klient natomiast chce, żeby aplikacja zapełniała mu potrzebne funkcje. To, czy ta aplikacja jest napisana w Java 8 czy Java 11 dla niego nie robi różnicy. Jest zadowolony, kiedy dostaje działające oprogramowanie w krótkim terminie. Kiedy zaś usłyszy “W tym Sprincie zaktualizowaliśmy frameworki do najnowszej wersji i zrobiliśmy refaktoring.” to potraktuje to tak samo, jak irytujące notyfikacje z Windowsa i zastanowi się: “Za co ja właściwie płacę?”.

Niestety (dla Developerów), kod sam w sobie nie posiada wartości. Wartość jest wtedy, kiedy aplikacja rozwiązuje jakiś problem z świata rzeczywistego. Wtedy klient jest zadowolony i chce za to płacić. Działające oprogramowanie, satysfakcja klienta – chyba gdzieś już o tym czytaliśmy. Tak! W Agile Manifesto! Zazwyczaj, nie zwracamy uwagi na fakt, że zarówno twórcy Agile’a, jak i bardziej szczegółowo – Scruma – byli programistami. I to bardzo dobrymi. Oni doskonale widzieli, jakie problemy istnieją w tej branży i wynaleźli na nie skuteczne rozwiązania. Stwierdzili, że te zespoły Developerskie, które budują relacje z klientem i uczą się rozumieć jego perspektywę, które skupiają się na dostarczaniu klientowi właśnie tego produktu, którego ten potrzebuje – te zespoły tworzą firmy informatyczne, które przyciągają najlepszych i zyskują najwięcej. Bo tworzą produkty (oprogramowanie), które doskonale pomaga klientom rozwijać ich biznes i zarabiać więcej.

Developer zwinny to ktoś, kto potrafi odpowiadać na te najważniejsze potrzeby biznesowe i szybko dostarczać wartościowe oprogramowanie. Który nie myśli jak tak zwany “Code Monkey”, tylko jak przedsiębiorca, który dba o swoich klientów. Jak? Dzięki temu, że umie pracować z innymi w jednym zespole i do tego w sposób, który mu to ułatwia. Robiąc skomplikowane rzeczy i starając się je zrobić równie szybko co dobrze, musimy pracować z agile mindsetem. W pojedynkę nie damy rady, dlatego musimy znaleźć jakiś sposób, który połączy osoby potrafiące robić to co trzeba, aby dowieźć nasze rozwiązanie. I wcale nie trzeba tych sposobów wymyślać na nowo, bo już zrobili to inni.

Więcej o tym, jak przejść z bycia “Code Monkey” do Developera zwinnego – w kolejnym artykule.

Artur Komendatskyi

5 lat doświadczenia w IT, PSM I, starszy inżynier oprogramowania, Scrum Master zespołów zwinnych

Click Here to Leave a Comment Below

Leave a Reply: