Zaskakująco refaktoryzacja nie jest często wyzwaniem technicznym. Zespoły zazwyczaj trafnie diagnozują nieefektywny desingkodu. Zazwyczaj również mają pomysły, co należy z tym zrobić, jakich narzędzi użyć, jakich przekształceń refaktoryzacyjnych. Gdyby mieli do dyspozycji wystarczającą ilość czasu oraz wystarczający budżet, to prawdopodobnie doprowadziliby sprawy do końca. 

Posłuchaj, w jaki sposób podeszliśmy do tego tematu w projekcie systemu e-bankowości w Nordea Bank AB S.A. Artykuł ten napisałem razem z Łukaszm Korczyńskim - programistą w Nordea Bank AB.

Kontekst

W wyniku decyzji biznesowych Nordea IT Polska (obecnie Norda Bank AB S.A. Oddział w Polsce) przestała rozwijać system e-bankowości na rynek polski, utrzymując jedynie ten produkt w krajach bałtyckich. Po jakimś czasie zaczęły pojawiać się następujące trudności:

• Klienci biznesowi długo oczekiwali na zlecone funkcjonalności – przeciętnie czas ten wynosił kilka miesięcy od momenty zgłoszenia;
• Niektóre zgłoszenia byłe niemożliwe do zrealizowania ze względu na ograniczenia technologii, w których stworzony był system e-bankowości;
• Klienci czasem zamawiali pojedyncze funkcjonalności tworzone w nowszych technologiach u lokalnych dostawców. Konieczność utrzymywania tych funkcjonalności oraz ich zintegrowania z systemami bankowymi spoczywała na Nordea IT Polska.

Na początku stycznia 2015 roku nawiązaliśmy współpracę (Michał Bartyzel/BNS IT i Nordea IT Polska), której cel został sformułowany następująco: Skrócić czas dostarczania nowych funkcjonalności do 30 dni. Aby nadać tej nowej inicjatywie w organizacji bardziej namacalny wymiar, nadaliśmy jej nazwę – Action-30.

Źródła problemu

Pierwszym krokiem w poszukiwaniu przyczyn problemów rozwoju systemu e-bankowości było przygotowanie ogólnego diagramu RCA.

Wyjściowym objawem, od którego zaczęliśmy analizę było: „Zmiany trwają długo albo są niemożliwe”. To, czego poszukiwaliśmy to przyczyny, do których zbiega się znaczna liczba objawów oraz zapętleń. Przykład takiego zapętlenia pokazuje poniżej.

Posiłkując się opracowanym diagramem wskazaliśmy dwie źródłowe przyczyny analizowanego problemu, że „Zmiany trwają długo albo są niemożliwe”:

• Używanie szkieletu Struts 1.2– system, nad którym pracowaliśmy, był rozwijany od prawie dziesięciu lat. Pierwotnie użyto w nim Struts 1.2 - szkieletu do tworzenia aplikacji webowych; w roku 2015 to rozwiązanie było już archaiczne i znacznie ograniczało możliwość tworzenia nowoczesnych aplikacji internetowych.
• Nadmierna uniwersalność kodu– system był tworzony przez wiele osób, wdrażany w kilku krajach, w których zależnie od regulatora usług bankowych, niektóre funkcjonalności nieznacznie różniły się od siebie; owe zróżnicowanie zostało zaimplementowane poprzez umieszczenie instrukcji warunkowych po stronie widoku (vieww tym kontekście to, co widzi user), serwisów aplikacyjnych, oraz w niektórych usługach domenowych. W konsekwencji kod charakteryzował się względnie dużą złożonością cyklomatyczną (cyclomatic complexity).

Analiza architektury

Kolejnym krokiem była sesja diagnozowania problemów związanych z istniejącą architekturą. Za kluczowe, mające bezpośredni i największy związek czasem dostarczania funkcjonalności, uznaliśmy:

• Konieczność przestrzegania architektury Struts 1.2­  - architektura ta nie była stworzona według paradygmatu convention over configuration, co wydłuża dodawanie oraz modyfikowanie funkcjonalności.
• Przetwarzanie biznesowe na stronach JSP (nieczęste przypadki)– ten sposób pisania jest wyjątkowo nieprzyjazny szybkiemu wprowadzaniu zmian.
• Duża ilość nieużywanego kodu– w związku z tym, ze system przestał być wdrażany w Polsce, kod z tym związany był nieużywany i nierozwijany, a jednocześnie obecny w głównej linii kodu (ang. code baseline).
• Silne zależności od innych systemów– ten aspekt wydłużał czas implementacji przede wszystkim wtedy, gdy nowe wymaganie powodowało zmiany w głównym systemie transakcyjnym (ang. core system).

