Znáte to: Analytici se hodně snaží, ale nasazený systém se díky dalším změnám postupně vzdaluje od původní analýzy. Každý systém tak z pohledu analýzy stárne a jde jen o to, jak rychle…
Realizovaný kód nakonec nemusí odpovídat analytické dokumentaci a díky tomu tým padá zpět do chaotického vývoje, jako by analýza ani nebyla…
Jak tomuto samovolnému posunu „realizovaný kód versus analýza“ co nejvíce zabránit anebo aspoň omezit na přípustnou mez? Možná vám v agilní technice chybí jeden sloupec TODO.
High Level Analysis a Low Level Analysis
Doporučuji dodržovat osvědčené rozložení analytické dokumentace podle následujícího vzoru (viz obr.), který zavádí dva okruhy dokumentů, tzv. High Level Analysis a Low Level Analysis.
Pozn.: Obrázek je převzat z online školení Efektivní analýza v agilním prostředí. Na obrázku jsou znázorněny dvě varianty agilních technik SCRUM resp. KANBAN.
High Level Analysis (BPM + UCM)
Pod High Level Analysis rozumíme kombinaci procesního modelu s vazbou na případy užití, které jsou používány z „atomických“ koncových procesů (tzv. tasky v syntaxi jazyka BPMN). K evidenci všech procesů se používá tzv. rozklad procesů (neboli dekompozice procesů anebo procesní mapa), viz obrázek výše.
Rozklad procesů vede vždy k přesné a důsledné evidenci všech prvků Use Case neboli z pohledu programátora všech spustitelných funkcionalit. Pro zdárný průběh projektu je opravdu výhodné mít takovou evidenci. Pohled shora připomíná otevírání šuplíků resp. zapínaní zoom – přiblížení a oddalování detailu. Pomocí tohoto rozložení získáváme neustálou inventuru všeho, co by se mělo realizovat anebo již realizovalo. Tento přehled je navíc díky stromové hierarchii (růst uzlů stromu jde dolů geometrickou řadou) velmi účinný i pro velmi rozsáhlé systémy s řádově tisíci nebo dokonce deseti tisíci případů užití (banky, pojišťovny atd.).
Přiznám se, že na tento dokument nedám dopustit a neumím si představit, že by se v projektu netvořil.
Evidenci dokumentace High Level Analysis si vedeme a udržujeme po celou dobu projektu, jedná se o stálý nejvyšší „kontrolní“ pohled na systém. Toto rozložení doporučuji používat i u menších projektů, i když se může zdát, že je to vzhledem rozsahu systému zbytečné. I zde totiž platí, co není v evidenci dokumentace projektu, jakoby neexistovalo.
Je třeba podotknout, že programátora výstupy z High Level Analysis nezajímají. Jsou však velmi zajímavé pro hlavního analytika, který si může „odfajkovávat“, co se realizuje, a také pro budoucího uživatele (zadavatel, např. business oddělení apod.) a také pro vedoucího projektu (managery aj.)
Low Level Analysis
Nižší vrstva analytické dokumentace tzv. Low Level Analysis reprezentuje (s trochou nadsázky řečeno) „vnitřky“ prvků Use Case (konkrétně UC Scenarios), tedy program v kódu a doprovodné analytické Class Modely, které zavádějí sofistikovaný pojmový slovník pro evidované prvky a vztahy mezi nimi.
Základní filosofie postupu řešení
Nyní zpět k problému posunu kódu a analýzy. Uvedu zde základní myšlenku, jakou filosofií řešit problém posunu kódu versus analýza tak, jak jej zavádím ve firmách resp. předávám na školení, a který se mi osvědčil:
1)
Je třeba oddělit tvorbu Analýzy od tvorby Tasků a to i fyzicky přes kopie. Analýza a Tasky jsou dva okruhy dokumentace propojené vztahy tam a zpět typu „kdo s kým souvisí“. Tento vztah však není „živý“, ale je realizován přes kopírování obsahů.
2)
Při zadání vznikají nové Tasky do realizace, ty používají analytické modely jako zdroj, kopírují se jak texty, tak diagramy. Takto se Tasky oddělují od analýzy „fyzicky“.
3)
Během samotné realizace Task žije vlastním životem bez zpětného zásahu do analýzy během kódování. Pokud dochází ke změnám při realizaci, promítnou se změny v této chvíli pouze v Tasku, nikoliv v analýze.
4)
Po fázi testování alias akceptace (např. sloupec v KANBANU) se u Tasku zavádí jeden další nový krok (např. nový sloupec v KANBANU) a to „Feedback to Analysis“, viz obrázek:
V této fázi zpracování se naopak Task se svými případnými změnami stává zdrojem pro zpětnou opravu analytické dokumentace. Analýza se v zde stabilizuje do podoby, jak je realizován kód daného Tasku. Je zřejmé, že analytik zde musí úzce spolupracovat s programátory a technology, kteří se podíleli na realizaci tohoto Tasku. Teprve až po ukončení tohoto kroku končí také životní cyklus Tasku a přechází do stavu Hotovo. Analytický model se tak stává relevantním zdrojem pro další změny.
V případě, že dojde při kódování ke zjištění rozdílu v chodu procesu, tak se musí založit zvláštní Task pro analytiky pro přehodnocení High Level Analysis (BPMN) a provádí se klasické změnové řízení procesního modelu v BPMN. Přitom je třeba samozřejmě využít nástroje pro řízení verzí u daného CASE nástroje, např. Baselines v EA apod.
Základní premisy technologické disciplíny
Je zřejmé, že je třeba dodržovat základní premisy technologické disciplíny:
1)
Programuje se přesně to, co je zapsáno a zadáno v Tasku. Dodržení tohoto pravidla si vynucuje dva nutné procesy ve vývoji: Musí dojít ke vzniku Tasku na začátku (aby se zadalo, co se má programovat na začátku) a musí docházet k jeho změnám, když se na něco narazí při realizaci resp. je třeba blíže specifikovat. Změny se nejprve zadávají do Tasku a poté se realizují.
2)
Na začátku realizace Tasku a na jeho konci (stav Hotovo) musí být Task a Analýza v souladu.
Závěr
Všimněme si, že tímto postupem zpětné vazby až po testování se získá žádoucí stav, kdy se neztrácí agilnost, protože případné změny, které vyvstaly během kódován (upřesnění, specifikace, drobné změny apod.) se provádějí v rámci Tasku a nikoliv v analýze. Teprve následně po realizaci a po testování se změny promítnou zpět do analýzy jednorázově (a nikoli s každou drobnou změnou při realizaci).
Uvedený postup lze doplnit o další kontrolní mechanismy nad CASE nástrojem související se změnami modelů v průběhu realizace Tasku, např. porovnání verzí Baselines, změny v RDB modelu apod.
Napsat komentář