V minulém článku bylo pojednáno o významu analýzy a o efektivních postupech její tvorby v agilním prostředí SCRUM. V této části se budeme věnovat otázce, v jakém vztahu je analýza k procesům SCRUMu zvaným Sprint review a Sprint Retrospective.
Sprint Review se zaměřuje na inspekci samotného přidání přírůstku a Sprint Retrospective se více zaměřuje na inspekci procesu (postupů) ve sprintu.
Pro vysvětlení pozice analýzy a UML Sprint Review a Sprint Retrospective použijeme tento názorný obrázek, který je jednou z nosných myšlenek tvorby High Level Analysis a Use Case Implementation View:
Shora čteno obrázek zobrazuje rozklad procesů. Tento strom má i další synonyma, jako „oblasti řešení“ nebo také „dekompozice procesů“ anebo také „mapa procesů“. Na koncových listech rozkladu procesů jsou použity případy užití. Ty mají ve své implementaci scénáře, ve kterých si můžeme označit jejich části a tyto části (anebo celý UC) se stávají jako popis algoritmu programu zdrojem pro zadání do SCRUMu.
S trochou nadsázky bych tento dokument nazval také jako „bible projektu pro vedoucího“ :) . Tento dokument se skládá jako puzzle postupně a dost hekticky. Ale už od počátku tvorby poskytuje dobrou možnost inventarizace projektu.
Poznámka: Velice podrobně o dané problematice viz webinář zdarma na dané téma 10 výhod High Level Analysis pro vedoucího projektu.
Tento strom je i u středních systémů relativně rozsáhlý, ale protože se tvoří efektivně s agilním přístupem s fokusem „jít rychle dolů“. Analytici tak rychle přechází k výstupům, tj. k tvorbě zdrojů pro zadání ve formě Tasků a User Story ve SCRUMU. Znamená to, že se snažíme o co nejrychlejší „ponoření do hloubky“ stromu, což jsou úplně dole části scénářů, které se stávají zdrojem pro zadání (viz obrázek).
Sprint Review
Tým ve Sprint Review prezentuje výsledky, jakých dosáhl během sprintu. Obvykle má Sprint Review podobu předvedení nových funkcí anebo základní architektury. Podoba má být neformální a neměla by sklouznout do prezentace výsledků ve formě obdoby „obchodní předváděčky“ v Powerpointu (tj. žádná „Potěmkinova vesnice”). Ukazuje se tedy přímo realizace, je však možné předvést doprovodné dokumenty (např. diagram architektury, schéma apod.). Měl by se ho zúčastnit celý tým, ale je otevřen i pro návštěvy z jiných týmů („whole world invited“).
Vztah Sprint Review a High Level Analysis
Jak ukazuje předešlý názorný obrázek, tak každý realizovaný kus kódu nějaké funckionality má svoji pozici: Nachází se v daném případu užití jako jeho UC Scenario Fragment (resp. se jedná o „celý scénář UC“). Tento Use Case je navázán na daný Task (tj. koncový proces rozkladu) a ten je umístěn v dané větvi rozkladu. Tímto je přesně definována pozice každého kódu v systému. Pro vedoucího poskytuje tento přístup velmi výhodný přehled o systému.
Jako příklad čteno shora:
Podnikový systém (= nejvyšší proces, sumarizuje všechny oblasti řešení), jeho jedna pod-větev Účetní operace (stále velká, ale menší kapitola), jeho pod-větev Chod došlé faktury, koncový proces a následně Use Case: Založení došlé faktury v systému. UC Scenario Fragment : Výběr partnera – Task: realizovat tento UC Scenario Fragment + podrobnosti z technologického zadání.
Při inspekci naprogramované funkcionality je určitě velice vhodné ukázat, která část systému se řešila, tj. ukázat u dodaného prvku ( tj. u tzv. „shippable prodtuct“) jeho pozici v řešení, viz příklady a obrázek výše.
Poznámka: Daný strom rozkladu působí sice „molochálně“, ale je třeba opětovně zdůraznit, že tento strom se svými větvemi se netvoří celý metodou Vodopád, ale skládá se vcelku efektivní metodou: Pomocí identifikace klíčových procesů se najdou právě ty koncové listy, které se dají naprogramovat jako první. Na začátku prací má tento strom rozkladu funkcionalit pouze několik málo prvků (větví) nalezených v klíčových procesech a ty se řeší. Současně se ale pracuje na tzv. „nabalování řešení“ (Project Scope Widening).
Vztah Sprint Review a Use Case Scénářů (tj. UC Implementation View)
Zatímco High Level Analysis s rozkladem procesů umožňuje určit pozici řešení v systému, tak scénáře UC, resp. jejich části, (viz obrázek výše) jsou již zdrojem pro tvorbu zadání do realizace. Pomocí nich se navrhují Tasky resp. User Story (mnohdy např. pouze s odkazem na danou část scénáře případně doplněno o další technologické poznámky). Může se ale jednat také o zadání realizace definiční části systému, tj. zadání pro realizaci struktur (např. objektové třídy + RDB pomocí ORM apod.)
Pokud se předvádí řešení, tak je vždy dobré také uvádět zadání, která se měla splnit. Pokud jsou tato zadání tvořena tímto velmi efektivním postupem (viz výše), tak se tyto analytické UC fragmenty objevují také ve Sprint Review ve smyslu „takové bylo zadání vyplývající z analytického modelu a takto to vypadá jako již hotové v realizaci“.
Sprint Retrospective
Sprint Retrospective provádí inspekci a posouzení průběhu sprintu ve smyslu „jak se to dělalo“, tj. z hlediska procesů neboli postupů v týmu.
Poznámka: Jako velký přínos nasazení SCRUMu považuji neustálý tlak na rychlou zpětnou vazbu a to i z hlediska postupů prací.
Při Sprint Retrospective se zodpovídají tyto tři základní otázky:
- Co by se mělo dělat a nedělalo se („start doing“)
- Co se dělalo a nemělo by se dělat (neosvědčilo se, „stop doing“)
- Co se dělalo a mělo by se dělat (osvědčilo se, „continue doing“)
Díky zodpovězení těchto otázek se získává rychlá zpětná vazba ohledně postupu prací v týmu.
Co se týče vztahu Sprint Retrospective a nasazení UML (jak zaznělo v otázce od účastníka), tak se jedná vlastně o položení těchto tří základních otázek právě na tuto oblast. Tím se získává efektivní zpětná vazba ohledně výstupů z analýzy a použití UML.
Jak ukazují zkušenosti, tak se většinou jedná o námitky vůči zápisům scénářů, případně nepřehlednosti analytického zadání, případně nějaké chybějící informace v zadání apod., anebo se může jednat o návrhy pro lepší dohodu nad analytickými typy a mapování na technologické typy apod.
Pomocí této zpětné vazby se tak průběžně zdokonaluje přechod od analytického modelování k zadání a realizaci do kódu.
Konec článku
Prosperující SW firma hledá analytiky a JAVA programátory v okolí Hradce Králové
V případě zájmu pište na e-mail objects@object.cz
