Zwinne techniki szacowania: prawdziwe oszacowanie w zwinnym projekcie

agile estimation techniques

Prawdziwe szacunki w zwinnym projekcie: kompletny wgląd z przykładami szacowania zwinnego

Bardzo ważne jest, aby oszacować Agile na różnych poziomach. Ma to na celu właściwe planowanie, zarządzanie i oszacowanie całkowitego wysiłku, który zamierzamy przeznaczyć na wdrożenie, przetestowanie i dostarczenie Klientom pożądanego produktu w określonym czasie w określonych terminach.

W przypadku braku oszacowań w projekcie zwinnym może nie być odpowiedniego planowania i zarządzania, które może zakończyć się dostarczeniem niepożądanego produktu, a tym samym niezadowoleniem klienta.

Oszacowania punktów fabularnych są wykonywane w projektach zwinnych przy użyciu różnych technik, takich jak Planning Poker, Bucket System, Affinity Mapping itp. W tym celu używane są różne szablony szacowania na różnych poziomach, takie jak szablon planu projektu Agile, szablon planu wydania, szablon planu sprintu, szablon mapy drogowej , Szablon historii użytkownika itp.

Czego się nauczysz:

• Wprowadzenie
• Szacowanie punktów fabularnych w Agile
• Zalecane narzędzie
• Różne techniki estymacji zwinnej
  • # 1) Poker planujący
  • # 2) Rozmiary koszulek
  • # 3) Głosowanie kropkami
  • # 4) System wiadra
  • # 5) Duży / niepewny / mały
  • # 6) Mapowanie podobieństwa
  • # 7) Sposób zamawiania
• Obliczanie budżetu w Agile
• Szablony szacowania w projekcie Agile Development
  • 1) Szablon planu projektu Agile:
  • 2) Szablon planu zwinnego wydania:
  • 3) Szablon Backlogu Produktu Agile:
  • 4) Szablon Backlogu Agile Sprint:
  • 5) Szablon planu testów Agile:
  • 6) Szablon historii użytkownika Agile:
  • 7) Szablon mapy drogowej Agile:
• Etapy szacowania w zwinnym projekcie
  • 1) Szacunek na poziomie propozycji lub projektu
  • # 2) Szacowanie poziomu wydania
  • # 3) Szacowanie poziomu sprintu
• Wniosek
• rekomendowane lektury

Wprowadzenie

Poniżej podano 3 główne poziomy szacowania zwinnego.

# 1) Poziom projektu lub propozycji to ten, który korzysta z szybkiej analizy punktów funkcyjnych w początkowych fazach rozwoju projektu.

# 2) Poziom wydania obejmuje przypisywanie punktów historii do historyjek użytkownika, które mogą pomóc w zdefiniowaniu kolejności historyjek użytkownika na podstawie priorytetu, a także mogą pomóc w podjęciu decyzji, które historie można pobrać w bieżącej wersji, a które można wykonać później.

# 3) Poziom sprintu to ten, w którym historyjki użytkownika są podzielone na zadania, a szacowane godziny są przypisane do zadań zgodnie z ich złożonością. Tutaj również określamy osobę odpowiedzialną za zadanie wraz ze statusem zadań.

Informacje te można później wykorzystać do obliczenia budżetu projektu Agile. Obliczanie budżetu jest kluczowe, aby upewnić się, że projekt nie przekroczy budżetu z powodu zadań przed i po iteracji lub z innych powodów.

Szacowanie punktów fabularnych w Agile

Oszacowania punktów fabularnych to analiza porównawcza mająca na celu zgrubne oszacowanie pozycji rejestru produktu ze względną wielkością. Członkowie zespołu oceniającego historyjki użytkowników to: Właściciel Produktu, Scrum Master, Programiści, Testerzy i Posiadacze Stake'ów.

Poniżej podano kilka kroków prowadzących do ostatecznej decyzji o względnej wielkości:

# 1) Przeanalizuj wszystkie historie użytkowników i zidentyfikuj historię bazową lub referencyjną. Jest to ważne przy określaniu rozmiaru względnego. Ta historia może być wybrana z aktualnego backlogu produktu lub z tej, którą zrobiliśmy wcześniej. Ta historia powinna zostać wybrana jako historia odniesienia za zgodą wszystkich członków.

#dwa) Wybierz inną historię z aktualnego Backlogu Produktu, a członkowie zespołu mogą swobodnie omawiać wszelkie pytania lub wątpliwości z Właścicielem Produktu, jednocześnie rozumiejąc wymagania historii. Właściciel produktu jest odpowiedzialny za wyjaśnienie wszystkich swoich pytań i wątpliwości.

# 3) Zrób listę rzeczy, na które należy zwrócić uwagę podczas wdrażania historii użytkownika. Można to zrobić, pisząc notatki w sekcji notatek narzędzia lub dodając wypunktowania na karcie opowieści. Robi to głównie Scrum Master.

# 4) Poniżej podano kilka często zadawanych przez uczestników pytań:

• Projekt: Jaka jest wcześniejsza i obowiązkowa wiedza, którą powinniśmy mieć przed przystąpieniem do pracy?
• Kodowanie: Ile kodowania jest wymagane do wdrożenia tej historii użytkownika. Czy wcześniej spotkaliśmy się z podobną historią użytkownika?
• Testów jednostkowych: Czy do wykonania testów jednostkowych dla tej historyjki użytkownika wymagane są pozorowane obiekty?
• Testy integracyjne: Czy ta historia wpływa na inne funkcjonalności tego samego modułu, a także na inne moduły?
• Testy akceptacyjne: Jakie punkty należy zadbać, aby dostarczyć pożądany przez Klientów produkt?
• Ekspertyza: Czy któryś z uczestników zrobił już wcześniej podobną historię i jest w niej ekspertem?

# 5) Dokonaj względnej wielkości dla wybranego wątku. Jeśli wymaga takiej samej ilości pracy i wysiłku, przypisz mu to samo nie. punktów przypisanych do kondygnacji odniesienia. Jeśli wymaga to więcej wysiłku, przypisz mu większą wartość. Jeśli wymaga mniej wysiłku, przypisz mu niższą wartość.

# 6) Osiągnij konsensus ze wszystkimi uczestnikami, aby sfinalizować względny rozmiar wybranej historyjki użytkownika zgodnie z definicją ukończenia.

różnica między niejawnym i jawnym oczekiwaniem w selenie

# 7) Po wykonaniu względnej wielkości wszystkich elementów rejestru produktu, upewnij się, że wszystkie historyjki użytkowników mają ten sam numer. przypisanych im punktów wymagają tego samego wysiłku i rozmiaru, aby były spójne.

Zalecane narzędzie

# 1) Agile Poker

Agile Poker to dobrze znana aplikacja dla Jira do szybkiego i wygodnego planowania i szacowania zarówno dla zespołów zdalnych, jak i kolokowanych.

Rozpoczęcie pracy z Agile Poker jest proste i łatwe, ponieważ zostało zainspirowane trzema standardowymi metodologiami szacowania: Planning Poker®, Wideband Delphi i Magic Estimation (znane również jako Silent Grouping, Affinity Estimation, Swimlanes Sizing lub Relative Estimations).

Różne techniki estymacji zwinnej

Istnieje wiele technik przeprowadzania oszacowań w projekcie zwinnym. Główne zasady dokonywania szacunków to Estymacja Względna, dyskusje w celu uzyskania większej ilości informacji o pozycjach, których oszacowania trzeba wykonać oraz zapewnienie zaangażowania całego zespołu w powierzone im zadania.

Istnieje głównie 7 technik szacowania projektów zwinnych:

# 1) Poker planujący

• W tej technice szacowania wszyscy ludzie, którzy mają dokonać oszacowania, siedzą w okrągłym kółku podczas sesji Planning Poker.
• Każdy kalkulator ma zestaw kart do pokera planowania o wartościach: 0,1,2,3,5,8,13,20,40 i 100. Te wartości reprezentują punkty fabularne lub miary, w których szacuje zespół.
• Na początku sesji właściciel produktu lub klient czyta historię użytkownika, opisując wszystkie jej funkcje i wymagania.
• Po odczytaniu historii odbywają się dyskusje między estymatorami oraz z właścicielem produktu / klientem. Estymatorzy mogą zadawać pytania lub wyjaśniać swoje wątpliwości właścicielowi produktu.
• Po dyskusjach wszyscy estymatorzy proszeni są o wybranie jednej karty w celu oszacowania historyjki użytkownika. Jeśli wszystkie estymatory dają tę samą wartość, staje się to ostatecznym oszacowaniem.
• Jeśli wartości są różne, estymatorzy podający najwyższe i najniższe wartości wyjaśniają swoje opinie i dlaczego wybrali tę wartość, aż do osiągnięcia konsensusu.
• Dobra technika, gdy mała nie. Liczba pozycji ma zostać oszacowana w małym zespole.

