Sdílet prostřednictvím

Scrum a osvědčené postupy

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Sprint plánování schůzek

Většina plánování sprintů zahrnuje vyjednávání mezi vlastníkem produktu a týmem, které určují zaměření a práci na řešení v nadcházejícím sprintu. Je užitečné naplánovat schůzku s časovým rámečkem a omezit ji na 4 hodiny nebo méně.

V první části schůzky se váš vlastník produktu setká s vaším týmem a prodiskutuje uživatelské scénáře, které můžou být součástí sprintu. Produktový vlastník sdílí informace a odpovídá na všechny otázky, které má váš tým ohledně těchto příběhů. Tato konverzace může odhalit podrobnosti, jako jsou zdroje dat a rozložení uživatelského rozhraní. Nebo může odhalit očekávání doby odezvy a důležité informace o zabezpečení a použitelnosti. Váš tým by měl tyto podrobnosti zaznamenat ve formuláři položek backlogu. Během této části schůzky se váš tým dozví, co musí sestavit.

Při plánování sprintů můžete zjistit další požadavky na zachycení a přidání do backlogu. Ujistěte se, že je dobře definovaný a v pořadí priority.

Nastavení cíle sprintu v rámci plánování také může týmu pomoct soustředit se na to, co je pro každý sprint nejdůležitější.

Po naplánování sprintu můžete chtít plán sdílet s klíčovými zúčastněnými stranami.

Další informace najdete v těchto zdrojích informací:

Nastavení cílů sprintu

Týmy Scrum používají cíle sprintu k zaměření svých aktivit sprintu. Tento cíl často nastavují při plánování sprintu. Cílem je shrnutí toho, co chce tým dosáhnout na konci sprintu. Explicitním vyjádřením cíle vytvoříte sdílené porozumění v rámci týmu základního účelu. Cíl sprintu může také pomoct týmu při vzniku konfliktů v případě priorit.

Tipy z výkopů: Definování cílů sprintu

Cíl sprintu definuje, co vlastník produktu a tým považují za konečný cíl k dosažení tohoto sprintu. Nejedná se o náhodný výběr položek backlogu, které ve skutečnosti nemají vztah, ale krátký text, který zachycuje, čeho by se měl tým pokusit dosáhnout. Vlastník produktu obvykle přichází s cílem sprintu před výběrem mnoha položek pro další sprint. Položky pro tento sprint by měly vyhovovat danému společnému cíli.

Cíle sprintu můžou být orientované na funkce, ale můžou mít také velkou komponentu procesu, jako je automatizace nasazení nebo automatizace testů.

Například:

  • Tento sprint se zaměříme na jednoduchý uživatelský příběh. Použijeme ho k prokázání toho, že navrhované řešení funguje.
  • Tento sprint se týká implementace funkcí zabezpečení, které správně zabezpečují část správy webu.
  • Tento sprint se týká integrace nejdůležitějších platebních bran, abychom mohli začít shromažďovat peníze.

Nastavení cílů sprintu pomáhá týmu udržet si přehled. Usnadňuje definování priority úkolů v rámci sprintu a pravděpodobně pomáhá omezit počet zúčastněných stran a koncových uživatelů, kteří se účastní.

Při kontrole sprintu byste měli položit nejdůležitější otázku, jestli jste se podařilo dosáhnout cíle sprintu. Kolik příběhů jste dokončili, je až druhotné. Pokud se dosáhne cíle, sprint bude úspěšný, i když nebyly dokončeny všechny scénáře.

přispěl Jesse Houwing, Visual Studio DevOps Ranger a hlavní konzultant pracující pro Avanade Nizozemí.

Tipy pro úspěšné schůzky pro třídění

Oprava chyb představuje kompromis s jinou prací. Pomocí schůzky pro třídění určíte, jak důležitá je oprava jednotlivých chyb oproti jiným prioritám souvisejícím s rozsahem projektu, rozpočtem a plánem.

  • Nastavte kritéria týmu pro vyhodnocení chyb, které chcete opravit a jak přiřadit prioritu a závažnost. Chyby spojené s funkcemi významné hodnoty (nebo významné náklady na zpoždění příležitosti) nebo jinými riziky projektu by měly mít přiřazenu vyšší prioritu a závažnost. Uložte kritéria třídění s dalšími týmovými dokumenty a podle potřeby aktualizujte.
  • Pomocí kritérií třídění určete, které chyby se mají opravit a jak nastavit jejich stav, prioritu, závažnost a další pole.
  • Upravte kritéria třídění podle toho, kde se nacházíte ve vývojovém cyklu. V rané fázi se můžete rozhodnout opravit většinu chyb, které roztřídíte podle důležitosti. Později v cyklu však můžete zvýšit kritéria třídění, abyste snížili počet chyb, které potřebujete opravit.
  • Jakmile provedete třídění chyby, přiřaďte ji některému z vývojářů. Vývojář pak může prozkoumat a určit, jak implementovat opravu.

