Zarządzanie utrzymaniem w agile

Czym jest utrzymanie w agile? Jakie zagrożenia mogą pojawić się kiedy nie zarządzamy utrzymaniem? Dowiesz się czego powinno się z pewnością unikać. Omawiamy też kilka dobrych praktyk dotyczących utrzymania. Sami z nich korzystamy w pracy z zespołami czy firmami nad ich zwinną transformacją.

Zobacz wersję wideo

Dodatkowe materiały

• Kanban przy kawie – odcinek 6

TRANSKRYPCJA

Jacek: W dzisiejszym odcinku porozmawiamy o utrzymaniu w podejściu zwinnym. Jest to temat, który został zgłoszony przez naszych Słuchaczy w ankiecie, którą niedawno zakończyliśmy i nad tym tematem dzisiaj się pochylimy.

Kuba: W ramach odcinka zdefiniujemy co rozumiemy pod utrzymaniem. Opowiemy jakie są zagrożenia niezaopiekowanego tematu utrzymania i podzielimy się z Tobą praktykami, które nam przychodzą do głowy, gdy myślimy o temacie dobrego ogarnięcia, utrzymania praktyki, z których sami korzystamy, korzystaliśmy w przeszłości i sami je propagujemy obecnie, gdy pracujemy z zespołami czy firmami nad ich transformacją zwinną. Zaczniemy od definicji. To jest o tyle istotne, że to tak pierwsza uwaga na metapoziomie, że to utrzymanie bywa rozumiane bardzo różnie w różnych firmach. Bywa też różnie rozumiane pomiędzy zespołami, a na przykład poziomem managerskim. Więc tutaj tak jak mówię – definiujemy w ramach tego odcinka. To jest coś, co nam pomaga, żebyśmy mówili na temat, ale to też jest pytanie, które warto sobie zadać w czasie pracy, czy w czasie dyskusji na temat tych procesów. Utrzymanie definiujemy jako utrzymanie produkty, rozumiane przed przykłady, błędy ze środowiska tak zwanego produkcyjnego, czyli tego, na którym już korzystają Klienci, z którego korzystają Użytkownicy. Opieka nad tym środowiskiem poprzez na przykład upgrady bibliotek, upgrady frameworków. Być może jakiś monitoring, podłączanie go, aktualizacja. Być może odczytywanie jakichś ważnych informacji z tego monitoringu. Czasem praca utrzymaniowa to są jakieś audyty. Raz na jakiś czas trzeba sprawdzić, czy wszystko działa tak, jakbyśmy chcieli. Może jakieś formalne audyt rozumiany jako przegląd kodu albo przegląd stosowanych procesów czy narzędzi. Utrzymaniem mogą też być jakieś niezbędne prace sprawiające, że produkt dalej funkcjonuje. One nie są zmianą biznesową, nie są zlecone przez biznes, a są niezbędne, żebyśmy dalej dobrze funkcjonowali. To są jakieś parametryzacje, jakieś dodatkowe małe zmiany, które powodują, że wszystko to, czym jest nasz produkt i za co cenią nas nasi Klienci – wszystko to funkcjonuje. Podsumowując – to utrzymanie jest niezbędnym elementem tego, żeby produkt funkcjonował. To może być przez negację, to jest wszystko, co nie jest zmianą biznesową, nie jest projektem, nie jest zlecone przez zamawiających różne rzeczy, czy to Product Ownera, czy też Interesariuszy.

Jacek: Kilka zagrożeń, które widzimy, jeśli chodzi o zarządzanie utrzymaniem. Pierwsze jest takie, że nie zarządzanie w jakikolwiek sposób utrzymaniem powoduje problem dla zespołów, kiedy przychodzi do planowania pracy. Jest to temat, który nieustannie wraca, czy podczas prac z Klientem, czy podczas różnego rodzaju szkoleń, czy warsztatów. A jak sobie radzić z utrzymaniem, kiedy pracujemy zwinnie. Ten problem wynika z tego, że trudno oczekiwać od zespołu skupienia, czy trudno oczekiwać od zespołu efektywności, czy trudno oczekiwać od zespołu przewidywalności. Jeżeli co chwilę pojawia się jakaś praca, która nie jest zaplanowana, jest nieprzewidziana, a z różnych powodów tę pracę musimy wykonać. Tak więc, jeżeli chcemy mieć przewidywalne zespoły warto zarządzać w świadomy sposób tym wszystkim, co przed chwilą Kuba zdefiniowałeś jako utrzymanie.

