Programování

3 agilní zprávy o rozbalování a jak je používat

Agilní praktiky, pro nezasvěcené a nedostatečně informované, se někdy mohou jevit jako metodologie vývoje softwaru ad hoc a řízení projektů. Pravda je úplně jiná.

Jeden z 12 principů agilního softwaru uvádí: „Nejlepší architektury, požadavky a design vycházejí ze samoorganizujících se týmů“, ale většina organizací, které používají agilní postupy, včetně skrumáže a Kanbanu, prosazuje některé významné přísnosti a rituály procesu. Například mnoho organizací implementuje agilní plánovací postupy, včetně odhadu bodu příběhu, standardů architektury a disciplín správy verzí, aby zlepšily obchodní dopad, kvalitu a spolehlivost vydání aplikace.

Většina týmů se ke správě nevyřízených položek, sprintů a spolupráce mezi agilními týmy rozhodne použít agilní nástroj, jako je Jira Software nebo Azure DevOps. Primárním účelem těchto nástrojů je centrálně spravovat požadavky, stav sprintu, pracovní postup a spolupráci napříč agilními členy týmu a více agilními týmy. Čím přísnější organizace však tyto nástroje začnou používat, tím více mohou tyto nástroje pomoci vedoucím a týmům identifikovat problémy, podávat zprávy o stavu zúčastněným stranám a zlepšovat jejich provádění.

Jedním z nejběžnějších out-of-the-box zpráv je burndown report. Jelikož agilní postupy umožňují vlastníkům produktů změnit pořadí nevyřízených položek na základě zpětné vazby od zákazníků, tradiční zprávy, jako jsou Ganttovy diagramy, nezachycují plynulou povahu agilního provádění. Zásadní pro graf podrobností je, že zohledňuje dokončenou práci, novou práci přidanou do oboru a další změny rozsahu. Burndown graf může poskytnout rychlý obraz o tom, jak týmy kráčejí ke svým cílům.

Čtení základního grafu rozběhu sprintu

Burndownové grafy mají obvykle čas na ose x a odhady na ose y. Mnoho týmů odhaduje v bodech příběhu, ale mnoho hbitých nástrojů může mapovat vyčerpání podle počtu příběhů nebo odhadů v hodinách. U tohoto článku předpokládám, že se používají příběhové body.

Zpráva o sprintu shrnuje počet bodů příběhu, které jsou v rozsahu pro časový interval. Jak tým dokončuje příběhy, graf ukazuje, jak „vypalují“ seznam příběhů a dalších typů práce (problémy v Jira, typy pracovních položek v Azure DevOps), dokud není práce dokončena nebo dokud sprint neskončí. Když týmy dokončí práci věnovanou sprintu, protíná vynesená čára osu x, což naznačuje, že je vše hotovo.

Konceptuální sprint je nejjednodušší. První den sprintu se tým zaváže k několika příběhům a celkovému počtu bodů příběhu. Pokud si v ten den zkontrolujete rozbalovací graf, měli byste vidět jediný bod na ose y představující počet bodů, ke kterým se tým zavázal v den nula sprintu.

Když jsou příběhy označeny jako dokončené, shoda sprintu ukazuje zbývající počet bodů k dokončení.

Jak se používá sprint burndown v praxi? Zdravý pokles ukazuje lineární a v ideálním případě exponenciální křivku až na nulu. Pokud má křivka v rané fázi sprintu plochý sklon, může to znamenat bloky nebo hodně rozpracovaných prací a že sprint může být ohrožen. Ploché nebo pomalu se svažující zhroucení může být velmi problematické, pokud se na příbězích s úplným kódem provádí velké testování a pokud testovací práce nemohou začít až v posledních několika dnech sprintu.

Rychle sestupný pokles sprintu je obecně dobrá věc, ale může to znamenat, že se tým málo angažuje nebo se rozhodl ve sprintu přijmout pouze menší příběhy.

Epické burndowny sledují pokrok oproti obchodním a technickým faktorům

Shrnutí sprintu jsou velmi užitečné pro sledování krátkodobého provádění a pomáhají týmům úspěšně plnit závazky sprintu. Aby bylo možné lépe sledovat pokrok oproti dlouhodobějším cílům, poskytují potřebnou viditelnost epická a uvolňovací vydání.

