Ten artykuł trzeba czytać w drugiej kolejności po Ach, te story pointy…

Lubię story pointy, mam do nich sentyment. To fajny pomysł, którego zastosowanie omówiłem już we wspomnianym artykule. Z drugiej strony uważam, że choćby koncepcja była najświętsza, to jeśli nie wytrzymuje próby rzeczywistości, trzeba ją odrzuć. Tako i przyszła kreska na story pointy.

Jakiś czasu temu poprosiłem na FB, LI i TT od odpowiedź na trzy pytania odnośnie do story pointów. Dziękuję wszystkim, którzy wypełnili ankietę. Wyniki przedstawiają się następująco:

Czterdzieści procent respondentów stwierdziła, że nie używa lub nie zna skali, która jest kluczowa, jeśli chodzi o metodę szacowania przez podobieństwo - bo do tego służą story pointy. Jest to jakiś problem, ale istnieje poważniejszy - spora część ankietowanych używa story pointów chociaż nie widzi w tym żadnego sensu lub ta metoda nie buduje przewidywalności zespołu. I to jest bardzo bardzo poważny problem.

Jeśli zdecydowałeś się na pewien styl pracy, firmowany hasłem "zwinność", oparty na empiryzmie i zbieraniu danych, to ma to swoje konsekwencje. Po pewnym czasie czasie inżynierki i inżynierowie wyrabiają sobie osąd, co działa, a co nie. Jeśli zatem twoje doświadczenie poparte wynikami ze Sprint Report w Jira, czarno na białym stwierdza, że story points nie mają sensu i nie budują przewidywalności zespołu - przestań je stosować i to od razu

Moje osobiste zdanie jest następujące: story points nie przynoszą wartości przede wszystkim gdy:

  • nie masz regularnie aktualizowanej skali
  • refinement nie prowadzi do wystarczającego sprecyzowania pracy
  • jest duża liczba wrzutek i tematów pobocznych, które utrudniają zbudowanie rzetelnej skali

Co zamiast?

Zamiast kombinować ze story pointami, co ostatecznie i tak przybiera postać wyliczenia punktów ze wzoru 2 * ILE_TO_ZAJMIE + BUFOR do estymowania prędkości zespołu używaj liczby zadań wziętych na sprint. Uwaga doczytaj do końca !

Prędkość jako liczba zadań usunie bezużyteczne kombinowanie w stylu ile story pointów dać na to a na to? i kto da więcej? kto da mniej?. Do Jiry wciąż możesz wpisać liczbę - dla każdego zadania wpisz 1. Żeby każdemu zadaniu przypisać 1, muszą one być podobne. Zatem, aby zadania były podobne i żeby zespół mógł budować swoją przewidywalność musi on:

Prędkość jako liczba zadań usuwa storypointową przeszkodę; można bardzo skupić się na planning pokerze i fajnych kartach i zapomnieć, że podstawowym narzędziem jest tu refinement i dekompozycja. Robienie czegokolwiek uspokaja.

W zwinności często podkreślamy priorytety oraz skupienie na usuwaniu przeszkód. Priorytetem dla zespołu jest przewidywalnie dostarczać przyrosty. Story pointy miały w tym pomagać. Jeśli nie pomagają, to należy je zapisać na konto strat i niezwłocznie usunąć. Od zaraz.

Pseudoszacowania

Jest kilka podejść, które udają szacowanie, ale nim nie są. Zdemaskujmy je.

Wróżenie z fusów

– Ile czasu wam potrzeba?– Dwieście mendejów - brzmi pełna wiary we własne siły odpowiedź.

To jest właśnie wróżenie z fusów w pełnej krasie. Wróżba jak to wróżba – czasem się sprawdzi, czasem nie. Jeśli zespołowi przypadkiem uda się wykonać zadanie w terminie, okrywa się nieśmiertelną sławą.

Zgadywanie nie jest żadnym szacowaniem, lecz grą losową. W dodatku bez znajomości konstrukcji tej gry.

Metoda trzech miesięcy

Każde nietrywialne przedsięwzięcie programistyczne da się przedstawić tak, aby zostało oszacowane na trzy miesiące. 

