Techniky agilného odhadu: Skutočný odhad v agilnom projekte

agile estimation techniques

Skutočné odhady v agilnom projekte: Kompletný prehľad s príkladmi agilného odhadu

Je veľmi dôležité robiť agilný odhad na rôznych úrovniach. To sa deje za účelom správneho plánovania, riadenia a odhadu celkového úsilia, ktoré vynaložíme na implementáciu, testovanie a dodanie požadovaného produktu zákazníkom v stanovenom termíne.

Pri nedostatku odhadov v agilnom projekte nemusí existovať správne plánovanie a riadenie, ktoré by sa mohlo skončiť dodaním nežiaduceho produktu, a tým by zostal zákazník nespokojný.

Bod príbehu Odhady sa robia v agilných projektoch pomocou rôznych techník, ako je Planning Poker, Bucket System, Affinity Mapping, atď. Na tento účel sa používajú rôzne šablóny odhadov na rôznych úrovniach, ako napríklad šablóna agilného plánu projektu, šablóna plánu vydania, šablóna plánu sprintu, šablóna plánu cesty. , Šablóna príbehu používateľa atď.

Čo sa dozviete:

• Úvod
• Odhady Story Story sú agilné
• Odporúčaný nástroj
• Rôzne techniky agilného odhadu
  • # 1) Plánovanie pokru
  • # 2) Veľkosti tričiek
  • # 3) Bodové hlasovanie
  • # 4) Vedierkový systém
  • # 5) Veľké / Neisté / Malé
  • # 6) Mapovanie afinity
  • # 7) Spôsob objednávania
• Agilný výpočet rozpočtu
• Šablóny odhadov v projekte agilného vývoja
  • 1) Šablóna agilného projektu:
  • 2) Šablóna plánu agilného vydania:
  • 3) Šablóna agilného produktu Backlog:
  • 4) Šablóna agilného sprintu backlogu:
  • 5) Šablóna plánu agilného testu:
  • 6) Agilná šablóna príbehu používateľa:
  • 7) Šablóna agilnej cestnej mapy:
• Fázy odhadovania v agilnom projekte
  • # 1) Odhad úrovne návrhu alebo projektu
  • # 2) Odhad úrovne vydania
  • # 3) Odhad úrovne sprintu
• Záver
• Odporúčané čítanie

Úvod

Ďalej sú uvedené 3 hlavné úrovne agilného odhadu.

# 1) Úroveň projektu alebo návrhu je ten, ktorý využíva rýchlu funkčnú bodovú analýzu počas počiatočných fáz vývoja projektu.

# 2) Úroveň vydania Zahŕňa priradenie bodov príbehu k príbehom používateľov, ktoré môžu pomôcť pri určovaní poradia príbehov používateľov na základe priority a môžu tiež pomôcť pri rozhodovaní, ktoré príbehy je možné v aktuálnom vydaní vziať a ktoré sa dajú vziať neskôr.

# 3) Úroveň sprintu je ten, kde sú príbehy používateľov rozdelené do úloh a úlohám sú podľa ich zložitosti priradené odhadované hodiny. Tu tiež definujeme osobu zodpovednú za úlohu spolu so stavom úloh.

Tieto informácie môžu byť neskôr použité na výpočet rozpočtu pre agilný projekt. Výpočet rozpočtu je zásadný pre zabezpečenie toho, aby projekt neprekročil rozpočet z dôvodu úloh pred a po iterácii alebo z iných dôvodov.

Odhady Story Story sú agilné

Odhady Story Points sú komparatívnou analýzou, ktorá slúži na hrubý odhad položiek nevybavených produktov s relatívnym rozmerom. Členmi tímu pre odhad užívateľských príbehov sú: produktový vlastník, Scrum Master, vývojári, testeri a držitelia podielov.

Ďalej je uvedených niekoľko krokov k dosiahnutiu konečného rozhodnutia o relatívnej veľkosti:

# 1) Analyzujte všetky príbehy používateľov a identifikujte základný alebo referenčný príbeh. Je to dôležité pre relatívnu veľkosť. Tento príbeh je možné zvoliť z aktuálneho množstva nevybavených produktov alebo z príbehu, ktorý sme vytvorili už skôr. Tento príbeh by sa mal zvoliť ako referenčný príbeh po dohode všetkých členov.

