Ruch #NoEstimates, czyli koniec estymat

Powierzchowne spojrzenie na nurt #NoEstimates przypomina spojrzenie na manifest agile, zakładający nadrzędność działającego oprogramowania nad szczegółową dokumentacją. Aha! Oprogramowanie ma po prostu działać, a dokumentacja jest zbędna. 

I kiedy próbuję przekonać kogoś, że warto byłoby dokumentować kluczowe elementy wytwarzanego oprogramowania (bo ktoś to oprogramowanie będzie rozwijał, utrzymywał itd...), słyszę: „Dobrze, ale to już nie będzie agile”. 

Idąc tym tropem można uznać, że estymowanie zadań jest stratą czasu, bezsensowną próbą pokazania, że jesteśmy w stanie określić czas wdrożenia danej funkcjonalności z dokładnością do godziny. 

Zdecydowana większość projektów nie jest realizowana terminowo i w założonym budżecie, więc albo trzeba zwiększyć dokładność szacowania albo w ogóle zaprzestać robienia tego. Jedno wydaje się trudne, drugie - odrobinę szalone. 

Laureat nagrody Nobla Daniel Kahneman wraz z Amosem Tverskym, zaproponowali określenie „złudzenia planowania”, wykazując, że planowanie czasowe związane jest ze zbyt dużym optymizmem, wynikającym z uwzględnienia tylko najbardziej optymalnego scenariusza, myślenia życzeniowego oraz niedoszacowania. 

Autorzy koncepcji #NoEstimates - Neil Killick, Woody Zuill czy Vasco Duarte, przekonują do rezygnacji z oszacowań, sięgając po trzy koronne argumenty nazwane “3xE”2.

Empiricism (empiryzm)

Jedyną miarą postępu prac jest działające oprogramowanie i to powinien być dominujący czynnik przy podejmowaniu decyzji. Nie jest to bynajmniej z góry zaplanowany harmonogram nieuwzględniający elementów niepewności, zmienności i ryzyka, czy błędne założenia wejściowe. 

Ethics (etyka)

Harmonogramy projektowe mają z góry zadeklarowany zakres, czas, a niekiedy także kolejność realizacji poszczególnych zadań. Zadania są często wykonywane po zadeklarowanej dacie ukończenia albo zgodnie z założoną datą dostarczenia, ale kosztem jakości. To osłabia zaufanie i wiarygodność między Zleceniodawcą a Wykonawcą. 

Emergence

Feedback z rynku albo bezpośrednio od klienta jest wyznacznikiem rzeczywistej wartości naszego produktu. Często jednak odroczonym.

Remember that #NoEstimates is not about no estimation ever, but about the minimum amount of estimates that will do, and then look carefully at ways to reduce that need even more.” 

— Ángel Medinilla

Przede wszystkim powinniśmy się skupić na priorytetyzowaniu zadań pod kątem wartości biznesowej dla klienta. Product Backlog powinien być posortowany właśnie w oparciu o to kryterium. 

Jaką alternatywę możemy zastosować dla estymacji, a już zwłaszcza w jednostkach czasowych? Forecast

Forecast

Forecast jest niczym innym jak próbą zdefiniowania trendu zmian (poprzez zestawienie danych historycznych) oraz jego ekstrapolacji w przyszłość. Opierając się na zbieranych w procesie danych, można przygotować realną prognozę dla kolejnych zadań. Brzmi trochę znajomo, szczególnie dla tych, którzy pracując w Scrumie, mieli okazję usłyszeć o velocity. 

Forecastowanie nie jest zresztą niczym szczególnym w Scrumie. Znając velocity (ilość pracy, jaką zespół wykonuje w trakcie iteracji) i capacity zespołu (czas, jaki mają do dyspozycji członkowie zespołu na wykonanie zadań iteracji), możemy obliczyć współczynnik skupienia tj. tzw. focus factor (focus factor = velocity/capacity), który z kolei jest jedną z danych podstawianych do wzoru obliczającego forecast (Forecast = Focus Factor x Capacity). 

W przypadku #NoEstimates mówimy o czymś zbliżonym, ale mimo wszystko zgoła odmiennym. Będziemy patrzeć na liczbę dostarczonych elementów w trakcie trwania jednej iteracji. Takie założenie wymusza na nas przygotowanie równej wielkości zadań. Vasco Duarte sugeruje tutaj, aby implementacja jednego zadania nie trwała dłużej niż 0,5-1 dnia. 

Widzę w tym założeniu pewien brak konsekwencji. Czy to nie jest przypadkiem klasyczne dzielenie zadań w oparciu o man-days? 

Nie estymuj, prioretyzuj

Zostańmy przy podziale zakresu prac na równej wielkości zadania. Być może jestem odosobniona, ale nie widziałam do tej pory Product Backlogu, który byłby podzielony na równe kawałki. Jestem w stanie sobie to wyobrazić przy zastosowaniu sztucznego podziału i odstawieniu na bok logiki i zdrowego rozsądku. To tak jakby przycinać książki, aby ich rozmiar pasował do wysokości regału. 

