Story pointy a błędy

Zapytał mnie ostatnio znajomy Agile Coach co sądzę o pomyśle, by posługując się metodami Agile szacować błędy, które rozwiązuje zespół developerski. Oszacowania te mogłyby być wyrażone w tytułowych story pointach albo mieć dowolną inną formę przyjętą przez zespół. Po usłyszeniu takiego pytania ma się ochotę odpowiedzieć „to zależy”, ja jednak zacznę od odpowiedzi na zupełnie inne pytanie.

Po co w ogóle coś szacujemy w Agile?

To temat na osobny wpis, ale upraszczając odpowiedź do absolutnego minimum: po to, żeby wiedzieć, czy coś jest opłacalne i wykonalne w akceptowalnym czasie. Posługując się oszacowaniami wartości, jaką uzyskamy i kosztów wytworzenia (czasochłonności, pracochłonności lub „wielkości” w przypadku story pointów) da się lepiej zidentyfikować co jest najbardziej wartościowe w danym momencie.

Oczywiście jak już mamy oszacowania, możemy pokusić się o tworzenie na ich bazie prognoz. Z tym zastrzeżeniem, że takie projekcje są ważne na chwilę obecną i w danym kontekście, a przyszłość może szybko przynieść zmianę, która uczyni je zupełnie nieadekwatnymi. Przykładem może być przewidywanie terminów ukończenia prac z wykorzystaniem velocity – nie ma w tym nic pewnego, jest tylko mniejsze lub większe prawdopodobieństwo, że prognozowane daty się potwierdzą.

Innym sposobem użycia oszacowań – zwłaszcza tych dotyczących „wielkości” lub czasochłonności – jest ich wykorzystanie w procesie pielęgnacji backlogu. Rzeczy zbyt duże wymagają podziału, by dało je się zrealizować w krótkich iteracjach. Natomiast dyskusja o oszacowaniach i możliwej dekompozycji dużych elementów backlogu pozwala lepiej zrozumieć opisane nimi potrzeby.

Szacowanie błędów

Nie da się problemu potraktować binarnie i napisać jednoznacznych zasad czy i jak szacować pracę nad rozwiązaniem defektów. Przede wszystkim zespół developerski powinien zastanowić się, czemu oszacowania te mają służyć:

  • Podejmowaniu decyzji o tym jak i kiedy rozwiązać błąd?
  • Czemuś innemu? (czemu?)

Wiele zespołów liczy swoje velocity sumując estymaty zrealizowanych elementów backlogu produktu. Co stanie się, jeśli zaczniemy szacować również błędy? Powinniśmy je uwzględniać w kalkulacji velocity czy nie? Bo istnieje ryzyko, że uzyskamy fałszywe poczucie, iż robimy dużo wartościowych rzeczy jak te oszacowania uwzględnimy. A z drugiej strony nie chcemy, żeby developerzy stronili od rozwiązania błędów, jeśli oszacowań nie uwzględnimy i velocity okaże się mizerne w niektórych sprintach…

Oczywiście decydując o zasadach szacowania (lub braku szacowania) błędów trzeba też zastanowić się jak uniknąć sytuacji, w których zespół uzna, że rozwiązywanie dużej ilości defektów to wartościowa praca. Developerów i zlecającego im pracę Product Ownera (lub osobę pełniącą ekwiwalent tej roli w innej metodzie) powinno uwierać, że czas poświęcany jest na naprawianie błędów. A żeby coś zabolało, musi najpierw być widoczne. Wtedy jest szansa, że pojawią się usprawnienia, które poprawią jakość tworzonych rozwiązań i ilość błędów zacznie spadać.

Błąd błędowi nie równy

Jeśli mamy do czynienia z ewidentnym błędem technicznym wynikającym z partactwa zespołu developerskiego, który bezwzględnie musi dostarczyć poprawkę, aby produkt działał – to szacowanie niewiele w tym pomoże i można sobie go darować. Brak oszacowania nie stanowi przeszkody w odkryciu, że usunięcie defektu wymaga ogromnego nakładu pracy. W takim przypadku Product Owner poinformowany przez developerów o skali problemu może podjąć decyzję o pozostawieniu błędu bez rozwiązania.

Mniej oczywista jest sytuacja zespołu, który zaimplementował perfekcyjnie (od strony technicznej) coś co nie do końca odpowiada potrzebom biznesowym, bo źle je zrozumiał. Niby jest to błąd, ale empiryczny proces polega między innymi na odkrywaniu, że źle się zrozumieliśmy. I równie dobrze w tym przypadku Product Owner może powiedzieć: „nie dogadaliśmy się, więc trzeba rozwiązanie przerobić w ten sposób…”. Błąd stanie się kolejnym wymaganiem opisującym pożądaną zmianę w produkcie, a jego wyszacowanie i uwzględnianie w velocity nabiera od razu sensu.

Jest i trzeci przypadek: błędu wynikającego z braku wiedzy, że są jakieś przypadki, dla których dostarczone rozwiązanie działać będzie niepoprawnie. Problem ujawnia się późno, np. zgłaszają go użytkownicy produktu. Skoro wcześniej w ogóle nie było intencji obsługi takiego scenariusza, taki defekt powinien być traktowany jako nowe wymaganie i wtedy oczywiste jest, że powinien być szacowany i uwzględniany w velocity.

Dwa obszary zastosowania oszacowań

