AgileScrum

INVESTujte do svých položek v produktovém backlogu

Přehledný, kvalitní a dobře systematicky rozložený produktový backlog je jeden ze základních stavebních kamenů, jak vlastník produktu (Product Owner) vytváří strategii rozvoje produktu.

Abychom mohli takového stavu dosáhnout můžeme použít techniku INVEST. Za tímto akronymem se schovává sada kritérií, které si můžeme snadno zapamatovat. Tímto hodnotícím seznamem posuzujeme kvalitu položek v produktovém backlogu (PBI). Nejčastěji se tyto parametry používají k posuzování byznysových potřeb sestavených formou User Stories, nicméně tento přístup se hodí i v jiných případech. Pokud některý z parametrů nemůže PBI dodržet, tak se tým zamýšlí nad tím, jak takovou položku v produktovém backlogu přeformulovat nebo funkcionalitu rozřezat na menší části jiným způsobem s přihlednutím na zachování hodnoty pro uživatele, či jiného účastníka v procesu, což mnohdy vede k smazání původních položek a nahrazení zcela novými.

I.N.V.E.S.T nám tedy přípomíná, že dobrá PBI naplňuje následující parametry.

Independent / je nezávislá

Položky v backlogu mají být co nejméně závislé, práce s takovými položkami v rámci produktového backlogu je mnohem jednodušší. Cílem je, že se jednotlivé položky koncepčně nepřekrývají a díky tomu máme velmi dobrou schopnost třídění, plánování a doručování v jakémkoliv pořadí tzn. není nutné striktně nejdříve udělat jedno a pak následně druhé. To nám dovoluje, že můžeme třídit položky v produktovém backlogu dle skutečných potřeb.

Protože dosažení takového stavu není vždy možné je určitě v pořádku, že k položkám přistoupíme tak, že nejdříve „prokopneme“ byznys cestu jednou položkou a pak obohacujeme tuto byznysovou cestu o další funkce skrze následující závislé položky, které už jsou na sobě nezávislé. Tím stále zachováme to, že na konci iterace každá položka přinese hodnotu pro koncového uživatele, či jiného důležitého účastníka procesu.

⚠ Nevhodné položky jsou ty, které potřebují, abychom udělali něco před tím, než na ni začneme pracovat.

Negotiable / lze vyjednávat

Dobrá položka v backlogu je vyjednávatelná. Položky nejsou kontraktem s podrobnou specifikací, ale pozvánkou k diskuzi. Význam je takový, že během vývoje se zákazník s vývojáři společně domlouvá na podrobnostech, které se objevují v průběhu Product Backlog refinementu nebo během vývoje. Položka v backlogu v takovém případě zachycuje především podstatu potřeby, nikoli podrobnosti o tom, co se má udělat. Průběžně k položce přidáváme nápady k realizaci, testování, možné dopady uvažované změny apod., ale tyto náležitosti nepotřebujeme k jejímu zatřízení, či plánování.

⚠ Nevhodné položky jsou ty, které jsou plné podrobně sepsaných požadavků. Popisují, jak má být práce udělána, místo toho jak má vypadat výsledek.

Nezapomínejme, že je nutné klást silné otázky koncovým uživatelům, či jinými lidem, kteří jsou vně našeho týmu, abychom pochopili skutečnou potřebu, kterou máme naplnit.

Valuable / má hodnotu

Položka musí být hodnotná. Nezáleží nám na hodnotě jen tak pro někoho. Záleží nám na tom, co je pro koncového uživatele hodnotné. Jestliže vývojáři mají (oprávněné) technické požadavky, formulujeme je tak, že je zákazník vnímá jako důležité.

Tento problém, kdy dochází ke ztrátě hodnoty, se objevuje při rozdělování položek na menší části. Představte si položku jako vícevrstvý koláč, který se skládá ze síťové, výkonostní, logické a prezentační vrstvy (obrázek 1). Když dojde k rozdělení na úrovni vrstev, tak servírujeme zákazníkovi k ochutnání jen např. šlehačku. My ovšem chceme touto položkou dát zákazníkovu možnost ochutnat podstatu celého dortu a nejlepším způsobem je svislé krájení napříč vrstvami. Vývojáři mají často sklon pracovat pouze na jedné vrstvě najednou (a považují to za správné). Když provedeme všechny změny na databázové úrovni, aniž bychom provedli změny na vrstvě prezentační, doručíme z pohledu koncového uživatele téměř žádnou hodnotu.

Obrázek 1: Výtváření položek v produktovém backlogu vertikálním řezem.

Vytvářením jednotlivých cenných plátků dortu pro zákazníka zajišťujeme soulad s touto mantrou. Musíme neustále vyhodnocovat, že to, co obsahuje položka v produktovém backlogu, přinese hodnotu našemu koncovému uživateli nebo jinému důležitému účastníku v procesu.

⚠ Nevhodné položky jsou ty, které popisují činnosti, místo toho jaký má být přínos (hodnota). Popisuje se, jakým způsobem osoba vykonává činnosti z její perspektivy.