Jeżeli zaczniemy grupować taski i zakładać, że wielkość jednego zadania odpowiada sumie dwóch innych, to moim zdaniem wchodzimy ponownie w proces estymowania. 

Dzięki ułożeniu tasków w Product Backlogu według wartości biznesowej, odejdziemy od myślenia o ich estymowaniu, a skupimy się na priorytetyzowaniu. To z kolei pozwoli realnie planować rozwój produktu nie w oparciu o ramy czasowe i działanie zgodnie z harmonogramem, ale o wartość biznesową ze wszystkimi jej miarami efektywności. 

Ruch #NoEstimates tylko pozornie zachęca zatem do zaniechania estymowania. Przypomina nam, że często wykorzystywane przez nas storypointy mówią o złożoności problemu, a nie o czasie jego rozwiązania. 

W rzeczy samej pokazuje adaptacyjne podejście do dostarczania wartości rozwijanych produktów. 

W przeciwieństwie do realizacji z góry ustalonego planu opartego na ramach czasowych, skupia się na podejściu iteracyjnym, gdzie ograniczeni jesteśmy przez czas (ustalony ostateczny termin wdrożenia) lub finanse (maksymalny budżet przeznaczony na wdrożenie produktu/usługi). Wartość dostarczonego rozwiązania ponownie pojawia się na pierwszym planie. 

Focus factor wycelowany jest tutaj na proces dostarczania wartości. Jedną z podstawowych zasad Kanbana jest dążenie do kończenia zadań, a nie rozpoczynanie kilku rzeczy jednocześnie, z których część zatrzyma się na etapie „in progress”. Kanban stawia na limity WIP (work in progres), które ograniczają pracę w toku i pokusę pozornej pracy nad całym zakresem projektu jednocześnie. 

Prawie robi dużą różnicę. Albo praca nad daną funkcjonalnością jest zakończona albo nie. Zero-jedynkowo. Prawie”- oznacza tę drugą możliwość. Dokładnie taki sam sposób myślenia jest reprezentowany przez ruch #NoEstimates. 

Celowo wspomniałam o Kanbanie, z uwagi na to, że #NoEstimates zachęca do korzystania z metryk zaczerpniętych z tej metody. Podstawowym celem metryk nie jest kontrola ludzi, tylko wspieranie ich pozytywnych zachowań oraz kontrola procesu. 

W swojej pracy zawodowej widziałam wiele różnorodnych projektów. Te, które mogę uznać za najbardziej dojrzałe i wartościowe, miały zdefiniowane kluczowe czynniki efektywności i odpowiednio dobrane pod to metryki (z ograniczonym ryzykiem wpadnięcia w pułapkę lokalnych optymalizacji). Cel, jaki im przyświecał, to ostateczny sukces produktu, a nie sukces poszczególnych procesów (np. dążenie do wysokiego poziomu pokrycia kodu testami, próba wdrożenia polityki „no bugs” itp.). To są oczywiście bardzo ważne elementy procesu inżynierii oprogramowania, ale same w sobie i oderwane od pozostałych, nie przynoszą wartości biznesowej. 

Cycle Time

#NoEstimates zachęca do mierzenia procesu np. wykorzystując metrykę „Cycle Time”. Pokazuje nam ona średni czas spędzony na wykonaniu zadania – od momentu jego podjęcia, do osiągnięcia statusu „Done”. 

Załóżmy, że jednym z elementów, które będziemy monitorować, będzie jakość dostarczanego kodu. Przykładową metryką, która może nam w tym pomóc, będzie czas naprawy błędów wychwyconych w testach regresyjnych. 

Sposób, w jaki będziemy to mierzyć, będzie wypadkową czasu pomiędzy wykryciem błędu regresji, a wprowadzeniem poprawki w kodzie. Możemy określić także maksymalny dopuszczalny czas na naprawienie błędu albo procent testów automatycznych, które wykrywają regresję jeszcze przed integracją kodu z master branchem (% testów w smoke testach). To będą nasze mierniki efektywności procesu.

Nie chodzi tutaj o tworzenie mierników, które nie mają przełożenia na wzrost wartości dostarczanych rozwiązań. Czy jesteśmy w stanie osiągnąć 90 –procentowy poziom pokrycia kodu testami? Tak! Czy to będą wartościowe testy i czy naprawdę wszystko warto obwarować testami? Niekoniecznie. 

Lead Time

Drugą podstawową miarą jest „Lead Time”- czyli średni czas mierzony od momentu powstania zadania do jego dostarczenia. Doskonale pokazuje odcięcie się od estymat na rzecz pokazania zmienności czasu zamykania zadań. 

Posłużmy się przykładem: 

1 grudnia do rejestru produktu trafia zadanie. Dwa tygodnie później (14 grudnia) zespół developerski rozpoczyna pracę nad tym zadaniem. 20 grudnia następuje jego wdrożenie produkcyjne. 

