Dlaczego nie estymujemy błędów?

Nie zawsze trzeba wyceniać błędy. Należymy do tej grupy zwinnych praktyków, która ich nie wycenia. Poznaj nasze argumenty, które nas do tego przekonały. Dowiesz się też jak poradzić sobie z błędami w zespole bez ich wyceniania. Dodatkowo wymieniamy nasze kontrargumenty na najczęstsze powody wyceniania błędów.

Czy błędy powinniśmy błędy wyceniać, aby pracować zwinne? Jeśli nie – dlaczego nie estymujemy błędów i jak wtedy poradzić sobie z tematem planowania pracy?

Pytanie to pojawiło się ostatnio kilkukrotnie podczas naszej pracy i sesji mentoringowych, które prowadzimy. Dla nas temat zawsze był jednoznaczny, ale okazało się, że są różne spojrzenia na kwestię estymowania błędów. Dlatego postanowiliśmy przyjrzeć się przeciwnemu stanowiskowi do naszego, czyli do wyceniania błędów. 

Na początek chcieliśmy zaznaczyć, że:

• mówimy tu o błędach, które trafiają z szeroko rozumianych środowisk produkcyjnych do zespołu, a nie o błędach wykrywanych przez sam zespół w trakcie pracy, 
• estymowanie w tym artykule oznacza jakąkolwiek próbę oszacowania błędu przed jego naprawieniem. Może to być oszacowanie pracy w Story pointach, w konkretnych jednostkach czasu, ale co ważne: bez próby faktycznego rozwiązania.

Jednocześnie pamiętaj, że to, o czym tu piszemy to wyłącznie nasza perspektywa i do niczego nie chcemy Cię przekonywać. Dzielimy się tylko naszym punktem widzenia i chętnie poznamy Twoje spojrzenie na temat estymowania błędów.

Dlaczego my nie estymujemy błędów?

Zacznijmy od argumentów za tym, dlaczego naszym zdaniem nie warto wyceniać błędów.

1. Błędy mają bardzo różny rozkład czasu realizacji – jedne z nich będą oczywiste już “na pierwszy rzut oka”, jak np. widzimy w logach, że skończyło się miejsce na dysku. Inne z kolei będą dla wykonawcy zagadką i nie da się poznać ich przyczyny bez głębokiej diagnozy i próby rozwiązania. Ta charakterystyka jest odmienna od typowych elementów Backlogu Produktu, gdzie zwykle na podstawie kryteriów akceptacji i opisu da się mniej więcej określić, co konkretnie chcemy zrobić. W przypadku błędów wiemy jedynie, że chcemy coś naprawić, ale nie mamy jasnej odpowiedzi, ile czasu nam to zajmie.
2. Szacowanie relatywne (czyli storypointy) to jednostka w skali porównywania elementu do elementu – nie ma możliwości porównania błędu, który jest nieznany, ponieważ nie ma sposobu odniesienia dzięki któremu możemy oszacować wielkość tego błędu i czasu, jaki nam zajmie jego naprawienie (na podstawie wiedzy, którą mamy z wcześniejszych podobnych sytuacji). Wiedzę zdobywamy dopiero w trakcie pracy, rozwiązywania danego problemu. Ale wówczas proces estymacji jest już niepotrzebny.
3. Czas rozwiązania błędu ma wyraźną różnicę pracochłonności zależną od wykonawcy oryginalnego kodu – w idealnym świecie, każdy członek zespołu deweloperskiego powinien mieć kompetencje umożliwiające naprawienie takiego błędu. Jednakże w rzeczywistości zwykle jest tak, że mamy ekspertów z wąskich obszarów (technologicznych i komponentowych). Stąd też uniwersalne wspólne oszacowanie może być trudne, jeśli konkretnej kompetencji, a czasem nawet twórcy danego kodu, zabraknie.
4. Uwzględnianie w wycenach błędów może powodować złudne wrażenie, że zespoły dużo dostarczają – porównując to do fabryki aut: jeśli jednego dnia z linii produkcyjnej zjedzie 100 aut idealnych jakościowo i 100 kolejnych aut wymagających poprawek, a potem następnego dnia (oprócz wyprodukowania 100 nowych aut), załoga fabryki naprawi te 100 aut z poprzedniego, to czy może powiedzieć, że firma wyprodukowała przez dwa dni 300 czy 400 aut? Jeśli w zespole mierzymy Velocity, ta miara zacznie zakłamywać obraz o dostarczonej ilości elementów wartościowych, ponieważ w takiej sytuacji wliczanie poprawionych błędów tworzy złudne wrażenie, że zespoły dużo dostarczają.
5. Velocity przestaje być wiarygodną podstawą do prognoz – miara ta nie pokazuje nam już tylko, jak dostarczamy jako zespół, traci swoje znaczenie jako podstawa do prognoz dostarczania w przyszłości. Velocity zaczyna pokazywać nam po prostu, ile pracy zespół realizuje, z tym że nie tylko nowych funkcjonalności, ale i eliminowania błędów z tych dostarczonych poprzednio.

Argumenty zwolenników estymacji błędów

Po przedstawieniu Ci naszych argumentów za tym, dlaczego nie estymujemy błędów, odniesiemy się teraz do argumentów zwolenników wyceniania błędów i podamy nasze kontrargumenty.

Co najczęściej słyszymy od osób i zespołów, które chcą wyceniać błędy?

