AgileScrum

Co je Spike aneb jak dělat výzkum v agilním vývoji

Agilní týmy pracující nejen v rámci frameworku Scrum to znají dobře. Setkávají se s nezodpovězenými otázkami, problémy, neznámými situacemi, riziky nebo nejistotami. Dostávají se do situace, kdy není možné okamžitě vypracovat řešení nebo dojít k závěru či hádají, co může být přínosem. Z tohoto důvodu provádí experimenty, které pomáhají najít správnou příčinu těchto situací a můžeme tak navrhnout správné řešení.

Nicméně vyřešení těchto situací není vždy tak jednoduché a rychlé, jak by se mohlo zdát. Někdy mouhou být příčiny buď příliš velké a nebo velmi komplikované. Způsobují, že tým není schopen odhadnout práci dobrým způsobem. Tým se může setkat i s vlivem potenciální překážky, která mu brání vytvořit řešení.

Z výše uvedených důvodů tu máme k dispozici alternativu, kterou nalezneme v Extreme Programming a to je vytvoření Spike.

Kdybychom věděli, co jsme dělali, nemuselo by to být nazýváno výzkumem.

Albert Einstein

Co je Spike?

Spike je experiment, který umožňuje vývojářům odhadnutí množství a komplexitu práce tím, že jim poskytuje dostatek informací o neznámých prvcích řešené potřeby.

Kdy Spike použít

  • Ke snížení možného rizika
  • K získání znalostí zvyšující jistotu vhodnosti zvoleného přístupu
  • Lepšího pochopení aspektu přístupu nebo specifikace požadavku
  • Zvýšení spolehlivosti plánu nebo počátečních odhadů

Jaké jsou typy Spike

Funkční Spike používáme, když chceme analyzovat celkové chování řešení a určit následující věci

  • Jak rozdělit velkou položku v produktovém backlogu
  • Jak si organizovat práci
  • V čem se nachází složitost a riziko
  • Jak ovlivnit implementační rozhodnutí na zakladě vhledu do problematiky

Technický Spike používáme, když chceme zkoumat různé technické přístupy, jako například

  • Určit zda řešení vytvořit nebo nakoupit
  • Vyhodnotit potenciální výkon nebo dopad nového požadavku
  • Vyhodnotit specifické technické implementační přístupy
  • Rozvíjet důvěru rozhodnutého technického řešení

Se Spike pracujeme naprosto totožně jako s jakoukoliv jinou položkou v produktovém backlogu, tzn. že ho přidáme jako novou položku. Dimenzujeme ho tak, aby se vešel do jedné iterace. Někdy se Spike označuje jako User Story Spike. Tímto způsobem si přidělujeme část týmové kapacity před tím, než jsme reálně schopni začít pracovat na řešení.

Jaký je rozdíl mezi Spike a User Story? Výsledkem User Story je hotové technické řešení, naopak výsledkem Spike jsou nové poznatky a informace.

Co bychom měli o Spike vědět je to, že ne vždy vede k většímu rozvoji. Jde jen o rychlý způsob určení, zda stojí určitá myšlenka za úvahu a má cenu se jí dále zabývat.

Mějme na paměti, že Spike vede k lepšímu vhledu a schopnosti odhadnout množství a komplexitu práce. Cíl definujeme tak, aby byl jasný a jednoznačný. Není jeho cílem vytvořit funkční základ, k tomu, abychom mohli udělat odhad.

Vyvarujme se vytváření nadměrného množství Spike, je to kontraproduktivní. Tento přístup může vést k oddalování doručení hodnoty!

Jak přistupovat ke Spike?

Pokud výzkum (Spike) trvá pouze jednu nebo dvě hodiny, není třeba ho vytvářet a tím zvyšovat byrokratickou zátěž. Výzkum, který je potřebný na delší časový úsek bychom naopak do Produktového backlogu měli zadat. Usnadní nám to plánování budoucí iterace. V oblíbeném nástroji JIRA nám k tomu poslouží typ položky Spike.

Výsledek Spike je představitelný jak v rámci týmu, tak i případným stakeholderům. Tento přístup vede k vysokému zviditelnění výzkumu a navržené architektury. Výsledkem je posilování kolektivního vlastnictví a sdílení zodpovědnosti za rozhodování.

Každý Spike vytvářejme tak, aby nezahrnoval více času než pro 1 den výzkumu.

Existují však některé důvody, kdy potřebujeme výzkum provádět delší dobu, tj. i několik dnů. Vždy platí pravidlo bez ohledu na délku časového rámce, že při jeho vyčerpání tým hlasí, jaká jsou zjištění. V situaci, že po vypršení časového rámce nedošlo k zjištění požadovaných informací, rozhodneme se, co potřebujeme dále udělat. Při vypršení časového rámce nedocházi k jeho automatickému překročení či navýšení.

Důvodem nedosažení cíle v rámci časového rámce může být nedostatečně srozumitelná definice či nejasný rámec přínosu výzkumu.

Výsledkem Spike může být i zjištění, že potřebujeme navazující výzkum a vytvoření dalšího Spike.

Ultimátním cílem každého agilního týmu je schopnost řešení nejistoty v každé iteraci. Spike proto používejme vyhrádně v situacích, kdy existuje vysoká míra nejistoty, která může být kritická v průběhu iterace.

Podstatu agilního vývoje charakterizuje nejistota a riziko. Tým definuje správná řešení prostřednictvím mnoha hodin strávených v rámci diskuze, spolupráce, experimentování a vyjednávání. Každá položka v produktovém backlogu může mít svou strukturou charakter podobný Spike, která pomáhá identifikovat technická a funkční rizika.

Shrnutí

Používejme Spike, kdykoliv potřebujeme získat hlubší porozumění, kdy při odhadování narazíme, že odhadnutí je velmi obtížné. Důvodem může být, že položka je příliš velká, nebo je příliš velká nejistota či nejistot je více.

Pokud je položka příliš velká (Epic, Super User Story atd.), rozdělujeme ji na menší položky. Stále mějme na paměti, že nové položky stále následují I.N.V.E.S.T.

V případech, kdy položka obsahuje příliš nejistot, můžeme použít technický nebo funkční Spike. Tím tuto nejistotu mužeme snížit a umožní nám to začít na položce v produktovém backlogu pracovat.

Spike neodhadujeme v žádných jednotkách (fixních či abstraktních), ani časové rámce nepřepočítáváme. Jedná se o výzkum a nevíme, za jak dlouho a jaké množství práce uděláme pro dosažení výsledku.

V žádném případě se nesnažíme odhadovat velikost Spike. Určujeme, jak dlouho se chceme výzkumu věnovat!

Zamysleme se, před tím než vytvoříme Spike a následně jej zaplánujeme do další iterace, jakým jiným způsobem uděláme výzkum. Skutečně nám nestačí schůzka s důležitými lidmi, která vše vyjasní? Nebo bychom si mohli na Product backlog refinement pozvat někoho, kdo nám pomůže nejasnosti rozkrýt? Nacházejme vlastní způsoby, jak nepotřebovat Spike za každé situace.

Mějme na paměti, že na prvním místě je optimální provedení výzkumu a dosažení maximální efektivity vývoje.

Sdílejte s přáteli

Napsat komentář

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