Druhý pilíř – (Skoro)Neustálé inkrementální dodávky vyvíjeného produktu

Každou vývojovou iteraci se musí dodat inkrement výsledného produktu. Rámcově se může jednat o část automatizovaných test case, část prototypu nebo část výsledného řešení. Postupuje se od nejdůležitějších částí k těm méně důležitým s cílem maximalizovat využití paretova pravidla.

Během jiných než vývojových iterací se musí také něco dodat, typicky je to solution design (nebo jiná neproduktová specifikace vývoje), dokumentace, analýza ve wordu (to je totiž dokumentace prototypu) a další formality, které jsou důležité, ale nejsou produkt. Definici produktu je nutné si odladit hned na začátku. Na produkt by se měl zákazník těšit, pokud je mu to jedno, zpravidla je to formalita. Projekty, které jsou celé formalita neděláme, ty odkládáme, pokud jsou regulatory a nikdo interní o ně nemá zájem, doporučil bych watterfall a schopného dodavatele s referencí na implementaci této regulace.

Délka jedné iterace by měla být cca 14 dní. Ve firmách, kde se nasazuje jednou měsíčně, by tak měla dobře vycházet vždy jedna vývojová a jedna nevývojová iterace.

 

Proč oddělovat inkrementy produktu a ostatních částí dodávky?

Postup prací v incremental BI se definuje postupem na produktu, postup na formalitách je druhotný (protože nezajímají zákazníka). Tato kategorizace je zásadní pro rozkrytí neefektivit vývojového procesu. Má to zásadní vliv na uvažování o projektu – nikdo totiž není schopný vám zbytečnými specifikacemi, analýzami apod. uměle nafukovat dodávku a spoléhat se na to, že se to ztratí.

U větších projektů, kde jsou specializované role (developer, tester, analytik, solution architect, data architect, atd), je možné mít více inkrementů najednou, jejich řešitelské týmy jsou ale jasně odděleny.

Inkrement by měl vždy končit na produkci (ať už je jím cokoliv). Toto by mělo bavit a hlavně zapojit zákazníka. Pro fázi analýzy (=prototypu) jde zpravidla zajistit nějakou omezenou databázi na produkčním prostředí / reportserveru apod. Standardizace už není tak zajímavá (zákazník je zpravidla vyžaduje jen nepřímo), tuto poslední fázi zpravidla dotáhneme interně (zákazník už má tou doubou prototyp na produkci).

 

 

 

Cílem je koncentrace – jakmile se jednou člověk nebo tým zakousne do kódu (a komentářů v něm) měl by v něm zůstat co nejdéle. Těkat mezi Wordem, kódem a modelem je zpravidla dost neefektivní. Toto jednoduché pravidlo má za následek dva klíčové stavy – jednoduché řízení očekávání do okolí. (například při nevývojové iteraci je jasné, že nebude nic nasazovat, je zřejmé, že budete spíš komunikovat s architekturou apod., řešit formality a nebudete tolik vytěžovat zákazníka), a druhý stav je komunikace postupu prací – velmi dobře dokážete oddělit, kolik času trávíte dodávkou vlastního produktu a kolik práce vám přidělává okolí. Je to velmi dobře komunikovatelné na statusech a steeringu.

 

V tří-vrstevné architektuře (DEV,TEST,PROD) nelze za 14 dní dodat na produkci. Ano, iBI je vždy nutné zasadit do kontextu konkrétního zákazníka. Někomu stačí dodat do UAT (test) prostředí (a to už se stihnout dá).

Také je možnost odladit dostatečně prototyp a dohodnout se, že se celý standardizuje do výsledné podoby BI řešení jedním nebo několika většími inkrementy. Aby to fungovalo, musí se splnit několik předpokladů – businessově je prototyp zcela v pořádku a je závazně akceptován zákazníkem, chybí jen technicistní standardizace (správný typ historizace, podoba cizích klíčů, ssis balíčky apod., dokumentace) a tato standardizace je jasně zadaná a provádí se nad stejnými daty jako prototyp. Čím lepší máte automatizované testy tím lépe, můžete je použít pro ověření standardizace. Tato část má totiž nejmenší riziko change requestu a zároveň je tu sporná role zákazníka.

Při určitém zjednodušení lze říct, že čím více je organizace vodopádově zaměřená, tím více mají smysl prototypy. Některé firmy budou mít řešení sestavené třeba z 60% z protototypů. Aby to bylo udržetelné je nutné vědět, co je produkčně provozovatelný prototyp a co není a jaké má na sobě SLA.





Leave a Comment

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *