Estymacja

Za wikipedią estymacja to dział wnioskowania statystycznego, będący zbiorem metod pozwalających na uogólnianie wyników badania próby losowej na nieznaną postać i parametry rozkładu zmiennej losowej całej populacji oraz szacowanie błędów wynikających z tego uogólnienia.

Naturalnie nie mogę zagwarantować, że po lekturze niniejszego artykułu szanowny czytelnik będzie uzyskiwał dokładne estymacje. Niemniej mam nadzieję, że uczynię Cię bardziej pewnym w ich dostarczaniu.

Przykład

W artykule chciałem się skupić na przykładzie oraz metodologii, która sprawdza się w moim przypadku. Przechodząc do meritum proponuję rozpatrzyć następujący problem:

Jako administrator sklepu internetowego chcę, aby jego zamówienia zostały automatycznie przekazane po opłaceniu do zewnętrznego spedytora, który w tym celu wystawi niezbędne API.

Na pierwszy rzut oka brzmi prosto i precyzyjnie, niemniej w zależności od złożoności systemu oraz intensywności wpadania do niego zamówień sprawa znacząco się komplikuje. Widzimy zatem, że już na początku natrafiamy na pierwszą przeszkodę. Literatura elegancko nazywa niniejszy problem Cone of Uncertainty (czyli rożek/stożek/lejek niepewności). Termin ten oznacza, że developer w chwili początkowej startuje od największej ilości ryzyka i niepewności związanych z funkcjonalnością.

Sytuacja pogarsza się tym bardziej im zainteresowane strony zmieniają założenia i cele. Jedynym sposobem na obniżenia stożka jest stale przeprowadzanie badań oraz konsultacji w celu wyjaśnienia i uporządkowania możliwie jak największej ilości zmiennych.

Przy tak przedstawionym problemie naturalnie nasuwa się masę pytań. Jakim protokołem wysyłane będą dane do API, w jaki sposób będą zabezpieczone, jakiego formatu powinny być dane wyjściowe, jaką przepustowość zapewni bramka odbierająca zamówienia, itd…

Work-breakdown structure

Istnieje ogromna niepewność/nieprecyzyjność w naszej treści zadania. Pierwszą rzeczą, którą należy zrobić jest rozbicie zadania na mniejsze porcje pracy, tak abyśmy mogli wyestymować każde z osobna. Formalnie mówimy o tworzeniu work-breakdown structure (WBS), czyli strukturę podziału pracy.

Naturalnie po dokonaniu konsultacji z klientem otrzymałem niezbędną specyfikacje techniczną interfejsu API, który wymagał protokołu RESTowego z prostą autoryzacją tokenową. Specyfikacja również zawierała niezbędne szczegóły co do formatu danych wejściowych oraz zwracanych błędów. Dopiero wówczas problem mogłem podzielić na mniejsze komponenty:

1. przygotowanie interfejsu klienta, który przyjmując dane wejściowe konwertuje dane do formatu json i wysyła je bramki
2. dodanie do interfejsu klienta mechanizmu logującego wychodzące żądania oraz przychodzące odpowiedzi
3. przygotowanie mechanizmu kolejkującego zamówienia, aby w sytuacji niepowodzenia wysyłki móc ponawiać ją do skutku, a w sytuacji niedostępności serwisu partnera poinformować o tym administratora systemu
4. przygotowanie serwisu mapującego dane zamówienia do modelu przyjmowanego przez bramkę partnera
5. implementacja wysyłki danych

Naturalnie wciąż pozostaje sporo niejasności zwłaszcza w sytuacji metodologii mapowania. Po dalszych konsultacjach okazało się, że administrator systemu zarządał dodatkowej kontroli nad mapowaniem w związku z tym ostatni punkt musiałem rozbić na jeszcze mniejsze partie:

4a. przygotowanie GUI dla elementów zamówienia, które administrator sytemu może zmapować na dane zgodne w bramce partnera
4b. przygotowanie struktury przechowującej relacje encji naszego systemu do encji systemu partnera
4c. uzupełnienie mappera zamówień o zaktualizowane właściwości oraz encje systemu partnera zgodnie z zapisaną mapą

