Zwinne punkty fabularne a godziny: jak lepiej oszacować rozwój oprogramowania

Ogarnięcie umysłu procesami tworzenia oprogramowania może być trudne. Kiedy wpadniesz na pomysł i podejdziesz z nim do programistów, pierwsze dwie rzeczy, o które pytasz, to ile będzie kosztować wdrożenie i ile czasu zajmie budowa . Szacowanie to jeden z pierwszych kroków w rozwoju aplikacji.

W tym artykule porównujemy dwa najpopularniejsze modele estymacji we współczesnym tworzeniu oprogramowania: Agile story points vs hours .

Czytaj dalej, aby dowiedzieć się, jak szacować czas w Agile, poznać istotę obu modeli estymacji, zrozumieć ich różnice i zobaczyć, dlaczego programiści mogą wybrać jeden z nich.

Godziny są dość łatwe do zrozumienia i przez długi czas były podstawowym modelem szacowania w tworzeniu oprogramowania. Godziny, znane również jako roboczogodziny lub roboczogodziny, to liczba godzin, które programista spędza nad projektem.

Czym więc są story pointy i dlaczego się pojawiły, skoro mamy już prosty i bezpośredni model estymacji?

Zawartość:

1. Czym dokładnie są punkty fabularne?
2. Oto jak obliczane są punkty fabularne w Agile
3. Zalety szacowania w punktach fabularnych
4. Wady szacowania w punktach fabularnych
5. Zalety szacowania w godzinach
6. Wady szacowania w godzinach
7. Czy potrafisz zamienić punkty fabularne na godziny?
8. Punkty historii a godziny: co wybrać do tworzenia oprogramowania?

Czym dokładnie są punkty fabularne?

Story Points to względny model estymacji natywny dla Agile i Scrum. Szacują wysiłek włożony w zbudowanie produktu , odnosząc się do trzech aspektów rozwoju:

• ilość pracy, jakiej wymaga produkt

• złożoność cech produktu

• ryzyka i niepewności, które mogą wpłynąć na rozwój

Na samym początku oceny projektu programiści wybierają najmniejszą i najprostszą historyjkę użytkownika, jaką posiada produkt — na przykład historyjkę użytkownika związaną z rejestracją — i ustawiają ją jako jednopunktową historyjkę użytkownika. To jest podstawowa historyjka : historyjka użytkownika, która będzie używana do porównywania złożoności. Wszystkim pozostałym historyjkom użytkownika zostanie przypisana liczba punktów narracyjnych w zależności od stopnia złożoności ich opracowania w porównaniu z narracją podstawową.

Z pozoru wygląda dość prosto, ale kto decyduje o liczbie punktów fabularnych w każdej historii?

Oto jak obliczane są punkty fabularne w Agile

Podobnie jak w przypadku godzin, ludzie, którzy będą pracować nad produktem, zwykle szacują punkty fabularne do rozwoju. Jednak proces szacowania jest nieco inny w przypadku punktów fabularnych.

Aby przypisać punkty narracyjne do historyjki użytkownika, zaangażowanych jest kilku programistów . Powinny być co najmniej dwa, ale firma może poprosić wszystkich swoich programistów o udział w grze w to, co branża nazywa Planning Pokerem . Oto zasady gry:

1. Każdy programista otrzymuje zestaw kart Planning Poker.

2. Deweloperzy wybierają historyjkę użytkownika i omawiają jej złożoność oraz wymagany wysiłek programistyczny.

3. Każdy programista wystawia kartę odpowiadającą liczbie punktów, które przypisałby historii.

4. Jeśli oszacowania punktów kondygnacji są takie same, szacowana liczba punktów jest przypisywana do kondygnacji.

5. Jeśli sugerowane punkty fabularne różnią się, twórcy omawiają historyjkę użytkownika, dopóki nie wymyślą liczby punktów zatwierdzonych przez większość.

6. Deweloperzy wybierają kolejną historyjkę użytkownika.

7. Powtórz kroki od 3 do 5.

Kiedy wszystkie nasze działania stały się zdalne, proces ten został zmodyfikowany. Zamiast kartek i spotkań, punkty fabularne są ustalane w dyskusjach online, podczas spotkań Zoom lub na komunikatorach.

Wygląda to mniej więcej tak:

