ÚvodBlogAgilní Business Intelligence, díl 4: sprint
Agilní Business Intelligence, díl 4: sprint
V minulém díle jsme psali o tom, jak vypadá agilní tým, jak by měl probíhat úvodní dvoudenní workshop a definice projektové vize. Dnes se již zaměříme na to, co po workshopu následuje – samotnou implementaci. Implementace probíhá formou tzv. sprintů – dvou až třítýdenních iterací, ve kterých se neustále opakuje 5 fází:
Uživatelská konference
První půlden sprintu. Jde o setkání agilního týmu, byznys vlastníka a dalších zainteresovaných osob, na kterém jsou vybrány a do většího detailu prodiskutovány uživatelské příběhy s nejvyšší prioritou, který by byznys vlastník rád v rámci aktuálního sprintu vyřešil. Příběhy jsou vybírány ze zásobníku, který vznikl v průběhu definice projektové vize, ale protože podstatou agilního vývoje je flexibilita, byznys vlastník může příběhy podle svého uvážení přidávat nebo odebírat podle aktuálních priorit. Rozsah uživatelských příběhů pro sprint by měl být o něco větší, než je kapacita týmu (náročnost příběhů je v této fázi odhadována spíše intuitivně). Následně tým prodiskutuje jednotlivé příběhy, odhadne jejich náročnost formou relativních bodů (do většího detailu rozebereme v jednom z dalších dílů) a vybere konečný seznam uživatelských příběhů, které se v daném sprintu zaváže dodat.
Plánování
Druhý půlden sprintu. Agilní tým podrobněji rozpracuje uživatelské příběhy a vytvoří z nich úkoly, u kterých může provést časový odhad, aby se ujistil, že vybrané příběhy ve sprintu dokáže dodat (pokud ne, může se vrátit k vybírání příběhů, ale měl by přehodnotit svůj proces bodování). Úkoly jsou popsány několika větami a mohou zahrnovat analytické, vývojové, testovací a další činnosti.
Vývoj
Implementace začíná druhý den sprintu. Samotná implementace v agilních projektech vypadá odlišně, než jak jsme zvyklí z waterfall projektů – v týmu nefiguruje manažer, který by ostatním zadával úkoly. Úkoly (vytvořené v předchozí fázi) jsou na projektové nástěnce a každý člen týmu si z nich vybírá, na čem bude pracovat – tým se fakticky organizuje sám podle svých možností. Když si vývojář vybere úkol, napíše na něj své jméno a úkol na nástěnce přesune do sekce rozpracovaných aktivit. Po dokončení úkolu jej přesouvá mezi dokončené a vybírá si další. Celý tým tak má průběh sprintu neustále na očích, může včas rozpoznat problémy a flexibilně přesouvat síly, aby byly všechny úkoly včas dokončeny. Metodiky agilního vývoje obsahují další techniky pro efektivní vývoj, jako je párové programování, průběžný refaktoring kódu, vývoj řízený testy, automatizace rutinních aktivit a další, o kterých si více řekneme v následujících kapitolách.
Demo
Poslední den sprintu nastává velký okamžik - předvedení hotového produktu byznys vlastníkovi a uživatelům. Byznys vlastník prochází seznam příběhů, které se tým zavázal dodat a vyhodnocuje, zda splňují požadavky nebo nikoliv. Příběhy může akceptovat, akceptovat s připomínkami, které jsou evidovány jako technický dluh a prioritně řešeny v dalším sprintu, nebo neakceptovat. Neakceptované příběhy se vracejí do zásobníku a mohou (a nemusí) být zařazeny do sprintu dalšího.
Retrospekce
Po předvedení výsledků byznys vlastníkovi se tým opět sejde a vyhodnotí, co v rámci sprintu fungovalo, co nefungovalo a jaká opatření zavést k tomu, aby se problémy neopakovaly. Tímto způsobem se tým neustále učí a zefektivňuje svou práci, takže později může být schopen zvyšovat svou kapacitu.
Výsledkem sprintu musí být funkční řešení, které je možné předat k používání uživatelům. Reálně nasazení nové verze může, ale nemusí proběhnout po každém sprintu, je možné definovat delší nasazovací cyklus.
V další kapitole si něco řekneme o agilním plánování a relativních odhadech náročnosti uživatelských příběhů.
autor: Jakub Holubec
Chcete se dozvědět více o agilním řízením? Přijďte na náš Workshop agilního řízení. Workshop pořádáme pro firmy i pro jednotlivé zájemce.