Sdílet prostřednictvím

Scrum a osvědčené postupy

  • Článek

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. Vlastník produktu sdílí informace a odpovídá na všechny otázky, které váš tým obsahuje o těchto příbězích. 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 účastníky.

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 pří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ů.

Pří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, přijde druhý. 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 vedoucí konzultant pracující pro Avanade Nizozemsko.

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 příležitosti zpoždění) nebo jinými riziky projektu by měly být přiřazeny 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é určíte podle priorit. 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 určíte prioritu chyby, přiřaďte ji vývojáři. Vývojář pak může prozkoumat a určit, jak implementovat opravu.

Správa technického dluhu

Zvažte správu panelu chyb a technického dluhu jako součást celkové sady aktivit průběžného zlepšování vašeho týmu. Můžete najít tyto zdroje informací, které vás zajímají:

Tipy z zákopů: Správa chyb

Agilní správa chyb: Ne Oxymoron
Gregg Boer, Principal Program Manager, Visual Studio Cloud Services ve společnosti Microsoft

Vyřešte všechny známé dluhy chyb při každém sprintu.

Každý sprint se tým podívá na všechny chyby, které zůstávají v backlogu chyb, a vyhrazuje kapacitu, aby získala známou sadu chyb směrem dolů na nulu nebo téměř 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. Plánování kapacity proti známé sadě chyb zvyšuje deterministické plánování sprintů, což zvyšuje jejich šanci splnit závazky. 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 chyb 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 zmožnostích

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 limitem, očekává se, že zastaví práci na nových funkcích a dostane se pod limit chyby. Očekává se, že tým bude vždy pod limitem, ale tým se rozhodne, jak to chce udělat. Limit chyby zajišťuje, aby týmy nepřenesly dluh chyb příliš dlouho. Tým se může poučit z chyb, které způsobí, že se chyby vloží na první místo.

Nezapomeňte, že limit chyby 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 vrácenou 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ých scénářů nebo chyb. 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 do libovolné pracovní položky přidat, abyste je seskupily do kategorie podle svého výběru.

Role scrum masteru

Scrum Masters pomáhá vytvářet a udržovat zdravé týmy pomocí procesů Scrum. Řídí, trenéra, učí a pomáhá týmům Scrum ve správném zaměstnání metod Scrumu. 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.

  • Ochrana před vlastníkem produktu nebo členy týmu před přidáním práce po zahájení 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ý počítač sestavení nebo vyřešení konfliktu v rámci 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ý.

  • Znemožní týmu prezentovat neúplné uživatelské scénáře během schůzky kontroly 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 mají nebo rozvíjet vynikající komunikaci, vyjednávání a konfliktní řešení dovedností. 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í. Postání pomáhá udržet si schůzku zaměřenou a krátkou.
  • Začínají a končí včas a probíhají ve stejnou dobu na stejném místě každý den.
  • Každý člen týmu odpovídá na tři otázky Scrumu:
    • Co jsem udělal 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 moji 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. Pří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 toho dnes dokážu dosáhnout. 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í, na které se dokončí. Ve skutečnosti, slovo, které se nikdy nedostavilo.

Je důležité, aby během sestavy nikdo nepřerušil. 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ů zpozdí diskuze pomocí metody "virtuální parkoviště". Jak se objeví téma, že člen týmu si myslí, že potřebuje další diskusi, může tiše chodit na tabuli nebo překlopit a uvést předmět na parkovišti. 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 backlogu. Obě sady scénářů se řadí a odhadují nebo znovu odhadují při 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ů.

Retrospektivní schůzky sprintu

Retrospektivní, když se provádí 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 podporovat retrospektivní využití vašeho týmu, zvažte instalaci rozšíření Retrospectives z Marketplace. 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.

Podívejte se na tyto oblasti během retrospektivních akcí 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 se stalo kvůli neúplným položkám backlogu? 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 procvičit programování eXtreme, aby tento problém v průběhu času pomohl opravit.

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 je negativně ovlivněno příliš mnoha neúspěšnými buildy, se rozhodl implementovat kontinuální integraci. 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.