Kuba: Zagrożeniem niezajęcia się utrzymaniem albo traktowania go po macoszemu jest też to, że koszty wprowadzenia takich zmian mogą zacząć bardzo rosnąć. To będą albo koszty poprawiania rzeczy po dużym czasie albo koszty takie biznesowe, jeśli czymś się nie zajęliśmy. Niezaopiekowane utrzymanie może prowadzić do awarii. Może prowadzić do jakichś problemów związanych z kompromitacją systemu z perspektywy bezpieczeństwa. Szereg kosztów biznesowych, które narastają tylko dlatego i rosną do poziomu już takich krytycznych dla funkcjonowania firmy, tylko dlatego, że ktoś gdzieś kiedyś przeoczył, nie odjął na odpowiednim priorytecie jakiejś drobnej pracy czy jakiegoś drobnego zadania, które sprawia, że nie mamy luk, że wsparcie dla naszego systemu jest nadal aktualne. Te zabezpieczenia i ten poziom technologiczny jest całkowicie zaopiekowanym.

Jacek: Niewątpliwie zagrożeniem jest też wzrost długu technicznego. Czyli takie konsekwentne nierealizowanie rzeczy, które są ważne. Rzeczy, które są istotne. Rzeczy, które powinniśmy zrobić. Długotrwałe utrzymywanie takiego trendu zwykle powoduje problemy i bardzo często te problemy przychodzą znienacka. Tak nam się przynajmniej wydaje. Natomiast zwykle to jest kwestia zaniedbań. Przekładania pracy utrzymaniowej na później. Przesuwanie priorytetów biznesowych ponad te rzeczy techniczne. Takie podejście może powodować sporą frustrację, w szczególności po stronie managementu IT, gdzie zwykle osoby będące na tych stanowiskach odpowiadają za to, żeby od strony IT wszystko było poukładane, zaopiekowane, no tak, żeby ryzyko wszelkiego rodzaju awarii, problemów, opóźnień, jakichś spowolnień systemu występowało jak najrzadziej.

Kuba: Pierwsze te zagrożenia, które wymieniliśmy są takie bardziej od tej strony, że całe utrzymanie jest trochę ignorowane, trochę pomijane i z tego powodu narastają problemy. Ale utrzymanie może też być powiązane z tym, że to jest jedyne co robimy i na przykład frustracja, tak jak Jacek powiedziałeś, managementu IT, że nie robimy utrzymania, może też mieć lustrzane odbicie. Frustracja po stronie biznesowej, że nic innego, co nie robimy tylko utrzymanie ciągle poprawiamy, ciągle naprawiamy, ciągle coś update’ujemy. Nie rozumiemy co to jest strona biznesowa dlaczego projekt nie idzie do przodu. Czy jakaś inicjatywa, czy jakaś kolejna wersja produktu nie jest rozwijana, bo robicie utrzymanie? I to takie jest pojemne hasło a’propos tej definicji. Trochę nie wiadomo co się dzieje. Warto o tym porozmawiać.