#dva) Vyberte si ďalší príbeh z aktuálneho produktového backlogu a členovia tímu môžu s vlastníkom produktu diskutovať o akýchkoľvek otázkach alebo pochybnostiach a porozumieť požiadavkám tohto príbehu. Produktový vlastník je zodpovedný za objasnenie všetkých ich otázok a pochybností.

# 3) Vytvorte zoznam vecí, na ktoré je potrebné dbať pri implementácii užívateľského príbehu. Môžete to urobiť tak, že napíšete poznámky do časti s poznámkami nástroja alebo pridáte odrážky na kartu s príbehom. Väčšinou to robí Scrum Master.

# 4) Ďalej je uvedených niekoľko častých otázok účastníkov:

• Dizajn: Aké sú predchádzajúce a povinné znalosti, ktoré by sme mali mať, skôr ako na nich začneme pracovať?
• Kódovanie: Koľko kódovania je potrebné na implementáciu tohto užívateľského príbehu. Stretli sme sa už s podobným užívateľským príbehom aj predtým?
• Testovanie jednotky: Vyžadujú sa na vykonanie testovania jednotiek pre tento príbeh používateľa nejaké falošné objekty?
• Testovanie integrácie: Ovplyvňuje tento príbeh ďalšie funkcionality toho istého modulu a tiež ďalších modulov?
• Prijímacie skúšky: Aké sú body, ktoré je potrebné dbať na dodanie požadovaného produktu podľa želania zákazníkov?
• Odbornosť: Robil niekto z účastníkov podobný príbeh už predtým a je v ňom odborníkom?

# 5) U vybraného príbehu urobte relatívnu veľkosť. Ak to vyžaduje rovnaké množstvo práce a úsilia, pridelte mu to isté č. bodov pridelených referenčnému príbehu. Ak to vyžaduje viac úsilia, priraďte mu vyššiu hodnotu. Ak to vyžaduje menšie úsilie, priraďte mu nižšiu hodnotu.

# 6) Dosiahnite konsenzus so všetkými účastníkmi a dokončite relatívnu veľkosť vybraného príbehu používateľa podľa definície hotového.

pl sql rozhovor s vývojárom otázky a odpovede pre skúsených

# 7) Po vykonaní relatívnej veľkosti všetkých položiek produktového backlogu sa uistite, že ak sú všetky príbehy používateľov s rovnakým číslom. bodov, ktoré im boli pridelené, vyžaduje rovnaké úsilie a veľkosť, aby boli konzistentné.

Odporúčaný nástroj

# 1) Agilný poker

Agilný poker je známa aplikácia pre Jira na rýchle a pohodlné plánovanie a odhady pre vzdialené aj spoločne umiestnené tímy.

Začíname s Agile Poker je jednoduché a ľahké, pretože sa inšpirovalo tromi štandardnými metodikami odhadu: Planning Poker®, Wideband Delphi a Magic Estimation (tiež známe ako Silent Grouping, Affinity Estimation, Swimlanes Sizing alebo Relative Estimations).

Rôzne techniky agilného odhadu

V agilnom projekte existuje veľa techník na vykonávanie odhadov. Medzi hlavné zásady vykonávania odhadov patrí relatívny odhad, diskusie s cieľom získať viac informácií o položkách, ktorých odhady je potrebné vykonať, a zabezpečenie záväzku celého tímu k úlohám, ktoré sú im pridelené.

Existuje hlavne 7 techník odhadu agilných projektov:

# 1) Plánovanie pokru

• V tejto technike odhadu sedia všetci ľudia, ktorí majú robiť odhady, okolo kruhového kruhu pri relácii Planning Poker.
• Každý odhadca má sadu plánovacích pokerových kariet s hodnotami: 0,1,2,3,5,8,13,20,40 a 100. Tieto hodnoty predstavujú body príbehu alebo mieru, v ktorej tím odhaduje.
• Na začiatku relácie si produktový vlastník alebo zákazník prečíta užívateľský príbeh a popíše všetky jeho vlastnosti a požiadavky.
• Po prečítaní príbehu prebehnú diskusie medzi odhadcami a s produktovým vlastníkom / zákazníkom. Odhadcovia môžu klásť otázky alebo objasniť svoje pochybnosti s vlastníkom produktu.
• Po diskusiách sú všetci odhadcovia požiadaní, aby vybrali jednu kartu na odhadnutie používateľského príbehu. Ak všetky odhady dajú rovnakú hodnotu, stane sa z nich konečný odhad.
• Ak sú hodnoty odlišné, potom odhady udávajúce najvyššie a najnižšie hodnoty vysvetľujú svoje názory a prečo si vybrali túto hodnotu, kým sa nedosiahne konsenzus.
• Dobrá technika, keď je malé č. položiek sa odhaduje v malom tíme.