• “Dzięki oszacowaniu wiemy ile pracy mamy do zrobienia w tym błędzie” –  zespół mając przekonanie, że wie, ile jest pracy do zrobienia w danym błędzie, może nie widzieć przeszkód przed jego estymacją. Jednak tak jak już wspominaliśmy wcześniej, trudno jest rzetelnie wycenić błędy z wielu powodów, wymienionych powyżej.
• “Pomaga nam w planowaniu i uwzględnieniu właściwej ilości błędów do Sprintu” – naszym zdaniem tworzymy sobie tutaj iluzję kontroli nad sytuacją. Tak naprawdę nie tylko mamy pozornie wycenione błędy, ale dodatkowo na tej bazie planujemy kolejny Sprint i pracę całego zespołu. To może pociągać za sobą lawinę dalszych konsekwencji i problemów – m.in. opóźnienia powstania Przyrostów i zaniedbanie jakości.
• “Wiemy jaki procent Story points per sprint idzie na bugi” – ze względu na to, że estymaty przypisywane do błędów mają tendencję do większego rozrzutu i są często mniej trafne, to wnioskowanie na tej bazie naszej przepustowości, jaką możemy przeznaczyć na błędy, będzie nierzetelne.
• “Jak nie będzie widać tych Story pointów, to raporty wykażą, że prawie nic nie robimy” – jest to częsty argument w zespołach, które utrzymują dojrzałe produkty. Ponieważ produkt nie wymaga dodawania nowych funkcjonalności i zespół większość czasu poświęca na rozwiązywanie starych błędów, to w raportach dla managementu czy interesariuszy chcą (lub oczekuję się od nich by) w jakiś sposób wykazać obciążenie swoją pracą i wykorzystują do tego Velocity uwzględniające różne dodatkowe aktywności, w tym usuwanie błędów. Naszym zdaniem jest to jednak budowanie fałszywego poczucia produktywności. 
• “Scrum Guide tak każe” – staramy się nie odwoływać zbyt często do Przewodnika po Scrumie, jednak tym razem zrobimy wyjątek. Przede wszystkim nie ma w nim nic o błędach. Scrum Guide wspomina o Product Backlog Items, czyli o elementach Backlogu Produktu, które są przygotowywane w procesie Refinementu Backlogu. Jak podaje sam Scrum Guide, “Refinement to ciągły proces, którego celem jest dodawanie szczegółów takich jak: opis, kolejność czy rozmiar. Właściwości te często są różne w zależności od specyfiki pracy”. Stwierdzenie “takie jak” wskazuje na katalog otwarty (czyli PBI może, ale nie musi zawierać wspomniane opisy, kolejności i rozmiar), z kolei drugie zdanie daje możliwość doboru właściwości elementów w zależności od specyfiki. Naszym zdaniem charakterystyka błędów jest właśnie taką specyfiką – sprawia, że przyznawanie im rozmiaru jest mało celowe. 
• “Mój trener zwinności/Scruma tak mi powiedział” – tu proponujemy być ostrożni przy przyjmowaniu tak zdecydowanych i mocnych rekomendacji od trenerów. Życie i doświadczenie pokazują nam, że praktyka, która świetnie sprawdza się w jednym zespole czy firmie, może nie być adekwatna w innych sytuacjach. Zachęcamy Cię do świadomego odkrywania nowych metod pracy poprzez praktykę i otwartość na eksperymenty. 

Jak postępować z błędami?

Przedstawimy Ci teraz kilka kierunków, jak radzimy sobie z błędami bez ich wyceniania. Potraktuj to jako inspirację, jako materiał do pogłębienia i dalszej analizy. Chcemy Ci pokazać na praktycznych przykładach z naszej pracy z zespołami, w których nie trzeba estymować błędów i radzić sobie z nimi bez oszacowań, dostarczając cele i pracując efektywnie.

Jak można radzić sobie z błędami, jeśli zdecydujemy się ich nie wyceniać?

• Rzetelne zespołowe planowanie, a nie tylko bazowanie na zajętości czy dostępności zespołu. Innymi słowy, nie podchodźmy do planowania, jak do działania, w którym zapełniamy pojemność sumując wszystkie szacunki pracy lub poprzypisujemy sobie tylko zadania, bez przemyślenia, co jest tak naprawdę do wykonania i jak układamy to w Zespole w Sprincie. To podejście jest dla nas uniwersalną poradą dla Planowania Sprintu, więc rekomendujemy je również, jeśli chodzi o rozwiązywanie błędów.
• Ujmowanie capacity zespołu na rozwiązywanie błędów w postaci jednostek czasu czy dostępności osób. Pamiętajmy o tym, że nasze capacity jest mniejsze niż suma godzin, jaką mamy w ogóle dostępną do pracy. Oczywiście uwzględniamy też urlopy, L4 i szkolenia itp. To capacity możemy oszacować na bazie danych historycznych i w przypadku błędów oznacza to odjęcie od przepustowości zespołu odpowiedniej części czasu (np. procentu, konkretnej liczby dni, godzin czy wyjęcie całej osoby na dany Sprint).
• Założenie konkretnego timeboxu (w godzinach czy dniach) na diagnozę lub rozwiązanie błędu, a jeśli zostanie on przekroczony, to podjęcie z góry zaplanowanego odpowiedniego działania, jak np. poproszenie o wsparcie kogoś z zespołu.
• Adaptowanie planu iteracji co najmniej raz dziennie, np. na codziennym Scrumie lub standupie. Pozwoli to lepiej oszacować przepustowość całego zespołu i przeplanować inne zadania, jeśli praca nad rozwiązaniem błędu się przeciąga lub pojawiły się kolejne defekty, które wymagają reakcji zespołu i wpływają na pierwotne plany.
• Śledzenie czasu poświęconego na błędy per Sprint – zamiast budowania statystyki na StoryPointach, bardziej rzetelne będzie zliczanie czasu, jaki zespół faktycznie poświęca. Czas ten będziemy mogli potem uwzględniać podczas analizowania naszego capacity. Możemy też wykorzystać tę informację, jeśli rzetelnie monitorujemy całym zespołem, nad jakimi aktywnościami spędzamy ile czasu.
• Liczenie średniej ilości błędów per Sprint – być może to będzie dla Twojego zespołu wystarczająco dobrą, a do tego szybką do policzenia, statystyką związaną z problemem jakości produktu. Sprawdzamy ile mamy otwartych błędów i ile średnio udaje nam się zamykać w trakcie jednego SprintuTo oczywiście będzie duże przybliżenie, ale taka miara jest szybka i tania w uzyskaniu, a w odpowiednio dużej puli błędów i okresie, na który patrzymy, może się okazać, że wielkość błędów i rozkład wielkości tychże się uśredniają.
• Rzetelne uwidocznienie tematu jakości w zespole. Mamy na myśli ujęcie szersze niż procent Story pointów na błędach czy nawet wspomniane wyżej liczenie błędów – uważamy, że może to nie być wystarczające ujęcie jakości produktu. Warto rozważyć techniki i narzędzia jak np. narzędzia do kontroli jakości kodu, trendy ważnych metryk systemowych, statystyki czasów odpowiedzi i dostępności, danych związanych z wydajnością i bezpieczeństwem.
• Wspólne rozwiązywanie błędów – zamiast marnować czas całego zespołu na Refinemencie na wycenę błędów, zespoły wspólnie zabierają się do rozwiązania błędów poprzez takie praktyki jak pair programming czy praca w grupach. Wartością dodaną będzie to, że podchodzimy do tego zespołowo i patrzymy na błąd z różnych perspektyw, co może przyspieszyć diagnozę lub faktyczne rozwiązanie.
• Przyjęcie “no bug policy”, czyli dążenie do tego, żeby nie zarządzać błędami, tylko rozwiązywać je na bieżąco (nawet jeśli spowolni to rozwój nowych funkcji). Ważne też, by długofalowo szukać przyczyn źródłowych problemów i zmniejszać przyczyny ich powstawania. 

