Axiom Value Based Management (VBM)¶
Pravidlo priority příjmů¶
Při vývoji informačního systému se musí posuzovat jak příjmy projektu (tj. peníze, které je zákazník ochoten zaplatit za užitečné hodnoty, které mu systém přináší), tak i náklady (typicky u SW odpracované člověkohodiny).
Základní pravidlo ohledně priorit příjmů a nákladů zní:
V projektu je vždy prioritní cíl hlídat příjmy a pak náklady. Nikdy ne v opačném pořadí.
Důvod: Příjmy jsou vždy podloženy nezbytnými náklady. Neuváženými škrty bez posouzení vlivu na hodnotu se hodnoty bortí stejně jako při neuváženém bourání nosných pilířů mostu. Následně při ztrátě hodnoty se příjmy buď sníží anebo dokonce úplně vynulují s krachem projektu.
Říkáme ekvivalentně, že projekt má být prioritně řízen hodnotově a nikoliv nákladově.
Definice VBM a CBM¶
Value Based Management (VBM) = během vývoje se kontinuálně sleduje, zda produkt stále nese hodnotu, za kterou zákazník zaplatí. Pokud tuto hodnotu ztratí, tak se příjmy poníží anebo dokonce zruší příjmy. Náklady se posuzují také, ale sekundárně jako nutný tvůrce hodnot. Balancuje se tak optimální výše daných nákladů jako nezbytná nutnost k získání dané hodnoty.
Cost Based Management (CBM) = vývoj se řídí primárně přes náklady. Škrtá se bez kontroly dopadů na hodnoty dodaného systému. Žádný balance příjmy versus náklady se nekoná. Mnoho takových škrtů zákazníkovi sníží hodnotu a někdy až fatálně natolik, že zákazník ztratí ochotu zaplatit.
Důsledky CBM — řetěz Rychlá issue → Tunel¶
CBM v praxi neprobíhá jako jednorázové rozhodnutí, ale postupně — projekt sklouzává do CBM přes řetěz dílčích kroků, kdy každý vypadá rozumně, ale celek vede ke ztrátě hodnoty. Tento řetěz má v AAF dvě pojmenované fáze: metodiku Rychlá issue a stav Tunelu.
Metodika Rychlá issue¶
Metodika Rychlá issue je způsob práce, kdy se každá změna systému řeší jako jednotlivé issue: požadavek přišel od konzultanta nebo zákazníka, rychle se zapíše, rychle naprogramuje, hotovo. Vypadá to agilně. Není to agilně.
Klíčový rozdíl: Rychlá issue rozhoduje po jednotlivých issue bez nadřazené hodnoty užitku. Není UC, který by issue zarámoval do širšího užitku. Není BPM-UCM-CLM, který by hlídal konzistenci napříč systémem. Issue je samostatný, ad hoc atom.
V krátkém horizontu Rychlá issue funguje — práce se hýbe, zákazník vidí výstup. V delším horizontu se issue začínají překrývat, narážet na sebe a opravovat předchozí issue. Logická konzistence systému slábne.
Tunel¶
Tunel je stav, do kterého projekt vedený metodikou Rychlá issue nevyhnutelně dospěje. Symptomy:
- bludiště ad hoc oprav bez nadřazené struktury,
- geometricky rostoucí technologický dluh,
- pojmový slovník v rozporu (jeden UC mluví o „Zákazníkovi", druhý o „Klientovi", myslí totéž),
- ztráta opětovné použitelnosti — typické situace se neidentifikují jako vzor, řeší se znovu pokaždé,
- ztráta důvěry zákazníka — slibovaná hodnota se nedoručuje, nebo se doručuje s rostoucím opožděním a chybovostí.
Tunel je past právě proto, že vstup do něj vypadá jako zkratka. Rychlá issue se v krátkém horizontu jeví jako efektivnější než zavádění UC, BPM-UCM-CLM a hodnotového řízení. V delším horizontu ale úspora neexistuje — ztracený čas se vrací mnohonásobně v podobě přepracování, ztráty hodnoty a v krajním případě krachu projektu.
Vztah Tunelu k Waterfallu¶
Tunel a Waterfall jsou dvě různé anti-metodiky se stejným důsledkem: ztráta hodnoty. Liší se v mechanismu:
- Waterfall ztrácí hodnotu pomalou zpětnou vazbou — analýza, návrh a realizace běží v dlouhých sekvenčních fázích, zákazník vidí výsledek pozdě.
- Tunel ztrácí hodnotu fragmentací bez nadřazené struktury — zpětná vazba je rychlá, ale na úrovni jednotlivých issue, ne na úrovni hodnoty užitku celého systému.
AAF se vyhýbá oběma současně: rychlá zpětná vazba plus hodnotové řízení přes BPM-UCM-CLM.
Hodnota užitku systému – funkcionality systému¶
Hodnotové řízení projektů se týká mnoha sledovaných vlastností systému: nízká chybovost, vysoká stabilita, flexibilita, security, nízký technologický dluh aj.
Specificky pro oblast Agile Analysing (a tedy AAF) je stěžejní očekávanou hodnotou systému „užitek systému pro zákazníka".
Tato hodnota je reprezentována „seznamem funkcionalit systému", které systém musí splňovat. Pokud je nebude systém umět anebo dělat jinak, než má, hodnota se výrazně ztrácí.
Proto byl v UML už v 1.0 zaveden tzv. Use Case Model (UCM). Use Case není funkce ani metoda; je to pojem spojený s užitkem — s hodnotou pro zákazníka, tedy pojem úzce spojený s VBM.
Avšak klasická tvorba UCM, která tento problém teoreticky řeší, vede bez AAF k dlouhé a nákladné analýze bez zpětné vazby, tzv. anti-metodika Waterfall.
AAF plně řeší tento úkol:
Jak udržet hodnotu užitku – funkcionalit (VBM) a zároveň zachovat agilní postup s rychlou zpětnou vazbou.
AAF zavádí VBM specificky v doméně analytického modelování jako axiom.
Formulace AXIOMU AAF¶
Neztratit během agilního vývoje hodnotu užitku systému očekávanou zákazníkem.
Od toho se odvíjí celý framework.
Verze a změny¶
- 1.2 - změna názvu na Axiom...
- 1.1 — doplněna sekce Důsledky CBM — řetěz Rychlá issue → Tunel mezi sekci Definice VBM a CBM a sekci Hodnota užitku systému. Sekce zavádí dva nové pojmy: metodika Rychlá issue (CBM v praktickém provedení — issue-driven práce bez nadřazené hodnoty užitku) a Tunel (stav projektu, do kterého Rychlá issue dovede). Doplněna pod-sekce Vztah Tunelu k Waterfallu — odlišení dvou anti-metodik se stejným důsledkem (ztráta hodnoty), ale různým mechanismem (Waterfall = pomalá zpětná vazba, Tunel = fragmentace bez nadřazené struktury). Důvod úpravy: kapitola Analytické modelování — LLA odkazuje na pojem Tunel forward přes „viz kapitola VBM".
- 1.0 — první verze kapitoly.