Wracam do tematu długu technicznego i obiecanego jakiś czas temu pytania o to, jak radzić sobie z tym zjawiskiem. Piszę o Scrumie, ale w każdej innej metodzie, z dokładnością do specyficznych dla niej praktyk, podejście może być analogiczne.

Przypomnę na początek, że dług techniczny to skutki kiepskich decyzji podejmowanych w trakcie pracy nad produktem, braku dbania o jakość, posługiwania się marnymi narzędziami i praktykami, wreszcie pomijania niezbędnych czynności, czego skutkiem jest powstanie czegoś, co tylko pozornie zostało w pełni ukończone.

Taki dług Developerzy mogą generować świadomie, gdy brak im profesjonalizmu albo nieświadomie, gdy nie mają wystarczających kompetencji, by zdawać sobie z tego sprawę.

Istnienie długu technicznego w produkcie powoduje masę problemów, na przykład:

  • generuje nową pracę do wykonania (bo dług trzeba spłacić z odsetkami),
  • zmniejsza przejrzystość stanu produktu,
  • powoduje, że rozwój produktu staje się coraz wolniejszy,
  • prognozowanie i szacowanie obłożone są coraz większym błędem (bo ciężko dobrze przewidzieć skutki istnienia długu),
  • powoduje spadek motywacji (bo naprawianie błędów i usuwanie długu nie jest ciekawe),
  • generuje konflikty (bo często szuka się odpowiedzialnych za problemy, jakie spowodował dług).

To oczywiście tylko niewielka lista skutków nagromadzenia się długu w produkcie. W skrajnym przypadku może dojść do sytuacji, w której dalszy rozwój produktu przestaje w ogóle być możliwy, bo próba zmiany w nim czegokolwiek powoduje, że coś innego przestaje działać.

Ograniczanie skali długu technicznego

Zapobiegając kumulacji długu, pamiętać trzeba, że nie jest możliwe zbudowanie produktu całkowicie pozbawionego długu technicznego. To, co robimy, potrafi się zestarzeć i stanie się długiem, choćby wcześniej było technicznym majstersztykiem.

Nie chodzi więc o całkowitą eliminację długu, ale o utrzymywanie go na stałym poziomie, jak najmniejszym, przy racjonalnych kosztach jego zwalczania. Dzięki temu możliwe staje się wytworzenie produktów nadających się do użycia i dalszego rozwoju, a jednocześnie koszt ich zbudowania jest akceptowalny.

Developerzy mają obowiązek przeciwdziałać długowi technicznemu i w ramach tej odpowiedzialności muszą robić między innymi następujące rzeczy:

  • uzgodnić Definicję Ukończenia taką, by nie dało się łatwo i bezrefleksyjnie długu technicznego w produkcie powiększać,
  • uwzględniać w oszacowaniach i w trakcie Planowania Sprintu potrzebę eliminacji długu technicznego tak, żeby była w ogóle przestrzeń do takich działań,
  • identyfikować dług (np. w trakcie developmentu) i usuwać go w miarę możliwości na bieżąco, a nie czekać, aż sam się objawi problemami w produkcie, zgłaszanymi przez użytkowników lub Product Ownera,
  • uświadomić Product Ownera, jaki jest realny stan produktu i poziom długu technicznego oraz jakie są konsekwencje istnienia tego długu.

Oczywiście to nie znaczy, że między Developerami i Product Ownerem nie ma prawa odbyć się dyskusja, czy i jaki dług powinien zostać wyeliminowany i ile czasu można na to poświęcić. Niemniej to Developerzy mają obowiązek być dostatecznie asertywni, by ograniczyć skalę długu technicznego do poziomu, który pozwoli skutecznie (czyli we właściwym momencie, a nie zbyt późno) dostarczać produkt o wymaganej jakości.

Kto odpowiada za zwalczanie długu technicznego?

Dług techniczny to domena przede wszystkim Developerów, nie Product Ownera, bo dług ten związany jest z jakością strukturalną produktu, a nie jego cechami funkcjonalnymi czy użytkowymi. Co więcej, Product Owner nie ma zwykle niezbędnych kompetencji związanych z technologią, by samodzielnie analizować, czy i jaki dług istnieje w produkcie i jakie mogą być tego implikacje.