Na koniec chcielibyśmy zaprosić Cię do eksperymentu. Jeśli estymujesz błędy, to spróbuj tego nie robić. A może nie estymujesz błędów i masz z tego powodu jakieś kłopoty? Przetestuj zatem ich wycenę, być może w Twoim przypadku to będzie lepsze podejście. Poszukuj lepszych sposobów pracy i weź swój proces wytwórczy w swoje ręce, robiąc świadome eksperymenty.

Transkrypcja podcastu „Dlaczego my nie estymujemy błędów?”

Kuba: Ten odcinek ma tytuł „Dlaczego nie estymujemy błędów?”. Ostatnio kilka razy trafiliśmy niezależnie od siebie na to pytanie, w ramach naszej pracy, w ramach naszych też sesji mentoringowych. Nam wydawało się ono na tyle oczywiste, że nasza szybka, krótka odpowiedź mogłaby zamknąć odcinek. Ale jednak jak sprawdziliśmy głębiej coś, co nas trochę przeraziło, to to, że szkoły są bardzo różne. Różne osoby mają do tematu estymowania błędów bardzo różne podejście. No i jest szkoła przeciwna do tego, w co my aktualnie wierzymy, czyli wyceniania błędów. Ma sporo argumentów, więc stwierdziliśmy, że to jest idealny temat na osobny odcinek, osobne nagranie i w tym spróbujemy potraktować temat poważnie i głęboko.

Jacek: Trzy ważne takie sprawy na początek. Po pierwsze, kiedy mówimy o błędach, mamy na myśli błędy, które trafiają z szeroko rozumianych środowisk produkcyjnych do zespołu. Czyli nie mówimy w tym odcinku o błędach, które zespół wykrywa w trakcie procesu wytwarzania. 

Kuba: Gdy mówimy o estymowaniu, mamy na myśli jakąkolwiek próbę oszacowania błędu, zanim zostanie on naprawiony. Czyli oszacowanie pracy, czy to w story pointach, czy nawet w konkretnych jednostkach czasu, jak godziny i dni. Po prostu, ocena czasu albo w jednostkach względnych, albo bezwzględnych, bez próby faktycznego rozwiązania. 

Jacek: I trzecia myśl to, o czym dzisiaj opowiemy, to wyłącznie nasza perspektywa. W szczególności nie mamy ambicji przekonywania. To po prostu jest nasz punkt widzenia. Jeśli robisz inaczej, to jest to dla nas OK.

Kuba: I co poruszymy konkretnie w odcinku? Odcinek będzie miał trzy wyraźne części. W pierwszej części podamy nasze własne argumenty za tym, żeby nie wyceniać błędów. Dlaczego tak uważamy? W drugiej części zderzymy się i pokażemy swoją perspektywę odwrotną do popularnych argumentów za tym, żeby jednak te błędy wyceniać. Czyli podamy nasze kontrargumenty. I żeby nie zostać bez jakichś konkretów, to w ostatniej części powiemy, jak sobie radzić z błędami bez ich wyceniania. Czyli jak ten zespół może praktykować pracę z błędami, bez wyceniania błędów. 

Jacek: Przypominamy, że od niedawna jest w sprzedaży nasz webinar o Dekompozycji Elementów Backlogu Produktu. Wszystkie nasze płatne projekty, jakie ten webinar znajdziesz na stronie porzadnyagile.pl/sklep. 

Kuba: Dobra, to przechodząc do pierwszego rozdziału tego odcinka. Wymienimy nasze argumenty za tym, żeby nie wyceniać. Co mamy na pierwszym miejscu?

Jacek: Pierwsza myśl jest taka, że błędy mają bardzo inny rozkład czasu realizacji. Co to oznacza? Oznacza to, że możemy trafić na błędy, które będą takie bardzo oczywiste. Czyli na przykład. Mamy wyraźny jakiś ślad w logach, że skończyło się nam miejsce na dyskach, na serwerach, i to jest jakby jeden typ błędu. W sensie, patrzymy co to za błąd. I mówimy: „Aha. Wszystko jasne”. Drugi typ błędów, z którym możemy się spotkać, to są błędy takie bardziej nieznane. Czyli wiemy, że nie działa, ale patrząc na błąd, nie jesteśmy w stanie ustalić, co jest jego przyczyną. Ta charakterystyka jest inna od takich klasycznych elementów, które chcemy realizować, gdzie mamy najczęściej jakieś kryteria akceptacji, jakiś opis, jednak dosyć precyzyjnie opisane, co konkretnie chcemy zrobić. W przypadku, kiedy mówimy o błędach, tak naprawdę wiemy, że chcemy naprawić. No ale sam rzut oka na zgłoszenie może nie dać nam jasnej odpowiedzi ile konkretnie pracy przed nami. 