Jacek:Kolejnym problemem, czy kolejnym zagrożeniem jest potencjalna frustracja z kolei u developerów. Przed chwilą powiedzieliśmy o tej perspektywie managerskiej, Jeśli chodzi o development, to rzecz, którą bardzo często spotykam, jest narastające niezadowolenie, że rzeczy, które są ważne, nie są realizowane. Z perspektywy developerów, w szczególności w świecie IT, te rzeczy ważne, no to są bardzo często też rzeczy techniczne. Najczęściej wynika to z dobrej woli, z takiej potrzeby dobrego wykonywania swojej pracy. Żeby ta praca była wykonana dobrze, żeby można się było się pod nią podpisać, no to pewne rzeczy muszą zostać zrobione w sposób porządny. Jeżeli developerzy tracą tą przestrzeń, jeżeli mają robić rzeczy szybko, po łebkach, kleić jakieś tam problemy na zapałki i wiecznie nie ma tego czasu, żeby wreszcie posprzątać, żeby wreszcie się zaopiekować jakimiś takimi obszarami, które mogą lada moment wybuchnąć, no to ta frustracja rośnie. W pewnym momencie już się przeradza w takie oczekiwania, aż to wszystko się zawali. No i wtedy zwykle jest za późno i często wtedy słyszę coś takiego, że – A nie mówiłem? Mówiliśmy, że tak będzie. Jest awaria, system leży, trzeba było i tu cała lista rzeczy, które trzeba było zrobić, a które nie zostały zrealizowane.

Kuba: Dobra, to zdefiniowaliśmy sobie, czym jest utrzymanie i też trochę opowiedzieliśmy, jakie są zagrożenia, jeśli to utrzymanie nie będzie zaopiekowane. W zasadniczej części, do której części teraz przechodzimy opowiemy trochę z Jackiem na temat praktyk, które przychodzą nam do głowy, które pomogą właśnie zaopiekować, trochę ucywilizować, trochę uporządkować temat utrzymania. Pomogą też uniknąć tych zagrożeń, która pokrótce wymieniliśmy. Pierwsza praktyka, która nam przychodzi do głowy to jest umieszczanie tego utrzymania w tym samym miejscu, w którym umieszczone są, czy zebrane są zmiany biznesowe. Mamy tu na myśli Backlog Produktu, jeśli pracujemy w Scrumie. Mamy tu na myśli tę samą tablicę kanbanową, jeśli nasza praca przechodzi przez tablicę kanbanową. A nawet, jeśli nie stosujemy żadnej z praktyk, czy metod, to po prostu pewnie jest gdzieś jakieś miejsce, w którym zmiany i zlecenie i zadania, które mamy do zrobienia są zbierane. Mocno rekomendujemy, żeby praktyką jednak było to, że na jednym miejscu, na jednej liście, na jakimś wspólnym inwentarzu mamy wszystko to, co jest do zrobienia i rzeczy utrzymaniowe również tam mają prawo bytu. Mają swoje miejsce, są widoczne. Powodów ku temu jest wiele. Możemy też trochę o tym podywagować. Ale tak jakby, dlaczego w ogóle coś takiego rekomendujemy? Przede wszystkim właśnie po to, żeby to utrzymanie w ogóle uwidocznić. Pokazać, że ono jest. Pokazać, że często jest ono całkiem niemałe. Żeby osoby, które przyglądają się pracy zespołu, sam zespół, ale też właśnie też jakiś Product Owner, być może Interesariusze pracy zespołu, wszyscy widzieli, że tej pracy jest dużo, jaka ona jest. Też taka wspólna lista pozwala na wspólne priorytety. Pozwala pokazać, że te rzeczy biznesowe, że te rzeczy bardziej projektowe, bardziej rozwojowe, no one też muszą być jakoś zrównoważone tymi rzeczami utrzymaniowymi. Te rzeczy utrzymaniowe to nie jest jakaś szara strefa, jakaś tajna lista. Jakieś rzeczy traktowane po macoszemu.

Jacek: Drugą konkretną praktyką, którą chcieliśmy się jest praktyka, w której przeznaczamy sobie na etapie jakieś formy planowania. bufor na to, że tego rodzaju zadania się pojawią. Tutaj można w różny sposób podejść do przygotowywania tego bufora. Z jednej strony, jeżeli Twój zespół nie ma takiego buforu, no to rekomendowali byśmy zacząć z jakimś buforem takim nadanym z góry. Na zasadzie procentowym na przykład. Czy wydzielić jakiś konkretny dzień z czasu kiedy zespół pracuje na to, żeby się tego rodzaju zadaniami zająć. To może być taki fajny punkt, od którego można zacząć, a następnie w procesie analizowania, czy ten bufor był wykorzystany. Czy go wystarczyło, czy było za dużo, czy za mało. Można podejść do określenia wielkości tego bufora już bardziej na podstawie naszych doświadczeń. Na podstawie danych historycznych, wiedząc, że na przykład średnio 30% naszego czasu pracy to są rzeczy utrzymaniowe. Oboje z Kubą jesteśmy dużymi fanami tego, żeby w jak największym stopniu podejmować decyzje w sposób empiryczny. Tak więc to sięganie wstecz i przygotowywanie bufora na taki wymiar faktycznie realnie zaspokajające nasze potrzeby, no to jest zdecydowanie kierunek, który chcielibyśmy zarekomendować.