Estimable / je odhadnutelná

Odhadnutelnost neznamená, že potřebujeme přesný odhad, ale znamená, že potřebujeme vědět o jak velkou položku se jedná. Vlastníkovi produktu to pomáhá seřadit a naplánovat implementaci jednotlivých produktových přírůstků, tak abychom mohli jednotlivé vývojové iterace naplňovat optimálně. Vlastník produktu pro změnu zajišťuje, že položky v produktovém backlogu mají dostatek informací k odhadování vývojovým týmem.

Odhadování souvisí s vyjednáváním, protože u nejasných položek je odhadování velmi těžké, protože jim jednoduše nerozumíme. Uvědomujme si, že odhadování souvisí i s velikostí položky, protože čím větší položka je, tím hůře se odhaduje. U velkých položek nám unikají důležité souvislosti (nejsme v detailu). Nakonec nám odhadování ještě ovlivňuje samotná zkušenost týmu, protože čím je tým méně zkušený, tím složitěji se mu odhaduje.

V některých případech, kdy je tým již v koncích, vytváříme tzv. Spike, díky kterému se tým pokusí získat dostatek informací k tomu, aby mohl takto nejasnou položku odhadnout. Tímto způsobem dochází k rozdělení původní položky na část analytickou a část implementační.

⚠ Nevhodné položky jsou ty, které jsou příliš velké a obtížně se odhadují. Chybí důležité detaily k provedení odhadu.

Small / je malá

Aby se s položkami pracovalo dobře jak z pohledu produktového vlastníka, tak i z pohledu vývojového týmu, zajišťujeme, že jsou dostatečně malé. Takové položky jsou zjednodušeně velké tak, že jejich pracnost nezabere víc než několik člověkotýdnů. Některé týmy si množství práce limitují jen na několik člověkodní. Ve Scrumu limitujeme velikost tak, že tým takovou položku může dokončit v průběhu jednoho Sprintu (iterace). Uvědomění, co nás čeká v průběhu vývoje větších položek, je velmi těžké. V takovém případě pravděpodobně uslyšíme od člena týmu: „To bude trvat dlouho, protože nevím, co to všechno obnáší“, a proto odhadování menších položek má tendenci být mnohem přesnější než u těch větších.

⚠ Nevhodné položky jsou ty, které se těžce odhadují a jejich pochopení není jednoduché.

Testable / je testovatelná

Dobře vytvořená položka je testovatelná. Pokud nevíme, jak řešení otestujeme, je zde vysoká pravděpodobnost, že tým má nedostatek informací k vytvoření produktového přírustku. Diskuze se zákazníkem o testování před zahájením vývoje přináší zvýšenou šanci, že budeme mnohem produktivnější a koncový uživatel dostane hodnotu, která odpovídá jeho původním představám. Schopnost otestování je vždy dobrý signál toho, že se jedná o dobře sestavenou položku. Kladení důrazu na psaní testů v brzkých fázích vývoje nám navíc ukazuje, zda je náš cíl dosažitelný.

Jestliže z diskuze s uživatelem vyplývá, že neví jak něco otestovat, může to naznačovat, že položka v produktovém backlogu není dostatečně jasná, nebo pro uživatele neodráží něco hodnotného, a nebo že potřebuje pomoc při testování.

Tým se stará i o požadavky nefunkčního charakteru (např. výkon, použitelnost a bezpečnost), které vyžadují testování. Zajištění, jak tyto oblasti testovat, pomáhá týmu se naučit něco víc o skutečných potřebách. Vytvářejme tento typ testů jako nedílnou součást kontrolního mechanismu v rámci Sprintu, abychom zajišťovali, že výsledné řešení netrpí výkonostními problémy a použitelnost zůstává vysoká po každé iteraci.

⚠ Nevhodné položky jsou ty, kterým chybí určitý druh dokladu o tom, kdy položku považujeme za hotovou. Pokud nejsme schopni poukázat jak vypadá dokončená práce, je pravděpodoné, že položku nelze testovat.

Shrnutí

I.N.V.E.S.T. je něco, co máme mít na paměti, když přidáváme položky do našeho produktového backlogu. Když se podíváme na adaptaci této praktiky, zjistíme, že ne vše se dá jednoznačně zařadit do jednotlivých kategorií. Jedná se pouze o vodítko, které je možné následovat a v případě potřeby ho nedodržovat, znamená-li to, že to napomůže týmovému úspěchu.

Možná, že dobrým signálem dobré položky je to, že generuje konverzaci mezi členy týmu. Prostřednictvím dialogu je dosaženo vyjasnění a členové týmu získají pochopení proč a pak kolektivně začnou realizovat jak.

A nakonec připojený tahák může pomoci k lepší orientaci, v jakém stavu máme jednotlivé položky v našem produktovém backlogu a jak můžeme případně zlepšit jejich kvalitu.

INVEST-cheatsheet

Sdílejte s přáteli

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *