Sprinty, maratony i leczenie kanałowe

Wiele zespołów zmaga się dziś z planowaniem czegoś, co zwykle nazywa się pracą techniczną lub redukcją długu technicznego (technologicznego), czyli ulepszeniami systemu, które zespół uważa za ważne chociaż użytkownik o nie nie prosi. Jeśli zbyt mało uwagi poświęcasz tej pracy, to niszczysz produkt, powoli zmieniając go w nieutrzymywalny bałagan. Jeśli poświęcasz jej zbyt dużo czasu, to niszczysz produkt, opóźniając dostarczenie ważnych funkcji biznesowych. Bardzo trudno jest znaleźć i wypracować właściwy balans. Niektórzy uważają, że problemy generuje mikrokontrola spowodowana przez narzędzia do zarządzania zadaniami. Inni twierdzą, że ścisła współpraca z klientami zmienia zespół w fabrykę funkcji, przyjmującą zamówienia od osób, które nie rozumieją znaczenia infrastruktury technicznej. Oczywiście łatwo jest obwiniać kogoś innego, czy to narzędzia, czy nieświadomych interesariuszy, ale przyczyna tego problemu jest bardziej fundamentalna. Z drugiej strony nie jest to szczególnie nowy problem, a dobre rozwiązania istnieją od dawna.

Dostarczanie nowoczesnego oprogramowania opiera się na ścisłej współpracy z klientem i przejrzystości, a zespoły rozproszone potrzebują cyfrowych narzędzi do śledzenia pracy. Żaden z tych czynników sam w sobie nie powoduje, że planowanie prac technicznych urasta do rangi problemu, tylko wyraźniej pokazuje pewne trendy. Jest to jeszcze bardziej widoczne w przypadku, gdy organizacja używa takich podejść jak outcome-driven planning czy eksperymentów w kontekście metod lean. W takich sytuacjach dzięki całkowitemu skupieniu się na celu biznesowym, prace techniczne będą odkładane na później względem rzeczy, które są widoczne i wartościowe z perspektywy klienta. To oczywiście naiwny argument, ale po wysłuchaniu go tak wiele razy podczas rozmów przy tworzeniu Impact Map, czuję, że należy się nim zająć.

Podział pracy na techniczną i biznesową jest błędem na wielu płaszczyznach, ale na razie to pomińmy. Sednem problemu jest fakt, że dużo pracy wydaje się ważne dla osób pracujących nad dostarczaniem oprogramowania, ale nie wydaje się to ważne dla tych, którzy płacą za cały proces. A ponieważ to ludzie kontrolujący budżet są najczęściej odpowiedzialni za ustalanie priorytetów, lista priorytetów jest często zdominowana przez zadania, które łatwo przełożyć na pieniądze. W rezultacie zespoły muszą szukać sposobów na wizualizację, sprzedaż, wyjaśnienie i przekonanie interesariuszy, że rzeczy techniczne są ważne, zwykle wiążąc je z mistycznym pojęciem jakości. To całkowicie błędne podejście, nic więc dziwnego, że rzadko przynosi efekty.

Metafory wyrwane z kontekstu

Duża część problemów ze zrozumieniem wagi pracy technicznej jest spowodowana złą analogią używaną w słowniku biznesowym. Dobre metafory pomagają ludziom łatwo odnieść się do nowej koncepcji, więc mogą być bardzo przydatne do uczenia się nowych rzeczy, ale zbyt dosłownie patrzenie przynosi efekt przeciwny do zamierzonego. Jednym konkretnym słowem-metaforą, które powinno już odejść do lamusa jest myślenie o sprintach rozwoju oprogramowania.

Na przełomie wieków, w okresie szczytowej popularności narzędzi UML, RUP i CASE, oprogramowanie było tworzone na bazie szablonów sowieckich pięcioletnich planów gospodarczych (z porównywalnymi wskaźnikami powodzenia). Sprinty były wówczas użyteczną metaforą, ponieważ w tym kontekście zmuszały ludzi do myślenia o krótszych odcinkach czasu i mniejszych celach. Dwie dekady później, gdy dwutygodniowe iteracje stały się normą planowanie w krótkich cyklach nie stanowi już problemu dla większości zespołów. Metafora sprintu nabrała teraz niebezpiecznego dosłownego znaczenia.

Słowo sprint weszło do języka angielskiego z języków skandynawskich i znaczyło przestraszyć, odskoczyć lub przeskoczyć. Około połowy XIX wieku zaczęło oznaczać krótki bieg na pełnych obrotach. Powiedz dzisiaj słowo “sprint”, a większość ludzi wyobrazi sobie Usaina Bolta, wylatującego z pozycji startowej, jakby wataha głodnych wilków siedziała mu na ogonie i przebiegającego w mgnieniu oka do mety.