Kuba: Tak jak Jacek powiedziałeś o tym momencie planowania, to ten bufor może być czymś o czym myślimy na początku na przykład Sprintu czy Iteracji. To też jest jakaś taka perspektywa, którą warto mieć z tyłu głowy i trochę propagować, jeśli planujemy pracę jednak projektów, czy portfeli projektów, że często ta praca utrzymaniowa może być czasami przeoczona na takim etapie. W pewnym sensie zespół jest albo skazany na to, żeby te pracę utrzymaniową bardzo mocno zminimalizować do absolutnie niezbędnych elementów, bo inaczej się nie wyrabiamy z projektami, na jakieś tam obiecane daty, albo w obiecanym zakresie. Albo jest bardzo duży niepokój po stronie biznesowej to były na przykład trzy miesiące, no ale nie uwzględniliśmy tego bufora, na przykład 25% pracy utrzymaniowej. Więc siłą rzeczy ten projekt nie będzie trwał trzy miesiące, tylko prawie cztery miesiące. Czyli ta różnica między wyceną, pracochłoności a wyceną czasochłonności będzie dosyć widoczna. I od razu rodzi się jakieś takie niepotrzebne, głupie dyskusję – tak to nazwę, że praca trwa za długo. Ona nie trwa za długo, tylko pierwotnie była wyceniona na za krótki czas. W ogóle nie uwzględniała tego,  że mamy też pod opieką żywy organizm, jakim jest ten produkt – już funkcjonujący u Klienta.

Jacek: No i w sumie jak o tym teraz opowiadasz to samo, to jak nazwaliśmy – bufor na utrzymanie, wskazuje na to, że to jest coś takiego nie naszego. Jakieś ciało obce, które skądś tam do nas przychodzi. Legendy mówią, że Jira tworzy te zadania, natomiast jakby zaakceptowanie tego, że ten rodzaj pracy się pojawi, powoduje, że zaczynamy z mojej perspektywy kompleksowo patrzeć na rozwój produktu, gdzie utrzymanie jego jest po prostu jego częścią, a nie jakimś niechcianym dzieckiem, czy czymś, co robimy za karę.

Kuba: Następną praktyką, którą chcemy wspomnieć, to jest w zasadzie para praktyk. Ja je wymienię obie na raz.Jedna praktyka to jest to, że zespół utrzymuje swój obszar produktowy, a druga praktyka, że ta odpowiedzialność za utrzymanie tego obszaru jest wspólną odpowiedzialnością całego zespołu. Dlaczego taka para i po kolei, dlaczego je chcemy wymieniać. Przede wszystkim zespół utrzymuje swój obszar produktowy, to w domyśle też oznacza, że być może mamy jakąś, jeśli mamy więcej zespołów to być może mamy jakiś podział produktowy również w ramach odpowiedzialności, w ramach pomiędzy zespołami. Przede wszystkim chodzi o to, żeby nie tworzyć takiego jakiegoś rozwiązania, w którym zespół najpierw wytwarza projekty, a później jest gdzieś obok, albo osoba, albo jakiś dodatkowy zespół z boku, który zajmuje się utrzymaniem. No i to utrzymanie z jednej strony niby jest zaopiekowane, ale z drugiej strony za mocno jest separowana odpowiedzialność. Są ci ludzie od tej fajnej roboty i tego postępu biznesowego oraz Ci ludzie, których w sumie nie widzimy na oczy, którzy gdzieś tam sprawiają, że to w ogóle istnieje. No i tutaj z Jackiem mówimy na takie osoby – tacy cisi bohaterowie. Znamy parę imion lub ksywek z naszej wspólnej przeszłości. Ludzi, którzy robili świetną robotę i praktycznie nikt ich nie widział na oczy, właśnie co najwyżej może management IT doceniał. Bo to, że funkcjonowały te produkty, które rozwijało wiele innych zespołów zależne było raptem od kilku osób, które były dla nas takim antywzorcu osoby lub zespołów utrzymaniowych. Nie rekomendujemy tego wzorca. Raczej zachęcamy do tego, żeby szukać rozwiązań na to, żebyśmy odpowiadali całościowo za produkt. Tak jak chyba bezdyskusyjną praktyką jest, że zespół end to end odpowiada całościowo za rozwój, czyli ma wszystkie kompetencje do tego, żeby ten produkt rozwijać. To my zachęcamy również do tego, żeby miał też odpowiedzialność za utrzymanie, co rodzi szereg konkretnych konsekwencji, ale też uczy zespołu pewnych nawyków i uczy też po prostu pewnej odpowiedzialności za jakość swojej pracy.