Nie oznacza to oczywiście, że wszyscy deweloperzy zaangażowani w szacowanie punktów fabularnych będą pracować nad projektem. Ale kluczową zaletą systemu punktów fabularnych jest to, że tworzy mniej lub bardziej uniwersalną strukturę, której można używać nie tylko w danym projekcie, ale także w przyszłych projektach o podobnych funkcjach.

Istnieją dwie często używane opcje szacowania punktów fabularnych. Możesz przypisać punkty:

• używając dowolnych liczb całkowitych (1, 2, 3… 13,14,15 itd.)

• za pomocą liczb w ciągu Fibonacciego (1, 2, 3, 5, 8, 13… 55, 89, 144, itd.)

Ciąg Fibonacciego jest wygodniejszą opcją do szacowania rozwoju, ponieważ pozostawia pewien margines na aproksymację. Model porządku liczbowego jest nieco zbyt precyzyjny, aby można było wygodnie dokonywać porównań.

Podczas opracowywania i między projektami, jeśli historyjka użytkownika okaże się bardziej lub mniej złożona niż pierwotnie szacowano, przypisane punkty narracji mogą zostać zmienione.

Zalety szacowania w punktach fabularnych

Jeśli proces przydzielania punktów fabularnych wydaje się nieco skomplikowany, nie daj się zniechęcić. Planowanie wydajności za pomocą punktów fabularnych ma swoje zalety.

1. Punkty fabularne są niezależne od deweloperów

Punkty fabularne za każdą historię są przydzielane przez kilku programistów w trakcie negocjacji , a powodem tego jest to, że liczba ta jest przypisana nie tylko do jednego konkretnego produktu i jednego konkretnego programisty, ale „średnio”. Dlaczego to dobrze?

Rzeczy się zdarzają. Czasami programista twojego projektu może opuścić twój projekt i zostać zastąpiony. Może zachorują, zdecydują się na urlop rodzicielski lub urlop naukowy, albo po prostu odejdą z firmy. Może okażą się niewykwalifikowani lub zbyt wykwalifikowani do projektu.

Po ich wymianie nowy programista może mieć inną szybkość pracy , co spowoduje ponowne oszacowanie godzin pracy niezbędnych do utworzenia produktu.

Punkty fabularne minimalizują ten problem . Przydzielone przez kilku różnych programistów zapewniają ogólny wgląd w to, jak złożona jest konkretna historyjka użytkownika. Punkty fabularne działają dla wszystkich programistów w danej firmie. (Proszę jednak pamiętać, że szacunki dotyczące historyjek nie będą poprawne dla różnych firm.)

2. Story Points ułatwiają ponowne obliczenie czasu rozwoju

W szacowaniu czasu Agile z punktami fabularnymi zespoły używają terminu prędkość, aby odnieść się do liczby punktów fabularnych uwolnionych w jednym sprincie.

Drużyny stale monitorują swoją prędkość i na początku jest ona dość zmienna. Zespół może wydać elementy warte pięć punktów fabularnych w jednym tygodniu i dwadzieścia punktów fabularnych w następnym. Ale to dopiero początek. W miarę postępu projektu wykres prędkości będzie się wyrównywał .

Z godzinami, jeśli członek zespołu się zmieni, każde zadanie, w które jest zaangażowany, będzie musiało zostać ponownie oszacowane, aby dostosować terminy. W przypadku punktów fabularnych jest to niepotrzebne — zespół może dostosować termin projektu po następnym sprincie, znając zmianę ogólnej prędkości.

Punkty fabularne oceniają wydajność zespołu jako całość , eliminując potrzebę ponownej oceny według zadania.

3. Punkty fabularne są dobre do monitorowania wyników zespołu

Gdy masz zespoły pracujące nad podobnymi projektami i/lub zadaniami w różnym czasie, prędkość może z łatwością pokazać postęp, jaki poczynił każdy zespół. Czy się poprawiły io ile? Który zespół lub programista zmaga się i może potrzebować dodatkowego szkolenia? Jaka jest krzywa uczenia się? Może inny zespół radzi sobie lepiej?

Velocity to doskonałe narzędzie do oceny wyników zespołu nie tylko na miejscu, ale także w sposób ciągły.

4. Oszacowanie czasu uruchomienia z punktami fabularnymi jest bardziej precyzyjne

Śledząc prędkość, zespół z dużą precyzją wie, ile punktów fabularnych może uwolnić w jednym sprincie. Chociaż obliczenie szybkości działania zespołu zajmującego się tworzeniem aplikacji zajmuje trochę czasu, po obliczeniu szacowaną datę uruchomienia można łatwo przewidzieć .