=> Dalsze szczegółowe czytanie Planowanie techniki szacowania pokera .

# 2) Rozmiary koszulek

• Podobnie jak w przypadku koszulek widzimy rozmiary: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). Podobnie postępujemy w tym przypadku - pozycje są szacowane w rozmiarach koszulek.
• Jest to doskonała technika pozwalająca na przybliżone oszacowanie dużych zaległości pozycji.
• Przydatne, gdy trzeba dokonać szybkiej i zgrubnej oceny. Później te rozmiary można przekształcić w nie zgodnie z wymaganiami.
• Względna wielkość (przeważnie Średnia) jest ustalana po wzajemnej dyskusji i uzgodnieniu członków zespołu lub estymatorów. Następnie elementy nie są przypisywane zgodnie z rozmiarem względnym przypisanym do rozmiaru Średniego.
• Niekorzyść: To, co komuś wydaje się L, może wydawać się komuś XL.
• Wszystkie estymatory przypisują pozycjom własny rozmiar. Po dyskusjach i rozwiązaniu problemu rozbieżności osiągnięto konsensus co do ostatecznego oszacowania.

# 3) Głosowanie kropkami

• Jest to w zasadzie metoda rankingowa służąca do decydowania o kolejności w Rejestrze Produktu od artykułów o najwyższym priorytecie do artykułów o najniższym priorytecie. Ma to na celu wybranie najważniejszych historii, które należy kontynuować.
• Na początek umieść wszystkie historyjki użytkowników wraz z ich opisami na ścianie lub tablicy przy użyciu żółtych klejnotów lub w sposób wyróżniający ich za otrzymanie głosów.
• Wszyscy interesariusze otrzymują od 4 do 5 kropek (głównie w formie naklejek, długopisów lub markerów można również użyć do wykonania kropki).
• Wszyscy interesariusze proszeni są o oddanie głosów na preferowane przez nich historyjki użytkowników.
• Właściciel produktu zamawia pozycje z rejestru produktu od najbardziej preferowanych (taki, w którym nie ma większości kropek) do najmniej preferowanego (taki, w którym jest najmniej punktów).
• Może tak być w przypadku, gdy niewielu interesariuszy jest niezadowolonych z podjętej decyzji. W tym przypadku historyjki użytkownika po dyskusjach są podzielone na 3 grupy: o wysokim priorytecie, niskim priorytecie i średnim priorytecie. Historie użytkowników o wysokim priorytecie są umieszczane na ścianie w celu uzyskania głosów. Odbywa się to do momentu osiągnięcia ostatecznego zamówienia za zgodą wszystkich zainteresowanych stron.

# 4) System wiadra

• Jest to dobra technika, gdy duże nie. pozycji należy oszacować w dużej liczbie. uczestników. Jest szybszy i bardziej rozsądny niż Poker Planning.
• Tworzone są różne segmenty z wartościami: 0,1,2,3,4,5,8,13,20,30,50,100, 200. W razie potrzeby można to rozszerzyć. Te kosze to nic innego jak karty reprezentujące wartości ułożone sekwencyjnie na stole.
• Historie należy umieścić w tych miejscach, w których oceniający uzna je za odpowiednie. Wszystkie szacowane pozycje są zapisane na kartach.
• Wybierz losowo przedmiot i włóż go do wiadra 8. Służy on wyłącznie jako odniesienie. Wybierz losowo inną historię, omów z grupą wszystkie jej cechy i wymagania i po uzyskaniu zgody umieść ją w odpowiednim wiadrze. Podobnie trzeci przedmiot jest pobierany i umieszczany w odpowiednim wiadrze.
• Kolejność segmentów można również zmienić, na wypadek gdyby grupa uznała, że ​​pierwszy wybrany element powinien należeć do segmentu 1 zamiast segmentu 8.
• Stosuje się podejście Dziel i rządź. Wszystkie pozostałe pozycje są rozdzielane między wszystkich uczestników. Wszyscy uczestnicy mogą umieścić przedmiot bez zgody innych uczestników.
• Przedmioty powinny być umieszczone prawidłowo. Nie można umieścić żadnego przedmiotu między pojemnikami.
• Jeśli uczestnik nie rozumie pozycji rejestru produktu lub jeśli pozostali uczestnicy zakończyli umieszczanie swoich historyjek użytkownika, wówczas historie użytkownika mogą zostać przeniesione do innych uczestników.
• W końcu wszyscy uczestnicy przeprowadzają kontrolę poczytalności. Jeśli jakikolwiek uczestnik znajdzie niewłaściwe wiadro przypisane do przedmiotu, może powiadomić o tym innych uczestników i porozmawiać z nimi. Odbywa się to do momentu osiągnięcia konsensusu dla całego rejestru produktu.
• Facylitator powinien sprawdzić, czy nikt nie przenosi przedmiotów, chyba że zostanie przeprowadzona kontrola poczytalności.
• Odbywa się to również w celu osiągnięcia priorytetu pozycji w rejestrze produktu.

