Alai

Kdybychom věděli, co děláme, neříkalo by se tomu výzkum.

-Albert Einstein

Hroty jsou typem příběhu průzkumu Enabler v SAFe. Původně byly definovány v Extrémním programování (XP) a představují činnosti, jako je výzkum, návrh, zkoumání, průzkum a prototypování. Jejich účelem je získat znalosti potřebné ke snížení rizika technického přístupu, lepšímu pochopení požadavku nebo zvýšení spolehlivosti odhadu příběhu.

Stejně jako ostatní příběhy jsou i hroty odhadovány a následně demonstrovány na konci iterace. Poskytují také dohodnutý protokol a pracovní postup, který používají agilní release trainy (ART), aby pomohly určit životaschopnost epiků.

Agile a Lean oceňují fakta před spekulacemi. Když Agilní týmy čelí otázce, riziku nebo nejistotě, provádějí před přechodem k realizaci malé experimenty, místo aby spekulovaly o výsledku nebo se vrhly na Řešení. Týmy mohou používat hroty v různých situacích:

• Vyhodnocování nových funkcí a schopností k analýze předpokládaného chování, což poskytuje náhled na přístup k jejich rozdělení na menší, kvantifikovatelné části
• Provádění analýzy proveditelnosti a dalších činností, které pomáhají určit životaschopnost epiky
• Provádění základního výzkumu k seznámení se s novou technologií nebo doménou
• Získání důvěry v technický nebo funkční přístup, snížení rizika a nejistoty

Spiky zahrnují vytvoření malého programu, výzkumné aktivity nebo testu, který demonstruje některý aspekt nové funkce.

Technické a funkční špičky

Špičky mají především dvě formy: technickou a funkční.

Funkční hroty – Slouží k analýze celkového chování řešení a určení:

• Jak jej rozdělit
• Jak organizovat práci
• Kde existují rizika a složitost
• Jak využít poznatky k ovlivnění rozhodnutí o implementaci

Technické hroty – Slouží k výzkumu různých přístupů v oblasti řešení. Například:

• Určit rozhodnutí build-versus-buy
• Vyhodnotit potenciální dopad nového uživatelského příběhu na výkon nebo zátěž
• Vyhodnotit konkrétní technické přístupy k implementaci
• Vyvinout jistotu ohledně požadované cesty řešení

Některé funkce a uživatelské příběhy mohou vyžadovat oba typy hrotů. Zde je příklad:

„Jako spotřebitel chci vidět svou denní spotřebu energie v histogramu, abych mohl rychle pochopit svou minulou, současnou a předpokládanou spotřebu energie.“

V tomto případě může tým vytvořit oba typy hrotů:

• Technický hrot pro výzkum, jak dlouho trvá aktualizace zákaznického displeje na aktuální spotřebu, určení komunikačních požadavků, šířky pásma a toho, zda data odesílat nebo stahovat
• Funkční hrot – Vytvořte prototyp histogramu na webovém portálu a získejte zpětnou vazbu od uživatelů ohledně velikosti prezentace, stylu a tvorby grafů

Pokyny pro hroty

Protože hroty nepřinášejí přímo hodnotu pro uživatele, používejte je střídmě. Platí následující pokyny:

Kvantifikovatelné, prokazatelné a přijatelné

Stejně jako ostatní příběhy se i hroty zařazují do týmového backlogu, odhadují se a jejich velikost se přizpůsobuje iteraci. Výsledky hrotů se liší od příběhu, protože hroty obvykle vytvářejí spíše informace než funkční kód. Měly by vytvářet pouze potřebná data, aby bylo možné s jistotou identifikovat a dimenzovat příběhy, které je řídí.

Výstup spiku je prokazatelný, a to jak pro tým, tak pro všechny ostatní zúčastněné strany, což přináší zviditelnění výzkumného a architektonického úsilí a také pomáhá budovat kolektivní vlastnictví a sdílenou odpovědnost za rozhodování. Vlastník produktu akceptuje špičky, které byly předvedeny a splňují jeho akceptační kritéria.

Časování špiček

Protože představují nejistotu v jednom nebo více potenciálních příbězích, je někdy riskantní plánovat špičky i výsledné příběhy ve stejné iteraci. Pokud je však malý a přímočarý a je pravděpodobné, že se najde rychlé řešení, pak může být poměrně efektivní udělat obojí ve stejné iteraci.

Výjimka, ne pravidlo

Každý uživatelský příběh obsahuje nejistotu a riziko; taková je povaha agilního vývoje. Tým objevuje správné řešení prostřednictvím diskuse, spolupráce, experimentování a vyjednávání. V jistém smyslu tedy každý uživatelský příběh obsahuje aktivity podobné bodům, které identifikují technická a funkční rizika. Cílem agilního týmu je naučit se v každé iteraci řešit nejistotu. Spiky jsou kritické, pokud existuje vysoká nejistota nebo mnoho neznámých.

Zjistěte více

Leffingwell, Dean. Agilní požadavky na software: D.: Agile Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Postupy štíhlých požadavků pro týmy, programy a podniky). Addison Wesley, 2011.

Poslední aktualizace: 10. února 2021