=> Ďalšie podrobné čítanie dňa Plánovanie techniky odhadu pokru .

# 2) Veľkosti tričiek

• Rovnako ako v prípade tričiek, aj tu vidíme veľkosti: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). Podobný postup sa tu uplatňuje. Položky sa odhadujú vo veľkostiach tričiek.
• Toto je dokonalá technika na hrubý odhad veľkého množstva nevybavených položiek.
• Je to užitočné, keď je potrebné urobiť rýchly a hrubý odhad. Neskôr môžu byť tieto veľkosti podľa požiadavky prevedené na žiadne.
• O relatívnej veľkosti (väčšinou strednej) sa rozhodne po vzájomnej diskusii a dohode členov tímu alebo odhadov. Potom sú položky priradené k položkám podľa relatívnej veľkosti, ktorá je priradená k strednej veľkosti.
• Nevýhoda: To, čo sa niekomu javí ako L, sa môže niekomu zdať ako XL.
• Všetci odhadcovia priradia položkám vlastnú veľkosť. Po diskusiách a vyriešení nezhôd sa dosiahne konsenzus, aby sa získal konečný odhad.

# 3) Bodové hlasovanie

• Toto je v zásade metóda určovania poradia na určenie poradia produktového backlogu od príbehov s najvyššou prioritou po príbehy s najnižšou prioritou. Týmto sa vyberajú najdôležitejšie príbehy, v ktorých by sa malo pokračovať.
• Začnite tým, že zverejníte všetky príbehy používateľov spolu s ich popisom na stene alebo doske pomocou žltých lepiacich páskov alebo spôsobom, ktorý ich odlišuje pri prijímaní hlasov.
• Všetkým zúčastneným stranám je pridelené 4 až 5 bodiek (väčšinou sú to štítky, perá alebo fixky, ktoré môžu byť použité aj na vytvorenie bodky).
• Od všetkých zainteresovaných strán sa vyžaduje, aby hlasovali o užívateľských príbehoch, ktoré uprednostňujú.
• Produktový vlastník objedná položky nevybaveného produktu od najviac preferovaných (jeden s najviac bodkami) po najmenej preferované (jeden s najmenším počtom bodiek).
• Môže to byť tak, keď niekoľko zainteresovaných strán nie je spokojných s rozhodnutím, o ktorom sa rozhodlo. V takom prípade sú príbehy používateľov po diskusiách rozdelené do 3 skupín: vysoká priorita, nízka priorita a stredná priorita. Príbehy používateľov s vysokou prioritou sú zverejnené na stene, aby získali hlasy. Toto sa deje, kým sa nedosiahne konečné poradie so súhlasom všetkých zainteresovaných strán.

# 4) Vedierkový systém

• Je to dobrá technika, keď sa objaví veľké č. položiek sa má odhadovať podľa veľkého č. účastníkov. Je to rýchlejšie a rozumnejšie ako Planning Poker.
• Vytvárajú sa rôzne segmenty s hodnotami: 0,1,2,3,4,5,8,13,20,30,50,100, 200. V prípade potreby je možné ich rozšíriť. Tieto segmenty nie sú nič iné ako karty predstavujúce hodnoty usporiadané postupne na stole.
• Príbehy je potrebné umiestniť do týchto oblastí, kde ich odhadca považuje za vhodné. Všetky položky, ktoré sa majú odhadnúť, sú napísané na kartách.
• Náhodne vyberte položku a vložte ju do vedra 8. Slúži iba na informačné účely. Náhodne vyberte iný príbeh, prediskutujte so skupinou všetky jeho vlastnosti a požiadavky a po dohode ho vložte do príslušného vedra. Podobne sa vyberie tretia položka a umiestni sa do vhodného vedra.
• Sekvenciu segmentov je možné tiež zmeniť, v prípade, že sa skupina domnieva, že prvá vybraná položka by mala patriť do segmentu 1 namiesto segmentu 8.
• Sleduje sa prístup Divide and Conquer. Všetky zostávajúce položky sú rozdelené medzi všetkých účastníkov. Všetci účastníci môžu položku umiestniť bez súhlasu ostatných účastníkov.
• Predmety by mali byť umiestnené správne. Medzi lopaty nemôže byť položený žiadny predmet.
• Ak účastník nerozumie položke nevybaveného produktu alebo ak ostatní účastníci dokončili vkladanie svojich užívateľských príbehov, môžu sa príbehy používateľov preniesť na ďalších účastníkov.
• Na konci vykonajú kontrolu duševného zdravia všetci účastníci. Ak ktorýkoľvek účastník zistí, že k položke je priradený nesprávny segment, môže to upozorniť ostatných účastníkov a diskutovať s nimi. Toto sa deje dovtedy, kým sa nedosiahne konsenzus pre celý produktový backlog.
• Facilitátor by mal skontrolovať, či nikto predmetmi nehne, pokiaľ sa nevykoná kontrola zdravého rozumu.
• Toto sa tiež robí na dosiahnutie poradia priorít položiek nevybaveného produktu.

