Blog

Wyobraźmy sobie taką oto sytuację: przez kilkanaście miesięcy rozwijamy oprogramowanie, za wszelką cenę dostarczając funkcjonalność wymaganą przez biznes w narzuconych z góry terminach. Nie ma czasu na zadbanie o jakość strukturalną rozwiązania, przez co z wydania na wydanie ilość błędów rośnie, zwiększa się też trudność w ich rozwiązywaniu. Ponieważ często podejmujemy decyzje, by iść na skróty – wszak dotrzymanie terminów jest najważniejsze – dodawanie nowych funkcjonalności jest coraz trudniejsze, ponieważ potykamy się o narastający dług techniczny.

Wreszcie uderzamy w ścianę: ilość błędów i problemów, zarówno technicznych jak i funkcjonalnych, jest tak duża, że większość czasu spędzamy na ich rozwiązywaniu. Rozwój oprogramowania zamiera, choć przecież praca developerom płonie w rękach żywym ogniem.

Wygląda to znajomo, prawda? Praktycznie każdy w branży IT zna choć jeden podobny przypadek, większość zetknęła się z kilkoma, a niektórzy mieli pecha taką pełzającą katastrofę obserwować od środka.

Gdy już dojdziemy do muru, jedynym rozwiązaniem jest zmiana sposobu postępowania. Niezależnie od terminów, nacisków ze strony zarządu, presji biznesu czy prób ratowania się konsultantami, wcześniej czy później jasne staje się, że wybory są w zasadzie trzy.

Toniemy…

Można nie zrobić nic i spokojnie poczekać na bankructwo firmy. Bez zmian w podejściu do wytwarzania oprogramowania jest ono w zasadzie nieuchronne. Dlaczego? Bo produkt jest tak źle wytworzony, że nawet próby rozwiązywania krytycznych błędów kończą się lawiną nowych zgłoszeń o problemach. Próby stabilizowania oprogramowania z wykorzystywaniem procesu, w którym dopuszczalne jest „spawanie na krótko” byleby szybko dostarczyć jakiś kod oznaczają, że z dnia na dzień będzie coraz gorzej.

Wersja 2.0 nas uratuje!

Można podjąć śmiałą decyzję o napisaniu produktu na nowo. Skoro wiemy, co nie wyszło nam w pierwszej wersji, jakoś ją połatajmy aby zyskać czas na wytworzenie wersji kolejnej. Takiej, która będzie „napisana dobrze” (cudzysłów nieprzypadkowy). Gdy tylko będzie to możliwe, odetniemy balast, jakim stał się stary nieutrzymywalny kod… tak przynajmniej nam się wydaje. Niestety, to podejście ma trzy ogromne wady.

Najbardziej oczywista: ryzykujemy, że braknie nam czasu, tym bardziej, że przez długi czas będziemy musieli gasić pożary w starym rozwiązaniu i próbować wytworzyć nowe, które go zastąpi. Cierpliwość klientów korzystających z oprogramowania może się skończyć nim zdołamy dostarczyć im wystarczająco dopracowaną wersję 2.0, a wtedy czeka nas potencjalne bankructwo.

Mniej oczywisty problem: może się zdarzyć, że wersje 1.0 i 2.0 będą używane jednocześnie, przez co na jakimś etapie będziemy mieć wszystkie problemy związane z utrzymaniem starego, źle napisanego rozwiązania, i rozwojem nowego systemu, niedojrzałego i wciąż wymagającego dopracowania. W ekstremalnych przypadkach nie udaje się nigdy odciąć od starego oprogramowania, przez co sytuacja firmy może z dramatycznej zmienić się w katastrofalną (podwojone koszty utrzymania systemów i wciąż wysoka liczba nierozwiązanych błędów).