Skoro to Developerzy odpowiadają za walkę z długiem, nie mogą oddać Product Ownerowi decyzji odnośnie do tego, kiedy i czy w ogóle zostanie on spłacony. A tak się stanie, jeśli praca związana ze spłatą długu będzie zawsze ujęta w specjalnie na tę potrzebę stworzonych elementach Backlogu Produktu. Product Owner może każdy taki element przesuwać w dół, odkładając w czasie jego realizację. Lub nawet wyrzucić go z Backlogu.

Nie jest więc dobrą praktyką zarządzanie długiem technicznym w ten sposób, że tworzy się na poczet walki z nim elementy Backlogu Produktu, co nie znaczy, że w niektórych sytuacjach tak się nie stanie (o tym później). I to z paru jeszcze powodów, poza tym wskazanym powyżej.

Po pierwsze, Backlog powinien opisywać sposób kreowania wartości dla użytkowników i osiągania Celu Produktu – spłacanie długu technicznego nie jest kreowaniem wartości, a co najwyżej jej przywracaniem do poziomu, jakiego nie udało się (mimo wcześniejszych deklaracji) faktycznie zapewnić.

Po drugie, dodawanie do Backlogu Produktu elementów opisujących potrzebę usunięcia długu technicznego obniży przejrzystość samego Backlogu – przede wszystkim dla interesariuszy, którzy nie muszą rozumieć kwestii technicznych związanych z istniejącym długiem.

Po trzecie, w systemowy sposób Zespół umówi się, że z długiem walczy wyłącznie w wybranych momentach – wtedy, gdy realizowane są te zdefiniowane w Backlogu elementy, a nie stale, w każdym Sprincie, przy realizacji każdej zmiany w produkcie.

Oczywiście żadna skrajność nie ma sensu. Może okazać się, że usunięcie długu technicznego wymaga tak dużej inwestycji, iż to jednak Product Owner musi zdecydować o momencie, gdy niezbędne prace zostaną wykonane. I wtedy rzeczywiście w Backlogu Produktu pojawi się stosowny element opisujący taką potrzebę. Powinien to jednak być raczej wyjątek niż reguła.

Rejestr długu technicznego

Niektóre Zespoły tworzą osobny rejestr długu technicznego (nie jest to Backlog Produktu) i w czasie Planowania Sprintu decydują, ile elementów z tego rejestru zrealizują. Czy to dobry pomysł? Niewątpliwie eliminuje to potrzebę posługiwania się elementami Backlogu Produktu, ale taki rejestr długu ma też wady.

Problem pierwszy: pojawi się pokusa (lub presja ze strony interesariuszy), by odkładać pracę nad długiem do czasu, gdy uzbiera się go sporo, bo przecież ważniejszy jest Backlog Produktu. W efekcie poziom długu zacznie falować, cyklicznie rosnąc do momentu, aż znów zostanie zredukowany. Jeśli pojawi się konieczność pilnego wytworzenia jakiejś zmiany w produkcie tuż przed planowanym przełączeniem na tryb usuwania długu (czyli gdy jest tego długu sporo), ta pilna zmiana może okazać się trudna do realizacji. Albo wręcz trzeba będzie ją odłożyć w czasie i najpierw ograniczyć dług techniczny.

Problem drugi: Developerzy mogą wykształcić dwa tryby pracy, jeden związany z rozwojem produktu, a drugi z jego naprawianiem (usuwaniem długu), zależnie od tego, czy realizują elementy Backlogu Produktu, czy zadania z rejestru długu technicznego. Bardzo szybko doprowadza to do erozji poziomu praktyk technicznych w tym pierwszym trybie, bo przecież nawet, jak zrobi się coś byle jak, potem można to naprawić. Tyle że efektywnie Developerzy oduczają się jak rozwijać produkt, nie psując go jednocześnie.

Trzeci problem: istnienie dwóch rejestrów (Backlogu Produktu i rejestru długu technicznego) może spowodować spadek przejrzystości oraz kłopot w podjęciu decyzji, który rejestr jest ważniejszy i wymagają pilnego działania najpierw. Aby uniknąć tej trudności, Developerzy szybko zaczynają tak organizować sobie pracę, że samoczynnie pojawiają się dwa powyżej opisane problemy. Dzieje się tak dlatego, że najczęściej zapada decyzja, by w wybranych dniach lub Sprintach pracować nad długiem, zamiast regularnie sięgać do rejestru z nim w czasie prac nad elementami Backlogu Produktu.