# 5) Duży / niepewny / mały

• Jest to wersja przybliżona i stanowi uproszczenie systemu łyżek, w którym są tylko trzy rozmiary: duży, mały i niepewny.
• Uczestnicy lub estymatorzy proszeni są o umieszczenie pozycji w jednej z kategorii. Najpierw wybiera się proste historyjki użytkownika i umieszcza je w dużych i małych kategoriach. Następnie podejmowane są złożone elementy.
• Jest to dobra technika, gdy w Backlogu Produktu znajdują się porównywalne pozycje.

# 6) Mapowanie podobieństwa

• Dobra technika, gdy zespół jest mały i nie ma. zaległych pozycji jest mniej.
• Pierwszym krokiem jest cichy względny dobór: Na ścianie karta z napisem „Mniejszy” jest umieszczana po lewej stronie, a karta z napisem „Większa” po prawej stronie. Właściciel produktu zapewnia podzbiór pozycji wszystkim uczestnikom. Wszyscy uczestnicy proszeni są o dopasowanie rozmiaru każdego elementu do rozmiarów na kartach na ścianie, biorąc pod uwagę wysiłek wymagany do ich wykonania. Jest to samodzielna decyzja uczestnika bez dyskusji z pozostałymi członkami zespołu. Właściciel produktu lub interesariusz jest obecny w celu wyjaśnienia wątpliwości uczestnika. Elementy Backlogu Produktu, które są zbyt niejednoznaczne, aby członkowie zespołu mogli je zrozumieć do oszacowania, są umieszczane osobno. Zajmuje to 5-20 minut.
• Edycja ściany: Członkowie zespołu mogą zmieniać położenie przedmiotów na ścianie. Mogą omawiać wymagania projektowe i wdrożeniowe z innymi członkami zespołu. Ta czynność może zostać zakończona, gdy na ścianie dzieje się niewielka zmiana. Zajmuje to około 20-60 minut .
• Umieszczanie przedmiotów we właściwych lokalizacjach: Po dyskusjach zespół umieszcza pozycje z rejestru produktu na odpowiednich i odpowiednich pozycjach. Możemy tutaj użyć rozmiaru koszulki, serii Fibonacciego itp., Aby względnie oszacować rozmiar przedmiotów.
• Wyzwanie właściciela produktu: Właściciel produktu może zauważyć pewne rozbieżności w szacunkach wykonanych przez zespół i będzie musiał omówić z zespołem więcej funkcji lub wymagań dotyczących pozycji. Po dyskusjach dokonuje się ostatecznych szacunków.
• Eksportuj do narzędzia zarządzania backlogiem projektu: Aby upewnić się, że informacje o ostatecznych szacunkach nie zostaną utracone, wyeksportuj je do narzędzia do zarządzania backlogami produktów.

# 7) Sposób zamawiania

• Dobra technika, gdy duże nie. przedmiotów i małe nie. ludzi tam jest.
• Podaje dokładne względne rozmiary pozycji rejestru produktu.
• Przygotowywana jest skala od niskiej do wysokiej. Wszystkie przedmioty są na nim umieszczane losowo. Każdy uczestnik jest proszony o jednorazowe przesunięcie dowolnej pozycji na wadze. Ruch może być jeden w górę, jeden w dół lub przekazać kolej innemu członkowi.
• Trwa to tak długo, aż wszyscy uczestnicy będą zadowoleni i nie chcą przesuwać żadnego elementu na wadze.
• Daje to również priorytet kolejności elementów Backlogu Produktu.

Obliczanie budżetu w Agile

Obliczanie budżetów odgrywa ważną rolę w projektach zwinnych. Ma to na celu upewnienie się, jaki jest faktycznie dostarczony budżet, jaki budżet jest wymagany i w jaki sposób podzielimy budżet na różne pozycje z rejestru produktu.

