Witamy po długiej przerwie. Niniejszym wznawiamy cykl “Pierwsze Dni Scrum” i wchodzimy w obszar wykraczający poza uniwersalne reguły Scrum, lecz ważny dla wszystkich zespołów stosujących Scrum w obrębie inżynierii oprogramowania, a mianowicie ZPI – zwinny praktyki inżynierskie. Ale zacznijmy od początku:
Dlaczego szybkie dostarczanie “działającego oprogramowania” nie wystarczy?
Wyobraźmy sobie taką sytuację: nasz Właściciel Produktu ma świetny pomysł na biznes i dokładnie wie jak przekazać swoją wizję zespołowi, zespół dobrze rozumie jak działa Scrum i sprawnie się samoorganizuje pod opieką doświadczonego Scrum Mastera, który tydzień w tydzień rozbija w pył wszelkie przeszkody organizacyjne. Mijają sprinty, przyrosty przyrastają, pierwsi Klienci kupują, PO jest zadowolony, zespół jest zadowolony, management się cieszy. Bajka…
Błogostan trwa kilka miesięcy, lecz stopniowo, jakby nie wiadomo skąd, pojawia się coraz więcej zgrzytów:
- znajdujemy coraz więcej błędów i ich naprawianie zajmuje coraz więcej czasu,
- coraz częściej naprawienie jednego błędu powoduje zepsucie czegoś innego,
- dodanie nawet prostych funkcji zajmuje dużo dłużej niż na początku,
- tempo prac (velocity) maleje mimo ulepszeń organizacyjnych wprowadzanych po retrospekcjach.
PO i management myśli sobie, że zespół przestał się starać, więc próbuje zastosować techniki pseudo-motywacji rodem z call center banku detalicznego, wysyłając sygnał, że zespół nie zasługuje na zaufanie i szacunek i musi być zdalnie sterowany i kontrolowany przez czujnych managerów. Zespół próbuje wyjaśnić, że powodem jest wzrastająca złożoność systemu i że to nie ich wina, ale kierownictwo odbiera to jako wymówki. Motywacja spada, produktywność jeszcze bardziej, Klienci zaczynają oglądać się za konkurencją.
Sytuacja tylko się pogarsza szczególnie, że nikt nie zaadresował prawdziwego problemu, gdyż:
Czy da się utrzymać wysokie tempo prac zaniedbując jakość kodu?
Czy znalazłeś się kiedyś w sytuacji, kiedy konieczność szybkiego dostarczania użytkownikom nowych funkcji zdominowało wszystko inne, w tym jakość wewnętrzną (mierzoną np. liczbą WTF/min podczas code review), a nawet zewnętrzną (liczba błędów i niedociągnięć widocznych dla użytkowników)? Czy szef powiedział Ci kiedyś, że “ma poprawnie działać dla użytkowników, a w środku choćby na zapałki” albo “wystarczy jakość na 80%, byle byśmy szybko dostarczyli nowe funkcje“.
To może być rozsądna strategia biznesowa, zakładając, że decydenci w pełni rozumieją konsekwencje swoich decyzji. Jest to problem, bo świetni biznesmeni i managerowie produktu rzadko są jednocześnie doświadczonymi architektami a doświadczeni architekci rzadko świetnie rozumieją reguły biznesu.
Jak w tej sytuacji optymalnie wykorzystać wiedzą i doświadczenie obu stron?
Dług techniczny
Na ratunek przychodzi pojęcie długu technicznego (ang. technical debt), które pozwala obu stronom popatrzeć na postawiony wyżej problem w ich naturalnym języku. Metafora ta została użyta po raz pierwszy przez Warda Cunninghama w 1992 roku. Ward porównał w ten sposób pośpieszną produkcję kodu do szybkiej ekspansji, finansowanej kredytem. Dzięki niemu możemy szybciej osiągnąć nasze cele, lecz w naszej długoterminowej strategii musimy uwzględnić spłatę zaciągniętego długu i liczyć się z tym, że zbyt długie zwlekanie ze spłatą spowoduje narośnięcie kosztownych odsetek. Jeżeli nie poświęcimy czasu na przywrócenie odpowiedniej jakości kodu, coraz trudniej będzie go utrzymywać i rozwijać.
Takie postawienie sprawy pozwala zrównoważyć obie perspektywy. Z jednej strony inwestowanie w jakość może nie mieć uzasadnienia ekonomicznego i architektom łatwiej to zaakceptować, jeśli za cel postawią sobie optymalizację wartości biznesowych, a nie tylko techniczne aspekty produktu. Z drugiej strony odbiorcy staną się świadomi konsekwencji ścinania zakrętów i chętniej zainwestują w jakość widząc jej bezpośredni wpływ na długofalowe utrzymanie wysokiego tempa rozwoju.
Dlaczego nie zawsze dbamy o jakość kodu?
Bo to trudne.
Dlatego, choć nie mam przed oczami statystyki na ten temat, wiem, że większość zespołów nie dba o jakość kodu z zapałem niezbędnym do utrzymania wysokiego tempa rozwoju.
Aby zwiększyć swoje szanse musimy ukształtować nasze otoczenie w taki sposób, by czynniki wspierające znacznie przeważały nad przeszkodami. Przydatny model opisuje Jurgen Appelo w swojej książce “Jak zmienić świat“. Według modelu ADKAR przeszkodą blokującą udaną zmianę może być między innymi:
- Brak świadomości problemu (Awareness) – brak bolesnego doświadczenia zespołu, Właściciela Produktu i kierownictwa w zakresie długofalowych konsekwencji zaniedbania jakości kodu. Co gorsza może się okazać, że w przeszłości osoby te wykopały się z dołka niskiej jakości za pomocą dużej dawki morderczego wysiłku z domieszką szczęścia i teraz uważają, że heroiczny wysiłek i improwizacja niwelują potrzebę systematyczności i proaktywnego inwestowania w jakość.
- Brak motywacji lub aktywna demotywacja (Desire) – jeśli osoba posiadająca władzę w organizacji explicite stawia inne korzyści ponad jakością trudno wykrzesać w sobie chęć dyskutowania. Odpowiedzialny profesjonalista znajdzie sposób, by pokazać jak wysoka jakość wpłynie na sukces w języku odbiorcy i czym grozi jej zaniedbanie, ale często łatwiej jest po prostu podporządkować się obowiązującym oczekiwaniom i zrzucić odpowiedzialność z własnych barków.
- Brak wiedzy i umiejętności (Knowladge i Ability) – inżynieria złożonych systemów jest po prostu trudna. Nawet doświadczeni specjaliści muszą włożyć dużo wysiłku w stosowanie dobrych praktyk i ciągłe poznawanie nowych. Bez wiedzy i umiejętności dobre chęci nie wystarczą.
- Brak mechanizmów utrwalających (Reinforce) – wszystkich powyższych przeszkód nie wystarczy zaadresować raz i o nich zapomnieć. Dla długofalowego sukcesu potrzebne są długofalowe mechanizmy wspierające i utrwalające pozytywne aspekty naszych praktyk oraz niewelujące zagrożenia.
Jak się pozbyć długu technicznego i zapobiegać nierozsądnemu jego zaciąganiu?
Chcesz uniknąć przeistoczenia Twojego zespołu w grupę szambonurków? Przy rosnącej złożoności systemu nie jest to łatwe. Na pewno czeka Cię duży wysiłek. Nagrodą za ten wysiłek jest sukces Twojej organizacji i budowanie Twojej reputacji jako wysokiej klasy profesjonalisty.
Aby odwrócić, albo chociaż spowolnić, zaciąganie długu technicznego albo spłacić wcześniej zaciągnięty dług potrzebne są świadome działania. Jest milion różnych podejść, niżej wybraliśmy dla Ciebie najważniejsze:
Pisząc nowy kod możesz:
- automatyzować testy jednostkowe, integracyjne i funkcjonalne oraz uruchamiać je przy każdej zmianie za pomocą serwera Continuous Integration,
- stosować programowanie zorientowane na testy (Test Driven Development),
- programować w parach,
- dbać o (samo)edukację w zakresie technik pomagających utrzymywać wysoką jakość kodu,
- utrzymywać wysoką czytelność kodu (mierzoną chociażby zrozumiałością dla innych członków zespołu) jako jedno z ważnych kryteriów jakości.
Pracując z istniejącym kodem możesz:
- refaktoryzować, aż do usunięcia prawie wszystkich brzydkich zapachów i osiągnięcia czystego kodu, z którego dumny byłby nawet Wujek Bob.
- stosować statyczną analizę kodu (i poprawiać wykryte usterki),
- badać pokrycie kodu przez testy,
- stosować przeglądy kodu.
W ramach kolejnych dni z cyklu porozmawiamy więcej o wybranych technikach i korzyściach, jakie one wnoszą, a tymczasem zostawimy Cię z dwoma pytaniami.
Pytania do Was:
- Jak często rozmowy między “IT” a “biznesem” na temat jakości kodu i innych spraw technicznych udaje się w Twojej organizacji zakończyć porozumieniem uwzględniającym potrzeby wszystkich zainteresowanych?
- Co robisz na co dzień, by zminimalizować narastanie długu technicznego lub sukcesywnie spłacać dług który nagrabiliście sobie wcześniej?
Skontaktuj się z nami, jeśli chcesz podzielić się swoimi doświadczeniami lub chciałbyś skorzystać z naszej pomocy w osiąganiu Twojego sukcesu.
Marcin Zajączkowski i Michał Parkoła
