Vztah UML a analýzy k Review a Retrospective Sprintu ve SCRUMu (odpověď na otázku z webináře), část 1.

Po webináři Jak tvořit High Level Analýzu v agilních technikách (SCRUM apod.) jeden účastník vznesl tyto dvě zajímavé otázky:

Měl bych dva doplňující dotazy ke vztahu UML a SCRUMu:

1. Jaká je úloha analýzy na review sprintu?
2. Jaká je úloha analýzy na retrospektivě ke sprintu?

Zdravím, L. K.

Tento článek odpovídá na obě otázky.

Analýza v agilních technikách, ano nebo ne?

Rád bych úvodem upozornil na jednu důležitou věc, která se týká právě postupů tvorby analytických dokumentů v rámci agilních technik.

Jak jsem si všiml, tak diskuse o agilnosti (resp. její ztráty) někdy sklouzne do velice zjednodušující otázky „Má se analýza dělat, ano nebo ne, když tak zdržuje?“. Jako příklad bych uvedl jeden z odstrašujících pojmů vystihujících ne-agilní postupy ve smyslu „Comprehensive Documentation“.

Ano, samozřejmě, nemá se dělat hora dokumentace jen proto, aby byla. Ale to neznamená, že se analytické úvahy úplně vynechají. Například neumím si představit, že by se navrhovala agenda úvěrů čistě agilní metodou bez nějakých analytických úvah (a úvahy musí být zapsány), tj. že by nikdo neřešil, jak má vlastně úvěr chodit. Ad hoc postup metodou pokus omyl by byl v podstatě pádem do chaotického vývoje nazývané také jako anti-metodika TUNEL ( = tým jde černým tunelem a vidí snad tak na jeden krok dopředu).

Vzpomínám v této souvislosti na jednu úsměvnou historku ze školení o SCRUMu, kde se přednášející snažil vychválit SCRUM tím, že údajně on si postavil celý dům metodou SCRUM od A až do Z. Jeden z účastníků se jej zeptal, zda existovaly nějaké namalované plány tohoto domu před zahájením stavby a dopředu nahrubo navržené postupy, aby se nezačalo střechou. Odpověď zněla „samozřejmě“. Účastník na to jen poznamenal: „Děkuji, to mi stačí…“

Jak je to tedy s analýzou v agilních technikách?

Zde je třeba na úvod připomenout hlavní důvod, proč je dobré agilní techniku používat:

Při nasazení nedoporučovaného postupu Vodopád se nejprve vytvoří velký kus analýzy, poté velký kus návrhu technologie a teprve poté se přistupuje ke kódování – a proto název Vodopád. Samozřejmě zřetelně vidíme obrovskou nevýhodu v pomalé zpětné vazbě (a také v řízení lidských zdrojů – vývojářů).

Při nasazením agilní techniky vývoje získáme velice rychlou zpětnou vazbu. Znamená to, že se velice rychle přechází ke kódování (samozřejmě na něj musí být vždy fokus, to je konečný výsledek tvorby SW) a to je ono obrovské plus agilních technik. Příznivý důsledek spočívá hlavně v tom, že se velice rychle odhalují případné analytické chyby ve smyslu „takhle jsme to nechtěli“ anebo „takto to bohužel nepůjde“.

Pokud spadneme do pasti Vodopád, tak odhalení takové chyby může být řádově za týdny a dokonce i za měsíce, což je samozřejmě nepřijatelné. Daná chyba rodí další chyby, takže velké kusy analýzy se musí doslova překopat a bohužel toto následné druhé kolečko má opět velké časové zpoždění.

Pokud se zamyslíme nad podstatou výhody agilní techniky ve smyslu „rychlá zpětná vazba“, tak zjednodušující otázka „analýza ano anebo ne“ je vlastně nesmyslná, protože vůbec nevystihuje podstatu problému. Spíš to vystihuje situaci „neumíme dělat analýzu s rychlou zpětnou vazbou“.

Z toho plynou tyto závěry:

1. Analýza je nutná. Podle principu Occamovy břitvy musí být v takovém rozsahu, že v ní není ani písmenko navíc
2. Analýza se tvoří tak inteligentně a v takovém pořadí kroků, že se dodrží princip rychlé zpětné vazby

…a o tom to všechno je.

Díky rozumnému postupu získáme už během prvních pár dnů analýzy první možné zadání do kódování (tj. první prvky do Project Backlogu a poté do Sprint Backlog ).

Následně se s dalšími kroky analýzy v rychlém sledu rodí další a další zadání do realizace.

Právě tyto efektivní postupy od High Level Analýzy až dolů umožňují získat opravdu super rychlou zpětnou vazbu při zachování nutné (avšak pouze nutné, tj. nic navíc) analytické dokumentace.  Navíc dokumentace vzniká jako součást vývojových prací „in situ“ a nikoli „ex post“ po vývoji, jak tomu mnohdy bývá (anebo naopak při Vodopádu velice dlouho před realizací)…

Výsledkem dobrých postupů je příznivý stav, kdy programátoři nečekají na velký kus analýzy. Realizace SW se totiž uskutečňuje „takřka paralelně“ s analýzou. Práce na realizaci běží sice o malinko opožděně, ale v podstatě pouze „o jeden krok pozadu“ oproti analýze.

Jak vypadá rozumný postup od High Level Analýzy až ke kódu při dodržení rychlé zpětné vazby?

Ohledně tohoto rozumného postupu tvorby analýzy, který odpovídá agilnímu postupu, se mi líbí jedno velice výstižné přirovnání:

Představme si, že máme obrovský kus lesní plochy (např. Kanada, Sibiř apod.) a máme tuto velikou plochu obhospodařovat, tj. v našem příkladu někde kácet nemocné nebo nahusto vysazené stromy. Vzhledem k obrovské velikosti plochy se nejprve vytvářejí satelitní snímky. V tomto pohledu jsme hodně vysoko. Vidíme ale zřetelně hranice lesní plochy, vidíme i hlavní lesní cesty apod. Následují letecké snímky, v této situaci jsme sice ještě někde hodně vysoko, ale níž. Začneme vidět větší detaily, například odhadujeme podle barvy a z měření druhy dřevin, sklony svahů apod. A pak jdeme až do lesa, kde už budou dřevorubci s motorovými pilami, to jsme vlastně na úrovni samotné realizace obhospodaření přímo na místě (implementace).

Tento pěkný příklad je dobrou analogii s tvorbou IS:

Satelitní snímky odpovídají dokumentům High Level Analysis, což reprezentují dokumenty v textové podobě popisující některé procesy velice nahrubo a kde si velice dobře rozumíme s budoucím uživatelem systému.

Letecké snímky odpovídají nalezení případů užití (Use Case), kdy začneme vidět detailněji ty oblasti „kde se co má udělat“.

Práce dřevorubců odpovídá práci programátorů, tj. z pohledu je na nejnižší úrovni („na úrovni stromů“), tzv. Use Case Implementation View. Jsou to vlastně již „vnitřky UC“ neboli scénáře programu, ze kterého vznikne konkrétní zadání pro konkrétní práci dřevorubce.

Přechod od High Level Analysis (satelit) k BPM and Use Case View (letadlo) až k Use Case Implementation View (práce dřevorubce)

Mimochodem existuje jedna velmi častá chyba při nasazení SCRUMu, kterou velmi pěkně vystihuje přísloví „pro stromy nevidíme les“. To přesně odpovídá této analogii, kdy se vývojáři pohybují pouze v úrovni dřevorubců mezi stromy, tj. v realizaci (Tasky) a nevidí les shora, vidí jen haldu střípků jako dílčí zadání pro zpracování stromů (viz např. předešlý článek)

Analogie je pěkná i v tom, že názorně ukazuje rozdíl mezi metodou Vodopád a agilními technikami např. SCRUM.

Metoda Vodopád:

1. Nejprve vyhotovíme všechny satelitní snímky celé oblasti, zjistíme rozsah. Vyhodnotíme všechny snímky.
2. Poté vyhotovíme všechny letecké snímky všeho.
3. Potom v každé oblasti popíšeme vše, co se má se stromy udělat.
4. Pak tam teprve vpustíme do lesa dřevorubce s pilami (kteří doposud čekali hodně dlouho na výsledky naší práce).

Asi tušíme nebezpečí tohoto postupu: Velmi dlouhá zpětná vazba. Například nastane situace ve smyslu „Tady jsme předpokládali smrky, ony to jsou duby, takto se to nedá zpracovat, musí se vzít jiná technika a udělat jiná cesta“ apod. Bohužel z toho plynou další nepříjemné důsledky pro další již pracně naplánované postupy…

Samozřejmě takový omyl je v každém případě nepříjemnou situací. Je ale jasné, že situace je o mnoho lepší, když se taková chyba odhalí co nejdřív. A k tomu má mimo jiné sloužit rychlá zpětná vazba v agilních technikách.

Metody agilních technik:

1. Vyhotovíme nejprve pouze některé satelitní snímky. Jsou to tzv. „hlavní snímky“, například v lese podél hlavních cest apod. V analogii při tvorbě IS tvoříme textový popis pouze tzv. Klíčových procesů podniku, kterých je velmi málo na prstech jedné ruky (Text Epic).
2. V několika málo vytipovaných snímcích, kde se ihned jeví možnost prací, posíláme letadlo pro letecké snímky (a nikam jinam). Tomu odpovídá v IS přechod od textu k tzv. modelu Use Case View. Máme několik málo oblastí, kde se co má udělat ( = nalezené UC).
3. V několika málo oblastech (neboli UC) analyzujeme a popíšeme zpracování stromů a to navíc, pokud je toho hodně, ještě ne všechno v dané oblasti. V analogii pro SW řešíme pouze některé časti ze scénáře UC, nikoliv celý UC.
4. Na těchto několik málo míst posíláme dřevorubce, kteří na toto zadání nečekali dlouho.
5. Důležité: Přitom paralelně současně s těmito pracemi přechodu dolů od satelitu až ke stromům v bodech 1-4 postupně a neustále rozšiřujeme oblast řešení, tj. rozšiřujeme zpracování dalších oblastí (nabalování řešení – Project Scope Widening). Současně však sledujeme a vyhodnocujeme zpětné vazby od práce dřevorubců.

Jak je vidět, tak postupy analytických prací lze řídit tak, že projekt nebude ztrácet na agilnosti a přitom získá také obstojnou a postačující dokumentaci analýzy. Když se podíváme na ilustrativní obrázek s paralelou zpracování velké oblasit lesa, tak se jedná hlavně o problém, jak co nejrychleji „putovat“ ze satelitního pohledu k dřevorubci v lese a zpět. Výsledkem prací je nakonec nejenom hotový SW, ale současně i pohledy shora na něj z nejvyšší úrovně až po implementační pohled.

Konec první části, pokračování následuje

[myrelposts-related title=”my title”]