Zjistěte více o tom, jak Atlassian plánuje pomocí sprintu

08.01.2015 |  a poznejte další tipy pro plánování práce

 

Tento článek je pokračováním článků o agilních technikách Atlassian. Každý další rok se svět softwaru mění, posouvá se dále a vždy nám slibuje, že přináší lepší software. Atlassian je do značné míry závislý na agilních technikách plánování sprintu, minimalizujících překvapení při realizaci a celkově zajišťující kvalitnější kód. Pojďme si projít čtyři principy plánování ve sprintu a najděte si velmi užitečné tipy.

 

Krok 1: Zkontrolujte si vaše plány ještě dříve, než bude první schůzka

Čas běží rychleji, než si myslíme. Je dobrým zvykem aktualizovat plány svých projektů. Plán stanoví rámec pro dva důležité pojmy: agilní eposy a verze, které jsou základem pro agilní plánování programů a poskytování pomoci při sledování práce v delším období. Ujišťujte se vždy, že je plán aktuální, že je viditelný pro celý tým, a že eposy a verze jsou správně uvedeny uvnitř JIRA ještě před plánování schůzky prvního sprintu.

 

 

Krok 2: Setkání před první schůzkou

Plánování ve sprintu zahrnuje dva klíčové úkoly: kontrolu nevyřízených požadavků a rozhodování o tom, které úkoly budou dokončeny v příštím sprintu. Atlassian zjistil, že nevyřízená přání a úkoly se nejlépe řeší případ od případu ještě před vlastním plánování sprintu. Tato schůzka před schůzkou je volitelná pro celý vývojový tým.

Řízení nevyřízených přání a úkolů údržujte v rozumném množství, kdy upřednostňujte všechny pracovní položky, přičemž nejdůležitější kroky pro konkrétní dílo zahrnuje plná kontrola realizačního vývojového teamu, který má odhady a kompletní zadání pro každou pracovní položku.

Týmy Atlassian zpracovávají nevyřízená přání a úkoly pár dní před plánováním sprintu. Naplánujte 30 minut ke schůzce navíc pro čas na třídění problémů, které budou řešeny s největší pravděpodobností v příštích dvou sprintech. Někdy zjistíte, že položky, které nemají dost detailních informací a detailní zadání nemohou být provedeny nebo potřebují více kontextových informací od vlastníka produktu. V kontrole spočívá krása péče o počet nevyřízených úkolů v předstihu. Chybějící informace pak mohou být doplněny mezi schůzkami, takže neblokují čas realizace a nezpůsobjí ztráty času během realizace a v průběhu samotného plánování sprintu. Takto péče o nevyřízené úkoly dává týmu více času při plánování sprintu a dovoluje zvážit své možnosti pro každý sprint a určuje položky pro příští sprint, podle aktuální potřeby.

Příklad: Některé týmy bojují s odhady času. Plán jednotlivých bodů poskytuje pevný rámec pro odhad práce. Zapojte tým do činnosti zvané tzv. tichý odhad. Zkuste cvičení, kdy umístíte hodnoty (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) ve sloupcích na bílou tabuli. Pak se zeptejte svého teamu, ať umístí jednotlivé úkoly ve sprintu do sloupců náročnosti, kde si myslí, že je vidí nejpřesněji. Většina úkolů vás jako team bude táhnout k jednomu číslu, a pokud dojde k neshodě nad hodnotou pro daný úkol, je čas otevřít diskusi o tom, proč tomu tak je. Může tak dojít k odhalení potenciálních rizik a jejich vyřešení v čas.

 

Krok 3: Schůzka nad plánem aktuálního sprintu

Zaměření se na plánovací sprint dovoluje stanovení a dohodnutí sprintu cílového množství práce, kdy tým věří, že daný objem práce bude moci v průběhu sprintu objektivně dokončit. Majitel produktů, scrum mistr a celý vývojový tým u všech úkolů očekává, že všichni budou pracovat naplno a jako team. Atlassian doporučuje se pravidelně a průběžně věnovat plánování ve sprintu a to minimálně jednu hodinu každý týden práce ve sprintu věnovat plánovací schůzce pro lepší koordinaci prací. Nebo například začněte s dvouhodinovými plánovacími schůzkami ohledně plánování ve sprintu, aby jste pokryli další dvoutýdenní sprint. V ideálním případě naplánujte plánování ve sprintu na začátku týdne. Následně je výkon a funkčnost týmu méně narušena než při plánování před víkendem.

 

V praxi ověřené zkušenosti: neplánujte sprint retrospektivy a plánovací setkání ohledně sprintu dohromady. Dejte teamu dostatek místa pro retrospektivy a účinném přispění každého člena k plánování ve sprintu, nejlépe přestávkou mezi jednámi.

 

Na začátku schůzek optimálně scrum mistr představí veškeré relevantní akční položky z týmu retrospektivy k řešení. Dále, majitel produktu vydává aktualizace daného produktu a to tak, že všichni najednou řeší stejné táma a udržují svojí pozornost k danému tématu a jsou pozorní.

Po jednání je následně odpovědností majitele produktu zahájit skutečné plánovácí schůzky. Majitel produktu by měl znát a používat průměrnou rychlost práce v týmu (pro množství práce obvykle řešené ve sprintu), sestavit doporučenou sadu úkolů ve sprintu.

 

Majitel produktů by měl vzít v úvahu tyto tři faktory:

 

  • svátky, osobní prázdniny a již naplánované akce v teamu
     
  • prioritizovat úkoly v seznamu nevyřízených (ideálně řídit jejich samotné pořadí řešení)
     
  • zajistit, že podstata úkolů a práce dostane výrobek blíže k jeho konečnému cíli

 