Jacek: I tą wspólną odpowiedzialność w zespole można ograć na różne sposoby. To co my byśmy chcieli dzisiaj zarekomendować, to taką praktykę, w której ta odpowiedzialność jest przechodnia;. Bardzo często ona się pojawia pod angielską nazwą „Round Robin”. Jakby różnie można tę praktykę zaimplementować. Przykładowo możemy sobie ustalić taką rotacyjną odpowiedzialność za zadania utrzymaniowe dla konkretnej osoby, czy grupy osób, per konkretną iterację. Tu oczywiście w zależności od tego jak długa jest nasza iteracja to ten okres czasu może wynosić w praktyce pewnie najczęściej od tygodnia do dwóch tygodni. To może być też umowa, że niezależnie od długości naszej iteracji umawiamy się na przykład na tydzień, czyli od poniedziałku do piątku. To może zejść do poziomu konkretnego dnia, czyli osoba lub grupa osób jest odpowiedzialna za wszelkiego rodzaju zadania utrzymaniowe per konkretny dzień. Tego konkretnego dnia skupia się na tych zadaniach, następnego dnia następuje zmiana. No i te osoby, które już nie robią utrzymania wracają do tej pracy, nazwijmy takiej biznesowej. Natomiast na ich miejsce wchodzą kolejne osoby.

Kuba: Ja uwypuklę powody, dla których taka praktyka jest przez nas rekomendowana. Bo tak jak Jacek powiedział, są osoby, które realizują zadania biznesowe i są osoby, które realizują zadania utrzymaniowe. Tutaj wychodzimy naprzeciw temu zagrożeniu, że ta praca jest nieprzewidywalna, że ona rozwala nasze plany, że być może jest w jakimś tam stopniu frustrująca, bo niektóre z tych zadań potrafią być dosyć pochłaniające. Wewnątrz zespołu tą odpowiedzialność wewnątrz zespołu realizujemy sobie w ten sposób, że po prostu wyznaczamy jedną osobę, która jest bardzo mocno skupiona na pracy tej utrzymaniowej. Jest na nią gotowa, być może tak trochę poświęca się dla reszty zespołu. No, ale w efekcie reszta zespołu może się bardzo skupić. O ile nie wydarzy się coś naprawdę kryzysowego, czy krytycznego, może zakładać i planować, że faktycznie będziemy mogli poświęcić się tej pracy projektowej i to tylko ją przewidywać w naszej pojemności dnia pracy. Przewidywać ją w kolejnych dniach planu, który sobie tam jako zespół budujemy. Czyli jest to pewna praktyka, która tak troszkę jest niekorzystna dla tej osoby, która no trochę zostanie takim – właśnie ja to czasem słyszę, że się nazywa dyżurnym. Ten dyżurny tak trochę w imieniu całego zespołu się poświęca, ale jest też właśnie też ten aspekt roli przechodniej, czyli raz na jakiś czas każdy z nas musi być dyżurnym i poleci do łazienki namoczyć gąbkę i znaleźć kredę, to w szkole takie, rzeczy były robione. Natomiast potem mogę się skupić na tej pracy projektowej.