Co więcej, zmiany członków zespołu, wymagań czy liczby/złożoności funkcji nie powodują wielu problemów z przeszacowaniem.

5. Możesz ponownie wykorzystać story pointy do przyszłych projektów, aby przyspieszyć szacowanie

Nierzadko zdarza się, że firma jest dobrze zorientowana w określonej niszy (lub kilku) i buduje więcej niż jeden produkt o podobnym zestawie funkcji. Po zrealizowaniu choćby jednego projektu szacowanego w story points, programiści mogą odnosić się do tego oszacowania dla nowych projektów . Skróci to czas szacowania.

Jednak ważne jest, aby śledzić prędkość każdego projektu, ponieważ okoliczności mogą się zmienić.

6. Punkty fabularne poprawiają pracę zespołową

Tradycyjnie firmy deweloperskie mają kilka zespołów programistów, z których każdy pracuje nad osobnymi projektami. Przy szacowaniu w godzinach to programista pracujący nad projektem dokonuje oszacowania. Ogólnie rzecz biorąc, jest to dobra rzecz, ponieważ kto wie lepiej, jak długo coś potrwa, niż osoba, która to robi?

Jednak szacowanie złożoności w punktach fabularnych oferuje programistom z tej samej dziedziny możliwość współpracy — coś, co rzadko zdarza się inaczej. Ten rodzaj pracy zespołowej to świetna okazja do wymiany doświadczeń i wzajemnego motywowania się.

Wady szacowania w punktach fabularnych

Zawsze istnieje druga strona sporu, czyli sposób, w jaki rodzą się wspaniałe systemy. Szacowanie oparte na złożoności ma też swoje wady , a każdy zespół musi sam zdecydować, czy przeważa nad zaletami.

1. Story Points powinien przydzielać więcej niż jeden programista

Zaletą modelu story points jest jego obiektywność i wartość dla przyszłych szacunków. Ale aby to było prawdą, oszacowanie musi być wykonane przez więcej niż jednego programistę . W przypadku małych firm z jednym zespołem lub firm, w których jest tylko jeden specjalista w danej dziedzinie (tj. tylko jeden projektant lub programista iOS), story pointy nie przynoszą tak wielu korzyści. Takie małe firmy tradycyjnie wybierają roboczogodziny jako model estymacji.

2. Szacowanie w punktach fabularnych wymaga znacznych zaległości

Aby w pełni wykorzystać potencjał punktów fabularnych, Twój zespół będzie musiał poświęcić sporo czasu . Jeśli pracujesz nad projektem z funkcjami, nad którymi zespół nigdy wcześniej nie pracował (lub nie pracował na pełny etat), pierwsze dwa lub trzy sprinty będą trudne do przewidzenia pod względem wydajności. To prawda, im więcej elementów zaległości mają Twoje zespoły, tym dokładniejsze mogą być ich szacunki ze względu na obfitość danych statystycznych. Ale Story Points nie jest systemem, który jest gotowy do działania od razu.

3. Punkty fabularne są bardziej złożone w przypadku budżetowania

Story Points świetnie nadają się do wyznaczania precyzyjnych terminów i dat uruchomienia, co może mieć znaczenie dla programistów i marketingu klienta. Jednak jeśli chodzi o szacowanie kosztów tworzenia aplikacji, są one mniej wygodne .

Chodzi o to, że programiści spędzają czas nad projektem nie tylko na pisaniu kodu (czy tworzeniu projektów czy testowaniu). Trochę czasu poświęca się na badania, dyskusję — wewnątrz zespołu iz klientem — wprowadzanie zmian itp. Czas poświęcony na szacowanie punktów narracyjnych to również czas poświęcony na projekt, ale nie jest on wliczany do punktów na historię.

Budżetowanie przy szacowaniu w story points jest możliwe, ale zazwyczaj szybciej i łatwiej jest zrównać pieniądze z czasem spędzonym na projekcie.

4. Prędkość jest obliczana na drużynę

Oznacza to, że jeśli zespoły mieszają się między projektami, musisz osobno obliczyć prędkość dla każdej kombinacji programistów. Dlatego oszacowanie dla jednego zespołu niekoniecznie będzie prawdziwe dla innego zespołu, a nawet zmiana jednego członka zespołu może potencjalnie unieważnić wcześniejsze szacunki.

Z drugiej strony możesz użyć szacowania złożoności, aby znaleźć najlepsze kombinacje. Jednak zajmie to trochę czasu.

