“Czy estymować bugi?” To pytanie pojawia się w różnych konfiguracjach co chwila. W naszym zespole, który liczy aktualnie (stan na lipiec 2023 ;)) 16 osób, zadało je co najmniej w różnej formie pewnie z 75% osób. Samo słowo ‘bug’ w kontekście błędu ma bardzo ciekawą historię, do przeczytania tutaj.
Odpowiedź na pytanie “Czy estymować bugi?” jest jak kot Schrödingera – jednocześnie i łatwa i trudna. Pomijając wszelkie zależności i wymagania organizacyjne, często sprzeczne ze zdrowym rozsądkiem (np. “my zawsze musimy estymować bugi”), można użyć tyleż elastycznego, co wyświechtanego “to zależy”.
No właśnie, to zależy od czego?
Zanim jednak opiszę od czego to może zależeć i jak do tego podchodzę dziś (w ramach tzw. CBT – Current Best Thinking), wyjaśnię jak podchodziłem to tego wcześniej i jak się moje podejście zmieniało. Bo zmieniło się, i to więcej niż raz.
Podejście pierwsze – wszystkie błędy estymujemy
Dawno dawno temu, w początkach mojej przygody z nauką podejścia zwinnego (w pierwszym szkoleniu od Scrum.org, PSM I brałem udział już w 2014 roku) uważałem, że błędy estymować nie tylko można, ale i trzeba. Wydaje mi się, że traktowałem to jako pewnego rodzaju ‘refinement’. Wynikało to z moich dość naiwnych jeszcze wówczas przekonań, że każdy błąd jest (lub będzie) do naprawy. Skoro tak – to można go wycenić i zastanowić się, jak wysoko w Product Backlogu powinien być. Na potwierdzenie tego nie miałem wiele, ale mimo tego przeświadczenie takie miałem silne 🙂
I w tym przeświadczeniu (głównie teoretycznym) trwałem bardzo długo. Prawdopodobnie z powodu braku wystarczających bodźców zewnętrznych powodujących refleksję, zwanych inaczej doświadczeniem 😉
W międzyczasie zacząłem częściej pracować pracy z zespołami. Zacząłem zdobywać więcej świadomości dotyczących różnych miar. Miałem okazję poznać więcej przypadków analizy błędów w formie RCA (Root Cause Analysis – metoda o której napiszę więcej w innym wpisie) i optyka zaczęła się zmieniać. Zwłaszcza jedno z prowadzonych przeze mnie RCA miało wpływ na dość gruntowaną zmianę mojego spojrzenia na estymację błędów.
Podejście drugie – żadnych błędów nie estymujemy
W ramach tego RCA okazało się, że samo diagnozowanie na środowisku Klienta może trwać nawet półtora roku 🙂 bo dany błąd może być widoczny tylko przy pewnej koniunkcji warunków. Występować np. tylko u konkretnego Klienta. W specyficznej wersji oprogramowania. A także na konkretnym typie hardware’u. Plus na określonym obszarze, lub pod konkretnym obciążeniem. Lub przy dowolnym połączeniu tych, a także innych, mniej lub bardziej losowych warunków). I bądź tu mądry i pisz wiersze.
A to tylko potencjalna charakterystyka błędu. Dodatkowo sama diagnoza to połączenie znajomości produktu, technologii, obszaru, oraz doświadczenie w troubleshootingu. A, jeszcze połączone z testerskim nosem, oraz odpowiednią hipotezą “a jeżeli (…)”. I oczywiście chęci i zdolności do współpracy np. Klienta, u którego na środowisku produkcyjnym staramy się dowiedzieć co jest przyczyną nieprawidłowego zachowania systemu. Całkiem sporo tego.
I teraz czy taki błąd jest w ogóle estymowalny? Według mnie, a także według zespołu(ów) mających na co dzień styczność z takimi błędami (i przekonały mnie naocznie do swoich racji) – absolutnie nie. Więc nie dość, że nie ma sensu tego robić, to nawet wszelkie próby tego są szkodliwe, bo marnują jeden z naszych najcenniejszych zasobów – czas.
W dodatku czasem diagnoza to lwia część naprawy błędu, bo sam fix (czyli poprawka) to kilka minut lub godzin pracy. Innym razem po długiej diagnozie, poprawka to kolejny wieloetapowy proces trwający dni lub tygodnie. I dopóki nie zainwestujemy często ogromnej ilości czasu i energii – nie dowiemy się jak jest naprawdę.
Taka estymacja ma kosztować często prawie tyle ile naprawa, to raz. Nie zawsze chcemy coś naprawiać [od razu], to dwa. A w dodatku często okazuje się to dopiero post factum. Więc może najlepiej ominąć ten etap (jako klasyczny WASTE) i bez estymacji przekierować błąd do Product Backlogu (jeśli jest decyzja GO – błąd jest ważny)? Albo (jeśli jest decyzja NO GO – błąd nie jest ważny (dziś)) przyjąć to po prostu do wiadomości, a skupić się na rzeczach ważniejszych?
Proste i klarowne, prawda?
I taki zdecydowany stan moich przekonań trwał do jesieni 2022, kiedy wziąłem udział w szkoleniu Professional Scrum Master II (zwanym Advanced) u Rebelsów, gdzie w trakcie jednej z gęstych od merytoryki dyskusji dałem się przekonać (czytaj: zrozumiałem), że wchodzimy obszar który możemy określić “TO ZALEŻY” 🙂
Podejście trzecie, bieżące – błędy szacujemy i nie szacujemy (to zależy)
Tutaj wielkie podziękowania dla Andrzeja Zińczuka, który z finezyjną prostotą podkopał mój jednowymiarowy pogląd na tę kwestię. W ogóle mam wrażenie, że im większe doświadczenie, tym większa skłonność do elastyczności i zwinności, ale to temat na inny wpis.
No dobrze, ale że jak to, nie będzie jednoznacznie? Trochę będzie. A trochę nie. Czyli jak? Na szczęście prosto, w dodatku opierając się na [UWAGA!] empiryzmie 🙂
Genialna prostota tego podejścia polega na robieniu tylko tyle, ile trzeba, żeby otrzymać wartościową informację zwrotną, na której będzie można oprzeć nasze dalsze działania. Taki w sumie Agile 😉
W praktyce wynika to z tego, że decyzja estymować/nie estymować nie powinna być podejmowana “a priori” (przed doświadczeniem). Bo dlaczegóż by? Nic nie stoi na przeszkodzie, żeby się odrobinę z takim błędem zapoznać, przyjrzeć mu się i wówczas ocenić, czy wiemy co się zepsuło (“autokar się zepsuł”), czy nie wiemy.
I jak okazuje się, że jednak wiemy, to zastanowić się, czy wiemy jak to naprawić. Obie odpowiedzi twierdzące dają nam zielone światło do tego, żeby taki błąd traktować jako każdy inny estymowa(l)ny PBI (Product Backlog Item). O ile oczywiście organizacja tego od nas wymaga, lub czujemy silny wewnętrzny przymus 😉 jeśli nie, to tym lepiej.
Jeśli wiemy co się zepsuło, ale nie wiemy jak to naprawić, to w sumie sytuacja jest bardzo zbliżona – z tym że w ewentualnej wycenie powinno znaleźć się odpowiednie podkreślenie obszaru “ryzyko”.
Jeśli natomiast nie wiemy co się zepsuło, to próba estymacji czegoś takiego to bardzo grube zgadywanie 🙂 i sam fakt że są osoby, które na podstawie takiego “guesstimation” (guess + estimation) są w stanie podejmować decyzje jest tyleż zaskakujący, co przerażający 🙂
Cała powyższa deliberacja bazuje oczywiście na tym, że ktoś tej estymacji błędów od nas może chcieć. Najlepiej się oczywiście bronić przed tym jak najdłużej, ale nie ma sensu za to umierać, i warto podejść do tej estymacji lub jej braku – metodycznie 😉
Co dalej?
Żeby ułatwić korzystanie z tej koncepcji, postanowiłem to zwizualizować. Skorzystałem z kultowego flowchartu dotyczącego rozwiązywania problemów za pomocą WD-40 lub srebrnej taśmy, w zależności od tego czy coś się rusza, i czy powinno i postanowiłem przygotować analogiczny.
Więc przedstawiam autorski diagram, pomagający odpowiadać na pytanie – “Czy estymować bugi?” 🙂
Ten flowchart jest zrobiony pół-żartem, pół-serio, ale dość dobrze ilustruje problem z estymacją bugów. Jest to pewien koszt. Koszt, który bardzo często jest trudny/niemożliwy do oszacowania zanim się go nie poniesie. Koszt, którego często da się uniknąć bo bug i tak zostanie naprawiony.
W dodatku mam spore wątpliwości czy priorytetyzacja błędu na podstawie czasochłonności i/lub pracochłonności jest lepszym (i w ogóle dobrym) sposobem porządkowania Product Backlogu, niż na przykład wpływ tegoż błędu na działanie użytkowników (i wszelkie z tym związane zagadnienia).
Brzmi to jak próba optymalizacji kosztów PRZED optymalizacją wartości. A według mnie powinno być dokładnie odwrotnie.
Z tymi przemyśleniami zostawiam Was i szczerze zapraszam do dyskusji, bo moje bieżące podejście do pytania “czy estymować bugi?” jest tylko podejściem, które jak najbardziej ma szansę się zmienić, jeśli tylko dostanie do tego odpowiednio umotywowany bodziec 🙂
Pozdrawiam serdecznie,
Marcin
1 comment