Jacek: Swoją drogą, jest spora kreatywność w zespołach, jeśli chodzi o wymyślanie nazw na tą osobę. Słyszałem i „heroesów” – to osoby, które walczą z maintenance’m. Słyszałem też jakąś wariację „turbodymomena”. Jako takie właśnie zwykle takie okolice super powery super bohaterów. No, ale faktycznie pewne rzeczy noszą takie znamiona. Kolejna praktyka, którą chcieliśmy się podzielić, to jest praktyka, w której zachęcamy do nie tylko wykonywania pracy utrzymaniowej, ale także zastanowienia się nad tym w ogóle o jakim typie pracy mówimy. Tę poradę skróciłbym do porady – analizuj typy zadań utrzymaniowych. Powodów jest sporo, dlaczego warto się nad tym pochylić. Po pierwsze warto się zastanowić, czy aby na pewno to zadanie, które realizujemy to jest zadanie utrzymaniowe. Czy czasem nie jest tak, że jakieś zadanie typowo biznesowe jest przemycane do naszej listy zadań jako zadanie utrzymaniowe. No po to, wprost mówiąc, żeby zostało zrealizowane. Natomiast ono być może powinno być realizowane zupełnie inną ścieżką i podlegać zupełnie innej ocenie. Na pewno taka analiza też pomaga, jeśli chodzi o dostrzeżenie w ogóle jakiego typu zadań mamy najwięcej. W ogóle co to jest to nasze utrzymanie. Czy to są błędy? W jakim stopniu? Czy to są jakieś zadania związane z drobnymi pracami, takimi usprawniającymi? Czy to najczęściej jest problem związany w ogóle z całą naszą platformą? Tutaj również dobrze jest mieć jasność. Jak najwięcej danych, żeby zespół był w stanie podejmować lepsze decyzje. No, a przede wszystkim też chcielibyśmy wiedzieć w ogóle na jaki typ obsługi my się umawiamy w kontekście tych poszczególnych zadań. Czy one muszą być realizowane od razu? Czy te zadania mogą poczekać? W ogóle jakie mamy typy? Jak do nich podchodzimy? Tak więc cały ten taki sposób obsługi tych zadań w zespole.

Kuba: I rozszerzając, to co Jacek powiedziałeś. Raz, że takie analizowanie tych zadań maintenance’owych może też nam przynieść jakieś takie argumenty, że na przykład jakiś kawałek systemu ciągle generuje jakieś zadania i być może możemy wymyślić jakieś rozwiązanie. Może jakiś refaktoring, albo poważne zajęcie się tematem, żeby tych zadań utrzymaniowych aż tyle nie było. Ale o tym jeszcze będziemy mówili w kolejnej poradzie. Natomiast bardziej chciałem poszerzyć ten wątek obsługi. Zadania utrzymaniowe często mają ten charakter, na przykład błędów, awarii, jakichś takich rzeczy, które nie za bardzo mogą czekać. I tutaj naprawdę przyda się, żebyśmy mieli algorytmy postępowania. Jakieś takie, może nazwijmy je procedury, ale w takim zdrowym rozumieniu tego, że jeśli trafia się jakaś sytuacja, to w bardzo szybkim czasie rozpoznajemy gdzie jesteśmy, aplikujemy pewną ścieżkę postępowania i ją stosujemy bez wielkiego zastanawiania się, szukania. Zwłaszcza jeśli mówimy tutaj o błędach lub awariach, to każda sekunda i każda minuta zmarnowana na jakieś tam szukanie, potwierdzanie, pytanie się kogoś czy możemy. To jest minuta zmarnowana. I jeszcze jedna myśl w ramach tego zadania, to to, że takie typy utrzymania, procedury utrzymania, mogą się Wam mocno kojarzyć z takim zadaniem bardzo korporacyjnym, że na wszystko mamy procedurę, mamy jakieś takie rozpisane procesy. Ja bardzo mocno szedłbym w ten schemat, żeby te rzeczy były bardzo ludzkie, bardzo zrozumiałe. I najlepiej oddolnie, żeby zespół lub zespoły, jeśli mówimy o jakiejś grupie zespołów, żeby sobie te zasady tworzyły. Żebyśmy sami je stworzyli. Sami je uzupełniali, sami je rozszerzali. No bo sami też je będziemy stosować. I tutaj nie raz już spotkałem w tym świecie korporacyjnym z procedurami, na przykład obsługi błędów, czy raportowania jakichś rzeczy, który osobny czas jest potrzebny, żeby w ogóle zrozumieć te definicje i te sposoby postępowania. I w praktyce nikt ich nie stosuje, bo jak jest gorąco, to niestety, ale nie mam głowy do tego, żeby teraz się jeszcze zastanawiać czy ja coś mogę, czy nie mogę i co to znaczy średniej wielkości błąd, albo co to znaczy awaria krytyczna. Po prostu działam, a potem się zastanawiam. I tutaj jest taka przestroga, żeby nam te typy, żeby nam te procedury czasami się nam nie wyrwały spod kontroli. Były takie bardzo nieludzkie.