# 5) Veľké / Neisté / Malé

• Toto je hrubá verzia a je zjednodušením systému lyžice, kde existujú iba tri veľkosti: veľká, malá a neistá.
• Účastníci alebo odhadcovia sú požiadaní, aby umiestnili položky do jednej z kategórií. Najprv sa vyberú jednoduché príbehy používateľov, ktoré sa umiestnia do veľkých a malých kategórií. Potom sa zložité položky vyberú.
• Je to dobrá technika, ak sa v produktovom backlogu nachádzajú porovnateľné položky.

# 6) Mapovanie afinity

• Dobrá technika, keď je tím malý a nie. nevybavených položiek je menej.
• Prvým krokom je tichá relatívna veľkosť: Na stene je karta s nápisom „Menšie“ umiestnená na ľavej strane a karta s nápisom „Väčšie“ je umiestnená na strane úplne vpravo. Produktový vlastník poskytuje podmnožinu položiek všetkým účastníkom. Všetci účastníci sú požiadaní, aby veľkosť každej položky zodpovedali veľkostiam na kartách na stene, s prihliadnutím na úsilie potrebné na ich implementáciu. Je to sólo rozhodnutie účastníka bez akejkoľvek diskusie s ostatnými členmi tímu. Na objasnenie pochybností účastníka je prítomný vlastník produktu alebo zainteresovaná strana. Položky produktového backlogu, ktoré sú príliš nejednoznačné na to, aby ich členovia tímu mohli odhadnúť, sú umiestnené samostatne. Trvá to 5-20 minút.
• Úpravy steny: Členovia tímu môžu meniť umiestnenie položiek na stene. Môžu diskutovať o požiadavkách na dizajn a implementáciu s ostatnými členmi tímu. Túto činnosť je možné ukončiť, keď sa na stene deje malá zmena. Trvá to asi 20 - 60 minút .
• Umiestnenie položiek na správne miesta: Po diskusiách tím umiestni položky nevybavených produktov na ich relatívne a vhodné pozície. Na relatívny odhad veľkosti tovaru tu môžeme použiť veľkosť trička, sériu Fibonacci atď.
• Výzva vlastníka produktu: Produktový vlastník môže nájsť určité nezrovnalosti v odhadoch vykonaných tímom a bude musieť s tímom prediskutovať viac funkcií alebo požiadaviek na položku. Po diskusiách sa urobia konečné odhady.
• Export do nástroja na správu nevybavených projektov: Exportujte ich do nástroja na správu nevybavených produktov, aby ste sa ubezpečili, že sa informácie o konečných odhadoch nestratia.

# 7) Spôsob objednávania

• Dobrá technika, keď je veľké č. položiek a malé č. ľudí je tam.
• Poskytuje presné relatívne veľkosti položiek nevybaveného produktu.
• Je pripravená stupnica od najnižšej po najvyššiu. Na ňu sú náhodne umiestnené všetky položky. Každý účastník je požiadaný, aby presunul ľubovoľnú jednu položku na váhe, naraz. Pohyb môže byť jeden hore, jeden dole alebo prejsť otočením na iného člena.
• Toto pokračuje, kým nebudú všetci účastníci spokojní a nebudú chcieť presunúť žiadnu položku na váhe.
• Toto tiež dáva prioritné poradie položiek produktového backlogu.

Agilný výpočet rozpočtu

