Při čtení článku na serveru Lupa.cz :
Pracovali jsme i na Štědrý den, ale stejně jsme za blbce…
se mi vybavila velmi známá situace: Jak vypadá projekt vývoje IS řízený nedoporučovanou anti-metodikou Tunel.
O tom je tento článek.
Celý článek na Lupa.cz (a následné zprávy o fungování projektu) vystihuje ukázkově a velmi přesně důsledky anti-metodiky Tunel.
Jak tato anti-metodika funguje, viz obr. z prezentace „Agile – HLA“ :
Poznámka: Obrázky si můžete lépe prohlédnout přes „pravé tlačítko myši a Otevřít na nové kartě“.
Stačí vybrat pár charakteristických vět (včetně samotného názvu článku):
„Projekt se větvil a ukázalo se, že ani zdaleka nejde pouze o jednoduchý formulář…“
Viz bobtnání projektu, navíc ex post po nasazení se zjistilo, že tam chybí dost podstatná funkcionalita „zpětvzetí přihlášky“.
„Docházelo ke zpožděním..“
Viz nedodržování termínů, došlo i k odložení nasazení.
„Stalo se i to, že Mirek Krejčí se svým synem sedli do auta, jeli do Bratislavy a tam celý víkend programovali. Mirkův syn programoval responzivitu front-endu.“
Viz zbytečná hektičnost prací
„ Oslovili jsme vývojáře, se kterými naše firma dlouhodobě spolupracuje… Myslím si, že většina programátorů by do toho nešla, protože časový tlak byl obrovský…“
A tady už začíná svítat, kde je problém, a to ani ne tak tím, co se popisuje, ale tím, co tam chybí.
V celém článku se nevyskytuje ani jedna zmínka o profesionálním analytikovi a o tvorbě artefaktů z oblasti zvané jako
High Level Analysis.
Zmínka je jen o úvodní 7 hodinové schůzce…
A to je jádro pudla.
Pokud by se jednalo o IS banky nebo IS pojišťovny, tak by se určitě analýza na úrovni High Level Analysis prováděla. Evidentně zde však došlo k podcenění jednoho z velmi nepříjemných Murphyho zákonů:
Každý IS na začátku vývoje vypadá menší, než ve skutečnosti je.
A dodatek tohoto zákona: A to i se znalostí tohoto zákona
Toto je nejzáludnější vlastnost vývoje IS. Nazývá se také „manažerský syndrom“, protože této nebezpečné iluzi ve smyslu „však na tom nic není“ podléhají hlavně manažeři, ředitelé, vedoucí, ale také zadavatelé projektu apod.
Co je to High Level Analysis (HLA) a Low Level Analysis (LLA)
Rozdělení na obě oblasti analýzy vystihuje tento obrázek z již zmíněné prezentace:
Jednoduše řečeno v oblasti HLA se identifikují a popisují takové činnosti okolí systému (BPM), které používají systém (UCM). Doporučuje se tvořit tuto analýzu i v případě malých systémů, protože i pro ně platí zmíněný Murphyho zákon. A důsledky pro malé systémy jsou stejné jako u velkých, viz zmíněné nedodržení termínu, hektičnost prací a opominutí některých funkcionalit s jejich nalezením ex post po nasazení.
Proč se tedy mnohdy HLA nedělá?
Jsou dva základní důvody, proč se HLA nedělá:
1) Protože se vůbec neví, že něco takového existuje (pro programátory je to oblast úplně mimo, protože HLA není program, ten je až v LLA)
2) Protože se sice ví, že existuje, ale neví se, jak HLA tvořit rychle a efektivně.
Jednou ze zásad tvorby HLA je soustředit se nejdříve na tzv. klíčový proces a ten velmi rychle analyzovat, nejprve v textu (to jde rychle) a teprve poté se „přemalují“ do modelu BPM a UCM:
Například velmi pochybuji, že by se při popisu klíčovém procesu v textu u zmíněného systému podání přihlášek nenadnesla otázka: „A co když chce daný uživatel přihlášku stáhnout zpět?“ Na tyto otázky nikoliv „Happy Scenario procesu“ má analytik díky „neblahým“ zkušenostem také fokus, protože tam může být ukryt „ďábel v detailu“ (nesplácení úvěru, nevrácení knížky v knihovně, omyl v zadání převodu materiálu z místa na místo, „oživení“ mrtvého v evidenci omylem zadaného jako mrtvého apod.) . Při zkoumání BPM alias „kroků“ u klíčového procesu Podání přihlášky by se na to zeptal každý byť jen trochu zkušený analytik.
Následně se tvoří další oblasti HLA, které mají povahu tzv. tanečků okolo, aby tento klíčový proces dobře fungoval. Bohužel, mnohdy je těchto tanečků asi tak 60% – 80% procent všech funcionalit.
Závěr
Podcenění HLA má větší negativní dopady na vývoj IS, než chybějící LLA. Nedostatky anebo dokonce chybějíc HLA vede k fatálním nedostatkům na nejvyšší analytické úrovni se všemi již zmíněnými důsledky.
LLA již v tomto není až tak kritická, protože zde se již programátoři pohybují na její úrovni a rozumí problematice přímo v realizaci. Proto lze LLA tvořit postupně (agilně) a nejprve „v ruce, na papíře“, hned se zadá do realizace ( = task resp. issue) a následně se dokumentuje až naprogramovaný výsledek reverzní analýzou.
Napsat komentář