Cycle Time czyli proces implementacji wynosi 6 dni (14.12 –rozpoczęcie prac, a 20.12 – wejście na produkcję) 

Lead Time czyli czas, jaki upłynął od momentu wpisania zadania do Product Backlogu do produkcyjnego wdrożenia, wynosi 19 dni. 

Lead Time skupia się na aspekcie doświadczenia klienta (tyle faktycznie dni klient oczekiwał na wdrożenie zmiany), a Cycle Time na możliwościach procesu. 

Lead Time = Cycle Time x Work in Progress 

Ten przykład bazuje także na założeniu, że Product Backlog nie jest listą życzeń, ale trafiają tam wyłącznie zadania, nad jakimi faktycznie chcemy pracować. 

Trzecią miarą jest Throughput (TP), która jest dla odmiany miarą ilościową. To nic innego, jak liczba zadań zrealizowanych przez zespół w danym okresie. 

#NoEstimates opiera się na bardzo małych zadaniach zbliżonych wielkością do siebie, dzięki czemu możemy przejść do prostego mierzenia ich liczby per 1 iteracja. 

Jeżeli Throughput nie zmienia się w czasie, osiągamy pewną przewidywalność zespołu (nie oznacza to najwyższej efektywności, jaką ten zespół może osiągnąć, ale pewną stałą). 

Dla zespołu, który chce podnieść efektywność swojej pracy, celem będzie zwiększenie Throughputu przy jednoczesnym zmniejszeniu Cycle Time. 

Z kolei relację pomiędzy Lead Time a Throughput można zobrazować w następujący sposób: 

Work in Progress = Lead Time x Throughput 

Największa wartość wynika z bezpośrednich relacji pomiędzy tymi miarami. Sukces optymalizacji prac zespołu (Lead Time, Cycle Time), będzie zależny od ilości zadań, nad którymi zespół pracuje (WiP). 

Zainteresowanym symulacjami w zakresie metryk produktowych polecam przetestowanie prostego, darmowego narzędzia Agiledata.

Podsumowanie dotychczasowych rozważań

Ruch #NoEstimates nie zachęca nas do porzucenia estymacji zadań, ale zmiany sposobu myślenia o rozwoju produktu i osiągnięcia pewnej przewidywalności pracy. W jaki sposób można rozwijać produkty bez szacowania ich rozmiaru? 

1. Odejdźmy od klasycznego estymowania na rzecz prognozowania. Forecastowanie opiera się na realnych danych i pozwala uchwycić pewne trendy i zależności. 
2. Załóżmy, że naszym ograniczeniem jest budżet i czas. Zakres projektu jest elementem zmiennym, warunkowanym zmianami rynkowymi oraz zmianami priorytetów biznesowych. 
3. Priorytetyzacja zadań w Product Backlogu powinna bazować na wartości biznesowej. W pierwszej kolejności realizowane będą te, których wpływ na biznes jest najistotniejszy. 
4. Zadania w Product Backlogu powinny być małe, a najlepiej równej wielkości. Dzięki temu łatwo będzie nam planować kolejne iteracje, bazując na podejściu ilościowym. 
5. Produkty powinny być rozwijane iteracyjnie, w żadnym wypadku według z góry ustalonego harmonogramu. 
6. Stosujmy metryki do mierzenia procesów. Mierzmy tylko to, co faktycznie ma znaczenie dla powodzenia projektu. Takie dane pozwolą nam śledzić, jak kształtuje się wydajność procesów. 
7. Kompleksowo skupmy się na procesie i nie wpadnijmy w pułapkę nadmiernej optymalizacji poszczególnych jego elementów (np. tylko procesu testowania, developmentu, deploymentu). 
8. Zbudujmy histogramy, aby określić średni czas trwania zadania (Cycle Time). Zapisujmy datę rozpoczęcia i zakończenia prac nad danym featurem. 
9. Korzystajmy ze średniego czasu trwania cyklu dla zadania (Lead Time), aby mierzyć, ile czasu potrzeba od momentu powstania zadania do jego wdrożenia produkcyjnego. 
10. Bazując na Cycle Time i Lead Time oraz na średniej ilości ukończonych zadań w iteracji, możemy tworzyć wiarygodne prognozy. 

Podsumowanie

Czy sprawdzi się to w praktyce? Pewnie to zależy od projektu, produktu i od otoczenia biznesowego. Nie uwzględniliśmy tutaj kilku elementów, które są powszechne w pracy nad rozwojem oprogramowania, jak wrzutki, ryzyka projektowe, zmiany personalne w zespołach czy zaciągnięty dług techniczny, który potrafi nas zaskoczyć w najmniej spodziewanym momencie. 

Pracując jednak nad wzrostem przewidywalności procesów poprzez zbieranie i pomiar danych, a w konsekwencji prognozowanie przebiegu kolejnych etapów, będziemy na dobrej drodze.