Często jednak się udaje, wytwarzamy wymarzoną wersję 2.0 i… tu pojawia się trzecie zagrożenie: jest ona napisana równie źle, jak ta poprzednia. Dlaczego? Cóż, decydując się na swoistą informatyczną „ucieczkę do przodu” przed problemami, najczęściej uciekamy też przed koniecznością zmierzenia się z przyczynami, przez które ugrzęźliśmy w długu technicznym. Jako że nowe oprogramowanie pisze się zawsze łatwiej, na początku praca nad nim idzie płynnie i bezproblemowo, bo doskonale wiemy, co próbujemy zbudować. Tylko że mniej lub bardziej świadomie replikujemy wiele z błędnych decyzji, nasz proces wciąż nie zapobiega prowizorkom i irracjonalnym oszczędnościom… a presja czasu rośnie, im dłużej tą wersję 2.0 piszemy. Skoro trzeba się spieszyć, nie dbamy o jakość i wracamy do punktu wyjścia.

Świadomy maintenance

Trzecim rozwiązaniem jest zracjonalizowanie procesu wytwarzania oprogramowania tak, by zyskać czas na redukcję długu technicznego. Im bardziej się pod nim zakopaliśmy, tym większe spowolnienie rozwoju nas czeka – bo więcej błędów trzeba będzie rozwiązać. Być może wiele iteracji (o ile posługujemy się w ogóle procesem zakładającym pracę iteracyjną) poświęcić trzeba będzie na maintenance.

Aby to podejście miało sens konieczne jest zagwarantowanie, że dług techniczny nie będzie powiększany. Nawet jeśli musimy zawołać „wszystkie ręce na pokład!” i zająć się tylko rozwiązywaniem błędów, nie możemy przy tym niczego robić szybko i byle jak. W przeciwnym razie będziemy dreptać w miejscu (coś naprawimy, ale co innego przestanie działać), albo wręcz będziemy kontynuować degradację rozwiązania.

Kanban kołem ratunkowym

Wiele firm szukających dla siebie ratunku przed utonięciem zwraca się w stronę metodyk zwinnych, o których powiada się, że pozwalają robić więcej i szybciej, niż taki na przykład Waterfall. Jest to połowiczna prawda, bo istotą Agile jest zaprzestanie robienia rzeczy niepotrzebnych i optymalizacja procesu tak, by pracując w tym samym tempie osiągać więcej, niekoniecznie produkując dwa razy tyle oprogramowania. Ale na razie pomińmy ten aspekt i wróćmy do maintenancu.

Uważa się, że dobrą metodą zwinną pozwalającą radzić sobie z pracami utrzymaniowymi jest Kanban. Nie wymaga on definiowania iteracji o stałej długości tak jak na przykład Scrum, planowanie może odbywać się w sposób ciągły, można ewolucyjnie usprawniać proces od punktu początkowego, jakim jest stan obecny.

Kanban wybierany jest często również dlatego, że próba rozwiązywania błędów przy pomocy metody Scrum jest zadaniem dość karkołomnym. Nie możemy przecież przewidzieć, kiedy i jakie błędy zostaną zgłoszone – jak więc planować sprinty? Priorytety zmienić mogą się w dowolnej chwili – jak więc zapewnić stabilność w iteracji?

I często to wszystko jest prawdą, należy wszakże zadać sobie pytanie: co chcemy osiągnąć? Ponieważ w zależności od odpowiedzi na nie, być może Kanban będzie złym wyborem.

Trudna decyzja

Dla przypomnienia: Kaban posiada wbudowane mechanizmy pozwalające na ewolucyjne optymalizowanie procesu przepływu zleceń przez proces ich realizacji, ale nie jest metodą „produktową”, czyli nie jest wprost nastawiony na poszukiwanie najlepszych rozwiązań potrzeb biznesowych. Aby rozwijać produkt w Kanbanie i korzystać efektywnie z empirycznego podejścia (a więc działać w pełni zwinnie), trzeba bardzo świadomie z tej metody korzystać, suplementując ją o elementy, które nie są w niej wymagane.

Ponieważ Kanban zakłada ewolucyjne usprawnianie procesu od jego stanu obecnego, wymaga dużej dyscypliny aby nie zatrzymać się dość szybko na szklanym suficie. Dzieje się tak często wtedy, gdy pojawia się poczucie, że jest już dostatecznie dobrze i dalsze usprawnienia nie są pilnie potrzebne – co oznacza, że w praktyce nie pojawiają się wcale.

Wracając do pytania, które wcześniej zadałem: co jest celem dla firmy, która chce uratować produkt nim dług techniczny pociągnie go i firmę na dno? Odpowiedź jest trywialna: poprawienie jakości produktu i nauczenie się, jak o nią dbać długoterminowo.

Czy Kanban pozwoli nam to osiągnąć? Może, ale nie musi. Zastosowanie tej metody może spowodować, że zamiast usprawnić produkt, wyspecjalizujemy się w maintenance. Z pomocą Kanbana udoskonalimy procedury, które spowodują, że będziemy bardzo sprawnie radzić sobie z błędami. Oczywiście to pozwoli jakoś tam kontynuować rozwój produktu, bo choć wciąż będzie on kiepskiej jakości, szybko będziemy naprawiali to, co w developmencie zostało popsute.

Jeśli jednak rzeczywiście chcemy udoskonalić sam produkt, powinniśmy być może skorzystać ze Scruma.

Scrum a maintenance

Tym, czego desperacko potrzebujemy, to mechanizmu wymuszającego jakość strukturalną – bez niej o jakości funkcjonalnej ciężko mówić. W Scrum mamy koncept Definition of Done, która określa jaki produkt spełnia w ogóle kryteria technicznej używalności i nadaje się wydania. Poprzez świadome ustawienie Definition of Done na takim poziomie, który jest osiągalny przez developerów, a jednocześnie wymusza poprawę jakości, uruchomimy powolny ale skuteczny proces wygrzebywania się z błota, w jakim tkwimy.

Kolejną przyczyną, dla której Scrum może okazać się lepszą metodą niż Kanban jest orientacja tej metody na rozwój produktu. Przykładowo: sposobem na rozwiązanie problemów nie zawsze jest naprawianie kodu, ale – nieoczywista rzecz – usuwanie niepotrzebnych funkcjonalności z produktu. To wymaga zaangażowania biznesu (interesariuszy), aby świadomie taką decyzję podjąć. Scrum ma mechanizmy, które temu służą.

Oczywiście Scrum podobnie jak Kanban pozwala doskonalić procesy, narzędzia i komunikację – więc nic nie tracimy decydując się na wybór tej metody.

Problemem będzie konieczność planowania iteracji i ich długość. Ale jeśli zastanowimy się nad tym na spokojnie, może warto robić kilkudniowe (tygodniowe) sprinty? W tak krótkim czasie da się ustabilizować zakres prac na tyle, by praca w Scrum była możliwa, a jednocześnie cały proces będzie na tyle reaktywny, że nie będzie problemu z odpowiednio szybkim rozwiązywaniem nowych, pilnych zgłoszeń. Jeśli zaś pojawiają się krytyczne zgłoszenia, na które należy reagować natychmiast, zespół może podczas planowania sprintu zarezerwować sobie bufor na ich obsługę, lub wyznaczyć „dyżurnego”, który będzie się tym w sprincie zajmował.

Dlaczego warto?

Przede wszystkim dlatego, że w opisanej na samym początku tragicznej sytuacji wciąż musimy pamiętać, co jest celem. Nie jest nim wyłącznie opanowanie pożaru, bo wtedy katastrofa wróci z hukiem za jakiś czas. Celem jest doprowadzenie do takiej sytuacji, by po wygaszeniu ognia (czyli ustabilizowaniu rozwiązania) potrafić dalej go rozwijać bez tworzenia nowego długu technicznego.

Jeśli zespół i organizacja nauczy się korzystać ze Scruma do realizacji maintenance, będzie bez trudu w stanie kontynuować rozwój produktu przy pomocy tej metody. To da zmianę w procesie, który zacnie gwarantować jakość albo wręcz sprzyjać jej podnoszeniu. Co więcej, nie nastąpi rozdzielenie odpowiedzialności wśród developerów na tych, co rozwijają oprogramowanie i tych, co naprawiają produkt, ponieważ usuwanie długu technicznego przeprowadzą te same zespoły, które produkt rozwijają. Nauczą się, dlaczego warto zapobiegać jego gromadzeniu się.