it-swarm-eu.dev

Jaké je nejlepší vysvětlení toho, co jsou Story Points?

Začínáme zde používat Story Points pro náš Agilní vývoj, ale je pro mě těžké vysvětlit a také nemůžu najít definitivní odpověď na to, co jsou. Nejlepší věc, kterou mohu udělat, je poukázat na jiné weby (jako http://blog.mountaingoatsoftware.com/tag/story-points ) a dát nějaké vágní zobecnění toho, čím jsou. Hledám dobré vysvětlení s některými příklady použití, které by byly užitečné pro ostatní. Existují nějaké dobré zdroje pro vysvětlení příběhových bodů?

36
six8

To může pomoci jako startér: Mike Cohn v příběhových bodech . Ale tohle je mnohem lepší: Agilní vývojové týmy: Rozsah a měřítko s Mikeem Cohnem

Mikeovo řešení metrik softwarového odhadu je jednoduché a efektivní. Biologická fakta:

  • Lidský mozek prostě nedokáže správně odhadnout čas. Obzvláště pokud více než několik hodin.
  • To je velmi umocněno množstvím nejistot v softwarovém vývojáři, psychologickými tlaky ze strany managementu (když odhadujete, zavazujete se ...) a rozdílem v dovednostech v týmu.
  • Jsme však docela dobře v porovnání věcí. Jsme tam docela přesní.

Záměrem je vzít jeden referenční příběh uživatele , a pak mu dát libovolný počet (příběh) bodů , pak další příběhy získají body související s tímto odkazem.

Pokud je váš referenční příběh 100 bodů a jiný příběh je třikrát větší, bude to 300 bodů.

Chcete-li převést příběhové body do času pro plánování, musíte znát svou rychlost .

Chcete-li získat přesnou rychlost, musíte provést několik iterací a spočítat, kolik bodů váš tým dokončil v daném množství času.

Funguje to .

36
user2567

Souhlasím se vším, @Pierre 303: řekl výše: (kromě 100 referenčních bodů).

Jediné, co bych chtěl přidat (důraz), je to, že nejsme dobří při odhadování úkolů. Můžeme odhadnout úkoly ve vztahu k jiným úkolům, pokud jsou zhruba stejné velikosti. Čím větší je rozdíl mezi úkoly, tím horší je.

Proto nesouhlasím s použitím výchozího bodu 100.

Není to tak, jako byste odhadli další úkol jako 42% referenční úlohy. Je to buď stejná polovina práce, dvojnásobek práce, trojnásobek práce atd.

Náš tým používá Planing Poker : V tomto máme referenční úkol 2 příběhových bodů. Poté pomocí řady Fibonacci odhadujeme úkoly: 1,2,3,5,8,13,21, Huge ,? vzhledem k referenční úloze (Spíše než Fibonacci jsem viděl jiné týmy používat síly 2. 1,2,4,8,16,32, Huge ,?) Viděl jsem jiné týmy používat (malý (1), střední ( 2), velký (3), XLarge (4), když vypočítali rychlost, která stále fungovala.).

Jde o to, že jak se velikost úkolu v porovnání s referenčním úkolem zvětšuje, jsme méně schopni přesně odhadnout jeho náklady. Takže nemá smysl to zkoušet. To se projevuje větším sklonem na konci odhadovací stopy.

Takže pokud je váš referenční úkol 2SP. Poté je odhad 1/2/3/5 relativně snadný, protože úkol má podobnou velikost. Jakmile se dostanete 3krát větší než referenční úkol (5SP), odhad bude těžší (na tom záleží 8/9/10SP) Vše, co můžete říci, je jeho větší než 5SP a menší než 13SP, pak 8SP vyhovuje vyúčtování.

Cokoli s hodnotou SP 13/21/Obrovské je příliš velké pro nevyřízené sprinty. Jedná se o odhady věcí, na které ještě nejste připraveni skutečně pracovat (a tak se nerozdělili na menší úkoly (nerozbíjejte je, dokud nepotřebujete příliš)). Ale oni vám poskytnou odhad velikosti úkolu v nevyřízeném produktu (což umožňuje nějaké budoucí plánování). V době, kdy se dostanete do bodu, kdy budete na nich pracovat, měli byste mít dostatek znalostí, abyste je mohli rozdělit na menší úkoly pro backlog sprintu a individuálně je znovu odhadnout (Poznámka: Je to běžná mylná představa, že součet částí se rovná původnímu).

  • Všechno, co odhadnete jako obrovské, je třeba rozdělit na menší úkoly.
  • Odhaduje se něco? znamená, že není dostatečně definován k odhadu
    Chcete-li úkol definovat, musíte přidat konkrétní úkol
    (tj. napsat nějakou dokumentaci nebo prezentaci).
5
Martin York

Jsou ztráta času.

enter image description here

http://www.Amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Zajímavé, že tento názor nyní pochází od chlapa, který napsal Scrum a XP z Trenches a jehož název společnosti ( Crisp ) najdete na tolika balíčcích plánování pokerových karet, které používá tolik týmů po celém světě.

Poslední věta OP: „Existují nějaké dobré zdroje pro vysvětlení příběhových bodů?“ Ano, tato kniha je dobrým zdrojem. K zamyšlení.

2
azheglov

Body příběhu jsou relativní měření toho, jak obtížný je úkol. Je tomu tak proto, že lidé jsou ve skutečnosti v relativních odhadech lepší než přesná měření.

Způsob použití příběhových bodů spočívá v tom, že v projektu vezmete dva úkoly a přiřadíte jim dvě různé hodnoty příběhových bodů. Poté odhadnete další úkoly pomocí těchto dvou přibližných bodů příběhu jako základu pro váš odhad. Tj. Úkol C není o nic těžší než úkol A, ale neuvěřitelně jednodušší než úkol B, takže je o 2 příběhové body více práce než úkol A.

Když dokončíte odhad všech požadavků, které máte dosud, odhadněte, kolik můžete ve sprintu udělat. V příštích několika sprintech odhadnete, kolik jich jste dokončili. Body příběhu požadavku se počítají jako dokončené, pouze pokud je požadavek splněn. V Scrumu není žádné "80% kompletní". Je to proto, že lidé ve skutečnosti odhadují úplnost špatně. Po několika sprintech byste měli mít představu o tom, kolik příběhových bodů můžete udělat na sprint.

Jak odhadujete? Pomocí plánování poker můžete určit, kolik práce vaši vývojáři cítí, že požadavek bude trvat v porovnání s vašimi základními požadavky.

Doporučil bych také přečíst Agilní Samurai . Podle mého názoru to vysvětluje tyto a další agilní koncepty dobře.

Zde je odkaz na další informace o příběhových bodech.

Zde je další odkaz.

2
indyK1ng

Jak jiní uvedli, příběhové body jsou relativním měřítkem složitosti uživatelského příběhu. Skutečná výhoda příběhových bodů je realizována, když

  1. Body jsou měřeny jednotkou odpovědnou za implementaci (jednotlivec nebo tým).
  2. Metriky jsou uchovávány pro to, kolik agregovaných bodů je dokončeno stejnou jednotkou v konstantním trvání (rychlosti).

Po několika iteracích měření v příběhových bodech a rychlosti sledování byste měli být schopni přesně odhadnout, kolik bodů příběhu se vejde do daného časového bloku (iterace nebo sprint, pokud používáte scrum). Upozorňujeme, že použití této techniky ve skupině a pokus o použití těchto metrik pro jiný tým nebude fungovat dobře. To znamená, že pokud tým může dokončit 120 příběhových bodů ve dvoutýdenním sprintu, očekávání, že tým b bude mít stejné výsledky, je nerealistické.

Jak řekl někdo jiný, plánování pokeru je při použití této metody skvělou pomocí, protože pomůže identifikovat příběhy, které vyžadují další upřesnění (pokud existuje nesoulad mezi hlasy, znamená to, že požadavky jsou nejisté).

0
Michael Brown

Nejjednodušší vysvětlení, které mohu přijít, je použití předmětu, který je hmatatelný a může poskytnout konkrétní příklad.

Vezměte si mobilní dům. Kdybych byl v mobilním byznysu, věděl bych, že budování jedné široké obvykle trvá 5 (body, žáby, widgety ... měřicí formulář je libovolný), a proto by budování dvojité šířky mělo trvat přibližně dvojnásobek úsilí nebo 10 (body) , žáby, widgety).

Programátorské myšlení v tomto okamžiku nakopne a promluví o zefektivnění přístupu; netrvá to dvakrát tak dlouho, protože infrastruktura spotřebovává největší část času a další podobné příklady. To je nevyhnutelné. Harp na skutečnost, že se jedná o odhad v (body, žáby, widgety), protože NIKDY nemůžeme přesně odhadnout v čase, a proto odhad v (body, žáby, widgety) odstraní přesvědčení, že můžeme.

Abychom věděli, jak dlouho bude něco budovat, využijeme naše trendy v čase; tak v průběhu času získáváme stále větší a přesnější odhady.

Nezapomeňte plánování poker , když je tým připraven jít.

0
Aaron McIver