Jeśli miałbym szukać jakiegoś uzasadnienia, to wydaje mi się, że te „trzy miesiące” to taka perspektywa czasowa, która:

·        nie jest zbyt długa, więc dość łatwo można ją zabudżetować,

·        nie jest zbyt krótka, więc jeszcze nie trzeba się martwić o ten temat.

Idąc za tym rozumowaniem można powiedzieć, że „trzy miesiące” to taka odpowiedź, której można udzielić jeśli chce się już zakończyć spotkanie i jednocześnie wyjść z niego „z twarzą”. Martwić się będziemy później.

Ekstremalnie długi bufor

Niezmiernie prostym i skutecznym sposobem pseudoszacowania jest ustalenie jakiegoś szacowania na zasadzie zgadywania, a potem dodanie do tego tak dużego bufora, żeby na pewno zdążyć zakończyć prace. Naturalnie istnieje szansa, że mimo bufora i tak nie uda się zakończyć prac w terminie.

To również nie jest szacowanie lecz drenowanie budżetu.

Sztywny deadline i cięcie zakresu

W tym przypadku została założona data wydania produktu, którego zakres na samym początku był prawdopodobnie mgliście określony. Następnie ktoś (może zespół, może pojedyncza osoba) potrafił tak doprecyzowywać oraz negocjować wymagania interesariuszy, że uzyskał satysfakcjonujący ich rezultat w założonym czasie.

Czy to rzeczywiście ma znaczenie, że opisana metoda nie jest prawdziwym szacowaniem. Tak ma. Jeśli ulegniesz złudzeniu, że ktoś rzeczywiście trafnie oszacował i poprosisz go o spisanie know-how, a następnie rozpoczniesz nowy projekt już bez tej osoby, to efekt może być zgoła odmienny. W tej metodzie kluczem do sukcesu jest umiejętność komunikacji, nie szacowania.

Sztywny deadline i roszady w budżetach

Wyobraź sobie następujący dialog:

– Kaziu, nie wyrobimy się z tymi funkcjonalnościami do końca kwartału.– Nie martw się, Stasiu. Podpiszę Ci protokół odbioru, a resztę prac dokończycie w ramach utrzymania.

Zagrożony projekt w magiczny sposób zakończył się z dotrzymaniem terminu oraz zakresu prac. W przyrodzie nic nie znika tak po prostu. Nic też nie powstaje bez przyczyny. Podobnie i tutaj ilość koniecznej do wykonania pracy nie wyparowała nagle w niebyt. Ot, zmieniła po prostu kolumnę w arkuszu kalkulacyjnym i powędrowała do innego budżetu.

Jak poprzednio, nie było to żadne szacowanie lecz arytmetyka projektowa.

Metoda ekspercka

Tej ostatniej metodzie można przyznać status metody szacowania (bez cudzysłowów). Polega ona na tym że, szacuje ekspert z bogatym doświadczeniem mierzonym zarówno w latach jak i w liczbie przedsięwzięć, w których uczestniczył.

Gdy ktoś spędził ogromną ilość czasu na robieniu pewnej rzeczy, to w głowie cały zestaw działających kontekstowo reguł decyzyjnych.

Główną trudnością w tej metodzie jest znalezienie odpowiedniego eksperta.

Szacowany MD to nie dzień kalendarzowy

Gdy inżynier szacuje w MD to przeważnie pojawiają się wartości takie jak: 1MD, 2MD, 3MD albo 0.5MD, 1MD, 2.5MD. Zazwyczaj są to wielokrotności tego, co inżynier musi zaraportować w time sheet. Nie są więc "prawdziwe" dni pracy lecz raczej wyobrażenie inżyniera o czasochłonności lub trudności zadania. Czyli takie story pointy przebrane w koszulkę mendeja. To spostrzeżenie doprowadziło właśnie do wniosku, że skoro szacowane MD to co innego niż dni kalendarzowe, to może nazywajmy je inaczej, może....story pointy...

Decyzje i dekompozycja

Steve McConnell opisuje studium nad zależnością pomiędzy dokładnością oszacowania a etapem na którym ono nastąpiło. Studium to przybrało postać stożka niepewności.