I wreszcie problem czwarty: jeśli konieczne jest stworzenie rejestru długu technicznego, to znaczy, że produkt już w nim tonie. Rzeczy do poprawy jest tyle, że Developerzy przestają ogarniać ich liczbę i gubią się w tym, co powinno być zrobione. Samo stworzenie listy, której elementy opisywać istniejący dług, niczego nie zmieni, a nawet może wygenerować pokusę, by zacząć tym długiem jakoś zarządzać, zamiast po prostu zabrać się za jego usuwanie. Jeszcze do tego wrócę w dalszej części artykułu.

Dług techniczny a Backlog Sprintu

O ile Backlog Produktu nie jest dobrym miejscem do opisu działań związanych z usuwaniem długu technicznego, to Backlog Sprintu nadaje się do tego doskonale. Zawarty jest w nim bowiem nie tylko Cel Sprintu i plan jego osiągnięcia, ale też plan realizacji wszystkiego, co Developerzy zamierzają zrobić w trakcie Sprintu. Jeśli zamierzają (a powinni) pracować nad długiem technicznym, opis tych działań w jakiejś formie również powinien znaleźć się w Backlogu Sprintu.

Czy oznacza to, że o długu technicznym i zakresie prac nad nim Zespół Scrum powinien podyskutować w trakcie Planowania Sprintu? Oczywiście, że tak. Przecież będzie to wymagać developmentu, a więc czasu, którego Developerzy nie mają nigdy w nadmiarze. Niekoniecznie chodzi o precyzyjne zaplanowanie, kto i co zrobi, ale o zarezerwowanie czasu niezbędnego na walkę z długiem i ustalenie jakiejś strategii postępowania.

Czasami pytany jestem, czy możliwe w takim razie jest poświęcenie całego Sprintu na spłacanie długu technicznego i ustanowienie w związku z tym stosownego Celu Sprintu? Odpowiadam: nie, to bez sensu, bo nie zgrywa się z zasadami Scruma. Sprinty służyć mają uzyskaniu korzyści dla interesariuszy, a spłata długu, nie przynosi ich w wyniku wytworzenia czegoś nowego, a jedynie w wyniku poprawienia czegoś, co wcześniej było zrobione źle.

Inaczej mówiąc, taki pseudo-Sprint naprawczy nie przybliża Zespołu nijak do osiągnięcia ustanowionego Celu Produktu, jest też przyznaniem, że wcześniejsze Sprinty odbywały się z lekceważeniem wymogów jakościowych (świadomym lub mimowolnym). Ktoś złośliwy (np. ja) mógłby wręcz stwierdzić, że taka iteracja jest efektem tego, iż Developerzy potrafią albo zrobić coś nowego byle jak, albo naprawiać coś, co zrobili byle jak wcześniej, ale nie są w stanie połączyć dbania o jakość z realizacją zmian w produkcie.

Codzienna walka z długiem technicznym

Zdecydowanie najlepszym rozwiązaniem jest uwzględnienie potrzeby redukcji istniejącego długu w koszcie realizowania zmian w produkcie, zwłaszcza w tych obszarach, gdzie długu jest dużo.

Mówiąc prościej: oszacowania elementów Backlogu Produktu i plan prac nad nimi powinny obejmować również konieczność usunięcia przynajmniej części długu, który istnieje w modyfikowanych obszarach produktu.

Można to podejście połączyć z utrzymywaniem jakiegoś rejestru długu technicznego, ale używanego nie jako osobne źródło pracy dla Developerów w Sprincie, lecz jako źródło informacji o istniejącym długu. W ten sposób, przez zestawienie Backlogu Produktu z tym rejestrem, Developerzy mogą zidentyfikować, jaki dług (które elementy rejestru) może zostać usunięty w trakcie prac nad poszczególnymi elementami Backlogu.