Kuba: Innymi słowy błąd, tak trochę przerysowując, albo jest oczywisty i natychmiast wiem, co zrobić, albo jest zupełnie nieznany. Trochę trudno to oszacować. Drugi argument za tym, żeby nie wyceniać, to to, że szacowanie, zwłaszcza konkretnie relatywne, czyli story pointy, to jednostka porównywania elementu do elementu. I jakby nadbudowując nad tym, co przed chwilą Jacek powiedział. Błąd, który jest nieznany, taki, że no gołym okiem nie wiem, co w nim jest. Chwila siedzenia albo czytania opisu absolutnie mi nie podpowiada, co tu się mogło wydarzyć, albo powiedzmy, że daje mi tam jakiś punkt wyobrażenia, ale kompletnie z doświadczenia wiem, że nie wiem, co tam będzie. Niestety to powoduje, że nie jestem w stanie porównywać. Nie ma do czego porównywać. Tak jakby historycznie, czy w jakiejś takiej osi, skali. Tak samo jest też z szacowaniem czasu. To, że jakiś błąd zajął mi, kiedyś tam podobny 5 godzin, żeby go rozwiązać. No, to gdy przychodzi jakiś błąd nowy, który też brzmi jak coś takiego, to historyczna wiedza o tym, że kiedyś zajęło mi to 5 godzin, nic mi nie daje. Tak naprawdę, rzetelnie do sprawy podchodząc, nie wiem ile to będzie, i to naprawdę nie wiem. I to nie jest moja niefachowość. Faktyczna wiedza tu buduje się dopiero w trakcie już faktycznej pracy. Czyli jak już zacznę rozwiązywać, zaczynając pewnie od jakiegoś śledztwa, co w ogóle jest, co działa, co nie działa. Dopiero wtedy, zaczynając faktyczną pracę, jestem w stanie zbudować sobie tę wiedzę, która będę potrzebował, żeby rozwiązać. Ale jest też duża szansa, że jak już dobrze śledztwo przeprowadzę, to znalezienie rozwiązania to będzie chwila. Cały ten proces wyceniania jest mi tutaj do niczego niepotrzebny. Czyli, podsumowując tą moją część. Szacowanie relatywne, ale też szacowanie w jednostkach czasu bazuje na danych historycznych. W przypadku błędów te dane historyczne o innych błędach w przeszłości absolutnie nic nam nie mówią. 

Jacek: Kolejny argument za tym, żeby nie wyceniać błędów, jest taki, że czas rozwiązania konkretnego błędu może mieć wyraźną korelację z osobą, która napisała oryginalny kod. No i oczywiście można byłoby powiedzieć, że przecież każdy w zespole powinien mieć pecet wystarczającą, żeby ten błąd naprawić. No i co do zasady tak. Natomiast w szczególności w zespołach takich posilosowanych, w zespołach, w których mamy punktowych ekspertów z konkretnego obszaru, gdzie tylko oni mogą pewne rzeczy zaimplementować. I jednocześnie sami mogą tylko ten błąd naprawić. No to niestety jakby ta ocena, czy oszacowanie tej konkretnej osoby będzie zupełnie inne, niż oszacowanie osoby, która kompletnie nie ma pojęcia, jak działa dany obszar. Więc trudno się spodziewać, że będzie wiedziała, jak naprawić błąd z tego obszaru.

Kuba: Wymieniliśmy trzy argumenty, które nazwijmy, są z takiego poziomu specyfiki czy natury błędów. Czyli podsumowując tak krocząco, błędy mają inny rozkład czasu realizacji. Błędy bardzo trudno albo w  zasadzie niemożliwe jest porównywać relatywnie jeden do drugiego oraz błędy mają taką naturę, że pracochłonność ich jest bardzo zmienna w zależności od tego, kto dokładnie będzie to realizował. Ale jest też pula dwóch argumentów, które mamy z takiego poziomu już organizacyjnego, czy takiego poziomu monitorowania i prognozowania. I tutaj pierwszy, który ja wymienię z tej puli to to, że uwzględnianie w wycenach błędów, czyli uzyskaliśmy wycenę błędu i jeszcze w dodatku je sumujemy, co jest też taką dosyć popularną praktyką, którą często widujemy w niektórych zespołach, w niektórych firmach, to to, że takie wycenianie błędów i później ich jeszcze sobie podliczanie czy sumowanie, może powodować bardzo złudne wrażenie, że zespoły dużo dostarczają. Użyję tutaj analogii. Ona jest nie do końca zupełnie wydumana. Wyobraźmy sobie fabrykę aut, która jednego dnia wyprodukowała 100 aut perfekcyjnych, jeśli chodzi o jakość i 100 aut z usterkami, które trzeba poprawić. I drugiego dnia ta fabryka, czy ekipa pracująca w tej fabryce poprawiła te 100 zepsutych aut z poprzedniego dnia i wyprodukowała 100 kolejnych z dobrą jakością. No i teraz pytanie, czy przez te 2 dni fabryka wyprodukowała 400 aut, czy 300 aut z dobrą jakością? I analogia zupełnie z innego świata, nie zawsze w pełni przenaszalna. Zespoły, które sobie wyceniają błędy, później sobie jeszcze je naliczają do swoich wszystkich możliwych statystyk. Bardzo łatwo wpadają w tę pułapkę liczenia, liczenia po kilka razy tej samej pracy. Czyli najpierw stworzyliśmy kod czy produkt, który miał błędy, a później jeszcze sobie osobno podliczamy, naliczamy punkty za poprawienie tych samych efektów. Tutaj jakby tego nie liczyć, oczywiście podkreślmy, że velocity jest miarą tutaj out-putu. Czyli ile tych elementów wyszło z danego odcinka czasowego, czyli ile aut powstało, a nie to, czy są one wartościowe, albo ile biznesu się na nich robi. Ale wracając do głównej myśli, dużą pułapką jest to, że podsumowywanie wycen błędów daje złudne wrażenie, że zespół dużo wytwarza. 

Jacek: I ostatni argument, którym chcemy się podzielić za tym, żeby nie wyceniać, jest taki, że wycenianie błędów powoduje, że velocity, czyli nasza taka miara dostarczania elementów Backlogu Produktu, które to dostarczają wartość, trochę nam się zaczyna sypać. Na takiej zasadzie, że już nie tylko ta miara pokazuje nam, jak dostarczamy, no bo jednocześnie zaczyna nam pokazywać czas, czy jakieś tam nasze zaangażowanie w naprawianie błędów. No i przestaje być podstawą do prognoz dostarczania w przyszłości. Czyli jeżeli ktoś się spodziewa, że velocity będzie pokazywać taką faktyczną prędkość zespołu w kontekście dostarczania jakichś zmian w produkcie, no to musi wziąć pod uwagę, że estymując błędy, to nie do końca pokazuje, jak bardzo zespół jest zdolny dostarczać wartość, no tylko pokazuje, ile zespół robi. Zarówno nowych funkcjonalności, że tak uproszczę, ale również to velocity, nazwijmy to, będzie skażone też tymczasem koniecznym czy wartością, która wynika z błędów. 