Wiele zespołów wpada w pułapkę podporządkowania swoich praktyk związanych z szacowaniem niewłaściwemu celowi. Mamy do czynienia co najmniej z dwoma obszarami zastosowania estymat:

  1. Oszacowania elementu backlogu, zadania lub błędu po to, by podejmować związane z nim decyzje.
  2. Użycia tych oszacowań później do czegoś więcej.

Nie ma co zastanawiać się nad obszarem drugim, jeśli nie zaspokajamy potrzeb obszaru pierwszego. Przede wszystkim należy zapewnić możliwość empirycznego działania, a więc podejmowania decyzji o tym co robić, w jakim zakresie i kiedy, a czego nie robić. Dopiero potem można dywagować na temat tego, jak jeszcze estymat dałoby się użyć (kalkulacja velocity, prognozowanie, planowanie etc.).

Przejrzystość

Sposób szacowania i korzystania z oszacowań zależy od umowy między zespołem i Product Ownerem. Mogą uzgodnić, że szacują wszystko, w tym błędy (bo to pozwoli lepiej ocenić jak kosztowne będzie naprawianie błędów), a potem pomijać w liczeniu velocity błędy. Mogą błędów nie szacować a te z nich, które są de facto nowymi zmianami w produkcie, konwertować na inny rodzaj zgłoszenia i traktować je w odpowiedni dla nich sposób. Mogą wymyślić jeszcze coś innego.

Ważne jest, by nie utracić przejrzystości. Zespół musi szybko zauważyć problem, jeśli ilość czasu poświęcanego na naprawę błędów rośnie. Ale musi też być w stanie potwierdzić, że podjęte usprawnienia dają pozytywny efekt (tworzone rozwiązania są lepiej dopasowane do potrzeb i mają mniej błędów niż wcześniej).

W wielkim świecie wielkich firm

Rzecz jasna w dużych organizacjach tej swobody decydowania o procesach i praktykach bywa mniej, bo najczęściej dążą one do unifikacji procesów i praktyk. Ciężko jednoznacznie określić, czy to dobrze, czy źle – granica jest płynna i zależy od kontekstów. Całkowita swoboda w dużej organizacji, gdzie zespoły pracują nad czymś wspólnie i mocno od siebie zależą, niekoniecznie pozwoli na ich skuteczne działanie i wzajemną synchronizację. Z drugiej strony nadmierny reżim pozbawi zespół wpływu na własny proces, a to może zabić motywację.

Jeśli więc mamy do czynienia z dużą organizacją to obowiązujące w niej standardy stanowią dodatkowy czynnik do uwzględnienia przy decydowaniu jak i co szacować. Zespół, któremu z racjonalnych powodów standardy wybitnie nie odpowiadają, znajdzie sposób na ich zmianę.

Niezbędna jest rozmowa i zrozumienie potrzeb i ograniczeń wszystkich zainteresowanych (organizacji i wszystkich zespołów). Pomagają w tym wybitnie wszelkiego rodzaju społeczności lub gildie, które zazwyczaj funkcjonują w sporych firmach. Współpraca przy definiowaniu standardów stosunkowo szybko prowadzi do znalezienia rozwiązania zadowalającego wszystkich. Oczywiście „szybko” jest pojęciem względnym i w dużych firmach o sporej inercji cierpliwość jest niezbędna.

Z pamiętnika Scrum Mastera

Nie chcę wniosków z moich doświadczeń jako Scrum Master podsuwać jako prawd uniwersalnych – każde miejsce jest inne. Ale chciałem podzielić się trzema.

Pierwszy jest taki: definiowanie twardej reguły, że tylko „biznesowe wymagania” powinny być szacowane a wszystko inne traktowane jest jako mająca niską wartość praca techniczna utrwala lub odnawia podział na „biznes” i „technologię”. A to szkodliwe, bo większość dzisiejszych rozwiązań to połączenie procesów biznesowych ze wspierającą je technologią. Twarde przekonania i wynikające z nich twarde reguły co szacować a czego nigdy nie szacować, co uwzględniać w velocity a czego absolutnie nie, to sygnał, że sporo jeszcze jest do zrobienia w zespole i organizacji.

Druga moja obserwacja dotyczy pokusy, by tworzyć algorytmy, które jednoznacznie pokierują nami w działaniu. To też szkodliwe, bo wyłącza myślenie. Ustalmy proste zasady i bądźmy otwarci do dyskusji indywidualnie o każdym przypadku. Ważniejsza niż precyzja reguł jest ich prostota i możliwość konsekwentnego stosowania. Złożone reguły generują wiele przypadków, dla których konieczne jest reguł tych doprecyzowanie, więc kodeks się rozrasta i w końcu nikt już go nie ogarnia… a więc i nie przestrzega.

Trzecia, dużo bardziej generalna obserwacja: problem „szacować czy nie szacować błędy” (albo zadania techniczne, tworzenie dokumentacji – dowolną inną rzecz można tu wstawić) pojawia się najczęściej tam, gdzie ludzie skupieni są na procesie, rolach, odpowiedzialnościach a nie na tym, co mają do zrobienia. Zespół, któremu zależy na produkcie, działający w środowisku, gdzie istnieje minimum wzajemnego zaufania niezbędnego do zadziałania empiryzmu, ustali zasady obsługi błędów w kilka minut. Choćby dlatego, że nie będzie pod nimi tonął, bo – jako że mu zależy – zadba o budowanie dobrych rozwiązań. A wtedy problem obsługi defektów w ogóle przestanie być istotny.