INVEST (mnemotechnická pomůcka) - INVEST (mnemonic)

The INVESTOVAT mnemotechniku pro Agilní vývoj softwaru projektů vytvořil Bill Wake[1] jako připomínka vlastností kvalitní položky nevyřízeného produktu (běžně psané v uživatelský příběh formát, ale nemusí být) nebo PBI Zkrátka. Tyto PBI mohou být použity v a Skrumáž nevyřízené položky, Kanban deska nebo XP projekt.

DopisVýznamPopis
JáNezávislýPBI by měl být samostatný, takovým způsobem, aby neexistovala inherentní závislost na jiném PBI.
NObchodovatelnéPBI nejsou výslovné smlouvy a měly by ponechat prostor pro diskusi.
PROTICennýPBI musí přinést hodnotu zúčastněným stranám.
EOdhadnutelnéVždy musíte být schopni odhadnout velikost PBI.
SMalýPBI by neměly být tak velké, aby bylo nemožné plánovat / plnit úkoly / určovat priority s úrovní přesnosti.
TTestovatelnéPBI nebo související popis musí poskytovat nezbytné informace, které umožní vývoj testu.

Nezávislý

Jednou z charakteristik agilních metodik, jako je Skrumáž, Kanban nebo XP je schopnost pohybovat PBI kolem, s přihlédnutím například k jejich relativní prioritě bez velkého úsilí. Pokud najdete PBI, které jsou úzce závislé, může být dobrý nápad spojit je do jednoho PBI.

Obchodovatelné

Jediná věc, která je v agilním projektu zafixována a vytesána do kamene, je nevyřízená iterace (a dokonce i poté lze toto „vyjasnit a znovu vyjednat ... jak se dozví více“.[2]). Zatímco PBI spočívá v nevyřízených produktech, lze jej přepsat nebo dokonce zahodit, v závislosti na obchodních, tržních, technických nebo jiných požadavcích členů týmu.

Cenný

Zde se zaměřujeme na to, abychom zainteresovaným stranám přinesli skutečnou hodnotu související s projektem. Příchod s technickými PBI, které je opravdu zábavné kódovat nebo navrhovat, ale nepřináší žádnou hodnotu pro zúčastněné strany, je v rozporu s jedním z Agilních principů, kterým je neustále dodávat hodnotný software.[3]

Odhadnutelné

Pokud nelze odhadnout velikost PBI, nebude nikdy plánována ani zadána; proto se nikdy nestane součástí iterace. Takže vlastně nemá smysl vůbec udržovat tento druh PBI v produktovém backlogu. Většinu času nelze provést odhad kvůli nedostatku podpůrných informací ani v samotném popisu příběhu, ani přímo od vlastníka produktu. (Jazyková poznámka - „Odhadnutelná“, protože „schopnost odhadnout“ je definice v americké angličtině.) Definice „vysoké úcty“ v britské angličtině může některé čtenáře zmást. Některé verze modelu používají odkaz „Odhad-schopný“, který také není definovaným slovníkovým záznamem.)

Malý

Snažte se udržet své velikosti PBI obvykle na několik osobodnů a maximálně na několik osobotýdnů (dobrým pravidlem je, že jakákoli jednotlivá položka produktového backlogu nezabere více než 50% iterace; například jedna položka nebude trvat déle než 5 dní pro 2týdenní / 10denní sprint). Cokoli mimo tento rozsah by mělo být považováno za příliš velké na to, aby bylo možné odhadnout s dobrou úrovní jistoty - tyto velké PBI mohou být nazývány „Epics“, kde Epic bude mít více než jednu iteraci k dodání a bude nutně nutné jej rozdělit do menších PBI, které se pohodlně vejdou do iterací. Není problém začít s epickými PBI, pokud jsou rozděleny, když se blíží čas na jejich umístění v iteračním nevyřízeném stavu. Tím je implementován koncept analýzy Lean's Just In Time.

Testovatelné

PBI by mělo být považováno za hotové, mimo jiné, pokud bylo úspěšně testováno. Pokud nelze testovat PBI kvůli nedostatku informací nebo přístupu (viz výše „Odhadnutelné“), neměl by být PBI považován za dobrého kandidáta na to, aby byl součástí iteračního backlogu. To platí zejména pro týmy zaměstnávající TDD - Test Driven Development.

Viz také

externí odkazy

  1. Jeff Sutherland je Blog
  2. https://agileforall.com/new-to-agile-invest-in-good-user-stories/
  3. https://www.agilealliance.org/glossary/invest

Reference

  1. ^ Původní článek Billa Wakeho: INVESTUJTE do dobrých příběhů a SMART úkolů
  2. ^ Průvodce Scrum
  3. ^ Zásady agilního manifestu