Správa technického dluhu

Zvažte řízení ukazatele chyb a technického dluhu jako součást celkového souboru aktivit neustálého zlepšování vašeho týmu. Můžete najít tyto zdroje informací, které vás zajímají:

Tipy z výkopů: Správa chyb

Agilní správa chyb: Není oxymoron
Od Gregga Boera, hlavního manažera programu ve Visual Studio Cloud Services ve společnosti Microsoft

Řešte všechny známé dluhy způsobené chybami během každého sprintu.

Každý sprint se tým podívá na chyby, které zůstávají v backlogu, a vyhradí kapacitu, aby se známý počet chyb snížil na nulu nebo téměř na nulu. Ať už se jedná o jeden den, jeden týden nebo celý sprint, opraví chyby jako první. Chyby zjištěné později ve sprintu se nepovažují za součást tohoto počátečního závazku. Pokud nemají vysokou prioritu, zadají se do backlogu chyb pro další sprint.

Mnoho týmů pracuje v organizaci založené na závazku. Vedení často klade vysokou hodnotu na schopnost týmu plnit své závazky. Provádění plánování kapacity ve vztahu k známé sadě chyb způsobuje, že plánování sprintů je více deterministické, čímž se zvyšuje šance na splnění závazků. Všechny nové chyby zjištěné během sprintu nejsou součástí počátečního závazku a je možné je vyřešit v dalším sprintu.

Správa dluhu způsobeného chybami v rámci podniku

Organizace, která přechází na kulturu, kde se dluh průběžně eliminuje, řeší následující otázku: Jak dostanete týmy, abyste snížili počet chyb, aniž byste jim přesně řekli, co dělat? Vedení chce, aby se tým změnil, ale dává týmu autonomii, aby určil, jak se mění. Jednou z možností je použít ochrannou krytku na hmyz.

Představte si například limit chyb se třemi chybami na inženýra. Proto by tým 10 lidí neměl mít v backlogu chyb více než 30 chyb. Pokud je tým nad svým limitem, mělo by přestat pracovat na nových funkcích a snížit počet chyb pod stanovený limit. Očekává se, že tým bude vždy pod limitem, ale tým se rozhodne, jak to hodlá udělat. Limit na počet chyb zajišťuje, aby týmy nehromadily dluh z chyb příliš dlouho. Tým se může poučit z chyb, které vedou k tomu, že se chyby inicializují.

Nezapomeňte, že limit počtu chyb představuje chyby v backlogu chyb. Nezahrnuje nalezené chyby a opravené ve sprintu, ve kterém se vyvíjí funkce. Tyto chyby se považují za nedokončenou práci, nikoli dluh.

I když chyby přispívají k technickému dluhu, nemusí představovat všechny dluhy.

Špatný návrh softwaru, špatně napsaný kód nebo krátkodobé opravy můžou přispět ke technickému dluhu. Technický dluh odráží dodatečnou vývojovou práci, která vzniká ze všech těchto problémů.

Sledujte práci na řešení technického dluhu jako PBI, uživatelské příběhy nebo chyby. Pokud chcete sledovat pokrok týmu při řešení technického dluhu, měli byste zvážit, jak zařadit pracovní položku do kategorií a podrobnosti, které chcete sledovat. Značky můžete přidat k libovolné pracovní položce a seskupit je do kategorie výběru.

Role Scrum Mastera

Scrum Masters pomáhá vytvářet a udržovat zdravé týmy pomocí procesů Scrum. Vedou, koučují, učí a pomáhají Scrum týmům ve správném používání Scrumových metod. Scrum Masters také působí jako agenti změn, kteří pomáhají týmům překonat překážky a řídit tým směrem k významnému zvýšení produktivity.