Aby pomyślnie “sprintować”, zawodnicy olimpijscy muszą odciąć się od wszystkiego i zwiększyć swoje możliwości poza to, co normalni ludzie uważają za możliwe. Jeśli chodzi o sprinterów, świat stoi w miejscu, gdy biegają. W gorączce wyścigu liczy się tylko przekroczenie linii mety. Usain Bolt może podczas wyścigu lekceważyć przepisy ruchu drogowego czy polityki biurowej i pewnie ani razu nie zastanowi się nad różnicą między kosztami operacyjnymi a kapitałowymi. Ale dostarczanie oprogramowania tak nie działa .

Zespoły programistyczne rzadko mogą lekceważyć otaczający ich świat, a gra nie kończy się wraz z zakończeniem sprintu. Sportowi sprinterzy nigdy nie przechodzą od razu do następnego wyścigu. Nawet mistrzowie olimpijscy mogą biec tylko przez bardzo krótki czas, po którym potrzebują stosunkowo długiego okresu odpoczynku przed następnym starciem. Sprinty w tworzeniu oprogramowania są procesem ciągłym, bez przerw i czasu na odzyskanie sił.

Te dwa rodzaje sprintów nie mają ze sobą nic wspólnego poza tym, że są stosunkowo krótkie. Intensywne i niezrównoważone bieganie jest idealną strategią do sportowych wyścigów sprinterskich, ale totalną katastrofą w pracy z oprogramowaniem. Produkowanie fukcjonalności, mikromanagement i ciągłę odkładanie w czasie pracy nad infrastrukturą powodują, że zespoły programistów mają poczucie intensywnego biegu przez bardzo długi czas na pracującej z pełną prędkością bieżni. Wszystkie sprawy dotyczące refaktoryzacji, ulepszania architektury lub infrastruktury nie dotyczą jakości produktu, a przynajmniej nie tej jakości, na której skupiają się interesariusze biznesowi. To wszystko to inwestycja w długoterminowy zrównoważony rozwój produktu. Nic dziwnego, że zespoły mają problem z umieszczeniem tych rzeczy na roadmapie, gdy dominującą metaforą procesu tworzenia oprogramowania jest szalony wyścig. Dlatego myślenie o sprintach jest niebezpieczne.

Jeśli istnieje sportowa metafora dla dostarczania oprogramowania, byłby nią maraton, a nie sprint. Budowanie udanego produktu to długi i wyczerpujący proces. Przez większość czasu nie dzieje się nic przełomowego. Zamiast robić wielkie skoki w krótkich seriach, ludzie przez większość czasu robią małe, ciągłe postępy.

Pomysł maratonów podoba mi się znacznie bardziej niż sprintów, ponieważ maratończycy muszą dbać o równowagę w perspektywie długiego dystansu. Samo stanie i oddychanie we właściwym rytmie nie wygra wyścigu, ale bieganie bez odpowiedniej techniki oddychania nie zakończy się dobrze. Podobnie, najlepsze praktyki inżynieryjne na świecie nie pomogą, jeśli produkt w rzeczywistości nie przynosi użytkownikowi wartości, ale skupienie się na samych funkcjach biznesowych spowoduje, że zespół odpadnie z wyścigu, zanim jeszcze dotrze do mety. Te dwa aspekty nie powinny konkurować o pierwszeństwo ponieważ są ze sobą mocno powiązane.

Oczywiście ta metafora też nie jest idealna, żadna nie jest. Maratony mają dobrze znany stan końcowy czyli metę do której zmierzają, większość prac nad oprogramowaniem nie (z godnym uwagi wyjątkiem podrasowywania produktu tylko po to, aby sprzedać go konkurencji i patrzeć, jak płonie, gdy starają się go zintegrować). W książce o tworzeniu oprogramowania, Agile Software Development: The Cooperative Game, Alistair Cockburn próbował podważyć metaforę wyścigów, zanim się w ogóle przyjęła, ale Scrum miał znacznie lepszy model marketingowy niż jakiekolwiek inne podejście Agile. Cockburn pisał o grach skończonych czyli tych, które mają określony stan końcowy i nieskończonych, czyli takich, w które gra się w celu kontynuowania gry. Podzielił również gry na kooperacyjne lub konkurencyjne, stwierdzając, że tworzenie oprogramowania jest nieskończoną grą kooperacyjną. Wyścigi to konkurencyjne gry skończone, znajdujące się całkowicie na drugim końcu spektrum. Zrezygnuj z myślenia kategoriami sprintów i maratonów, ponieważ dostarczanie oprogramowania coś zupełnie innego wyścigi. Zamiast tego podczas planowania pamiętaj o idei zrównoważonego rozwoju.