14:12 Kuba: OK, to wymieniliśmy w sumie 5 argumentów za tym, żeby błędów nie wyceniać. Trzy bardziej z natury błędu i dwa takie bardziej na poziomie metryki prognozowania. Ale są też osoby, które wyceniania błędów bronią z tej perspektywy argumentów za tym, żeby jednak wyceniać. I kilka takich, z którymi się spotykamy na swojej drodze. Być może są jeszcze jakieś, o których nie słyszeliśmy, ale te po prostu do nas nie dotarły, więc ich nie wymienimy. Te, które znamy, wymienimy i się do nich spróbujemy delikatnie podnieść, pokazując światło alternatywne. To dlaczego niektórzy chcą wyceniać i co o tym sądzimy? 

Jacek: Argument, który często pada, jest taki, że wiemy ile pracy mamy do zrobienia w tym błędzie. No więc skoro wiemy, ile mamy pracy do zrobienia, to dlaczego by też tego błędu nie oszacować? Trochę o tym mówiliśmy w pierwszej części odcinka. Błędy nie sposób rzetelnie wycenić z powodów, które już wspomnieliśmy, więc argument na zasadzie, że wiemy, ile pracy będzie nam zajmowało poprawienie błędu. No niestety można powiedzieć, dziedziczy tę nierzetelność. Na takiej zasadzie, że nadal będzie to dosyć złudne i to najprawdopodobniej jeszcze bardziej złudne, niż próba estymowania rzeczy, które nie są błędami. Czyli rzeczy, które mimo wszystko są troszeczkę bardziej ogarnialne i trochę łatwiejsze do okiełznania.

Kuba: Drugi argument, który czasem spotykamy to coś w stylu, szacowanie pomaga nam w planowaniu, wzięciu właściwej ilości błędów do Sprintu, szacowania oczywiście błędów. No i tutaj jest wielka filozoficzna rzecz, którą spróbuję sprowadzić do kilku takich jednak bardziej nakłuć. Bardzo obawiam się, że tutaj osoby, które zakładają, że dzięki dobrze wycenionym błędom, co Jacek już przed chwilą już wymienił, że dziedziczy jakby błąd myślenia, tym razem. Te błędy są źle wycenione, a my jeszcze na tej bazie budujemy sobie plan pracy całego zespołu. Niestety ja nie mogę tego nazwać inaczej jak iluzja kontroli. Czyli na bardzo złych podstawach budujemy sobie przeczucie czy takie przekonanie, że mamy wszystko pod kontrolą. Wzięliśmy do Sprintu właściwą ilość. Nie cztery, nie sześć, tylko dokładnie pięć, bo tak nam powiedziały szacunki. No i niestety, to też buduje pewne konkretne dalsze reperkusje. Czyli mamy takie założenia, że tylko tyle i nie więcej błędów rozwiążemy, że te błędy, które wzięliśmy, to na pewno rozwiążemy, no bo tak szacunki mówią. Zwłaszcza w organizacjach, w których też takie rzeczy są trochę śledzone. Ja bym powiedział tak w poprzek zespołów, czy to przez management, czy to poprzez jakieś struktury skalowania. To całe konkretna lawina dalszych wniosków może się zbudować tylko na tym, że ktoś oszacował coś, co szacowane, naszym zdaniem być nie powinny. I co gorsza, tutaj jest jeszcze cały wielki ból, że po pierwsze budujemy to złudne poczucie kontroli i w dodatku marnujemy na to złudne poczucie kontroli kupę czasu. Czyli ten czas, który zespół męczy się i tam robi jakiś Planning Poker dla błędów, albo o próbach jakiegoś tam sumowania czegoś, główkowania jak to wszystko pomieścić. Tak naprawdę, ten czas mógłby być przeznaczony na rozwiązywanie tych błędów, ale do tego jeszcze trochę wrócimy. 

Jacek: Kolejny argument, z którym się spotykamy jest taki, że estymując błędy wiemy jaki procent na przykład story pointów per Sprint idzie na wagi. No i oczywiście ze względu na to, że te estymaty, które przypisujemy do błędów są nieco bardziej rozrzucone, może czasem trochę mniej trafne, no to dalsze wnioskowanie na bazie tak przygotowanych danych, będzie po prostu nierzetelne. Ale żeby nie zostawić Ciebie słuchaczu bądź słuchaczko tylko z takim poczuciem, że nie jest to idealne rozwiązanie, no to w ostatniej części nagrania zaproponujemy coś alternatywnego.

Kuba: Argument, który mocno rozumiem i czasami spotykam, to jak nie będzie widać tych story pointów, które sobie zaliczamy za błędy. Czyli jeśli błędy nie będą miały oszacowań, to raporty, być może jakiś management, być może jacyś interesariusze zobaczą, że prawie nic nie robimy, że nasza przepustowość czy nasze capacity rozumiane jako dni robocze, które mamy do dyspozycji prawie na żaden produkt dodany się nie zamieniają. Albo przecież zajmujemy się w dużym stopniu na przykład rozwiązywaniem błędów. Taka sytuacja może być szczególnie adekwatna dla produktów, które są już bardzo dojrzałe, czy dla organizacji, które utrzymują jakieś systemy, które mają swoje lata, żeby to powiedzieć bardzo dyplomatycznie. Faktycznie taka sytuacja może nie być zbyt przyjemna. Bo taki zespół, może po połowę, a nawet i więcej swojego czasu spędza tylko i wyłącznie na jakiś niewielkich pracach utrzymaniowych i na rozwiązywanie jakichś błędów, które gdzieś tam z racji na dług techniczny ciągle do tego zespołu wracają. Natomiast ja w tym miejscu będę być może nieludzki, za mało empatyczny. Na ile rozumiem, że taki argument się pojawia, potrafię zrozumieć, z czego to wynika, to mimo wszystko uważam, że zwłaszcza jeśli mówimy o metodach zwinnych, zwłaszcza jeśli konkretnie mówimy o próbie zastosowania Scruma, no to tutaj jednak nie budujmy jakichś fałszywych wyobrażeń na temat tego, jak super produktywny ten zespół jest. Nie udawajmy, że jest inaczej. Jeśli ten zespół dostarcza tych nowych rozwiązań niewiele, to niech też suche fakty dokładnie to pokazują. Jeśli zespół jest utopiony w błędach, to być może właśnie jeszcze bardziej trzeba uwidocznić to zjawisko. No, a jeśli zespół próbuje szacować błędy i nic, niewiele więcej w produkcie jest w ogóle robione, to oddzielny temat. Czy ten zespół do zastosowania Scruma i całych takich narzędzi pracy iteracyjnej? 

