Akční položky z retrospektivy: Příklady, které zpřehledňují další kroky

Akční položka z retrospektivy je konkrétní zlepšení, které se tým dohodne provést po diskuzi o jeho efektivitě. Užitečný záznam pojmenuje změnu, vlastníka, bod kontroly a vysvětlí, jaký důkaz potvrdí, zda změna pomohla.

„Zlepšit code review“ ponechává další krok otevřený. „Pro následující sprint dejte každé připravené pull request do jedné sdílené fronty; Maya každý pracovní den kontroluje nepřidělené požadavky; čekací dobu a přerušení zhodnoťte na další retrospektivě“ dává týmu konkrétní akci k vyzkoušení.

Scrum Guide popisuje retrospektivu jako příležitost ke zvýšení kvality a efektivity a vyzývá k rychlému řešení užitečných vylepšení. Níže uvedený formát záznamu a příklady jsou praktická doporučení, nikoliv další Scrum pravidla.

V tomto průvodci

• Šest příkladů akčních položek
• Vyberte vlastníka a zajistěte prostor pro práci
• Dokončená akce může vyžadovat další rozhodnutí
• Zkopírujte záznam akce
• Zhodnoťte, co se stalo
• Uchovejte kontext v Agilo

Šest příkladů akčních položek z retrospektivy

Jde o fiktivní situace z vývojářských týmů. Lidé, časové limity a kritéria hodnocení ukazují, jak explicitně definovat rozhodnutí; přizpůsobte je kapacitám a pravidlům vašeho týmu. Vyberte příklad, který řeší skutečný problém, místo abyste převzali celý seznam.

1. Pull requesty čekají, protože nikdo neví, kdo je zkontroluje

Nejasná akce: „Kontrolujte kód rychleji.“

Konkrétní akce: Pro příští sprint autoři zařazují připravené pull requesty do jedné sdílené fronty. Maya každý pracovní den kontroluje nepřidělené požadavky a žádá dostupného recenzenta o převzetí. Autoři identifikují cokoli, co recenzi brání, např. chybějící kontext nebo nedokončenou kontrolu.

Hodnocení: Porovnejte dobu do první smysluplné recenze s předchozím sprintem a zaznamenejte velikost požadavku, dostupnost recenzenta a přerušení. Pouhé potvrzení nepovažujte za recenzi. Rychlejší reakce jsou užitečné, jen pokud lidé mají čas kód pečlivě prozkoumat.

2. Ta samá nedůvěryhodná část testů neustále zdržuje dodání

Nejasná akce: „Opravte CI.“

Konkrétní akce: Před příštím plánováním Leo prozkoumá nepravidelný checkout test, který blokoval poslední dva merge, zaznamená reprodukovatelnou příčinu nebo zúženou hypotézu a navrhne nejmenší opravu. Tým si vyhradí čas pro vyšetřování.

Hodnocení: Při plánování přezkoumejte zjištění a dohodněte další krok. Po opravě sledujte další relevantní běhy na opakování problému a přineste výsledky na další retrospektivu. Omlčení kontroly nebo jediný úspěšný běh problém neřeší; zachovejte požadované pokrytí.

3. Změna API jiného týmu dorazí příliš pozdě

Nejasná akce: „Lépe koordinujte s platformovým týmem.“

Konkrétní akce: Před zahájením další integrační úlohy Priya požádá platformového protějška o kontrolu jednoho sdíleného příkladu požadavku, odpovědi a chybového případu. Zaznamená přijaté předpoklady a nevyřízená rozhodnutí v integračním úkolu. Pokud není protějšek k dispozici, přinese tuto závislost na plánování místo toho, aby ji považovala za dohodnutou.

Hodnocení: Na další retrospektivě zkontrolujte, zda byl dohodnutý příklad během implementace platný a jaký přepracování vzniklo kvůli chybějícím nebo změněným předpokladům. Domluvení schůzky je krok; cílem je vyřešení závislosti.

4. Oprava chyby ztrácí kroky reprodukce během předávání

Nejasná akce: „Připravujte lepší bug reporty.“

Konkrétní akce: Pro následující tři opravy chyb Sam přidá kroky reprodukce, relevantní prostředí a očekávané chování do úkolu před předáním. Vývojář a tester společně vyřeší chybějící detaily dřív, než se na tyto kroky spolehnou.

Hodnocení: Po třetí opravě zjistěte, zda příjemce mohl každou opravu reprodukovat a ověřit bez nutnosti rekonstruovat původní rozhovor. Zaznamenejte chybějící informace, ale nehodnoťte autory reportů.

5. Podpůrné dotazy opakovaně ruší téhož vývojáře

Nejasná akce: „Chraňte čas na soustředěnou práci.“

Konkrétní akce: Na jeden sprint tým vyzkouší rotujícího prvního kontaktu pro rutinní podpůrné dotazy. Noor zveřejní rotaci a sdílené místo příjmu dotazů, přičemž zůstává zachován stávající postup eskalace naléhavých incidentech. Tým vyhrazuje čas osobě pokrývající podporu.

Hodnocení: Na další retrospektivě posuďte přerušení v týmu a nezodpovězené požadavky. Pokud jedna osoba přijímá všechen chaos, nebo důležité požadavky čekají déle, upravte uspořádání. Pouze méně zpráv ve schránce vývojáře neznamená úspěch.

6. Jen jedna osoba ví, jak obnovit neúspěšné nasazení

Nejasná akce: „Sdílejte více znalostí.“

Konkrétní akce: Před příštím releasem Alex uspořádá nácvik postupu obnovy s dalším vývojářem v schváleném neprodukčním prostředí. Druhá osoba sleduje stávající poznámky a zaznamenává chybějící kroky; Alex vlastní nácvik a aktualizuje podle nich instrukce.

Hodnocení: Po nácviku ověřte, zda druhá osoba rozumí rozhodnutí o obnově a zvládá provést procvičovaný postup bez nepsaných rad. Pouhá existence dokumentu nestačí. Tento nácvik nenahrazuje pravidla přístupu do produkce ani schvalování změn.

Vyberte vlastníka a vyčleňte prostor pro práci

Jeden vlastník udržuje další krok přehledný, shání pomoc a přináší důkazy. Nemusí vykonávat všechny úkoly ani nést odpovědnost za chování ostatních. Potvrďte, že akci přijímá a může ji ovlivnit.

Začněte s jednou nebo dvěma změnami, pokud to tým zvládne. Jde o rozhodnutí o kapacitě, ne univerzální limit. Před přidáním akce se dohodněte na potřebném čase a způsobu sledování vedle běžné práce. Vyšetřování může vyžadovat samostatný úkol, změna pravidla předávání se může vejít do existujícího úkolu.

Pokud změna závisí na jiném týmu nebo manažerovi, jasně formulujte požadavek a rozhodovací bod. Vlastník se zaváže vyhledat rozhodnutí, nemůže však zaručit schválení ostatních.

Použijte šablonu Start Stop Continue, pokud jde o diskusi o praktikách k změně nebo zachování. Poznámka „Start“ je stále návrh, dokud tým nepotvrdí akci a nevyhradí jí čas.

Dokončená akce může stále vyžadovat další rozhodnutí

Vraťme se k příkladu fronty recenzí. Tým zaznamenává dvě různé kontroly:

Představte si, že tým používá frontu během celého sprintu, ale požadavky čekají, kdykoli je jediný znalý člověk dané služby nedostupný. To je fiktivní výsledek, nikoliv výsledek z reportování zákazníků Agilo.