Výpočet rozpočtov hrá v agilných projektoch dôležitú úlohu. Toto sa robí preto, aby sme sa ubezpečili, aký je skutočný rozpočet, aký rozpočet je potrebný a ako rozdelíme rozpočet na rôzne položky nevybavených produktov.

Používa údaje zhromaždené z predchádzajúcich projektov a pomocou matematického vzorca získa odhadovaný rozpočet pre aktuálny projekt.

Nasleduje postupnosť krokov na výpočet rozpočtu v agilnom projekte:

# 1) Uveďte zoznam všetkých požiadaviek projektu a urobte odhady pre nich pomocou Planning Poker, Bucket System, série Fibonacci atď. Všetci členovia tímu by sa mali po jasnej analýze a pochopení užívateľských príbehov dohodnúť na odhadoch vykonaných pre uvedené požiadavky. Odhady sa robia na základe funkcií, ktoré sa majú implementovať do užívateľského príbehu.

#dva) Určte trvanie iterácií nazývaných Sprinty a položky nevybavených produktov, ktoré sú k nim priradené. Zvyčajne je to 2 až 3 týždne. Príbehy používateľov sa vyberajú v poradí počnúc príbehom používateľa s maximálnou prioritou, prechodom na menšiu prioritu a príbehom s najmenšou prioritou na konci. To pomáha pri rozhodovaní, ktoré príbehy používateľov musia byť zachytené v prvom Sprinte a ktoré príbehy je možné prevziať neskôr.

# 3) Pripravte spálený graf, ktorý poskytne jasný obraz o tom, koľko práce ešte zostáva, a koľko času ešte zostáva na implementáciu. V zásade poskytuje rýchlosť postupu svižného tímu. Poskytuje jasný obraz o tom, ako sa tím správa a ako sa od neho očakáva.

Postup tímu sa meria ako splnené úlohy, zostávajúce úsilie, ideálne vyčerpanie a zostávajúce úlohy, ako je uvedené nižšie:

# 4) Pridajte ďalšie náklady, ako je nákup vybavenia, nástroje, podpora infraštruktúry, získanie licencií na softvérové ​​nástroje, ktoré sa majú použiť, nástroje na správu projektu, inštalácia a aktualizácie antivírusu.

# 5) Pridajte rozpočty pred a po iterácii. Všetci agilní členovia majú byť krížovo funkční, existujú však limity. Čokoľvek, čo urobí člen tímu mimo jeho odbornosti, sa považuje za pred iteračnú prácu alebo post iteračnú prácu. Táto práca pred a po iterácii vyžaduje na implementáciu ďalší rozpočet.

# 6) Dozerajte na skryté riziká. Medzi riziká v projekte Agile patria: Riziko prekročenia rozpočtu projektu, Absencia členov tímu, Členovia nemajú jasné alebo úplné vedomosti, Členovia nemajú požadované zručnosti, boli prekročené termíny atď.

Šablóny odhadov v projekte agilného vývoja

Existuje veľa šablón odhadov, ktoré sú pripravené na rôznych úrovniach v agilnom vývojovom projekte. Jediným účelom je jasne uviesť odhady potrebné na implementáciu požiadavky alebo položky a na sledovanie jej pokroku.

Hlavné šablóny sú uvedené nižšie:

1) Šablóna agilného projektu:

Poskytuje prehľad na vysokej úrovni o tom, koľko času je potrebných na splnenie charakteristík požiadaviek a aký je ich stav. Uvádza sa v ňom aj osoba zodpovedná za konkrétnu úlohu.

(Poznámka: Kliknutím na ľubovoľný obrázok zobrazíte zväčšené zobrazenie.)

2) Šablóna plánu agilného vydania:

Poskytuje podrobnosti o vydaní úloh zodpovedajúcich požiadavkám spolu s ich stavom a Sprintom, v ktorom je potrebné ich vykonať.

3) Šablóna agilného produktu Backlog:

Opisuje kompletný produktový backlog definovaný pre projekt. Poskytuje podrobnosti o úlohách Sprintov spolu so stavom, prioritou, bodmi príbehu a o tom, či sú priradené k Sprintu, alebo či existujú nejaké ďalšie úlohy, ako napríklad chyby atď.

4) Šablóna agilného sprintu backlogu:

Poskytuje popis užívateľských príbehov spomenutých v backlogoch konkrétneho Sprintu. Poskytuje celkový počet bodov príbehu priradených k príbehu používateľa a ako sú rozdelené do rôznych úloh. Poskytuje tiež stav zodpovedajúcich úloh a informácie o tom, aké sú práce vykonávané denne na zodpovedajúcich úlohách.

5) Šablóna plánu agilného testu:

Celý testovací scenár rozdeľuje na čiastkové scenáre. Poskytuje podrobnosti o čiastkových scenároch, ako je dátum implementácie, očakávaný výsledok, skutočný výsledok, stav atď.

Ďalej sa v ňom uvádza názov projektu, kompatibilný prehliadač, verzia testovanej aplikácie, ID prípadu pre vybraný scenár, autor, testovaný, popis atď.

6) Agilná šablóna príbehu používateľa:

Poskytuje podrobnosti špecifické pre analýzu užívateľského príbehu, napríklad Aké sú role potrebné pre testovanie konkrétnej funkcie, aká je predbežná požiadavka (nastavenie prostredia a prepojenia povolené) a aký je očakávaný výsledok?

7) Šablóna agilnej cestnej mapy:

Poskytuje smerovanie projektu v spoločnosti na krátkodobom a dlhodobom základe. Pomáha pri stanovovaní očakávaní v rámci spoločnosti. A prehľad, kam projekt smeruje.

Fázy odhadovania v agilnom projekte

V agilnom projekte sa odhady vykonávajú na 3 úrovniach, ako je uvedené nižšie:

• Úroveň projektu / návrhu: Celková funkčná veľkosť celej aplikácie sa odhaduje pomocou metódy QFPA (Quick Function Point Analysis), keď sú k dispozícii iba vysoké požiadavky.
• Úroveň vydania: Body príbehu sú priradené príbehom používateľov, ktoré pomáhajú pri určovaní počtu č. vydaní plánovaných v rámci projektu a č. užívateľských príbehov, ktoré treba vziať do vydania a šprintu.
• Úroveň šprintu: Odhadované hodiny sú priradené k úlohám používateľských príbehov v rámci šprintu. Toto sa robí, aby sa zabezpečil záväzok vývoja k poskytovaniu používateľských príbehov v šprinte.

S1, S2, S3, S4, S5, S6 sú šprinty.

# 1) Odhad úrovne návrhu alebo projektu

Je to odhad na veľmi vysokej úrovni pre projekt. Zameriava sa na celkový počet požiadaviek v položke Produktový backlog. Funkčné body sa používajú na odhad veľkosti softvéru / projektu pred zdokumentovaním podrobného opisu funkčných požiadaviek.

Funkčné body sú všeobecne akceptovaným spôsobom výpočtu veľkosti softvéru. Zameriava sa na funkcionality nachádzajúce sa v softvérových projektoch. Funkčným bodom je metrika, ktorá prevádza požiadavky alebo príbehy používateľov na číslo.

V počiatočných fázach projektu sa odporúča prijať metódu QFPA (Quick Function Point Analysis).

Metóda rýchlej funkčnej bodovej analýzy je jedinečný prístup k odhadu FP, keď sú k dispozícii iba vysoké požiadavky.

ako otestovať kompatibilitu medzi prehliadačmi

Ako vypočítať celkovú funkčnú veľkosť?

• Pochopte všetky funkcie aplikácie pomocou odborníkov na domény.
• Identifikujte a uveďte zoznam všetkých možných funkcií aplikácie.
• Funkcie ukladania údajov sa delia na súbory interného logického systému (dáta uložené interne v rámci aplikácie) a súbory externého rozhrania (údaje slúžiace iba na referenčné účely).
• Transakčné funkcie sa delia na Externé vstupy (dáta prichádzajúce z externých zdrojov do aplikácie), Externé výstupy (odvodené dáta idú z aplikácie do exteriéru) a Externé dotazy (dáta načítané z jedného alebo viacerých externých vstupov a externých výstupov).
• Vypočítajte veľkosť FP pre každú funkciu výpočtom jej priemernej zložitosti.
• Zhrňte veľkosť FP všetkých funkcií a získate celkovú funkčnú veľkosť aplikácie.
• Minimálne dve osoby s odbornými znalosťami v oblasti analýzy FP by mali počítať nezávisle, porovnávať výsledky a riešiť rozdiely.

Príklad pre odhad na úrovni projektu:

Nižšie je uvedený zoznam požiadaviek na projekt, napríklad v produktovom backlogu:

• Používateľ by mal mať možnosť prihlásiť sa na webovú stránku zadaním používateľského mena a hesla.
• Po úspešnom prihlásení by sa mal používateľ presmerovať na hlavnú stránku s definovanými pravými a ľavými tabuľami.
• Používateľ by mal mať možnosť odhlásiť sa z aplikácie.
• Platný používateľ má možnosť zmeniť heslo zadaním aktuálnych údajov.

Tím používa rýchly odhad FP na odhad veľkosti projektu.

Nasleduje analýza:

• Funkcia ukladania dát tu ukladá prihlasovacie údaje používateľa, aby sa mohol prihlásiť a zmeniť heslo.
• Pretože prihlasovacie údaje sú uložené v rámci hranice aplikácie, sú uložené v ILF (interné logické súbory).
• Transakčné funkcie zahŕňajú:
  • Prihlásenie užívateľa a zobrazenie hlavnej stránky.
  • Odhlásenie používateľa a zobrazenie obrazovky odhlásenia.
  • Možnosť zmeny hesla.

Ďalej sú uvedené kroky vykonané na odhadnutie veľkosti projektu pomocou analýzy rýchlych funkčných bodov:

KROK č. 1: Zoznam všetkých dátových funkcií

UFP (neupravený funkčný bod) je prevzatý z tabuľky Caper Jones.

Krok 2: Zoznam všetkých transakčných funkcií

UFP (neupravený funkčný bod) je prevzatý z tabuľky Caper Jones.

Krok 3: Odvodenie odhadovanej veľkosti projektu vo funkčných bodoch