Jacek: I te rzeczy, o których powiedzieliśmy, tak, żeby to wszystko było takie jasne dla zespołu, żeby ta ścieżka postępowania była, no właściwie taka domyślna, jasna dla wszystkich, to mocno nam się kojarzy z konkretną praktyką kanbanu, która brzmi: Uczyń zasady jasnymi. Tutaj byśmy chcieli zarekomendować Słuchaczom posłuchanie podcastu Kanban przy kawie, który prowadzi Radek Orszewski. Szczerze polecamy konkretny odcinek, który Radek nagrał na ten temat. Link do tego odcinka znajdziecie w notatkach do podcastu. Taką ciekawą informacją, która wypłynęła z ankiety, którą ostatnio przeprowadziliśmy jest to, że 29% spośród osób, które słuchają podcastu Porządny Agile, słuchają również podcastu Kanban przy kawie. Pozdrawiamy i rekomendujemy.

Kuba: Odcinek szósty. Znajdźcie go w swojej aplikacji do podcastu lub tak jak Jacek wspomniał, wejdzcie na stronę i tam cały odcinek jest podlinkowany. Nie za bardzo możemy podać krótki link, bo Radek akurat takich nie ma. Ale Radka bardzo pozdrawiamy. I ostatnia praktyka, którą byśmy chcieli wymienić, to jest temat, który już troszkę już zaznaczyłem przy tym analizowaniu typów utrzymania, to też konieczność czy analiza przyczyn źródłowych utrzymania. Pojawiania się tego utrzymania. Są takie zadania utrzymaniowe, które no są tak naprawdę naprawianiem pewnego symptomu, pewnej wierzchniej warstwy jakiegoś większego problemu. I fajnie oprócz takiego fixa, czyli szybkiego rozwiązania tego, że problem już nie występuje. Błąd już się nie pojawia, żeby się zastanowić całym zespołem – co zrobić, żeby tego utrzymania nam się, żeby ono nam się nie pojawiało w przyszłości. Żeby ono się nie nawarstwiało. Być może, żeby zupełnie do zera wyeliminować przyczyny źródłowe. No i tutaj to jest chyba dla mnie najmocniejszy przypadek, dlaczego to ten sam zespół, który tworzy pewne rozwiązania powinien również odpowiadać za jego utrzymanie. Bo to jest takie bardzo mocne. Czasami bolesne. Dopięcie pętli informacji zwrotnej, że nasze rozwiązania miały jakieś błędy, jakieś wady. Nasze rozwiązania nie przewidziały wszystkich możliwych scenariuszy. I też może również na takiej warstwie inżynierskiej, ten, co tworzył rozwiązanie jak już zacznie zbierać też owoce, również te kwaśne, swoich fragmentów pracy, będzie również trochę lepiej wiedział jak ten problem rozwiązać. Czyli nie skazujemy jakichś innych ludzi, żeby to utrzymanie robili. Ani też nie liczymy, że ktoś inny za nas tę analizę zrobi, tylko autentycznie weźmy chwilę oddechu po tym jak problem zostanie rozwiązany i zastanówmy się z czego wynika, że ten problem w ogóle się pojawił? Jak my jako zespół możemy pracować lepiej nad innymi rzeczami, ale też jakie zmiany w systemie są potrzebne, żebyśmy ten problem rozwiązali. Może masz tutaj Jacek jakiś przykład, który chciałbyś wspomnieć, żeby też lepiej zobrazować o co nam chodzi.