W powyższym podziale zawsze staram się trzymać zasady, aby każdy z punktów pochłonął do 4h mojej pracy. Uwaga! podejrzewam, że wielu programistów spotkało się w literaturze, aby porcje zajmowały nie więcej niż 8h, czyli maksymalnie jeden dzień roboczy. Istnieje również Queueing theory (teoria kolejek), która sugeruje rozbijanie rzeczy na mniejsze, łatwiejsze do opanowania części, dzięki czemu istnieje możliwość równoległego przepływu pracy co w konsekwencji prowadzi do zwiększenia jej przepustowości.

Niemniej ze względu na fakt, że często pracuje nad zadaniami samodzielnie i jestem zmuszony przerywać prace i zajmować się innymi drobniejszymi tematami, które wpadają niezapowiedzianie jak konsultacje lub hotfixy, drobniejsza estymacja pozwala mi lepiej planować sobie nadchodzący dzień. Naturalnie w sytuacji gdy skończę bieżący punkt zadania, biorę się za następny 😉

Naturalnie finalną estymacją jest zsumowanie czasów wykonania poszczególnych punktów. Powyższy przykład przedstawia tzw. oszacowanie eksperckie. Oprócz tego istnieje jeszcze podejście formalne, tj. wykorzystanie próby statystycznej. Dzięki niej można obliczyć dodatkowy błąd statystyczny i uwzględniać go w następnych szacunkach. Oraz dysponujemy również podejściem łączonym, które stanowi sumę dwóch wspomnianych metod.

Planowanie grupowe

W sytuacji, gdy poszczególne punkty naszego zadania szacujemy w grupie programistów dysponujemy jeszcze takimi opcjami jak Planning Poker (lepiej znany jako Scrum Poker) oraz Wideband Delphi. W pierwszej, członkowie grupy dokonują oszacowań, grając ponumerowanymi kartami zakrytymi do stołu, zamiast wypowiadać je na głos. Karty zostają ujawnione, a następnie omawia się dane szacunkowe. Ukrywając dane w ten sposób, grupa unika nastawienia poznawczego, gdzie pierwsza liczba wypowiedziana na głos stanowi precedens dla kolejnych oszacowań.

W procesie Delphi koordynator zespołu przedstawia każdemu ekspertowi specyfikację i formularz oceny. Następnie podczas grupowego spotkania eksperci omawiają kwestie oceny z koordynatorem i między sobą. Na koniec wypełniają formularze anonimowo, a Koordynator przygotowuje i rozpowszechnia podsumowanie szacunków. W sytuacji gdy estymacje są mocno rozbieżne powtarzamy cały proces, aż do osiągnięcia zadowalającego konsensusu.

Niewątpliwą zaletą wspólnego szacowania problemów programistycznych jest fakt, że te mogą odkryć nowe techniki i/lub pułapki które skrywa zadanie. Istnieje jeszcze bardziej złożone podejście mianowicie metoda punktów przypadków użycia (Use Case Points w skrócie UCP). Polega ona na przypisywaniu punktów relatywnie w zależności od złożoności zadania. Im bardziej złożone tym kosztują więcej punktów. Pomysł polega na tym, że bardziej złożone zadanie powinno się wykonać dłużej, niż proste zadanie. Po uzyskaniu punktacji można w pewien sposób uzyskać niezbędną ilość godzin developerskich. Niemniej należy pamiętać, że punkty nie stanowią bezpośredniego przełożenia na liczbę godzin. Dla zainteresowanych odsyłam do artykułu: https://rubygarage.org/blog/3-reasons-to-estimate-with-story-points

Podsumowanie

Podsumowując, estymacje stanowią istotną część cyklu produkcyjnego. Pozwalają nam podejmować decyzje dotyczące tego, co się dzieje w projekcie. Na koniec zwracam jeszcze uwagę o prawie Brook’a z pozycji „The Mythical Man Month”, który stwierdza, że dodawanie osób do projektu może zwiększyć ilość czasu w jego realizacji. Zatem należy również pamiętać o równowadze między wprowadzaniem ludzi w zadania bez powodowania wielu przeszkód i utrudnień.

Autorem tekstu jest Marek Rode.