UFP = údaje FP + transakcia FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (za predpokladu VFP (faktor úpravy hodnoty = 1)

Produktivita = 16 FP / mesiac (normálny štandard)

Úsilie = FP / Produktivita = 22/16 osôb mesiac = 1,37 osoby mesiac

# 2) Odhad úrovne vydania

Odhady úrovne vydania sa robia počas plánovania vydania. Je to ďalšia aktivita po odhade na úrovni projektu. Prioritné požiadavky sú prevzaté z produktového backlogu, ktorý je vo forme užívateľských príbehov.

Príbehy používateľov sa odhadujú z hľadiska príbehových bodov počas plánovania vydania, ktoré sa zameriava na odhad veľkosti softvéru, ktorý sa má pre dané vydanie dodať. Týmto spôsobom sa neplánuje počet vydaní a celkový počet príbehových bodov v každom vydaní.

Bod príbehu v zásade predstavuje relatívne úsilie potrebné na implementáciu funkcie alebo funkčnosti v porovnaní s ostatnými funkciami. Je to v podstate na zmenu veľkosti položiek produktového backlogu.

Odhad bodu príbehu sa robí na základe:

• Zložitosť funkcie, ktorá sa má implementovať.
• Skúsenosti a technické zručnosti všetkých členov.

S1, S2, S3, S4, S5 sú šprinty.

Kroky na priradenie bodov príbehu k príbehu používateľa:

• Všetci členovia tímu sa zhromaždia okolo stola, ktorý prechádza príbehmi používateľov v Sprint Backlogu.
• O význame jedného bodu príbehu a zodpovedajúcom úsilí je rozhodnuté.
• Jeden z členov tímu prečíta príbeh používateľa a potom požiada členov tímu, aby priradili relatívne body príbehu.
• Ak existuje výrazný rozdiel medzi bodmi príbehu pridelenými členmi tímu, potom vysvetlia body príbehu, ktoré im boli pridelené, čím sa na konci dosiahne konsenzus.
• Proces sa opakuje 3 - 4 krát, kým nie je zásadný rozdiel medzi odhadmi poskytnutými členmi tímu.
• Dimenzovanie príbehov pomáha určiť, koľko príbehov sa v rámci šprintu a vydania uskutoční.

Príklad odhadu úrovne vydania:

To zahŕňa vytvorenie prioritného zoznamu Príbehov používateľov s názvom Produktový backlog. Vlastník produktu vytvorí produktový backlog a poskytne obchodnú hodnotu pre každú z položiek v ňom uvedených.

Pre odhady Story Points Estimations môžeme použiť nasledujúce metódy:

• Numerická veľkosť: 1 až 10
• Veľkosť trička: Každá požiadavka je klasifikovaná ako mimoriadne malá (XS), malá (S), stredná (M), veľká (L), mimoriadne veľká (XL).
• Séria Fibonacci: Odhad vykonaný prostredníctvom Fibonacciho sekvencie (1,2,3,5,8,13,21,34,….)

Odhad vyššie uvedených užívateľských príbehov prostredníctvom Fibonacciho postupnosti:

# 3) Odhad úrovne sprintu

Odhady úrovne sprintu sa robia počas plánovania sprintu. Položky nevybavených produktov s najvyššou prioritou sa preberajú a rozdeľujú na rôzne úlohy, ako sú podrobnosť, návrh, analýza, vývoj, vytváranie testovacích prípadov, vykonávanie testovacích prípadov, testovanie prijatia používateľov atď.

Úlohy sa odhadujú ako odhadované hodiny, tj. Čas potrebný na dokončenie tejto úlohy pre zodpovedajúci príbeh používateľa. Prístup zdola nahor sa používa na odhady úloh, kde sú obchodné požiadavky rozdelené na činnosti na nízkej úrovni a každej činnosti sú priradené odhadované hodiny.

Účelom odhadov je vedieť, koľko užívateľských príbehov môže vývojový tím zaviazať k Sprintu. Vývoj musí byť v súlade so záväzkom a vlastníci produktu si musia byť istí, že tím záväzok splní.

S teploty pre priradenie odhadovaných hodín k úlohám:

• Členovia tímu si vyzdvihnú príbehy používateľov. Potom sa od nich požaduje, aby odhadli skutočné úsilie, týkajúce sa hodín alebo dní, týkajúce sa úloh zodpovedajúcich príbehu používateľa.
• Ak sa v týchto odhadoch nezhodnú členovia tímu, potom o tom diskutujú a dospejú ku konsenzu.
• Ak má niektorá úloha viac ako šesť hodín, rozdelí sa na menšie úlohy.
• Ak existujú dve alebo viac úloh s odhadovaným počtom hodín menej ako dve, potom sa spoja a vytvoria novú úlohu.

Príklad pre odhad úrovne sprintu:

Stretnutie Sprint Planning má dve časti:

• Prvá časť: Dôraz je kladený na objasnenie požiadaviek na Príbehy používateľov vybraných z produktového backlogu.
• Druhá časť: Dôraz sa kladie na rozdelenie požiadaviek na úlohy a odhad hodín potrebných na ich splnenie. Mali by byť zahrnuté všetky úlohy potrebné na to, aby bola položka Produktový backlog dodávateľná. Úlohy by mali byť malé. V ideálnom prípade by úsilie nemalo trvať dlhšie ako šesť hodín.

Záver

Odhady v projekte Agile zohrávajú dôležitú úlohu pri zabezpečovaní správneho smerovania, plánovania a riadenia. Poskytujú kroky, ako sa projektu chopiť v budúcnosti.

Techniky odhadu bodov príbehu, ako napríklad Planning poker, Bucket System atď., Využívajú karty alebo bodky, na ktorých sú vytlačené hodnoty alebo čísla, a potom priradia tieto nosy. na užívateľské príbehy pre odhad relatívnej veľkosti.

Jediným účelom je nastaviť položky v prioritnom poradí od maximálnej priority po minimálnu prioritu. Relatívne veľkosti odhadované pre položky nevybavených produktov pomáhajú pri odhadovaní alebo výpočte rozpočtu požadovaného pre projekt.

Dúfam, že by ste získali vynikajúci prehľad o odhadoch agilných projektov. Neváhajte a vyjadrite svoj názor na tento výukový program v sekcii komentárov nižšie.

Odporúčané čítanie

• Ako uľahčiť proces agilného odhadu pomocou plánovacieho pokru
• Vodopád Agile Vs: Ktorá je najlepšia metodika pre váš projekt?
• Techniky odhadu softvérových testov (Kompletný sprievodca odhadom úsilia o testovanie)
• Výukový program VersionOne: Sprievodca nástrojom agilného riadenia projektu „všetko v jednom“
• Výukový program pre portfólio Jira: Doplnok Agile Project Portfolio Management pre JIRA (recenzia)
• TOP 10 najlepších nástrojov agilného riadenia projektov v roku 2021
• Podklady pre úspešnú agilnú cestu: Ako zvoliť správnu metódu, nástroje a techniky
• 4 kroky k vývoju agilného testovania myslenia pre úspešný prechod na agilný proces