Wykorzystuje dane zebrane z poprzednich projektów i wykorzystuje formułę matematyczną, aby uzyskać szacunkowy budżet dla bieżącego projektu.

Poniżej znajduje się sekwencja kroków, aby obliczyć budżet w projekcie Agile:

# 1) Wypisz wszystkie wymagania projektu i wykonaj szacunki dla nich za pomocą Planning Poker, Bucket System, Fibonacci series itp. Wszyscy członkowie zespołu powinni zgodzić się na oszacowania dokonane dla wymienionych wymagań po dokładnej analizie i zrozumieniu historyjek użytkownika. Szacunki są wykonywane na podstawie funkcji, które mają zostać zaimplementowane w historyjce użytkownika.

#dwa) Określ czas trwania iteracji zwanych Sprintami i przypisane do nich elementy rejestru produktu. Zwykle trwa od 2 do 3 tygodni. Historie użytkownika są wybierane w kolejności, zaczynając od historyjki użytkownika o maksymalnym priorytecie, przechodząc do historyjki o niższym priorytecie, a na końcu historyjki użytkownika o najmniejszym priorytecie. Pomaga to w podjęciu decyzji, które historyjki użytkownika należy odebrać w pierwszym Sprincie, a które później.

# 3) Przygotuj spalony wykres, aby dać jasny obraz tego, ile pracy pozostało do wykonania w porównaniu z tym, ile czasu pozostało na wdrożenie. Zasadniczo daje to tempo postępu zwinnego zespołu. Daje jasny obraz tego, jak zachowuje się zespół i jak ma się zachowywać.

Postęp zespołu jest mierzony za pomocą ukończonych zadań, pozostałego wysiłku, idealnego wypalenia i pozostałych zadań, jak pokazano poniżej:

# 4) Dodaj dodatkowe koszty, takie jak zakup sprzętu, narzędzia, wsparcie infrastruktury, uzyskanie licencji na używane narzędzia programowe, narzędzia do zarządzania projektami, instalacja oprogramowania antywirusowego i aktualizacje.

# 5) Dodaj budżety przed i po iteracji. Wszyscy członkowie zwinni powinni być wielofunkcyjni, ale istnieją ograniczenia. Wszystko, co zrobił członek zespołu poza jego specjalistyczną wiedzą, jest uważane za pracę przed iteracją lub pracę po iteracji. Te prace przed i po iteracji wymagają dodatkowego budżetu na realizację.

# 6) Miej oko na ukryte ryzyko. Ryzyka w projekcie Agile obejmują: ryzyko przekroczenia budżetu projektu, nieobecność członków zespołu, członkowie nie mają jasnej lub pełnej wiedzy, członkowie nie mają wymaganych umiejętności, przekroczono terminy itp.

Szablony szacowania w projekcie Agile Development

Istnieje wiele szablonów szacunków, które są przygotowywane na różnych poziomach w projekcie deweloperskim Agile. Jedynym celem jest jasne określenie szacunków wymaganych do realizacji wymagania lub pozycji i śledzenie jego postępów.

Główne szablony są wymienione poniżej:

1) Szablon planu projektu Agile:

Daje ogólny obraz tego, ile czasu potrzeba na dostarczenie cech wymagań i jaki jest ich status. Wspomina również osobę odpowiedzialną za określone zadanie.

(Uwaga: kliknij dowolny obraz, aby wyświetlić powiększony widok)

2) Szablon planu zwinnego wydania:

Podaje szczegóły wydania zadań odpowiadających wymaganiom, wraz z ich statusem i Sprintem, w którym mają zostać wykonane.

3) Szablon Backlogu Produktu Agile:

Opisuje kompletny backlog produktu zdefiniowany dla projektu. Podaje szczegóły zadań Sprintów wraz ze statusem, priorytetem, punktami fabularnymi i czy są one przypisane do Sprintu, czy są jakieś dodatkowe zadania, takie jak defekty itp.

4) Szablon Backlogu Agile Sprint:

Zawiera opis historyjek użytkownika, o których mowa w liście zadań danego Sprintu. Podaje całkowitą liczbę punktów opowieści przypisanych do historyjki użytkownika oraz sposób, w jaki są one podzielone na różne zadania. Podaje również status odpowiednich zadań i jaka jest codzienna praca wykonywana w ramach odpowiednich zadań.