Zrównoważony rozwój to nie tylko tempo

Potrzeba zrównoważonego i utrzymywalnego tempa nie jest oczywiście niczym nowym, jest to jedna z oryginalnych zasad eXtreme Programming. Sprinty, we wczesnych dniach zwinności, podczas gdy metafora wciąż jeszcze miała sens, faktycznie działały na rzecz zrównoważonego rozwoju. Krótsze plany z częstymi przeglądami pomagają zespołom zrozumieć ich faktyczne możliwości, więc myślenie o sprintach jako krótkich wyścigach pomogło ludziom uniknąć zbyt dużej ilości pracy.

Jednak zrównoważony rozwój wymaga znacznie więcej niż tylko zapewnienia, że ​​wszystkie zaplanowane prace mogą zostać ukończone, przetestowane i zintegrowane w ramach iteracji. Ósma zasada manifestu Agile sprytnie nie mówi o zrównoważonym tempie. Mówi o zrównoważonym rozwoju i równym tempie pracy. Często pracuję z zespołami, które na codzień utrzymują swoje tempo, ale czasami muszą się całkowicie zatrzymać, aby spłacić dług techniczny, przeprowadzić sprint stabilizujący znany jako hardeninig lub iterację refaktoryzacji. Oczywiście cała idea iteracji refaktoryzacji jest oksymoronem. Refaktoryzacja pierwotnie była procesem wprowadzania drobnych ulepszeń projektu bez zmiany funkcjonalności, ale słowa mają sposób na wymykanie się z ich zamierzonego znaczenia. Sprinty refaktoryzacji są dużo łatwiejsze do sprzedania niż to, czym w rzeczywistości są, czyli przerwą na gruntowne przeprojektowanie systemu.To jak pit stop Formuły 1, podczas którego mechanicy próbują zainstalować klimatyzację.

Aby utrzymać stałe tempo pracy niezbędny jest zrównoważony proces, ale produkt również musi być zrównoważony. Ta druga część zrównoważonego rozwoju jest często zaniedbywana. W tym miejscu skupia się cała praca, której potrzebuje zespół deweloperski, nawet jeśli niekoniecznie jest ona pożądana lub zrozumiana przez interesariuszy. Brady, firma zajmująca się środkami czystości, sprzedaje etykiety ostrzegawcze, które doskonale wyjaśniają ten problem: „Jeśli nie zaplanujesz czasu na konserwację, Twój sprzęt zaplanuje to za Ciebie”.

Kluczowym problemem związanym z priorytetyzacją zadań technicznych umożliwiających zrównoważony rozwój jest to, że ich modele wartości różnią się znacznie od modeli biznesowych. W przypadku typowych funkcji biznesowych ludzie mogą przynajmniej poczynić pewne założenia dotyczące oczekiwanej wartości. Pieniądze zwykle pojawiają się po dostarczeniu funkcji, stopniowo rosną, gdy użytkownicy zaczynają z niej korzystać, a następnie mają tendencję do spadku, gdy konkurenci nadrabiają zaległości, procesy stają się przestarzałe, a potrzeby klientów zmieniają się. W przypadku potrzeb technicznych wartość może nadejść w pewnym nieznanym momencie w przyszłości, głównie skupia się na zapobieganiu nieznanym problemom, więc bardzo trudno jest ją określić ilościowo.

Poprawa wydajności przynosi zerową wartość, dopóki liczba użytkowników nie przekroczy możliwości systemu, a wtedy zespół musi rozwiązać problem wydajnościowy systemu podczas całkowitej awarii. Poprawa monitoringu wewnętrznego nie przynosi żadnej widocznej wartości, dopóki coś nie spowoduje utraty danych ważnego użytkownika, wówczas różnica między szybką analizą i naprawą a nierozwiązywalnym problemem ma znaczenia. Innym świetnym przykładem jest aktualizacja wersji oprogramowania. Wiele zespołów korzysta z zewnętrznych bibliotek. Projekty te poruszają się we własnym tempie, niezależnie od produktów, które z nich korzystają i mogą wprowadzać przełomowe zmiany w nowych wersjach. Aktualizacja bibliotek wymaga czasu i wysiłku, a rzadko przynosi natychmiastową wartość biznesową, więc może być trudne do uzasadnienia w porównaniu z pomysłami biznesowymi. Z drugiej strony ciągłe nadążanie za małymi zmianami sprawia, że pojedyncza aktualizacja jest łatwa. Jeśli ktoś odkryje i naprawi krytyczny problem, zespoły korzystające z najnowszej wersji z łatwością zainstalują patch. Zespoły, które wciąż używają archaicznych wersji, mogą mieć trudności z szybką zmianą. Świetnym tego przykładem jest luka CVE-2017-5638 w Apache Struts, która w 2017 roku umożliwiła hakerom kradzież danych około 150 milionów osób z Equifax. Błąd został naprawiony przez zespół Struts dwa miesiące przed włamaniem, ale zespoły Equifax nie były w stanie zaktualizować swojego produktu na czas, aby zapobiec włamaniu.

Stwórz budżet zamiast planować

Wiele zespołów nalega na umieszczenie wszystkich zadań na jednej liście i chce używać tego samego procesu do wszystkiego, głównie dlatego, że uważają to za zgodne z wytycznymi Scruma. Następnie mają trudności z opisaniem kryteriów akceptacji dla pracy na rzecz zrównoważonego rozwoju, oszacowaniem jej wartości lub przewidzeniem, ile czasu zajmie wykonanie tych zadań. Interesariusze raczej nie mają zdania na temat kryteriów realizacji takich zadań i nie potrafią porównywać ich z innymi rzeczami. A ludzie rzadko pytają, dlaczego te czynności są potrzebne.

Zamiast przekonywać interesariuszy, aby zobaczyli coś, czego nie można nawet wyrazić słowami, po prostu zapytaj ich, czy produkt musi być zrównoważony czyli rozwijalny i utrzymywalny w perspektywie średnio- i długoterminowej. Jeśli nie, nie martw się o zadania związane z pracą techniczną. Jeśli interesariusze oczekują, że produkt pozostanie w użyciu, poproś o budżet, aby jego rozwój był zrównoważony. Odejmij ten budżet od ogólnej wydajności podczas planowania funkcji biznesowych. W ten sposób możesz mieć dwie kategorie zadań i nie będą one konkurować.

Nie musisz przechowywać zadań technicznych w backlogu produktu ani śledzić ich w narzędziu do zarządzania zadaniami, po prostu wykonuj ich tyle na ile pozwala budżet na każdą iterację. Zespół w większości wie, które z technicznych ulepszeń jest istotne i nie musi trzymać ich na liście widocznej dla nikogo innego. Teoretycznie dobrze jest zrozumieć wpływ zadań pozwalających na zrównoważony rozwój w celu ustalenia ich priorytetów, ale w większości przypadków jest to oczywiste. Na pierwszym miejscu pojawiają się pilne błędy, (w przeciwnym razie nie są one tak pilne), a pozostałe zadania związane ze zrównoważonym rozwojem są zwykle stopniowymi ulepszeniami, więc wybór konkretnego z nich nie jest tak istotny, gdy mamy świadomość, że kolejne z nich będziemy realizować regularnie.

Jeśli utrzymanie prac technicznych poza głównym backlogiem produktu brzmi przerażająco, pozwól, że przekonam Cię, że już tworzysz i planujesz coś znacznie bardziej istotnego niż oprogramowanie, nie mając na roadmapie większości zadań technicznych. Kontynuując trend metafor, które można łatwo wyrwać z kontekstu, sprawdź swój kalendarz na następny miesiąc. O ile nie cierpisz na poważne zaburzenia obsesyjno-kompulsyjne, prawdopodobnie twój kalendarz nie zawiera żadnych wpisów dotyczących brania prysznica lub mycia zębów. Jednak większość ludzi nadal wykonuje te zadania regularnie, bez konieczności ich śledzenia i ustalania priorytetów.

Gdy wszystko przebiega sprawnie, zadania związane ze zrównoważonym rozwojem nie muszą znajdować się w planie, po prostu je robisz. Oczywiście w nagłych wypadkach można pominąć mycie zębów na dzień lub dwa. Ale jeśli całkowicie przestaniesz to robić, jest prawie pewne, że znajdziesz się w ból zębów przerywie twój normalny rozkład dnia zmuszając do wizyty u dentysty. Takie zadania “techniczne” pojawiają się w planie głównie wtedy, gdy coś idzie źle i zwykle mają pierwszeństwo przed wszystkim innym. A jeśli naprawdę wystarczająco długo zaniedbywałeś znaki ostrzegawcze, zamiast zwykłego wypełnienia będziesz potrzebować leczenia kanałowego.

Umieszczanie regularnych zadań związanych ze zrównoważonym rozwojem w kalendarzu spowodowałoby po prostu hałas. Umieszczenie zadań związanych ze zrównoważonym rozwojem w backlogu produktu ma ten sam efekt. Posiadanie budżetu eliminuje presję na planowanie, ustalanie priorytetów lub szacowanie takich zadań i pozwala uniknąć konieczności porównywania ich z funkcjami, które przynoszą natychmiastową wartość. Budżet zrównoważonego rozwoju daje zespołom czas na wykonanie niezbędnych prac usprawniających i utrzymaniowych, ale także wyznacza górną granicę tych zadań. Przejrzyste porozumienie w sprawie budżetu pomaga zapewnić, że praca na rzecz utrzymywalności produktu nie wpływa na regularne prace. Upewnia to interesariuszy, że ich priorytety nie ucierpią, ponieważ ktoś będzie “polerował” zadania techniczne, jednocześnie eliminując potrzebę posiadania wszystkiego na jednej liście i śledzenia w ten sam sposób.

Dotarcie do budżetu

Większość zespołów ma już budżet na zrównoważony rozwój produkty, ale jest on ukryty. Maintanance wykonywany “ad-hoc”, sprinty związane z długiem technicznym i iteracje refaktoryzacji efektywnie wykorzystują ten sam budżet, tylko zostaje on przydzielony, gdy sytuacja staje się nie do zniesienia. Zsumuj czas porządkowania technicznego, który Twój zespół spędził w ciągu ostatniego roku i po prostu świadomie zadeklaruj go jako budżet. Na przykład, jeśli zespół miał w zeszłym roku dwa sprinty hardeningowe trwające dwa tygodnie każdy, to i tak efektywnie spędził 10% czasu na ulepszaniu technicznej strony produktu, powodując dodatkowo poważne zakłócenia w regularnym przepływie dostarczania funkcji biznesowych. Zaplanuj wykorzystanie tego samego czasu, ale rozłóż go tak, aby kumulujące się zadania nie wyeliminowały dostarczania wartości biznesowej. Regularnie “myj zęby” produktu, aby nie trzeba było stosować leczenia kanałowego. Spędzisz taką samą ilość czasu i będzie to znacznie mniej bolesne.

Jedną z opcji wydatkowania budżetu jest stworzenie ścisłego harmonogramu. To odpowiednik codziennej higieny osobistej. Być może zaplanuj pracę nad zrównoważonym rozwojem w godzinach, które zwykle są spokojniejsze, może na początku iteracji. Na przykład zarezerwuj poniedziałkowe poranki na zadania związane ze zrównoważonym rozwojem i pozwól zespołom robić wszystko, co uważają za ważne, aby ulepszyć produkt w tym czasie.

Innym sposobem wydatkowania budżetu jest wprowadzenie do zespołu roli Batmana. Po raz pierwszy spotkałem się z tym pomysłem w książce Jima Shore’a The Art of Agile. (Jest w rozdziale Planowanie Iteracji, dostępnym na stronie internetowej Jima). Jim definiuje rolę w następujący sposób: „W zespole XP Batman zajmuje się nagłymi przypadkami organizacyjnymi i prośbami o wsparcie, aby inni programiści mogli skupić się na programowaniu [sic]”. Batman jest zwykle rolą rotacyjną, a różne osoby biorą na siebie odpowiedzialność za robienie wszystkiego, co wykracza poza normalną pracę, tak aby reszta zespołu mogła pracować nieprzerwanie. W przypadku zespołów z dość stabilnym produktem Batman przez większość czasu nie ma zbyt wiele do roboty. Czekając na pilne prośby o pomoc, Batman na ten tydzień może pracować nad najważniejszymi zadaniami związanymi ze zrównoważonym rozwojem i w razie potrzeby zawiesić je w krótkim czasie bez uszczerbku dla funkcji biznesowych.

Podsumowując, odpowiedź na pytania wstępne składa się z dwóch ważnych kroków:

Nie myśl o zadaniach zespołu deweloperskiego jako o pracy technicznej, myśl o nich jako o pracy na rzecz zrównoważonego rozwoju czyli utrzymywalnego i rozwijalnego produktu.

Skonfiguruj proces planowania tak, aby zrównoważony rozwój nie konkurował z postępem biznesowym.

Aby otrzymać dodatkową wskazówkę, przestań myśleć o sprintach i wróć do bardziej neutralnego pomysłu iteracji z XP, który sugeruje trwający cykliczny proces.