Jacek: No co najmniej dwa przychodzą mi do głowy. Pierwszy to taki, że bardzo często zdarza się, że pewne błędy – na przykład jakaś taka niespójność danych, które otrzymujemy od Klienta, w szczególności, jeśli to są dane finansowe się pojawia w produkcie, bardzo często można te błędy w nieskończoność poprawiać ręcznie. A de facto przyczyną źródłową jest jakiś konkretny błąd w algorytmie, który traktuje te dane inaczej niż biznesowo byśmy się tego spodziewali. Innym przykładem może być permanentnie kończące się miejsce na dyskach, na serwerach, co bywa zaskoczeniem, że znów się skończyło miejsce na dysku. No i tutaj też istnieje szereg sposobów, żeby albo otrzymać na wczesnym etapie sygnał, że takie miejsce się kończy, albo wprowadzić jakąś formę monitorowania, czy to w zespole. W dużych firmach bardzo często są dedykowane działy, które monitorują pracę całego systemu. Tak więc tutaj byśmy chcieli mocno zachęcić do tego, żeby znaleźć czas, żeby pochylić się nad przyczynami źródłowymi utrzymania. W szczególności, jeśli są to takie rzeczy, które można wyeliminować, jeśli tylko znajdziemy czas na to, żeby systemowo pewne konkretne problemy rozwiązać.

Kuba: Ok. To na podsumowanie tego odcinka, który dziś nam wyszedł trochę krótszy niż zwykle, wymienię te praktyki, które przedstawiliśmy w ramach zarządzania utrzymaniem w podejściu zwinnym. Pierwsza praktyka to umieszczanie utrzymania tam, gdzie umieszczamy również wszystkie zmiany biznesowe. Zaplanowanie buforu na utrzymanie. Poświęcenie czasu na utrzymanie swojego własnego obszaru produktowego przez ten sam zespół, który go ten obszar produktowy również rozwija. Wewnątrz zespołu, wspólna odpowiedzialność za utrzymanie, ale również realizowana poprzez jakąś formę przez tak zwanego „dyżurnego” oraz takie refleksyjne punkty, czy praktyki. Posiadajmy typy utrzymania, posiadajmy zasady postępowania z tym utrzymaniem i miejmy te zasady bardzo jasne oraz analizujmy przyczyny źródłowe powstawania jakichś zadań utrzymaniowych i zastanawiajmy się, jak możemy nasz system poprawić oraz nasz proces poprawić, żeby tego utrzymania nie było tyle lub nie było, powiedzmy, tak niekorzystne dla całości naszych prac.

Jacek: Kończąc odcinek chciałbym zaprosić Cię na warsztaty stacjonarne o nazwie Labirynty Scruma, które będę prowadził w Warszawie 24 i 25 września. Będzie to okazja, żeby bardzo głęboko zanurzyć się w najczęstsze problemy, które można spotkać w pracy scrumowej i wypracować rozwiązania, które pozwolą tych problemów unikać w przyszłości. Zostało dosłownie kilka miejsc. Więcej informacji na temat tych warsztatów znajdziesz na stronie warsztaty.labiryntyscruma.pl.

Kuba: Kończąc ten odcinek przypominam, że notatki do tego odcinka z linkami do wszystkich materiałów, które wspomnieliśmy, więc zarówno warsztaty Jacka, podcast Radka i wszystkie inne materiały, które też mogą się przydać jak wideo, jak linki społecznościowych mediów, wszystkie one są zawarte na stronie porzadnyagile.pl/43 czyli numer tego odcinka.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.