Experiment s frontou byl proveden. Tým zjistil, že sama viditelnost nevyřešila úzké hrdlo specialisty. Další rozhodnutí může být přiřadit dalšího vývojáře ke kontrolám pro danou službu a frontu ponechat, pokud zůstane užitečná. „Hotovo“ znamená dokončení dohodnuté práce, ne automaticky odstranění původního problému.

Zjistíte-li jen pár srovnatelných požadavků, uveďte, že důkazy jsou omezené. Můžete se rozhodnout sledovat další sprint bez tvrzení, že změna uspěla nebo selhala.

Zkopírujte tento záznam akce z retrospektivy

Použijte to ve vašem stávajícím správci úkolů nebo týmových poznámkách. Akci pojmenujte tak, aby vystihovala změnu, a vedle ní uveďte zdůvodnění.

Pozorování a zdroj:
Změna, kterou vyzkoušíme:
Majitel, který ji přijal:
Potřební lidé nebo rozhodnutí:
První krok a vyhrazený čas:
Kdy provedeme kontrolu:
Důkazy o uskutečnění akce:
Důkazy, že to pomohlo, včetně možných vedlejších efektů:
Rozhodnutí po kontrole: ponechat / upravit / zastavit / získat více důkazů

U kontrolní fronty může být prvním krokem dohodnout se, kam požadavky směřují před začátkem sprintu. Kontrola může proběhnout na příští retrospektivě, s krátkou kontrolou během sprintu, pokud zůstanou požadavky nevyřízené. Použijte skutečný datum nebo událost, kterou tým může znovu najít, místo „později“.

Zhodnoťte, co se stalo, než přidáte další akce

Při dohodnuté kontrole požádejte vlastníka, aby popsal práci a ukázal dostupné důkazy. Zachovejte diskusi o podmínkách a rozhodnutích, včetně toho, zda tým poskytl slíbený čas.

Pokračování v téže akci bez změny podmínek znamená, že další sprint ponese tentýž nevyřešený závazek. Nové rozhodnutí zobrazte, i když je rozhodnutí akci zastavit.

Pro kompletní posloupnost schůzky včetně přípravy a prioritizace použijte průvodce facilitací sprintové retrospektivy.

Otázky ohledně akčních položek z retrospektivy

Vyžaduje každá poznámka z retrospektivy nějakou akci?

Ne. Poznámky mohou uchovat něco, co funguje, vznést otázku nebo dodat kontext. Vyberte zlepšení na základě toho, co se tým naučí a co může ovlivnit. Přeměna každé poznámky na úkol může skrýt ty skutečné změny, které si zaslouží pozornost.

Měl by mít Scrum Master na starosti všechny akce?

Vyberte vlastníka, který může každý změnu posunout dále. Facilitátor může týmu pomoci uzavírat a revidovat dohody, aniž by se stal řešitelem každého zlepšení. Akce týkající se chování sestavení může potřebovat vývojáře; rozhodnutí o externích závislostech může potřebovat někoho, kdo má přístup k danému týmu.

Může být šetření (investigace) akční položkou?

Ano, když nejistota brání smysluplné změně. Uveďte otázku, dostupný čas a rozhodnutí, které výsledky ovlivní. „Prověřit pomalé recenze“ zůstává vágní; „identifikovat, kde čekaly tři zpožděné požadavky, a přinést navrhovanou změnu k zpřesnění“ má konkrétní výstup.

Uchovejte pozorování a akci pohromadě v Agilo

V Agilo Retrospectives může mít akční položka název, popis, přiřazeného, prioritu a stav a může odkazovat zpět na svoji zdrojovou kartu. Do popisu vložte dohodnutý bod kontroly a důkazy k shromáždění; při kontrole přidejte pozorovaný výsledek do komentáře.

Tím se uchová důvod práce společně s jejím pokrokem. Tým stále rozhoduje, zda změna pomohla a co dělat dále.

Vytvořte retrospektivu a převeďte jedno pozorování na akci, kterou je váš tým připraven realizovat.