Analiza procesu dostarczania oprogramowania

Na etapie analizy procesu dostarczania oprogramowania skupiliśmy się na poszczególnych czynnościach pomiędzy zgłoszeniem zapotrzebowania biznesowego a wdrożeniem oprogramowania. Szukaliśmy w pierwszej kolejności wąskich gardeł procesu, a także takich rodzajów zgłoszeń biznesowych, które najczęściej były odrzucane z powodu ograniczeń technologicznych. Największy wpływ na przepustowość tego procesu miały:

• Wielozadaniowość– programiści byli zaangażowani w więcej niż jeden projekt, w skrajnych przypadkach samo przełączenie się pomiędzy zadaniami z różnych projektów włączając to przełączenie między środowiskami programistycznymi oraz wejście w tryb efektywnego realizowania zadań zajmowało od 30 do 60 minut.
• Nieefektywne spotkania– ilość projektów jednocześnie realizowanych przekładała się na ilość spotkań.
• Specjalizacja programistów– utrudniało to współpracę oraz powodowało duże lokalne obciążenia poszczególnych programistów.

Metoda pracy

Od samego początku zdawaliśmy sobie sprawę z zestawu ograniczeń, w których musieliśmy się poruszać:

• Action-30 nie może zaburzać toczących się projektów.
• Początkowo w przedsięwzięciu może wziąć pięciu ochotników.
• Każdy z programistów może poświęcić na pracę nad Action-30 jeden dzień w tygodniu.
• Możliwie szybko trzeba pokazać biznesową korzyść z inwestycji w refaktoryzację.
• Metoda pracy powinna być ciekawa i angażująca, gdyż praca nad Action-30 jest zajęciem dodatkowym.

Ostatecznie zdecydowaliśmy, że będziemy pracować w a’la Scrum. A’la ponieważ nie był to właściwie Scrum lecz swobodna na jego temat wariacja. Nazwanie naszej metody a’la Scrumem miało bardziej charakter PR-owy i motywacyjny dla zespołu niż korzystanie ze szkieletu Scrum. Założenia metody pracy były następujące:

• Cały zespół pracuje nad Action-30 wyłącznie w czwartki.
• A’la sprint trwa jeden miesiąc, czyli 4 czwartki.
• Po zakończeniu a’la sprintu odbywa się retrospektywa, przegląd z możliwie dużą liczbą potencjalnych interesariuszy oraz planowanie kolejnego a’la sprintu.
• Nad zadaniami pracujemy dwójkami.
• W porozumieniu z Kierownikiem Działu podjęliśmy wspólne zobowiązanie konsekwentnego unikania nieproduktywnych spotkań.
• Aby ułatwić zespołowi osiągniecie sukcesu w trakcie planowania szczegółowo dekomponowaliśmy zadania na składowe nie dłuższe niż 4 godziny.
• Każdy a’la sprint ma konkretny i mierzalny cel do osiągnięcia.

A'la sprint 1

Na pierwszy a’la sprint zaplanowaliśmy zestaw zadań organizacyjnych oraz tylko jedno zadanie techniczne. Polegało ono na wyodrębnieniu z systemu e-bankowości bezpiecznego webserwisu udostępniającego dane dla jednego z widoków. 

Dlaczego tylko jedno zadanie techniczne na 20 osobodni? Przede wszystkim dlatego, aby mieć niemal zagwarantowany sukces pierwszego sprintu. Inicjatywy takie jak Action-30 są dość niestabilne w organizacji, niewielka awaria w bieżących projektach może skutecznie uniemożliwić zespołowi zaplanowane prace nad nową inicjatywą. Dla przyszłości całego przedsięwzięcia korzystniej jest mieć jeden malutki sukces, niż wielkie plany co do których entuzjazm ulatnia się po dwóch tygodniach.

Retrospektywa

Podsumowanie zespołu po pierwszym a’la sprincie było następujące:

• Cel został osiągnięty.
• Bardzo dobrze pracuje się w dwie osoby nad zadaniem.
• Spotkania się ustrukturyzowały i zagęściły, z perspektywy czasu trwania jest ich mniej.
• Udało się zrobić więcej niż planowaliśmy.
• Wprowadźmy jeszcze więcej zespołowego planowania.

Obserwacje

Pierwszą sprawą, która momentalnie zwróciła naszą uwagę było to, że Action-30 zaczyna żyć własnym życiem. Pozostali pracownicy rozmawiają o tej inicjatywie w kuchni, przy kawie. Interesują się, pytają czy można się przyłączyć.