Owszem, takie postępowanie nieznacznie spowolni Developerów i podniesie koszt rozwoju produktu, ale przecież nie da się za darmo spłacić długu. Jeśli na bazie marnych rozwiązań szybko wytworzą oni kolejne marne rozwiązania, dług zacznie rosnąć jak na drożdżach.

Pomysł zarezerwowania jakiejś części Sprintu na walkę z długiem również może być sensowny, ale trzeba strzec się wpadnięcia w pułapkę. Developerzy mogą nauczyć się, że usuwanie długu to jakieś punktowe działanie i traktować tę czynność jako coś zupełnie innego od samego rozwoju produktu. Tymczasem kluczowe dla poprawy stanu spraw jest zaprzestanie kreowania nowego długu właśnie poprzez dbałość o działania realizowane na bieżąco w ramach standardowego developmentu, a nie w wyjątkowych sytuacjach czy wyznaczonym czasie.

Bardzo dobrym pomysłem jest uwzględnienie potrzeby zwalczania długu wprost w Definicji Ukończenia. Jeśli Developerzy umówią się na jakieś zasady powolnej eliminacji długu, zacznie się on zmniejszać. Zasady te mogą wymagać zastosowania określonych narzędzi lub praktyk, ale mogą też wskazywać na oczekiwany poziom miar jakości strukturalnej, którymi posługują się Developerzy do oceny skali istniejącego długu technicznego, a od którego zależy, czy zmiana w produkcie może być uznana za w pełni ukończoną.

O miarach jakości strukturalnej produktu napiszę osobny tekst, bo to szeroki temat, który wart jest czegoś więcej, niż krótkiej dygresji.

Kto i w jaki sposób zarządza długiem technicznym?

Dług techniczny to źródło ryzyka i niepewności, braku przejrzystości stanu produktu, a także generator problemów. Nie należy nim zarządzać, trzeba go ograniczać i eliminować przynajmniej tak szybko, jak się pojawia. Chęć zarządzania długiem oznacza de facto akceptację dla jego istnienia w tym momencie i skutkuje odkładaniem w czasie niezbędnych działań naprawczych.

Wspominałem o rejestrze długu technicznego, który jest przykładem narzędzia używanego do zarządzania istniejącym długiem. Niekoniecznie jednak musi mieć taką funkcję w każdym przypadku.

Jeśli lista jego elementów jest krótka i Developerzy pracują nad nimi regularnie w każdym Sprincie, nie widzę w tym problemu. Z tym zastrzeżeniem, że wolałbym, aby rejestr ów nie stał się równoległym źródłem pracy w stosunku do Backlogu Produktu, tylko uzupełniał go, podpowiadając, jaki dług można usunąć przy realizacji poszczególnych elementów Backlogu.

Natomiast jeśli rejestr długu technicznego jest obszerny i służy przede wszystkim do podtrzymywania wiedzy o tym, jakie problemy wciąż w produkcie istnieją oraz „priorytetyzowania” poszczególnych elementów na liście – to jest już objawem zarządzania długiem technicznym. Czyli służy do odkładania w czasie walki z nim, bo „mamy teraz pilniejsze rzeczy do zrobienia”.

Dlaczego właściwie takie zarządzanie długiem uznaję za szkodliwe? Ponura prawda jest taka, że wszystko, co stanowi nadbudowę na rozwiązaniach skażonych nieusuniętym długiem technicznym, powiększa ten dług. Inaczej mówiąc, im więcej zmian w produkcie oblepi istniejący dług, tym trudniej będzie go usunąć, a w skrajnym przypadku stanie się to niemożliwe.

Przy czym dług ten bynajmniej nie przestanie generować problemów – wręcz przeciwnie, będzie ich coraz więcej, proporcjonalnie do skali niedoróbek, jakie wciąż tkwią w produkcie.

Dlatego można zaryzykować stwierdzenie, że jakaś forma zarządzania długiem technicznym ma sens tylko w sytuacji, gdy już jest go ogromna ilość i potrzeba czasu na wyciągnięcie się z bagna, może być uzasadniona. W każdym innym przypadku zamysł, by nie reagować na dług (taki, który już został zidentyfikowany) i nie pozbywać się go na bieżąco, tylko zacząć nim zarządzać, jest przepisem na odłożoną w czasie katastrofę.