Jacek: Kolejny argument, który często słyszymy, zresztą nie tylko w przypadku estymowania błędów, to argument, który brzmi, „Ale przecież Scrum Guide tak każe”. I zwykle staramy się nie odwoływać się przesadnie do Scrum Guide’a, natomiast tutaj warto powiedzieć sobie o faktach. Czyli przede wszystkim jak weźmiemy sobie Scrum Gudie czy Przewodnik po Scrumie, jeśli mówimy o polskiej edycji, do ręki, no to po pierwsze nie ma tam nic o błędach. Są PBI, czyli są elementy Backlogu Produktu. Te elementy Backlogu Produktu są przygotowywane na Refinementach, czyli w procesie doskonalenia Backlogu Produktu. Czym to jest? Jest to, i tu już będę bardzo precyzyjny. Cytat: „To ciągły proces, którego celem jest dodawanie szczegółów takich jak: opis, kolejność czy rozmiar. Właściwości te często są różne w zależności od specyfiki pracy”. Koniec cytatu. 

Kuba: Chcemy cytować Scrum Guide’a i to już będzie ostatni raz kiedy cytujemy Scrum Guide’a, przynajmniej w tym nagraniu. Po to, żeby jednak bardzo precyzyjnie zinterpretować ten fragment. I co nam mówi ten fragment? Ten fragment mówi nam o tym, że element Backlogu Produktu może mieć szczegóły i to jest powiedziane przez katalog otwarty. To jest interpretacja logiczna takiego zdania, takich jak. Czyli te szczegóły, te PBI-ki się mogą składać, czy to jest opis, kolejność czy rozmiar. Taki katalog otwarty w szczególności oznacza, że Scrum Guide interpretując logicznie zdania, które są podstawową obowiązującą definicją czym jest Scrum. Scrum Guide mówi rozmiar nie należy do obowiązkowych elementów PBI-ka. Zwłaszcza to zdanie, że właściwości często są różne w zależności od specyfiki pracy. No i nasza interpretacja konsekwentnie już udowodniona przez całe to nagranie. Błędy mają taką nietypową charakterystykę czy specyfikę pracy, że przyznawanie im rozmiaru jest bezcelowe. Niewiele wnosi. Czy jest pracą, która wręcz może powodować pewne oszukiwanie się. Więc tutaj wyczytując to tylko ze Scrum Guide’a, bądźmy bardzo ostrożni na to, że w szczególności w ani jednym miejscu Scrum Guide’a nie ma mowy o tym, że są błędy, ani o tym jak dokładnie ten rozmiar ma być przyznawany. Więc w szczególności też nie występuje ani razu wzmianka o story pointach. Czy też dla równowagi godzinach czy dniach. Więc tutaj, jeśli tak interpretujemy Scrum Guide’a, albo tak interpretuje Scrum Guide’a ktoś, kto nam tę sytuację wyjaśnia, to proponuję poprosić o wierny cytat i logiczną interpretację tych zapisów, które naszym zdaniem mówi, nie trzeba wszystkich elementów oceniać co do rozmiaru, zwłaszcza tych, których specyfika niekoniecznie jest do tego adekwatna. 

Jacek: I ostatni argument, z którym się spotykamy, dlaczego mielibyśmy oszacowywać błędy brzmi „Mój trener zwinności lub mój trener Scruma tak mi powiedział”. Nasza taka krótka odpowiedź z Kubą jest taka, że „A nasz trener powiedział nam, że nie”. No i oczywiście, w sensie, nie jest to żart, ale tak faktycznie powiedział. Natomiast będziemy szli dalej. Czyli co do zasady generalnie proponujemy być ostrożnym w takim mocnym przyjmowaniu na wiarę takich dosyć zdecydowanych rekomendacji od trenerów. Oczywiście to dotyczy nie tylko błędów. Wynika to z tego, że i życie, i nasza praktyka, doświadczenie pracy z różnymi organizacjami, z różnymi zespołami w różnych branżach pokazuje nam, że to, że konkretna, wybrana praktyka czy podejście, sprawdza się w jakiejś konkretnej firmie czy zespole. Absolutnie nie oznacza, że zadziała tak samo dobrze w innych. Tym samym, raczej zachęcamy do tego, żeby tak bardzo świadomie odkrywać nowe metody pracy, lepsze metody pracy, poprzez praktykowanie oraz eksperymentowanie.

Kuba: To przechodząc do ostatniej części, jeśli, słuchaczu lub słuchaczko Cię teraz przekonaliśmy, że być może zmienić podejście, mimo tego ostatniego zastrzeżenia, że nas to też dotyczy, czyli nas, nie słuchaj sam. Samodzielnie eksperymentuj, sama eksperymentuj, ale mimo wszystko nie chcemy zostawić tego tak zupełnie zawieszonego w powietrzu. Chcemy, żeby też był taki wymiar praktyczny tego nagrania. Więc ostatnia część ma tytuł „Jak sobie radzić z błędami, jeśli zdecydujemy się ich nie wyceniać?”. Jak robią to zespoły, które obserwujemy, albo sami w nich byliśmy w swojej przeszłości? Traktuj tę listę po pierwsze jako katalog otwarty. Wracając do interpretacji logicznej. Niektóre rzeczy może nawet jednocześnie zaimplementowane to byłaby przesada. Raczej materiał do analizy, do inspiracji. Wybierz sobie coś z tego i spróbuj, albo wybierz coś jeszcze zupełnie innego. Chcemy po prostu pokazać kierunki i praktyczne przykłady, że można robić to inaczej, czyli nie wyceniać błędów i radzić sobie z tym, co jest codziennością zespołów.

Jacek: Pierwsza rzecz niezwykle istotna, rekomendujemy rzetelne, zespołowe planowanie, a nie tylko bazowanie bądź na zajętości zespołu czy na dostępności zespołu, czy na tym, że po prostu poprzypisywaliśmy sobie indywidualnie zadania. Wierzymy z Kubą i to też jakby obserwujemy w zespołach, które wspieramy, że nic nie zastąpi zespołowego planu, zespołowego przemyślenia tego, co jest do wykonania. Podobna sytuacja będzie czymś, co na pewno będziemy rekomendować, jeśli chodzi o podejście do błędów.