Epické burndowns fungují nejlépe, když týmy definují několik dlouhodobých snah, jako je implementace hlavních schopností koncových uživatelů, strategie technického dluhu, vylepšení výkonu nebo vývoj procesů. Chcete-li využít výhod epických burndownů, měl by mít backlog:

  • Mezi pěti a 15 eposy, které budou trvat nejméně několik měsíců a bude trvat šest nebo více sprintů.
  • Funkce, příběhy a útržky příběhů, které se valí pod eposem a představují plán na vysoké úrovni, který lze v eposu provést.
  • Odhady na vysoké úrovni, ideálně v bodech příběhu pro každý příběh nebo útržek příběhu, který spadá pod eposy.

Jakmile jsou na místě, epické burndown mapuje změny tohoto plánu. Jeho osa x představuje sprinty a osa y představuje celkový odhad příběhů a útržků příběhů přiřazených k eposu. V epickém grafu rozbalování Jira Software vidíte sloupcový graf s jednou barvou představující příběhy dokončené ve sprintu a druhou, která ukazuje přidané body příběhu. Body příběhu se zvyšují, když se k eposu přidají nové příběhy nebo útržky příběhu nebo když se změní odhady.

Existuje několik způsobů, jak použít epický burndown graf:

  • Ilustruje rychlost dokončení funkcí a příběhů oproti plánu. Když jsou plány přesné a konzistentní s rychlostí týmu, může poskytnout indikátor, když je práce eposu dokončena.
  • Většina agilních plánů není úplná a týmy přidávají, mění a odstraňují příběhy na základě zpětné vazby koncových uživatelů, objevu technických složitostí a řešení technického dluhu zavedeného během cesty. Epické zhroucení pak naznačuje, jak daleko od plánu je epos založen na tom, jak moc narůstá počet nevyřízených položek oproti dokončení sprintu sprintem.
  • Epické burndowny také pomáhají srovnávat úsilí napříč několika sprinty a měřit, kolik plánování a dodávek probíhá v jednom eposu oproti ostatním.

Vydání vydání informují týmy o tom, zda vydání zasáhnou datum a rozsah

Pokročilé týmy, které plně automatizují své doručovací kanály s nepřetržitou integrací, průběžným testováním a nepřetržitým doručováním, nemusí potřebovat vydání vydání. Týmy, které nasazují často, by měly sledovat, jaké funkce a příběhy jsou spojeny s vydáním, ale vydání vydání není příliš užitečné, protože často sleduje postup sprintem.

Pro ostatní týmy, které dodržují postupy správy vydání a standardizují vydání multisprint, může být vydání vydání nejdůležitějším nástrojem vlastníka produktu a týmu.

Burndown vydání je podobný epickému burndownu, až na to, že místo sledování funkcí, příběhů a útržků příběhů přiřazených k eposu, vydání vydání ukazuje, co je přiřazeno vydání. Osa a pruhy jsou pak identické s epickými výběry.

Týmy využívající vydání vydání tak mohou sledovat rozsah a časovou osu vydání. Týmy, které jsou na správné cestě, uvidí klesající sklon dolů k ose x se sklonem shodným s rychlostí týmu. Uvolnění, která mohou odbočit mimo trať, mají buď menší sklon, nebo zobrazují více bodů příběhu, které jsou přidávány (když je do vydání přidán větší rozsah), než co se dokončuje.

S těmito projekcemi vám pomáhá Jira Software. Za předpokladu, že tým pracoval na projektu po dobu nejméně tří sprintů, vypočítá Jira Software průměrnou rychlost týmu a na základě této rychlosti předpovídá konečný sprint pro vydání.

Rozběhy sprintu, epiky a uvolnění dávají týmům několik snadno použitelných nástrojů pro sladění cílů. Když týmy sdílejí porozumění rozsahu, dohodnou se na prioritách, plánují několik sprintů dopředu a vhodně označují příběhy v jejich nevyřízených případech, burndowns vyprávějí příběh o tom, zda je plánování a provedení v souladu s cíli. Pokud tomu tak není, jedná se o nástroj založený na datech, který může podnítit diskusi o tom, jaké úpravy mohou být nutné.

$config[zx-auto] not found$config[zx-overlay] not found