Im późniejszy etap przedsięwzięcia tym większa trafność oszacowania. Ale uwaga! Upływ czasu nie zwęża stożka. Nie jest tak, że jeśli odczekasz swoje, to wzrośnie trafność oszacowania. Zwężanie się stożka, czyli zwiększanie trafności oszacowania jest skutkiem podejmowanych decyzji. Na rysunku są to czerwone strzały. Mowa o decyzjach odnośnie priorytetów, wymagań, architektury.

Druga sprawa to taka, że dekompozycja zadania jest ujemnie skorelowana z błędem oszacowania. Zatem im bardziej dekomponujesz, tym bardziej zwiększasz szansę na to, że dowiedziesz zgodnie z założeniami.

Zatem jeśli:

  • PO ustala priorytety - zwiększa się trafność oszacowania,
  • PO odrzuca wrzutki w trakcie sprintu - zwiększa się trafność oszacowania,
  • PO na podstawie liczb wybiera MVP na najbliższy kwartał - zwiększa się trafność oszacowania,
  • Robicie regularne refinementy - zwiększa się trafność oszacowania,
  • Piszecie scenariusze testowe na wczesnym etapie czyli na refinemencie - zwiększa się trafność oszacowania,
  • Warsztatujecie architekturę na wczesnym etapie czyli na refinemencie - zwiększa się trafność oszacowania,
  • Dekomponujecie zadania na małe kawałki - zwiększa się trafność oszacowania.

Refinement jest wszystkim

Jedyną znaną mi metodą, która pozwala na szacowanie "prawdziwymi" dniami kalendarzowymi jest PERT, lecz wtedy:

  • zadanie należy rozłożyć na kawałki (dekompozycja)
  • każdy z nich oszacować optymistycznie, pesymistycznie i realistycznie
  • policzyć wartość oczekiwaną
  • policzyć i uwzględnić odchylenie standardowe, aby zwiększyć przedział ufności szacowania
  • zbierać dane oczekiwane i rzeczywiste oraz prowadzić statystykę dla osób lub zespołów, aby wyznaczać ich charakterystyki oraz tuningować proces

Jak widać wszystko sprowadza się do refinementu wg praktyk wskazanych powyżej, gdyż właśnie refinement pomaga budować przewidywalność.

A co z punktami funkcyjnymi?

No jest coś takiego i czasem jakaś organizacja szczyci się trafnością szacowania w FP, ale:

  • w punktach funkcyjnych należy dogłębnie rozkminić architekturę: liczbę danych we, liczbę danych wy, liczbę odczytów oraz zapisów, liczbę modułów współpracujących, itd.
  • punkty funkcyjne wyliczają rozmiar oprogramowania w LOC, a potem każą przeliczać na MD, co samo w sobie jest karkołomne
  • w tej organizacji nieustannie zbiera się dane i tuninguje mnożniki: ryzyka, złożoności, liczby współpracowników itd.
  • dba się o powtarzalność zadań, bo powtarzalność to wiedza, a wiedza zwiększa trafność oszacowania
  • FP zostały opracowane dla systemów bazodanowych, wg mojej wiedzy metody dla oprogramowania np. obiektowego nie mają statusu metod oficjalnych
  • o ile wiem metoda nie jest rozciągnięta na wszystkie możliwe przedsięwzięcia

Czyli ponownie: refinement, decyzje, refinement, decyzje. I tak w nieskończoność.

Lektura uzupełniająca

Coś pozytywnego na koniec

Dostałej jeszcze krótkie podsumowanie artykułu od jednej z czytelniczek. Myślę, że warto je tu przytoczyć w całości.

Trochę podumałam i przekaz jest optymistyczny. W 80% osób korzystających ze story pointów zawiera się grupa osób posiadających skalę. Czyli w bezwzględnych procentach - 60% repondentów wycenia w sp i ma skalę. A to się idealnie pokrywa z 60% osób, które widzą sens w takiej metodzie. Przypadek? :)

Moim zdaniem to prowadzi do wniosku, że jeśli poprawnie zastosujesz sp to dadzą Ci one wymierną korzyść w postaci przewidywalności

Czytelniczka

.