Zalety szacowania w godzinach

Podczas gdy niektóre zespoły Agile korzystają z punktów fabularnych, wiele z nich musi jeszcze przestawić się z godzin pracy. Są ku temu ważne powody. Omówmy je również.

1. Godziny to znany model!

Innowacja jest świetna, ale wymaga czasu. Zarówno deweloperzy, jak i ich klienci są dobrze zorientowani w szacowaniu roboczogodzin. Dla wielu pomysł brzmi: „jeśli nie jest zepsuty, nie naprawiaj tego”. Dopóki system oferuje wykonalne szacunki, po co przechodzić na coś innego?

Różnica w precyzji oszacowań może nie być wystarczająco duża, aby niektórzy programiści mogli zmienić sposób, w jaki robią rzeczy.

2. Klienci zazwyczaj płacą za godziny

To wymaga niewielkiego opracowania. Dla klientów szacowanie oparte na złożoności może być mylące . Co więcej, jeśli dla klienta budżet jest ważniejszy niż data uruchomienia (co często jest), punkty fabularne nie będą dla niego istotne.

3. Oszacowanie godzinowe może wykonać jeden programista

W przypadku małych zespołów lub freelancerów punkty fabularne są w dużej mierze bezużyteczne, ponieważ wymagają wielu punktów widzenia. Bez żadnego odniesienia szacowanie w punktach fabularnych jest niepotrzebnym kłopotem.

Z drugiej strony godziny dają deweloperowi pracującemu nad projektem możliwość samodzielnego dość precyzyjnego oszacowania .

To samo dotyczy szybkości zespołu. Gdy zespoły zmieniają się za każdym razem, jak to ma miejsce w przypadku freelancerów lub częściowego outsourcingu, szybkość monitorowania nie ma większego sensu. Lepszym wyborem jest tutaj estymacja w oparciu o godziny.

Wady szacowania w godzinach

Oto powody, dla których zespoły mogą zdecydować się na zaprzestanie używania godzin jako modelu szacowania.

1. Ponoszenie wyłącznej odpowiedzialności za oszacowanie to duża presja

Z jednej strony oszacowanie własnych wymagań czasowych może być łatwiejsze, ponieważ polegasz tylko na sobie.

Z drugiej strony, jeśli nie dotrzymasz swoich szacunków, jest to ogromny cios. Tym bardziej, jeśli zespół oczekujący na rozpoczęcie swoich zadań jest zależny od tego, czy wykonasz swoje.

Co więcej, stres spowodowany presją dostarczenia tego, co obiecałeś, może zakłócić dobrze wykonywane zadanie.

2. Oszacowanie jednego dewelopera jest zawsze mniej dokładne niż zespołu

Szacunki indywidualne są subiektywne i powiązane z emocjonalnymi i psychologicznymi okolicznościami estymatora.

Niektórzy programiści mają tendencję do przeceniania samych siebie i wyznaczania ram czasowych, które później mają trudności z utrzymaniem. To nie tylko zakłóca rozwój (i nakłada dodatkowe koszty na zespół, jeśli są kary), ale także powoduje stres i wypalenie programistów .

Inni nie doceniają własnych umiejętności , przedłużając rozwój bardziej, niż jest to obiektywnie potrzebne. Niepewność i nawyk nadmiernego przemyślenia, sprawdzania i ponownego sprawdzania pracy często prowadzą do tego, że terminy opracowywania są ustawiane na późniejsze daty — a zadania rzadko są kończone przed terminami . Wkład zespołu pozwala na bardziej obiektywną ocenę.

3. Im większe zadanie, tym trudniej je oszacować w godzinach

Koreluje to również z sytuacjami niezwiązanymi z rozwojem. Łatwo powiedzieć, ile czasu zajmie przeczytanie trzystronicowej broszury uniwersyteckiej, ale trudniej oszacować, ile czasu zajmie ukończenie Wojny i pokoju .

To samo dotyczy rozwoju. Małe zadania są łatwe do oszacowania dla programistów z pewnym doświadczeniem. Jednak im większe zadanie, tym więcej rzeczy — dziejących się zarówno wewnątrz projektu, jak i poza nim — może wpłynąć na rozwój. Szacunki godzinowe nie oferują marży, jaką mają punkty, co sprawia, że ​​szacunki są bardziej zgrubne.

4. Mała elastyczność