5) Szablon planu testów Agile:

Rozbija cały scenariusz testowy na podscenariusze. Zawiera szczegółowe informacje na temat scenariuszy podrzędnych, takich jak data wdrożenia, oczekiwany wynik, rzeczywisty wynik, stan itp.

Wymienia również nazwę projektu, kompatybilną przeglądarkę, wersję testowanej aplikacji, identyfikator przypadku testowego dla wybranego scenariusza, napisane przez, testowane przez, opis itp.

6) Szablon historii użytkownika Agile:

Zawiera szczegółowe informacje dotyczące analizy historyjki użytkownika, takie jak: Jakie role są wymagane do przetestowania określonej funkcjonalności, jakie są wymagania wstępne (konfiguracja środowiska i włączone łącza) i jaki jest oczekiwany wynik?

7) Szablon mapy drogowej Agile:

Daje kierunek projektowi w firmie, w perspektywie krótko- i długoterminowej. Pomaga w ustalaniu oczekiwań w firmie. I przegląd dokąd zmierza projekt.

Etapy szacowania w zwinnym projekcie

W projekcie zwinnym szacunki są wykonywane na 3 poziomach, jak wspomniano poniżej:

jaka jest maska ​​podsieci dla adresu IP klasy b?

• Poziom projektu / oferty: Całkowity rozmiar funkcjonalny całej aplikacji jest szacowany przy użyciu metody Quick Function Point Analysis (QFPA), gdy dostępne są tylko wymagania wysokiego poziomu.
• Poziom wydania: Do historyjek użytkownika przypisywane są punkty fabularne, które pomagają w określeniu nie. wydań zaplanowanych w ramach projektu i nie. historyjek użytkowników, które mają zostać pobrane w wersji i sprincie.
• Poziom sprintu: Szacowane godziny są przypisane do zadań historyjek użytkownika w ramach sprintu. Ma to na celu zapewnienie zaangażowania programistów w dostarczanie historii użytkownika w sprincie.

S1, S2, S3, S4, S5, S6 to sprinty.

1) Szacunek na poziomie propozycji lub projektu

Jest to szacunek na bardzo wysokim poziomie dla projektu. Skupia się na całkowitej liczbie wymagań w elemencie Backlog Produktu. Punkty funkcyjne służą do oszacowania rozmiaru oprogramowania / projektu przed udokumentowaniem szczegółowego opisu wymagań funkcjonalnych.

Punkty funkcyjne to powszechnie przyjęty sposób obliczania rozmiaru oprogramowania. Koncentruje się na funkcjach występujących w projektach oprogramowania. Punkt funkcyjny to metryka, która przekształca wymagania lub historyjki użytkownika na liczbę.

Na początkowych etapach projektu zaleca się przyjęcie metody Quick Function Point Analysis (QFPA).

Metoda szybkiej analizy punktów funkcyjnych to unikalne podejście do szacowania FP, gdy dostępne są tylko wymagania wysokiego poziomu.

Jak obliczyć całkowity rozmiar funkcjonalny?

• Zrozum wszystkie funkcje aplikacji z pomocą ekspertów dziedzinowych.
• Zidentyfikuj i wypisz wszystkie możliwe funkcjonalności aplikacji.
• Funkcje przechowywania danych są podzielone na wewnętrzne pliki logiczne (dane przechowywane wewnętrznie w aplikacji) i pliki interfejsu zewnętrznego (dane używane wyłącznie w celach informacyjnych).
• Funkcje transakcji są podzielone na wejścia zewnętrzne (dane pochodzące ze źródeł zewnętrznych do aplikacji), wyjścia zewnętrzne (dane pochodne są przesyłane z aplikacji na zewnątrz) i zapytania zewnętrzne (dane pobrane z jednego lub większej liczby zewnętrznych wejść i wyjść).
• Oblicz rozmiar FP dla każdej funkcji, obliczając jej średnią złożoność.
• Zsumuj rozmiar FP wszystkich funkcji, aby uzyskać całkowity rozmiar funkcjonalny aplikacji.
• Co najmniej dwie osoby z doświadczeniem w analizie PR powinny samodzielnie obliczać, dopasowywać wyniki i rozwiązywać różnice.

Przykład oszacowania na poziomie projektu:

Poniżej lista wymagań dla projektu, tak jak w Backlogu Produktu:

• Użytkownik powinien mieć możliwość zalogowania się do serwisu podając nazwę użytkownika i hasło.
• Po pomyślnym zalogowaniu, użytkownik powinien zostać przeniesiony na stronę główną ze zdefiniowanymi prawymi i lewymi panelami.
• Użytkownik powinien mieć możliwość wylogowania się z Aplikacji.
• Prawidłowy użytkownik ma możliwość zmiany hasła poprzez podanie aktualnych poświadczeń.

Zespół wykorzystuje oszacowanie Quick FP do oszacowania wielkości projektu.

Poniżej przedstawiono analizę:

• Funkcja przechowywania danych tutaj przechowuje poświadczenia użytkownika do logowania i zmiany hasła.
• Ponieważ poświadczenia są przechowywane w granicach aplikacji, są przechowywane w plikach ILF (wewnętrzne pliki logiczne).
• Funkcje transakcji obejmują:
  • Logowanie użytkownika i wyświetlanie strony głównej.
  • Wylogowanie użytkownika i wyświetlenie ekranu wylogowania.
  • Możliwość zmiany hasła.

Poniżej znajdują się kroki wykonywane w celu oszacowania rozmiaru projektu przy użyciu szybkiej analizy punktów funkcyjnych:

KROK 1: Wypisz wszystkie funkcje danych

UFP (Unadjusted Function Point) jest pobierane z tabeli Caper Jones.

KROK 2: Wypisz wszystkie funkcje transakcji

UFP (Unadjusted Function Point) jest pobierane z tabeli Caper Jones.

KROK 3: Wyznaczanie szacunkowej wielkości projektu w punktach funkcyjnych