Doporučení: vlastník výrobku můžete použít značky ve sprintu pro výpočet rychlosti zpracování.


 

V případě, že tým je nový a nemá stanovenou rychlost postupu prací, měl by majitel produktu nebo cílového řešení/výrobku navrhnout sám očekávaný průběh prací ve sprintu. Současně se může jednat o cvičení koordniace a akceschopnosti teamu, protože je to důležité znát možnost a reakce každého člena. Zpočátku bude tým využívat svého nejlepšího úsudku s ohledem na prognózy, a pracovat přes několik sprintů cestou pokusů a omylů. Následně se průměrná rychlost práce celého teamu ustálí a bude to znát i v rychlosti grafu práce v JIRA v číselných hodnotách.

 

 

Poté, co majitel pruduktu má své představy o prognózách práce ve sprintu daného teamu, může pro daný tým potvrdit (a / nebo upravit) plán činnosti dle očekávání ve sprintu.

 

Doporučení: Tým by měl zvážit způsoby, jak snížit množství technických dluhů svojí dodávky řešení s každým sprintem. Je dobré vytvořit si rychlý filtr, který zvýrazní chyby v týmu nevyřízených úkolů, co je snadný způsob, jak upozornit na významné chyby, a které je třeba ohlídat ve sprintu, jak tým pokračuje v práci na různých oblastech kódu. Rychlý filtr “Technický dluh" používá omezení pohledu na chyby v poli "typ chyby” pomocí JQL. Stačí do rozšířeného dotazu JQL zahrnout další typy polí podle potřeby.

 

 

Dalším krokem při plánování sprintu, je projít definice a popisy, které práce jsou nutné k dokončení každého úkolu. Vzhledem k použití plánů týmu se ujistěte, že někdo zachycuje klíčové body každé změny v JIRA. Jde o důležité rozhodnutí, jehož důvody jsou snadno vidět později. Tým by měl zvážit následující otázky:

 

  • Změnila se má definice zadání od té doby, kdya bylo zadání vytvořeno?
    Obsahuje definice nové kontextové informace, které musí tým vzít v úvahu?
     
  • Je odhad pracnosti stále platný? Souhlasil celý tým s odhady pracnosti?
    Pokud tomu tak není, scrum mistr by měl provést celý tým procesem opětovného odhadu očekávatelné pracnosti.
     
  • Jaké úkoly jsou nutné k dokončení tohoto zadání?
    Pomocí dílčích úkolů, které pomáhají paralelizovat práci a optimalizovat tok jejího řešení. Rozdělením práce v teamu na jedinečné částí práce podporující dořešení těchto úkolů zcela nezávisle.
     
  • Jaké jsou důsledky pro testování tohoto úkolu?
    Jak můžeme automatizovat testování? Nezapomeňte, že samotné ruční testovací skripty jsou v podstatě technickým dluhem.
     
  • Jsou nějaké specializované sady a typy dovednosti nutné?
    Jak můžeme optimalizovat čas na specialisty/odborníky bez blokování zbytku týmu?
     
  • Jaký vliv na architekturu výrobku má celé jeho řešení?
    Existují konkrétní lidé v týmu potřební pro zapojení do projektu a pro přezkoumání kódu?
     
  • Existují nějaké souvislosti mezi příběhy v průběhu delivery?
    Můžeme dokončit všechny práce v průběhu sprintu daného deliveery s ohledem na tyto závislosti?

 

Je tu silné pokušení spěchat prostřednictvím tohoto podrobného cvičení. Dobré plánování se vyplatí a přináší výhody, jakmile se již samotný sprint spustí. Základem je pochopit, jak stihnout plánované práce ve scrumu pomocí zapojení celého týmu. Je důležité, aby se všichni členové teamu dozvěděli potřebné informace a byli s nimi obeznámeni a měli pocit osobní odpovědnosti, jakmile je samotný plán vytvořen.

 

Doporučení: při plánování sprintu je snadné pohybovat úkoly z a do sprintu, tak jak tým vytváří svojí prognózu vývoje sprintu. Stačí kliknout pravým tlačítkem myši na úkol a přesunout jej dovnitř nebo ven ze sprintu.

 

 

4. Připravit, pozor, start!

V této fázi by měl být tým být spokojen s prognózou celého sprintu. Na konci plánování sprintu je dobrým zvykem si vyžádat slovní souhlas od každého člena teamu v místnosti v duchu očekávání cílů a samotného delivery včetně souhlasu se zvolenou cestou k cíli. Také je dobré ověřit, že každý člen týmu má alespoň jeden úkol a nedošlo k duplikaci přidělené práce.

Zapojení teamu a morálka bude přirozeně kolísat v průběhu od sprintu ke sprintu. Tyto rozdíly se často objeví při plánování sprintu, ale odolejte pokušení jednotlivé sprinty impulsivně měnit. Místo toho použijte retrospektivu týmu pro pochopení všech problémů, které mají vliv na morálku v teamu. Týmy, které rychle reagují na kulturu a rozvoj obav jsou šťastnější a produktivnější, a hlavně jsou autory lepšího kódu.

 

V případě dotazů nás neváhejte kontaktovat na obchod@onlio.com nebo kontaktujte společnost Atlassian na marketplace_zavináč_atlassian.com.

Pro lokální podporu neváhejte kontaktovat odborníky na produkty Atlassian ve společnosti Onlio.

Pro další informace o novinkách Atlassian a JIRA6 sledujte web www.myJIRA.cz a @myJIRAcz na Twitteru. Kontakty: tel. ČR +420222744766 / tel. SR +421233889033 / atlassian_zavináč_onlio.com.

 

Za team Atlassian,

Štěpán Martínek

senior marketing communications manager v Onlio

 

Zpět