Scrum Guide | 28. Sprint ve Scrumu

Více menších událostí tvoří Sprint v Scrum. Sprints společně vytvářejí cestu zaměřenou na vývoj a vydání produktu. Každý Sprint má specifický cíl Sprintu a Sprint Backlog, který spravuje vývojový tým.

Co je Sprint v Scrum – obsah:

1. Sprint v Scrum – Úvod
2. Struktura Sprintu v Scrum
3. Sprints a tři pilíře empirismu
4. Transparentnost
5. Inspekce
6. Adaptace
7. Jaké změny provést během Sprintu?
8. Sprint v Scrum – Shrnutí

Co je Sprint v Scrum?

Sprint je největší z událostí v Scrum, o kterém jsme psali v tomto článku. Sprints následují nepřetržitý cyklus od začátku do konce práce na produktu. A každá iterace přibližuje tým k dosažení cíle produktu.

Každý Sprint má specifický cíl Sprintu, aby zajistil konzistenci v práci vývojového týmu. Má podobu obchodního cíle a odpovídá na otázku “Proč?”, “K jakému účelu?” nebo “Proč?”.

Pracovní postup Sprintu je zdokumentován v Sprint Backlogu, který uvádí práci potřebnou k dosažení cíle Sprintu. Jeho podrobný popis lze nalézt zde.

Struktura Sprintu v Scrum

Každý Sprint má specifickou strukturu a zahrnuje následující události:

• Plánování Sprintu – Sprint začíná. Během této události si Scrum tým vybírá plánovanou práci z Product Backlogu, která má být provedena v novém Sprintu
• Daily Scrum – denní událost, kde vývojáři plánují úkoly na den
• Revize Sprintu – otevřená pro zúčastněné strany, koná se poslední den Sprintu. Jejím cílem je shrnout Sprint z hlediska pokroku na produktu
• Retrospektiva Sprintu – závěrečná událost Sprintu, kde Scrum tým diskutuje o způsobech práce a nápadech na zlepšení

Opakování událostí Sprintu podporuje implementaci dobrých organizačních praktik. Jinými slovy, Scrum tým implementuje rutiny nezbytné pro efektivní plánování a při práci věnuje pozornost problémům, které mohou být projednány na příslušných událostech.

Sprints a tři pilíře empirismu

Sprints umožňují Scrum týmu rozdělit práci na produktu do rovných časových segmentů trvajících maximálně měsíc. Tento pevný rámec posiluje tři pilíře empirismu:

• transparentnost
• inspekce
• adaptace

O třech pilířích empirismu a jejich roli v Scrum jsme psali podrobněji zde. Dnes se však podíváme na to, jak se vztahují k Sprintu a jeho struktuře.

Transparentnost

Rozdělení práce do Sprintů zvyšuje transparentnost, protože všichni zúčastnění mohou získat potřebné informace o stavu práce na produktu v každém Sprintu. Plánování Sprintu a Revize Sprintu, začátek a konec Sprintu, spolu s aktualizací Product Backlogu, poskytují všem zúčastněným cenné informace o aktuálním stavu produktu.

Inspekce

Rozdělením práce do Sprintů je možné často sledovat její pokrok. To podporuje neustálé identifikování problémů ve dvou klíčových oblastech. Tyto oblasti jsou:

• problémy související s dosažením cíle produktu – na začátku a na konci Sprintu, tj. během Plánování Sprintu a Revize Sprintu
• překážky v práci Scrum týmu – během denních schůzek a na konci každého Sprintu, tj. během Daily Scrum a Retrospektivy Sprintu

Adaptace

Adaptace je velmi důležitou součástí práce Scrum týmu, protože umožňuje řešit problémy identifikované během inspekce. Během každého Sprintu poskytují Daily Scrum a Retrospektiva Sprintu bezpečný prostor k diskusi o tom, jak zlepšit Scrum tým. Implementace navrhovaných řešení probíhá okamžitě nebo na začátku dalšího Sprintu.

Plánování Sprintu a Revize Sprintu vytvářejí bezpečný prostor pro diskusi týkající se cílů a metod jejich dosažení. Dobrý samořídící Scrum tým úspěšně zjistí, co a jak implementovat pro další Sprint.

Jaké změny provést během Sprintu?

Každý Sprint ponechává dostatek prostoru pro Scrum tým, aby zlepšil a improvizoval způsob své práce. Proto je důležité identifikovat, co změnit během Sprintu. Scrum Guide neposkytuje seznam takových změn. Nicméně, pojem empirismus poskytuje pokyny, kterými se lze řídit a přizpůsobit způsobu, jakým konkrétní Scrum tým pracuje.

1. Všechny změny mohou ohrozit dosažení cíle Sprintu. Podle prvního pravidla nelze během Sprintu například snížit počet úkolů v tomto Sprintu nebo výrazně změnit jejich charakteristiky. Sprint je úzce spjat s cílem Sprintu. Proto, když se cíl změní, měli bychom Sprint zrušit. To se však stává jen zřídka, protože jediným důvodem, proč Sprint selže, je, když se cíl stane zastaralým. Mějte na paměti, že rozhodnutí o ukončení Sprintu náleží výhradně Product Ownerovi.
2. Kvalita práce nesmí být ohrožena. Toto pravidlo má zabránit tomu, aby práce provedená během Sprintu nebyla Incrementem, protože nesplňuje definici dokončení. Snížení kvality práce může vést k tomu, že cíl Sprintu bude zdánlivě splněn, ale způsob, jakým jsou jednotlivé úkoly dokončovány, nesplňuje standardy kvality stanovené organizací nebo požadované zúčastněnými stranami.
3. Product Backlog může být podrobnější. Během práce na produktu se znalosti o něm zvyšují. Proto se detail úkolů k provedení přirozeně zvyšuje. Proto je během Sprintu přijatelnou a dokonce doporučenou změnou podrobněji zpracovat Product Backlog.
4. Rozsah práce může být objasněn nebo znovu vyjednán. Tato změna, stejně jako předchozí, zahrnuje rostoucí porozumění povaze vykonávané práce. Vývojový tým to může provést v konzultaci s Product Ownerem. Základní podmínkou pro její zavedení je však absence konfliktu s principy 1. a 2.

Sprint v Scrum – Shrnutí

Sprint je cyklická událost Scrum, která obsahuje všechny ostatní. Má podřízený cíl Sprintu oddělený od cíle produktu. A Sprint Backlog je odlišný od Product Backlogu. Povaha Sprintů je cyklická. Pevná délka Sprintů napomáhá udržování dobrých pracovních praktik a podporuje tři pilíře empirismu. Během Sprintu nemůže Scrum tým změnit svůj cíl. Může však upřesnit Product Backlog a jak se znalosti zvyšují, upřesnit a vyjednat rozsah práce.

Pokud se vám náš obsah líbí, připojte se k naší komunitě pilných včel na Facebooku, Twitteru, LinkedInu, Instagramu, YouTube, Pinterestu.