Obsah
1 Úvod 6
2 Co je Scrum 8
2.2 Přehled artefaktů 8
Sprint 8
Product Backlog 9
Product Owner 9
Sprint Backlog 9
Scrum Team 10
Scrum Master 10
Burndown Chart 11
2.3 Vlastnosti Scrumu 11
2.4 Procesní rozbor 13
3 Systém pro Scrum 19
4 Návrh aplikace 21
4.2 Zaměření a cíle 21
4.3 Doménový model 23
4.4 Funkční případy užití 27
Správa Sprintů 27
Řízení úkolů 32
Správa produktového Backlogu 34
Správa projektů 38
Správa externích podmínek 40
4.5 Životní cykly požadavků a úkonů 43
Životní cyklus PB položky 43
Životní cyklus SB položky 45
4.6 Pokročilé funkcionality 47
Task Tracking 47
Risk Management 49
Analytické funkce : 49
Správa dokumentů 55
Automatické notifikace 58
5 Návrh architektury 60
6 Závěr 62
Seznam použitých zdrojů 64
Seznam použitých zkratek 66
⦁ Úvod
Tato práce se zabývá problematikou maximalizace efektivity projektového řízení za pomoci podpůrné softwarové aplikace. Obsahem práce je konkrétně návrh aplikace pro podporu řízení projektů podle metodiky Scrum.
Procesní metodika Scrum je v současné době moderní a dynamicky se rozšiřujícím nástrojem. Je v jistém ohledu revoluční a je tudíž velmi diskutovanou. Její koncepce je diametrálně odlišná od dosavadních metodik, což na ni strhává pozornost mnoha subjektů, a díky svým přednostem je častou volbou projektových manažerů. Označuje se jako agilní metodika vývoje. Pokud je správně aplikována, zajišťuje velmi rychlý efektivní vývoj s minimalizací rizik a s maximální efektivností práce.
Scrum je velmi často administrován s využitím velmi jednoduchých prostředků bez pokročilých funkcí pro zkvalitnění celého procesu.
Hlavním cílem této práce je návrh aplikace s maximální přidanou hodnotou, nikoli aplikace, která by proces řízení pouze administrovala. Navržená aplikace by měla disponovat vlastnostmi, které aktivním způsobem zlepší řízení projektů a plně podpoří silné stránky Scrumu. Komplexní návrh by měl zároveň zajistit universální použitelnost aplikace a napomoci tak i k rozšíření celé metodiky na projekty, kde by Scrum bez nadstandardní podpory nemohl být aplikován. Jedná se například o větší kritické projekty, kdy je kladen mimo jiné velký důraz na přehled a kontrolu nad průběhem projektu ze strany zadavatele.
V této oblasti již vznikla řada aplikací jak komerčních tak i Open Source. Komerčních řešení není mnoho a nejsou většinou volně dostupná. Stávající Open Source aplikace jsou příliš jednoduché a poskytují jen základní administrativní funkčnosti. V každém případě tato problematika skýtá ještě mnoho prostoru a možností k návrhu originálních koncepcí.
Aplikace implementovaná na základě této práce by mohla dojít velké obliby díky své praktičnosti a jistě by mohla být přínosnou volbou na některém z tisíců projektů, na kterých se v dnešní době Scrum zavádí.
Zdrojem pro tuto práci byl rozbor specifikací celé metodiky, dále pak studie a praktická doporučení pro aplikování Scrumu. Po detailní analýze všech dostupných informací a porozumění silných a slabých stránek samotného procesu se postup práce zaměřil na identifikování míst, která je možné podpořit a zdokonalit s využitím IS/ICT. Zde se nejvíce nabízí zavedení analytických funkcí, pro které je využití ICT nezbytné a které mohou mít obrovský přínos. Specifikace Scrumu definuje své elementární analytické nástroje, které však kvůli své jednoduchosti mohou podávat nepřesné či klamavé informace. Dále je nutné se zaměřit na potenciální dopad slabých stránek administrativní části aplikace na vykonávání Scrumu.
⦁ Co je Scrum
Scrum je agilní metodika vývoje. Její název pochází z angličtiny a je odvozen z těsně sepjaté formace, kterou utváří sportovní týmy při hře zvané ragby – scrum.
Tato metodika je definována jako vývojový proces, jinými slovy jako obecná metoda projektového řízení. Zaměřuje se zejména na vývoj IS/ICT aplikací, je však aplikovatelná i na projekty z jiných odvětví. Specifikace procesu obsahuje popis systému, který proces definuje. Tento systém zahrnuje několik rolí lidských zdrojů a několik administrativních artefaktů. Proces se pak dělí na několik dílčích částí, z nichž některé jsou označovány jako ceremoniály.
Ve stručnosti lze celý vývojový proces popsat následovně. Výchozím bodem procesu je fronta požadavků, která za pomocí přiřazených priorit tvoří zároveň variabilní dlouhodobý projektový plán. Přibližně každý měsíc se započíná nová iterace vybráním požadavků s nejvyšší prioritou, které se rozpadnou na atomické úkoly a vytvoří se tak detailní plán pro nadcházející měsíc, avšak bez priorit ani pořadí. V průběhu iterace se provádí každodenní kontrola stavu průběhu prací a přiřazení nových úkolů lidským zdrojům. Tím je zajištěno hlavně včasné identifikování rizik vznikajících za běhu projektu.
Bližší specifikace jednotlivých artefaktů a podprocesů je podrobně rozepsána dále.
⦁ Přehled artefaktů
Sprint
Základní iterační jednotku Scrumu tvoří takzvaný Sprint. Sprint je v podstatě časový interval o určité, předem jasně definované délce, během kterého jsou vykonávány naplánované úkoly. Nejčastěji se volí 30-ti denní interval, mohou však nastat i případy, kdy je v závislosti na potřebách projektu délka Sprintu určena kratší. Nejméně však dvoutýdenní. Vždy by měla být dodržena podmínka, že všechny Sprinty daného projektu budou trvat přibližně stejně dlouhou dobu.
Product Backlog
Důležitým scrumovským dokumentem je Product Backlog, který představuje frontu pro správu požadavků na funkcionality nejvyšší úrovně abstrakce. Zároveň však realizuje i hrubý projektový plán. Požadavky jsou zde řazeny prioritně tak, že nejvýše stojí požadavky s nejvyšší přiřazenou prioritou. Tím je zajištěno, že budou implementovány přednostně. Flexibilita Scrumu spočívá v tom, že umožňuje reagovat na změny požadavků ze strany sponsora projektu. Je to dáno tím, že podporuje možnost přidávat či obměňovat obsah produktového Backlogu až do okamžiku zařazení požadovaných funkcionalit do Sprintu. V rámci provádění změn v produktovém Backlogu je samozřejmě možné aktualizovat priority zařazených požadavků.
Product Owner
Product Backlog je volně přístupný. Hlavní osobou, která odpovídá za jeho tvorbu a správu, je Product Owner. Ten reprezentuje zadávající stranu, například zákazníka nebo i někoho uvnitř firmy (v případě interního projektu).
Z produktového Backlogu jsou požadavky s nejvyšší prioritou zařazovány do Sprint Backlogu připravovaného Sprintu.
Sprint Backlog
Sprint Backlog je detailním plánem pro daný Sprint. Obsahuje soubor úkolů, které se budou realizovat. Na rozdíl od klasického plánování nejsou úkoly předplánovány na konkrétní čas a pro konkrétní pracovníky. Úkoly jsou přiřazovány dynamicky až v průběhu Sprintu. Sprint Backlog je vytvořen ve fázi plánování Sprintu, která se nazývá Sprint Planning Meeting. Plánování obnáší výběr požadavků s nejvyšší prioritou z PB a jejich detailní analýzu a návrh tak, aby výsledkem byla sada elementárních úkolů implementujících požadované funkcionality. Pracnost jednotlivých úkolů musí být jednoznačně stanovena. Optimální náročnost jednoho úkolu by neměla přesáhnout 2MD. V rámci procesu tvorby Sprint Backlogu se doporučuje provést zpětnou kontrolu, zda pracnost úkolů ve Sprint Backlogu se příliš neliší od původních odhadů v produktovém Backlogu.
Scrum Team
Skupina lidí, kteří pracují na realizaci úkolů jednotlivých Sprintů a společně tak postupně vytváří cílový produkt, se nazývá Scrum tým. Tým nemá žádného vedoucího, který by přiděloval úkoly. Veškerá organizace je v tomto směru ponechána čistě na domluvě mezi členy. Rozdělování úkolů probíhá na každodenním Scrum Meetingu. Optimální velikost Scrum týmu by se měla pohybovat v rozmezí 5 – 9 členů.
Scrum Master
Hlavní náplní role Scrum Master je podpora týmu. Jeho úkolem je zajišťovat hladký průběh celého projektu, odstraňovat možné překážky či vzniklé problémy, které brání členům týmu vykonávat vybrané úkoly. Každý den také Scrum Master svolává takzvaný Scrum Meeting, krátký sraz celého týmu, kdy by měl postupně každý člen říci co dělal předchozí den, na čem bude pracovat dnešní den a dále také, zda mu ve vykonání úkolu něco nebrání.
Na konci Sprintu organizuje Scrum Master schůzku, kde probíhá závěrečné zhodnocení uplynulého Sprintu, takzvaný Sprint Review Meeting. Na této schůzce jsou jednak zákazníkovi předváděny nové funkcionality, o které byl vyvíjený produkt rozšířen oproti stavu v minulém Sprintu. A dále je zde také vyhrazen prostor pro členy týmu, kteří se mohou vyjádřit o pozitivních či negativních událostech proběhlého Sprintu.
Scrum Master je někdy nepřesně interpretován jako coach, tedy typ manažera, který řídí a vede tým. Lépe je však pohlížet na Scrum Mastera spíše jako na moderátora.
Burndown Chart
Průběh vykonávání plánovaných úkolů daného Sprintu je pro přehledný monitoring zanášen do grafu. Na jedné ose grafu je zobrazován čas, který určuje o kolikátý den Sprintu se jedná, a na druhé ose se postupně odkrajuje práce vykonaná v daném Sprintu.
Slouží ke sledování průběhu prací na Sprintu a ke včasnému identifikování časových problémů či rezerv.
⦁ Vlastnosti Scrumu
Scrum spíše než metodikou je metodou řízení projektů. Používá se často označení „framework“, což naznačuje, že nám neudává jak se má celý projekt realizovat, ale definuje obecný proces řízení.
Scrum je zejména označován jako agilní vývojový proces. Agilní znamená hbitý. Takto označované metodiky se vyznačují dokonalým využitím a motivací lidských zdrojů. Výsledkem je pak efektivnější a rychlejší vývoj. Dá se říci, že Scrum je po této stránce rozhodně plnohodnotným representantem.
V důsledku tohoto prvního dojmu se často opomíjí druhá velmi významná vlastnost, kterou Scrum oplývá, a to je flexibilnost. Ta je nejvíce patrná v plánování a správě požadavků. Tato flexibilnost se na různé druhy projektů podepisuje různým způsobem. Všeobecně, a hlavně v případe interních projektů, je přínosem absence složitých projektových plánů, které často představují náročnou, a možná i do jisté míry zbytečnou, administrativu.
V případě dodavatelských projektů, kde existují dva oddělené subjekty dodavatel a odběratel, je flexibilita Scrumu velkým lákadlem pro vedení na straně odběratele. Ta jim totiž dává volnou ruku v definování a změnách svých požadavků. To je odlišné od jejich dosavadních zkušeností z jiných projektů, kdy jsou požadavky běžně zafixovány v počátečních fázích projektu a nelze je již měnit.
⦁ Procesní rozbor
Některé aktivity z výše uvedeného procesního modelu jsou rozepsány dále jako dílčí podprocesy kvůli jejich komplexnosti. Konkrétně se jedná o:
⦁ Vytvoření Product Backlogu
⦁ Vytvoření Sprint Backlogu
⦁ Vykonávání Sprintu
Product Owner vytvoří seznam požadavků na funkcionality cílového produktu. Jeho zodpovědností je nadefinovat takový produkt, aby jeho výsledná hodnota byla co nejvyšší a aby tedy přinášel co nejvyšší zisk. Nadefinované požadavky pak seřadí dle jejich priorit. Tímto způsobem vznikne Product Backlog, jehož správa je plně v kompetenci Product Ownera.
Tak, jak se mění situace na trhu nebo preference sponzora či uživatelů, je možné Product Backlog v průběhu projektu aktualizovat. Mohou se přidávat, odebírat nebo modifikovat zahrnuté položky. Jediné položky, se kterými již není možné manipulovat, jsou ty, které již byly zařazeny do aktuálně probíhajícího Sprintu. Takové položky jsou de facto „zmrazené“.
Jakmile Product Owner vytvoří Product Backlog, ohodnotí členové Scrum týmu jednotlivé položky dobou jejich pracnosti. Přesahuje-li pracnost některé z nich optimálně doporučenou (10 MD), provede se její rozčlenění na několik dílčích, které jsou poté zařazeny na Product Backlog namísto původní. Následně se provede aktualizace priorit položek.
Je-li Product Backlog připraven, je svolán Sprint Planning Meeting. Product Owner zde představí a detailně rozebere ty požadavky z Product Backlogu, které označil jako prioritní. Scrum tým tak získá veškeré potřebné informace pro jejich implementaci, na základě čehož se pak po týmovém projednání zaváže k dodání určitého množství. Tento konečný počet odsouhlasených požadavků se nazývá Sprint Backlog.
Dále také Scrum tým společně s Product Ownerem stanoví cíl, který je třeba v rámci daného Sprintu splnit.
Poté co je vytvořen Sprint Backlog, začne fáze vykonávání vlastního Sprintu. Jeho délka se určuje na začátku projektu a obvykle bývá třicet dnů. Členové týmu si sami přiřazují jednotlivé úkoly.
Během Sprintu se každý den ve stejnou dobu a na stejném místě schází tým k dennímu meetingu. Na základě reportů od jednotlivých členů potom Scrum Master provádí denní aktualizaci Sprint Backlogu. Scrum Master neustále přepočítává délku zbývajících úkolů do konce Sprintu a změny zanáší do grafu (do tzv. Burndown Chart).
Může nastat situace, že se tým dostane do časové tísně. Může to být například z důvodu, že byl při svém původním odhadu na začátku Sprintu příliš optimistický anebo že se při implementaci zadaných úkolů objeví nové souvislosti a přibudou tak úkoly, se kterými se v původním plánu nepočítalo. V takovém případě se přistupuje k řešení, kdy jsou po prodiskutování situace s Product Ownerem, některé požadavky ze Sprint Backlogu jednoduše odstraněny a vráceny zpět na produktový.
Na konci Sprintu svolá Scrum Master schůzi všech zainteresovaných stran (Sprint Rewiev Meeting). Meeting je rozdělen na dvě části. Začíná prezentací týmem vytvořeného inkrementu, tedy ideálně fungujícího rozšíření vyvíjeného produktu. Dále dojde k zhodnocení, zda byl nebo nebyl splněn cíl Sprintu.
V další části zůstávají na meetingu pouze Scrum tým a Scrum Master, kde společně proberou a zhodnotí proběhlý Sprint. Cílem je vytvořit zpětnou vazbu pro tým a také členy povzbudit do dalšího Sprintu.
⦁ Systém pro Scrum
Procesy Scrumu lze rozdělit do dvou částí. První se týká projektového plánování a správy požadavků. Druhá se týká řízení úkolů (Task Management).
Část projektového plánování je spojena s aktivitami týkajícími se správy obou Backlogů. Product Backlog definuje hrubší plánování spolu se správou požadavků. Na druhé straně Sprint Backlog definuje detailní plánování spolu se správou detailní analýzy a designu. Řízení úkolů je spojeno s vykonáváním samotných Sprintů, kdy si jednotliví členové týmu zadávají a vykonávají jednotlivé kroky ze Sprint Backlogu. Aplikace pro administraci Scrumu by měla respektovat toto rozdělení a obsahovat tedy odpovídající funkční moduly.
Obecně nejsou funkční požadavky na aplikaci pro podporu Scrumu nijak náročné. Samotný Scrum proces je totiž více o lidech a méně o administrativě. To znamená, aby proces byl úspěšný, musejí být dodržována veškerá definovaná pravidla zainteresovanými lidskými zdroji.
Administrativní část je vcelku jednoduchá. Když například srovnáme Product Backlog, jako seznam ohodnocený prioritami, s Gantovým diagramem využívaném v klasickém plánování a vyžadujícím použití sofistikovaných nástrojů jako je např. MS Project.
Základní administrativní aplikaci je možné implementovat jednoduše. Byly zaznamenány různé pokusy implementace za pomoci běžného SW vybavení či Open Source projektů. Jako nejzákladnější možnou implementaci lze považovat správu Scrumu v tabulkách MS Excell. Velmi jednoduchými a úspěšnými jsou implementace postavené na kombinaci DMS (Document Management System) či CMS (Content Management Systemu) spolu s nějakým ticketovacím systémem (bug report systém). Při této kombinaci DMS/CMS systém obstarává nástroj pro projektové plánování a správu požadavků. Ticketovací systém pak slouží pro řízení úkolů.
Nejvíce oblíbeným Open Source nástrojem využívaným v roli DMS/CMS je široce rozšířený projekt WIKI, který je nejznámější asi díky implementaci internetové encyklopedie Wikipedia. WIKI umožňuje snadnou správu jak obsahu, tak struktury. To ho předurčuje jako universální flexibilní nástroj pro ad-hoc implementace podobných aplikací.
V oblasti tzv. ticketovacích systémů je rovněž mnoho použitelných Open Source projektů (např. Mantis, Bugzilla, atd).
Z toho se může zdát, že využití a tedy i nákup či vývoj kompletní aplikace pro podporu Scrumu je zbytečný, jelikož je možné si vystačit s jednoduchými Open Source nástroji. Klíčovým rozdílem při implementaci speciální aplikace je její přínos ve schopnosti dodávat statistické informace a reporty. Aplikace navrhovaná v rámci této práce se tuto analytickou funkčnost snaží rozvést co nejvíce. Pro samotný Scrum jsou takové informace ohromně důležité. Slouží jako informativní a varovný nástroj jak při plánovaní tak při vykonávání Sprintů. Zejména jsou důležité pro naplnění zpětné vazby mezi jednotlivými Sprinty. V neposlední řadě jsou pak globální statistiky užitečnou informací pro sponzora daného projektu.
⦁ Návrh aplikace
⦁ Zaměření a cíle
Primárním funkčním cílem této aplikace je dodávat užitečné analytické informace. Aby byl tento cíl dosažen, musí být splněny určité klíčové předpoklady zajišťující kvalitu podkladových dat pro samotné analýzy. Zdrojovými daty jsou veškerá dynamická data administrovaná v této aplikaci. Jsou to oba Backlogy (produktový a sprintový), které obsahující informace o plánování. Dále jsou to data o průběhu Sprintů, tedy data o plnění jednotlivých úkolů implementace položek SB.
Právě data o průběhu Sprintů jsou nejdůležitější pro většinu statistik a analytických funkcí. Je tedy nutné obzvláště klást důraz na kvalitu těchto dat. Naneštěstí je jejich kvalita silně ovlivněna lidským faktorem a externími okolnostmi, jelikož jde o data, která členové týmu vyplňují na základě své každodenní práce. Zajištění kvality dat tedy znamená striktní dodržování pravidel používání aplikace. To může být obtížné zajistit a znamená to vážné ohrožení úspěšnosti implementace této aplikace. Tato práce si v rámci návrhu aplikace klade jako vedlejší cíl minimalizaci těchto negativních vlivů, proto se zaměřuje na několik rozšiřujících vlastností.
První a nejvíce náročnou funkcionalitou je zohlednění rozdílů mezi realitou a idealními podmínkami. Tato funkcionalita do jisté míry ošetřuje vliv lidského faktoru a zejména pak chrání systém před externími okolnostmi. Tato funkcionalita je realizována sofistikovaným řízením úkolů (viz Task Tracking).
Další podpůrnou vlastností je ergonomie a uživatelská přátelskost, která je důležitá pro maximální odlehčení potřebné administrativy tak, aby se aplikace nestala pro své uživatele přílišnou přítěží, zejména pro výkonné členy týmu. Primárním cílem ergonomických vlastností je podpořit uživatele v pravidelném a pečlivém vyplňování informací o provádění úkolů.
Třetí podpůrnou vlastností je automatická notifikační funkce. To znamená, že sama aplikace identifikuje důležité události, stavy a rizika v systému, a aktivně o nich informuje uživatele. Tato funkcionalita je použita napříč celým systémem a slouží například i k odhalování možných kolizí v PB. V kontextu zajištění kvality dat kontroluje a nutí uživatele k potřebným krokům. Například kontroluje, aby uživatelé nedělali prodlevy v přiřazování úkolů. Takže pokud si pracovník nepřiřadí úkol nejpozději do 6 hodin od ukončení předchozího úkolu, pak je zaslána emailová zpráva jak jemu, tak Scrum Masterovi.
Pokud budou tyto rozšiřující funkce úspěšné a zajistí vysokou kvalitu dat, pak lze očekávat velký přínos navržených analytických funkcí pro celé projektové řízení.
⦁ Doménový model
Hlavní entitou je třída Project. Každá její instance představuje jednotlivé projekty jako celky, s detailním popisem požadovaného cílového výstupu a dále s popisem funkčnosti. Pro jednoduché označování je každému projektu přiřazena zkratka, která je odvozena z vlastního názvu projektu. Například byl zadán projekt na vytvoření zákaznického portálu, který nese název Nový zákaznický portál. Pro něj je odvozena zkratka NZP.
Třída Project zde není bezpodmínečně nutná pro administraci vývojového procesu. Přináší však ohromné výhody pro velké firmy, kde může probíhat více projektů najednou. Vzhledem k tomu, že jedním z cílů této aplikace je zaměření se na analytické funkce, je práce s archivovanými daty všech uskutečněných projektů velmi užitečná zejména pro vyšší management a zároveň pro zpětnou vazbu při optimalizaci plánování a vykonávání Sprintu.
Pod třídu Project jsou zahrnuty všechny ostatní artefakty systému. Těmi jsou hlavně třídy definované v rámci samotného Scrumu. Je zde například Product Backlog Item, Sprint, Sprint Backlog Item, User a Role. Vlastní Scrum je zde pak rozšířen o třídy External Condition a Task, které usnadní a zpřehlední průběh vykonávání práce na jednotlivých položkách produktového nebo sprintového Backlogu.
Třída Task definuje, který uživatel a jak dlouho pracoval na dané položce Sprint Backlogu. Datum od – do je doplněno navíc ještě uskutečněnou pracností, která slouží jako zpětnovazebná kontrola vlastní odpracované doby každého pracovníka. Nebude tedy moci nastat situace, kdy si pracovník například vykáže, že na položce pracoval jeden den, přestože ji měl alokovanou dva dny po sobě. Pro jednotlivé úkoly nemusí přesně odpovídat vykázaná uskutečněná pracnost intervalu, po který měl člen týmu úkol přiřazen. Je to z důvodu zohlednění lidského faktoru, kdy není vyžadováno, aby si pracovník musel úkol přiřadit přesně v okamžik, kdy na něm začíná pracovat. V dlouhodobějším měřítku, nejdéle v rámci Sprintu, musí však celková vykázaná pracnost odpovídat celkovému alokovanému času na po sobě uskutečněných úkolech. Tím, že není vyžadované časově přesné alokování úkolů, je zde definována jistá uživatelská benevolentnost, která pomáhá tomu, aby se práce se systémem nestávala pro členy týmu přílišnou administrativní přítěží.
Pomocí třídy External Condition je možné evidovat závislosti jednotlivých položek Product Backlogu na externích podmínkách, které mohou podstatným způsobem ovlivnit proces vykonávání jednotlivých položek. Příkladem externí podmínky může být například nutnost dodání určitých dokumentů, jako je třeba analýza zpracovaná druhou či třetí stranou (např zákazník, externí dodavatel). V systému je pak u každé podmínky evidován takzvaný deadline interval, který označuje hraniční den pro splnění této podmínky. Je- li tento den překročen, nemůže nastat plánované zařazení dané položky do Sprintu a celý projekt tak může být brzděn. Tato funkcionalita spadá do odvětví Risk Managementu, kterým se sice Scrum primárně nezabývá, nicméně univerzální nástroj pro projektové plánování a řízení by měl takovéto funkcionality podporovat.
Položky obsažené v produktovém Backlogu jsou reprezentovány třídou Product Backlog Item. Každá položka obsahuje dokument (dokumenty) obsahující analýzu požadavku. Dokumenty jsou uloženy buď v nativním formátu aplikace (DocBook), nebo mohou být realizovány formou přílohy v libovolném formátu (doc, pdf, …). Přílohové dokumenty jsou evidovány třídou Attachement. V případě, že pracnost některé z položek přesahuje doporučenou dobu, systém podporuje rozdělení takových položek na několik dílčích podpoložek tak, aby jejich pracnost byla úměrná přibližně 10 MD. Toho by mělo být využíváno zejména u požadavků s vysokou prioritou, u kterých je velmi pravděpodobná jejich blízká implementace a očekává se od nich tedy co nejdetailnější specifikace. Další nadstandardní vlastností je možnost zachycení závislosti mezi jednotlivými položkami v produktovém Backlogu. Položka, která je závislá na jiné položce, může být implementována až po ukončení implementace položky jí nadřízené. Hlavním přínosem této vlastnosti je zpřehlednění produktového Backlogu.
Společnou vlastností tříd Product a Sprint Backlog Item je možnost zaznamenání existence závislosti mezi jednotlivými položkami.
Lidské zdroje jsou alokovány na projekty tak, že na daném projektu může pracovník vystupovat ve vícero rolích. Jeden pracovník může být na jednom projektu v roli Scrum Master, zatímco na druhém projektu v roli Team Member. Navíc může být Scrum Master zároveň i v roli Administrátora, který má právo například administrovat lidské zdroje.
V rámci Sprintu mohou vznikat různé problémy, které brání implementaci sprint backlogových položek. Řešením těchto problémů se zabývá vždy jedna konkrétní osoba – Scrum Master, který se o vzniklém problému dozvídá od členů týmu prostřednictvím denního meetingu. Jeho úkolem je pak problém co nejrychleji vyřešit anebo pověřit jeho vyřešením někoho jiného, kdo je k danému problému více kompetentní.
⦁ Funkční případy užití
Správa Sprintů
Sprint Management
Účastníci:
Scrum Master
Body rozšíření:
<Create Sprint>
<Update Sprint>
<Sprint Backlog Management>
Vstupní podmínky:
Uživatel přistoupil na úvodní stránku pro správu Sprintů
Tok událostí:
⦁ Uživatel prochází přehled Sprintů zvoleného projektu.
<Create Sprint>
<Update Sprint> – pouze u nového, či aktuálního Sprintu
<Sprint Backlog Management>
Alternativní tok:
Následné podmínky:
Create Sprint
Účastníci:
Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro založení Sprintu z obrazovky pro správu Sprintů
Tok událostí:
⦁ Uživatel vyplní vstupní pole:
⦁ název
⦁ požadovaný datum ukončení Sprintu (uživatel tak zvolí délku Sprintu)
⦁ Uživatel potvrdí tlačítkem Vytvořit
⦁ Pokud je předchozí Sprint uzavřen, je uživatel dotázán, zda chce nový Sprint zahájit
⦁ Systém založí nový Sprint
⦁ Pokud uživatel klikl ano, systém nastaví atribut je_aktivní na true a datum_zahajeni na aktuální datum
Alternativní tok:
Následné podmínky:
V systému je založen nový Sprint
Update Sprint
Účastníci:
Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro aktualizaci Sprintu z obrazovky pro správu Sprintů
Tok událostí:
⦁ Uživatel změní jedno nebo více polí:
⦁ název
⦁ aktivace Sprintu – povoleno pouze pokud není Sprint aktivní a zároveň předchozí Sprint byl ukončen
⦁ Systém aktualizuje Sprint, aktivace Sprintu viz případ užití Create Sprint
Alternativní tok:
Následné podmínky:
Sprint je aktualizován
Sprint Backlog Management
Účastníci:
Scrum Master, Team Member
Body rozšíření:
<Create SB Item>
<Update SB Item>
<Delete SB Item>
<Postpone SB Item>
<Export SB Documentation>
<Assign Task>
<Add Note>
Vstupní podmínky:
Uživatel klikl na odkaz pro správu Sprint Backlogu z obrazovky pro správu Sprintů
Tok událostí:
⦁ Uživatel prochází přehled a jednotlivé položky SB
⦁ Body rozšíření je možné aplikovat pouze v případě nového nebo aktuálního Sprintu:
<Create SB Item>
<Update SB Item>
<Delete SB Item>
<Postpone SB Item>
<Export SB Documentation> – je možné pro všechny Sprinty
<Assign Task>
<Add Note>
Alternativní tok:
Následné podmínky:
Update SB Item
Účastníci:
Scrum Master, Team Member
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro aktualizaci SB položky z obrazovky pro správu Sprint Backlogu
Tok událostí:
⦁ Uživatel změní jedno nebo více polí:
⦁ název
⦁ odhad pracnosti
⦁ popis
⦁ design
⦁ přidat poznámku
⦁ Uživatel volitelně vybere z commoboxu položku, na které daná položka
⦁ Uživatel potvrdí změny
⦁ Systém uloží změny
Alternativní tok:
Následné podmínky:
Položka je aktualizovaná
Delete SB Item
Účastníci:
Scrum Master, Team Member
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro smazání SB položky z obrazovky pro správu Sprint Backlogu
Tok událostí:
Systém provede smazání položky
Alternativní tok:
Pokud je na této položce závislá jiná položka, zobrazí se hláška, že není možné položku odstranit, dokud nejsou odstraněny všechny závislosti
Následné podmínky:
Položka je smazána ze systému
Poznámka:
Tento use case je využit pouze pro opravy při správě Sprint Backlogu
Export SB Documentation
Účastníci:
Scrum Master, Team Member
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro export SB dokumentace z obrazovky pro správu Sprint Backlogu
Tok událostí:
⦁ Systém vygeneruje dokumentaci pomocí přednastavené XSLT šablony s interního formátu DocBook do libovolného požadovaného externího formátu (např. html, pdf)
⦁ Uživatel si stáhne dokumentaci pomocí funkce Download
Alternativní tok:
Následné podmínky:
Assign Task
Účastníci:
Scrum Master, Team Member
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro přiřazení SB položky z obrazovky pro správu Sprint Backlogu
Tok událostí:
Systém vytvoří úkol (Task) pro danou SB položku s vazbou na uživatele a vyplní datum_od na aktuální datum
Alternativní tok:
Následné podmínky:
Položka je přiřazena uživateli
Postpone SB Item
Účastníci:
Scrum Master, Team Member
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro odložení SB položky z obrazovky pro správu Sprint Backlogu
Tok událostí:
⦁ Uživatel potvrdí tlačítkem Odložit
⦁ Systém založí vrácenou položku jako novou podpoložku do Product Backlogu a vytvoří vazbu na původní položku PB. Nová položka bude mít v Product Backlogu stav Vrácená z SB
⦁ Systém změní stav položky ve Sprint Backlogu ze stavu Založená na stav Vrácená
Alternativní tok:
Následné podmínky:
viz změny v toku událostí, body 2 a 3
Řízení úkolů
Process Task
Účastníci:
Team Member
Body rozšíření:
<Release Task>
Vstupní podmínky:
Uživatel klikl na zobrazení seznamu svých úkolů
Tok událostí:
1. Uživatel volitelně přidá poznámku k vykonávané položce
<Release Task>
Alternativní tok:
Následné podmínky:
Release Task
Účastníci:
Team Member
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro ukončení práce na daném úkolu z obrazovky s detailem svých úkolů
Tok událostí:
⦁ Uživatel vyplní vstupní pole:
⦁ uskutečněná pracnost
⦁ procentuální nasazení (defaultní hodnota 100%)
⦁ Uživatel je dotázán, zda je implementace kompletní
⦁ Systém změní stav Sprint Backlog Item v závislosti na odpovědi z předchozího kroku:
Ano = stav Naimplementovaná
Ne = stav Rozpracovaná
⦁ Systém nastaví vyplněné položky do tasku a automaticky nastaví datum do na aktuální čas a datum
Alternativní tok:
Následné podmínky:
Task je ukončen, stav SB Item je změněn
Správa produktového Backlogu
Product Backlog Management
Účastníci:
Product Owner
Body rozšíření:
<Create PB Item>
<Update PB Item>
<Delete PB Item>
<Decompose PB Item>
<Transform PB Item>
Vstupní podmínky:
Uživatel přistoupil na úvodní stránku pro správu PB
Tok událostí:
⦁ Uživatel prochází přehled a jednotlivé položky PB zvoleného projektu.
<Create PB Item>
<Update PB Item>
<Delete PB Item>
<Decompose PB Item>
<Transform PB Item>
Alternativní tok:
Následné podmínky:
Create PB Item
Účastníci:
Product Owner
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro založení položky PB z obrazovky pro správu PB
Tok událostí:
⦁ Uživatel vyplní vstupní pole:
⦁ název
⦁ priorita
⦁ deadline datum
⦁ popis
⦁ Uživatel potvrdí tlačítkem Vytvořit
⦁ Systém nastaví stav nové položky na Nová
Alternativní tok:
⦁ Uživatel vyplní odhad pracnosti
⦁ Systém nastaví stav nové položky na Analyzovaná
Následné podmínky:
V systému je založena položka v produktovém Backlogu ve stavu Nová
Update PB Item
Účastníci:
Product Owner
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro aktualizaci položky PB z obrazovky pro správu PB
Tok událostí:
Uživatel změní jedno nebo více polí:
⦁ priorita
⦁ deadline date
Alternativní tok 1:
⦁ Uživatel změní specifikaci
⦁ Systém po potvrzení změní stav položky na Nová
Alternativní tok 2:
⦁ Uživatel změní odhad pracnosti
⦁ Pokud byl předchozí stav položky Nová, systém po uložení změní stav položky na Analyzovaná
Následné podmínky:
Položka je aktualizovaná
Delete PB Item
Účastníci:
Product Owner
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro smazání položky PB z obrazovky pro správu PB
Tok událostí:
Systém provede smazání položky
Alternativní tok:
Pokud je na této položce závislá jiná položka nebo obsahuje podpoložky, zobrazí se hláška, že není možné položku odstranit, dokud nejsou odstraněny všechny závislosti
Následné podmínky:
Položka je smazána ze systému
Decompose PB Item
Účastníci:
Product Owner
Body rozšíření:
<Create PB Item>
Vstupní podmínky:
Uživatel klikl na odkaz pro rozdělení položky PB na podpoložky PB z obrazovky pro správu PB
Tok událostí:
⦁ <Create PB Item>
⦁ Systém při založení položky vytvoří vazbu na původní položku
⦁ Uživatel je dotázán, zda chce vytvořit další podpoložku
⦁ Pokud odpoví ano, tok pokračuje bodem 1
Alternativní tok:
Následné podmínky:
Systém založí jednotlivé podpoložky s vazbou na mateřskou PB položku
Transform PB Item
Účastníci:
Team Member
Body rozšíření:
<Create SB Item>
Vstupní podmínky:
Uživatel klikl na odkaz pro transformaci položky PB na položky SB z obrazovky pro správu PB
Tok událostí:
⦁ <Create SB Item>
⦁ Systém při založení položky vytvoří vazbu na mateřskou položku
⦁ Uživatel je dotázán, zda chce vytvořit další položku
⦁ Pokud odpoví ano, tok pokračuje bodem 1
Alternativní tok:
Následné podmínky:
Systém založí jednotlivé položky s vazbou na mateřskou PB položku
Create SB Item
Účastníci:
Team Member
Body rozšíření:
Vstupní podmínky:
Uživatel spustil usecase Transform PB Item
Tok událostí:
⦁ Uživatel vyplní vstupní pole:
⦁ název
⦁ odhad pracnosti
⦁ popis
⦁ design (textové pole ve formátu DocBook)
⦁ Uživatel volitelně vybere z commoboxu položku, na které daná položka
⦁ Uživatel potvrdí tlačítkem vytvořit
4. Systém nastaví stav nové položky na Založená
Alternativní tok:
Následné podmínky:
V systému je založena položka ve sprintovém Backlogu ve stavu Založená
Správa projektů
Project Management
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
<Create Project>
<Update Project>
Vstupní podmínky:
Uživatel přistoupil na úvodní stránku pro správu projektů
Tok událostí:
Uživatel prochází přehled všech projektů.
<Create Project>
<Update Project>
Alternativní tok:
Následné podmínky:
Create Project
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro založení projektu z obrazovky pro správu projektů
Tok událostí:
⦁ Uživatel vyplní vstupní pole:
⦁ název
⦁ zkratka
⦁ datum zahájení
⦁ očekávaný datum předání
⦁ odhad pracnosti
⦁ popis
⦁ Uživatel potvrdí tlačítkem Vytvořit
⦁ Systém založí nový projekt
Alternativní tok:
Následné podmínky:
V systému je založen nový projekt
Update Project
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro aktualizaci projektu z obrazovky pro správu projektů
Tok událostí:
⦁ Uživatel změní jedno nebo více polí:
⦁ datum zahájení
⦁ očekávaný datum předání
⦁ popis
⦁ Uživatel potvrdí změny tlačítkem Změnit
⦁ Systém změny uloží
Alternativní tok:
Následné podmínky:
Projekt je aktualizován
Správa externích podmínek
External Condition Management
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
<Create Condition>
<Update Condition>
<Delete Condition>
<Confirm Condition>
Vstupní podmínky:
Uživatel přistoupil na úvodní stránku pro správu externích podmínek
Tok událostí:
⦁ Uživatel si prohlíží tabulku, která obsahuje seznam externích podmínek pro daný projekt
⦁ Má možnost provádět následující operace:
<Create Condition>
<Update Condition>
<Delete Condition>
<Confirm Condition>
Alternativní tok:
Následné podmínky:
Create Condition
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro vytvoření podmínky z obrazovky pro správu externích podmínek
Tok událostí:
⦁ Uživatel vyplní vstupní pole:
⦁ název
⦁ časový interval (do kdy musí být splněna podmínka)
⦁ popis
⦁ Výběr ze seznamu PB položek (možnost výběru několika položek)
⦁ Uživatel potvrdí tlačítkem Vytvořit
⦁ Systém nastaví hodnotu atributu je_splnena=false
⦁ Systém založí novou podmínku s vazbou na položku (položky) Product Backlogu
Alternativní tok:
Následné podmínky:
V systému je založena nová externí podmínka
Update Condition
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro aktualizaci podmínky z obrazovky pro správu podmínek
Tok událostí:
⦁ Uživatel změní jedno nebo více polí:
⦁ název
⦁ časový interval
⦁ popis
⦁ Uživatel potvrdí změny tlačítkem Změnit
⦁ Systém změny uloží
Alternativní tok:
Následné podmínky:
Podmínka je aktualizovaná
Delete Condition
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro smazání podmínky z obrazovky pro správu podmínek
Tok událostí:
Systém provede smazání podmínky
Alternativní tok:
Následné podmínky:
Podmínka je smazána ze systému
Confirm Condition
Účastníci:
Product Owner, Scrum Master
Body rozšíření:
Vstupní podmínky:
Uživatel klikl na odkaz pro potvrzení podmínky z obrazovky pro správu podmínek
Tok událostí:
Systém nastaví hodnotu atributu je_splnena=true
Alternativní tok:
Následné podmínky:
Podmínka je evidována jako splněná
⦁ Životní cykly požadavků a úkolů
Životní cyklus PB položky
Položka PB vzniká po jejím zařazení na Product Backlog, tím se dostává do stavu Nová. V tomto stavu má položka všechny základní informace a zůstává v tomto stavu i po změnách priority a specifikace a to až do okamžiku analyzování pracnosti členy týmu, pak se dostává do stavu Analyzovaná. V tomto stavu je položka připravená pro zařazení do Sprint Backlogu. Stav není ovlivněn změnou priority avšak změna specifikace řadí položku zpět do stavu Nová.
Analyzovaná položka je po přiřazení celého obsahu, nebo jen části, do Sprint Backlogu automaticky považovaná za Implementovaná. Pouze analyzovaná položka může být zařazena do SB. Výjimkou je položka, která byla z SB vrácena, jde totiž o speciální druh analyzované položky, který má speciální název stavu pro zpřehlednění Product Backlogu. Další výjimkou je položka neúplná (viz dále).
Pokud jsou dokončeny všechny dílčí podpoložky původní položky z Product Backlogu, přechází tato položka do konečného stavu Dokončená, ve kterém zůstává již po zbytek celého projektu.
Může však nastat situace, kdy položka nemůže být do konečného stavu převedena, protože nejsou dokončeny všechny její podpoložky. To nastává například v případě, kdy byl ukončen Sprint, ve kterém nebyla implementována celá funkcionalita dané PB položky. V takovém případě je položka ponechána ve stavu Rozdělaná. Podmínkou pro zařazení do tohoto stavu je, že žádná z jejích podpoložek není aktivně implementována v právě probíhajícím Sprintu. Položka setrvává v tomto stavu dokud není její další část zařazena do Sprintu.
Životní cyklus SB položky
Položka SB vzniká zařazením některé z dílčích podpoložek položky produktového Backlogu na Sprint Backlog. Tato nově zařazená položka je v počátečním stavu označeném jako Založená, ve kterém se nachází až do doby, kdy je přiřazena k implementaci některému z členů týmu a dostává se do stavu Přiřazená.
V této fázi však může nastat výjimka, kdy položka místo do stavu Přiřazená přechází do stavu Vrácená a to v případě, že je daná položka vyřazená ze Sprint Backlogu a tím i z celého Sprintu. Tato situace nastává v případě, kdy se tým dostane do časové tísně a nestíhá tak odbavovat jednotlivé položky.
Vyřazená položka je poté vrácena zpět do produktového Backlogu. V systému to znamená, že pro přehlednost zůstává položka v SB Vrácená, nicméně už není aktivní. V produktovém Backlogu je založená nová položka s obsahem právě vyřazené sprintbacklogové položky (viz stav Vrácená z SB). Nová položka PB je založená jako tzv. podpoložka původní položky, ze které vznikla při založení do SB.
V průběhu fáze, kdy je položka Přiřazená, pracuje vývojář na její implementaci. Pokud ji úspěšně dokončí, přejde položka do stavu Naimplementovaná. Zde životní cyklus této položky končí.
Za určitých okolností však člen týmu nemůže implementaci položky dokončit, například v případě, kdy musí její implementaci dočasně přerušit a přednostně se věnovat jinému požadavku. Důvodem může být například zjištění dočasného problému nebo překážky bránící v pokračování implementace. V takovém případně je položka ponechána ve stavu Rozpracovaná, ze kterého se pak vrací zpět do stavu Přiřazená a následně Naimplementovaná. Tato funkcionalita je zde zahrnuta z důvodu sledování přesné alokace lidských zdrojů. Je tak zajištěna kvalita dat pro analytické funkce systému.