Szacowanie godzinowe jest oparte na programistach. Jeśli jeden członek zespołu pracujący nad produktem zmieni się w trakcie projektu, zespół będzie musiał ponownie obliczyć każdą historyjkę użytkownika, której dotyczy problem, która jest nadal opracowywana lub zaplanowana na przyszłe sprinty. To może być bardzo pracochłonne, w zależności od etapu, na którym znajduje się projekt i różnicy w umiejętnościach oryginalnego i nowego dewelopera. Szacowanie czasu w oparciu o godziny jest dość sztywne.

Czy potrafisz zamienić punkty fabularne na godziny?

Klienci mogą poprosić zespół o oszacowanie w punktach fabularnych, aby przekonwertować mapowanie punktów fabularnych Agile na godziny . Większość ludzi, którzy nie są zaznajomieni z najnowszymi trendami rozwoju oprogramowania, nie będzie wiedziała, co myśleć o punktach fabularnych.

Jednak, gdy klient pyta, ile godzin wynosi jeden punkt fabularny, nie można jednoznacznie odpowiedzieć. Jednym z kluczowych elementów szacowania opartego na złożoności jest wysiłek włożony w ukończenie historii. Ale wysiłek nie przekłada się bezpośrednio na poświęcony czas . Godziny odnoszą się do niepewności w bardziej niejasny sposób niż punkty fabularne.

Im bardziej złożone zadanie, tym więcej niepewności i ryzyka. Przeliczanie punktów narracyjnych na godziny w prosty sposób i poleganie tylko na prędkości nie uwzględnia wielu takich zagrożeń, ponieważ szacowanie godzinowe jest bardziej przybliżone niż punkty narracyjne, jeśli chodzi o ryzyko i niepewności.

Do pewnego stopnia użycie sekwencji Fibonacciego do przypisywania punktów fabularnych będzie uwzględniać niepewność w czasie rozwoju, ale nie pozwala dokładnie na bezpośrednią konwersję.

Oto przykład.

Ukończenie 1-piętrowej historii punktowej (podstawowej) zajmuje, powiedzmy, dwie godziny.

13-piętrowa historia może zająć 26 godzin w najlepszym przypadku — jeśli nic nie pójdzie nie tak lub nic nie stanie na przeszkodzie. Na przykład, jeśli używany interfejs API pasuje bezproblemowo, punkt końcowy do punktu końcowego. Ale jeśli tak się nie stanie, historia może wymagać od, powiedzmy, 30 do 50 godzin – w zależności od liczby niedopasowań. Nikt nie może z góry powiedzieć, jak to pójdzie, jeśli programista nie pracował jeszcze z danym API.

Tak więc, tłumacząc punkty historii na godziny, musi istnieć mnożnik dla wykładniczego wzrostu, aby poradzić sobie z niepewnością. A ten mnożnik będzie się różnić w zależności od zespołu.

Punkty historii a godziny: co wybrać do tworzenia oprogramowania?

Jak widać, zarówno punkty fabularne, jak i godziny są prawidłowymi wyborami dla dewelopera do oszacowania projektów.

Ogólnie rzecz biorąc, powiedzielibyśmy, że więcej firm produktowych wybiera punkty fabularne, podczas gdy outsourcerzy mają tendencję do skłaniania się ku godzinom.

Firmy pracujące z modelem stałej ceny zwykle wybierają estymację w oparciu o godziny. Zespoły, które preferują Scrum, często wybierają punkty fabularne, ponieważ dosłownie narodziły się ze Scrum i są rodzime dla tej metodologii.
W naszym wieloletnim doświadczeniu doszliśmy do tego w ten sposób:

• Jeśli dokładne oszacowanie daty premiery jest ważniejsze niż dopasowanie budżetu, wybierz punkty fabularne.

• Jeśli budżet jest ważniejszy niż dokładna data uruchomienia, rozważ godziny.

Lub, co najlepsze, połącz oba.

Punkty fabularne są bardzo wygodne dla zespołów programistycznych pracujących nad długimi projektami, w których szybkość monitorowania ma znaczenie.

Godziny są ważne dla klientów, którzy martwią się, że zagarną swój budżet. Również godziny mają większy sens w przypadku projektów krótkoterminowych.

System oparty na złożoności jest wciąż dość młody, podobnie jak sam Scrum, i wciąż się rozwija. Połączenie obu modeli estymacji i wypracowania systemu, aby szybko zmienić każdy punkt historyczny na godziny, zapewnia korzyści obu modeli, jednocześnie minimalizując wady.