„…nasze techniki szacowania błędnie mylą wysiłek z postępem, ukrywając założenie, że ludzie i miesiące są wymienne”. ~ Frederick P. Brooks Jr.

Szacunki rozwoju oprogramowania są trudne i niewiarygodne. To nie jest nowy problem; zmagaliśmy się z szacunkami przez dziesięciolecia. Mimo to wciąż na nie nalegamy — dają (w dużej mierze fałszywe) poczucie bezpieczeństwa.

Problem leży w charakterze pracy, którą wykonujemy. Często wymaga rozumowania i rozwiązywania problemów; musimy usiąść i zmagać się z problemem, dopóki nie będziemy w stanie go „rozgryźć”. Nasze szacunki próbują zapewnić pewien stopień przewidywalności pracy, która jest z natury nieprzewidywalna.

Dla zilustrowania — powiedzmy, że znasz zasady gry w szachy. Jeśli postawię przed tobą szachownicę z toczącą się partią i powiem ci, że białe mogą zmatować w trzech ruchach — ile czasu zajmie ci odgadnięcie, jakie to są trzy ruchy? Pamiętaj, że znasz zasady, wiesz, jak poruszają się pionki i wiesz, jak aktualnie wygląda plansza. Innymi słowy, masz wszystkie informacje, jakich można sobie wyobrazić.

Nie możesz tego oszacować? Cóż… tworzenie oprogramowania to prawie to samo.

Dlaczego oszacowania są trudne do uzyskania

W przypadku projektów oprogramowania musimy wziąć pod uwagę wiele elementów — w tym technologię, ludzi, wymagania i zależności zewnętrzne. W każdym z nich istnieje zmienność.

Technologia sama w sobie jest złożona — istnieje wiele języków programowania, bibliotek i narzędzi. Nieoczekiwane problemy często pojawiają się, gdy łączymy te wszystkie rzeczy. Rzekoma pięciominutowa zmiana w celu uaktualnienia wersji biblioteki może zamienić się w dwudniowy wysiłek, ponieważ nowa wersja biblioteki jest gdzieś niekompatybilna z inną biblioteką, co oznacza, że ​​również należy ją zmienić. To z kolei wymaga dodatkowych testów. Literówka w linii kodu może spowodować wielogodzinne debugowanie.

Ludzie też nie zawsze są jednakowo produktywni — a szacunki zakładają, że wszyscy jesteśmy jednakowo kompetentni i że będziemy pracować w stałym tempie, niezależnie od tego, czy jesteśmy zmęczeni, sfrustrowani czy chorzy. To tak nie działa w realnym świecie. Przerwy się zdarzają i czasami ktoś musi poświęcić godzinę lub dwie na pomoc koledze (a to nie jest złe).

Wymagania mogą być niejasne lub zmieniać się wraz z pojawianiem się nowych informacji (a powinny). Jeśli programista zaczyna wdrażać nowe wymaganie i odkrywa, że ​​coś nie ma sensu, musi znaleźć kogoś, kto może mu to wyjaśnić. Ale co, jeśli ta osoba jest na urlopie lub utknęła na spotkaniach przez resztę dnia? „Czas oczekiwania” skutkuje ogólnym opóźnieniem — co oznacza, że ​​jedno pytanie dotyczące wymagania może unieważnić oszacowanie.

Zależności zewnętrzne są trudniejsze do kontrolowania niż zmiany wymagań — jeśli przejdziemy do świata, w którym jesteśmy zależni od zewnętrznych dostawców, będziemy podlegać ich umowom SLA w celu rozwiązania problemów. Jeśli zewnętrzną zależnością jest interfejs API, oznacza to, że wprowadziliśmy wiele dodatkowych punktów awarii — wszelkie problemy z naszymi serwerami, serwerami dostawcy lub dowolnymi składnikami sieci pomiędzy nimi spowodują opóźnienia.

Szacunki mogą również prowadzić do przekonania, że ​​praca jest podzielna — jeśli szacuje się, że opracowanie funkcji zajmie 10 dni, czy to oznacza, że ​​dwóch programistów może to zrobić w ciągu pięciu dni? Lub 10 programistów dziennie? Niestety, dziewięć kobiet nie może urodzić dziecka w miesiąc . W rzeczywistości dodanie większej liczby programistów, aby spróbować przyspieszyć proces, służy jedynie do dodania narzutu komunikacyjnego, co prawdopodobnie pogorszy sytuację.

Dlaczego interesariusze chcą szacunków

Nietrudno zrozumieć, dlaczego nasi interesariusze chcą szacunków. W końcu ktoś płaci za naszą pracę. Mają budżety, terminy, klientów do zaspokojenia i zwrot z inwestycji do obliczenia. Jeśli możemy im powiedzieć, czego i kiedy mają się spodziewać, proces ten staje się prostszy.

W niektórych innych branżach zadania mogą być wystarczająco dobrze zdefiniowane, abyśmy mogli je wiarygodnie oszacować. Jeśli prowadzimy linię produkcyjną składającą widżety i wiemy, że złożenie jednego widżetu zajmuje dokładnie 10 minut, wiemy, że w ciągu godziny możemy złożyć sześć widżetów. Jednak nasze widżety (w przeciwieństwie do naszego oprogramowania) są ustandaryzowane — więc jeśli linia produkcyjna nie zostanie zamknięta, jest mało prawdopodobne, że odejdziemy od normy. Tego samego sposobu myślenia, który sprawdza się w innych branżach, nie można rozszerzyć na oprogramowanie. Każde innowacyjne rozwiązanie, które budujemy, wiąże się z rozwiązaniem nowego, nowatorskiego problemu. Możemy czerpać z wcześniejszych doświadczeń, ale nie prowadzimy linii produkcyjnej.