Mezi základní zodpovědnosti scrum master patří:

  • Podporu týmu, aby přijal procesy Scrumu a sledoval je. Například byste neměli nechat, aby se denní schůzka Scrum stala otevřenou diskuzí, která trvá 45 minut.

  • Chraňte se před tím, aby vlastník produktu nebo členové týmu přidávali práci po začátku sprintu.

  • Vymažte blokující problémy, které brání týmu v dalším pokroku. Tato práce může vyžadovat, abyste dokončili malé úkoly, například schválení nákupní objednávky pro nový sestavený počítač nebo vyřešení konfliktu ve vašem týmu.

  • Pomozte týmu vyřešit konflikty a problémy, které vznikají, a učit se z procesu.

  • Položte otázky, které odhalí skryté problémy, a ověřte, že lidé komunikují dobře celým týmem.

  • Identifikujte a zabezpečte tým před potenciálními problémy, které se stávají hlavními problémy. Stejně jako je levnější opravit chybu hned po jeho zjištění, je také jednodušší a méně rušivé opravit problém týmu, když je malý a spravovatelný.

  • Zabraňte týmu v prezentaci neúplných uživatelských příběhů během revizního setkání sprintu .

  • Shromážděte, analyzujte a prezentujte data obchodním zúčastněným stranám, abyste ukázali, jak se tým zlepšuje a roste. Pokud například váš tým zvýšil hodnotu, kterou doručil při generování méně chyb, zviditelněte hodnotu prostřednictvím pravidelné komunikace obchodním zúčastněným stranám.

Dobrý Scrum Master má nebo rozvíjí vynikající komunikační, vyjednávací a schopnosti řešit konflikty. Aktivně poslouchají slova, která lidé říkají a napíšou. Také si poslechnou, jak doručují své zprávy, například jazyk těla, výrazy obličeje, hlasité tempo a další neverbální komunikace.

Stejně jako je levnější opravit chybu hned po jeho zjištění, je také jednodušší a méně rušivé opravit problém týmu, když je malý a spravovatelný dříve, než začne narůstat na hlavní problém.

Denní schůzky Scrumu

Denní schůzky Scrum pomáhají týmu soustředit se na to, co potřebuje udělat další den. Udržování pozornosti pomáhá týmu maximalizovat schopnost plnit závazky sprintu. Váš Scrum Master by měl vynucovat strukturu schůzky a zajistit, že začíná včas a skončí za 15 minut nebo méně.

Mezi tři aspekty úspěšných schůzek Scrum patří:

  • Všichni stojí. Stání pomáhá udržet schůzky zaměřené a krátké.
  • Začínají a končí včas a probíhají ve stejnou dobu na stejném místě každý den.
  • Každý se účastní, každý člen týmu odpovídá na tři otázky Scrumu:
    • Co jsem dosáhl od nejnovějšího Scrumu?
    • Co můžu udělat před dalším Scrumem?
    • Jaké blokující problémy nebo překážky můžou mít vliv na mou práci?

Poznámka:

Cílem schůzek scrum je stav práce, kterou je potřeba předat od jednoho člena týmu jinému členu týmu.

Členové týmu by se měli snažit rychle a stručně zodpovědět své otázky. Například:

"Včera jsem aktualizoval třídu tak, aby odrážela nový datový prvek, který jsme stáhli z databáze, a dostal jsem ho k zobrazení v rozhraní. Tento úkol je dokončený. Dnes se ujistěte, že nový datový prvek správně počítá s uloženou procedurou a dalšími datovými prvky v tabulce. Věřím, že to dnes dokážu. Potřebuji, aby někdo zkontroloval výpočty. Nemám žádné překážky nebo blokující problémy."

Tato odpověď vyjadřuje, co člen týmu dosáhl, čeho se člen týmu chystá dosáhnout, a že člen týmu by chtěl, aby vám pomohl podívat se na kód.

Kontrast s tímto dalším příkladem:

"Včera jsem pracoval na třídě a funguje to. Dnes jsem pracoval na rozhraní. Žádné blokující problémy."

Člen týmu neposkytuje dostatek podrobností o tom, na jaké třídě pracoval, ani o komponentách rozhraní, které dokončí. Ve skutečnosti slovo „splněno“ nikdy nezaznělo.