Ku zaskoczeniu zespołu udało się wykonać więcej pracy niż to zostało zaplanowane. Stało się tak dlatego, że poszczególni programiści poświęcali na pracę nad Action-30 więcej czasu niż planowane czwartki. Sam ten fakt jest bardzo interesujący. Oczywiście żaden z bieżących projektów nie ucierpiał. Wysnuwamy na tej podstawie wniosek, że jeśli coś jest fajne i ciekawe, to czas się znajdzie. Co więcej, ten „dodatkowy” czas nie wymaga formalnego harmonogramowania i procedowania. Ludzie z własnej inicjatywy inicjują lokalne optymalizacje, aby pracować na tym, co rzeczywiście się im podoba.

Pierwszy a’la sprint unaocznił również ogromną wartość managera w przedsięwzięciach tego typu – inicjujących zmianę. Zespół świetnie sobie poradzi z zadaniami technicznymi, lecz w przypadku zadań organizacyjnych, a zwłaszcza takich które zmieniają sposób współpracy pomiędzy jednostkami organizacyjnymi i przełamują silosy, potrzebna jest pomoc kogoś kto zna formalne i nieformalne ścieżki decyzyjne w organizacji. Dzięki pomocy managera zespół ograniczył ilość spotkań oraz zainicjował inne kanały komunikacji ze współpracującymi wydziałami.

W kontekście zespołu zaczynały być również widoczne powstające zasady współpracy (ang. team norms):

• Zawsze pracujemy w dwie osoby nad zadaniem.
• Świętujemy sukcesy
• Unikamy nieproduktywnych spotkań.
• …

a także wytyczne refaktoryzacji (ang. refactoring guidlines) w formie opisu typowych zadań oraz problemów i ich rozwiązań. Wytyczne te porządkowały wiedzę zespołu. Przeznaczone były również dla przyszłych członków zespołu.

A’la sprint 2

Począwszy od drugiego a’la sprintu planowaliśmy regularne pokazywanie interesariuszom korzyści biznesowych refaktoryzacji. Chociaż refaktoryzacja jest zmianą struktury kodu bez zmiany jego zewnętrznych funkcjonalności, to bez wskazywania na efekty biznesowe jest ona praktycznie nie do „sprzedania”. Wykorzystaliśmy dwa podejścia:

• eskalowanie organizacyjnych korzyści z refaktoryzacji – wskazujemy mierzalne korzyści z refafaktoryzacji dla organizacji np. skrócenie czasu dewelopmentu.
• architectural slices of customer-centric features– pracę refaktoryzacyjne zawsze łączymy (w rozsądnej proporcji) ulepszeniem/dodaniem wartościowych funkcjonalności.

Raport – podstawowe narzędzie komunikacji z organizacją

W trakcie początkowych analiz zwróciliśmy uwagę na dużą ilość nieużywanego kodu. Tak jak wspomnieliśmy wcześniej, system przestał być rozwijany na rynek polski, jednak kod związany ze specyfiką polskiej bankowości był wciąż obecny w głównej linii kodu. Dodatkowo kod nie był opakowany („zenkapsulowany”) lecz umieszczony wewnątrz algorytmów. Oznacza to, że zarządzanie zmiennością oraz rozbudowa systemu odbywała się nie poprzez dodawanie nowych implementacji lecz poprzez dokładanie instrukcji warunkowych wewnątrz metod.

Aby dotrzeć z przekazem do decydentów postanowiliśmy wyrazić korzyść z usunięcia tego kodu w języku pieniędzy i harmonogramu. W tym celu przygotowaliśmy próbkę kodu w którym zmierzyliśmy ilość wierszy oraz złożoność cyklomatyczną przed oraz po usunięciu kodu związanego z polskim rynkiem. Choć mierzenie ilości wierszy kodu daje niewiele informacji programiście, to dla osoby nietechnicznej jest to synonim rozmiaru oprogramowania. 

O wiele ciekawsza jest złożoność cyklomatyczna kodu. Daje ona informację o liczbie ścieżek decyzyjnych w kodzie, a zatem jest również miarą ilości testów koniecznych do pokrycia funkcjonalności. Okazało się, że po usunięciu „polskiego” kodu złożoność tej próbki zmalała o 15%., co przełożyło się na redukcję liczby koniecznych testów o 29. 

W tym momencie pozwoliliśmy sobie na trochę karkołomną szacunkową ekstrapolację – aproksymując otrzymane wyniki po wszystkich podobnych próbkach w kodzie i przeliczając liczbę zredukowanych testów na dni robocze otrzymaliśmy pewne przybliżenie na temat tego ile „mendejdów” możemy zaoszczędzić dzięki proponowanej refaktoryzacji. To jest już informacja, która z pewnością zostanie usłyszana…