Kuba: Druga inspiracja, o której można pomyśleć, to ujmowanie capacity zespołu na rozwiązywanie błędów. Czyli, o ile nie jesteśmy wielkimi fanami wyceniania – co już, udowadniamy od kilkunastu minut, to nie ma problemu w tym, żeby na planowaniu rzetelnie wykonanym jak to Jacek wymienił, jednak przyjąć pewne założenie o tym, że nasze capacity jest mniejsze niż suma godzin, jakie w ogóle mamy dostępne do pracy. No oczywiście to jest cały oddzielny wątek, żeby tutaj odjąć urlopy, planowane L4 i wszystkie te historie. No ale też, żeby sobie założyć, że pozostały czas, jaki nam wyjdzie z tej wykreślanki ankietę, to nie będzie być może 100% na prace rozwojowe, bo musimy jeszcze przewidzieć jakąś swoją przepustowość na rozwiązywanie błędów. No i w tym miejscu jesteśmy fanami, żeby jednak to capacity szacować na bazie danych historycznych. Nie na bazie szacunków wycen, błędów. Jak dokładnie to zrobić?Jeszcze zaraz będzie w kolejnym punkcie. Natomiast tu sugerujemy to, żeby jednak na przykład jakiś ułamek czasu dostępności, może konkretne dni, może konkretne dedykowane osoby przeznaczyć już na etapie planowania na temat rozwiązywania błędów. 

Jacek: Kolejna inspiracja. Warto w momencie, kiedy nie mamy estymaty na błędzie założyć sobie jakiś konkretny time-box, czy to w godzinach, czy w dniach, który chcemy mieć przewidziany na, czy rozpoznanie, czy na właściwe naprawienie błędu. Jest to taki bardzo sensowny bezpiecznik. Na takiej zasadzie, że jeżeli upłynie nam time-box, czyli taka nasza, naprawdę w szybkim czasie postawiona bariera, zostanie przekroczona i nie mamy rozwiązania, no to wtedy warto podjąć jakieś konkretne działanie naprawcze. Takim bardzo prostym przykładem, który często ma sens to jest coś w stylu, jeżeli założyłam, założyłam sobie jeden dzień na rozwiązanie błędu. Minął jeden dzień, a ja nie mam rozwiązania, no w takiej sytuacji warto poprosić o pomoc. Na takiej zasadzie, żeby po prostu jakaś dodatkowa para oczu, czy jakiś dodatkowy mózg pomógł nam rozwiązać problem. Spojrzeć na świeżo. No i po prostu wykorzystać mądrość zbiorową do tego, żeby z takim błędem sobie poradzić.

Kuba: I czwarta praktyka, która może być inspiracją, nadbudowując nad tym, co Jacek powiedział przed chwilą, to to, że warto wykorzystać codzienne spotkanie. Czy to jest stand-up, czy to jest Daily Scrum, do tego, żeby adaptować sobie plan działania całego zespołu? Czyli na etapie planowania mieliśmy jakieś założenia co do błędów. Mogło się okazać, że jednak jest o wiele gorzej, czyli zrealizował się ten scenariusz, w którym błąd okazuje się być o wiele trudniejszy i pomimo wykonanych działań nadal nie znajdujemy żadnych rozwiązań. Jeśli ten błąd dodatku jest ważny, a tak najczęściej z błędami bywa, no być może trzeba przebudować to, jak całym zespołem do tematu podchodzimy. No i tutaj wycenianie tych błędów konsekwentnie, absolutnie nic nam nie da, nic nam nie pomoże. O wiele sensowniej będzie całym zespołem podejść adaptacyjne do tego, jak z tematem sobie radzimy jako cały zespół. 

Jacek: Kolejną inspiracją, która z naszej perspektywy może być interesująca jako zastępstwo dla estymowania, jest śledzenie czasu, który faktycznie poświęciliśmy na błędy per konkretny Sprint. No i oczywiście idąc na większą ilość Sprintów, to będziemy mówić tutaj o jakimś uśrednieniu. Jest to tyle fajne podejście, które warto rozważyć, z tego względu, że no jednak opiera się na faktach. Czyli nie jest taka estymata ile nam się wydaje, no tylko faktycznie w ostatnim Sprincie sumarycznie poświęciliśmy, strzelam, 25 godzin na rozwiązywanie błędów. No i teraz mając taką daną, no to pierwsze co możemy zrobić? Możemy uwzględnić ten czas podczas analizowania naszego capacity, gdzieś na etapie planowania ile chcemy w konkretnej iteracji, czy w Sprincie zrealizować. Jak również możemy sobie też monitorować proporcję czasu, jeżeli oczywiście śledzimy w jakikolwiek sposób to, na co spędzamy nasz czas, jaka ilość czasu idzie na konkretne typy aktywności. Czyli ile procentowo spędzamy nad rozwojem, ile procentowo spędzamy nad utrzymaniem, ile procentowo spędzamy na przykład nad naprawianiem błędów. 

Kuba: I śledzenie czasu pracy, to jest często w wielu organizacjach kojarzone raczej z narzędziem opresji menedżerskiej. Natomiast może się okazać, że dla naszych własnych wewnętrznych, zespołowych potrzeb jest to najcenniejsze źródło prawdy, gdzie jesteśmy. Oczywiście wtedy musimy też całkiem rzetelnie te czasy raportować, a nie na zasadzie 8 godzin zajmowałem się czymś tam i nie wnikam, jaka jest dokładna proporcja. Ale jeśli jako zespół zgodzimy się, że te czasy sobie warto śledzić, jakoś tak w miarę rzetelnie kategoryzować, to może się nagle okazać, że niedużym kosztem jesteśmy w stanie z tych danych wyciągać ważne dla nas i potrzebne informacje. Zarówno co do trendów, jak i też takie Sprint po Sprincie, czy tam iteracja po iteracji, informacji na temat tego, gdzie w ogóle jesteśmy i gdzie moglibyśmy być.