UFP = Dane FP + Transakcja FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (Zakładając VFP (współczynnik korekty wartości = 1)

Wydajność = 16 FP / miesiąc (normalny standard)

Wysiłek = PR / produktywność = 22/16 osób miesięcznie = 1,37 osoby miesięcznie

# 2) Szacowanie poziomu wydania

Szacunki poziomu wydania są wykonywane podczas planowania wydania. Jest to kolejna czynność po oszacowaniu poziomu Projektu. Priorytetowe wymagania są pobierane z Backlogu Produktu, który ma postać Historii użytkowników.

Historie użytkowników są szacowane w kategoriach punktów historii podczas planowania wydania, które koncentruje się na szacowaniu rozmiaru oprogramowania, które ma być dostarczone dla tej wersji. W ten sposób planowana jest liczba wydań i całkowita liczba punktów fabularnych w każdym wydaniu.

Punkt fabularny zasadniczo reprezentuje względny wysiłek wymagany do wdrożenia funkcji lub funkcjonalności w porównaniu z innymi funkcjami. Służy głównie do określania rozmiaru elementów rejestru produktu.

Oszacowanie fabuły odbywa się na podstawie:

• Złożoność funkcji do zaimplementowania.
• Doświadczenie i umiejętności techniczne wszystkich członków.

S1, S2, S3, S4, S5 to sprinty.

Kroki przypisywania punktów historii do historyjki użytkownika:

• Wszyscy członkowie zespołu gromadzą się przy stole i przeglądają historie użytkowników obecne w Backlogu Sprintu.
• Podjęto decyzję o znaczeniu jednego punktu fabularnego i odpowiedniego wysiłku.
• Jeden z członków zespołu czyta historyjkę użytkownika, a następnie prosi członków zespołu o przypisanie odpowiednich punktów opowieści.
• Jeśli istnieje znacząca różnica między punktami opowieści przypisanymi przez członków zespołu, wówczas wyjaśniają oni punkty opowieści, które przypisali, osiągając w ten sposób konsensus na końcu.
• Proces powtarza się 3-4 razy, aż nie ma większej różnicy między szacunkami podanymi przez członków zespołu.
• Rozmiar historii pomaga określić, ile historii zostanie zrobionych w ramach sprintu i wydania.

Przykład oszacowania poziomu wydania:

Obejmuje to utworzenie priorytetowej listy Historii użytkowników o nazwie Backlog Produktu. Właściciel Produktu tworzy Rejestr Produktu i zapewnia wartość biznesową dla każdego wymienionego w nim elementu.

Do Szacowania Punktów Historycznych możemy użyć poniższych metod:

• Rozmiar numeryczny: Od 1 do 10
• Rozmiar koszulki: Każde wymaganie jest klasyfikowane jako bardzo małe (XS), małe (S), średnie (M), duże (L), bardzo duże (XL).
• Seria Fibonacciego: Oszacowanie wykonane za pomocą sekwencji Fibonacciego (1,2,3,5,8,13,21,34,….)

Oszacowanie powyższych historyjek użytkowników poprzez ciąg Fibonacciego:

# 3) Szacowanie poziomu sprintu

Szacunki poziomu sprintu są wykonywane podczas planowania sprintu. Elementy rejestru produktu o najwyższym priorytecie są brane i dzielone na różne zadania, takie jak detalowanie, projektowanie, analiza, programowanie, tworzenie przypadków testowych, wykonywanie przypadków testowych, testy akceptacyjne użytkowników itp.

Zadania są szacowane na podstawie szacowanych godzin, tj. Czasu wymaganego do wykonania tego zadania dla odpowiedniej historyjki użytkownika. Podejście oddolne jest używane do szacowania zadań, w którym wymagania biznesowe są podzielone na czynności niskiego poziomu, a do każdego działania przypisana jest szacunkowa liczba godzin.

Celem oszacowań jest ustalenie, ile historyjek użytkownika, zespół programistów może zaangażować w Sprint. Rozwój musi być zgodny z zaangażowaniem, a właściciele produktu muszą mieć pewność, że zespół wywiąże się ze zobowiązania.

S Czynności do przypisania szacunkowych godzin do zadań:

• Członkowie zespołu odbierają historyjki użytkownika, a następnie proszeni są o oszacowanie rzeczywistego nakładu pracy w odniesieniu do zadań odpowiadających historyjce użytkownika w wymiarze godzin lub dni.
• Jeśli członkowie zespołu nie zgadzają się co do tych szacunków, omawiają je i dochodzą do konsensusu.
• Jeśli jakieś zadanie trwa dłużej niż sześć godzin, jest dzielone na mniejsze zadania.
• Jeśli istnieją dwa lub więcej zadań z szacowaną liczbą godzin mniejszą niż dwa, są one łączone w celu utworzenia nowego zadania.

Przykład oszacowania poziomu sprintu:

Spotkanie poświęcone planowaniu sprintu składa się z dwóch części:

• Pierwsza część: Skupiamy się na wyjaśnieniu wymagań dotyczących Historii użytkowników wybranych z Backlogu Produktu.
• Druga część: Nacisk kładziony jest na rozbicie wymagań na zadania i oszacowanie godzin potrzebnych do ich wykonania. Należy uwzględnić wszystkie zadania niezbędne do dostarczenia elementu Backlogu Produktu. Zadania powinny być małe. W idealnym przypadku nakład pracy nie powinien trwać dłużej niż sześć godzin.

Wniosek

Oszacowania w projekcie Agile odgrywają ważną rolę w zapewnieniu właściwego kierunku, planowania i zarządzania, a także zapewniają kroki, jak podjąć projekt w przyszłości.

Techniki szacowania punktów fabularnych, takie jak Planning poker, Bucket System itp., Wykorzystują karty lub kropki z wydrukowanymi wartościami lub liczbami, a następnie przypisują te numery. do historyjek użytkowników w celu oszacowania względnego rozmiaru.

Jedynym celem jest ustawienie elementów w kolejności od maksymalnego do minimalnego priorytetu. Względne rozmiary szacowane dla pozycji rejestru produktu pomagają w szacowaniu lub obliczaniu budżetu wymaganego dla projektu.

Mam nadzieję, że miałbyś świetny wgląd w szacunki projektów zwinnych. Zapraszam do wyrażenia swoich przemyśleń na temat tego samouczka w sekcji komentarzy poniżej.

rekomendowane lektury

• Jak sprawić, by proces oszacowania był łatwy dzięki Planning Poker
• Agile Vs Waterfall: jaka metodologia jest najlepsza dla twojego projektu?
• Techniki szacowania testów oprogramowania (kompletny przewodnik dotyczący szacowania nakładów testowych)
• Samouczek VersionOne: Przewodnik po narzędziu All-in-one Agile do zarządzania projektami
• Samouczek Jira Portfolio: Wtyczka do zarządzania portfelem projektów Agile dla JIRA (recenzja)
• TOP 10 najlepszych narzędzi do zwinnego zarządzania projektami w 2021 roku
• Podstawy udanej zwinnej podróży: jak wybrać właściwą metodę, narzędzia i techniki
• 4 kroki w kierunku rozwoju podejścia do testowania zwinnego w celu pomyślnego przejścia do procesu zwinnego