W dużej organizacji, podstawowym narzędziem komunikacji o dużym znaczeniu są raporty. Raz opublikowany raport jest przekazywany pomiędzy skrzynkami mailowymi niczym plotka w kuchni, a informacja w nim zawarta dociera do szerokiego grona odbiorców. Przygotowaliśmy więc raport z opisanymi szacunkami i przesłaliśmy do najbliższego przełożonego. Tak jak się spodziewaliśmy informacja o korzyściach z refaktoryzacji została usłyszana oraz zrozumiana.

Pokażmy wartość biznesową

Drugą metodą działania było łączenie prac refaktoryzacyjnych z ulepszaniem/dodawaniem wartościowych funkcjonalności. Chociaż refaktoryzacja jest z definicji upiększeniem kodu bez zmiany jego funkcjonalności, to jednak wydaje nam się konieczne ze względów organizacyjnych i finansowych łączyć ją dodawaniem wartości do produktu preferując zazwyczaj tę drugą aktywność.

Postanowiliśmy, że biznesową wizytówką refaktoryzacji będzie zrealizowanie jednej z tych funkcjonalności, które do tej pory były oczekiwane przez biznes, lecz niemożliwe do wykonania ze względów technologicznych. 

Tak jak wspominaliśmy jedną z głównym przyczyn problemów z dostarczaniem oprogramowania było używanie szkieletu Struts 1.2 – zdecydowaliśmy się wypróbować AngularJS.

Ponieważ zespół nie posiadał wcześniejszych doświadczeń z nową technologią, skupiliśmy się w pierwszej kolejności na dokładnym wyspecyfikowaniu ekranów użytkownika, a następnie zaprosiliśmy specjalistę do JavaScrpit na kilkugodzinny warsztat. Jego zadaniem było przygotowanie w AngularJS widoków oraz przekazanie podstaw jego konstrukcji i działania tak, aby zespół był w stanie wdrożyć go w swoim systemie. 

W ten sposób programiści mogli się skupić na refaktoryzacji backendu, ostylowaniu nowych ekranów oraz zintegrowaniu ich systemem e-bankowości. Zmniejszyliśmy drastycznie próg wejścia w nową technologię i umożliwiliśmy łatwiejsze osiągnięcie sukcesu. Na tamtym etapie priorytetem było wypromowanie konieczności refaktoryzacji, a nie migracja do nowej technologii.

Biznes chce więcej

Od tamtej pory planowaliśmy kolejne a’la sprinty tak, aby refaktoryzując dostarczać jednocześnie biznesową wizytówkę tej refaktoryzacji – najczęściej w postaci najbardziej pożądanych przez biznes funkcjonalności. 

Współpracujący z nami manager dbał, aby na review a’la sprintów było obecnych możliwie dużo potencjalnych interesariuszy. Widocznym efektem takiego działania był fakt, że kierownicy projektu prosili o dostarczenie kolejnych „ładnych” fukcjonalniści”. Jednocześnie do inicjatywy Action-30 przyłączyło się kilku programistów z innych zespołów, a zatem nasz marketing wewnętrznych odniósł skutek.

Najbardziej zaskakującą informacją była ta, że „podobno top management zainteresował się Action-30”. Po weryfikacji okazało się, że była to, precyzyjnie rzecz ujmując, plotka. Jednak dla naszej inicjatywy jak najbardziej korzystna. Zrozumieliśmy wtedy, że Action-30 przebiło się ze swoim komunikatem do świadomości organizacji i zaczęło żyć własnym życiem.

Jak to wszystko się skończyło?

W wyniku ruchów na poziomie korporacji zapadała decyzja o stopniowym wygaszaniu rowoju systemu e-bankowości w Polsce. Zatem nie udało nam się doprowadzić Action-30 do końca. Proaktywność zespołu została jednak zauważona, gdyż otrzymali oni zadanie przejęcia ważnych projektów w „nowoczesnych” technologiach od zagranicznych partnerów.

To, co przede wszystkim podkreślał zespół to fakt, że się da. Że można zainicjować i wypromować poważną zmianę w dużej organizacji tworzącej wrażliwe oprogramowanie. Programiści doświadczyli, że mają wpływ na decyzje organizacji, i że mogą przebić się ze swoimi technicznymi potrzebami. Czy można chcieć więcej?

Tekst został przygotowany za zgodą Nordea Bank AB S.A. Oddział w Polsce.