Scrum w dużych projektach bankowych - pierwszy podcast!
W INCAT rozpoczęliśmy przygodę z podcastami. W efekcie przygotowaliśmy dla Was rozmowę z naszym incatowym Scrum Masterem, Karolem Kłaczyńskim, z którym omawiamy temat Scruma w dużych projektach bankowych. Odnośnik do podcastu znajdziecie poniżej, a jeśli nie macie tyle czasu by przesłuchać całość, zapraszamy do poniższego artykułu, w którym zebraliśmy dziesięć kluczowych wskazówek i ważnych stwierdzeń, które padły w podcaście. Bierzcie więc i czytajcie z tego wszyscy :).
O zwinności biznesowej
Zwinność biznesowa to swoisty mindset, sposób myślenia nastawiony na ludzi, na dostosowywanie się do zmian. Scrum z kolei to framework, który promuje podejście zwinne, czyli jest to zestaw pewnych zasad, zdarzeń, ról i artefaktów, które można obudowywać swoimi elementami i który pomaga sobie radzić ze skomplikowanymi projektami biznesowymi i tworzeniem rozbudowanych systemów. Zwinny sposób myślenia pomaga się dostosowywać do wymagań klienta i, w efekcie, tworzyć lepsze rozwiązania.
O zwinności w projekcie i zwinności na poziomie organizacji
Zwinność na poziomie tworzenia produktu jest kluczowa, ale równie ważne jest, aby zwinne podejście prezentowała cała organizacja. Najlepiej widać tę zależność na przykładzie. Problem, który może się pojawić, to na przykład kwestia tego, że potrzebujemy nowego sprzętu w projekcie. I jeśli organizacja nie działa zwinnie, a osoby, które odpowiadają za tego rodzaju sprawy są swoistym wąskim gardłem organizacji, to nawet jeśli na poziomie projektu zespoły działają zwinnie, niewiele to pomoże, jeśli na trzy monitory i dwa notebooki będziemy czekać trzy-cztery tygodnie. Zespół jest zblokowany zewnętrznymi zależnościami, co odbija się na powodzeniu projektu.
O transformacji w organizację zarządzaną zwinnie
Ważne jest zrozumienie i wola ze strony zarządu. Zrozumienie, że jeśli organizacja nie będzie działać zwinnie, to efekty będą ograniczone. Warto też wybrać “agentów zmiany”, czyli osoby, które mają doświadczenie w pracy zwinnej i mają na tyle duże poważanie oraz posłuch u pozostałych członków organizacji, by móc tę zmianę propagować i przeprowadzać. Na początku kluczowe jest jednak, aby ustalić zasady, reguły i proces przejścia na agile w organizacji, w taki sposób, by był on jak najbardziej dopasowany do specyfiki i wymagań danej firmy. Stworzenie kontraktu w takiej sytuacji może być dobrym pomysłem, natomiast warto pamiętać o tym, by raczej go nie spisywać - określić i zobowiązać się do jego przestrzegania, ale niekoniecznie traktować jak pisemnej umowy. To jest na początku bardzo trudne, ale z mojego doświadczenia wynika, że im większy poziom zaufania w zespole/ organizacji, tym z czasem jest łatwiej trzymać się opracowanych postanowień.
O projektach, w których scrum się nie sprawdza
Bardzo małe produkty, albo tworzenie proof of concept to coś, do czego scrum niespecjalnie przystaje i może być czymś w rodzaju armaty na wróble. Inwestycja w scruma w małych, niewymagających projektach może być wyższa niż oczekiwane korzyści. Jeśli produkt jest oczywisty i mamy bardzo dokładnie opisane wymagania i pewność, że założenia biznesowe raczej się nie zmienią, to w takiej sytuacji wprowadzanie scruma nie jest dobrym pomysłem. Scrum dobrze radzi sobie w projektach rozbudowanych, dynamicznych, z często zmieniającymi się zarówno oczekiwaniami klienta, jak i warunkami rynkowymi.
O narzędziach, które daje scrum
Scrum daje pewne zasady, definicje, nadaje role w projekcie. Cele poszczególnych ról i wydarzeń są dobrze i jasno opisane w Scrum Guide, co bardzo ułatwia promowanie zwinności w organizacji. Jeśli się wczytamy w Scrum Guide’a, zobaczymy w jaki sposób każdy ten element wspiera zwinność. Na przykład Daily Scrum tę zwinność wspiera w ten sposób, że de facto cały czas planujemy i mamy pod kontrolą to co robimy jako zespół na bieżąco, dostosowujemy się natychmiast do nowych wymagań, od razu rozwiązujemy problemy, wyciągamy je “na wierzch” każdego dnia, a nie raz na dwa tygodnie, gdy zdążą już urosnąć do niebotycznych rozmiarów. Backlog z kolei pokazuje jaki mamy plan na najbliższy czas, a dostosowanie backlogu do nowych warunków pomaga łapać szerszą perspektywę nie tylko na najbliższy sprint, ale także na miesiąc, czy dwa do przodu.
O relacji Scrum Mastera z Product Ownerem
Rola Scrum Mastera wobec Product Ownera to przede wszystkim nauka pracy w ramach zespołu scrumowego, wsparcie w kwestiach budowania backlogu i tworzenia analizy biznesowej. Product Owner to taka osoba, która musi dużo mówić “nie”, bo, zwłaszcza w dużych organizacjach, istnieje sporo stakeholderów i osób decyzyjnych, a każdy z nich jest tak samo mocno przekonany o tym, że jego pomysł, jego funkcjonalność jest kluczowa. I jakoś trzeba tym zarządzić, w czym czasami nieodzowna jest pomoc i wsparcie Scrum Mastera.
O wyzwaniach scruma w dużych projektach
Sporym problemem jest to, że wiele organizacji chce zbyt szybko skalować swoje bardzo zaawansowane produkty, bez podchodzenia do tematu iteracyjnie. Podejście iteracyjne to takie, w którym mamy jeden zespół, on pracuje na zwinnych zasadach, a następnie rozwijamy kolejny, w którym umieszczamy agentów zmiany i oni uczą ten nowy zespół przestrzegania zasad agile. Niestety, zazwyczaj jest tak, że mamy jeden zespół, dorzucamy osiem kolejnych, nikt nie rozumie na czym polega zwinność, ale liczy się sam fakt, że “pracujemy w scrumie”. Inna sprawa to fakt, że w dużych, wielozespołowych projektach planowanie odbywa się na wyższym poziomie, czasami trzeba je organizować pomiędzy reprezentantami poszczególnych zespołów. Jest też kwestia komunikacji wewnątrz zespołów - problemy jednego zespołu wpływają na pozostałe. Wyobraźmy sobie, że mamy jakiś wspólny komponent, czy bibliotekę z której korzystają wszyscy w projekcie i nagle zmieniamy jej wersję. Pozostałe zespoły muszą o tym wiedzieć, przygotować się na to, zsynchronizować działania. Jeśli komunikacja pomiędzy zespołami zawodzi, takich procesów nie da się przeprowadzić bez wpadek. Mówiąc krótko - wszystkie problemy, które występują na poziomie jednego zespołu, w przypadku kilku lub kilkunastu mocno się skalują - i to w postępie geometrycznym.
O zwinności w branży bankowej
Zwinność w branży bankowej już jest. Jeszcze nie na poziomie systemów centralnych, ale na poziomie np aplikacji czy portali, podejście zwinne całkiem nieźle się przyjęło. Klienci w branży bankowej niejako wymagają tych zmian - istnieją rozwiązania typu Revolut, które świetnie i szybko odpowiadają na zmiany w obrębie wymagań biznesowych i to sprawia, że branża bankowa musi się szybciej dostosowywać do klienta, bo konkurencja, nierzadko bardziej elastyczna, nie śpi.
O procedurach w bankowości
Zwinność i Scrum może w pewien sposób uświadomić decydentom w projektach bankowych po co istnieją wybrane procedury. I ze względu na transparentność, rozwiązywanie problemów i reagowanie na bieżąco, nierzadko może się okazać, że praca w Scrumie identyfikuje, które procedury są przestarzałe, nieadekwatne, niepotrzebne. Scrum pyta “dlaczego” i “po co” i dzięki temu pomaga uporządkować pracę, oszczędzać czas i w efekcie pieniądze.
O pogodzeniu monolitu ze Scrumem
Monolity nie lubią zmian, to rzecz oczywista. Ale, zazwyczaj monolity mają takie elementy, które można powoli wydzielać i przekształcać je w elementy zwinne. Oczywiście, można mieć ambicję, by projektem monolitycznym zarządzać całkowicie zwinnie, natomiast wiąże się z to dużymi wyzwaniami typu koszty, czas, nieodporność na zmiany. Wydaje się więc, że strategia wolniejsza, ale pozbawiona tych wszystkich ryzyk, polegająca na wydzielaniu modułów które da się elastycznie zarządzać jest lepszą opcją.
Chcesz sięgnąć po więcej? Całą rozmowę z Karolem znajdziesz tutaj:
https://soundcloud.com/user-381845270/scrum-w-duzych-projektach-bankowych
7 nieoczywistych kompetencji miękkich przydatnych w pracy programisty
O kompetencjach miękkich w kontekście IT mówi się w ostatnich latach coraz więcej, co bardzo cieszy, bowiem przez dłuższy czas obszar inteligencji emocjonalnej był w IT mocno niedoceniany. Dziś to podejście podlega sporym zmianom, a managerzy i szefowie działów IT dostrzegają zalety budowania zespołów technicznych z uwzględnieniem kompetencji miękkich. Specyfika IT pokazuje jak ważne w codziennej pracy zespołów technicznych są umiejętności komunikacyjne czy zdolność do skutecznej pracy w grupie. Istnieją jednak takie kompetencje, które z pozoru wydają się w IT niepotrzebne, jednak po głębszym zastanowieniu można dojść do wniosku, że posiadanie ich bardzo ułatwia codzienną pracę. Wybraliśmy 7, naszym zdaniem przydatnych i nieoczywistych kompetencji miękkich, które są bardzo ważne w kontekście pracy w IT:
Zarządzanie emocjami
Zarządzanie emocjami jest umiejętnością przydatną ogólnie w biznesie, natomiast w branży IT pełni szczególną rolę. Zarządzanie emocjami najogólniej rzecz ujmując sprowadza się do interpretowania, kontrolowania i bieżącej regulacji własnych emocji w taki sposób by nie przeszkadzały one w działaniu.
W psychologii zdolność do dostrzegania i interpretowania własnych emocji, określa się mianem wglądu. To niezbędna umiejętność do tego, by pracować nad samokontrolą, nie reagować pod wpływem silnego wzburzenia, a także przyjmować właściwe interpretacje różnych sytuacji, nie zniekształconych przez emocje. W branży pełnej wyzwań, jaką jest niewątpliwie IT nie brakuje okazji do spięć, frustracji czy złości, więc tym ważniejsze jest kontrolowanie tych sytuacji na tyle, by nie wpływały one zbyt silnie na pracę. Wysoki poziom pobudzenia emocjonalnego wpływa negatywnie na efektywność, skupienie i uwagę, a przecież to właśnie te procesy nierzadko stanowią o powodzeniu przy pisaniu skomplikowanego algorytmu, lub analizowaniu krytycznych błędów w aplikacji.
Elastyczność
Elastyczność to, w dużym uproszczeniu, zdolność dostosowania się do zmieniającej się sytuacji, bez ponoszenia dużych kosztów emocjonalnych. Osobom elastycznym łatwiej jest radzić sobie, gdy “zasady zmieniają się w trakcie gry”, dlatego ta cecha w pracy programisty przydaje się nadzwyczaj często. Bo niech pierwszy rzuci kamieniem ten, kto nigdy nie był w sytuacji, gdy klient zmieniał wymagania lub podważał wcześniejsze ustalenia, podczas gdy projekt był już w zaawansowanej fazie. Takie sytuacje u osób mocno pryncypialnych budzą frustrację i masę negatywnych emocji, co odbija się najczęściej na pracy, natomiast elastyczność pozwala zachować potrzebny spokój, jednocześnie dając możliwość znalezienia alternatywy przy rozwiązywaniu problemów.
Kreatywność
Przecież jestem programistą, niepotrzebna mi kreatywność, powiesz zapewne. I cóż...na pierwszy rzut oka trudno odmówić racji takiemu rozumowaniu, ale wchodząc głębiej, można zobaczyć, że kreatywność bardzo pomaga w pracy technicznej. Bycie kreatywnym jest silnie połączone z umiejętnością rozwiązywania problemów, bo osoby z tą zdolnością potrafią patrzeć na rzeczywistość z trochę szerszej perspektywy niż reszta. Dostrzegają związki i nawiązania, tam, gdzie pozornie ich nie widać, dzięki czemu potrafią znaleźć nieszablonowe rozwiązanie gdy klasyczne sposoby zawodzą. Osoby kreatywne to mistrzowie workaroundów, często tak niezbędnych, gdy stajesz przed dużym technologicznym wyzwaniem.
Autoprezentacja
To kolejna miękka umiejętność, która pozornie wydaje się zupełnie nieprzydatna w świecie IT. Prezentacje czy wystąpienia, to raczej domena działów marketingu i sprzedaży, pomyślisz. To przekonanie traci dziś na aktualności, bowiem coraz częściej zdarza się, że osoby techniczne prowadzą wewnętrzne warsztaty dla młodszych programistów, biorą udział w technicznych webinarach, a także przygotowują prezentacje dla klientów. W dobie social mediów i trendu jakim jest dzielenie się swoją wiedzą z odbiorcami, firmy technologiczne mocno korzystają z potencjału intelektualnego swoich działów IT. Warto więc rozwijać swoje zdolności autoprezentacji, by w takiej sytuacji czuć się pewniej i móc skupić się wyłącznie na treści tego, co jest do przekazania, bez konieczności zamartwiania się o formę.
Samomotywacja
Firmy technologiczne prześcigają się w tworzeniu pakietów motywacyjnych, systemów premiowych i benefitów, które nie tylko mają zachęcić do pracy w wybranej firmie, ale także utrzymać wysoki poziom motywacji. Takie motywatory zewnętrzne, które nie są immanentną częścią danego zadania mają jednak o wiele niższą skuteczność niż motywacja wewnętrzna, rozumiana jako zaangażowanie w pracę wynikające z chęci wykonania określonego działania, nawet jeśli nie wiąże się z tym żadna nagroda “z zewnątrz”. Ale motywacja wewnętrzna także ma swoje ograniczenia. Zdarza się, że nawet gdy praca w IT jest Twoją pasją i wykonujesz ją z przyjemnością, Twoje chęci z czasem słabną. Wiecznie niezadowolony klient czy przełożony, który regularnie dokłada obowiązków, projekty do “wyklepania”, przy których nie uczysz się nowych rzeczy - to czynniki, które negatywnie wpływają na poziom motywacji wewnętrznej. Dobrze jest więc, gdy potrafisz rozpoznać ten stan i skutecznie mu zaradzić.
Resiliencja
Resiliencja to po prostu odporność psychiczna i umiejętność adaptacji w nieprzewidzianych sytuacjach oraz radzenia sobie z problemami. Ta umiejętność wraca ostatnio do łask, głównie za sprawą pandemii koronawirusa. Można powiedzieć, że ostatnie kilka miesięcy zapewniło organizacjom, pracodawcom i pracownikom ogromny egzamin z resiliencji, który zapamiętamy na lata. Odporność psychiczna to cecha, którą można skutecznie rozwijać, co jest bardzo dobrą wiadomością dla osób, które muszą nad nią popracować. Choć wydaje się, że praca programisty jest bardzo stabilna, nie jest jednak wolna od nieprzewidzianego, zarówno w wymiarze technicznym, jak i biznesowym. Zdarzają się aplikacje, które, mimo najlepszych chęci, okazują się nierentowne i nieatrakcyjne dla odbiorców, bugi, które “wychodzą” już po releasie oprogramowania, czy krytyczne projekty na wczoraj, generujące ogromny poziom stresu. Odporność i umiejętność radzenia sobie z takimi sytuacjami jest niezbędna dla zachowania równowagi, a także sprawia, że każdy kolejny problem przestaje być sytuacją bez wyjścia, a jedynie kłopotem, z którym trzeba sobie poradzić i iść dalej.
Zarządzanie sobą w czasie
Zdarzają Ci się dni, gdy pracujesz przez cały dzień, a wieczorem dociera do Ciebie, że w gruncie rzeczy niczego konkretnego nie zrobiłeś? Powodem może być właśnie nieumiejętność zarządzania sobą w czasie, czyli między innymi brak nadawania priorytetów zadaniom, słaby poziom planowania działań, czy estymacji czasu, a także problem z ustalaniem celów. To wszystko sprawia, że praca pod presją czasu staje się podwójnie stresująca, bo martwisz się nie tylko o to, by zrobić swoje zadanie dobrze, ale także o to, czy “się wyrobisz”. A w branży IT terminowość i efektywność, zwłaszcza w pracy z klientem jest bardzo ważna, warto więc pochylić się nad tym aspektem swojej pracy. Opisywanie wszystkich najskuteczniejszych technik i metod zarządzania sobą w czasie zajęłoby nam zbyt dużo miejsca, tym niemniej polecamy zapoznać się na początek z macierzą Eisenhowera oraz techniką Pomodoro, które świetnie sprawdzą się jako narzędzia wspierające skuteczne zarządzania czasem.
Choć wciąż niedoceniane, dobrze rozwinięte kompetencje miękkie w branży IT niosą za sobą szereg zalet. To ten właśnie aspekt naszej codziennej pracy pomaga rozwinąć potencjał i zwiększyć efektywność, a to przekłada się na coraz lepsze rezultaty w pracy, pozbawionej niepotrzebnej frustracji, obaw, czy negatywnych emocji.
Z punktu widzenia procesów rekrutacyjnych, jakie prowadzimy w INCAT, aby realizować ciekawe zadania w projekcie, w pracy programisty liczą się dla nas nie tylko umiejętność programowania. Wiedza i umiejętności techniczne powinny iść w parze z kompetencjami miękkimi - w codziennych zadaniach programisty ich rola jest o tyle ważna, ponieważ projekty często są różnorodne, wymagają kreatywnych rozwiązań, a także przekazywania informacji technicznych osobom spoza branży. Niezależnie od tego jaką rolę pełni programista, czy jest managerem zarządzającym projektem, czy developerem, powinien być osobą komunikatywną. Zwracamy dużą uwagę na tą umiejętność, gdyż jest ona niezbędna podczas planowania projektu, a także podczas wprowadzania zmian. Tworzenie aplikacji to nie tylko samotne kodowanie – wymaga ono wielomiesięcznej pracy zespołowej oraz współpracy wielu specjalistów, w czym zdecydowanie pomaga wdrożenie opisanych umiejętności w swoją zawodową codzienność. Zdecydowanie wszystkie przekładają się na efektywność pracy, a połączone ze specjalistyczną wiedzą i doświadczeniem zaowocują zdobyciem satysfakcjonującej pracy i poczuciem spełnienia - mówi Karolina Wolf, specjalista ds. HR i rekrutacji w INCAT.
Co sprawia, że architektura mikroserwisów jest tak efektywna?
Od kilku lat na rynku IT możemy obserwować rosnącą popularność mikroserwisów, które powoli spychają na boczny tor dominującą do tej pory architekturę monolityczną. Struktura mikroserwisów, w przeciwieństwie do monolitu to zbiór wielu, niezależnych od siebie usług i procesów, które razem tworzą aplikację. Mikroserwisy to wygodne rozwiązanie przy tworzeniu zaawansowanego systemu lub dużych aplikacji - pozwala na szybkie wdrożenie projektu oraz równoległą pracę nad kilkoma modułami jednocześnie. Choć na mikroserwisach swoje rozwiązania oparli tacy giganci jak Netflix czy Uber, nie tylko to stanowi o niezwykłości tego podejścia.
Elastyczność
Mikroserwisy, w przeciwieństwie do architektury monolitów pozwalają na łatwą modyfikację funkcjonalności w projekcie. Ze względu na to, że każdy mikroserwis to niezależny element aplikacji, można zmieniać, dodawać i usuwać kolejne komponenty w taki sposób, by nie wpływało to na funkcjonowanie całości. Odpadają zatem takie problemy jak cykliczna zmiana testów automatycznych czy ryzyko zatrzymania całej aplikacji przy wdrożeniu następnego modułu.
Łatwa integracja
Otwarte API, wykorzystywane w architekturze mikroserwisów pozwala na szybką i bezproblemową integrację z innymi serwisami. Rozwiązanie takie jak API Gateway pośredniczy w komunikacji pomiędzy modułami, umożliwiając wygodne dostosowanie API pod konkretnych klientów, bez potrzeby umieszczenia go w każdym mikroserwisie.
Skalowalność
Podejście modułowe pozwala błyskawicznie i efektywnie reagować na dynamikę środowiska biznesowego - zmiana wymagań biznesowych nie oznacza restrukturyzacji całej aplikacji, a jedynie tego modułu, który dotyczy danej funkcjonalności. Ponadto w przypadku dużych obciążeń mikroserwisy pozwalają na sprawne zwiększenie liczby instancji, które balansują nadmiarowy ruch w aplikacji, co także adresuje problem wydajności.
Szybkie wdrożenie
Mikroserwisy dają możliwość szybkiego releasu MVP systemu. Wdrożenie w pełni działającej, podstawowej i gotowej do dalszego rozwoju aplikacji jest przy tej architekturze kwestią kilku tygodni. Z kolei dodawanie kolejnych modułów i modyfikacja już istniejących nie komplikuje w żaden sposób możliwości korzystania z systemu przez klientów, ponieważ jest zwyczajnie mniej inwazyjne niż w przypadku monolitu i nie oddziałuje na core aplikacji.
Niezależny development i autonomia
Architektura rozproszona oznacza także niezależność zespołów projektowych. Nie ma tutaj centralnego ośrodka zarządzającego, dzięki czemu przepływ informacji jest płynniejszy. Każdy zespół pracuje nad “swoim” elementem aplikacji i nie musi brać pod uwagę baz danych czy architektury pozostałych modułów. Co ciekawe, mikroserwisy pozwalają na rozwijanie każdego elementu w innej technologii i języku, oraz utrzymanie serwisów na osobnych serwerach i w repozytoriach. Tak rozumiana niezależność rozwiązuje problem długu technicznego oraz zwiększa efektywność samego systemu.
Oczywiście, mikroserwisy nie są lekiem na całe zło. Póki co, nie istnieje architektura, która byłaby pozbawiona wad, a przy tym nadawałaby się do każdego typu aplikacji. Nie inaczej jest z mikroserwisami. W przypadku gdy rozważasz wdrożenie architektury mikroserwisów, kluczowym pytaniem, które powinieneś sobie zadać nie jest “Czy?”, tylko “Jak?”, bowiem nieprawidłowe opracowanie wymagań technicznych i struktury, czy brak przemyślanej obsługi ruchu pomiędzy serwerami, może wyrządzić ostatecznie więcej złego niż dobrego. Zaniedbanie tych kwestii na etapie planowania może spowodować klasyczne wylanie dziecka z kąpielą i w efekcie najprawdopodobniej okaże się, że architektura, która w założeniu miała wiele spraw ułatwić, tak naprawdę spędza sen z powiek wszystkim zainteresowanym. Warto wtedy rozważyć wsparcie partnera technicznego, który ma doświadczenie w tworzeniu rozwiązań opartych o mikroserwisy. Dzięki temu ominiesz wiele trudności związanych z wdrożeniem i jednocześnie będziesz mieć pewność, że czeka Cię sprawny release oraz system, który można modyfikować na tyle elastycznie, by na bieżąco dostosowywać się do szybko zmieniających się wymagań biznesowych.