Tradycyjne podejścia do szacowania

godziny

To oczywiste — szacujemy, że wykonanie określonego zadania zajmie określoną liczbę godzin. W praktyce ludzie są w tym okropni i zwykle bardzo źle to rozumiemy. Jest to również niebezpieczne, ponieważ szacunki godzinowe są różne dla różnych członków zespołu — dwugodzinne zadanie dla programisty z 10-letnim doświadczeniem w Javie prawdopodobnie nie będzie dwugodzinnym zadaniem dla absolwenta, który zaczął uczyć się Javy miesiąc temu .

Punkty fabularne

Takie podejście proponuje Scrum.

Punkty historii to względna jednostka miary, która porównuje zadania ze sobą. Innymi słowy, zaczniemy od zadania proxy, takiego jak „dodaj ekran z pięcioma polami, punktem końcowym interfejsu API i tabelą bazy danych” i przypisujemy mu dowolną wartość (zwykle opartą na ciągu Fibonacciego). Jeśli naszemu zadaniu pośredniczącemu przydzielono pięć punktów fabularnych i oszacowaliśmy nasze następne zadanie — „dodaj ekran z dziesięcioma polami, dwoma punktami końcowymi interfejsu API i tabelą bazy danych” — możemy zdecydować, że zadanie jest nieco bardziej złożone i przydzielić osiem historii wskazuje na to. Punkty fabularne nie reprezentują dni, godzin ani żadnych innych metryk specyficznych dla czasu — są jedynie sposobem na porównanie różnych zadań.

Następnie obliczamy liczbę punktów fabularnych, które zespół ukończy w trakcie sprintu, i wykorzystujemy to do określenia „szybkości” zespołu, która jest metryką, która wskazuje, ile punktów fabularnych możemy ukończyć podczas sprintu. Wskaźnik ten jest oparty na zespole jako całości, a nie na poszczególnych osobach.

Proces szacowania punktów historii nazywa się „ pokerem planowania ” i odbywa się podczas sesji porządkowania backlogu, w których bierze udział cały zespół programistów. Istnieje wiele sprzeciwów wobec punktów fabularnych , ale proces przydzielania punktów fabularnych jest niezwykle cenny, ponieważ umożliwia całemu zespołowi debatę i zrozumienie zadania. Osobiście uważam, że jest to wciąż znacznie lepsze podejście niż próba oszacowania godzin.

Alternatywne podejścia

Używamy szacunków, aby stworzyć poczucie przewidywalności. Chociaż oszacowanie jest trudne i niewiarygodne, istnieją inne sposoby na zapewnienie przewidywalności.

Przewidywalność może wynikać z regularnego rytmu dostarczania — innymi słowy, regularnie dostarczamy coś do produkcji (tj. wdrożenie po każdym dwutygodniowym sprincie). Chociaż nie możemy wiarygodnie przewidzieć, co trafi do produkcji, możemy niemal zagwarantować, że coś zostanie wdrożone co dwa tygodnie. Ponieważ definiujemy historie jako jednostki pracy, które dodają rzeczywistą wartość biznesową, oznacza to, że nieustannie dążymy do lepszego stanu.

Podczas gdy praca programistyczna często nie jest podzielna, możemy ją usprawnić, poświęcając więcej siły umysłowej na problem — np. programowanie w parach lub programowanie grupowe. Nie chodzi tu o dzielenie pracy, ale o współpracę nad rozwiązaniem tego samego problemu. Może to przyspieszyć rozwój, ponieważ rzeczywista praca polega na rozwiązywaniu problemów, a nie na pisaniu — dwie głowy są lepsze w rozwiązywaniu problemu.

Kluczem jest przejrzystość — nieoczekiwane niespodzianki są na porządku dziennym, ale jako zespół programistów upewnij się, że interesariusze wiedzą o twoich postępach i napotkanych problemach.

Podziel zadania na małe, szczegółowe jednostki. Małe fragmenty kodu są łatwiejsze do opracowania, łatwiejsze do przetestowania i bardziej przewidywalne ze względu na ich ograniczony zakres.

Jeśli musisz podać oszacowanie, wyjaśnij, jakie są wstępne warunki oszacowania. Na przykład, Twój szacunek trzech dni na wdrożenie funkcji może zakładać, że wymagania się nie zmienią, że nie będzie żadnych konfliktów bibliotek i że wszystkie zewnętrzne interfejsy API będą dostępne przez cały czas. Może to nie być realistyczne, ale wyrażając się jasno, pomagasz także swoim interesariuszom zrozumieć złożoność leżącą u podstaw.

Podsumowując — oszacowanie jest trudne. Potraktuj to jako wskazówkę i cel, ale pamiętaj, że Twoje szacunki mogą być błędne. Zamiast starać się, aby Twoje szacunki były w 100% poprawne, skup się na zrozumieniu zadań, stopniowo wykonuj małe części pracy, często dostarczając wartość i zachowując przejrzystość wobec interesariuszy.

PS Sprawdź także ruch #noestimates .

Zastrzeżenie: Jak zawsze, poglądy wyrażone w tym poście są moimi własnymi.