Je důležité, aby během prezentace zpráv nikdo nepřerušoval. Každá osoba musí mít dostatek času na zodpovězení těchto tří otázek.

Podrobnější a následné diskuze by se měly konat po schůzce, protože se lidé vracejí do svých stolů nebo v případě potřeby významného množství konverzací v následné schůzce.

Mnoho týmů odkládají diskuse pomocí metody "virtuální parkoviště". Když nastane téma, o kterém si člen týmu myslí, že potřebuje další diskusi, může tiše přijít k tabuli nebo flipchartu a uvést téma na 'parking lot'. Na konci schůzky tým určí, jak budou zpracovávat uvedené položky.

Sprint – kontrola schůzek

Schůzky pro kontrolu sprintu proveďte v poslední den sprintu. Váš tým předvádí každou položku backlogu produktu, kterou dokončila ve sprintu. Vlastník produktu, zákazníci a účastníci přijímají uživatelské scénáře, které splňují jejich očekávání, a identifikují nové požadavky. Zákazníci často chápou své potřeby lépe po zobrazení ukázek a můžou identifikovat změny, které chtějí vidět.

Na základě této schůzky se některé uživatelské scénáře přijmou jako dokončené. Neúplné uživatelské scénáře zůstanou v backlogu produktu. Nové uživatelské scénáře se přidají do seznamu úkolů. Obě sady příběhů jsou hodnoceny a buď odhadnuty, nebo znovu odhadnuty na příští schůzce plánování sprintu.

Po této schůzce a retrospektivní schůzce plánuje váš tým další sprint. Vzhledem k tomu, že obchodní potřeby se rychle mění, můžete využít tuto schůzku s vlastníkem produktu, zákazníky a zúčastněnými stranami a znovu zkontrolovat priority backlogu produktů.

Schůzky pro retrospektivu sprintu

Retrospektivy, když se provádějí dobře a v pravidelných intervalech, podporují průběžné zlepšování.

Retrospektivní schůzka sprintu se obvykle vyskytuje v poslední den sprintu po schůzce kontroly sprintu. V této schůzce váš tým prozkoumá provádění Scrumu a toho, co může vyžadovat úpravy.

Na základě diskuzí může váš tým změnit jeden nebo více procesů, aby zlepšil vlastní efektivitu, produktivitu, kvalitu a spokojenost. Tato schůzka a výsledná vylepšení jsou zásadní pro agilní princip samoobslužné organizace.

Poznámka:

Pokud chcete podpořit retrospektivu vašeho týmu, zvažte instalaci rozšíření Marketplace Retrospektivy. Toto rozšíření podporuje shromažďování zpětné vazby k milníkům projektu, uspořádání a stanovení priorit zpětné vazby a vytváření a sledování úkolů, které vašemu týmu pomůžou v průběhu času zlepšit.

Zaměřte se na tyto oblasti během retrospektivy týmového sprintu.

  • Problémy, které ovlivnily obecnou efektivitu, produktivitu a kvalitu vašeho týmu

  • Prvky, které ovlivnily celkovou spokojenost vašeho týmu a tok projektu

  • Co způsobilo, že položky backlogu jsou neúplné? Jaké akce může tým provést, aby se těmto problémům v budoucnu zabránil?

    Představte si například tým, který měl několik úkolů, které by mohl udělat jenom jeden jednotlivec v týmu. Izolované odborné znalosti vytvořily kritickou cestu, která ohrožuje úspěch sprintu. Jednotlivý člen týmu vložil další hodiny, zatímco ostatní členové týmu byli frustrovaní, že nemohli dělat víc, aby pomohli. V budoucnu se tým rozhodl praktikovat eXtreme Programming, aby se tento problém časem vyřešil.

Jako tým se snažíme určit, jestli se má jeden nebo více procesů přizpůsobit, aby se minimalizoval výskyt problémů během sprintu.

Váš tým možná bude muset provést určitou práci, aby bylo možné provést vylepšení. Například tým, který zjistil, že byl negativně ovlivněn příliš mnoha neúspěšnými sestaveními, se rozhodl pro implementaci kontinuální integrace. Vzhledem k tomu, že nechtěli narušit proces, trvalo několik hodin, než si vytvořili zkušební build, než ho zapnuli v produkčním buildu. Pro reprezentaci této práce vytvořili špičku a uspořádali ji proti zbytku backlogu produktu.