Kuba: Idąc tropem miar, mierzenia, następna inspiracja to to, że być może zamiast wyceniania błędów i śledzenia jakichś trendów do jakiejś sumy. One się gdzieś tam składają, na przykład ze story pointów czy godzin, które nam się wydaje, że są jeszcze przed nami, żeby je skończyć. Może wystarczająco dobrą miarą będzie liczenie średniej ilości błędów? Czyli przyjąć takie trochę upraszczające założenie, że błędy, zwłaszcza jeśli jest ich trochę więcej, no to one się uśrednią. Czyli będzie trochę małych, trochę średnich, trochę dużych. Summa summarum, sprowadzą się mniej więcej do podobnych rzeczy. I tak naprawdę wystarczająco dobre trendy będzie się budowało na ilościach. Czyli ile mamy otwartych błędów? Ile nam co Sprint udaje się zamykać? Ile jeszcze Sprintów? Przy tym tempie zamykania elementów potrzebne by było, żeby tę ilość błędów wyzerować. No i teraz to, żeby takie trendy śledzić, możemy to zrobić zupełnie, nie mając żadnych oszacowań czy wycen. To oczywiście będzie bardzo duże przybliżenie, ale za to przybliżenie, które jest super tanie. Na zasadzie, jak bardzo musimy, to możemy w polu wpisać 1, a jeśli nie, to po prostu policzmy ilość elementów. 

Jacek: Idąc dalej, przed nami jeszcze trzy inspiracje. Na pewno warto rozważyć szersze uwidocznienie tematów jakości w zespole niż tylko to ujęcie takie bardzo często story point’owe. Czyli ile w sumie story bugów mamy patrząc przez pryzmat story pointów? Czy jaki pryzmat story pointów idzie nam per Sprint? No są na pewno bardziej wysublimowane techniki i narzędzia, takie jak dedykowane narzędzia do kontroli jakości kodu, śledzenie trendów. Możemy sobie popatrzeć też na statystykę czasów, jak tam się te różne błędy w tym czasie rozkładają. No i możemy też patrzeć szerzej, trochę wychodząc poza takie tylko bugi, ale spojrzeć na jakość też trochę szerzej. Czyli spojrzeć na liczby związane czy z wydajnością, czy z bezpieczeństwem.

Kuba: I na koniec inspiracje, gdzie z takiego poziomu bardziej ogólnego i być może abstrakcyjnego dla wybranych osób, ale nie możemy nie zakończyć tego odcinka jednak odwołaniem się do takiego poziomu troszkę wyższego. Pierwsza inspiracja z mojej strony to marnowanie czasu. Refinement, wycenianie błędów, zwłaszcza Refinement całym zespołe, gdzie rzucamy, przerzucamy się argumentami. Wygenerowujemy sobie jakiegoś Planning Pokera, czy online’owo, czy na miejscu. To jest kupę czasu. Jakbyśmy to podsumowali, licząc w minutach czy godzinach, no to może się okazać, że w Sprincie sporo tego czasu idzie tylko i wyłącznie na to, żeby uzyskać liczbę, która jest super niedokładna. Potraktujmy ten czas, który być może organizacja dzisiaj akceptuje, zwłaszcza jeśli to organizacja też od nas tych wycen jakoś oczekuje. Czy jest jakaś taka presja, czy wytyczna, żeby tak właśnie to robić? Potraktujmy ten czas, który byśmy normalnie spędzili na Planning Pokerze, story pointów, na błędach jako nasz budżet na zespołowe rozwiązywanie błędów. Po prostu weźmy ten błąd i zaczniemy go rozwiązywać. Może się okazać, że z perspektywy wydajności i pracy całego zespołu, z perspektywy też wartości dodanej dla całej organizacji jest to mądrzejsze podejście. Być może możemy te błędy rozwiązywać w kilka osób. To też jest ciekawe podejście, czy to programowanie w parach, czy wręcz takie grupowe zmóżdżanie się nad całym rozwiązaniem. Tu będą wartości dodane z faktu, że podchodzimy do tego zespołowo. Co dwie głowy to nie jedna, co trzy to nie dwie, a jednocześnie być może podarujemy sobie żmudny, bezsensowny proces wyceniania czegoś, co nie ma sensu. 

Jacek: I ostatnia myśl, z którą chcielibyśmy Ciebie, słuchaczko bądź słuchaczu zostawić, to polityka zera błędów. Czyli dążenie do tego, żeby nie zarządzać błędami, tylko po prostu rozwiązywać je na bieżąco i dążyć też do tego, żeby systemowo zmniejszać ich przyczyny źródłowe. 

Kuba: I tu ta myśl nie zarządzać błędami jest o wiele głębsza. Jakakolwiek próba szacowania, dzielenia, planowania, kolejkowania, budowania trendów to wszystko są tak naprawdę w zawoalowany sposób idee. Te błędy to jest coś, z czym możemy żyć. Te błędy to one mogą poczekać. No i to niestety prowadzi do długich kolejek, błędów, listy błędów, które być może przez lata nie są rozwiązywane. Tutaj niestety trudno o dobry kompromis i z tego powodu inspiracją będzie podejście bezkompromisowe. Znajdujesz błąd, to go rozwiąż.

Kuba: I tak na koniec zamiast klasycznego dla nas w odcinkach podsumowania myśl, którą chcemy, żeby z Tobą została. Cały odcinek przedstawią nasze argumenty i kontrargumenty do tematu niewyceniania błędów. Ale naszą intencją jest to, żeby zaprosić do eksperymentu. Estymujesz błędy? Spróbuj tego nie robić. Nie estymujesz błędów i masz z tego powodu jakieś problemy? To spróbuj, może wyciąganie błędów akurat Tobie pomoże. Poszukuj lepszych sposobów pracy i weź swój proces wytwórczy w swoje ręce, robiąc świadome eksperymenty.

Jacek: Od parunastu dni jesteśmy już w kolejnym roku kalendarzowym. W 2023 planujemy z Kubą po dwie edycje, wiosenną i jesienną naszych autorskich warsztatów. Labirynty Scruma i Prawdziwe Przypadki Scrumowe. Jeśli chcesz rozwijać swoją wiedzę w temacie Scruma i jeszcze nie jesteś absolwentem lub absolwentką naszych warsztatów, to rozważ dołączenie do nas na wiosnę lub na jesieni.

Kuba: Przygotuj budżet albo plan szkoleniowy w swojej organizacji lub po stronie swoich finansów osobistych i sprawdź nasze propozycje dat edycji wiosennych, które już są na odpowiednich stronach. Prawdziwe przypadki znajdziesz na stronie 202procent.pl/przypadki-scrumowe, a Labirynty Scruma znajdziesz na stronie labiryntyscruma.pl/warsztaty. Powtórzę linki. 202procent.pl/przypadki-scrumowe, labiryntyscruma.pl/warsztaty.

Jacek: Notatki do tego odcinka, artykuł, transkrypcja oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/102. 

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

Jacek: Dzięki Kuba! Do usłyszenia wkrótce!